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 在原文中直接把问题写成：
“once agents are writing to the corpus, can it really be trusted?” [1]
也就是说，当知识越来越多地由 Agent 生成、维护，再由另一批 Agent 消费时，系统凭什么相信其中的一条内容？
这也是很多 RAG 项目真正遇到的下一道门槛：内容被找到以后，系统如何判断它能不能用？
一、检索命中，不等于答案可信
最常见的 RAG 流程并不复杂：
文档被切分并建立索引； 用户提出问题； 系统找到相似片段； 大模型结合片段生成答案。
它解决的是“从很多材料里找到与问题相关的内容”。
但相关性不是可信度。
假设系统同时检索到三份价格说明：
一份来自已经失效的旧方案； 一份是销售人员的临时笔记； 一份是当前已审批版本。
三份文本都可能与问题高度相关。向量相似度可以帮助系统把它们找出来，却不会天然知道哪份仍然有效、哪份更权威、哪份只能作为线索。
问题也不只出在检索端。长上下文研究显示，即使正确材料已经放进上下文，模型使用它的能力仍会受到材料位置和上下文长度影响。换句话说，“已经提供给模型”也不等于“模型一定正确使用”。
所以，一个可靠知识系统至少要分开处理三件事：
找到相关内容； 判断内容能不能信； 约束模型应该怎样使用它。
RAG 主要加强第一件事。OKF v0.2 开始把第二件事变成机器可以读取的结构。
二、OKF v0.2 新增的，不是更多正文
OKF 的基础形态仍然很简单：Markdown 正文，加上一段 YAML frontmatter。
v0.1 主要用 frontmatter 描述“这是什么”，例如：
typetitledescriptionresourcetags
v0.2 增加的是另一组信号。它们不是继续描述内容，而是帮助使用者在读取正文前做判断。
Google Cloud 把这些判断归纳成五个问题：
这条知识由什么材料产生？—— provenance 我应该在多大程度上相信它？—— trust 它现在仍然有效吗？—— freshness 它还是当前版本吗？—— lifecycle 这个数值是否按约定的方法计算出来？—— attestation
规范对此的概括是：
“OKF v0.2 makes provenance, trust, lifecycle, and attestation first-class.” [2]
这五个问题共同构成了一层“知识信任信号”。
需要注意的是，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 的价值不是“自动建立可信知识库”，而是：
它让治理结果可以和知识一起被记录、交换、过滤和检查。
真正的信任仍然来自来源、责任人、审核流程和可复现证据。
六、企业知识库可以先补哪几项？
不需要等到采用某个完整标准，现有知识库就可以先给高频知识对象补上最小信任信息。
我建议从下面八项开始：
type |
|
source |
|
owner |
|
verified_at |
|
effective_from |
|
stale_after |
|
status |
|
supersedes |
然后把使用规则接到检索流程里：
未核验内容只能作为线索，不能直接形成高风险结论； 已过期内容默认不进入答案上下文； 存在冲突时暴露冲突，不让模型静默选择； 数值类答案保留计算过程或运行凭证； 公开内容与内部知识使用不同的权限和披露边界。
这一步做完，知识库才开始从“能搜到文档”走向“能提供带条件的答案”。
七、可信知识还需要更新闭环
知识通过一次核验，并不意味着以后都可以直接使用。
来源会变化，规则会调整，旧版本会被替代，实际使用也会暴露原来没有发现的问题。因此，一个可持续的知识系统还需要形成闭环：
从原始资料形成候选知识； 完成来源、状态和版本核验； 让搜索、问答或 Agent 在具体任务中使用； 记录错误、冲突和缺失反馈； 更新知识并重新核验。
这个闭环的重点，是让知识的维护责任回到系统里，而不是让每次回答都重新从零判断。
结语
上一篇文章里，我把 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
