引言
大型語言模型(LLM)的新進展，包括ChatGPT，為AI應用提供了新的能力，使其能夠構建新的人機互動解決方案、完成複雜任務、總結文件、回答文獻中的問題並生成新內容。然而，LLM在獲取最新知識或企業內部知識庫中的領域特定知識時仍存在侷限性。
解決此問題的兩個選項是：
- 微調LLM(繼續使用特定領域的文獻對LLM進行訓練)，這需要管理或提供微調後的LLM。
- 使用檢索增強生成(RAG)系統，依賴LLM使用現有(可擴充套件的)知識文獻生成答案。
這兩個選項在資料隱私/安全性、可擴充套件性、成本、所需技能等方面各有優缺點。RAG-GPT中採用的是RAG系統。在本文中，我們重點討論RAG選項。
透過結合檢索機制和LLM的生成能力，RAG系統可以生成上下文相關、準確且最新的資訊。RAG系統結合了資訊檢索能力和LLM的生成能力。檢索模組專注於從資料儲存中檢索與使用者查詢相關的資訊，生成模組則使用檢索到的資訊作為上下文來生成答案。RAG系統能夠索引所有的非結構化資訊並供查詢，從而減少了開發時間，無需建立知識圖譜，並且對資料的整理和清洗要求有限。
構建RAG系統時，需要預處理以不同格式的領域知識，將處理後的資訊儲存在適當的資料儲存(如向量資料庫)中，實施或整合合適的查詢與文件匹配策略，對匹配的文件進行排序，並呼叫LLM的API傳遞使用者查詢和上下文文件。儘管關於構建RAG系統的新進展不斷湧現，但它們在特定應用環境中的關聯和表現尚需進一步探索。
RAG系統的核心流程
隨著大語言模型服務（如ChatGPT、文心一言、Kimi和豆包等）的流行，人們開始探索其在問答系統中的應用。儘管其表現令人印象深刻，但存在兩個基本挑戰：
- 幻覺：LLM生成的響應看似正確但實際上不正確。
- 無限制：無法直接控制或更新輸出內容(除非透過提示工程)。
RAG系統是一種資訊檢索方法，旨在克服直接使用LLM的侷限性。
RAG的工作原理是將自然語言查詢轉換為Embedding，然後使用該Embedding在一組文件中進行語義搜尋。檢索到的文件隨後傳遞給大型語言模型，以生成答案。
建立RAG系統所需的Index和Query。Index通常在開發時進行，Query在執行時進行。
Index
在RAG系統中，檢索系統使用Embedding來提供文件的壓縮語義表示。Embedding被表示為一個數字向量。在索引過程中，每個文件被拆分為較小的chunk，然後使用Embedding模型將這些chunk轉換為Embedding。原始chunk和Embedding隨後被索引到資料庫中。我們在設計時需要考慮如何最佳地拆分文件以及chunk的大小。如果chunk太小，某些問題可能無法回答；如果chunk太大，答案中可能會包含生成的噪音。
不同型別的文件需要不同的拆分和處理階段。例如，影片內容需要一個轉錄流程來提取音訊並在編碼前將其轉換為文字。選擇使用哪種Embedding也很重要，因為改變Embedding策略需要重新索引所有chunk。應根據語義檢索正確響應的能力來選擇Embedding。這一過程取決於chunk的大小、預期的問題型別、內容的結構以及應用領域。
Embedding models Of OpenAI
Query
查詢過程在執行時進行。首先，將自然語言表達的問題轉換為一般查詢。為了使查詢通用，使用大型語言模型，這使得可以在新查詢中包括額外的上下文，例如之前的聊天記錄。然後，從新查詢中計算出一個Embedding，用於從向量資料庫中定位相關文件。使用相似度方法(如餘弦相似度)檢索出Top K的相似文件(向量資料庫有諸如倒排索引等技術來加快檢索時間)。K太小可能導致召回率太低，無法檢索到正確答案相關資訊，K太大會導致輸入LLM的Prompt太長，計算代價很高，甚至有可能LLM無法支援對應長度的輸入。
檢索到的文件隨後會重新排序，以最大限度地提高包含答案的chunk位於頂部的可能性。下一階段是合併器，它負責處理這些chunk。這一階段是為了克服大型語言模型的侷限性：
- token限制
- 速率限制
像OpenAI這樣的服務對Prompt中包含的文字量有嚴格限制。這限制了在Prompt中包含的chunk的數量，以提取出答案。這些線上服務還限制在一定時間範圍內使用的token數量，從而限制了系統的延遲。在設計RAG系統時，我們需要考慮這些權衡。
Tier 1 rate limits of OpenAI
LLM底座的選擇還有一個需要特別關注點，推理成本。通常來說GPT-4作為LLM底座是效果最好的，但是其代價很高，因此需要結合實際應用場景折中選擇，比如現在效果還行但是小得多的開源LLM，不合適的模型也可能導致LLM不按照Prompt要求生成答案，因此通常也需要相應的評估實驗來決策。
Chinese Open Ended Generation Evaluation
Price of LLM API
RAG系統的最後階段是從生成的文字中提取答案。上層應用需要從提示中過濾噪音，遵守格式指示(例如，將問題的答案作為選項列表提供)，並生成要返回的查詢輸出。實現RAG系統需要定製多個提示來處理問題和答案。這一過程確保返回與領域相關的問題。使用大型語言模型從文件中回答實時問題，開啟了問答作為新能力的新應用領域。
RAG的優勢
RAG具有三個明顯的優勢，這使其在當前很多AI應用場景中被採用。
- RAG減少了LLM幻覺。幻覺是指LLM產生高度簡潔、連貫、合理且可信的答案。然而，這些回應實際上是不正確的； LLMs與事實的近似可以透過利用LLMs強大的上下文學習能力來彌補。這是透過在推理時注入具有高度上下文參考資料的提示來實現的。
- 源資料和參考資料與互動和對話相關聯。RAG 是一種引入組織、企業或行業特定資料以及定義、術語等的簡單方法。
- 對參考資料進行分塊和索引的過程在很大程度上是一個自動化過程。因此不需要對資料進行人工註釋。
RAG的挑戰
RAG系統在落地過程中，主要有以下潛在的故障點(Failure Points)：
- FP1: 缺失內容。當提出無法使用現有文件解決的問題時，可能會出現失敗。在有利的情況下，RAG系統將簡單地回覆一條訊息，例如“抱歉，我不知道”。然而，如果問題與內容相關但缺乏具體答案，系統可能會被誤導而提供響應。
- FP2: 錯過了最相關的文件。文件包含問題的答案，但排名不夠高，無法呈現給使用者。理論上，所有文件都會被排序並考慮進行進一步處理。然而，在實踐中，僅返回前 K 個文件，其中 K 的值是根據效能指標選擇的。
- FP3: 不在上下文中。包含答案的文件已成功從資料庫中檢索，但未包含在用於生成響應的上下文中。當從資料庫中檢索多個文件並採用合併過程來提取答案時，就會出現這種情況。
- FP4: 未提取。在這種情況下，答案就在所提供的上下文中，但大型語言模型無法準確提取它。當上下文中存在過多噪音或衝突資訊時，通常會發生這種情況。
- FP5: 格式錯誤。該問題需要以特定格式(例如表格或列表)提取資訊，但大型語言模型忽略了該指令。
- FP6: 特定性錯誤。響應包含答案，但缺乏所需的具體性或過於具體，無法滿足使用者的需求。
- FP7: 不完整。不完整的答案不一定是錯誤的，而是缺少一些資訊，即使它存在於上下文中並且可以被提取。
經驗教訓和未來最佳化方向
Chunking and Embedding
Chunking聽起來很簡單。然而，chunk的質量在許多方面影響了檢索過程，特別是影響了chunk的Embedding，從而影響了chunk與使用者查詢的相似性和匹配。有兩種Chunking方式：
- 基於啟發式的方法(使用標點符號、段落結尾等)。
- 語義分塊(使用文字中的語義來確定塊的開始和結束)。
進一步的研究應該探討這些方法之間的權衡及其對Embedding和相似性匹配等關鍵下游過程的影響。透過比較Chunking技術在查詢相關性和檢索準確性等指標上的系統評估框架將對該領域有所幫助。
Embedding表示另一個活躍的研究領域，包括為多媒體和多模態塊(如表格、圖形、公式等)生成Embedding。chunk的Embedding通常在系統開發期間或索引新文件時建立一次。查詢預處理顯著影響RAG系統的效能，特別是在處理否定或模糊查詢時。需要進一步研究架構模式和方法，以解決Embedding固有的侷限性(匹配質量是特定領域的)。
RAG vs 微調
LLM由於其訓練資料量大以及釋出前應用的微調任務，因此成為了很好的通用模型。然而，這些通用模型可能不瞭解你領域的具體細節，而且不是最新的(其知識有截止日期)。微調和RAG提供了兩種潛在的定製路徑，各自具有不同的權衡。微調需要策劃內部資料集以適應和訓練LLM。然而，所有資料都會被Embedding到模型中，你需要解決安全/隱私問題(誰可以訪問什麼)。此外，隨著基礎模型本身的演變或你需要新增新資料到模型中，你將需要重新進行微調。另一方面，RAG系統似乎提供了一種務實的解決方案，允許你根據需要對資料進行分塊，並且只使用相關的塊在上下文中向LLM生成答案。這有助於透過新文件持續更新知識，並且還可以控制使用者能夠訪問哪些塊。然而，chunk的Embedding、檢索和上下文融合的最佳化策略仍然是活躍的研究領域。進一步的工作應系統地比較微調和RAG正規化在準確性、延遲、運營成本和魯棒性等因素上的表現。
RAG系統的測試和監控
對於RAG系統的工程最佳實踐仍在不斷髮展。測試和測試用例生成是需要改進的領域之一。RAG系統需要與應用程式相關的問題和答案，這些通常在索引非結構化文件時是不可用的。新興的研究已經考慮使用LLM從多個文件生成問題。如何生成現實的、與領域相關的問題和答案仍然是一個開放的問題。
結論
本文介紹了在構建RAG系統時的挑戰和解決方案，特別是透過整合LLM實現智慧客服。RAG系統透過結合檢索機制和LLM的生成能力，能夠有效處理非結構化資訊，減少開發時間和資料清洗需求。然而，在實現過程中存在一些故障點，如缺失內容、格式錯誤和不完整答案等。
本文探討了RAG系統的核心流程、優勢以及面臨的挑戰。RAG系統具有減少LLM幻覺、關聯源資料和參考資料、以及自動化處理非結構化資料的優點。但在實際應用中，還需要解決Chunking和Embedding策略、RAG與微調的選擇、以及系統的測試和監控等問題。希望這些經驗和建議能為從事RAG系統開發的工程師提供有價值的參考。
|
FP |
最佳化方向 |
具體描述 |
|
FP4 |
更多的上下文資訊 |
大模型的視窗從4K增加到8K或者更大，LLM可以使用更多的上下文資訊 |
|
FP1 |
語義快取降低了成本和延遲 |
由於速率限制和LLM的成本，RAG系統在應對併發使用者方面存在困難。使用常見問題的預檢索能力，可以緩解內容缺失現象。 |
|
FP5~FP7 |
RAG“越獄” |
LLM大模型微調，增加模型的基礎能力 |
|
FP2, FP4 |
增加元資訊 |
將檔名和chunk編號新增到檢索到的上下文中有助於讀者提取所需資訊。這對對話很有用。 |
|
FP2 FP4~7 |
開源LLM模型在處理小型文字方面表現更優。 |
在處理小型文字方面，開源LLM模型的表現與閉源替代品相當。 |
|
FP2~7 |
RAG系統需要持續校準。 |
RAG系統在執行時接收未知輸入，需要不斷監控。 |
|
FP1 FP2 |
實現一個RAG配置流水線 |
一個RAG系統需要校準chunk大小、Embedding策略、Chunking策略、檢索策略、整合策略、上下文大小和提示。 |
|
FP2,FP4 |
透過組裝定製解決方案建立的RAG Pipeline是次優的。 |
端到端訓練模型，增強RAG的領域實用性 |
|
FP2~FP4 |
只有在執行時才能測試效能特徵。 |
離線評估技術，如G-Evals看起來很有前景，但前提是能夠獲得標記過的問題和答案對。 |
關於我們
OpenIM是領先的開源即時通訊（IM）平臺，目前在GitHub上的星標已超過13k。隨著資料和隱私安全的重視以及資訊科技的快速發展，政府和企業對於私有部署的IM需求急劇增長。OpenIM憑藉“安全可控”的特點，在協同辦公軟體市場中佔據了一席之地。在後AIGC時代，IM作為人機互動的首要介面，其價值愈發重要，OpenIM期待在此時代扮演更關鍵的角色。
基於這樣的視角，我們最近開源了RAG-GPT專案，已被部分企業採用並持續完善中。
RAG-GPT關鍵特性：
- 內建LLM支援：支援雲端LLM和本地LLM。
- 快速設定：只需五分鐘即可部署生產級對話服務機器人。
- 多樣化知識庫整合：支援多種型別的知識庫，包括網站、獨立URL和本地檔案。
- 靈活配置：提供使用者友好的後臺，配備可定製的設定以簡化管理。
- 美觀的使用者介面：具有可定製且視覺上吸引人的使用者介面。
如果您對RAG-GPT感興趣，可以訪問以下連結瞭解更多資訊：
專案地址：
https://github.com/open-kf/rag-gpt
線上Demo： https://demo.rentsoft.cn/
我們的目標是改進檔案管理功能，更有效地管理資料，並整合企業級知識庫。歡迎大家在GitHub上Star並關注，支援我們的開源旅程。
開源說明：RAG-GPT採用Apache 2.0許可，支援免費使用和二次開發。遇到問題時，請在GitHub提Issue或加入我們的OpenKF開源社群群討論。如果您需要更智慧的客服系統，請與我們聯絡。