大模型RAG技術

petercao發表於2024-06-27
大模型

在人工智慧領域，大模型RAG技術（Retrieval-Augmented Generation）已成為近年來研究的熱點。它結合了檢索和生成兩大關鍵技術，為自然語言處理任務帶來了革命性的進步。本文將帶領大家深入瞭解大模型RAG技術的全流程，讓你輕鬆掌握這一前沿技術。

一、RAG技術概述

RAG技術，即檢索增強生成技術，是一種將檢索和生成相結合的自然語言處理技術。它利用大規模的語料庫進行資訊檢索，為生成過程提供豐富的背景知識和上下文資訊，從而提高生成結果的準確性和多樣性。RAG技術廣泛應用於文字生成、對話系統、問答系統等領域。

二、RAG技術工作流程

  1. 預處理：首先，對大規模的語料庫進行預處理，包括分詞、去除停用詞、構建詞彙表等步驟。這些預處理操作有助於提取出文字中的有效資訊，為後續的檢索和生成過程奠定基礎。

  2. 檢索：在生成過程中，RAG技術會根據當前的上下文資訊，在語料庫中檢索相關的文字片段。這個檢索過程通常基於某種相似度度量方法，如餘弦相似度、TF-IDF等。檢索結果將作為生成過程的參考和補充。

  3. 生成：在得到檢索結果後，RAG技術會利用生成模型（如Transformer、GPT等）來生成新的文字。生成過程會綜合考慮當前的上下文資訊、檢索結果以及生成模型自身的知識庫，從而生成更加準確、多樣的文字。

  4. 後處理：最後，對生成的文字進行後處理，包括去除重複、修正語法錯誤等步驟。這些後處理操作有助於提高生成結果的質量。

RAG架構

下面我們來了解一下RAG，它有非常多的元件，但是我們可以化繁為簡。我喜歡把RAG——Retrieval Augmented Generation理解為Retrieval And Generation，也就是檢索與生成，在加上一個資料向量和索引的工作，我們對RAG就可以總概方式地理解為“索引、檢索和生成”。

以下就是RAG的主要組成，依次是資料提取——embedding（向量化）——建立索引——檢索——自動排序（Rerank）——LLM歸納生成。當然這裡少了使用環節，我們暫時先忽略使用者提問的環節。

1

RAG技術細節概覽

在技術細節上，我們還可以分成更細的組成。

2

一、資料索引

  • 資料提取

    • 資料清洗：包括資料Loader，提取PDF、word、markdown以及資料庫和API等；
    • 資料處理：包括資料格式處理，不可識別內容的剔除，壓縮和格式化等；
    • 後設資料提取：提取檔名、時間、章節title、圖片alt等資訊，非常關鍵。

  • 分塊（Chunking）

    • 固定大小的分塊方式：一般是256/512個tokens，取決於embedding模型的情況。但是這種方式的弊端是會損失很多語義，比如“我們今天晚上應該去吃個大餐慶祝一下”，很有可能就會被分在兩個chunk裡面——“我們今天晚上應該”、“去吃個大餐慶祝一下”。這樣對於檢索是非常不友好的，解決方法是增加冗餘量，比如512tokens的，實際儲存480tokens，一頭一尾去儲存相鄰的chunk頭尾的tokens內容；
    • 基於意圖的分塊方式：
      • 句分割：最簡單的是透過句號和換行來做切分。當然也有透過專業的意圖包來切分的，常用的意圖包有基於NLP的NLTK和spaCy；
      • 遞迴分割：透過分治的方法，用遞迴切分到最小單元的一種方式；
      • 特殊分割：還有很多不常見的，用於特殊場景，這裡就不提了。
    • 影響分塊策略的因素：
      • 取決於你的索引型別，包括文字型別和長度，文章和微博推文的分塊方式就會很不同；
      • 取決於你的模型型別：你使用什麼LLM也會有不同，因為ChatGLM、ChatGPT和Claude.ai等的tokens限制長度不一樣，會影響你分塊的尺寸；
      • 取決於問答的文字的長度和複雜度：最好問答的文字長度和你分塊的尺寸差不多，這樣會對檢索效率更友好；
      • 應用型別：你的RAG的應用是檢索、問答和摘要等，都會對分塊策略有不同的影響。

  • 向量化（embedding）：這是將文字、影像、音訊和影片等轉化為向量矩陣的過程，也就是變成計算機可以理解的格式，embedding模型的好壞會直接影響到後面檢索的質量，特別是相關度。關於embedding大家可以看我之前的一篇文章《大模型應用中大部分人真正需要去關心的核心——Embedding》，一般我們現在可以選擇的embedding模型有這些：

    • BGE：這是國人開發的中文embedding模型，在HuggingFace的MTEB（海量文字Embedding基準）上排名前2，實力強勁；
    • M3E：也是國人開發的中文embedding模型，我們之前用的就是這個模型，總體來說也算可以，這個還看大家的使用場景，也許你的場景會比我們更加適用；
    • 通義千問的embedding模型：因為是1500+維的模型，所以我們在國慶節後準備用用看；
    • Text-embedding-ada-002：這是OpenAI的embedding模型，1536維，我感覺上應該是目前最好的模型，但是它在MTEB上排名好像只有第六，但是國內應該也不太能用，所以我們就放棄了；
    • 自己訓練embedding模型：這是最酷的了，我過幾天會專門寫一篇如何訓練embedding模型的文章，沒有關注我的可以先關注，哈。當然，訓練是基於一個既有embedding模型的，一般我們有希望讓它在原來的基礎上提升3%-10%的效能。

二、檢索環節（Retriever）

檢索環節技術含量依然很高，而且對於我們目前來說，還有一兩項工作正在進行中。

檢索最佳化一般分為下面五部分工作：

  • 後設資料過濾：當我們把索引分成許多chunks的時候，檢索效率會成為問題。這時候，如果可以透過後設資料先進行過濾，就會大大提升效率和相關度。比如，我們問“幫我整理一下XX部門今年5月份的所有合同中，包含XX裝置採購的合同有哪些？”。這時候，如果有後設資料，我們就可以去搜尋“XX部門+2023年5月”的相關資料，檢索量一下子就可能變成了全域性的萬分之一；

  • 圖關係檢索：如果可以將很多實體變成node，把它們之間的關係變成relation，就可以利用知識之間的關係做更準確的回答。特別是針對一些多跳問題，利用圖資料索引會讓檢索的相關度變得更高；

  • 檢索技術：前面說的是一些前置的預處理的方法，檢索的主要方式還是這幾種：

    • 相似度檢索：前面我已經寫過那篇文章《大模型應用中大部分人真正需要去關心的核心——Embedding》種有提到六種相似度演算法，包括歐氏距離、曼哈頓距離、餘弦等，後面我還會再專門寫一篇這方面的文章，可以關注我，yeah；
    • 關鍵詞檢索：這是很傳統的檢索方式，但是有時候也很重要。剛才我們說的後設資料過濾是一種，還有一種就是先把chunk做摘要，再透過關鍵詞檢索找到可能相關的chunk，增加檢索效率。據說Claude.ai也是這麼做的；
    • SQL檢索：這就更加傳統了，但是對於一些本地化的企業應用來說，SQL查詢是必不可少的一步，比如我前面提到的銷售資料，就需要先做SQL檢索。
    • 其他：檢索技術還有很多，後面用到再慢慢說吧。

  • 重排序（Rerank）：很多時候我們的檢索結果並不理想，原因是chunks在系統內數量很多，我們檢索的維度不一定是最優的，一次檢索的結果可能就會在相關度上面沒有那麼理想。這時候我們需要有一些策略來對檢索的結果做重排序，比如使用planB重排序，或者把組合相關度、匹配度等因素做一些重新調整，得到更符合我們業務場景的排序。因為在這一步之後，我們就會把結果送給LLM進行最終處理了，所以這一部分的結果很重要。這裡面還會有一個內部的判斷器來評審相關度，觸發重排序。

  • 查詢輪換：這是查詢檢索的一種方式，一般會有幾種方式：

    • 子查詢：可以在不同的場景中使用各種查詢策略，比如可以使用LlamaIndex等框架提供的查詢器，採用樹查詢（從葉子結點，一步步查詢，合併），採用向量查詢，或者最原始的順序查詢chunks等；
    • HyDE：這是一種抄作業的方式，生成相似的，或者更標準的prompt模板。

    三、生成（Gen）

    這一部反而是我比較疏忽的，因為有大量的現成框架可以使用，而且，這一步真正發揮巨大作用的是LLM。

    這裡面我們使用的框架有Langchain和LlamaIndex，而且我們因為有之前的AI產品積累，所以還有一套完整的Java框架可以使用，所以這一塊我沒有太多研究。唯一非常關注的就是Prompt工程，我們團隊內部，這一部分的工作是交給了原來AI產品的知識庫運營團隊來做的，他們原來做的更多是BERT相關的知識庫預訓練，應該說工作內容還是比較匹配的。

refs：

https://cloud.baidu.com/article/3291373

https://luxiangdong.com/2023/09/25/ragone/

相關文章