AWS开源Multi-Agent-Orchestrator:多智能体编排框架,管理AI智能体,处理复杂对话

介绍

大型和小型语言模型的出现，这些模型既可以在云环境中部署，也可以在本地系统上运行，为针对特定任务利用多个专业模型提供了机会。

当配置为在指定任务上独立运行时，这些专业模型通常被称为代理。

构建智能的、具有上下文感知能力的AI应用程序在管理一组多样化的代理方面面临着重大挑战。这一核心难题因需要在不同领域统一操作、保持上下文理解以及实现可扩展架构的需求而变得更加复杂。

🚀构建灵活的AI系统

为了解决这些挑战，并赋能开发者快速试验和部署先进的多代理AI系统，我们创建了Multi-Agent Orchestrator框架。

Multi-Agent Orchestrator是一个灵活且强大的框架，旨在管理多个AI代理，智能路由用户查询，并处理复杂的对话。该框架在构建时考虑了可扩展性和模块化，使得能够创建出能在多个领域内保持连贯对话的AI应用程序，同时高效地将任务分配给专业代理，并在整个交互过程中保持上下文。

此项目旨在解决广泛的用例，包括但不限于：

• 复杂的客户支持系统
• 多领域虚拟助手
• 智能家居和物联网设备管理
• 多语言客户支持

🔖功能

以下是Multi-Agent Orchestrator框架中我们构建的一些关键功能：

🧠智能意图分类——根据上下文和内容动态将查询路由到最合适的代理。

🌊灵活的代理响应——支持不同代理的流式和非流式响应。

📚上下文管理——在多个代理之间维护和利用对话上下文，以实现连贯的交互。

🔧可扩展架构——轻松集成新代理或自定义现有代理以满足您的特定需求。

🌐通用部署——可在任何地方运行——从AWS Lambda到您的本地环境或任何云平台。

🚀可扩展设计——高效处理多个并发对话，从简单的聊天机器人扩展到复杂的AI系统。

📊代理重叠分析——内置工具用于分析和优化您的代理配置。

📦预配置代理——由Amazon Bedrock模型驱动的即用型代理。

借助Multi-Agent Orchestrator框架，开发人员可以快速原型设计和部署复杂的AI对话系统，该系统利用多个专业代理的强大功能。

该框架的可扩展性和自定义功能支持创建广泛的AI应用程序，从复杂的客户服务系统到多领域虚拟助手和先进的协作AI工具，让各种创意得以实现。 

工作原理

Multi-Agent Orchestrator框架是一个强大的工具，用于实现由多个专业代理组成的复杂AI系统。其主要目的是智能地将用户查询路由到最合适的代理，同时在整个交互过程中保持上下文感知。

Orchestrator Logic（编排器逻辑）

Multi-Agent Orchestrator针对每个用户请求遵循一个特定流程：

1. 请求发起：用户向编排器发送请求。

2. 分类：分类器使用大型语言模型（LLM）分析用户的请求、代理描述以及当前用户ID和会话ID下所有代理的对话历史。这种全面的视角使分类器能够理解所有代理之间正在进行的对话和上下文。

• 框架包含两个内置的分类器实现，其中一个为默认使用。
• 用户可以自定义这些内置分类器的许多选项。
• 用户还可以选择创建自己的自定义分类器，可能会使用与内置实现中不同的模型。
  

分类器确定以下情况中最合适的代理：

• 1. 需要特定代理的新查询（例如，“我想预订航班”或“20年期贷款的基准利率是多少？”）
• 2. 对之前交互的跟进，其中用户可能会提供简短回答，如“告诉我更多”、“再来一次”或“12”。在这种情况下，LLM会识别出最后一个回复的代理，并等待这个答案。

3. 代理选择：分类器返回所选代理的名称。

4. 请求路由：用户的输入被发送到所选代理。

5. 代理处理：所选代理处理请求。它会自动检索当前用户ID和会话ID下的自己的对话历史。这确保了每个代理在无法访问其他代理对话的情况下保持自己的上下文。

• 框架为常见任务提供了多个内置代理。
• 用户可以选择自定义这些内置代理的广泛属性。
• 用户还具有针对特定需求快速创建自定义代理的灵活性。

6. 响应生成：代理生成响应，该响应可能会以标准响应模式发送，也可能会通过流式传输发送，具体取决于代理的能力和初始化设置。

7. 对话存储：编排器自动处理将用户的输入和代理的响应保存到特定用户ID和会话ID的存储中。这一步骤对于保持上下文和启用连贯的多轮对话至关重要。关于存储的关键点：

• 框架提供了两种内置存储选项：内存存储和DynamoDB。
• 用户可以灵活地快速创建和实现自己的自定义存储解决方案，并将其传递给编排器。
• 对于不需要后续交互的单个代理，可以禁用对话保存。
• 可以为每个代理配置保存在历史记录中的消息数量。

8. 响应传递：编排器将代理的响应传递回用户。

此流程确保每个请求都由最合适的代理处理，同时在整个对话过程中保持上下文。分类器具有所有代理对话的全局视图，而单个代理只能访问自己的对话历史。这种架构允许进行智能路由和上下文感知响应，同时保持代理功能之间的分离。

编排器对对话保存和检索的自动处理，以及灵活的存储选项，为管理多代理场景中的对话上下文提供了一个强大且可定制的系统。自定义或替换分类器和代理的能力为根据特定需求定制系统提供了进一步的灵活性。

Multi-Agent Orchestrator框架使您能够利用多个代理来处理各种任务。

在框架上下文中，代理可以是以下任一项（或一项或多项的组合）：

• 大型语言模型（通过Amazon Bedrock或任何其他云托管或本地大型语言模型）
• API调用
• AWS Lambda函数
• 本地处理
• Amazon Lex Bot
• Amazon Bedrock Agent
• 任何其他特定任务或过程

这种灵活的架构允许您根据应用程序的需求融入尽可能多的代理，并以最适合您需求的方式将它们组合在一起。

每个代理都需要一个名称和描述（以及您使用的代理类型特有的其他属性）。

代理描述在编排过程中起着至关重要的作用。

它应该详细且全面，因为编排器依赖于此描述，以及当前用户输入和所有代理的对话历史，来确定每个请求的最合适路由。

虽然框架的灵活性是一个优势，但重要的是要注意代理之间可能存在的潜在重叠，这可能会导致路由错误。为了帮助您分析和防止此类重叠，我们建议您深入阅读我们的代理重叠分析部分。

代理抽象：跨平台的统一处理

多代理编排器（Multi-Agent Orchestrator）框架的关键优势之一在于其代理的标准实现。这种标准化为不同环境带来了显著的灵活性和一致性。无论您是与不同的云服务提供商合作，使用各种大型语言模型（LLM），还是混合使用基于云和本地的解决方案，代理都提供了一个统一的接口来执行任务。

这意味着您可以无缝地在例如Amazon Lex Bot Agent和Amazon Bedrock Agent之间切换，或使用工具进行过渡，也可以从云托管的大型语言模型切换到本地运行的大型语言模型，同时保持相同的代码结构。

此外，如果您的应用程序需要按顺序或并行地使用Bedrock LLM Agent和/或Amazon Lex Bot Agent的不同模型，您也可以轻松实现，因为代码实现已经就绪。这种标准化方法意味着您无需为每个模型编写新代码；相反，您可以直接使用现有的代理。

为了利用这种灵活性，您只需安装框架并导入所需的代理。然后，无论底层技术如何，您都可以直接使用processRequest方法调用它们。这种标准化不仅简化了开发和维护工作，还促进了在不同平台和技术之间轻松进行实验和优化，而无需进行大量的代码重构。

这种标准化使您能够在保持核心应用程序代码完整性的同时，尝试各种代理类型和配置。

编排器的主要组件

编排器由以下主要组件构成：

• 编排器
  • 作为所有其他组件的中央协调器。
  • 管理分类器、代理、存储和检索器之间的信息流。
  • 处理用户输入并协调生成适当的响应。
  • 处理错误场景和回退机制。

• 分类器
  • 分析用户输入、代理描述和对话历史。
  • 为每个请求识别最合适的代理。
  • 自定义分类器：为特定任务或领域创建全新的分类器。

• 代理
  • 预建代理：用于常见任务的即用型代理。
  • 可自定义代理：扩展或覆盖预建代理以定制功能。
  • 自定义代理：为特定任务或领域创建全新的代理。

• 对话存储
  • 维护对话历史。
  • 支持灵活的存储选项（内存存储和DynamoDB）。
  • 自定义存储解决方案。
  • 在两个层面上运行：分类器上下文和代理上下文。

• 检索器
  • 通过提供上下文和相关信息来增强基于大型语言模型（LLM）的代理性能。
  • 通过按需提取必要信息来提高效率，而不是仅依赖模型的训练数据。
  • 预建检索器：用于常见数据源的即用型检索器。
  • 自定义检索器：为特定数据存储或格式创建专业的检索器。

编排器的每个组件都可以使用自定义实现进行自定义或更换，从而提供了无与伦比的灵活性，并使该框架能够适应各种场景和特定要求。 

快速入门

为了帮助您快速启动多代理编排器（Multi-Agent Orchestrator）框架，我们将引导您逐步完成设置和运行您的第一个多代理对话的全过程。

💁在继续之前，请确保您的开发环境中已安装Node.js和npm（用于TypeScript）或Python（用于Python）。

前提条件

1.创建一个新项目：

2.使用您的AWS账户进行身份验证

本快速入门将展示如何使用Amazon Bedrock进行分类和代理响应。

要按照以下步骤使用您的AWS账户进行身份验证：

a. 如果您尚未安装AWS CLI，请从AWS CLI官方页面下载并安装。

b. 使用您的凭证配置AWS CLI。有关如何设置AWS CLI的详细指南，请参阅AWS CLI配置快速入门指南。

c. 配置完AWS CLI后，通过运行以下命令验证您的身份验证：

终端窗口

如果成功，此命令将返回您的AWS账户ID、用户ID和ARN。

默认情况下，该框架配置如下：

分类器：

使用带有anthropic.claude-3-5-sonnet-20240620-v1:0的Bedrock Classifier实现

代理：使用带有anthropic.claude-3-haiku-20240307-v1:0的Bedrock LLM Agent

重要提示

这些只是默认设置，您可以根据需求或偏好轻松更改。

您具有以下灵活性：

• 更改分类器模型或实现
• 更改代理模型或实现
• 使用Amazon Bedrock提供的任何其他兼容模型

请确保您已通过AWS控制台请求了您打算使用的模型的访问权限。

要自定义模型选择：

• 对于分类器，请参阅我们关于配置分类器的指南。
• 对于代理，请参阅我们关于配置代理的指南。

🚀 开始操作！

1.在您的项目中安装多代理编排器框架：

2.为您的快速启动代码创建一个新文件：

创建一个名为quickstart.py的文件。

3.创建编排器：

4.添加代理：

5.发送查询：

现在，让我们运行快速启动脚本：

编排器

Multi-Agent Orchestrator是框架的核心组件，负责管理代理、路由请求和处理对话。本页提供了如何初始化Orchestrator的概述，并详细列出了所有可用的配置选项。

初始化Orchestrator

要创建一个新的Orchestrator实例，您可以使用MultiAgentOrchestrator类：

options参数是可选的，允许您自定义Orchestrator行为的各个方面。

配置选项

Orchestrator在初始化时接受一个OrchestratorConfig对象。所有选项都是可选的，如果未指定，将使用默认值。以下是可用选项的完整列表：

• storage：指定聊天历史的存储机制。默认值为InMemoryChatStorage。
• config：一个OrchestratorConfig实例，包含各种配置标志和值。
• logger：自定义日志记录器实例。如果未提供，将使用默认日志记录器。
• classifier：自定义分类器实例。如果未提供，将使用BedrockClassifier。
• default_agent：当分类器无法确定最合适的代理时使用的默认代理。

包含所有选项的示例

以下示例展示了如何使用所有可用选项初始化Orchestrator：

请记住，所有这些选项都是可选的。如果不指定某个选项，Orchestrator将使用其默认值。

默认值

默认配置定义如下：

在两种实现中，DEFAULT_CONFIG都是具有默认值的OrchestratorConfig实例。

可用功能

MultiAgentOrchestrator 提供了多个关键功能来管理代理、处理请求以及配置协调器。以下是每个功能的详细介绍，解释了其作用以及您可能会使用它的原因：

让我们分解每个功能：

1. addAgent (TypeScript) / add_agent (Python)

• 作用：向协调器添加一个新的代理。
• 使用原因：使用此功能可以通过引入新的专业代理来扩展系统的功能。每个代理都可以处理特定类型的查询或任务。
• 示例用例：添加一个天气代理来处理与天气相关的查询，或添加一个预订代理来处理预订任务。

2. getDefaultAgent

• 作用：检索当前的默认代理。
• 使用原因：当您需要引用或使用默认代理时，此功能非常有用，例如用于回退场景或比较其与其他代理的功能。
• 示例用例：在决定是否替换当前默认代理之前，检查其配置。

3. setDefaultAgent

• 作用：为协调器设置一个新的默认代理。
• 使用原因：这允许您更改在查询未选择特定代理时使用的回退代理。它对于自定义系统的通用响应处理非常有用。
• 示例用例：将默认的通用代理替换为更适合您应用程序主要用例的更专业代理。

4. setClassifier

• 作用：为协调器设置一个新的分类器。
• 使用原因：当您想使用除默认 BedrockClassifier 之外的分类器时，无论是使用另一个内置分类器（如 AnthropicClassifier 或 OpenAIClassifier）还是实现您自己的自定义分类器。
• 示例用例：实现一个针对您的特定用例比默认分类器更准确的域特定分类器。

5. getAllAgents

• 作用：检索所有已注册代理的字典，包括它们的名称和描述。
• 使用原因：此功能对于获取系统中所有可用代理的概览非常有用。它可以用于调试、记录或提供有关系统功能的用户面信息。
• 示例用例：生成一个帮助消息，列出所有可用代理及其功能。

6. routeRequest

• 作用：这是处理用户请求的主要功能。它接收用户的输入，对其进行分类，选择一个合适的代理，并返回代理的响应。
• 使用原因：这是您在应用程序中处理用户交互的核心功能。它封装了理解用户意图并生成适当响应的整个过程。
• 示例用例：在聊天机器人界面中处理用户的消息并返回适当的响应。

这些功能在配置和操作 Multi-Agent Orchestrator 中发挥着至关重要的作用。通过有效地使用它们，您可以创建一个灵活且强大的系统，能够跨多个域处理广泛的用户请求。

这些功能允许您配置协调器、管理代理以及处理用户请求。

功能示例

以下是如何使用每个功能的实际示例：

代理选择与默认行为

当用户向多代理协调器发送请求时，系统会尝试对意图进行分类并选择一个合适的代理来处理该请求。然而，也存在未选择任何特定代理的情况。

未选择代理时

如果分类器无法确定哪个代理应该处理请求，可能会导致没有代理被选中。在这种情况下，协调器的行为取决于USE_DEFAULT_AGENT_IF_NONE_IDENTIFIED配置选项：

• 如果USE_DEFAULT_AGENT_IF_NONE_IDENTIFIED为True（默认值）：协调器将使用默认代理来处理请求。这确保了用户总是能收到回复，即使这个回复来自一个通用代理。
• 如果USE_DEFAULT_AGENT_IF_NONE_IDENTIFIED为False：协调器将返回由NO_SELECTED_AGENT_MESSAGE配置指定的消息。这提示用户重新表述他们的请求，以便更好地识别代理。

默认代理

默认代理是一个配置为通用型的BedrockLLMAgent，能够处理广泛的主题。它在以下情况下使用：

• 没有选择特定代理，且USE_DEFAULT_AGENT_IF_NONE_IDENTIFIED为True。
• 您明确将其设置为备用选项。

您可以使用set_default_agent方法自定义默认代理或完全替换它：

自定义NO_SELECTED_AGENT_MESSAGE

您可以通过在协调器配置中设置NO_SELECTED_AGENT_MESSAGE来自定义在未选择代理时返回的消息（且USE_DEFAULT_AGENT_IF_NONE_IDENTIFIED为False）：

最佳实践

1. 默认代理的使用：当您希望确保所有用户查询都能收到回复（即使不是来自专业代理）时，请使用默认代理。

2. 提示澄清：当您希望鼓励用户提供更具体或清晰的请求时，将USE_DEFAULT_AGENT_IF_NONE_IDENTIFIED设置为False并自定义NO_SELECTED_AGENT_MESSAGE。

3. 平衡具体性和覆盖范围：仔细考虑您的用例。使用默认代理可以提供更广泛的覆盖范围，但可能会牺牲具体性。提示澄清可能会导致更准确的代理选择，但需要额外的用户交互。

4. 监控和迭代：定期审查未选择代理的情况。这有助于您识别代理覆盖范围的空白或改进分类过程。

通过了解和自定义这些行为，您可以调整您的多代理协调器，以为您的特定用例提供最佳的用户体验。

附加说明

存储选项允许您指定自定义存储机制。默认情况下，它使用内存存储（InMemoryChatStorage），但您可以实现自己的存储解决方案或使用内置选项，如DynamoDB存储。有关更多信息，请参阅“存储”部分。

日志记录器选项允许您提供一个自定义日志记录器。如果未指定，将使用默认日志记录器。要了解如何实现自定义日志记录器，请查阅“日志记录”部分。

分类器选项允许您使用自定义分类器进行意图分类。如果未提供，将默认使用BedrockClassifier。有关实现自定义分类器的详细信息，请参阅“自定义分类器”文档。

通过自定义这些选项，您可以调整Orchestrator的行为，以满足您的特定用例和需求。 

分类器

分类器是多代理协调器（Multi-Agent Orchestrator）的关键组件，负责分析用户输入并识别最合适的代理。协调器支持多种分类器实现，其中Bedrock分类器和Anthropic分类器是主要选项。

可用分类器

• Bedrock分类器

• 利用Amazon Bedrock的AI模型进行意图分类。它是协调器使用的默认分类器。
• Anthropic分类器

• 使用Anthropic的AI模型进行意图分类。它为偏好或有权访问Anthropic服务的用户提供了另一种选择。
• OpenAI分类器
• 使用OpenAI的AI模型进行意图分类。它为偏好或有权访问OpenAI服务的用户提供了另一种选择。

流程

无论使用哪种分类器，一般流程都保持不变：

1. 协调器收集用户输入。

2. 分类器执行输入分析，考虑以下因素：

• 所有代理的会话历史
• 各个代理的简介和能力

3.确定最合适的代理。

默认情况下，如果没有选择代理，协调器可以配置为：

• A. 使用默认代理（例如BedrockLLMAgent）
• B. 返回一条消息提示用户提供更多信息。

可以使用协调器中的USE_DEFAULT_AGENT_IF_NONE_IDENTIFIED和NO_SELECTED_AGENT_MESSAGE 配置选项来自定义此行为。

有关这些选项和其他协调器配置的详细说明，请参阅协调器概述页面。

分类器的决策过程对于有效地将用户查询路由到最合适的代理至关重要，从而确保无缝且高效的多代理交互体验。

初始化

当您通过初始化MultiAgentOrchestrator创建一个新的协调器时，将初始化默认的Bedrock分类器。

要使用Anthropic分类器，可以将其作为选项传递：

这样，您就可以根据您的需求选择合适的分类器来初始化协调器了。

自定义分类器实现

您可以通过扩展抽象Classifier类来提供自己的自定义分类器实现。有关如何执行此操作的详细信息，请参阅“自定义分类器”部分。

测试

您可以直接使用classify方法来测试任何分类器：

这允许您：

• 验证分类器的决策过程
• 测试不同的输入和对话场景
• 微调系统提示或代理描述

常见问题

• 错误分类：如果您发现频繁的错误分类，请审查和更新代理描述或调整系统提示。
• API密钥问题：对于AnthropicClassifier，请确保您的API密钥有效且已正确配置。
• 模型可用性：对于BedrockClassifier，请确保您在AWS账户中有权访问指定的Amazon Bedrock模型。

选择合适的分类器

在决定使用不同的分类器时，请考虑：

1. API访问权限：您可以访问和偏好的服务。

2. 模型性能：使用您的特定用例测试分类器，以确定哪个更适合您的需求。

3.成本：比较您预期使用的定价结构。

通过彻底测试和调试您选择的分类器，您可以确保在多代理协调器中进行准确的意图分类和高效的查询路由。

直接分类器访问

带上下文管理

测试带有完整对话历史记录处理的分类器：

此方法：

• 自动检索对话历史记录
• 在测试调用之间维护上下文
• 适用于端到端测试

不带上下文

测试没有对话历史的原始分类：

最适合：

• 提示调整
• 单输入验证
• 分类单元测试

智能体

在多智能体编排器（Multi-Agent Orchestrator）中，智能体（Agent）是一个基本构建模块，旨在处理用户请求并生成响应。智能体抽象类（Agent Abstract Class）是所有具体智能体实现的基础，提供了通用的结构和接口。

智能体选择过程

多智能体编排器使用一个分类器（Classifier），通常是一个大语言模型（LLM），来为每个用户请求选择最合适的智能体。

这一过程的核心是智能体描述。这些描述至关重要，应尽可能详细和全面。一个精心设计的智能体描述应：

• 清晰地概述智能体的能力和专长
• 提供其能够处理的任务的具体示例
•  将其与系统中的其他智能体区分开来

这些描述越详细和精确，分类器就能越准确地将请求路由到正确的智能体。这在具有多个专用智能体的复杂系统中尤为重要。

有关智能体选择过程的更详细说明，请参阅我们文档中的“工作原理”部分。

为了优化智能体选择：

• 投入时间编写详尽、具体的智能体描述
• 定期审查和优化这些描述
•  使用框架的智能体重叠分析功能，确保智能体之间的明确区分

通过优先考虑详细的智能体描述并微调选择过程，您可以显著提高多智能体编排器实现的效率和准确性。

智能体抽象类

智能体类（Agent class）是一个抽象基类，定义了系统中所有智能体必须具备的基本属性和方法。它设计灵活，允许从简单的API调用者到复杂的基于LLM的对话智能体等多种实现。

关键属性

• name：表示智能体名称的字符串。
• id：智能体的唯一标识符，自动从名称生成。
• description：描述智能体能力和专长的字符串。
• save_chat：布尔值，指示是否保存此智能体的聊天历史记录。
• callbacks：可选的AgentCallbacks对象，用于处理诸如流式响应中新令牌等事件。

抽象方法：process_request

任何智能体的核心功能都封装在process_request方法中。该方法必须由所有具体智能体类实现：

• input_text：用户的输入或查询。
• user_id：用户的唯一标识符。
• session_id：当前对话会话的标识符。
• chat_history：对话中先前消息的列表。
• additional_params：用于额外上下文或配置的可选参数。这是一个强大的功能，允许动态定制智能体行为。它是一个键值对字典，可以在调用编排器的route_request时传递。这些参数随后会转发给相应智能体的process_request方法。自定义智能体可以使用这些参数来调整其行为或为处理请求提供额外的上下文。

该方法返回单个响应的ConversationMessage或流式响应的AsyncIterable。

示例用法：

智能体选项

在创建新智能体时，您可以使用AgentOptions类指定各种选项：

直接使用智能体

当您有单一智能体用例时，可以绕过编排器直接调用智能体。这种方法利用了多智能体编排器框架的强大功能，同时专注于单一智能体场景：

这种方法适用于不需要编排但希望利用多智能体编排器框架强大功能的单一智能体场景。

这些选项允许您自定义智能体行为的各个方面及其配置。 

对话存储

多智能体编排系统（Multi-Agent Orchestrator System）提供了灵活的存储选项，用于维护对话历史记录。这使得系统能够在多次交互中保留上下文，并使智能体能够提供更加连贯且与上下文相关的响应。

关键概念

• 每个对话通过userId、sessionId和agentId的组合唯一标识。
• 存储系统会保存用户消息和助手响应。
• 通过ConversationStorage接口支持不同的存储后端。

可用的存储选项

1.内存存储（In-Memory Storage）：

• 适用于开发、测试或不需要持久化的场景。
• 对于短期会话，快速且高效。

2.DynamoDB存储：

• 为生产环境提供持久化存储。
• 支持可扩展且耐用的对话历史记录存储。

3.SQL存储：

• 使用SQLite或Turso数据库提供持久化存储。
• 适用于需要本地优先开发并支持远程部署的场景。

4.自定义存储解决方案：

• 系统允许实现自定义存储选项，以满足特定需求。

选择合适的存储选项

• 内存存储：用于开发、测试或不需要在应用重启后保留数据的场景。
• DynamoDB存储：适用于生产环境，需要长期保存对话历史记录或跨多个应用实例的场景。
• SQL存储：在简单性和可扩展性之间取得平衡，支持本地和远程数据库。
• 自定义存储解决方案：如果现有选项无法满足特定需求，可以实施自定义存储方案。

通过利用这些存储选项，您可以确保多智能体编排系统在各种用例和部署场景中保持必要的上下文，从而实现连贯且有效的对话。 

检索器

检索器（Retriever）是一种组件或机制，用于从大规模数据集或数据库中提取与查询相关的信息。这一过程对于提升大语言模型（LLMs）的性能和准确性至关重要，尤其是在需要访问和利用外部知识源的任务中。

检索器的关键作用

1.提升上下文与相关性：
检索器能够为大语言模型提供相关的上下文或信息，这些信息可能未包含在其训练数据中，或者过于具体而无法仅从模型的内部知识生成。

2.记忆增强：
检索器充当大语言模型的扩展记忆，使其能够访问最新信息或特定主题的详细数据，从而提高生成响应的相关性和准确性。

3.提高效率：
检索器允许模型按需提取必要的信息，而不是在庞大且不断增长的数据集上进行训练，从而使系统更加高效。

通过检索器的使用，大语言模型能够更智能地

整合外部知识，生成更准确、更符合上下文的响应，同时优化资源利用。

本文章转载微信公众号@Paper易论