RAG 解决“从哪里找到相关内容”GraphRAG 解决“如何理解知识之间的关系”LLM Wiki 解决“如何让知识长期沉淀、持续维护并被人和 AI 共同使用”。关键词RAG、GraphRAG、LLM Wiki、知识库、知识图谱、AI Agent在构建企业知识库、智能问答或 AI Agent 时RAG、GraphRAG 和 LLM Wiki 经常被放在一起比较。它们看起来都在做“让大语言模型使用外部知识”但实际关注点并不相同RAG重点是查询时检索相关文本。GraphRAG重点是建立实体、关系和社区结构支持跨文档推理。LLM Wiki重点是把原始资料加工成可阅读、可维护、可持续演化的知识库。更准确地说这三者不是完全互斥的替代方案而是处在不同层次的技术模式。实际项目中它们也可以组合使用。一、先给结论三者的核心区别对比维度RAGGraphRAGLLM Wiki核心目标找到与问题相关的文本理解实体、关系和全局主题构建可持续维护的长期知识库主要知识单元文档片段、向量实体、关系、社区摘要、文本片段Markdown 页面、目录、双向链接、来源记录知识处理时机查询时召回入库时构建图查询时检索导入时整理后续持续维护典型查询“某个接口怎么使用”“这些文档中有哪些共同主题”“这个项目过去做过哪些技术决策”优点简单、灵活、上线快擅长跨文档和全局分析可读、可审计、可积累主要代价依赖切片和召回质量构建索引成本较高需要持续整理和人工校验适合场景FAQ、客服、产品文档问答研究分析、报告总结、关系发现个人研究、团队知识库、Agent 长期记忆可以先用下面三句话记忆RAG检索相关内容。GraphRAG检索内容并利用知识关系进行推理。LLM Wiki让知识被整理、保存和持续更新。二、为什么仅靠大语言模型不够大语言模型的知识主要存储在模型参数中但参数并不适合直接承载企业内部文档、项目代码、最新制度或个人研究笔记。常见问题包括模型不知道企业内部的私有知识。模型参数中的知识可能已经过时。模型难以给出可靠的来源和证据。面对大量文档时模型无法一次性读取全部内容。文档中的实体、关系和上下文可能被割裂。因此实际系统通常会引入外部知识源并在生成答案前把相关内容提供给模型。三、RAG查询时检索相关文本1. RAG 的基本流程RAG即 Retrieval-Augmented Generation中文通常翻译为“检索增强生成”。典型的 RAG 系统包含以下步骤导入 PDF、网页、Markdown、Word 等文档。将文档切分成多个片段。使用 Embedding 模型将片段转换为向量。将向量保存到向量数据库中。用户提问时将问题向量化。检索相似度较高的文本片段。把召回内容拼接到 Prompt 中。由大语言模型基于这些内容生成答案。RAG 的经典研究工作是 Lewis 等人在 2020 年发表的论文该论文提出将模型自身的参数化记忆与外部非参数化记忆结合起来。RAG 原始论文2. RAG 的优势RAG 最大的特点是结构简单、适应性强。它不需要重新训练大语言模型只需要更新外部文档和检索索引就可以让系统使用新的知识。RAG 比较适合快速上线文档规模较小时构建速度快。可以替换 Embedding 模型或向量数据库。可以使用向量、关键词或混合检索。文档变化后可以增量更新索引。适合对单个问题进行精准回答。3. RAG 的典型问题RAG 的核心判断通常是“哪些文本片段与问题最相似”。但是“语义相似”不一定等于“能够回答问题”。例如用户提出这批项目报告中最常出现的三个风险主题是什么这个问题需要跨越多份文档进行汇总。问题本身可能没有明确指出某个实体或关键词因此单纯依赖向量相似度容易只召回局部内容无法形成完整的全局视角。RAG 常见的问题包括文档切片不合理导致上下文被截断。召回内容相关但无法组成完整答案。多跳问题需要多次检索。文档之间的关系没有被显式保存。对大量文档进行统计或主题归纳时效果不稳定。因此RAG 更适合回答具体事实和局部问题例如产品功能、接口参数、制度条款和操作步骤。四、GraphRAG用知识图谱增强检索1. GraphRAG 做了什么GraphRAG 可以理解为“知识图谱 RAG”但它并不只是简单地在系统中增加一个图数据库。GraphRAG 通常会在索引阶段使用大语言模型从原始文本中抽取实体例如公司、人物、产品、技术和地点。关系例如“依赖”“属于”“导致”和“竞争”。事件或事实声明。实体之间的社区结构。不同层级的社区摘要。Microsoft GraphRAG 的官方索引文档将这一过程描述为从非结构化文本中抽取实体、关系和声明进行社区发现生成多个粒度的社区摘要并创建向量表示。GraphRAG Indexing Overview2. Local Search面向具体实体的问题GraphRAG 的 Local Search 主要用于回答和特定实体有关的问题例如某个公司与哪些技术存在合作关系某个产品有哪些依赖组件某位作者提出了哪些相关观点某个事件由哪些因素导致官方文档中Local Search 被描述为结合知识图谱中的结构化数据和原始文档中的文本片段为模型补充与实体相关的上下文。GraphRAG Local Search3. Global Search面向整个数据集的问题Global Search 主要面向需要理解整个数据集的问题例如这批访谈中最常见的主题是什么这些报告反映出哪些共同风险多个项目之间有哪些相似的失败原因这组材料可以归纳出哪些主要观点GraphRAG 官方文档指出传统的基线 RAG 在回答需要跨数据集聚合的问题时可能表现不佳而 GraphRAG 可以利用知识图谱结构和预先生成的社区摘要来理解整个数据集。GraphRAG Global Search4. GraphRAG 的优势与代价GraphRAG 擅长处理“关系”和“全局”尤其适合跨文档主题归纳、实体关系分析、隐藏联系发现和大规模非结构化资料分析。其代价主要集中在索引阶段。构建知识图谱通常需要多次调用大语言模型因此会增加文档处理时间、模型调用成本和索引维护复杂度。如果原始文档经常变化图谱、社区和摘要也需要重新计算或增量更新。GraphRAG 也不会自动保证事实正确错误的实体或关系抽取可能继续影响社区摘要和查询结果。五、LLM Wiki让知识长期沉淀下来1. LLM Wiki 是什么需要先说明一点“LLM Wiki”目前更像是一种知识库组织和维护模式而不是像 RAG 一样具有统一定义的标准算法。本文所说的 LLM Wiki主要参考 Andrej Karpathy 提出的 LLM Wiki 设计模式以及相关的开源实现。它的核心思路是原始资料保持不变由 LLM 将资料整理为结构化 Wiki 页面并通过目录、链接、规则和日志持续维护。一个典型的 LLM Wiki 会包含raw/sources/原始资料。wiki/经过整理的知识页面。index.md知识目录。log.md知识变更日志。schema.md页面结构和维护规则。[[wikilink]]页面之间的交叉引用。YAML frontmatter页面类型、来源和更新时间。Karpathy 的设计说明可以参考LLM Wiki 设计说明目前也有具体的开源实现例如 llm_wiki。该项目将文档导入、Wiki 页面生成、来源追踪、知识图谱、搜索和 Agent 查询结合起来。2. LLM Wiki 与普通 RAG 的不同普通 RAG 的典型过程是每次提问时从文档切片中召回相关内容再拼接上下文。LLM Wiki 的典型过程是导入资料时先将资料整理成持久化的知识页面之后查询这些已经整理好的页面。因此两者的主要差别不在于“有没有检索”而在于知识是否被提前组织和沉淀。对比点普通 RAGLLM Wiki知识形式文档切片和向量页面、目录、链接和来源主要处理时机查询时导入和维护时知识是否可直接阅读通常需要查看原始文档页面本身就是可阅读内容更新方式更新向量索引更新页面、索引和日志人工参与主要参与数据准备可以直接审核和编辑页面长期积累能力依赖外部数据库和索引以知识页面形式持续沉淀3. LLM Wiki 的优势与局限LLM Wiki 的优势包括知识以 Markdown 页面存在人可以直接阅读和修改。新资料可以更新已有页面而不是只形成新的孤立片段。页面可以保存原始资料来源和更新时间。Agent 可以通过目录、页面链接和规则逐步浏览知识库。人负责知识目标和边界LLM 负责归纳、链接和维护。其局限包括需要设计页面结构和知识分类。初次导入仍然需要消耗模型调用。页面质量依赖 LLM 的整理能力。需要定期去重、校验和维护链接。Markdown Wiki 不适合作为高并发事务数据库。没有审核机制时错误可能长期沉淀。六、三者不是互相替代而是可以组合一个企业技术知识平台可以这样设计将设计文档、代码说明和会议纪要导入 LLM Wiki。使用 LLM 生成组件、系统、决策和问题页面。为页面添加来源、更新时间和交叉链接。对页面内容建立 RAG 索引回答具体问题。对实体和链接建立 GraphRAG 索引分析系统依赖和技术演进。由工程师定期审核页面和来源。将确认后的页面作为 Agent 的长期知识库。在这套分层架构中LLM Wiki负责知识沉淀和维护。RAG负责快速、精准的局部检索。GraphRAG负责关系分析和全局总结。七、如何选择选择 RAG如果主要问题是查找具体事实。文档更新频繁。需要快速上线。数据量中小问题比较明确。主要是 FAQ、客服或产品文档问答。选择 GraphRAG如果问题经常跨越多份文档。需要分析实体、关系、主题和社区。需要回答“整体上有哪些共同点”。需要发现隐藏联系或知识缺口。可以接受较高的索引成本。选择 LLM Wiki如果知识需要长期积累。人需要直接阅读和修改知识。需要保留来源和变更记录。资料来自持续性的研究和项目活动。希望为 AI Agent 提供可浏览的长期上下文。三者一起使用如果既需要精准问答又需要全局分析。既希望 AI 自动整理又希望人可以审核。知识会长期演化并且需要被多个应用复用。八、落地时最容易忽略的问题1. 不要只看模型回答要评估检索质量建议分别评估是否召回正确文档、是否遗漏关键来源、是否混入无关内容、是否能够追溯原始资料以及是否正确处理文档更新和删除。2. GraphRAG 要评估抽取错误知识图谱中的错误实体或关系可能影响社区摘要和全局推理。需要重点检查实体合并、别名、关系方向、时间关系和摘要遗漏。3. LLM Wiki 要建立维护规则至少需要明确原始资料是否允许修改、页面如何命名、哪些内容必须附带来源、何时更新旧页面以及谁负责处理冲突和错误。4. 不要一开始就追求复杂架构如果业务只是回答“这个 API 的参数怎么填写”先使用普通 RAG 通常更经济。当业务逐渐出现系统依赖分析、跨项目总结或技术演进追踪等问题时再引入 GraphRAG 或 LLM Wiki更容易控制成本和复杂度。九、总结RAG、GraphRAG 和 LLM Wiki 可以看作三个不同层次的知识增强方案RAG关注查询时如何找到相关文本。GraphRAG关注如何利用实体、关系和社区结构理解整个知识集合。LLM Wiki关注如何将知识组织成可阅读、可维护、可长期积累的内容资产。最稳妥的演进路线通常是先用 RAG 解决具体问答再用 LLM Wiki 沉淀长期知识最后在需要跨文档推理时引入 GraphRAG。这样可以根据实际问题逐步增加能力而不是一开始就构建复杂、昂贵且难以维护的系统。参考资料Retrieval-Augmented Generation for Knowledge-Intensive NLP TasksMicrosoft GraphRAG Indexing OverviewMicrosoft GraphRAG Query OverviewMicrosoft GraphRAG Global SearchMicrosoft GraphRAG Local SearchAndrej Karpathy 的 LLM Wiki 设计说明llm_wiki 开源实现
