停止切分文档!OKF让企业AI知识库更靠谱,幻觉率暴降83%

每个团队的第一个RAG管道都长得一样：四个方框——文档上传、固定切分、向量数据库、LLM。下午就能跑通demo，上线后问题接踵而至——答案过时、缺乏关联、无法治理，模型在碎片中猜测。

在Mattrx这个多租户营销分析SaaS（.NET 9 + Azure SQL + Python FastAPI AI服务）中，盲切分带来三个核心问题：知识碎片化导致幻觉率高达18%，缺乏时效性管理使过时答案占比11%，无法处理跨文档的多跳问题。传统做法把文档切成无意义的文本块，指望余弦相似度重新拼凑含义，就像把一本书撕成碎片扔进黑箱，指望别人拼出完整故事。

解决方案不是更大的向量索引，而是停止存储文档，开始存储知识。这就是Open Knowledge Format（OKF）。需要明确的是，OKF不淘汰向量检索——向量仍然负责召回。OKF淘汰的是盲切分——把不透明的文档切成脱离上下文的碎片，指望余弦相似度重新组装含义。在Mattrx中，用OKF + 上下文引擎替代盲切分后，助手的幻觉率从18%降至3%，过时答案率从11%降至1.5%。

架构全景

OKF的核心思想是把每个知识单元变成可治理、有类型、有关联的实体。一个OKF单元包含Markdown正文加结构化元数据：id、type、owner、version、valid_from/valid_until、visibility，还有relationships、apis、schemas和business rules。正文仍然会被嵌入；元数据是引擎进行过滤和排序的依据。

知识图谱是OKF的关键。传统切分的文本块是孤立岛屿，向量相似度只能找到”听起来相似”的文本，无法找到”有联系”的文本。OKF定义了relates_to、supersedes、governed_by、depends_on等关系边，形成知识图谱。向量找到入口，图谱遍历整栋建筑。

上下文引擎是OKF知识转化为prompt的桥梁。它整合了混合检索、向量检索、图检索，按优先级组装prompt，确保约束条件优先，预算紧张时合规规则不被裁剪。

核心对比：

核心模块拆解

从文档到知识单元

文本块没有身份——无法说明谁拥有它、何时过期、与什么相关。OKF的原子单元是Markdown正文加结构化元数据。一旦单元有了valid_until字段，引擎就可以拒绝基于过期知识回答问题，这直接将过时答案从11%降至1.5%。

每个OKF单元包含以下元数据字段：

• id：唯一标识符
• type：知识类型，如billing-rule、product-catalog、runbook
• owner：所有者，负责维护该知识单元
• version：版本号，支持变更追踪
• valid_from / valid_until：有效期，控制知识的时效性
• visibility：可见性，控制多租户场景下的访问权限
• relationships：关系边，定义与其他单元的连接
• apis：实时API引用，确保答案反映当前状态
• schemas：结构化数据模式
• business rules：业务规则，作为一等数据被引擎强制执行

关系与模式：知识图谱

文本块是孤立岛屿；向量相似度只能找到”听起来相似”的文本，无法找到”有联系”的文本。OKF将关系边设为一等对象（relates_to、supersedes、governed_by、depends_on），并为结构化单元定义模式——共同构成语料库上的知识图谱。图检索从语义种子开始，沿着这些边扩展，这就是”Growth客户中途降级如何计算费用”这类跨越三个文档的问题变得可回答的原因。

关系类型包括：

• relates_to：关联关系，如产品与定价规则
• supersedes：替代关系，如新版本替代旧版本
• governed_by：治理关系，如业务规则约束知识单元
• depends_on：依赖关系，如计算逻辑依赖配置参数

API与业务规则：实时数据与治理

“我们的计划有Starter、Growth、Scale……”这样的快照在目录变更当天就失效了，而写在段落中的规则只是模型可以忽略的建议。OKF单元引用实时API（通过受治理的工具层在查询时解析），确保答案反映当前目录状态；同时链接到business-rule单元（enforcement: hard），引擎将其作为约束条件注入。”推荐废弃方案”从反复出现的问题变为零。

上下文引擎：检索与组装

OKF是知识的存储方式；上下文引擎是知识转化为prompt的方式。

检索层：Top-k余弦相似度只是一个信号——它会错过精确术语匹配（如活动ID、错误代码）和相关但不相似的单元。引擎运行混合搜索（BM25 + 向量）进行召回，向量检索捕捉细微语义，图检索获取关联单元——所有检索都按租户范围限定，并过滤为当前有效单元（onlyValid: true），元数据免费承担安全和质量工作。这种组合是幻觉率从18%降至3%、忠实度达0.96的核心原因。

记忆、工具调用与prompt组装：记忆提供已知信息；工具调用获取OKF单元引用的实时数据；prompt组装按优先级顺序将所有内容打包到严格的token预算——约束条件优先（永不裁剪），然后是记忆，接着是排序后的知识，最后是实时数据。排序是设计决策：预算紧张时绝不能静默丢弃保持答案合规的规则。这就是上下文从14k tokens降至3.5k tokens但准确率反而提升的原因。

边界条件

OKF需要投入结构化工作——在结构存在且重要的地方投入。以下情况应跳过OKF：

• 小规模/静态语料库
• 真正无法结构化的知识
• 无人能负责维护元数据（腐烂的元数据比没有更糟）
• 尚未搞定普通混合RAG + 交叉编码器重排序（OKF是下一层，不是第一层）

改造时不要一步到位——先转换高价值、高变动领域（先做计费，再做产品，再做运行手册），长尾部分保持普通切分即可。

重构后知识库转为约11000个OKF单元（Markdown + 元数据 + 关系 + API + 模式 + 业务规则），关键指标全面提升：

• 幻觉率：18% → 3%；忠实度：0.96；答案相关性：0.91
• 每次调用上下文token：14k → 3.5k——结构让引擎附上”正确的东西”，而非”所有东西”
• 过时答案率：11% → 1.5%（valid_until + 元数据时效性）
• 多跳问题：从不答到可答（通过图检索）
• 废弃方案推荐：从反复发生到零（业务规则作为数据强制执行）

需要转变的一个认知：文本块是没有身份、没有所有者、没有过期时间的文本碎片；OKF单元是上下文引擎可以推理的可治理、有类型、有关联的知识块。停止索引文本，开始索引知识。

架构关系：混合检索（BM25 + 向量）召回OKF单元，图检索遍历关系边扩展关联知识，记忆提供已知信息，工具调用获取实时API数据，上下文引擎按优先级组装Prompt

如果正在做企业级RAG，可以列出所有进入LLM上下文的数据源，检查是否存在过期知识和碎片化问题，评估当前检索策略是否覆盖了精确匹配、语义相似和关联遍历三种维度，考虑是否需要引入OKF治理机制。