RAG 回答错了最常见的第一反应是什么改 Prompt换大模型或者把 Top-K 调大。这三个动作都可能有用但它们不应该成为排查起点。因为最终答案只是链路最后一层。错误可能早在文档解析时就发生也可能是 Query 被改写带偏、过滤条件挡掉了正确文档、向量召回没找到、融合时被压下去或者 Rerank 把正确证据排到了后面。如果连正确证据在哪一层消失都不知道改参数更像碰运气。先把这道题答到 30 秒面试时可以先这样回答我会沿证据流逐层排查。先用人工标注的正确文件、页码或 Chunk 确认原文已被解析、切分并写入当前索引再比较原 Query 与改写 Query检查否定、实体和过滤条件然后分别查看 BM25、向量、融合和 Rerank 的候选、分数与名次最后确认交给模型的上下文是否包含完整证据。每层都记录 Chunk ID、来源、召回通道、过滤条件、模型与索引版本。修复后用原 Query 和同一正确证据回归再补一组相邻样本避免只修好一个例子。先抓住一条主线确定证据在哪一层消失再对那一层做最小修改而不是罗列优化手段。排查前为什么先要有“正确证据”如果只知道“答案错了”排查没有参照物。系统返回的每条候选都可能看起来相关但只有能够直接支持参考答案的原文才是这次问题应该追踪的对象。因此一条可调试样本至少要准备三样东西原始 Query、参考答案、正确证据位置。证据位置最好具体到文档、页码、Chunk 或内容区域不能只写一个文件名。长文档中可能有许多相似段落找到同一份文件并不等于找到能回答问题的那一段。多跳问题还可能需要多条证据。如果答案需要规则定义与例外条款共同支持就要把两段都标出来。只跟踪其中一段会把“部分召回”误判为“已经找到答案”。正确证据是整条调试链的坐标。后面每一层都只问一个问题它还在不在分数是多少排在什么位置为什么被保留或丢弃。盲目调参和证据链排查的区别盲目调参只看最终答案证据链排查则先固定正确原文再追踪它在哪一层出现或消失。第一层正确内容真的入库了吗先从离线链路查起。原文件是否被系统接收目标页面有没有解析出来双栏和表格结构是否正确切分后条件与结论是否仍在同一个可用语义单元。接着确认 Chunk 是否写进当前可检索索引。文档可能解析成功却因为批量写入部分失败没有进入向量库。也可能新版本已经上传检索仍然只看旧索引。权限、知识库和文档状态也可能让正确 Chunk 不在本次范围内。如果正确证据根本不存在于索引调 BM25 权重、替换 Embedding、扩大 Top-K 都不会修好问题。检索器只能在已有语料中挑选不能找回从未进入候选空间的内容。这一层应该保存文档身份、解析版本、切分版本、Chunk ID、索引版本和当前状态。当原文件更新后还要确认正确证据属于当前有效版本。旧版和新版同时存在时检索可能找到一条语义高度相关、业务上却已经失效的内容。第二层Query 有没有被处理错很多检索问题不是模型不够强而是送进检索的 Query 已经偏离用户原话。需要同时保存原 Query 与改写 Query。多轮问题里“这个怎么申请”需要结合历史补全对象但历史中有多个实体时重写可能选错。否定问题里“哪些情况不能申请”如果丢掉“不”检索方向会完全相反。精确编号、错误码和产品名如果被改成自然语言原本最强的关键词信号可能被稀释。还要检查 Query 分解。多跳问题拆成子查询后是否覆盖了所有信息点子查询是否添加了原问题没有的条件合并时是否只保留了其中一路这一层的排查顺序可以是原问题是否清楚改写是否保持实体与否定扩写是否引入噪声分解是否完整失败时是否保留原 Query 回退。不要只看改写结果是否“更像标准问题”。它的任务是提高检索可用性不是润色句子。第三层过滤条件有没有挡掉正确证据过滤通常发生在相关性排序之前却很容易被忽略。知识库 ID、租户、权限、文档状态、版本、时间和文档类型都会决定哪些 Chunk 有资格参与检索。正确证据被过滤后后面的 BM25、向量、融合和 Rerank 都看不到它。因此每次请求都要记录实际生效的过滤条件而不只是业务层传入的参数。例如调用方传入了当前知识库检索层又根据默认状态排除某类文档。最终条件可能比日志里看到的更严格。调试时可以先确认正确 Chunk 在无过滤情况下能否找到再逐项恢复过滤定位是哪条规则把它排除。但这不意味着可以长期去掉权限或状态过滤。调试绕过只用于定位最终修复要保证安全边界不被破坏。第四层两路召回分别找到了什么不要一上来只看融合后的 Top-K。BM25 与向量检索解决的失败类型不同。把两路混在一起会看不出正确证据原本由哪一路找到又在哪一步被压下去。BM25 更依赖原词、编号和专业术语。用户换了说法时它可能漏掉正确文档。向量检索擅长语义改写但短 Query、领域术语和否定表达可能出现偏移。调试时应分别保存两路候选、原始分数、排名和 Chunk 来源。同义词问题先看向量路线是否补回了正式术语。精确标题和错误码先看 BM25 是否命中。否定问题则要比较正面描述与例外条款分别在哪一路排得更高。正确证据两路都没有出现先查 Query、模型、索引与候选范围。某一路已经找到融合后却消失再进入下一层。第五层融合为什么把正确证据压下去了关键词分数与向量相似度不是同一把尺子。如果使用加权求和需要确认两路分数怎样归一化、权重如何设置以及某一路是否因为数值范围更大长期主导排序。如果使用基于名次的融合也要查看正确证据在各路的原始名次。两路都排得很后融合不会自动变成第一。合并去重也可能出错。同一 Chunk 由两路召回时应按稳定 ID 合并同时保留召回通道。如果去重键不稳定一段内容可能以两个候选出现如果只保留一路记录又可能丢掉有价值的分数与来源。这一层至少保存融合前后列表、每条候选的通道、原始分数、归一化分数、综合分和去重键。不要只保存最后一个综合数字。出现异常时需要能还原它由哪些信号组成。第六层Rerank 是没起作用还是根本没机会Rerank 只能重新排列已有候选。正确证据没有进入粗召回 Top-N它就没有补救机会。此时更换更大的重排模型不会解决漏召回。正确证据已经进入候选却排在后面才是典型排序问题。比较 Rerank 前后名次检查模型输入是否被截断、语种与文档是否适配、否定与条件是否得到正确判断。候选数量也要记录。Top-N 太小可能把正确证据挡在精排外太大则增加成本与噪声。调试时扩大候选能帮助判断覆盖边界但最终参数仍要回到评测集和延迟预算上决定。有些系统只对部分页面执行 Rerank。翻页后结果重复或跳动时要确认不同页面是否使用相同排序口径。第七层最终上下文真的包含完整证据吗候选排对以后还可能在截断与组装时出错。最终只保留前几条正确证据可能被最后一次阈值过滤丢掉。多跳问题需要两段证据系统却只保留其中一段。相邻重复 Chunk 占满上下文互补证据没有空间进入。标题、表头或列表前导句在展示前被清洗掉模型看到的内容不再完整。所以 Trace 还要保存最终送给模型的原始上下文而不是只保存候选 ID。如果正确证据已经完整进入上下文模型仍然答错再去看 Prompt、证据冲突、引用约束和生成模型。这时修改 Prompt 才有明确依据。从 Query 到最终上下文的证据流每一层都保存正确证据是否存在、名次怎样变化以及为何被过滤。最终答案只是证据流的最后结果。开始调参前先把实验现场冻结下来检索问题最容易出现一种假修复今天把参数调好明天同一个 Query 又复现不了。原因不一定是算法失效也可能是索引、模型、文档或过滤条件已经变化。因此最小复现不能只保存一句用户问题。至少要冻结知识库版本、文档版本、Chunk 版本、Embedding 与 Rerank 模型版本、Query 处理规则、过滤条件以及每一层的 Top-K。若系统还在持续增量入库同一个 Query 在两个时间点面对的候选集合可能本来就不同。“版本”也不能只是一个发布时间。解析规则变了Chunk ID 可能整体重建Embedding 模型变了旧向量和新向量可能不能直接比较Rerank 模型没变但候选数量变了正确证据也可能从有机会排序变成根本进不了重排。冻结这些信息的目的不是把系统暂停而是让一次问题能够被重放。排查人员拿到同一份最小复现包应该能看到相同的原 Query、改写 Query、候选、分数和过滤结果。只有先做到可复现后面的参数变化才有因果意义。用一张“候选变化表”定位证据在哪一层消失面对一条失败样本可以给正确证据建立一张逐层记录表。第一列记录解析和切分后它是否存在、Chunk ID 是什么、正文是否完整。第二列记录 BM25 与向量检索中的名次。第三列记录过滤后是否还在。第四列记录融合后的名次。第五列记录 Rerank 后的位置。最后一列记录它是否进入生成上下文以及进入时有没有被截断。如果正确证据在入库阶段就不存在修复方向是解析、切分或增量同步如果只在 BM25 出现说明向量表达或语义召回需要检查如果两路都能召回却在过滤后消失应查元数据、状态和作用域如果进入 Rerank 前排名尚可重排后被压下去就要查看 Query 与候选传给模型的实际文本如果最终上下文中存在完整证据而回答仍然错误才轮到生成约束和证据归因。这张表还有一个价值阻止团队凭最终相似度猜原因。不同阶段的分数往往不是同一量纲不能把 BM25 分、向量距离和 Rerank 分直接横向比较。我们真正关心的是正确证据何时进入、何时离开以及该阶段做了什么变换。对多跳问题还要同时追踪多条必要证据。一段进入 Top-K、另一段掉出候选最终回答依然不完整。此时“命中了一条正确 Chunk”并不能判定检索成功标注数据必须说明答案需要哪些证据共同成立。不要把每个失败样本都修成一条特殊规则一条 Query 定位清楚以后下一步不是立刻给它加关键词而是判断它属于哪一种可复用的失败类型。如果用户口语和文档术语不同这是表达鸿沟如果否定条件被丢掉这是意图保持问题如果标题、正文和表格被拆散这是 Chunk 结构问题如果正确片段被状态过滤排除这是元数据问题如果多条证据无法同时进入上下文这是多跳召回或上下文组装问题。分类以后修复才有合理作用域。表达鸿沟可以通过同义扩展或更合适的向量表示验证不能为每个口语说法手工写替换结构问题要回到解析和切分不能靠 Rerank 猜回丢失的表头过滤问题要修字段和状态流转而不是盲目提高 Top-K。每次修复至少准备三组样本。第一组是原始失败 Query证明问题确实被修复。第二组是同类型但不同措辞的相邻样本检查方案是否具有泛化性。第三组是容易被副作用影响的反例例如加入扩写后检查精确错误码调整过滤后检查已下线文档扩大 Chunk 后检查上下文噪声。如果只看第一组很容易得到“这个例子好了”的结论却不知道系统是否在别处退化。工程排查真正的终点不是某条答案变对而是失败原因进入稳定分类、修复能够被回归测试覆盖并且下一次同类问题能被 Trace 自动暴露。还要记录没有采用的修复方案。比如问题来自解析缺失团队选择重建索引而没有调大召回数量这种取舍能说明你理解故障发生在哪一层也能避免以后的人看到旧参数后重新走一遍无效尝试。三类典型问题排查入口有什么不同下面均为教学示例。用户用口语文档用正式术语先看原 Query 的 BM25 与向量候选。如果向量路线已经找到正确术语检查融合和 Rerank。两路都没找到再考虑同义词词典、Query 扩写或 Embedding 适配。不能看到最终答案错了就直接给所有 Query 增加扩写。用户问“哪些不支持”却召回大量正面描述先核对原 Query 与改写 Query 的否定词是否保留再比较正面条款和例外条款在两路候选中的名次。如果正确例外条款已经进入候选但排得靠后检查融合与 Rerank。如果它根本没入库改写也无法补救。一个问题需要两段证据先标注两条正确证据再看单次检索找到了哪一条。必要时把问题拆成子查询各自召回后合并。但最后要检查两条证据是否都进入上下文以及它们之间有没有版本或范围冲突。这些问题不能统一叫“召回率低”。同义词更像表达差异否定涉及意图与排序多跳涉及问题分解和证据覆盖。失败类型不同修复和回归样本也不同。检索失败现象与优先排查层证据没入库、没召回、被融合压低、被 Rerank 排错和被上下文截断对应不同修复入口。一条可复现的 Trace 应该记录什么Trace 不是把若干日志文本放在一起。它要能用同一个请求身份串起整条证据流。请求层记录 Trace ID、原 Query、相关历史、改写与扩写结果、最终路由。数据层记录知识库、权限、文档状态、解析版本、切分版本和索引版本。召回层记录 BM25 与向量候选、Chunk ID、来源、通道、分数和过滤条件。排序层记录融合前后分数、Rerank 模型版本、输入截断、重排前后名次。上下文层记录最终交给模型的原文、顺序、总量和被截掉的候选。生成层记录 Prompt 版本、模型版本、回答和引用。这些信息不一定全部长期保存全文敏感内容还要做权限与脱敏控制。但至少要保留能复现排序决策的标识、版本和关键候选。没有版本今天重放同一 Query 得到不同结果也不知道是内容、模型还是参数变了。没有候选日志里只剩一句“回答错误”团队只能重新猜测。怎样准备一个最小复现包完整 Trace 很重要但排查时不应该把整个系统环境都复制一遍才开始分析。可以为每条重点问题整理一个最小复现包。第一部分是输入包括原 Query、必要的对话历史和实际过滤条件。第二部分是目标包括参考答案、正确证据原文、文档身份、页码和 Chunk ID。第三部分是阶段结果包括 BM25、向量、融合和 Rerank 的前几条候选以及最终上下文。第四部分是版本包括解析、切分、索引、Embedding、Rerank 和 Prompt 版本。第五部分是预期判断明确正确证据应该在哪一层出现最终需要几段证据以及哪些旧版本或无权限内容必须被排除。最小复现包有两个作用。一是把问题从大量运行日志中抽离出来让每次修改都能快速重跑同一输入。二是让不同成员讨论的是同一份候选和证据不会有人看旧索引有人看新模型最后得出互相矛盾的结论。敏感文档不能直接复制时也应保留经过授权的最小片段与稳定标识并确保复现环境仍遵守权限。为了调试而绕过访问控制会让结果失去真实约束。复现包还应记录“当前未知”。如果没有人工确认正确证据就明确标记待标注而不是先假设某个候选正确。调试建立在错误标准上只会让系统更稳定地返回错误内容。修复以后怎样防止只修好一个例子第一必须用原始 Query 重跑。不要把问题手工改得更标准再证明系统已经恢复。那只说明换了一个更容易的输入。第二保持正确证据不变。修复前后都追踪同一原文才能判断它在哪一层发生变化。第三一次只改一个主要因素。同时换 Embedding、改 Query、调融合权重和扩大 Top-N即使答案变对也无法知道哪个改动有效。第四增加同类相邻样本。修好一个否定问题后再测试其他否定表达与正面问题防止规则只记住某个关键词或者把正常查询一起破坏。第五分别看检索和生成。正确证据名次上升是检索收益最终答案改善是端到端收益。两者都要记录不能让生成模型的偶然表达掩盖候选仍然错误。回归结果还要绑定索引快照或内容版本。同一 Query 如果面对的知识库已经变化前后候选不能直接归因于算法调整。先确认输入语料一致再比较参数和模型才能让实验结论可复现。如果知识库必须同步更新就保留更新前后的两套结果明确区分内容变化带来的改善与检索策略带来的改善。否则一次正确答案可能只是新版资料恰好补齐并不能证明算法修复有效。RAG 检索问题修复验收清单原 Query、正确证据、单一变量和同类样本共同组成回归避免用一个更容易的问题证明修复。面试官继续追问怎么接正确证据没入库为什么调检索没有用因为检索器只能在现有索引中排序。原文没有被解析、切分或写入再高的 Top-K 也只会返回其他内容。为什么要分别看 BM25 和向量候选两路解决的失败类型不同。拆开后才能判断正确证据由哪一路找回又是否在融合时被压下去。否定问题为什么容易出错正面条款与例外条款常共享大量主题词Query 改写还可能丢掉否定。需要同时检查意图保持、候选内容和重排顺序。Rerank 后仍然不对先查什么先确认正确证据是否进入它的候选范围再看输入截断、模型适配和重排前后名次。候选不存在时问题仍在召回层。Trace 为什么一定要带版本文档、索引、模型、提示词和参数都会变化。没有版本同一个请求无法稳定复现也无法判断结果变化来自哪里。修复后为什么还要加相邻样本单个规则可能只修好一个句式却破坏同类其他问题。相邻样本用来验证修复针对的是失败机制而不是记住某个案例。最后把答案完整说一遍完整回答应该沿着证据流展开我不会先改 Prompt而是先固定原 Query、参考答案和正确证据沿证据流逐层排查。第一步确认原文已经正确解析、切分并写进当前索引第二步比较原 Query 与改写 Query检查实体、否定和过滤条件第三步分别查看 BM25 与向量候选再看融合和 Rerank 前后正确证据的分数与名次最后核对实际交给模型的上下文是否完整。每层都通过同一个 Trace ID 串起来记录 Chunk ID、来源、召回通道、过滤条件、解析与索引版本、模型版本和候选变化。正确证据不存在就查离线入库存在但没召回就查 Query 与检索召回后排得靠后查融合与 Rerank已经进入上下文仍答错才查 Prompt 和生成。修复后继续用原 Query 和同一证据回归一次只改一个主要因素再补同类相邻样本。这样才能证明修复的是一类错误而不是把问题换简单或碰巧让某个答案变对。这道题真正考的是可观测性和归因能力。会列一堆优化手段不难难的是知道正确证据在哪一层消失为什么选择这项修复又怎样证明它没有破坏其他查询。在实际排查中建议使用留存的 Trace、候选变化和回归结果避免只凭印象判断参数调整的效果。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
