RAG 找到内容之后，谁能证明它可信？

内容能由RAG检索出来，可信与否却难以分辨；为破解知识系统的信任难题，OKF v0.2引入五类信任信号。
核心内容：
1. RAG流程只能完成内容检索，无法判断其可信度，例如是否过期或属于非权威版本
2. 基础形态维持简洁，并加入机器可读取的信任信号：OKF v0.2设计逻辑
3. 来源、信任度与时效性等判断维度，构成五类信任信号的方向

先给出结论：

内容是否可信、有没有过期、是不是当前版本，并不会因RAG “找到相关内容”而自动得到判断。OKF v0.2 正是以新增的五类信任信号补足这一层。

知识库、RAG、LLM Wiki 和 OKF，是我上周所写一篇文章讨论的对象。

我当时得出的结论是：RAG 更像知识的查询和消费层，LLM Wiki 侧重持续整理知识，而 OKF 试图实现知识在不同工具间的表示与交换。

那篇文章发布仅几天，OKF 就出现了一项值得继续关注的更新。

2026 年 7 月 24 日，Google Cloud 发布 Open Knowledge Format v0.2。它没有把格式变得更重，也没有增加一套复杂平台。Google Cloud 在原文中直接把问题写成：

换句话说，当知识日益由 Agent 生成和维护，又交由另一批 Agent 消费，系统依据什么相信其中某条内容？

这正是许多 RAG 项目随后真正面对的一道门槛：系统找到内容之后，应当如何判断它是否可以使用？

一、检索命中并不代表答案可信

最常见的 RAG 流程其实并不复杂：

1. 先切分文档并建立索引；
2. 再由用户提出问题；
3. 系统检索相似片段；
4. 最后由大模型结合片段生成答案。

这套流程处理的是“如何从大量材料中找出与问题有关的内容”。

然而，相关性并不等同于可信度。

假设系统一次检索出三份价格说明：

• 其中一份来自已失效的旧方案；
• 一份属于销售人员的临时笔记；
• 还有一份是当前已获审批的版本。

这三份文本可能都与问题高度相关。向量相似度能帮助系统发现它们，却无法天然识别哪份仍有效、哪份更加权威，以及哪份只能用作线索。

问题并非只存在于检索端。长上下文研究表明，即使正确材料已经进入上下文，模型利用材料的能力仍会受其位置与上下文长度影响。因此，“已经交给模型”不代表“模型必然正确使用”。

因此，可靠的知识系统至少应分别处理三件事：

• 检索出相关内容；
• 判断这些内容是否可信；
• 约束模型使用内容的方式。

RAG 主要强化第一项，而 OKF v0.2 开始把第二项转化为机器能够读取的结构。

二、更多正文并不是 OKF v0.2 的新增内容

一段 YAML frontmatter 配合 Markdown 正文，仍是 OKF 简单的基础形态。

“这是什么”是 v0.1 借助 frontmatter 主要描述的内容，例如：

• type
• title
• description
• resource
• tags

到了 v0.2，新增的是另一组信号。这些信号不再继续描述内容，而是帮助使用者在阅读正文之前作出判断。

Google Cloud 将相关判断总结为五个问题：

1. provenance —— 产生这条知识所依据的材料是什么？
2. trust —— 对它的相信程度应该有多高？
3. freshness —— 到了现在，它的效力是否还在？
4. lifecycle —— 当前版本是否依然是它？
5. attestation —— 约定的计算方法是否确实产生了这个数值？

规范将其概括为：

一层“知识信任信号”，由这五个问题共同搭建起来。

这些字段并非全部属于强制要求，这是理解 OKF v0.2 时需要留意的一点。type 始终必需的字段仍然只有一个，其余信号均可逐步采用。

这种设计十分克制：它不假定每个团队都需要相同的治理流程，而是优先让机器能够区分“已核验”与“未核验”、“当前”与“过期”、“有来源”与“无来源”。

三、让 Agent 完成判断后再阅读，才是真正关键的变化

正文中写一句“本内容已审核”并不够，这些字段为什么需要进入 frontmatter？

原因是许多知识检索根本不会进入完整阅读正文的阶段。

筛选通常是一个 Agent 处理几千个知识对象时最先进行的环节：

• 类型与当前任务是否匹配？
• 内容是否来自获准使用的来源？
• 是否已经由人工或流程完成验证？
• 内容是否已经超出有效期限？
• 是否已有更新的替代版本？

如果这些信息只能埋在正文中，系统必须先读取大量文本，再识别不应使用的内容。这不仅浪费 token，还容易使过期或低可信内容提前进入生成上下文。

检索流程中能够设置一道轻量闸门，前提是把信任信号纳入结构化元数据：

使用条件被置于语义检索与生成之间，并不意味着语义检索会由元数据取代。

知识检索开始判断“能不能用”，而不再把“像不像”作为唯一回答。

四、“数字从哪里算出来”才是 Attestation 处理的问题

在这五类信号之中，attestation 有必要单独讨论。

来源能够说明一条结论参考了哪些材料，验证记录则能表明谁曾检查它；但有些答案还须进一步证明，本次展示的数字是否真正按照规定方法计算。

“本月收入”可能已经具备获批的计算口径。若Agent每次都临时编写一条表面合理的 SQL，并将结果作为正式数字输出，这种做法并不合适。

OKF v0.2 为 Attested Computation 它定义了下面这种表达方式：

• 声明获准使用的计算方法；
• 明确指定执行方式；
• 要求执行过程返回 receipt；
• 本次执行及结果，交给具备确定性的 attester 进行检查；
• 知识过期或验证失败时，发出提醒或拒绝展示。

应当拆开检查“这一次是否按定义执行”与“定义是否仍正确”；关键并非采用哪一种 SQL，也不在于选择什么执行平台。

• 知识定义是 verification 的检查对象；
• attestation 用于检查单次运行。

这一点对 Agent 十分重要：某个定义即使刚通过人工审核，也不能保证 Agent 本次必然按其执行；反过来，一次计算完全合规，同样无法证明所引用的定义尚未过期。

五、这依旧不是自动可信系统

只要元数据得到补齐，知识就会可信——看到 provenance、verified、stale_after 这些字段时，这种新的误解很容易出现。

事实并非如此。

字段只能记录治理结果，无法代替组织实施治理。

如果一个团队没有清楚规定：

• 哪些来源能够成为正式依据；
• 谁有权确认一条知识；
• 需要间隔多久重新核查；
• 发生版本冲突时由谁处理；
• 哪些计算必须经过批准流程；

格式正确的自我声明，仍可能是再完整的 frontmatter 所能提供的全部。

存储、服务与查询基础设施不由 OKF 规范规定，领域 Schema 也不会被它替代；至于每条知识正确与否，它同样不设中央权威进行判断。这些都是该规范明确划定的边界。

所以，“自动建立可信知识库”并非 OKF v0.2 的价值所在，其价值是：

信任的真正来源，仍是来源、责任人、审核流程与可复现证据。

六、企业知识库可以优先补充哪些信息？

现有知识库不必等到采用完整标准，便可先为高频知识对象补齐最基本的信任信息。

我建议先从以下八项着手：

接下来，把相应使用规则连接到检索流程：

• 高风险结论不能直接来自未核验内容，这类内容仅能充当线索；
• 已经过期的内容默认不进入答案上下文；
• 发生冲突时应展示冲突，不能让模型静默作出选择；
• 对于数值类答案，应保留计算过程或运行凭证；
• 内部知识与公开内容应采用不同的权限和披露边界。

完成这一步后，知识库才能从“可以搜到文档”逐渐转向“能够提供附带条件的答案”。

七、可信知识还须具备更新闭环

一条知识通过一次核验，并不表示今后都能不经判断直接使用。

来源可能变化，规则也会调整；旧版本会被取代，实际使用还会暴露此前未发现的问题。因此，可持续的知识系统仍需建立如下闭环：

1. 依据原始资料生成候选知识；
2. 核验其来源、状态和版本；
3. 在具体任务里供 Agent、问答或搜索使用；
4. 记录错误、冲突以及缺失反馈；
5. 更新相应知识并再次核验。

该闭环的关键，是把知识维护责任重新纳入系统，而不是让每次回答都从头作出判断。

结语

同一个知识库分层框架，在上一篇文章里被我用来容纳 RAG、LLM Wiki 和 OKF。

OKF v0.2 让这套框架变得更加清晰：

• RAG 处理“应该去哪里找”；
• “怎样持续整理”由 LLM Wiki 解决；
• OKF 处理“如何表示与交换”；
• “使用前怎样判断”这个问题，开始由 v0.2 新增的信任信号作答。

知识治理的复杂性并未被它消灭；它所改变的，是治理不必再完全隐于正文角落、流程说明和人脑之中。

随着 Agent 开始批量产出知识，这一步会愈发重要。未来真正稀缺的或许不是内容，而是能够回答以下问题的证据：

参考文献

[1] Google Cloud. “Open Knowledge format v0.2 tackles agentic trust.” Google Cloud Blog, 2026-07-24. https://cloud.google.com/blog/products/data-analytics/okf-v0-2-adds-trust-signals/

[2] GoogleCloudPlatform. Open Knowledge Format — Version 0.2 Specification. Knowledge Catalog, 2026. https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md

[3] Lewis, P., et al. “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” Advances in Neural Information Processing Systems, 2020. https://arxiv.org/abs/2005.11401

[4] Liu, N. F., et al. “Lost in the Middle: How Language Models Use Long Contexts.” Transactions of the Association for Computational Linguistics, 2024. https://arxiv.org/abs/2307.03172

登录后查看剩余 70% 内容