AI 大模型故障：大模型幻觉的工程压制：RAG 溯源、强制引用、输出校验三板斧

一、幻觉的本质：从"概率鹦鹉"到"证据约束"

1.1 幻觉不是bug，而是生成范式的必然产物

要压制幻觉，先得理解它从哪来。LLM 的核心机制是"下一个 token 的概率预测"：给定上下文，模型输出一个词表上的概率分布，采样得到下一个词。这个机制在语言流畅性上极其强大，但它没有任何内置的"事实真值"约束——模型优化的目标是"像人一样说话"，而不是"说真话"。

2020年，Merrill 等人在论文《Sparse, Dense, and Attentional Representations for Text Retrieval》中系统讨论了检索与生成的表示差异；而真正把"幻觉"作为独立研究对象的是 2022 年 Ji 等人的综述《Survey of Hallucination in Natural Language Generation》（ACM Computing Surveys），它将幻觉分为内在幻觉（与输入矛盾）和外在幻觉（无法从输入验证）两类。本文评述：这个二分法至今仍是工程界最实用的分类框架，因为它直接对应两种不同的压制策略——内在幻觉靠"忠实性校验"，外在幻觉靠"外部证据检索"。

从信息论角度看，幻觉可以理解为模型在"低置信度区域"的过度自信输出。当训练数据中某类事实稀疏，或问题超出训练分布时，模型仍会以高概率生成看似合理的答案。这正是"流畅性"与"真实性"解耦的根源。

1.2 幻觉的三层成因：数据、训练、解码

工程实践中，笔者倾向于把幻觉成因拆成三层，便于对症下药：

本文评述：三层成因对应三种干预时机——数据层是"事前"，训练层是"事中"，解码层是"事后"。三板斧中的 RAG 溯源主要作用于数据层与推理时，强制引用作用于生成约束，输出校验则覆盖解码层与事后验证。理解这个映射，是设计完整方案的前提。

1.3 为什么"证据闭环"是正确的主线

市面上关于幻觉治理的文章，多按技术点罗列：RAG 怎么做、引用怎么加、校验怎么跑。但笔者在实践中发现，单点技术很容易被"绕过"——检索到了但没用、引用了但引错、校验了但漏检。真正稳定的方案，是把"证据"作为贯穿全链路的约束对象，形成闭环：

证据闭环 = 检索（找到证据）→ 约束（只能用证据）→ 验证（检查是否真用了证据）→ 反馈（把失败案例回流到检索与提示）

这条主线的好处是：它把幻觉治理从"模型能力问题"转化为"系统工程问题"，让每一环都有明确的输入、输出和度量指标。下文的三板斧，正是这条主线上的三个关键节点。

二、第一板斧：RAG 溯源——让答案有据可查

2.1 RAG 的基本原理与溯源诉求

检索增强生成（Retrieval-Augmented Generation, RAG）由 Lewis 等人于 2020 年在 NeurIPS 论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》中提出。其核心思想是：在生成前，先从外部知识库检索相关文档片段，把它们拼进上下文，让模型"看着材料答题"。

但标准 RAG 只解决了"给材料"，没解决"溯源"——模型可能用了材料，也可能没用，甚至可能张冠李戴。溯源（provenance/attribution）要求的是：输出的每一句关键结论，都能定位到具体的来源片段。这是从"RAG"到"可归因 RAG"（Attributable RAG）的升级。

2023年，Gao 等人发布的综述《Retrieval-Augmented Generation for Large Language Models: A Survey》系统梳理了 RAG 的演进：从 Naive RAG（简单检索-拼接）到 Advanced RAG（优化检索与重排）再到 Modular RAG（模块化可组合）。本文评述：溯源能力正是 Modular RAG 阶段的核心诉求，它要求检索模块输出的不只是文本，还有"可追溯的元数据"（来源、位置、时间戳）。

2.2 溯源型 RAG 的工程架构

一个可溯源的 RAG 系统，需要在标准架构上增加三个关键设计。笔者结合工程实践，给出如下分层架构：

【数据层】文档解析 → 分块(Chunking) → 元数据注入 → 向量化 → 索引
                ↓
【检索层】查询改写 → 混合检索(向量+BM25) → 重排(Rerank) → 证据打包
                ↓
【生成层】证据注入 → 约束提示 → 生成 → 引用标注
                ↓
【溯源层】引用解析 → 来源映射 → 置信度打分 → 溯源报告

其中，元数据注入是溯源的基础。每个 chunk 必须携带：文档 ID、标题、章节路径、页码/字符偏移、更新时间、来源 URL。这些元数据在检索时随证据一起返回，在生成时用于标注引用。

证据打包是另一个易被忽视的环节。检索到的 top-k 片段不能简单拼接，而要带上编号（如 [1][2][3]），并在提示中明确要求模型"引用编号"。这一步是强制引用的前置条件。

2.3 分块策略：溯源精度的隐形决定因素

很多团队把精力花在向量模型选型上，却忽视了分块（chunking）策略。但笔者认为，分块粒度直接决定溯源精度：块太大，引用指向模糊；块太小，语义不完整。

本文评述：父子分块（Parent-Child Chunking）是当前工程界性价比较高的方案——用小块做检索保证召回精度，用父块做上下文保证语义完整，引用时指向父块中的具体句子。LangChain、LlamaIndex 等框架均已支持该模式。

2.4 检索质量：溯源的上游瓶颈

检索不到，溯源无从谈起。检索质量取决于三个环节：查询理解、召回、重排。

查询改写（Query Rewriting）：用户问题往往口语化、含指代。工程上常用 HyDE（Hypothetical Document Embeddings，Gao 等人 2022 年提出）——先让模型生成一个"假想答案"，再用它去检索。本文评述：HyDE 对短查询效果显著，但会引入额外延迟，需权衡。

混合检索：向量检索擅长语义，BM25 擅长关键词。两者融合（如 RRF 倒数排名融合）能显著提升召回。2024年，多家云厂商的 RAG 服务已默认采用混合检索。

重排（Rerank）：用交叉编码器（Cross-Encoder）对候选片段精排。Cohere Rerank、BGE-Reranker 等模型在中文场景表现良好。重排是提升溯源精度的关键一步，但会增加延迟。

2.5 溯源型 RAG 的失败模式清单

工程落地中，笔者总结了溯源型 RAG 的六类典型失败：

1. 检索空返回：知识库无相关内容，模型仍强行作答。对策：设置相似度阈值，低于阈值时明确回复"未找到依据"。
2. 检索到但未使用：模型忽略证据，凭参数记忆作答。对策：强制引用 + 输出校验。
3. 张冠李戴：引用了错误片段。对策：引用后做归因校验（见第四节）。
4. 分块割裂：关键信息被切断。对策：父子分块 + 重叠窗口。
5. 元数据丢失：无法定位来源。对策：入库时强制注入元数据。
6. 过时信息：检索到旧版本。对策：时间加权 + 版本过滤。

本文评述：这六类失败中，第1、2类最常见，也最致命。很多团队上线 RAG 后感觉"效果一般"，往往就是这两类问题在作祟。建议在监控中单独统计"空返回率"和"未引用率"。

拓展学习：LangChain 官方 RAG 教程（https://python.langchain.com/docs/tutorials/rag/）与 LlamaIndex 的溯源文档（https://docs.llamaindex.ai/）提供了可运行的代码示例，适合动手实践。

三、第二板斧：强制引用——把"引用"变成硬约束

3.1 为什么"提示模型引用"往往无效

最朴素的做法是在提示里写"请引用来源"。但工程实践表明，仅靠提示的引用约束非常脆弱：模型可能忘记引用、引用格式错误、引用不存在的编号，甚至编造来源。原因在于，引用对模型而言只是"文本模式"，不是"硬约束"。

2023年，斯坦福等机构的研究者在《Enabling Large Language Models to Generate Text with Citations》中提出 ALCE 基准，系统评估了 LLM 的引用生成能力。结果显示：即使是最强的模型，在"引用正确性"和"引用完整性"上仍有明显短板。本文评述：这说明强制引用不能只靠提示工程，必须结合解码约束与后处理校验。

3.2 强制引用的三个层次

笔者把强制引用分为三个由弱到强的层次：

3.3 L2：结构化输出让引用可解析

结构化输出是工程上性价比最高的方案。通过 JSON Schema 或函数调用（Function Calling），强制模型按固定格式返回，例如：

{
  "answer": "根据[1]，RAG 由 Lewis 等人于 2020 年提出。",
  "citations": [
    {"id": 1, "source": "Lewis et al., NeurIPS 2020", "quote": "..."}
  ],
  "confidence": 0.85
}

这种格式的好处是：引用可被程序解析、可校验、可展示。OpenAI 的 Structured Outputs、Anthropic 的 Tool Use、以及开源框架 Outlines、Guidance 都支持类似能力。本文评述：结构化输出把"引用"从自然语言变成了"数据字段"，这是从"软约束"到"硬约束"的关键一步。

3.4 L3：受限解码的工程实现

受限解码（Constrained Decoding）在 token 采样阶段就限制输出空间。例如，要求模型在生成引用时只能输出检索到的编号集合 {1,2,3}，其他 token 概率置零。这能从根本上杜绝"编造引用编号"。

实现上，可用有限状态机（FSM）或正则语法引导解码。开源库 Outlines（https://github.com/dottxt-ai/outlines）和 Guidance（https://github.com/guidance-ai/guidance）提供了成熟实现。本文评述：受限解码的代价是可能损害生成流畅性，且对复杂格式支持有限，建议在"引用编号"这类强约束字段上使用，而非全句约束。

3.5 引用粒度：句级还是段级

引用粒度直接影响可验证性。段级引用（一段话一个来源）实现简单，但精度低；句级引用（每句一个来源）精度高，但对模型要求高。

2024年，研究者提出"细粒度归因"（Fine-grained Attribution）方向，要求模型在句子级别标注来源。笔者建议：高风险场景用句级，通用问答用段级，并在提示中明确"每句结论后必须跟引用编号"。

3.6 强制引用的常见反模式

1. 引用堆砌：一句话挂五个引用，实际只用了一个。对策：限制每句引用数量，做归因校验。
2. 形式引用：引用了但内容无关。对策：引用后做语义相似度校验。
3. 引用幻觉：编造不存在的来源。对策：受限解码 + 来源白名单。
4. 忽略冲突：多个来源矛盾时不做说明。对策：提示中要求"如来源冲突，需明确指出"。

本文评述：反模式1和2在长文档问答中最常见。建议在输出校验环节加入"引用-内容一致性"检查，把形式引用筛出来。

四、第三板斧：输出校验——给生成结果装上"质检线"

4.1 输出校验的定位：最后一道防线

前两板斧是"事前约束"，输出校验是"事后验证"。它不改变生成过程，而是对生成结果做独立检查，发现问题则拦截、重试或降级。这是证据闭环的最后一环，也是把"不可靠生成"转化为"可控输出"的关键。

2023年，Manakul 等人提出 SelfCheckGPT（EMNLP 2023），核心思想是：对同一问题多次采样，若答案高度一致则置信度高，若发散则可能存在幻觉。这是"自一致性校验"的代表工作。本文评述：SelfCheckGPT 无需外部知识库，适合作为通用兜底，但计算成本随采样次数线性增长，需权衡。

4.2 四类校验方法

4.3 归因校验：把"引用"验成"真引用"

归因校验（Attribution Verification）是证据闭环的核心环节。它要回答：引用的来源，是否真的支持这句话的结论？

工程实现上，常用自然语言推理（NLI）模型判断"证据→结论"的蕴含关系。若为"蕴含"则通过，若为"矛盾"或"中立"则标记。2024年，研究者进一步提出用 LLM 自身做归因判断（LLM-as-Judge），在多个基准上表现优于小模型。本文评述：LLM-as-Judge 成本较高，建议用于高风险场景或抽样校验；大规模场景可用蒸馏后的小模型。

4.4 事实核查：FactScore 与检索验证

2023年，Min 等人提出 FactScore（EMNLP 2023），把长文本拆成原子事实（atomic facts），逐条核查。其流程是：拆解→检索→判断→打分。FactScore 已成为评估生成事实性的重要基准。

工程上，事实核查可与 RAG 复用同一检索链路：把生成的原子事实作为查询，检索知识库，判断是否支持。本文评述：FactScore 的拆解步骤本身可能引入误差，且计算成本高，适合离线评估而非在线拦截。

4.5 校验后的处置策略

校验发现问题后，不能简单丢弃，而要有分级处置：

1. 重试：调整提示或检索，重新生成（适合偶发失败）。
2. 降级：返回"未找到可靠依据"，而非编造（适合检索空返回）。
3. 标注：输出但标注低置信度，提示用户核实（适合中等风险）。
4. 拦截：直接拒绝输出（适合高风险、强合规场景）。

本文评述：处置策略要与业务风险等级绑定。医疗、金融建议"拦截+人工复核"，通用问答可"标注+提示"。切忌一刀切。

五、三板斧的协同：证据闭环的工程落地

5.1 完整链路设计

把三板斧串起来，就得到一条完整的证据闭环链路。笔者给出一个可落地的参考架构：

用户提问
  ↓
[查询理解] 改写 + 意图识别
  ↓
[检索] 混合检索 → 重排 → 证据打包(带编号)
  ↓
[生成] 约束提示 + 结构化输出(强制引用)
  ↓
[校验] 归因校验 + 自一致性 + 规则检查
  ↓
[处置] 通过→输出 / 失败→重试或降级
  ↓
[反馈] 失败案例回流 → 优化检索与提示

这条链路的关键在于反馈回流：每次校验失败都是宝贵的训练信号。把失败案例分类（检索失败/引用失败/生成失败），针对性优化，才能让系统持续进化。

5.2 关键工程参数与调优

本文评述：这些参数没有"万能值"，必须结合业务数据调优。建议先在小流量上做 A/B，用评估指标（见第六节）指导调参。

5.3 成本与延迟的权衡

三板斧都会增加成本与延迟：RAG 增加检索开销，强制引用增加输出长度，输出校验增加额外推理。工程上必须做权衡。

笔者的建议是分级策略：低风险场景只做 L1 提示约束 + 轻量校验；中风险加结构化输出 + 归因校验；高风险全量三板斧 + 人工复核。这样能在保证效果的同时控制成本。

六、评估体系：如何度量幻觉压制效果

6.1 核心指标

没有度量就没有优化。幻觉压制的评估，需覆盖"事实性"和"归因性"两个维度：

6.2 公开基准

国内外已有多个幻觉评估基准：

• HaluEval（2023）：通用幻觉评估集，含问答、对话、摘要任务。
• TruthfulQA（2021）：测试模型是否复述常见误解。
• ALCE（2023）：评估带引用生成的质量。
• RAGAS（2023）：RAG 系统专用评估框架，含忠实度、答案相关性等指标。
• CRUD-RAG（2024）：中文 RAG 基准，覆盖多任务。

本文评述：RAGAS 是工程落地最实用的框架，它把评估拆成"检索质量"和"生成质量"两部分，便于定位问题。建议团队自建业务测试集，同时参考公开基准。

6.3 数据集预处理说明

以 RAGAS 为例，其评估数据通常需如下预处理：

1. 清洗：去除 HTML 标签、乱码、重复段落。
2. 分块：按语义分块，保留元数据。
3. 标注：人工标注"标准答案"与"支撑证据"。
4. 划分：按 7:2:1 划分训练/验证/测试，避免泄漏。
5. 脱敏：去除个人隐私信息，符合合规要求。

本文评述：评估集的质量决定评估结论的可信度。建议至少 200 条业务真实问题，覆盖高频与长尾场景。

七、前沿预判：2025年后的技术走向

7.1 检索-生成联合训练

当前 RAG 多为"检索器+生成器"分离训练。前沿方向是联合训练，让检索器学习"生成器需要什么"，生成器学习"如何利用检索结果"。2024年，REPLUG、Self-RAG 等工作在此方向取得进展。Self-RAG（Asai 等人，2023）引入"反思 token"，让模型自主决定何时检索、何时引用。本文评述：Self-RAG 的思路与证据闭环高度契合，但训练成本高，短期内难大规模落地。

7.2 长上下文与 RAG 的融合

随着上下文窗口扩展到百万 token，有人预测 RAG 会被取代。但笔者认为，长上下文解决的是"容量"，RAG 解决的是"定位与溯源"。即使上下文足够长，仍需检索来筛选相关证据、提供来源。未来趋势是"长上下文+RAG"融合：用检索缩小范围，用长上下文保留细节。

7.3 可验证生成与形式化方法

更长远看，"可验证生成"（Verifiable Generation）是终极方向：让生成过程本身可被形式化验证。这需要结合程序合成、定理证明等技术。2024年已有研究探索用 LLM 生成可验证代码。本文评述：这条路很长，但在数学、代码等可形式化领域，可能率先突破。

7.4 监管与合规驱动

欧盟《人工智能法案》（2024年生效）对高风险 AI 系统提出透明度与可追溯要求。国内《生成式人工智能服务管理暂行办法》也强调内容真实准确。本文评述：合规压力将倒逼企业把"证据闭环"从"可选项"变成"必选项"，这是幻觉治理工程化的最大外部推力。

八、结语：把"证据"当作系统的一等公民

大模型幻觉无法被"消灭"，但可以被"压制"。本文的核心主张是：幻觉治理的本质，是把"证据"从附属品提升为系统的一等公民。RAG 溯源让答案有据可查，强制引用让证据进入生成，输出校验让证据被验证——三者构成闭环，缺一不可。

工程落地没有银弹。三板斧的价值不在于技术多新，而在于它们提供了一条可操作、可度量、可迭代的路径。建议团队从"检索质量"和"引用正确率"两个指标入手，先跑通最小闭环，再逐步加码。

最后，笔者想强调：技术手段之外，产品设计同样重要。明确告知用户"AI 可能出错"、提供"来源可查"、设置"人工兜底"，这些看似简单的设计，往往比复杂算法更能建立信任。证据闭环的终点，不是让 AI 永不犯错，而是让错误可被发现、可被追溯、可被纠正。