處理超長文本的AI評論摘要：一種基於層次聚類的多通道方法
最初發表於2024年10月28日，Bazaarvoice開發者博客
引言
大型語言模型 (LLM) 是處理非結構化文本的強大工具，但如果您的文本超出上下文窗口的限制怎麼辦？ Bazaarvoice在構建其AI評論摘要功能時就面臨著這一挑戰：數百萬條用戶評論根本無法容納到即使是最新的LLM的上下文窗口中，即使可以容納，成本也高得令人望而卻步。
本文將分享Bazaarvoice如何通過壓縮輸入文本（不損失語義）來解決這個問題。具體來說，我們使用了一種多通道層次聚類方法，使我們能夠明確地調整想要損失的細節級別以換取壓縮，而不管選擇的嵌入模型是什麼。最終的技術使我們的評論摘要功能在經濟上可行，並為我們未來的業務擴展奠定了基礎。
問題
Bazaarvoice收集用戶生成的產品評論已有近20年曆史，因此我們擁有大量的數據。這些產品評論完全是非結構化的，長度和內容各不相同。大型語言模型非常適合處理非結構化文本：它們可以處理非結構化數據，並在干擾因素中識別相關信息。
然而，LLM也有其局限性，其中一個局限性是上下文窗口：一次可以輸入網絡的標記數量（大致相當於單詞數量）。最先進的大型語言模型，例如Anthropic的Claude版本3，具有高達200,000個標記的超大上下文窗口。這意味著您可以將小型小說放入其中，但互聯網仍然是一個龐大且不斷增長的數據集合，我們用戶生成的產品評論也不例外。
在構建我們的評論摘要功能（總結客戶網站上特定產品的全部評論）時，我們遇到了上下文窗口的限制。然而，在過去的20年中，許多產品積累了數千條評論，這些評論迅速超載了LLM上下文窗口。事實上，我們甚至有一些產品擁有數百萬條評論，需要對LLM進行巨大的重新設計才能在一個提示中進行處理。
即使在技術上可行，成本也會非常高昂。所有LLM提供商都根據輸入和輸出標記的數量收費。當您接近每個產品的上下文窗口限制時（我們有數百萬個產品），我們的雲託管賬單很快就會超過六位數。
我們的方法
為了克服這些技術和經濟上的限制來發布評論摘要，我們關注了我們數據的一個相當簡單的見解：許多評論表達的是相同的意思。事實上，摘要的整個概念都依賴於此：評論摘要捕捉了評論者反復出現的見解、主題和情感。我們意識到，我們可以利用這種數據重複來減少需要發送到LLM的文本量，從而避免達到上下文窗口限制並降低我們系統的運營成本。
為此，我們需要識別表達相同意思的文本片段。這樣的任務說起來容易做起來難：人們經常使用不同的單詞或短語來表達相同的意思。
幸運的是，識別文本語義是否相似一直是自然語言處理領域的一個活躍研究領域。 Agirre等人2013年的工作（SEM 2013共享任務：語義文本相似性。在詞彙和計算語義的第二次聯合會議上）甚至發表了一組人類標記的語義相似句子的數據，稱為STS基準。在其中，他們要求人們根據1-5的等級來指示文本句子在語義上是相似還是不同，如下表所示（來自Cer等人，SemEval-2017任務1：語義文本相似性多語言和跨語言重點評估）：
STS基準數據集通常用於評估文本嵌入模型在其高維空間中關聯語義相似句子的能力。具體來說，皮爾遜相關性用於衡量嵌入模型對人類判斷的表示程度。
因此，我們可以使用這樣的嵌入模型來識別產品評論中語義相似的短語，然後在將它們發送到LLM之前刪除重複的短語。
我們的方法如下：
在項目符號列表中寫出來時，這似乎很簡單，但在我們可以信任這種方法之前，我們必須解決一些細節問題。
嵌入模型評估
首先，我們必須確保我們使用的模型有效地將文本嵌入到語義相似的句子靠近，而語義不相似的句子遠離的空間中。為此，我們只需使用STS基準數據集併計算我們想要考慮的模型的皮爾遜相關性。我們使用AWS作為雲提供商，因此我們自然希望評估其Titan文本嵌入模型。
下表顯示了不同Titan嵌入模型在STS基準測試上的皮爾遜相關性：
因此，AWS的嵌入模型在嵌入語義相似的句子方面非常出色。這對我們來說是個好消息——我們可以直接使用這些模型，而且它們的成本極低。
語義相似聚類
我們面臨的下一個挑戰是：如何在聚類過程中強制執行語義相似性？理想情況下，沒有哪個集群的兩個句子的語義相似性低於人類可以接受的程度——上表中的分數為4。然而，這些分數並不能直接轉化為嵌入距離，而這是凝聚層次聚類閾值所需要的。
為了解決這個問題，我們再次轉向STS基準數據集。我們計算了訓練數據集中所有對的距離，並根據分數擬合多項式到距離閾值。
這個多項式使我們能夠計算出滿足任何語義相似性目標所需的距離閾值。對於評論摘要，我們選擇了3.5分，因此幾乎所有集群都包含“大致”到“大部分”等效或更高的句子。
值得注意的是，這可以在任何嵌入網絡上完成。這使我們能夠隨著新嵌入網絡的出現而進行實驗，並在需要時快速更換它們，而無需擔心集群將包含語義不相似的句子。
多通道聚類
到目前為止，我們知道我們可以信任我們的語義壓縮，但還不清楚我們可以從數據中獲得多少壓縮。正如預期的那樣，壓縮量因不同的產品、客戶和行業而異。
在沒有語義信息丟失的情況下，即4的硬閾值，我們只實現了1.18的壓縮比（即15%的空間節省）。
顯然，無損壓縮不足以使這項功能在經濟上可行。
然而，我們上面討論的距離選擇方法在這裡提供了一個有趣的可能性：我們可以通過以較低的閾值重複對剩餘數據運行聚類來逐漸增加信息丟失量。
方法如下：
因此，在聚類的每個通道中，我們都在犧牲更多信息丟失，但獲得更多壓縮，並且不會混淆我們在第一通道中選擇的無損代表性短語。
此外，這種方法不僅對評論摘要非常有用（我們希望以較少壓縮為代價獲得高水平的語義相似性），而且對其他用例也非常有用，在這些用例中，我們可能不太關心語義信息丟失，但希望在提示輸入上花費更少。
在實踐中，即使在多次降低分數閾值之後，仍然有大量集群只有一個向量。這些被認為是異常值，並被隨機抽樣以包含在最終提示中。我們選擇樣本大小以確保最終提示有25,000個標記，但不多於此。
確保真實性
多通道聚類和隨機異常值採樣允許以較小的上下文窗口（發送到LLM）為代價犧牲語義信息。這就提出了一個問題：我們的摘要有多好？
在Bazaarvoice，我們知道真實性是消費者信任的必要條件，我們的評論摘要必須保持真實，才能真正代表評論中捕捉到的所有聲音。任何有損壓縮方法都存在歪曲或排除花時間撰寫評論的消費者的風險。
為了確保我們的壓縮技術有效，我們直接測量了這一點。具體來說，對於每個產品，我們都抽取了一些評論，然後使用LLM Evals來確定摘要是否具有代表性和與每條評論相關。這為我們提供了一個硬性指標來評估和平衡我們的壓縮。
結果
在過去的20年中，我們已經收集了近10億條用戶生成的評論，並且需要為數千萬種產品生成摘要。這些產品中的許多產品都有數千條評論，有些甚至高達數百萬條，這會耗盡LLM的上下文窗口並大幅增加價格。
然而，使用我們上述的方法，我們將輸入文本大小減少了97.7%（壓縮比為42），使我們能夠在未來為所有產品和任何數量的評論量擴展此解決方案。此外，為我們所有十億級數據集生成摘要的成本降低了82.4%。這包括嵌入句子數據並將它們存儲在數據庫中的成本。
以上是語義壓縮文本以節省LLM成本的詳細內容。更多資訊請關注PHP中文網其他相關文章！
