大模型面經(jīng):RAG與Long context“相愛相殺”背景下,如何設計最優(yōu)解決方案? 原創(chuàng)
本篇分享RAG與long context結合的實踐方案。
本篇始于一個老生常談的話題,“一旦大模型的Context Length變大,RAG還有沒有存活的必要?”
RAG主要通過問題從知識庫中找相關答案,然后把檢索到的內(nèi)容再用大模型總結;Long context相當于把全部文本內(nèi)容輸入給大模型,利用大模型查找或總結。
這兩者評估的維度包括成本、是否使模型變得更智能、是否可以混合檢索和推理、是否可以緩存、推理時間等等。
其實兩者之爭也相當于左右手之爭,最近在工作場景中遇到越來越多兩者不同的場景,本篇就來分享一下目前是如何結合兩種方法。
下面是一個具體示例。
目前有5M token量級的私有化醫(yī)療知識庫,需要搭建智能問診系統(tǒng),如何巧妙結合RAG與Long context設計你的最優(yōu)方案?
1. 思路
首先來梳理一下需求:醫(yī)療場景對準確性要求非常高,另外知識更新頻繁,并且需要處理病史、檢查報告等長文本。
那么現(xiàn)在來分析一下這兩種技術起到的作用:
- RAG優(yōu)勢:可以精準定位最新知識,降低幻覺風險
- Long context優(yōu)勢:可以結合推理理解復雜癥狀關聯(lián),處理多輪對話上下文
另外基于現(xiàn)狀進行分析,首先如果只用LLM,5M token的文檔全量輸入LLM從哪個角度考慮都是不現(xiàn)實的,成本高,性能還差;如果單純使用RAG又可能遺漏跨文檔關聯(lián)推理。
2. 方案
首先設計一個動態(tài)路由層,主要需要做三件事,包括相關文檔查找,潛在文檔關聯(lián)以及深度語義關聯(lián)。
第一層:相關文檔查找
基于輕量級Embedding模型快速檢索,篩選Top5相關文檔,這里還有一些顯得比較專業(yè)的trick,比如Embedding模型是如何選擇的?BAAI or bge-small?是否合理?有沒有做query rewriting?等等。
第二層:潛在文檔關聯(lián)
可以構建文檔關系圖譜,通過Graph RAG識別潛在關聯(lián)文檔;也可以自建一個知識圖譜架構進行識別。
第三層:深度語義關聯(lián)
對精選的3-5份文檔使用Long context窗口進行深度語義關聯(lián)分析。
另外建立緩存也是必須的,緩存優(yōu)化策略包括直接建立癥狀-診斷pair的向量緩存庫,長尾查詢,動態(tài)模型切換等等。
更精細的調(diào)整還包括:
- 漸進式的上下文注入:首次響應的時候使用RAG精準片段和關鍵元數(shù)據(jù),在追問階段采用滑動窗口機制(不無限制增加上下文,需要保留最相關的部分),逐步注入關聯(lián)文檔的全文。
- 多重驗證:使用輸出結果反向檢索知識庫,進行實時校驗;后期構建診斷邏輯鏈的可視化追溯校驗。
從上面的步驟基本可以完成整個方案的設計,如果更細節(jié)的話面試官可能會讓寫一個動態(tài)路由的代碼,下面是一個示例
class MedicalReasoner:
def __init__(self):
self.retriever = HybridRetriever(knowledge_graph) # 結合向量+圖檢索
self.llm = MedPaLM(chunk_size=8192) # 定制醫(yī)療長文本處理模型
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
)
最后如果還需要更深度的表達,還有一些細節(jié)內(nèi)容可以去潤色,比如:
建立快速檢索的過程中,用fasis進行索引還是自研了召回機制,采用了什么壓縮策略?如何評估召回好不好?有沒有對RAG prompt進行優(yōu)化,進行引導式摘要、多段拼接、answer-aware檢索等等...
文轉載自公眾號瓦力算法學研所,作者:喜歡瓦力的卷卷
原文鏈接:??https://mp.weixin.qq.com/s/LLipYnSBWC-I0dC_ZZS3UA??
