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