AI時代產品經理必須懂得的技術,談談Rag的產生原因、基本原理與實施路徑

1 評論 382 瀏覽 3 收藏 26 分鐘

在人工智能領域,RAG技術正成為推動大模型應用的關鍵。本文將深入探討RAG技術的原理、挑戰以及在不同階段的優化策略,幫助讀者全面了解并有效實施這一技術。如果你對提升AI Agent的性能感興趣,不妨繼續閱讀。

《大佬們都在關注的AI Agent,到底是什么?用5W1H分析框架拆解AI Agent(上篇)》中,風叔提到要實現良好的AI Agent性能,RAG技術的使用至關重要,今天我們就來重點談一談RAG。

對于Rag系統的整體框架,風叔做了梳理。想提前了解全部內容的同學,可以關注GZH“風叔云”,回復關鍵詞“Rag框架”,獲取完整內容。

一、什么是Rag?

RAG,Retrieval-Augmented Generation,中文名檢索增強生成,是AI領域非常重要的一種技術方案。其核心作用是給LLM大模型外掛專門的知識庫,指導大模型生成更準確的輸出。

為什么要給LLM大模型外掛知識庫呢?因為雖然大模型的能力越來越強大,但其內在的缺點也非常明顯。

第一,存在幻覺問題。LLM大模型的底層原理是基于數學概率進行預測,其模型輸出本質上是一種概率預測的結果。所以LLM大模型有時候會出現胡言亂語,或者生成一些似是而非的答案,在大模型并不擅長的領域,幻覺問題會更加嚴重。使用者要區分幻覺問題是非常困難的,除非使用者本身就具備了相應領域的知識,但這里就會存在矛盾,已經具備相關知識的人是不會采用大模型生成的答案的。

第二,缺乏對生成結果的可解釋性。LLM大模型本身就是一個黑盒,這個模型使用了什么數據進行訓練,對齊策略是怎么樣的,使用者都無從得知。所以對于大模型生成的答案,更加難以追蹤溯源。

第三,缺乏對專業領域知識的理解。LLM大模型知識的獲取嚴重依賴訓練數據集的廣度,但目前市面上大多數的數據訓練集都來源于網絡公開數據,對于企業內部數據、特定領域或高度專業化的知識,大模型無從學習。因此大模型的表現更像是一個及格的通才,但是在一些專業場景,比如企業內部的業務流,一個及格的通才是無法使用的,需要利用企業的專屬數據進行喂養和訓練,打造為優秀的專才。

第四,數據的安全性。這是對上面第三點的延伸,沒有企業愿意承擔數據泄露的風險,將自身的私域數據上傳第三方平臺進行訓練。因此,完全依賴通用大模型自身能力的應用方案,在企業場景下是行不通的。

第五,知識的時效性不足。大模型的內在結構會被固化在其被訓練完成的那一刻,但是當你詢問大模型一些最新發生的事情,則難以給出答案。

為了克服這些問題,第一種方式是微調,即Finetune。但是由于生成模型依賴于內在知識,也就是各類參數的權重,即使做了微調,模型還是無法擺脫幻覺問題。此外在實際場景中,很多新的信息、數據、政策每時每刻都在產生,除非對模型進行高頻的微調,否則模型的訓練速度永遠趕不上外部信息更新的速度,而高頻微調的成本就太高了,

在2020 年,Meta AI 的研究人員提出了檢索增強生成(RAG)的方法,為LLM大模型提供了一種與外部信息高效互動的解決方案。其主要作用類似于搜索引擎,找到用戶提問最相關的知識或者是相關的對話歷史,并結合原始提問,創造信息豐富的prompt,指導LLM大模型生成更準確的輸出。

這就是Rag技術產生的背景和原因。

二、Rag技術的基本原理

聊聊炙手可熱的Rag:產生原因、基本原理與實施路徑

RAG可分為5個基本流程:知識文檔的準備、嵌入模型、存入向量數據庫、查詢檢索和生產回答。

現實場景中,我們面對的知識源可能包括多種格式,如Word文檔、TXT文件、CSV數據表、Excel表格,甚至圖片和視頻。因此需要使用專門的文檔加載器(例如PDF提取器)或多模態模型(如OCR技術),將這些豐富的知識源轉換為大語言模型可理解的純文本數據,然后開啟RAG的五個核心步驟。

第一步,文檔切片/分塊:在企業級應用場景中,文檔尺寸可能非常大,因此需要將長篇文檔分割成多個文本塊,以便更高效地處理和檢索信息。分塊的方式有很多種,比如按段落、按內容或者其他特殊結構。同時,需要注意分塊的尺寸,如果分塊太小,雖然查詢更精準,但召回時間更長;如果分塊太大,則會影響查詢精準度。

第二步,嵌入模型:嵌入模型的核心任務是將文本轉換為向量形式,這樣我們就能通過簡單的計算向量之間的差異性,來識別語義上相似的句子。

第三步,存入向量數據庫:將文檔切片和嵌入模型的結果存儲進入向量數據庫。向量數據庫的主要優勢在于,它能夠根據數據的向量接近度或相似度,快速、精確地定位和檢索數據,實現很多傳統數據庫無法實現的功能,比如根據旋律和節奏搜索出特定的歌曲、在電影中搜索浪漫的片段、在文檔中找出意圖相近的段落等等。

第四步,用戶查詢檢索:用戶的問題會被輸入到嵌入模型中進行向量化處理,然后系統會在向量數據庫中搜索與該問題向量語義上相似的知識文本或歷史對話記錄并返回,這就是檢索增強。

第五步,生成問答:最終將用戶提問和上一步中檢索到的信息結合,構建出一個提示模版,輸入到大語言模型中,由大模型生成最終的結果并返回。

Rag技術一經問世,就取得了非常廣泛的使用,成為AI大模型產品落地中必不可少的一環。根據具體的使用場景,可以分為以下幾類。

  1. 通用問答系統:RAG可以根據檢索到的相關信息生成準確的答案,幫助員工更快地獲取所需信息,提高決策效率,比如搭建企業內部知識庫、公司規章制度查詢、新員工入職培訓、公司合同資料解讀和查詢等。
  2. 智能客服系統:RAG可以結合產品資料知識庫、聊天記錄、用戶反饋等數據,自動為用戶提供更精準的回答,已經有非常多的初創公司選擇用RAG技術構建新一代的智能客服系統。
  3. 智能數據分析:RAG可以結合外部數據源,如數據庫、API、文件等,為用戶提供更便捷的數據分析服務。傳統企業的數據分析主要靠BI分析師,每天都需要寫大量的SQL語句進行查詢,而在RAG的支持下,企業的每個員工都能以自然對話的方式獲取數據。比如門店店長直接用語音對話,“請幫我找出上周銷量排名前10,但本周銷量下滑最快的品類”,系統即可直接給出答復。
  4. 自動化文檔處理:企業還可以利用RAG和LLM大模型自動化文檔處理流程,例如自動生成合同、撰寫周報、總結會議紀要等,節省時間和人力成本。

三、Rag實施路徑

Rag技術雖然相對比較容易入門,但是要部署到生產環境并且對外提供穩定的服務,還是有很多路要走的,尤其是其流程的各個環節都有非常多的優化空間。

從優化的方向來看,主要包括四個方面,知識分塊與索引優化、用戶query改寫優化、數據召回優化和內容生成優化。當然,“羅馬不是一天建成的”,Rag相關項目的實施也需要分階段逐步進行迭代和優化,風叔建議可以按照以下三個階段來實施。

第一階段,可運行,即系統能跑通整體流程

1)知識分塊與索引

在RAG系統中,文檔需要分割成多個文本塊再進行向量嵌入。在不考慮大模型輸入長度限制和成本問題情況下,其目的是在保持語義上的連貫性的同時,盡可能減少嵌入內容中的噪聲,從而更有效地找到與用戶查詢最相關的文檔部分。

如果分塊太大,可能包含太多不相關的信息,從而降低了檢索的準確性。相反,分塊太小可能會丟失必要的上下文信息,導致生成的回應缺乏連貫性或深度。

第一階段可先按固定字符拆分知識,并通過設置冗余字符來降低句子截斷的問題,使一個完整的句子要么在上文,要么在下文。這種方式能盡量避免在句子中間斷開的問題,且實現成本最低,非常適合在業務起步階段。

2)用戶Query改寫

在RAG系統中,用戶的查詢問題會被轉化為向量,然后在向量數據庫中進行匹配,因此查詢的措辭準確度會直接影響搜索的結果。在向量空間中,對人類來說看似相同的兩個問題其向量大小并不一定很相似

我們可以采用“查詢重寫”方案,即直接利用LLM大模型重新表述問題。在進行多輪對話時,用戶提問中的某些內容可能會指代上文中的部分信息,可以將歷史信息和用戶提問一并交給LLM大模型進行重新表述。

總體來說,第一階段可以先直接使用大模型的理解能力,結合上下文,突出用戶意圖。此時不需要做過多的Query改寫,以測試大模型理解能力和跑通流程為主。

3)數據召回

第一階段可以先使用最簡單的向量召回方式,找到在語義向量維度最近似的答案進行召回。這里需要注意的是,要找一個和自己業務比較契合的embedding模型和向量數據庫。

召回結果的數量是另一個關鍵因素,更多的結果可以提供豐富的預料,有助于系統更好地理解問題的上下文和隱含細節。但是結果數量過多可能導致信息過載,降低回答準確性并增加系統的時間和資源成本。第一階段我們可以先把召回數量設置為10。

4)內容生成

內容生成環節更多的是考慮用戶體驗,在第一階段我們可以先簡單一些,能順利輸出答案即可。因為數據召回環節只有向量召回,因此這一步可以只將上一步召回環節返回的top 10的知識篩選出來,然后提供給大模型生成答案。

第一階段的系統可能會存在較多問題,大家會發現生成答案的相關性和準確度都比較低。但是沒關系,這一階段的首要任務是跑通系統流程,優化的工作我們放在第二和第三階段再做。

第二階段,可使用,即系統初步達到可上線水平

1)知識分塊與索引

知識的分塊與索引,對最終答案生成的準確性有非常大的影響,尤其是在處理超長文本的時候,會出現索引混淆問題。

索引混淆是指知識文檔的核心關鍵詞被湮沒在大量的無效信息中,比如大量無關緊要的助詞、語氣詞、或無關信息,導致建立的索引中核心知識比重少,從而影響生成答案的質量。針對這個問題,我們可以采用三種優化方案,索引降噪、多級索引和HYDE。

索引降噪:是根據業務特點,去除索引數據中的無效成分,突出其核心知識,從而降低噪音的干擾,保障核心知識的比重。比如原文檔內容是“How can I download source code from github.com”,其核心內容是“download source code、github”,其他噪音可以忽略。

多級索引:是指創建兩個索引,一個由文檔摘要組成,另一個由文檔塊組成,并分兩步搜索,首先通過摘要過濾掉相關文檔,然后只在這個相關組內進行搜索。這種多重索引策略使RAG系統能夠根據查詢的性質和上下文,選擇最合適的索引進行數據檢索,從而提升檢索質量和響應速度。但為了引入多重索引技術,我們還需配套加入多級路由機制,比如對于查詢“最新發表的Rag論文推薦”,RAG系統首先將其路由至論文專題的索引,然后根據時間篩選最新的Rag相關論文。

聊聊炙手可熱的Rag:產生原因、基本原理與實施路徑

HYDE:全稱是Hypothetical Document Embeddings,用LLM生成一個“假設”答案,將其和問題一起進行檢索。HyDE的核心思想是接收用戶提問后,先讓LLM在沒有外部知識的情況下生成一個假設性的回復。然后,將這個假設性回復和原始查詢一起用于向量檢索。假設回復可能包含虛假信息,但蘊含著LLM認為相關的信息和文檔模式,有助于在知識庫中尋找類似的文檔。

聊聊炙手可熱的Rag:產生原因、基本原理與實施路徑

2)用戶Query改寫

直接使用原始的用戶query進行檢索,會存在一些問題。比如知識庫內的數據無法直接回答,需要組合多種知識才能找到答案;此外,涉及細節比較多的問題,大模型往往無法進行高質量的回答??梢允褂肦ag-Fusion進行優化。

RAG-Fusion:首先對用戶的原始query進行擴充,即使用 LLM 模型對用戶的初始查詢,進行改寫生成多個查詢;然后對每個生成的查詢進行基于向量的搜索,形成多路搜索召回;接著應用倒數排名融合算法,根據文檔在多個查詢中的相關性重新排列文檔,生成最終輸出。

聊聊炙手可熱的Rag:產生原因、基本原理與實施路徑

3)數據召回

在第一階段,我們使用了單純的語義向量做召回,但是當文本向量化模型訓練不夠好時,向量召回的準確率會比較低,此時需要利用其他召回方式作為補充。

分詞召回:一種有效的稀疏搜索算法是最佳匹配25(BM25),它基于統計輸入短語中的單詞頻率,頻繁出現的單詞得分較低,而稀有的詞被視為關鍵詞,得分會較高。我們可以結合稀疏和稠密搜索得出最終結果。

多路召回:多路召回的結果經過模型精排,最終篩選出優質結果。至于使用幾種召回策略,根據業務而定。

聊聊炙手可熱的Rag:產生原因、基本原理與實施路徑

4)內容生成

根據前幾個環節的優化策略,內容生成環節也需要有相應的調整。

文檔合并去重:多路召回可能都會召回同一個結果,針對這部分數據要去重,否則對大模型輸入的token數是一種浪費;其次,去重后的文檔可以根據數據切分的血緣關系,做文檔的合并。

重排模型:重排模型通過對初始檢索結果進行更深入的相關性評估和排序,確保最終展示給用戶的結果更加符合其查詢意圖。這一過程通常由深度學習模型實現,如Cohere模型。這些模型會考慮更多的特征,如查詢意圖、詞匯的多重語義、用戶的歷史行為和上下文信息等。

聊聊炙手可熱的Rag:產生原因、基本原理與實施路徑

經過第二階段的優化,答案生成的相關性和準確度都會大幅提升,但是仍然會有較大概率出現答非所問的情況,我們還需要對系統做更進一步的優化。

第三階段,很好用,即系統回答的準確率達到用戶滿意水平

下面,風叔介紹一些更高級的Rag優化策略。

1)知識分塊與索引

雖然在第二階段,我們通過索引降噪、多級索引、HYDE等方式,大幅提升了知識庫的準確度,但是按固定字符切,有時候會遇到句子含義聯系比較緊密的片段被切分成了兩條數據,導致數據質量比較差。

這個情況下可以嘗試訓練專門的語義理解小模型,然后使用實際語義進行句子拆分,使拆分出來的知識片段語義更加完整。

另外一種方法是構建元數據,增加內容摘要、時間戳、用戶可能提出的問題等附加信息來豐富知識庫,而元數據不需要被向量化。此外,我們還可以添加諸如章節或小節的引用,文本的關鍵信息、小節標題或關鍵詞等作為元數據,有助于改進知識檢索的準確性。

還有一種更加有效的方式是建立知識圖譜。嵌入模型雖然簡單,但是沒法有效捕捉實體之間的復雜關系和層次結構,所以導致傳統RAG在面對復雜查詢的時候特別吃力。比如,用戶詢問“《跨越鴻溝》這本書的主旨是什么”,傳統Rag技術是肯定回答不出來的。但是知識圖譜技術可以做到,因為利用知識圖譜對數據集建立索引的時候,會做提取實體以及實體之間的關系,這樣就能構建一種全局性的優勢,從而提升RAG的精確度。

但是,知識圖譜雖然很強大,可惜成本太高了,會大幅提升token使用量,大家需要綜合產品體驗和成本進行評估。

2)用戶query改寫

Step-Back Prompting:如果果原始查詢太復雜或返回的信息太廣泛,我們可以選擇生成一個抽象層次更高的“退后”問題,與原始問題一起用于檢索,以增加返回結果的數量。例如,對于問題“勒布朗詹姆斯在2005年至2010年在哪些球隊?”這個問題因為有時間范圍的詳細限制,比較難直接解決,可以提出一個后退問題“勒布朗詹姆斯的職業生涯是怎么樣的?”,從這個回答的召回結果中再檢索上一個問題的答案。

3)數據召回

圖譜召回:如果在知識分塊環節使用了知識圖譜,那么我們就可以直接用圖譜召回,大幅提升召回準確度。

Agentic-rag:RAG應用退化成一個Agent使用的知識工具。我們可以針對一個文檔/知識庫構建多種不同的RAG引擎,比如使用向量索引來回答事實性問題;使用摘要索引來回答總結性問題;使用知識圖譜索引來回答需要更多關聯性的問題等。

在單個文檔/知識庫的多個RAG引擎之上設置一個DocAgent,把RAG引擎作為該Agent的tools,并利用LLM的能力由ToolAgent在自己“負責”的文檔內使用這些tools來回答問題。最后設置一個總的頂級代理TopAgent來管理所有的低階DocAgent,將DocAgent看作自己的tools,仍然利用LLM來規劃、協調、執行用戶問題的回答方案

聊聊炙手可熱的Rag:產生原因、基本原理與實施路徑

4)內容生成

Prompt優化:RAG系統中的prompt應明確指出回答僅基于搜索結果,不要添加任何其他信息。例如可以設置prompt:“你是一名智能客服。你的目標是提供準確的信息,并盡可能幫助提問者解決問題。你應保持友善,但不要過于啰嗦。請根據提供的上下文信息,在不考慮已有知識的情況下,回答相關查詢?!?此外,使用Few-shot的方法指導LLM如何利用檢索到的知識,也是提升LLM生成內容質量的有效方法。

Self-rag:self-rag通過檢索評分(令牌)和反思評分(令牌)來提高質量,主要分為三個步驟:檢索、生成和批評。Self-RAG首先用檢索評分來評估用戶提問是否需要檢索,如果需要檢索,LLM將調用外部檢索模塊查找相關文檔。接著,LLM分別為每個檢索到的知識塊生成答案,然后為每個答案生成反思評分來評估檢索到的文檔是否相關,最后將評分高的文檔當作最終結果一并交給LLM。

四、總結

本篇文章重點介紹了Rag技術的概念、產生原因、基本原理和實施路徑,可以作為AI產品經理和研發同學在實際項目中的參考資料。

圍繞Rag相關的各項技術和理念仍然在飛速迭代,從大方向來說,風叔比較看好知識圖譜和AI Agent在Rag系統中的使用。

知識圖譜的成本一定會繼續下降,那么一定存在一個臨界點,即使用知識圖譜帶來的對實體和實體關系的理解優勢,會遠遠大于對成本的考量。

對于AI Agent,其本身和Rag也是相輔相成的關系。Rag系統為AI Agent提供長期記憶能力,而AI Agent的規劃與反思也會為Rag系統提供非常好的規劃管理和路由能力。

相信Rag會在各個領域的AI產品落地過程中,持續扮演重要的角色。

作者:風叔,微信公眾號:風叔云

本文由@風叔 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 一個對我來說全新的東西,如果以后要學習AI的話這個應該會是個重點。

    來自廣東 回復