线上 RAG 应用最典型的故障不是报错，而是"答非所问"：系统正常返回了内容，但与用户问题无关。这类问题很难靠看最终答案定位，必须回到检索链路逐层验证。下面给出一条可执行的排查路径（属工程经验总结，具体参数取值与组件行为需以所用组件的官方文档为准）。\n\n一、先统一判断标准，把"不相关"变成可复现样本\n排查前先把一次失败请求还原成固定四元组：原始问题、实际送入检索器的查询文本、召回文档 ID 及得分、最终拼进提示词的片段。同时把问题分类：召回列表里根本没有包含答案的文档（召回问题）；答案文档在列表里但排在后面（排序问题）；答案片段已进入提示词而模型仍未答对（生成问题）。三类问题的排查方向完全不同，混在一起调参只会左右摇摆。\n\n二、查询改写环节\n常见失效有三种：改写过程丢掉了关键实体或把专有名词换成近义表达，导致查询向量偏离主题；多轮对话中错误继承上一轮指代，把"它"解析成了错误的实体；把短问题扩写成一段长指令，使查询向量落到"任务意图"而非"内容主题"区域。验证方法是把改写前后文本分别送入同一嵌入模型，比较与已知正确文档的相似度排序是否发生变化；若改写后排序变差，先关闭改写做对照实验，再决定保留哪些改写策略。\n\n三、向量化环节\n第一，检查嵌入模型的输入长度限制与截断行为。超长文本会被截断，截断点之后的语义完全丢失。做法是统计送入嵌入接口的文本长度分布，若大量样本堆积在模型上限附近，基本可确认存在截断。\n第二，确认索引侧与查询侧使用同一模型、同一版本、同一归一化方式。两侧模型不一致会系统性拉低相似度，表现为所有查询的分数都偏低且区分度差。\n第三，检查查询是否被附加了与文档侧不一致的预处理：大小写、全半角、去停用词，或只在一侧添加的指令前缀。这类不对称处理不会报错，但会稳定地劣化召回。\n\n四、召回与过滤环节\n分数阈值：向量检索的相似度分数量纲取决于度量方式（内积、余弦或欧氏距离），跨模型、跨版本不可直接比较。阈值应由标注样本的分数分布确定。若所有查询的得分都集中在很窄的区间，说明阈值实际没有起到区分作用。\n元数据过滤：时间范围、租户、权限、状态等过滤条件写错时，正确文档会被直接排除，外在表现就是"召回了，但都不相关"。检查过滤前后候选数量，若过滤后骤减，先核对过滤字段与取值。\ntop-k：k 过小会漏召，k 过大则把噪声全部交给重排序，超出重排序处理能力的部分会被丢弃。注意是否所有请求都使用同一个 k，没有按问题类型区分。\n分块策略：块过大，一个块里混合多个主题，向量被稀释，块与问题的相似度整体下降；块过小，答案被切断，语义不完整。对比不同分块粒度下的召回排序，重点看块边界是否切断了表格、代码、条款编号这类结构化内容。\n\n五、重排序环节\n重排失效的典型信号是：重排后的顺序与向量召回的初始顺序高度一致，而初始顺序本身是错的——这说明重排没有真正参与排序，常见原因包括候选列表未正确传入、重排模型对长候选发生了截断、重排分数未写回排序结果。排查时对比重排前后的文档顺序变化，若几乎不变，就应先验证重排环节的输入输出是否完整。\n\n六、上下文拼接环节\n召回了正确文档但答案仍不对，问题常出在拼接：按分数排序后顺序放反，低分片段占用了靠前位置；总长度超限，导致后面的片段被静默丢弃；片段缺少标题、来源或章节标识，生成模型无法判断内容归属；多个文档互相冲突时没有指定优先级。建议记录最终进入提示词的片段 ID 与各自长度，确认关键片段没有被截断掉。\n\n七、最小日志埋点集合\n每条请求至少记录：改写前后查询、嵌入模型与版本、召回 top-k 列表及分数、过滤前后候选数、重排前后顺序、最终进入提示词的片段 ID 与长度、生成答案。有了这些字段，"不相关"才能被定位到具体一层，而不是停留在主观评价。\n\n八、推荐的排查顺序\n从后往前推进：先确认进入提示词的片段中是否包含答案，若包含则问题在生成侧或提示词组织；若不包含，检查重排前后是否出现过正确文档，出现过则定位到重排序；若召回阶段就没有，回到向量化与查询改写；若正确文档存在但分数贴着阈值被滤掉，则调整阈值与分块策略。每一步都用固定样本集验证，避免一次改动多个变量导致结论不可归因。