企业级RAG的真正需求：知识图谱还是结构化方案？

在大型语言模型应用快速发展的今天，如何构建高效的企业级知识库已成为技术团队关注的核心议题。近期，两个开源项目引发了广泛关注：Karpathy提出的LLM Wiki概念和Graphify项目（已在GitHub获得约3.5万Star）。这两个项目分别代表了不同的技术路线——前者强调知识的预编译与结构化组织，后者则侧重于自动化的知识图谱生成。那么，对于企业级RAG系统而言，这些方案是否真的能解决核心问题？

LLM Wiki：知识预编译的思路值得借鉴

本文通过构建一套包含30份水处理设备集成合同的测试基准，对基础RAG、LLM Wiki模式和受控schema综合方案进行了系统性对比测试。测试问题涵盖简单事实查询、条件筛选、跨合同综合、主补充协议关系、风险识别等六大类型，共计48道测试题。通过这套基准，我们可以更清晰地看到不同技术方案在实际业务场景中的表现差异。

Graphify：自动化图谱的局限性

Graphify项目试图将文件夹直接转化为可查询的知识图谱，通过Tree-sitter分析代码结构、LLM提取语义关系，输出交互式图谱和结构化报告。在代码场景测试中，Graphify能够识别出Client、Response、Request等核心抽象，对于代码库的结构化摸底有一定价值。 然而，当我们将它应用于合同文档时，问题变得复杂。合同中的关系不是显式的函数调用，而是语义化的业务约束——补充协议如何修改主合同、验收单是否影响违约金条款、质保期按哪份文件执行，这些关系需要业务理解而非语法分析。更关键的是，合同关系必须按受控schema抽取，不能让模型自由生成，否则图谱会迅速变成一堆看似相关但无法在业务上使用的关系。 因此，Graphify更适合作为代码场景的架构摸底工具，而非企业合同知识库的直接解决方案。

受控Schema：企业级合同知识库的正确打开方式

基于测试结果，我们提出了一个五层架构的企业级合同知识库方案： 第一层是文件解析，负责处理Word、PDF、扫描件等文档格式，保留页码、标题、表格位置等关键信息。第二层是结构化字段抽取，将合同编号、客户、金额、日期、付款节点、质保期、违约金等字段提取到数据库中。第三层是条款级索引与受控图谱，将合同按条款切分而非固定字数切分，并按业务schema建立关系（如补充协议修改主合同、验收单对应项目等）。第四层是问答层，实现权限过滤、混合检索和答案生成，确保答案引用原文。第五层是评测与审计，通过测试集、引用检查和人工复核确保系统质量。 在30份合同、24道核心问题的测试中，这套方案获得了100%的答案准确率和引用准确率，显著优于基础RAG的25%准确率。

工程实践中的关键挑战

将LLM Wiki或Graphify这类工具直接应用于企业合同知识库，目前主要面临四个工程挑战： 首先是成本问题。合同数量越多，预编译、抽取、更新、复核的成本越高，不能每次新增合同就无差别生成大量页面和关系。其次是可控性问题，合同关系必须按业务schema抽取，不能让模型自由生成，否则后续问答时难以判断一条关系是否可作为依据。第三是权限问题，合同天然涉及客户、部门、项目、角色的权限边界，知识库不仅要答对，还要确保不该看的合同绝对不能被召回。第四是合规与审计问题，企业合同问答不能只给出一个看似合理的答案，还需要能追溯到原文，解释引用了哪份合同、哪个条款、哪个字段。

如有侵权，请联系删除。