RAG 答错的时候，问题几乎从不在生成那一步
微信读书《基于RAG的大模型应用开发：问答系统、多模态系统与Agent开发实践》
逐页翻阅 365 屏 · 9 章 · 2026-11-03
说明：这是一本"手上有活"的书——九章里有六章都在写代码，从 PyPDF 解析、CharacterTextSplitter 切块、Faiss 建索引，一路到 Dify 编排和 RAGAS 打分。它不适合躺着读，适合开着编辑器读。
RAG 这个题目，网上教程已经多到不用再写了。所以我读这本书，真正想找的不是"怎么搭一个"，而是两个更难的问题：搭完之后怎么知道它好不好？以及出问题时该改哪一段？
这本书的第 5 章，是我读过的中文材料里把这两件事讲得最实在的。它开头没讲方法论，先讲了一个真实事故。
一、一句话答错的代价，是全额退款
书里第 5 章第一节的标题就叫"加拿大航空公司的故事"：
2024 年，加拿大航空公司因客服聊天机器人的一次错误解读退款政策，被迫向一位旅客全额退款，这一事件引发了业界对人工智能驱动的聊天机器人的深刻反思。
过程并不复杂，书里写得很清楚：一位旅客因航班延误申请赔偿，向航空公司的客服聊天机器人提问。令人惊讶的是，机器人错误解读了公司的政策，向旅客明确表示其有资格获得全额退款。旅客依据这一回复，与航空公司据理力争，最终成功获得退款。
这件事的分量，不在于"AI 又幻觉了"——那已经不算新闻。它的分量在于责任的归属：企业不能一边用 AI 替代客服，一边声明 AI 说的话不算数。你把它放出去代表你说话，它说的话就是你说的。
我在别的 RAG 材料里很少看到这个案例被放在最前面。大多数教程的开头是"RAG 解决了大模型的三大痛点：知识陈旧、幻觉、成本"。这话没错，但它把 RAG 说成了一种纯技术增益。而加拿大航空这个故事说的是另一件事：RAG 把"引用外部知识"这件事接进了业务流程，也就把外部知识的错误一并接了进来，并且是以你的名义说出去的。
这就是为什么这本书把"评估"单独列为一章，而不是塞在优化里当一个小节。在这个场景下，评估不是调优手段，是风控。
二、先拆开，再评估
书里给评估定的第一个任务，不是"提高准确率"，而是定位错误来源：
通过对检索模块和生成模块的独立评估，可以深入分析并明确错误回答的根本原因。分模块评估的方法有助于精确识别问题所在，是解决系统漏洞的关键步骤。
这句话看起来是常识，但实践中被违反得极其普遍。绝大多数团队的迭代方式是：答错了 → 换一个更强的模型 → 再看。这个循环跑十次，钱花完了，效果没提升多少——因为问题根本不在生成端。
RAG 的错误，八成发生在检索之前。你问"退款政策是什么"，知识库里那段话被切成了两半，前半段进了 chunk 17，后半段进了 chunk 18，检索器只召回了 17。模型拿到半句话，答得含糊，你去怪模型不够聪明。
书里给检索模块的指标是老两样：精确率——检索到的文档里有多少是相关的；召回率——数据库里所有相关文档有多少被检索到了。定义给得很朴素，就是两个分数，还配了可直接跑的代码。
这两个指标必须分开看，因为它们的失效方向相反。召回率低，是"该给的材料没给"；精确率低，是"给了一堆没用的"。前者让模型无从作答，后者让模型分心——书里后面用 RAGAS 的"噪声敏感度"专门量化后者，这个后面再说。
三、RAGAS 那四个指标，各自治什么病
第 5 章后半段讲 RAGAS。书里列了四个指标，我认为它们恰好对应四种不同的失败模式，值得一个个拆。
忠实度（Faithfulness）。答案里的每个主张，是不是都能在检索到的上下文里找到依据。这个指标治的是"模型自己加戏"——上下文里说了 A，模型答出了 A 和 B，B 是它凭常识补的。在客服、法律、医疗场景里，这往往是最致命的一类错误，因为它最像"专业"。答得比材料多，不是聪明，是越界。
答案相关性（Answer Relevancy）。答的东西是不是问的东西。这个指标治"答得很对但没用"——用户问"能不能退"，模型答了一大段退款政策的历史沿革。字字有据，就是不解决问题。
上下文召回率（Context Recall）。参考答案里需要的信息，检索到的上下文覆盖了多少。书里给了个很具体的例子：
上下文实体召回率在基于事实的场景中非常有用，如旅游服务台、历史QA等。该指标根据与reference中存在的实体的比较来帮助评估实体的检索机制，因为在实体很重要的情况下，需要覆盖它们的retrieved_contexts。
这段值得留意的地方是"实体"两个字。它承认了一件事：有些问题的答案是有硬核的——某个日期、某个金额、某个人名。这类问题不能用"语义相似"糊过去，实体的命中与否是 0 和 1 的区别。
噪声敏感度（Noise Sensitivity）。书里定义：用来衡量系统在利用相关或不相关的检索文档时提供错误响应的概率，取值范围 0 到 1，值越低表示性能越好。
这个指标是四个里最容易被忽略的，也是我认为最实用的。因为它指向一个反直觉的事实：给模型更多上下文，不一定更好。你多召回十条不相关的文档，模型不会自动忽略它们，反而可能被其中某条带偏。所谓"检索增强"，前提是检索进来的东西得是干净的；不干净的增强就是噪声注入。
这也解释了为什么工程上"先多召回再重排序"是标准做法：让召回端放宽（保召回），让重排序端收紧（保精确），最后才把精排结果交给模型。把两道关分开做，比在一个环节上同时追求又全又准要现实得多。
四、六代架构：一条"越来越不信任检索结果"的谱系
第 3 章是全书的骨架，讲了六种 RAG 架构：经典 RAG、多头 RAG、自反思 RAG、纠正 RAG（CRAG）、自适应 RAG、图 RAG。
书里是一个一个讲的，每种都给了简介、架构图、构建实战三节。我读完之后发现，这六种不是并列的六个选项，而是一条清晰的演进线：每一步都在增加"对检索结果的怀疑"。
经典 RAG 最单纯：检索 top-k，塞进提示词，生成。它默认检索是对的。
多头 RAG 开始怀疑"一个问题是不是够用"。它把一个大问题拆成几个子问题，各自检索再汇总。这治的是含糊提问——用户问"这本书讲了什么"，一条检索路径只能命中一部分。
自反思 RAG 开始怀疑"检索到的东西够不够答这一问"。它先自查，不够就再来一轮。这是把"检索"从一次性动作变成了循环。
纠正 RAG（CRAG） 怀疑得最彻底，也最具体。书里把它的流程拆成五步，我认为是全书技术密度最高的一段：
(1) 构建轻量级检索评估器。给定输入查询和从检索器中获取的文档，估算文档与查询的相关性分数
(2) 置信度分类。根据相关性分数分为三种：正确、不正确、模糊
(3) 进行 Correct 操作。评估为"正确"时，对检索结果做细化：知识分解、过滤和重组
(4) 进行 Incorrect 操作。评估为"不正确"时，直接丢弃检索到的文档，然后通过 Web 搜索获取外部补充知识
(5) 进行 Ambiguous 操作。当无法自信地判断文档是否准确时，采取一种柔和的策略
这个设计里有两个地方值得单独说。
第一个是"模糊"这一档。绝大多数系统只有"命中"和"没命中"，CRAG 承认了第三种状态：拿不准。这是工程上的成熟标志——承认不确定性，比强行二分类要诚实得多，因为强行二分类会把"有点相关"的文档当成"相关"，然后一路错到底。
第二个是错了就上网搜。这一步很关键，它意味着 CRAG 承认知识库有边界：库里没有的东西，硬检索也检不出来，不如换个信息源。但它同时引入了一个新风险——网页内容的质量比自有知识库低得多。用一个更脏的源去补一个不全的源，这是权衡，不是解决。书里没展开这一层，是我觉得可惜的地方。
自适应 RAG 怀疑的是更前面一步：这个问题到底该不该检索。有些问题（比如"帮我改写这句话"）根本不需要外部知识，硬检索反而是干扰。这个判断本身就要花一次模型调用，所以它是个成本换准确率的交易。
图 RAG 怀疑的是检索的形态。向量检索擅长"找相似的段落"，但对付不了"谁是谁的上级""这条政策影响了哪几类人"这种关系型问题。这类问题在向量空间里没有好答案，因为答案不在某一段文字里，而在段与段之间的连线上。
五、优化那一章，说的是"脏活"
第 4 章讲优化，顺序很说明问题：先讲源数据清洗，再讲向量数据库优化、检索质量提升、提示词工程、模型优化。
把数据清洗放第一位，是对的。书里说得很直接：源数据清洗、多数据源整合和多模态数据融合是构建高质量知识库的三大核心环节；通过清洗和规范化原始数据，可以确保信息的准确性和一致性。
书里列了缺值处理、重复、格式不一致这些具体活。这些都是不体面、不出彩、也没法写进汇报的工作，但它们对最终效果的影响，往往大过一次模型升级。
举个实际会遇到的例子：一份 PDF 年报，页眉页脚每页都有，直接按字符切块，每个 chunk 里都混着"XX公司 2024 年年度报告 第 3 页"。这些字进了嵌入向量，会让所有 chunk 彼此都"相似"，检索的区分度直接塌掉。这不是模型问题，是你把噪声喂进了索引。
书里也讲了向量数据库的量化压缩（INT4/INT8/FP16/FP32）和检索算法优化。这类内容偏工程手册，但有一句话点到了要害：量化在减少存储和计算需求的同时，会带来精度损失。这个交易在 RAG 里尤其要小心，因为嵌入向量的精度损失，最后表现为"检索莫名其妙不准"——一种极难排查的故障。
六、它的短板
这本书的优点是实，缺点也是实——它太像一本操作手册了。
第一，示例全是单机 demo 量级。书里的代码确实能跑：用 PyPDF 逐页解析、用 CharacterTextSplitter 切块、用 Faiss 建索引、把元数据（文件名、页码）一起封进 Document。但也就到此为止。并发怎么办、索引怎么增量更新、权限怎么隔离、一次问答多少钱——这些真正决定能不能上线的部分，书里基本没碰。
第二，架构讲得多，选型讲得少。六种 RAG 每种都给了完整实战，但几乎没回答"我该选哪个"。而这是读者最需要的判断。实际上选型的依据很清楚：问句含糊就用多头，知识库不全就用 CRAG，关系密集就用图 RAG，其余情况经典 RAG 就够。书里有全部素材，却没有把这层判断说出来。
第三，多模态和 Agent 两章偏薄。第 8 章讲 CLIP、ImageBind、Qwen-VL 的本地推理，第 9 章讲 Agent 四大组件和 ReAct，内容都对，但都是"介绍 + 跑通"，缺少这两块真正难的地方——多模态的对齐误差怎么评估、Agent 调 RAG 时如何避免反复检索死循环。
第四，有一个前提被默默跳过了。全书假设知识库里的文档是"正确且最新"的。但现实中，知识库最常见的故障不是检索不到，是检索到了过期的版本——比如同一份政策，2023 版和 2025 版都在库里，向量长得几乎一样，检索器分不出来。加拿大航空那个案例，本质就是这类错误。书里把它当评估问题讲，其实它首先是数据治理问题。
另外还有一层，我认为值得所有做 RAG 的人记住：RAG 系统出错的最终表现，永远是一句语法完美、语气自信的错话。它不会报错，不会崩溃，不会给你任何提示。你只有主动去查，才会发现它答错了。所以第 5 章的那套评估，不是可选的质量保障，是这个系统能够被交付的前提。
一句话总结：RAG 答错的时候，问题几乎从不在生成那一步——是它压根没拿到那一段，而你从未测过它有没有拿到。
阅读记录：《基于RAG的大模型应用开发：问答系统、多模态系统与Agent开发实践》，微信读书逐页翻阅 365 屏，九章读完，读至第 9 章基于 RAG 构建 Agent 系统。2026-11-03。
发表评论: