OpenKB 评测：知识编译器比 RAG 更好吗？

OpenKB 是 LLM 知识编译器理念中最清晰的可运行实现之一，但它不能直接替代企业 RAG。它读取来源，撰写摘要与概念页面，更新交叉引用，再让 agent 查询不断积累的 wiki。工作单位因此从“为这次问题找 chunks”变成“维护一套可复用的知识资产”。

这个模式来自 Andrej Karpathy 在 2026 年 4 月发布的 LLM Wiki idea file。商业问题已经不是这个想法听起来好不好，而是把构建成本、信息损失、权限和维护都算进去后，OpenKB 能否比向量 RAG 交付更好的可验证答案。

我们在 2026 年 8 月 11 日审阅项目和近期研究后的结论是：对于精选、重综合的知识工作，值得试点 OpenKB；对于大型、高频变化或权限敏感的语料库，应保留向量 RAG 或混合架构。本文只负责“OpenKB 评测”和“OpenKB vs RAG”的产品采购意图。另有面向企业的 Open Knowledge Format 指南负责可移植格式，RAG 生产就绪清单负责检索、权限和答案控制。

OpenKB 是什么？

OpenKB 是一款开源 Python CLI 和 Web Workbench，可把文件与 URL 编译成持续存在、互相链接的 Markdown wiki。OpenKB 官方仓库列出 PDF、Word、PowerPoint、Excel、HTML、CSV、文本、Markdown 和 URL 等输入。编译过程创建或更新来源摘要、概念、实体、索引和日志。查询、聊天、可视化、幻灯片和 agent skill 生成器再消费这套 wiki。

短文档通过 MarkItDown 转换并按文本读取。长 PDF 则依赖 PageIndex 的无向量树索引方法：先建立类似目录的层次结构，再让 LLM 导航到相关章节。因此，“没有向量数据库”不等于“没有检索”。它是用文档结构和推理取代 embedding 相似度。

知识编译器与向量 RAG 有什么不同？

向量 RAG 通常存储 chunks 和 embeddings，每次提问取 top-k，再组合答案。OpenKB 把更多综合工作移到 ingest 阶段。一个新文档可能在任何人提问前就改写多张概念页。

有效的比较不是“旧 RAG 对新魔法”。OpenKB 自身也把编译 wiki 与基于推理的检索结合起来。成熟系统还可以检索编译页面、原始来源或两者。架构是连续谱：原始 chunk 检索、分层检索、编译摘要、显式知识图和缓存全上下文可以共存。

OpenKB 免费吗，真实成本是什么？

软件使用 Apache 2.0 许可证，因此商业使用没有 OpenKB 许可费。我们检查时，PyPI 当前软件包记录显示 0.4.4 版于 2026 年 7 月 10 日发布，并把项目归类为 alpha。这是成熟度信号，不是批评。采购应该固定版本、测试升级，并为快速变化的依赖安排 owner。

总成本至少有六部分：

1. 编译 token。每个来源都可能触发摘要、概念、实体和交叉引用工作，一次 ingest 会更新多页。
2. 检索和答案 token。查询仍有成本。无向量不等于无模型或零 token。
3. 文档处理。本地解析覆盖常见输入，复杂 OCR 和可选 PageIndex Cloud 会增加另一条供应商与成本路径。
4. 人工审阅。需要有人检查事实压缩、矛盾、引用和敏感输出。
5. 企业控制。SSO、角色、租户边界、审计、secret、备份和删除都属于产品工程。
6. 评测与运维。黄金问题、来源变化回归、延迟、重试、模型变化和事件处理需要持续 owner。

正确的成本单位不是“每个 embedding 页面的价格”，而是每个被接受、有来源支撑的答案或完成的研究任务。把编译、查询、重试和审阅分钟都算进去。我们的 AI agent 单次动作成本框架提供这个分母。

独立研究中，编译知识胜过 RAG 吗？

没有一种架构能赢下所有知识任务。目前最有用的证据是一项基于 24 篇论文和 13 个问题的向量 RAG 与 LLM 编译 wiki 预注册比较。wiki 更擅长连接不同论文的发现，其引用页面也更常精确支撑论断。向量 RAG 通过了预注册的单一事实查找测试，并使用少得多的查询 token。带问题分解的 RAG 以更低 token 成本追回大部分综合优势，但没有追回逐条论断引用优势。

这项研究规模有意控制得很小，而且使用 LLM judge，不是人类评审。它不能证明 OpenKB 胜过生产 RAG，却给 CTO 更好的评测模型：分别衡量综合结构、逐条论断支持和总成本。单一“答案质量”平均分会隐藏真正的采购取舍。

第二篇论文暴露了核心失败模式。WiCER 在 6,800 个问题上评测 wiki-memory 编译。在报告的设置中，盲目编译因丢弃关键事实，得分远低于原始全上下文，并出现 53% 到 60% 的灾难性失败率。迭代的评测和修正循环追回了大量质量。结论很直接：编译必须配诊断问题和修复轮次，不能只做一次摘要 prompt。

Google OKF 对 OpenKB 有什么影响？

可移植性是这个方法最强的部分之一。Google Cloud 于 2026 年 6 月推出 Open Knowledge Format v0.1，为 Markdown、YAML frontmatter、链接、索引文件和日志定义了一小块互操作接口。OpenKB 表示其 wiki 页面已支持 OKF。

这意味着，即使试点失败，也可能留下可读、带版本的资产。团队能在编辑器中检查，用 Git 迁移，或交给另一个搜索与 agent 系统。但它不保证语义正确、完美互操作，也不保证 v0.1 演进后仍然合规。应在 CI 中验证 bundle，并把原始来源和编译页面分开。

OpenKB 达到企业就绪了吗？

OpenKB 已适合受控的开发者或研究试点，但其公开控制面还不是完整的企业知识平台。当前 Workbench 和 REST API 让上传、编译、查询、聊天、lint 和重编译更容易。文档中的认证模型仍然刻意采用 local-first。

官方 REST API 指南说明，认证默认关闭，可通过一个 bearer token 开启。文档明确警告：绑定到非 loopback host 却未设置 token，会让所有可访问知识库暴露。一个共享 token 能保护试点 endpoint，但它不等于 SSO、用户身份、基于角色的访问、文档级授权或租户隔离。

对于敏感企业来源，检索时授权是硬边界。如果用户能看政策 A 但不能看政策 B，把两者编译进同一张概念页，可能在查询层过滤前就泄露受限事实。应建立保留权限边界的编译域，或不把这些来源交给 compiler。我们的 permissions-first RAG 架构解释了 SharePoint、Confluence 和 Drive 中的同一条规则。

什么时候选 OpenKB、向量 RAG 或混合方案？

不要从技术开始，要从标注过的问题集开始。如果大多数问题是“政策 X 当前退款上限是多少？”，检索和权限占主导。如果问题是“十二份报告中，我们对市场 Y 的假设如何变化？”，持久综合价值更高。如果两者都重要，就运行两条路径并按问题类型路由。

十天 OpenKB 试点计划

1. 选择一个有 owner 的领域。使用 20 到 50 个已批准来源和一名负责的领域专家，不要从整个公司网盘开始。
2. 保留证据层。对原始来源做 hash、记录日期，并把编译页放进独立目录。wiki 不能悄悄替代原件。
3. 建立 30 个盲测问题。覆盖单一事实、跨来源综合、矛盾、无答案、权限陷阱和近期变化。
4. 冻结三条 baseline。在相同来源与模型预算下，比较现有搜索或人工流程、简单向量 RAG 和 OpenKB。
5. 逐条评估论断支持。检查每个重要句子是否由引用来源支撑，而不是只看答案是否完整。
6. 测试信息损失。加入冲突或更新来源后重编译，检查什么变化、消失，以及旧说法是否仍可找到。
7. 攻击边界。测试文档内 prompt injection、未授权来源混合、恶意链接、超大文件、解析失败和模型供应商中断。
8. 计算完整循环。统计 ingest 和 query token、p50、p95、重试、审阅时间、错误答案和恢复工作。
9. 设定扩展 gate。只有可验证质量或审阅时间的改善足以支付控制和运维时才继续。
10. 保持可逆退出。导出 wiki、schema、评测集和来源清单，确保其他系统能够接手。

Wavect 的 AI 赋能服务可以在你的基础设施上构建这次比较，而不是从 demo 宣布赢家。Twinsoft AI 案例展示了我们如何处理可追溯 AI 输出与审阅者控制。在选择商业模式前，可以比较AI 赋能与通用 AI 咨询，判断你需要实施还是策略文件。

研究边界

状态检查日期为 2026 年 8 月 11 日。本文是基于公开项目文档和研究的独立架构与采购评测，不是赞助内容、渗透测试，也不是对私有语料库的 hands-on benchmark。OpenKB、软件包、API 和 roadmap 可能快速变化。采购前请固定版本并核对最新文档。