关于RAG你需要会的

1 什么是 RAG

（RAG，Retrieval Augmented Generation）检索增强生成：给大模型配备知识库，也可以让它参考查询到的信息回答原本无法回答的问题，这种结合了信息检索与文本生成的方法就是检索增强生成。

RAG 包括三个步骤：建立索引、检索、生成。准备「导游手册」的过程就是建立知识库索引；导游翻手册查资料就是检索知识库；导游基于检索到的资料充分思考并回答游客的问题就是生成答案。

2 RAG 的实现原理

RAG 刚流行时，典型形态很单纯：一个向量数据库，加一个大模型。

向量数据库 = 专门用来存“AI理解后的东西”，并且能快速找到“意思最相近的东西”的数据库。

基于向量知识库的 RAG的实现原理如下：

基于向量知识库的 RAG 主要分两个阶段：

建立索引：首先要清洗和提取原始数据，将 PDF、DOCX 等不同格式的文件解析为纯文本数据；然后将文本数据分割成更小的片段（chunk）；最后将这些片段通过嵌入模型转换成向量数据（此过程叫做 embedding），并将原始语料块和嵌入向量以键值对形式存储到向量数据库中，以便进行后续快速、高频的检索。这就是建立索引的过程。

检索生成：系统会获取到用户输入，随后计算出用户的问题与向量数据库中的文档块之间的相似度，选择相似度最高的 K 个文档块（K 值可以自己设置）作为回答当前问题的知识。检索到的知识和你的问题会按一定格式组合起来，作为提示词（就是你发给大模型的那段文字）提交给大模型，大模型给出回复。

这类 RAG 应用在企业中随处可见：

• 内部知识库助手：帮员工快速检索公司制度、技术文档
  
• 电商导购助手：结合商品说明和用户评价，给出个性化选购建议
  
• 售后支持助手：对照产品手册和历史工单，快速响应售后咨询
  

5 持续改进 RAG 应用

5.1 从真实问题中抽样

5.2 评测体系：建立持续优化的基础

评测这件事，得由业务专家主导。他们最清楚用户会问什么、什么样的回答算解决了问题。业务专家能站在用户角度，透过真实问答洞察用户实际意图，基于亲自操作判断系统回答是否到位，并据此优化知识库、迭代评测集，持续驱动业务和技术迭代。

1. 制作评测集

评测样本通常从线上用户的真实问答、工单和负反馈中随机抽取。业务专家拿到这些样本后，为每条问题写出标准答案。

标准答案不用写成完整文章，列出关键要点就够了，这也方便后续做自动评测（后面会讲到）。

用户的真实提问配上业务专家写的标准答案，就构成了评测集。评测集不是一次做完就不管了，因为用户需求会不断变化。上个月的热点（比如景区内一场已经结束的临时展览），这个月可能就没人问了。过期的问题要淘汰，新出现的问题类型要补充，不准确的标准答案要修正。建议每周从线上问答中随机抽样，只保留最近几个月（比如 3 个月）内的真实问答对，滚动维持 1000～3000 条评测样本。

2. 建立评测指标

有了评测集，还需要一套评测指标来衡量 RAG 系统的效果。

但问题是：业务关心的指标往往不能直接用来优化系统。比如景区主管关心「游客满意度有没有提升」「问题解决率有没有提升」，但这些指标只能告诉你「出问题了」，不能告诉你「问题出在哪」。技术指标才能定位系统的问题，把这些问题逐一优化后，RAG 系统的效果通常会随之改善。

因此，你要把业务指标拆解为具体的、可量化和可优化的技术指标。

怎么拆？可以像考核一名导游的讲解服务一样，先把「游客满意度」下钻到回答过程中的关键环节，比如是否听懂了游客的问题、有没有从手册中准确找到相关的资料等。对应到 RAG 系统中，这些环节可以映射为意图理解、知识检索、答案生成等模块。只有先定位到某个具体的模块，技术指标才有明确的评估对象。

定位到模块后，就可以用技术指标量化问题了。RAG 系统可以采用 Ragas 评测体系（这是一套开源的 RAG 评测框架，详细指标定义可查阅其官方文档）：

• 检索模块：

• 准确率（Precision）：检索到的文档有多少是真正相关的
  
• 召回率（Recall）：相关文档有多少被检索到了
  

• 生成模块：

• 相关性：回答是否切题
  
• 忠实度：是否基于资料回答，没有编造
  
• 完整性：信息是否充分
  
• 流畅性：表达是否自然
  

这些技术指标怎么影响 RAG 系统的效果？举个例子：如果检索的召回率从 30% 提升到 70%，意味着系统多找回了 40 个百分点的相关信息。用户不用反复追问，一次就能拿到完整答案，满意度自然上升，工单量也会下降。

5.3 执行评测

1. 专家评测

业务专家定期从线上用户的真实问答中抽样审查，让团队持续掌握用户满意度的变化。发现异常时，业务专家要及时分析原因（归因方法在第 6 节展开）。归因清楚后，按问题类型分派改进：

• 技术团队：负责优化意图理解、检索、生成等问题
  
• 业务专家：负责补充知识库内容、更新知识、修复错误
  
• 产品团队：负责处理业务规则类问题
  

同时，专家每次审查还会产出新的评测样本，从而覆盖更多场景，持续扩展下面将讲到的自动评测能力。

2. 自动评测

专家评测发现问题后，团队会做相应修复，比如调整检索算法、优化系统提示词等。但修完之后，新问题来了：这次改动到底是改好了还是改坏了？核心技术指标有没有退化？如果每次改动后所有场景都要依赖业务专家重新人工做评测，专家就会成为系统迭代速度的瓶颈。

这时，前期沉淀的高质量评测集就派上用场了。对于评测集已覆盖的场景，直接交给机器快速批量对比验证。

具体做法是：用前面提到的 Ragas 框架，基于同一套评测集，分别跑基线版本和新版本，对比关键指标的变化。指标整体提升且核心指标没有退化，说明改动有正向收益。如果某些指标出现下降，可以结合 Trace 工具（如 LangSmith 等）查看完整的调用链路，明确是没找对（检索失败）还是没答好（生成失败），从而实现精准归因。

小结

总体来看，专家评测和自动评测应长期并行、相互补充。专家评测适合关键场景和新场景的评测、掌握用户满意度和意图空间变化、发现异常、沉淀新的评测样本与指标；自动评测适合日常批量评测，用于版本迭代后的批量回归验证，判断新版本是否稳定变好，发现潜在退化，降低上线风险。

6 如何归因问题

分析 RAG 应用的问题也是同样的思路。按照以下「五步归因分析法」，从最终回答是否有效开始，反向逐步排查到知识库：

6.1 五步归因分析法

第 1 步：回答是否解决了问题？

游客问路，你的回答让他找到了目的地吗？如果游客走到湖边无路可走，说明回答完全不对。如果你讲了一大堆景点历史但没说怎么走，说明回答太啰嗦、没切中要点。

核心看两点：用户照着 RAG 系统的回答去做，能不能得到预期结果；RAG 系统的回答是否言简意赅。

第 2 步：系统理解对了吗？

如果系统回答不对，先看 RAG 系统有没有理解对用户的意图。游客问「兰州拉面去哪吃？」，导游需要判断：查手册（RAG）？掏手机搜索（上网搜）？还是转给其他导游（转人工）？如果判断错了方向，后面做得再好也没用。意图理解决定了 RAG 系统应该走哪条路径来回答问题。

关键点：第 1 步看结果，第 2 步看方向。一前一后，是把握回答正确性的关键。

第 3 步：问题改写跑偏了吗？

在确认系统没有误解用户意图后，下一步需要检查它拿去检索的内容是否合理。有些 RAG 系统会先改写用户的问题，让它更适合检索，因为用户的输入往往信息不全、表达模糊。但如果改写时扭曲了原意就有问题了。比如用户问「附近有茶叶店吗」，改写成「附近有奶茶店吗」，导致后续检索方向跑偏。

第 4 步：检索和排序是否正确？

假设 RAG 系统判断需要查手册（走 RAG 路径），那就要看检索到的内容是否正确。在评测时，业务专家心里有标准答案，用标准答案对照系统检索出来的内容。看三个方面：

第一，找到的内容相不相关。翻到「兰州拉面的历史」明显不对，这是准确率的问题。

第二，专家知道应该有的内容有没有被遗漏。手册里记录了 8 家店只找出来 2 家，这是召回率的问题。

第三，排序对不对。找到了 10 条关于拉面的信息，但真正有用的「附近拉面店地址」排在第 8、9 条，前面全是烹饪方法和历史典故。排序不好，大模型就要在一堆无关信息里大海捞针，反而容易被误导。第 7 节会讲怎么用精排解决这个问题。

第 5 步：知识库本身有没有问题？

还有一种可能：手册里根本没记录这家店，或者记录的地址是错的。这时要检查知识库内容是否有缺失、是否准确。

6.2 构建业务需要的 RAG 系统

总体来看，构建业务需要的 RAG 系统，核心是持续对齐「意图空间」和「知识空间」的过程。

图9：意图空间与知识空间

如上图所示，把用户可能问的问题（意图空间）和 RAG 系统存的文档、规则、业务知识（知识空间）在元信息层面进行多维正交投影：

• 针对意图空间没有被知识空间覆盖的部分，需要业务专家补文档、更新规则，让知识跟上用户需求的变化。
  
• 针对知识空间中过期、重复或低质量内容的部分，会干扰检索和生成，需要业务专家和技术团队一起清理。
  
• 只有在知识空间和意图空间交叠的部分，才能通过工程和算法优化来持续迭代提升效果。
  

AI 产品经理首先要关注：

用户到底会问什么 → 知识库有没有覆盖 → 知识是不是最新、准确、完整 → 最后才是技术优化。

所以你以后面试被问：

“你认为 RAG 效果不好应该怎么排查？”

一个很不错的产品思路就是：

先查知识覆盖，再查知识质量，最后才查检索和生成链路。

7 如何改善 RAG 效果

当一个 RAG 系统的知识问答不准确时，你可以从多个角度做改进：优化用户意图理解、优化向量检索链路、引入混合检索、选择合适的信息来源、回答前反复思考、升级基座模型。

7.1 优化用户意图理解

游客问什么，导游就查什么，这未必行得通：有的问题太简略，缺关键信息；有的又长又杂，抓不住重点。所以要先「加工」，常用策略有下面几种。

追问补全

游客说话往往口语化、不够精确。

解决办法：先追问。把模糊需求补全再去查，命中率高得多。这种策略叫追问补全（Query Enrichment）。

图10：通过多轮对话完善用户问题的工作流

多角度改写

但如果游客自己也说不清楚，此时追问也问不出更多信息。怎么办？不要只从一个方向查。针对每种理解方向去查一遍手册，再综合所有结果给出答案。这种策略叫多角度改写（Multi-Query Retrieval）。

图11：Multi-Query Retrieval

假设答案

还有一种方式：导游听到「推荐个烤鸭店」，脑子里先浮现出一个答案轮廓，「全聚德应该不错」，然后你翻手册找到全聚德的详细信息（地址、营业时间、特色菜），再把完整资料告诉游客。用「第一印象」来引导查找方向。这种策略叫假设答案（HyDE，Hypothetical Document Embeddings）：让大模型先根据用户的问题生成一段假设答案，然后用这段假设的答案作为新的问题去文档库里匹配新的文档块，再进行总结，生成最终答案。

图12：假设答案

问题摘要

有时候游客的问题太长太杂，核心不明确。比如游客说了一大段话，又是描述位置又是讲个人偏好。这时可以先后退一步，让大模型提炼核心意图：「大体上看，这是什么类型的问题？」抓住主线后再去检索，比直接拿原文搜更准。这种策略叫问题摘要（Step Back）。

问题分解

与之相反，有些问题不是太杂而是太大。游客问「怎么去长城并在那里玩一天」，你可以拆解成几个小问题：怎么去？门票多少？有什么景点？午饭在哪吃？逐个查手册再整合成完整攻略。这种策略叫问题分解（Decomposition）。

7.2 优化向量检索链路

企业一般采用向量知识库支撑知识问答服务，它的核心是向量检索。从原始文档入库到准确召回，要经过解析、切分、向量化、检索、重排序等环节，每个环节都直接影响准确率。下面你可以沿着建立向量知识服务的链路逐一优化。

7.2.1提升文档解析效果

知识入库前首先要进行文档解析，从 PDF、Word、图片等原始资料中提取文字和结构，是内容提取的核心。

资料的解析质量确保了有多少内容可以完整、准确地录入知识库。尤其是表格、图片和复杂排版，一旦解析时丢失信息，后续检索就很难拼出完整答案。

来看一个具体案例：

为什么会这样？传统做法是用 OCR（Optical Character Recognition，光学字符识别）等规则化工具提取文字。OCR 能识别标准文字，但它只认字不认结构，遇到表格、图注、复杂排版时，内容之间的层级和关联关系就丢了。

处理复杂合并单元表格，重点在于保留单元格对应的行与列的关联关系。比如可以将Excel拆分填充成多个JSON对象，PDF也可以采用Docling解析为HTML。

业界更优的做法是用 AI 驱动的智能文档解析，比如阿里云的文档智能。这类工具不只识别文字，还能理解文档的结构，区分标题、表格、图注，保留层级和关联关系。

目前前沿方向之一的 Visual RAG，可直接把图片或者统计图表作为检索对象，用视觉语言模型理解图片内容，再基于检索到的视觉证据回答问题。

7.2.2 优化文档切分方式

文档切分同样重要：把整份文档切成许多片段，再放进知识库，这样大模型在回答问题时能更精准地找到相关内容。

为什么要切分？最初是受早期大模型上下文窗口限制。早期大模型的窗口只有 2K token，假如每个片段按 256 token 算，最多只能容纳 8 个片段。为了避免超出窗口的内容被截断，传给大模型的文档必须先切分，即使现在大模型拥有了超长上下文，你仍然需要对上下文进行有效管理。

你可能会问：现在大模型的上下文窗口已经很长了，直接把整篇文档塞进会话，回答不是更全面吗？

可问题在于，大模型并不会均匀地关注超长文本中的每一处信息。大海捞针（The Needle in a Haystack）测试表明：输入文本越长，大模型越容易漏掉埋在其中的关键信息；它对开头和结尾关注多，容易忽略中间的信息，即 Lost in the Middle 效应。

图15：模拟压力测试实验。在上下文较短或 needle 位于首尾时，模型找到 needle 的概率较高；

随着文本变长、needle 被埋到中间位置，找出 needle 的概率明显下降

所以通常不要给模型传入巨量的上下文内容。RAG 的策略是先把文档切成小片段，只挑最相关的几段送进大模型，每个片段都远小于上下文窗口的上限，减少模型回答的压力。

以下是几种常见的优化策略：

基于结构切分（Structure-Based Chunking）：像 HTML、Markdown、LaTeX、代码、Excel 等文件自身携带结构信息，切分时应优先利用这些结构，使每个片段保留标题、层级、段落关系、注释、公式等上下文，而非简单按固定字数截断。

• HTML：HTML 的标签天然标记了文档结构，比如  标识标题层级、标识段落。切分时可依据这些标签识别结构边界，避免将一个完整的小节或段落截断。
  
• Markdown：Markdown 的语法（标题、列表、代码块等）可直接作为切分依据。推荐的做法是先按标题层级划分内容，再在过长的章节内部进一步拆分，保证每个片段的语义完整。
  

图16：Markdown 按标题切分

• LaTeX：LaTeX 通过 \section、\subsection 等命令组织内容。切分时可沿这些结构边界划分，并将公式与其前后的解释文本保留在同一片段中，避免丢失关键上下文。
  
• 代码文件：代码的切分不应按行数机械截断，而应基于函数、类或 AST（抽象语法树）结构进行。这样可以保证每个片段在语法上完整，同时保留调用关系和实现意图，便于后续 RAG 系统理解。
  
• Excel：Excel 文件的首行通常是表头（字段名），后续各行是数据记录。如果将每行数据切为独立片段，模型看到的只是「张三, 28, 上海」这样的裸数据，后续在检索时 RAG 系统无法判断各列的含义。推荐的做法是将表头拼接到每个数据行，比如「姓名:张三,年龄:28, 城市:上海」，让每个片段都携带完整表头。
  

语义切分（Semantic Chunking）：对于没有明显格式标记，或一节内混杂多个话题的文本，按固定字数硬切容易斩断上下文。这时更好的做法是计算句子间的语义相关性，找到主题边界再切分，把意思相近的句子归到同一片段。比如相邻句子都在讲套餐价格，就不从中切开；话题从套餐价格跳到预订流程，就在转折处切一刀。

7.2.3 补充片段的上下文

但无论怎么切，由于片段本身只包含一部分信息，难免会出现信息断裂或背景丢失。怎么才能让这些孤立的片段找回原本的语境？这里介绍三种常见策略：

字符重叠

让相邻片段保留一部分重叠字符（通常是单片段字符数的 10%～20%），避免边界附近的关键信息被切断。

如下图所示，不加重叠时，游客问「全聚德烤鸭双人套餐，怎么预定？」，片段 2 会因为缺少「全聚德」、「预定」等语义信息而无法被召回，关键限制随之漏掉。加上重叠后，大模型就能顺利找到片段 2 并给出更完整的回答。

图18：让相邻片段保留一部分共同内容（重叠），避免边界信息丢失

句子滑动窗口

按单句切分并向量化以保证检索精准，同时通过设置 window_size 指定保留该句前后多少上下文。例如设置 window_size = 2，即保留当前句前后各 2 句，连同目标句一共 5 句。

图19：设置 window_size（如设为 2）保留句子前后的上下文

后续当用户问题命中某个单句时，系统实际送给大模型的是扩充了前后背景的完整窗口。

上下文增强

切分之后，每个片段都脱离了原文语境，RAG 的检索系统很难判断片段原本属于文档的哪个部分、与其他片段有何关联。为了保留片段的位置信息、或者说明该片段在文中的作用，可以为每个片段生成一段摘要，这就是上下文增强（Contextual Augmentation）。2024 年以来，这一方向涌现出 Late Chunking、Contextual Retrieval 等技术，通过还原语境，让召回更准、回答更稳。

图20：Contextual Retrieval 为每个片段补充上下文，还原其语境

7.2.4优化片段的语义理解

以前的办法是用关键词检索，也就是文本匹配，只认字、不认含义。工程师想了不少办法补强：用同义词词典把「西红柿」和「番茄」划上等号，点击模式挖掘发现搜「北京烤鸭」和搜「全聚德」的人想要的结果其实一样。然而，这些关键词之间的关联全靠人工构建和维护。

文本嵌入（Text Embedding）换了个思路：把含义映射成向量空间中的一个「点」，意思相近的两个向量，在空间中的距离会更近。这种语义关联是从训练数据中自动学到，无需人工逐条建立。你可以先用二维平面来想象：假设每个片段都是平面上的一个点（二维向量），意思越相近，位置也越靠近。如下图中，“通心粉”和“意大利面”的距离更近。

但一段文字的含义远不止两个维度，实际可能有数千个维度。

图21：意思相近的文本在空间中位置也相近

如何将一段文字变成一串数字（向量）？ 过程很简单：

1. 把这段文字喂给一个文本嵌入模型（Text Embedding Model）如BGE 系列
   
2. 模型会将这段文字转化为一个向量（通常上千维，每个数字取值在 -1 到 +1 之间）
   
3. 这个向量就是这段文字的嵌入向量串
   

图22：文本经过嵌入模型输出一个向量，再存入向量数据库

每个数字代表什么？ 没人能给出准确答案。可以把每个数字理解为文本在某个特征上的「得分」。这些特征是嵌入模型在训练阶段学到的，事先没有人为定义。所以不能说第 587 个数字「这就是美食维度」，只能大致猜测：比如有的数字可能和美食有关，有的和餐厅有关，还有的和交通路线有关。

图23：嵌入向量中的每个数字，代表文本某方面特征的得分

嵌入模型在训练阶段“学过”的数据，决定了它擅长处理的语言和任务类型。落到你的业务，如果主要做中文检索，就优先选择中文表现好的模型。你可以去 ModelScope 社区挑最近关注度高、下载量大的模型，一般不会踩坑。如果不想自己部署，阿里云提供了按 token 计费的通用文本向量 API，它是通义实验室基于大模型底座开发的多语言向量模型，开箱即用，项目初期没有运维成本。另一个热门选择是智源研究院的 BGE 系列，其中 bge-large-zh-v1.5 在中文场景表现突出。

利用向量召回片段

切分后的文本片段连同其嵌入向量以键值对的形式一起存入向量数据库。检索时，用户的问题也会被同一个嵌入模型转成向量，再度量它与已入库片段向量之间的相似程度。一种常见的度量方式是余弦相似度（Cosine Similarity）：以二维平面为例，比较两个向量之间的夹角。夹角越小，语义越相关；夹角越大，语义越无关。

图24：用余弦相似度度量向量间的语义相关程度

给问题向量和库里每个片段向量算完相似度后，系统再从高到低排序，取前 N 个（top N）片段作为候选。这一步的 N 可以设得大一些（>100）：宁可多召回，也不漏掉可能相关的内容，更精细的筛选交给后面要讲的重排序（ReRank）。

7.3 引入混合检索

向量检索（语义检索）擅长找表达相近的内容，但容易遗漏编号、名称、专有名词这类适合精确匹配的信息。所以工程上仍然建议保留传统的关键词检索。常见的做法是两路分工：编号、名称、专有名词匹配交给关键词检索；语义相近、表达多变的交给向量检索。两路结果分别召回后，再合并排序，这就是混合检索（Hybrid Search）。

合并多路召回结果

解决方案是通过 RRF（Reciprocal Rank Fusion，倒数排名融合） 对各片段在不同召回结果中的排名进行打分（RRF Score），再合并成一份统一的候选列表。这样你就拿到了一批更准确的片段，既有专有名词查询结果，也有高语义相似度的片段。

精选送入大模型的内容

前面提到，大模型在处理长文本时，并不会均匀关注所有信息，尤其容易忽略位于上下文中间的内容。而多路召回返回的大量结果，往往只有很少的部分真正有用，把大量无关信息输入上下文会严重干扰大模型判断（Context Rot 现象）。

所以解决思路是：用精排（ReRank）精选最相关的几条，提高送入大模型的有效信息浓度。

前面的 RRF 是粗排：速度快，目标是尽量不漏掉可能相关的内容。精排则会把用户问题和候选片段放在一起理解，判断它们是否真的匹配。比如游客问「全聚德人均消费多少」，粗排觉得「全聚德的百年历史」很相关（都提到了全聚德），但精排会发现这篇讲的是历史不是价格，相关度不高。精排后只保留最相关的 top K 个片段（K 可配置）送给大模型。

实践中，可以先从 K=3 或 K=5 开始，分别运行评测集对比不同 K 值的效果，你可能需要关注是否存在类似问题：

• 真正相关的片段有没有被召回
  
• 真正相关的片段是否被排在前面
  

根据评测结果，再决定是否调大或调小 K。如果调整 K 之后效果仍然不理想，再考虑更重一步：更换或优化 ReRank 模型。好的 ReRank 模型就像经验丰富的导游，能准确判断哪条信息最能解决游客的问题。你也可以让技术团队测试不同的 ReRank 模型，选出最适合业务的。

7.4 选择合适的信息来源

需要实时信息，可以上网搜索。 许多主流大模型（Qwen、GPT、Claude 等）的智能体产品已经支持联网搜索，常见形式包括 Web Search（调搜索 API）、Web Fetch（抓取网页内容）、Browser Use（操作浏览器）三档。不过要注意，有些网站会限制 AI 抓取，需要登录才能获取页面内容。

需要内部业务数据，可以从数据库查数据。 像「去年收入是多少」这类问题，答案往往存在内部数据库或 BI 系统。如果你要查询这类数据，常见做法是让大模型把自然语言问题转换成 SQL，这类技术叫 NL2SQL。该技术降低了查数门槛，但不能默认其结果一定可靠：真实业务往往库表结构复杂、指标口径不统一，另外还要处理权限控制。如果直接面向客户或用于关键决策，建议配合 SQL 校验、权限限制和结果复核。

要实体之间的关系，就从知识图谱挖关系。 游客问「故宫和颐和园有什么历史渊源？」——系统从知识图谱里查找两个景点的关联节点，发现都和清朝皇室有关，挖掘出隐藏的关联信息。代表方案是微软的 GraphRAG，以及更轻量、构建更快的 LightRAG。

7.5 回答前反复思考

在 RAG 系统中加入反馈路径、让系统在回答前进行自我反思。

图32：让 RAG 系统在回答前进行反思

图中的这些检查可以借助提示词工程用大模型来完成。虽然这会增加系统复杂度，但能有效减少错误回答。

更资深的导游遇到复杂问题时，会先在脑海中思考，做任务拆解与规划。比如游客问「带老人小孩，怎么规划明天的游览路线？」，导游就会去先看天气、路线是否方便、哪里适合休息等。在执行过程中，他会根据观察到的新情况，随时调整后续步骤，直到所需信息集齐，再组织好语言，给出条理清晰的回答。

这就是目前主流的 Agentic RAG。它靠一个「思考→行动→观察→决策」的推理循环（ReAct 模式）实现自主决策：理解问题、选择信息源、执行检索、自我反思——全部交给系统自主调度，不再需要开发者提前规定唯一路径。每执行一步，系统都会检查当前结果够不够好，不够就换用其他策略再来一轮。

图33：Agentic RAG 自主决策循环（简化示意）

7.6 升级基座模型

大模型技术日新月异，你可以通过一些第三方评测榜单（如 Artificial Analysis，livebench.ai）来了解最新发布的大模型的性能，选择适合你当前任务的候选模型。

建议先用自动评测对比线上部署的大模型和候选大模型，快速筛选出在当前场景下表现更优的。再让业务专家抽样对比，重点关注文字组织、伦理合规等方面的细微差异，从而确定是否切换基模，不断提升知识问答的表现。

本节小结

这一节，你完整了解了 RAG 是什么、怎么工作的，还动手体验了搭建 RAG 应用。更重要的是，你学会了「业务驱动、评测优先」的持续优化方法：如何建立评测标准、如何归因问题、如何针对性改进。有了这些方法，你就能和技术团队合作打造适用于公司内部的知识问答系统。