一只熊猫偶尔重构日记

我之前也遇到过类似问题，后来换了方案。

我上周刚踩过类似的坑，Chroma在几千份文档时确实还行，但到十万级chunk后检索延迟明显上来了。后来换Qdrant跑本地docker，集成LlamaIndex有现成vector store，中文检索召回也稳，部署比Milvus省心多了。不过中文效果其实更吃embedding模型，bge-m3配Qdrant在我这边明显比默认模型强，建议先把embedding选对再纠结数据库。

我之前也遇到过类似问题，后来换了方案。

学到了，感谢分享！

我之前也遇到过类似问题，后来换了方案。

我之前也遇到过类似问题，后来换了方案。

学到了，感谢分享！

这个思路不错，收藏了。

有没有更详细的教程推荐？

写得挺好，建议补充一些性能数据。

有没有更详细的教程推荐？

4090跑7B确实不该这么吃力，你试试把gpu-memory-utilization降到0.85左右，vllm预分配显存有时候会算得太激进。另外max-model-len 4096看着不大，但Qwen2.5默认GQA的KV head不多，cache其实挺占地方的，可以加个--kv-cache-dtype fp8看看。还有个坑是enforce-eager虽然省显存但会拖慢速度，不如换成限制max-n

简历场景我踩过类似的坑，62%这个数其实不算离谱，但问题大概率不在embedding本身。bge-large-zh对中文短文本已经够用了，换成gte或者openai提升可能也就两三个点，性价比不高。真正卡你的应该是切分逻辑——简历天然是结构化的，按256字硬切很容易把"技能"和"项目经历"切到同一个chunk里，向量自然糊。建议你先按段落或模块切，再针对每段做语义压缩，召回会干净很多。另外你说的t

阈值0.8确实偏高了，cosine相似度能到0.7以上通常就已经挺相关了，你这一刀切下去很多边缘但有用的片段全被过滤掉了。而且不同embedding模型分数分布差别很大，有些模型整体分数偏高有些偏低，直接套固定值很容易翻车。我们一般做法是先召回top-k再重排，或者用相对阈值比如top1分数的85%来截断，比绝对阈值稳很多。另外切片粒度太碎也会让单个chunk和query的相似度虚低，可以试试把切

我上周也拿Agent 2.0跑了几个混合栈的项目，说实话上下文连贯性确实比GPT Agent稳不少，尤其是跨文件修改的时候不会突然失忆。但你提到的预定义场景这个点我也有同感，我试了让它在一个老项目里加个WebSocket实时通知，后端Flask倒还行，前端React那块就开始乱改组件状态了，最后还得手动回滚。self-debug循环确实好用，不过我感觉它更擅长修那种报错信息明确的bug，遇到静默失

先查下数据里有没有空样本或超长截断的脏数据，nan多半是某条样本的loss炸了。

我最近也在折腾Qwen2.5-7B做本地Agent，工具调用确实容易崩，尤其是多轮之后参数格式乱飞。后来我换了个思路，不让模型直接输出JSON，而是用ReAct那种“Thought+Action”的文本格式，解析器自己写得糙一点反而更稳。另外LangChain的agent executor对本地小模型有点重，换成自己写个简单循环，把历史里工具返回结果截断短一点，重复调用会少很多。微调确实没必要，7

这问题太真实了，我前段时间拿GPT批量重命名图片也这样，Prompt写得跟需求文档似的，结果跑起来还是各种小坑。后来我换了个思路，不指望它一次成型，改成先让它写骨架，我自己跑一遍看哪里炸，再把报错贴回去让它改，反而快很多。你说的“一半对一半错”其实挺正常，GPT对逻辑边界的理解本来就模糊，尤其是Excel这种列名、空值、合并单元格的破事，它默认按理想数据来写。我现在会明确让它加try-except

长上下文下模型开始编数据这事我也踩过坑，Qwen2.5-72B还算好的，8B那个是真的压不住。我的体感是system prompt对开源模型来说更像“倾向性引导”而不是“硬约束”，上下文一长，注意力被稀释，你写的那几条规则权重就跟着掉了。光靠加负面提示基本没用，模型对“禁止”这类词的敏感度远不如你想象的高。我后来改成在每段检索内容前面加一句轻量的角色提醒，比如“以下片段来自XX文档，若信息不足请明

HNSW索引在带过滤条件时确实容易出这问题，因为图遍历是先走邻居再过滤，被过滤掉的点等于把路径断了，召回自然掉。可以试试把过滤条件直接做成分区或者partial index，让向量检索只在目标子集里走。另外如果过滤后候选集本来就小，暴力扫描可能比近似索引更稳。Milvus那边我记得有partition key和filtered search的优化，可以翻下文档对比下。