Agent實戰-JSON結構化智能
隨著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] = SmalltalkInput
def _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_args
tools = [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被優化以作為智能代理使用。
References
- Langchain模板：https://github.com/langchain-ai/langchain/tree/master/templates/neo4j-semantic-ollama?ref=blog.langchain.dev
- Jupyter筆記本版本：https://github.com/tomasonjo/blogs/blob/master/llm/ollama_semantic_layer.ipynb?ref=blog.langchain.dev
本文轉載自 ??AI小智??，作者： AI小智
