Anthropic提出Contextual Retrieval讓RAG再進化，大幅降低檢索失敗率
在知識庫問答等場景中，RAG已經成為當下最流行的LLM應用范式，為LLM提供又全又準的上下文信息是眾多RAG技術努力的方向。在傳統(tǒng)的 RAG 解決方案中，編碼信息時往往會丟失上下文，這導致系統(tǒng)無法從知識庫中檢索到相關信息，如何能夠更好地保留上下文信息成為了問題關鍵。
Anthropic 研究團隊提出了“Contextual Retrieval（上下文檢索）”的創(chuàng)新方法在此領域取得了顯著進展。近日，他們發(fā)表文章[1]可披露了這一技術的細節(jié)，他們通過上下文嵌入（Contextual Embeddings）和上下文 BM25（Contextual BM25）（文本檢索）可以將檢索失敗率減少 49%，聯(lián)合重排序（reranking），失敗率可減少 67%。
我們一起來了解這一方法的核心內容。
上下文檢索的創(chuàng)新點
傳統(tǒng)的 RAG 系統(tǒng)在分割文檔時會破壞上下文，導致檢索到的信息分塊缺乏足夠的背景信息。
例如，假設你有一個包含財務信息的知識庫，并收到以下問題：“ACME 公司在 2023 年第二季度的收入增長是多少？”一個相關的分塊可能包含這樣的文本：“公司的收入比上一季度增長了 3%?！比欢@個分塊本身并沒有指定是哪家公司或相關的時間段，導致難以檢索到正確的信息或有效地使用這些信息。
研究團隊嘗試過一些業(yè)內流行的改進措施，諸如：分塊中添加文檔摘要（adding generic document summaries to chunks）[2]，假設文檔嵌入（hypothetical document embedding）[3]，以及索引摘要（summary-based indexing）[4]，但都效果不佳。
他們通過大量實驗摸索，采用上下文檢索時通過在嵌入前為每個分塊添加特定的解釋性上下文（Contextual Embeddings）和創(chuàng)建 BM25 索引（Contextual BM25）來解決這個問題。例如：
原始分塊 = "公司的收入比上一季度增長了3%。"
上下文化分塊 = "這個分塊來自ACME公司在2023年第二季度的SEC文件；上一季度的收入為3.14億美元。公司的收入比上一季度增長了3%。"
圖片
這種方法顯著提高了檢索的準確性，特別是在處理包含特定標識符或技術術語的查詢時。
如何實現(xiàn)上下文檢索
手動為知識庫中的成千上萬個分塊添加上下文顯然是不現(xiàn)實的。為此，研究團隊使用了 Claude 模型，通過一個特定的提示生成每個分塊的簡潔上下文，生成的上下文通常為 50-100 個 token，然后在嵌入和創(chuàng)建 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.
以下是詳細的實現(xiàn)步驟：
- 生成上下文
首先，研究團隊使用 Claude 為每個分塊生成上下文。通過設計一個特定的提示，Claude 可以為每個分塊生成簡潔而有意義的上下文。
例如，假設我們有一個分塊：
“公司的收入比上一季度增長了3%?！?/code>我們可以設計一個提示，讓 Claude 生成上下文：
“請為以下分塊生成一個簡潔的上下文：‘公司的收入比上一季度增長了3%?！?/code>Claude 可能會生成以下上下文：
“這個分塊來自ACME公司在2023年第二季度的SEC文件；上一季度的收入為3.14億美元。公司的收入比上一季度增長了3%?！?/code>- 添加上下文到分塊
生成上下文后，將其添加到原始分塊中。這樣，每個分塊都包含了足夠的背景信息，便于后續(xù)的檢索和使用。
上下文化分塊 = "這個分塊來自ACME公司在2023年第二季度的SEC文件；上一季度的收入為3.14億美元。公司的收入比上一季度增長了3%。"- 創(chuàng)建嵌入
接下來，使用嵌入模型將上下文化分塊轉換為向量嵌入。向量嵌入是高維空間中的點，表示文本的語義含義。常用的嵌入模型包括 Voyage 和 Gemini，它們在實驗中表現(xiàn)出色。
嵌入向量 = 嵌入模型(上下文化分塊)- 創(chuàng)建 BM25 索引
除了生成嵌入，還需要為上下文化分塊創(chuàng)建 BM25 索引。BM25 是一種基于詞頻和逆文檔頻率的檢索算法，能夠有效地衡量文本分塊與查詢之間的相關性。
BM25索引 = BM25模型(上下文化分塊)- 存儲和檢索
將生成的嵌入向量和 BM25 索引存儲在向量數(shù)據(jù)庫和 BM25 索引庫中。這樣，當用戶輸入查詢時，系統(tǒng)可以同時使用嵌入向量和 BM25 索引進行檢索，從而找到最相關的上下文化分塊。
向量數(shù)據(jù)庫.存儲(嵌入向量)
BM25索引庫.存儲(BM25索引)- 重排序
在檢索到相關分塊后，使用重排序技術對分塊進行過濾和排序，確保只有最相關的分塊被傳遞給生成模型。重排序可以顯著提高檢索的準確性和相關性。
相關分塊 = 向量數(shù)據(jù)庫.檢索(查詢)
重排序分塊 = 重排序模型(相關分塊)在實現(xiàn)上下文檢索時，研究團隊特別指出需要考慮以下幾點：
- 分塊策略：考慮如何將文檔分割成分塊。分塊大小、邊界和重疊的選擇會影響檢索性能。
- 嵌入模型：選擇合適的嵌入模型，對提高上下文檢索性能幫助更大，Gemini[5]和Voyage[6]在測試中表現(xiàn)更好。
- 自定義上下文提示：雖然通用提示效果良好，但仍然可能需要針對一些場景定制提示來獲得更好的結果。
- 分塊的數(shù)量：將更多的塊添加到上下文窗口中，增加了包含相關信息的可能性。然而，過多的信息可能會使模型分心，因此存在一個限制。研究團隊嘗試了提供 5、10 和 20 塊，發(fā)現(xiàn)使用 20 塊在這三個選項中表現(xiàn)最佳，但仍然在一些具體場景中進行實驗選擇。
- 持續(xù)評估：通過將上下文化的語塊傳遞給響應生成器，并區(qū)分上下文和語塊，可以改進響應生成。
效果如何
研究團隊的實驗結果顯示：
- 上下文嵌入將前 20 個分塊的檢索失敗率減少了 35%（從 5.7%降至 3.7%）。
- 結合上下文嵌入和上下文 BM25 將前 20 個分塊的檢索失敗率減少了 49%（從 5.7%降至 2.9%）。
同時，利用提示緩存技術降低了使用成本。通過提示緩存，您不需要為每一塊都傳遞參考文檔。您只需將文檔加載到緩存中一次，然后引用之前緩存的內容即可。假設每塊有 800 個 token，8k 個 token 的文檔，50 個 token 的上下文指令，以及每塊 100 個 token 的上下文，生成上下文化塊的一次性成本為每百萬文檔 token1.02 美元。
聯(lián)合重排序進一步提升性能
在傳統(tǒng) RAG 中，AI 系統(tǒng)會從知識庫中檢索到大量潛在相關的信息分塊。對于大型知識庫，這一初始檢索往往會返回大量分塊，有時多達數(shù)百個，且相關性和重要性各不相同。重排序是一種常用的過濾技術，確保只有最相關的分塊被傳遞給模型。實驗結果顯示，重排序后的上下文嵌入和上下文 BM25 將前 20 個分塊的檢索失敗率減少了 67%（從 5.7%降至 1.9%）。
同時注意，由于重排序在運行時增加了額外的步驟，即使所有分塊都是并行評分，也必然會增加一小部分延遲，在重排序大量分塊時表現(xiàn)更加明顯。重排序在使用更多分塊以獲得更好性能與更少分塊以降低延遲和成本之間存在取舍，這需要在具體的場景下嘗試不同的設置，以找到合適的平衡點。
總結
研究團隊通過大量的實驗，為大家指出了一個新的提升 RAG 性能的方法，為開發(fā)者指出了實踐新方向。
同時，研究團隊基于大量實驗的結果，給出了一些關鍵的經驗總結：
- 嵌入+BM25 比單獨使用嵌入效果更好（向量檢索與文本檢索相結合）；
- Voyage 和 Gemini 是測試中效果最好的嵌入模型；
- 將前 20 個分塊傳遞給模型比僅傳遞前 10 個或前 5 個分塊更有效；
- 為分塊添加上下文顯著提高了檢索準確性；
- 重排序比不重排序效果更好；
- 所有這些改進措施可以疊加：結合上下文嵌入（Voyage 或 Gemini）、上下文 BM25 和重排序步驟，并將前 20 個分塊添加到提示中，可以最大化性能提升。
對于該方法感興趣的讀者，可以在cookbook[7]指導下上手體驗。
參考資料
[1]文章: https://www.anthropic.com/news/contextual-retrieval
[2]分塊中添加文檔摘要（adding generic document summaries to chunks）: https://aclanthology.org/W02-0405.pdf
[3]假設文檔嵌入（hypothetical document embedding）: https://arxiv.org/abs/2212.10496
[4]索引摘要（summary-based indexing）: https://www.llamaindex.ai/blog/a-new-document-summary-index-for-llm-powered-qa-systems-9a32ece2f9ec
[5]Gemini: https://ai.google.dev/gemini-api/docs/embeddings
[6]Voyage: https://www.voyageai.com/
[7]cookbook: https://github.com/anthropics/anthropic-cookbook/tree/main/skills/contextual-embeddings
本文轉載自 ??AI工程化??，作者： ully
