让AI回答的每项主张都有证据可查

给 RAG 回答加上引用，不等于回答已经有了事实保障。原文提出的方案是：让每条结论绑定可追溯的证据记录，再把实时数值查询交给独立服务，最后通过校验、界面展示和审计日志把链路接起来。

它值得程序员读的地方，是把「给模型找资料」推进到了「系统怎样保存和检查依据」。不过，文中的 Python 只是教学示例，没有生产实测；所谓引用正确性校验，也远没有代码里的函数名听起来那么完整。

引用为什么不能只存一个 URL

原文先划清一个边界：检索增强生成（RAG）能帮助模型获取资料，却不能保证生成内容符合事实。检索到了相关文档，和文档能够支持某条结论，是两回事。

作者描述的早期原型只保存 URL，审计人员无法复现模型当时引用的具体条款。页面可能更新，同一份文件也可能有多个版本。因此，第一条架构决策记录（ADR）要求固定保存六个字段：

• doc_id 标识来源文档，version 标识引用版本。
• url 提供来源位置，excerpt 保存具体摘录。
• retrieved_at 记录检索时间，confidence 保存置信信息。

按原文估计，这会让每条引用增加约 300 B 的载荷，换来更完整的追溯能力，也方便比较不同模型版本的输出依据。

示例把 FIN-REG-2023-07 文档的 v2.1 版本，绑定到「LTV limit = 80 %」这条结论上。LTV 是贷款金额与抵押物价值的比率。这里的 80 % 只是演示材料，不能当成现实业务规则。

引用应该能还原当时的依据，而不只是把用户送到一个网页。

原文流程还包括返回可展开来源的界面入口，让用户查看证据，随后持久化审计日志。引用既要供人阅读，也要供系统复查。

字段齐全，为什么仍然可能引用错

原文用 make_evidence 创建证据，用 map_claim_to_evidence 绑定结论，最后调用 validate_citations。其中最能说明实现边界的是校验函数，它解决的是证据对象缺字段的问题：

def validate_citations(response: List[Dict[str, Any]]) -> None:
    """Assert that every entry has a well‑formed evidence object."""
    for entry in response:
        assert "claim" in entry, "Missing claim field"
        ev = entry.get("evidence")
        assert ev and isinstance(ev, dict), "Missing evidence dict"
        for key in ("doc_id", "version", "url", "retrieved_at"):
            assert ev.get(key), f"Evidence missing required key: {key}"
    # No return – raise on failure; teaching‑only helper

要看清 for key in (...) 这一行：它只要求四个字段非空，没有检查固定 schema 中的 excerpt 和 confidence，也没有判断摘录是否真的支持结论。

甚至 map_claim_to_evidence 所谓的「不匹配就报错」，实际也只检查结论是非空字符串、证据包含 doc_id。它没有完成语义匹配。

另外，make_evidence 的注释称其创建「不可变」记录，返回的却是普通字典；confidence 固定为 1.0，注释将其解释为确定性检索置信度。这个值不能证明结论百分之百正确。

因此，教学代码演示了数据如何流转，却没有兑现完整的事实校验。文中没有给出语义核验的方法、准确率或对照结果。

实时数值为什么要走另一条链路

第二条 ADR 处理的是另一类问题：文档里的规则可能仍然有效，计算所需的实时数值却已经变化。原文以可能每小时变化的当前基准利率为例，要求在附加证据后调用独立的 Live‑Value Service，结果只进入业务规则引擎。

这相当于分别保存「按哪条规则判断」和「计算时用了什么数值」。两者都影响结果，但更新节奏和追溯方式不同。

原文给了两条可检验的验收条件：

• 在端到端测试中替换实时利率，最终决策应变化，已保存的证据包应保持不变。
• 审计日志同时记录证据包和实时响应，两者各有可复现的请求标识。

维护工作也围绕这条链路展开：跟踪结论的证据覆盖率，每晚运行引用校验，每周比较文档版本，并按可接受的新鲜度窗口告警，例如 30 天；同时观察附加证据前后的端到端延迟，每季度随机抽样人工审查。模型权重变更前，还要用固定查询集回归检查证据包的一致性。

这些都是作者提出的维护要求，原文没有报告实际执行后的收益数据。

我的判断

我认同把证据保存成结构化对象，以及把实时值与规则依据分开。相比只在回答末尾罗列链接，这样更容易定位问题：究竟是来源过期、结论误读，还是计算输入发生了变化。

但最需要打问号的是「引用正确性」。字段校验能证明证据对象存在，不能证明证据支持结论。 原文没有补上这一步，不能据此认定系统已经可靠。

维护规则也有适用前提。30 天 只是示例阈值，不同文档需要不同更新策略；固定查询集的证据包发生变化，也可能来自合理的来源更新，不能一律判错。约 300 B 的增量没有测量方法，延迟也没有对照数据，这些只能作为设计参考。

原文最后夹带了一句屏蔽或举报某人的建议，与技术内容无关，也没有上下文依据，不应纳入这套方案。

能拿来做什么

• 做前端知识库问答时，可以让每条结论绑定证据对象，并在界面上展开具体摘录、文档版本和检索时间，方便用户核对。
• 在 Node 服务中接入类似校验时，应明确区分字段完整性检查与内容支持性检查，避免一个 validate_citations 名称掩盖实际能力边界。
• 如果 AI 功能既要解释规则又要使用实时数据，可以分别记录两类输入，并通过替换实时响应的集成测试验证隔离效果。
• 更新模型或检索来源前，可以保留固定查询集比较证据变化，再检查变化原因，避免只凭回答看起来通顺就放行。