LLM Agent 零微调范式：ReAct 与 Self Ask

其中 AGENT_TO_CLASS 里面定义了所有的 Agent 类型，其中 SELF_ask_with_search 是 Self Ask 的实现。不同 Agent 的差异，主要是以下 few-shot prompt 和对应的 parser 不同。

Self Ask 的 few-shot prompt 如下，few-shot 除了提供解码的格式之外，还提示了模型要对问题进行拆解：

Question: Who lived longer, Muhammad Ali or Alan Turing? Are follow up questions needed here: Yes. Follow up: How old was Muhammad Ali when he died? Intermediate answer: Muhammad Ali was 74 years old when he died. Follow up: How old was Alan Turing when he died? Intermediate answer: Alan Turing was 41 years old when he died. So the final answer is: Muhammad Ali 
Question: When was the founder of craigslist born? Are follow up questions needed here: Yes. Follow up: Who was the founder of craigslist? Intermediate answer: Craigslist was founded by Craig Newmark. Follow up: When was Craig Newmark born? Intermediate answer: Craig Newmark was born on December 6, 1952. So the final answer is: December 6, 1952 
...
Question: {input} Are followup questions needed here:{agent_scratchpad}

构建完 chain 我们来跑一个问题看下模型的中间返回结果。直接调用 callable 可以返回中间过程。

以下是带中间结果的返回值，可以发现 few-shot-prompt 引导模型把问题拆分成了多个子问题，并通过谷歌搜索得到结果后，继续提问得到最终结果。

Self Ask 结果不好的两个主要原因有：

1. 搜索没有返回有效结果：当前搜索引擎的返回结果并非为大模型回答设计，而是为传统搜索引擎设计，返回结果不可用可能是抽取的文章摘要不合理，或者排序逻辑返回的 Top1 答案不合适，再或者回答的时效性错误等等。
2. 模型拆解问题有误：Self Ask 当前主要针对组合类问题，如果你的问题拆解方式不同，需要对以上 few-shot-prompt 进行调整，或者进一步通过 COT finetune 来注入问题拆解的方式。

Self Ask 是一类最简单的工具调用模板，只支持单一搜索工具的使用，不支持工具选择。

ReAct

ReAct: SYNERGIZING REASONING AND ACTING IN LANGUAGE MODELS

原理

ReAct 文如其名，模型推理分成了两个部分，Reason 和 Action。Reason 生成分析步骤，Action 生成工具调用请求，二者交替进行直到得到最终的结果。和 Self Ask 对比，ReAct 进一步把推理和工具调用进行了解耦。在 Self Ask 中，自我提问既是推理步骤也是搜索工具的请求 query，而在 ReAct 中工具调用的请求在推理步骤之后，这样可以更好的支持搜索以外的其他工具。

ReAct 在文档问答上给出的 few-shot-cot 推理模板如下：

应用

同样是 AGENT_TO_CLASS，ReActDocstoreAgent 和 ZeroShotAgent 是基于 ReAct 开发的。为了保持一致性，我们用和以上 Self Ask 相同的方式来初始化以下两个 Agent。

ZeroShotAgent

需要提供可以使用的工具列表，以及每种工具的描述，LLM 完全基于上下文，根据工具的描述进行工具选择，适用于没有固定推理套路的场景。为了和 SelfAsk 对比，这里我们还是使用谷歌搜索，再额外加入 Wolfram Alpha 工具。

import os
from langchain.agents.loading import AGENT_TO_CLASS
from langchain.agents.agent import AgentExecutor
from langchain.agents import AgentType, Tool
from langchain import OpenAI, SerpAPIWrapper
from langchain.utilities.wolfram_alpha import WolframAlphaAPIWrapper

os.environ["WOLFRAM_ALPHA_APPID"] = "你的 key"

# 定义大模型和搜索工具
llm = OpenAI(temperature=0, openai_api_key="你的 key")
search = SerpAPIWrapper(params={
    "engine": "google",
    "gl": "us",
    "hl": "zh-cn",
}, serpapi_api_key="你的 key")
wolfram = WolframAlphaAPIWrapper()

tools = [
    Tool(
        name="搜索",
        description="搜索引擎，当你需要回答当前问题的时候调用，输入是检索 query",
        func=search.run
    ),
    Tool(
        name="Wolfram",
        description="Wolfram Alpha，当你需要回答和数学，科学，科技，文化，社会，日常生活相关的问题时调用，输入是检索 query",
        func=wolfram.run
    ),
]

agent_cls = AGENT_TO_CLASS[AgentType.ZERO_SHOT_REACT_DESCRIPTION]
agent = agent_cls.from_llm_and_tools(llm, tools)
chain = AgentExecutor.from_agent_and_tools(agent, tools, return_intermediate_steps=True)
output = chain("昨日 A 股市场涨幅最高的板块成交量多少")

加入谷歌搜索和 Wolfram 工具后，zero-shot prompt 包含工具的描述和 Action 部分可以调用的工具列表。因为没有 few-shot 拆解问题的指引，只有以上 zero-shot 去描述工具选择，因此模型并没有正确拆解问题，不过正确选择了搜索工具。

当我们提问 Wolfram 可以解决的问题领域，例如求解几何面积时，大模型会选择调用 Wolfram 来解决数学问题。

ReActDocstoreAgent

适用于文档问答的固定推理模板 + 固定工具使用，论文定义了两种工具 Search 检索，和 Lookup 在文档中查找关键词所在的句子。DocStore 因为推理模板固定，可用的场景比较有限。

React 虽然本身是可以不经过模型指令微调直接使用的，但论文中也提出指令微调后效果会有提升。

总结与方案选择建议

看完了 Self Ask 和 React 的实现，不难发现二者存在一些局限性，同时也明确了各自的适用场景。

1. 更适合简单的工具调用：这里的简单是指工具的输入和上文的文本语义比较符合，工具输入比较'自然语言'风格例如搜索。高度结构化和符号化的工具输入，使用 Prompt 实现，准确率比较有限。
2. 更适合少量的工具组合：受限于 Prompt 上文的长度，不能把几十个工具 prompt 全塞进去，因此更适合少量的工具组合，一般是 3~5 个以内。
3. 规划能力：在问题拆解上 few-shot 的效果会比 zero-shot 要好，不过要支持特定的问题拆解逻辑需要定制化领域 few-shot。如果逻辑过于复杂或者多样性较高，只依赖固定 prompt 的效果也会比较一般。
4. 串行计算延时高：Self Ask 和 React 都是串行推理逻辑，每一步推理和工具调用都依赖上一步的推理结果，导致整体计算耗时太长。针对这个问题可以看下 ReWOO 提出的并行推理 + 槽位填充的方案。

方案选择建议：

• 如果问题是组合型的查询（如 A 的 B 属性），且主要依赖搜索，优先尝试 Self Ask。
• 如果需要调用多种不同类型的工具（如搜索 + 计算器 + 数据库），且不需要复杂的拆解逻辑，优先尝试 ReAct (ZeroShot)。
• 如果涉及文档内部检索，考虑 ReActDocstoreAgent。
• 对于更复杂多样的工具调用，和更有针对性/复杂的模型规划能力，建议后续探索基于指令微调的工具调用方案。

针对更复杂多样的工具调用，和更有针对性/复杂的模型规划能力，下一章我们将介绍基于指令微调的工具调用方案。