独家｜复合人工智能系统的设计模式（对话式人工智能、CoPilots 和 RAG）-下篇

在上文中，我们介绍了何为复合人工智能系统，系统组件以及它们如何相互交互以构建复杂系统，基于LLM的自主智能体 —— 复合人工智能系统中的关键模块，以及复合人工智能系统的设计模式中关于定义的澄清和选择模式之前的考量。

在下文中，我们将介绍复合人工智能系统的三种部署模式。

部署模式1 — RAG / 对话式RAG

下图显示了RAG / 对话式RAG系统中各模块的主要职责，这传统上属于IR领域，首先通过神经搜索、知识图谱改进，然后是使用LLM的生成方法环。从另一个视角来看，这是一个对话式IR系统，当IR和对话系统合并，将查询视为转换上下文的对象。

对于RAG系统的成功，关键在于理解用户的查询并将其映射为底层知识（结构化或非结构化），并将其与适当的指令一起提供给生成器/对话管理器，这些动作可以使用一个明确定义的工作流，或者使用智能体模块，模块的动作决定执行哪些步骤（在下一节中将更详细地阐述）。

RAG流程，转交给对话管理器 — 如果对话管理器是一个智能体，RAG则成为一个工具

来看看一些中间模块/工具，它们允许智能体在复杂的RAG世界中导航。

查询理解与重构

查询扩展 / 多查询

使用LLM来扩展查询可以改进使用稀疏和统计检索器时的搜索结果。

查询重写 / 自我查询

自我查询检索器，顾名思义，具有自我查询的能力。具体来说，给定任何自然语言查询，检索器使用查询构建LLM链来编写结构化查询，然后将其应用于底层的VectorStore。检索器不仅可以使用用户输入的查询与文档的内容进行语义相似性比较，还可以从用户查询中提取出文档元数据上的过滤器，并执行这些过滤器。

实体识别
查询增强
知识或意图检索
多文档搜索
对话管理
响应生成

智能体式RAG

智能体式RAG是一种设计模式，其中一个模块由LLM驱动，根据其可用工具集推理和规划如何回答问题。在高级场景中，可能还会连接多个智能体以创造性地解决RAG问题，智能体不仅能检索，还能验证、总结等。有关更多信息，请参见多智能体部分。

需要细化的关键步骤和组件：

1.基于推理，子任务制定和系统化安排的计划。2.基于自我一致性的自我纠正，由于生成多条路径和推理，基于规划的RAG方法（ReWoo和Plan+）比仅基于推理的（ReAct）效果会更好。3.对执行的适应能力，更多元化的智能体范例。

通常，使用以下模式执行：

基于推理的智能体式RAG

ReAct

使用搜索工具进行推理和动作

基于规划的智能体式RAG

https://blog.langchain.dev/planning-agents/

ReWoo

ReWoo — 比ReAct生成更少的标记

PlanRAG

它由两个组件组成：首先，制定一个计划，将整个任务划分为更小的子任务，然后根据计划执行子任务。

部署模式2 — 对话式人工智能

传统意义上，对话流程一直是高度脚本化的，是“机器人说” -> “人类说” -> “机器人说”…的交互，表示不同假设的真实世界场景，对于Rasa开发人员来说也称为“故事”。每个用户的意图可以基于用户的状态和交互表达为数百个“故事”，机器人采取动作执行已定义好的故事并予以回应响应。例如，如果用户想要订阅新闻稿，可能有两个路径：

1.用户已经订阅。2.用户尚未订阅。

来源

如果用户说“如何订阅新闻稿”触发了意图，机器人需要检查该用户是否已经订阅，然后采取适当的下一步。这个“下一步该做什么”的决策是一个手动硬编码的路径。如果偏离了路径，机器人会说，“对不起，我还在学习，我可以帮助你做xyz..”。

构建和维护机器人的真实成本来自这些故事，之所以要搭建上述乏味的模式，是为了使机器人能够在多样化的真实世界场景中导航，并且可以以有组织的方式添加新路径。路径编写者往往总是有一些“条件需要检查”，“动作需要执行”和“对话的最终目标”来构建一个有目标的执行脚本。

有了LLM，可以尝试使用LLM的“推理”和“规划”能力来自动化脚本编写或路径规划。

想象一下，你是一个客户服务智能体，一名用户带着不同的需求来到你这里，该如何订阅你的服务？你将如何定义应该采取的下一步？它可以完全开放吗？很可能不是，从管理成本的角度来看，它也不能高度脚本化。如果我告诉你以下内容：

条件 — 如果存在电子邮件，那么用户可以订阅工具 — check_subscription, add_subscription

作为有自尊的人类，你将能够在脑海中编织出如下故事：

1.用户想要订阅，基于声明 — “我如何订阅？”2.向用户询问电子邮箱 — “你的电子邮箱是什么？”3.如果他提供了一个有效的电子邮箱，触发工具 — check_subscription4.如果用户尚未订阅，触发add_subscription5.回应成功或失败。

这就是我们希望LLM做的，产生它可以参考的“计划”，并在运行时据此采取动作。

回到模块模板，看看规划者的模样：

上述规划者使用工具和条件构建出计划或故事，来看看研究中的一个真实示例：

KnowAgent: 基于知识的LLM智能体增强规划

有哪些工具可以帮助规划者根据可靠的推理决定路径？

1.由先前类似声明触发的路径。2.企业动作图和动作之间的依赖性。帮助规划者确定某个动作是否会得出正确的结果，然后进行下一个动作，依此类推，直到递归地解决问题。3.用户/对话的当前状态。

部署模式3 — 多智能体 在多智能体设置中，目标是为LLM支持的生成器定义角色和责任，配备精准的工具，可以协同工作，生成智能答案/解决方案。

得益于明确定义的角色和底层模型，智能体将子目标或“计划”的一部分委派给“专家”，然后根据输出来决定下一步该做什么。

使用下述通信模式控制下一步的权限。

智能体/模块如何通信以构建现实世界的CoPilots — https://arxiv.org/pdf/2402.01680v1.pdf

多智能体设计的优势：

关注点分离：每个智能体可以有自己的指令和少样本示例，由单独微调的语言模型支持，并由各种工具支持。将任务分配给不同的智能体可以得出更好的结果。每个智能体专注于特定任务，而不是从众多工具中作出选择。
模块化：多智能体设计允许将复杂问题分解为可管理的工作单元，由专门的智能体和语言模型执行。多智能体设计允许对各智能体独立评估和改进，无需破坏整个应用程序。将工具和责任分组带来更好的结果，当专注于特定任务时，智能体更有可能成功。
多样性：引入强大的智能体团队，带来不同的观点，完善输出，避免幻觉和偏见。（像典型的人类团队一样）。
可重用性：一旦构建了智能体，就有机会将这些智能体应用于不同的用例，实现一个智能体生态系统，它们聚集在一起解决问题，具有适当的编排/协调框架（如AutoGen、Crew.ai等）。

部署模式4 — CoPilot

在CoPilot系统中看到的唯一区别是它能够从用户互动和测试功能中获得学习。

更多内容敬请期待…

框架与实现

区分构建CoPilots的框架和实际的CoPilots实现（如GPT Pilot和aider）非常重要。在大多数情况下，没有开源CoPilots是在已有框架上开发的，所有实现都是从头开始开发的。

回顾流行的实现：OpenDevin、GPT Pilot回顾流行的研究论文：AutoDev、AgentCoder流行的框架 — Fabric、LangGraph、DSPy、Crew AI、AutoGen、Meta GPT、Super AGI 等

全文尽可能坚持以下定义：基于LLM的多智能体。

深入研究 — APPS

GPT Pilot

GPT Pilot项目是一个创造性提示工程和LLM响应链式“分层”流程的杰出例子，以执行看似复杂的任务。

有几个配置文件以分层通信方式工作，请参阅下面的绿色框：

https://www.reddit.com/r/MachineLearning/comments/165gqam/p_i_created_gpt_pilot_a_research_project_for_a/