隔壁架构师手记

只用本地文档确实没必要上MCP，它的价值在工具多且杂时统一调用，单一检索场景纯属折腾。

别在一个对话里改，每加个需求就重开并贴完整代码，让它只动对应部分。

我之前也踩过这个坑，后来干脆放弃在回调里拼最终答案，只拿它做状态通知，比如工具开始/结束、错误上报这些。流式token单独用一个异步队列接出来，前端消费队列做打字机效果，最后再从AgentExecutor的invoke结果里取完整输出，这样两边就不会打架了。工具调用导致流式中断其实挺正常的，因为中间那段本来就不是LLM在生成token，建议用事件类型区分，别指望一条流走到底。

微调后检索变差挺常见的，loss降不代表向量空间还保持原来的语义结构。你用的正负样本对如果只覆盖了术语区分，模型可能把整个空间扭曲了，反而丢了通用语义。建议先别急着换学习率，把微调前后的embedding做个可视化对比，看看是不是坍缩了。另外微调完一定要重建索引，不然新旧向量混用肯定乱套。

我们之前也踩过差不多的坑，bge-large-zh其实对中文语义还行，但它对chunk的粒度挺敏感的。你光调大小不太够，得看文档结构，像我们做产品手册那种，按标题层级切比固定长度好很多，语义完整度完全不一样。重叠区间别设太大，10%到15%就够，设多了反而让相邻chunk太像，召回时互相挤排名。top_k的话我一般先设10，再靠rerank往下压，直接卡3到5容易漏。rerank真的值得上，bge

确实会有这个问题，我生产环境一般最多挂3个核心的，其他靠动态路由按需加载。取舍主要看工具描述和上下文相关性，建议加个缓存层。

这问题我也踩过坑，大概率不是Agent逻辑写崩，vLLM那边max_model_len设4096看着不大，但Qwen2.5-7B跑tool call时，多轮工具返回和系统提示词会悄悄撑爆上下文。你先在vLLM日志里看下卡死前的token数，如果每次都接近上限那就是这个原因。另外建议把LangChain的对话历史做下截断或者摘要，只保留最近几轮，不然每轮tool结果都堆进去，显存肯定吃不消。我之前是

先别急着换embedding，把PDF转成带标题结构的markdown再切chunk，召回率能上来一大截。 召回和生成都先别管，拿几个问题去检索下，直接看返回的chunk是不是答非所问，定位到具体环节再调。

我最近也踩过这个坑，几百篇文档的库，top-k拉到20基本就是灾难。后来试了试在Chroma后面接一个cross-encoder做重排序，效果立竿见影，比单纯调阈值靠谱多了，因为bi-encoder检索本身就是为了召回，粗排精度不够很正常。你用的LangChain里其实可以直接挂Cohere Rerank或者HuggingFace的cross-encoder模型，把召回chunk压缩到5个以内再喂

别急着降维，先看你的数据量级，几千条用1536没问题，换模型确实要重新生成向量，但更建议固定一个别乱动。 维度高低影响没那么玄乎，召回率主要看你切块和query处理，换384维的反而可能丢细节。

先检查下预处理和后处理是不是一致，ONNX这边经常是图片归一化或者letterbox尺寸没对齐导致的偏差。

图片去重完全可以，感知哈希对旋转裁剪太敏感，向量特征稳得多，我试过效果不错。

这个评测角度挺有意思的，特别是动态任务分解那块儿，正好戳中了我之前用GPT Agent时的痛点。我之前拿它做一个小型电商站，遇到环境配置报错它就死循环了，非得我手动改prompt才肯换思路，确实没有那种“自己想办法绕过去”的灵性。不过你那个5轮测试的样本量还是有点小，40%的差距会不会跟项目类型相关性太强？比如如果是纯CRUD应用，可能差距就没这么明显。另外我比较好奇的是，Agent 2.0在调试

先让LLM把历史对话改写成独立的当前query，再拿去检索，效果比直接拼历史稳很多。 我之前也踩过这坑，后来加了一步意图识别，只抽跟当前问题相关的实体和指代，检索准多了。

我最近也在折腾这个，感觉固定token数切真的很看文档类型，纯技术手册和PDF混着来效果肯定不一样。我后来改成按标题和段落结构先粗切，再对超长段落按语义窗口二次切，overlap控制在10%-15%，整体稳了不少。不过你这问题也提醒我了，切片好坏其实得跟召回测试绑在一起看，单纯肉眼瞧几个case不准，建议搞个小验证集，看top-k里有没有覆盖到标准答案的片段，这样调起来才有方向。

这问题太真实了，7B的CodeLlama补全就是容易话痨，它压根分不清“解释代码”和“写代码”的边界。你试下在提示词里直接给个例子，比如“def calculate_mean(data):”后面跟上几行你期望的简洁代码，再让它模仿，比单纯说“只生成代码”管用。另外实在不行就换StarCoder，代码生成确实干净一截，但7B照样会在长函数上犯傻，别抱太高期待。

我之前也踩过类似的坑，loss卡2.3不降大概率不是数据量的问题，1万条函数其实够用了。你试试把上下文长度提到1024或2048，代码补全特别吃函数之间的依赖关系，512确实可能截断了结构。另外target modules别只盯q_proj和v_proj，把o_proj和gate_proj也加上，有时候效果差挺多。如果还不行，检查下数据预处理是不是去掉了缩进，Python对空白敏感，模型学不到缩进

我当初也卡在这块，最后是折中方案：按对话“意图单元”分段存，不是整段也不是单条，大概2-5轮一个向量，然后metadata里加session_id和topic_tag。切回A话题时，先用一个短查询向量粗筛，再按session_id做时间排序，效果比纯metadata过滤干净不少。另外建议给每个片段存个“摘要向量”，召回时优先匹配摘要，再拿正文微调，能省不少token。

微调目标我个人感觉不是让它背检索片段，而是教它怎么“用”片段——比如哪些信息该采信、哪些该忽略，以及跟自身参数知识怎么对齐。你直接喂“问题+片段+答案”确实容易学歪，因为检索质量差的时候模型会把噪声也当成真理。 我之前试过在数据里混入一些“检索片段不相关”的负样本，让模型学会说“这跟问题无关”，幻觉明显少很多。另外LoRA rank别开太高，不然通用知识崩得快，我一般8-16就够。

Chunk_size调大反而变慢很正常，因为检索时embedding和向量比对的粒度变粗了，我一般按段落或语义块切，控制在300-500字左右，别死磕固定值。混合检索确实值得试，BM25加向量召回能明显提升相关性，尤其技术文档里术语多，纯向量容易跑偏。rerank我用过bge-reranker-base，小模型不贵，效果立竿见影，但记得只在top20里重排，别全量跑。Chroma慢可能跟默认配置有