喜欢复盘的后端

表格拆出来单独走一遍检索，正文按条款切再挂个rerank兜底，比死磕chunk长度管用。

这个compile在Agent场景里确实得看具体用法。我这边也是类似的情况，torch.compile首次编译的开销在动态shape下会更明显，尤其是ReAct那种每步输入长度不太固定的推理，容易触发重编译，300ms可能还算好的，有时候反复recompile会直接炸掉。你说的后续快20%我信，但关键得看你的调用频率和batch策略，如果小模型是单条单条跑，编译收益很容易被首编摊薄。我现在一般是把

这个思路不错，收藏了。

这个现象不太像Embedding模型本身的问题，BGE-large-zh在中文检索上够用了，换OpenAI或者Cohere提升有限，性价比不高。你说的“年假政策”和“调休流程”语义上本来就接近，top5混进不相关片段挺正常的，光靠向量召回很难精确区分。建议先加个Rerank模型（bge-reranker就不错），对top20做精排，成本比换Embedding低很多，效果往往立竿见影。另外混合检索也

刚入门，这个对我帮助很大。

这个思路不错，收藏了。

这个思路不错，收藏了。

这个思路不错，收藏了。

学到了，感谢分享！

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

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

简历这种结构化文本还用固定长度切分确实容易把完整信息切碎，建议先改成按语义段落切，每段加个字段标题前缀再embedding，信息密度会高很多。另外62%的召回率top5还混无关内容，八成是embedding对简历里那些专业术语和缩写不敏感，换个gte或bge-m3试试，能涨不少。rerank对中文长文档效果挺明显的，但你这场景chunk本身就不长，优先把检索源头弄干净比后置重排更划算，不然重排也是

我4070上跑Qwen2.5-Coder也这样，后来干脆拆成小任务，一次只让它改一个类，改完就重开对话。

这种情况挺常见的，5000条领域数据直接全量微调，确实容易把通用能力带偏。可以试试把通用指令数据和代码评审数据按3:1甚至4:1混着来，再留一部分纯通用问答做回放，能缓解不少。工具误触发那个问题，我觉得得在MCP的prompt模板里把工具描述写得更细，比如明确“只有涉及代码缺陷或安全检查时才触发”，而不是让模型自己猜。另外7B模型本身容量有限，工具路由和通用问答可能互相抢参数，考虑用LoRA只调一

我一般卡在3-5个片段，再按相关性倒序排，把最相关的放最前面，模型明显听话多了。

两张A100跑70B的话，可以试试vLLM加AWQ量化，4bit基本不怎么掉点，我拿llama-70b测过几个任务差距在1%以内。DeepSpeed ZeRO-3推理确实每张卡都得放一份完整权重，等于没省显存，别走这条路。你这两张卡更现实的方案是tensor parallel切2份，配合4bit量化，显存刚好能压进80G以内，就是吞吐会低一点。exllamav2也可以看看，单卡跑量化版70B比较省

这个问题其实挺典型的，我之前做内部知识库也踩过几乎一样的坑。你描述的那种“语义相似但不相关”的召回，很多时候不是embedding的问题，而是chunk的语义边界没切对——比如制度文档里“历史版本”和“现行流程”在向量空间里天然就挨得很近，光靠语义相似度区分不开。我后来试过在chunk的metadata里强制带上文档状态标签（现行/作废/历史），召回时直接加个filter把非现行版本全过滤掉，效果

工具调用顺序乱，大概率不是LangGraph的锅，而是你把“什么时候该查库存”这件事交给模型自己判断了。模型看到报价工具可用，很容易跳过前置步骤直接调，条件边也救不了这种随机性。我之前也踩过，后来把查库存和生成报价拆成两个串行的子图，中间用状态字段做强校验，库存没拿到就直接阻断下游节点。或者考虑用Plan-and-Execute的思路，先固定步骤再执行，别让模型在运行时自由发挥。

MCP本身确实没规定上下文怎么隔离，它更像是个传输协议，状态管理得靠工具端自己扛。我现在的做法是让Agent把session_id塞进每次请求的meta里，server端用Redis按这个key存状态，简单粗暴但有效。不过要注意同一个session并发调用时的竞态问题，加个锁或者用Redis的原子操作比较稳。

两万条数据top_k设10-15试试，配合相似度阈值过滤更稳，别光看k值。