RAG 找到内容以后，谁来证明它可信？

一、检索命中，不等于答案可信

最常见的 RAG 流程并不复杂：文档被切分并建立索引；用户提出问题；系统找到相似片段；大模型结合片段生成答案。它解决的是“从很多材料里找到与问题相关的内容”。

但相关性不是可信度。

假设系统同时检索到三份价格说明：一份来自已经失效的旧方案；一份是销售人员的临时笔记；一份是当前已审批版本。三份文本都可能与问题高度相关。向量相似度可以帮助系统把它们找出来，却不会天然知道哪份仍然有效、哪份更权威、哪份只能作为线索。

问题也不只出在检索端。长上下文研究显示，即使正确材料已经放进上下文，模型使用它的能力仍会受到材料位置和上下文长度影响。换句话说，“已经提供给模型”也不等于“模型一定正确使用”。

所以，一个可靠知识系统至少要分开处理三件事：找到相关内容；判断内容能不能信；约束模型应该怎样使用它。RAG 主要加强第一件事。OKF v0.2 开始把第二件事变成机器可以读取的结构。

二、OKF v0.2 新增的，不是更多正文

OKF 的基础形态仍然很简单：Markdown 正文，加上一段 YAML frontmatter。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 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	它替代了哪个旧版本？

然后把使用规则接到检索流程里：

• 未核验内容只能作为线索，不能直接形成高风险结论；
• 已过期内容默认不进入答案上下文；
• 存在冲突时暴露冲突，不让模型静默选择；
• 数值类答案保留计算过程或运行凭证；
• 公开内容与内部知识使用不同的权限和披露边界。

这一步做完，知识库才开始从“能搜到文档”走向“能提供带条件的答案”。

七、可信知识还需要更新闭环

知识通过一次核验，并不意味着以后都可以直接使用。

来源会变化，规则会调整，旧版本会被替代，实际使用也会暴露原来没有发现的问题。因此，一个可持续的知识系统还需要形成闭环：

1. 从原始资料形成候选知识；
2. 完成来源、状态和版本核验；
3. 让搜索、问答或 Agent 在具体任务中使用；
4. 记录错误、冲突和缺失反馈；
5. 更新知识并重新核验。

这个闭环的重点，是让知识的维护责任回到系统里，而不是让每次回答都重新从零判断。

RAG、LLM Wiki 与 OKF 的分工演进

上一篇文章里，我把 RAG、LLM Wiki 和 OKF 放进了同一个知识库分层框架。OKF v0.2 让这个框架又清楚了一步：

• RAG 解决“去哪里找”；
• LLM Wiki 解决“怎样持续整理”；
• OKF 解决“怎样表示和交换”；
• v0.2 新增的信任信号，开始回答“使用前怎样判断”。

它没有消灭知识治理的复杂性，只是让治理不再完全藏在人脑、流程说明和正文角落里。

当 Agent 开始批量生产知识时，这一步会越来越重要。因为未来最稀缺的可能不是内容，而是能够回答下面这句话的证据：

这条知识为什么值得被相信？

JOTO 企业落地观察

• 对企业部署而言，OKF v0.2 的结构化信任信号意味着知识接入不再仅依赖文档完整性，而需同步配置元数据治理策略。团队必须明确 source、verified_at、stale_after 等字段的维护责任与更新机制，否则元数据将沦为静态标签，无法支撑动态可信决策。
• 这类系统的取舍在于：是否接受将部分治理逻辑前置到元数据层。若跳过 provenance 和 lifecycle 字段的落地，Agent 就无法在检索阶段排除过期或非授权内容，导致后续生成环节被动承担纠错成本，显著增加 token 消耗与幻觉风险。
• 对 RAG 知识工程而言，OKF v0.2 将‘可信’从隐式经验转化为可编程条件。企业需评估现有知识生产流程能否产出稳定、可验证的元数据，例如 verified_at 是否对应真实审核动作，supersedes 是否反映版本管理闭环，否则结构化字段将失去过滤效力。
• AI 安全治理需关注 attestation 机制的落地可行性。当数值类答案要求保留计算过程或运行凭证时，企业必须配套建设确定性执行环境与 attester 校验能力，否则 '按定义执行' 将停留在声明层面，无法形成可审计的计算链路。