多智能体系统中的潜在协作

发表
Jiaru ZouJiaru Zou 提交
作者: Jiaru ZouJiaru Zou, Xiyuan Yang, Ruizhong Qiu, Gaotang Li, Katherine Tieu, Pan LuPan Lu, Ke Shen, Hanghang Tong, Yejin Choi, Jingrui He, James Zou, Mengdi Wang, Ling YangLing Yang

摘要

AI 生成总结
LatentMAS 使得 LLM 代理能够在潜在空间中进行高效、无损的协作,与基于文本的方法相比,提高了性能并降低了计算成本。
多智能体系统(MAS)将大型语言模型(LLM)从独立的单模型推理扩展到协作的系统级智能。现有LLM智能体依赖基于文本的媒介进行推理和通信,而我们向前迈进了一步,使模型能够在连续的潜在空间内直接协作。我们引入了LatentMAS,一个端到端免训练的框架,它使LLM智能体之间能够进行纯粹的潜在协作。在LatentMAS中,每个智能体首先通过最后一层隐藏嵌入生成自回归的潜在思维。然后,一个共享的潜在工作记忆保存并传输每个智能体的内部表示,确保无损信息交换。我们提供了理论分析,证明LatentMAS在实现更高表达能力和无损信息保留方面,其复杂性显著低于传统的基于文本的MAS。此外,在涵盖数学和科学推理、常识理解以及代码生成的9个综合基准测试中进行的实证评估表明,LatentMAS始终优于强大的单模型和基于文本的MAS基线,准确率提高了14.6%,输出token使用量减少了70.8%-83.7%,并且端到端推理速度快了4到4.3倍。这些结果表明,我们新的潜在协作框架在不进行任何额外训练的情况下,提高了系统级推理质量,同时提供了显著的效率提升。代码和数据已在https://github.com/Gen-Verse/LatentMAS完全开源。
查看 arXiv 页面查看 PDF

评论

Michael BarryMichael Barry

非常激动人心的工作!
这会如何影响带宽?它是否以牺牲令牌效率来换取带宽效率低下?

Jiaru ZouJiaru Zou
论文作者
论文提交者

您好,Michael,

感谢您就我们的LatentMAS工作提出的出色问题。我将在下面提供详细的答复。如果您想进一步讨论,请告诉我!

> 这如何影响带宽?它是否以牺牲带宽效率为代价来提高令牌效率?

摘要

简短回答:不。LatentMAS不会以牺牲带宽效率为代价来提高令牌效率。它的“带宽”存在于潜在工作内存中,由于每个潜在步骤的表达能力远超一个令牌,LatentMAS所需的步骤大大减少,使其既节省令牌又节省带宽,并能加快推理速度。

详细答复

在常规TextMAS中,带宽 = #令牌数 × |V|(词汇级别的信息吞吐量)

在LatentMAS中,带宽 = #潜在步骤 × dₕ × L(隐藏状态KV传输)。
注意:此处,“带宽”指的是潜在工作内存(存储在KV缓存中)在代理之间进行的内部GPU内存移动。

根据定理3.1可知:
$$
\text{潜在表达能力} = \Omega!\left(\frac{d_h}{\log |V|}\right) \times \text{文本}
$$

这意味着:
- 一个潜在步骤承载着数百个令牌的语义信息。
- 您只需要m≪T_tokens即可达到相同的推理深度。

因此,虽然每个潜在步骤传输的是密集向量,但每个步骤承载的信息远超一个令牌,从而大大减少了所需的通信步骤。根据论文,理论复杂性分析和经验结果(令牌减少70-80%,速度提高4倍)都表明,在系统层面,LatentMAS比基于文本的多代理通信更具带宽效率。

Michael BarryMichael Barry

谢谢。我们现在考虑的可能是50个潜在步骤,这应该和生成50个token所需的时间差不多,也许会少10%。然后它会输出大约1000个token,这将是答案减去冗长的推理过程,最终得到一个通常需要8000多个token才能解决的问题。因此,如果没有多智能体设置,它实际上是一个潜在循环Transformer。

Jiaru ZouJiaru Zou
论文作者
论文提交者

很抱歉回复晚了。我注意到你更新了问题,所以我会回答新问题。我也很乐意更详细地讨论你之前的问题或其他新问题。😀 再次感谢你对我们工作的极大兴趣!

> 那么我们可能会看到大约50个潜在步骤,这应该与50个tokens所需的时间大致相同……所以如果没有多代理设置,它实际上是一个潜在循环Transformer。

我认为你的理解与我们在LatentMAS中实现的非常吻合。我只想强调LatentMAS中的潜在步骤与TextMAS中标准token生成步骤之间一个重要的技术区别,因为这个区别对于解释我们方法的效率和计算特性至关重要。

在标准的基于文本的解码中,每个新token都必须关注所有先前token的完整KV缓存,因此冗长的推理链会迅速增加内存使用和解码延迟。相比之下,LatentMAS将推理从显式token级别的KV增长转移到紧凑的潜在工作内存,这使得最终解码期间的有效KV读取大大减小。因此,每个输出token的注意力成本显著降低,除了跳过中间token解码所节省的开销之外,还进一步加速了最终答案的生成。

此外,我们不需要诸如词汇表上的softmax、token采样和嵌入查找等操作。因此,实际上,在实际实现中,50个潜在步骤将比50个解码token花费 substantially less time (~70-90% less)。

> 我们可以混合搭配LLM吗?Qwen 3 4b和Qwen 3 14b?与其他家族混合呢?它支持量化吗?它与Lora一起工作吗?

是的,LatentMAS绝对支持混合使用不同的模型。 我们实际上在论文的《附录C.3》中已经进行了讨论。

此外,LatentMAS完全兼容量化和LoRA。 由于该方法完全免训练,并且只重用骨干模型的隐藏状态和潜在工作内存,因此标准的推理时间量化(例如,INT8/INT4,GPTQ,AWQ)无需任何修改即可开箱即用。同样,LoRA也原生支持,因为LatentMAS不改变模型的前向架构;它只是改变了隐藏状态的传播方式和工作内存的传输方式。小的对齐矩阵 (W_a) 在加载(可能经过LoRA适配和/或量化)模型后计算一次,因此它会自动适应部署设置,开销可以忽略不计。

> 分层代理设置是并发的吗?也就是说,两个小型模型可以实时协作,即时访问彼此的步骤,还是需要完全完成所有步骤后才能共享?

简而言之,协作通过在潜在思想完成后的批处理式潜在内存传输进行。

在当前的LatentMAS设计中,分层代理在代理级别是并行的,但不是步骤级并发的。例如,分层MAS设置中的多个专家代理可以同时在相同的输入上运行,但每个代理应首先完成其完整的潜在推理步骤序列,然后其潜在工作内存才能与聚合器共享。

我们的理念是,为了使信息交换有效和语义完整,每个代理应首先完全形成自己的潜在思想,然后将其传输给其他代理。这确保了共享的是一个连贯且收敛的内部表示,而不是一个部分形成的中间状态。同时,你提出了一个关于潜在扩展方向的极好观点,即代理可以以步骤级方式并发交换潜在思想。我们相信这确实可能是未来工作中进一步扩展LatentMAS的一个有前景且重要的扩展。

总的来说,我们相信LatentMAS开辟了一个非常有趣的新方向,即如何在潜在空间中直接扩展多代理系统。你的许多问题都触及了该领域的基础性和前瞻性挑战,我们认为它们是未来扩展中值得保留的绝佳观点。我们也希望这些想法能激发社区内对可扩展潜在空间多代理协作的更广泛探索。

Michael BarryMichael Barry

> 抱歉回复晚了。我注意到你更新了问题,所以我会回答新问题。我也很乐意更详细地讨论你之前的问题或其他新问题。😀 再次感谢你对我们工作的极大兴趣!

无需道歉,我感谢你的回复。修改后的问题对我更有用,而我最初的问题有点过于猜测,但我稍后会对此进行一些扩展。

> 在标准基于文本的解码中,每个新令牌都必须关注所有先前令牌的完整 KV 缓存……所以,实际上,在实际实现中,50 个潜在步骤所需的时间将大大少于(~70-90% 少于)50 个解码令牌。

我肯定是在阅读论文时错过了这一点,谢谢你的澄清。这比我想象的还要好。

> 是的,LatentMAS 绝对支持与不同模型混合。我们实际上已经在论文的附录 C.3 中进行了讨论。

我也错过了这一点,我想我需要再读一遍 😂

> 此外,LatentMAS 完全兼容量化和 LoRA

我开始产生“好得不真实”的感觉了👍 我很难找到你们方法的任何缺点。它似乎在各个方面都更好。

> 我们的理念是,为了使信息交换有效且语义完整,每个代理都应首先充分形成自己的潜在思想,然后将其传递给其他代理。这确保了所共享的是一个连贯且收敛的内部表示,而不是一个部分形成的中间状态。

我同意,但如果你不介意,我还有一个问题😂

我们可以使用 SFT 让模型添加一个特殊令牌来表示一个可理解思想的结束,然后在推理过程中,我们可以在每个步骤进行解码(承担性能损失)搜索特殊令牌,例如 [/Thought],然后发送出去,允许模型决定何时共享,希望能产生一些非常有趣的结果。也许效率会提高一个数量级,特别是当你添加更多代理时。也许会出现一种新的模型间推理“顿悟时刻”。

但有没有更好的方法可以在不完全解码每个步骤的情况下做到这一点,例如,有没有一种简单有效的方法,让模型从潜在空间中发出信号,表明其当前思想已准备好共享。

抱歉,如果这对我来说有点太简单了,或者如果我完全理解错了,我是一名开发人员,不是研究员,我正在开发一个代理框架,这让我思绪万千,这非常有前景。这是我读过的很长一段时间以来最好的论文。

谢谢