一文了解RAG到底是什么?

0 評論 1152 瀏覽 5 收藏 17 分鐘

在人工智能領域,RAG(Retriever-Augmented Generation)技術正逐漸成為提升自然語言處理任務性能的關鍵。這種結合了檢索與生成的模型架構,通過從大量文檔中檢索相關信息,并利用這些信息生成響應或文本,顯著提高了預測的準確性。

最近在負責調研RAG產品,雖然之前通過Dify和Coze使用過其中知識庫的RAG功能,但始終對其相關配置能力的理解還較為有限。

RAG(Retriever-Augmented Generation)是一種將檢索與生成相結合的人工智能模型架構。

當大模型回答問題或生成文本,首先從大量文檔中檢索相關信息,隨后再利用這些檢索到的信息來生成響應或文本,從而提高預測的質量。

其主要用于知識密集型的自然語言處理任務,尤其是在需要結合外部知識庫的信息生成高質量文本的場景中。

于是在惡補了2周知識后,結合自己所關注的點,現梳理出一篇關于RAG到底是什么的文章(其中大部分信息來源于整合,小部分內容為個人見解)。

本文將分為3大部分:

1、RAG到底是什么?

2、RAG能幫助企業做什么?

3、RAG未來將怎樣發展?

01 RAG到底是什么?

2020年,首次出現了RAG這個概念,但其真正火起來也是自ChatGPT發布以后(2022年12月)才開始的。前面應用ChatGPT給出了官方一些的說明,本質上其給大模型帶來的價值可以粗略提煉為:沒有應用RAG技術的大模型在回答問題時是閉卷考試,而應用了RAG技術的大模型則是——通過外掛了一個知識庫來實現開卷考試。

目前大模型在生成回答時有3大問題:容易出現幻覺、缺乏專業知識、回答缺乏可解釋性,而RAG技術通過外掛專業的知識庫、在生成答案時結合知識庫回答問題、同時在最終生成結果中展示知識庫信息來源,一定程度上有效的解決了這3大問題。

那么,RAG是怎樣解決上面這3大問題的呢?

首先我們來看一下RAG的架構,整體分為索引、檢索、增強、生成4個大的階段:

1.1 索引Indexing

這一步指通過內容分塊、向量化等方式,生成索引并存入向量數據庫。為什么這里這么麻煩,既要分塊又要做向量化處理來建索引,而不是像一些關系型數據庫直接去建立索引呢?

這是核心因為2個點:

(1)大模型需要通過向量化去建立語義理解。

通過將包含高維信息的知識降維拍到向量空間里,這些知識就變成了一堆數字串;此時,當用戶去提問時,先將提問的知識向量化變成一串數字后,再從知識庫中通過余弦計算等方式找出和用戶提問數字串最相似的信息出來,這就完成了所謂的語義理解(當然這塊還有復雜的對稱和不對稱計算等,不做展開了)。

(2)分塊能夠有效提升檢索效率和緩解上下文長度限制。

理想狀態下,在檢索時將每個信息都遍歷一遍肯定就不會漏信息了,但是當信息量大且不能讓用戶等待過久的時候,還是需要更高效和更具性價比的方式;同時,大模型一次能輸入的上下文有長度限制,雖然已經有大模型將上下文長度延伸至了更高量級,但似乎實驗證明更大的上下文窗口不一定對檢索結果更有效。

而分塊技術,則可以理解為將一篇50w字的書籍文檔按照段落或者語義等方式劃分成n個塊。這樣,既能夠有效解決上下文長度限制問題,同時也對于檢索有一定的效率提升;但同時也存在可能會丟失文檔的全局結構、不同塊之間的前后邏輯等問題(不過這些問題都在陸續通過建立重疊上下塊內容、建立塊的類似索引結構等方式逐漸解決中)。

1.2 檢索Retrieval

當用戶提問后,通過檢索技術則可以從知識庫中召回相關內容塊。根據2024年一篇很火的RAG論文,其將RAG劃分為3大范式:原生RAG、先進RAG、模塊化RAG。

目前2024年基本大部分廠商已經在第二步(先進RAG)這一層面了,例如Dify就有全文檢索和向量檢索2種模式。

因此,在檢索這一步,我特地畫了2種混合檢索來做示意,個人判斷混合檢索會是未來的一大趨勢,因為每種檢索都有其優勢和弊端,只有結合才能取長補短。而檢索方式將不局限于關鍵詞檢索和向量檢索,最終的形態一定是多種檢索方式的結合和互補。當混合檢索結束后,再通過一個Rerank的機制重新對不同渠道的檢索結果做一個最終的整合和排序。

1.3 增強Augment

當重排序結束后,將生成最終前n個匹配度最高的內容塊,將這些內容塊與用戶的查詢、系統配置的prompt等做整合,一并讓大模型根據這些信息生成最終的回答。

在整個完整的RAG過程中,索引和檢索將極大的影響最終生成的質量。

02 RAG能幫助企業做什么?

從下述生成式AI技術應用跟蹤來看,目前最常見的幾大使用場景:知識助手、智能客服、數據分析等無一例外都應用到了知識庫及RAG技術。

當企業某一業務存在大量重復性、知識密集型且標準化較高的特征時,則可以考慮使用RAG來搭建一個問答機器人。如果是搭建基礎知識問答助手,FastGPT、Dify社區版、Coze都可以很快捷地進行知識庫的搭建,也有完整的FAQ支持。

以我們公司為例,產品本身專業性強所以使用門檻較高,因此搭建了圍繞產品使用的問答助手;

某醫療公司每年都會推出新的醫療器械、醫藥等,醫藥代表不一定能及時記憶最新的產品和細節,則可以通過新產品問答助手隨時查詢圍繞產品的細節;

而某高端社區打造了社區內部的社群服務,每天都要頻繁被咨詢如何創建社群、如何參加活動、停車、wifi等問題,此時他們則選擇通過AI客服助手來解決重復回答效率低的問題。

如今的AI問答其優勢在于能夠很好的理解自然語言、并很好的生成自然語言,這讓對話不再顯得是那么的「人工智障」和生硬(雖然又會容易存在幻覺問題,但問題總在解決的過程中嘛)。

當然,如果是搭建復雜的知識問答助手,其難點還是在于:

  1. 面向問答機器人使用場景下,額外所需的文檔整理:例如某企業做了一個財務助手,對于某項報銷條款,不同角色能看到的內容是不同的,而這就倒逼企業對該條款進行一些元數據的二次處理
  2. 面向特定使用場景的索引與檢索策略:不同使用場景的前述2種策略往往有差異。

例如某產品推薦場景下,針對結構化的產品數據則不需要做內容分塊,直接針對字段進行向量化和關鍵詞檢索即可;

針對某醫療問診助手場景下的大量非結構化和疾病相關的pdf文檔,則需要分塊向量化;

而針對某社區提供的社群問答助手場景,其直接提供了數十個Q&A結構的文檔,那自然按照原始的Q&A結構去做問題的分塊,才能更好的保證最終的檢索結果。

03 RAG未來將怎樣發展?

2024年這一年,RAG領域出現了非常多的論文,夸張的時候一周可能有十多篇。同時,根據下圖這篇報告,2024年RAG占據設計的主導地位,而提示詞和微調已逐漸有些弱化掉了。這說明,RAG正處在一個大家對其充滿期望和肯定的蓬勃探索期。

這一年,RAG領域涌現了諸多新思路和新技術,以下列舉比較熱門的3個:

1、通過提煉內容結構和宏觀理解等來縮減語義鴻溝:如GraphRAG、SiReRAG、RAPTOR

以GraphRAG為例,這是一種微軟在24年中開源的圖RAG技術,其本質上是將知識圖譜和RAG做了融合。

通過利用大模型自動抽取文檔內的命名實體,然后利用這些實體自動構建知識圖譜。在圖譜中,同樣利用聚類產生實體聚集的“社區”,并利用 LLM 生成這些社區的摘要。在召回的時候,知識圖譜的實體、邊、以及社區摘要,它們連同原始文檔一起來做混合召回。

由于這些數據同樣形成了文檔中跨 Chunk 的關聯信息,因此對于宏觀性提問,多跳提問,有著更好的效果。GraphRAG 可以看作是解決語義鴻溝的當下行之有效的策略和架構。

2、通過Agent來加強RAG:即Agentic RAG

RAG 本身是 Agent 的重要算子,它可以解鎖 Agent 訪問內部數據的能力;Agent 直接用于 RAG,可以提供高級 RAG 能力,這就是所謂 Agentic RAG。

在RAG的過程中,諸如該如何進行分塊、該如何選擇檢索方式、如何選擇最終召回結果、召回效果怎么樣評估、基于多跳問題該如何補足等,都可以利用大模型的能力打造一個獨立的Agent來實現。

3、多模態RAG

未來的 RAG 系統不僅限于文本檢索,還將能夠處理圖像、音頻等多種媒體類型。大模型將能夠理解并生成包含文本、圖像和聲音的信息,為用戶提供更豐富的互動體驗。

對于RAG未來將怎樣發展這個命題,我同意RAGFlow負責人的觀點:

RAG 就相當于過去的數據庫,對外暴露的接口無比簡單,內部卻無比復雜,它不僅僅包含了數據庫本身,還包含了各種小模型以及把它們串接起來的工具,從本質上來說,它就是過去的企業搜索引擎在大模型時代的進化,但它又大大超出了搜索引擎本身的范疇。

最后呢,我對未來的RAG的設想有如下3個:

1)未來的RAG應該是在數據源和上層AI應用中間去搭建橋梁的關鍵角色。

基于上層AI應用的訴求,對數據源制定不同的RAG策略,從而讓RAG能夠更好的服務于應用的效果。

2)未來的RAG會因為微調和大模型本身的技術/性能突破而變得更加簡單和統一化。

現在的很多RAG策略其實都是為了補足微調和大模型的短板而設計的,就像2023年最火的技術是門檻最低的Prompt、2024年最火的技術是RAG、2025年最火的技術將是Agent一樣,未來門檻越高的技術(如微調)將逐漸變低,這對原來更為簡單的技術會造成極大的影響。

而關于RAG的各類思路、技術也將逐漸收斂,其范式也將逐漸趨于穩定和主流。

3)未來的RAG將作為關鍵支撐層服務于Agent。

講到這里,一定會有很多伙伴提出問題,就是未來的演進究竟是RAG把自己變成一個Agent平臺,還是各種Agent平臺把自己的RAG能力增強?這個趨勢很難預測:正如我們在數字化時代,究竟是做數倉的,把做中臺這種包含業務的事情也做下來,還是做業務的最終下沉自身技術能力提供更好的數倉,兩者都有先例。

針對RAGFlow負責人對于RAG和Agent關系的如上觀點,我有不一樣的看法:我認為RAG最終還是要服務于Agent的。

客戶不可能用A平臺去做獨立的知識庫、B平臺去做獨立的Agent;客戶也不可能停留在做一個以RAG技術為主的問答助手,除了基礎問答外,肯定會伴隨著希望更多的流程和SOP自動化智能化。此時,就會優先選擇Agent平臺去做集成:既能做流程、又能做知識。

因此,如果選擇繼續做RAG類產品:

  1. 至少要比agent平臺的知識庫做的靈活和更好(例如RAG三大范式里的Modular RAG)
  2. 設計好開放能力、準備和更多的上層Agent應用做對接和被集成

That’s all,以上就是對RAG的一些初步整合和淺見,如有問題煩請指正~后續也將針對RAG領域做更多產品類調研,歡迎關注。

專欄作家

冰冰醬;公眾號:冰冰醬啊,人人都是產品經理專欄作家。5年產品經驗,創過業、帶過人、踩過坑;獨立負責從0-1搭建業務中臺,持續深耕B端及SaaS領域。

本文原創發布于人人都是產品經理,未經許可,不得轉載。

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

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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!