4 月 1 日，InfiniFlow （英飛流）的端到端RAG解決方案 RAGFlow 正式開源，首日即獲得了 github 千星，目前已接近 3000 star。在這之前，InfiniFlow 還開源了專門用于 RAG 場景的 AI 原生數據庫 Infinity，一個是 AI Infra基礎組件，一個是端到端應用，在回答 InfiniFlow 為什么要連續開源這樣兩款產品之前， 先來總結一下這兩款產品應用的主要場景 RAG （基于檢索增強的內容生成）、現狀以及未來。

RAG 技術從提出到成為共識，經歷了不短也不長的時間。它最早浮出水面，是在 2023 年 3 月的英偉達 GTC 大會上，老黃當眾點名了向量數據庫，緊接著 OpenAI 自身也發布了信息檢索插件解鎖了讓大模型訪問私有數據的能力，由此，讓向量數據庫作為大模型的外掛記憶體存在，提供外掛知識庫的產品功能，成為 RAG 最早為大眾所知的使用姿勢，就是下邊這張圖展現的應用架構：

在很長一段時間內，RAG 在行業的代名詞都叫知識庫，上述的應用架構，不僅帶火了向量數據庫，也帶火了以LangChain，LlamaIndex 為代表的中間件，它們負責處理上圖中各個箭頭背后的工作流。具體包括：

1、把用戶的文檔進行切分，然后再調用一個 Embedding 模型把切分好的文檔生成為向量。

2、把生成好的向量連同原始文檔寫入到向量數據庫中。

3、查詢時，將用戶的提問也根據相同的 Embedding 模型生成向量，然后查詢向量數據庫返回 Top K 結果。

4、把 Top K 結果對應的文本拼成提示詞交由大模型做最終的摘要和內容完成。

因此，整個架構圖里核心部分是兩個：

1、向量數據庫：負責基于向量對用戶的文檔進行查詢召回。

2、中間件：負責對文檔的切分，并轉成適合的向量。

采用向量這種形式是因為向量可以提供語義召回，用戶只要提問，最終能按照相似度高低返回最接近的答案而無需考慮問題是否真的有哪些關鍵詞匹配到了文檔。即使沒有匹配，也依然可以根據語義相似度返回答案。之所以需要對用戶文檔進行切分，是因為向量表征的語義比較含糊，不僅一篇文章可以表征為一個向量，一個單詞也可以表征為一個向量，這就導致文字塊跟向量對應的粒度很難控制：粒度過粗，用一條向量對應一大段話，對這些文字的細節很難表征；粒度過細，那么一大段文字會對應一堆向量，而每個向量又僅僅代表幾個詞的語義，因此無法簡單根據相似度來找到符合語義的向量。因此，需要對文檔進行“恰當”的切分，這就是 LangChain，LlamaIndex 等中間件的核心工作。

那么，如何定義“恰當”呢？通常會采取一些簡單的策略：例如先根據文字間的空白將文檔切分成不同的段落，這些段落表征的粒度相對比較適合。隨后通常會把一些標題（通常需要根據一些規則來判斷）跟這些段落合并，讓這些只包含局部文字的段落也能體現整篇文章或者部分章節的語義。

因此，有了這類組件就可以快速搭建一套 RAG 系統。不過，自從這種應用架構從 23 年 4 月開始流行，就一直面臨一個爭論：“把用戶的數據微調進大模型直接回答問題更好，而無需 RAG 這一整套基于檢索的架構”。這類爭論伴隨了整個 2023 年。直到今天，這類爭論的聲音才漸漸淡去。因為，很顯然，無論是實時性還是成本等方面， 采用 RAG 是碾壓對 LLM 進行微調的方案的。支持微調的擁護者所最看重的問答質量，但更多評測發現，兩者差距并不大，而逐漸得出了兩者需要搭配使用的結論。并且，這種所謂搭配使用的方案，隨著開源 LLM 不斷快速迭代推陳出新，也導致實際真正采用微調的已寥寥無幾。

上述這種 RAG 架構，也被一些 LLM 廠商所采納，典型代表是 2023 年 11 月初 OpenAI 推出的 GPT4 Turbo，根據一些出錯的日志截圖，可以看出 OpenAI 正是可能采用了以向量數據庫 qdrant 為基礎搭建的 RAG 架構，從而提供了讓用戶自行上傳文檔并進行問答的個人知識庫服務。

今年 2 月以來， AI 領域連續出了很多重磅熱點，除了最火熱的 Sora 之外，另一個熱點就是長上下文 LLM ，例如 Claude 3、 Gemini 1.5，當然也包含國產的月之暗面。Sora 的本質是針對視頻提供更加可控的生成能力，這其實是解鎖未來多模態 RAG 熱潮的一個必要條件；而長上下文 LLM ，卻引發了更多針對 RAG 的爭論，因為這些 LLM 可以支持用戶隨時上傳 PDF，甚至上傳幾十個 PDF，然后針對這些 PDF 提供問答，同時還具備強大的“大海撈針”能力。所謂“大海撈針”測試，就是針對長上下文窗口內的細節進行提問，看 LLM 是否可以準確地回答。

用 RAG 來實現大海撈針是輕而易舉的，然而上邊列舉的這些 LLM，它們不是基于 RAG 來提供這種能力，卻也都可以達到很高的召回。長上下文技術在2023年底就已經有很多了，代表工作是 StreamLLM，其本質是滑動窗口，只保留對最近上下文的注意力，窗口滑過，內容即會被逐漸“遺忘”，因此“大海撈針”測試表現不佳。而今年的這些新出現的長上下文 LLM，卻徹底解決了這個問題，其中的若干產品，效果確實非常好，上傳一個 PDF，甚至可以針對里邊的復雜圖表給出精確的回答。因此，這引發了新的一輪關于長上下文 LLM 和 RAG 的爭論，許多人評價 “RAG 已死”，而 RAG 擁護者則認為，長上下文 LLM 并不能滿足用戶海量數據的需求，成本高，速度也不夠快，也只能針對長文本、圖片等數據提問。

隨著長上下文 LLM 為更多用戶接納，近期各家國產 LLM 都快速推出了這個產品特性，除月之暗面外，其他家大多基于 RAG 來實現，下表是兩者的基本對比：

這里要額外說明一下為何 RAG 派的大海撈針能力一般，這并不是 RAG 本身的問題，而是依靠純向量數據庫去構建 RAG，并不能保證對精確數據和細節的準確召回。以上的對比，其實并沒有完全解答 RAG 的必要性，因為至少就目前 RAG 最普遍的場景——個人知識庫問答而言，確實很多情況下只需要 LLM 就足夠了。至于成本性能等因素，這些問題是會隨著時間推演，逐漸得到緩解的。

因此，RAG 的未來，似乎并不是那么樂觀。而 InfiniFlow 則認為，LLM 的長上下文能力，對于 RAG 來說是很大的促進。這里先用 OpenAI 聯創Andrej Karpathy的一張圖做個類比，他把 LLM 比喻為一臺計算機的 CPU， 把上下文類比為計算機的內存，那么以向量為代表的數據庫，就可以看作是這臺計算機的硬盤。

下邊進一步來說明，為什么即使有了“大海撈針”能力，RAG 仍然必不可少。RAG 從提出到為業界廣泛接納，經歷了一年多時間，當下的 RAG 產品已經并不稀缺，然而在實際應用中，卻普遍得出了“ RAG 屬于上手容易，但真正落地卻很難”的結論。究其原因，這里邊主要包含兩個方面：

其一是來自 LLM 自身。由于 RAG 的工作流程是針對從數據庫返回的結果進行回答，這樣的話，對于 RAG 來說，LLM 最基礎也是最重要的能力其實包含：

1、摘要能力；

2、可控性：即 LLM 是否聽話，是否會不按照提示要求的內容自由發揮產生幻覺；

3、翻譯能力：這對于跨語言 RAG 是必備的。

遺憾的是，在過去，國內可以用到的 LLM 中，在這三點上表現良好的并不多。至于所謂高級的能力，例如邏輯推理，以及各類 Agent 要求的自主決策能力等，都建構在以上基礎能力之上。基礎不好，這些也都是空中樓閣。

其二，則是來自于 RAG 系統本身。在前文中已經可以看到：RAG 系統是一條完整的鏈路，包括數據準備，數據寫入，乃至從數據庫查詢和返回結果排序。在整條鏈路中，最大的難點來自于兩個方面：一是如何應對復雜多變的數據，這些數據包含各種格式，更復雜的還包含各類圖表等，如果在沒有理解這些語義的基礎之上直接提供 RAG 方案，例如簡單的根據文字空白就來切分段落，就會導致語義丟失從而讓最終查詢的結果也是混亂不堪。二是如何查詢和排序。當下的主流 RAG 都是采用向量數據庫作為支撐，然而在 InfiniFlow 多次實際的應用中已經看到了單純依靠向量數據庫很難滿足 RAG 要求。原因就在于，當下的 RAG 大都是服務面向個人的知識庫這樣的簡單場景的，這些場景的用戶數據，基本都是文檔，那么個人用戶對于文檔的提問，大體上都是圍繞著摘要來做的，有個看上去差不多的答案就可以了。然而在面向企業端的時候，簡單依賴向量的 RAG 就顯得力不從心，這是由向量的本質決定的：向量只能表征語義而無法對精確信息召回，更甚者，只有向量是無法跟企業內部的信息系統集成的。舉幾個典型場景：把符合要求的簡歷篩出，篩選條件包含工作技能（需要向量 + 全文搜索），某類行業的工作經驗（基于向量的分組聚合），期望收入，學歷，地域（結構化數據）等；基于對話推薦符合個人要求的產品，可以采用多列向量來描述個人偏好，不同的列代表了用戶對不同類目產品的過往使用偏好。在推薦過程中，除了采用基于用戶的偏好向量進行搜索之外，還需要結合產品的過濾條件：包括是否過期，是否有優惠券，是否符合權限要求，是否有合規要求，該用戶是否近期已經購買或者閱讀過，等等。簡單地講，在大多數情況下，都必須引入多路召回和重排序，才能保證數據查詢的準確度。

假如不去專注于解決這兩類問題，那么就很容易陷入讓 RAG 去和長上下文 LLM 反復對比的情況：RAG 僅僅提供數據的簡單解析，然后直接轉化為向量，最后用單一向量做召回，這除了成本，以及私有化場景里所要求的安全等優勢之外，在核心對話能力上并沒有顯著地跟長上下文 LLM 區分開來，甚至還有所不及。

正是基于這些 RAG 本身的痛點，InfiniFlow 先后推出了兩個開源項目，旨在解鎖 RAG 面向各類場景的服務能力，在當下長上下文 LLM 能力越來越強的前提下，如果把 RAG 自身的痛點也解決掉，那么就可以讓更多企業都真正把 LLM 用起來，而不是總是停留在淺層的知識庫對話。

第一個是 AI 原生數據庫 Infinity。它解決的是如何解鎖 RAG 面臨 B 端場景的復雜查詢：如何跟企業已有的數據——包括但不限于非結構化的文檔、圖片，還包括結構化的信息系統來結合，并解決多路召回和最終融合排序的問題。

如下圖所示的基于 RAG 的推薦系統，企業內部已有數據包含用戶表，日志表，產品描述表等等，這些數據都可以進入 Infinity，但并不是 1:1 同步，而是增加了若干向量列。這些企業數據，如果僅用向量數據庫來建模，是無法表征的：向量數據庫只包含一些用于過濾的“標量”字段，而這個系統需要的查詢，是多向量，多表 + 全文搜索的復雜查詢，采用向量數據庫，那么產品的開發是極其復雜的：因為這需要引入額外的 ETL，從而產生一些“標量”過濾字段，這帶來了維護性，以及更嚴重的數據一致性的問題。RAG 面臨的是最終用戶的使用場景，它是需要業務乃至 LLM 發起請求，就立刻得到答案的，因此不能像數據中臺一樣僅僅為了一張報表就可以搭建一整套數據管道體系去做寬表這種額外邏輯。因此，Infinity 實際上等于向量數據庫 + 搜索引擎 + 普通結構化數據查詢，并保證三者的高并發和融合排序。

第二個就是端到端的 RAG 引擎 RAGFlow。它解決數據的問題：因為如果不對用戶數據加以區分和清洗，識別其中的語義，就容易導致 Garbage In Garbage Out。RAGFlow 包含了如下的完整 RAG 流程，確保數據從 Garbage In Garbage Out 變為 Quality In Quality Out。

具體來說， RAGFlow 的最大特色，就是多樣化的文檔智能處理，因此它沒有采用現成的 RAG 中間件，而是完全重新研發了一套智能文檔理解系統，并以此為依托構建 RAG 任務編排體系。這個系統的特點包含：

1、它是一套基于 AI 模型的智能文檔處理系統：對于用戶上傳的文檔，它需要自動識別文檔的布局，包括標題、段落、換行等，還包含難度很大的圖片和表格。對于表格來說，不僅僅要識別出文檔中存在表格，還會針對表格的布局做進一步識別，包括內部每一個單元格，多行文字是否需要合并成一個單元格等。并且表格的內容還會結合表頭信息處理，確保以合適的形式送到數據庫，從而完成 RAG 針對這些細節數字的“大海撈針”。

2、它是一套包含各種不同模板的智能文檔處理系統：不同行業不同崗位所用到的文檔不同，行文格式不同，對文檔查閱的需求也不同。比如：

a. 會計一般最常接觸到的憑證、發票、Excel 報表；查詢的一般都是數字，如：看一下上月十五號發生哪些憑證，總額多少？上季度資產負債表里面凈資產總額多少？合同臺賬中下個月有哪些應付應收？

b. 作為一個 HR 平時接觸最龐雜的便是候選人簡歷，且查詢最多的是列表查詢，如：人才庫中 985/211 的三到五年的算法工程師有哪些？985 碩士以上學歷的人員有哪些？趙玉田的微信號多少？香秀哪個學校的來著？

c. 作為科研工作者接觸到最多的可能是就是論文了，快速閱讀和理解論文，梳理論文和引文之間的關系成了他們的痛點。

這樣看來憑證/報表、簡歷、論文的文檔結構是不一樣的，查詢需求也是不一樣的，那處理方式肯定是不一樣。因此 RAGFlow 在處理文檔時，給了不少的選擇：Q&A、Resume、Paper、Manual、Table、Book、Law、通用等等。當然，這些分類還在不斷繼續擴展中，處理過程還有待完善。他們也會抽象出更多共通的東西，使各種定制化的處理更加容易。

3、智能文檔處理的可視化和可解釋性：用戶上傳的文檔到底被處理成啥樣了，如：分割了多少片，各種圖表處理成啥樣了，畢竟任何基于 AI 的系統只能保證大概率正確，作為系統有必要給出這樣的空間讓用戶進行適當的干預，作為用戶也有把控的需求，黑箱不敵白箱。特別是對于 PDF，行文多種多樣，變化多端，而且廣泛流行于各行各業，對于它的把控尤為重要，RAGFlow 不僅給出了處理結果，而且可以讓用戶查看文檔解析結果并一次點擊定位到原文，對比和原文的差異，可增可減可改可查，如下圖所示：

4、RAGFlow 是一個完整的 RAG 系統，而目前開源的 RAG，大都忽視了 RAG 本身的最大優勢之一：可以讓 LLM 以可控的方式回答問題，或者換種說法：有理有據、消除幻覺。大家都知道，隨著模型能力的不同，LLM 多少都會有概率會出現幻覺，在這種情況下， 一款 RAG 產品應該隨時隨地給用戶以參考，讓用戶隨時查看 LLM 是基于哪些原文來生成答案的，這需要同時生成原文的引用鏈接，并允許用戶的鼠標 hover 上去即可調出原文的內容，甚至包含圖表。如果還不能確定，再點一下便能定位到原文，如下圖所示：

接下來講講，RAGFlow 具體是如何利用文檔結構識別模型來處理數據的。所謂文檔結構模型，如下所示，是針對文檔的布局進行目標識別，然后根據布局再做文字切分。這些布局識別的目標包括文檔的標題，段落，語義文字塊等等，尤其還會包含文檔當中的圖表。

在識別出這些目標之后，還需要分別對這些目標做相應處理：對于文字來說，需要首先判斷文字的換行信息——這對于文字的語義理解也會產生干擾；其次需要對文字內容進行一些整理，這些整理會隨著 RAGFlow 模板的不同有所區分；針對表格來說，還需要進一步識別它的內部結構，這在 AI 領域有個專門的研究課題，叫做 TSR(Table Structure Recognition 表格結構識別) 。

TSR 任務其實相對比較復雜，因為表格的定義是多種多樣的，表格內部可能會出現有線條或者沒有線條的情況，對于不同行的文字，判斷它們是否是一個單元格是存在很大挑戰的，單元格判斷失誤，很可能就會讓表格的數字跟表格列的對應關系弄錯，從而影響了對單元格內文字和數字語義的理解。因此他們花了很多時間來提升 TSR 的能力，最早是利用現成的 OCR 開源模型，后邊也嘗試過微軟研究院專門針對 TSR 任務的 Transformer 模型，但是發覺這些模型處理 TSR 任務的魯棒性依然非常不足，最后他們還是訓練了自己的模型，從而讓 TSR 任務表現良好。這個模型比較簡單，就是基于 CNN 的目標檢測模型，但是它的效果卻比上邊提到的其他模型都要好。為了降低對硬件的依賴和開銷，甚至切換到用 YOLOv8 來做目標檢測，使得僅僅利用 CPU 也可以運行文檔結構識別。

關于這些，其實也有很多業內人士建議直接走 LLM 的路子，用 LLM 來做文檔語義理解，從長期來看這肯定是個趨勢，然而在當下來說，讓 LLM 在文檔結構識別上表現良好，還需要大量的數據才可以。這從他們放棄了基于 Transformer 的 TSR 模型就可以看出：同樣的任務下，基于 Transformer 的模型需要更多的數據才可以表現更好，在有限數據下，不得不退回到傳統 CNN 模型，如果是 LLM ，它需要的數據和算力更多——他們之前曾經嘗試過基于多模態 LLM 進行識別的努力，相比專用小模型，

它的效果還是差別比較大。

解鎖對于非結構化數據的深度語義理解是 RAGFlow 追求的目標之一，InfiniFlow 希望在未來能夠將更加 scalable 的文檔結構識別模型應用到系統中。不僅如此， RAGFlow 的設計目標是讓 RAG 逐漸承接起更多的復雜場景尤其是 B 端場景，因此在未來，它會接入企業的各類數據源，比如 MySQL 的 binlog，數據湖的 ETL，乃至外部的爬蟲等。只有這些都被納入 RAG 的范疇，他們才能實現如下的愿景：

再回過來看 RAG 的未來以及 RAG 跟長上下文 LLM 之爭，這種爭論其實沒有必要，顯然兩者一定是合作的。長上下文 LLM 當下已經逐步具備了 RAG 最不可或缺的基礎能力，隨著它自身邏輯推理能力地增強，再結合來自數據庫，還有數據方面的改進，一定能加速 LLM 的 B 端場景走出嬰兒期的進程。

RAGFlow 近期更新：將提供類似文件管理的功能，這樣 RAG 可以跟企業內部文檔以更靈活的方式整合。RAGFlow 中期更新，將提供面向企業級數據接入的低代碼平臺，同時提供問答對話之外的高級內容生成，比如長文生成等等。

Infinity 近期更新：Infinity 將于近期發布第一個正式版本，屆時將提供業界最快的多路召回與融合排序能力。

歡迎大家關注他們的開源社區，并提出反饋意見！

項目開源地址：

Infinity : https://github.com/infiniflow/infinity

RAGFlow：https://github.com/infiniflow/ragflow

RAGFlow 在線Demo：https://demo.ragflow.io/

繼續閱讀：

未經允許不得轉載：RPA中國 | RPA全球生態 | 數字化勞動力 | RPA新聞 | 推動中國RPA生態發展 | 流 > 由近期 RAGFlow 的火爆看 RAG 的現狀與未來