Anthropic研究團隊提出新技術，引入Contextual Retrieval讓RAG再進化，大幅降低檢索失敗率 原創
?在當前的知識檢索領域，RAG技術正引領著最新潮流，它的目標是為大型語言模型（LLM）提供豐富而精確的上下文信息。然而，傳統RAG方法在處理信息時經常會忽略上下文細節，這限制了其從知識庫中提取相關信息的能力。解決如何有效保存上下文信息的問題，已成為該領域的重點。
針對這一挑戰，Anthropic的研究團隊提出了一種名為“上下文檢索”的創新技術，使得在這一領域取得了重大突破。他們最近發表的研究詳細介紹了這一技術，展示了如何通過上下文嵌入和上下文敏感的BM25算法顯著降低檢索失敗率。讓我們深入探討這一方法的關鍵要素。
關于使用較長提示符的說明
有時候最簡單的解決方案就是最好的。如果你的知識庫小于200，000個token（大約500頁的材料），你可以在給出模型的提示中包含整個知識庫，而不需要RAG或類似的方法。
幾周前，Claude發布了快速緩存，這使得這種方法更快，更具成本效益。開發人員現在可以在API調用之間緩存頻繁使用的提示，將延遲減少2倍以上，成本降低高達90%（可以通過閱讀prompt caching cookbook了解它是如何工作的）。
但是，隨著知識庫的增長，您將需要一個更具可擴展性的解決方案。這就是上下文檢索的用武之地。
擴展到更大的知識庫
對于不適合上下文窗口的較大知識庫，RAG是典型的解決方案。RAG通過使用以下步驟預處理知識庫來工作：
- 將知識庫（文檔的“語料庫”）分解為更小的文本塊，通常不超過幾百個標記;
- 使用嵌入模型將這些塊轉換為編碼含義的向量嵌入;
- 將這些嵌入存儲在矢量數據庫中，以便根據語義相似性進行搜索。
在運行時，當用戶向模型輸入查詢時，向量數據庫用于基于與查詢的語義相似性來找到最相關的塊。然后，將最相關的塊添加到發送到生成模型的提示中。
雖然嵌入模型擅長捕捉語義關系，但它們可能會錯過關鍵的精確匹配。幸運的是，有一種更古老的技術可以幫助解決這些問題。BM 25是一個排名功能，它使用詞匯匹配來查找精確的單詞或短語匹配。它對于包含唯一標識符或技術術語的查詢特別有效。BM 25基于TF-IDF概念，TF-IDF衡量一個單詞對集合中文檔的重要性。BM 25通過考慮文檔長度并將飽和函數應用于詞頻來細化這一點，這有助于防止常見詞主導結果。
假設用戶在技術支持數據庫中查詢“Error code TS-999”。嵌入模型通常可以找到有關錯誤代碼的內容，但可能會錯過精確的“TS-999”匹配。BM 25查找此特定文本字符串以識別相關文檔。
RAG解決方案可以通過使用以下步驟結合嵌入和BM 25技術來更準確地檢索最適用的塊：
- 將知識庫（文檔的“語料庫”）分解為更小的文本塊，通常不超過幾百個標記;
- 為這些塊創建TF-IDF編碼和語義嵌入;
- 使用BM 25來找到基于精確匹配的頂部塊;
- 基于語義相似度，使用嵌入來找到頂部塊;
- 使用融合技術對來自（3）和（4）的結果進行聚合和去重;
- 將前K個塊添加到提示符中以生成響應。
通過利用BM 25和嵌入模型，傳統的RAG系統可以提供更全面和準確的結果，平衡精確的術語匹配和更廣泛的語義理解。
這種方法使您能夠經濟高效地擴展到巨大的知識庫，遠遠超出了單個提示中所能容納的內容。但是這些傳統的RAG系統有一個顯著的局限性：它們經常破壞上下文。
傳統RAG中的語境難題
在傳統的RAG中，文檔通常被分成更小的塊以進行有效的檢索。雖然這種方法對于許多應用程序都很有效，但當單個塊缺乏足夠的上下文時，它可能會導致問題。
例如，假設您的知識庫中嵌入了一系列財務信息，您收到了以下問題：“ACME Corp在2023年第二季度的收入增長是多少？"
一個相關的塊可能包含這樣的文本：“公司的收入比上一季度增長了3%。“然而，這一大塊本身并沒有指定它所指的是哪家公司或相關的時間段，因此很難檢索正確的信息或有效地使用這些信息。
Contextual Retrieval
上下文檢索簡介
上下文檢索通過在嵌入之前將特定于塊的解釋性上下文前置到每個塊（Contextual Embeddings）并創建BM 25索引（Contextual BM25）來解決這個問題。
下面是一個如何轉換塊的示例：
原始分塊 = "公司的收入比上一季度增長了3%。"
上下文化分塊 = "這個分塊來自ACME公司在2023年第二季度的SEC文件；上一季度的收入為3.14億美元。公司的收入比上一季度增長了3%。"值得注意的是，過去已經提出了使用上下文來改進檢索的其他方法。其他建議包括：將通用文檔摘要添加到塊，假設文檔嵌入和基于摘要的索引。這些方法的收益和性能都很低。
實現上下文檢索
手動為知識庫中的成千上萬個分塊添加上下文顯然是不現實的。為此，研究團隊使用了 Claude 模型，通過一個特定的提示生成每個分塊的簡潔上下文，生成的上下文通常為 50-100 個 token，然后在嵌入和創建 BM25 索引之前將其添加到分塊中。對應的prompt示例:
<document>
{{WHOLE_DOCUMENT}}
</document>
Here is the chunk we want to situate within the whole document
<chunk>
{{CHUNK_CONTENT}}
</chunk>
Please give a short succinct context to situate this chunk within the overall document for the purposes of improving search retrieval of the chunk. Answer only with the succinct context and nothing else.下面是預處理流程在實踐中的樣子：
使用Prompt Caching降低上下文檢索成本
上下文檢索得益于Prompt Caching功能，通過Claude可以以低成本獨特地實現。有了提示緩存，您不需要為每個塊傳入參考文檔。您只需將文檔加載到緩存中一次，然后引用之前緩存的內容。假設800個令牌的塊，8k令牌的文檔，50令牌的上下文指令，以及每個塊的100令牌的上下文，生成上下文化塊的一次性成本是每百萬文檔令牌1.02美元。
注意事項
在實現上下文檢索時，需要記住幾個注意事項：
- 塊邊界：考慮如何將文檔拆分為塊。塊大小、塊邊界和塊重疊的選擇會影響檢索性能。
- 嵌入模型：雖然上下文檢索提高了我們測試的所有嵌入模型的性能，但某些模型可能比其他模型受益更多。Gemini和Voyage嵌入特別有效。
- 自定義prompt：雖然通用提示效果很好，但您可以使用針對特定領域或用例定制的提示（例如，包括可能僅在知識庫中的其他文檔中定義的關鍵術語的詞匯表）來實現更好的結果。
- **塊的數量：**在上下文窗口中添加更多的塊可以增加包含相關信息的機會。然而，更多的信息可能會分散模型的注意力，所以這是有限制的。嘗試使用5、10和20塊，發現使用20塊是這些選項中性能最好的，但值得在您的用例中進行試驗。
通過Rerank進一步提升性能
在傳統 RAG 中，AI 系統會從知識庫中檢索到大量潛在相關的信息分塊。對于大型知識庫，這一初始檢索往往會返回大量分塊，有時多達數百個，且相關性和重要性各不相同。重排序是一種常用的過濾技術，確保只有最相關的分塊被傳遞給模型。實驗結果顯示，重排序后的上下文嵌入和上下文 BM25 將前 20 個分塊的檢索失敗率減少了 67%（從 5.7%降至 1.9%）。
成本和延遲考慮
重排序的一個重要考慮因素是對延遲和成本的影響，特別是在對大量塊進行重排序時。因為重排序在運行時增加了一個額外的步驟，所以它不可避免地增加了少量的延遲，即使重排序器并行地對所有塊進行評分。在重新排序更多塊以獲得更好的性能與重新排序更少塊以降低延遲和成本之間存在固有的權衡。建議您在特定用例中嘗試不同的設置，以找到正確的平衡。
總結
研究團隊通過大量的實驗，為大家指出了一個新的提升 RAG 性能的方法，為開發者指出了實踐新方向。同時，研究團隊基于大量實驗的結果，給出了一些關鍵的經驗總結：
- Embeddings+BM25 比單獨使用Embeddings效果更好
- Voyage 和 Gemini 是測試中效果最好的嵌入模型
- 將前20個塊傳遞給模型比只傳遞前10個或前5個塊更有效
- 在語塊中加入上下文可以大大提高檢索的準確率
- 采用重排序的方法比起不進行重排序
- 將這些改進策略綜合起來：為了最大限度地提高性能，我們可以將contextual embeddings（來自Voyage或Gemini）與contextual BM25結合起來，再加上重新排序步驟，并將20個塊添加到提示符中。
?
本文轉載自公眾號AI 博物院 作者：longyunfeigu
