基于JSON的Ollama和LangChain agent

到目前为止，我们都可能意识到，通过为LLMs提供额外的工具，我们可以显著增强它们的功能。

例如，即使是ChatGPT在付费版本中也可以直接使用Bing搜索和Python解释器。OpenAI更进一步，为工具使用提供了经过优化的LLM模型，您可以将可用的工具和提示一起传递给API端点。

然后LLM决定是否可以直接提供回答，或者是否应该首先使用任何可用的工具。

请注意，这些工具不仅仅用于获取额外的信息；它们可以是任何东西，甚至可以让LLMs预订晚餐。我之前实施过一个项目，允许LLM通过一组预定义的工具与图数据库进行交互，我称之为语义层。

一个与图数据库交互的代理LLM。图片由作者提供。

本质上，这些工具通过提供动态、实时的信息访问、通过记忆进行个性化以及通过知识图谱对关系进行复杂的理解，来增强像GPT-4这样的LLM。

它们共同使LLM能够提供更准确的推荐，随着时间的推移了解用户的偏好，并获得更广泛的最新信息，从而实现更具互动性和适应性的用户体验。

正如提到的那样，除了在查询时能够检索到额外的信息外，它们还给LLM提供了一种影响他们环境的选择，例如在日历中预订会议。

虽然OpenAI为我们提供了精细调整的模型来进行工具使用，但事实是，大多数其他LLMs在函数调用和工具使用方面都不及OpenAI水平。

我已经尝试了Ollama中大部分可用的模型，大多数都难以始终生成可用于驱动代理的预定义结构化输出。另一方面，有一些模型是针对函数调用进行了优化的。

然而，这些模型采用了一种自定义的提示工程模式来进行函数调用，但这种模式并没有很好地记录，或者它们不能用于除了函数调用之外的任何其他用途。

最终，我决定遵循现有的LangChain实现，使用基于JSON的代理，使用Mixtral 8x7b LLM。我将Mixtral 8x7b用作电影代理，通过语义层与Neo4j进行交互，Neo4j是一种本地图数据库。代码可作为Langchain模板和Jupyter笔记本提供。如果你对工具的实现方式感兴趣，可以查看我之前的博客文章。在这里，我们将讨论如何实现基于JSON的LLM代理。

语义层中的工具

LangChain文档中的示例（JSON代理，HuggingFace示例）使用的是只有一个字符串输入的工具。由于语义层中的工具使用稍微复杂一些的输入，我不得不深入研究一下。这是一个推荐工具的示例输入。

all_genres = [
    "Action",
    "Adventure",
    "Animation",
    "Children",
    "Comedy",
    "Crime",
    "Documentary",
    "Drama",
    "Fantasy",
    "Film-Noir",
    "Horror",
    "IMAX",
    "Musical",
    "Mystery",
    "Romance",
    "Sci-Fi",
    "Thriller",
    "War",
    "Western",
]


class RecommenderInput(BaseModel):
    movie: Optional[str] = Field(description="movie used for recommendation")
    genre: Optional[str] = Field(
        description=(
            "genre used for recommendation. Available options are:" f"{all_genres}"
        )
    )

推荐工具有两个可选输入：电影和类型。此外，我们使用一个可用值的枚举来表示类型参数。

虽然输入并不是非常复杂，但仍比单个字符串输入更先进，因此实现方式必须稍有不同。

基于JSON的LLM代理的提示

在我的实现中，我从LangChain hub中现有的 hwchase17/react-json 提示中获得了很大的灵感。该提示使用以下系统消息。

Answer the following questions as best you can. You have access to the following tools:

{tools}

The way you use the tools is by specifying a json blob.
Specifically, this json should have a `action` key (with the name of the tool to use) and a `action_input` key (with the input to the tool going here).

The only values that should be in the "action" field are: {tool_names}

The $JSON_BLOB should only contain a SINGLE action, do NOT return a list of multiple actions. Here is an example of a valid $JSON_BLOB:

```
{{
  "action": $TOOL_NAME,
  "action_input": $INPUT
}}
```

ALWAYS use the following format:

Question: the input question you must answer
Thought: you should always think about what to do
Action:
```
$JSON_BLOB
```
Observation: the result of the action
... (this Thought/Action/Observation can repeat N times)
Thought: I now know the final answer
Final Answer: the final answer to the original input question

Begin! Reminder to always use the exact characters `Final Answer` when responding.

提示从定义可用工具开始，稍后我们将介绍。提示的最重要部分是指示LLM输出应该是什么样子的。当LLM需要调用一个函数时，应该使用以下JSON结构：

{{
  "action": $TOOL_NAME,
  "action_input": $INPUT
}}

这就是为什么它被称为基于JSON的代理：当LLM想要使用任何可用工具时，我们指示它生成一个JSON。然而，这只是输出定义的一部分。完整的输出应该具有以下结构：

Thought: you should always think about what to do
Action:
```
$JSON_BLOB
```
Observation: the result of the action
... (this Thought/Action/Observation can repeat N times)
Final Answer: the final answer to the original input question

LLM应该在输出的思考部分解释它正在做什么。当它想要使用任何可用的工具时，应该将动作输入提供为JSON blob。

观察部分保留给工具输出，当代理决定可以向用户返回答案时，应使用最终答案键。以下是使用此结构的电影代理的示例。

在这个例子中，我们要求代理人推荐一部好的喜剧片。由于代理人可用的工具之一是推荐工具，它决定利用推荐工具，通过提供JSON语法来定义其输入。幸运的是，LangChain具有内置的JSON代理输出解析器，所以我们不必担心实现它。接下来，LLM从工具中获得一个响应，并将其作为提示中的观察。

由于工具提供了所有所需的信息，LLM决定它已经有足够的信息来构建最终答案，并将其返回给用户。

我注意到很难促使工程师Mixtral只在需要使用工具时使用JSON语法。在我的实验中，当它不想使用任何工具时，有时会使用以下JSON动作输入。

{{
  "action": Null,
  "action_input": ""
}}

LangChain中的输出解析函数不会忽略空或类似的操作，而是返回一个错误，指出未定义空工具。我试图向工程师提供解决这个问题的提示，但无法以一致的方式做到。

因此，我决定添加一个虚拟的闲聊工具，当用户想要闲聊时，代理可以调用它。

response = (
    "Create a final answer that says if they "
    "have any questions about movies or actors"
)


class SmalltalkInput(BaseModel):
    query: Optional[str] = Field(description="user query")


class SmalltalkTool(BaseTool):
    name = "Smalltalk"
    description = "useful for when user greets you or wants to smalltalk"
    args_schema: Type[BaseModel] = SmalltalkInput

    def _run(
        self,
        query: Optional[str] = None,
        run_manager: Optional[CallbackManagerForToolRun] = None,
    ) -> str:
        """Use the tool."""
        return response

这样，代理可以在用户打招呼时决定使用一个虚拟的Smalltalk工具，我们不再遇到解析空或缺失工具名称的问题。

这个解决方法非常有效，所以我决定保留它。正如提到的，大多数模型没有经过训练来产生行动输入或文本，如果不需要行动，我们必须使用当前可用的内容。

然而，有时候模型在第一次迭代时成功地不调用任何工具，这取决于情况。但是给它一个像smalltalk工具这样的逃逸选项似乎可以防止异常。

在系统提示中定义工具输入

如前所述，我必须弄清楚如何定义稍微复杂的工具输入，以便LLM能够正确解释它们。

有趣的是，在实施自定义函数之后，我发现了一个现有的LangChain函数，它将自定义的Pydantic工具输入定义转换为Mixtral可以识别的JSON对象。

from langchain.tools.render import render_text_description_and_args

tools = [RecommenderTool(), InformationTool(), Smalltalk()]

tool_input = render_text_description_and_args(tools)
print(tool_input)

生成以下字符串描述：

"Recommender":"useful for when you need to recommend a movie",
"args":{
   {
      "movie":{
         {
            "title":"Movie",
            "description":"movie used for recommendation",
            "type":"string"
         }
      },
      "genre":{
         {
            "title":"Genre",
            "description":"genre used for recommendation. Available options are:['Action', 'Adventure', 'Animation', 'Children', 'Comedy', 'Crime', 'Documentary', 'Drama', 'Fantasy', 'Film-Noir', 'Horror', 'IMAX', 'Musical', 'Mystery', 'Romance', 'Sci-Fi', 'Thriller', 'War', 'Western']",
            "type":"string"
         }
      }
   }
},
"Information":"useful for when you need to answer questions about various actors or movies",
"args":{
   {
      "entity":{
         {
            "title":"Entity",
            "description":"movie or a person mentioned in the question",
            "type":"string"
         }
      },
      "entity_type":{
         {
            "title":"Entity Type",
            "description":"type of the entity. Available options are 'movie' or 'person'",
            "type":"string"
         }
      }
   }
},
"Smalltalk":"useful for when user greets you or wants to smalltalk",
"args":{
   {
      "query":{
         {
            "title":"Query",
            "description":"user query",
            "type":"string"
         }
      }
   }
}

我们可以简单地将这个工具描述复制到系统提示中，Mixtral就能够使用定义好的工具，这非常酷。

 结论

JSON-based agent的大部分工作是由Harrison Chase和LangChain团队完成的，我对此表示感谢。我所要做的就是找到拼图的碎片并将它们组合起来。正如前面提到的，不要期望与GPT-4一样的代理性能水平。然而，我认为像Mixtral这样更强大的OSSLLMs可以作为代理使用（比GPT-4需要更多的异常处理）。

我期待更多的开源LLMs被调整得更好作为代理。

代码可作为Langchain模板和Jupyter笔记本提供。