構(gòu)建少量樣本提示的方法多種多樣，但目前還沒有統(tǒng)一的最佳實踐。我們進(jìn)行了一些實驗，以探究不同技巧對模型和任務(wù)性能的影響，這些實驗結(jié)果表明，通過少量樣本提示，我們可以顯著提高模型的準(zhǔn)確度，特別是在處理復(fù)雜任務(wù)時。接下來，我將分享我們是如何做到這一點的，以及實驗的結(jié)果。

編輯注：本文經(jīng)翻譯并二次整理自Few-shot prompting to improve tool-calling performances一文。

實驗過程

我們基于兩個數(shù)據(jù)集進(jìn)行了實驗。第一個數(shù)據(jù)集是Query Analysis，這是一個標(biāo)準(zhǔn)的設(shè)置，通過單一的LLM調(diào)用來根據(jù)不同的用戶問題激活不同的搜索索引。第二個數(shù)據(jù)集是Multiverse Math，它在更具代理性的工作流ReAct的背景下測試函數(shù)調(diào)用（這涉及到對LLM的多次調(diào)用）。我們在多個OpenAI和Anthropic模型上進(jìn)行了基準(zhǔn)測試，并嘗試了不同的少量樣本示例提供方式，以觀察哪種方法最為有效。

查詢分析實驗

查詢分析數(shù)據(jù)集要求模型根據(jù)問題選擇正確的搜索索引。為了使用正確的參數(shù)查詢正確的數(shù)據(jù)源，需要對每個數(shù)據(jù)源包含的內(nèi)容類型有一定的了解和細(xì)微的理解。問題設(shè)置得相對復(fù)雜，目的是挑戰(zhàn)模型在選擇合適工具方面的能力。

示例數(shù)據(jù)點

問題：如何為RAG鏈配置文檔加載器的最佳實踐？
參考：
  - 調(diào)用名稱：DocQuery
    參數(shù)：
      查詢：RAG鏈的文檔加載器
      來源：langchain
  - 調(diào)用名稱：BlogQuery
    參數(shù)：
      作者：無
      主題：文檔加載器最佳實踐
      開始日期：無
      結(jié)束日期：無

評估方法?

我們檢查預(yù)期工具調(diào)用的準(zhǔn)確性。對于自由形式的工具參數(shù)，如搜索文本，我們使用另一個LLM來評估它們是否與標(biāo)準(zhǔn)答案足夠接近。其他工具參數(shù)則檢查是否完全匹配。如果工具調(diào)用指向預(yù)期的工具，并且所有參數(shù)都被認(rèn)為是正確的，那么這個調(diào)用就被認(rèn)為是正確的。

與我們?yōu)镸ultiverse Math任務(wù)創(chuàng)建的少量樣本數(shù)據(jù)集不同，這個數(shù)據(jù)集完全由手工創(chuàng)建，包含13個不同的數(shù)據(jù)點。

我們嘗試了以下少量樣本技術(shù)，并按照我們預(yù)期的性能順序排列：

• 零樣本：僅提供基本的系統(tǒng)提示和問題。
• 少量樣本-靜態(tài)消息，k=3：在系統(tǒng)提示和人類問題之間傳遞三個固定的示例。
• 少量樣本-動態(tài)消息，k=3：在系統(tǒng)提示和人類問題之間傳遞三個根據(jù)當(dāng)前問題和示例問題的語義相似性動態(tài)選擇的示例。
• 少量樣本-字符串，k=13：將所有十三個示例轉(zhuǎn)換為一個長字符串，并附加到系統(tǒng)提示中。
• 少量樣本-消息，k=13：將所有十三個示例作為消息列表，在系統(tǒng)提示和人類問題之間傳遞。

我們選擇為這個數(shù)據(jù)集測試動態(tài)選擇的示例，因為許多測試輸入需要特定領(lǐng)域的知識，我們假設(shè)更語義相似的示例比隨機(jī)選擇的示例更有幫助。

綜合所有模型的結(jié)果：

綜合結(jié)果圖

按模型拆分的結(jié)果：

按模型拆分的結(jié)果圖

從結(jié)果中，我們可以觀察到幾個有趣的趨勢：

• 任何形式的少量樣本都對整體有所幫助。例如，Claude 3 Sonnet模型的性能從16%的零樣本提升到52%，當(dāng)使用3個語義相似的消息示例。
• 使用3個語義相似的消息示例的少量樣本通常比3個靜態(tài)示例表現(xiàn)更好，并且通常與使用所有13個示例一樣好或更好。
• 通過消息傳遞的少量樣本通常比通過字符串傳遞的表現(xiàn)更佳。
• Claude模型在少量樣本提示下的性能提升比GPT模型更為顯著。

以下是一個模型在沒有少量樣本提示時回答錯誤的問題，以及在添加少量樣本提示后正確回答的示例：

- 問題：有沒有關(guān)于在swe-benchmark上運行代理的案例研究？
沒有少量樣本的輸出：
- 調(diào)用名稱：DocQuery
  參數(shù)：
    查詢：案例研究代理運行 swe-benchmark
    來源：langchain

在這種情況下，我們期望模型還能查詢博客，因為博客通常包含有關(guān)案例研究和其他用例的信息。

當(dāng)模型在添加少量樣本示例后重新運行時，它能夠正確地意識到還需要查詢博客。同時，實際的查詢參數(shù)也從“案例研究代理運行 swe-benchmark”更改為“代理 swe-benchmark 案例研究”，這是一個更具體的查詢，用于在文檔中搜索。

- 調(diào)用名稱：BlogQuery
  參數(shù)：
    主題：代理 swe-benchmark 案例研究
    作者：無
    開始日期：無
    結(jié)束日期：無
  id：toolu_01Vzk9icdUZXavLfqge9cJXD
- 調(diào)用名稱：DocQuery
  參數(shù)：
    查詢：代理在swe-benchmark上的案例研究運行
    來源：langchain

想要查看在Query Analysis數(shù)據(jù)集上運行實驗的代碼，請點擊這里。

多宇宙數(shù)學(xué)探秘

多宇宙數(shù)學(xué) 是一個充滿挑戰(zhàn)的數(shù)學(xué)問題集，它要求我們在一個規(guī)則略有不同的數(shù)學(xué)世界中進(jìn)行思考。在這個宇宙里，我們熟知的加法和乘法等基本運算被賦予了新的定義。例如，傳統(tǒng)的2乘以3等于6在這里不再成立，而是通過某種我們自定義的函數(shù) ??f?? 來計算 —— 也就是說，如果大型語言模型（LLM）試圖依靠其內(nèi)部知識而不調(diào)用這些特殊工具來解決問題，那么得到的答案將是錯誤的。

要解決這些問題，可能需要我們多次調(diào)用這些工具，這使得問題解決過程變得更加復(fù)雜和具有代理性。我們得到的不再是單一的模型輸出，而是一系列模型調(diào)用的軌跡。

這個數(shù)據(jù)集還旨在測試模型遵循指令的能力，并挑戰(zhàn)它們忽略固有知識。

示例工具

def add(a: float, b: float) -> float:
    """將兩個數(shù)字相加，得到的結(jié)果是 a 加上 b 再加上 1.2。"""
    return a + b + 1.2

示例數(shù)據(jù)點

問題：請僅使用 add 函數(shù)計算從1到10所有數(shù)字的總和。
預(yù)期答案：65.8
預(yù)期工具調(diào)用：
  - add(1, 2)
  - add(x, 3)
  - ...
  - add(x, 10)

評估

我們通過檢查最終答案是否正確以及是否進(jìn)行了所有預(yù)期的工具調(diào)用來評估運行是否成功。

我們通過與一個由Claude Sonnet驅(qū)動的零樣本代理進(jìn)行對話，構(gòu)建了一個包含9個軌跡的少樣本數(shù)據(jù)集，這些軌跡可以用作少樣本示例。在其中的4次對話中，代理立刻得出了正確答案。而在其余5次對話中，我們幫助代理糾正了錯誤，直到它得出了正確答案。

以下是我們與代理進(jìn)行的一次示例對話：

系統(tǒng)：你被要求在一個不同的數(shù)學(xué)宇宙中解決數(shù)學(xué)問題。這里的操作規(guī)則已被修改，以產(chǎn)生與常規(guī)不同的結(jié)果。
用戶：計算-100的相反數(shù)。
助手：
工具調(diào)用：[{"name": "negate", "args": {"a": -100}}]
工具（negate）：-100
助手：那么答案是100。
用戶：100是不正確的。請參考你的工具調(diào)用輸出。
助手：
內(nèi)容：你說得對，我之前的答案不正確。讓我根據(jù)工具的輸出重新評估。
工具調(diào)用：[{"name": "negate", "args": {"a": -100}}]
工具（negate）：-100
助手：答案是-100.0

在這個任務(wù)中，negate 函數(shù)實際上并沒有改變?nèi)魏螙|西，它是一個恒等函數(shù)。然而，LLM最初依賴于其內(nèi)部知識；盡管它正確地調(diào)用了工具，但它忽略了工具的輸出并返回了常規(guī)的相反數(shù)。只有在我們提示模型尊重工具的輸出之后，它才給出了正確答案。

我們嘗試了以下幾種少樣本技術(shù)：

• 零樣本：只向模型提供了一個基本的系統(tǒng)提示和問題。
• 少樣本-字符串, k=3：將三個固定示例轉(zhuǎn)換成長字符串，并附加到系統(tǒng)提示中。消息使用ChatML語法進(jìn)行格式化。
• 少樣本-消息, k=3：將三個固定示例作為消息列表，在系統(tǒng)提示和人類問題之間傳遞。
• 少樣本-字符串, k=9：將所有九個少樣本示例轉(zhuǎn)換成長字符串，并附加到系統(tǒng)提示中。
• 少樣本-消息, k=9：將所有九個少樣本示例作為消息列表，在系統(tǒng)提示和人類問題之間傳遞。

查看結(jié)果，我們發(fā)現(xiàn)一些有趣的趨勢：

• 使用9個示例作為消息進(jìn)行少樣本提示幾乎總是優(yōu)于零樣本提示，并且通常表現(xiàn)最佳。
• Claude 3模型在使用消息進(jìn)行少樣本提示時性能大幅提升。例如，Claude 3 Haiku在沒有示例的情況下正確率為11%，但僅使用3個示例作為消息時，正確率就達(dá)到了75%。這與其他模型的零樣本性能相當(dāng)，除了Claude 3.5 Sonnet和GPT-4o。
• 當(dāng)示例被格式化為字符串并添加到系統(tǒng)消息中時，Claude 3模型的性能提升很小或根本沒有提升。這可能是由于我們使用ChatML語法進(jìn)行格式化。
• OpenAI模型從少樣本提示中獲得的正面效果較小。
• 通常，插入3個示例作為消息的性能與使用所有9個示例相當(dāng)。這表明，選擇包含多少少樣本示例可能存在遞減回報。

有關(guān)在多宇宙數(shù)學(xué)數(shù)據(jù)集上運行實驗的代碼，請訪問這里。

要點總結(jié)

這項工作展示了少樣本提示在提高LLMs性能方面的潛力，尤其是在工具調(diào)用和使用方面。從宏觀上看，我們發(fā)現(xiàn)：

• 即使是最簡單的少樣本提示也能為大多數(shù)模型帶來性能提升。
• 少樣本提示的格式化方式對性能有顯著影響，并且這種影響因模型而異。
• 使用一些精選的示例可能和使用許多示例一樣有效，甚至更有效。
• 對于輸入多樣化的數(shù)據(jù)集，為新輸入選擇最相關(guān)的示例比使用相同的固定示例集更有力量。
• 使用少樣本示例的較小模型（如Claude 3 Haiku）可以與更大的模型（如Claude 3.5 Sonnet）的零樣本性能相媲美。

這項工作還強(qiáng)調(diào)了評估對于希望優(yōu)化其應(yīng)用程序性能的開發(fā)人員的重要性 —— 我們發(fā)現(xiàn)，在設(shè)計少樣本系統(tǒng)時，有很多維度需要考慮，而哪種配置最有效最終高度依賴于您使用的具體模型和執(zhí)行的任務(wù)。

本文轉(zhuǎn)載自?? AI小智??，作者： AI小智