[譯] AI Agent(智能體)技術(shù)白皮書(Google,2024)
譯者序
本文翻譯自 2024 年 Google 團隊的一份 Agents 白皮書, 作者 Julia Wiesinger, Patrick Marlow, Vladimir Vuskovic。
Agent 可以理解為是一個擴展了大模型出廠能力的應用程序。
工具的使用,是人類區(qū)別于動物的標志 —— 也是 Agent 區(qū)別于大模型的標志。
水平及維護精力所限,譯文不免存在錯誤或過時之處,如有疑問,請查閱原文。 傳播知識,尊重勞動,年滿十八周歲,轉(zhuǎn)載請注明出處。
以下是譯文。
- 譯者序
- 1 引言
- 2 什么是 Agent?
- 3 認知架構(gòu):Agent 是如何工作的
- 4 工具:模型通往現(xiàn)實世界的關(guān)鍵
- 5 通過針對性學習提升模型性能
- 6 基于 LangChain 快速創(chuàng)建 Agent
- 7 總結(jié)
- 參考資料
1 引言
1.1 人類的先驗知識與工具的使用
人類很很好地處理復雜和微妙的模式識別任務。 能做到這一點是因為,我們會通過書籍、搜索或計算器之類的工具來補充我們頭腦中的先驗知識, 然后才會給出一個結(jié)論(例如,“圖片中描述的是 XX”)。
1.2 人類的模仿者
與以上類似,我們可以對生成式 AI 模型進行訓練, 讓它們能使用工具來在現(xiàn)實世界中獲取實時信息或給出行動建議。 例如,
- 利用數(shù)據(jù)庫查詢工具獲取客戶的購物歷史,然后給出購物建議。
- 根據(jù)用戶的查詢,調(diào)用相應 API,替用戶回復電子郵件或完成金融交易。
為此,模型不僅需要訪問外部工具,還要能夠自主規(guī)劃和執(zhí)行任務。 這種具備了推理、邏輯和訪問外部信息的生成式 AI 模型,就是 Agent 的概念; 換句話說,Agent 是一個擴展了生成式 AI 模型出廠能力的程序。
2 什么是 Agent?
2.1 概念:應用程序
寬泛地來說,生成式 AI Agent 可以被定義為一個應用程序, 通過觀察周圍世界并使用可用的工具來實現(xiàn)其目標。
- Agent 是有自主能力的(autonomous),只要提供了合適的目標,它們就能獨立行動,無需人類干預;
- 即使是模糊的人類指令,Agent 也可以推理出它接下來應該做什么,并采取行動,最終實現(xiàn)其目標。
在 AI 領域,Agent 是一個非常通用的概念。本文接下來要討論的 Agent 會更具體, 指的是本文寫作時,基于生成式 AI 模型能夠?qū)崿F(xiàn)的 Agents。
2.2 架構(gòu):cognitive architecture
為了理解 Agent 的內(nèi)部工作原理,我們需要看看驅(qū)動 Agent 行為、行動和決策(behavior, actions, and decision making)的基礎組件。
這些組件的組合實現(xiàn)了一種所謂的認知架構(gòu)(cognitive architecture), 通過這些組件可以實現(xiàn)許多這樣的架構(gòu)。我們后面還會就這一點展開討論。
2.3 組件
Agent 架構(gòu)中有三個核心組件,如圖所示,
Figure 1. 典型 Agent 架構(gòu)與組件。
2.3.1 模型(model)
這里指的是用作 Agent 中用來做核心決策的語言模型(LM)。
- 可以是一個或多個任何大小的模型,能夠遵循基于指令的推理和邏輯框架,如
ReAct、Chain-of-Thought、Tree-of-Thoughts
。 - 可以是通用的、多模態(tài)的,或根據(jù)特定 Agent 架構(gòu)的需求微調(diào)得到的模型。
- 可以通過“能展示 Agent 能力的例子或數(shù)據(jù)集”來進一步微調(diào)模型,例如 Agent 在什么上下文中使用什么工具,或者執(zhí)行什么推理步驟。
2.3.2 工具(tool)
基礎模型在文本和圖像生成方面非常強大,但無法與外部世界聯(lián)動極大限制了它們的能力。 工具的出現(xiàn)解決了這一問題。有了工具,Agent 便能夠與外部數(shù)據(jù)和服務互動,大大擴展了它們的行動范圍。
工具可以有多種形式,常見是 Web API
方式,即 GET、POST、PATCH 和 DELETE 方法。
例如,結(jié)合用戶信息和獲取天氣數(shù)據(jù)的 tool,Agent 可以為用戶提供旅行建議。
有了工具,Agent 可以訪問和處理現(xiàn)實世界的信息,這使它們能夠支撐更專業(yè)的系統(tǒng),如檢索增強生成(RAG),顯著擴展了 Agent 的能力。
2.3.3 編排層(orchestration)
編排層描述了一個循環(huán)過程:Agent 如何接收信息,如何進行內(nèi)部推理,如何使用推理來結(jié)果來指導其下一步行動或決策。
- 一般來說,這個循環(huán)會持續(xù)進行,直到 Agent 達到其目標或觸發(fā)停止條件。
- 編排層的復雜性跟 Agent 及其執(zhí)行的任務直接相關(guān),可能差異很大。 例如,一些編排就是簡單的計算和決策規(guī)則,而其他的可能包含鏈式邏輯、額外的機器學習算法或其他概率推理技術(shù)。
我們將在認知架構(gòu)部分更詳細地討論 Agent 編排層的詳細實現(xiàn)。
2.4 Agent 與 model 的區(qū)別
為了更清楚地理解 Agent 和模型之間的區(qū)別,這里整理個表格,
? | 模型 | Agent |
---|---|---|
知識范圍 | 知識僅限于其訓練數(shù)據(jù)。 | 通過工具連接外部系統(tǒng),能夠在模型自帶的知識之外,實時、動態(tài)擴展知識。 |
狀態(tài)與記憶 | 無狀態(tài),每次推理都跟上一次沒關(guān)系,除非在外部給模型加上會話歷史或上下文管理能力。 | 有狀態(tài),自動管理會話歷史,根據(jù)編排自主決策進行多輪推理。 |
原生工具 | 無。 | 有,自帶工具和對工具的支持能力。 |
原生邏輯層 | 無。需要借助提示詞工程或使用推理框架(CoT、ReAct 等)來形成復雜提示,指導模型進行預測。 | 有,原生認知架構(gòu),內(nèi)置 CoT、ReAct 等推理框架或 LangChain 等編排框架。 |
3 認知架構(gòu):Agent 是如何工作的
3.1 類比:廚師做菜
想象廚房中一群忙碌的廚師。他們的職責是根據(jù)顧客的菜單,為顧客烹制相應的菜品。 這就涉及到我們前面提到的“規(guī)劃 —— 執(zhí)行 —— 調(diào)整”循環(huán)。具體來說, 廚師們需要執(zhí)行以下步驟,
- 收集信息(輸入):顧客點的菜,后廚現(xiàn)有的食材等等;
- 推理(思考):根據(jù)收集到的信息,判斷可以做哪些菜;
- 做菜(行動):包括切菜、加調(diào)料、烹炒等等。
在以上每個階段,廚師都根據(jù)需要進行調(diào)整 —— 例如某些食材不夠用了,或者顧客反饋好吃或難吃了 —— 進而不斷完善他們的計劃。 這個信息接收、規(guī)劃、執(zhí)行和調(diào)整(information intake, planning, executing, and adjusting)的循環(huán)描述的就是一個廚師用來實現(xiàn)其目標的特定認知架構(gòu)。
3.2 Agent 推理框架
跟以上廚師類似,Agent 也可以使用認知架構(gòu)處理信息、做出決策,并根據(jù)前一輪的輸出調(diào)整下一個行動,如此循環(huán)迭代來實現(xiàn)其最終目標。
- 在 Agent 中,認知架構(gòu)的核心是編排層,負責維護記憶、狀態(tài)、推理和規(guī)劃(memory, state, reasoning and planning)。
- 它使用快速發(fā)展的提示詞工程及相關(guān)框架(prompt engineering and associated frameworks)來指導推理和規(guī)劃,使 Agent 能夠更有效地與環(huán)境互動并完成任務。
在寫作本文時,有下面幾種流行的推理框架和推理技術(shù)。
3.2.1 ReAct
為語言模型提供了一個思考過程策略。
已經(jīng)證明 ReAct 優(yōu)于幾個 SOTA 基線,提高了 LLM 的人機交互性和可信度。
3.2.2 Chain-of-Thought (CoT)
通過中間步驟實現(xiàn)推理能力。CoT 有各種子技術(shù),包括自我一致性、主動提示和多模態(tài) CoT,適合不同的場景。
3.2.3 Tree-of-Thoughts (ToT)
非常適合探索或戰(zhàn)略前瞻任務。概括了鏈式思考提示,并允許模型探索各種思考鏈,作為使用語言模型解決問題的中間步驟。
3.3 ReAct 例子
Agent 可以使用以上一種或多種推理技術(shù),給特定的用戶請求確定下一個最佳行動。 例如,使用 ReAct 的例子,
- 用戶向 Agent 發(fā)送查詢。
- Agent 開始 ReAct sequence。
- Agent 提示模型,要求其生成下一個 ReAct 步驟及其相應的輸出:
- 問題:提示詞 + 用戶輸入的問題
- 思考:模型的想法:下一步應該做什么
- 行動:模型的決策:下一步要采取什么行動。這里就是可以引入工具的地方,
例如,行動可以是
[Flights, Search, Code, None]
中的一個,前三個代表模型可以選擇的已知工具,最后一個代表“無工具選擇”。 - 行動的輸入:模型決定是否要向工具提供輸入,如果要提供,還要確定提供哪些輸入
- 觀察:行動/行動輸入序列的結(jié)果。根據(jù)需要,這個思考/行動/行動輸入/觀察(
thought / action / action input / observation
)可能會重復 N 次。 - 最終答案:模型返回對原始用戶查詢的最終答案。
- ReAct 循環(huán)結(jié)束,并將最終答案返回給用戶。
Figure 2. Example Agent with ReAct reasoning in the orchestration layer
如圖 2 所示,模型、工具和 Agent 配置共同工作,根據(jù)用戶的輸入返回了一個有根據(jù)的、簡潔的響應。 雖然模型第一輪根據(jù)其先前知識猜了一個答案(幻覺),但它接下來使用了一個工具(航班)來搜索實時外部信息, 從而能根據(jù)真實數(shù)據(jù)做出更明智的決策,并將這些信息總結(jié)回給用戶。
總結(jié)起來,Agent 的響應質(zhì)量與模型的推理能力和執(zhí)行任務的能力直接相關(guān), 包括選擇正確工具的能力,以及工具自身的定義的好壞(how well that tools has been defined)。 就像廚師精選食材、精心做菜,并關(guān)注顧客的反饋一樣,Agent 依賴于合理的推理和可靠的信息來提供最佳結(jié)果。
在下一節(jié)中,我們將深入探討 Agent 與“新鮮”數(shù)據(jù)的各種連接方式。
4 工具:模型通往現(xiàn)實世界的關(guān)鍵
語言模型很擅長處理信息,但它們?nèi)狈?strong>直接感知和影響現(xiàn)實世界的能力。 在需要與外部系統(tǒng)或數(shù)據(jù)聯(lián)動的情況下,這些模型的實用性就很低了。某種意義上說, 語言模型的能力受限于它們的訓練數(shù)據(jù)中覆蓋到的信息。
那么,如何賦予模型與外部系統(tǒng)進行實時、上下文感知的互動能力呢? 目前有幾種方式:
- Functions
- Extensions
- Data Stores
- Plugins
雖然名稱各異,但它們都統(tǒng)稱為工具(tools)。 工具是將基礎模型與外部世界連接起來的橋梁。
能夠連接到外部系統(tǒng)和數(shù)據(jù)之后,Agent 便能夠執(zhí)行更廣泛的任務,并且結(jié)果更加準確和可靠。 例如,工具使 Agent 能夠調(diào)整智能家居設置、更新日程、從數(shù)據(jù)庫中獲取用戶信息或根據(jù)特定指令發(fā)送電子郵件。
寫作本文時,Google 模型能夠與三種主要工具類型互動:Functions、Extensions、Data Stores。
配備了工具之后,Agent 不僅解鎖了理解真實世界和在真實世界中做出行動的超能力, 而且打開了各種新應用場景和可能性的大門。
4.1 工具類型一:extensions
在最簡單的概念上: extension 是一種以標準化方式連接 API 與 Agent 的組件, 使 Agent 能夠調(diào)用外部 API,而不用管這些 API 背后是怎么實現(xiàn)的。
4.1.1 需求:預定航班的 Agent
假設你想創(chuàng)建一個幫用戶預訂航班的 Agent,并使用 Google Flights API 來搜索航班信息, 但不確定如何讓你的 Agent 調(diào)用這個 API。
Figure 3. How do Agents interact with External APIs?
4.1.2 實現(xiàn)方式一:傳統(tǒng)方式,寫代碼解析參數(shù)
傳統(tǒng)解決方式是寫代碼,從用戶輸入中解析城市等相關(guān)信息,然后調(diào)用 API。 例如,
- 用戶輸入 “I want to book a flight from Austin to Zurich”(“我想從奧斯汀飛往蘇黎世”); 我們的代碼需要從中提取“Austin”和“Zurich”作為相關(guān)信息,然后才能進行 API 調(diào)用。
- 但如果用戶輸入“I want to book a flight to Zurich”,我們就無法獲得出發(fā)城市信息,進而無法成功調(diào)用 API,所以需要寫很多代碼來處理邊界 case。
顯然,這種方法維護性和擴展性都很差。有沒有更好的解決方式呢? 這就輪到 exntension 出場了。
4.1.3 實現(xiàn)方式二:使用 Extension
Figure 4. Extensions connect Agents to External APIs
如上圖所示,Extension 通過以下方式將 Agent 與 API 串起來:
- 提供示例信息教 Agent 如何使用 API。
- 告訴 Agent 調(diào)用 API 所需的具體參數(shù)。
Extension 可以獨立于 Agent 開發(fā),但應作為 Agent 配置的一部分。
Agent 在運行時,根據(jù)提供的示例和模型來決定使用哪個 extension 來處理用戶的查詢,
這突出了 extension 的一個核心優(yōu)勢:built-in example types
,
允許 Agent 動態(tài)選擇最適合所執(zhí)行任務的 extension,如下圖所示,
Figure 5. 1-to-many relationship between Agents, Extensions and APIs
4.1.4 Extension 示例
以 Google 的 Code Interpreter extension 作為例子,從自然語言描述生成和運行 Python 代碼。
import vertexai
import pprint
PROJECT_ID = "YOUR_PROJECT_ID"
REGION = "us-central1"
vertexai.init(project=PROJECT_ID, location=REGION)
from vertexai.preview.extensions import Extension
extension_code_interpreter = Extension.from_hub("code_interpreter")
CODE_QUERY = """Write a python method to invert a binary tree in O(n) time."""
response = extension_code_interpreter.execute(
operation_id="generate_and_execute",
operation_params={"query": CODE_QUERY}
)
print("Generated Code:")
pprint.pprint(response['generated_code'])
輸出如下:
class TreeNode:
def __init__(self, val=0, left=None, right=None):
self.val = val
self.left = left
self.right = right
def invert_binary_tree(root):
"""Inverts a binary tree."""
if not root:
return None
# Swap the left and right children recursively
root.left, root.right = invert_binary_tree(root.right), invert_binary_tree(root.left)
return root
# Example usage:
# Construct a sample binary tree
root = TreeNode(4)
root.left = TreeNode(2)
root.right = TreeNode(7)
root.left.left = TreeNode(1)
root.left.right = TreeNode(3)
root.right.left = TreeNode(6)
root.right.right = TreeNode(9)
# Invert the binary tree
inverted_root = invert_binary_tree(root)
4.2 工具類型二:functions
在軟件工程中,也就是我們?nèi)粘懘a時,“函數(shù)”指的是自包含的代碼模塊,用于完成特定任務,并可以復用(被不同地方的代碼調(diào)用)。 軟件工程師寫程序時,通常會創(chuàng)建許多函數(shù)來執(zhí)行各種任務,還會定義函數(shù)的預期輸入和輸出。
在 Agent 的世界中,函數(shù)的工作方式非常相似 —— 只是將“軟件開發(fā)者”替換為“模型”。 模型可以設置一組已知的函數(shù),然后就可以根據(jù)規(guī)范決定何時使用哪個函數(shù),以及函數(shù)需要哪些參數(shù)。
4.2.1 Function vs. Extension
還是以前面的 Google Flights 為例,可以看出 Function 與 Extension 的不同:
Figure 7. How do functions interact with external APIs?
- 模型只輸出函數(shù)名及其參數(shù)信息,但不會執(zhí)行函數(shù);
-
函數(shù)在客戶端執(zhí)行。作為對比,Extension 在 Agent 端執(zhí)行。見下圖,
Figure 8. Delineating client vs. agent side control for extensions and function calling
4.2.2 例子:教模型結(jié)構(gòu)化輸出信息
考慮以下例子,實現(xiàn)一個 AI Traval Agent,它會與想要旅行的用戶互動。 我們的目標是讓 Agent 生成一個城市列表,然后就可以下載相應城市的圖片、數(shù)據(jù)等,以供用戶旅行規(guī)劃使用。
-
用戶可能會說:
I’d like to take a ski trip with my family but I’m not sure where to go.
-
典型的模型輸出可能如下:
Sure, here’s a list of cities that you can consider for family ski trips: - Crested Butte, Colorado, USA - Whistler, BC, Canada - Zermatt, Switzerland
-
雖然以上輸出包含了我們需要的數(shù)據(jù)(城市名稱),但格式不適合解析。 通過 Function,我們可以教模型以結(jié)構(gòu)化風格(如 JSON)輸出,以便其他系統(tǒng)解析。 例如,輸出可能是下面這樣,
{ "name": "display_cities", "args": { "cities": ["Crested Butte", "Whistler", "Zermatt"], "preferences": "skiing" } }
這個 Agent 應用的整體流程圖如圖 9 所示,
Figure 9. Sequence diagram showing the lifecycle of a Function Call
4.2.3 示例代碼
Function 定義:
def display_cities(cities: list[str], preferences: Optional[str] = None):
"""Provides a list of cities based on the user's search query and preferences.
Args:
preferences (str): The user's preferences for the search, like skiing, beach, restaurants, bbq, etc.
cities (list[str]): The list of cities being recommended to the user.
Returns:
list[str]: The list of cities being recommended to the user.
"""
return cities
接下來,初始化模型和工具,然后將用戶的查詢和工具傳遞給模型。
from vertexai.generative_models import GenerativeModel, Tool, FunctionDeclaration
model = GenerativeModel("gemini-1.5-flash-001")
display_cities_function = FunctionDeclaration.from_func(display_cities)
tool = Tool(function_declarations=[display_cities_function])
message = "I’d like to take a ski trip with my family but I’m not sure where to go. "
res = model.generate_content(message, tools=[tool])
print(f"Function Name: {res.candidates[0].content.parts[0].function_call.name}")
print(f"Function Args: {res.candidates[0].content.parts[0].function_call.args}")
效果:
> Function Name: display_cities
> Function Args: {'preferences': 'skiing', 'cities': ['Aspen', 'Vail', 'Park City']}
總結(jié)起來,F(xiàn)unction 提供了一個簡單的框架,使應用程序開發(fā)人員能夠
- 對數(shù)據(jù)流和系統(tǒng)執(zhí)行進行細粒度的控制,
- 利用 Agent 和模型生成結(jié)構(gòu)化的信息,方便作為下一步的輸入。
4.3 工具類型三:data storage
Figure 10. How can Agents interact with structured and unstructured data?
語言模型就像一個大圖書館,其中包含了其訓練數(shù)據(jù)(信息)。但與真實世界的圖書館不同的是, 這個圖書館是靜態(tài)的 —— 不會更新,只包含其最初訓練時的知識。 而現(xiàn)實世界的知識是不斷在演變的,所以靜態(tài)模型在解決現(xiàn)實世界問題時就遇到了挑戰(zhàn)。
Figure 11. Data Stores connect Agents to new real-time data sources of various types.
Data Storage 通過提供動態(tài)更新的信息來解決這一問題,
- 允許開發(fā)人員以原始格式向 Agent 提供增量數(shù)據(jù),將傳入的文檔將被轉(zhuǎn)換為一組向量數(shù)據(jù)庫嵌入(
embedding
),Agent 可以使用這些 embedding 來提取信息。 - 使模型的返回更相關(guān),更具實效性。
- 避免了微調(diào)甚至重新訓練模型等重量級操作。
4.3.1 實現(xiàn)與應用
在生成式 AI 場景,Agent 使用的數(shù)據(jù)庫一般是向量數(shù)據(jù)庫 —— 它們以向量 embedding 的形式存儲數(shù)據(jù),這是一種高維向量或數(shù)學表示。
Figure 12. 1-to-many relationship between agents and data stores, which can represent various types of pre-indexed data
使用語言模型與 Data Storage 的最典型例子是檢索增強生成(RAG
)。
RAG 應用程序通過讓模型訪問各種格式的數(shù)據(jù)來擴展模型知識的廣度和深度,如:
- 網(wǎng)站內(nèi)容
- 結(jié)構(gòu)化數(shù)據(jù),如 PDF、Word 文檔、CSV、電子表格等
- 非結(jié)構(gòu)化數(shù)據(jù),如 HTML、PDF、TXT 等
每個用戶請求和 Agent 響應循環(huán)的基本過程通常如圖 13 所示,
Figure 13. The lifecycle of a user request and agent response in a RAG based application
- 用戶 query 送到 embedding 模型,生成 query 的 embedding 表示。
- 將 query embedding 與向量數(shù)據(jù)庫的內(nèi)容進行匹配,本質(zhì)上就是在計算相似度。
- 將相似度最高的內(nèi)容以文本格式發(fā)送回 Agent。
- Agent 決定響應或行動。
- 最終響應發(fā)送給用戶。
更多 RAG 信息:大模型 RAG 基礎:信息檢索、文本向量化及 BGE-M3 embedding 實踐(2024)。譯注。
4.3.2 例子
圖 14 是一個 RAG 與 ReAct 推理/規(guī)劃的 Agent 示例,
Figure 14. Sample RAG based application w/ ReAct reasoning/planning
4.4 工具小結(jié)
總結(jié)來說,Extension、Function 和 Data Storage 是 Agent 在運行時可以使用的幾種不同工具類型。 每種工具都有其特定的用途,可以根據(jù) Agent 開發(fā)人員的判斷單獨或一起使用。
Extensions | Function Calling | Data Stores | |
---|---|---|---|
Execution | Agent-Side Execution | Client-Side Execution | Agent-Side Execution |
Use Case |
|
|
|
5 通過針對性學習提升模型性能
有效使用模型的一個關(guān)鍵是,讓模型具備在生成輸出時選擇正確工具的能力。 雖然一般訓練有助于模型獲得這種技能,但現(xiàn)實世界的場景通常需要超出訓練數(shù)據(jù)的知識。 這就像是掌握基本做菜技能和精通特定菜系之間的區(qū)別, 兩者都需要基礎烹飪知識,但后者需要針對性學習以獲得更好的垂類結(jié)果。
幫模型獲得這種特定技能,有幾種方法:
In-context learning
Retrieval-based in-context learning
Fine-tuning based learning
5.1 In-context learning, e.g. ReAct
基于上下文學習:
- 原理:還是使用通用模型,但在推理時為模型提供提示詞、工具和示例,使模型其能夠“即時學習”如何以及何時為特定任務使用這些工具。
- 例子:
ReAct
框架。
5.2 Retrieval-based in-context learning, e.g. RAG
基于檢索的上下文學習:
- 原理:這種技術(shù)通過從外部存儲中檢索相關(guān)信息、工具和示例來動態(tài)填充模型提示詞。
- 例子:
RAG
架構(gòu)。
5.3 Fine-tuning based learning
基于微調(diào)的學習:
- 原理:用大量的特定示例對模型進行訓練(微調(diào)/精調(diào)),然后用微調(diào)過的模型進行推理。
- 好處:微調(diào)之后的模型在處理請求之前,已經(jīng)具備了何時以及如何使用某些工具的先驗知識。
5.4 再次與“廚師做飯”做類比
最后與廚師做飯再做個類比,加深理解:
方式 | 類比 |
---|---|
In-context learning | 廚師收到了一個特定的食譜(提示詞)、一些食材(相關(guān)工具)和一些示例菜肴(少量示例)?;谶@些信息和廚師已經(jīng)具備的常規(guī)烹飪知識,“即時學習”如何準備最符合菜單和客戶偏好的菜品。 |
Retrieval-based in-context learning | 廚房里有一個儲藏室(外部 Data Storage),里面有各種食材和食譜(示例和工具)。廚師可以從儲藏室中自主選擇更符合用戶飲食偏好的食材和食譜,做出讓用戶更滿意的菜品。 |
Fine-tuning based learning | 把廚師送回學校學習新的菜系(在大量的特定示例數(shù)據(jù)集上進行訓練)。如果希望廚師在特定菜系(知識領域)中表現(xiàn)出色,這種方法非常合適。 |
每種方法在速度、成本和延遲方面都各有優(yōu)缺點,需要看實際需求組合使用。
6 基于 LangChain 快速創(chuàng)建 Agent
本節(jié)來看下如何基于 LangChain 和 LangGraph 構(gòu)建一個 Agent 快速原型。 這些開源庫允許用戶通過“串聯(lián)”邏輯、推理和工具調(diào)用序列來構(gòu)建客戶 Agent。
6.1 代碼
from langgraph.prebuilt import create_react_agent
from langchain_core.tools import tool
from langchain_community.utilities import SerpAPIWrapper
from langchain_community.tools import GooglePlacesTool
os.environ["SERPAPI_API_KEY"] = "XXXXX"
os.environ["GPLACES_API_KEY"] = "XXXXX"
@tool
def search(query: str):
"""Use the SerpAPI to run a Google Search."""
search = SerpAPIWrapper()
return search.run(query)
@tool
def places(query: str):
"""Use the Google Places API to run a Google Places Query."""
places = GooglePlacesTool()
return places.run(query)
model = ChatVertexAI(model="gemini-1.5-flash-001")
tools = [search, places]
query = "Who did the Texas Longhorns play in football last week? What is the address of the other team's stadium?"
Agent = create_react_agent(model, tools)
input = {"messages": [("human", query)]}
for s in Agent.stream(input, stream_mode="values"):
message = s["messages"][-1]
if isinstance(message, tuple):
print(message)
else:
message.pretty_print()
其中用到的工具包括:
- SerpAPI(用于 Google 搜索)
- Google Places API。
6.2 運行效果
=============================== Human Message ================================
Who did the Texas Longhorns play in football last week? What is the address of the other team's stadium?
================================= Ai Message =================================
Tool Calls: search
Args:
query: Texas Longhorns football schedule
================================ Tool Message ================================
Name: search
{...Results: "NCAA Division I Football, Georgia, Date..."}
================================= Ai Message =================================
The Texas Longhorns played the Georgia Bulldogs last week.
Tool Calls: places
Args:
query: Georgia Bulldogs stadium
================================ Tool Message ================================
Name: places
{...Sanford Stadium Address: 100 Sanford...}
================================= Ai Message =================================
The address of the Georgia Bulldogs stadium is 100 Sanford Dr, Athens, GA 30602, USA
雖然這是一個很簡單的 Agent,但它展示了模型、編排和工具等基礎組件如何協(xié)同工作以實現(xiàn)特定目標。
6.3 使用 Google Vertex AI Agent 創(chuàng)建生產(chǎn)應用
最后,我們來看看這些組件如何在像 Vertex AI Agent 和生成式劇本這樣的 Google 規(guī)模的托管產(chǎn)品中結(jié)合在一起。
Figure 15. Sample end-to-end agent architecture built on Vertex AI platform
7 總結(jié)
本文討論了生成式 AI Agent 的基礎構(gòu)建模塊及工作原理。一些關(guān)鍵信息:
- Agent 可以利用工具來擴展語言模型的能力,
- 擴展的能力包括:訪問實時信息、建議現(xiàn)實世界的行動以及自主規(guī)劃和執(zhí)行復雜任務。
- Agent 可以利用語言模型來決定何時以及如何轉(zhuǎn)換狀態(tài),并使用外部工具完成任意數(shù)量的復雜任務,這些任務對于模型單獨完成來說是困難甚至不可能的。
- Agent 的核心是編排層,
- 這是一個認知架構(gòu),它結(jié)構(gòu)化了推理、規(guī)劃、決策并指導其行動。
- 各種推理技術(shù),如 ReAct、Chain-of-Thought 和 Tree-of-Thoughts,為編排層提供了一個框架,以接收信息、進行內(nèi)部推理并生成決策或響應。
- 工具作為 Agent 通往外部世界的關(guān)鍵,使 Agent 能夠與外部系統(tǒng)互動,以及讓模型獲取在它的訓練數(shù)據(jù)之外的知識。
- Extensions 為 Agent 與外部 API 之間提供了一個橋梁,使 Agent 能完成實時 API 調(diào)用和實時信息檢索。
- Functions 使 Agent 能夠生成可以在客戶端執(zhí)行的函數(shù)代碼,為開發(fā)人員提供了更精細的控制。
- Data Stores 為 Agent 提供了訪問結(jié)構(gòu)化或非結(jié)構(gòu)化數(shù)據(jù)的能力,使數(shù)據(jù)驅(qū)動的應用程序成為可能。
本文對 Agent 的探索還非常淺顯和初級,Agent 的未來將非常激動人心。 隨著工具變得更加復雜,推理能力得到增強,Agent 將被賦予解決現(xiàn)實生活中越來越復雜的問題的能力。
此外,“Agent chaining” 也將是一個戰(zhàn)略性方向, 通過結(jié)合 specialized Agents —— 每個 Agent 在其特定領域或任務中表現(xiàn)出色 —— 可以創(chuàng)建一種 “mixture of Agent experts”(混合智能體專家)的方法,能夠在各個行業(yè)和問題領域中提供卓越的性能。
最后需要說明,復雜的 Agent 架構(gòu)并不是一蹴而就的,需要持續(xù)迭代(iterative approach)。 給定業(yè)務場景和需求之后,不斷的實驗和改進是找到解決方案的關(guān)鍵。
Agents 底層都是基于基座大模型,而后者的生成式性質(zhì)決定了沒有兩個 Agent 是相同的。 但是,只要利用好這些基座模型,我們可以創(chuàng)建出真正有影響力的應用程序, 這種應用程序極大擴展了語言模型的能力,帶來了真實的現(xiàn)實世界價值。
參考資料
- Shafran, I., Cao, Y. et al., 2022, ReAct: Synergizing Reasoning and Acting in Language Models
- Wei, J., Wang, X. et al., 2023, Chain-of-Thought Prompting Elicits Reasoning in Large Language Models
- Wang, X. et al., 2022, Self-Consistency Improves Chain of Thought Reasoning in Language Models
- Diao, S. et al., 2023, Active Prompting with Chain-of-Thought for Large Language Models
- Zhang, H. et al., 2023, Multimodal Chain-of-Thought Reasoning in Language Models
- Yao, S. et al., 2023, Tree of Thoughts: Deliberate Problem Solving with Large Language Models
- Long, X., 2023, Large Language Model Guided Tree-of-Thought
- Google, Google Gemini Application
- Swagger, OpenAPI Specification
- Xie, M., 2022, How does in-context learning work? A framework for understanding the differences from traditional supervised learning
- Google Research, ScaNN (Scalable Nearest Neighbors)
- LangChain, LangChain