我对比评测了经典向量 RAG、谷歌新 OKF 格式以及两者组合——同一语料、同样 7 个问题，全部本地运行（Ollama + ChromaDB）

谷歌云于 6 月 12 日发布了 OKF（开放知识格式）——一种规范，用于将精选知识存储为带 YAML frontmatter 的 markdown 文件目录。每个文件一个概念，文件之间互相链接，并带有用于渐进式披露的 index.md。唯一必填字段是 `type`。我想知道它是否真的解决了实际问题，于是构建了一个测试语料并进行测量。一切都在本地运行：qwen3:8b + nomic-embed-text + ChromaDB，无任何外部 API。 搭建 - 语料：60 个虚构但真实的公司文档 markdown 文件（wiki、表结构、ADR、40 个支持工单）。85 个块，800/100 切分。 - OKF 包：9 个精选概念，覆盖相同内容。 - 7 个问题，每个问题都旨在触发不同的检索失败模式。 结果（7 个问题） | 方法 | 答对题数 | token 数 | |---|---|---| | RAG | 2 | 6341 | | OKF | 3 | 8625 | | OKF+RAG | 4 | 8435 | 没有全对。组合层答对题数是纯 RAG 的两倍，token 多约 33%。 让我惊讶的一点 问题：“我们如何计算收入？” 语料中有一份 2023 年文档（已弃用，冗长，4000 字符）和当前的 2026 年规范（精简，500 字符）。弃用文档被切成 7 个块，当前文档切成 1 个块。top-5 检索结果中有 3 个块来自弃用文档。正确文档在 85 个块中排第 15——落后于一个术语表、一个客户表结构和一张关于加那利群岛运费的支持工单。把 k 提高到 15 也没用：你会拉进来 6 个说错内容的块，而不是 1 个说对内容的块。重排序器也无法修复——块文本中没有任何信息表明哪个是当前的。日期不在块中。 其他触发的失败模式 - 分块器把一个 18 列的结构表切碎了。正确的文件确实在上下文中；但表不在。模型在 k=3 和 k=5 时都说“我不知道”。 - 组合：一个指标定义需要 3 条规则，分别存在于 3 个独立文件中。RAG 检索到 3 条中的 2 条，并自信地回答，引用了来源，从未暗示可能缺了什么东西。 - 有趣的模式：当它几乎什么都没有时，它说“我不知道”；当它几乎什么都齐了时，它却什么也不说。它恰恰在最昂贵的时候沉默。 OKF 输在哪里 长尾问题。"三月份有没有发生过重复订单的事件？"——纯 RAG 在 40 个杂乱且未经审核的工单中轻松答对。手工去策展这些工单简直荒谬。仅用 OKF 则答不上来。 术语说明 我用“RAG”作为经典向量实现的简写。严格来说，一个在 OKF 索引中导航的 agent 也是一个 RAG 流水线——只是用结构化检索代替了向量检索。更准确的表述是“经典向量 RAG vs 基于 OKF 的结构化检索”。有人正确地指出了这一点。 完整代码、语料、包和原始 results.txt：https://github.com/JoaquinRuiz/rag-vs-okf 执行 git clone + uv sync 即可复现。好奇是否有人用更大的模型得到不同数字——第 4 个问题在我多次运行中不稳定。