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

圖片

所謂的“高基數分類值”，指的是那些必須從有限的選項中選擇的值，這些值不能隨意指定，而必須來自一個預定義的集合。當這個集合中的有效值數量非常龐大時，我們稱之為“高基數”。處理這類值之所以困難，是因為LLM本身并不知道這些可能的值是什么。因此，我們需要向LLM提供關于這些可能值的信息。如果忽略了這一點，LLM可能會自行編造值。對于只有少數幾個可能值的情況，我們可以通過在提示中明確列出這些值來解決。但是，當可能的值非常多時，問題就變得復雜了。

隨著可能值數量的增加，LLM正確選擇值的難度也隨之增加。一方面，如果可能的值太多，它們可能無法適應LLM的上下文窗口。另一方面，即使所有可能的值都能適應上下文，將它們全部包含在內會導致處理速度變慢、成本增加，以及LLM在處理大量上下文時的推理能力下降。

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

結果的概覽可以在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個隨機姓名。需要注意的是，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個值，而許多現實世界中的系統可能需要處理的是數百萬級別的基數。因此，對更高基數的數據進行基準測試將是非常有價值的。