RAG系统答非所问？从检索到评估的工程化排查指南
当RAG系统开始“自信地胡说八道”
假设你给团队搭建了一个内部知识库。文档导进去了，向量库建好了，大模型也接上了。测试时问它“出差住宿费怎么报”，回答有条有理，最后还附了出处。
点开出处一看：引用的是两年前的旧版制度。
换个问题，问某款产品的功能限制，系统又把同系列另一款产品的说明拿了过来。答案仍然很流畅，语气也很自信，但问题完全没有被解决。
这种情况在RAG（检索增强生成）开发初期非常常见。很多开发者此时的第一反应是换一个大模型，或者调整提示词（Prompt）。但如果证据源本身就有问题，再强大的模型也只能基于错误的前提进行推理。
面对这类“幻觉”或“错引”，更有效的做法是沿着数据流动的路径去排查：到底是哪份材料进了系统？哪段内容被切分错了？检索时为什么没区分适用范围？最终提示词里，模型到底看到了什么？
这也是《RAG与LangChain开发实战：从知识检索到智能生成》这本书试图解决的核心问题。它没有停留在“如何调用API”的层面，而是将知识库构建、检索增强、生成控制、评估与优化放在同一条主线上。对于正在从Demo走向生产环境的开发者来说，这种工程化视角比单纯的代码示例更有价值。
别只盯着模型，先看看检索结果
在做知识问答系统时，我们很容易陷入“模型中心主义”：觉得回答不好是因为模型不够聪明。于是不断切换模型提供商，调整温度参数，修改System Prompt。
这时候，不妨先把检索结果单独拿出来看。
比如用户问的是“A型号产品的售后条件”，搜索结果里出现了“售后”“维修”“服务”等关键词，但这并不代表已经找到了适用条款。产品型号、版本、地区，都可能决定这段材料是否有效。如果检索阶段把B型号的说明书也召回了，模型就很难在不产生幻觉的情况下排除干扰。
书中提到的“多路召回”和“重排序”技术，正是为了解决这个问题。
多路召回让系统有机会从不同路径寻找候选材料。例如，同时使用关键词检索（BM25）和向量检索（Embedding）。关键词检索擅长精确匹配专有名词，而向量检索擅长语义理解。两者结合，可以互补短板。
**重排序（Re-ranking）**则是对已经召回的候选集进行二次筛选。以交叉编码器（Cross-Encoder）为例，它会同时处理“用户问题”和“候选文档”，计算二者的相关程度得分。这一步虽然增加了计算开销，但能显著提升进入上下文窗口的文档质量。
这里有一个重要的边界需要记住：重排只能处理已经召回的候选。如果关键证据在第一轮检索中就被漏掉了，重排阶段无论如何打分，也找不回它。
因此，学习检索和重排时，一个值得做的练习是把中间结果打印出来：原始候选有哪些？重排后留下了哪些？最终送入模型的上下文用了哪些？看着这些数据流，很多“答非所问”的问题就能找到具体出处。
理解LangChain的数据流向
对于框架类技术书，我通常有一个偏好：希望它能帮助我理解组件为什么这样组合，而不仅仅是提供一段可运行的代码。
拿到一段能跑的LangChain代码，建立直觉很容易。但接下来必须弄清楚：检索器返回的是什么结构？文档怎样被格式化并进入提示词？模型输出由谁解析？工具调用的结果又回到哪里？
这本书把LangChain核心模块和Agent机制纳入讲解范围，这部分值得带着上述问题去读。理解了数据与调用关系，在修改流程、替换组件时才更有把握。
书中还涉及了Agentic RAG的概念。可以把它理解为让模型参与决定“何时检索”、“怎样检索”。具体实现上，可以加入检索结果判断、查询改写和再次检索等步骤。LangChain官方的相关教程就展示了这样的流程：模型先分析用户意图，如果需要外部知识，则生成搜索查询；拿到结果后，模型判断信息是否充足，若不足则发起第二轮检索。
但在给自己的项目选方案时，得看问题是否真的需要这些步骤。
一个范围明确、文档结构清晰的内部问答系统，先建立简单、线性的流程更方便维护，也更容易排查问题。只有遇到需要多次查找、跨文档整合资料的任务时，才考虑增加Agent的规划能力。因为每一步Agent的决策都意味着额外的延迟和Token成本。带着这种判断去学Agent，才知道每个步骤解决了什么问题，以及多出来的等待时间是否值得。
评估：从“感觉变好了”到“数据证明”
在这本书的内容里，评估与优化是我特别关注的部分。
因为在没有评估体系的情况下，“改完好像更好了”是一种很危险的直觉。假设你换了文档切分方式，又加了重排，最后还调整了提示词。新的回答看起来更完整，可究竟是哪项修改起了作用？原来答得对的问题，会不会因为这次修改而变错？
我会建议保留一组固定测试集（Golden Dataset），让修改前后的系统回答同样的问题，然后分别检查以下几个维度：
- 检索质量：检索结果是否包含回答问题所需的充分证据？
- 答案相关性：回答是否正确回应了用户的问题，有没有跑题？
- 忠实度（Faithfulness）：回答中的说法能否由检索到的材料支持？有没有编造事实？
- 拒答能力：遇到资料不足的情况，系统是否诚实地说明了缺口，而不是强行作答？
LangSmith等工具提供的RAG评估教程，也是将答案正确性、相关性、对检索材料的忠实度，以及检索质量分开考察。拆开来看，比只给最终答案打一个总分更便于定位问题。
除了质量检查，还要记录响应耗时和调用成本。增加一个重排步骤，延迟增加了多少？准确率提升了几个百分点？结合业务要求来判断，这个 trade-off 是否划算。
这也是我关注书中评估与优化内容的原因：搭好流程只是第一步，还需要回答“怎么知道修改有效”。
国产模型接入与本地化部署
对于国内开发者而言，书中关于DeepSeek等国产模型接入的内容也比较贴近实际需求。
LangChain提供了对DeepSeek模型的集成支持，开发者可以通过对应组件调用其托管模型服务。但在具体项目中，我更关心的是接入之后的表现：同样的资料和问题，回答是否遵循要求？引用是否准确？工具调用能否完成预期任务？
如果项目还有本地部署要求，也要继续确认具体模型版本、推理服务框架、硬件资源消耗和数据流安全性。支持国产模型接入，只能说明其中一部分能力，完整部署仍要结合自己的环境验证。
所以，读这一部分时，可以把它和前面的检索、生成、评估串起来。拿自己的任务测试，模型选择才有依据。
带着自己的资料去实践
阅读这类实战书籍时，建议准备一小份熟悉的资料，再写下自己确实需要解决的问题。
比如，用产品手册做一个问答助手，同时放进容易混淆的型号说明；或者用内部制度做知识库，保留版本差异，让系统处理适用条件。也要故意留下一些资料中根本没有答案的问题，测试系统的拒答能力。
跟着内容搭出基本流程后，每增加一种方法，就回到这些问题上检查变化。出了错，保留当时的检索结果、上下文和回答，再去找对应环节。
这本书提供企业知识库、智能问答等实战方向，可以作为动手的入口。具体代码和依赖版本，阅读时仍适合对照官方文档确认；把注意力放在设计理由和排查方法上，收获会更长久。
如果你已经调用过模型API，或者搭过简单的问答系统，现在开始关心“为什么漏检”、“为什么引用不对”、“改完到底有没有变好”，那么这条从知识检索到智能生成的内容主线，值得你认真看看。
我会带着开头那个问题去读：系统拿着旧版制度，为什么还能给出一段自信的回答？等到能沿着整条流程找到原因，做出修改，再用相同的问题验证结果，书里的知识也就开始成为自己的开发能力了。