想象你是一家大型图书馆的资深管理员。过去，读者提问时，你总是火速冲到书架前，抱回一摞书，然后埋头摘抄——这就是传统 RAG 的流程。但问题是，你经常抱回一堆无关紧要的书，或者书的内容已经过时，而你却毫不知情，照抄不误，最后给读者一个错误答案。 现在，你决定改变工作方式。每次抱回书后，你不再急着摘抄，而是先做一次“质检”：快速翻阅这些书，评估它们跟问题的关联度有多高。如果质量高，直接摘抄；如果质量一般，就回到书架重新找，甚至换一个查找思路；如果质量极差，你干脆放下书，走到隔壁的互联网信息中心，从海量更新的在线资讯中寻找答案。这个“检索后质检、按需纠错”的工作流，就是今天的主角—— Corrective RAG（CRAG） 。

岗位关联

掌握 CRAG，意味着你的 RAG 系统不再“盲目自信”。你将学会如何让系统识别自己的不足，并像一位资深专家那样，在关键节点做出正确的补救决策——这是通往可靠、鲁棒的企业级 RAG 应用的必修课。

目录
  1. 可视化演示
  2. CRAG概念
  3. 检索评估
  4. 置信度判断
  5. 纠错策略
  6. 对比标准RAG
  7. 系统实现
  8. 应用场景
  9. 未来展望
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

动态演示Corrective RAG的核心机制，通过基础/核心/应用/扩展四种模式展示关键概念与交互流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

Corrective RAG：CRAG CRAG的核心思想与检索纠错架 检索结果评估与置信度判断 核心机制可视化 Corrective RAG整体架构与关键组件

CRAG概念

还记得那位图书馆管理员吗？在传统的 RAG 系统里，他就是一个“埋头苦干的搬运工”——读者提问，他冲进书架检索，把找回来的资料往桌上一堆，就开始埋头整理答案。问题在于，搬运工从不检查自己抱回来的书是否真的有用，哪怕拿错书、拿到过时的百科，他也照抄不误。这种“有错不知”的流程，在生产环境中会引发严重的幻觉问题。

Corrective RAG（CRAG）正是为了解决这个问题而生的。它给搬运工配备了一位“质检员”——在检索完成之后、生成答案之前，插入一个评估-纠错环节。这个概念的核心思想是：不要让 RAG 系统盲目相信一次检索的结果，而是通过轻量级的评估手段，主动识别检索质量问题，并根据问题的严重程度，采取不同的纠正策略。其完整流程可以概括为：检索 → 评估 → 置信度分级 → 纠错策略 → 生成。

这一设计思路借鉴了人类专家的工作习惯：专家在引用资料时，绝不会拿到什么就信什么，而是会快速判断资料的可靠性，再决定是直接使用、换一本参考书，还是上网搜索最新信息。CRAG 将这套判断逻辑固化到系统中，让每一次检索都经过质量把关。相比传统 RAG 的“一次性决定”，CRAG 提供了一个可进退的决策框架，极大地提升了系统的鲁棒性。

质检员模式不是凭空发明，而是 RAG 系统走向成熟的关键一步。从前端交互到后端架构，CRAG 的意义在于让系统拥有“自知之明”——知道什么时候该相信自己，什么时候该怀疑自己，这恰恰是智能系统的核心能力。

CRAG 流程=Retrieve→Eval→(Refine∣Re-retrieve∣Web Search)→Generate\text{CRAG 流程} = \text{Retrieve} \rightarrow \text{Eval} \rightarrow \left(\text{Refine} \mid \text{Re-retrieve} \mid \text{Web Search}\right) \rightarrow \text{Generate}
这个公式是 CRAG 系统的全景图。它说明 CRAG 不是简单的“检索-生成”两步走，而是在中间加入了评估（Eval）环节，并根据评估结果在三条纠错路径（精炼 Refine、重检索 Re-retrieve、Web 搜索）中选择一条，最终才进入生成。
  1. 检索系统根据用户问题从知识库中召回候选文档。
    Retrieve(q)→D={d1,d2,…,dn}\text{Retrieve}(q) \rightarrow \mathcal{D} = \{d_1, d_2, \dots, d_n\}
  2. 评估对每篇文档的相关性进行打分。
    Eval(di)→si∈[0,1]\text{Eval}(d_i) \rightarrow s_i \in [0, 1]
  3. 策略选择根据综合置信度决定走哪条纠错路径。
    Strategy={Refine高置信度Re-retrieve不确定Web Search低置信度\text{Strategy} = \begin{cases} \text{Refine} & \text{高置信度} \\ \text{Re-retrieve} & \text{不确定} \\ \text{Web Search} & \text{低置信度} \end{cases}
  4. 生成基于纠错后的上下文生成最终答案。
    Generate(q,D∗)→Answer\text{Generate}(q, \mathcal{D}^*) \rightarrow \text{Answer}

检索评估

质检员上岗后的第一项工作，就是练就一双“火眼金睛”——快速判断一份资料与当前问题的相关程度。在图书馆场景中，这相当于快速翻阅书的前言、目录和关键章节，判断这本书是否真的能回答读者的疑问。在 CRAG 中，这个角色由轻量级评估器承担。

评估器的工作方式极具巧思。它不直接问大模型“这段文本相关吗”（那样太慢太贵），而是采用分词任务分解：将检索到的文档与用户问题拆分成若干语义片段，然后逐块计算相关性分数。这种细粒度的方式让评估更精准，也更容易定位文档中哪些部分有效、哪些部分是噪音。评估器本身通常由一个小型语言模型或经过微调的评分模型构成，力求在保证判断质量的同时，把计算开销控制在可接受范围内。

具体实现时，评估器会对每个文档-问题对输出一个相关性分数。这些分数不仅反映“相关/不相关”的二元判断，还会附带一个置信度指标，指示这个判断本身的可靠程度。这个设计非常贴近我们的日常经验——一本看起来很相关的书，也可能只是标题吸引人，翻开才发现内容空洞。评估器需要同时给出“这本书对我有没有用”以及“我对这个判断有没有把握”两个信号。

有了评估器这个“火眼金睛”，系统终于能够分辨“金矿”和“废石”。但光有评估还不够——如何解读这些分数，做出正确的应对决策，才是 CRAG 真正精彩的地方。

Score(d,q)=1K∑k=1KE[ I(relevant(dk,qk)) ]\text{Score}(d, q) = \frac{1}{K} \sum_{k=1}^{K} \mathbb{E} \left[ \, \mathbb{I}(\text{relevant}(d_k, q_k)) \,\right]
这里的公式描述了评估器如何综合 K 个片段的相关性判断，得出文档的整体相关性分数。其中 $\mathbb{I}(\cdot)$ 是指示函数——当第 k 个片段与问题第 k 个部分相关时记 1，否则记 0，最后取平均。这相当于质检员把一本书分成若干章节，分别评估每一章对回答问题是否有帮助，最后综合出整本书的价值判断。
  1. 分解将文档和问题分别拆成 K 个语义单元。
    d→{d1,d2,...,dK},q→{q1,q2,...,qK}d \rightarrow \{d_1, d_2, ..., d_K\}, \quad q \rightarrow \{q_1, q_2, ..., q_K\}
  2. 打分对每个文档片段和问题片段做相关性判断。
    relevant(dk,qk)∈{0,1}\text{relevant}(d_k, q_k) \in \{0, 1\}
  3. 指示函数把判断结果转化为数值信号。
    I(relevant(dk,qk))=1 if relevant, else 0\mathbb{I}(\text{relevant}(d_k, q_k)) = 1 \text{ if relevant, else } 0
  4. 平均综合所有片段得分，得到整体相关性分数。
    Score=1K∑k=1KI(… )\text{Score} = \frac{1}{K} \sum_{k=1}^{K} \mathbb{I}(\dots)

置信度判断

质检员不仅评估每份资料，还要回答一个更关键的问题：“这些资料整体上够不够好？”这就像图书馆管理员面对一堆书，不仅要判断每本书的质量，还要综合判断：“这堆书够不够我写出一份完美答案？”这个综合判断在 CRAG 中被称为置信度。

CRAG 使用阈值作为判断标准。评估器产出的分数经过汇总后，会与预设的高、低两个阈值进行比较。当综合分数超过高阈值时，系统判定为高置信度——检索结果质量很好，可以直接进入精炼生成阶段。当分数低于低阈值时，判定为低置信度——检索结果基本不可用，需要启动更激进的纠错手段。落在两个阈值之间的，则是不确定态——检索结果有参考价值但不够充分，需要尝试重检索。

这个阈值机制看似简单，实则是 CRAG 的灵魂所在。它把“检索质量”这个模糊概念转化成了清晰的决策树，让系统每次都能做出最优的下一步选择——就像经验丰富的医生，先快速判断病情严重程度，再决定是开药、转诊还是直接急救。

Confidence={HighScore≥τhighLowScore≤τlowUncertainτlow<Score<τhigh\text{Confidence} = \begin{cases} \text{High} & \text{Score} \ge \tau_{\text{high}} \\ \text{Low} & \text{Score} \le \tau_{\text{low}} \\ \text{Uncertain} & \tau_{\text{low}} < \text{Score} < \tau_{\text{high}} \end{cases}
这个公式展示了 CRAG 如何将连续分数转化为离散的置信度等级。$\tau_{\text{high}}$ 和 $\tau_{\text{low}}$ 是经验阈值，就像质检员心里的两把尺子——超过这把尺子说明料很足，低于那把尺子说明完全不行，两者之间则是“还凑合但得再找找”。
  1. 输入将评估器产出的综合分数作为输入。
    Score∈[0,1]\text{Score} \in [0, 1]
  2. 高阈值判断分数是否达到高置信度门槛。
    Score≥τhigh⇒High\text{Score} \ge \tau_{\text{high}} \Rightarrow \text{High}
  3. 低阈值判断分数是否跌破低置信度底线。
    Score≤τlow⇒Low\text{Score} \le \tau_{\text{low}} \Rightarrow \text{Low}
  4. 中间态落在两阈值之间为不确定态。
    τlow<Score<τhigh⇒Uncertain\tau_{\text{low}} < \text{Score} < \tau_{\text{high}} \Rightarrow \text{Uncertain}

纠错策略

当置信度分级完成后，系统的“纠错三修方案”正式登场。这一节就像图书馆的“应急处理手册”：不同情况对应不同行动方案。

高置信度 → 精炼处理：当检索结果质量优秀时，系统选择精炼（Refine）。它会把检索到的文档与原始问题结合，通过抽取关键信息过滤噪音，形成精炼的知识片段，再送入生成器。这相当于质检员看完书后，在便签上划出最重要的几段话，而不是把整本书塞给写手。

不确定态 → 重检索触发：当检索结果“不上不下”时，系统进入重检索（Re-retrieve）模式。它会分析当前结果缺失的信息，进行查询改写——比如将“苹果公司的创始人”改写为“Steve Jobs 与苹果公司的创立关系”——然后用改写后的问题再去知识库检索。这类似于管理员发现手上的书不够新，于是按旧书的参考书目去查找更新的资料。

低置信度 → Web 搜索兜底：当检索结果几乎完全不可用时，系统启用Web 搜索作为最后手段。它会将问题直接发送到外部搜索引擎，抓取网页内容作为备选知识源。Web 搜索返回的内容往往更实时、更宽泛，虽然格式和噪声更复杂，但在本地知识库无力支撑时，这是最有效的保底方案。这就像管理员放下旧书架，大步走向互联网信息中心的计算机终端，从海量的在线数据中寻找答案。

三种策略环环相扣，覆盖了从“资料很好”到“资料全废”的全谱系场景。精炼保证质量，重检索填补空缺，Web 搜索兜底极端情况——这正是 CRAG 得以在各种恶劣检索条件下“存活”的秘密。

Refine:d~=Snippet(d,q)⟶Gen(q,d~)\text{Refine}: \quad \tilde{d} = \text{Snippet}(d, q) \quad \longrightarrow \quad \text{Gen}(q, \tilde{d})
Re-retrieve:q′=Rewrite(q,missing_info)⟶Retrieve(q′)\text{Re-retrieve}: \quad q' = \text{Rewrite}(q, \text{missing\_info}) \quad \longrightarrow \quad \text{Retrieve}(q')
Web Search:dweb=SearchEngine(q)⟶Gen(q,dweb)\text{Web Search}: \quad d^{\text{web}} = \text{SearchEngine}(q) \quad \longrightarrow \quad \text{Gen}(q, d^{\text{web}})
这三组公式分别对应三种纠错策略。第一组表示从文档中抽取关键片段精炼后生成；第二组表示先重写查询再重新检索；第三组表示直接从外部搜索引擎获取网页内容来生成。它们共同构成了 CRAG 的完整纠错工具箱。
  1. 精炼公式从高相关文档中抽取与问题相关的片段。
    d~=Snippet(d,q)\tilde{d} = \text{Snippet}(d, q)
  2. 精炼生成用精炼后的片段生成答案。
    Gen(q,d~)→Answer\text{Gen}(q, \tilde{d}) \rightarrow \text{Answer}
  3. 重写公式根据缺失信息重写查询。
    q′=Rewrite(q,missing_info)q' = \text{Rewrite}(q, \text{missing\_info})
  4. 重检索生成用新查询重新检索并生成。
    Retrieve(q′)→Gen(q,d′)\text{Retrieve}(q') \rightarrow \text{Gen}(q, d')
  5. Web 搜索公式从搜索引擎获取外部文档。
    dweb=SearchEngine(q)d^{\text{web}} = \text{SearchEngine}(q)
  6. 兜底生成基于外部文档生成答案。
    Gen(q,dweb)→Answer\text{Gen}(q, d^{\text{web}}) \rightarrow \text{Answer}

对比标准RAG

看到这里，你可能会问：CRAG 到底比传统 RAG 强在哪？让我们回到图书馆，对比两种工作模式的差异。

传统 RAG 是“一次检索定终身”的书呆子。它不看资料质量就动笔，即使检索到一堆无关信息，也会硬生生地编出答案。这种盲目检索的缺陷在于：知识的源头脏了，下游生成再强也是白搭。更致命的是，遇到高质量问题需要多轮查找时，传统 RAG 毫无“回头路”可走，一次失败即全盘失败。它的架构是静态的：检索-生成，生成-结束，没有任何中间干预点。

CRAG 则像一位“精细化管理”的团队主管。它把检索这件事从“跑一趟腿”升级为“闭环管理”。不仅评估检索结果，还能在一次检索不充分时不放弃，通过多轮纠错不断提高知识质量。在面对复杂问题（如多跳推理）时，CRAG 的重检索机制能帮助系统一步步补齐缺失的信息链路，而传统 RAG 只能在第一步就戛然而止。

这种差异的本质，是鲁棒性的跃迁。在真实应用中，知识库的数据质量参差不齐，用户提问千变万化，一次检索就能命中的场景越来越少。CRAG 的设计哲学是“承认检索可能失败，并为失败做好预案”——这种“允许犯错但及时纠正”的思路，是传统 RAG 完全不具备的。

对开发者而言，标准 RAG 就像一个快捷键“Ctrl+S“——按错了就全没了；CRAG 则更像”版本管理”——即使当前快照坏了，也能回退、分支、重新提交。在 RAG 应用迈向生产环境的路上，这种稳健性弥足珍贵。

Robustness=P(Answer is correct)=P(Retrieval good)⏟传统RAG⋅P(Generation good)⏟两者均具备+P(Retrieval bad)⋅P(Corrective good)⏟仅CRAG具备\text{Robustness} = \mathbb{P}(\text{Answer is correct}) = \underbrace{\mathbb{P}(\text{Retrieval good})}_{\text{传统RAG}}\cdot\underbrace{\mathbb{P}(\text{Generation good})}_{\text{两者均具备}} + \underbrace{\mathbb{P}(\text{Retrieval bad})\cdot\mathbb{P}(\text{Corrective good})}_{\text{仅CRAG具备}}
这个公式从概率视角解释了 CRAG 为何更鲁棒。传统 RAG 只有在“检索好且生成好”时才能答对；而 CRAG 在“检索差”时还能通过纠错环节挽回——多了一条成功路径。简单说，CRAG 给系统上了双保险。
  1. 正确概率系统答对的整体概率。
    P(Answer is correct)\mathbb{P}(\text{Answer is correct})
  2. 传统路径检索好且生成好。
    P(Retrieval good)⋅P(Generation good)\mathbb{P}(\text{Retrieval good}) \cdot \mathbb{P}(\text{Generation good})
  3. CRAG 加成检索差但纠错成功。
    P(Retrieval bad)⋅P(Corrective good)\mathbb{P}(\text{Retrieval bad}) \cdot \mathbb{P}(\text{Corrective good})
  4. 整合两条路径相加得到总鲁棒性。
    Ptotal=P1+P2P_{\text{total}} = P_1 + P_2

系统实现

理论清晰后，如何在实际代码中搭建这套“质检-纠错”流水线？CRAG 的系统实现并不复杂，关键在于将评估器、置信度判断、纠错路由三个组件正确串联。

首先看组件设计。一个典型的 CRAG 系统包含四个核心模块：检索器（Embedding + 向量库）、评估器（轻量评分模型）、纠错路由器（基于置信度选择策略）、生成器（LLM）。数据流是：用户问题 → 检索器召回文档 → 评估器对文档打分 → 路由器根据阈值分流 → 执行对应策略 → 最终送入生成器。

在工程落地上，LangChain 提供了良好的集成基础。开发者可以基于 langchain 构建检索链，自定义评估函数作为路由器。以 Python 代码为例，核心实现思路是：先定义一个 score_documents 函数模拟评估器打分，再定义一个 route_by_confidence 函数根据分数分流到 refine、re_retrieve、web_search 三个分支。整个系统约 100 行代码即可完成原型。评估器选型是关键，常用方案包括：基于 LLM 的零样本打分、基于小模型的微调打分、以及基于规则的关键词匹配。三者复杂度递减，但效果也相应递减——开发者需要根据预算和精度需求权衡。

以下用一段完整的 Python 代码演示 CRAG 的核心路由逻辑：

四个函数各司其职，代码实现不过是这把“函数折叠尺”的逐步展开。真正优雅之处在于：每个函数都可以独立优化、单独测试——这让 CRAG 系统的维护和升级变得异常轻松。

CRAG 函数=feval∘groute∘hcorrect∘kgenerate\text{CRAG 函数} = f_{\text{eval}} \circ g_{\text{route}} \circ h_{\text{correct}} \circ k_{\text{generate}}
这个公式把 CRAG 系统表达为四个函数的复合：评估 $f_{\text{eval}}$ → 路由 $g_{\text{route}}$ → 纠错 $h_{\text{correct}}$ → 生成 $k_{\text{generate}}$。工程实现时，只需把四个函数一一实现并串联即可。
  1. 评估函数输入检索文档，输出相关性分数。
    feval:D→[0,1]nf_{\text{eval}}: \mathcal{D} \rightarrow [0, 1]^n
  2. 路由函数根据分数映射到策略。
    groute:[0,1]n→{refine,re_retrieve,web_search}g_{\text{route}}: [0, 1]^n \rightarrow \{\text{refine}, \text{re\_retrieve}, \text{web\_search}\}
  3. 纠错函数执行对应策略，输出精炼后的文档集。
    hcorrect:{策略,D,q}→D∗h_{\text{correct}}: \{\text{策略}, \mathcal{D}, q\} \rightarrow \mathcal{D}^*
  4. 生成函数基于精炼文档生成答案。
    kgenerate:{q,D∗}→Answerk_{\text{generate}}: \{q, \mathcal{D}^*\} \rightarrow \text{Answer}

应用场景

CRAG 的“纠错三板斧”在实际工作中能解决哪些痛点？让我们走进几个真实场景。

企业知识库问答是 CRAG 最典型的应用场景。大型企业往往拥有数十万份内部文档，包括制度文件、产品手册、技术规范。员工提问时，传统 RAG 经常检索到过时版本的制度文件，从而输出错误指引。部署 CRAG 后，系统会实时评估检索到的文档与问题的相关性，一旦发现文档质量差，自动触发 Web 搜索或重检索。即使内部知识库不完善，系统也能给出更可靠的答案。在这一场景中，RAG 系统开发者、AI 应用工程师直接受益，因为他们无需手工清洗全部语料，即可大幅提升问答准确率。

开放域问答则是 CRAG 展现弹性的舞台。用户问题千奇百怪，领域覆盖极广，任何单一知识库都无法全知全能。CRAG 的 Web 搜索兜底在这里大放异彩：当本地知识库无法回答时，系统自动切换外部搜索引擎，把问题扔给更广阔的互联网。这就像图书馆管理员对付“偏门冷知识”的终极策略——直接上网搜索。AI 平台架构师在设计面向公众的 AI 助手时，会优先考虑这种混合检索架构。

多跳推理任务是 CRAG 的另一个亮点。像“谁接替了乔布斯担任苹果 CEO？后来他又去了哪里？”这类问题，需要先找到第一个答案，再基于它做第二次检索。CRAG 的重检索机制天然支持这种链式推理：第一跳检索置信度不足时，系统会重写查询并重新检索，逐步建立完整的推理链路。算法工程师和提示词工程师在构建复杂推理 Agent 时，经常将 CRAG 作为核心检索模块。

无论哪种场景，CRAG 都指向同一个核心价值：在不可靠的世界里，建立一个可靠的问答系统。它承认检索可能失败，但通过纠错机制让失败不至于演变为错误的答案。

未来展望

故事讲到这里，质检员已经成了图书馆里不可或缺的角色。但未来的路还很长——CRAG 下一步会走向何方？

第一个方向是自反馈闭环。当前的 CRAG 依赖预设阈值来判断置信度，这些阈值是经验值，无法自适应不同领域的检索质量分布。未来的 CRAG 将引入自反馈机制：系统记录每次纠错的效果，并根据历史数据动态调整阈值和策略权重。这就像质检员积累经验后，自动调整自己的判断标准，而不是永远拿着入职时的那把尺子。这一方向的推动者主要是机器学习研究员和数据科学家。

第二个方向是多模态 CRAG。当前 CRAG 主要处理纯文本检索，但企业知识库中包含大量图片、表格、音视频资料。多模态 CRAG 需要评估器同时理解文本与图像的相关性，并在纠错策略中加入“多模态重检索”。例如，当用户询问“去年的营收趋势”时，系统不仅要找到相关文档，还要确保检索到的图表是真的行情数据，而不是过时的旧图。多模态算法工程师是这一方向的骨干力量。

第三个方向是轻量化评估器。当前评估器虽“轻量”，但仍需调用一个小型模型，在超大规模查询场景下仍有成本压力。未来研究者将探索更轻量的评估方案：基于规则的启发式评估、基于嵌入距离的近似打分、甚至用端侧小模型完成评估。这就像用一枚袖珍放大镜替代厚重的显微镜——成本更低、速度更快，虽然放大倍数有限，但对大多数场景已经足够。推理优化工程师和嵌入式 AI 工程师会在这个方向大展身手。

质检员的故事还在继续。从一把直尺到自适应判断，从只能看书到能看图听音，从笨重的仪器到口袋里的放大镜——CRAG 的未来，正朝着更智能、更全面、更轻盈的方向演进。而这一切的起点，不过是我们今天讲的“检索后质检”这个朴素想法。

CRAGfuture=CRAGcurrent+Self-Feedback⏟自适应+Multi-Modal⏟多模态+Lightweight Eval⏟轻量化\text{CRAG}_{\text{future}} = \text{CRAG}_{\text{current}} + \underbrace{\text{Self-Feedback}}_{\text{自适应}} + \underbrace{\text{Multi-Modal}}_{\text{多模态}} + \underbrace{\text{Lightweight Eval}}_{\text{轻量化}}
这个公式总结了 CRAG 未来演进的三大方向。它不是简单的叠加，而是意味着 CRAG 将变得更聪明（自反馈）、更全面（多模态）、更高效（轻量化）。每一个加号背后，都是一片值得探索的工程蓝海。
  1. 当前状态现有的 CRAG 基础框架。
    CRAGcurrent:Retrieve→Eval→Correct\text{CRAG}_{\text{current}}: \text{Retrieve} \rightarrow \text{Eval} \rightarrow \text{Correct}
  2. 自反馈让系统从历史纠错中学习。
    Self-Feedback: τ←arg⁡max⁡τE[Accuracy]\text{Self-Feedback: } \tau \leftarrow \arg\max_\tau \mathbb{E}[\text{Accuracy}]
  3. 多模态扩展评估器到多模态输入。
    Multi-Modal: Eval(dtext,dimage,daudio)\text{Multi-Modal: } \text{Eval}(d^{text}, d^{image}, d^{audio})
  4. 轻量化用极小模型完成评估任务。
    Lightweight: Evaltiny(d,q)≈Evallarge(d,q)\text{Lightweight: } \text{Eval}_{tiny}(d, q) \approx \text{Eval}_{large}(d, q)

AI 应用场景

企业智能客服系统升级

阶段：检索增强生成（RAG）管线优化

解决的问题：传统 RAG 客服系统无法判断检索到的知识库文档是否真的能回答用户问题，经常出现“答非所问”或“一本正经地胡说八道”。特别是在产品手册更新期间，过期文档被反复检索到，导致客服给出错误操作指南。CRAG 通过评估-纠错机制，让系统在文档质量差时自动切换重检索或外部搜索，将错误率大幅降低。

具体案例：某 SaaS 公司在工单系统中集成 CRAG 后，客服人员处理“API 接口报错”类问题时，系统不再只依赖命中率低的知识库，而是先评估本地文档质量。当置信度不足时自动查询官方论坛和最新文档，准确率从 62% 提升至 89%，一次性解决率提高近三成。

学术文献综述助手

阶段：检索评估与多轮检索

解决的问题：科研人员在撰写综述时，需要同时参考大量论文，但一次检索很难覆盖全部相关文献。CRAG 的不确定态重检索机制能自动分析缺失信息、改写检索词，帮助系统在多个知识源间迭代寻找文献，避免传统 RAG 只找到首轮结果就“罢工”的局限。

具体案例：某 AI 实验室内部文献助手使用 CRAG 后，面对“图神经网络在推荐系统的应用”这类宽泛问题，先通过本地论文库检索，评估发现文献覆盖不足后，自动触发 Web 搜索引擎补全最新 arXiv 论文，最终生成的综述包含的基础文献数量增加了 40%，且时新性更高。

Python 演示

python79 行
import random  class CorrectiveRAG:    """演示 Corrective RAG 核心路由逻辑的简化实现"""     def __init__(self, high_threshold=0.7, low_threshold=0.4):        self.high_threshold = high_threshold        self.low_threshold = low_threshold     def retrieve(self, query, doc_pool, top_k=3):        """模拟向量检索：从文档池中召回 top_k 篇文档"""        # 真实实现会使用 embedding 相似度检索        self.retrieved_docs = random.sample(doc_pool, top_k)        return self.retrieved_docs     def eval_documents(self, query):        """评估器：对每篇文档与查询的相关性打分（0-1）"""        # 真实实现会调用一个小型语言模型打分        self.relevance_scores = []        for doc in self.retrieved_docs:            # 模拟打分：与 query 共享关键词越多分数越高            overlap = len(set(query.split()) & set(doc.split()))            score = min(1.0, overlap / max(len(set(query.split())), 1))            self.relevance_scores.append(score)        return self.relevance_scores     def get_confidence(self):        """综合置信度：取平均分数作为整体置信度"""        self.confidence_score = sum(self.relevance_scores) / len(self.relevance_scores)        return self.confidence_score     def refine(self, query, docs):        """精炼策略：提取文档中与查询最相关的片段"""        # 真实实现会使用 LLM 抽取关键片段        return " ".join(docs)[:200] + " ... (精炼片段)"     def re_retrieve(self, query):        """重检索策略：重写查询后重新检索"""        rewritten = query + " more details"  # 真实实现会调用 LLM 改写        return self.retrieve(rewritten, self.doc_pool), rewritten     def web_search(self, query):        """Web 搜索兜底：从外部获取信息"""        # 真实实现会调用搜索 API        return f"[Web搜索结果] 关于{query}的最新信息"     def route(self, query, docs):        """路由核心：基于置信度决定纠错策略"""        self.eval_documents(query)        conf = self.get_confidence()        if conf >= self.high_threshold:            return "refine", self.refine(query, docs)        elif conf <= self.low_threshold:            return "web_search", self.web_search(query)        else:            return "re_retrieve", f"Rewrite and re-retrieve... {query}"     def run(self, query, doc_pool):        """执行 CRAG 全流程"""        self.doc_pool = doc_pool        self.query = query        docs = self.retrieve(query, doc_pool)        strategy, result = self.route(query, docs)        return {"strategy": strategy, "result": result, "confidence": self.confidence_score}  if __name__ == "__main__":    pool = [        "苹果公司在 1976 年创立 乔布斯是创始人之一",        "深度学习的核心是反向传播算法",        "上海市位于中国东部沿海地区 是中国最大的城市",        "推荐系统用于预测用户对物品的偏好",    ]    rag = CorrectiveRAG()    out = rag.run("苹果公司创始人是谁", pool)    print("策略:", out["strategy"])    print("置信度:", round(out["confidence"], 2))    print("结果:", out["result"])
目的：演示 CRAG 系统的核心路由逻辑——包含检索、评估、置信度判断和策略选择四大模块，展示如何根据文档质量自动决定精炼/重检索/Web搜索。
  1. self.high_threshold = high_threshold设置高置信度阈值（0.7），分数超过它则走精炼策略
  2. overlap = len(set(query.split()) & set(doc.split()))用关键词重叠模拟相关性打分，真实应用中这里会换成轻量级评分模型
  3. self.confidence_score = sum(...) / len(...)计算平均分作为整体置信度，是路由判断的依据
  4. if conf >= self.high_threshold:高置信度：直接精炼文档片段生成回答
  5. elif conf <= self.low_threshold:低置信度：触发 Web 搜索作为兜底方案
  6. else:不确定态：执行查询改写并触发重检索流程

常见误区

误区“传统 RAG 生成答案时用的语言模型很强大，即使检索结果一般，它也能凭借自身知识生成不错答案，所以 CRAG 加的那道检查程序显得多余。”

正解大模型的知识是有截止日期的，而知识库中的文档通常是企业私有或专业领域的，模型并没有“见过”这些内容。当检索结果质量差时，模型面对的是“无米之炊”，再强的生成能力也只能强行编造。CRAG 的价值正是在于拦截低质量检索结果，防止“幻觉”进入最终答案。实际评测中，CRAG 在知识库噪声较高的场景下对准确率的提升可达 20% 以上。

为何常见：初学者对 RAG 的认知停留在“检索 + 大模型”两个组件上，忽视了检索质量对生成质量的绝对约束。加上大模型本身能处理部分语义噪声，让人误以为检索差一点没关系。

误区“CRAG 的评估器听起来很高级，肯定要像训练一个 BERT 模型那样跑大量的标注数据、调参、微调，小团队根本做不了。”

正解CRAG 的评估器设计目标就是“轻量”。论文中使用的评估器可以基于通用 LLM 的零样本打分实现，也可以基于小模型做简单微调，甚至可以先用基于规则的关键词重叠、向量距离等启发式方法快速上线。真实工程中，很多团队用 GPT-3.5 级别的模型加几条 prompt 模板就实现了评估器，效果已经很不错。评估器的复杂度和精度可以根据场景灵活取舍。

为何常见：很多人把“评估”与“训练”画等号，认为任何模块都必须经过深度学习训练才算正规。实际操作中，工程上的“够用”往往比“最先进”更具现实意义。

误区“CRAG 里的 high_threshold 和 low_threshold 设置好之后，系统就能一直稳定运行，如果效果不好，那就调整一次再重启。”

正解阈值的合理性高度依赖知识库的数据分布。当知识库更新、用户提问分布漂移、检索器换用新 embedding 模型时，相关性分数的分布都会变化，原来的阈值可能失效。生产级的 CRAG 系统需要动态监控评估分数分布，定期校准阈值。更进阶的方案是让系统根据反馈自动调整阈值——这正是“自反馈闭环”方向的研究内容。

为何常见：阈值看似是一个参数，初学者容易把它当成“配置项”而不是“需要持续维护的系统状态”。忽略了数据分布的变化性。

误区“CRAG 的低置信度处理很简单，就是重写个 query 调一下 Google API 就完事了。”

正解真实生产环境远比这复杂。调用搜索 API 只是第一步，后续还要处理网页抓取（反爬、渲染）、正文提取（剥离导航和广告）、去重、相关性过滤、版权考量——这些环节无论哪一个出错，都会把“兜底”变成“挖坑”。实践中，Web 搜索结果进入生成器前至少要经过一轮清洗和相关性过滤，否则模型会把网页上的广告文本也当成参考资料。业界甚至有团队专门维护一个“搜索标准化清洗流水线”来支撑 CRAG 的 Web 分支。

为何常见：Web 搜索的入口太简单（一个 API 调用），让人们容易忽略入口背后的复杂生态。

面试题

Q1. Corrective RAG 的最核心创新点是什么？

单选题 · easy

  • A.引入向量检索技术
  • B.在检索后生成前增加评估纠错环节← 正确答案
  • C.使用更大的语言模型
  • D.用图数据库替代向量库

答案：B。CRAG 的核心是在检索与生成之间插入“评估-纠错”环节，让系统对检索结果进行质量把关后决定下一步策略。向量检索（A）是基础手段，并非 CRAG 独创；使用更大模型（C）与 CRAG 无关；图数据库（D）是另一条技术路线。就像质检员把关，才是 CRAG 的灵魂。

Q2. CRAG 评估器对文档与问题做的相关性打分为 0.2，此时系统最可能采取哪种策略？

单选题 · easy

  • A.精炼处理
  • B.直接生成
  • C.Web 搜索兜底← 正确答案
  • D.忽略问题

答案：C。0.2 属于典型的低置信度区间（通常低于 low_threshold）。系统会判定检索结果基本不可用，启动 Web 搜索兜底来获取外部信息。精炼处理（A）适用于高置信度场景，直接生成（B）是传统 RAG 的行为，而忽略问题（D）没有任何系统会这么做。

Q3. 在 CRAG 中“重检索”（Re-retrieve）策略的核心步骤是什么？

单选题 · mid

  • A.重新想一个问题
  • B.改写查询后重新在知识库中检索← 正确答案
  • C.丢弃所有旧文档
  • D.换个更大的知识库

答案：B。重检索的核心是查询改写（Query Rewrite）：分析当前检索结果缺失的信息，构造新的查询表达式，然后重新在知识库中检索。“重新想一个问题”（A）描述过于随意，“丢弃所有旧文档”（C）没有建设性，“换个更大的知识库”（D）成本极高且不精准。

Q4. CRAG 中置信度的“不确定态”对应的处理策略是哪个？

单选题 · mid

  • A.直接精炼
  • B.使用规则模板回答
  • C.触发重检索← 正确答案
  • D.拒绝回答

答案：C。不确定态（Uncertain）介于高置信度和低置信度之间，说明检索结果有一些参考价值但不够充分。系统会通过查询改写触发重检索，尝试从知识库中获取更多相关信息。直接精炼（A）是高置信度的策略；拒绝回答（D）不是 CRAG 设计目标。

Q5. 与标准 RAG 相比，CRAG 在架构上多出的关键组件是什么？

单选题 · mid

  • A.嵌入模型
  • B.重排序器
  • C.评估器和纠错路由器← 正确答案
  • D.向量数据库

答案：C。CRAG 是在标准 RAG 的检索与生成之间新增了评估器（打分）和纠错路由器（策略选择）两个组件。嵌入模型（A）和向量数据库（D）是标准 RAG 的基础组件；重排序器（B）是 Rerank 思路，不是 CRAG 特有。

Q6. 以下哪些属于 CRAG 定义的纠错策略？

多选题 · mid

  • A.精炼处理（Refine）← 正确答案
  • B.重检索（Re-retrieve）← 正确答案
  • C.模型微调
  • D.Web 搜索兜底← 正确答案

答案：ABD。CRAG 定义了三种纠错策略：精炼（高置信度）、重检索（不确定态）、Web 搜索（低置信度）。模型微调（C）是模型训练层面的手段，不属于 CRAG 检索纠错范畴，也不在 CRAG 流程内。

Q7. CRAG 的评估器与 Rerank 模型的主要区别是什么？

单选题 · hard

  • A.评估器更轻量
  • B.评估器的输出包含置信度信号，用于分流决策← 正确答案
  • C.Rerank 模型不支持神经网络
  • D.两者没有区别

答案：B。Rerank 模型的作用是把召回的多篇文档重新排序，输出顺序更合理的列表，但其输出仍是排序结果。CRAG 评估器输出的是相关性分数，并据此推导置信度、决定精炼/重检索/Web搜索的分流。如果非要说轻量，评估器通常也确实追求轻量，但这并非核心区别。评估器是“决策者”，Rerank 是“整理者”。

Q8. 关于 CRAG 的工程实现，以下说法正确的有哪些？

多选题 · hard

  • A.评估器可以用零样本方式调用通用 LLM 实现← 正确答案
  • B.置信度阈值需要随数据分布变化而动态调整← 正确答案
  • C.Web 搜索结果可以直接送入生成器无需清洗
  • D.CRAG 流程适合与 LangChain 等框架集成← 正确答案

答案：ABD。零样本 LLM 评估器是论文和工程中常见的轻量实现（A 对）。阈值依赖数据分布，需要动态监控校准（B 对）。Web 搜索结果含大量噪声，必须清洗过滤后才能使用（C 错）。CRAG 的模块化和函数式设计非常适合嵌入 LangChain 等现有框架（D 对）。

Q9. 以下哪个不是 CRAG 的优势？

单选题 · easy

  • A.提升对低质量检索结果的鲁棒性
  • B.减少 RAG 系统的幻觉现象
  • C.无需任何推理开销← 正确答案
  • D.在知识库覆盖不足时可用 Web 兜底

答案：C。CRAG 的评估器、路由判断都会带来额外的计算和延迟开销（C 错），这是选择 CRAG 时必须权衡的成本。A、B、D 都是 CRAG 的典型优势。CRAG 是一种用“推理开销换可靠性”的策略。

Q10. 在 CRAG 的自反馈闭环演进方向中，系统需要实现哪些关键能力？

多选题 · extreme

  • A.记录每次纠错的效果← 正确答案
  • B.自动调整置信度阈值← 正确答案
  • C.完全替代人工评估
  • D.根据历史数据优化策略权重← 正确答案

答案：ABD。自反馈闭环的核心是记录纠错效果（A）、动态调整阈值（B）和按历史表现优化策略权重（D）。“完全替代人工评估”（C）是过于极端的设想——反馈信号仍需人工标注或自动化指标来定义，评估体系不能完全脱离人的设计。