减少 RAG 幻觉：类型化提取合约的七种模式

在当前的企业级文档智能（Enterprise Document Intelligence）领域，“幻觉”（Hallucination）一词已成为大语言模型（LLM）产生任何错误输出的统称。然而，对于构建鲁棒的检索增强生成（RAG）系统的工程师来说，这种术语往往是不精确且具有误导性的。当 LLM 已经获得了正确的上下文窗口，但未能准确合成答案时，我们看到的并不是一种“创造性的幻觉”，而是一种“提取错误”（Extraction Error）。

在 n1n.ai 的实践中，我们经常观察到，原型系统与生产级 RAG 系统之间的区别在于开发人员如何管理“生成模块”（Generation Brick）。通过从非结构化的文本提示词转向“类型化生成合约”（Typed Generation Contract），开发人员可以显著提高流水线的可靠性。本文将探讨构建这些合约的七种模式，以及为什么它们对于高性能 RAG 至关重要。

提取与幻觉的技术区别

真正的“幻觉”发生在模型根据其内部权重生成了提供的上下文中不存在的事实时。相反，当信息确实存在于检索到的文档中，但模型未能将其映射到所需的输出格式或遗漏了关键细节时，就会发生“提取错误”。

在准确性不容协商的企业场景中，将所有错误都视为幻觉会导致无效的“提示词工程”死循环。相反，通过定义严格的架构（Schema），你可以强制模型遵守逻辑结构，使错误更容易调试。通过 n1n.ai 使用高性能模型，可以提供执行这些复杂提取任务所需的底层推理能力。

什么是类型化生成合约？

类型化生成合约是应用程序与 LLM 之间的一种程序化协议。它使用架构（如 JSON Schema 或 Pydantic 模型）确切地定义输出的样式。这种方法利用了现代模型（如 GPT-4o 或 Claude 3.5 Sonnet）的“结构化输出”能力，这些模型均可通过 n1n.ai 的 API 聚合器访问。

模式 1：严格架构强制执行 (Strict Schema Enforcement)

任何合约的基础都是架构。与其要求模型提供一个“摘要”，不如定义一个 Pydantic 类，指定诸如 primary_entities（主要实体）、dates（日期）和 quantitative_values（定量值）等字段。

from pydantic import BaseModel, Field
from typing import List

class FinancialExtraction(BaseModel):
    revenue: float = Field(..., description="报告中提到的总收入")
    currency: str = Field(..., description="ISO 4217 货币代码")
    fiscal_year: int
    risk_factors: List[str]

通过强制执行此类类型，你可以消除 90% 以上与格式相关的提取错误。

模式 2：针对小模型的粒度分解 (Granular Decomposition)

在使用 Llama 3 8B 或 Mistral 7B 等较小、较快的模型（SLM）时，复杂的提取任务经常失败。“分解规则”建议将单个大型提取任务分解为多个较小的类型化任务。

与其一次性提取整个法律合同，不如创建一个调用序列：一个用于“身份识别”，一个用于“终止条款”，另一个用于“责任限制”。这减轻了模型的认知负荷，并增加了在延迟（Latency） < 200ms 的情况下成功提取的可能性。

模式 3：参考引用锚定模式 (Reference Grounding Pattern)

为了防止模型“瞎猜”，合约应包含一个用于源引用的字段。每个提取的数据点都必须附带原始文本的片段。

{ "value": "52 亿美元", "source_quote": "公司报告第三季度总收入为 52 亿美元。" }

这种模式允许应用程序根据上下文以程序化方式验证提取结果。

模式 4：枚举约束分类 (Enum-Constrained Classification)

自由格式的文本是自动化的敌人。只要有可能，就使用 Enums（枚举）来限制模型的选择。这在情感分析、文档标记或意图识别中特别有用。它防止模型发明下游代码无法处理的新类别。

模式 5：单位与格式标准化 (Unit and Format Normalization)

提取错误通常表现为单位不一致（例如，“5 百万”与 “5,000,000”）。类型化合约应指定标准化规则。你可以指示模型始终将日期转换为 ISO 8601，将数字转换为浮点数。这把“数据清洗”逻辑移到了生成阶段，因为此时 LLM 拥有理解这些数值所需的完整上下文。

模式 6：负空间模式 (Negative Space Pattern)

RAG 的一个常见失败是模型试图寻找不存在的信息。你的架构应该显式处理 null 或 None 值。定义一个清晰的协议：“如果信息不存在，返回 null；不要猜测。”这会将潜在的幻觉转变为受控的“未找到”状态。

模式 7：多轮验证合约 (Multi-Pass Validation Contract)

对于高风险的提取任务，使用两步走合约。第一个模型将数据提取到架构中，第二个模型（或新会话中的同一模型）根据原始文本验证提取的 JSON。这种自我修正循环在通过 n1n.ai 提供的低延迟端点运行时非常高效。

实施策略建议

要实现这些模式，开发人员应利用 Instructor 或 Outlines 等与 LLM 供应商深度集成的库。通过 n1n.ai 选择模型供应商时，请参考模型的“结构化输出”基准测试。具有更高推理能力（如 DeepSeek-V3）的模型通常在长上下文中维持类型化合约完整性方面表现更好。

总结

通过将 RAG 失败重新定义为提取错误，我们可以将工程纪律应用于 LLM 输出。类型化生成合约将 LLM 生成的“黑盒”转变为软件栈中可预测、可验证的组件。无论你是在构建法律助手还是财务分析工具，这七种模式都将确保你的 RAG 系统保持诚实和准确。

立即在 n1n.ai 获取免费 API 密钥。