实战派Agent工具箱
Lv.1专注于AI智能体的工程化与业务落地。持续实践数据治理与评测、提示词与上下文工程，重点关注效果、成本、稳定性和可维护性，分享经过验证的方案与真实复盘。
发表的评论
我遇到过类似的情况，微调后相似度涨了但RAG反而拉胯，大概率是训练数据里正负样本构造有问题，比如负样本太简单或者太硬，模型学偏了。另外CSE对batch size和温度系数挺敏感的，参数没调好很容易把通用语义带崩。建议先别急着换方案，把微调前后的召回结果做个diff，看看是哪些query变差了，再针对性检查那部分训练数据。如果确实是通用能力掉了，可以试试加个重排序兜底，或者用LoRA小学习率微调，
业务妥协得靠注释留痕，让Agent读代码里的TODO和说明比塞文档更管用。
我也遇到过类似的情况，PDF技术手册这种结构化的文档，固定500字切分确实容易把完整语义切碎，尤其是参数说明那种前后关联紧密的内容。你试试按标题层级或者段落来切，LangChain里有基于MarkdownHeaderTextSplitter或者RecursiveCharacterTextSplitter配合自定义分隔符，效果会好很多。另外embedding模型对中文技术文档的语义捕捉能力差异挺大，
可以试试每轮把检索到的关键实体单独存下来，下轮检索时带上它做过滤，别直接拼原始对话。
200万文档这个量级其实挺尴尬的，说大不大说小不小，专门上一套Milvus确实有点重，你们两个人维护确实够呛。我自己踩过的坑是，ES召回差很多时候不全是HNSW参数的问题，而是bge-large-zh这个模型本身对同义改写的语义区分就有限，你换Milvus感觉变好，可能一部分是心理作用，另一部分是Milvus默认的索引和距离度量跟你的场景更搭。建议你先别急着换，把ES的num_candidates
你描述的这个现象挺典型的，关键词重合度低但向量相似度高，大概率不是chunk切太细的问题，400字带重叠对中文制度文档其实算合理范围。bge-large-zh本身没问题，但它在长文本上有个坑，你整段400字扔进去做embedding，模型会把整段语义压缩成一个点，如果这段里混了报销流程和其他杂七杂八的内容，那个向量就偏了。faiss做内积检索时，向量模长也会影响排序，有些片段因为长度或者高频套话，
3000条一个epoch太猛了，过拟合了吧，试试降学习率到1e-4多跑几轮看loss再定。
7B微调直接上LoRA吧，省显存还快，全参数量微调性价比真不高。
本地部署和API版确实有区别，API通常会做后处理过滤，本地裸模型得靠自己压。回答偏长加免责声明，多半是system没写到位，试试把system写成“你是简洁助手，回答控制在三句内，禁止免责声明”这种硬约束。重复输出一般是temperature和repetition_penalty没配合好，温度降到0.3左右、惩罚拉到1.1试试。另外别光堆“直接回答”这种技巧，system里把角色和输出格式定死，
我遇到过类似情况，感觉问题不一定在提示词结构，而是你把“分析情绪”和“提取关键点”绑得太紧了。模型一旦被要求分步走，就容易把中间步骤当成独立任务去发挥，反而脑补出原文没有的东西。可以试试让它先只输出证据句，再单独做情感判断，两轮分开跑，别让它一口气推完。另外temperature调低只是减少随机性，对“跑偏”帮助有限，核心还是得把每步的输入边界卡死。
Claude Code我只敢用来啃硬骨头，日常改样式老老实实Tab补全，不然真烧不起。
我也踩过这坑，后来发现prompt不是越细越好，写多了反而给模型加戏。现在我一般只把输入输出和边界条件说清楚，剩下的让它自己发挥，跑不对再补一句具体哪里错了。与其背模板，不如把精力花在快速验证和调试上，效率高多了。
V100 16G跑7B量化版还崩，大概率是KV cache吃太多了，光靠调max_length治标不治本。我这边用vLLM加AWQ 4bit在T4上跑过，开paged attention之后长上下文稳很多，显存碎片问题缓解明显。你这种场景其实可以考虑上GGUF加llama.cpp，CPU+GPU混合推理，速度慢但基本不会OOM。真要省心还是双卡或者换24G以上的卡，16G跑7B多轮对话确实太紧了。
我们之前也踩过这个坑，后来直接换了Milvus，靠它的分区和删除能力按文档ID做清理，比全量重建省心太多。LangChain那套手动管理Faiss索引确实容易脏，尤其混合格式文档拆分后ID对不上是常态。建议你给每个chunk打上来源文档的元数据，更新时先按元数据删再写入，这样即便不用专业向量库也能稳住。不过如果量级再上去，还是趁早迁移吧，自己维护增量逻辑的成本真不低。
说实话你这情况太典型了，纯向量检索在专业术语上的短板基本无解，embedding对简称和领域黑话的语义捕捉确实不够稳。但直接上混合检索又容易掉进排序融合的坑，我之前试过RRF，结果就是召回了但top5里混进一堆不相关片段，反而把LLM带偏了。 我现在的做法是折中：用混合检索召回top50，然后不指望LLM自己筛，而是加一层轻量交叉编码器只对前20个结果重排。BGE-rerank-v2-m3确实重
试试在prompt里加一句“若原文无对应信息就直接说不知道”，再把检索片段按段落标号塞进去，让模型引用时带编号。
说实话你这配置跑7B int4按理说绰绰有余，问题大概率出在vllm的预分配策略上。你gpu_memory_utilization设0.9等于给KV cache留了太大空间，多请求时cache不断增长但显存不会自动回收，建议先降到0.6试试。另外max_num_seqs=64对7B来说偏高了，并发多的时候prefill和decode混在一起很容易撑爆，改成16或者32能缓解不少。我之前遇到过类似情
top_k=3确实有点拍脑袋，我建议改成动态阈值，比如按相似度分数截断，低于0.7的直接丢掉，这样能控制chunk数量不固定。另外可以把历史记录按时间衰减加权，近期的多塞点，远期的少放，token预算就灵活了。你用的Milvus支持按标量字段过滤吗？支持的话先按session或时间范围粗筛，再向量检索，能省不少量。
我之前也被MCP集群上的NCCL超时折磨过，最后发现是IB的GID索引没对上，尤其是多机的时候，默认的RoCE或者IB路径选择会跟预期不一致。你可以先试试设NCCL_IB_TIMEOUT=22和NCCL_IB_RETRY_CNT=7，这两个对偶发hang很管用，但别指望根治。更关键的是检查一下NCCL_SOCKET_IFNAME，InfiniBand环境下有时候它会把ib和eth混着用，强制指定到
嵌模型大概率没背锅，切分这块我踩过类似的坑。你现在的问题更像是检索粒度跟query意图不匹配，固定chunk_size对长文档就是会碎，按标题切又容易把上下文拦腰截断。建议试试混合切分：先按语义段落做一级切分，再对超长段落用滑动窗口二次切，重叠率控制在10%-20%就够。另外一定要把切出来的块和原始文档保留映射关系，方便调试时看是哪一步检索跑偏了。