从聊天机器人到通用agent：如何让大模型成为操作系统核心

论文标题：The Compressor-Retriever Architecture for Language Model OS论文链接：https://arxiv.org/pdf/2409.01495项目地址：https://github.com/gblackout/LM-OSLLMs增强了其跨多种模态聚合和处理信息的能力，使其能够执行多模态数据查询、工具使用、网页交互和处理长文档等广泛任务。这

江湖人称麻花滕

989人浏览 · 2024-09-21 20:05:23

江湖人称麻花滕 · 2024-09-21 20:05:23 发布

一、论文的简单介绍

论文标题：The Compressor-Retriever Architecture for Language Model OS

论文链接：https://arxiv.org/pdf/2409.01495

项目地址：https://github.com/gblackout/LM-OS

LLMs增强了其跨多种模态聚合和处理信息的能力，使其能够执行多模态数据查询、工具使用、网页交互和处理长文档等广泛任务。这些能力为将LLMs从单纯的聊天机器人转变为能够与现实世界交互的通用代理铺平了道路。

论文探讨了将语言模型作为操作系统的核心组件的概念，有效地充当处理存储在上下文窗口中数据的CPU，该上下文窗口充当RAM。实现这种LM OS的一个关键挑战是管理终身上下文并确保会话间的状态性，这是由于当前基于会话的交互范式受上下文窗口大小限制而有限的功能。为了解决这个问题，论文引入了压缩器-检索器，这是一种用于终身上下文管理的模型无关架构。与检索增强生成等其他长上下文解决方案不同，论文的方法仅使用基础模型的前向函数来压缩和检索上下文，确保端到端可微性。具体来说，压缩器构建了一个分层数据库来存储分块的过去上下文，其中每个块由从粗到细的记忆层次结构表示；检索器通过自上而下的稀疏检索来搜索相关上下文，动态地收集不同粒度的上下文，仅使用纯自注意力机制。在论文的初步实验中，论文在上下文学习（ICL）推理任务中验证了这种设计，论文的模型显示出与理想设置相比有希望的性能。

实验显示了该架构的巨大潜力，为开发LM OS奠定了基础。

二、论文的简单介绍

2.1 论文的背景

LLMs可以作为一个中央模型，以统一的方式聚合和处理来自不同来源和模态的信息。例如，它可以回答多模态数据的问题，使用工具，使用桌面应用程序和网络，回答长文档的问题。这些努力从根本上将LLMs从单纯的聊天机器人转变为能够与现实世界互动并以不同方式帮助用户的通用智能体。最近，这些进展引发了将LLM作为操作系统（OS）的想法，其中LLM被用作OS的CPU，处理存储在RAM（即上下文窗口）中的数据，并调用外部工具作为函数。

然而，要实现这一目标，需要解决几个关键挑战。操作系统最重要的特征之一是它永远保持状态。如果允许，它可以存储所有数据、软件和运行日志，并在完成未来任务时检索它们。相比之下，到目前为止，论文与LLMs的大多数交互都是基于会话的，LLMs在不同会话之间基本上是无状态的。

图1：构建一个语言模型操作系统（LM OS）需要一个有原则的架构来管理上下文的生命周期。

这种基于会话的与大语言模型（LLM）交互的范式是由多个因素导致的，其中一个因素是上下文窗口的限制。最近的LLM通常预训练时使用约4K窗口大小（或更高，对于某些专有模型），并且可能通过长达32K或更多的长上下文进行微调。在推理时，一些模型可以扩展到数百万个输入token，例如Gemini。尽管这看起来很大，但对于一个操作系统来说，仍然远远不足以消化可能被提供给它的上下文，以使其在意义上保持状态：单个高清图像可能需要超过1K个token来表示；一次网络搜索可能返回10个网页，每个网页包含数千个token；一个仓库级别的代码可以轻松达到数千行。虽然基于会话的范式已经可以解决许多问题，但许多日常任务仍然需要访问长上下文。为了开发一个能够协助处理现实世界任务并在整个过程中保持状态的LM OS，必须以终身的方式管理上下文信息（图1）。论文认为，缺乏一个有原则的架构来管理上下文的生命周期是从基于会话的范式转向操作系统范式的主要障碍之一。

论文提出了一种新颖的架构来管理终身上下文，即压缩器-检索器架构。论文设计这种架构使其保持模型无关性，并对基础模型结构施加最小的更改。与现有的解决方案（如检索增强生成（RAG））不同，该架构不引入独立的模块，仅依赖基础模型的前向函数来压缩和检索上下文，使得整个过程是端到端可微分的。

图2：压缩器-检索器架构概览。

2.2 论文的方法

论文提出了一种新颖的架构，以一种原则性的方式管理上下文的整个生命周期。一个理想的设计应具备以下特性：（1）处理无限长度的上下文；（2）依赖于状态和任务的压缩检索；（3）端到端可训练，无需额外的独立模块。压缩器-检索器架构通过引入两个模块：压缩器和检索器来实现上述目标。论文不是引入独立的适配器，而是设计模块以充分利用基础模型的前向传播作为构建块。背后的思想是，论文相信基础模型通过大规模预训练已经获得了压缩和重建信息的能力，这可以通过在基础模型上进行监督微调来激发。另一个好处是，由于论文只使用前向函数，论文的架构可以轻松应用于所有仅解码器Transformer模型。

2.2.1 压缩器

设 f_llm为基础LLM模型。前向函数 f_llm ( x ) 将输入x（n 个token，潜在维度为 d）映射到相同大小的输出嵌入h，其中h 是最后一个隐藏状态。

压缩器模块通过在上下文中附加特殊的 m= token，并在之后获取相应的隐藏状态，将给定的上下文压缩为一前向传递:

设 k 为压缩因子，m = [ m_1, m_2,… ] 是大小为 n / k 的 token序列，编码了 x 的压缩信息，并对应于序列 x 的输出，论文忽略这一点。M 是特殊的注意力掩码，论文将在下面介绍。

面向检索的压缩（Retrieval-oriented compression）。到目前为止，压缩器类似于先前工作中提出的压缩技术，如AutoCompressor和 ICAE。然而，论文引入了两个重要特性，以实现更灵活和终身管理的上下文信息。

论文不是仅在单个会话中压缩和重用上下文，而是寻求构建一个分层数据库，该数据库存储所有外部和过去的上下文，例如通过网络搜索检索的页面、整个过去的聊天历史记录、过去工具使用生成的日志等。这样的数据集应以一种能够高效检索上下文并具有不同粒度级别的方式构建。

为此，论文通过迭代压缩上下文来构建分层数据库，形成一个编码从粗到细信息的嵌入层次结构。形式上，给定一个段落 x，论文有：

对于固定的压缩因子 k，这形成了一个层次结构。在此基础上，可以通过处理整个过去上下文的块形式 x_0, x_1,…, 来构建数据库，生成的层次结构可以存储在磁盘上以供将来检索使用。

分段注意力掩码。在检索阶段，模型将进行自上而下的检索搜索以找到相关的上下文。为此，论文将标准的因果注意力掩码修改为分段注意力掩码。具体来说，让[x,m]表示要压缩的序列，mj表示m的第j个token。标准的注意力掩码允许mj关注整个序列x。然而，如果这样做，一旦在检索阶段选中mj，就不清楚它具体关注哪个部分，这使得难以缩小要检索的范围。相反，论文让mj关注x的某个特定段。分段方式可以有很多种，在这项工作中，论文首先研究了一种简单的方案，即将x按顺序分割成长度为k的段，mj关注[x_k∗(j−1), …, x_k∗j]这个段。论文发现这种方案是有效的，并将更高级方案的研究留待未来工作。论文在图3中展示了相应的注意力掩码。

2.2.2 检索器

现在论文展示如何从层次数据库中检索上下文。与压缩器类似，在这个过程中论文仅使用基础模型及其前向函数。这与之前的检索增强生成（RAG）等工作不同，后者依赖外部小型模型来索引和检索上下文。论文认为这种设计可以充分利用基础模型的能力，并对模型架构施加最小的更改，使其易于微调。

检索过程首先将当前上下文编码为检索嵌入，这些嵌入将用于保存检索到的信息。设 x 为当前上下文，r=< ret >为特殊的检索token，论文有：

其中 r=[ r_1, r_2,… ] 是附加的 token序列。例如，对于一个 4K 窗口和 1K 上下文，可以指定 1K 用于检索到的上下文，其余 2K 用于生成。也就是说，检索嵌入大小是一个超参数，主要取决于硬件资源和任务的性质，应根据具体情况确定。

自顶向下的稀疏检索。现在论文从r 开始检索相关上下文。设 r 是其中一个检索嵌入，论文的核心检索机制是使用 f_llm 计算这些记忆相对于r 的注意力分数，然后从上到下逐级聚合到 tilde r 级别，即

考虑到这些观察结果，并且论文知道更高层次的嵌入在其低层次嵌入上的注意力位置（得益于分段注意力掩码），论文进一步提出稀疏检索：

2.2.3 训练

压缩器-检索器架构并未引入额外的独立模块。尽管论文相信预训练的大型语言模型（LLMs）已经具备了必要的能力，但仍需要微调以激发这些能力。设置训练数据和流水线并非易事。论文将从参数、训练目标、数据和性能考虑四个方面讨论挑战及论文提出的解决方案。

可训练参数。运行该架构所需训练的最小参数是和token的两个嵌入。然而，在实验中，论文发现通过微调基础LLM的参数可以获得最佳性能。这一观察结果在相关工作中也得到了证实。在论文的初步实验中，论文发现LoRA微调已经足够。然而，如果有足够的硬件资源，也可以进行全参数微调以获得最佳性能。总之，可训练参数包括所有线性层上的LoRA适配器以及两个嵌入。

训练目标。由于架构是端到端可微分的，因此训练模型学习压缩和检索上下文变得简单直接。论文使用标准的自回归目标

其中模型根据先前的上下文和分层数据库 M =[ m_0, m_1,… ] 预测下一个token。直观地说，为了预测下一个token，模型学习从数据库中检索最有价值的上下文。在实验中，论文发现这个目标已经足够，这与先前工作[Chevalier et al., 2023]中的观察结果一致。论文将在未来的开发中探讨其他目标，例如重建损失。

数据。为了有效地利用压缩和检索能力训练模型，需要精心策划训练和推理数据集。与通常为4K长的标准序列预训练不同，必须收集高质量的长上下文数据。然而，与The Pile和FineWeb等短上下文预训练数据相比，原生的长上下文数据几乎不存在。为此，许多工作依赖于私有收集的数据或合成数据。在论文的实验中，论文通过在一个小规模问题上验证论文的架构来规避这一挑战，并将这部分内容留待未来开发。

除了支持模型能力的数据外，论文还需要收集数据来教导模型在推理过程中管理上下文。这类似于指令微调数据集。例如，在推理过程中，模型需要知道何时启动检索。论文计划通过构建插入特殊检索token <call retrieval> 的微调数据集来解决这个问题，模型学会解码该token以启动检索过程。这种方法在先前的工具使用工作中也有应用。

性能考虑。与标准的自回归训练相比，论文的训练成本更高。对于目标序列 x，标准训练仅进行一次前向传播，以 x 作为输入来获取预测标签，并且仅保存此次前向传播的中间激活用于反向传播。论文的情况在某种程度上类似于循环模型，如 RNN，因为标签预测依赖于前一次前向传播的输出。具体来说，设c 为长度为 n 的上下文，k 为压缩因子。首先，需要进行 L=「log_k n 」次前向传播来构建层次结构。然后，对于检索，需要再进行 L+1 次前向传播来生成检索嵌入并搜索到底部。最后，进行最后一次前向传播以预测 x 的标签。总共，在调用反向传播之前需要进行 2L+2 次前向传播。除了计算成本外，这还导致了另外两个问题：

中间激活：PyTorch 保存了反向传播所需的注意力机制和嵌入等激活。设 T_ 为反向传播前调用的总前向传播次数，空间复杂度为 O(Tn^2+Tnd)。通常，与那些长达 32K 的上下文训练相比，这个成本是适中的，因为它随上下文长度的平方增长，并且通过论文的架构，论文可以始终将每次前向传播的最大长度限制在一个较小的数值（例如，4K 甚至更小）。尽管如此，考虑到上下文块的总数可能非常巨大（例如，10M 个token被分割成 5K 个长度为 2K 的块），不可能将所有激活存储在 VRAM 中。在论文的实验中，论文使用梯度检查点来缓解这个问题。论文还研究了实现自定义的打包和解包函数，将块激活转储到 RAM 和磁盘，并且仅在它们位于前 C 个索引时加载它们。
Potential gradient instability：循环模型的主要缺点之一是梯度消失/爆炸问题，因为需要展开循环前向调用以计算梯度，这也被称为时间反向传播（BPTT）。一个广泛使用的解决方案是截断BPTT，即在展开一定次数后停止梯度。这种技术在先前的工作中也被用于transformer模型。

不幸的是，这在论文的情况下无法应用。与这些工作中使用的seq2seq训练不同，每个循环调用有两个梯度来源（一个来自当前状态的预测损失，另一个来自后续状态的BPTT），压缩和检索调用在潜在空间中进行，因此没有真实标签，所以唯一的梯度来源是最终的自回归损失。这意味着必须执行完整的BPTT以获取压缩和检索的损失信号。尽管听起来很糟糕，但到目前为止，论文在实验中还没有遇到任何梯度问题。这部分是由于深度L相对于n以对数尺度增长。例如，一个4K块因子为4时，仅导致6层。因此，论文情况下的总循环步骤数通常很小。尽管如此，论文还研究了使用中间损失（例如，来自压缩嵌入的重构损失）来训练压缩和检索过程，以避免执行完整的BPTT。

2.2.4 推理

使用压缩-检索架构进行推理是直接的。一个典型的会话从空上下文或类似于RAG用例中的现有上下文开始。给定一个上下文窗口大小，论文在整个交互过程中主动管理窗口。例如，当当前上下文即将超过窗口大小时，它会自动压缩上下文并将其添加到数据库中。在与用户交互期间，模型可以设置为在生成时主动检索，或者在指令微调后，设置为在认为合适时主动生成 token。

异步检索。在任何情况下，检索过程都可能阻塞生成过程，导致一定的延迟。与训练阶段不同，在训练阶段压缩和检索发生在生成之前且同步进行，可以将这两个过程设置为在后台异步运行。例如，当模型解码 <call retrieval> token时，它会在一个单独的进程中启动检索，并继续当前的生成，随着生成的进行，结果将逐步添加到当前上下文中。

2.3 论文的效果

论文在一个小规模的初步实验中验证了该架构。

任务。论文在上下文学习（ICL）设置中评估了论文的架构在推理问题上的表现。给定一个问题 q，模型被要求预测答案 a。与目标问题一起，还包括几个示例<q, a> 作为少样本示例。在论文的上下文中，论文认为所有 ICL 示例c={<q, a >_1, <q, a>_2,… } 都是上下文，目标问题 x=q 是输入序列。

如果模型从未在目标数据集上进行过训练，包含ICL示例c将显著提高性能，相比于零样本情况。因此，论文可以通过测试模型是否能有效压缩和检索“正确”的ICL示例来解决当前任务，从而验证论文的架构。具体来说，论文为模型提供来自与目标问题相同数据集的ICL示例以及来自其他推理任务数据集的示例。换句话说，一些ICL示例是相关的，而其他则是无关的。然后论文限制窗口大小，使得模型只能选择示例的一个子集。如果模型能够成功检索到相关的示例，那么其性能将接近于全示例情况。

数据。论文使用四个推理数据集来构建论文的训练和测试数据集：GSM8K 包含数学问题，FOLIO 包含自然语言推理问题，proScript包含图推理问题，Re-Clor包含常识推理问题。这四个任务足够不同，因此它们的ICL示例是无关的，对解决其他问题贡献甚微。论文通过将它们的正确答案连接到问题上来构建ICL示例。

设置。论文使用LLaMA3.1-8B-instruct作为实验的基础模型。论文选择instruct版本，以便模型具有合理的零样本能力，这可以作为准确性的“下限”——如果模型检索到正确的示例，其准确性应介于零样本和全示例情况之间。

论文的数据集中每个样本包含6个ICL示例：2个来自与目标问题相同的数据集，4个从其余数据集中随机抽取。对于训练集，目标样本从GSM8K、proScript和ReClor中抽取，不相关的样本从另外两个数据集中抽取；对于测试集，目标样本仅从FOLIO中抽取，不相关的样本从GSM8K、proScript和ReClor中抽取。

表1：基于基础和压缩-检索架构的ICL推理任务准确率。

测试集中仅包含FOLIO目标问题，并且论文有意从训练集中排除了YOLlO示例。论文相信这种压缩和检索能力应该是领域无关的，因此，论文将训练集限制为仅包含“分布外”数据（从解决FOLIO问题的角度来看），以使模型不会直接在解决FOLIO问题上进行训练。生成的训练集包含3375个训练样本，平均token长度为600；测试集包含192个样本，平均长度为514。由于GPU资源有限，论文使用固定的压缩方案，其中上下文被压缩到第1级，包含50个嵌入，然后是第2级，包含1个嵌入。所有实验均在配备24GB RAM的4090 GPU上进行。论文对LLaMA3.1-8B-instruct在训练集上进行微调，使用LoRA r=8对所有线性层进行微调。论文训练了3个epoch，lr=3 e-4，批量大小为32，小批量大小为1。

结果。论文在表1中展示了结果。实验表明，论文的方法达到了6-shot ICL性能的75%，这表明模型已成功选择了正确的示例。为进一步验证这一点，论文跟踪了顶层注意力，并将顶部索引与相关示例的索引进行比较，匹配率为64%，这意味着在64%的测试案例中，模型找到了所有正确的示例。尽管如此，通过扩展实验，分数可以显著提高。论文将在未来的开发中处理这部分内容。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述