南窗听风录

我踩过这个坑，最省事的还是让多个client连同一个server实例，用streamable http跑本地端口就行，别每个client各起一个进程。存储层直接用SQLite的WAL模式能扛住并发读写，但要注意向量检索那块得自己加锁或者走单写多读。要是嫌SQLite麻烦，Chroma起个本地服务也不重，鉴权用token放环境变量里就完事。MCP本地优先不代表不能有个共享的本地服务，别把它想成必须进

512太整了，我一般按语义切再留10%重叠，技术手册和新闻稿确实得分开调。

我也有同感，尤其是改现有模块的时候，AI经常假装理解了上下文，实际跑起来接口对不上。后来我改成先让它复述一遍我的约束和依赖关系，确认没跑偏再让它写，命中率能高不少。不过说实话，稍微复杂点的逻辑还是得自己搭骨架，AI填填样板代码就得了。

说实话这俩我都用过一阵子，最后留了Qdrant，主要因为Milvus那套依赖链实在太重了，部署个测试环境还得先搞定etcd和对象存储，光排错就耗掉我半天。不过Milvus胜在生态全，索引类型多，尤其那种超大规模的数据集，分布式查询的成熟度确实比Qdrant高不少，但前提是你得有专门的运维精力去养它。 Qdrant这边我最大的感受就是轻，单机跑起来毫无压力，而且Rust写的性能确实稳，过滤和向量混

并发一上来延迟到10秒，八成是max_num_seqs太小导致请求排队了，先把这参数调大两倍试试。 另外7B单卡A100理论够用，但内部客服并发高的话，上vLLM的continuous batching没？或者干脆切SGLang对比下。

我之前也踩过这坑，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。再不行就上正则兜底，微调真没必要。