知识管理手记

我之前也踩过这个坑，召回看着没问题但生成跑偏，大概率是检索片段里噪音太多，模型分不清主次。你可以试试在喂给qwen之前加个rerank（比如bge-reranker），再把top片段做一轮压缩或摘要，只留跟问题强相关的句子。另外qwen2.5-7b对中间位置的上下文确实容易忽略，把最关键的片段放开头或结尾会稳一些。prompt里光说“只根据资料”不够，最好明确要求它先指出依据再作答。

这问题我太熟了，多步Agent跑到后面基本就是靠“锚点”续命。我的做法是每轮搜完先让它自己写一句当前结论和还差什么，下一轮必须基于这句继续，不然很容易原地打转或者跑偏。另外胡编链接大概率是上下文塞太多，试试只保留摘要和URL，别把整页内容都喂回去。架构上也可以拆成搜索、验证、写作三个独立节点，每个节点只干一件事，比一个Agent从头扛到尾稳不少。

十几个人并发其实不用急着上双卡张量并行，A100 80G跑14B int8本身够，问题多半出在KV Cache没管住。可以试试AWQ量化加vLLM的prefix caching，历史上下文和RAG片段共用的前缀能省不少重复计算。RAG片段别直接怼进history里，单独拼成system段或者用固定模板截断，配合max_model_len压一压，OOM基本就稳了。

我之前也踩过类似的坑，LangGraph的State更新本质上是按channel合并的，并行Worker写同一个key当然会覆盖，得给每个Worker单独定义输出字段，再用reducer聚合。上下文丢失多半是Supervisor节点没把A的输出显式写回state，别太依赖Memory模块，它和State的边界挺模糊的。你可以试试把A的结果封装成一个带标识的字段传给B，而不是直接塞对话历史。另外建议

AWQ 4bit 在 vLLM 上偶尔会踩到慢内核，先把量化换回 fp16 或 gptq 跑一遍对比下速度，能快速排除是不是量化的锅。

人事政策这种文档确实容易踩这个坑，条款之间经常有“除……外”“符合以下条件之一”这种交叉引用，512切完正好把前提和结论分到两个chunk里，检索出来看着都相关，拼一起就打架了。我建议先别急着换rerank，那个解决的是排序问题，解决不了片段本身语义不完整。你可以试试按markdown标题或者条款编号做父块切分，检索还是用小的子块去匹配，但喂给模型的时候把整个父块带上去，这样既保住了召回精度又保住

我这两周也有类似感觉，尤其是写Pydantic模型的时候，字段名和类型提示经常给我整岔劈，有时候还把我上面刚删掉的旧字段又补回来，挺烦的。之前我以为是项目开太久缓存乱了，重启VS Code、重开Copilot都试过，作用不大。后来我怀疑是上下文被稀释了，因为最近仓库里加了不少自动生成的schema文件和测试快照，Copilot可能把那些垃圾当成了强信号。我目前的土办法是：把不相关的文件从工作区关掉

我之前也卡在这块，后来发现光调chunk size没用，得先看你的文档类型。像我们做技术文档，表格和代码块必须单独处理，不然切完就废了。现在用unstructured先按结构分块，再对纯文本部分用递归切分，效果比死磕数字好很多。建议你拿20个真实问题跑个小评测集，比瞎试靠谱。

我踩过一样的坑，合同审核这种任务光靠prompt约束真的不稳，模型一看到条款就容易直接下结论。后来我把中间步骤改成用结构化输出卡住，比如每步必须返回固定的JSON字段，缺了字段就重跑，效果比单纯写“请按步骤”强很多。如果步骤之间依赖比较强，还是建议上LangGraph这类显式流程控制，prompt只负责每步的质量，别让它自己决定跳不跳。

我一般会先给个最小可运行的例子，再让它按这个模板改，后面就稳很多。还有个技巧是让它显式输出依赖和字段检查，比如“先列出手动确认的列名再写代码”，能减少瞎猜。温度调低点也有用，不过更关键的还是把输入结构说清楚，别让它自己脑补。

我之前也踩过类似的坑，问题大概率出在并行节点同时写同一个字段上。LangGraph里每个节点拿到的state其实是那一刻的快照，并行分支各自改完再合并，后写的就把先写的盖掉了。你可以试试把共享状态拆细，每个Agent只写自己的专属key，汇总节点再统一做merge。或者干脆别共用一份state，让查重Agent直接依赖上游节点的输出通道，用reducer控制合并顺序会稳很多。

维度这事儿真不能只看数字大小，384和768的差距很多时候还不如你chunk切得好不好来得明显。bge-small本身就是在384维上训练的，你硬把它输出跟768维模型比，那是不公平的对比，得看同系列里base和large的差异才有意义。10万条chunk这个量级其实不大，Milvus扛1024维也毫无压力，真正拖速度的是索引类型和nlist参数，不是维度本身那点开销。我自己的经验是，技术文档这种

我之前也遇到过类似情况，后来发现光调chunk和overlap不够，关键得加个rerank步骤，用bge-reranker对top结果重排一下，相关性提升挺明显。text-embedding-3-small其实够用，但如果你文档领域比较垂直，换个bge-m3或者gte-large试试可能更稳。生成模型温度直接降到0.1以下，top_p 0.9左右，再在prompt里明确要求只用检索内容回答，不然8

我之前也踩过这个坑，后来发现光靠system prompt不够，得在user prompt里把原文用明确标记包起来，比如“以下是参考资料，请只基于这些内容作答”，再配合few-shot给个正反例效果会稳很多。分段塞确实比整段好，尤其原文长的时候，模型注意力容易分散，你可以按语义切成几个小块，每块前面标个编号，让它在回答里引用编号。另外如果还乱编，可以试试把temperature调低到0.1左右，代

几万条记录真不用纠结性能，Chroma本地绰绰有余，我跑了半年多快十万条也没觉得慢。Milvus那个分布式配置光看文档就劝退，一个人搞纯属给自己加戏。MCP里Chroma有现成工具封装，跟function calling配合挺顺的，Milvus还得自己写不少胶水代码。倒是建议你后面真上规模了再换也不迟，反正接口都兼容。

我之前也踩过类似的坑，最后定位下来问题其实出在chunk切分和prompt的配合上。256字符对中文来说太碎了，经常把一个完整逻辑块拦腰截断，检索出来的片段单独看相关，拼起来就前言不搭后语，模型只能硬着头皮“脑补”。你试着把chunk调到500-800字符，并且加一个overlap，至少保留段落间的承接关系，效果会明显改善。 另外你说“仅基于上下文”约束太死，这个我特别有同感。我当时的做法是改成

我之前也踩过这坑，固定窗口切分对技术手册这种强结构文档确实容易把语义拆碎。后来改成了先按标题和目录做结构解析，再对每个小节内部用滑动窗口，效果明显好很多。另外你提到相关性打分还行但答非所问，我觉得检索阶段可以试试混合召回，比如加个BM25权重，跟向量分数融合一下，能压掉不少“看着像其实跑题”的结果。 还有个小建议，bge-large对这种长尾技术词可能不够敏感，有条件可以微调一下或者换个领域模型

说实话，几千页的企业文档用固定chunk_size本来就容易出问题，跨章节的内容被硬切断了，embedding再强也白搭。我建议你先试试按文档结构（标题、段落）做语义切块，别死磕字符数。另外text-embedding-3-small对中文长文本确实一般，有条件换个bge-m3或text-embedding-3-large对比下效果。BM25混合检索值得加，尤其处理那些专业术语和精确匹配的场景，能

这问题我之前也踩过坑，ResNet50直接提特征做检索，召回率卡在60%太正常了。你试试把输出层去掉，用倒数第二层的feature map做全局池化，比直接用2048维那个分类前的向量要稳得多。另外L2距离对图片这种高维特征其实不太友好，换成余弦相似度或者先做PCA降维到256维再检索，效果会明显好一些。还有个细节是Milvus的索引参数，HNSW的M和efConstruction调大点，召回能再

我也遇到过一模一样的坑，后来发现问题往往不在chunk大小，而是embedding本身没区分好语义相近的段落。你试试先做一下query改写，把用户口语问题转成更贴近文档的表述，效果会明显很多。 另外Agent的system prompt里得明确告诉它“只能基于检索内容回答，找不到就说不知道”，不然LLM很容易自己脑补。Chroma的相似度阈值也可以调严一点，低于0.7的直接不返回。 我后来换成