RAG 检索不相关：分块与嵌入配置的排查与调优

检索回来三条每条都跟问题沾点边但拼起来答不出正确答案。这时候换嵌入模型通常不是第一步要做的事——大多数「检索不相关」的根因在向量化之前的文档处理环节。先分清是召不回还是排不准在动任何参数之前做一次分层验证把含答案的原文片段直接拼进 prompt看模型能否答对。答对说明生成侧没问题问题在检索侧。用原文档里含答案的那句话本身作为 query 去检索看目标块是否出现在 top-k。对照三种结果分别归因原句也召不回是分块或向量化的问题原句能召回、用户问法召不回是查询与文档表述风格不一致的问题都能召回但排不到前面是排序问题对应 top-k、阈值或 rerank。这一步的价值在于把「检索不准」拆成互斥的几类否则很容易在错误的层面反复调参。用距离分布判断分块是否合理对一批真实 query记录每次返回的 top-k 相似度分数观察分布形态比单看某一条结果更有信息量候选分数全部挤在一个很窄的区间里彼此差异极小说明向量区分度不足。最常见的原因不是模型不行而是每个 chunk 里都混进了相同的模板文字页眉页脚、导航、免责声明、重复的表头这些东西把不同文档的向量拉到了一起。目标块的分数很高却排在后面属于排序问题处理方式与分块无关。分数整体偏低但相对排序是对的可能是查询与文档的表述差异先考虑查询改写而不是重切文档。还可以做一次反向检索拿每个 chunk 去检索 query 集合看它命中哪些问题。如果某个 chunk 对所有 query 都排在中游它很可能是一个语义混杂块——里面装了两三个主题向量落在了这些主题的「平均位置」谁都不像。清洗和分块收益通常大于调参数优先级上先把这些处理掉模板化的页眉页脚、版权声明、重复表头、以及与正文无关的导航文本。它们不会单独造成错误但会系统性地压缩向量之间的可分性。分块层面有几个容易踩的点固定长度切分是最容易做错的做法。优先按结构切标题层级、段落、列表项、代码块边界。硬切会把一个完整论述拦腰截断前半句在 A 块、后半句在 B 块两块都答不出问题。标题路径要跟着块走。做法有两种把「一级标题 二级标题」拼成前缀后一起嵌入或者作为结构化元数据字段用于过滤和结果展示。只把标题留在文档结构里、不进入向量正文块就会「不知道自己在讲什么主题」。小块匹配、大块投喂。用小粒度块做向量相似度匹配命中后把其所属的父块或相邻块送给模型。这样匹配精度和上下文完整性可以同时拿到不必在 chunk 大小上做非此即彼的取舍。overlap 不是越大越好。它的作用是防止答案正好落在切分边界上代价是重复内容增多、top-k 里挤进大段相同文字。常见起点是块长的 10%–20%但这个区间只是探索起点收益是否为正必须在自己的评估集上验证。一个 chunk 只讲一件事。混合主题的块是最难被检索到的因为它的向量没有明确指向。标题和正文要不要分开嵌入这在工程上是一个折中不是标准答案。先明确要解决什么如果正文块缺少标题信息正文向量就丢失了主题线索如果标题和正文长度差异很大混在一起确实可能被标题主导或被正文稀释。一个成本较低的做法是把标题路径作为前缀拼进正文再嵌入同时另存一份结构化元数据供过滤使用。这样只维护一份向量检索链路简单。只有当评估显示前缀拼接会明显改变正文语义时才值得考虑双向量或按字段分别检索再合并分数——那会带来分数归一化和合并策略的额外复杂度需要相应验证收益。元数据过滤把硬条件从语义里拿出来文档类型、时间范围、权限、产品线、租户这类条件应该用过滤表达式表达而不是指望相似度去理解。「最近一次修订的政策」这种限定交给向量去猜失败率很高。前提是入库时就把这些字段抽好事后补抽往往要全量重建。调整顺序先修清洗和分块用同一套评估集看 recallk 的变化。再调 top-k 和相似度阈值。阈值不要拍脑袋用前面的正负样本分布来找分界点。再考虑查询改写把用户的口语化问法映射到文档的表述风格。最后才考虑换嵌入模型或引入 rerank。顺序反了就会出现「换了模型、指标没动」的情况。没有评估集就不要调参最小可行做法挑 30–100 条真实或构造的问题为每条标注对应的正确原文位置固定下来。每次只改一个变量记录 recallk 和 MRR。有一个细节容易被忽略分块方案一变chunk 编号就全变了。评估集应该按原文定位文档 字符区间或段落锚点标注而不是按 chunk id 标注否则每次重新切分都要重标一遍评估成本会高到没人愿意做。还需要注意的边界上面给出的参数区间都是探索起点不是推荐值。语料长度分布、语言、专业术语密度都会改变最优区间唯一可靠的判断依据是自己在评估集上的召回结果。另外多语言内容、代码、表格和公式通用的文本切分与嵌入方式未必适用需要单独评估不能沿用正文的结论。最后是一个一致性风险更换嵌入模型会改变向量维度和语义空间历史向量必须全量重建不能只对新文档重新向量化。新旧向量混在同一个索引里检索结果会变得不可预测而且很难从单条 bad case 上看出原因。从工程角度看处理「检索不相关」的合理路径是先定位问题层再动对应的旋钮分块决定向量表达什么嵌入决定怎么表达检索参数决定取哪些。把这三层的职责分清调试过程才可复现。