本篇分享RAG與long context結合的實踐方案。

本篇始于一個老生常談的話題，“一旦大模型的Context Length變大，RAG還有沒有存活的必要？”

RAG主要通過問題從知識庫中找相關答案，然后把檢索到的內容再用大模型總結；Long context相當于把全部文本內容輸入給大模型，利用大模型查找或總結。

這兩者評估的維度包括成本、是否使模型變得更智能、是否可以混合檢索和推理、是否可以緩存、推理時間等等。

其實兩者之爭也相當于左右手之爭，最近在工作場景中遇到越來越多兩者不同的場景，本篇就來分享一下目前是如何結合兩種方法。

下面是一個具體示例。

目前有5M token量級的私有化醫療知識庫，需要搭建智能問診系統，如何巧妙結合RAG與Long context設計你的最優方案？

1. 思路

首先來梳理一下需求：醫療場景對準確性要求非常高，另外知識更新頻繁，并且需要處理病史、檢查報告等長文本。

那么現在來分析一下這兩種技術起到的作用：

• RAG優勢：可以精準定位最新知識，降低幻覺風險
• Long context優勢：可以結合推理理解復雜癥狀關聯，處理多輪對話上下文

另外基于現狀進行分析，首先如果只用LLM，5M token的文檔全量輸入LLM從哪個角度考慮都是不現實的，成本高，性能還差；如果單純使用RAG又可能遺漏跨文檔關聯推理。

2. 方案

首先設計一個動態路由層，主要需要做三件事，包括相關文檔查找，潛在文檔關聯以及深度語義關聯。

第一層：相關文檔查找

基于輕量級Embedding模型快速檢索，篩選Top5相關文檔，這里還有一些顯得比較專業的trick，比如Embedding模型是如何選擇的？BAAI or bge-small？是否合理？有沒有做query rewriting？等等。

第二層：潛在文檔關聯

可以構建文檔關系圖譜，通過Graph RAG識別潛在關聯文檔；也可以自建一個知識圖譜架構進行識別。

第三層：深度語義關聯

對精選的3-5份文檔使用Long context窗口進行深度語義關聯分析。

另外建立緩存也是必須的，緩存優化策略包括直接建立癥狀-診斷pair的向量緩存庫，長尾查詢，動態模型切換等等。

更精細的調整還包括：

• 漸進式的上下文注入：首次響應的時候使用RAG精準片段和關鍵元數據，在追問階段采用滑動窗口機制（不無限制增加上下文，需要保留最相關的部分），逐步注入關聯文檔的全文。
• 多重驗證：使用輸出結果反向檢索知識庫，進行實時校驗；后期構建診斷邏輯鏈的可視化追溯校驗。

從上面的步驟基本可以完成整個方案的設計，如果更細節的話面試官可能會讓寫一個動態路由的代碼，下面是一個示例

class MedicalReasoner:
    def __init__(self):
        self.retriever = HybridRetriever(knowledge_graph)  # 結合向量+圖檢索
        self.llm = MedPaLM(chunk_size=8192)  # 定制醫療長文本處理模型
    def diagnose(self, query):
        # 階段1：精準檢索
        base_docs = self.retriever.search(query)  
        # 階段2：上下文增強
        extended_context = self._expand_context(base_docs)  
        # 階段3：長文本推理
        return self.llm.generate(
            prompt=build_prompt(query, extended_context),
            max_tokens=2048
        )

最后如果還需要更深度的表達，還有一些細節內容可以去潤色，比如：

建立快速檢索的過程中，用fasis進行索引還是自研了召回機制，采用了什么壓縮策略？如何評估召回好不好？有沒有對RAG prompt進行優化，進行引導式摘要、多段拼接、answer-aware檢索等等...  

文轉載自公眾號瓦力算法學研所，作者：喜歡瓦力的卷卷

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