1. CrewAI 决策框架

在使用 CrewAI 框架实现我们的应用之前，CrewAI 给出了一个 “Complexity vs. Precision” 矩阵，它基于复杂性与精确性两个维度，划分了 4 个象限，并针对不同象限对复杂性、精确性的要求，提供了使用 CrewAI 的特性的指导和建议。4 个象限划分，如下图所示：

通过这个矩阵可以很好地评估，我们应该如何选择 CrewAI 具备的能力，从而更好地满足应用需求。
下面先给出，在 CrewAI Application 的上下文之内，“复杂性” 和 “精确性” 具体包含哪些要点，这样能够更好地将我们面对的具体应用场景的要求，更准确地映射到 “复杂性” 和 “精确性” 对应的维度上。

1.1 复杂性与精确性

复杂性（Complexity）包括如下几个要点：

• 应用所要求的不同步骤/操作的数量
• 需要执行的任务（Task）的多样性
• 应用中不同组件或不同步骤之间的相互依赖程度
• 是否有条件约束或分支逻辑的要求
• 待构建的整个 Workflow 的复杂程度

精确性（Precision）包括如下几个要点：

• 最终输出结果的精确性要求
• 对结构化（Structured）的、可预测（Predictable）的结果的要求
• 可再现性（Reproducibility）要求
• 程序运行过程中，每一个执行步骤的可控制程度要求
• 对可变化结果输出的容忍性（Tolerance）

1.2 复杂性 vs 精确性四象限

1.2.1 象限一：低复杂性+低精确性

1、象限特征

• 简单的、直接的任务
• 能够容忍输出结果的可变性
• 应用执行的步骤数非常有限
• 创意类或探索类应用

2、应用场景参考

• 基础的内容生成类应用
• 想法头脑风暴
• 简单的提取摘要类任务
• 创意写作助手

3、策略推荐
选择简单的 Crew，或者简单的 Agent 来构建应用。

1.2.2 象限二：低复杂性+高精确性

1、象限特征

• 具有强制性、结构化输出要求的简单 Workflow
• 具有可再现性结果输出需求的场景
• 有限步骤，但要求满足高精确性
• 常常包含数据处理、数据转换要求的场景

2、应用场景参考

• 数据抽取与转换
• 表单填充与校验
• 结构化内容生成（JSON、XML）
• 简单分类任务

3、策略推荐
选择能够直接与 LLM 交互/调用的 Flow，或者具有结构化输出的 Crew。

1.2.3 象限三：高复杂性+低精确性

1、象限特征

• 具有很多步骤的多阶段处理应用场景
• 创意或探索类输出
• 各个组件之间具有复杂的交互
• 能够容忍最终结果的可变性

2、应用场景参考

• 调研与分析场景
• 内容创建 Pipeline
• 数据探查分析
• 解决创意类问题

3、策略推荐
选择具有多个专业化（Specialized）Agent 构建而成的复杂 Crew。

1.2.4 象限四：高复杂性+高精确性

1、象限特征

• 结果要求结构化输出的复杂 Workflow
• 具有严格精确性要求的、多个步骤之间相互依赖的场景
• 同时满足复杂处理和精确结果要求的场景
• 常被认为是至关重要（mission-critical）类的应用场景

2、应用场景参考

• 企业决策支持系统
• 复杂处理 Pipeline
• 多阶段文档处理
• 例行化（受监管类）行业应用场景

3、策略推荐
选择使用 Flow，能够支持编排（Orchestrating）具有带校验步骤的多个 Crew。

2. 实用的评估框架

为了能够在实际使用 CrewAI 之前进行评估，可以参考下面的评估流程：

2.1 评估复杂性要求

通过考虑以下因素，在 1-10 的范围内对应用程序的复杂性进行打分（打完分后，计算平均得分作为总体的复杂性分数）：
2.1.1 步骤数量：要求有多少个不同的操作步骤？

• 1-3 步：低复杂性（1-3）
• 4-7 步：中复杂性（4-7）
• 8+ 步：高复杂性（8-10）

2.1.2 相互依赖性：不同部分相互依赖程度如何？

• 依赖非常少：低依赖性（1-3）
• 一些依赖：中依赖性（4-7）
• 很多复杂依赖：高依赖性（8-10）

2.1.3 条件逻辑：需要多少分支和决策？

• 线性流程：低复杂性（1-3）
• 一些分支：中复杂性（4-7）
• 复杂决策树：高复杂性（8-10）

2.1.4 领域知识：所需要的知识有多么专业？

• 通用知识：低复杂性（1-3）
• 一些专业知识：中复杂性（4-7）
• 在多个领域具有深厚的专业知识：高复杂性（8-10）

2.2 评估精确性要求

通过考虑以下因素，在 1-10 的范围内对精确性要求进行评分（打完分后，计算平均得分作为总体的精确性要求得分）：
2.2.1 必须输出内容的结构化程度如何？

• 自由形式的文本输出：低精确性（1-3）
• 半结构化输出：中精确性（4-7）
• 严格结构化输出（JSON、XML）：高精确性（8-10）

2.2.2 精确度要求：事实的准确性有多么重要？

• 创意类内容：低精确性（1-3）
• 信息类内容：中精确性（4-7）
• 关键类信息：高精确性（8-10）

2.2.3 可再现性要求：各批次输出的结果需要有多么强的一致性要求？

• 能够接收可变性：低精确性（1-3）
• 有一定的一致性要求：中精确性（4-7）
• 需要精确的可再现性：高精确性（8-10）

2.2.4 错误容忍度：错误结果的影响是什么？

• 影响不大：低精确性（1-3）
• 中度影响：中精确性（4-7）
• 影响很大：高精确性（5-10）

2.3 映射到 “Complexity vs. Precision” 矩阵

根据上面两个步骤得到的总体复杂性得分、精确性要求得分，映射到对应的四象限的某一个象限，得出适合的当前要构建的应用的选型方法：

• 低复杂性 (1-4), 低精确性 (1-4)：Simple Crews
• 低复杂性 (1-4), 高精确性 (5-10)：Flows with direct LLM calls
• 高复杂性 (5-10), 低精确性 (1-4)：Complex Crews
• 高复杂性 (5-10), 高精确性 (5-10)：Flows orchestrating Crews

2.4 需要考虑的其他因素

• 开发时间：Crew 一般用于快速构建原型
• 运维要求：Flow 能够更好地支持长期可维护性
• 团队专业性：考虑团队对其他方法的熟悉程度
• 可扩展性要求：Flow 能够更好地支持扩展以适应复杂应用场景
• 集成要求：考虑解决方案与现有系统怎样进行集成

3. Crew 与 Flow 选择参考

Crew 与 Flow 是 CrewAI 框架中两个非常核心的组件，通过它们可以构建满足各种需求的应用程序。深入理解在什么场景下使用 Crew 或 Flow 更加合适，能够更好地指导我们做出更佳的决策。

3.1 Crew 是什么？

在 CrewAI中，Crew 代表了一组协同工作的 Agent，它们能够共同完成一系列任务。每个 Crew 都定义了任务执行、Agent 协作和整体 Workflow 的策略。
有关 Crew 更详细的说明和使用，可以参考官网文档 https://docs.crewai.com/concepts/crews。

3.2 Flow 是什么？

Flow 是 CrewAI 提供的一个强大的特性，它旨在简化 AI Workflow 的创建和管理。Flow 允许开发人员高效地组合并协调编码任务（Task）和 Crew，为构建复杂的 AI 自动化应用程序提供了一个强大的框架。
Flow 允许我们创建结构化的、事件驱动的 Workflow，并提供了一种无缝的方式来连接多个任务、管理状态和控制 AI 应用程序中的执行流。借助 Flow，我们可以轻松设计和实现具有多个步骤的 Workflow，更加充分地发挥出 CrewAI 的潜力。
有关 Flow 更详细的说明和使用，可以参考官网文档 https://docs.crewai.com/concepts/flows。

3.3 使用 Crew 的最佳场景

• 需要更智能的协作：具有不同专业化能力的多个 Agent 共同协作完成任务
• 待解决的问题更依赖思维涌现：解决方案受益于不同的视角和方法
• 具有创造性或分析性能力的任务：工作涉及研究、内容创建或分析
• 强调灵活性胜过严格的结构：Workflow 受益于 Agent 的自主性
• 输出结构具有一定的灵活性：能够接受输出结构有一定的变化

3.4 使用 Flow 的最佳场景

• 需要对任务执行做精确控制：Workflow 需要精确排序和状态管理
• 应用具有复杂的状态：需要跨多个步骤对状态进行维护与转换
• 需要结构化的、可预测的输出：应用程序要求一致性、格式化的结果
• Workflow 包含条件逻辑：对于不同的中间结果需要有不同的执行路径
• 需要将 AI 与过程性代码相结合：方案要求兼具 AI 能力与传统编程能力

3.5 混合使用 Crew 与 Flow 的最佳场景

• 复杂多阶段处理场景：使用 Flow 编排整体流程，使用 Crew 实现复杂子任务
• 具有创意性和结构性要求的场景：使用 Crew 实现创意性的部分，使用 Flow 实现结构化处理的部分
• 企业级 AI 应用场景：使用 Flow 管理状态和处理流程，使用 Crew 实现具有专业性要求的任务

4. 总结

使用 CrewAI 框架构建 AI Agent 应用程序，需要在 Crew 和 Flow 之间进行选择，或者将它们组合在一起来使用，这样一个关键的架构决策过程，能够影响到我们使用 CrewAI 应用程序的有效性、可维护性和可扩展性。通过对对应场景的复杂性和精确性进行评估，能够更好地做出与特定要求相匹配的明智决策。
一个推荐的方法是，随着需求的不断细化而不断调整我们的决策，以满足不同阶段的不同需要。我们可以从最简单的解决方案开始，随着经验的积累和需求的明确，不断地调整和完善架构，最终达到我们期望实现的业务目标或系统目标。

5. 参考链接

• Evaluating Use Cases for CrewAI
• https://docs.crewai.com/concepts/crews
• https://docs.crewai.com/concepts/flows

• CSV RAG Search
• Directory RAG Search
• DOCX RAG Search
• JSON RAG Search
• MDX RAG Search
• MySQL RAG Search
• PDF RAG Search
• PG RAG Search
• Qdrant Vector Search Tool
• TXT RAG Search
• XML RAG Search
• Website RAG Search
• YouTube Channel RAG Search
• YouTube Video RAG Search

下面，我们通过使用 PDFSearchTool 来快速探索 CrewAI 支持 RAG 的能力，以及探索 StringKnowledgeSource、PDFKnowledgeSource 这两个非常基础的 Knowledge Source 的使用，以此来了解 CrewAI 对 RAG 能力的支持和使用方法。

PDFSearchTool 使用示例

我们通过 CrewAI 提供的 PDFSearchTool 来快速实现一个简单的用户问答系统：回答用户的提问，都是基于给定的 PDF 文档的内容来进行回答，这样就把给定的文档作为会话的知识库了（这里，我是基于 https://github.com/drewzeee/crewai-rag.git 这个例子简单改了一下，基本业务逻辑未变，但是使用了本地 Ollama 管理的 DeepSeek-R1 模型来进行推理）。这个例子的基本功能是：
设置两个 Agent，一个是 Research Agent，负责检索给定的 PDF 文档，获取与用户提问相关的内容片段；另一个是 Professional Writer Agent，它根据 Research Agent 检索得到的内容，写一封满足指定要求的 Email 正文。
具体实现的完整代码，如下所示：

from crewai import Agent, Crew, Process, Task, LLM
from crewai_tools import PDFSearchTool
import litellm

litellm._logging._turn_on_debug()

# Initialize local LLM
llm = LLM(
    api_key="NA",
    temperature=0,
    model="ollama/deepseek-r1:1.5b",
    base_url="http://localhost:11434")
print("Local LLM: ", llm)

# PDF SOURCE: https://www.gpinspect.com/wp-content/uploads/2021/03/sample-home-report-inspection.pdf
pdf_search_tool = PDFSearchTool(
    pdf="./example_home_inspection.pdf",
    config=dict(
        llm=dict(
            provider="ollama",
            config=dict(
                model="deepseek-r1:1.5b",
            ),
        ),
        embedder=dict(
            provider="ollama",
            config=dict(
                model="nomic-embed-text:latest",
            ),
        ),
    )
)

research_agent = Agent(
    role="Research Agent",
    goal="Search through the PDF to find relevant answers",
    allow_delegation=False,
    verbose=True,
    backstory=(
        """
        The research agent is adept at searching and
        extracting data from documents, ensuring accurate and prompt responses.
        """
    ),
    tools=[pdf_search_tool],
    llm=llm
)

professional_writer_agent = Agent(
    role="Professional Writer",
    goal="Write professional emails based on the research agent's findings",
    allow_delegation=False,
    verbose=True,
    backstory=(
        """
        The professional writer agent has excellent writing skills and is able to craft
        clear and concise emails based on the provided information.
        """
    ),
    tools=[],
    llm=llm
)

# --- Tasks ---
answer_customer_question_task = Task(
    description=(
        """
        Answer the customer's questions based on the home inspection PDF.
        The research agent will search through the PDF to find the relevant answers.
        Your final answer MUST be clear and accurate, based on the content of the home
        inspection PDF.

        Here is the customer's question:
        {customer_question}
        """
    ),
    expected_output="""
        Provide clear and accurate answers to the customer's questions based on
        the content of the home inspection PDF.
        """,
    tools=[pdf_search_tool],
    agent=research_agent,
)

write_email_task = Task(
    description=(
        """
        - Write a professional email to a contractor based
            on the research agent's findings.
        - The email should clearly state the issues found in the specified section
            of the report and request a quote or action plan for fixing these issues.
        - Ensure the email is signed with the following details:

            Best regards,

            Brandon Hancock,
            Hancock Realty
        """
    ),
    expected_output="""
        Write a clear and concise email that can be sent to a contractor to address the
        issues found in the home inspection report.
        """,
    tools=[],
    agent=professional_writer_agent,
)

crew = Crew(
    agents=[research_agent, professional_writer_agent],
    tasks=[answer_customer_question_task, write_email_task],
    process=Process.sequential,
)

customer_question = input(
    "Which section of the report would you like to generate a work order for?\n"
)
result = crew.kickoff_for_each(inputs=[{"customer_question": "Bathroom and Components"}])
print(result)

上面代码中，我们输入的用户问题为：Bathroom and Components，亦即从 PDF 中的这个段落里检索相关内容，并最终生成一个 Work Order 的 Email 正文。
运行代码，我们可以通过日志来看一看程序执行过程中的一些关键内容：

1、使用自定义 LLM 与 Embedding 模型

在 PDFSearchTool 中通过 config 来指定自己想使用的 LLM 和 Embedding 模型，如下所示：

  config=dict(
      llm=dict(
          provider="ollama",
          config=dict(
              model="deepseek-r1:1.5b",
          ),
      ),
      embedder=dict(
          provider="ollama",
          config=dict(
              model="nomic-embed-text:latest",
          ),
      ),
  )

如果不指定默认的 Embedding 模型，PDFSearchTool 默认会使用 OpenAI 的 Embedding 模型，直接在本地调试运行可能会调用 OpenAI 的 API 失败而无法使用。另外，在运行程序之前，我们需要在本地通过 Ollama 下载 nomic-embed-text 模型，并启动 Ollama 服务，这样程序才能正常运行。

2、Research Agent 检索 PDF 文档

程序运行过程中，会把 PDF 文档内容的 Embedding 数据写入 Chromadb，如下所示：

Local LLM:  <crewai.llm.LLM object at 0x122f65e20>
/Users/dean/anaconda3/envs/crewai/lib/python3.12/site-packages/embedchain/embedder/ollama.py:27: LangChainDeprecationWarning: The class `OllamaEmbeddings` was deprecated in LangChain 0.3.1 and will be removed in 1.0.0. An updated version of the class exists in the :class:`~langchain-ollama package and should be used instead. To use it run `pip install -U :class:`~langchain-ollama` and import as `from :class:`~langchain_ollama import OllamaEmbeddings``.
  embeddings = OllamaEmbeddings(model=self.config.model, base_url=config.base_url)
Inserting batches in chromadb: 100%|██████████| 3/3 [02:14<00:00, 44.84s/it]

我们可以看到，在当前目录下生成了一个 db 文件目录，里面保存对应的数据：

db
├── 3b95287f-b015-43cd-937c-4a45617dff1c
│   ├── data_level0.bin
│   ├── header.bin
│   ├── length.bin
│   └── link_lists.bin
└── chroma.sqlite3

3、Research Agent 检索 PDF 文档

Research Agent 检索 PDF 文档，检索关键词是 Roof，通过运行日志可以看到得到的内容，如下所示：

# Agent: Research Agent
## Final Answer:
The home inspection PDF provides detailed information about the bathroom system, including water heater,龙头, Tank, Shower, and Sink. It also outlines fixtures like showerheads, vanities, and basic components such as flushers and toilet tanks.

这是 Research Agent 从 PDF 文档中检索到的相关内容。

4、Professional Writer Agent 与 LLM 交互

将 Research Agent 检索得到的结果内容作为 Professional Writer Agent 的会话上下文信息，执行具体的任务，我们可以看到此时发送给 LLM 的请求信息，如下所示：

POST Request Sent from LiteLLM:
curl -X POST \
http://localhost:11434/api/generate \
-d '{'model': 'deepseek-r1:1.5b', 'prompt': "### System:\nYou are Professional Writer. \n        The professional writer agent has excellent writing skills and is able to craft \n        clear and concise emails based on the provided information.\n        \nYour personal goal is: Write professional emails based on the research agent's findings\nTo give my best complete final answer to the task respond using the exact following format:\n\nThought: I now can give a great answer\nFinal Answer: Your final answer must be the great and the most complete as possible, it must be outcome described.\n\nI MUST use these formats, my job depends on it!\n\n### User:\n\nCurrent Task: \n        - Write a professional email to a contractor based \n            on the research agent's findings.\n        - The email should clearly state the issues found in the specified section \n            of the report and request a quote or action plan for fixing these issues.\n        - Ensure the email is signed with the following details:\n        \n            Best regards,\n\n            Brandon Hancock,\n            Hancock Realty\n        \n\nThis is the expected criteria for your final answer: \n        Write a clear and concise email that can be sent to a contractor to address the \n        issues found in the home inspection report.\n        \nyou MUST return the actual complete content as the final answer, not a summary.\n\nThis is the context you're working with:\nThe home inspection PDF provides detailed information about the bathroom system, including water heater,龙头, Tank, Shower, and Sink. It also outlines fixtures like showerheads, vanities, and basic components such as flushers and toilet tanks.\n\nBegin! This is VERY important to you, use the tools available and give your best Final Answer, your job depends on it!\n\nThought:\n\n### User:\nI did it wrong. Invalid Format: I missed the 'Action:' after 'Thought:'. I will do right next, and don't use a tool I have already used.\n\nIf you don't need to use any more tools, you must give your best complete final answer, make sure it satisfies the expected criteria, use the EXACT format below:\n\n```\nThought: I now can give a great answer\nFinal Answer: my best complete final answer to the task.\n\n```\n\n", 'options': {'temperature': 0, 'stop': ['\nObservation:']}, 'stream': False}'

可以看到，以 “This is the context you’re working with:” 开始的内容，就是 Research Agent 指派的 Task 执行检索 PDF 文档的结果内容，它作为 Professional Writer Agent 执行 Task 的上下文信息，提供了与用户提出的问题相关的会话上下文。

5、Professional Writer Agent 生成最终的结果

可以通过运行日志看到，Professional Writer Agent 按照指定的要求，生成了最终的 Work Order Email 正文，如下所示：

# Agent: Professional Writer
## Final Answer:
Brandon Hancock, Hancock Realty
Dear Brandon Hancock,

I am writing to address the findings from the bathroom system inspection report. The key issues identified include water heater performance,龙头 pressure, Tank leaks, Shower fixtures not functioning properly, and potential issues with vanities or flushers.

We request quotes for component replacements and an action plan to address these problems promptly. Please let us know when you can provide more details on the specific components that need attention.

Best regards,
Brandon Hancock
Hancock Realty

至此，基于 PDFSearchTool，并且具有两个 Agent 的例子，两个 Agent 进行协作解决了用户提出的问题。

CrewAI Knowledge 使用示例

在 CrewAI 中，Agent 和 Crew 都具有 knowledge_sources 属性，所以 CrewAI 能够分别支持 Agent 和 Crew 两个不同级别的 Knowledge 设置，它们使 Knowledge 限定在了指定的作用域之内。
使用 CrewAI Knowledge 特性的过程中，会遇到各种问题，我们可以通过例子来具体说明使用 StringKnowledgeSource 和 PDFKnowledgeSource。

使用 StringKnowledgeSource 示例

根据给定的字符串，回答用户的提问，这个例子比较简单，示例代码如下所示：

...

from crewai import Agent, Task, Crew, Process, LLM
from crewai.knowledge.source.string_knowledge_source import StringKnowledgeSource

content = "Users name is John. He is 30 years old and lives in San Francisco."
string_source = StringKnowledgeSource(
    content=content,
)

# Create an agent with the knowledge store
agent = Agent(
    role="About User",
    goal="You know everything about the user.",
    backstory="""You are a master at understanding people and their preferences.""",
    verbose=True,
    allow_delegation=False,
    llm=llm,
    knowledge_sources=[string_source],
    embedder=dict(
            provider="ollama",
            config=dict(
                model="nomic-embed-text:latest",
                base_url="http://localhost:11434",
            ),
        ),
)

task = Task(
    description="Answer the following questions about the user: {question}",
    expected_output="An answer to the question.",
    agent=agent,
)

crew = Crew(
    agents=[agent],
    tasks=[task],
    verbose=True,
    process=Process.sequential,
)

result = crew.kickoff(inputs={"question": "What city does John live in and how old is he?"})

我们可以看到，Agent 基于输入的字符串信息作为会话上下文，正确回答了用户提出的问题：

# Agent: About User
## Final Answer:
John is 30 years old and lives in San Francisco.

我们需要注意两个问题：

1、指定自己的 Embedding 模型配置

通过 Agent 的 embedder 来指定希望使用的 Embedding 模型的配置，具体参考前面说明，不再赘述。

2、Knowledge Source 文本长度对 Agent 有影响

上面代码中，我们使用的 StringKnowledgeSource 对应的字符串文本长度比较短，在运行过程中不会出现问题。但是如果文本长度比过长，就会报错，这时需要对 StringKnowledgeSource 进行分块配置，需要指定对应的配置，示例如下：

content = "... ...（长度很长的字符串文本）"
string_source = StringKnowledgeSource(
    content=content,
    chunk_size=256,  # Maximum size of each chunk (default: 4000)
    chunk_overlap=32  # Overlap between chunks (default: 200)
)

需要注意的是，对所有的 Knowledge Source，如果内容过长都需要进行分块配置，否则程序报错。以我使用的为例，主要是在写入 Chromadb 时超时，错误信息如下：

[2025-03-12 13:08:02][ERROR]: Failed to upsert documents: timed out in upsert.
Traceback (most recent call last):
  File "/Users/dean/anaconda3/envs/crewai/lib/python3.12/site-packages/httpx/_transports/default.py", line 72, in map_httpcore_exceptions
    yield
  File "/Users/dean/anaconda3/envs/crewai/lib/python3.12/site-packages/httpx/_transports/default.py", line 236, in handle_request
    resp = self._pool.handle_request(req)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/dean/anaconda3/envs/crewai/lib/python3.12/site-packages/httpcore/_sync/connection_pool.py", line 256, in handle_request
    raise exc from None
  File "/Users/dean/anaconda3/envs/crewai/lib/python3.12/site-packages/httpcore/_sync/connection_pool.py", line 236, in handle_request
    response = connection.handle_request(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/dean/anaconda3/envs/crewai/lib/python3.12/site-packages/httpcore/_sync/connection.py", line 103, in handle_request
    return self._connection.handle_request(request)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/dean/anaconda3/envs/crewai/lib/python3.12/site-packages/httpcore/_sync/http11.py", line 136, in handle_request
    raise exc
  File "/Users/dean/anaconda3/envs/crewai/lib/python3.12/site-packages/httpcore/_sync/http11.py", line 106, in handle_request
    ) = self._receive_response_headers(**kwargs)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/dean/anaconda3/envs/crewai/lib/python3.12/site-packages/httpcore/_sync/http11.py", line 177, in _receive_response_headers
    event = self._receive_event(timeout=timeout)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/dean/anaconda3/envs/crewai/lib/python3.12/site-packages/httpcore/_sync/http11.py", line 217, in _receive_event
    data = self._network_stream.read(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/dean/anaconda3/envs/crewai/lib/python3.12/site-packages/httpcore/_backends/sync.py", line 126, in read
    with map_exceptions(exc_map):
         ^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/dean/anaconda3/envs/crewai/lib/python3.12/contextlib.py", line 158, in __exit__
    self.gen.throw(value)
  File "/Users/dean/anaconda3/envs/crewai/lib/python3.12/site-packages/httpcore/_exceptions.py", line 14, in map_exceptions
    raise to_exc(exc) from exc
httpcore.ReadTimeout: timed out

根据实际情况进行分块配置，就能解决这个问题。

使用 PDFKnowledgeSource 示例

使用 PDFKnowledgeSource，示例代码如下所示：

...

from crewai.knowledge.source.pdf_knowledge_source import PDFKnowledgeSource

# Create a PDF knowledge source
pdf_source = PDFKnowledgeSource(
    file_paths=["kde_example_home_inspection.pdf"],
    # chunk_size=256,  # Maximum size of each chunk (default: 4000)
    # chunk_overlap=32  # Overlap between chunks (default: 200)
)

# Create an agent with the knowledge store
agent = Agent(
    role="Report Analyst",
    goal="You know everything about the report.",
    backstory="""You are a master at understanding the content of the given report.""",
    verbose=True,
    allow_delegation=False,
    llm=llm,
    knowledge_sources=[pdf_source],
    embedder=dict(
            provider="ollama",
            config=dict(
                model="nomic-embed-text:latest",
                base_url="http://localhost:11434",
            ),
        ),
)

task = Task(
    description="Answer the following questions about the report: {question}",
    expected_output="An answer to the question.",
    agent=agent,
)

crew = Crew(
    agents=[agent],
    tasks=[task],
    verbose=True,
    process=Process.sequential,
)

crew.kickoff(inputs={"question": "What is the percentage of the lighting use typically?"})

总结

在使用过程中发现，如果 Agent 的属性 role 的内容为中文时，程序就会报错。在跟踪代码过程中发现，会把 role 的内容经过处理作为 collection name，而中文的 role 内容转换成的 collection name 是无法通过 CrewAI 框架代码的校验的，直接会报错。出现这个问题有可能和环境有关，也可能是其它原因，具体解决办法就是改成英文描述，即可暂时解决这个问题。

在使用 AI Agent 实现我们计划的功能的过程中，如果发现达不到预期，这时往往可能有如下几个原因：
1、对自己项目的应用场景的要求并未十分明确，比如应用复杂度、结果精确度，只有选择框架提供的合适的特性才能满足我们项目的要求；
2、和选择的 LLM 支持的语言有关，比如有的 LLM 对英文支持较好，有的对中文支持较好；
3、评估所选择的 LLM 推理能力，如果推理能力不好，也比较难达到预期结果；
4、设置 Agent、Task 的提示词需要一定的技巧，描述不清楚可能推理出来的结果就不好。

参考链接

• https://docs.crewai.com/concepts/knowledge
• https://github.com/drewzeee/crewai-rag.git

直接编码开发构建

下面，我们通过一个简单的例子，通过直观编码的来实现基本的 AI Agent，通过一个 Agent 和一个 Task 完成报表的查询和可视化输出。为了方便，可以使用 JupyterLab 开发和调试程序。

1.准备工作

在本地使用 Ollama 来运行大模型，从 Ollama 官网下载并安装 Ollama，为方便调试先安装 DeepSeek R1 7B 的模型，大约 5G 大小：

ollama run deepseek-r1:7b

在命令行中可以输入自然语言进行推理，说明安装成功。
然后，在本地安装 CrewAI 的工具包（这里我使用了一个 Anaconda 虚拟环境）：

conda create -n crewai python=3.12
conda activate CrewAI
pip install 'crewai[tools]'

下面可以开发我们的程序，如果需要可以打开 CrewAI 的 Debug 功能：

from langchain_openai import ChatOpenAI
from crewai import LLM

# Turn debug for LLM
import litellm
litellm._logging._turn_on_debug()

2.初始化大模型 LLM

可以使用本地的 LLM，实现代码如下所示：

# Initialize local LLM
llm = ChatOpenAI(
    api_key = "NA",
    model = "ollama/deepseek-r1:7b",
    base_url = "http://localhost:11434/v1")
print("Local LLM: ", llm)

也可以使用调用 API 的方式，代码如下所示：

# Connect remote LLM API
llm = LLM(
    api_key = "sk-xxxxxxx",
    model = "deepseek/Pro/deepseek-ai/DeepSeek-R1",
    base_url = "https://api.xxxx.com/v1",
    temperature=0.3)
print("Remote LLM: ", llm)

使用大模型服务提供商提供的 API，一般需要指定 API Key、模型名称、Base URL，根据自己的情况进行选择。这里需要说明的是，使用 CrewAI 时模型名称 model 的值要求满足格式“LLM 提供商名称/模型名称”，否则运行代码时无法通过验证，具体地 LLM 提供商可以查看 LiteLLM 网站 https://docs.litellm.ai/docs/providers/ 支持哪些 LLM Provider。

3.实现 CrewAI Agent、Task

创建一个 CrewAI 应用，需要实现 Agent、Task，还有构成它们的 Tools。我们实现的简单功能是，通过向 AI Agent 提问，查询指定的接口获取统计结果数据，并实现简单的可视化。这里，抽象出一个 Tool、一个 Task、一个 Agent，对应的实现代码如下所示：

# Create every agent & tool & task
from crewai import Agent, Task, Crew
from crewai.tools import BaseTool

# Define available tools
class ReportQueryTool(BaseTool):
    name: str = "报表查询工具"
    description: str = "根据输入日期范围，查询统计结果数据"

    def _run(self, start_date: str, end_date: str) -> str:
        """
        根据日期范围查询，结果是按天、城市统计的活跃用户数报表结果数据。
        参数:
            - start_date: 开始日期，格式为 yyyyMMdd
            - end_date: 截止日期，格式为 yyyyMMdd
        返回:
            - 查询结果以 JSON 格式字符串返回，结果包含按天、城市两个维度的活跃用户数统计结果
        """
        return '[{"dt":"20240101","city":"BJ","active_user_cnt":12765},{"dt":"20240101","city":"SH","active_user_cnt":823222},{"dt":"20240102","city":"BJ","active_user_cnt": 53025},{"dt":"20240102","city":"SH","active_user_cnt":92001}]'

# Define agent
report_agent = Agent(
    role = "数据报表分析助手",
    goal = "负责查询统计结果报表数据，并进行可视化",
    backstory = "使用提供的工具查询统计结果数据，然后自主实现数据可视化",
    llm = llm,
    tools = [ReportQueryTool()],
    verbose = True
)
print("Agent(report_agent): ", report_agent)

# Define our task
report_task = Task(
    description = "查询2024年1月用户活跃统计结果，然后自主生成简单的可视化表格",
    agent = report_agent,
    tools = [ReportQueryTool()],
    expected_output="包含日期、城市、活跃用户数三个字段的简单表格"
)
print("Task(report_task): ", report_task)

上面代码中，ReportQueryTool 模拟输入一个日期范围作为筛选条件，模拟返回查询到的统计结果记录行，使用 JSON 格式返回。然后配置 Agent 和 Task 都与该 Tool 关联。

4.实现 CrewAI 执行入口程序 Crew

每个 CrewAI 程序都包含一个执行入口，使用 CrewAI 提供的 Crew 类来实现，代码如下所示：

# Define crew
crew = Crew(
    agents = [report_agent],
    tasks = [report_task],
    verbose = True,
    planning = False,
    full_output = True)

result = crew.kickoff()
print(result)

运行上面程序，可以看到执行过程，能够看到程序与 LLM 交互来实现推理并得到最终结果，示例结果输出如下所示：

# Agent: 数据报表分析助手
## Task: 查询用户活跃统计结果，然后自主生成简单的可视化表格


# Agent: 数据报表分析助手
## Using tool: 报表查询工具
## Tool Input:
"{\"start_date\": \"2024-01-01\", \"end_date\": \"2024-01-31\"}"
## Tool Output:
[{"dt":"20240101","city":"BJ","active_user_cnt":12765},{"dt":"20240101","city":"SH","active_user_cnt":823222},{"dt":"20240102","city":"BJ","active_user_cnt": 53025},{"dt":"20240102","city":"SH","active_user_cnt":92001}]


# Agent: 数据报表分析助手
## Final Answer:
| 日期       | 城市 | 活跃用户数 |
|------------|------|------------|
| 2024-01-01 | BJ   | 12,765    |
| 2024-01-01 | SH   | 823,222   |
| 2024-01-02 | BJ   | 53,025    |
| 2024-01-02 | SH   | 92,001    |
```


| 日期       | 城市 | 活跃用户数 |
|------------|------|------------|
| 2024-01-01 | BJ   | 12,765    |
| 2024-01-01 | SH   | 823,222   |
| 2024-01-02 | BJ   | 53,025    |
| 2024-01-02 | SH   | 92,001    |
```

通过工程方式开发构建

对于复杂系统，可以将一些经常修改的内容，如提示词等放进配置文件里面，以方便按需修改，通过通过工程的方式构建就会比较方便一些。
使用 CrewAI 的 CLI 命令可以创建一个 CrewAI 项目：

crewai create crew simple_report_app

可以看到生成的项目结构，如下所示：

simple_report_app/
├── .gitignore
├── pyproject.toml
├── README.md
├── .env
└── src/
    └── simple_report_app/
        ├── __init__.py
        ├── main.py
        ├── crew.py
        ├── tools/
        │   ├── custom_tool.py
        │   └── __init__.py
        └── config/
            ├── agents.yaml
            └── tasks.yaml

接下来，把前面我实现的代码，拆分并转换成对应的 YAML 配置文件、代码文件即可。

main.py

#!/usr/bin/env python

import sys
from simple_report_app.crew import SimpleReporterCrew

def run():
  """
  Run the crew.
  """
  inputs = {
    'topic': 'AI Agents'
  }
  SimpleReporterCrew().crew().kickoff(inputs=inputs)

crew.py

from crewai import Agent, Crew, Process, Task
from crewai.project import CrewBase, agent, crew, task
from custom_tool import ReportQueryTool

@CrewBase
class SimpleReporterCrew():
  """SimpleReporter crew"""

  @agent
  def reporter(self) -> Agent:
    return Agent(
      config = self.agents_config['reporter'],
      verbose = True,
      tools = [ReportQueryTool()]
    )

  @task
  def report_task(self) -> Task:
    return Task(
      config =s elf.tasks_config['report_task'],
    )

  @crew
  def crew(self) -> Crew:
    """Creates the SimpleReporter crew"""
    return Crew(
      agents = self.agents, # Automatically created by the @agent decorator
      tasks = self.tasks, # Automatically created by the @task decorator
      process = Process.sequential,
      verbose = True,
    )

custom_tool.py

from crewai.tools import BaseTool

# Define available tools
class ReportQueryTool(BaseTool):
    name: str = "报表查询工具"
    description: str = "根据输入日期范围，查询统计结果数据"

    def _run(self, start_date: str, end_date: str) -> str:
        """
        根据日期范围查询，结果是按天、城市统计的活跃用户数报表结果数据。
        参数:
            - start_date: 开始日期，格式为 yyyyMMdd
            - end_date: 截止日期，格式为 yyyyMMdd
        返回:
            - 查询结果以 JSON 格式字符串返回，结果包含按天、城市两个维度的活跃用户数统计结果
        """
        return '[{"dt":"20240101","city":"BJ","active_user_cnt":12765},{"dt":"20240101","city":"SH","active_user_cnt":823222},{"dt":"20240102","city":"BJ","active_user_cnt": 53025},{"dt":"20240102","city":"SH","active_user_cnt":92001}]'

agents.yaml

reporter:
  role: >
    数据报表分析助手
  goal: >
    负责查询统计结果报表数据，并进行可视化
  backstory: >
    使用提供的工具查询统计结果数据，然后自主实现数据可视化

tasks.yaml

report_task:
  description: >
    查询2024年1月用户活跃统计结果，然后自主生成简单的可视化表格
  expected_output: >
    包含日期、城市、活跃用户数三个字段的简单表格
  agent: reporter

我们可以修改项目配置文件 pyproject.toml 指定相应的配置，然后安装相关依赖：

cd simple_report_app
crewai install

如果安装没有问题，可以执行运行命令：

crewai run

输出和前面直接编码的方式，结果类似。因为每次都和 LLM 交互进行推理，有可能出现不一样的结果。如果得到的结果不满足预期，就要调整对应的提示词，最终达到我们期望的结果。

参考链接

• https://docs.crewai.com/introduction
• https://docs.crewai.com/installation
• https://docs.crewai.com/quickstart
• https://ollama.com

下面，对 GPT 系列每一个模型的网络架构和相关优化技术要点进行详细说明。

GPT-1 模型

GPT-1 模型的基本架构，以及基于预训练模型进行微调应用于下游 NLP 任务的流程，如下图所示：

GPT-1 模型的训练过程，可以分为两个阶段：

• 无监督预训练（Unsupervised Pre-training）

GPT-1 模型采用了基于自注意力（Self-Attention）机制的 Transformer 模型，模型架构只包括解码器（Encoder）部分。
在预训练过程中，使用了掩码自注意力（Masked Self-Attention）机制实现自注意力计算，在计算自注意力权重时，模型只能关注当前位置及前面的位置，而不考虑未来的位置。
GPT-1 预训练任务的目标是学习语言的通用表示，而不是将输入序列映射到目标序列，所以 GPT-1 模型选择了只采用解码器（Encoder）部分的神经网络架构。

• 有监督微调（Supervised Fine-tuning）

GPT-1 模型预训练完成后，模型为了能够更好地支持下游多种不同类型的 NLP 应用任务，模型需要进行有监督微调，即根据具体 NLP 任务的需求对数据进行标注，然后在进行模型的微调训练。模型微调的过程也称为迁移学习，利用已经预训练好的模型，能够节省巨大的计算成本，而且能够将预训练得到的模型的知识能力迁移到下游应用场景中，比如推理（Inference）、情感分析、相似度计算（Similarity Computation）、多项选择（Multiple Choice）、文本分类（Text Classification）、对话问答（Chat Q/A）等。
在微调阶段，对特定任务的输入进行转换时，需要保证预训练阶段使用的词汇表和编码方案与微调阶段保持一致，否则得到的微调模型使用时会出现无法保持一致的语言表示、理解能力。

采用 BPE（Byte-Pair Encoding）分词算法

GPT-1 采用 BPE（Byte-Pair Encoding）分词算法，它是一种基于数据压缩的可逆分词（Reversible Tokenization）方法，可以有效地减小词汇表的大小，从而减少模型需要学习的参数量。
BPE 分词算法的基本步骤，如下所示：

1. 建立初始词表：将每个词/字符加入词表；
2. 统计字符出现频率；
3. 合并高频的字符对；
4. 重复上面步骤 2 → 3。

最后，将原始的文本压缩成立一种更短的形式，同时还保存了词/字符间频繁出现的模式。
BPE 算法非常适合处理英文文本，而中文和英文完全不同，处理中文分词会更加复杂。

采用掩码多头注意力机制

GPT-1 采用了掩码自注意力（Masked Self-Attention）机制，掩码的含义是，用来控制模型在处理序列数据时忽略无效的部分，具体来说就是一个与输入序列的长度相同的、由 0 和 1 组成的矩阵，其中 0 表示对应位置是无效的，1 表示对应位置是有效的。掩码自注意力，是将输入序列中右侧部分的无效位置屏蔽掉，这样在进行计算时无效位置的权重就会变得非常小，从而将其对最终结果的影响降到最小。通过使用掩码自注意力机制，使模型在训练过程中能够更好地捕捉到序列中的有效信息。
对于掩码多头注意力（Masked Multi-head Attention）机制，我们可以通过下图来说明它的处理机制：

上图中，使用了一种 Look Ahead Masking 的方法，对于未来出现的 token 会将它们的权重值置为无效，而对其它已经出现过的 token 使用正常的多头注意力机制来计算权重。

GPT-2 模型

GPT-2 也采用了只包含解码器（Decoder）部分的 Transformer 架构，而且是单向的，它使用了不同规模的参数量进行模型的训练，如下图所示：

如图所示，总计包括了 4 种不同参数规模的模型：

• SMALL：117M 参数
• MEDIUM：345M 参数
• LARGE：762 M 参数
• EXTRA LARGE：1542M 参数

对于每一种参数规模的模型，对应的超参数情况，如下图所示：

自注意力层前后都进行层归一化（Layer Normalization）

与 GPT-1 不同，GPT-2 对每个 Encoder Block 的自注意力层，前后分别都进行了层归一化（Layer Normalization）操作，即在每一层的输入和输出都有一个 Layer Normalization 子层，如下图所示：

在输入自注意力层之前新增 Layer Normalization 层，能够将输入数据的均值和方差分别标准化为 0 和 1，使数据在不同的尺度上保持一致。而且，这种策略能够缓解梯度消失和梯度爆炸的问题。同时，层归一化有助于优化器在更新权重时找到合适的方向，提高模型的训练稳定性和收敛速度。

采用 BBPE（Byte-level BPE）分词算法

GPT-2 采用了 BBPE（Byte-level BPE）分词算法，它是 BPE 算法的一种变体，从字符级别扩展到字节（Byte）级别。
BBPE 可以跨语言共用词表，压缩词表的大小，对于同样的训练集，BBPE 模型可能比 BPE 模型的表现更好。然而使用 BBPE 算法使得序列比 BPE 更长，导致训练/推理时间会更长。

采用相对位置编码(Learnable Relative Positional Encoding)

GPT-2 采用了一种可学习的相对位置编码（Learnable Relative Positional Encoding）方法，这种方法不仅考虑了输入数据 token 之间的绝对距离，还关注了它们的相对位置关系，从而能够更好地捕获长程依赖关系，提高模型的性能。

采用掩码自注意力机制

GPT-2 采用了掩码自注意力（Masked Self-Attention）机制，下图对比了自注意力（Self-Attention）与掩码自注意力（Masked Self-Attention）之间的区别：

在预训练阶段，模型训练过程中会学习语言的通用表示，掩码自注意力（Masked Self-Attention）能够保证模型在生成文本时只关注当前位置以及之前位置的上下文，最小化无效部分带来的影响，有助于得到的模型遵循自然语言的生成规律。
在 GPT-2 模型训练中，使用单向语言建模任务来学习文本的上下文信息，这使得 GPT-2 在文本摘要、机器翻译、对话生成等 NLP 任务上表现出色。

零样本学习（Zero-shot Learning）

在 GPT-2 中，多任务学习在无监督预训练阶段学习了大量的自然语言文本，所以 GPT-2 模型的零样本学习能力，可以直接迁移到下游的不同应用领域。下面是 GPT-2 在多任务情况下零样本学习结果表现，如图所示：

GPT-3 模型

GPT-3 模型通过预训练过程训练，得到预训练模型，下游各种应用任务基于该预训练模型，不需要任何的进行梯度更新或模型微调，只需要基于上下文学习（In Context Learning，ICL）来适应不同类型的任务，而且表现非常好，这离不开基础预训练模型的优异性能。
GPT-3 模型，是基于优化的类 Sparse Transformer 解码器架构的超大规模模型，拥有参数量 1750 亿。这种类 Sparse Transformer 模式在 Transformer 的各层中交替使用密集（Dense）和局部带状稀疏（Locally Banded Sparse）注意力模式，大大提高了 GPT-3 处理长序列的计算效率。GPT-3 模型的架构，如下图所示：

训练 GPT-3 模型，使用了 5 个数据集：Common Crawl (filtered)、WebText2、Books1、Books2、Wikipedia（其中未公开 Books1 和 Books2 的数据来源），各个数据集的信息如下图所示：

GPT-3 模型训练了 8 种不同尺寸的模型，训练过程中分别使用的超参数情况，如下图所示：

其中，最大的 GPT-3 模型有 1750 亿参数。

引入稀疏注意力机制

GPT-3 在 Transformer 网络的各层中引入了交替的密集和局部带状稀疏注意力模式，这种方式能够使 GPT-3 更有效地处理长序列，从而减少计算复杂度及内存空间占用，因此提高了模型的可扩展性。
局部带状稀疏（Locally Banded Sparse）注意力的计算过程如下：

1. 设置 Window 大小，确定每个 token 能够关注的上线文范围
2. 基于 Window 大小范围内的 token 创建自注意力矩阵
3. 计算局部带状注意力

使用上下文学习（In Context Learning，ICL）方法

为了避免在微调阶段调整模型参数，GPT-3 模型更加重视基于内容的学习方法：在任务适应阶段，模型采用了零样本（Zero-shot）、单样本（One-shot）和少样本（Few-shot）的学习策略，突破了传统微调方法的限制。与传统微调方法相比，零样本（Zero-shot）、单样本（One-shot）和少样本（Few-shot）的学习策略具有非常明显的优势。
零样本（Zero-shot）学习，是指训练模型在没有接触过任何与目标任务相关的标签数据的情况下，仅凭借在预训练阶段学到的知识来解决问题。使用这种策略，模型需要理解任务描述，并在没有任何样本的情况下完成下游任务。GPT-3 模型在零样本（Zero-shot）学习方面表现优异。
单样本（One-shot）学习，是指在仅给定一个与目标任务相关的示例样本的情况下进行推理。使用这种策略的关键是，让模型从有限的信息中快速学习并适应新任务。GPT-3 模型可以在极少的标签数据情况下快速适应新任务，降低了在特定任务上进行监督学习所花费的时间和训练代价。
少样本（Few-shot）学习，是指训练模型在给定少量与目标任务相关的标签样本示例后进行推理。GPT-3 模型在少样本学习任务上的表现也很好，这是因为 GPT-3 预训练模型已经具有很强的泛化能力，可以在只具有少量标签数据的情况下经过推理得到高质量的结果。
GPT-3 在 LAMBADA 数据集上测试了模型的性能，结果如下表所示：

通过上表可见，GPT-3 模型极大地改进了在 LAMBADA 数据集上的性能，相比于 SOTA 方法。在 StoryCloze 和 HellaSwag 两个数据集也获得了比较可观的性能。

GPT-3.5 模型

从 GPT-3 开始，OpenAI 开始采用部分闭源策略，一些关键的技术细节并未全面公开。
ChatGPT 模型是基于 GPT-3.5 进行构建和改进的，而 InstructGPT 则建立在 GPT-3 之上，它们都通过引入人工反馈机制来对原始模型进行微调和优化。基于 GPT-3 微调得到的模型是 GPT-3.5-Turbo，然后又有了 InstructGPT 模型，它也被称为 GPT-3.5。
GPT-3.5 引入了 GitHub 等代码数据集，以及 StackExchange 等对话论坛和视频字幕数据集。GPT-3.5 模型在训练过程中也使用了大量的数据集，这些数据集的多样性和丰富性保证了模型能够更好地理解和生成各种类型的文本，从而使模型在各种应用场景中都具有较好的表现。
为了降低下游使用预训练模型的成本，提高基于预训练模型更容易适应下游各种类型任务，基础预训练模型的性能非常关键，在数据集方面可能需要从如下几个角度来不断优化：

1. 提高预训练数据的数量与质量
2. 对预训练数据集进行去重处理
3. 提高预训练数据集的多样性

InstructGPT 主要通过微调（fine-tuning）的方式，来更好地对齐人类的意图。为了训练 InstructGPT，OpenAI 训练了 3 个模型（模型参数分别为 1.3B、6B、175B），模型架构与 GPT-3 相同，这三个模型如下所示：

• SFT 模型（Supervised Fine-Tuning）
• RM 模型（Reward Modeling）
• RL 模型（Reinforcement Learning）

InstructGPT 数据集

InstructGPT 使用的数据集概要情况，如下表所示：

SFT 数据集和 RM 数据集，训练集和验证集都使用了 OpenAI API 客户调用获取，以及标注人员手动编写的 Prompt 提示数据，而 PPO 数据集都是使用 OpenAI API 客户调用获取的数据。
另外，InstructGPT 训练也考虑了标注数据的多样性，收集到的训练数据跨多个不同的类别，如下表所示：

上表中包含了 RM 数据集和 SFT 数据集跨多个不同类别，PPO 数据集也是基于类似的要求准备的，分布的类别具有多样性的特点。

InstructGPT 训练过程

上面三个阶段的微调方法和过程，可以通过下图给出的步骤来简要说明：

分别对应于上面提到的三个模型（SFT 模型、RM 模型、RL 模型），InstructGPT 的训练过程主要包括如下三个步骤：
Step 1: Collect demonstration data, and train a supervised policy.
Step 2: Collect comparison data, and train a reward model.
Step 3: Optimize a policy against the reward model using PPO.
下面详细说明各个阶段具体是如何进行训练的：

1. 有监督微调（Supervised Fine-Tuning）

有监督微调使用了 SFT 数据集，该数据集的来源如下：

• 通过 OpenAI 的 API 调用得到 Prompt 提示数据
• 专门的标注人员编写的 Prompt 提示数据

基于上面两种数据来源，最终用于有监督微调的训练数据有 13K 个 Prompt 提示数据条目，其中训练数据中也包括 Prompt 提示对应的答案。
有监督微调阶段，使用了 SFT 数据集对预训练的 GPT-3 模型进行了微调，这个经过微调的模型被称为 SFT 模型，参数为 1750 亿，它是一个具有基本预测能力的 Baseline 模型。
根据论文中描述，有监督微调过程采用了余弦学习率衰减策略，训练了 16 轮，同时为了防止过拟合，设置残差的 Dropout 参数值为 0.2。训练 SFT 模型使用了 13K 个样本，由于训练数据时候可能会导致微调的模型过拟合，而 InstructGPT 并不会直接使用该微调 SFT 模型，而是作为一个 Baseline 模型以支持另外两个模型的训练。

2. 奖励建模（Reward Modeling）

奖励建模阶段使用 RM 数据集，该数据集通过 OpenAI API 获取，以及标注人员编写，共计提供了 33K 个 Prompt 提示数据条目。
在考虑到人类不可能为所有问题编写答案的情况下，训练一个奖励模型用于理解人类的偏好是很有必要的。InstructGPT 基于 GPT-3 微调模型（即 SFT 模型），训练了一个奖励模型，该模型相对较小，具有 60 亿参数，较小的模型能够节省一定的算力资源。
奖励建模（Reward Modeling）的核心思想是，通过人工排序信息将其转化为可优化的奖励分数，并利用这些分数来调整 GPT-3 的模型参数。为了实现这一目标，InstructGPT 采用了一种创新的奖励建模算法，如下图所示：

在使用 RLHF 学习的情况下，排序提供了一种弱监督信号，也就是说是以人类的偏好作为奖励。排序能更好地评估每个答案的质量，从而提高模型的泛化能力，最终奖励模型逐渐学会了按照人类偏好进行打分。

3. 强化学习（Reinforcement Learning）

强化学习训练阶段，使用 PPO 数据集，该数据集只是通过 OpenAI API 获取的 Prompt 提示数据，共计 31K 个，被用于微调 SFT 模型，将标注人员提供的不带标注的提示，输入 SFT 模型，此时不再让人类来反馈，而是直接使用前面训练得到的 RM 模型来对 SFT 模型的推理结果进行评估反馈，从而不断优化模型参数。然后，根据优化后的策略再次生成推理结果，再由 RM 模型进行评估反馈，持续优化 SFT 模型参数，如此循环持续优化策略至最优。
在强化学习过程中采用了 PPO 算法，SFT 模型是前面第一步中 “有监督微调” 中经过微调的 GPT-3 得到的，该 SFT 模型作为 PPO 算法的策略网络。基于 PPO 算法的 InstructGPT 强化学习过程，如下图所示：

对于每个 Prompt 提示，输入到当前的强化学习模型中，生成一个对应的输出 y；接着，将 (x，y) 输入到 RM 模型中，以计算评估其得分。通过优化如下目标函数：

使新训练得到的 RL 模型，能够生成人类认为排序较高的推理结果。

GPT-4 模型

GPT-4 是一个多模态大模型（Large Multimodal Model，LMM），能够处理输入的文本和图片，并生成文本输出，GPT-4 的性能和效果，显示出其卓越的生成和理解能力。由于 OpenAI 并没有公布 GPT-4 的技术细节，只能通过发布的 GPT-4 技术报告来粗略推测。
GPT-4 的核心原理是，基于 Decoder-only 的 Transformer 自回归语言模型，即通过给定的文本序列，预测下一个词的概率分布，从而生成新的文本。GPT-4 采用了大规模的无监督预训练和有监督微调的方法，即先在海量的通用文本语料上进行预训练，学习文本的通用特征和规律，然后在特定的下游任务上进行微调，学习任务的特定知识，从而实现对任意文本的生成和理解。

基本特点

• 规模巨大，参数众多。

GPT-4 拥有超过 1000 亿个参数，是 GPT-3 的 3 倍，是 GPT-2 的 300 倍，是 GPT-1 的 3000 倍。

• 数据丰富，覆盖广泛。

GPT-4 使用了超过 2.5 PB 的数据进行预训练，其中包括了 Common Crawl（1.8PB）、Wikipedia（60TB）、Reddit（40TB）、BooksCorpus（30TB）、Open Images（20TB）、LibriSpeech（10TB）、YouTube（10TB）等多种类型和格式的数据。GPT-4 的数据覆盖了文本、图像、音频、视频等多个领域，涵盖了人类的各种知识和信息，显示出其广泛的适应和理解能力。

• 模型通用，任务多样。

GPT-4 采用了通用语言模型的架构，即不针对特定的任务或领域进行优化，而是通过大规模的预训练，学习文本的通用特征和规律，然后通过少量的微调，适应不同的下游任务和领域。GPT-4 可以处理多种类型和格式的数据，如文本、图像、音频、视频等，也可以处理多种任务，如聊天机器人、搜索引擎、写作助手、教育辅导、娱乐创作、知识问答等，显示出其灵活的生成和理解能力。

• 性能卓越，效果惊艳。

GPT-4 在多个性能基准测试中，都取得了令人瞩目的成绩，超越了人类水平或现有最先进的模型。
例如，在 MMLU（大规模多任务语言理解）测试中，GPT-4 以 95.0% 的成绩超越了人类专家，这一测试综合了数学、物理、历史等 57 个科目；在 UltraMMMU（超大规模多模态语言理解）测试中，GPT-4 以 75.4% 的成绩超越了 GPT-3.5，这一测试综合了文本、图像、音频、视频等多种类型和格式的数据 。

技术方案

Zero-shot 及 Few-shot 学习能力

Zero-shot 以及 Few-shot 学习能力的提升，理论依据最可能是由于 LLM 模型的涌现能力（Emergent Ability）。
涌现能力（Emergent Ability）是指模型在训练过程中，自动地学习到一些高级的、复杂的功能或行为，而这些功能或行为并没有被直接编码或指定。这种能力使模型能够在处理新的、未知的任务时表现更加出色，因为它是通过自适应地学习获得了新的功能或行为，而不需要重新训练或修改模型。
模型产生涌现能力，主要取决于 4 分方面：

• 模型参数量超大。GPT-4 很可能使用一些策略提高了模型的推理速度，所以文本模型参数大概是千亿级别甚至非常接近万亿级别。如果 GPT-4 使用了 CLIP 做图像编码，据 OpenAI 论文公布，目前最大的图像编码器是扩大了 64 倍的残差网络，那么 GPT-4 的图像编码大概有 16 亿。当然也可能采用其它图像编码结构，比如基于 Transformer 的 KOSMOS-1 就是一个不错的选择。
• 模型的架构。GPT-4 大幅提升了对长文本的处理能力，有可能使用了 Transformer-XL 或 Sparse Transformer 架构；GPT-4 更有可能是在 ChatGPT 的基础上迭代而得到的；GPT-4 还可能使用了原生的 Transformer，并增加了更多的层数，head 数量以及隐藏层节点数。GPT-4 支持多模态能力，可能是基于多模态算法 CLIP 实现的图像编码器；另外，微软的 KOSMOS-1 也展示出了和 GPT-4 类似的多模态语言模型能力，GPT-4 有可能借鉴了 KOSMO-1 的思想。
• 高质量的训练数据。
• 先进的训练策略。GPT-4 基本保持了和 ChatGPT 相同的训练策略，遵循了“预训练+提示+预测”的范式，改进包括：引入基于规则的奖励模型（Rule Based Reward Model，RBRM）、引入了多模态的提示学习、引入了思维链（Chain of Thought，COT）。

逻辑推理能力

OpenAI 为了提升 GPT-4 的推理能力，很有可能使用了近年来 LLM 非常重要的思维链（Chain of Thought，COT）以及自提升（Self-Improve）方法。
思维链（Chain of Thought）是指人们在进行思考时，由于某个观点、想法或感知刺激而引发的一系列相关思维关联，这些关联可以通过人们的记忆、经验、知识、情感和意识等方面来建立和加强，最终形成了一个有机的思维链，帮助人们理解和解决问题，做出决策和行动。
LLM 和思维链的结合，可以让模型使用无监督的数据进行自我提升（Self-Improve），计算过程如下图所示：

计算过程描述如下：

1. 基于思维链构建 Prompt 提示；
2. 根据不同的温度系数，模型生成多个不同的包含推理过程的 Path；
3. 使用投票的方式选择最有可能的正确答案；
4. 将包含这个正确答案的所有 Path 用来优化 LLM。

理解图像能力

GPT-4 支持图像格式的图表输入，OpenAI 的多模态算法 CLIP 可以通过对比学习将图像和文本映射到同一特征空间，那么结合 CLIP 的图像编码器便可以实现 GPT-4 的图像输入，训练一个可以和 GPT 的文字特征对齐的图像编码器，然后将 CLIP 的图像编码器的输出作为图像 token，最后再加一个 Embedding 层将这个 token 编码为 GPT-4 的特征向量。

GPT-4 还可以理解包含了很多细节的学术图片。在学术图片中，图中代指的符号，目标之间的位置关系都是十分重要的，如果 GPT-4 仅仅通过一个图像编码就能捕获这些细节信息，那么这个图像编码器一定也展现出了非常强的涌现能力，这个图像编码器也大概率是千亿规模的参数量。

更安全的文本生成能力

GPT-4 的技术报告中指出，文本模型会存在下面几类的风险输出：幻觉、有害内容、歧视、虚假信息、暴力、隐私、网络安全等。GPT-4 聘请了 50 余名来自不同领域专家扮演红队进行对抗测试。红队的工作是提出有危险性的问题，以测试 GPT-4 给出的输出，并尝试攻克它。通过领域专家的对抗，OpenAI 也采集了大量不同方向的领域专家数据来提升 GPT-4 的安全性。
幻觉（Hallicination）是生成模型都非常难以解决的问题，它指的是模型产生的荒谬的或者不真实的内容。GPT-4 采用了两个策略来解决幻觉问题：

• 利用 ChatGPT 的数据进行训练；
• 采用 NLP 技术来检测模型产生的幻觉样本，包括自动评估和人工评估。

对于可能出现的其它风险输出，OpenAI 并没有详细的介绍它的技术方案，不过从他们的技术方案中，我们可以看出他们大概使用了下面几类方法：

• 使用 RBRM（Rule-Based Reward Model）来检测可能出现的风险；
• 通过提示学习让模型学习拒绝回答此类问题；
• 利用红队发现这些可能存在的问题；
• 过滤训练数据，删除可能触发风险问题的样本；
• 训练奖励模型，让模型惩罚有危害的输出内容。

更强的编程能力

GPT-4 在编程能力上比 ChatGPT 有了巨大的提升，一方面可能使用思维链掌握了更强的逻辑分析能力，另一方面有可能借鉴了 OpenAI 著名的代码生成算法 CodeX。CodeX 是 GPT-3 在代码生成领域的衍生版本，也是 Copilot 插件背后的基础算法。CodeX 采用了 GPT 系列 Decoder-only 的 Transformer 架构体系，模型的参数量有从 12M 到 12B 等多个不同的版本。CodeX 的训练分成预训练和微调两个阶段:
在预训练阶段，OpenAI 从 Github 上爬取了大量的 Python 文件，经过清洗后得到了一个大小为 159GB 的训练集;
在微调阶段，OpenAI 从竞赛网站、面试网站、Github 的单元测试脚本中收集了大约 40000 条数据。
CodeX 和 GPT-4 都是 GPT-3 的下一代模型，让 GPT-4 使用 CodeX 现成的思想和数据，并提高模型的编程能力，是非常合理的。

多语言能力

GPT-4 的在其它语种上能力的大幅提升，可能使用的技术方案如下：

• 提升了其它语种的训练数据；
• 更大规模的模型让 GPT-4 在小语种上涌现了更多的能力；
• 加入了针对小语种的任务，例如利用现有平行语料构建基于提示学习的机器翻译任务，使用机器翻译引擎将部分数据翻译成小语种等。

处理更长序列的能力

这里的长序列包含两个方面，一方面是 GPT-4 是支持多轮对话的，另一方面是 GPT-4 支持更长的输入数据，下面讨论它们可能使用的技术：

• 支持多轮对话

GPT-4 支持连续对话，可能使用了 Transformer-XL，Transformer-XL 的重要改进是提出了片段递归的机制。片段递归机制类似于 Transformer 和 RNN 的结合体，它的核心思想是对于一个长度不限的变长数据，在计算的时候也是固定每个片段的长度并计算这个片段的特征，然后在计算下一个片段时将前面片段的特征加到当前片段上，从而让模型可以处理任意长度的特征。

• 支持更长的输入数据

GPT-3 就是使用的普通 Transformer 和 Sparse Transformer 的混合模式，所以 Sparse Transformer 也是非常有可能被 GPT-4 用来处理长输入文本的一个模型。Sparse Transformer 的特点是只关注 Top-k 个贡献最大的特征的状态，它使用稀疏注意力机制替代了 Transformer 的密集注意力。

GPT-4V 模型

GPT-4V 在处理任意交错的多模态输入和其能力的通用性方面，具有前所未有的能力，使 GPT-4V 成为一个强大的多模态通用系统。
另外，GPT-4V 独特的理解输入图像上绘制的视觉标记的能力，可以催生出新的人机交互方法，比如视觉参考提示（Visual Referring Prompting）。

输入模式（Input Modes）

GPT-4V 支持的输入模式包括：

• 作为单模型语言模型的文本输入
• 单个图像-文本对输入
• 使用交错的图像-文本对输入
• 使用多个图像作为输入

工作模式和提示技术

• 遵循文本指令（Following Text Instructions）

GPT-4V 的一个独特优势是其通用性，通过其强大的理解和遵循文本指令的能力实现。指令提供了一种自然的方式来定义和定制任意视觉语言用例所需的输出文本。
在输入端，GPT-4V 可以通过理解详细的指令来执行具有挑战的任务，比如，通过提供中间步骤的指令来更好地解释抽象推理问题。GPT-4V 从指令中学习新任务的能力，在适应各种未见过的应用和任务方面显示出巨大的潜力。

• 视点与视觉参考提示（Visual Pointing and Visual Referring Prompting）

GPT-4V 特别擅长理解和处理直接绘制在图像上的视点。鉴于在图像上绘制的灵活性，这种能力可以作为未来野外人机交互的一种自然方法。
通过探索一种新的提示方法，称为视觉参考提示（Visual Referring Prompting），它是一种人工智能技术，结合了自然语言处理和计算机视觉的能力，以理解和响应用户对特定视觉场景中的对象的描述。在这种技术中，模型需要根据自然语言提示（prompt）来定位和描述图像或视频中的特定对象或区域。Visual Referring Prompting 这种技术在增强现实、虚拟现实、机器人导航、智能助手等领域有广泛的应用潜力。

• 视觉 + 文本提示（Visual + Text Prompting）

视觉参考提示（Visual Referring Prompting）可以与其他图像文本提示顺畅地一起使用，呈现出一种细致的界面，简洁地表示出感兴趣的问题。GPT-4V 的通用性和灵活性使其具备了一种类似人类的多模态指令理解能力，以及适应未见过的任务的前所未有的能力。

• 上下文少样本学习（In-context Few-shot Learning）

GPT-4V 支持上下文少样本学习能力，通过给定几个上下文示例，而无需参数更新，就可以生成期望的推理输出。

目前，与 GPT-4V 相关的资料，更多出自论文《The Dawn of LMMs: Preliminary Explorations with GPT-4V(ision)》，该论文更多的是在探索 GPT-4V 的能力，以及在基于 GPT-4V 的能力能实现哪些可能的场景化应用。
想要更多的推测 GPT-4V 的技术要点和原理，可能更多需要详细了解该模型发布之前的几代模型的能力，尤其是 GPT-4。另外，GPT-4V 在视觉方面相关能力的逐步提升，尤其是人机互动，可能会是一个重要的点。

参考资源

• GPT: Improving Language Understanding by Generative Pre-Training
• Language models are few-shot learners
• The Illustrated GPT-2
• How GPT3 Works – Visualizations and Animations
• Positional encoding, residual connections, padding masks: covering the rest of Transformer components
• GPT-4 Technical Report
• https://openai.com/research/gpt-4
• https://openai.com/blog/gpt-4-api-general-availability
• https://zhuanlan.zhihu.com/p/621328705
• https://zhuanlan.zhihu.com/p/630548590
• https://zhuanlan.zhihu.com/p/680426850
• ChatGPT 原理与架构：大模型的预训练、迁移和中间件编程

新的 Agent 范式

通过上面图示的例子，我们可以看到，要实现一个基于多模态跨现实的 Agent AI 系统，涉及到很多 Agent 之间的集成（Integration）与交互（Interaction）。一个新的可供参考的 Agent 范式（Agent Paradigm）——实现多模态“全才” Agent（Multimodal Generalist Agent）系统，如下图所示：

该范式包含 5 个模块：

• 环境、感知、任务规划、技能观察（Environment, Perception, Task-planning, Skill Observation）
• Agent 学习（Learning）
• Agent 记忆（Memory）
• Agent 行动（Action）
• Agent 认知（Cognition）

Agent 在上图定义的这样一个交互式闭环（Interactive Closed-loop）中，不断学习，提高认知，最后能够做出更优的决策并执行。
用于 Agent 的学习/优化策略和基本机制，可以参考如下技巧：

• 强化学习（Reinforcement Learning，RL）
• 模拟学习（Imitation Learning，IL）
• 上下文学习（In-Context Learning，ICL）
• 时间优化（Temporal Optimization）
• 空间优化（Spatial Optimization）

基于多模态跨现实的 Agent AI 系统，需要集成大量的、不同类型的 Agent，在完成各自任务的同时，它们之间也会通过进行交互来不断学习、共同完成 AI 任务。各种不同类型的 Agent，如下所示：

• Generalist Agents
• Embodied Agents
• Action Agents
• Interactive Agents
• Simulation and Environments Agents
• AR/VR/mixed-reality Agents
• Knowledge Agents
• Logic Agents
• Agents for Emotional Reasoning
• Neuro-Symbolic Agents
• LLMs and VLMs Agent

在开发复杂的多模态 AI Agent 系统时，集成视觉和语言的理解非常关键，包括生成图像标题、可视化问答、视频语言生成、视频理解等等。交互式多模态 Agent 包含 4 个基本核心模块，如下图所示：

这 4 个核心模块及其功能，说明如下：

• 交互服务（Interaction Service）

交互服务，有助于建立一个统一的自动化行动（Automated Actions）、认知和决策平台。

• 音频服务（Audio Service）

音频服务，将音频和语音处理集成到应用程序和服务中。

• 视觉服务（Vision Service）

视觉服务，识别和分析在图像、视频和数字墨水中出现的内容。

• 语言服务（Language Service）

语言服务，从结构化、半结构化文本内容中抽取语义。

Agent AI 应用任务

1、使用 Agent 改善游戏中 NPC 的行为

面向游戏领域的 Agent 应用比较常见，比如游戏中的 NPC（Non-Player Characters）的行为主要由开发者精心制作的预定义脚本决定，所以这些脚本预定义好的行为都是可预测的，完全不能根据游戏中玩家（Player）的操作在动态的游戏环境中产生更高级的变化和行为，这极大地阻碍了动态游戏环境中的沉浸式体验。因此，如果利用 LLM 来引导 NPC 的行为，使其具备自主性和适应性，就能够使互动更加微妙和有趣。
基于 AI 驱动的 NPC 可以从游戏玩家的行为中学习，逐渐适应动态变化的策略，从而提供具有挑战性且更少可预测性的游戏体验。
下面是一个使用 GPT-4V 模型，对游戏 Minecraft Dungeons 进行交互体验改进的 Agent 实现的应用任务：

图中，通过不断地与 GPT-4V 互动反馈，得到一些基于 LLM 驱动的新场景和行为，最后一个生成的图片中 NPC 在战斗后的状态和场景，很难甚至无法通过预定义的脚本来实现。

2、使用 Agent 分析游戏

LLM 可以作为一个强大的语言工具，支持分析游戏中的文本数据，包括聊天日志、玩家反馈，以及叙述内容。
VLM 可以用来解析玩家游戏过程中，交互得到的大量图像、视频数据，以帮助分析游戏世界中的用户意图和动作。

3、游戏场景合成

场景合成在创建和增强沉浸式游戏环境的过程中，具有非常重要的作用。场景合成包括游戏中 3D 场景和环境的自动生成，或者半自动生成，比如地形的生成、对象的放置、逼真照明的创建，有时甚至还包括动态的天气系统。
另外，现代游戏制作通常以广阔、开放的世界环境为主要特色，而人工设计这些景观可能耗费大量时间和资源。通过使用场景合成能力，自动生成地形，同时利用程序或 AI 驱动的技术，使用较少的手动操作就可以生成复杂、逼真的景观/场景。
LLM 和 VLM 能够利用丰富的知识来设置各种规则，使输出的设计在视觉上更加新颖独特，而不像使用传统方式得到的更多是一些千篇一律、平淡无奇的创意。
例如，下图是基于 Minecraft Dungeons 游戏视频，使用了 VLM 模型预测生成的图像：

上图中，通过屏蔽掉视频中画面的一些部分，使用 GPT-4V 预测生成的结果，可以对比一下原始图像和预测生成图像之间不同。

4、机器人

机器人（Robotics）是通过与环境不断地进行交互、获得反馈，持续学习改进性能，以完成人类期望它完成的任务。

• 视觉运动控制（Visual Motor Control）

视觉运动控制（Visual Motor Control）是指，将视觉感知和运动动作相结合，使机器人能够更有效地执行任务。这种集成至关重要，因为它使机器人能够理解来自其环境的视觉数据，并相应地调整其动作以与环境精确地互动。视觉运动控制，有助于机器人适应环境状态快速变化的动态环境，能够基于视觉反馈对运动动作进行实时调整。
在安全操作的背景下，视觉信息对于检测执行错误、确认每个机器人动作序列先后关系，显得至关重要。在不受控的环境中，比如机器人对室内环境比较陌生，由于家具形状的变化、照明的变化等不可预测的因素，它们的行为可能会面临意想不到的结果。所以，利用视觉反馈不断验证每一步的结果，能够确保机器人系统稳健可靠地运行。

• 语言条件操纵（Language Conditioned Manipulation）

语言条件操纵，需要机器人系统具有基于语言指令解释和执行任务的能力，通常有必要为人机交互提供一个直观和用户友好的界面，通过自然语言命令，用户可以以类似于人类交流的方式向机器人指定目标和任务，降低操作机器人系统的难度。

• 技能优化（Skill Optimization）

最近的研究强调了 LLM 在机器人任务规划中的有效性。然而为了使任务更好地执行，尤其是那些涉及抓取等物理交互的任务，需要让机器人对环境有更深入的了解，而不仅仅是简单地解释人类指令。
对于机器人精确的接触点、手臂姿势等，这些对人类来说是直观的，但想要通过语言表达却非常困难，有一定的挑战性。因此，让机器人从场景中捕捉这些细微的间接线索，并将其有效转化为机器人的技能仍然是一个重大的挑战。机器人界也越来越专注于收集经过增强的数据集，或开发从人类的演示中直接获得技能的方法，包括示范学习、模仿学习，这对优化机器人的技能非常有帮助。

最近的研究已经证明，LLM/VLM 在特定环境中与人类交互学习过程中，机器人 Agent 表现出了巨大的潜力。一些和 LLM/VLM 有关的话题有：

• 多模态系统（Multimodal Systems）
• 任务规划和技能训练（Task Planning and Skill Training）
• 在线优化（On-site Optimization）
• 对话 Agent（Conversation Agents）
• 导航 Agent（Navigation Agents）

5、医疗保健（Healthcare）

在医疗保健领域，LLM 和 VLM 可以充当诊断试剂、患者护理助理，甚至治疗辅助工具。虽然 AI 试剂在改善患者护理和挽救生命方面有巨大的潜力，但也存在可能的巨大风险，即滥用或仓促部署 AI 试剂可能危及全球千百万病人。

参考资源

• Agent AI: Surveying the Horizons of Multimodal Interaction

HuggingGPT 设计概览

HuggingGPT 的总体处理流程，如下图所示：

通过上图可以看到，HuggingGPT 的处理过程可以分为如下 4 个阶段：

• 任务规划（Task Planning）

使用一个 LLM（ChatGPT）分析用户的请求，了解用户的意图。通过用户输入到 LLM（ChatGPT）的 Prompt，根据对话结果将用户任务分解为可执行的多个任务。

• 模型选择（Model Selection）

为了解决计划任务，LLM（ChatGPT）通过一定的策略，选择托管在 Hugging Face 网站上的某个领域的专家模型，来执行某个特定的任务。

• 任务执行（Task Execution）

调用并执行选择的某个专家模型，执行任务并将结果返回给 LLM（ChatGPT）。

• 响应生成（Response Generation）

最后，利用 LLM（ChatGPT）集成来自所有专家模型的推理结果，并统一为用户生成响应内容。

HuggingGPT 的上述 4 个阶段，更详细的处理过程，可以参考下图：

任务规划

LLM（ChatGPT） 接受用户的请求，将其分解为一系列结构化的任务。复杂的请求通常涉及多个任务，LLM 需要确定这些任务的依赖关系和执行顺序。为了使 LLM 进行有效的任务规划，HuggingGPT 在 Prompt 提示设计中采用了基于规范化指令（Specification-based Instruction）和基于演示的解析（Demonstration-based Parsing）。
基于规范的指令任务规范为任务提供了统一的模板，允许大型语言模型通过槽位归档进行任务解析。HuggingGPT 为任务解析设计了 4 个字段，分别是任务类型、任务编号、任务依赖、任务参数，各个字段分别说明如下：

• 任务类型：使用 “task” 字段表示，任务类型涵盖语言、视觉、视频、音频等不同任务。
• 任务编号：使用 “id” 字段表示，任务编号为任务规划提供了一个唯一的标识符，用于引用相关任务及其生成的资源。
• 任务依赖：使用 “dep” 字段表示，任务依赖定义了执行所需的先决条件任务。只有在完成所有先决条件相关任务后，才会启动该任务。
• 任务参数：使用 “args” 字段表示，任务参数包含执行任务所需的参数列表。它包含 3 个子字段，根据任务类型填充文本、图像和音频资源，它们是从用户的请求或相关任务的生成资源中解析的。

任务规划阶段，生成的规范化指令模板，示例如下图所示：

生成的任务列表描述格式为：

[{
	"task": task,
	"id",
	task_id,
	"dep": dependency_task_ids,
	"args": {
		"text": text,
		"image": URL,
		"audio": URL,
		"video": URL
	}
}]

可以在上图中看到，演示部分（Demonstrations）给出了 3 个具体的任务的实例描述，使用 JSON 格式，如下所示：

• 图片 e1.jpg 中有几个实体

[{
	"task": "object-detection",
	"id": 0,
	"dep": [-1],
	"args": {
		"im age": "e1.jpg"
	}
}]

• 图片 e2.jpg 中是什么动物，以及它们在做什么

[{
	"task": "image-to-text",
	"id": 0,
	"dep": [-1],
	"args": {
		"im age": "e2.jpg"
	}
}, {
	"task": "image-cls",
	"id": 1,
	"dep": [-1],
	"args": {
		"image": "e2.jpg"
	}
}, {
	"task": "object-detection",
	"id": 2,
	"dep": [-1],
	"args": {
		"image": "e2.jpg"
	}
}, {
	"task": "vi- sual-quesrion-answering",
	"id": 3,
	"dep": [-1],
	"args": {
		"text": "what’s the animal doing?",
		"image": "e2.jpg"
	}
}]

• 先生成图片 e3.jpg，基于该图片生成文本 “a girl reading a book”，并以一个新图片的形式做应答

[{
	"task": "pose-detection",
	"id": 0,
	"dep": [-1],
	"args": {
		"im age": "e3.jpg"
	}
}, {
	"task": "pose-text-to-image",
	"id": 1,
	"dep": [0],
	"args": {
		"text": "a girl reading a book",
		"image": "<re- source>-0"
	}
}]

模型选择

在 HuggingFace Hub 上托管的 LLM 模型（专家模型）具有全面的模型描述，这些描述通常由开发人员提供。这些描述的内容包含：模型功能、体系结构、支持的语言和域、许可等，它们能够有效地支持 HuggingGPT 根据用户请求和模型描述的相关性为任务选择正确的模型。
在解析任务列表并完成任务规划后，接下来 HuggingGPT 就需要匹配任务和 LLM 模型（专家模型），即为任务列表中的每个任务选择合适的 LLM 模型（专家模型）。为了获取 LLM 模型，首先需要从 HuggingFace Hub 上获得专家模型的描述信息，然后通过上下文中的任务模型分配机制为任务动态选择模型。具体来说，需要根据模型的任务类型筛选模型，只保留与当前任务类型匹配的模型，对剩下的模型需要根据下载量排序，并选择 top-K 个模型作为 HuggingGPT 可以选择的候选模型集合。
模型选择阶段，生成的规范化指令模板，示例如下图所示：

HuggingGPT 选择后输出的格式必须是严格的 JSON 格式，格式如下所示：

{
	"id": "id",
	"reason": "your detail reason for the choice"
}

最终生成的专家模型候选集合，包含 top-K 个模型，以列表形式显示如下：

{
	"model_id": model id #1, "metadata": meta-info # 1,
	"description": description of model #1} {"model_id": model id # 2,
	"metadata": meta - info #2, "description": description of model # 2
}
·········
{
	"model_id": model id# K,
	"metadata": meta - info# K,
	"description": description of model# K
}

任务执行

任务被分配给最合适的模型以后，接着就需要使用选定的专家模型，来对任务进行推理以执行任务。具体地，HuggingGPT 会把任务的参数输入给选定的专家模型，执行这些模型来获取推理结果，然后发送回 LLM。由于任务在与专家模型交互过程中，专家模型动态输出结果，所以 HuggingGPT 必须在任务开始执行就计划好，动态地在需要的时候提供任务所需的特定资源，以完成任务的推理执行。
理想情况下，我们只使用 HuggingFace 上的远端服务提供的推理端点（Inference Endpoints）就能完成任务执行。但现实情况并不总是这样，比如某个任务需要使用的专家模型并不存在，这样就不得不在本地部署了推理端点，是任务正常执行。所以，为了加快任务处理速度并保证计算的稳定性，HuggingGPT 会在混合推理端点上运行这些模型。通过将任务参数作为输入，模型计算推理结果，然后将其发送回 LLM。

响应生成

经过任务执行节点，在所有任务执行完成后，HuggingGPT 进入响应生成阶段。HuggingGPT 将前面三个阶段（任务规划、模型选择、任务执行）的所有信息集成在一起，包括计划任务列表、为任务选择的模型以及模型的推理结果，还有推理的结果，HuggingGPT 会依赖推理结果做出最终决策的支持。这些推理结果以结构化格式呈现，例如，对象检测模型中具有检测概率的边界框、问答模型中的答案分布等，HuggingGPT 允许 LLM 接收这些推理结果作为输入，并将具有一定置信度的响应结果进行汇总，返回给最终的用户。
下面是在响应生成阶段，生成的规范化指令模板，示例如下图所示：

收集到前三个阶段的信息，格式模板如下：

• 用户输入（User Input）： {{ User Input }}
• 任务规划（Task Planning）：{{ Tasks }}
• 模型选择（Model Selection）{{ Model Assignment }}
• 任务执行（Task Execution）{{ Predictions }}

上面可注入的 Slot（injectable slots），及双花括号内部的标识，会被替换成最终的文本内容，然后输入给 LLM，汇总得到用户需要的最终答案。

HuggingGPT 局限

虽然 HuggingGPT 提出了 AI 解决方案的新范式，但仍然存在一些限制，如下所示：

• 任务规划严重依赖 LLM 的能力

大模型并不能 100% 确保生成的计划始终是可行且最优的，因此，探索优化 LLM 的方法至关重要，进而提升规任务划能力。

• 效率

效率的瓶颈主要在使用大型语言模型的推理上。对于每一轮用户请求，HuggingGPT 都需要在任务规划、模型选择和响应生成阶段至少与大型语言模型进行一次交互，大大增加了响应延迟，并导致用户体验下降。

• 最大上下文长度的限制

受 LLM 可以接受的最大 token 数量的限制，HuggingGPT 面临着最大上下文长度的限制。通过使用会话窗口，在任务规划阶段只跟踪了会话上下文，这样做在一定程度上能够缓解这个问题。

• 系统稳定性

包括两个方面：一是在大型语言模型的推理过程中通常是不可控的。LLM 在推理时偶尔会不符合指令，并且输出格式可能会超出预期，从而导致程序工作流中出现异常；二是 HuggingFace 的推理端点上托管的专家模型的状态不可控。HuggingFace 上的专家模型可能会受到网络延迟或服务状态的影响，导致任务执行阶段出现错误。

HuggingGPT 是一个 AI 智能体的实现，这个系统来解决 AI 任务。它以语言为接口将 LLM 与 AI 模型（专家模型）连接起来，所以，LLM 可以被视为管理 AI 模型的控制器，并且可以利用来自 ML 社区（如 Hugging Face）的模型来自动解决用户的不同需求。
通过利用 LLM 在理解和推理方面的优势，HuggingGPT 可以分析用户的意图，并据此将其分解为多个子任务；然后，基于 Hugging Face 上专家模型的描述，HuggingGPT 能够为每个任务选择并分配最合适的模型，最后集成不同模型的推理结果，以生成最终响应结果内容。通过利用来自 ML 社区的众多 AI 模型的能力，HuggingGPT 在解决具有挑战性的 AI 任务方面展示了巨大的潜力，同时也为实现 AGI 做了一次有意义的探索。

参考资源

• HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face
• https://github.com/microsoft/JARVIS

• Query：在自主提示下，自主提示的内容，对应着矩阵 Q
• Keys：在非自主提示下，进入视觉系统的线索，对应着矩阵 K
• Values：使用 Query 从 Keys 中匹配得到的线索，基于这些线索得到的进入视觉系统中焦点内容，对应着矩阵 V

我们要训练的模型，输入的句子有 n 个 token，而通过选择并使用某个 Embedding 模型获取到每个 token 的 Word Embedding，每个 Word Embedding 是一个 d 维向量。本文我们详细说明自注意力（Self-Attention）的计算过程，在进行解释说明之前，先定义一些标识符号以方便后面阐述使用：

• X：输入训练数据的 Embedding 是一个 n x d 矩阵
• Q：查询矩阵，矩阵形状 n x dq
• K：键矩阵，矩阵形状 n x dk，其中 dk=dq
• V：值矩阵，矩阵形状 n x dv

计算自注意力（Self-Attention）的基本流程，如下图所示：

计算过程及其示例演示，描述如下：

1. 计算生成 Embedding 矩阵

X 是基于输入数据得到的 n x d 的 Embedding 矩阵：通过选择并使用某个 Embedding 模型，输入数据经过分词得到 n 个 token，再获取到每个 token 的 Embedding 向量，然后将这 n 个 Embedding 向量拼接成一个 n x d 的 Embedding 矩阵。
假设我们输入的是一个句子：

Life is short, less is more.

比如，要训练模型以便下游执行机器翻译任务，上面句子对应的 Embedding 是一个 6 x 16 的 Tensor，即 n=6，d=16，如下所示：

tensor([[ 0.3374, -0.1778, -0.3035, -0.5880,  0.3486,  0.6603, -0.2196, -0.3792,
          0.7671, -1.1925,  0.6984, -1.4097,  0.1794,  1.8951,  0.4954,  0.2692],
        [-1.3250,  0.1784, -2.1338,  1.0524, -0.3885, -0.9343, -0.4991, -1.0867,
          0.8805,  1.5542,  0.6266, -0.1755,  0.0983, -0.0935,  0.2662, -0.5850],
        [ 0.2553, -0.5496,  1.0042,  0.8272, -0.3948,  0.4892, -0.2168, -1.7472,
         -1.6025, -1.0764,  0.9031, -0.7218, -0.5951, -0.7112,  0.6230, -1.3729],
        [ 0.8768,  1.6221, -1.4779,  1.1331, -1.2203,  1.3139,  1.0533,  0.1388,
          2.2473, -0.8036, -0.2808,  0.7697, -0.6596, -0.7979,  0.1838,  0.2293],
        [-1.3250,  0.1784, -2.1338,  1.0524, -0.3885, -0.9343, -0.4991, -1.0867,
          0.8805,  1.5542,  0.6266, -0.1755,  0.0983, -0.0935,  0.2662, -0.5850],
        [ 0.5146,  0.9938, -0.2587, -1.0826, -0.0444,  1.6236, -2.3229,  1.0878,
          0.6716,  0.6933, -0.9487, -0.0765, -0.1526,  0.1167,  0.4403, -1.4465]])
torch.Size([6, 16])

2. 计算生成 Q、K、V 矩阵

定义 3 个矩阵 Wq、Wk、Wv 它们是权重矩阵，输入 X 与这 3 个矩阵的转置分别相乘，得到 Q、K、V。其中，Q 是 n x dq 矩阵，K 是 n x dk 矩阵，V 是 n x dv 矩阵。计算的公式如下所示（().T 表示对矩阵的转置操作）：

• Q = X · (Wq).T
• K = X · (Wk).T
• V = X · (Wv).T

Wq、Wk、Wv 是三个参数矩阵，通过在模型进行训练的过程中，经过学习会得到这 3 个矩阵对应的参数值。
在模型训练过程中，参数矩阵可以采用随机策略生成，这里我们随机生成 Wq（8 x 16 矩阵）、Wk（8 x 16 矩阵）、Wv（12 x 16 矩阵），使用 PyTorch 生成：

Wq = torch.rand(8, 16)
print(Wq.T)
print(Wq.T.shape)

Wk = torch.rand(8, 16)
print(Wk.T)
print(Wk.T.shape)

Wv = torch.rand(12, 16)
print(Wv.T)
print(Wv.T.shape)

从而可以分别得到这 3 个矩阵的转置的结果，如下所示：

tensor([[0.9882, 0.7577, 0.6397, 0.5757, 0.6042, 0.0206, 0.6886, 0.4270],
        [0.8363, 0.4536, 0.8954, 0.2785, 0.9836, 0.3247, 0.9024, 0.8210],
        [0.9010, 0.4130, 0.2979, 0.1946, 0.1444, 0.9355, 0.1123, 0.3605],
        [0.3950, 0.5585, 0.6314, 0.5382, 0.9010, 0.5855, 0.2685, 0.4516],
        [0.8809, 0.1170, 0.5028, 0.1291, 0.9221, 0.4695, 0.6591, 0.7056],
        [0.1084, 0.5578, 0.1239, 0.1242, 0.9043, 0.5201, 0.1735, 0.1853],
        [0.5432, 0.6681, 0.3786, 0.1746, 0.5713, 0.8118, 0.9247, 0.6339],
        [0.2185, 0.9275, 0.1661, 0.3302, 0.9546, 0.0585, 0.6166, 0.3894],
        [0.3834, 0.3443, 0.7211, 0.5370, 0.8339, 0.1142, 0.3608, 0.7398],
        [0.3720, 0.6800, 0.5449, 0.8443, 0.8730, 0.3338, 0.5325, 0.2288],
        [0.5374, 0.9998, 0.5490, 0.6937, 0.4675, 0.2122, 0.6559, 0.5185],
        [0.9551, 0.2855, 0.3483, 0.8831, 0.1163, 0.7579, 0.3232, 0.5489],
        [0.7475, 0.9753, 0.5024, 0.1861, 0.4938, 0.8533, 0.1126, 0.0977],
        [0.4979, 0.2518, 0.3445, 0.5422, 0.5938, 0.0149, 0.5034, 0.1364],
        [0.8549, 0.7204, 0.6437, 0.0556, 0.1594, 0.0757, 0.5091, 0.6918],
        [0.2438, 0.6959, 0.9856, 0.7868, 0.2132, 0.0131, 0.5101, 0.3545]])
torch.Size([16, 8])
tensor([[0.7969, 0.7674, 0.5840, 0.6569, 0.0975, 0.3534, 0.1829, 0.1836],
        [0.0061, 0.4058, 0.1227, 0.3704, 0.2956, 0.6638, 0.2956, 0.2010],
        [0.2528, 0.1548, 0.9587, 0.3630, 0.9027, 0.4563, 0.8646, 0.9603],
        [0.0882, 0.5201, 0.9914, 0.0578, 0.3112, 0.1091, 0.8010, 0.6861],
        [0.6997, 0.8773, 0.1547, 0.3629, 0.9167, 0.3069, 0.8044, 0.4209],
        [0.4855, 0.9577, 0.5185, 0.2974, 0.4139, 0.7274, 0.0733, 0.8046],
        [0.4067, 0.1226, 0.2337, 0.2275, 0.4362, 0.5164, 0.7355, 0.2621],
        [0.4168, 0.2742, 0.9794, 0.0484, 0.6996, 0.6845, 0.6248, 0.0638],
        [0.1092, 0.8893, 0.7788, 0.8916, 0.4265, 0.2073, 0.1638, 0.0036],
        [0.6418, 0.7444, 0.7945, 0.0532, 0.4958, 0.9727, 0.5158, 0.7032],
        [0.5125, 0.8095, 0.6613, 0.9964, 0.8463, 0.2913, 0.6000, 0.3051],
        [0.1549, 0.2511, 0.4502, 0.2377, 0.6671, 0.6066, 0.2299, 0.8070],
        [0.6881, 0.9308, 0.7815, 0.4616, 0.4801, 0.2557, 0.2890, 0.9271],
        [0.4900, 0.0890, 0.5085, 0.9079, 0.6904, 0.2588, 0.9078, 0.6647],
        [0.0164, 0.4759, 0.3176, 0.6650, 0.9355, 0.7239, 0.4596, 0.9296],
        [0.7690, 0.5104, 0.7582, 0.3573, 0.6260, 0.3604, 0.4947, 0.3848]])
torch.Size([16, 8])
tensor([[0.9357, 0.8048, 0.0204, 0.9148, 0.2590, 0.4970, 0.1098, 0.9920, 0.4196,
         0.5242, 0.5921, 0.8188],
        [0.2616, 0.0649, 0.8290, 0.1705, 0.7162, 0.3552, 0.6353, 0.4791, 0.0050,
         0.5153, 0.0056, 0.5773],
        [0.4344, 0.8322, 0.1063, 0.0943, 0.5689, 0.2576, 0.3719, 0.7945, 0.1368,
         0.5047, 0.5577, 0.7870],
        [0.8323, 0.3672, 0.2062, 0.8800, 0.8181, 0.7346, 0.0574, 0.9323, 0.8588,
         0.7175, 0.3350, 0.8855],
        [0.2410, 0.9012, 0.5058, 0.2614, 0.8286, 0.4564, 0.6951, 0.1144, 0.0121,
         0.3116, 0.4620, 0.9941],
        [0.8815, 0.8146, 0.6522, 0.5325, 0.5292, 0.4009, 0.6766, 0.8039, 0.2541,
         0.5315, 0.7872, 0.3705],
        [0.6226, 0.2077, 0.7905, 0.9981, 0.7914, 0.8474, 0.5674, 0.0651, 0.0475,
         0.5021, 0.3279, 0.5148],
        [0.4902, 0.4474, 0.4298, 0.3005, 0.1387, 0.1203, 0.8267, 0.3650, 0.7690,
         0.7111, 0.1213, 0.2103],
        [0.9279, 0.5746, 0.2427, 0.9657, 0.0221, 0.8265, 0.2993, 0.2984, 0.8418,
         0.1939, 0.5302, 0.9562],
        [0.8751, 0.6429, 0.4570, 0.8973, 0.0927, 0.9441, 0.9564, 0.0324, 0.5438,
         0.1091, 0.3608, 0.6591],
        [0.2943, 0.0369, 0.6638, 0.8862, 0.7759, 0.1928, 0.1189, 0.0290, 0.2486,
         0.0931, 0.2668, 0.4172],
        [0.5485, 0.5224, 0.2187, 0.6483, 0.9598, 0.0263, 0.9508, 0.0179, 0.3788,
         0.7101, 0.3473, 0.6253],
        [0.5583, 0.7605, 0.0657, 0.2746, 0.3617, 0.5696, 0.8715, 0.1132, 0.5291,
         0.8978, 0.2165, 0.9961],
        [0.9096, 0.7823, 0.7387, 0.8148, 0.7766, 0.1197, 0.0552, 0.2206, 0.7095,
         0.9959, 0.9389, 0.7036],
        [0.7810, 0.7459, 0.1691, 0.1575, 0.1427, 0.7091, 0.4556, 0.3352, 0.5086,
         0.6785, 0.5344, 0.7429],
        [0.9049, 0.5791, 0.2186, 0.2087, 0.4906, 0.1012, 0.2310, 0.7797, 0.2669,
         0.3981, 0.2346, 0.9616]])
torch.Size([16, 12])

接着，分别计算 Q、K、V 这三个矩阵，代码如下所示：

Q = X.matmul(Wq.T)
print(Q)
print(Q.shape)

K = X.matmul(Wk.T)
print(K)
print(K.shape)

V = X.matmul(Wv.T)
print(V)
print(V.shape)

计算得到 Q、K、V 三个矩阵的结果，如下所示：

tensor([[ 0.3018,  0.5771,  0.8287, -0.3224,  0.9979, -1.3807,  0.7953,  0.3018],
        [-2.4223, -1.3309,  0.0371,  0.4128, -0.2362, -1.7722, -0.9576, -0.6908],
        [-1.5899, -2.5706, -3.0113, -3.2927, -4.0568, -0.3453, -3.0388, -2.1831],
        [ 1.4786,  2.4595,  3.2942,  2.1628,  4.1394,  0.7536,  2.8714,  3.5802],
        [-2.4223, -1.3309,  0.0371,  0.4128, -0.2362, -1.7722, -0.9576, -0.6908],
        [-0.3082, -0.5900, -0.9257, -0.7688,  1.8828, -1.6065, -0.8011, -0.4114]])
torch.Size([6, 8])
tensor([[ 1.1813,  1.3559,  0.2174,  3.4764,  1.1683, -0.6475,  0.9448,  0.1573],
        [-1.9191, -0.0077, -1.5536, -0.7241, -1.9709, -1.2558, -1.5606, -1.4531],
        [-2.6464, -2.5228, -3.2055, -1.5096, -2.4377, -2.7335, -1.7701, -0.5160],
        [-0.2554,  2.9326,  1.8757,  1.9398, -0.1509,  1.9660, -0.5092, -0.2307],
        [-1.9191, -0.0077, -1.5536, -0.7241, -1.9709, -1.2558, -1.5606, -1.4531],
        [-0.6116,  1.3902, -0.1460,  0.0244, -0.5577,  1.5972, -2.2190, -0.0214]])
torch.Size([6, 8])
tensor([[ 1.5465,  1.5362,  1.3274,  0.9452,  0.5531,  0.1000, -1.5909,  0.8779,
          0.8645,  1.1643,  2.2148,  1.3088],
        [-1.0912, -2.8470, -0.4005,  0.6766, -1.7351,  1.0082, -1.1248, -3.2161,
          0.5959, -2.3485, -1.7592, -1.2618],
        [-3.7293, -2.7705, -2.1744, -2.7340, -1.0410, -1.8867, -4.0902, -0.3303,
         -3.1343, -2.4864, -1.1285, -3.5427],
        [ 4.1125,  0.5593,  2.1795,  4.3551,  1.7887,  3.0898,  1.5155,  3.2049,
          2.5387,  2.0061,  1.2701,  2.4616],
        [-1.0912, -2.8470, -0.4005,  0.6766, -1.7351,  1.0082, -1.1248, -3.2161,
          0.5959, -2.3485, -1.7592, -1.2618],
        [ 0.2002,  1.3752, -0.0809, -1.2746, -2.3948, -0.3425,  1.5967,  0.5399,
          0.9113,  0.0962,  0.7300, -1.0553]])
torch.Size([6, 12])

3. 计算注意力分数矩阵

上一步已经得到 Q、K，其中 Q 是 n x dq 矩阵，K 是 n x dk 矩阵，这里 dq = dk。
注意力分数矩阵（Attention Score Matrix）的计算，直接使用 Q 与 K 的转置相乘，得到的结果是一个 n x n 矩阵 Q(K).T。
使用 PyTorch 计算 Q·(K).T，代码如下：

QKT = Q.matmul(K.T)
print(QKT)
print(QKT.shape)

计算结果，如下所示：

tensor([[  3.0568,  -3.5501,  -4.6460,  -0.7954,  -3.5501,  -4.0441],
        [ -3.3648,   9.4917,  16.4977,  -5.2158,   9.4917,  -0.9232],
        [-25.1955,  26.4776,  42.6549, -17.1836,  26.4776,   6.2588],
        [ 20.9407, -28.3288, -43.0230,  15.7782, -28.3288,  -5.4665],
        [ -3.3648,   9.4917,  16.4977,  -5.2158,   9.4917,  -0.9232],
        [ -1.6198,   2.7452,   7.8636,  -7.8188,   2.7452,  -2.3448]])
torch.Size([6, 6])

4. 标准化注意力分数矩阵，并与 V 相乘得到自注意力结果

针对矩阵 QKT 进行标准化 Softmax 操作，得到归一化的结果矩阵 A，A 的大小为 n x n。
最后，n x dv 的矩阵 V，乘以 n x n 的矩阵 A，得到了最后的自注意力结果矩阵 Z。
计算 Z = AT(Q, K, V) 的计算公式如下图所示：

前面计算已经得到 QKT 矩阵，n=6，dk=8，则 A 的大小也是 6 x 6。

dk = 16
A = F.softmax(QKT/(dk**0.50), dim=0)
print(A)

然后再乘以矩阵 V：

Z = A.matmul(V)
print(Z)
print(Z.shape)

结果示例如下所示：

tensor([[-2.9351e-02,  6.1129e-02,  5.4583e-02,  9.4816e-02,  4.9514e-02,
          1.2487e-01,  2.9251e-02,  6.3045e-03, -2.7838e-02,  2.7134e-02,
          1.2357e-01,  4.0422e-02],
        [-2.4056e-01,  3.3915e-02,  1.9047e-03,  1.1973e-01, -1.5679e-02,
          1.4004e-01, -9.8062e-02, -8.4042e-02, -1.5060e-01, -1.1663e-02,
          1.6010e-01, -2.3983e-02],
        [-7.0469e+00, -5.9786e+00, -6.3531e+00, -3.7648e+00, -1.4788e+00,
         -5.4479e+00, -6.4546e+00, -6.2927e+00, -2.4734e+00, -3.2765e+00,
         -5.1672e+00, -6.0859e+00],
        [ 3.8240e+00,  1.7311e+00,  2.8731e+00,  2.2339e+00,  4.9503e+00,
          2.7620e+00,  3.9712e+00,  1.2559e+00,  3.1700e+00,  1.4015e+00,
          1.8649e+00,  2.7100e+00],
        [-2.4056e-01,  3.3915e-02,  1.9047e-03,  1.1973e-01, -1.5679e-02,
          1.4004e-01, -9.8062e-02, -8.4042e-02, -1.5060e-01, -1.1663e-02,
          1.6010e-01, -2.3983e-02],
        [-1.2892e-01,  4.9015e-02,  2.3402e-02,  9.5212e-02, -1.8994e-02,
          1.2503e-01, -3.3910e-02, -1.9795e-02, -1.0338e-01,  1.0985e-02,
          1.5254e-01,  6.4172e-03]])
torch.Size([6, 12])

或者，我们可以直接使用 PyTorch 的 torch.nn.functional.scaled_dot_product_attention() 函数，从 Q、K、V 一步就可以计算得到，如下所示：

import torch.nn.functional as F

Z = F.scaled_dot_product_attention(Q, K, V)
print(Z)
print(Z.shape)

参考资源

• Understanding and Coding the Self-Attention Mechanism of Large Language Models From Scratch
• https://pytorch.org/docs/stable/generated/torch.nn.functional.scaled_dot_product_attention.html

注意力（Attention）框架

19 世纪 90 年代，美国心理学家威廉·詹姆斯（William James）提出了视觉注意力的工作原理类似于聚光灯，他认为：我们在日常中会聚焦一些事物，在这个焦点上可以清楚地看到一些物体；而在这个焦点周围的区域（称为边缘）仍然可见其他一些物体但不是很清楚。基于这个注意力的原理，后来提出了双组件（two‐component）的框架，其中两个非常重要的概念就是：非自主性提示和自主性提示，通过这两种方式都能够引导我们注意力关注焦点的改变。

• 非自主性提示

我们在所处环境中，时刻都能不由自主地目及一些事物，还有另外一些事物，这时进入视觉系统的物体如果有特别突出的特征，我们就会将注意力的焦点放在其上面，如下图所示：

上面指定了 5 个物品：一份报纸、一篇论文、一杯咖啡、一个笔记本、一本书，其中装有红色咖啡的杯子的特征最突出，我们不自主地看向这些物品时会把注意力焦点放到咖啡杯上面，通过默认的提示选择了所关注的物品，它应该并不受我们意识控制，这就是非自主提示。

• 自主性提示

自主提示，就是我们有意识地将注意力改变，选择聚集到一个并非是由于特征突出才关注的物体上。当我们可以将注意力焦点改变时，比如从上图显眼突出的红色咖啡杯，将注意力集中到最下面的一本书上，这时相当于强制给了大脑一个暗示，要将注意力焦点转移到一本书上，如下图所示：

使用神经网络来设计注意力机制的框架，就是基于上述非自主性提示和自主性提示的原理，来选择要聚焦的观察对象。具体抽象出来的元素就是最基本的 Key、Query、Value，如下所示：

• Keys（键）：在非自主提示下，进入视觉系统的的所有元素的线索，称为 Keys。
• Query（查询）：在自主提示下，自主提示的内容或元素的线索，称为 Query。
• Values（值)：在由自主提示 Query 限制或者强制下改变注意力的焦点，也就是经过从 Keys 中进行匹配 Query，所得到的进入视觉系统的内容，称为 Values。

注意力机制的框架，可以用下图来表示：

上图表达了：
在注意力机制中，Key 和 Value 是成对的，而 Query 及其查询的结果是前面所有 Keys/Values 对的一个子集。
通过注意力汇聚（Attention Pooling）将 Query（自主性提示）和 Keys（非自主性提示）结合在一起，实现对 Values（感官输入）的选择。

注意力汇聚（Attention Pooling）

通过上面说明注意力的框架，接下来要理解注意力是如何进行汇聚（Pooling）的，即通过什么样的过程使我们的视觉系统聚焦到了最后的物体上（如上面部分：将没有特别突出特征的一本书作为焦点）。从直观感觉上来说，貌似应该是 Query 与 Keys 越接近的话，注意力越集中，也就是说权重越大。
使用 Nadaraya–Watson 核回归模型，能够非常清楚地解释注意力机制。Nadaraya 和 Watson 提出，根据输入位置来对输出进行加权，则可以得到下面的公式推导：

其中，在推导的第二步代入了高斯核（Gaussian kernel）函数（也可以使用其它的核函数：Boxcar/Constant/Epanechikov，具体说明可以参考这里 https://d2l.ai/chapter_attention-mechanisms-and-transformers/attention-pooling.html#kernels-and-data）。
上面公式中，x 对应于 Query，xi 对应于 Key。如果 xi 越是接近 x，则分配给 xi 这个 Key 所对应的结果 yi 的权重就越大。同样可以推导出，一个 Key 越接近给定的 Query，那么分配给这个 Key 对应的 Value 的注意力权重就会越大，即获得了更多的注意力。
上面公式给出了对注意力汇聚（Attention Pooling）的建模：通过使用 x 与 xi 之间关系的来表示注意力的权重 α(x-xi)，即使用 Query 与 Key 之间关系表示注意力汇聚（Attention Pooling）。可以看出，它是不带参数的注意力汇聚（Attention Pooling）模型，对应带参数的注意力汇聚（Attention Pooling）模型，也可以同样推导出来，如下所示：

其中，公式中的 w 是参数，这个参数 w 可以通过学习得到，所以使用带参数的注意力模型也能够对注意力汇聚（Attention Pooling）进行同样的建模。
上面，使用高斯核来对 Query 和 Key 之间的关系建模，高斯核指数部分可以视为注意力评分函数（Attention Scoring Function），然后把该数的输出作为后面 Softmax 函数的输入进行计算，这样将得到与 Key 对应的 Value 的概率分布（即注意力权重）。最后，注意力汇聚（Attention Pooling）的输出就是基于这些注意力权重的值的加权平均和。
计算注意力汇聚（Attention Pooling）结果的过程，如下图所示：

前面我们使用 Nadaraya–Watson 核回归模型，使用了一个高斯核 α(q, k) 基于相似度来评估注意力权重，注意力评分函数（Attention Scoring Function）如下所示：

不带指数部分的表达式，如下所示：

进而，注意力汇聚（Attention Pooling）函数可以表示为：

选择不同的注意力评分函数，会导致不同的注意力汇聚（Attention Pooling）操作。

自注意力（Self-Attention）

从形式上看，给定一个由 Token 组成的输入序列 x1, x2,…, xn，该序列的自注意力输出序列为 y1, y2,…, yn，根据注意力汇聚（Attention Pooling）公式：

我们可以得到 yi 的表达式为：

在自注意力中，Query、Keys 和 Values 都来自同一组输入，所以称为自注意力（Self-Attention）。通过下面的动态图像中提供的句子，我们可以理解一下自注意力（Self-Attention）的原理：

当聚焦到前面一列头部的某个 Token 时，它会在后面一列（也是同一个句子中的 Token 序列）找到与该 Token 更相关的其它 Token，或者可以说句子中的每个 Token 都与前面当前所聚焦 Token 有一个相关数值，值越大表示越相关，对应的注意力权重也越大。当然，同一个 Token 与它自己最相关，通常相关值最大。

多头注意力（Multi-Head Attention）

多头注意力（Multi-Head Attention）融合了来自于多个注意力汇聚（Attention Pooling）的不同知识，虽然它使用的是相同的注意力机制，但是能够比单个注意力汇聚（Attention Pooling）学习到更多的行为，比如，在句子内部能够捕获可变范围的多个依赖关系。
下面使用全连接层（FC）作为 Head，多个全连接层依次连接形成多头注意力（Multi-Head Attention），如下图所示：

上图中，在实践中是可以实现对多头注意力的多个 Head 进行并行计算处理的。
为了更形象的说明多头注意力，我们引用一个三维的说明图片（来自 peltarion.com），更直观地理解，如下图所示：

输入序列（如一个句子），其中的每个 Token 都获取到对应的 Word Embedding，然后输入到神经网络中（比如 Transformer 架构的网络）。在这个过程中，每一个 Head 都可以自己独立地去学习得到自己独有的特征，类似于只有一个 Self-Attention 的情况。而多个 Head 并行学习过程中，可能相当于有多个 Self-Attention 的情况，整体来看 Query、Keys、Values 在不同的 Head 上都可能会有部分互相不同，从而学习到的特征也就不同。
比如，在机器翻译任务中，使用多头注意力能够学习并捕捉到输入序列中的不同类型信息：一个注意力头可能学习句子的语法结构，而另一个注意力头可能学习句子中的于语义信息，这样更有利于模型生成准确、自然的翻译结果，从而提高了模型的性能。

参考资源

• https://zh.d2l.ai/chapter_attention-mechanisms/index.html
• https://d2l.ai/chapter_attention-mechanisms-and-transformers/index.html
• https://armanasq.github.io/nlp/self-attention/
• https://theaisummer.com/self-attention/
• https://peltarion.com/blog/data-science/self-attention-video

什么是 AI Agent

AI Agent 是一种能够感知环境、制定决策、执行动作的人工智能体，它能够通过独立思考、进行规划并调用合适的工具去逐步实现给定的目标，整个过程完全不需要人类参与。大模型（LLM）的出现、快速发展与完善，AI Agent 更有潜力借助 LLM 来实现对通用问题的解决与自动化处理，所以我们可以认为目前 AI Agent 基本是基于 LLM（LLM-Based） 的 AI 智能体。
AI Agent 的演化经过了如下几个阶段：

• Symbolic Agents

在 AI 研究的早期阶段，最主要的方法是符号 AI，通过采用逻辑规则和符号表示来封装知识并进行推理。在 Symbolic Agents 这个阶段主要专注解决的问题是：转换问题、表示/推理问题。

• Reactive Agents

Reactive Agent 不使用复杂的符号推理，主要关注 Agent 与其所在的环境（Environment）之间的交互，强调快速和实时响应。

• RL-Based Agents

在 RL-Based Agents 阶段，主要关注点是如何让 Agent 通过与环境（Environment）的交互进行学习，使其在特定任务中获得最大的累积奖励，从而使 Agent 能够在未知环境中自主学习并执行 Action，学习过程中无需人工干预。

• Agents with Transfer Learning and Meta Learning

传统的 RL 学习需要 Agent 耗时处理大量样本和训练，通过引入迁移学习，实现知识共享和迁移，提高了 Agent 的性能表现和泛化能力。在此基础上又引入了元学习，使 Agent 能基于少量样本迅速推断出新任务的最优策略。

• LLM-Based Agents

LLM-Based Agent 以 LLM 为核心大脑组件（中央控制器），通过多模态感知（Multimodal Perception）和工具利用（Tool Utilization）等策略来扩展其 Perception 和 Action 空间。通过使用 CoT（Chain-of-Thought）和问题分解等技术，使 LLM-Based Agent 具有推理和规划能力。同时，LLM-Based Agent 也能够与环境进行交互，通过不断地从反馈中学习，从而优化策略并做出决策，执行下一个 Action。另外，基于 LLM-Based Agent 具有更广泛的应用场景。

LLM-Based Agent 基本框架

LLM-Based Agent 的基本概念框架，如下图所示：

其中包括三个主要的组件：

• 大脑（Brain）

Brain 组件主要由核心的 LLM 组成，它包含的能力有：存储知识和记忆、信息处理与决策、推理与规划。

• 感知（Perception）

Perception 组件主要将 Agent 的感知空间，从语言文字领域扩展到多模态领域（包括语言、视觉、听觉等等）。

• 行动（Action）

在 Action 组件中，Agent 从 Brain 模块接收 Action 序列，执行与环境交互的任务。
通过上图和对三个组件的描述，我们可以看到存在这样一个自动化的环路：Environment → Perception → Brain → Action → Environment，Agent 通过自动地持续与环境交互（感知环境输入/执行 Action 输出到环境）不断学习，并不断优化策略执行新的 Action。

LLM-Based Agent 应用场景

目前，LLM-Based Agent 的应用场景主要包括三类：

• Single Agent

Single Agent，即单智能体。解决这一类场景的应用主要专注于解决任务，即任务导向，如下图所示：

任务导向：在任务导向的部署中，Agent 遵循用户的指令，负责诸如目标分解、子目标序列规划、环境交互式探索等任务，直至最终实现目标。
创新导向：在对智能程度要求更高的领域，比如尖端科学，Agent 的潜力还没有完全实现，还有很大的潜力。
生命周期导向：构建一个具有普适能力的智能体，能够在开放、未知的世界中不断探索、创造新技能，并保持长期的生命周期，目前这还是一个巨大的挑战。

• Agent-Agent

Agent-Agent，即多智能体。多智能体应用场景会存在多个智能体，它们之间存在互动，主要包括两种互动形式：合作型互动（Cooperative Interaction）、对抗型互动（Adversarial Interaction），如下图所示：

• Agent-Human

Agent-Human，即人机互动智能体。Agent 与人类合作完成任务，在这个过程中，人类的参与能有效地指导和监督 Agent 的行为，确保它们的能力满足人类的需求和目标。如下图所示：

Instructor-Executor 范式：人类直接提供清晰具体的指令，Agent 理解来自人类的自然语言命令，并将其转化为相应的 Action。
Equal Partnership 范式：包含两种情形，一种是 Agent 能够从人类的表达中感知并理解情感和情绪，最终创造出情感共鸣的对话；另一种是 Agent 以与人类对等的身份共同参与任务的执行。

AI Agent Society

AI 智能体社会（AI Agent Society），这个概念表达了 LLM-Based Agent 与模拟环境进行交互，像人类一样规划目标、做出决策、执行 Action，并参与社交活动。而未来人类也可能参与到这样一个智能体社会中，与 AI Agent 形成一个互相协作、共同演化的整体。下图展示了这种愿景：

上图中展示了一个节日的场景，模拟了一个 AI Agent 社会应用场景：
在厨房内：一个 Agent 负责点菜，另一个 Agent 负责规划（做菜需要哪些食材），然后完成做菜的任务；
在音乐会上：三个 Agent 作为一个乐队进行协同表演；
在户外：两个 Agent 在讨论制作灯笼，规划需要的材料，使用工具来计算成本开销。
人类用户：也可以参与到这个社会场景中，与 AI Agent 一起协同、社交。

参考资源

• Generative Agents: Interactive Simulacra of Human Behavior
• The Rise and Potential of Large Language Model Based Agents: A Survey
• 全球 AI Agent 大盘点，大语言模型创业一定要参考的 60 个 AI 智能体