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

1. 背景

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

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

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

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

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

上篇介绍了传统 RAG、GraphRAG 和 LightRAG，主要看怎样把相关资料找出来。这一篇继续看三个问题：结论变了怎么记录，长文档该读哪些章节，一次检索不够时又该怎样补查。对应的方案是时序知识图谱、PageIndex 和 Agentic RAG。

2. 时序知识图谱：把事实的变化也记录下来

负责人变了，旧关系应该覆盖还是保留

图里原来记录“李明负责支付回调改造”，后来负责人换成王蕾。直接覆盖旧关系，会丢掉历史；两条关系都留下却不记录时间，查询时又可能同时出现两个负责人。

本体能约定“负责”是什么关系，要判断这段关系何时成立，还需要时间信息。

还有一种麻烦是记录迟到：王蕾周二已经接手，系统周三才收到交接记录。资料进入系统的顺序，与事情发生的顺序并不一致。一个普通的 updated_at 字段无法同时解释“谁在当时负责”和“系统何时才知道”。

所以要一起保存三样东西：事实何时有效、系统何时知道、依据是哪条原始记录。

交接后保留旧记录，查询时按有效时间选择。图中只展示业务时间，系统记录时间见下文。

把事实的有效时间与记录时间分开

时序知识图谱会记录“谁和谁有什么关系”，也记录“这段关系什么时候成立”。这样就能同时保留当前状态和历史状态。

Graphiti 是 Zep 团队开发的开源框架，能持续接入对话、文档和业务事件。它用双时态区分业务生效时间和系统记录时间。这里讲的是需要自行部署、集成的 Graphiti，不是 Zep 托管服务。

时序知识图谱怎样工作

时间表示：用有效区间保留历史，用双时态区分迟到记录

负责人变更后，图中可以保留这样的业务视图：

关系	有效起点	有效终点
李明负责支付回调改造	9 月 1 日	9 月 15 日
王蕾负责支付回调改造	9 月 15 日	尚未结束

旧事实结束有效区间后仍然保留，查询可以按时点选择关系。Graphiti 进一步区分两条时间线：

• 有效时间： 事实在业务上什么时候成立，用 valid_at / invalid_at 表达。
• 系统时间： 系统什么时候记录、识别这条事实的变化，用 created_at / expired_at 表达。

王蕾周二接手、周三才录入，valid_at 就是周二，created_at 是周三。旧关系也要分别记录业务结束时间和系统获知时间，才能区分“当时发生了什么”和“当时系统知道什么”。

摄入与更新：从原始事件抽取事实，再比较已有关系

以逐条增量摄入负责人交接记录为例，可以按下面的过程理解：

第 1 步：接收原始记录，抽取候选事实。

Graphiti 把对话、纪要或业务事件作为 Episode ，抽取实体、关系和时间。比如从周三的交接说明中抽出“王蕾从周二开始负责支付回调改造”，并关联原始记录。

第 2 步：匹配已有对象，合并重复信息。

系统先确认新记录里的“支付回调改造”是不是已有任务，再合并重复实体和事实。对上同一个对象，才能比较前后变化。

第 3 步：比较相关旧事实，识别冲突。

系统检索已有关系，由模型结合内容和时间范围判断新旧事实是否冲突。比如，新记录说王蕾正式接手，需要与“李明负责这项任务”比较；若李明负责开发、王蕾负责验收，两条关系则可以并存。新纪要上传得晚，本身不能成为覆盖旧关系的理由。

第 4 步：更新有效区间，保留历史与来源。

给被替代的旧关系补上有效终点，并记录系统时间；新关系从业务生效时间开始有效。旧关系和来源继续保留，方便回查。

要注意写入方式：当前官方说明中，批量摄入不处理关系失效，写入后不一定已经解决冲突。

查询：先确定时间含义，再组织相应证据

应用可以按下面的过程组织查询，具体检索组合取决于配置：

第 1 步：明确对象、范围和时间意图。

从问题中确定要查哪项任务、哪种职责，以及哪个时点。问“现在谁负责”，目标是当前有效关系；问“为什么换负责人”，则需要保留变更前后的事实，不能只查当前状态。

第 2 步：结合查询条件召回相关事实。

关键词找人名、任务名，向量找相近表达，图查询补充关联对象，再按问题中的时间过滤。不能只取最近导入的记录。

第 3 步：核对来源，组织回答。

回到 Episode 核对交接说明和条件，再按排序与上下文预算选证据。解释变更时给出前后依据；来源有冲突，就说明还有什么没确认。

双时态提供时间建模基础，具体历史查询仍需按问题设计，不能假定默认搜索会自动还原任意历史快照。

时序知识图谱的优点与代价

负责人、状态和决定经常变化，又需要查历史时，适合用时序图。它能保留变化过程，区分迟到记录，并回查来源。

代价是时间抽取、实体归并、冲突识别与修复更复杂。业务上还要区分正式变更、条件方案与历史引用：

新信息	应怎样理解
“王蕾正式接手，李明不再负责”	同一任务负责人变更
“如果李明下周离岗，就由王蕾接手”	条件尚未满足
“李明负责开发，王蕾负责验收”	职责不同，可以同时成立
“上周是李明负责”	引用历史，不恢复旧关系

谁有权确认变更、哪些条件才算生效，仍要由应用规则明确。框架维护时间与冲突信息，不会自动提供业务授权。

除了“哪条事实当前有效”，还有一个问题：证据散在长文档里，怎么找齐？接下来看 PageIndex。

3. PageIndex：无向量检索，沿目录树找原文

规则、约束和例外分散在不同章节

用户问：“支付请求超时了，能不能重新发起？”假设一份《支付接口规范》把相关规则写在三个地方：

• 请求超时 ：未收到响应时，可以重试。
• 幂等性约束 ：重试必须沿用原商户订单号，避免重复扣款。
• 附录例外 ：支付状态为“处理中”时，应先查询结果，不要重复发起支付。

只取语义最相近的少量片段，可能找到“超时可以重试”，却漏掉后两条限制。 片段与问题相关，不代表回答所需的条件已经找齐。

可以利用文档自己的结构：目录找章节，摘要看内容，交叉引用提示下一步读哪里。看到“须满足幂等要求”或“例外见附录”，就继续查对应原文。

PageIndex 根据这些线索选择章节，减少整篇阅读。目录和摘要用来导航，答案仍要核对原文；选错分支，也会漏条件。

目录和摘要负责指路，答案要回到原文核对。

用目录、摘要和原文位置组织检索

PageIndex 是 Vectify AI 团队提出并开源的无向量 RAG 方案。 2025 年的官方介绍将它称为“无向量、基于推理的 RAG”（Vectorless, Reasoning-based RAG）。

它先为长文档建立包含章节标题、摘要和页码的目录树。提问时，LLM 根据问题判断该读哪些章节，取回原文；信息不足就继续补读，最后依据证据生成回答。 这条核心检索路径不需要 Embedding 模型或向量数据库。

RAG 可以用多种方式找资料。PageIndex 用模型搜索目录树，仍然遵循“先查资料，再回答”的流程。

PageIndex 怎样工作

构建目录树

第 1 步：识别文档的章节层次。

• 经典实现： 读取已有目录的层级；没有可用目录时，根据正文识别章节。
• PageIndex Flash： 更多利用文本 PDF 的排版提取层次，再结合模型调整结构。

两条路径都要得到章节及其上下级关系；扫描件还需相应的 OCR 或视觉解析。

第 2 步：将章节对应到原文位置。

只有标题还无法取回内容。经典实现会核对标题，把目录页码映射到实际 PDF 页面，确定节点的页码范围；较大的章节还可以继续细分，便于按需读取。

第 3 步：补充摘要，保存索引节点。

模型给节点写摘要，帮助判断该读哪一章。节点还保存标题、标识、页码范围和子节点，方便定位原文或继续往下找。

沿目录树查询

对于“接口超时后能不能直接重试”，一次查询可以这样展开：

第 1 步：确定候选文档和章节。

这里以用户已经选定《支付接口规范》为例；多文档场景还需要先定位候选文件。

进入支付接口规范后，模型读取结构和摘要，判断“请求超时”“幂等性约束”和“异常处理”可能包含依据，得到待阅读的节点。

第 2 步：读取节点对应的原文。

按节点标识和页码范围取得相关页面，检查重试条件。节点摘要只负责帮助导航，不能替代原文成为最终证据。

第 3 步：根据已读内容补查。

读到“错误码例外见附录”，就打开附录；证据还不够，再选其他分支继续读。

第 4 步：依据原文回答并标注出处。

条件查齐后，说明哪些情况可以重试，并标注页面。查不到的关键条件要说明，别把局部规则当成完整结论。

官方示例：先找到章节，再读取图示

官方视觉问答示例使用《Attention Is All You Need》，提问： “Scaled Dot-Product Attention 图中的最后一个操作是什么？” Notebook 保存的示例过程是：

1. 根据目录树定位到 3.2 Attention 和 3.2.1 Scaled Dot-Product Attention 两个节点。
2. 取出节点对应的 PDF 第 3—4 页图片，交给视觉模型读取。
3. 根据图示回答：最后一步是 MatMul（矩阵乘法） ，将 Softmax 后的注意力权重与值矩阵 V 相乘。

这个例子展示了“问题 → 章节节点 → 原始页面 → 回答”的完整路径。代码与保存的输出见官方视觉问答 Notebook，重点看 Step 2：树搜索 和 Step 3：答案生成 。

“无向量、无切块”的边界

“无向量”指检索流程不依赖文本向量索引和相似度搜索。 模型仍需理解问题、选择章节和读取原文，因此省去了向量化与向量库，也会带来模型导航的调用开销。

“无切块”指不依赖固定长度的硬切分；章节、页面和子节点仍是读取单位。官方也提供可选的混合树搜索，用向量召回辅助定位节点，这是另一种组合方式，不是核心无向量路径的必需环节。

PageIndex 的优点与代价

PageIndex 保留了文档层次，支持逐步深入，也便于定位到原文页面。它适合长规范、技术手册和报告，尤其是答案需要同时考虑定义、细则和例外的情况。

解析、建树和多轮读取都有成本。目录或摘要出错会带偏检索，表格和扫描页解析不好也会影响答案，所以要用实际问题验证效果。

如果还要查任务状态和依赖关系，就需要决定下一步查文档、图还是业务接口。这可以交给 Agentic RAG。

4. Agentic RAG：让检索成为可以调整的过程

找到发布计划，还不能确认项目能否上线

固定 RAG 通常按预设流程完成召回、重排和回答。面对“商城支付升级项目能按计划发布吗，卡在哪里”这样的问题，第一次检索可能只找到发布计划。计划说明了上线条件，却不能证明任务已经完成，更不能替代最新验收记录。

下一步查任务系统还是验收材料，要看当前缺什么。Agentic RAG 让查询根据已有结果继续调整，避免把所有来源都查一遍。

让中间证据影响下一步工具调用

Agentic RAG 让模型根据问题和已有证据，决定查什么、用哪个工具、要不要继续查。 它是一种设计方式，没有唯一框架，一个 Agent 也能完成。

Agentic RAG 怎样工作

这次要查上线条件、相关任务和验收状态。取证和检查可以反复进行，每轮补上一个缺口。

第 1 步：明确回答需要什么证据，形成初步计划。

对于这个发布问题，可以先确认上线条件，再核对相关任务和验收状态。

记录原问题、待查来源和未解决事项，并设置调用次数或时间预算。新证据出现后，可以调整计划。

第 2 步：选择工具，取得当前缺少的证据。

定义和规范适合查文档，当前状态适合查业务接口，依赖关系适合查图。GraphRAG、LightRAG、PageIndex 提供各自的检索能力，Agent 根据当前缺口决定调用哪一种。

例如，Agent 可以用图检索找出发布依赖，用 PageIndex 查接口规范中的验收要求，再调用业务接口确认状态。

工具结果应带上来源、时间和适用范围，避免把旧记录当成当前状态。权限、查询范围和可执行操作由工具层约束，不能只靠模型自行遵守口头约定。

第 3 步：检查证据，决定是否补查。

如果任务系统只返回“开发完成”，还不能直接判定“验收通过”，就需要把验收记录列为待查事项。

结果不相关，就改写问题、拆成子问题或换来源，再查一次。每轮记下新证据和剩余问题，避免重复查或跑题。

LangGraph 的官方示例使用检索工具、相关性判断和问题改写构成循环，展示了如何让检索结果影响后续动作。

第 4 步：满足结束条件时，给出有依据的结果。

关键证据齐全后，回答能否发布、阻塞项是什么，并附上来源。

连续没有新增证据、达到调用预算或必要来源不可用时，也应结束调查，但要说明哪些结论仍无法确定。达到预算只代表停止调用，不代表证据已经充分。

多查一轮，要解决一个明确的证据缺口

Agentic RAG 适合需要调查、跨来源核对的问题，能够根据证据调整路径。但工具选择可能出错，模型也可能把“相关资料”误判为“充分证据”；多轮查询还会增加延迟和调用成本。

评估时要看工具选得对不对、证据够不够，以及耗时和成本。简单问题可以直接走固定流程，需要补证据时再多查一轮。

反复整理的项目背景和方案关系，可以存下来复用。接下来的 LLM Wiki 就是做这件事。

参考资料

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

1. Graphiti 项目
2. 时间字段说明
3. Graphiti 的时序架构
4. Episode 摄入说明
5. Graphiti 检索说明
6. PageIndex 官方介绍
7. PageIndex 项目
8. 经典建树实现
9. Flash 建树方式
10. 官方视觉问答 Notebook
11. 混合树搜索
12. Agentic RAG 示例
13. 《Agent 知识库这些年：从 RAG 到 OKF 0.2》

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