ProofRAG把LLM当“不可信组件”，每个引用单独验证、不过就拒答，这种架构的成本和可用性怎么平衡？

——以“验证粒度—成本—可用性”三角为主线，拆解声明级验证的工程边界

摘要与核心论点

检索增强生成（Retrieval-Augmented Generation, RAG）把外部文档引入生成流程，缓解了大模型的知识时效与幻觉问题，但并没有消除“引用不可信”这一根本风险：模型可能引用不存在的段落、把原文结论改写成相反含义，或把弱相关证据包装成强结论。ProofRAG这类架构的核心主张，是把大语言模型降格为“不可信组件”——它只负责提出候选声明与候选引用，是否成立由独立的验证器逐条判定，任何一条引用验证不通过，系统就拒答而非“带病输出”。

本文的主线是一个三角约束：验证粒度越细，可信度越高，但单位查询成本与延迟上升；拒答阈值越严，错误率越低，但可用性（有效回答率）下降。三者不可能同时最优，工程上真正要做的是在给定业务风险预算下寻找可行域，而不是追求“全验证、零拒答”。笔者认为，ProofRAG的价值不在于“消灭幻觉”，而在于把不可控的生成风险转化为可度量、可定价、可协商的验证成本，使系统从“概率性可信”走向“可审计的有限可信”。

目录

一、问题定义：为什么“有引用”不等于“可信”

1.1 引用幻觉的三种形态

在工程实践中，带引用的RAG输出至少存在三类失效。第一类是引用虚构：模型给出看似规范的文献编号或段落定位，但检索库中并不存在对应内容。第二类是语义漂移：引用段落真实存在，但模型对其做了过度概括、因果倒置或范围扩大，例如原文说“在特定条件下观察到相关性”，输出变成“已被证明存在因果关系”。第三类是证据强度错配：引用本身正确，但不足以支撑结论，典型如用单一样本案例支撑普遍性判断。

这三类失效的共同点是：它们都无法通过“检查引用是否存在”来发现。传统RAG的评估多停留在检索命中率（Recall@k）与答案相似度（如ROUGE、BERTScore）层面，而这类指标对“引用是否真正支撑该声明”几乎不敏感。本文评述：把引用存在性当作可信性代理指标，是当前多数RAG系统最容易被忽视的设计缺陷。

1.2 声明级验证的定义

所谓声明级验证（claim-level verification），指把模型输出拆解为若干原子声明（atomic claim），每条声明独立地与所引证据做蕴含判定（entailment judgment），判定结果分为支持、部分支持、矛盾、无关四档，只有达到“支持”才允许该声明进入最终答案。这与句子级、段落级验证的区别在于：验证单元与证据单元的对应关系被显式建立，错误可以被定位到具体声明，而不是整段答案。

笔者认为，声明级验证的真正代价不在“多调用一次模型”，而在于它把一个原本端到端的生成问题，改造成了“声明抽取 + 证据对齐 + 蕴含判定 + 聚合决策”的多阶段流水线，每个阶段都引入新的误差来源与工程复杂度。这也是后文成本分析的基本出发点。

1.3 与事实性评估的关系

需要区分声明级验证与事实性评估（factuality evaluation）。后者通常以外部知识库或人工标注为基准，衡量答案整体是否正确；前者是系统内部的运行时机制，目标是决定“这条输出能不能发出去”。前者是离线度量，后者是在线门控。二者共享技术组件（如自然语言推理模型），但优化目标不同：评估追求与人类判断的一致性，门控追求在给定成本下的风险控制。混淆二者，会导致把评估指标直接当作拒答阈值使用，从而在分布偏移时出现系统性误判。

二、技术路线：声明级验证的四种实现范式

2.1 范式一：NLI模型直接判定

最直接的做法是使用自然语言推理（Natural Language Inference, NLI）模型，把“证据段落”作为前提（premise）、“原子声明”作为假设（hypothesis），输出蕴含、矛盾、中立三分类。这类模型参数量通常在1亿至10亿级，单条判定延迟可控制在数十毫秒量级，适合高并发场景。其局限在于：NLI模型在长前提、多句证据、数值比较等情形下准确率明显下降，且对领域术语的覆盖依赖训练分布。

本文评述：NLI路线的性价比在“证据短、声明结构简单”的场景中最优，例如FAQ式问答、条款查询。一旦证据需要跨段拼接或涉及表格数值，NLI的误判率会快速上升，此时应把它当作粗筛而非终判。

2.2 范式二：LLM作为评判者

用大模型做蕴含判定（LLM-as-judge）是近年主流。相比NLI小模型，LLM能处理更复杂的语义关系，支持“给出判定理由 + 置信度”的结构化输出。代价是单次判定成本高出1至2个数量级，且存在位置偏差、长度偏差等已知问题。工程上常见的缓解手段包括：交换前提与假设顺序做双向判定、要求输出结构化JSON而非自由文本、对判定结果做多采样投票。

{
  "claim_id": "c_07",
  "claim": "该药物在III期试验中使主要终点风险降低32%",
  "evidence_span": "doc_1182#p4",
  "verdict": "partial_support",
  "reason": "原文报告风险比为0.68，对应相对风险降低32%，但置信区间跨1，未达统计学显著",
  "confidence": 0.71
}

上述结构化输出是工程落地的关键：只有把判定结果变成可程序化消费的字段，聚合决策与拒答逻辑才能稳定实现。笔者认为，很多团队在LLM评判者上踩坑，根源不是模型能力不足，而是没有约束输出格式，导致下游无法可靠解析。

2.3 范式三：检索式证据定位

第三类范式不直接判定蕴含，而是先做细粒度证据定位：把声明拆成实体与关系，回到索引中检索最小支撑片段（minimal supporting span），再判断该片段是否覆盖声明全部要素。这种方法对“引用虚构”特别有效，因为它要求证据必须可定位、可回溯到具体文档偏移。缺点是对索引质量高度敏感，且难以处理需要多跳推理的声明。

本文评述：检索式定位与NLI判定并非互斥，实践中更合理的组合是“先定位、再判定”——定位负责排除虚构引用，判定负责识别语义漂移，两者分工明确，成本也可分别核算。

2.4 范式四：程序化校验

对数值、日期、单位、统计量等结构化要素，最可靠的不是语义模型，而是程序化校验：从证据中抽取数值，与声明中的数值做精确比对，并检查单位换算与比较方向。这类校验的边际成本极低，且结果确定。工程上应优先把可程序化的部分从LLM判定中剥离出来，既降本又提准。

三、成本结构：一次验证到底花在哪里

3.1 成本分解模型

把单次查询的总成本记为 C，可分解为：检索成本 C_r、声明抽取成本 C_e、证据定位成本 C_l、蕴含判定成本 C_j、聚合与拒答决策成本 C_d。其中 C_j 通常是主导项，因为它对每条声明都要调用一次（或多次）判定模型。若平均每条答案含 n 条声明、每条声明平均需要 m 次判定调用，则 C_j 与 n×m 成正比。

需要说明的是，上表为结构性分解，不涉及具体厂商价格；实际单价随模型、批量、缓存命中率变化很大，工程上应以自身压测数据为准。本文评述：把成本拆到这一层，才能回答“钱花在哪、能不能省、省了会不会伤可信度”这三个问题。

3.2 声明数量是隐性放大器

很多团队低估了声明数量 n 的影响。一段三百字的答案，若按句子拆分，可能产生8至15条声明；若其中每条都要独立判定，判定调用量就是答案条数的十倍以上。更麻烦的是，声明之间存在依赖关系（如“因此”“综上”引出的结论依赖前文），独立判定会丢失这种结构信息，导致结论句被误判为“无直接证据支持”。

笔者认为，合理的做法是建立声明依赖图：把结论型声明标记为依赖节点，其验证只需检查“前提声明是否全部通过 + 推理形式是否合法”，而不必为结论单独检索证据。这一步通常能减少两到四成的判定调用，且不牺牲可信度。

3.3 延迟而非金额才是硬约束

在交互式场景中，真正的约束往往不是每次查询的金额，而是端到端延迟。串行验证的延迟随声明数线性增长，若单条判定耗时300毫秒、答案含10条声明，仅判定环节就超过3秒，用户体验难以接受。可行的缓解包括：声明间并行判定、按风险排序优先验证高风险声明、对低风险声明采用快速通道。

# 伪代码：按风险分层的并行验证
claims = extract_claims(answer)
claims.sort(key=lambda c: c.risk_score, reverse=True)

fast_pass = [c for c in claims if c.risk_score < TAU_LOW]
must_verify = [c for c in claims if c.risk_score >= TAU_LOW]

# 低风险：规则/小模型快速通道
fast_results = [rule_check(c) for c in fast_pass]
# 高风险：并行调用强判定器
verified = parallel_map(strong_judge, must_verify)

if any(r.verdict == "contradict" for r in verified):
    return refuse("存在与证据矛盾的声明")
if unresolved(verified) > BUDGET:
    return refuse("未决声明超出预算")

这段伪代码体现的核心思想是：验证预算应随风险分配，而不是平均分配。本文评述：平均分配看似公平，实则把大量算力浪费在低风险声明上，同时让高风险声明得不到足够验证，是成本与可信度双输的做法。

四、可用性：拒答率的来源与阈值设计

4.1 拒答的四种触发条件

“不过就拒答”听起来简单，工程上至少要区分四类触发：一是证据缺失，检索未召回可支撑片段；二是证据矛盾，多条证据相互冲突；三是判定未决，置信度落在灰区；四是预算耗尽，验证调用达到上限。四类触发的业务含义完全不同：证据缺失应触发补充检索，证据矛盾应提示用户存在分歧，判定未决可降级为“带警示输出”，只有预算耗尽才是真正的系统性拒答。

把四类混为一谈，是拒答率虚高的常见原因。笔者认为，可用性优化的第一步不是放宽阈值，而是把拒答原因分类统计，找出哪一类占比最高，再针对性处理。

4.2 阈值与错误率的权衡曲线

设判定置信度为 s，拒答阈值为 τ，则拒答率 R(τ) 随 τ 单调上升，而漏放错误率 E(τ) 随 τ 单调下降。二者的权衡曲线形状取决于置信度分布的可分性：若支持与不支持两类声明的置信度分布重叠严重，曲线会非常平缓，意味着提高可信度需要付出极高的可用性代价。

上表为策略示意，不构成具体数值建议。本文评述：阈值不应是全局常数，而应按声明类型分层——数值类声明用严格阈值，观点类声明用宽松阈值，这样能在不显著抬高整体拒答率的前提下守住高风险部分。

4.3 拒答不等于失败

从产品视角看，拒答是一种“有信息量的失败”：它告诉用户系统在何处不确定，并往往附带可操作的下一步（补充材料、缩小问题范围、转人工）。若把拒答设计成结构化反馈而非简单报错，可用性的主观感受会明显改善。笔者认为，ProofRAG类系统应把“拒答理由 + 缺失证据类型 + 建议动作”作为标准输出的一部分，这比单纯压低拒答率更能提升实际价值。

五、平衡路径：分层验证与成本复用的工程方法

5.1 三层验证漏斗

可落地的第一套方法是三层漏斗：第一层规则校验（数值、单位、实体存在性），成本近乎为零；第二层小模型NLI粗筛，把明显支持与明显矛盾的声明分流；第三层仅对灰区声明调用强判定器。漏斗的关键是各层阈值要联合标定，而不是各自独立设定，否则会出现“上层放行、下层全拒”的浪费。

本文评述：漏斗结构的收益来自“大部分声明是容易判断的”这一经验事实。若业务场景中灰区声明占比过高（例如大量需要跨文档推理的声明），漏斗收益会迅速衰减，此时应考虑改变证据组织方式，而非继续加层。

5.2 验证结果缓存与复用

同一证据片段与同一原子声明的组合，其判定结果在短期内是稳定的，可以缓存。工程上以“证据指纹 + 声明规范化文本”为键，命中缓存直接复用判定，能显著降低重复查询成本。需要注意缓存失效策略：文档更新、判定模型升级、阈值调整都应使相关缓存失效。

cache_key = sha256(
    normalize(evidence_span) + "||" +
    normalize(claim_text) + "||" +
    judge_model_version + "||" +
    str(threshold_bucket)
)

把模型版本与阈值档位纳入键，是避免“缓存污染”的必要设计。笔者见过因忽略这一点，在模型升级后仍返回旧判定的案例，表面降本，实则引入系统性偏差。

5.3 按风险分配预算

第二套方法是预算分配：为每次查询设定验证预算上限，按声明风险分排序消耗预算，高风险声明优先获得多次采样与强模型判定，低风险声明只做单次快速判定。预算耗尽时，对剩余声明采取保守策略（标记未验证并降级输出），而不是无限追加调用。

这套方法把“成本控制”从被动限流变成主动调度，使系统在高负载下仍能保持行为可预期。本文评述：可预期性本身就是可用性的一部分——用户能理解系统为何拒答，比系统随机变慢或随机出错要好得多。

5.4 离线标定与在线监控

阈值与分层策略不能拍脑袋，需要离线标定：构造带标注的声明—证据对，覆盖支持、部分支持、矛盾、无关四类，绘制不同阈值下的拒答率与错误率曲线，选择符合业务风险预算的工作点。上线后持续监控灰区占比、缓存命中率、各层分流比例，一旦分布漂移就触发重新标定。

延伸阅读可参考检索增强生成与事实性评估的公开教程与综述，例如RAG综述（arXiv:2312.10997）、FActScore相关方法，以及Hugging Face官方课程中关于文本蕴含与评估的章节，便于对照实现细节。

六、对比与局限：ProofRAG不适合什么场景

6.1 与端到端RAG的对比

端到端RAG把检索与生成耦合在一个流程里，工程简单、延迟低，但可信度不可控；ProofRAG把验证显式化，可信度可度量，但流程长、成本高。二者的差别类似“乐观并发”与“悲观锁”：前者吞吐高、偶发出错，后者安全、开销大。选择哪一种，取决于错误的代价是否可逆。

6.2 不适用的场景

ProofRAG式架构在以下场景收益有限甚至为负：一是创意生成类任务，输出本就不以事实支撑为目标，逐条验证会扼杀多样性；二是证据本身稀缺或非结构化的探索性研究，验证器频繁落入灰区，拒答率居高不下；三是超低延迟的实时交互，验证开销难以摊薄。本文评述：把验证架构当作普适方案推广，是另一种形式的过度工程。

6.3 验证器自身的可信问题

还有一个常被忽略的边界：验证器本身也可能出错。若判定模型的假阴性（把支持判为不支持）偏高，系统会过度拒答；假阳性偏高，则验证形同虚设。因此，验证器需要独立的评估集与定期校准，且其版本变更应纳入整体可信度审计。笔者认为，ProofRAG的“不可信组件”原则应当递归适用——不仅LLM不可信，验证器也应被视为需要持续监控的组件，而非绝对权威。

七、结论与展望

回到最初的问题：ProofRAG把LLM当不可信组件、逐条验证、不过就拒答，成本与可用性如何平衡？本文的答案是：不存在单一最优解，只有在给定风险预算下的可行域。可行域由三件事共同决定——验证粒度（决定成本下限）、拒答阈值（决定可用性上限）、验证器质量（决定二者权衡曲线的形状）。工程上真正有效的动作，是抬高验证器质量以改善曲线形状，用分层与缓存压低成本，用分类拒答与结构化反馈提升可用性感受，而不是在“全验证”与“不验证”之间二选一。

展望未来，三个方向值得关注：其一，验证器与生成器的联合训练，使验证信号反哺生成，从源头减少不可验证声明；其二，验证过程的可解释化，让每条判定都附带可复核的证据链，支撑合规审计；其三，验证成本的动态定价，按查询风险实时调度算力，使系统在高负载下仍保持行为一致。笔者认为，随着验证器能力提升与推理成本下降，声明级验证会从“高成本可选项”逐步变为“中高风险场景的默认配置”，而端到端RAG则退守低风险、高吞吐的场景。二者的边界会随成本曲线移动，但“把不可信组件隔离出来单独验证”这一设计原则，具有超越具体模型的长期价值。

主要参考文献

文章声明

本文内容仅为作者学习、思考、经验、笔记的总结，仅供技术交流与参考。文中观点仅代表笔者个人思辨，不构成任何学术建议、商业建议或专业建议。所有数据来源已标注，引用时请以原始文献为准。