4 月 1 日，InfiniFlow （英飛流）的端到端RAG解決方案 RAGFlow 正式開(kāi)源，首日即獲得了 github 千星，目前已接近 3000 star。在這之前，InfiniFlow 還開(kāi)源了專門用于 RAG 場(chǎng)景的 AI 原生數(shù)據(jù)庫(kù) Infinity，一個(gè)是 AI Infra基礎(chǔ)組件，一個(gè)是端到端應(yīng)用，在回答 InfiniFlow 為什么要連續(xù)開(kāi)源這樣兩款產(chǎn)品之前， 先來(lái)總結(jié)一下這兩款產(chǎn)品應(yīng)用的主要場(chǎng)景 RAG （基于檢索增強(qiáng)的內(nèi)容生成）、現(xiàn)狀以及未來(lái)。

RAG 技術(shù)從提出到成為共識(shí)，經(jīng)歷了不短也不長(zhǎng)的時(shí)間。它最早浮出水面，是在 2023 年 3 月的英偉達(dá) GTC 大會(huì)上，老黃當(dāng)眾點(diǎn)名了向量數(shù)據(jù)庫(kù)，緊接著 OpenAI 自身也發(fā)布了信息檢索插件解鎖了讓大模型訪問(wèn)私有數(shù)據(jù)的能力，由此，讓向量數(shù)據(jù)庫(kù)作為大模型的外掛記憶體存在，提供外掛知識(shí)庫(kù)的產(chǎn)品功能，成為 RAG 最早為大眾所知的使用姿勢(shì)，就是下邊這張圖展現(xiàn)的應(yīng)用架構(gòu)：

在很長(zhǎng)一段時(shí)間內(nèi)，RAG 在行業(yè)的代名詞都叫知識(shí)庫(kù)，上述的應(yīng)用架構(gòu)，不僅帶火了向量數(shù)據(jù)庫(kù)，也帶火了以LangChain，LlamaIndex 為代表的中間件，它們負(fù)責(zé)處理上圖中各個(gè)箭頭背后的工作流。具體包括：

1、把用戶的文檔進(jìn)行切分，然后再調(diào)用一個(gè) Embedding 模型把切分好的文檔生成為向量。

2、把生成好的向量連同原始文檔寫入到向量數(shù)據(jù)庫(kù)中。

3、查詢時(shí)，將用戶的提問(wèn)也根據(jù)相同的 Embedding 模型生成向量，然后查詢向量數(shù)據(jù)庫(kù)返回 Top K 結(jié)果。

4、把 Top K 結(jié)果對(duì)應(yīng)的文本拼成提示詞交由大模型做最終的摘要和內(nèi)容完成。

因此，整個(gè)架構(gòu)圖里核心部分是兩個(gè)：

1、向量數(shù)據(jù)庫(kù)：負(fù)責(zé)基于向量對(duì)用戶的文檔進(jìn)行查詢召回。

2、中間件：負(fù)責(zé)對(duì)文檔的切分，并轉(zhuǎn)成適合的向量。

采用向量這種形式是因?yàn)橄蛄靠梢蕴峁┱Z(yǔ)義召回，用戶只要提問(wèn)，最終能按照相似度高低返回最接近的答案而無(wú)需考慮問(wèn)題是否真的有哪些關(guān)鍵詞匹配到了文檔。即使沒(méi)有匹配，也依然可以根據(jù)語(yǔ)義相似度返回答案。之所以需要對(duì)用戶文檔進(jìn)行切分，是因?yàn)橄蛄勘碚鞯恼Z(yǔ)義比較含糊，不僅一篇文章可以表征為一個(gè)向量，一個(gè)單詞也可以表征為一個(gè)向量，這就導(dǎo)致文字塊跟向量對(duì)應(yīng)的粒度很難控制：粒度過(guò)粗，用一條向量對(duì)應(yīng)一大段話，對(duì)這些文字的細(xì)節(jié)很難表征；粒度過(guò)細(xì)，那么一大段文字會(huì)對(duì)應(yīng)一堆向量，而每個(gè)向量又僅僅代表幾個(gè)詞的語(yǔ)義，因此無(wú)法簡(jiǎn)單根據(jù)相似度來(lái)找到符合語(yǔ)義的向量。因此，需要對(duì)文檔進(jìn)行“恰當(dāng)”的切分，這就是 LangChain，LlamaIndex 等中間件的核心工作。

那么，如何定義“恰當(dāng)”呢？通常會(huì)采取一些簡(jiǎn)單的策略：例如先根據(jù)文字間的空白將文檔切分成不同的段落，這些段落表征的粒度相對(duì)比較適合。隨后通常會(huì)把一些標(biāo)題（通常需要根據(jù)一些規(guī)則來(lái)判斷）跟這些段落合并，讓這些只包含局部文字的段落也能體現(xiàn)整篇文章或者部分章節(jié)的語(yǔ)義。

因此，有了這類組件就可以快速搭建一套 RAG 系統(tǒng)。不過(guò)，自從這種應(yīng)用架構(gòu)從 23 年 4 月開(kāi)始流行，就一直面臨一個(gè)爭(zhēng)論：“把用戶的數(shù)據(jù)微調(diào)進(jìn)大模型直接回答問(wèn)題更好，而無(wú)需 RAG 這一整套基于檢索的架構(gòu)”。這類爭(zhēng)論伴隨了整個(gè) 2023 年。直到今天，這類爭(zhēng)論的聲音才漸漸淡去。因?yàn)椋茱@然，無(wú)論是實(shí)時(shí)性還是成本等方面， 采用 RAG 是碾壓對(duì) LLM 進(jìn)行微調(diào)的方案的。支持微調(diào)的擁護(hù)者所最看重的問(wèn)答質(zhì)量，但更多評(píng)測(cè)發(fā)現(xiàn)，兩者差距并不大，而逐漸得出了兩者需要搭配使用的結(jié)論。并且，這種所謂搭配使用的方案，隨著開(kāi)源 LLM 不斷快速迭代推陳出新，也導(dǎo)致實(shí)際真正采用微調(diào)的已寥寥無(wú)幾。

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

今年 2 月以來(lái)， AI 領(lǐng)域連續(xù)出了很多重磅熱點(diǎn)，除了最火熱的 Sora 之外，另一個(gè)熱點(diǎn)就是長(zhǎng)上下文 LLM ，例如 Claude 3、 Gemini 1.5，當(dāng)然也包含國(guó)產(chǎn)的月之暗面。Sora 的本質(zhì)是針對(duì)視頻提供更加可控的生成能力，這其實(shí)是解鎖未來(lái)多模態(tài) RAG 熱潮的一個(gè)必要條件；而長(zhǎng)上下文 LLM ，卻引發(fā)了更多針對(duì) RAG 的爭(zhēng)論，因?yàn)檫@些 LLM 可以支持用戶隨時(shí)上傳 PDF，甚至上傳幾十個(gè) PDF，然后針對(duì)這些 PDF 提供問(wèn)答，同時(shí)還具備強(qiáng)大的“大海撈針”能力。所謂“大海撈針”測(cè)試，就是針對(duì)長(zhǎng)上下文窗口內(nèi)的細(xì)節(jié)進(jìn)行提問(wèn)，看 LLM 是否可以準(zhǔn)確地回答。

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

隨著長(zhǎng)上下文 LLM 為更多用戶接納，近期各家國(guó)產(chǎn) LLM 都快速推出了這個(gè)產(chǎn)品特性，除月之暗面外，其他家大多基于 RAG 來(lái)實(shí)現(xiàn)，下表是兩者的基本對(duì)比：

這里要額外說(shuō)明一下為何 RAG 派的大海撈針能力一般，這并不是 RAG 本身的問(wèn)題，而是依靠純向量數(shù)據(jù)庫(kù)去構(gòu)建 RAG，并不能保證對(duì)精確數(shù)據(jù)和細(xì)節(jié)的準(zhǔn)確召回。以上的對(duì)比，其實(shí)并沒(méi)有完全解答 RAG 的必要性，因?yàn)橹辽倬湍壳?RAG 最普遍的場(chǎng)景——個(gè)人知識(shí)庫(kù)問(wèn)答而言，確實(shí)很多情況下只需要 LLM 就足夠了。至于成本性能等因素，這些問(wèn)題是會(huì)隨著時(shí)間推演，逐漸得到緩解的。

因此，RAG 的未來(lái)，似乎并不是那么樂(lè)觀。而 InfiniFlow 則認(rèn)為，LLM 的長(zhǎng)上下文能力，對(duì)于 RAG 來(lái)說(shuō)是很大的促進(jìn)。這里先用 OpenAI 聯(lián)創(chuàng)Andrej Karpathy的一張圖做個(gè)類比，他把 LLM 比喻為一臺(tái)計(jì)算機(jī)的 CPU， 把上下文類比為計(jì)算機(jī)的內(nèi)存，那么以向量為代表的數(shù)據(jù)庫(kù)，就可以看作是這臺(tái)計(jì)算機(jī)的硬盤。

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

其一是來(lái)自 LLM 自身。由于 RAG 的工作流程是針對(duì)從數(shù)據(jù)庫(kù)返回的結(jié)果進(jìn)行回答，這樣的話，對(duì)于 RAG 來(lái)說(shuō)，LLM 最基礎(chǔ)也是最重要的能力其實(shí)包含：

1、摘要能力；

2、可控性：即 LLM 是否聽(tīng)話，是否會(huì)不按照提示要求的內(nèi)容自由發(fā)揮產(chǎn)生幻覺(jué)；

3、翻譯能力：這對(duì)于跨語(yǔ)言 RAG 是必備的。

遺憾的是，在過(guò)去，國(guó)內(nèi)可以用到的 LLM 中，在這三點(diǎn)上表現(xiàn)良好的并不多。至于所謂高級(jí)的能力，例如邏輯推理，以及各類 Agent 要求的自主決策能力等，都建構(gòu)在以上基礎(chǔ)能力之上?；A(chǔ)不好，這些也都是空中樓閣。

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

假如不去專注于解決這兩類問(wèn)題，那么就很容易陷入讓 RAG 去和長(zhǎng)上下文 LLM 反復(fù)對(duì)比的情況：RAG 僅僅提供數(shù)據(jù)的簡(jiǎn)單解析，然后直接轉(zhuǎn)化為向量，最后用單一向量做召回，這除了成本，以及私有化場(chǎng)景里所要求的安全等優(yōu)勢(shì)之外，在核心對(duì)話能力上并沒(méi)有顯著地跟長(zhǎng)上下文 LLM 區(qū)分開(kāi)來(lái)，甚至還有所不及。

正是基于這些 RAG 本身的痛點(diǎn)，InfiniFlow 先后推出了兩個(gè)開(kāi)源項(xiàng)目，旨在解鎖 RAG 面向各類場(chǎng)景的服務(wù)能力，在當(dāng)下長(zhǎng)上下文 LLM 能力越來(lái)越強(qiáng)的前提下，如果把 RAG 自身的痛點(diǎn)也解決掉，那么就可以讓更多企業(yè)都真正把 LLM 用起來(lái)，而不是總是停留在淺層的知識(shí)庫(kù)對(duì)話。

第一個(gè)是 AI 原生數(shù)據(jù)庫(kù) Infinity。它解決的是如何解鎖 RAG 面臨 B 端場(chǎng)景的復(fù)雜查詢：如何跟企業(yè)已有的數(shù)據(jù)——包括但不限于非結(jié)構(gòu)化的文檔、圖片，還包括結(jié)構(gòu)化的信息系統(tǒng)來(lái)結(jié)合，并解決多路召回和最終融合排序的問(wèn)題。

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

第二個(gè)就是端到端的 RAG 引擎 RAGFlow。它解決數(shù)據(jù)的問(wèn)題：因?yàn)槿绻粚?duì)用戶數(shù)據(jù)加以區(qū)分和清洗，識(shí)別其中的語(yǔ)義，就容易導(dǎo)致 Garbage In Garbage Out。RAGFlow 包含了如下的完整 RAG 流程，確保數(shù)據(jù)從 Garbage In Garbage Out 變?yōu)?Quality In Quality Out。

具體來(lái)說(shuō)， RAGFlow 的最大特色，就是多樣化的文檔智能處理，因此它沒(méi)有采用現(xiàn)成的 RAG 中間件，而是完全重新研發(fā)了一套智能文檔理解系統(tǒng)，并以此為依托構(gòu)建 RAG 任務(wù)編排體系。這個(gè)系統(tǒng)的特點(diǎn)包含：

1、它是一套基于 AI 模型的智能文檔處理系統(tǒng)：對(duì)于用戶上傳的文檔，它需要自動(dòng)識(shí)別文檔的布局，包括標(biāo)題、段落、換行等，還包含難度很大的圖片和表格。對(duì)于表格來(lái)說(shuō)，不僅僅要識(shí)別出文檔中存在表格，還會(huì)針對(duì)表格的布局做進(jìn)一步識(shí)別，包括內(nèi)部每一個(gè)單元格，多行文字是否需要合并成一個(gè)單元格等。并且表格的內(nèi)容還會(huì)結(jié)合表頭信息處理，確保以合適的形式送到數(shù)據(jù)庫(kù)，從而完成 RAG 針對(duì)這些細(xì)節(jié)數(shù)字的“大海撈針”。

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

a. 會(huì)計(jì)一般最常接觸到的憑證、發(fā)票、Excel 報(bào)表；查詢的一般都是數(shù)字，如：看一下上月十五號(hào)發(fā)生哪些憑證，總額多少？上季度資產(chǎn)負(fù)債表里面凈資產(chǎn)總額多少？合同臺(tái)賬中下個(gè)月有哪些應(yīng)付應(yīng)收？

b. 作為一個(gè) HR 平時(shí)接觸最龐雜的便是候選人簡(jiǎn)歷，且查詢最多的是列表查詢，如：人才庫(kù)中 985/211 的三到五年的算法工程師有哪些？985 碩士以上學(xué)歷的人員有哪些？趙玉田的微信號(hào)多少？香秀哪個(gè)學(xué)校的來(lái)著？

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

這樣看來(lái)憑證/報(bào)表、簡(jiǎn)歷、論文的文檔結(jié)構(gòu)是不一樣的，查詢需求也是不一樣的，那處理方式肯定是不一樣。因此 RAGFlow 在處理文檔時(shí)，給了不少的選擇：Q&A、Resume、Paper、Manual、Table、Book、Law、通用等等。當(dāng)然，這些分類還在不斷繼續(xù)擴(kuò)展中，處理過(guò)程還有待完善。他們也會(huì)抽象出更多共通的東西，使各種定制化的處理更加容易。

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

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

接下來(lái)講講，RAGFlow 具體是如何利用文檔結(jié)構(gòu)識(shí)別模型來(lái)處理數(shù)據(jù)的。所謂文檔結(jié)構(gòu)模型，如下所示，是針對(duì)文檔的布局進(jìn)行目標(biāo)識(shí)別，然后根據(jù)布局再做文字切分。這些布局識(shí)別的目標(biāo)包括文檔的標(biāo)題，段落，語(yǔ)義文字塊等等，尤其還會(huì)包含文檔當(dāng)中的圖表。

在識(shí)別出這些目標(biāo)之后，還需要分別對(duì)這些目標(biāo)做相應(yīng)處理：對(duì)于文字來(lái)說(shuō)，需要首先判斷文字的換行信息——這對(duì)于文字的語(yǔ)義理解也會(huì)產(chǎn)生干擾；其次需要對(duì)文字內(nèi)容進(jìn)行一些整理，這些整理會(huì)隨著 RAGFlow 模板的不同有所區(qū)分；針對(duì)表格來(lái)說(shuō)，還需要進(jìn)一步識(shí)別它的內(nèi)部結(jié)構(gòu)，這在 AI 領(lǐng)域有個(gè)專門的研究課題，叫做 TSR(Table Structure Recognition 表格結(jié)構(gòu)識(shí)別) 。

TSR 任務(wù)其實(shí)相對(duì)比較復(fù)雜，因?yàn)楸砀竦亩x是多種多樣的，表格內(nèi)部可能會(huì)出現(xiàn)有線條或者沒(méi)有線條的情況，對(duì)于不同行的文字，判斷它們是否是一個(gè)單元格是存在很大挑戰(zhàn)的，單元格判斷失誤，很可能就會(huì)讓表格的數(shù)字跟表格列的對(duì)應(yīng)關(guān)系弄錯(cuò)，從而影響了對(duì)單元格內(nèi)文字和數(shù)字語(yǔ)義的理解。因此他們花了很多時(shí)間來(lái)提升 TSR 的能力，最早是利用現(xiàn)成的 OCR 開(kāi)源模型，后邊也嘗試過(guò)微軟研究院專門針對(duì) TSR 任務(wù)的 Transformer 模型，但是發(fā)覺(jué)這些模型處理 TSR 任務(wù)的魯棒性依然非常不足，最后他們還是訓(xùn)練了自己的模型，從而讓 TSR 任務(wù)表現(xiàn)良好。這個(gè)模型比較簡(jiǎn)單，就是基于 CNN 的目標(biāo)檢測(cè)模型，但是它的效果卻比上邊提到的其他模型都要好。為了降低對(duì)硬件的依賴和開(kāi)銷，甚至切換到用 YOLOv8 來(lái)做目標(biāo)檢測(cè)，使得僅僅利用 CPU 也可以運(yùn)行文檔結(jié)構(gòu)識(shí)別。

關(guān)于這些，其實(shí)也有很多業(yè)內(nèi)人士建議直接走 LLM 的路子，用 LLM 來(lái)做文檔語(yǔ)義理解，從長(zhǎng)期來(lái)看這肯定是個(gè)趨勢(shì)，然而在當(dāng)下來(lái)說(shuō)，讓 LLM 在文檔結(jié)構(gòu)識(shí)別上表現(xiàn)良好，還需要大量的數(shù)據(jù)才可以。這從他們放棄了基于 Transformer 的 TSR 模型就可以看出：同樣的任務(wù)下，基于 Transformer 的模型需要更多的數(shù)據(jù)才可以表現(xiàn)更好，在有限數(shù)據(jù)下，不得不退回到傳統(tǒng) CNN 模型，如果是 LLM ，它需要的數(shù)據(jù)和算力更多——他們之前曾經(jīng)嘗試過(guò)基于多模態(tài) LLM 進(jìn)行識(shí)別的努力，相比專用小模型，

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

解鎖對(duì)于非結(jié)構(gòu)化數(shù)據(jù)的深度語(yǔ)義理解是 RAGFlow 追求的目標(biāo)之一，InfiniFlow 希望在未來(lái)能夠?qū)⒏?scalable 的文檔結(jié)構(gòu)識(shí)別模型應(yīng)用到系統(tǒng)中。不僅如此， RAGFlow 的設(shè)計(jì)目標(biāo)是讓 RAG 逐漸承接起更多的復(fù)雜場(chǎng)景尤其是 B 端場(chǎng)景，因此在未來(lái)，它會(huì)接入企業(yè)的各類數(shù)據(jù)源，比如 MySQL 的 binlog，數(shù)據(jù)湖的 ETL，乃至外部的爬蟲(chóng)等。只有這些都被納入 RAG 的范疇，他們才能實(shí)現(xiàn)如下的愿景：

再回過(guò)來(lái)看 RAG 的未來(lái)以及 RAG 跟長(zhǎng)上下文 LLM 之爭(zhēng)，這種爭(zhēng)論其實(shí)沒(méi)有必要，顯然兩者一定是合作的。長(zhǎng)上下文 LLM 當(dāng)下已經(jīng)逐步具備了 RAG 最不可或缺的基礎(chǔ)能力，隨著它自身邏輯推理能力地增強(qiáng)，再結(jié)合來(lái)自數(shù)據(jù)庫(kù)，還有數(shù)據(jù)方面的改進(jìn)，一定能加速 LLM 的 B 端場(chǎng)景走出嬰兒期的進(jìn)程。

RAGFlow 近期更新：將提供類似文件管理的功能，這樣 RAG 可以跟企業(yè)內(nèi)部文檔以更靈活的方式整合。RAGFlow 中期更新，將提供面向企業(yè)級(jí)數(shù)據(jù)接入的低代碼平臺(tái)，同時(shí)提供問(wèn)答對(duì)話之外的高級(jí)內(nèi)容生成，比如長(zhǎng)文生成等等。

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

歡迎大家關(guān)注他們的開(kāi)源社區(qū)，并提出反饋意見(jiàn)！

項(xiàng)目開(kāi)源地址：

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

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

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

繼續(xù)閱讀：

未經(jīng)允許不得轉(zhuǎn)載：RPA中國(guó) | RPA全球生態(tài) | 數(shù)字化勞動(dòng)力 | RPA新聞 | 推動(dòng)中國(guó)RPA生態(tài)發(fā)展 | 流 > 由近期 RAGFlow 的火爆看 RAG 的現(xiàn)狀與未來(lái)