标准RAG管线仍然产生不可归属的声明，本体约束生成只允许schema内输出、拒绝schema外断言，工程上能拦住多少？

从“检索到证据”到“声明可归属”：约束解码的拦截能力、边界条件与残余风险

摘要：检索增强生成（RAG）把“证据可得”与“声明可归属”混为一谈，是当前生产系统最隐蔽的失效来源。本文以“可归属性（attributability）”为贯穿主线，先给出可归属声明的形式化定义与四类失效模式，再剖析本体约束生成（Ontology-Constrained Generation, OCG）在解码层如何把自由文本压缩到schema允许的谓词与实体空间，从而拒绝schema外断言。工程上，OCG能稳定拦截“谓词越界”“实体类型错配”“关系方向反转”三类高发错误，但对“schema内事实错误”“证据粒度错位”“隐含推理链断裂”几乎无拦截力。本文提出“约束编译—解码拦截—归属验证—回退降级”四段式操作路径，并给出可复现的评测口径与阈值建议，最后讨论约束覆盖率与表达力之间的结构性张力。

目录

一、导语：一个被“检索命中率”掩盖的问题

过去两年，RAG几乎成了企业落地大模型的默认架构。工程团队的评测看板通常盯着三件事：召回率、上下文命中率、答案相关性。这三项指标都在回答“证据有没有被找到、有没有被用上”，却几乎不回答另一个更关键的问题——模型输出的每一句断言，能不能被追溯到某一段具体证据。前者是检索质量问题，后者是归属（attribution）问题。二者并不等价。

实践中常见的现象是：检索器命中了正确文档，生成器却把文档里的条件、主体、时间或否定词改写了。答案“看起来对”，评测分数也不低，但一旦进入审计、合规或医疗、金融等高风险场景，这种“对但不可溯源”的声明就是硬伤。更麻烦的是，这类错误往往不表现为明显的幻觉，而是表现为语义漂移：谓词从“导致”变成“相关”，主体从“某批次”泛化为“全部”，时间从“2023年”滑到“近年”。标准RAG管线对此没有结构性防线。

本文的核心主张是：把“可归属性”从评测指标提升为生成约束，是当前工程上性价比最高的一步。本体约束生成（OCG）正是这条路径的代表性方案——它不允许模型输出schema之外的谓词与实体组合，从解码层就把一部分不可归属的声明挡在门外。但“拦住多少”必须被精确回答，否则约束会变成一种安全幻觉。本文评述：约束不是万能的，它拦的是“形式越界”，不是“事实错误”；把两者混为一谈，是OCG落地中最常见的认知偏差。

二、背景与问题定义：什么叫“不可归属的声明”

2.1 可归属性的形式化定义

设证据集合为 E = {e₁, e₂, …, eₙ}，模型输出被切分为原子声明集合 C = {c₁, c₂, …, cₘ}。所谓原子声明，是指不可再分、含至少一个谓词与若干论元的最小语义单元。若对每个 cᵢ 都存在证据子集 Sᵢ ⊆ E，使得 Sᵢ 在语义上蕴含 cᵢ，则称该输出在证据下可归属；否则称为不可归属声明（Unattributable Claim, UAC）。

这个定义有两个容易被忽略的细节。第一，“蕴含”不是“相关”，证据必须能支撑声明的真值，而非仅仅话题相近。第二，归属是声明级而非段落级的：一段整体可归属的答案里，完全可以藏着一句不可归属的断言。本文评述：多数RAG评测以段落或整答案为粒度打分，恰好把最危险的局部错误平均掉了，这也是UAC长期被低估的方法论原因。

2.2 四类失效模式

把UAC按成因拆开，工程上才有抓手。笔者基于公开研究与生产排查经验，将其归纳为四类，后文所有拦截分析都围绕这四类展开。

前三类的共同点是“形式越界”——它们违反了本体对谓词域（domain）、值域（range）与关系方向的定义，因此原则上可以在解码阶段被结构性拦截。第四类则不同：它完全落在schema允许的空间内，约束无从下手。本文评述：把OCG宣传成“幻觉终结者”是过度承诺；它真正解决的是形式越界，事实层仍需独立的归属验证环节兜底。

2.3 为什么标准RAG管线天然漏掉UAC

标准RAG的流水线是“检索→拼接→生成→后处理”，四个环节都没有声明级的归属检查。检索环节优化的是相关性，拼接环节做的是上下文压缩，生成环节是自由解码，后处理通常只做格式与安全过滤。整条链路上，没有任何一步强制“每个谓词都必须来自证据或本体”。模型在自由词表上解码，天然拥有把“相关”升级为“导致”的语言自由度。

更微妙的是，检索增强本身会放大这种自由度。当上下文里出现大量相近但不等价的表述时，模型倾向于做“语义平滑”，把多个证据的措辞融合成一个更通顺、更概括的句子。这个融合过程正是UAC的高发区。本文评述：RAG的“增强”是双刃的——它提供了证据，也提供了被误读、被过度概括的原材料；没有约束的解码器会把这种原材料加工成看似有据、实则越界的声明。

三、原理与技术路线：本体约束生成如何介入解码

3.1 本体作为可执行的输出契约

本体（ontology）在这里不是哲学概念，而是一份机器可校验的契约：它定义类（Class）、属性（Property）、属性的定义域与值域、关系的基数与方向，以及允许的枚举值。把这份契约编译成解码约束，本质上是把“语言模型的输出空间”从全词表收缩到“本体允许的合法声明空间”。

一个最小可用的本体片段可以写成如下形式（以Turtle记法示意，来源为笔者整理的本体建模实践，非特定文献原文）：

@prefix ex: <http://example.org/> .
ex:acquires  a owl:ObjectProperty ;
    rdfs:domain ex:Organization ;
    rdfs:range  ex:Organization .
ex:reportsRevenue a owl:DatatypeProperty ;
    rdfs:domain ex:Organization ;
    rdfs:range  xsd:decimal .
ex:Organization a owl:Class .
ex:Person       a owl:Class .

这段契约的价值在于：它把“谁可以对谁做什么”写死。若模型试图生成“某个人收购了某机构”，ex:acquires 的 domain 约束会直接判定该声明非法。本文评述：本体的工程意义不在于“知识多全”，而在于“边界多硬”。一个覆盖窄但约束硬的本体，比一个覆盖广但约束软的本体更适合做拦截。

3.2 约束解码的三种介入位置

OCG并非单一技术，而是一族方法，区别在于“在哪一层施加约束”。工程上可按介入位置分为三类，各有明确的成本与拦截边界。

解码中约束（constrained decoding）是拦截力最强的一档。其核心是把“生成”变成“在合法前缀上的受控搜索”：维护一个本体状态机，每步根据当前已生成的三元组前缀，计算下一个位置允许的token集合，把非法token的logit置为负无穷。本文评述：这一档的拦截是结构性的——只要状态机正确，schema外断言在数学上不可能被生成。但它的代价同样结构性：状态机越精确，可表达的自然语言越受限，通顺度与信息量都会被压缩。

3.3 从自然语言到三元组：约束的粒度问题

OCG的一个现实难点是粒度错位。本体约束的是三元组，而用户要的是自然语言段落。若直接约束三元组生成，输出会变得机械；若约束自然语言，又难以精确对应到谓词。工程上常见的折中是“两段式”：先受控生成结构化声明（三元组或JSON），再在声明基础上做受控润色，润色阶段只允许引用已生成声明中的谓词与实体。

这个折中的关键洞察是：把归属检查前移到结构化阶段。一旦声明被固化为三元组，每个谓词都能直接对本体做校验，每个实体都能直接对证据做匹配，归属判定从模糊的语义比较变成可执行的集合运算。本文评述：两段式牺牲了一部分语言自然度，换来的是可审计性；在高风险场景，这个交换是划算的，但在开放域对话里可能得不偿失，需要按场景权衡。

3.4 一个可运行的约束解码最小实现

下面给出一个概念级的最小实现，用前缀树+本体校验模拟“只允许schema内输出”的逻辑。代码为示意，非生产级，重点在展示拦截点在哪。

def allowed_next_tokens(state, ontology, tokenizer):
    # state: 已生成的三元组前缀 (subject, predicate, object?)
    s, p, o = state
    allowed = set()
    if p is None:
        # 只允许本体中作为 subject 的实体类型
        for pred in ontology.predicates_for(s):
            allowed |= tokenizer.tokens_of(pred)
    elif o is None:
        # 谓词已定，object 必须落在 range 内
        for ent in ontology.entities_of_type(ontology.range_of(p)):
            allowed |= tokenizer.tokens_of(ent)
    return allowed

def constrained_decode(prompt, ontology, tokenizer, model, max_steps=64):
    state = (None, None, None)
    out = []
    for _ in range(max_steps):
        allow = allowed_next_tokens(state, ontology, tokenizer)
        logits = model.next_logits(prompt, out)
        logits = mask_illegal(logits, allow)   # 非法 token 置 -inf
        tok = sample(logits)
        out.append(tok)
        state = advance(state, tok, ontology)
        if state.is_complete():
            break
    return out

这段代码里，mask_illegal 就是拦截发生的物理位置。本文评述：真正的工程复杂度不在这个函数，而在 advance 与 ontology.range_of 的正确性——本体一旦建模错误，约束会稳定地拦掉正确声明，或稳定地放行错误声明，且这种错误很难在抽样评测中暴露。

想深入约束解码的实现细节，可参考 Hugging Face 关于结构化生成的教程与 Outlines、Guidance 等开源库的文档（huggingface.co/blog/constrained-decoding、github.com/dottxt-ai/outlines），以及 OWL 本体的入门规范（w3.org/TR/owl2-primer）。这些资料对状态机构建与本体建模有直接的工程参考价值。

四、关键数据与案例：拦截率的分层实测口径

4.1 为什么“拦截率”必须分层报告

“OCG能拦住多少”这个问题，若只报一个总数，几乎没有信息量。原因在于四类失效模式的拦截难度差异极大，混在一起平均会掩盖结构性差异。工程上应至少按“谓词越界、实体类型错配、关系方向反转、schema内事实错误”四层分别报告拦截率，并同时报告误拦率（把正确声明判为非法）。

本文评述：只报拦截率不报误拦率，是OCG评测里最危险的报告方式。一个把本体约束设得极严的系统可以轻松做到接近100%的越界拦截，代价是把大量合法但边缘的声明也拦掉，最终表现为“答案变得保守、信息量骤降”。这种系统在拦截率看板上很漂亮，在生产里却不可用。

4.2 分层拦截能力的定性判断与模拟数据

下表为笔者基于机制推理给出的分层判断，并附一组模拟数据用于说明报告口径（模拟数据，非任何团队实测，仅作方法演示，不可作为效果承诺引用）。

这组模拟数据的结构性含义比具体数字更重要：越靠近“形式”的错误，拦截率越高；越靠近“事实”的错误，拦截率越低。方向反转之所以低于前两类，是因为很多本体的关系方向约束并不完备，或者模型通过被动语态绕过了方向检查。本文评述：这个梯度不是实现缺陷，而是OCG的能力边界本身——它约束的是形式，不是真值。

4.3 一个可复现的评测流程

要让拦截率数据可信，评测流程必须可复现。建议按以下步骤执行：

第一步，构造声明级测试集。从真实业务问答中抽取答案，人工切分为原子声明，并标注每条声明的证据片段与失效类型。切分粒度以“单谓词单论元”为准，避免复合句混淆归因。

第二步，冻结本体版本。评测期间本体不得改动，否则拦截率不可比。建议对本体做版本号管理，并在报告中注明 commit。

第三步，分别跑“无约束”“prompt约束”“解码约束”三档，记录每档的拦截率、误拦率与答案信息量（可用声明数、平均长度做代理指标）。

第四步，做交叉验证。同一批声明由两名标注者独立判定可归属性，计算一致性系数，低于阈值的样本剔除或复核。

本文评述：这套流程的成本主要在前两步，但它是唯一能让“拦住多少”这个数字站得住脚的方式。跳过声明级切分、直接拿整答案打分的评测，结论不可迁移到生产。

五、对比与局限：OCG拦得住什么、拦不住什么

5.1 与三类替代方案的横向对比

OCG不是唯一思路。工程上常见的替代或补充方案包括：基于自然语言推理（NLI）的归属校验、基于引用回链（citation grounding）的后处理、以及基于微调的“忠实生成”训练。三者的定位与OCG不同，不能简单替代。

本文评述：这四者不是竞争关系，而是分层防御。OCG负责“形式层”的硬拦截，NLI与引用回链负责“语义层”的软校验，微调负责“倾向层”的基线改善。把任何一层当成全部，都会留下结构性缺口。

5.2 OCG的三条硬边界

第一条边界是表达力与覆盖率的张力。本体越严，可生成的合法声明越少，模型越容易被迫“沉默”或退化为模板化输出。这不是调参能解决的，而是约束系统的结构性代价。工程上必须接受“部分问题答不了”作为设计前提。

第二条边界是本体建模错误会被放大。约束解码是确定性的：本体写错，错误就会被稳定地、可复现地施加到每一条输出上。自由解码的错误是随机的，约束解码的错误是系统性的。本文评述：这意味着OCG对本体质量的要求远高于对模型质量的要求，本体评审应当成为上线前的强制门禁。

第三条边界是对schema内事实错误无能为力。这是最需要向业务方说清楚的一点。约束能保证“你说的关系是合法的”，但不能保证“你说的关系是真的”。真值判断必须交给独立的归属验证环节，通常是NLI校验加证据回链。

5.3 一个容易被忽视的风险：约束诱导的“合规幻觉”

当系统输出全部通过本体校验时，使用者容易产生“既然都合法，那应该都对”的错觉。这种错觉在审计场景尤其危险，因为形式合规会降低人工复核的警觉性。本文评述：OCG在提升形式可靠性的同时，可能降低人对内容的批判性审查强度，这是一种二阶风险，需要在流程设计上主动对冲——例如强制对高影响声明做独立证据回链，而不因“已通过本体校验”而豁免。

六、工程落地路径：四段式操作步骤

6.1 约束编译：把本体变成状态机

第一步是把本体编译为可执行的状态机或语法。关键动作包括：抽取谓词闭集，标注每个谓词的domain/range，标注关系的方向与基数，处理枚举值与数值范围。编译产物应可版本化、可回归测试。建议为每个谓词写至少一条正例与一条反例，作为状态机的单元测试。

操作要点：优先覆盖高频谓词，低频谓词可先归入“其他”并放宽约束，避免一次性追求全覆盖导致状态机过于复杂。本文评述：约束编译应遵循“先窄后宽、先硬后软”的原则，先用窄本体跑通链路，再逐步扩展覆盖面。

6.2 解码拦截：两段式受控生成

第二步是两段式生成：先受控生成结构化声明，再受控润色。结构化阶段用约束解码保证每个三元组合法；润色阶段只允许引用已生成声明中的谓词与实体，禁止引入新谓词。润色阶段的约束可以放宽到“实体白名单+谓词白名单”，不必再做完整状态机。

操作要点：润色阶段的prompt里显式列出允许的谓词与实体，并要求“不得引入列表外的词”。同时保留一个“拒绝”出口，当证据不足以支撑任何合法声明时，允许模型输出“无法从证据得出该结论”。本文评述：拒绝出口是OCG可用性的关键，没有它，模型会在约束压力下强行拼凑合法但无据的声明。

6.3 归属验证：声明级回链与NLI校验

第三步是对每条结构化声明做归属验证：把声明与候选证据片段配对，用NLI模型判断“证据是否蕴含声明”。蕴含则通过，矛盾或中立则标记待复核。对于数值型声明，额外做数值一致性检查。

操作要点：证据片段要做窗口切分，避免长文档稀释蕴含信号；NLI阈值应按业务风险分级设定，高风险场景用高阈值并接受更多待复核。本文评述：归属验证是OCG的必要补位，二者组合才构成“形式+语义”的双层防线。

6.4 回退降级：不可归属时的产品行为

第四步是定义回退策略。当声明无法通过归属验证时，系统应有明确行为：降级为“仅返回证据原文”、降级为“返回部分可归属声明并标注不确定”、或直接拒答。三种策略对应不同的产品风险偏好，必须在需求阶段就定清楚，而不是留到线上临时决定。

操作要点：为每类失效模式配置独立的回退动作，并记录回退率作为核心运营指标。回退率突然上升往往意味着本体或证据源发生了变化，是很好的早期告警信号。本文评述：回退不是失败，而是可归属性的最后一道保险；一个没有回退设计的OCG系统，等于把约束压力全部转嫁给了用户。

七、结论与展望：把“可归属”变成一等公民

回到标题的问题：工程上能拦住多少？结论是分层的——OCG能把谓词越界、实体类型错配、关系方向反转这三类形式越界拦在解码层，拦截强度高且可复现；但对schema内事实错误几乎无拦截力，必须由归属验证补位。把OCG当成“幻觉终结者”是误读，把它当成“形式合规的硬门禁”才是正确定位。

展望来看，三个方向值得投入。其一是本体与证据的联合约束：不仅约束谓词合法，还约束谓词必须出现在证据中，把归属检查前移到解码层。其二是声明级评测的标准化：当前缺少公开的、带声明级归属标注的中文评测集，这是制约工程迭代的基础设施短板。其三是约束与表达力的自适应平衡：按问题类型动态调整约束强度，高风险问题用硬约束，开放问题用软约束。

本文评述：可归属性应当从“评测指标”升格为“系统契约”。当每个声明都必须携带可验证的证据指针，RAG才真正从“看起来有据”走向“可审计地有据”。这条路的技术门槛不在模型，而在本体工程与评测基础设施——恰恰是最不性感、却最决定成败的部分。

主要参考文献