随着AI运行工程的飞速开展，咱们不难发现为大言语模型（LLMs）提供额外工具能大大增强其配置。
举例来说，GPT3.5版本经过集成Bing搜查和Python解释器成功了才干的跃迁。GPTs则间接将api调用作为工具启动了集成，LLM会选择是间接作出回应，还是先调用它提供的工具。这些工具不只限于失掉额外信息，它们还能施展其余配置，比如帮用户订餐。
虽然OpenAI曾经用它的专门模型让咱们享用了工具经常使用的方便，大少数其余LLM在函数调用和工具经常使用方面仍不迭OpenAI的水平。我尝试了Ollama上的少数模型，大少数在继续生成可用于代理的预约义结构化输入方面体现不佳。另一方面，也有一些模型是专为函数调用提升的。但这些模型要么是驳回难以了解的自定义提醒架构，要么除了函数调用别无它用。
智能代理LLM与图数据库的交互示用意
当天咱们要讨论的是如何实施一个基于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(descriptinotallow="用来介绍的电影")genre: Optional[str] = Field(descriptinotallow=("用于介绍的电影类型。可选项有：" f"{all_genres}"))介绍工具有两个可选的输入项：电影和类型，并且咱们为类型提供了一系列可选的值。虽然这些输入项并不特意复杂，但比繁多字符串输入要初级一些，因此成功起来也略有不同。
基于JSON的LLM智能代理提醒
在我的成功中，我深受现有的
hwchase17/react-json
提醒的启示，这一提醒可以在LangChain hub中找到。提醒经常使用以下系统信息：
尽你所能回答上方的疑问。你可以经常使用以下工具：{tools}你可以经过指定一个JSON块来经常使用工具。详细而言，这个JSON应该蕴含一个`action`键（用来指定要经常使用的工具称号）和一个`action_input`键（工具的输入在这里）。"action"键里的值应当仅为：{tool_names}$JSON_BLOB应该只蕴含繁多的举措，请不要前往一个列表蕴含多个举措。以下是一个有效$JSON_BLOB的示例：```{{"action": $TOOL_NAME,"action_input": $INPUT}}```每次回答都要遵照以下格局：Question: 你须要回答的疑问Thought: 你应该在思索要做什么Action:```$JSON_BLOB```Observation: 举措的结果...（这种思索/举措/观察的环节可以重复N次）Thought: 我如今知道最终答案了Final Answer: 对原本提问的最终回答开局！请记住每次回答时都要准确经常使用`Final Answer`这个词。提醒的开局局部经过定义可用的工具来设定，前面咱们将深化讨论。提醒中最主要的局部是对LLM输入预期的批示。当LLM须要经常使用工具时，它应该经常使用以下JSON结构：
{{"action": $TOOL_NAME,"action_input": $INPUT}}这就是为什么它被称作基于JSON的代理：咱们指点LLM在宿愿经常使用任何可用工具时生成一个JSON。但是，这只是输入定义的一小局部。完整的输入应遵照以下结构：
Thought: 你应该在思索要做什么Action:```$JSON_BLOB```Observation: 举措的结果...（这可以重复N次）Final Answer: 对原本提问的最终回答LLM在输入中总是须要解释它正在做什么，即"Thought"局部。当它想要经常使用任何可用的工具时，它应以JSON块的方式提供举措输入。"Observation"局部留给工具的输入，而当代理选择可以回答用户提出的疑问时，它应经常使用"Final Answer"主要词。以下是电影智能代理经常使用此结构的一个实例。
在这个例子中，咱们让代理介绍一部喜剧片。由于代理的一个可用工具是介绍工具，它选择应用介绍工具，并提供了用JSON写的输入语法。幸运的是，LangChain有一个内置的JSON智能代理输入解析器，咱们无需操心其成功细节。而后，LLM从工具失掉回应，并在提醒语中作为观察结果经常使用。由于工具提供了一切必要的信息，LLM以为曾经有了足够的信息来构建可以交给用户的最终答案。
我留意到对Mixtral的提醒工程经常失败，它不总是只在须要工具时经常使用JSON语法。在我的测试中，当它不想经常使用任何工具时，有时它会经常使用如下的JSON举措输入：
{{"action": Null,"action_input": ""}}假设举措为null或相似的，LangChain的输入解析函数并不会漠视这个举措，而是会报错说没有定义null这个工具。我尝试对此启动提醒修正，但没能不时做到。因此，我选择参与一个假定性的闲谈工具，以便用户想要启动闲谈时代理可以调用。
response = ("创立一个最终回答它们能否有任何对于电影或演员的疑问")class SmalltalkInput(BaseModel):query: Optional[str] = Field(descriptinotallow="用户提问")class SmalltalkTool(BaseTool):name = "Smalltalk"description = "当用户打招呼或想要闲谈时实用"args_schema: Type[BaseModel] = SmalltalkInputdef _run(self,query: Optional[str] = None,run_manager: Optional[CallbackManagerForToolRun] = None,) -> str:"""经常使用该工具。"""return response如此，代理在用户打招呼时可以选择经常使用一个假的Smalltalk工具，咱们再也不会由于解析null或许缺失工具名而遇到疑问了。
这样的暂时补偿方法很管用，所以我选用留用它。像之前说的，大少数模型并未被训练以发生操作输入或许在不须要举措时生成文本，因此咱们必定应用现有资源。至于操控模型以便它只在有必要时发生JSON举措输入，有时是成功的，有时则依赖状况而定。但像smalltalk工具这样给它提供一个备选项，可以防止发生意外。
在系统提醒中定义工具输入
如前所述，我须要弄分明如何定义稍微复杂的工具输入，这样LLM才干正确解释它们。好笑的是，在我成功了一个自定义配置后，我找到了一个现成的LangChain配置，这个配置可以将自定义的Pydantic工具输入定义转换成Mixtral能识别的JSON对象。
from langchain.tools.render import render_text_description_and_argstools = [RecommenderTool(), InformationTool(), Smalltalk()]tool_input = render_text_description_and_args(tools)print(tool_input)它发生了以下的字符串形容：
"Recommender":"当你须要介绍一部电影时经常使用","args":{{"movie":{{"title":"Movie","description":"用于介绍的电影","type":"string"}},"genre":{{"title":"Genre","description":"用于介绍的电影类型。可选项有：['Action', 'Adventure', 'Animation', 'Children', 'Comedy', 'Crime', 'Documentary', 'Drama', 'Fantasy', 'Film-Noir', 'Horror', 'IMAX', 'Musical', 'Mystery', 'Romance', 'Sci-Fi', 'Thriller', 'War', 'Western']","type":"string"}}}},"Information":"当你须要回答对于各种演员或电影疑问时经常使用","args":{{"entity":{{"title":"Entity","description":"疑问中提到的电影或人名","type":"string"}},"entity_type":{{"title":"Entity Type","description":"实体的类型。可选项为'movie'或'person'","type":"string"}}}},"Smalltalk":"当用户打招呼或想要闲谈时经常使用","args":{{"query":{{"title":"Query","description":"用户提问","type":"string"}}}}咱们只有将这些工具形容复制粘贴到系统提醒中，Mixtral就能正确经常使用这些提早定义的工具，这十分繁难。
论断
为成功这个基于JSON的智能代理，Harrison Chase和LangChain团队曾经成功了大局部上班，我对此表示由衷的感谢。我只有要把碎片拼凑起来即可。正如所说，不要等候与GPT-4等同水平的性能。但是，我置信像Mixtral这样更弱小的开源LLMs可以立刻当做智能代理经常使用（比起GPT-4来或许须要更多的意外解决）。我等候未来会有更多开源LLMs被提升以作为智能代理经常使用。