南窗听风录

我之前也踩过这坑，system prompt别每条都塞，抽个10%-20%加进去反而更稳。

我之前也踩过类似的坑，bge-m3对长文本的语义区分其实没那么细，512字符切可能把“报销流程”和“差旅标准”揉进一个块里了。你先试试把chunk缩到256甚至128，overlap调到32，看召回是不是更聚焦。另外，建议给每个chunk加上文档标题或小标题作前缀，能明显提升相关性。如果还不行，再考虑用rerank模型把top-k从5拉到20之后精排，比单纯调embedding更直接。

试试把相关段落直接硬塞进prompt最前面，再让模型逐字引用，我这么干效果立竿见影。 这情况我也遇到过，换个更强的rerank模型往往比调prompt管用，你可以先拿个交叉编码器试试。

改代码建议用单独的小任务让它只改函数内部，别给整个文件的上下文，不然它老爱自己重构。 别让它一口气改太多，把要改的地方单独抽出来问，上下文一大它就飘了。

这配置跑7B确实勉强，试试把swap开大点然后换llama.cpp，别用vLLM了。

说实话我觉得你这个问题大概率不是embedding的锅，text-embedding-3-small在通用语义上已经够用了，尤其重置密码和权限管理这种明显属于不同意图的query，召回错位更像是chunk切分把上下文搞碎了。你试试把chunk提到800到1000字，overlap给到150左右，让每个片段保留完整的动作主体和对象，可能比换模型见效快。调相似度算法的话，cosine和IP在归一化向量

T4上bge-large确实吃力，可以试试bge-small或m3e，速度能提一截，效果差距没想象大。 多路召回加rerank延迟肯定翻倍，建议先量化再上，不然线上扛不住。

同感，Cursor现在真的越用越憋屈，模型切换麻烦还老断连。不过Trae那个端侧模型我实际体验下来，补全速度确实快，但复杂逻辑还是得靠云端，切换时能感觉到延迟差异。 CodeBuddy的多Agent倒是挺新鲜，重构老项目时能自动拆解任务，这点比Trae聪明。但有个问题想请教：这俩工具对私有化部署或内网项目支持怎么样？我们公司代码不能出内网，一直没敢深度用。

Prompt约束是一方面，但更关键的是在检索层给模型“断粮”——我试过把chunk切小到300字左右，并且让每个chunk自带标题和来源页码，模型引用时明显老实很多。另外你可以在Prompt里加一句“如果上下文没有直接对应内容，请回答‘资料中未提及’”，比“不知道”更具体。XML标签可以保留，但别指望它解决缝合问题，我最后是加了相似度阈值过滤，低于0.7的chunk直接不送进上下文。

这问题在LangGraph里太典型了，本质是主Agent的意图路由没做好，建议把子Agent能力描述写详细点，再给主Agent加个强制tool_call的校验逻辑。

reranker基本是必上的，另外切块别死守512，试试按语义段落切，效果会明显不一样。

两万条这个量级其实top_k不用太纠结，我一般先按10-15起步，然后看召回结果里相似度分数的分布。如果0.7以上的结果能覆盖主要答案，就固定在这个区间，不然就动态截到分数掉到0.6以下的位置。另外embedding模型确实有影响，text-embedding-3-small维度低，语义区分度有限，你试试换个稍大点的模型，可能同样的top_k噪声就少很多。还有个小技巧，你可以把检索回来的段落按分数

试试给长期记忆按主题分片存储，检索时只取和当前Query最相关的2-3段，比纯摘要靠谱很多。

我之前也踩过这个坑，后面发现光靠prompt约束确实容易翻车。自己写个轻量级的状态机或者用LangChain的AgentExecutor加个中间检查点，能强制控制在关键节点上，比纯靠模型自觉靠谱得多。另外可以试试把工具调用拆成两步，先让模型输出行动计划，再单独执行，这样它的“乱跑”几率会小很多。你用的是GPT-4的话，也可以把Function Calling的description写得更死一点，限

强烈建议试试把few-shot示例直接塞进system prompt里，别只调temperature。再不行就上正则兜底，微调真没必要。

版本控制加增量索引呗，ChromaDB按文档ID过滤旧的，新数据单独embedding进去就行。 定时重索引确实坑，我试过按更新时间戳做增量更新，配合缓存命中率能好不少。

看到你从faiss直接跳生产，我建议先别急着选型，把数据规模和QPS峰值再估一估。几百万条其实两个都能扛，但Milvus真正的优势在分布式和混合查询，比如标量过滤加向量检索同时做，Qdrant单机部署确实省心，但如果你以后数据涨到千万级还要加节点，它的集群方案成熟度不如Milvus。延迟100ms这个要求，其实HNSW参数比选库更关键，我踩过坑的是M（每层最大连接数）设太大，内存直接翻倍，建议M控

语法树切分绝对是正解，尤其Python这种缩进即结构的语言，用ast库把函数和类直接拎出来当chunk，Go那边用go/parser也能搞定，比固定行数靠谱太多了。不过要注意大函数可能还是超token，建议对超长的函数再按顶层语句拆，同时把函数签名和docstring保留在第一个chunk里。另外你既然用了LangChain，可以试试它的RecursiveCharacterTextSplitter

几百条数据太少了，LoRA学不到函数选择的边界，建议先拿现成toolbench数据做SFT试试。

碰到过一模一样的状况，最后发现多半不是max_iterations的问题，而是ReAct的推理循环在长上下文里自己把自己绕晕了。工具描述太长确实是个坑，模型每次都要重新读一遍，注意力全被无关的细节吸走，参数生成就容易在几个token之间打转。我后来把每个工具的description压到三行以内，只留关键参数格式和返回值类型，卡顿立刻少了大概一半。另外，中间结果压缩那块你可以试试用个简单的摘要节点，