2025年4月6日 星期日

LLM 呼叫外部工具的機制

大型語言模型（LLM）可以透過特殊的輸出格式來觸發外部工具，以延伸自身能力（例如取得最新資訊或進行精確計算）。OpenAI 最新提供的 Function Calling 架構正是此類機制的代表，而 LangChain 框架也有常見的工具（Tool）與代理（Agent）實作。以下將從原理、流程、通訊方式、決策機制、應用場景以及策略等方面，條列說明 LLM 如何呼叫外部工具的運作方式：

1. LLM 呼叫工具的原因與底層機制

  • 延伸模型能力：透過呼叫外部工具，LLM 能取得自身知識範圍外的資料或執行特定操作，例如查詢即時資訊、計算複雜數學等。這種作法將 LLM 的語言理解能力與外部程式的功能結合，可更可靠地連結模型與外部工具或 API (Function calling and other API updates | OpenAI)。模型將工具調用視為對話的一部分，以「輸出特殊格式的內容」來表示工具請求，而非模型直接執行操作 (Tool/function calling | ️ LangChain)。外部系統收到這種特殊輸出後，會據此決定進行實際的函式調用或 API 請求。
  • 語言輸出觸發機制：LLM 經過適當訓練和提示，會以結構化的語言格式提出工具使用請求。OpenAI 的方法是讓模型輸出一個 JSON 結構，內含要呼叫的函式名稱與參數 (Function calling and other API updates | OpenAI)。例如，對於「波士頓今天天氣如何？」這類問題，模型會產生一個 function_call JSON（如 {"name": "get_current_weather", "arguments": {"location": "Boston", "unit": "celsius"}}），指示系統應呼叫 get_current_weather 函式並傳入相應參數 (Function calling and other API updates | OpenAI)。在 LangChain 的典型實作中，模型則會依照預先約定的文字格式輸出工具名稱和參數。例如 ReAct 代理會讓模型輸出類似：Action: Search 與 Action Input:「查詢關鍵字」 來表明使用搜尋工具。
  • 底層支持與模型訓練：OpenAI 的 GPT-4-0613、GPT-3.5-turbo-0613 等模型經過微調訓練，能判斷何時需要呼叫函式，並以正確的 JSON 格式給出函式名稱和參數 (Function calling and other API updates | OpenAI)。也就是說，模型本身被強化學會辨識使用者需求是否超出自身知識或能力範圍，以及如何根據提供的函式定義來構造工具調用的參數 (LangChain的函数，工具和代理(一)：OpenAI的函数调用_langchain openai-CSDN博客)。例如，當使用者詢問天氣或需要計算時，模型會傾向輸出函式呼叫，而非直接編造答案。模型的這種能力是藉由在大量範例上學習特殊格式輸出實現的 (Function calling and other API updates | OpenAI)。
  • 模型不直接執行工具：重要的是，LLM 並非真的執行外部工具程式碼，而只是透過文字或結構化輸出表達「希望執行某工具」的意圖 (Tool/function calling | ️ LangChain)。真正的函式/工具呼叫由外部系統（例如應用的後端程式）負責執行。換言之，LLM 扮演決策者和參數提供者的角色，會產生所需的工具名稱及輸入參數，而實際行動由系統代為完成 (Tool/function calling | ️ LangChain)。這種清晰區隔確保了安全控制：模型擅長決定做什麼，開發者掌控實際怎麼做。

2. 辨識需求到完成工具呼叫的流程

LLM 從辨識使用者需求到最終完成工具呼叫，大致經歷以下步驟：

  1. 定義可用工具：在對話開始或系統初始化時，開發者會先定義外部工具的介面。例如在 OpenAI Function Calling 機制中，開發者透過參數提供可用函式的描述列表（functions），包含函式名稱、說明和參數結構 (LangChain的函数，工具和代理(一)：OpenAI的函数调用_langchain openai-CSDN博客)。以下是一個函式描述 JSON 範例：

    [
  {
    "name": "get_current_weather",
    "description": "Get the current weather in a given location",
    "parameters": {
      "type": "object",
      "properties": {
        "location": {"type": "string", "description": "City name"},
        "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
      },
      "required": ["location"]
    }
  }
]

    這段定義告訴模型有一個名為 get_current_weather 的工具可用，以及它需要的參數（例如地點和單位）。在 LangChain 等代理框架中，則通常以提示模板的方式列出工具清單和用法範例，供模型參考。

  2. 提供使用者請求與工具資訊給模型：接著，將使用者的提問（user message）與上述工具清單一起發送給 LLM。以 OpenAI API 為例，可以呼叫 ChatCompletion.create 時傳入 messages（對話訊息）以及前述 functions 列表 (LangChain的函数，工具和代理(一)：OpenAI的函数调用_langchain openai-CSDN博客)。模型此時知道有哪些工具可用以及它們的用途。
  3. 模型分析需求決定策略：LLM 根據使用者的問題內容，判斷是否需要使用外部工具來得出答案。如果模型（依訓練或提示）覺得自身知識足以回答，且不需要即時查詢/計算，就可能直接產生答案。反之，如果偵測到問題涉及即時資訊、精確計算或数据库查詢等，它會決定使用對應的工具 (Function calling and other API updates | OpenAI)。這個決策過程在 OpenAI 模型中是隱含的（模型被微調來做出選擇），在 LangChain 代理中則體現在模型輸出的「Thought 思考步驟」中。
  4. 模型生成工具呼叫指令：當決定使用工具時，模型會輸出特定格式的內容以請求工具執行：
    • OpenAI Function Calling 情況：模型的回答中會帶有一個function_call欄位，包含所選函式名稱和參數（JSON 形式）。例如: "function_call": { "name": "get_current_weather", "arguments": "{ \"location\": \"上海\", \"unit\": \"celsius\" }" } (LangChain的函数，工具和代理(一)：OpenAI的函数调用_langchain openai-CSDN博客)。此時回傳的 role 仍是 "assistant" 但內容被結構化為函式呼叫而非一般文字回答。注意：模型完全按照預先提供的參數結構產生 JSON，以確保開發者可解析執行 (Function calling and other API updates | OpenAI)。
    • LangChain 代理情況：模型輸出遵循約定的文字格式，例如： 
      Thought: 我需要查詢天氣資訊
Action: get_current_weather
Action Input: 上海
      其中 Action 行表明選擇的工具名稱，Action Input 行給出參數。代理程式會解析這段文字提取出工具名稱與輸入。
  5. 系統執行外部工具：外部系統（由開發者控制）在解析到模型的工具請求後，會呼叫對應的函式或 API。例如，偵測到 function_call 要求 get_current_weather，則程式會真正去執行 get_current_weather(location="上海", unit="celsius") 這個函式，并取得結果 (LangChain的函数，工具和代理(一)：OpenAI的函数调用_langchain openai-CSDN博客)。在 LangChain 中，代理類別會根據模型輸出的 Action，找到對應的工具函數並以提供的輸入參數執行。這一步通常涉及標準的編程調用（例如 Python 函式呼叫）或發送 HTTP 請求到外部API等。
  6. 取得工具結果並返回模型：工具執行完畢後會回傳結果給外部系統。系統接著將結果提供給 LLM，方式視框架而定：
    • 在 OpenAI ChatCompletion API 中，將結果封裝為一則新的對話訊息，role 設為 "function"，name 為函式名稱，content 包含函式執行的結果（通常是 JSON 或簡短文字）。然後把此消息追加到對話歷史中，再次調用 ChatCompletion，讓模型得知工具執行結果並產生後續回答。
    • 在 LangChain 代理中，則會將結果內容作為觀察值（Observation）附加到對話上下文。例如追加一行：Observation: {"location": "上海", "temperature": "22", "unit": "celsius", "forecast": ["sunny","windy"]}。模型在下一輪對話中能看到這個結果，據此進行推理。
  7. 模型利用結果產生最終回答：LLM 獲得工具提供的外部資訊後，會將之融入自身知識，產生解答並以自然語言回答使用者。由於模型把工具結果視為對話的一部分，因此它會根據結果和原提問來生成答覆。例如，對於天氣查詢，模型可能回答：「上海目前氣溫22°C，天氣晴朗且有微風。」這階段模型輸出的內容即為最終回答（role=assistant，內容為正常文字），不再包含函式呼叫語法。
  8. 迭代調用（如需）：在某些複雜情況下，模型可能需要連續呼叫多個工具或多次呼叫同一工具才能取得答案。例如先用搜尋工具找資料，再用計算工具處理數據。此時對話會在工具調用和結果返回之間循環多次（重覆步驟4–7），直到模型足以給出答案為止 (Tool/function calling | ️ LangChain)。OpenAI 的模型每次回答最多觸發一次函式呼叫，但透過多輪對話可以實現多步工具鏈；LangChain 代理則天然支援模型在同一次任務中多次輸出Action進行循環。整個流程由模型自行判斷何時停止呼叫工具並給出Final Answer終局回答。

3. LLM 與工具互動的通訊協定與技術實作

  • OpenAI Function Calling 通訊方式：OpenAI 提供在 ChatCompletions API 中使用 functions 和 function_call 參數的能力，這實際上是一種結構化的通訊協定。開發者以 JSON Schema 格式將可用函式的名稱、參數類型、描述等傳遞給模型 (Function calling and other API updates | OpenAI)。模型若決定呼叫函式，會在回傳訊息中給出對應的 function_call 欄位，其內容包含 name（函式名）和 arguments（JSON字串形式的參數）。這種定義和回傳方式，透過嚴格的 JSON 格式，讓開發者可以程式化地解析模型輸出並決定調用哪個外部函式 (LangChain的函数，工具和代理(一)：OpenAI的函数调用_langchain openai-CSDN博客)。模型遵循 JSON Schema 的定義生成參數，確保類型和欄位齊全 (Function calling and other API updates | OpenAI)。整個互動流程基於 HTTP API 請求實現：開發者->OpenAI API (附函式列表和使用者訊息)，模型->開發者 (含函式呼叫的回應)，開發者->外部函式/服務 (依據回應進行實際呼叫)，開發者->OpenAI API (傳回函式結果作為新的訊息)，模型->開發者 (最終答案)。因此，LLM 與工具並非直接通信，而是經由開發者的伺服器作為中介來完成資料傳遞。
  • LangChain 工具調用實作：在 LangChain 等框架下，工具通常封裝為Python函式或API調用的抽象介面，並由一個 Agent (代理) 驅動 LLM 使用這些工具。LangChain 先以系統提示提供工具列表及其説明給模型，並制定輸出格式（如 Action/Action Input 形式）。模型按照此格式輸出後，LangChain 代理會解析出要執行的工具名稱和參數，透過框架內建的方法調用對應的函式（這在技術上只是一般的函式呼叫或網路 API 請求）。執行結果再由代理以新的觀察訊息形式提供給模型。LangChain 的通訊協定本質上基於對話文字串：約定某些關鍵字來區分工具名稱、輸入和觀察。例如，輸出中出現“Action:”表示後面是工具識別碼，“Action Input:”後面是參數; 系統收到這些標誌後做相應處理 (langchain-ai/react-agent-template Public - LangSmith)。雖然實現方式不同，但目的同樣是讓模型輸出可解析的結構給系統執行。
  • API 調用與函式執行：不論使用何種框架，真正的工具執行通常透過兩種途徑之一：
    1. 調用本地函式（Function Call）：例如在 Python 應用中直接呼叫先前定義的函式，將模型提供的參數傳入。在上例中，模型要求 get_current_weather，程式就直接執行 get_current_weather("上海", unit="celsius") 並取得結果 (LangChain的函数，工具和代理(一)：OpenAI的函数调用_langchain openai-CSDN博客)。這種方式適合封裝好在本地執行的邏輯（如資料庫查詢、計算模組等）。
    2. 調用外部API：許多工具實際上是網路服務，需透過 HTTP 請求取得資料（例如天氣服務的 REST API）。模型可能輸出需要查詢的參數（如城市名稱），系統接著構造HTTP請求調用外部API，將回傳結果（通常為 JSON）提供給模型。這方面與傳統的後端服務調用相同，只是參數由LLM決定。值得注意的是，開發者需對這些外部API的安全性和可靠性負責，包括防止將不可信的輸出直接餵回模型導致誤動作 (Function calling and other API updates | OpenAI)。
  • 通訊內容格式：在模型與工具互動時，使用標準化的資料格式十分重要。例如 OpenAI 遵循 JSON Schema 讓模型產生 JSON 參數，而非自由文本，這提高了結構化數據的可靠性 (Function calling and other API updates | OpenAI)。再如資料庫查詢的場合，模型會產生 SQL 字串作為參數傳給預先定義的查詢函式。總之，透明且機器可讀的格式方便系統解析與執行。同時，對於模型返回的工具結果，開發者也需以模型容易理解的形式嵌入對話（通常直接用純文本或 JSON 字串）。良好的協定設計確保了模型-工具-系統三方在整個調用過程中的資訊一致與正確解析。

4. 工具調用的決策機制：何時及如何呼叫哪個工具

5. 常見實務應用場景及用例實作差異

透過工具調用，LLM 可以實現許多實用功能。不同場景下工具的實作方式和與模型互動細節各有差異，以下列出幾個常見用例：

  • 數學計算（Calculator）：針對較複雜或要求高精度的數值計算，LLM 可呼叫計算工具而非依賴自身估算。實作上，可以提供一個 calculator 函式或數學引擎 API，接受數學表達式或操作數作為參數。模型在遇到數學問題時會將算式作為參數傳給計算工具，確保結果精確無誤。例如 LangChain 就提供內建的計算工具，允許模型透過此工具完成算術運算 (Building Custom Tools for LLM Agents - Pinecone)。由於模型常被指示「不擅長心算，需使用計算器」來避免錯誤 (Tool/function calling | ️ LangChain)，因此一旦偵測到計算需求便會觸發工具。計算工具通常是一次性函式調用：模型提供表達式->工具返回結果，即可直接用於回答，無需多輪交互。
  • 網路搜尋（Web Search）：當使用者問的是即時資訊或模型知識截止後的新知識（如新聞、天氣、股價等），LLM 可透過搜尋工具獲取最新資料。實作上常見的是一個 search 函式或類似瀏覽器的插件，模型傳入查詢關鍵字，工具返回相關網頁摘要或結果列表。與計算不同的是，搜尋可能需要多步交互：模型第一次用適當關鍵字搜索，拿到結果後再決定是否需要進一步搜尋或從結果中提取答案。例如，ChatGPT Plugin 就提供了Browser搜尋的功能讓模型可以自主進行網路查詢 (Function calling and other API updates | OpenAI)。在 LangChain 代理中，模型可能交替進行「Search」動作和閱讀結果的思考，直至找到答案。實作時要注意結果的長度與格式：可能需要截斷或摘要網頁內容，再提供給模型。搜尋工具使模型能回答超出訓練資料範圍的問題，但同時要防止模型過度依賴搜尋而忘記自身知識。
  • 資料查詢與API調用：很多問題涉及查詢特定資料或使用現有服務，例如天氣查詢、貨幣匯率、翻譯、地理位置等。這類場景通常有現成的外部API可供調用。例如天氣服務API、翻譯API等。開發者可以將這些服務封裝成函式（如 get_current_weather(location) 或 translate(text, target_lang)），讓模型直接輸出對應的函式呼叫。模型會根據使用者的請求自動填入所需參數並呼叫該API (Function calling and other API updates | OpenAI)。實作關鍵在於確保模型輸出符合API需求格式，如城市名稱要精確、語言代碼正確等。如果使用者問：「明天紐約的天氣如何？」模型可能呼叫 get_weather("New York", "2025-03-30") 並得到預報，再將結果整理回覆。這類資料查詢通常一次函式調用即可獲得答案（除非API本身需要先後多個步驟認證等）。和搜尋不同，這類工具返回的就是所需資訊而非大量文本，因此模型只需對結果做適當措辭轉換即可回答。
  • 裝置操作與副作用任務：LLM 還可以透過工具對現實世界執行操作或引發副作用，例如發送電子郵件、日曆排程、控制物聯網裝置（開燈、調節溫度）等。這些場景下工具往往是一個動作函式（如 send_email(to, subject, body) 或 set_thermostat(temp)）。模型輸出相應函式呼叫後，系統執行該動作，可能同時返回執行結果或確認訊息給模型。實作上特別需要注意安全：由於這類操作會改變外部狀態，開發者通常會實現二次確認或限制模型何時能直接執行。例如 OpenAI 建議對有現實影響的行為加入使用者確認步驟，避免模型被不可信輸入誤導去執行危險操作 (Function calling and other API updates | OpenAI)。在回答上，模型可能需要告知使用者操作已完成（例如「郵件已發送」）。與純查詢類工具不同，裝置操作類工具重在執行效果，因此模型的回答更多是對行動結果的描述或確認，而不涉及額外推理。開發者也應確保模型不會在不適當情況下自行呼叫此類工具（可透過 system message 調控）。
  • 資料庫問答（Database QA）：如果需要查詢內部資料庫（如企業數據、歷史紀錄），LLM 可使用資料庫查詢工具。常見方式是提供一個函式（如 query_db(query_string) 或更細緻的 find_customers(name) 等）讓模型傳入查詢語句。模型可能會產生SQL 查詢作為參數（例如將「上月下單量最多的前十位客戶是誰？」轉換成 SQL 查詢） (Function calling and other API updates | OpenAI)。系統執行該SQL並將結果回傳給模型。模型再據此生成口語化答案（例如列出客戶清單）。資料庫工具的實作難點在於：模型必須正確生成查詢語法並理解結果。為此通常會在 prompt 中提供資料庫結構資訊或一些範例查詢，幫助模型構造正確的語句。此外，為安全起見，後端在執行模型產生的SQL時可能加上只讀限制或使用預先定義的查詢模板，防止模型生成潛在危險的指令。相較其他工具，資料庫查詢往往涉及結構化資料，模型在得到查詢結果（通常是表格或記錄）後，需要進一步總結或篩選才能給出使用者易懂的答覆。在 LangChain 中，也有結合向量資料庫的問答工具（屬於知識檢索類），即模型先用一個檢索工具獲取相關文本段落，再根據這些段落作答，這也是資料庫問答的另一種形式，只是不產生SQL而是基於語意檢索的結果。

以上場景中，各自的工具可能在調用次數和資料形態上有所不同：如搜尋和資料庫查詢可能需要迭代、多次交互且返回大段文本，需要模型整合摘要；而計算、天氣這類通常一次返回一個結構化結果即可直接引用。此外，對於有副作用的操作（發郵件、控制裝置），開發者需要在人機介面上體現確認或執行情況，模型則需要適當地向用戶描述執行結果或後續步驟。

6. 模型自主回答 vs 呼叫外部工具的策略選擇

LLM 在每次回應時都面臨一個策略抉擇：直接產生回答還是呼叫外部工具取得資訊後再答覆。這種決策取決於以下考量與依據：

  • 問題需求匹配：模型首先判斷使用者的要求能否僅憑自身已知知識和推理能力解決。如果問題屬於模型訓練知識範圍（如歷史事實、語義解析、通用問答）且不要求最新資訊或精確計算，模型會傾向於自主回答，因為這樣速度最快且不增加系統開銷。相反，若問題明顯涉及模型未知的信息（如「最新股價」、「即時天氣」、「某網站的內容」）或需要高精度/繁瑣計算（如長算式、統計分析），模型則選擇呼叫工具以確保答案的可靠與完整 (Function calling and other API updates | OpenAI)。
  • 內部信心與不確定性：當模型對回答不確定或缺乏足夠信心時，也會傾向使用工具來驗證或查補資訊。例如使用者問「某科技公司今年第三季度的營收是多少？」模型可能記得某些數字但不確定準確性，這時如果有財報查詢工具可用，模型會趨向於調用它而非冒險直接回答錯誤資訊。同理，對模棱兩可或需要最新更新的問題，工具提供了權威資料來源，模型會優先使用以提高正確率 (Function calling and other API updates | OpenAI)。
  • 效率與成本考量：在某些情況下，即便模型有能力回答，也可能考慮效率選擇直接回答而不調用工具。例如簡單數字計算（2+2）模型其實能算出來且代價很低，則沒必要每次都呼叫計算器。同時，每次工具調用意味著額外的API請求或函式執行，會增加時間延遲與資源消耗。因此模型的策略通常是：能直接回答就不浪費工具調用，除非使用工具能大幅提升正確性或是唯一路徑。開發者也可在系統訊息中強化這種考量，例如明確告知模型「除非必要，否則避免不必要的工具使用」以平衡效率。
  • 系統指令與預設偏好：模型的行為很大程度上受系統指令影響。開發者可設定規則明確何種場合下一定要用工具或一定不要。例如，可在 system prompt 中指示：「當涉及日期/時間/最新資訊時必須使用搜尋工具；當涉及算術計算時必須使用計算器」 (Tool/function calling | ️ LangChain)。這樣模型在判斷時會偏向遵循預設策略行事。此外，若開發者設定 function_call="none"，模型就算知道有相關工具也會強制不使用，轉而嘗試自行回答或禮貌拒絕無法完成的請求 (LangChain的函数，工具和代理(一)：OpenAI的函数调用_langchain openai-CSDN博客)。反之，設為強制某工具時，模型會無論上下文都生成該工具調用 (LangChain的函数，工具和代理(一)：OpenAI的函数调用_langchain openai-CSDN博客)。因此實務中通常透過預先設定來調校模型使用工具的頻率與時機，使其符合應用需求。
  • 多輪對話中的動態決策：在持續對話中，模型會根據上下文動態調整策略。如果前一次工具調用已經獲得了關鍵資訊，那下一次回應時就沒有再次調用的必要。此外，模型可能會告知使用者一些可由工具提供的資訊，然後等待使用者確認是否需要細節（這給了人類機會決定是否讓模型用工具深挖）。總之，模型會權衡對話目標是否已達成來決定是否還需要工具輔助。在理想情況下，模型只會在必要且有利的情境下調用工具，並在取得足夠資訊後立即回到由模型產生答案的模式。

綜上，LLM 透過 OpenAI Function Calling 等框架，能夠智慧地在自主回答與工具調用之間切換：當問題在掌控中時直接回答，超出知識或能力範圍時則調用外部工具輔助。這種策略讓模型既保持高效率，又能擴展功能邊界，在各種應用場景下提供準確且實用的回應 (Function calling and other API updates | OpenAI) (Function calling and other API updates | OpenAI)。

於
標籤： , , ,

The Era of Experience 導讀

1. 研究動機與核心主張（摘要／第 1 頁） 動機 ：當前主流 AI 依賴大規模「人類資料」──包括文字、程式碼與標註──透過模仿與人類偏好微調（RLHF）取得跨領域能力。然而在人類尚未涉足、或資料已枯竭的領域（如尖端數學、科學發現）出現進...

  • [音響] SF-801 改機心得
    SF-801 是 HITON AUDIO  推出的 DIY 前管後晶耳擴。此耳擴使用 42V 的直流電源，實測 Vpp 可以到達 20V 左右，故十分適合拿來推大阻抗耳機，比如說 SENNHEISER HD800 之流。最重要的是他的售價相當便宜，只需要台幣 3K 左右，...
  • [音響] 真空管屏蔽實驗
    真空管很容易被大氣中的電磁信號干擾，尤其是手機，特徵是會有 噠噠 或 嘶嘶 的聲音。最近被搞得不勝其擾，於是決定試試能否屏蔽掉這些惱人的雜訊。 以下是用來測試的管機，偉良的 E400。管子的組態是前面兩根12AX7信號管，後面兩根6V6功率管。兩根功率管本來就是軍規鐵殼，所以...