大模型应用开发之业务架构和技术架构（从AI Embedded 到 Copilot,再到Agent）

截止到目前，我们已经从大模型的定义概念，应用层涉及的一些概念做了些了解。在大模型的应用开发中，RAG、Agent等概念我们之前也做了些简述，没有看过的可以粗略回顾一下：大模型06-大模型应用开发之准备篇（OpenAI的plugins、GPTs与RAG、Agent）^[1]。（点击文末阅读原文，可跳转）

本文我们重点讲的就是伴随着大模型的广泛应用，这些概念是在什么体系和场景下衍生的；换句话说，基于LLM，目前大家在做的应用，他主流的业务架构和技术架构都是什么样子的，我们在了解之后，可以根据依据我们现实的业务需求，来选择自己的技术路线。

就像我们的软件开发，一半是做中间件，框架等基础层的，另一半是在基础层之上，来开发应用的。

大模型目前也是，目前技术分为两个方面：

1. 建设和训练基础大模型
2. 建造大模型应用，或者基于基础大模型的应用开发

同时，基础大模型的建设和训练，又需要更为复杂、丰富和专业的知识，这部分长期看来，不会需要太多的人；我们绝大多数人，都会在大模型的应用层这一层，而像我在01篇写到的：

我们在不断被迫接受着过量的信息和超出认知的技术革新，否则就会处于被革新的尴尬境地。

我们大部分人或者所有人都需要接触和掌握的。

目前在实际落地场景中，广泛在用的或者是不断迭代演进的，基本都是围绕这三种类型来的：

AI Embedded模式

这个场景，很好理解，就是在我们的传统应用中，其中某个环节加入了LLM的能力来帮我们提效做一些事情。

AI Copilot模式

这种模式，是在我们的系统应用中，广泛的应用LLM的能力，再通过我们的应用进行串联，这也是目前使用最多的模式。我们目前能看到各种各样的Copilot,Microsoft Copilot，GitHub Copilot等等。

在这些场景中，大家并不会依赖算法的结果进行最终决策，大都是作为一种信息的收集来源和参考。对比传统的搜索引擎，更多的是效率上的提升，形态其实没有发生本质变化。

AI Agent模式

这个我们可以看到，明显与前两种模式不同，前两种模式的任务主要还是以人来实现为主，LLM作为辅助。

而Agent模式，人只需要提出要求和指令，AI可以自动帮助拆解任务，完成任务的执行。

单Agent和Multi-Agent

我们之前说，在大模型领域，大模型替代了传统agent 中的规则引擎以及知识库，Agent提供了并寻求推理、观察、批评和验证的对话通道。

而Multi-Agent(多智能体系统) 是指由多个自主个体组成的群体系统，其目标是通过个体间的相互信息通信和交互作用。

在基于大模型的应用领域中，当复杂任务被分解成更简单的子任务时，LLM已经被证明了拥有解决复杂任务的能力。Multi-Agent 的通信与协作可以通过“对话”这一直观的方式实现这种子任务的分拆和集成。

为了使基于大模型的Agent适合于Multi-Agent的对话，每个Agent都可以进行对话，它们可以接收、响应和响应消息。当配置正确时 ，Agent可以自动与其他代理进行多次对话，或者在某些对话轮次中请求人工输入，从而通过人工反馈形成RLHF。可对话的Agent设计利用了LLM通过聊天获取反馈并取得进展的强大能力，还允许以模块化的方式组合LLM的功能。

基于大模型的常见单Agent 系统包括：

AutoGPT：AutoGPT是一个AI代理的开源实现，它试图自动实现一个给定的目标。它遵循单Agent范式，使用了许多有用的工具来增强AI模型，并且不支持Multi-Agent协作。

ChatGPT+ (code interpreter or plugin) ：ChatGPT是一种会话AI Agent，现在可以与code interpreter或插件一起使用。code interpreter使ChatGPT能够执行代码，而插件通过管理工具增强了ChatGPT。

LangChain Agent：LangChain是开发基于LLM应用的通用框架。LangChain有各种类型的代理，ReAct Agent是其中一个著名的示例。LangChain所有代理都遵循单Agent范式，并不是天生为交流和协作模式而设计的。

Transformers Agent：Transformers Agent 是一个建立在Transformer存储库上的实验性自然语言API。它包括一组经过策划的工具和一个用来解释自然语言和使用这些工具的Agent。与 AutoGPT类似，它遵循单Agent范式，不支持Agent间的协作。

基于大模型的常见Multi-Agent 系统包括：

BabyAGI：BabyAGI 是一个用Python脚本实现的人工智能任务管理系统的示例。在这个已实现的系统中，使用了多个基于LLM的代理。例如，有一个Agent用于基于上一个任务的目标和结果创建新任务，有一个Agent用于确定任务列表的优先级，还有一个用于完成任务/子任务的Agent。BabyAGI作为一个Multi-Agent系统，采用静态Agent对话模式，一个预定义的Agent通信顺序。

CAMEL：CAMEL 是一个agent 通信框架。它演示了如何使用角色扮演来让聊天Agent相互通信以完成任务。它还记录了Agent的对话， 以进行行为分析和能力理解，并采用初始提 示技术来实现代理之间的自主合作。但是，CAMEL本身不支持工具的使用，比如代码执行。虽然它被提议作为多代理会话的基础设施，但它只支持静态会话模式。

Multi-Agent Debate：Multi-Agent Debate试图构建具有多代理对话的LLM应用程序，是鼓励LLM中发散思维的有效方式，并改善了LLM的事实性和推理。在这两种工作中 ，多个LLM推理实例被构建为多个Agent来解决与Agent争论的问题。每个Agent都是一个LLM推理实例，而不涉及任何工具或人员，并且Agent间的对话需要遵循预定义的顺序。

MetaGPT：MetaGPT 是一种基于Multi-Agent对话框架的LLM自动软件开发应用程序。他们为各种gpt分配不同的角色来协作开发软件，针对特定场景制定专门的解决方案。

基于Multi-Agent的LLM 应用开发框架：Autogen

在单Agent和Multi-Agent的应用开发中，大家看到了我们之前提到的，LangChain与Autogen，就是为了Agent开发而出现的应用开发框架。

纯prompt

基本的对话式，你问一句，我答一句。。。

Agent + Function Calling

• Agent：AI 主动提要求
• Function Calling：AI 要求执行某个函数
• 场景举例：你问过年去哪玩，ta 先反问你有多少预算

RAG（Retrieval-Augmented Generation）

• Embeddings：把文字转换为更易于相似度计算的编码。这种编码叫向量
• 向量数据库：把向量存起来，方便查找
• 向量搜索：根据输入向量，找到最相似的向量
• 场景举例：考试时，看到一道题，到书上找相关内容，再结合题目组成答案。然后，就都忘了

Fine-tuning

大模型的微调

面对一个需求，如何选择技术方案？下面是个不严谨但常用思路。

刚接触LLM的小伙伴在听到Fine-tuning的时候都觉得蛮高级的，在我实际工作中应用了一段时间大模型之后，我自己的感受时，在很多基础应用场景中，我们用好提示工程，就足够了。

值得尝试 Fine-tuning 的情况

1. 提高大模型的稳定性
2. 用户量大，降低推理成本的意义很大
3. 提高大模型的生成速度

本文章，我们从大模型目前应用的典型业务架构和技术架构进行分析，让大家初步能够了解我们都是在如何使用LLM的，从而大家在自己的实际落地场景中，也可以对照分析，如何建设自己的业务架构和技术架构，以及选择什么样的技术路线。

参考资料