想象你是一家大型快递分拣中心的调度员。顾客（大语言模型）在等待他订的“知识包裹”，仓库拣货员（检索器）从货架（向量数据库）上取出文档片段，成批送上传送带。问题是：这些包裹真的可靠吗？有的包装完好、内容详实；有的新旧混杂、真假难辨；还有的干脆是错发件。如果不管三七二十一全塞给顾客，顾客极可能照着错误信息办事——这正是 RAG 系统“一本正经胡说八道”的根源。 CRAG（Corrective RAG，纠错式检索增强生成）就是加在分拣线上的一道质量闸口。闸口前的安检扫描仪（检索评估器）先给每批包裹打分，再由三色通道分流：绿灯放行、黄灯进入复核区拆包细查、红灯直接退回并转外部调货（Web 检索）。整篇文章围绕“扫描—分流—精修—调货—对比—上线”这套分拣体系展开。学完之后，你将能为自己的 RAG 应用装上这道纠错闸门，让大模型的每一次回答都有据可查、有错必纠。

岗位关联

掌握 CRAG，意味着你能为 RAG 系统加装自动质检与纠错机制，显著压低幻觉率和答非所问。这是大模型应用从“能跑”走向“可靠”的关键能力，也是 AI 应用开发者在生产环境中的核心加分项。

目录
  1. 可视化演示
  2. 检索评估器
  3. 三档纠错
  4. 知识精炼
  5. Web补充
  6. Self-RAG对比
  7. 系统实现
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示CRAG检索评估器评分、三档纠错分类策略与知识精炼Web检索补充的分级处理机制。

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

检索评估器评分机制 轻量级T5-small/BERT评估器对检索文档评分，推理延迟仅约8ms 评估器输出相关性分数，决定文档进入哪一档纠错策略 score = evaluator(query, doc) 检索评估是CRAG纠错的起点

检索评估器

快递分拣中心的第一道工序永远是安检。安检扫描仪不为包裹换内容，只判断“这批货靠不靠谱”，然后在传送带上贴一张质量标签。CRAG 的第一个组件——检索评估器（Retrieval Evaluator）就扮演这台扫描仪。

在技术实现上，检索评估器把用户问题 q 和检索回来的若干文档片段 D 拼成一段长文本，交给一个轻量级序列模型（CRAG 论文选用 T5-large）编码，再映射到三个类别：correct（质量好）、incorrect（质量差）、ambiguous（部分可用）。模型规模远小于生成答案的主模型，恰好适合当流水线上的“快速质检员”——每个问题都值得扫一遍，但不能让扫描拖慢整条线。

评估器输出的三类概率中，我们最关心“correct“那一类的概率，把它作为检索质量的置信度 score。Softmax 把三个原始打分归一化成和为 1 的概率分布，于是”质量合格”的占比越高，系统就越放心地把文档直接交给大模型：

扫描仪贴完标签，包裹顺着传送带流向岔路口——接下来是三色通道的舞台。

score(q,D)=ezcorezcor+ezamb+ezerr\text{score}(q, D) = \frac{e^{z_{\text{cor}}}}{e^{z_{\text{cor}}} + e^{z_{\text{amb}}} + e^{z_{\text{err}}}}
通俗地说：在所有三档可能性里，“合格”这一票占的份额越大，证据就越可信。
  1. 输入拼接把问题和每个检索文档用分隔符拼成长文本，让模型同时看到“问题与证据”的全貌。
    s=q⊕[SEP]⊕D1⊕D2⊕⋯⊕Dks = q \oplus [SEP] \oplus D_1 \oplus D_2 \oplus \cdots \oplus D_k
  2. 编码为向量T5 编码器把输入转成隐藏向量 h，浓缩了整段文本的语义信息。
    h=Encoder⁡(s)h = \operatorname{Encoder}(s)
  3. 线性三层映射一个线性层把 h 映射成三个原始分数 z，对应“正确 / 模糊 / 错误”三类。
    z=Wh+b,z∈R3z = W h + b, \quad z \in \mathbb{R}^{3}
  4. Softmax 归一化三个分数取指数后相除，得到“正确”类的概率，也就是最终置信度。
    score=ezcor∑kezk\text{score} = \frac{e^{z_{\text{cor}}}}{\sum_{k} e^{z_k}}

三档纠错

贴完标签的包裹在三色通道前会合。绿灯通道畅通无阻，包裹原样直送顾客；黄灯通道的包裹被推入复核区，由拆包员挑拣整理；红灯通道的包裹则被直接退回拣货员，同时向外部总仓发出调货请求。CRAG 的三档纠错策略，完全复刻了这套分拣逻辑。

两个阈值将置信度轴切成三段：高于高档阈值 τ₁ 判为“正确”，低于低档阈值 τ₂ 判为“错误”，中间统称“模糊”。三个区间对应三种动作：直接使用检索文档、先知识精炼再使用、放弃本地结果改用 Web 检索补充。阈值属于超参数，通常在一个验证集上根据回答准确率与检索成本来调优，而不是拍脑袋定。

用分段函数可以把整条决策规则浓缩成一个公式，这正是 CRAG 里“纠错”二字的全部含义：

三色通道各司其职，但“黄灯复核”具体怎么拆包挑拣，还需要一件趁手的工具——知识精炼。

action(q,D)={直接放行,score≥τ1知识精炼,τ2≤score<τ1Web 补充,score<τ2\text{action}(q, D) = \begin{cases}\text{直接放行}, & \text{score} \ge \tau_1 \\\text{知识精炼}, & \tau_2 \le \text{score} < \tau_1 \\\text{Web 补充}, & \text{score} < \tau_2\end{cases}
质量高就直接用，半信半疑就整理后再用，完全不可信就换一个来源。三档各管一段。
  1. 阈值确定两个阈值把置信度轴切成三段，数值在评测集上实验得出，经验值常取 0.7 与 0.4。
    τ1=0.7,τ2=0.4\tau_1 = 0.7, \quad \tau_2 = 0.4
  2. 绿灯放行分数不低于高档阈值，原始文档直接作为上下文进入生成器。
    score≥0.7⇒context=D\text{score} \ge 0.7 \Rightarrow \text{context} = D
  3. 黄灯精炼分数落在中间带，文档先送入知识精炼环节再使用。
    0.4≤score<0.7⇒context=refine⁡(D)0.4 \le \text{score} < 0.7 \Rightarrow \text{context} = \operatorname{refine}(D)
  4. 红灯调货分数跌破低档阈值，本地证据不可信，转而请求 Web 检索。
    score<0.4⇒context=Dfinal\text{score} < 0.4 \Rightarrow \text{context} = D_{\text{final}}

知识精炼

复核区的拆包员会把黄灯包裹拆开：里三层外三层的泡沫纸（噪声）扔进回收箱，破损的次品挑出去，完好的正品按发货清单重新码放装盒。知识精炼（Knowledge Refinement）做的正是这件事。

当一个批次的检索文档被判为“模糊”时，里面通常混着几段高度相关的内容和几段勉强沾边的内容。精炼的目标是：只保留与问题真正相关的片段，丢掉噪声，再合并成一段紧凑的上下文。CRAG 论文的做法更细致——用分解器把文档按知识行逐行切分，再逐行判断与问题的事件级相关性；工程上更通用的替代方案则是向量相似度过滤。

设 δ 为相关度阈值，精炼后的文档集合就是原集合中相似度达标的子集。这个公式把“拆包挑拣”翻译成了数学语言：

挑拣完毕的包裹重新出发。但如果红灯通道的调货指令已经发出，知识精炼就插不上手了——得靠外部总仓救急。

Drefined={d∈D∣sim⁡(d,q)≥δ}D_{\text{refined}} = \{ d \in D \mid \operatorname{sim}(d, q) \ge \delta \}
相似度低于阈值的片段一律淘汰，留下的都是能直接支撑回答的“干货”。
  1. 嵌入向量化把问题和每个候选片段分别编码成语义向量，这是算相似度的前提。
    vq=E(q),vd=E(d)v_q = E(q), \quad v_d = E(d)
  2. 余弦相似度两向量夹角的余弦值衡量语义接近程度，值域在 [-1, 1]，越大越相关。
    sim⁡(d,q)=vd⋅vq∥vd∥ ∥vq∥\operatorname{sim}(d, q) = \frac{v_d \cdot v_q}{\lVert v_d \rVert \, \lVert v_q \rVert}
  3. 阈值过滤保留下相似度达标（如大于 0.5）的片段，其余丢弃。
    d∈Drefined  ⟺  sim⁡(d,q)≥δ,δ=0.5d \in D_{\text{refined}} \iff \operatorname{sim}(d, q) \ge \delta, \quad \delta = 0.5
  4. 有序拼接把留下的片段按相关度从高到低排好，拼成一段精炼上下文。
    context=d(1)⊕d(2)⊕⋯\text{context} = d_{(1)} \oplus d_{(2)} \oplus \cdots

Web补充

红灯通道里被退回的包裹，意味着本地仓无货可发。分拣员拿起电话向外部总仓（Web 搜索引擎）调货：总仓发来大量散货，拆包员剥掉页面里的广告与导航，只留正文干货，再与本地还没扔的少数片段合并装箱。Web 检索补充就是这条外部调货热线。

触发的条件很明确：置信度跌破低档阈值。此时本地知识库给出的证据质量太差，再精炼也只是矮子里拔将军。系统把问题改写成适合搜索引擎的关键词查询，调用搜索 API，抓取返回页面并清洗正文，得到一批时效性强的新鲜资料——知识库永远跟不上世界变化，而 Web 能。

最终喂给生成器的上下文，是本地精炼结果与 Web 结果的并集，Web 片段通常附带来源链接以便追溯。合并公式简洁有力：

调货解决了“本地没货”的燃眉之急。但另一家快递公司发明了完全不同的质检思路——不检查包裹，而是让送货员送货时当场自查。

Dfinal=Drefined∪DwebD_{\text{final}} = D_{\text{refined}} \cup D_{\text{web}}
本地留一部分、外部补一部分，两边合起来就是最终证据包。调货不是替换，而是补充。
  1. 查询改写从原始问题里提取关键词，拼成搜索引擎友好的查询串。
    qweb=ExtractKeywords⁡(q)q_{\text{web}} = \operatorname{ExtractKeywords}(q)
  2. 搜索抓取调用搜索接口，得到候选网页集合。
    Rweb=SearchEngine⁡(qweb)R_{\text{web}} = \operatorname{SearchEngine}(q_{\text{web}})
  3. 正文清洗剥离网页里的广告、导航与脚本，留下干净正文。
    Dweb=Clean⁡(Rweb)D_{\text{web}} = \operatorname{Clean}(R_{\text{web}})
  4. 合并去重本地精炼结果与 Web 结果取并集，重复段落按来源优先级保留。
    Dfinal=Drefined∪DwebD_{\text{final}} = D_{\text{refined}} \cup D_{\text{web}}

Self-RAG对比

分拣中心的质检是“入库后、出库前”的集中扫描，而另一家快递公司 Self-RAG 的做法是：每个送货员送完货后当场填一张回执单，自问“这包裹真对得上订单吗？信息支持吗？对用户有用吗？”发现问题就当场补送或拦下。两种哲学各有优劣。

Self-RAG 在生成阶段让 LLM 输出一系列特殊令牌（reflection tokens），自评“检索到的文档是否与问题相关（Relevant）”“回答是否被文档支持（Supported）”“回答对用户是否有用（Useful）”。一旦发现不相关，模型可以主动再次检索；发现不支持，则修正自己的措辞。CRAG 不做生成时的自省，而是在生成之前就把检索结果里的问题解决掉——一个管输入，一个管输出。

Self-RAG 的核心是反射令牌里“相关性”的概率——模型在生成时对每个检索文档给出一个相关性判断，概率越高越敢放心引用：

两种质检思路并非水火不容——生产系统完全可以“出库前扫描”与“送货时自查”并用，把两者的优点叠满。

prel=P(Relevant∣q,d)p_{\text{rel}} = P(\text{Relevant} \mid q, d)
这个概率相当于送货员在回执单上勾选“这单货与订单匹配”的信心度，不匹配就触发补救措施。
  1. 反射令牌采样模型在生成时从三类令牌里输出一个，作为当前文档相关性的自评。
    tok∈{Relevant,Partially,Irrelevant}\text{tok} \in \{ \text{Relevant}, \text{Partially}, \text{Irrelevant} \}
  2. 相关性概率模型给出的条件概率，衡量文档与问题的契合程度。
    prel=P(Relevant∣q,d)p_{\text{rel}} = P(\text{Relevant} \mid q, d)
  3. 生成时修正Self-RAG 发现不相关时重新检索，直接干预生成输出。
    output←Regenerate⁡(q)\text{output} \gets \operatorname{Regenerate}(q)
  4. 与 CRAG 对照CRAG 在输入侧修证据，Self-RAG 在输出侧自省，二者时机互补。
    CRAG:修正输入→再生成;Self-RAG:生成中自省\text{CRAG}: \text{修正输入} \to \text{再生成}; \quad \text{Self-RAG}: \text{生成中自省}

系统实现

一台扫描仪、三条通道、一个复核台、一条调货热线——这些设备只有按顺序连成传送带，快递中心才算真正运转。CRAG 的系统实现同样是把检索、评估、分流、精炼、调货、生成六道工序串成一条流水线。

数据从用户问题出发：先进检索器拿候选文档，再过评估器打分，按阈值选择正确、精炼、Web 三条支路之一，最后把选定的上下文交给 LLM 生成答案。工程上还要操心瓶颈：评估器是上 GPU 还是 CPU 推理？Web 搜索的 API 配额与延迟怎么控制？阈值要不要随知识库更新定期重调？这些细节决定了 CRAG 是“加分项”还是“拖油瓶”。

整条流水线可抽象为“检索→纠错→生成”三段式，它是全文最浓缩的公式：

从安检扫描到三色分流，从拆包精炼到外部调货，再到与别人家质检法对比、整线组装——你的知识库里已经趴着一条完整的 CRAG 流水线。接下来看看它在真实工位上怎么干活。

A=LLM⁡(q, CRAG⁡(D))A = \operatorname{LLM}\left( q,\ \operatorname{CRAG}(D) \right)
回答的质量，既取决于生成器的本事，更取决于纠错器 CRAG 喂给它的证据靠不靠谱。
  1. 检索出库向量检索器根据问题取回候选文档集合。
    D=Retriever⁡(q)D = \operatorname{Retriever}(q)
  2. 纠错分流CRAG 依据置信度选一条支路，决定最终上下文。
    CRAG⁡(D)={D,score≥τ1Drefined,τ2≤score<τ1Dfinal,score<τ2\operatorname{CRAG}(D) = \begin{cases} D, & \text{score} \ge \tau_1 \\ D_{\text{refined}}, & \tau_2 \le \text{score} < \tau_1 \\ D_{\text{final}}, & \text{score} < \tau_2 \end{cases}
  3. 生成回答LLM 同时看到问题与纠错后的上下文，产出最终答案。
    A=LLM⁡(q,CRAG⁡(D))A = \operatorname{LLM}(q, \operatorname{CRAG}(D))
  4. 质量评估在评测集上统计正确回答占比，指导阈值与策略的迭代调优。
    Acc=NcorrectNtotal\text{Acc} = \frac{N_{\text{correct}}}{N_{\text{total}}}

AI 应用场景

企业知识库智能客服

阶段：部署与运维

解决的问题：客服机器人查产品手册回答问题，但手册版本混杂、部分条目过期。传统做法是把检索片段不分好坏全塞给大模型，答错了也无从知晓。CRAG 在中间加了一道评估闸口：低质量片段直接拦下转 Web 或转人工，回答可靠性显著提升。

具体案例：某 SaaS 公司把产品手册向量化后接入 CRAG，评估器为每批检索片段打分，模糊档触发知识精炼、错误档触发联网查最新公告。上线一个月，客服会话中“依据版本不符”的投诉下降约 40%。

金融研报问答

阶段：检索质量增强

解决的问题：研究报告时效性极强，本地知识库半年才更新一次，新政策一出库里的答案就过时。CRAG 在低置信度档自动调 Web 补充最新资讯，并对引用来源做标注，既保时效又保可追溯。

具体案例：投研平台对“今日美联储决议影响”这类问题，CRAG 评估本地研报置信度不足后，自动搜索权威财经网站，把最新决议原文纳入上下文，并在回答末尾附上来源链接，研究员核对成本大幅下降。

RAG 评测平台巡检

阶段：质量保障与回归测试

解决的问题：知识库内容漂移、向量化模型升级后，检索质量可能悄悄下滑。人工抽检成本高、覆盖低。CRAG 的策略统计（直接放行 / 精炼 / Web 调货的比例）本身就是知识库健康度的晴雨表。

具体案例：评测平台用 CRAG 流水线批量回放历史问题，统计三档触发率。当“Web 调货”占比连续一周上升时自动报警，提示某个领域的知识库已严重过期，运维再针对性补数据。

Python 演示

python86 行
"""CRAG 纠错流水线演示: 评估器打分 + 三档策略 + 知识精炼 (纯模拟)"""  class MockRetriever:    """模拟向量检索器: 按关键词返回带相关度分数的文档片段"""     def __init__(self):        self.corpus = {            "RAG": [                {"text": "检索增强生成用外部知识缓解幻觉。", "score": 0.92},                {"text": "RAG 流程包括检索、增强与生成三步。", "score": 0.85},                {"text": "知识库质量直接影响回答可靠性。", "score": 0.40},            ],            "LLM": [                {"text": "大语言模型通过海量文本预训练获得语言能力。", "score": 0.90},                {"text": "Transformer 架构是 LLM 的核心基础。", "score": 0.80},                {"text": "RLHF 让模型输出更符合人类偏好。", "score": 0.30},            ],        }     def retrieve(self, question, top_k=3):        key = "RAG" if "RAG" in question else ("LLM" if "LLM" in question else "UNKNOWN")        docs = self.corpus.get(key, [{"text": "本地过期的旧文档, 与问题无关。", "score": 0.20}])        return sorted(docs, key=lambda d: d["score"], reverse=True)[:top_k]  class MockEvaluator:    """模拟检索评估器: 把平均分映射成三档置信度"""     def score(self, question, docs):        avg = sum(d["score"] for d in docs) / len(docs)        if avg >= 0.7:            return 0.85        if avg >= 0.5:            return 0.55        return 0.30     def relevance(self, question, doc):        return doc["score"]  class CRAGPipeline:    """CRAG 主流程: 评估 -> 三档分流 -> 生成"""     def __init__(self, retriever, evaluator):        self.retriever = retriever        self.evaluator = evaluator        self.high_threshold = 0.7        self.low_threshold = 0.4        self.action_count = {"pass": 0, "refine": 0, "web": 0}     def refine(self, question, docs):        """知识精炼: 过滤掉弱相关片段并保留原序"""        kept = [d for d in docs if self.evaluator.relevance(question, d) >= 0.5]        return kept if kept else docs     def fallback_to_web(self, question):        """模拟 Web 检索补充: 返回一条外部来源记录"""        print("[Web检索] 本地知识不足, 向外部调货:", question)        return [{"text": "外部网页补充的最新时效资料。", "score": 0.60}]     def generate(self, question, docs):        context = " ".join(d["text"] for d in docs)        return context[:52] + "..."     def run(self, question):        docs = self.retriever.retrieve(question)        conf = self.evaluator.score(question, docs)        if conf >= self.high_threshold:            self.action_count["pass"] += 1            action, final_docs = "直接放行", docs        elif conf >= self.low_threshold:            self.action_count["refine"] += 1            action, final_docs = "知识精炼", self.refine(question, docs)        else:            self.action_count["web"] += 1            action, final_docs = "Web补充", self.fallback_to_web(question)        return action, self.generate(question, final_docs)  if __name__ == "__main__":    pipeline = CRAGPipeline(MockRetriever(), MockEvaluator())    for q in ["什么是RAG?", "LLM如何训练?", "今天的天气如何?"]:        action, answer = pipeline.run(q)        print("问题:", q, "| 策略:", action, "| 回答:", answer)    print("策略统计:", pipeline.action_count)
目的：用一个可运行的模拟器演示 CRAG 核心流程——评估器打分、三档分流、知识精炼与 Web 兜底。三个测试问题分别命中“直接放行 / 知识精炼 / Web补充”三条路径。
  1. key = "RAG" if "RAG" in question else ("LLM" if "LLM" in question else "UNKNOWN")模拟检索器按关键词选择不同知识库，返回带相关度分数的文档
  2. avg = sum(d["score"] for d in docs) / len(docs)把片段平均相关度当作评估器打分依据，对应置信度计算
  3. if conf >= self.high_threshold:第一档判断：质量足够高，原始文档直接放行进生成器
  4. elif conf >= self.low_threshold:第二档判断：落入模糊带，先精炼再使用
  5. kept = [d for d in docs if self.evaluator.relevance(question, d) >= 0.5]知识精炼核心：过滤掉相关度低于 0.5 的弱相关片段
  6. self.action_count["web"] += 1第三档触发 Web 调货，并记录次数用于成本与健康度监控
  7. pipeline = CRAGPipeline(MockRetriever(), MockEvaluator())把检索器与评估器注入流水线，完成系统组装

常见误区

误区加了 CRAG 之后，检索质量有人把关，幻觉应该彻底消失了，可为什么还是偶尔答错？是不是我配置得不对？

正解CRAG 把关的是“证据质量”而非“答案生成”。即便检索回来的文档全部正确，LLM 在生成时仍可能过度泛化或表述失真。它把错误率压低了，但不是降为零。想要更低，通常要把它和 Self-RAG、输出校验、拦截策略叠加使用。

为何常见：“自动纠错”听起来像终结方案，让人误以为一个组件能包治百病，忽略了生成环节同样存在风险。

误区评估器给分不高？别犹豫，马上调搜索引擎补资料，越快越好。

正解只有“错误”档（低于低档阈值）才触发 Web；“模糊”档应当先走知识精炼。每次 Web 搜索都有延迟与成本，无脑调货会让系统变慢变贵，还会引入新的噪声。

为何常见：把三档想成了“好 / 坏”两档，忽略了中间那片最值得精修的灰色地带。

误区名字都带 RAG，功能都是纠错，CRAG 和 Self-RAG 应该是一回事吧？

正解CRAG 在检索之后、生成之前修正输入证据；Self-RAG 在生成过程中输出反思令牌、动态自省。二者纠错的时机完全不同，一个管输入侧、一个管输出侧，而且可以组合使用。

为何常见：都叫“纠错”，让人下意识归为一类，忽略了“什么时候纠”这个关键差异。

误区打分当然越准越好，评估器直接用 GPT-4 级别的大模型，效果肯定碾压 T5。

正解评估器要为每一个问题都跑一遍推理，用大模型会把延迟和成本放大一个数量级。CRAG 论文验证了 T5-large 这类轻量模型的打分已足够支撑三档决策，省下的预算留给生成器才是正解。

为何常见：把“效果”简单等同于“模型大小”，忽视了流水线对延迟和成本的敏感度。

误区精炼嘛，就是让大模型把检索文档改写、润色得更好读。

正解精炼的核心是切分、过滤、去重与重排，它不改变内容的实质。CRAG 的精炼器按知识行切分，逐行评估相关性后保留原文，而不是转述改写——任何改写都可能引入新的错误。

为何常见：“精炼”这个词容易让人联想到“提炼重写”，而它实际做的是“挑选与归置”。

面试题

Q1. CRAG 中“检索评估器”的主要职责是什么？

单选题 · easy

  • A.把检索结果重新排序
  • B.判断检索质量三档← 正确答案
  • C.直接生成最终答案
  • D.训练向量检索模型

答案：B。检索评估器给检索文档打出“正确 / 模糊 / 错误”三档判断，相当于快递安检员判断包裹质量，并不会重新排序、生成答案或训练模型。

Q2. CRAG 论文中评估器通常基于哪个轻量模型？

单选题 · easy

  • A.T5-large← 正确答案
  • B.GPT-4o
  • C.LLaMA-70B
  • D.CLIP

答案：A。CRAG 选用 T5-large 作为轻量评估模型，因为它足够快、成本低，能胜任三分类打分任务，而 GPT-4o 与 LLaMA-70B 体量太大，CLIP 面向图文而非文本检索评估。

Q3. 置信度落入“模糊”档时，CRAG 采用什么处理？

单选题 · mid

  • A.直接拒绝回答
  • B.知识精炼后再用← 正确答案
  • C.无条件触发 Web
  • D.原样使用检索文档

答案：B。模糊档对应 τ₂ ≤ score < τ₁，系统进入知识精炼，过滤弱相关片段后再交给生成器。“直接拒绝”属于拦截策略，“无条件 Web”只在低档触发，“原样使用”是高档动作。

Q4. 知识精炼的核心目标是什么？

单选题 · mid

  • A.扩充知识库容量
  • B.过滤弱相关噪声← 正确答案
  • C.压缩向量维度
  • D.提升检索速度

答案：B。知识精炼相当于拆包挑拣，按相关度过滤掉噪声片段、去重并重排。它不扩充知识库、不压缩向量、不优化检索速度，只保证进生成器的证据更干净。

Q5. CRAG 触发 Web 检索补充的条件是什么？

单选题 · mid

  • A.置信度高于高档阈值
  • B.置信度落入两档之间
  • C.置信度低于低档阈值← 正确答案
  • D.用户明确要求联网

答案：C。只有置信度跌破低档阈值（score < τ₂），判定本地证据质量差，才会调 Web 调货。高档直接放行，中档先精炼，与用户是否要求联网无关。

Q6. 与 Self-RAG 相比，CRAG 的纠错发生在哪个环节？

单选题 · hard

  • A.生成阶段的采样
  • B.检索之后的输入侧← 正确答案
  • C.训练之前的预处理
  • D.微调过程中的损失

答案：B。CRAG 在检索后、生成前修正输入证据；Self-RAG 则在生成阶段通过反射令牌自省并修正输出。二者恰好一个在输入侧、一个在输出侧。

Q7. 三档策略中“正确”档的处理方式是什么？

单选题 · easy

  • A.直接使用原文档← 正确答案
  • B.全部推倒重检
  • C.强制改写查询
  • D.回退到纯生成

答案：A。置信度不低于高档阈值时，说明检索质量值得信任，原始文档直接作为上下文进入生成器，不做额外加工，与绿灯通道放行同理。

Q8. 下列哪些属于知识精炼的操作？

多选题 · mid

  • A.按相关度过滤片段← 正确答案
  • B.对片段去重合并← 正确答案
  • C.重新训练检索模型
  • D.过滤噪声信息← 正确答案

答案：ABD。知识精炼包含按相关度过滤、去重合并、过滤噪声，属于推理时的上下文整理。重新训练检索模型属于离线优化，与精炼这一环节无关。

Q9. 关于 CRAG 系统实现的描述，正确的有哪些？

多选题 · hard

  • A.低置信度才触发 Web← 正确答案
  • B.阈值需要离线调优← 正确答案
  • C.评估器必须用大模型
  • D.可统计策略触发率← 正确答案

答案：ABD。CRAG 只在低置信度档触发 Web 检索以控制成本；阈值是超参数，需在验证集上调优；三种策略的触发率可作为知识库健康度指标。评估器用轻量模型即可，不必上大模型。

Q10. CRAG 能提升 RAG 可靠性的原因有哪些？

多选题 · mid

  • A.拦截错误检索结果← 正确答案
  • B.对模糊结果精炼← 正确答案
  • C.用 Web 弥补知识缺失← 正确答案
  • D.扩大训练数据规模

答案：ABC。CRAG 通过三档策略拦截错误证据、精炼模糊证据、用 Web 补充知识盲区，从输入侧保证证据质量。它并不改变模型训练数据的规模，因此 D 不正确。