為 AI 代理賦能：函式呼叫與 RAG 的整合實踐

大型語言模型 (LLM) 本身是一個強大的語言產生器，但它被困在一個數位牢籠中：其知識截至訓練完成的那一刻，且它無法與外部世界進行任何互動。要將 LLM 提升為一個能解決實際問題的 AI 代理 (AI Agent)，我們必須為其賦予兩項核心能力：感知外部即時資訊，以及行動以執行具體任務。本文將深入探討實現這兩種能力的關鍵技術：資料儲存 (RAG) 與 函式呼叫 (Function Calling)，並展示如何將它們整合到一個統一的認知架構中。

一、賦予「行動」能力：函式呼叫 (Function Calling)

函式呼叫是讓 LLM 從一個「應答者」轉變為「行動決策者」的關鍵技術。它允許模型在分析使用者意圖後，不直接生成答案，而是輸出一份結構化的指令，要求客戶端應用程式去執行某個外部函式。

1. 函式呼叫的生命週期與優勢

這個流程的核心優勢在於控制權分離：

• 模型負責「決策」: 分析使用者意圖，決定應該呼叫哪個函式，並從對話中提取所需的參數。
• 客戶端負責「執行」: 接收模型的指令，實際執行本地或遠端的函式呼叫，並處理認證、錯誤和非同步操作。

這種設計帶來了極大的靈活性和安全性。例如，敏感的 API 金鑰可以安全地儲存在客戶端，而無需暴露給模型。

caption="圖表一：函式呼叫生命週期循序圖。此圖詳細描繪了從使用者提出請求到函式被呼叫並生成最終回應的完整互動流程。"
alt="一個展示函式呼叫生命週期的循序圖。使用者向 AI 模型提出請求，模型分析後決定呼叫某個函式，並將指令傳給客戶端應用。客戶端執行函式，可選地將結果回傳給模型，最後模型根據結果生成回應給使用者。"

@startuml
!theme _none_
skinparam dpi auto
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam minClassWidth 100
skinparam defaultFontSize 14
title 函式呼叫生命週期

actor "使用者" as User
participant "AI 模型 (LLM)" as Model
participant "客戶端應用" as Client

User -> Model : 提出請求\n(例如：幫我查台北的天氣)
Model -> Model : 分析請求，決定需呼叫\n`get_weather` 函式
Model -> Client : 回傳函式呼叫指令\n(名稱: get_weather, 參數: {city: "Taipei"})
Client -> Client : 接收指令，執行本地或遠端函式
Client -> Model : (可選) 回傳函式執行結果\n(例如：{temperature: "28°C"})
Model -> User : 根據函式結果生成最終回應
@enduml

2. 實作範例 (Vertex AI Gemini)

我們以一個滑雪旅行推薦的案例來展示函式呼叫的實作。首先，定義一個 Python 函式：

from typing import Optional

def get_ski_trip_recommendations(cities: list[str], preferences: Optional[str] = None):
    """根據使用者的搜尋查詢和偏好提供滑雪城市列表。"""
    print(f"根據您的偏好 '{preferences}'，推薦以下滑雪勝地: {', '.join(cities)}")
    return cities

接著，我們使用 Vertex AI 的 Gemini 模型，將此函式作為「工具」提供給它：

from vertexai.generative_models import GenerativeModel, Tool, FunctionDeclaration

model = GenerativeModel("gemini-1.5-flash-001")

# 從 Python 函式建立工具，讓模型知道這個工具的存在
ski_tool = Tool.from_function_declarations(
    [FunctionDeclaration.from_func(get_ski_trip_recommendations)]
)

# 使用者查詢
message = "我想和家人去滑雪旅行，但不確定去哪裡。"
# 在請求中提供工具
response = model.generate_content(message, tools=[ski_tool])

# 解析模型回傳的函式呼叫指令
function_call = response.candidates[0].content.parts[0].function_call
print(f"模型建議呼叫的函式: {function_call.name}")
print(f"模型生成的函式參數: {dict(function_call.args)}")

# 輸出:
# 模型建議呼叫的函式: get_ski_trip_recommendations
# 模型生成的函式參數: {'preferences': 'skiing', 'cities': ['Aspen', 'Vail', 'Park City']}

客戶端應用在收到這個結構化輸出後，便可安全地執行 get_ski_trip_recommendations 函式。

二、賦予「感知」能力：資料儲存與 RAG

函式呼叫解決了「行動」的問題，而檢索增強生成 (Retrieval Augmented Generation, RAG) 則解決了「感知」的問題。RAG 透過連接外部知識庫（通常是向量資料庫），讓模型能夠存取其訓練資料之外的、即時的、私有的資訊。

其工作流程通常是：

1. 查詢向量化: 將使用者查詢轉換為向量。
2. 向量檢索: 在知識庫中搜尋與查詢向量最相似的內容片段。
3. 內容增強: 將檢索到的內容片段與原始查詢一同注入到提示中。
4. 生成回應: 模型基於增強後的上下文生成更準確、更具體的回答。

三、整合與協調：AI 代理的認知架構

一個強大的 AI 代理，會將函式呼叫、RAG 等多種工具整合起來，並由一個協調層 (Orchestration Layer) 來統一管理和調度。這個協調層是代理的「大腦」，負責根據使用者目標，利用 ReAct、思維鏈 (Chain-of-Thought) 等推理框架，來規劃步驟並決定在何時使用何種工具。

caption="圖表二：AI 代理認知架構。此組件圖展示了一個整合了多種工具和推理框架的 AI 代理認知架構。"
alt="一個展示 AI 代理認知架構的組件圖。核心是協調層和 LLM，它們可以使用推理框架（如 ReAct）和工具集（如函式呼叫和資料儲存）。函式呼叫與外部 API 互動，資料儲存與向量資料庫互動。"

@startuml
!theme _none_
skinparam dpi auto
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam minClassWidth 100
skinparam defaultFontSize 14
title AI 代理認知架構

package "AI 代理核心" {
  [協調層 (Orchestration)] as Orchestrator
  [LLM] as LanguageModel
  
  package "推理框架" {
    [ReAct]
    [Chain-of-Thought]
  }
}

package "工具集 (Tools)" {
  [函式呼叫 (Actions)] as FuncCall
  [資料儲存 (Perception)] as DataStore
}

Orchestrator --> LanguageModel : 互動
Orchestrator --> ReAct : (選用)
Orchestrator --> Chain-of-Thought : (選用)

Orchestrator --> FuncCall : 決策使用
Orchestrator --> DataStore : 決策使用

FuncCall --> [外部 API/服務]
DataStore --> [向量資料庫]

@enduml

工具選擇策略

這兩種工具並非互斥。一個先進的客戶支援代理可能會同時使用：

• RAG 來存取產品手冊，回答「如何設定產品 A？」這類問題。
• 函式呼叫來查詢後端 API，回答「我的訂單狀態是什麼？」這類問題。

結論: AI 代理的強大之處在於其整合能力。透過將 LLM 的語言能力與函式呼叫的行動能力、RAG 的感知能力相結合，並由一個智慧的協調層進行統一管理，我們能夠建立出真正能夠自主規劃、決策和行動的智慧系統，從而將 AI 的應用從資訊檢索提升到參與並推動實際業務流程的全新高度。