深入理解agent学习笔记(十四)——RAG 组织与更新
- 2026-11-10 19:06:23
点击下方卡片，关注“人工智能陈小白”
视觉/大模型/图像重磅干货，第一时间送达!
1. 为什么扁平文本块不够
RAG 基础技术解决了「给定一个文本块，如何找到最相关的那几个」。但更根本的问题是：这些文本块本身该怎么组织？
把文档切成互不关联的扁平块，会丢掉知识固有的层次与跨文档关联。面对技术手册、法律文书、学术论文这类结构复杂、逻辑严谨的材料，只检索零散片段，就像靠字典的随机词条理解一部小说。
两个案例说明问题：
黑猫白猫计数。知识库有 100 个独立案例文档（90 只黑猫、10 只白猫，每个是独立文本块）。用户问「比例是多少」，受 top-k（如 20）限制，大部分案例根本不会被检索到；模型只能基于不完整样本（如 15 黑 3 白）得出错误结论。若预先生成摘要「共 100 只：90 黑（90%）、10 白（10%）」并索引，一次检索就能得到准确信息。
优惠资格边界。知识库是客服工单归档，几百条工单各记录一次处理结果：退伍军人通过、医生拿到折扣、教师不符合……没有任何一条写着资格范围本身。护士来问「我能不能享受优惠」时：
- 最近邻偏置
：「护士」与「医生」语义最近，医生那条排最前，模型顺势推断护士也可以；若教师那条排得更前，同一问题会得到相反答案； - 边界语义缺失
：调大 k 也解决不了——「仅限……，其他一律不适用」这种带全称与否定的边界，不存在于任何单条工单中； - 完整性信号缺失
：模型无从判断自己是否看全，于是不会追问，只照手里几条自信作答。
解决办法要从索引阶段入手：离线通读工单库，提炼一条规则卡——「优惠适用于现役与退伍军人、持证医护人员（含护士）；教师等其他职业不适用」。
未经提炼和结构化的知识，模型无法可靠利用。 无论存向量库、检索后注入，还是直接塞进长上下文，都需要在索引阶段投入计算，对原始知识主动提炼、抽象、结构化。
2. 结构化索引：树与图
索引前先用 LLM 把知识整理一遍——归纳、抽象、建立关联，用更多计算换更好的检索质量。两条主流路线：树状层次（RAPTOR）与实体关系图（GraphRAG）。
2.1 RAPTOR：自下而上的递归抽象
图 1：RAPTOR 树状层次索引
RAPTOR 把长文档切成小文本块作为「叶子节点」，再用聚类把语义相近的叶子分组——类似把图书馆的书按主题自动分堆：计算文本块之间的相似度，最相似的归为一类，每一类代表一个主题。
例如技术文档中，关于 SSE 指令的多个叶子（「SSE2 支持 128 位整数运算」「SSE4.1 新增字符串比较指令」）会聚到同一组，系统自动生成父节点摘要「x86 SIMD 指令集的各代演进」。这个过程不断递归，最终形成一棵从具体细节到高度概括的知识树。
检索可以在多个抽象层次上进行：既能精确回答细节，也能提供宏观概念。适合「从概念逐步钻进细节」的查询。
2.2 GraphRAG：实体与关系
图 2：GraphRAG 实体—关系知识图谱
GraphRAG 把知识建模为实体（Entities）与关系（Relationships）构成的知识图谱，用「主语—关系—宾语」三元组表达知识，如（北京, 是首都, 中国）、（张三, 就职于, 腾讯）。
两个核心优势：
- 多跳关系推理
：问「我的医生所在医院的地址」，需要沿「用户 → 医生 → 医院 → 地址」遍历。扁平记忆要么多次独立检索再由 LLM 拼接（效率低、易断链），要么根本无法表达；图结构天然支持沿边遍历。 - 实体消歧
：注意它与「一词多义」不同——判断 bank指河岸还是银行，是词义消歧，靠上下文嵌入即可；区分现实中两个同名的「张医生」，是实体消歧，需要维护实体本身的知识。在图谱中，（张医生-A, 科室, 牙科）与（张医生-B, 科室, 心脏科）是不同节点，消歧是图结构的原生能力。
GraphRAG 先用 LLM 抽取关键实体，再抽取关系，然后通过社区发现找出语义紧密的实体集群并生成摘要，自动发现知识中的主题聚类。它特别擅长回答涉及多实体复杂关系的问题。
但作为用户记忆的通用存储方案，知识图谱有固有局限：把自然语言转成三元组会导致语义降级——「如果下周还下雨，我就取消去海边，改去博物馆」包含条件与时间依赖，分解后只剩孤立事实，核心逻辑丢失；三元组提取的准确性也高度依赖 LLM，错误提取会污染知识。
因此推荐分层互补：用完整自然语言保存核心信息（保留语义完整性），辅以结构化元数据做索引与检索；在需要多跳推理与精确消歧的垂直场景（医疗、法律、家族关系），把知识图谱作为专项索引，与自然语言记忆协同。
2.3 什么时候需要结构化索引
不是所有场景都需要 RAPTOR 或 GraphRAG。混合检索（稠密 + 稀疏 + 重排序）已经覆盖大多数需求。判断标准：
查询主要是「找到包含某信息的文档片段」（如「退款政策是什么」）——混合检索就够； 查询经常需要跨文档综合（如「SSE 与 AVX 在架构上有什么区别」）或多层次导航（从整体架构到具体指令）——结构化索引才值得投入。
结构化索引的代价是索引构建与查询都需要更多 LLM 调用，成本与延迟显著增加。
3. 文件系统范式
RAPTOR 与 GraphRAG 代表学术探索，OpenViking 提出第三种哲学：文件系统范式。它不把上下文视为扁平向量或图谱节点，而是把记忆、资源、技能映射为虚拟文件系统中的目录与文件，每个条目有唯一 URI：
viking://├── resources/ # 外部知识：文档、代码库、网页├── user/memories/ # 用户记忆：偏好、习惯└── agent/ # Agent 自身：技能、经验├── skills/└── memories/
viking:// 是虚拟 URI，不指向具体物理位置；Agent 通过它访问知识，框架在背后决定从内存、磁盘还是远程加载。
核心设计是 L0/L1/L2 三层按需加载：
- L0（摘要）
：约 100 token 的一句话概述，用于快速判断目录相关性； - L1（概览）
：约 2,000 token 的核心信息与使用场景，供规划决策； - L2（全文）
：完整原始内容，仅在需要深入时加载。
每个目录自动生成 .abstract（L0）与 .overview（L1），形成从根到叶的层次摘要。若 L0 判定无关，就无需加载 L1/L2；大部分查询加载到 L1 即可决策，token 消耗大幅降低。这与 Skills 的渐进式披露如出一辙：先看轻量元信息，需要时再逐层拉取全文。
选择 Markdown 纯文本而非专用数据库，是深思熟虑的工程决策：纯文本可读、可编辑、可修正；可通过 Git 版本控制与回滚；Agent 拥有 write_file 后，可在工作分支自主记录知识，再经审核合入主库。
但纯文本文件系统有一个极易忽视的前提：文件之间必须建立链接与索引。.abstract/.overview 解决纵向层次摘要，横向关联还需要交叉引用——如果知识只是一堆互不相连的文件，除了逐个全文扫描或向量检索，Agent 几乎无法在相关条目间导航。
正确做法是把知识库组织得像 Wikipedia：每个条目提及其他条目时用链接指向它，再辅以入口页与索引页，让 Agent 能顺着链接从一个概念走到相关概念。这相当于用轻量文件链接，实现 GraphRAG 图谱的一部分导航能力。
不同模型主动建立链接的意愿与能力不同：能力强的模型写入新知识时会自发回指已有条目、维护索引；不少模型只会孤立地追加文件。因此写入提示词必须写明确——每新增一个条目，先检索并链接相关条目，再更新所在目录的索引页，形成双向可达的引用网络。
4. 知识更新：像代码库一样管理
上线运行的记忆或知识库会持续收到新信息。只更新不整理，内容越积越乱；只定期重写，新信息又无法及时生效。完整机制要同时包含事件触发的增量更新与周期触发的全量整理。
4.1 增量更新：把变更当 PR
最稳妥的工程答案：把知识库当代码库，把每次知识变更当成一个 Pull Request。
不只适用于可执行记忆；Markdown 知识库、用户记忆文件、规则文档同样应进入 Git，获得差异审查、版本历史、责任追溯与一键回滚。生产环境不应让任何模型绕过审核，直接改主分支或线上向量库。
沿用提议者—审核者模式：
- Proposer Agent 提交 PR
：从原始证据发现新事实、冲突或过期内容，在工作分支提出尽可能小而完整的 diff。它不是把最新对话粗暴追加到文件末尾，而是先检索相关已有知识，再增删改对应条目，同步维护链接、索引、时间元数据与证据引用。 - Reviewer Agent 独立审核
：拿到变更前知识、diff 与原始证据（轨迹、原始对话、业务文档、工具结果），逐条检查新断言是否有证据支持、是否遗漏限定条件、是否与其他文件冲突、删除或改写是否过度。不通过时返回指向具体证据与行号的可执行意见，而不是「还需改进」。 - 迭代至收敛
：Proposer 根据意见修改，Reviewer 回到原始证据复核；只有明确批准才可合入。设置最大迭代次数或成本预算，超限转人工，不能默认放行。 - 合入后再发布
：CI 检查格式、链接、元数据、权限标签；知识以代码表示时还要跑类型检查与测试。通过后才从已合入版本增量重建分块、摘要与向量索引。索引是可重建的派生物，Git 中已审核的知识才是来源。
这条流水线要分清三层：
- 原始证据层
：只增不改的对话、轨迹、原始文档； - 知识层
：经过提炼、可修订的 Markdown 或代码； - 服务层
：从特定已合入版本生成的检索索引。
PR 记录证据标识、知识库版本、审核意见与最终决定，使线上每条知识都能回答「从哪条证据而来、谁在什么时候批准」。
Proposer 与 Reviewer 都必须是 Agent，而不是两次固定 LLM 调用。 知识更新不是对一段预选文本做摘要：Proposer 要主动搜索其他记忆与规则，Reviewer 要追溯证据、对比多份文档、运行检查、发现新线索继续查询。它们需要文件搜索、版本比较、测试执行、证据检索工具，现成 Coding Agent 通常就能胜任。两者都应能按需查询完整知识库与证据库（在被授权的租户或用户范围内），工作轨迹与审核反馈也要归档。
两个 Agent 优先使用能力相近但来自不同家族的模型：Proposer 用 Claude，Reviewer 用 GPT；或 Proposer 用 DeepSeek，Reviewer 用 Kimi。不同训练数据、偏好与推理习惯可降低在同一处犯同类错误的概率；能力不宜悬殊，否则 Reviewer 跟不上复杂证据。异源互审增加独立性，但不能取代原始证据。权限上强制分工：Proposer 只能写工作分支，Reviewer 只读证据并提交审核结果，只有合并流程能更新主分支与线上索引。
4.2 定期整理：回到原始数据
增量更新及时，但每次只看到局部。长期运行后，多次局部正确仍可能累积全局问题：同一事实散落多文件、新旧说法并存、摘要偏离原始证据、目录结构不再适合当前规模。因此需要周期性全量整理——类似「睡眠学习」：前台交互累积证据与局部更新，后台在周期窗口里从全局重新审视。
至少三项工作：
- 去重、去旧与合并
：识别语义重复、已被取代、过度碎片化或只有表述差异的条目，删除、归并或重写；重新建立文件链接、入口页与索引页；必要时拆分过大文件、合并过小文件、调整目录层次。删除的是可服务的知识表达，不是下层只增不改的原始证据。 - 回到原始数据核查
：不能只在摘要之间相互改写，否则早期遗漏与误读会一代代传下去。整理 Agent 要逐段对照原始对话、轨迹、业务文档与工具输出，检查是否遗漏关键事实、丢失否定词或时间条件、把推测当成事实。大型知识库可按目录/时间/主题分批，但必须保留覆盖清单，确保最终覆盖全量，而不是随机抽样。 - 冲突解决与场景限定
：遇到矛盾，不简单「保留最新」或让模型猜，而要追溯各自信息源，检查是否在不同时间、对象、地域、任务或前置条件下成立。两者都有效，就把适用场景写进知识；证据不足，就保留冲突与待确认状态，不得强行收敛。
定期整理同样由 Proposer 在分支提交重组 diff，再由异源 Reviewer 结合证据审核；大 diff 可按目录/主题拆成多个 PR，但共享同一份整理计划与覆盖清单。全部通过后，除重建全量索引，还应回放一组典型检索与问答用例，确认新结构没有让原本可找到的知识变得不可见。
失效内容检测与下线：被新版取代的旧政策若仍留在库中，检索时可能与新版一起召回，让模型给出自相矛盾或过时的答案。生产系统通常给分块附加版本号、生效/失效时间，在检索阶段过滤失效内容，或在摘要中显式标注「此条已于某日废止」。
多用户共享的权限与租户隔离：知识库面向所有用户共享，但不等于所有内容对所有人可见。关键原则是检索必须按调用者权限过滤，绝不能让越权文档进入上下文；一旦敏感内容进入 LLM 上下文，就很难保证不以某种形式泄露。多租户系统还要保证租户之间的向量索引与元数据隔离。
5. 补记
结构化索引的价值不是「更高级」，而是匹配查询形状：需要跨文档综合、多层次导航时，树与图值得投入；只是查某个片段，混合检索更便宜。文件系统范式的启发则在于：知识组织不一定依赖专用数据库，纯文本 + 链接 + 索引 + Git，也能获得可读、可审、可回滚的知识库。
知识更新的关键不是「让模型改写」，而是让变更可审查。把知识当代码、把修改当 PR、把证据与版本绑定，才能回答「为什么改、依据是什么、改错了怎么回滚」。
欢迎同学添加小助手，获取代码或加入人工智能圈交流群
