Anthropic 推出上下文檢索：給文本塊補全背景，RAG 錯誤率降 67%

做過檢索增強生成（RAG）的開發者，大概都吃過這種暗虧：辛辛苦苦把上百頁財報切成幾百 token 的小塊存進向量資料庫，結果問模型某家公司第二季度營收漲了多少，系統硬是翻不出來。

翻不出來的根源特別尷尬。切片裡可能清清楚楚寫著「公司營收環比增長了 3%」，但因為切片時丟了上下文，這段話裡既沒有公司名字，也沒有具體年份。向量檢索對不上，精準搜尋也抓瞎。

Anthropic 提出了一個叫「語境檢索」（Contextual Retrieval）的方案，核心思路簡單到讓人意外：在把文本塊送去計算向量和建索引之前，先讓小模型給每個塊在開頭拼上一段 50 到 100 token 的全域性背景說明。

給每個文本塊補上一段自我介紹

傳統 RAG 遇到這種上下文斷裂，往往束手無策。Anthropic 的做法是拉來 Claude 3 Haiku，讓它先讀一遍整篇文件，然後為每一個切片寫一段簡短的定位描述。

比如原來孤零零的「營收環比增長 3%」，被模型處理後，開頭就會加上「這段內容出自 ACME 公司 2023 年第二季度財報」。處理完的切片，再分別去做向量嵌入和 BM25 關鍵詞索引。

這裡保留老牌演算法 BM25 是個很務實的細節。純向量模型雖然擅長理解意思，但經常抓不住特定的錯誤程式碼或型號。要是使用者搜一個「TS-999」，向量模型可能只找來一大堆通用的故障排查指南，而 BM25 卻能憑著精確字元把目標直接撈出來。

Anthropic 在程式碼庫、小說、ArXiv 論文和科學論文上的測試表明，單用語境向量檢索就能把 top-20 的檢索失敗率降低 35%。如果把語境向量和語境 BM25 結合，失敗率直接降了 49%；要是再加一道重排序，失敗率降幅能達到 67%。

用提示詞快取把預處理成本打下來

很多團隊之前不是想不到這個思路，而是算力賬根本算不過來。幾十萬個切片，每個都要讓大模型讀一遍整篇長文件來補上下文，API 賬單分分鐘爆表。

Anthropic 這次能跑通，關鍵在於他們前陣子剛上線的 Prompt Caching（提示詞快取）。處理同一篇文件的不同切片時，長文件只需要寫入快取一次，後續呼叫直接複用。

按照他們的測算，拿 8000 token 的文件切成 800 token 的塊來算，處理一百萬 token 的文件，生成上下文的一次性成本大概只需要 1.02 美元。

如果你的知識庫體量更小，連 20 萬 token（大約 500 頁材料）都不到，Anthropic 甚至建議乾脆別折騰 RAG 了。直接用提示詞快取把全部內容一股腦塞進 prompt，延遲能降低兩倍以上，費用還能省 90%。

為什麼重要

對正在搭建企業知識庫或垂直客服的團隊來說，這套方案几乎是目前價效比最高的一劑止痛藥。RAG 最讓人頭疼的就是召回準確率卡在瓶頸期，花幾塊錢給存量文件跑一遍批次預處理，就能讓召回失敗率腰斬，這筆投入無論怎麼算都很划算。

對行業來說，Anthropic 實際上在糾偏一種盲目追求複雜架構的風氣。過去一年裡，為了解決切片丟失上下文的問題，業界折騰出了圖 RAG、多級遞迴切片、甚至一堆複雜的自主檢索智慧體，把管道搞得無比臃腫。

我們認為，Anthropic 走得極其聰明的地方在於，他們用極度廉價的輕量模型把問題在「資料準備階段」就給抹平了，甚至還順手盤活了傳統 BM25 演算法。不過看起來這套方案也有侷限，它的成本優勢高度依賴提示詞快取，而且只適合相對靜態的知識庫；如果你的資料每分每秒都在高頻增刪變動，每次更新都要重新跑一遍上下文生成，維護成本和複雜度依然不可小覷。