从 RAG 到 OKF 0.2：让会议助手用对知识（上）

1. 背景

最近在做会议模块的 Agent 开发，调研了不少技术方案。老板让我准备一场内部技术分享，我觉得只讲某一个框架，能覆盖的内容还是有限，于是把从传统 RAG 到 OKF 0.2 的技术脉络整理了一遍，作为这次分享的内容，希望大家能从整体上理解这些方案分别解决什么问题、又可以怎样组合使用。

整理下来内容比较长，所以分成上、中、下三篇。三篇都从同一个会议场景出发，逐步讨论检索、关系、时序、文档导航，以及知识的维护与交付。

完整文档和配套数据示例已经上传到 GitHub：rag-knowledge-lab。可以把仓库拉到本地，按照 README 启动数据实验室，结合文章对照原文、文本切块、检索结果和知识关系，理解起来会更直观。

比如，我们的会议模块就面临下面三个问题：

1. 怎样根据会议内容实时检索？ 会议中会不断推送文档、任务和项目目标，怎样根据当前对话或用户的问题，及时找到相关资料？
2. 怎样避免上下文爆炸？ 如果把所有文档、任务、项目目标和会议内容都放进 LLM，上下文很快就会膨胀。怎样让模型只读取当前需要的内容，同时保留必要的背景和依据？
3. 怎样处理不断变化的结论？ 会议开到第三个小时，可能推翻第一个小时的决定；下一周的会议，又可能调整上一周的方案。怎样保留这些变化，并在用户提问时给出当前适用的结论？

先看资料怎样进入检索，再讨论跨文档关系和实体、关系两路检索。本篇完整展开传统 RAG、GraphRAG 和 LightRAG 的原理、步骤、案例与取舍。

2. 传统 RAG：先把相关原文找出来

业务资料在模型之外，回答依据从哪里来

LLM 能理解问题、组织语言，但只靠训练时学到的知识，回答业务问题会遇到三个限制：

• 私有知识没学过。 模型可能熟悉支付原理，却没见过企业内部的《支付接口规范》，不知道你们约定了哪些重试条件。
• 知识不会自动更新。 接口规则已经修改，模型参数里的知识不会随之改变。仅凭已有知识，它无法确认哪个版本当前有效。
• 回答流畅，也可能出错。 缺少必要事实时，模型仍可能给出看似合理的答案；没有原文依据，用户也难以核对。

可以把资料附在问题后面，让模型读完再回答。但文档一多，全部放入上下文会增加成本和等待时间，也会混入无关内容。

RAG 的做法是： 先查资料，再根据资料回答。 比如问“新版支付接口能否重试”，先找规范和重试条件，再交给模型组织答案。资料更新时，通常只需更新知识库和索引，不必重新训练模型。

RAG 怎样把外部资料接进回答

RAG（检索增强生成）把外部资料接入回答过程：先检索证据，再把证据与问题一起交给 LLM。本文从常见的文本切分、向量检索方案展开。

有出处还不够，检索还得找齐条件、用对版本。下面分入库和查询两部分来看。

RAG 怎样工作

入库时把文档处理成可检索的记录，查询时选出需要的内容。每个文本块都要保留来源，方便找回原文。

索引阶段：以 Milvus 为例准备资料

第 1 步：解析文档，切成文本块。

将文档内容提取为文本，按长度、结构或语义切分，并保留资料 ID、版本、所属章节等来源信息。每块应尽量包含完整的事实及适用条件。

第 2 步：用 Embedding 模型生成向量。

每个文本块转换成固定维度的向量。向量可以理解为文本在语义空间中的位置，意思接近的问题和段落更容易匹配，但“语义接近”不代表“当前有效”。

第 3 步：把向量与来源写入 Milvus。

将向量、原文或原文位置，以及项目、版本等字段写入 Collection。向量负责语义匹配，标量字段负责限定范围与回溯。

第 4 步：配置索引，确认数据可查询。

配置索引、加载数据，确认新内容能被查到。Milvus 负责存储和检索，解析、切分和生成答案由其他模块完成。

常见的三种切分策略

切块要尽量把规则和条件放在一起。切得太碎，容易漏条件；切得太大，又会带入无关内容。常见做法有三种：

1. 固定长度切分： 按字符数或 Token 数切块，用少量重叠减少信息断裂。实现简单，但可能拆散完整语义。
2. 结构切分： 按标题、段落切分，超长部分再递归拆分。适合结构清晰的文档，能保留内容层次。
3. 语义切分： 根据相邻句子的语义变化确定边界，尽量保留完整话题，但计算成本更高。

对会议转写，可以优先保留连续的问答和同一议题，再用长度上限兜底。无论采用哪种策略，都应尽量让任务描述、截止时间和适用条件一起进入检索结果。

查询阶段：召回、重排，再交给 LLM

第 1 步：理解问题，生成查询向量。

结合最近对话补全项目、任务和时间意图，再用与文档索引匹配的 Embedding 模型生成问题向量，避免“这个接口”这样的指代直接进入检索。

第 2 步：限定范围，多路召回候选。

按权限、项目等条件过滤，再找语义接近的文本块。任务名、版本号等精确信息还可以用 BM25 关键词检索补充，减少单一路线的遗漏。

第 3 步：融合去重，再做相关性重排。

多路结果先去重，再排序。 融合看各路排名，语义重排看内容是否相关。 常见做法是：

• RRF：按名次融合。 根据材料在各路结果中的名次合并排序，本身不重新阅读正文。
• Cross-Encoder：按内容打分。 把“问题＋候选片段”一起输入，逐对判断相关性。

Cross-Encoder 计算更贵，通常只对召回后的一小批候选做精筛。

第 4 步：组装证据，生成带来源的回答。

按上下文预算选取片段，保留出处与适用条件，再将证据和问题交给 LLM。重排能改善候选的顺序，但不能补回从未召回的材料，也不能仅凭相关性分数判断事实是否仍然有效。

实时会议还要关注更新延迟：“收到资料”不等于“检索能看到资料”。解析、向量化、写入和查询可见性都需要时间；数据库一致性设置只能解决其中一部分。

找到了相关片段，为什么还可能答不完整

查找明确事实时，RAG 可以从独立更新的资料中取证，并为回答保留引用。问题复杂以后，需要检查的就不只是片段排名：跨文档的依据有没有找全，少量候选能否代表整体，规则的条件是否与结论一起出现。下面分别看这三种情况。

痛点一：跨文档的多跳问题，证据容易找不齐

有些答案需要沿着引用或依赖关系，从一份资料追到另一份资料。这类问题涉及多跳推理，难点首先在于找齐证据。

例子一：一份文档的结论，依赖另一份文档中的前提。

假设有两份文档：

• 《订单服务压测报告》第 3.2 节写着：“启用本地缓存时，现有两台服务器可以承载活动峰值流量。”
• 《大促上线方案》依据上述测试结果，得出“活动期间无需扩容”的结论。

后来会议确认要关闭本地缓存，用户问：“不扩容的方案还成立吗？”

只召回《大促上线方案》，模型可能继续回答“不需要扩容”。要判断结论是否仍适用，还需要沿着 结论 → 引用依据 → 成立条件 ，找到压测报告的那一段。前提已经变化，合理的回答是需要重新评估容量，而不是直接沿用旧结论。

例子二：任务、负责人和项目，分别记录在不同地方。

• 任务系统：“支付回调改造，负责人李明，尚未完成。”
• 《商城支付升级项目上线计划》：“支付回调改造完成是项目上线的前置条件。”
• 最新会议记录：“李明本周调离项目，支付回调改造尚未交接。”

用户问：“李明调走后，哪个项目的上线依赖需要重新安排？”

只找到李明的任务列表，未必知道这些任务影响哪个项目；只找到商城支付升级项目的上线计划，又可能缺少最新交接状态。系统需要连接 李明 → 支付回调改造 → 商城支付升级项目 ，再结合会议记录，指出商城支付升级项目需要确认任务接手人及排期。

相关片段不一定组成完整的证据链。 按相似度排在前面的材料，未必包含结论的依据、任务的依赖和最新交接状态。模型拿齐资料后可以推理，但检索阶段需要有办法发现缺口并补查。

痛点二：问的是整体情况，拿到的却是局部片段

比如用户问：“这个季度，各项目反复出现的交付阻塞有哪些？”

这个答案需要比较多个项目的资料，归纳共同问题。假如得分最高的几个片段都在讨论接口联调，模型就可能把“联调困难”当成主要原因，漏掉其他项目里反复出现的需求变更、验收缺失。

相似度排序回答的是哪些片段相关，不能保证它们代表整体。 增大 Top-K 可以增加材料，但也会带来重复内容和上下文压力，仍不保证覆盖各个项目。

这类问题需要先按项目或主题组织材料，分批归纳后再汇总。GraphRAG 的社区报告就是为全局归纳准备的一种结构，后面会展开介绍。

痛点三：切块之后，结论和适用条件可能分开

假设《支付接口规范》的一段规则被拆成两块：

• 片段一：“支付回调失败后允许重试。”
• 片段二：“上述规则仅适用于已启用幂等校验的接口。”

用户问“回调失败后能直接重试吗”，如果只召回第一块，模型就可能把有条件的规则说成通用规则。即使第二块也被找到，缺少章节和前文时，“上述规则”指什么也可能不清楚。

切分需要保留完整的语义单元，召回也要能补回必要上下文。 按结构切分、带上标题、补取相邻段落都能缓解问题；图可以进一步保存对象与规则的关联，但抽取时同样需要读到完整条件。

当问题需要追查依赖或归纳整批资料时，仅调整片段排序通常不够。GraphRAG 在原文之外增加实体、关系和社区组织，让检索有更多线索可循。

3. GraphRAG：把片段连接成关系

什么是 GraphRAG

GraphRAG 将资料中的对象和关系组织成图，用这些联系帮助检索，再由 LLM 根据证据回答。 人、任务、项目可以成为节点，负责、依赖、引用等关系成为边，原始文本则保留为可核对的依据。

这个名字通常有两层含义：

• 广义的 GraphRAG： 利用图结构增强 RAG 的一类方法，具体建图和检索方式可以不同。
• 微软 GraphRAG： 微软研究团队提出的具体方案及开源项目，除了实体关系图，还构建社区和社区报告。本文主要介绍这套实现。

关联查询和全局归纳，需要两种证据组织

微软论文题为 From Local to Global: A Graph RAG Approach to Query-Focused Summarization，关注的问题是：怎样让问答归纳整批资料，而不只围绕少数命中的片段展开。

例如，“支付回调改造由谁负责”可以从一份任务记录中找到；“这个季度各项目反复出现哪些阻塞因素”则需要比较不同项目的材料。后一个问题没有一段天然对应的答案，也很难靠相似度最高的几个片段代表全貌。

为此，GraphRAG 在原文之外增加两层组织：

1. 实体关系图提供关联路径。 从李明找到支付回调改造，再找到商城支付升级项目，帮助检索追查跨文档的联系。
2. 社区报告提供分组后的知识概览。 把图中联系紧密的内容归为社区，提前整理报告，全局问题就可以基于多个社区的材料归纳。

前者服务于具体对象的关联查询，后者支撑跨资料的主题总结。两类需求也对应了微软项目中的 Local Search 和 Global Search，后面会分别展开。

LLM 怎样让建图进入文档处理流程

知识图谱并非到 GraphRAG 才出现。在微软的实现中，LLM 除了生成最终回答，还承担抽取实体关系、合并描述和生成社区报告的工作。普通文档因此可以经过批量处理，形成供检索使用的图与报告，而不必先手工整理成一套结构化知识库。

这些处理仍有模型调用和维护成本，切块造成的条件遗漏也要单独处理：如果抽取时没读到完整条件，建成图不会自动补齐。

微软 GraphRAG 从哪里来

微软研究院于 2024 年 2 月 13 日 公开介绍 GraphRAG，探索如何从企业私有文档等资料中发现知识。

同年 4 月 24 日 ，Darren Edge、Ha Trinh 等研究者提交论文 From Local to Global: A Graph RAG Approach to Query-Focused Summarization； 7 月 2 日 ，微软宣布在 GitHub 开源实现。论文公开与项目开源是两个时间点。

GraphRAG 怎样工作

GraphRAG 建库时准备图和社区报告；查询时，Local 查关联证据，Global 读报告做归纳。

索引阶段：从原文构建图与社区报告

第 1 步：切分文档，建立原文映射。

文档先切成文本块（TextUnit），每块保留所属文档。后面抽取的实体、关系都关联到这些文本块，查询时才能从图中的一条关系找到它的原始依据。

第 2 步：让 LLM 抽取实体与关系。

例如，一个文本块写着：

李明负责商城支付升级项目的支付回调改造任务；任务依赖支付结果查询接口，并支撑“减少支付状态不同步”的目标。

抽取时，LLM 需要识别两类信息：

• 实体： 李明是人员，支付回调改造是任务，支付结果查询接口是接口。除了名称和类型，还保留对象的描述。
• 关系： 谁负责什么、任务属于哪个项目、依赖哪个接口。关系包含两端对象及描述，并关联到来源文本块。

可以先约定有哪些实体类型、关系，以及它们的含义。这套概念和约束就是 Ontology（本体） ，让不同文档按同一套规则抽取。

本体中的类型与关系	图谱中的具体事实
人员可以负责任务	李明负责支付回调改造
任务可以属于项目	支付回调改造属于商城支付升级项目
任务可以依赖接口	支付回调改造依赖支付结果查询接口

本体还能区分“负责”和“参与”： 参加讨论，不等于负责交付。 这些约定能减少表达混乱，但同名对象和事实真假仍要核对。

可以先定义少量类型和关系，用起来再补充。微软 GraphRAG 也支持从资料中发现实体类型、生成领域抽取提示。

这一轮的产物是每个文本块各自对应的一小张图，同一个任务可能在多张图中重复出现。

第 3 步：合并小图，汇总实体和关系描述。

微软默认流程按实体名称和类型归并实体，按关系两端归并关系，再由 LLM 汇总多处描述。例如，任务记录说明“谁负责”，上线计划说明“影响哪个项目”，合并后才能围绕同一项任务继续查。

名称匹配仍可能混淆同名对象或漏掉别名。接入业务数据时，可以利用项目 ID、任务 ID 等标识帮助消歧。

第 4 步：用图算法发现社区。

图建好后， 层次化 Leiden 算法 寻找连接较紧密的节点群，并继续细分，形成不同粒度的社区。例如，支付任务、接口和故障记录可能聚成一组，再细分出回调处理、对账等部分。

分组依据来自图的连接结构，因此社区可能跨部门，也不等同于人工指定的业务分类。

第 5 步：让 LLM 为社区生成报告。

LLM 根据每个社区中的实体、关系和相关信息，概括主题、重要联系及问题。例如，把分散的接口延期与任务阻塞整理成该社区的交付情况。 图算法负责分组，LLM 负责概括 ，查询时就不必从零阅读社区内的全部材料。

第 6 步：建立检索索引，保存来源关联。

为实体描述等内容生成向量，并保存实体、关系、报告与原文的对应关系。查询时就能找入口、查关系、读报告，再回到原文。

图结构不意味着必须部署图数据库。微软 GraphRAG 的索引产物可以保存为表文件；知识组织方式与存储产品是两件事。

插入数据时，谁在调用谁

把上面的六步放到时序里看： 索引流程负责组织处理，LLM 负责抽取和概括，Embedding 负责向量化，存储负责保存产物。 图从上往下读，实线箭头表示请求或写入，虚线箭头表示返回；loop 表示重复处理。

这里展示标准建库的职责顺序，省略缓存、并发和重试；不表示每次追加资料都要重建全部社区。

查询路径一：Local Search 从具体对象出发

以“支付结果查询接口影响哪些任务”为例：

第 1 步：匹配实体，找到图的入口。

用问题搜索实体描述向量，找到相关接口实体。入口确定后，才有依据选择要补充哪些关联信息。

第 2 步：沿关联取回证据。

取得相连的任务与关系，再通过映射找到原文片段和相关社区报告。关系说明“任务依赖这个接口”，原文则可能补充“只有新客户受影响”等条件。

第 3 步：筛选上下文，由 LLM 回答。

筛选、排序实体、关系、报告和原文，在上下文预算内交给 LLM 回答，并附上依据。展开多少关联，由配置和预算决定。

前面的跨资料例子也可以按这条路径理解：先找到李明及其负责的任务，再补查项目依赖和交接记录。

查询路径二：Global Search 从社区报告归纳整体

“本季度项目有哪些共同阻塞因素”未必对应某个明确实体，可以基于社区报告采用 Map-Reduce：

第 1 步：选择社区层级，将报告分批。

根据需要的细节程度选定社区层级，把该层报告按上下文容量分成多批。细粒度报告能提供更多细节，也会增加处理量。

第 2 步：各批分别回答，形成候选观点（Map）。

每批围绕同一个问题生成中间回答，并评估观点的重要性。例如，不同批次分别发现接口延期、需求变更或验收缺失。

第 3 步：筛选并汇总观点（Reduce）。

将中间观点排序、过滤后交给 LLM，归纳共同阻塞因素，形成最终回答。覆盖范围取决于所选报告，抽取和摘要阶段漏掉的信息，后面未必能补回来。

Local 与 Global 是面向不同问题的两条查询路径，不要求一次问答先后执行两遍。

查询数据时，Local 与 Global 怎样调用

下图的 alt / else 表示按选定模式走不同分支： Local 取回关联证据后生成回答；Global 先分批生成候选观点，再汇总回答。 这里的“检索与存储”合并表示向量搜索和索引资料读取。

以腾讯 WeKnora 为例

这里涉及三个独立项目，定位并不相同：

• Microsoft GraphRAG：微软提出的图检索方法与开源框架。 本文介绍的标准流程会抽取实体关系、划分社区并生成社区报告。
• LightRAG：HKUDS 团队提出的另一套图检索方法与开源框架。 通过实体、关系两路检索组织证据，核心流程不依赖微软式社区报告，下一节会展开。
• WeKnora：腾讯开源的知识库应用平台。 集成文档处理、知识管理、检索问答与 Agent 等能力，图谱增强是其中一项能力。

WeKnora 展示了 怎样把图谱检索接进文档问答应用 。这里说的是图谱增强，不代表它采用微软的社区报告流程。

第 1 步：解析资料，建立检索索引。 文档先解析、切分，形成可被检索的文本内容。

第 2 步：按配置补充知识图谱。 开启图谱能力时，抽取实体和关系，并可使用 Neo4j 保存。

第 3 步：检索证据，组织回答。 查询时按配置结合向量、关键词和图谱等通道，把取得的证据交给模型。

图中按职责画出流程，实际查询不一定启用所有通道。

在会议里，关键词可以找任务编号，向量匹配自然表达，图谱补充任务与接口、目标的关系。但判断“新决定是否推翻旧决定”，仍需要时间和业务规则。

GraphRAG 的优点与代价：落地难在哪

图和社区报告提前整理了资料，也带来几项维护工作：核对实体、控制调用成本、检查社区质量，以及同步原文变更。

难点一：图建出来了，不代表关系就抽对了

《商城升级方案》写“统一支付平台”，接口文档写“支付中心”，它们可能是同一个系统；研发部和财务部各有一个“李明”，却不能合成一个人。 同一个对象被拆开，关联链会断；不同对象被合并，关联链会串错。

微软默认按名称和类型合并实体，未必能分清业务中的同名与别名。需要补充业务 ID、别名和抽取示例，并抽样核对原文，否则错误会传到报告和答案里。

难点二：建库和全局问答，都要控制 LLM 调用预算

标准建库流程里， 逐块抽取 → 汇总实体与关系描述 → 生成社区报告 ，都会用到 LLM。假设 1,000 个文本块各调用一次模型，光第一轮抽取就是 1,000 次，后面还有摘要与报告；实际次数还受补充抽取、缓存、重试等配置影响。

查询时，Global Search 又要分批阅读社区报告：每批一次 Map，最后再 Reduce。报告越多，调用量和等待时间通常越大，还要处理模型服务的限流、失败重试和并发。 Local Search 不需要完整执行这套全局流程 ，应按问题选择路径。

Leiden 社区划分本身是图算法，不调用 LLM；费用主要花在抽取和摘要上。并发可以缩短等待，但不会自动减少 Token 账单。

难点三：图上的社区，不一定就是业务想看的主题

社区算法按连接结构分组，业务却可能希望按“交付风险”“客户投诉原因”分析资料。两种划分不一定一致。社区太粗，报告容易压掉细节；太细，报告数量和查询开销又会上升。

要用真实问题检查报告： 共同问题有没有找出来，关键例外有没有被省掉。

难点四：原文改一处，可能牵动多层派生知识

例如，《支付重试规范》把“超时后可自动重试”改成了“必须先查询支付结果”。维护链条可能是：

1. 修正图。 找出旧文本支持的实体、关系和描述，判断哪些仍有其他来源支持。
2. 修正摘要。 检查受影响的社区报告是否还保留旧规则；图结构变化较大时，还需评估社区是否重算。
3. 同步索引。 更新相关向量和来源映射，避免图、报告与原文出现不同版本。

难点是找全受影响的内容。这需要来源映射、版本记录和失败补偿；只改原文，旧结论可能还留在图和报告里。

微软当前 已有增量流程，并非每次新增都全图重建 ；它会处理新增资料、合并结果，并追加社区与报告。旧文档修改、删除，以及何时重新整理全图主题，仍需要相应策略。

LightRAG 接下来减少的，主要是社区报告的构建、查询与维护工作。图的质量、实体身份和来源追踪这些问题，它仍然需要面对。

4. LightRAG：用实体和关系两路检索，减少社区维护

持续新增资料时，社区报告需要多少维护

微软 GraphRAG 的社区报告路线，除了维护实体关系，还要考虑新增资料对社区及报告的影响。对于资料持续增加、经常查询具体依赖的知识库，索引和更新工作会成为负担。

如果经常问“某个接口影响哪些任务”，可以直接查实体和关系。LightRAG 就这样做：按名称找对象，按主题找关系，再补充原文，不依赖预先生成社区报告。

LightRAG 把检索入口放在实体和关系上

LightRAG 把知识图谱和向量检索结合起来，分别为实体和关系建立索引。

它由 香港大学与北京邮电大学的研究者 提出，Zirui Guo、Lianghao Xia 等人于 2024 年 10 月 发表预印本《LightRAG: Simple and Fast Retrieval-Augmented Generation》，项目在 HKUDS/LightRAG 开源。它有自己的论文和检索设计，并非微软 GraphRAG 的一个配置模式。

这里的“轻”，主要体现在： 不预先生成社区报告，查询直接召回实体与关系，新增资料合并到已有图中。 图、LLM 抽取和向量索引依然保留。

LightRAG 怎样工作

下图采用 hybrid（混合检索） ：把 local（从具体实体出发）和 global（从关系主题出发）两路结果合并，再回取原文。这里“混合”的就是 实体检索与关系检索 。

上半部分构建索引；下半部分展示 hybrid：实体一路＋关系一路 → 合并去重 → 回取原文 → 生成答案。

索引阶段：把资料变成可检索的图

第 1 步：切分资料，保留原文来源。

文档先切成文本块，每块保留标识及所属文档。后续抽取的实体和关系关联到这些文本块，查询时才能找回依据。

第 2 步：抽取实体、关系和描述。

例如，资料中写着：

李明负责支付回调改造，该任务依赖支付结果查询接口，并影响商城支付升级项目上线。

LLM 从中识别李明、支付回调改造、支付结果查询接口、商城支付升级项目等实体，提取负责、依赖、影响上线等关系，并生成描述。关系还带有“接口依赖、项目交付”等主题关键词，供后续检索使用。

第 3 步：合并重复对象，汇总描述。

同一任务可能出现在多份文档里。系统合并重复实体、关系和描述，保留来源；描述太长时，再让模型概括。同名和别名是否匹配正确，仍要核对。

第 4 步：建立图与两类向量索引。

图保存对象间的连接。实体名称和描述生成实体向量；关系关键词、两端对象和描述生成关系向量。向量用来匹配问题，图用来补充关联，来源标识用来找回原文。

插入数据时，怎样合并到已有知识中

新增资料先经过抽取，再与已有实体、关系合并，同步描述、来源和向量。图中的 opt 表示 满足条件时才执行 ：例如描述过长，需要再调用 LLM 汇总。

图中按职责归并了存储操作；不同后端的写入、并发与持久化顺序可以不同。

查询阶段：两路召回再回取原文

下面以同时启用两路检索，回答“支付结果查询接口延期，会影响哪些工作”为例：

第 1 步：从问题中提取两组关键词。

LLM 提取关注具体对象的低层关键词，如“支付结果查询接口”；同时提取关注主题的高层关键词，如“延期、交付依赖”。

第 2 步：分别检索实体和关系，再合并结果。

• 实体一路： 搜索实体向量，找到支付结果查询接口，再补充相连的关系，例如“支付回调改造依赖这个接口”。
• 关系一路： 搜索关系向量，有机会找到“支付回调改造是商城支付升级项目的上线前置任务”，再补充关系两端的实体。

两路结果合并后，可以补齐接口、任务和项目之间的联系。“低层、高层”指线索的粒度，两路可以独立检索，不需要先遍历整张图。

第 3 步：回取原文，组装回答所需的证据。

根据来源标识取回原文，筛选、去重后，与实体和关系说明一起放入上下文。“仅影响新客户”“接口本周完成就不影响上线”等条件也要保留。

第 4 步：让 LLM 根据证据回答。

模型根据关系和原文，回答受影响的任务及上线条件。漏掉关键关系或条件，答案仍可能不完整。

查询数据时，两路结果怎样合在一起

时序图展示 hybrid 模式：LLM 先提取两组关键词，分别召回实体与关系，合并结果并回取原文，最后再调用 LLM 回答。 两路检索可以独立执行，画面上下排列不表示后一条依赖前一条。

当前实现常用的查询模式包括：

模式	检索方式
naive	直接检索文本块
local	以实体为入口，补充关系与原文
global	以高层关系线索为入口，补充实体与原文
hybrid	混合检索：合并实体一路（local）与关系一路（global）的结果
mix	在图检索之外加入文本块向量召回

LightRAG 的 global 搜索相关关系；微软 GraphRAG 的 Global Search 读取社区报告并进行整体归纳。 两者名称接近，承担的工作并不相同。

增量更新：合并受影响的实体与关系

假设图里已经记录了“李明负责支付回调改造，任务属于商城支付升级项目”。新加入的《支付接口联调说明》又补充：这个任务依赖支付结果查询接口。

灰色表示已有知识，蓝色标出新增依赖。已有任务节点继续复用，描述、向量和来源随新资料更新。

第 1 步：从新资料抽取实体与关系。

对新文档切分和抽取，得到“支付回调改造”“支付结果查询接口”及两者之间的依赖关系，保留对应文本块。

第 2 步：匹配已有对象，把新关系并入图。

识别出“支付回调改造”已经存在，复用这个任务节点，补上接口节点与依赖边；任务的描述和来源一起合并，必要时再让 LLM 汇总描述。

第 3 步：同步受影响的向量和来源。

为新增或描述变化的实体、关系更新向量，关联新文档与文本块。其他图数据继续保留，核心流程也不需要生成或维护社区报告。

图中展示的是 新增资料 。删除资料时，还要检查实体和关系是否有其他来源支持，再决定清理哪些信息、按剩余来源重建哪些描述。增量更新减少了重复处理范围，并未免除知识维护。

少了社区报告，查询和维护发生了什么变化

少了社区报告，维护更省事，但也少了一份提前整理好的主题概览。具体查依赖和做整体综述，效果会有不同。

取舍一：省了社区报告，也少了预先整理的全局视图

假设有一千份客户反馈。问题是“退款延迟涉及哪些系统”时，LightRAG 可以围绕“退款、延迟”找实体、关系和原文，比较直接。

但如果问“这些反馈反映了哪些主要问题，还有哪些少数但重要的风险”，就没有一个明确的查询入口。LightRAG 当次召回的相关关系，未必覆盖物流、售后、支付等全部主题。微软 GraphRAG 则可以从不同社区的报告中收集观点，再做整体归纳。

LightRAG 做大范围综述时，往往要补问题拆分、多轮检索或主题汇总，成本也会增加。 GraphRAG 有社区报告可以用，但报告也可能漏信息，具体效果还得看问题。

取舍二：查询更依赖当次召回，关键证据可能进不来

LightRAG 要经过“提取关键词 → 匹配实体或关系 → 补充关联与原文”。如果“支付结果查询接口”被提炼成过泛的“支付”，或者文档只写了未归一的别名，第一批候选就可能偏离目标。后续沿图补充，也可能围绕错误对象展开。

Top-K 调大，能多找一些关系，也会带入噪声；调小，可能漏掉关键依赖。 关键词、别名、召回数量和重排要一起调试 ，合并两路结果并不保证证据找齐。

仍要承担的工程成本：消歧、冲突与删除后的修复

新资料来了，LightRAG 仍要抽取、合并描述、更新向量。资料被删掉，也要检查哪些实体和关系还有其他来源支撑。若旧资料说“李明负责支付回调改造”，新资料说“王蕾接手”，增量合并本身并不说明交接何时生效。

LightRAG 省去了社区报告维护，数据质量和时效仍要自己处理。 实体怎么区分、变更何时生效、旧事实何时失效，都需要明确规则。

成本对比：LightRAG 具体省在哪里

先分清三笔账： 建库时抽取多少知识，查询时让模型读多少内容，更新时重做多少派生产物。 LightRAG 主要省去了社区报告相关的处理，抽取和答案生成仍需付费。

下面使用 LightRAG 论文的 Legal 数据集（94 篇文档、约 508 万 Token） ，比较论文中的 GraphRAG 社区报告基线与 LightRAG。数字对应当时的实现和配置，不是所有版本、模式的固定成本。

深蓝表示 GraphRAG，浅蓝表示 LightRAG。第一组使用对数刻度；第二、四组含明确假设，仅比较图中标注的处理阶段。点击可放大查看。

查询成本：少了逐批阅读社区报告的开销

为什么差这么多？基线中有 610 个二级社区 ，每份报告平均约 1,000 Token；GraphRAG 要让模型分批阅读它们。LightRAG 先生成检索关键词，再通过向量索引和图找证据，省掉了这一轮报告问答。

调用次数也随之减少：论文把 GraphRAG 该阶段的次数记为“610,000 ÷ 每批 Token 上限”，LightRAG 则是 1 次关键词提取 。610 是社区数，不能直接写成 610 次调用。

“少于 100 Token”只对应论文列出的检索阶段开销。 它没有给出完整请求的输入、输出账单；LightRAG 后面还要读取实体、关系、原文并生成答案，不能据此计算整次问答的价格或延迟。

建库与更新：省去社区报告，但仍要抽取知识

首次建库时，两者都要处理原文、抽取实体关系并建立索引；微软标准 GraphRAG 还要生成社区报告。论文又估算了“ 追加同等规模资料，并重新生成全部社区报告 ”的情景：仅报告重建就涉及 1,399 万 Token、2,798 次调用 ，抽取费用另计。

图中的金额是 计算示例 ，不是论文实测价格，也不是某个模型报价。原论文没有给出可直接复用的美元账单；实际模型通常分别收取输入和输出 Token 费用。微软当前也已有增量流程，新增资料不必每次全量重建报告。

费用发生在哪	微软标准 GraphRAG	LightRAG
首次建库	抽取、描述汇总、向量化， 另加社区报告生成	抽取、描述合并与向量化
每次查询	Local 读取局部证据；Global 分批报告问答＋最终汇总	关键词提取、实体／关系召回、读取证据并回答
持续更新	更新图与索引， 另需维护相关社区报告	合并受影响的图、描述、向量与来源

最终按同一周期计算： 首次建库＋期间更新＋查询次数×平均单次查询费用 。对同一批资料、同一组问题，记录输入与输出 Token、模型单价和耗时，并检查答案质量，才能判断省钱是否伴随证据遗漏。

GraphRAG 与 LightRAG：放在一起怎么选

两者都利用实体和关系连接资料。主要区别是： 是否预先生成社区报告，以及查询时怎样组织证据 。下表以微软 GraphRAG 的标准建库与 Local / Global Search 为参照。

这里对比社区报告与实体、关系检索；GraphRAG 也支持 Local Search。

对比维度	微软 GraphRAG	LightRAG
知识组织	实体关系图之上，再划分层次社区、生成社区报告。	保留实体关系图，建立实体与关系的向量索引，关联原文；核心流程不依赖社区报告。
检索方式	Local 围绕实体补充关联证据； Global 分批读取社区报告，再汇总答案。	local 找实体， global 找关系， hybrid 合并两路结果，再补充关联原文。
建库成本	LLM 用于抽取、描述汇总和社区报告生成；社区划分本身由图算法完成。	省去社区报告生成，但抽取、描述合并和向量化仍有成本。
查询成本与延迟	Local 按局部证据回答；Global 的 Map-Reduce 会增加 LLM 调用，报告批次越多，开销通常越大。	通常先提取关键词，再检索并生成答案；省去社区报告的分批问答，具体延迟仍取决于模型与配置。
增量更新	已有增量流程 ，新资料仍需处理社区及报告；若要重新梳理全图主题，还需安排相应重算。	抽取新资料，合并受影响的实体、关系，更新描述、向量与来源；少了社区报告的维护。
主要优势	社区报告提供分层主题视图，便于跨资料归纳；Local 也能回答具体对象的关联问题。	实体、关系两路互补，适合按问题寻找联系；持续接入资料时，更新链路较短。
主要局限	实体消歧与领域抽取需要调优；社区划分未必符合业务主题，报告可能压掉细节；调用预算与多层更新维护较重。	没有预先整理的分层主题视图 ；关键词与 Top-K 决定当次证据范围，宽泛问题可能漏主题；消歧与删除修复仍要处理。
需要额外补什么	业务标识与抽取校验、社区层级选择、来源追踪，以及修改／删除后的同步策略。	大范围综述可能要补问题拆分、多轮检索或主题汇总；补充后需重新计算总成本。
适用场景	整批资料的分析与综述 ：归档项目复盘、研究报告主题归纳。资料较稳定、可接受离线建库时，社区报告更容易复用。	持续更新的关联问答 ：技术文档、客户工单、产品变更记录。希望保留关系检索，又要控制更新和查询开销时，可优先评估。

选型先看问题：经常问“这批资料反映了哪些共同问题”，可以优先评估 GraphRAG 的社区报告；经常问“这个接口关联哪些任务”，同时每天都有新资料，可以优先评估 LightRAG。 最终比较的是回答质量、更新后可查询的时间和总成本 ，需要用自己的资料与问题测试。

两者支持追加资料，都不等于自动判断哪条决定当前有效。负责人或方案发生变化时，还需要在事实表示与查询中处理时间和状态。

参考资料

整理这次分享时，我参考了《Agent 知识库这些年：从 RAG 到 OKF 0.2》的议题顺序，再结合会议模块的问题展开。下面只列本篇用到的资料。业务数据是教学示例，流程图做了相应简化。

1. RAG 原论文
2. Milvus RAG 教程
3. 结构切分
4. 语义切分
5. Milvus 混合检索
6. Milvus 排名融合
7. Cross-Encoder 原理
8. Milvus 一致性说明
9. 微软 GraphRAG：全局查询
10. 微软 GraphRAG 项目
11. 论文研究的问题
12. 索引阶段的设计
13. 最初的研究介绍
14. GraphRAG 原论文
15. 开源公告
16. 本体的定义
17. 领域提示与类型发现
18. 索引概览
19. Local Search
20. LightRAG 项目与查询模式
21. WeKnora 项目
22. 知识图谱说明
23. 标准索引方法
24. 官方增量流程
25. 社区合并实现
26. LightRAG 论文与提交记录
27. LightRAG 作者与机构
28. LightRAG 索引设计
29. 当前查询参数
30. 《Agent 知识库这些年：从 RAG 到 OKF 0.2》

资料核对日期：2026 年 9 月 16 日。