如何管理智能体的上下文？RAG、LLM Wiki 和 GraphRAG

我清楚地记得，小时候大约十岁或十一岁，我们住在蓬塔德尔加达，我总是兴冲冲地跑回家，去看历史频道和探索频道的纪录片。每天都不例外，我的脑袋会记住成千上万个细节：“哦，古希腊人的一些神庙里居然有投币就能领取圣水的机器！”年复一年，这逐渐成了一个我至今保留的习惯。在过去这（将近）36年里，我大概看过数以万计的纪录片和视频，内容涵盖科普、历史、哲学及其他主题。而那个（显而易见的）事实是，我听过、看过和读过的内容，有99.9%都没有留在脑海的任何角落里。

有些事实确实留下来了，可能是因为它们像古希腊机器的故事一样有趣，也可能是因为我记了笔记，后来又读了一遍，或者因为我已经充分理解并吸收了它们，让它们成为常识的一部分，也可能是因为它们与其他难忘的记忆相连，又或者只是因为记忆还很新鲜。

由此可以引出一个有意思的类比，但不能把两者等同起来。基础模型（用大量、多样化数据训练，可以适配不同任务的AI模型）也不是在每一个时刻都能拿到所有信息。不过，我们需要区分训练过程中学到的知识与当前的上下文，后者是模型在某一次调用中收到的信息。

训练时，模型接触的数据量超过任何一个人一生所能消化的总量。其中一部分内容融入了模型基础知识的集合。而且，和人类一样，模型也可能吸收假新闻和错误观念。

在日常使用中，模型会把这些基础知识与多种上下文来源结合起来。如果我想让一个AI智能体自动筛选邮件，并给收件箱里的邮件排优先级，它会使用自身已有的基础知识、我提供的流程知识（指令），以及邮件本身的数据（具体任务的知识）。但这就碰到了这项技术最大的限制之一，模型的上下文窗口是有限的。有些前沿模型的窗口达到了100万token的量级。对于英文文本，可以粗略地认为每个token平均相当于四个字符。因此，100万token大约相当于英文原版《指环王》三卷全部文字的一倍半。

这里，我把智能体定义为一种使用基础模型（FM）做决策和调用工具的程序。每次需要接收信息并做决定时，它都要调用模型。没有包含在这次调用里的信息，就不能作为上下文使用，即使这些信息曾经出现在上一次调用中。行业一直在寻找绕过这个限制的方法。我在这里把那些向智能体提供所需的上下文，并在需要时提供的做法，称为上下文管理技术。其中一个基本思想是渐进式信息披露，也就是随着过程推进逐步提供上下文，同时给智能体配备工具，让它能够获取所需的信息。

整个领域都相对较新，因此不存在一种通吃所有场景的方案。行业里常见的启发式方法有好几种，其中应用最广的之一是检索增强生成（RAG）。这种技术通常会按照固定大小、语义上下文、文档层级等不同标准，把文档分成若干片段。这些片段往往会被转换为数值表示，也就是我们所说的嵌入向量（embeddings）。¹需要时，智能体会搜索这些信息，取得被判断为与任务相关的片段，再用它们生成答案。通常，它可以进行词法检索（查找特定词语）、语义检索（查找含义与任务需求相近的片段），或混合检索（两者结合）。当需要在很长的文档中找到具体信息时，这种方法非常有用，典型例子就是从一份500页的合同中提取相关信息。不过，即使智能体很好地构造了查询，也可能拿不到完成任务所需的全部片段，从而只得到不完整的上下文。尽管如此，行业和学术界依然经常讨论这项技术，而且在我见过的落地案例里，它几乎无处不在。

但这不是唯一的做法。生成式AI领域最常被提起的人物之一安德烈·卡帕西提出了LLM Wiki。²这种方法使用Markdown文件（.md），也就是带有特定格式语法的文本文件，来维护一个索引，以及一组彼此相连的知识页面。这些页面的知识由原始资料综合而来。智能体可以在需要时完整阅读相关页面。就像我拿到一个新东西，翻开使用说明书，根据目录只阅读对我有用的部分。在好几个使用场景里，这是我最喜欢的方法，因为它比较一致，也容易维护或手动调整。不过，在复杂场景中，它的维护负担可能比给新版文档生成嵌入向量并更新索引更重。我们可以建立信息提炼的流水线（我指的是减少文本量，同时保留信息密度），来维护一份LLM Wiki。这也正是卡帕西提出的做法。然而，以我的经验，模型在这类信息提炼上仍然相当容易出错，经常漏掉原始信息的细微差别，也容易忽视文档整体上想达到的目的。于是，知识整理与维护的工作很快就变得沉重。

最后，这篇文章已经有些长了，我不想让读到这里的人打退堂鼓，所以想简要谈谈GraphRAG，也就是Graph Retrieval-Augmented Generation。或许可以先说说什么是图：它是一种数学或计算结构，由一组顶点（节点）以及连接它们的边（或链接）组成……先喘口气。简单来说，它是一种表示信息以及数据间关系的方法，如下图所示。社交网络就是一个很好的例子，不同人的名字可以彼此连接，但这些连接有方向：Joaquina关注Manuel，Manuel关注Ramiro，而Ramiro又关注Joaquina。这并不意味着Manuel关注Joaquina，也不意味着Joaquina关注Ramiro。人是节点，连接则是“关注”关系。信息可以有方向，而关系是明确表达出来的。

从A指向B的箭头表示“A关注B”。反向关系并不隐含在其中。

GraphRAG使用知识图谱，把实体（概念、物体、人物）及其关系组织成一个可供查询的网络。智能体可以更容易地沿着这些关系展开检索，寻找完成任务所需的信息。找到的信息随后会作为上下文交给模型，用来生成答案。当需要综合多份文档中的信息时，这种能力可能尤其有用。和其他方法一样，信息与关系都必须经过整理和维护，特别是当它们由智能体自主生成时。例如，如果关系有误、不完整或已经过时，智能体可能漏掉重要信息，或者依据已经不再合理的连接作答。我就遇到过这种情况，用了这套方法后，得到了一个复杂到连我和智能体（向Sr. Alfredo致意）都搞不清里面有什么的网络。

这三种方法并不相互排斥。对于一个比较复杂、方法也较为成熟的企业实施项目，完全可能视具体情况同时采用三种方法。Wiki可以通过RAG来检索，GraphRAG本身也是利用检索到的信息来支持生成的一种方式。下面是我判断何时使用哪种方法的思维模型概要：

不过，上下文管理的话题并不止于此。这只是我围绕这个主题展开的系列文章的第一篇。以后我们还会谈到缓存（caching）、压缩（compaction）、上下文裁剪（context pruning），以及通过子智能体隔离上下文。我们很快再见。