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此次新增的内容

OKF依旧保持简单的基础形态：一段YAML frontmatter，加上Markdown正文。

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% 内容