?在當(dāng)前的知識(shí)檢索領(lǐng)域，RAG技術(shù)正引領(lǐng)著最新潮流，它的目標(biāo)是為大型語言模型（LLM）提供豐富而精確的上下文信息。然而，傳統(tǒng)RAG方法在處理信息時(shí)經(jīng)常會(huì)忽略上下文細(xì)節(jié)，這限制了其從知識(shí)庫中提取相關(guān)信息的能力。解決如何有效保存上下文信息的問題，已成為該領(lǐng)域的重點(diǎn)。

針對(duì)這一挑戰(zhàn)，Anthropic的研究團(tuán)隊(duì)提出了一種名為“上下文檢索”的創(chuàng)新技術(shù)，使得在這一領(lǐng)域取得了重大突破。他們最近發(fā)表的研究詳細(xì)介紹了這一技術(shù)，展示了如何通過上下文嵌入和上下文敏感的BM25算法顯著降低檢索失敗率。讓我們深入探討這一方法的關(guān)鍵要素。

關(guān)于使用較長提示符的說明

有時(shí)候最簡單的解決方案就是最好的。如果你的知識(shí)庫小于200，000個(gè)token（大約500頁的材料），你可以在給出模型的提示中包含整個(gè)知識(shí)庫，而不需要RAG或類似的方法。

幾周前，Claude發(fā)布了快速緩存，這使得這種方法更快，更具成本效益。開發(fā)人員現(xiàn)在可以在API調(diào)用之間緩存頻繁使用的提示，將延遲減少2倍以上，成本降低高達(dá)90%（可以通過閱讀prompt caching cookbook了解它是如何工作的）。

但是，隨著知識(shí)庫的增長，您將需要一個(gè)更具可擴(kuò)展性的解決方案。這就是上下文檢索的用武之地。

擴(kuò)展到更大的知識(shí)庫

對(duì)于不適合上下文窗口的較大知識(shí)庫，RAG是典型的解決方案。RAG通過使用以下步驟預(yù)處理知識(shí)庫來工作：

1. 將知識(shí)庫（文檔的“語料庫”）分解為更小的文本塊，通常不超過幾百個(gè)標(biāo)記;
2. 使用嵌入模型將這些塊轉(zhuǎn)換為編碼含義的向量嵌入;
3. 將這些嵌入存儲(chǔ)在矢量數(shù)據(jù)庫中，以便根據(jù)語義相似性進(jìn)行搜索。

在運(yùn)行時(shí)，當(dāng)用戶向模型輸入查詢時(shí)，向量數(shù)據(jù)庫用于基于與查詢的語義相似性來找到最相關(guān)的塊。然后，將最相關(guān)的塊添加到發(fā)送到生成模型的提示中。

雖然嵌入模型擅長捕捉語義關(guān)系，但它們可能會(huì)錯(cuò)過關(guān)鍵的精確匹配。幸運(yùn)的是，有一種更古老的技術(shù)可以幫助解決這些問題。BM 25是一個(gè)排名功能，它使用詞匯匹配來查找精確的單詞或短語匹配。它對(duì)于包含唯一標(biāo)識(shí)符或技術(shù)術(shù)語的查詢特別有效。BM 25基于TF-IDF概念，TF-IDF衡量一個(gè)單詞對(duì)集合中文檔的重要性。BM 25通過考慮文檔長度并將飽和函數(shù)應(yīng)用于詞頻來細(xì)化這一點(diǎn)，這有助于防止常見詞主導(dǎo)結(jié)果。

假設(shè)用戶在技術(shù)支持?jǐn)?shù)據(jù)庫中查詢“Error code TS-999”。嵌入模型通?？梢哉业接嘘P(guān)錯(cuò)誤代碼的內(nèi)容，但可能會(huì)錯(cuò)過精確的“TS-999”匹配。BM 25查找此特定文本字符串以識(shí)別相關(guān)文檔。

RAG解決方案可以通過使用以下步驟結(jié)合嵌入和BM 25技術(shù)來更準(zhǔn)確地檢索最適用的塊：

1. 將知識(shí)庫（文檔的“語料庫”）分解為更小的文本塊，通常不超過幾百個(gè)標(biāo)記;
2. 為這些塊創(chuàng)建TF-IDF編碼和語義嵌入;
3. 使用BM 25來找到基于精確匹配的頂部塊;
4. 基于語義相似度，使用嵌入來找到頂部塊;
5. 使用融合技術(shù)對(duì)來自（3）和（4）的結(jié)果進(jìn)行聚合和去重;
6. 將前K個(gè)塊添加到提示符中以生成響應(yīng)。

通過利用BM 25和嵌入模型，傳統(tǒng)的RAG系統(tǒng)可以提供更全面和準(zhǔn)確的結(jié)果，平衡精確的術(shù)語匹配和更廣泛的語義理解。

這種方法使您能夠經(jīng)濟(jì)高效地?cái)U(kuò)展到巨大的知識(shí)庫，遠(yuǎn)遠(yuǎn)超出了單個(gè)提示中所能容納的內(nèi)容。但是這些傳統(tǒng)的RAG系統(tǒng)有一個(gè)顯著的局限性：它們經(jīng)常破壞上下文。

傳統(tǒng)RAG中的語境難題

在傳統(tǒng)的RAG中，文檔通常被分成更小的塊以進(jìn)行有效的檢索。雖然這種方法對(duì)于許多應(yīng)用程序都很有效，但當(dāng)單個(gè)塊缺乏足夠的上下文時(shí)，它可能會(huì)導(dǎo)致問題。

例如，假設(shè)您的知識(shí)庫中嵌入了一系列財(cái)務(wù)信息，您收到了以下問題：“ACME Corp在2023年第二季度的收入增長是多少？"

一個(gè)相關(guān)的塊可能包含這樣的文本：“公司的收入比上一季度增長了3%?！叭欢@一大塊本身并沒有指定它所指的是哪家公司或相關(guān)的時(shí)間段，因此很難檢索正確的信息或有效地使用這些信息。

Contextual Retrieval

上下文檢索簡介

上下文檢索通過在嵌入之前將特定于塊的解釋性上下文前置到每個(gè)塊（Contextual Embeddings）并創(chuàng)建BM 25索引（Contextual BM25）來解決這個(gè)問題。

下面是一個(gè)如何轉(zhuǎn)換塊的示例：

原始分塊 = "公司的收入比上一季度增長了3%。"
上下文化分塊 = "這個(gè)分塊來自ACME公司在2023年第二季度的SEC文件；上一季度的收入為3.14億美元。公司的收入比上一季度增長了3%。"

值得注意的是，過去已經(jīng)提出了使用上下文來改進(jìn)檢索的其他方法。其他建議包括：將通用文檔摘要添加到塊，假設(shè)文檔嵌入和基于摘要的索引。這些方法的收益和性能都很低。

實(shí)現(xiàn)上下文檢索

手動(dòng)為知識(shí)庫中的成千上萬個(gè)分塊添加上下文顯然是不現(xiàn)實(shí)的。為此，研究團(tuán)隊(duì)使用了 Claude 模型，通過一個(gè)特定的提示生成每個(gè)分塊的簡潔上下文，生成的上下文通常為 50-100 個(gè) token，然后在嵌入和創(chuàng)建 BM25 索引之前將其添加到分塊中。對(duì)應(yīng)的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.

下面是預(yù)處理流程在實(shí)踐中的樣子：

使用Prompt Caching降低上下文檢索成本

上下文檢索得益于Prompt Caching功能，通過Claude可以以低成本獨(dú)特地實(shí)現(xiàn)。有了提示緩存，您不需要為每個(gè)塊傳入?yún)⒖嘉臋n。您只需將文檔加載到緩存中一次，然后引用之前緩存的內(nèi)容。假設(shè)800個(gè)令牌的塊，8k令牌的文檔，50令牌的上下文指令，以及每個(gè)塊的100令牌的上下文，生成上下文化塊的一次性成本是每百萬文檔令牌1.02美元。

注意事項(xiàng)

在實(shí)現(xiàn)上下文檢索時(shí)，需要記住幾個(gè)注意事項(xiàng)：

1. 塊邊界：考慮如何將文檔拆分為塊。塊大小、塊邊界和塊重疊的選擇會(huì)影響檢索性能。
2. 嵌入模型：雖然上下文檢索提高了我們測試的所有嵌入模型的性能，但某些模型可能比其他模型受益更多。Gemini和Voyage嵌入特別有效。
3. 自定義prompt：雖然通用提示效果很好，但您可以使用針對(duì)特定領(lǐng)域或用例定制的提示（例如，包括可能僅在知識(shí)庫中的其他文檔中定義的關(guān)鍵術(shù)語的詞匯表）來實(shí)現(xiàn)更好的結(jié)果。
4. **塊的數(shù)量：**在上下文窗口中添加更多的塊可以增加包含相關(guān)信息的機(jī)會(huì)。然而，更多的信息可能會(huì)分散模型的注意力，所以這是有限制的。嘗試使用5、10和20塊，發(fā)現(xiàn)使用20塊是這些選項(xiàng)中性能最好的，但值得在您的用例中進(jìn)行試驗(yàn)。

通過Rerank進(jìn)一步提升性能

在傳統(tǒng) RAG 中，AI 系統(tǒng)會(huì)從知識(shí)庫中檢索到大量潛在相關(guān)的信息分塊。對(duì)于大型知識(shí)庫，這一初始檢索往往會(huì)返回大量分塊，有時(shí)多達(dá)數(shù)百個(gè)，且相關(guān)性和重要性各不相同。重排序是一種常用的過濾技術(shù)，確保只有最相關(guān)的分塊被傳遞給模型。實(shí)驗(yàn)結(jié)果顯示，重排序后的上下文嵌入和上下文 BM25 將前 20 個(gè)分塊的檢索失敗率減少了 67%（從 5.7%降至 1.9%）。

成本和延遲考慮

重排序的一個(gè)重要考慮因素是對(duì)延遲和成本的影響，特別是在對(duì)大量塊進(jìn)行重排序時(shí)。因?yàn)橹嘏判蛟谶\(yùn)行時(shí)增加了一個(gè)額外的步驟，所以它不可避免地增加了少量的延遲，即使重排序器并行地對(duì)所有塊進(jìn)行評(píng)分。在重新排序更多塊以獲得更好的性能與重新排序更少塊以降低延遲和成本之間存在固有的權(quán)衡。建議您在特定用例中嘗試不同的設(shè)置，以找到正確的平衡。

總結(jié)

研究團(tuán)隊(duì)通過大量的實(shí)驗(yàn)，為大家指出了一個(gè)新的提升 RAG 性能的方法，為開發(fā)者指出了實(shí)踐新方向。同時(shí)，研究團(tuán)隊(duì)基于大量實(shí)驗(yàn)的結(jié)果，給出了一些關(guān)鍵的經(jīng)驗(yàn)總結(jié)：

1. Embeddings+BM25 比單獨(dú)使用Embeddings效果更好
2. Voyage 和 Gemini 是測試中效果最好的嵌入模型
3. 將前20個(gè)塊傳遞給模型比只傳遞前10個(gè)或前5個(gè)塊更有效
4. 在語塊中加入上下文可以大大提高檢索的準(zhǔn)確率
5. 采用重排序的方法比起不進(jìn)行重排序
6. 將這些改進(jìn)策略綜合起來：為了最大限度地提高性能，我們可以將contextual embeddings（來自Voyage或Gemini）與contextual BM25結(jié)合起來，再加上重新排序步驟，并將20個(gè)塊添加到提示符中。

?

本文轉(zhuǎn)載自公眾號(hào)AI 博物院 作者：longyunfeigu

原文鏈接：??https://mp.weixin.qq.com/s/qEZ-oyzFYDmWJJ0ycFLzDg??