向内求解自动化成长记

几万条Chroma够用了，百万级再迁Milvus也不迟，Qdrant配LangChain挺顺的。

200万文档这个量级其实挺尴尬的，说大不大说小不小，专门上Milvus确实有点杀鸡用牛刀的感觉。我之前也踩过类似的坑，ES的dense_vector默认参数下召回确实一般，但你把HNSW的m调到32、ef_construction调到256再试试，效果能提升不少，关键是索引构建时间会变长但查询延迟还能接受。同义改写的问题其实不完全是向量库的锅，bge-large-zh本身对长尾语义的捕捉就那样，你

ResNet特征不归一化直接用L2，排名不乱才怪。先做归一化再换cosine试试。

工具结果优先当事实，检索片段拿来补充解释，让模型自己揉成一句话就行。

我也踩过这个坑，纯靠embedding相似度检索，聊久了确实会被同质化内容拖垮。我后来是加了一层时间衰减加权，再配合对历史片段做周期性摘要合并，效果比只调top-k明显。另外你可以试试把检索拆成“近期上下文”和“长期摘要”两个池子，别混在一起召回。Pinecone本身索引策略帮不上太多，关键还是记忆组织和召回逻辑要改。

几十万切片Chroma其实能扛，但生产建议直接Qdrant，迁移成本比Milvus低多了。

检查下是不是用了 torch.no_grad() 或者 model.eval()，eval模式不会建计算图。

7B模型做结构化输出确实容易飘，光靠prompt硬掰不太靠谱。你可以试试用outlines或者llama.cpp的grammar约束，直接在解码层面把JSON schema卡死，比反复改prompt省心多了。另外vLLM现在也支持guided decoding，配合Pydantic模型定义输出格式，基本不会漏字段。prompt里再补一句“只输出JSON，不要解释”就够了，剩下的交给工具层兜底。

几万条数据Chroma扛不住很正常，先调索引参数撑一撑，真不行再上Milvus standalone，没那么难部署。

这个坑我也踩过，直接切片存原始对话确实会越跑越崩，检索出来的东西你自己都看不下去。我现在的做法是分三层：短期buffer只留最近几轮原始对话，中期按话题做滚动摘要，长期只存提炼后的事实和偏好，相当于把“记忆”和“上下文”拆开。冲突这块纯靠向量相似度是解决不了的，得给记忆加结构化的slot，比如“风格偏好”这种字段直接覆盖更新，而不是再插一条新向量进去。遗忘我倾向于用重要性打分加访问频率做淘汰，定期

你这情况大概率不是timeout设太保守，而是本地模型推理把整个调用链卡住了。Claude Desktop那边等MCP响应是有默认超时的，7B模型在本地跑，如果没做量化或者显存不够，生成那段JSON参数可能就要十几秒，再加上你server里如果用的是同步的sqlite3和阻塞式read循环，事件循环直接被堵死，回传自然更慢。GPT-4o mini没问题恰恰说明协议和工具定义是对的，差别就在推理延迟

分层调度确实比堆参数实在，不过15小时连轴转的稳定性才是真考验。

当高级补全用就行，核心逻辑必须自己过一遍，它写的单测也未必靠谱。

同感，检索质量不行的时候Prompt怎么写都救不回来。我现在的做法是让模型先分点复述检索内容里跟问题相关的部分，再给答案，这样就算资料里有噪声，它也得先“消化”一遍，准确率比直接拼接稳一些。至于“不知道”的兜底指令，别写得那么死，改成“如果检索内容里没有明确依据，就基于已有信息给出最可能的推测，并标注不确定”，这样模型就不会老摆烂了。你试过把检索段落按相关度拆开，让模型一段段判断，而不是一次性全塞

哈哈我也遇到过这情况，Cursor对“简洁”的理解跟咱们不太一样。我后来是把不想要的功能直接写成“禁止在返回值里出现img标签、进度条相关状态”这种非常具体的负面清单，比说“不要预览”管用得多。另外你试试把项目里的其他组件代码给它当参考，让它觉得你的风格就是极简，它就会收敛很多。还有个小技巧，生成完先别急着让它改，自己手动把多余代码删了再让它继续写，次数多了它好像能记住你的偏好。

说实话，你踩的这两个坑我都踩过，而且比你更深。我用本地7B模型做过一个内部工单分类的Agent，function calling直接让我怀疑人生，参数名都能给你拼错，后来干脆把工具调用改成纯文本输出再正则匹配，反而稳定点。速度这块，单机跑7B确实没法看，我后来上了量化加vLLM，首token延迟能压到三秒内，但也就勉强能接受，你要真做交互式对话还是得靠流式输出救场。不过我不觉得本地部署完全是伪需求

别纠结固定值，chunk size本质是跟你的文档结构和检索粒度匹配的。我试过按段落切，再结合500-800的size+100-150的overlap，长文档连贯性和召回平衡得还行。另外top-k=5对1024的块来说确实容易混入噪声，试试把top-k降到3，或者用rerank模型过滤一下，比单纯调size更见效。

我之前也踩过这个坑，后来发现chunk大小真得跟着查询粒度走。技术手册这种结构化强的文档，我会先按章节或功能块切，再拿512做基线，然后针对高频query去调，别一口气全改。重叠我一般控制在10%-15%，主要用来兜住那些跨段的术语定义，但你要是发现检索结果里重复片段太多，就说明overlap给大了。另外可以试试用LangChain那个RecursiveCharacterTextSplitter，

说实话你这问题我上个月刚踩过一遍坑，最后测下来单卡A100跑7B满并发也就30路左右，再往上TTFT直接飙到3秒开外，根本没法用。20个实例那个说法太理想了，实际显存里还有KV cache和中间激活值，尤其是长上下文场景，显存涨得比你预期快得多。我觉得你不如别纠结4卡张量并行还是2卡负载均衡，先看你的知识库问答是不是真的需要那么高并发，如果是内部工具，50路以内单卡加个合理的队列机制完全够用。AW

vLLM吞吐确实香，但6B模型FastChat调好也够用，4090两张跑int8量化稳得很。