LLM超長上下文查詢-效能評估實戰

在大型語言模型（LLM）的應用中，有幾個場景需要以結構化的方式呈現數據，其中資訊擷取和查詢分析是兩個典型的例子。我們最近透過更新的文檔和一個專門的程式碼倉庫強調了資訊擷取的重要性。對於查詢分析，我們同樣更新了相關文件。在這些場景中，資料欄位可能包括字串、布林值、整數等多種類型。而在這些類型中，處理高基數的分類值（即枚舉類型）是最具挑戰性的。

圖片

所謂的“高基數分組值”，指的是必須從有限的選項中選擇的值，這些值不能隨意指定，而必須來自一個預先定義的集合。在這種集合中，有時會存在有效值數量非常龐大的情況，我們稱之為「高基數數值」。處理這類數值之所以困難，是因為LLM本身並不知道這些可行的值是什麼。因此，我們需要向LLM提供關於這些可行值的資訊。即使忽略了只有少數幾個可行值的情況，我們仍然可以在提示中明確列出這些可能的值來解決這個問題。然而，由於可能值非常多，問題就變得複雜了。

隨著可能值數量的增加，LLM選擇值的難度也隨之增加。一方面，如果可能的值太多，它們可能無法適應LLM的上下文視窗。另一方面，即使所有可能的值都能適應上下文，將它們全部包含在內會導致處理速度變慢、成本增加，以及LLM在處理大量上下文時的推理能力下降。 `隨著可能值數量的增加，LLM選擇值的難度也隨之增加。一方面，如果可能的值太多，它們可能無法適應LLM的上下文視窗。另一方面，即使所有可能的值都能適應上下文，將它們全部包含在內會導致處理速度變慢、成本增加，以及LLM在處理大量上下文時的推理能力下降。 ` (Note: The original text appears to be URL encoded. I have corrected the encoding and provided the rewritten text.)

最近，我們對查詢分析進行了深入研究，並在修訂相關文件時特別增加了一個關於如何處理高基數數值的頁面。在這篇部落格中，我們將深入探討幾種實驗性方法，並提供它們的效能基準測試結果。

結果的概覽可以在LangSmithhttps://smith.langchain.com/public/8c0a4c25-426d-4582-96fc-d7def170be76/d?ref=blog.langchain.dev中查看。接下來，我們將詳細介紹：

圖片

#資料集概覽

詳細的資料集可以在這裡查看https://smith.langchain.com/public/8c0a4c25-426d-4582-96fc-d7def170be76/d?ref=blog.langchain.dev。

為了模擬這個問題，我們假設了一個場景：我們要找某位作者關於外星人的書。在這個場景中，作家欄位是一個高基數分類變數——可能的值有很多，但它們應該是特定的有效作家名稱。 為了測試這一點，我們建立了一個包含作者姓名和常用別名的資料集。例如，「Harry Chase」可能是「Harrison Chase」的別名。我們希望智慧系統能夠處理這種別名。 在這個資料集中，我們產生了一個包含作家姓名和別名清單的資料集。請注意，10,000個隨機姓名不算太多——對於企業級系統來說，可能需要面對數百萬等級的基數。

利用這個資料集，我們提出了這樣的問題：「Harry Chase關於外星人的書有哪些？」我們的查詢分析系統應該能夠將這個問題解析為結構化格式，包含兩個字段：主題和作者。在這個例子中，預期的輸出應該是{“topic”: “aliens”，“author”: “Harrison Chase”}。我們期望系統能辨識出沒有名為Harry Chase的作者，但Harrison Chase可能是使用者想要表達的意思。

透過這種設置，我們可以針對我們建立的別名資料集進行測試，檢查它們是否能夠正確地對應到真實姓名。同時，我們也會記錄查詢的延遲和成本。這種查詢分析系統通常用於搜索，因此我們非常關心這兩個指標。基於這個原因，我們也限制了所有方法只能進行一次LLM呼叫。我們可能會在未來的文章中對使用多次LLM呼叫的方法進行基準測試。

接下來，我們將介紹幾種不同的方法及其效能表現。

圖片

完整的結果可以在LangSmith中查看，復現這些結果的程式碼可以在這裡找到。

基準測試

首先，我們對LLM進行了基準測試，即在不提供任何有效姓名資訊的情況下，直接要求LLM進行查詢分析。結果不出所料，沒有一個問題得到了正確回答。這是因為我們故意建立了一個需要透過別名查詢作者的資料集。

上下文填充法

在這種方法中，我們將所有10,000個合法的作者姓名都放入了提示中，並要求LLM在進行查詢分析時記住這些是合法的作者姓名。有些模型（如GPT-3.5）由於上下文視窗的限制，根本無法執行這個任務。對於其他具有更長上下文視窗的模型，它們在準確選擇正確姓名方面也遇到了困難。 GPT-4只在26%的案例中選擇了正確的姓名。它最常見的錯誤是提取了姓名但沒有進行校正。這種方法不僅速度慢，成本也高，平均需要5秒鐘才能完成，總成本為8.44美元。

LLM前過濾法

我們接下來測試的方法是在將可能的值清單傳遞給LLM之前進行篩選。這樣做的好處是只傳遞可能姓名的子集給LLM，這樣LLM需要考慮的名稱就少得多，希望能夠讓它更快、更便宜、更準確地完成查詢分析。但這也增加了一個新的潛在失敗模式——如果初步過濾出錯怎麼辦？

基於嵌入的過濾法

我們最初使用的過濾方法是嵌入法，並選擇了與查詢最相似的10個名稱。需要注意的是，我們是將整個查詢與姓名進行比較，這並不是一個理想的比較方式！

我們發現，使用這種方法，GPT-3.5能夠正確處理57%的案例。這種方法比以前的方法快得多，也便宜得多，平均只需要0.76秒就能完成，總成本僅0.002美元。

基於NGram相似性的過濾法

我們使用的第二種過濾方法是對所有有效姓名的3-gram字元序列進行TF-IDF矢量化，並使用向量化的有效姓名與向量化的使用者輸入之間的餘弦相似度來選擇最相關的10個有效姓名添加到模型提示中。同樣需要注意的是，我們是將整個查詢與姓名進行比較，這並不是一個理想的比較方式！

我們發現，使用這種方法，GPT-3.5能夠正確處理65%的案例。這種方法同樣比以前的方法快得多，也便宜得多，平均只需要0.57秒就能完成，總成本僅0.002美元。

LLM後選擇法

我們最後測試的方法是在LLM完成初步查詢分析後，試著修正任何錯誤。我們首先對使用者輸入進行了查詢分析，沒有在提示中提供任何關於有效作者姓名的資訊。這與我們最初進行的基線測試相同。然後，我們進行了一個後續步驟，取作者欄位中的姓名，找到最相似的有效姓名。

基於嵌入相似性的選擇法

首先，我們使用嵌入法進行了相似性檢查。

我們發現，使用這種方法，GPT-3.5能夠正確處理83%的案例。這種方法比以前的方法快得多，也便宜得多，平均只需要0.66秒就能完成，總成本僅0.001美元。

基於NGram相似性的選擇法

最後，我們嘗試使用3-gram向量化器進行相似性檢查。

我們發現，使用這種方法，GPT-3.5能夠正確處理74%的案例。這種方法同樣比以前的方法快得多，也便宜得多，平均只需要0.48秒就能完成，總成本僅0.001美元。

結論

我們對處理高基數分類值的查詢分析方法進行了多種基準測試。我們限制了自己只能進行一次LLM調用，這是為了模擬現實世界中的延遲限制。我們發現，使用LLM後基於嵌入相似性的選擇方法表現最佳。

還有其他方法值得進一步測試。特別是，在LLM呼叫之前或之後尋找最相似的分類值有許多不同的方法。此外，本資料集中的類別基數並不像許多企業系統所面臨的那麼高。這個資料集大約有10,000個值，而許多現實世界中的系統可能需要處理的是數百萬個等級的基數。因此，對更高基數的數據進行基準測試將是非常有價值的。

#

以上是LLM超長上下文查詢-效能評估實戰的詳細內容。更多資訊請關注PHP中文網其他相關文章！