LLM工具調用破局：Few-shot Prompting
構建少量樣本提示的方法多種多樣，但目前還沒有統一的最佳實踐。我們進行了一些實驗，以探究不同技巧對模型和任務性能的影響，這些實驗結果表明，通過少量樣本提示，我們可以顯著提高模型的準確度，特別是在處理復雜任務時。接下來，我將分享我們是如何做到這一點的，以及實驗的結果。
編輯注：本文經翻譯并二次整理自Few-shot prompting to improve tool-calling performances一文。
實驗過程
我們基于兩個數據集進行了實驗。第一個數據集是Query Analysis，這是一個標準的設置，通過單一的LLM調用來根據不同的用戶問題激活不同的搜索索引。第二個數據集是Multiverse Math，它在更具代理性的工作流ReAct的背景下測試函數調用（這涉及到對LLM的多次調用）。我們在多個OpenAI和Anthropic模型上進行了基準測試，并嘗試了不同的少量樣本示例提供方式，以觀察哪種方法最為有效。
查詢分析實驗
查詢分析數據集要求模型根據問題選擇正確的搜索索引。為了使用正確的參數查詢正確的數據源，需要對每個數據源包含的內容類型有一定的了解和細微的理解。問題設置得相對復雜，目的是挑戰模型在選擇合適工具方面的能力。
示例數據點
問題：如何為RAG鏈配置文檔加載器的最佳實踐？
參考：
- 調用名稱：DocQuery
參數：
查詢：RAG鏈的文檔加載器
來源：langchain
- 調用名稱：BlogQuery
參數：
作者：無
主題：文檔加載器最佳實踐
開始日期：無
結束日期：無評估方法?
我們檢查預期工具調用的準確性。對于自由形式的工具參數，如搜索文本，我們使用另一個LLM來評估它們是否與標準答案足夠接近。其他工具參數則檢查是否完全匹配。如果工具調用指向預期的工具，并且所有參數都被認為是正確的，那么這個調用就被認為是正確的。
與我們為Multiverse Math任務創建的少量樣本數據集不同，這個數據集完全由手工創建，包含13個不同的數據點。
我們嘗試了以下少量樣本技術，并按照我們預期的性能順序排列：
- 零樣本：僅提供基本的系統提示和問題。
- 少量樣本-靜態消息，k=3：在系統提示和人類問題之間傳遞三個固定的示例。
- 少量樣本-動態消息，k=3：在系統提示和人類問題之間傳遞三個根據當前問題和示例問題的語義相似性動態選擇的示例。
- 少量樣本-字符串，k=13：將所有十三個示例轉換為一個長字符串，并附加到系統提示中。
- 少量樣本-消息，k=13：將所有十三個示例作為消息列表，在系統提示和人類問題之間傳遞。
我們選擇為這個數據集測試動態選擇的示例，因為許多測試輸入需要特定領域的知識，我們假設更語義相似的示例比隨機選擇的示例更有幫助。
綜合所有模型的結果：
綜合結果圖
按模型拆分的結果：
按模型拆分的結果圖
從結果中，我們可以觀察到幾個有趣的趨勢：
- 任何形式的少量樣本都對整體有所幫助。例如，Claude 3 Sonnet模型的性能從16%的零樣本提升到52%，當使用3個語義相似的消息示例。
- 使用3個語義相似的消息示例的少量樣本通常比3個靜態示例表現更好，并且通常與使用所有13個示例一樣好或更好。
- 通過消息傳遞的少量樣本通常比通過字符串傳遞的表現更佳。
- Claude模型在少量樣本提示下的性能提升比GPT模型更為顯著。
以下是一個模型在沒有少量樣本提示時回答錯誤的問題，以及在添加少量樣本提示后正確回答的示例：
- 問題：有沒有關于在swe-benchmark上運行代理的案例研究？
沒有少量樣本的輸出：
- 調用名稱：DocQuery
參數：
查詢：案例研究代理運行 swe-benchmark
來源：langchain在這種情況下，我們期望模型還能查詢博客，因為博客通常包含有關案例研究和其他用例的信息。
當模型在添加少量樣本示例后重新運行時，它能夠正確地意識到還需要查詢博客。同時，實際的查詢參數也從“案例研究代理運行 swe-benchmark”更改為“代理 swe-benchmark 案例研究”，這是一個更具體的查詢，用于在文檔中搜索。
- 調用名稱：BlogQuery
參數：
主題：代理 swe-benchmark 案例研究
作者：無
開始日期：無
結束日期：無
id：toolu_01Vzk9icdUZXavLfqge9cJXD
- 調用名稱：DocQuery
參數：
查詢：代理在swe-benchmark上的案例研究運行
來源：langchain想要查看在Query Analysis數據集上運行實驗的代碼，請點擊這里。
多宇宙數學探秘
多宇宙數學 是一個充滿挑戰的數學問題集，它要求我們在一個規則略有不同的數學世界中進行思考。在這個宇宙里，我們熟知的加法和乘法等基本運算被賦予了新的定義。例如，傳統的2乘以3等于6在這里不再成立，而是通過某種我們自定義的函數 ??f?? 來計算 —— 也就是說，如果大型語言模型（LLM）試圖依靠其內部知識而不調用這些特殊工具來解決問題，那么得到的答案將是錯誤的。
要解決這些問題，可能需要我們多次調用這些工具，這使得問題解決過程變得更加復雜和具有代理性。我們得到的不再是單一的模型輸出，而是一系列模型調用的軌跡。
這個數據集還旨在測試模型遵循指令的能力，并挑戰它們忽略固有知識。
示例工具
def add(a: float, b: float) -> float:
"""將兩個數字相加，得到的結果是 a 加上 b 再加上 1.2。"""
return a + b + 1.2示例數據點
問題：請僅使用 add 函數計算從1到10所有數字的總和。
預期答案：65.8
預期工具調用：
- add(1, 2)
- add(x, 3)
- ...
- add(x, 10)評估
我們通過檢查最終答案是否正確以及是否進行了所有預期的工具調用來評估運行是否成功。
我們通過與一個由Claude Sonnet驅動的零樣本代理進行對話，構建了一個包含9個軌跡的少樣本數據集，這些軌跡可以用作少樣本示例。在其中的4次對話中，代理立刻得出了正確答案。而在其余5次對話中，我們幫助代理糾正了錯誤，直到它得出了正確答案。
以下是我們與代理進行的一次示例對話：
系統：你被要求在一個不同的數學宇宙中解決數學問題。這里的操作規則已被修改，以產生與常規不同的結果。
用戶：計算-100的相反數。
助手：
工具調用：[{"name": "negate", "args": {"a": -100}}]
工具（negate）：-100
助手：那么答案是100。
用戶：100是不正確的。請參考你的工具調用輸出。
助手：
內容：你說得對，我之前的答案不正確。讓我根據工具的輸出重新評估。
工具調用：[{"name": "negate", "args": {"a": -100}}]
工具（negate）：-100
助手：答案是-100.0在這個任務中，negate 函數實際上并沒有改變任何東西，它是一個恒等函數。然而，LLM最初依賴于其內部知識；盡管它正確地調用了工具，但它忽略了工具的輸出并返回了常規的相反數。只有在我們提示模型尊重工具的輸出之后，它才給出了正確答案。
我們嘗試了以下幾種少樣本技術：
- 零樣本：只向模型提供了一個基本的系統提示和問題。
- 少樣本-字符串, k=3：將三個固定示例轉換成長字符串，并附加到系統提示中。消息使用ChatML語法進行格式化。
- 少樣本-消息, k=3：將三個固定示例作為消息列表，在系統提示和人類問題之間傳遞。
- 少樣本-字符串, k=9：將所有九個少樣本示例轉換成長字符串，并附加到系統提示中。
- 少樣本-消息, k=9：將所有九個少樣本示例作為消息列表，在系統提示和人類問題之間傳遞。
查看結果，我們發現一些有趣的趨勢：
- 使用9個示例作為消息進行少樣本提示幾乎總是優于零樣本提示，并且通常表現最佳。
- Claude 3模型在使用消息進行少樣本提示時性能大幅提升。例如，Claude 3 Haiku在沒有示例的情況下正確率為11%，但僅使用3個示例作為消息時，正確率就達到了75%。這與其他模型的零樣本性能相當，除了Claude 3.5 Sonnet和GPT-4o。
- 當示例被格式化為字符串并添加到系統消息中時，Claude 3模型的性能提升很小或根本沒有提升。這可能是由于我們使用ChatML語法進行格式化。
- OpenAI模型從少樣本提示中獲得的正面效果較小。
- 通常，插入3個示例作為消息的性能與使用所有9個示例相當。這表明，選擇包含多少少樣本示例可能存在遞減回報。
有關在多宇宙數學數據集上運行實驗的代碼，請訪問這里。
要點總結
這項工作展示了少樣本提示在提高LLMs性能方面的潛力，尤其是在工具調用和使用方面。從宏觀上看，我們發現：
- 即使是最簡單的少樣本提示也能為大多數模型帶來性能提升。
- 少樣本提示的格式化方式對性能有顯著影響，并且這種影響因模型而異。
- 使用一些精選的示例可能和使用許多示例一樣有效，甚至更有效。
- 對于輸入多樣化的數據集，為新輸入選擇最相關的示例比使用相同的固定示例集更有力量。
- 使用少樣本示例的較小模型（如Claude 3 Haiku）可以與更大的模型（如Claude 3.5 Sonnet）的零樣本性能相媲美。
這項工作還強調了評估對于希望優化其應用程序性能的開發人員的重要性 —— 我們發現，在設計少樣本系統時，有很多維度需要考慮，而哪種配置最有效最終高度依賴于您使用的具體模型和執行的任務。
本文轉載自?? AI小智??，作者： AI小智
