相见OpenCopilot，Incorta的聊天代理。

本文假定您对LLMs和ChatModels有足够的背景知识。如果您不了解这方面的知识，而且是一名新手，那么我们建议您查看本系列的第一篇文章。

请注意HTML结构，将以下英文文字翻译为简体中文： https://medium.com/engineering-incorta/unraveling-chatgpt-for-developers-and-engineers-cfb7bd2c89f1

为什么我们需要一位代理？

使用OpenAI API（或任何其他提供商）创建一个能够与您产品的用户进行互动并提供定制回复的聊天代理并不像简单想象的那么容易。

在本文中，我们将讨论为什么您应该使用代理或创建自己的代理，如果您想为您的用户提供个性化和相关的体验。

让我们从一些Incorta示例开始。顶部的第一个示例是直接由LLM模型回答的，而第二个示例是通过OpenCopilot（Incorta的概念聊天代理）处理LLM模型的结果：

以下两个图表展示了这两种情况的方法和架构的差异：

如您所见，区别在于上下文和业务领域意识。一般来说，定制代理更有能力提供经过精心制作和适当的答案。这些答案考虑了您产品的业务领域，以及用户的背景和个人历史。

聊天代理的类型：

一般来说，有两种聊天代理存在：

• 一次性执行：在这种情况下，智能客服将根据用户的问题决定一项单一操作并执行。通常情况下，其容量和功能都非常有限。
• 计划-执行：更先进的代理人将问题首先分解为子任务，然后逐个执行它们。可能会链式响应直到获得最终答案。

一般计划与执行聊天代理的要素

我们将探讨组成大多数定制聊天代理的关键要素。

1. 索引式知识库：这是一个突出特色，可以将传统的零射门聊天消息与更先进的自定义代理区分开来。在零射门方法中，问题只需转发到GPT API，然后等待响应。然而，这种方法可能并不总是有效，因为GPT系统可能缺乏关于您的产品文档、API能力和客户历史的最新知识。其中一些信息甚至可能不是公开可访问的。换句话说，索引式知识库为您的聊天代理带来了更高级别的定制和具体性。
2. 任务规划：这通常是最初的阶段，在此阶段中，用户的问题（附带规划提示）被转发给语言模型进行聊天。然后接收并存储计划，以便后续执行。
3. 任务执行：代理人随后搜索以前定义的任务列表，并尝试使用支持的执行引擎执行它们。任务执行涉及的阶段通常是明确定义的，并根据组织的需求进行定制。有时可能会使用搜索引擎等公共服务提供商。
4. 结果评估/反应: 这是该过程一个有趣的方面。在此，代理评估结果、确定其充分性，并决定是否需要进一步调查或概括。在某些情况下，代理可能需要重访计划阶段以适当地回应已获得的结果。
5. 记忆：一个有效的代理通常需要某种形式的短期或长期记忆。这对于处理未来的询问并维护对话的连续性非常重要。

流行的代理商：

• AutoGPT：不断地针对问题工作，咨询搜索引擎（和其他插件）进行操作。它将继续自主工作，直到获得回复。https://github.com/Significant-Gravitas/Auto-GPT

• BabyAGI：具有卓越的推理能力和长期分析能力，可以确定下一个应该完成的任务。尽管AutoGPT似乎在开放式查询方面表现更佳，但BabyAGI更适合涉及更多思考和任务分解的活动。它可以这样做，因为它维护所有任务的列表，并优先考虑哪个任务应该下一个完成。https://github.com/yoheinakajima/babyagi

• LangChain代理人：虽然LangChain主要由模块化组件构建，但它还包括一些用于特定任务的代理人。其中一个著名的代理人是计划和执行代理人，它可以减轻其他代理人发现的无限执行相关的一些限制。这个代理人的操作是首先制定计划，然后使用子循环依次处理每个阶段。子循环包括执行、评估、另一个轮回（或更多）的评估/执行，最后完成单个步骤。依此类推，直到完成所有步骤。

使用 vs. 构建，什么时候应该构建自己的？

总的来说，通常更有效地利用现有资源，而不是投入大量资金从零开始创建全新的东西。但是，需要注意的是，通常并不是每个普通代理都适合所有规模。可能有多种原因导致您找不到完美的配合，这些原因可以有很大的不同。

但在我们深入讨论之前，让我们考虑一下一般代理商所涉及的典型缺点。请允许我分享我们基于实验和观察所得出的见解：

• 费用：像BabyAGI和Auto-GPT这样的通用代理可以非常昂贵。这是因为它们可以进入循环，并消耗大量OpenAI（或任何其他提供商）的API令牌，这直接对应着货币成本。
• 简单：有时候，你想完成的任务可能很简单或者有可预测的结构。在这种情况下，使用一般代理可能过于繁琐和不必要。
• 创新：追求改进设计的旅程永无止境，优异的设计将不断涌现。然而，这往往是一个陷阱，因为你可能会认为自己已经开发出了新的设计，但实际上它并不是独一无二的。如果您是新手并认为自己正在创造新的东西，为避免这种陷阱，最明智的做法是先咨询社区，了解您的概念。

关于缺点，就像任何广受欢迎的开源系统一样，例如AutoGPT，它吸引了大量社区兴趣和广泛的贡献者。因此，如果它符合您的使用情况，您将从参与积极的社区的力量和活力以及提供全面支持的优势中获益。

为什么我们选择建立一个新代理？

在Incorta的背景下，我们有一个非常具体和受限制的应用程序。主要任务是回答与分析相关的查询。这通常涉及一系列明确定义的步骤：

• 理解问题
• 收集相关元数据
• 执行查询，并提供响应。

鉴于我们任务的狭窄重点，诸如BabyAGI和AutoGPT这样的解决方案似乎过于复杂。它们倾向于涉及广泛的、潜在的无限任务循环，这与我们解决明确和良好结构化问题的目标不相符。

因此，我们旨在优化我们的方法以满足几个关键属性：

• 最小化规划成本
• 可预测和预先确定的执行路径
• 确保任务完成。

OpenCopilot 设计：

我们建议采用以下系统设计作为传统无限任务执行循环的替代方案，适用于与我们类似需求的应用。我们的设计采用三层方法：

1. 高层计划：这一层涉及向代理提供基本指示。简单地说，我们向GPT介绍Incorta的功能，然后要求GPT制定一个高层计划。
2. 低层规划：在这里，高级任务被细分，表明每个操作员可以执行哪些任务。随后，低层规划阶段将操作员的高级任务转换为粒度更细、低层次的任务。
3. 指令提取：然后将每个低级任务传输到GPT，附带有如何将其转化为操作员可以执行的规范指令的指引。

这种分层架构显着降低成本。每个阶段都允许我们提供一个高度具体的提示，包含足够的信息在特定层次上规划。这避免了可能会因同时淹没GPT with all the information而导致的潜在混乱。

尽管BabyAGI可以提供类似的结果，但它有进入无限循环的风险。我们的分层方法为解决方案提供了可预测和可保证的路径。

请参考下面的图表，以获得系统在高和中级层次上的视觉描绘：

请注意图中的“运算符”框。运算符代表我们系统中的低级处理器。以下是我们在OpenCopilot中使用的一些运算符示例：

1. QueryWriterOperator：此运算符可将自然语言处理（NLP）文本转换为SQL语句。
2. QueryRunnerOperator: 这个运算符能够执行查询并从Incorta中检索结果。
3. 模式运算符：这个运算符可以提取与所提问题相关的元数据和列名。
4. UITextOperator：此操作员可以为用户生成一般文本响应。
5. UIChartOperator：此操作员能够使用各种方言创建Javascript图表。

以下图表提供了规划层次概念的更详细的视图：

Incorta的OpenCopilot接下来会有什么？

我们正在将这个工具发布为开源工具。敬请关注！

下一步去哪里？

如果您是GPT代理领域的新手，最好从检视这两个开源选项开始：

1. AutoGPT：AutoGPT GitHub 存储库
2. BabyAGI：BabyAGI GitHub存储库

接下来，您应该调查是否有其他开源替代方案与您特定的用例相符。

如果你坚持要构建自己的系统，那么熟悉以下概念和工具是强烈推荐的：

1. 提示工程：这是与对话式大语言模型（LLMs）交互的基本技能。
2. LangChain：这个工具包含了许多组件，能够极大地简化您构建自己的代理的过程。
3. 向量/嵌入式数据库：例子包括Pinecone 和ChromaDB。这些数据库是您存储数据和查询您的短期/长期记忆的地方。