Appearance
Q29 · RAG 效果不好时，你会怎么排查？
客服问答系统答错了：“订单 B204 的耳机签收 20 天、未拆封，还能按普通退货政策申请吗？”它回答“30 天内可以”。运营同学翻开当前政策却发现，耳机规则已经改成“签收后 7 天内且未拆封才可提交普通退货申请”。这时若只改提示词，可能完全治不到病：模型也许从未见过新版条款，而检索结果里只有旧版“30 天”。
我会把一次 RAG 请求拆开，寻找正确证据最早在哪一站消失或变形：原始文档 → 解析与入库 → 切块 → 召回候选 → 重排 → 送入模型的上下文 → 最终答案。每一步都留可核对的文本、文档 ID、版本和时间信息；先修最早出错的环节，再做整体回归。AWS 官方对知识库的说明也把入库描述为解析、切块、向量化与索引，把查询分为取回片段和基于片段生成；这正是可以逐段排查的链路。Amazon Bedrock：How knowledge bases work · Retrieve 与 RetrieveAndGenerate
先说明这些词指什么
| 术语或记号 | 含义 | B204 例子 |
|---|---|---|
| RAG（检索增强生成） | 先从外部知识找证据，再把证据交给大模型组织答案的方法 | 从政策库找适用条款后答复 |
| 源文档 | 尚未进入检索索引的原始文件或页面 | 新版《耳机退货政策》PDF |
| 解析 | 把 PDF、网页等转换成机器可检索的文本与结构 | 从 PDF 表格中读出“7 天、未拆封” |
| 切块 / chunk | 把长文档分成可单独检索的片段 | 含“耳机”“7 天”“生效日期”的一段 |
| 索引 | 保存可检索文本、向量与元数据的数据结构 | 政策片段及其版本、生效时间 |
| Embedding / 向量 | 把文本映射成可比较语义相似性的数字表示 | 比较用户问句与政策片段的语义接近程度 |
| 召回 | 从索引中找一批候选片段，目标是不要漏掉正确证据 | 取回新版 7 天规则及其他候选 |
top-k | 只取排序靠前的 k 个候选；k 是数量，不是质量分数 | top-5 表示取前 5 个片段 |
| 重排 / rerank | 对已经召回的候选重新打相关性分数并排序 | 将有效的新政策排在旧政策前面 |
| 上下文组装 | 决定哪些候选真正进入模型输入，以及截断、去重、引用编号 | 把新版条款连同来源和日期发给模型 |
| Faithfulness / 证据忠实度 | 答案中的结论能否由送入模型的证据支持 | 答“7 天”且引用新版政策 |
| Ground truth / 参考答案 | 由业务人员确认、用于评测的正确事实和证据 | “20 天超过普通退货 7 天范围” |
下面假设一组虚构业务数据：今天为 2026-09-26；B204 属于已授权的当前用户，耳机于 2026-09-06 签收、未拆封；旧版政策说“30 天内可提交”，到 2026-08-31 失效；新版政策从 2026-09-01 起生效，规则变为“7 天内且未拆封，可提交普通退货申请”。因此正确回答是“B204 签收 20 天，已超出这条普通退货政策的 7 天范围；如有特殊情形需人工核查”，不能说“30 天内可退”。订单归属与签收日期应由业务系统查询，政策 RAG 只负责查政策，不能凭检索文本替代订单鉴权。
先保存一次错答的完整证据链
不要从最终一句“答错了”反推原因。先固定用户原问、检索时的索引版本与日期、查询词、过滤条件、召回前几条、重排后几条、最终塞进模型的片段及其来源、模型输出与引用。这样才能回答以下关键问题：
- 原版政策里到底有没有正确的 7 天条款？
- 入库后的文本里还有没有“7 天”“耳机”“2026-09-01 生效”？
- 正确片段在初始候选中出现了吗？排第几？
- 重排后它是否仍在？是否被旧版挤掉？
- 送给模型的实际上下文包含什么？有没有被截断？
- 若模型看到了正确条款，为什么仍回答 30 天？
这是一套定位次序，不是要求每个系统必须使用向量库、重排模型或某个特定框架。AWS 的 Retrieve 可以单独检查取回的片段，RetrieveAndGenerate 才进一步生成答案；能分开观察这两步，排障就不会把检索问题误当成生成问题。Amazon Bedrock：Retrieving information
从原文到答案逐站检查
| 检查站 | 要看什么证据 | 看到什么说明问题出在这里 | 优先修法 |
|---|---|---|---|
| 原文与同步 | 原 PDF/页面、业务生效日期、索引同步时间 | 新版根本没发布到知识源，或改了文件但未重新同步 | 补齐权威文档并重新同步，清理过期副本 |
| 解析与切块 | 解析文本、切块文本、页码与元数据 | 表格“7 天”被读成“? 天”；“耳机”标题与条件被拆散；生效日期丢失 | 修解析器、表格抽取或切块边界，再重新入库 |
| 召回候选 | 原始 top-k 片段、查询词、过滤条件、索引版本 | 正确的新版片段存在索引却不在候选里 | 核查过滤、关键词/向量混合检索、查询改写与候选数量 |
| 重排 | 重排前后列表与分数 | 正确片段原在候选里，重排后却落到送入模型的名额外 | 调整重排策略、输入字段和候选数；对比关闭重排的效果 |
| 上下文组装 | 真正发给模型的完整片段顺序与截断位置 | 正确片段重排后还在，但 token 预算、去重或模板拼接将其丢掉 | 精简噪声、保留关键片段及元数据、检查截断逻辑 |
| 生成与引用 | 模型实际输入、答案、所引片段 | 上下文写 7 天，答案却说 30 天；或引用不支持结论 | 明确要求按有效版本和证据作答、缺证据时拒答，核查引用 |
原文与解析先于检索。 如果新版政策尚未同步，调大 top-k 也不会取出不存在的东西。PDF 中的表格、双栏、页眉页脚可能在解析时改变阅读顺序；必须直接打开解析后的文本比对关键数字和条件。切块检查不只看字数，也看“适用商品、期限、例外、生效日期”是否还在同一段或能从元数据关联回来。AWS 官方把解析、切块、向量化、索引分成不同入库步骤，并说明数据变更后需同步才能进入知识库。Amazon Bedrock：Turning data into a knowledge base · Sync a data source
召回和重排必须分开看。 B204 问句包含“耳机”“20 天”和“普通退货”，新版条款若已入库却没有进入初始候选，先查是否误设 effective_at < 2026-09-01 之类的过滤，是否只用语义检索而丢了日期/商品名这类精确词，查询与文档向量是否使用兼容的 embedding 配置。可对同一问句分别试关键词、向量、混合检索并比较候选，不要一次同时改许多参数。微软官方文档指出，混合检索把关键词与向量结果合并，精确代码、专有名词和日期等有时更适合关键词匹配；这些是可检验的候选修法，不是“混合检索一定赢”的承诺。Azure AI Search：Hybrid search overview · Hybrid query troubleshooting
若新版片段已经在候选中，才轮到看重排。重排器只能重排传给它的结果，不能从整个知识库凭空找回漏掉的片段；微软的语义排序文档对此说得很明确。若关掉重排后新版条款能进入上下文，问题可能在重排的输入文本缺了标题/日期，或名额太少。Azure AI Search：Semantic ranking overview
最后看模型看到的是什么。 检索页面显示新版片段，不等于模型输入里就有它。实际拼接可能先塞进多段旧条款，导致新版被 token 预算截断；也可能因去重把“7 天”段落误删。若实际上下文只有旧版“30 天”，应回到上下文组装或更早环节修；若上下文清楚写着“新版 7 天，旧版已失效”，答案仍说“30 天”，才检查生成提示词、回答时对版本的选择、是否遵守“无证据不下结论”，以及引用是否确实指向支持该结论的段落。微软对 RAG 的说明同样把内容准备、检索配置和提示设计列为不同的质量影响因素。Microsoft Foundry：RAG limitations and troubleshooting
用 B204 跑一遍正常与失败路径
正常路径：源 PDF 含“新版 7 天”；解析文本保留“耳机、7 天、未拆封、2026-09-01 生效”；切块保留这些条件并记录 policy_id=return-earphone-v2，这里的 policy_id 是政策片段的版本标识，v2 表示新版、v1 表示旧版；初始候选有 v2，且当前日期的过滤排除了已失效的 v1；重排将 v2 放前面；上下文带 v2 正文与来源；答案说“B204 签收 20 天，超出普通政策的 7 天”，并指向 v2。若订单事实缺失，答案应先请程序查订单，而不是仅靠政策片段猜签收天数。
本文配图的失败路径：原文和切块都正确保留“新版 7 天”，但召回结果只有旧版“30 天”。后面即使重排器工作正常，也只能把旧版在候选里排来排去；模型得到的上下文缺少新版，最后答错。这时先查看索引是否存有 v2、查询过滤是否按生效区间而非“发布日期”筛选、关键词与向量候选各返回了什么，再修召回。若系统将生效时间字段命名为 effective_at，还要核对它的值和比较方向。不能把“给模型加一句要准确”当作主修复。
图上的红圈只圈召回，表示这条失败轨迹里正确的 7 天片段在这一站被遗漏；“错答 30 天”是后果。它不表示 RAG 的所有错答都发生在召回。如果初始候选有 7 天而重排后消失，应把故障点移到重排；如果模型输入中已有 7 天而仍答错，故障点才在生成或版本判断。
用小样本评测防止“修好一问、弄坏十问”
先收集一组由业务人员核对的题：新版政策问答、旧版边界日期、含商品名/订单号、扫描 PDF 表格、找不到政策时应拒答。每题保存参考答案和能支持它的文档/片段 ID。评测分两层：
| 层次 | 要回答的问题 | 可用的检查方式 |
|---|---|---|
| 检索层 | 正确证据是否进了初始 top-k，最终候选是否相关、覆盖全部条件？ | 人工核对目标片段 ID；计算命中率或 Recall@k；看上下文相关性、覆盖度 |
| 生成层 | 答案是否回答问题、是否只说证据支持的事实、引用是否对应？ | 对照参考答案检查正确性/完整性，核对 faithfulness 与引用覆盖 |
例如 10 个有标准证据的问句里，只有 6 个的正确片段进入 top-5，则这组样本的检索命中率为 6/10；即便那 6 个答案都写得很好，另外 4 个仍要先查召回。反过来，10 个正确片段都进入模型上下文，但有 3 个答案选错政策版本，就应优先查版本过滤和生成规则。Amazon Bedrock 官方把 RAG 评估区分为 retrieve-only 与 retrieve-and-generate：前者可看上下文相关性和覆盖，后者可看答案正确性、完整性、证据忠实度与引用指标；这些分层指标适合定位问题。Amazon Bedrock：RAG evaluation metrics
自动评估是筛查工具，涉及政策有效期、例外条件和权限时仍要抽样人工核对。比较修复前后时固定同一批问句、参考证据与索引快照，记录每次只改了哪一项；同时看质量、延迟和成本，避免靠无限增大候选数换来单题改善。线上则记录脱敏后的查询、源文档 ID、版本、召回与重排列表、最终上下文 ID、答案引用及失败类型。这样下次错答能沿链路复盘，而不是重新猜原因。
面试时可以这样回答
我不会先改提示词，而是保存一条错答的完整链路，从原文、解析和切块，到初始召回、重排、最终上下文，再到答案和引用，找正确证据最早在哪一步消失。比如新版耳机政策是 7 天，用户签收 20 天，系统却按旧版 30 天答“可以”：先确认新版原文存在、同步成功、解析和切块没有丢数字与生效日期；若正确片段没进初始候选，查过滤条件、索引与关键词/向量召回；若进了候选却没进上下文，查重排和截断；若模型看到了新版仍答错，再改生成约束和版本判断。最后用有标准证据与参考答案的小样本分别评测检索命中、上下文覆盖、答案正确性和证据忠实度，按同一数据集回归，确保修复不是只碰巧改善一题。
参考资料
- Amazon Bedrock：How knowledge bases work —— RAG 的入库、检索和生成链路。
- Amazon Bedrock：Turning data into a knowledge base 与 Sync a data source —— 解析、切块、索引和同步。
- Azure AI Search：Hybrid search overview —— 关键词与向量召回的互补。
- Azure AI Search：Semantic ranking overview —— 重排只能处理已有候选。
- Amazon Bedrock：RAG evaluation metrics —— 检索层与生成层指标。