纠错式RAG（CRAG）实战：构建会自我校验的合规研究助手

普通RAG的致命问题：自信地给出错误答案

大多数RAG聊天机器人有一个共同的毛病——它们会自信地把检索到的任何内容直接抛给你，哪怕这些内容毫不相关，甚至完全错误。在闲聊场景下，这或许只是一个小瑕疵；但在合规（Compliance）领域，一个错误的检索结果可能直接演变成真实的监管风险与法律敞口。

开发者 Saurabh Kamal 在其分享中，围绕这个痛点构建了一个名为 Veltra Pay Compliance Assistant 的合规助手，核心思路是引入 Corrective RAG（纠错式 RAG，简称 CRAG） 与自我校正机制，让系统在把答案交给用户之前，先对自己的工作做一次严格的自查。

什么是 Corrective RAG（CRAG）

传统 RAG 的流程是线性的：检索文档 → 拼接上下文 → 生成答案。这个链条最大的隐患在于——它默认了「检索到的内容一定有用」这个前提。一旦向量检索召回了不相关的片段，模型往往仍会硬着头皮生成一个看似合理的答案，这正是幻觉（hallucination）的温床。

CRAG 的改进在于给检索环节加上了一道「质检关卡」。系统会用 LLM 对每一个召回的文档进行打分，判断它究竟是 相关（relevant） 还是 不相关（irrelevant）。当检索质量偏弱、相关文档不足时，系统不会将就着回答，而是主动重写搜索查询（query rewriting），换一种问法重新去检索，直到拿到足够可靠的证据。

这种「先评估、再决定」的思路，把 RAG 从一个被动的管道，变成了一个懂得判断信息质量的主动系统。

CRAG 的概念最早由 Yan 等人在 2024 年的论文《Corrective Retrieval Augmented Generation》中正式提出。其核心创新是引入一个轻量级的「检索评估器（retrieval evaluator）」，将每个召回文档的相关性量化为置信分数，并据此将文档归入三类处理路径：分数高则直接采用，分数低则完全丢弃并触发网络搜索，分数居中则做知识精炼（knowledge refinement）后再使用。这与传统 RAG「有什么用什么」的被动做法形成鲜明对比。值得注意的是，查询重写（query rewriting）在 CRAG 中不只是换个说法重搜一遍，而是让 LLM 将原始问题分解为若干更精确的子查询，分别检索后再合并，从而大幅降低「词汇鸿沟」（vocabulary mismatch）导致的召回失败。

自我校正 Agent：生成之后还要再验证一遍

如果说 CRAG 解决的是「检索够不够好」的问题，那么这个项目的另一层设计——Self-Correcting RAG Agent（自我校正 RAG 智能体）——解决的则是「生成的答案靠不靠谱」的问题。

在答案生成之后，Agent 会针对以下几个维度对自己的输出进行校验：

• Grounding（依据性）：答案是否真正建立在检索到的源文档之上，而非模型自己的臆测；
• Hallucination risk（幻觉风险）：输出中是否存在源材料无法支撑的内容；
• Completeness（完整性）：答案是否完整覆盖了用户的问题；
• Retrieval sufficiency（检索充分性）：现有证据是否足以支撑这个回答。

更关键的是它的行为逻辑：当校验失败时，系统会自动重试（retry）；而当它确实无法从源材料中找到答案时，会诚实地回答「我不知道（I don't know）」，而不是编造一个答案糊弄用户。在合规场景里，这种「宁可不答，也不乱答」的克制，往往比多回答几句更有价值。

技术栈拆解：LangGraph 撑起可控的重试循环

从工程实现看，这个项目的技术选型颇具代表性，也反映了当下 Agent 应用的主流做法：

• LangGraph：作为整个流程的编排核心，通过 StateGraph 定义节点（nodes）、条件边（conditional edges）以及有界重试循环（bounded retry loops）。有界重试尤为重要——它避免了 Agent 陷入无限循环，为自我修正设定了明确的上限。
• Qdrant：作为向量数据库，负责存储与检索文档向量。
• PDF 摄取与切分：使用 pdfplumber 进行 PDF 解析，并采用**带重叠的分块（overlapping chunks）**策略，以尽量保留上下文的连贯性。
• LLM 驱动的三大环节：文档打分、查询重写、答案验证均由大模型完成。
• 流式后端：通过 Server-Sent Events（SSE）向前端实时推送管道进度。
• Web 仪表盘：对整个 CRAG 流程进行实时可视化。

其中 SSE 流式推送加上可视化仪表盘的设计值得一提。它让原本是「黑盒」的 RAG 内部流程——什么时候在打分、什么时候触发了重写、哪一步失败重试——都变得可观测。对于合规这类需要审计与可解释性的场景，这种透明度本身就是一项刚需。

LangGraph 是 LangChain 团队推出的图结构 Agent 编排框架，与传统链式（chain）编排的关键区别在于它支持有状态的循环（stateful cycles）。在普通 LangChain 管道中，执行流是单向的 DAG（有向无环图），无法原生表达「失败后回到某个节点重试」的逻辑；而 LangGraph 的 StateGraph 允许节点之间存在条件回边（conditional back-edges），这正是实现自我校正重试循环的基础。所谓「有界重试」，是指在 StateGraph 的状态对象中维护一个重试计数器，每次进入重试节点时递增，当计数超过预设阈值（如 3 次）时，条件边会将流程导向「返回 I don't know」的终止节点，而非继续循环，从而在容错性与防止无限递归之间取得平衡。这一设计模式对于任何需要自适应重试的 Agent 应用都具有通用参考价值。

Qdrant 作为向量数据库，支持在内存模式与持久化模式间切换，适合从原型到生产的平滑迁移。带重叠的分块策略（overlapping chunks）通常设置 10%–20% 的重叠率，其目的是确保跨块边界的语义单元（如一个完整的监管条款）不会因为被切割在两个 chunk 的末尾而导致任意一个 chunk 的语义残缺，从而影响向量召回的准确性。

对开发者的启示

这个项目的价值不仅在于它是一个可运行的合规助手，更在于它示范了如何把「可靠性」当作一等公民来设计 RAG 系统。普通 RAG 追求的是「能回答」，而 CRAG 与自我校正 Agent 追求的是「负责任地回答」。

对于任何将 RAG 落地到金融、医疗、法律等高风险领域的团队来说，文档打分、查询重写、答案验证、有界重试、以及诚实说「不知道」这套组合拳，都值得作为工程模板参考。作者已将完整代码开源在 GitHub，并配有 YouTube 视频讲解，感兴趣的开发者可以据此复现整个管道。

需要说明的是，本文基于开发者在 Reddit 的单一来源分享整理，具体效果与性能表现建议结合其开源仓库与视频亲自验证。