大模型对话型多 Agent 协同的绊脚石
一、写在前
现阶段基于大模型的应用能否真正在生产落地成为了近几年企业创新工作关注的核心点，在落地的过程中很多企业都选择基于大模型的 Agent 或多 Agent 协同来试图解决实际问题，多 Agent 协同机制总体看来可以分为两类应用场景。
1.对话型应用：构建统一入口的对话式能力，通过多 Agent 协同实现功能的内聚与识别，从而使单一对话入口能够处理多种业务流程，例如，同一入口可以用于电力领域知识库查询、电费余额查询以及电费缴费等功能；
2.任务型应用：构建一体化任务执行式能力，通过多 Agent 协同实现功能的编排与执行，例如，创建一个运维日常巡检任务，该任务需要先查询前一天系统上线情况，然后查询某业务实时指标，并两步骤的查询内容进行汇总与分析。
在实际工程落地时，任务型应用大多流程相对固定，再加上 LangChain、LangGraph 等框架的出现，整体的任务执行准确率有一定的保证，大模型可以尽可能的帮我们做到函数参数抽取与调用等操作，但是对话型应用与任务型应用相比就不是很稳定，导致这种现象出现的绊脚石有认为有两个，一个是意图识别，一个是上下文关联记忆，其中的本质是语义歧义性，也就是同一句话不同的人理解不同，何况是机器。
下图例子是大模型下多 Agent 协同的示意图，为了统一概念在本例子中二级 Agent 代表工具、函数、操作等，对应刚介绍的案例是电费余额查询 Agent、业务实时指标查询 Agent 等，一级 Agent 代表统一入口 Agent，在该 Agent 中实现对话入口、意图识别、Agent 调度等，下面结合本例子介绍下意图识别和上下文关联记忆如何成为了多 Agent 协同的绊脚石。
1.意图识别：如上图，在一级 Agent 中“注册”了所有二级 Agent 的功能，根据用户的对话内容，大模型（或其它模型）需要来判断具体调用哪个二级 Agent，在这个过程中，可能会出现识别不稳定或产生幻觉的现象。例如，有两个二级 Agent 分别负责支付系统业务量查询与会员系统业务量查询，如下问题可能会导致意图混淆。
2.上下文关联记忆：如下图，在统一入口的对话中，当用户的第一问题正确命中二级 Agent 并执行后，如果用户继续追问，下一个问题的意图识别会有不同的技术路线进行处理，基于大模型有一个方案是一级 Agent 根据对话上下文再重新进行一次意图识别，虽然整体计算成本与效果还有进一步提升的空间，但在上下文管理记忆方便与小模型迭代训练的意图识别还是有一定的优势。
所以通过以上简单的分析我们发现，对话型应用瓶颈大多聚焦在意图识别，所以本文介绍几种意图识别的尝试。
二、大模型 prompt 意图识别
在本方案中意图识别基于大模型提示词工程 prompt 的定义，在 prompt 中会定义意图识别要求、对话上下文、声明需要识别的二级 Agent 功能描述等，该方案意图识别的质量取决于 prompt 质量，效果取决于大模型对于提示词工程的理解，所以会因 prompt 质量不同造成千差万别的识别效果，这也是为什么行业上有一种说法是未来提示词工程师可能出现的原因吧，该方案归属于大模型应用层，prompt 示意如下。
三、大模型 function_call 意图识别
在上述方案中意图识别的实现过程需要研发人员花费大量的时间调试与优化提示词，所以在大模型发展的初期，LangChain 很快就支持了 Agent 协同开发框架，研发人员可以快速实现 Agent 搭建与协同，而且且研发人员更多的是聚焦本文中二级 Agent 的具体实现，意图识别 prompt 与 Agent 调度都由框架自主实现，当时由于大模型自身理解成熟度也不高，导致 Agent 调度的准确度并不稳定。
后来随着 GPT3.5 API 提供 function_call 接口，研发人员可以通过接口的方式直接将工具详情与参数列表发送给大模型，这就相当于将意图识别（或工具选择）由模型应用层下移到模型层识别，整体的识别准确率会有所提升，但识别准备度也高度取决于 Agent（或工具列表）描述以及参数的定义。如下为 GPT 支持的 function_call 的接口与应用示例。
请求部分示例：
响应结果示例：
在请求大模型时通过接口会声明支持的函数列表，示例中声明了计算一组数求和的 sum 函数，同时会声明函数名称、描述、调用该函数的参数，大模型会根据问题选择与之最匹配的函数，同时按照要求提取函数调用参数，示例中大模型选择了 SUM 函数，并按照问题的语义提取出需要求和的两个数 2 和 4。
此例子主要给大家介绍一下 function_call 应用原理，在对话型多 Agent 协同的背景下一级 Agent 主要就负责 function_call 的调用，二级 Agent 成为被调用的函数，函数具体调用还需研发人员编码或利用开源框架完成，区别于 prompt 意图识别该方案整个意图识别主要依赖于大模型原生能力实现。
说道这还有一个小插曲，在 function_call 刚出现时各大模型为了适配 OpenAI 的 function_call 功能，有一些大模型团队选择新发布一个接口用于适配 function_call 字段，具体的意图识别或者说 Agent 调度都由大模型团队独立封装，不过随着大模型快速的发展，现阶段各大模型团队已经都将 function_call 下移到模型层供研发人员直接调用。
四、小模型意图识别
1、单模型训练
以上两个方案是基于大模型的意图识别，之所以大家选择大模型做意图识别是因为现在 Agent 协同大多也采用大模型的技术方案，一是技术体系相似，二是大模型参数大，但这其实也是把双刃剑，随着生产级应用大家发现由于大模型掌握的知识越来越多，在一些具体的领域上大模型意图识别表现不并理想，而且算力要求也比较高，所以大家或多或少都尝试过用小模型训练的方式来聚焦具体领域的意图识别。
该方案是基于小模型进行训练，具体小模型这里就不做示例的说明，在一定程度上大家也可以将大模型中参参小的模型叫做小模型，如Qwen2-0.5B，如现在有 N 个二级 Agent 需要进行意图识别，为了让意图识别更加聚焦，一般会采用 N+1 的方式进行模型训练，N 代表需要意图识别的场景数，1 代表固定兜底的闲聊场景，通过整理训练数据集并对小模型进行训练，实现有限范围的意图识别与 Agent 的调度。
2、多模型并行
单模型训练的技术方案看似没有什么问题，但是在生产级应用的过程中，我们会发现每多出现一个二级 Agent 就需要重新训练一次模型，这样的成本和工作量是巨大的，所以延伸了一种增量的迭代方案，就是采用“有限分+并行访问“的方式。
该方式是在模型训练时采取有限个（2 个或者 N 个）场景进行多个小模型的训练，当有新 Agent 时再训练一个小模型，这样 N 个场景的意图识别会分布在多个小模型中，在具体应用的过程中采用并发访问的方式让多个小模型进行意图识别，从而快速的定位到指定的 Agent 中，这样做的好处是生产上可以不断以增量的方式进行功能迭代，当并发访问成为性能瓶颈时在扩大有限分数量重新进行训练与优化。
五、大小模型融合意图识别
以上几种技术方案在实际的应用过程中大家都会怀着迟疑的态度，因为在技术验证的过程中并不能使意图识别的准确率稳定在一个较高的水平，所以结合以上的几种技术方案提出了一种大小模型融合的意图识别方法。
上图中的方案主要采用的大模型 function_call 与多模型并行融合的方式来提升意图识别的准确率，一方面通过大模型 function_call 原生能力定位到 top1 意图，另一方面通过多模型并行的方式，定位到 topn 个意图，这里的 n 通常都比较小，最后采用一定的策略算法进行最终意图的选择，可提供集中策略供大家思考。
若 function_call 定位 top1 意图在多模型并行意图 topn 列表中则选择 top1 意图为最终意图；
若 function_call 定位 top1 意图不在多模型并行意图 topn 中则通过大模型进行二次意图识别，在 n+1 个意图中重新选择一个；
六、方案推荐
结合一些生产案例的实践这里推荐“大模型 function_call 与多模型并行融合”与“大模型 function_call 意图识别”两种方案，当然这也不代表这两种技术方案就一定准确率高，技术方案只是实现需求的一种方式，大家最终的选择应该以为业务需求的综合测试结果为准。
七、遗留问题
本文主要以一种简单易懂的方式为大家在意图识别、Agent 调度、对话型任务的实现过程中提供几种思路进行参考，当然这里还有许多关联问题需要大家去逐一解决，如多模型并行的上下文关联问题，多 Agent 任务分解与调度问题等。
七、总结
本文以对话型多 Agent 协同为背景，简述了出现的问题和几种解决的方案，总体来说行业上现在意图识别还不是特别的成熟，相信随着 AI 领域的发展和大模型技术的不断提升，意图理解与多 Agent 协同技术会逐步形成最佳实践，但在这个过程中的确需要我们在生产实践中不断发现问题与解决问题。
我相信不久的将来意图识别准确率会逐渐接近“文科状元”的水平，让我们给 AI 一些时间，也给自己一些时间。
备注：本文 25 年 1 月写初稿，工作繁忙，现在看一些技术都已经迭代了，如长短记忆等，但是也发出来作为思路参考吧。
还未添加个人签名 2020-04-17 加入
还未添加个人简介
评论