AI如何助力电商卖家制作爆款短视频？从创意到生产解析
2026-07-29 3431662
2026-07-29 0
内容能由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 在原文中直接把问题写成：
“once agents are writing to the corpus, can it really be trusted?” [1]
一批 Agent 生成并维护的知识，越来越多地交由另一批 Agent 消费；面对其中任意一条内容，系统的信任依据是什么？
这正是许多 RAG 项目实际面对的下一道门槛：系统找到内容后，该如何判断它是否可以使用？
常见的 RAG 流程并不复杂：
这一流程解决的是从大量材料中检索与问题相关的内容。
然而，相关性并不等于可信度。
假设系统同时找到了三份价格说明：
这三份文本都可能和问题高度相关。向量相似度能协助系统检索它们，却无法天然分辨哪份仍然有效、哪份更具权威性，以及哪份只能用作线索。
即便正确材料已被放入上下文，模型也未必能正确使用，因为长上下文研究发现，这种能力还受材料位置与上下文长度制约。因此，问题并非仅在检索端：“提供给模型”与“被模型正确使用”并不是一回事。
要让知识系统可靠，至少有三件事必须分开处置：
RAG 重点强化第一件事，而 OKF v0.2 开始将第二件事转化为机器能够读取的结构。
一段 YAML frontmatter 与 Markdown 正文相配，便构成了OKF 仍然简洁的基础形态。
“这是什么”是v0.1 通过 frontmatter 重点描述的内容，例如：
typetitledescriptionresourcetags另一组信号在v0.2 中被加入，其作用并非延续内容描述，而是供使用者在正文读取之前作出判断。
这些判断被Google Cloud 整理为以下五个问题：
规范将其概括为：
“OKF v0.2 makes provenance, trust, lifecycle, and attestation first-class.” [2]
一层“知识信任信号”由这五项问题合在一起形成。
这些字段并未被OKF v0.2 一概列为强制项，这一点需要注意。type 唯一在任何情况下都不可缺少的仍是原字段，其他信号则允许分步采用。
这套设计保持了克制，因为它不预设每个团队采用相同治理流程。机器首先获得的是区分能力，可以识别“已核验”与“未核验”、“当前”与“过期”、“有来源”与“无来源”。
若在正文写一句“本内容已审核”即可，为什么还要将这些字段置于 frontmatter？
原因是许多知识检索根本不会进入完整阅读正文的阶段。
几千个知识对象摆在面前，一个 Agent 往往要先筛选：
系统若只能从正文中获取这些信息，就得读完大量文本，才能排除不应使用的内容。结果不仅是token被浪费，过期或低可信内容还可能在判断之前进入生成上下文。
结构化元数据收纳信任信号之后，一道轻量闸门便可被置入检索流程：
先从候选内容做相关性检索，再按来源、状态、时效与版本过滤，随后读取正文并生成答案
使用条件被安插在语义检索之后、生成之前，元数据并没有因此取代语义检索。
准确地说，知识检索除了判断“像不像”，也开始判断“能不能用”。
五类信号之中，需要另作说明的是attestation。
来源能够说明一条结论参考了哪些材料，验证记录可以表明由谁检查，但部分答案还须进一步证明：本次展示的数字是否确实依照规定方法计算。
“本月收入”例如可能存在已经审批的计算口径。正式数字不应来自Agent 每次临时编写的一条貌似合理的 SQL。
OKF v0.2 为 Attested Computation 它定义了一种表达方法：
重点不在某种 SQL 或执行平台，而在于把“定义是否依然正确”与“本次是否依照定义执行”拆分为两项检查。
这对 Agent 十分重要。定义刚通过人工审核，并不意味着 Agent 本次一定按其执行；反过来，某次计算过程完全合规，也不能证明引用的定义尚未过期。
provenance、verified、stale_after 这些字段可能让人误以为：元数据只要齐全，可信知识便自然形成。
事实并非如此。
字段只能记录治理结果，无法代替组织实施治理。
如果一个团队尚未明确：
即使完整具备，frontmatter 也可能仍是自我声明，只不过格式正确。
边界在OKF 规范中已有明确界定：领域 Schema 不由它替代，存储、服务及查询基础设施不由它规定；它也不会设立中央权威，替各条知识判断正误。
因此，“自动建立可信知识库”不是OKF v0.2 的价值所在；其价值是：
它使治理结果能够随知识一同记录、交换、过滤并接受检查。
来源与责任人、审核流程以及可复现证据，才是真正产生信任的基础。
现有知识库无须等到采用完整标准，便可先为高频知识对象补充最小信任信息。
我建议先从以下八项着手：
| 字段 | 需要回答的问题 |
|---|---|
type | 这属于什么类型的知识？ |
source | 它源自哪一份原始材料？ |
owner | 由谁承担确认和维护责任？ |
verified_at | 最近一次由谁在何时核验？ |
effective_from | 它从什么时候起生效？ |
stale_after | 它在什么时候必须复查？ |
status | 当前处于草稿、有效、弃用还是冲突状态？ |
supersedes | 它取代的是哪一个旧版本？ |
随后，把相应使用规则接入检索流程：
完成这一步，知识库才会从“可以搜到文档”迈向“可以提供附带条件的答案”。
知识通过一次核验，不代表今后始终可以直接使用。
来源可能变化，规则可能调整，旧版本会被替换，实际使用还会暴露此前未发现的问题。因此，可持续的知识系统还必须建立闭环：
这个闭环的关键，是把知识维护责任放回系统，而非每次回答时都从零开始判断。
同一个知识库分层框架中，我在上一篇文章纳入了OKF、LLM Wiki 和 RAG。
这个框架因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% 内容