創業：大模型RAG系統三個月的開發心得和思考

1. 前言

自從和員外上家公司離職後，我們就自己搞公司投入到了RAG大模型的AI產品應用的開發中，這中間有一個春節，前後的總時間大概是三個月左右，在這三個月期間，基本是晝夜兼程啊，到今天3月底結束，產品目前看是有了一個基礎的雛形。

在這期間，員外負責整個產品的營銷、商業客戶的洽談等方面的內容，我和阿包負責整體的技術架構搭建，程式碼從0-1的編寫，我們是在24年1月26，產品初步上線了一個版本，開始接受企業客戶的試用，這讓我們接受到了大量的需求，以及我們產品在目前的市場環境中還存在哪些競爭力不足需要改進的地方。

三個月時間過去了，在我們的TorchV AI 產品初步成型之際，和大家分享一下開發RAG、LLM系統以來的一些心得和經驗。

2. RAG簡介

RAG(檢索增強生成)名詞一開始來源於2020年的一片論文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》，旨在為大語言模型（LLM）提供額外的、來自外部知識源的資訊。這樣，LLM 在生成更精確、更貼合上下文的答案的同時，也能有效減少產生誤導性資訊的可能。

可以說在目前大模型井噴的今天，RAG作為一項為密集型知識NLP任務的處理指明瞭方向，配合AI大模型，讓世界發生了翻天覆地的變化，數以萬計的開發者都湧入這個賽道，同時競爭。

我們知道LLM目前存在的一些問題和挑戰：

我自己理解LLM大模型本質就是一個二進位制檔案，所有的知識都透過壓縮技術全部壓縮在一個/多個GB的二進位制檔案中，最終在獲取資料的時候，透過LLM的模型架構，推理能力，將所有的知識資訊又生成出來。

• 在沒有答案的情況下提供虛假資訊(胡說八道、幻覺)。
• 模型知識的更新成本、週期、及大模型的通用能力問題（大公司才玩的轉）
• 資料安全和隱私等問題

而RAG技術的出現，正好能有效的緩解目前大模型存在的一些問題，主要表現方面如下：

• 經濟高效的處理知識&開箱即用：只需要藉助資訊檢索&向量技術，將使用者的問題和知識庫進行相關性搜尋結合，就能高效的提供大模型不知道的知識，同時具有權威性
• 有效避免幻覺問題：雖然無法100%解決大模型的幻覺問題，但透過RAG技術能夠有效的降低幻覺，在軟體系統中結合大模型提供冪等的API介面就可以發揮大模型的重大作用
• 資料安全：企業的資料可以得到有效的保護,透過私有化部署基於RAG系統開發的AI產品，能夠在體驗AI帶來的便利性的同時，又能避免企業隱私資料的洩漏。

3. RAG技術&架構思考

既然我們知道，RAG作為密集型知識庫的處理和大模型配合起來有著天然優勢，那麼如何做好RAG的開發？

RAG應用的基礎技術核心是：讓大模型依靠現有的資料(PDF/WORD/Excel/HTML等等)精準的回答使用者的問題

這是最基礎的功能，同時也是最低要求，任何做RAG領域的AI應用產品，技術層面都需要去突破解決的技術難題。

注意兩個核心點：

• 📁 依賴現有的知識庫：依賴客戶本身的資料是為了給大模型提供強有力的資料支撐,避免大模型胡說八道,企業私有的資料大模型並沒有將資料納入模型進行訓練,所以大模型對於企業私有的資料及相關問題,大模型不可能知道，即使大模型能回答你這個領域的問題，那也是因為你這個問題在大模型訓練的資料集中早就存在了，而且是公開的資料集和問題，而企業私有的資料(財務報告、隱私資料等)大模型是不可能擁有的
• 🏹 精準命中回答：一旦客戶將自己的私有資料上傳了之後,我們要做的就是依靠此資料精準回答使用者的問題，而要做到精準回答命中,技術人員需要做多方面的努力💪。

技術人對於RAG應用考慮的最核心的就是這兩點，而技術測為了要實現這一個目標，其覆蓋的知識面以及技術難度都是非常大的。

我很早之前參考大模型的技術架構發展，為RAG畫了一張類似的圖，如下：

這裡面我為做RAG系統的總結為三顆樹，LLM大模型是土壤，主要為：資料工程、檢索生成、業務系統

這裡面並沒有把對模型的微調放入進來，當我們把基礎工程做到80分後，也許對Embedding模型、Chat模型等微調工作會加入進來，針對特定的業務場景做最佳化。

• 資料工程: 知識庫的形式豐富多彩,這其中配合RAG我們要做的事情非常多，包括檔案型別、格式、分割策略、知識型別、索引方式等等
• 檢索生成:當我們處理完成資料後，配合大模型需要進行檢索生成，而在這個過程中，包括：Prompt工程、演算法策略、檢索方式、中介軟體、大模型、查詢處理等內容
• 業務系統: 這是配合商業行為所衍生的業務系統&上層產品應用，包括租戶、計費、開放平臺、洞察、運營等業務系統，這些業務系統在TorchV AI的產品體系都一一體現

透過上面的圖，我們大概就能知道，RAG+LLM大模型系統的產品開發，是一個綜合性非常強的工作內容，這就和大模型的訓練一樣，整個工程龐大繁雜，是一個系統性工程。

如果我們把三顆樹中的每一項都作為一個技術因子，不同的步驟處理最佳化，都會影響著最終外部的商業的影響力，這就會產生量變到質變的轉變。

假設：我們把資料工程和檢索工程所有的步驟在技術層面提升了10%，那麼我們在和同類競品去競爭時，我們的優勢是多大呢？

3.1 資料工程

在大模型圈子裡，經典名言：Garbage in and garbage out，意思顯而易見，你給大模型送的資料質量越高，那麼大模型的響應回答效果就越好，反之，如果你丟垃圾給大模型，那麼大模型也會給你返回垃圾～

所以從這點來看，上層的應用開發者，要做好知識庫型別的產品，資料工程絕對是第一道攔路虎，從資料集的不同領域進行分類,目前存在非常多的資料格式

這裡麵包含的多種不同的挑戰

• 常見檔案解析：基於檔案型別的資料集是最常見的,也是使用最廣的,例如(PDF/WORD/Excel/CSV/Html/Markdown)等格式
• 關係型/NoSQL資料庫: 使用者的資料全部儲存在資料庫中介軟體中，例如MySQL/Postgres等，NoSQL資料庫中，這種資料來源的提取到是不難，開發者只需要根據不同的資料庫標準協議進行對接抽取即可，要做的是適配不同的資料庫型別
• 網路資料集：對於網路資料集的處理，那麼就需要開發者精通爬蟲之道,而網路上的資料集種類也是非常廣的，普通的W3C網頁(格式種類複雜繁多)，影片、音訊等等資訊
• 不同型別的資料提取：包括文字、圖片、表格、影片等，單單一個表格資料的在不同的檔案格式的處理，就需要花費大量的精力去最佳化
• 提取方式的類別：傳統的軟體工程、OCR、大模型等等
• 分割策略：分割策略在RAG的技術體系中有著舉足輕重的地位,分割的不好，會在資訊檢索(IR)的過程中丟失語義，包括：語義分割、大模型分割、按固定Token分割、文件結構分割等等
• Embedding索引構建：除了給每一個chunk塊構建向量索引，後設資料、標題、概要總結等等也會對系統準不準有不同的要求，同時還要和上層的業務進行結合。
• More...

在資料工程這棵樹上，所有的技術發展都不是停滯不前的，這裡僅僅只是列了一些基礎的樹枝，我相信在大模型AI井噴爆發的今天，會更快推進資料工程(ETL)的發展。

3.2 檢索生成

當我們把所有的知識資料處理完畢，藉助大模型來構建一個Chat系統時，資訊檢索技術則是必然要用到的

從這裡我們好像發現，做RAG，無非就是做搜尋?

在目前的RAG檢索的技術體系中，最普遍的無非兩種：關鍵詞和向量語義檢索

• 關鍵詞檢索：基於類似BM25這類詞頻倒排技術，透過統計關鍵詞的方式來執行搜尋，缺點是無語義資訊
• 向量語義檢索：透過將所有知識片段透過BERT等預訓練語言模型進行表徵提取，表示為多維的向量資料，透過KNN/ANN演算法搜尋獲取結果。

當然，在目前的很多向量資料庫中介軟體中，這兩類檢索引擎都得到了支援，或者是混合檢索也是一種重要的技術手段。

在整個檢索生成的過程中，這棵樹同樣關注的技術細節也非常的多，如下：

• Prompt工程：和大模型對話，技術人員必須掌握的Prompt工程，透過FewShot、CoT、ZeroShot等技術，針對不同的業務場景能發揮重大的作用，開發人員需要根據具體的業務場景來除錯，同時也是和大模型對接，解決冪等性的重要手段
• LLM大模型：glm3/4、百川、千問、月之暗面、gpt3.5、gpt4等等大模型，在不同的場景、能力各有側重，進行深度的業務除錯/適配同樣重要。
• 檢索召回過程處理：多輪對話、查詢重寫、多跳、多路召回、子查詢等等，伴隨業務場景的深入，每一個Chain的環節保證穩定可靠，不是輕鬆的事
• 中介軟體：系統穩定高可用、可擴充套件離不開中介軟體的支援，如快取、訊息佇列、向量資料庫、圖資料庫等等都是必不可少的
• More:....

在檢索生成的這棵樹上，和資料工程密切配合不可分割，都是在降低大模型幻覺的道路上深挖技術細節。

4. 技術&產品領導驅動商業的發展

做RAG這類AI應用開發以來，感受最深的是和之前做產品/專案並不相同，一方面是技術棧發展較新，新技術帶來的技術變革存在非常大的挑戰，有了大模型之後，需求&想法也是五花八門，另外，目前的AI應用，我覺得更多的是技術&產品來領導驅動商業的發展，這和普通軟體企業的開發流程或許有所不同。

這裡我覺得幾點非常重要：

• 新AI技術的迅速發展必然革新之前的軟體流程和開發過程，在思想層面是必須轉變的。
• 大模型幻覺很嚴重，透過RAG技術解決幻覺做60分很容易，但是把底層的能力提升到80分甚至90分，是非常難的事情，這需要一個長期累積迭代的過程。
• 企業客戶不會為了一個只有60-70分的技術產品買單付費，對待軟體編碼、技術架構實現，開發人員在思想上也是需要轉變的。

我們團隊內部經過這段時間的迭代，也碰了很多客戶的需求，團隊的方向也是在發展中不斷的進行調整。

我們在成立TorchV AI時，整體架構如下：

我們以RAG技術為核心，在上層做我們的中介軟體層，這裡面最核心的三個：

主要核心問題聚焦在降低大模型幻覺、不同資料來源連線上面

• TorchV IC(冪等分類器):讓既定的事實資料發揮更大比重，引入儘可能多的冪等，對抗和降低LLM的幻覺;
• TorchV Actuator(執行器):最佳化TorchV特有風格的輸出格式，包括互動介面的組裝，對應用更友好;
• TorchV Connector(聯結器):連線本地資料，有序解決本地化場景下資料多樣性和複雜性問題.

透過RAG技術+中介軟體的方式，開發出了我們的第一個產品基線TorchV Bot。透過持續的產品迭代和不同客戶需求碰撞，我們的TorchV Bot基線產品的架構也初步成型。如下圖：

主要元件拆分如下：

• RAG和Agent：RAG（檢索增強生成）和Agent是目前大語言模型落地到企業應用的事實標準，也是TorchV AI的核心中介軟體之一；
• Tenant：租戶系統，這是我們支起多租戶PaaS/SaaS平臺的基礎；
• OSS：線上檔案儲存，包括客戶上傳的檔案，以及從URL中匯入的資料等；
• ChatBot：TorchV AI會提供一個預設的Web版問答系統，客戶可以在上面對知識進行測試，對於內部使用場景，也可以直接使用；
• 資料&洞察分析：對資料進行分析，包括客戶預先設定的一些洞察條件，一旦觸發條件，就會進行指定動作，如產品和服務的推薦，諮詢分流等。客戶在這裡也可以對資料進行同步，匯入到自己的系統，作為資料分析的資料基礎；
• 知識庫管理：建立知識庫，為每個知識庫上傳和匯入檔案，一旦上傳，檔案立即被系統處理，變成chunk（小塊文字）和embedding之後的向量資料等；
• 運營後臺：包括計費系統、各類引數配置、對話記錄檢視和標註、使用者許可權設定和反饋處理等功能；
• 應用中心：一個客戶即可建立多個應用，然後透過API對接自己的原有系統，或者根據API建立新應用。除了API之外，我們還提供一鍵嵌入的對接方式，只需引入幾行js程式碼，即可在客戶的Web應用上開啟懸浮icon，提供TorchV AI的對話能力。

以上則是目前TorchV的產品雛形，更多細節可以訪問官網:https://www.torchv.com

5. 架構&程式語言的選擇

隨著大模型LLM的爆火，很多開發者在選擇開發RAG系統應用時，會可能無法著手。

起初在開發RAG應用的時候，我也糾結過程式語言的選擇，在這期間走了很多的彎路，也得到了一些教訓。

TorchV.AI的產品目前選擇是Java+Python作為服務端的開發語言。

這裡面有以下幾個原因：

• 員外和我都是多年的Java語言開發出生，從編碼、生態等方面的瞭解程度，那自然是不可能拋棄Java
• Python語言是無可避免的，但是在整個工程裡面，職責是有分工的，無狀態的一些邏輯操作都透過Python來實現
• 企業級開發語言以及技術元件生態
• 中介軟體豐富程度、開發社群的健康發展

下圖是我畫的一個Java VS Python這兩個程式語言在不同領域的一些特性對比。

目前市面上開發RAG大模型應用最火的當屬LangChain、LlamaIndex這兩個框架，都是Python語言進行開發，提供了開箱即用的功能，可能在不超過10行程式碼的情況下，就能輕鬆完成一個RAG大模型應用的demo。

我們起初也是在糾結在這期間如何更好的做取捨，後來團隊內部經過討論，還是將部分的業務邏輯放在Java語言中，重寫RAG過程中的一些核心邏輯和元件。

這裡面的思考：

• RAG架構涉及到的東西多且雜，開箱即用的LLM資料處理框架可能無法滿足企業的業務訴求(需求變化多端)
• RAG目前並沒有發展成為HTTP規範一樣的協議約定，所以不同的RAG過程、LLM模型等都會導致RAG的效果差異
• 國內LLM百花齊放，無法開箱即用，國內的不同需求也需要滿足(本地化適配)

結合在開發RAG應用中涉及到的資料工程等部分邏輯，我們結合兩大語言的特性，也能很輕鬆的勾畫出一張便語言級別的架構圖，涵蓋了在企業開發、業務場景落地時，如何快速的適配上層應用的需求。如下圖所示：

在這張圖中，我們可以清晰的看到，不同的任務&需求，職責分工是比較明確的。

• Java：使用Java生態時，針對業務系統的資料一致性，分散式、鑑權、限流等企業應用介面的特性開發，目前都有非常成熟的解決方案
• Python：涉及到無狀態的服務時，支撐上層應用的處理，包括資料工程、Chat模型、資料處理、微調等系統工程，那麼用Python是毫無疑問的

在這裡，當我們使用應用開發時，挑選程式語言來開發應用服務，優先考慮的是生態和穩定性。

當然，這裡面並沒有唯一的標準，根據自己的實際情況出發來選擇是最優的，以上僅僅只是分享一下我的看法。

6. 總結

好了，全文完，做一個總結：

• RAG、LLM等AI產品的開發是日新月異的，技術棧體系會飛速發展,對於公司而言，小步快跑，快速試錯可能是非常重要的
• 應用場景目前僅僅只是聚焦在知識密集型任務，未來隨著技術的發展，會擴充套件到更多的行業中。

TorchV.AI目前是剛起步階段，也歡迎更多的企業客戶試用，合作！！！

如果您有商務合作需求：

請掃碼新增以下微信（員外🔥TorchV），並請您告知您的稱呼 和 企業名稱 。

我們的官網地址：https://www.torchv.com

如果你也在關注大模型、RAG檢索增強生成技術，歡迎關注我（公眾號‬：八一菜刀‬）

7. References

• https://www.torchv.com
• https://www.luxiangdong.com
• https://arxiv.org/abs/2005.11401