一、RAG1.0 的痛點(diǎn)和解決方向

1. RAG 架構(gòu)模式

對(duì)于上圖所示的 RAG 架構(gòu)模式，大家應(yīng)該都比較熟悉。RAG 的標(biāo)準(zhǔn)流程包括四個(gè)階段，即抽取（Extraction）、索引（Indexing）、檢索（Retrieval）和生成（Generation）。

2. RAG 面臨的挑戰(zhàn)

RAG 通常會(huì)遇到如下一些挑戰(zhàn)：

• 第一個(gè)挑戰(zhàn)是向量的召回?zé)o法滿足要求，即命中率很低。當(dāng)前如果用一個(gè)純向量數(shù)據(jù)庫(kù)來(lái)做 RAG，其效果往往不夠理想。
• 第二個(gè)挑戰(zhàn)是文檔結(jié)構(gòu)復(fù)雜，數(shù)據(jù)太亂，“Garbage In，Garbage Out”。簡(jiǎn)單文本尚可，但如果稍微復(fù)雜一些，特別是涉及到多模態(tài)的文檔效果會(huì)較差。
• 第三個(gè)挑戰(zhàn)是問(wèn)題和答案所在文檔關(guān)聯(lián)不大，很難通過(guò)問(wèn)題找到正確文檔，存在語(yǔ)義鴻溝。對(duì)于比較宏觀的問(wèn)題，比如一篇文章講了些什么，或者是一些多跳問(wèn)答，一個(gè)問(wèn)題被分解成若干子問(wèn)題，需要根據(jù)子問(wèn)題進(jìn)一步推理，這些情況下可能搜不到想要的答案。

以上就是當(dāng)前阻擋 RAG 實(shí)現(xiàn)企業(yè)級(jí)應(yīng)用的一些障礙，接下來(lái)將探討如何解決這些問(wèn)題。

3. 下一代 RAG 架構(gòu)

下一代 RAG，即 RAG2.0，包括兩部分：一部分是離線處理，用來(lái)處理一些文檔；另一部分是在線處理。

離線處理部分需要經(jīng)過(guò)一系列的深度文檔理解模型，也就是未來(lái)的多模態(tài)模型。用多模態(tài)模型將多模態(tài)文檔進(jìn)行基于語(yǔ)義的切分之后，就可以得到一個(gè)保證數(shù)據(jù)質(zhì)量的結(jié)果，進(jìn)而才能得到一個(gè)高質(zhì)量的回答。

在線處理部分是在得到數(shù)據(jù)之后去做一些知識(shí)圖譜，解決答案與語(yǔ)義之間的鴻溝。繼而需要處理向量召回低命中率的問(wèn)題，我們需要多種解決方案，比如混合搜索、查詢改寫(xiě)等，最終通過(guò) LLM 生成答案。

4. Infiniflow

我們計(jì)劃將 RAGFlow 和 Infinity 整合到一起。我們的 RAGFlow 于今年 4 月 1 日開(kāi)源，并在持續(xù)迭代中。目前為止，RAGFlow 其實(shí)是對(duì)最終的 RAG 對(duì)話效果負(fù)責(zé)的，可以用這些模型去處理數(shù)據(jù)入口，其中也包含了 Graph RAG，未來(lái)還將加入一個(gè)開(kāi)源數(shù)據(jù)庫(kù) Infinity。該產(chǎn)品提供了豐富的針對(duì) RAG 場(chǎng)景的混合搜索能力，可以滿足對(duì)企業(yè)級(jí)檢索的所有要求。

二、如何有效 Chunking

1. Chunking 的流程

Chunking 的流程如以上右圖所示：

• 第一步會(huì)經(jīng)過(guò)一個(gè)專用的文檔結(jié)構(gòu)識(shí)別模型，確定文檔的頁(yè)眉、頁(yè)腳、段落、圖、表以及其坐標(biāo)分別在哪里。
• 第二步，判斷這些坐標(biāo)里面的區(qū)域是文字區(qū)域，那么就要進(jìn)行相應(yīng)的文字處理，比如對(duì) PDF 掃描件，就要去調(diào)用 OCR，如果不是掃描件，就直接去做文本的抽取。文本抽取需要注意的是，通常情況下是從 PDF 抽取文檔，解析出來(lái)的文本無(wú)法區(qū)分換行，到底是不是換行需要通過(guò)一個(gè)分類器去做進(jìn)一步判斷，如果換錯(cuò)了，生成的向量會(huì)對(duì)最終召回產(chǎn)生干擾。所以這里需要做一些額外的、比較瑣碎的 dirty work 來(lái)保證文檔的高質(zhì)量解析。
• 接著是 chunking 輸出最后的答案。

以上是文本類的處理流程。對(duì)于表，目前是通過(guò)一個(gè)表格結(jié)構(gòu)識(shí)別模型去處理，把表頭和單元格的對(duì)應(yīng)關(guān)系抽取出來(lái)，再得到最后的 chunking 結(jié)果。對(duì)于其它圖，比如流程圖、餅圖、柱狀圖、曲線圖、折線圖，同理，也可以利用多模態(tài)模型。這就是我們利用深度文檔理解模型保證數(shù)據(jù)質(zhì)量入口的解決方案。

2. 調(diào)整抽取模型的 RAGFlow 對(duì)比

上圖是 RAGFlow 與一些開(kāi)源 RAG 和頭部大模型公司的商業(yè)化 RAG 產(chǎn)品的評(píng)測(cè)對(duì)比。評(píng)測(cè)指標(biāo)有兩個(gè)：完全準(zhǔn)確率和部分準(zhǔn)確率。可以看到我們通過(guò)不斷的調(diào)整抽取之后，準(zhǔn)確率達(dá)到了非常高的量級(jí)。根據(jù)我們的經(jīng)驗(yàn)，要真正在企業(yè)中將 RAG 利用起來(lái)，開(kāi)源 RAG 很難滿足需求，因?yàn)槠涿新瘦^低。

3. 表格識(shí)別模型

上圖中的表格較為復(fù)雜，單元格有的有線段，有的沒(méi)線段，左側(cè)一列還有單元格合并，并且表格中出現(xiàn)了很多陰影，這些都會(huì)對(duì)表格內(nèi)容的抽取產(chǎn)生很多干擾，這些工作都是表格結(jié)構(gòu)識(shí)別模型的范疇。表格結(jié)構(gòu)識(shí)別模型有兩種做法，我們最早的做法是把每個(gè)單元格都變成一句話，但是這種方法的魯棒性不是太高。我們現(xiàn)在的做法是把整張表格識(shí)別出來(lái)的文本轉(zhuǎn)成 HTML 的形式（HTML 可以保證表格的結(jié)構(gòu)布局），然后整個(gè)輸入到模型中去，讓模型去針對(duì)表格內(nèi)容進(jìn)行回答。這種做法的魯棒性會(huì)更好一點(diǎn)。所以表格結(jié)構(gòu)識(shí)別的準(zhǔn)確度是非常關(guān)鍵的，甚至可以把它單獨(dú)拿出來(lái)做一個(gè)組件，以 API 的形式提供給業(yè)務(wù)方去使用。

上圖中的 RAGFlow 采用傳統(tǒng)的 CNN 卷積神經(jīng)網(wǎng)絡(luò)，把表格作為一個(gè)目標(biāo)檢測(cè)問(wèn)題來(lái)處理，然后得到最終的答案。我們現(xiàn)在正在訓(xùn)練的模型正是采用這種完全基于 transformer 的架構(gòu)，無(wú)論是表格還是流程圖、餅圖、柱狀圖都可以處理，因?yàn)檫@是一種通用的方案，解決圖片進(jìn)-文字出、encoder 進(jìn)-decoder 出的問(wèn)題。

具體過(guò)程為，第一步用 VAE（變分自動(dòng)編碼器）的方式做特征抽取，先用 CNN 編碼器把表格的圖片編碼，然后再用 CNN 解碼器還原，讓我們的解碼器和編碼器能得到的圖片盡可能跟原始圖片一樣，我們就得到了中間的 Code Book（碼本）。這其實(shí)就相當(dāng)于 image patch 的一個(gè) embedding，能夠非常真實(shí)地還原表格場(chǎng)景中 embedding 的表示，這個(gè) Code Book 是非常重要的。

第二步是訓(xùn)練 Transformer Encoder。Encoder 同樣是 image 進(jìn)，并且要讓 Encoder 的輸出盡可能去擬合上面的 embedding。

第三步是用 Encoder 和 Decoder 一起訓(xùn)練。Decoder 輸出最終的一個(gè) HTML 文本。

這種結(jié)構(gòu)跟大模型是有一定相似性的，只不過(guò)大模型如 GPT 都是 Decoder only。但是我們只要做多模態(tài)模型就必須是 Encoder Decoder 這種架構(gòu)，以得到一個(gè)統(tǒng)一的圖像轉(zhuǎn)文本的方案。

雖然模型仍在訓(xùn)練中，但已訓(xùn)練出來(lái)的結(jié)果顯示表格識(shí)別的效果非常好，比之前用 CNN 的魯棒性能要好很多。因?yàn)楸砀褡R(shí)別模型基于 Transformer 架構(gòu)，這種模型的訓(xùn)練都有個(gè)比較高的門(mén)檻就是訓(xùn)練數(shù)據(jù)的來(lái)源。我們現(xiàn)在的做法基本上都是用程序來(lái)生成，盡可能去覆蓋更多的場(chǎng)景。比如哪些用戶的表格做的不夠好，我們就專門(mén)針對(duì)這種場(chǎng)景去做模擬生成相應(yīng)的圖片，然后拿這種圖片去不斷迭代模型，最終形成一個(gè)數(shù)據(jù)飛輪，使模型迭代效果、泛化能力越來(lái)越好。

4. 文檔“大”模型

接下來(lái)，在表格的基礎(chǔ)上，還會(huì)加入流程圖、餅圖、柱狀圖等圖表，以同樣的架構(gòu)，得到語(yǔ)義信息的 HTML 格式的文本，交給大模型，進(jìn)而得到最終的回答。

三、如何準(zhǔn)確召回

接下來(lái)介紹如何保證準(zhǔn)確的召回。

1. Indexing Database

為了做到準(zhǔn)確召回，我們從兩年前就開(kāi)始開(kāi)發(fā)一個(gè)索引型數(shù)據(jù)庫(kù)。如上圖所示，當(dāng)我們創(chuàng)建一張有不同類型數(shù)據(jù)的表時(shí)，我們會(huì)根據(jù)列存儲(chǔ)中的數(shù)據(jù)類型去創(chuàng)建相應(yīng)的索引。比如對(duì)向量，會(huì)創(chuàng)建向量索引，如果是稀疏向量，就創(chuàng)建稀疏向量索引；如果是文字，就創(chuàng)建全文索引。值得一提的是，目前全文索引是唯一能夠保障問(wèn)題是什么就搜到什么的索引，它對(duì)于 RAG 來(lái)說(shuō)是一個(gè)必選項(xiàng)。當(dāng)然，還有一個(gè)是張量索引。最后再搞定融合性排序，我們就能一站式地解決所有針對(duì) RAG 的檢索問(wèn)題。

2. Benchmark

上圖中是我們當(dāng)前使用的一些指標(biāo)，與當(dāng)前流行的開(kāi)源向量數(shù)據(jù)庫(kù)和搜索引擎分別進(jìn)行了對(duì)比，左邊是延遲，數(shù)值越低越好，右邊是 QPS，數(shù)值越高越好?？梢钥吹?，目前我們?cè)谶@幾個(gè)數(shù)據(jù)集上都具有領(lǐng)先優(yōu)勢(shì)。

3. RAG 數(shù)據(jù)庫(kù)選型對(duì)比

目前用于 RAG 的數(shù)據(jù)庫(kù)分為三類：

• 第一類是傳統(tǒng)型數(shù)據(jù)庫(kù)。這種類型的數(shù)據(jù)庫(kù)只要增加了向量能力，理論上就可以用于 RAG。像 PostgreSQL 有個(gè)著名的插件 PG Vector 就是用來(lái)支持向量存取的，Snowflake 是一個(gè)數(shù)倉(cāng)，同時(shí)也具備向量的能力。
• 第二類是典型的向量數(shù)據(jù)庫(kù)，如 Pinecone、Qdrant、Weaviate。
• 第三類是具備全文搜索+向量能力的數(shù)據(jù)庫(kù)，比如 ROCKSET、LanceDB、Elasticsearch。

在企業(yè)級(jí)場(chǎng)景中，全文搜索是一項(xiàng)必備能力，目前知名的具備全文搜索和向量能力的數(shù)據(jù)庫(kù)就是以上這些。LanceDB 是最近北美孵化出來(lái)的一個(gè)數(shù)據(jù)庫(kù)，采用了知名的 Tantivy 庫(kù)做全文索引。ROCKSET 是 Open AI 在今年六月份收購(gòu)的一家數(shù)據(jù)庫(kù)公司，它是一個(gè)索引型數(shù)據(jù)庫(kù)，對(duì)每一列都建了全文索引，所以一開(kāi)始就是去取代 Elasticsearch 的，不過(guò)后來(lái)因?yàn)?RAG 的流行，它又增加了向量索引，因此具備了兩路混合搜索，以保證更好的召回結(jié)果。我們也正在將 Infinity 這個(gè)數(shù)據(jù)庫(kù)加到 RAGFlow 中。因?yàn)?RAGFlow現(xiàn)在用的是 Elasticsearch，替換成 Infinity 還需要一點(diǎn)時(shí)間。

4. 幾路召回？

接下來(lái)討論一些技術(shù)問(wèn)題，第一個(gè)問(wèn)題就是我們現(xiàn)在已經(jīng)有向量、稀疏向量、張量等搜索方式，那混合搜索、多路召回還有意義嗎？

我們使用 MLDR 數(shù)據(jù)集做了一個(gè)評(píng)測(cè)。MLDR 是一個(gè)長(zhǎng)文檔數(shù)據(jù)集，我們用自己的數(shù)據(jù)庫(kù)跑出了如上圖所示的指標(biāo)，圖中縱坐標(biāo)為 nDCG@10，對(duì)每個(gè)結(jié)果的位置都要去對(duì)最終的結(jié)果做一個(gè)加權(quán)的得分。所以本來(lái)是排在第一位的，放到第二位也會(huì)對(duì)這個(gè)分?jǐn)?shù)產(chǎn)生影響。圖中顏色最淺的這三路就是我們用三種方式分別去搜索，BM25 是全文搜索，Dense 是向量搜索，Sparse 是稀疏向量?？梢钥吹饺绻挥孟蛄康脑?，最低的只有 49 分。中間顏色深一點(diǎn)的是兩路召回，就是把稀疏向量和全文搜索兩兩組合，再加上一個(gè)比較 basic 的融合排序，即兩路召回加 RRF 得到一個(gè)混合搜索，結(jié)果確實(shí)比單路搜索要好一些。倒數(shù)第二個(gè)是把三路搜索混在一起，再加 RRF，它的得分更高。這個(gè)結(jié)果來(lái)自今年四月份 IBM Research 蘇黎世的研究員發(fā)表的一篇名為《BlendedRAG: Improving RAG》的論文（論文地址：https://arxiv.org/pdf/2404.07220），其結(jié)論就是三路召回效果最好。我們通過(guò)我們的數(shù)據(jù)庫(kù)也復(fù)現(xiàn)出了這個(gè)結(jié)論。圖中最右邊，又有一個(gè)比較大的提升，因?yàn)槲覀冏隽藗€(gè)張量，將張量以 ColBERT 的形式放進(jìn)來(lái)，使最終的召回效果有了更大的提升。

5. 排序模型

第二個(gè)問(wèn)題是張量究竟是怎么回事兒？

上圖展示了當(dāng)前的三類排序模型：

• 第一類是雙編碼器。雙編碼器與向量搜索思路一致，就是把 Query 和 Document 分別輸入模型之后編碼。這里有個(gè)關(guān)鍵點(diǎn)，編碼之后每個(gè) token 都生成了 embedding，但是經(jīng)過(guò)池化層（Pooling）后最終變成了一個(gè)向量，因此它的語(yǔ)義是一定有損失的。
• 第二類是交叉編碼器。將 Query 和文檔一起輸入模型，去做交叉編碼。交叉編碼能夠捕獲 Query 的每個(gè) token 和文檔的每個(gè) token 兩兩之間的一個(gè) interaction 的關(guān)系。這些 token 只要在我們的訓(xùn)練數(shù)據(jù)集里面出現(xiàn)過(guò)，我們就可以捕獲這種關(guān)系，最后我們只輸出一個(gè)。所以交叉編碼器相對(duì)于雙編碼器來(lái)說(shuō)效果要好很多，常見(jiàn)的 BGE 就是一種典型的交叉編碼器。
• 第三類是延遲交互編碼器。在離線階段就把模型給每個(gè) token 生成的 embedding 全部都存下來(lái)，對(duì)于每個(gè)文檔來(lái)說(shuō)存的不是一個(gè)向量，而是一個(gè)張量或者多向量，因?yàn)槲覀儠?huì)把每個(gè) token 的向量全部都存下來(lái)。查的時(shí)候只需要對(duì)查詢?nèi)ピ僮鰝€(gè)編碼，這樣就會(huì)把一個(gè) Query 變成很多 token 的向量。查詢和查詢結(jié)果也是向量，把這些向量之間的得分兩兩計(jì)算后再疊加。這種方式也是捕獲了 token 之間的交互關(guān)系，因此理論上接近于交叉編碼器，但是由于放到數(shù)據(jù)庫(kù)里面做就有額外的好處。

6. ColBERT 的收益

額外的好處在于它的效率要高很多，根據(jù)我們的評(píng)估，大概可以高兩個(gè)數(shù)量級(jí)。要求重排序模型必須得用 GPU 去跑，而且還只能針對(duì)前面的結(jié)果，比如 top 10 或者 top 20 去做重排序。但是要對(duì) top 100 或 top 1000 去做重排序，影響就比較大了，性能可能就會(huì)受影響，編碼的性能和傳輸?shù)男阅芏紩?huì)較差。但是如果我們有重排序模型，它在數(shù)據(jù)庫(kù)里面去跑，性能比這種基于 GPU 去跑的交叉編碼器高兩個(gè)數(shù)量級(jí)的話，我們就可以用 CPU 去跑，甚至可以對(duì) top 100 乃至 top 1000 去做重排序。這種情況下如果我們前面搜的效果不好，后面還有很大的概率可以挽回。所以這樣做的意義就是在效果接近的基礎(chǔ)之上提升了很多效率。因此，就可以有很大的概率能夠讓最終的排序比較好。

但同時(shí)也存在風(fēng)險(xiǎn)，ColBERT 其實(shí)是把每個(gè) token 都存下來(lái)，因此它的空間膨脹是非?？膳碌?，ColBERT 模型里面每個(gè) embedding 差不多是 128 維，也就是說(shuō)每個(gè) token 是 128 維，那就意味著我們最終得到的張量相比原始文本空間膨脹了兩個(gè)數(shù)量級(jí)。如果我們用更大的 embedding，比如一個(gè)典型的 BGE 輸出的 embedding 差不多是 1000 多維，那就意味著要膨脹三個(gè)數(shù)量級(jí)，如果原始是 1G 的文本，就變成 1T 了。

7. ColBERT 的收益

我們將 ColBERT 和沒(méi)有 ColBERT 的情況進(jìn)行了對(duì)比，可以看到，不管是一路召回、兩路召回還是三路召回，只要加了基于張量的重排序，都可以有一個(gè)比較明顯的提升。甚至語(yǔ)義，它損失是最大的，在加了張量之后也能從 40 級(jí)提升到 60 級(jí)。這個(gè)張量不是對(duì) top 10、top 20 去做重排，而是對(duì) top 100 以上去做重排才能得到這么好的結(jié)果。

8. ColBERT ranker 還是 reranker

我們現(xiàn)在就來(lái)談效率這個(gè)事兒。在張量里面有兩種做法，一種做法是用張量去建立索引，把它作為一種召回的手段，跟向量是一樣的；還有一種做法就是把張量作為重排序的方案。上圖展示了兩種方法的對(duì)比，第一個(gè)就是用了張量索引，這個(gè)張量索引在我們內(nèi)部叫做 EMVB。EMVB 其實(shí)是向量索引應(yīng)用到張量空間的一種改進(jìn)，它可以針對(duì) tensor 去做類似的索引。中間用 ColBERT 去做重排序。最右邊用張量去做暴力搜索，既不做重排序，也不做任何的索引，理論上也就沒(méi)有任何精度損耗。

可以看到最高 74，但是我們中間做重排序，甚至比用索引來(lái)搜還要好。這就意味著我們沒(méi)有必要對(duì)張量模型去實(shí)現(xiàn)這種索引，現(xiàn)在像 ColBERT 這種模型官方提供的都是這種索引方案，但是它的性價(jià)比不高，反而是做重排序性價(jià)比很高。而且用重排序有一個(gè)非常明顯的好處在于我們可以不用存原始的張量，而是只存它的二進(jìn)制量化。也就是用一個(gè)比特來(lái)表示一個(gè)浮點(diǎn)數(shù)，這樣就可以把空間壓縮 32 倍。如果是用 128 維的 ColBERT 模型，最后一個(gè) token 只需要占用 16 個(gè)字節(jié)，這個(gè)成本是可以接受的。我們用少量的空間膨脹換取了更高質(zhì)量的排序，這是值得的。所以未來(lái)重排序也將是 RAG 的一個(gè)標(biāo)配。

9. 延遲交互是 RAG 的未來(lái)

根據(jù)我們的觀察，延遲交互編碼并不是交叉編碼的一個(gè) trade off，它甚至可以做得比交叉編碼更好。上圖中第一個(gè)圖是來(lái)自 JaColBERT 的數(shù)據(jù)，這是今年八月份北美一家叫做昂斯利亞的公司訓(xùn)練出來(lái)的專門(mén)針對(duì)日本的ColBERT 的模型，可以看到在 MIRACL 這個(gè)數(shù)據(jù)集上，它的表現(xiàn)甚至比 BGE-M3 還要好。所以基于這種延遲交互的模型，可能會(huì)帶來(lái)更高的精度。因此我們認(rèn)為張量是 RAG 的未來(lái)發(fā)展方向。

第二個(gè)圖是 Jina 的工作，我們之前也一直在找這種中文的 ColBERT 模型，甚至我們自己也在訓(xùn)練，后來(lái)發(fā)現(xiàn) Jina 最近剛剛公布了一個(gè)叫 Jina-ColBERT v2 的模型，這是市面上第一個(gè)多語(yǔ)言的 ColBERT 模型，可以生成文本類的張量。只不過(guò) Jina 這個(gè)工作現(xiàn)在還沒(méi)有進(jìn)行到更進(jìn)一步，目前其結(jié)果相比 BGE 還是有所下降。但是我們由上面這個(gè) JaColBERT 已經(jīng)可以看到延遲交互模型做的效果不差于交叉編碼器，我們已將這些能力加入到了數(shù)據(jù)庫(kù)中。

10. 延遲交互是 RAG 的未來(lái)

另外一個(gè)模型是 answerai。它把 ColBERT 的參數(shù)壓縮到只有 3300 萬(wàn)，但是獲得的效果比 BGE 一億多參數(shù)的模型更好。而且它的每個(gè) token 只有 96 位，如果做二進(jìn)制量化之后，那么每個(gè) token 只有 12 個(gè)字節(jié)，這樣空間浪費(fèi)會(huì)大大減少。相信在未來(lái)會(huì)有更多這種 ColBERT 模型出現(xiàn)，特別是用于中文的 ColBERT 模型，來(lái)保證召回的效果。

四、高級(jí) RAG 和預(yù)處理

第三部分將介紹如何解決語(yǔ)義鴻溝，也就是預(yù)處理的方法。

1. 復(fù)雜問(wèn)答之文檔預(yù)處理-RAPTOR

第一種預(yù)處理方法稱為 RAPTOR，首先是對(duì)文檔去做聚類，做好聚類之后生成摘要，連同這些信息一起作為 chunks 送到 RAG 體系里面去，在搜索的時(shí)候我們就可以搜索到這個(gè)聚類后的信息。整個(gè)文檔跨 chunks 之間具備語(yǔ)義信息，所以基于 RAPTOR 可以去解決多跳問(wèn)答或者比較宏觀的問(wèn)答。

2. 復(fù)雜問(wèn)答之 Agentic RAG

第二種方法是 AgenticRAG?？赡芎芏嗤瑢W(xué)存在疑問(wèn)，RAG 和 Agent 到底是什么關(guān)系？在我們看來(lái) RAG 是 Agent 的基座，Agent 更偏向業(yè)務(wù)場(chǎng)景，而 RAG 則是一個(gè)技術(shù)類的中臺(tái)或者中心層，所以我們可以用 Agent 把 RAG 變得更加復(fù)雜，比如用 Agent 去編排更多的 RAG 流程。在這里面我們需要一些不同的算子，比如查詢意圖庫(kù)、查詢改寫(xiě)，有這些算子后就可以去編排整個(gè)對(duì)話，不斷迭代，最終達(dá)到一個(gè)理想的效果。

3. 復(fù)雜問(wèn)答之知識(shí)圖譜

第三種是知識(shí)圖譜。知識(shí)圖譜在十幾年前就已出現(xiàn)，以往使用知識(shí)圖譜要求非常準(zhǔn)確，需要大量的人工去校對(duì)知識(shí)圖譜的準(zhǔn)確性，這也導(dǎo)致了知識(shí)圖譜實(shí)施困難。而且知識(shí)圖譜中實(shí)體之間的關(guān)系非常復(fù)雜，會(huì)多達(dá)十幾種甚至幾十種，因此自動(dòng)化構(gòu)建知識(shí)圖譜的門(mén)檻非常高。

但是現(xiàn)在有了 Graph RAG 之后，很多工作得到了簡(jiǎn)化。我們首先用大模型抽取出文字當(dāng)中的實(shí)體，接下來(lái)只需要判定實(shí)體是否關(guān)聯(lián)就可以了。也就是說(shuō)，我們把傳統(tǒng)知識(shí)圖譜內(nèi)部的實(shí)體之間的關(guān)系從十幾種、幾十種簡(jiǎn)化成了一種關(guān)聯(lián)，這就使自動(dòng)化構(gòu)建知識(shí)圖譜成為一種可能。產(chǎn)生知識(shí)圖譜之后還可以繼續(xù)生成 node embedding，就可以以圖向量的方式去做檢索。

Graph embedding 其實(shí)也可以去做更多的改進(jìn)。一種簡(jiǎn)單的例子是以企業(yè)內(nèi)部問(wèn)答系統(tǒng)去對(duì)圖神經(jīng)網(wǎng)絡(luò)做一個(gè)近似，可以把 node embedding 質(zhì)量變得更高。如果直接生成 embedding 其實(shí)相當(dāng)于對(duì)知識(shí)圖譜的圖做了一個(gè)遍歷，類似于 PageRank，那為什么做 PageRank 可以把知識(shí)圖譜的召回做得比較符合我們答案的訴求呢？是因?yàn)檫@符合我們大腦思維的過(guò)程，我們?cè)诼?lián)想的時(shí)候，大腦內(nèi)部類似于走了一個(gè)隨機(jī)游走的過(guò)程，這個(gè)過(guò)程我們通過(guò)一個(gè)叫做 node2Vect 的算法把它變成 graph embedding。因此有了知識(shí)圖譜，再通過(guò) graph embedding 去做召回，就可以很好地處理多跳問(wèn)答或者比較宏觀的問(wèn)答方式。

大家可能會(huì)比較感興趣這三種方法哪種更好？

第一種 RAPTOR 顯然更為簡(jiǎn)單。第二種 AgenticRAG 需要依賴于一些內(nèi)部的算子，比如查詢意圖，查詢意圖在不同場(chǎng)景其實(shí)是不一樣的，所以很難標(biāo)準(zhǔn)化。第三種知識(shí)圖譜相比于 RAPTOR 不僅僅是聚類這么簡(jiǎn)單，它抽取出了更多的實(shí)體，因此知識(shí)圖譜的效果會(huì)比 RAPTOR 更好。但是它也存在缺點(diǎn)，因?yàn)橹R(shí)圖譜意味著我們要把用戶所有的文檔都過(guò)一遍模型，所以想要降低成本的話，除非全部都做私有化部署。我們比較推薦的做法是使用微調(diào)的小模型，實(shí)際上海外已經(jīng)有一些類似方案，比如 Triplex，它專門(mén)做知識(shí)圖譜抽取，我們認(rèn)為這種方案會(huì)成為未來(lái)的一個(gè)標(biāo)配。

五、RAG 未來(lái)如何發(fā)展

1. 多模態(tài) RAG-G—“雕花”還是？

我們預(yù)測(cè)明年會(huì)是多模態(tài) RAG 的爆發(fā)年。因?yàn)楦鶕?jù)我們現(xiàn)在的觀察，多模態(tài)技術(shù)已逐步走向成熟。上圖總結(jié)了當(dāng)前針對(duì)多模態(tài)數(shù)據(jù)的三種處理方式：

• 第一種就是我們現(xiàn)在開(kāi)源的 RAGFlow，通過(guò)目標(biāo)檢測(cè)算法，將圖表變成文本。
• 第二種我們正在訓(xùn)練，目前已經(jīng)達(dá)到非常好的一個(gè)結(jié)果，原理是用多模態(tài)模型 Encoder 進(jìn)、Decoder 出把圖片變成文本。
• 第三種是直接把圖片生成Patch Embedding，Patch 就是 Image 里面類似文本 token 的一個(gè)單元，要把它變成 Embedding。實(shí)際上，第三種跟第二種是可以共享的，因?yàn)樗鼈兊?Encoder 是完全可以共享的。第三條路線我們還沒(méi)有做，因?yàn)樗恼J(rèn)知相對(duì)來(lái)說(shuō)還沒(méi)有那么準(zhǔn)。不過(guò)其發(fā)展會(huì)非?？?，我們最近看到一篇工作叫做《ColPali: Efficient Document Retrieval with Vision Language Models》，它否定了上面的第一條傳統(tǒng)的路線:“把多模態(tài)文檔先做 OCR、布局識(shí)別，然后布局檢測(cè)得到文本，最后再送到 RAG”，將其比作“雕花”，因?yàn)樗_實(shí)非?，嵥椤?/span>

2. 多模態(tài) RAG 與延遲交互模型

這種方式是直接把多模態(tài)文檔以圖像的方式灌進(jìn)去變成 embedding，問(wèn)答的時(shí)候直接針對(duì) embedding 進(jìn)行回答即可。比如上圖中的例子，我們就可以直接對(duì)柱狀圖提問(wèn)：“2019 年一天中平均哪個(gè)小時(shí)電力消耗最高？”。可以看到右邊用 ColPali 之后，它的評(píng)測(cè)指標(biāo) NDCG 能夠達(dá)到 80 以上，這是非常高的值，意味著已經(jīng)達(dá)到生產(chǎn)可用了。ColPali 與前面講的 ColBert 關(guān)系非常密切，這個(gè) Col 的意思就是查詢和文檔是共同編碼。ColPali 就是把多模態(tài)數(shù)據(jù)輸出一個(gè)張量，而不是一個(gè)向量，可以看到它們的語(yǔ)義相似度的評(píng)測(cè)結(jié)果可以從不到 60 提升到 80 以上，這就是一個(gè)玩具級(jí)到生產(chǎn)可用的差別。所以在未來(lái)張量（Tensor）重排序會(huì)是數(shù)據(jù)庫(kù)內(nèi)部的一個(gè)標(biāo)配，它不僅僅是針對(duì)文本檢索，對(duì)多模態(tài)檢索也意義重大，預(yù)計(jì)明年將會(huì)非常普及。

3. 記憶增強(qiáng)的 Agent

Agent 進(jìn)一步發(fā)展，需要引入記憶，在不同領(lǐng)域中對(duì)應(yīng)不同的信息保存，比如醫(yī)療、金融、法律領(lǐng)域會(huì)保存案例、知識(shí)，市場(chǎng)信息或成功經(jīng)驗(yàn)等，對(duì)于游戲會(huì)保存一些個(gè)性化行為，而在推薦系統(tǒng)當(dāng)中則可以去保存用戶的歷史上下文。由此可以看出 Agent 的記憶模塊對(duì)數(shù)據(jù)庫(kù)也是有所要求的。未來(lái)的 RAG，對(duì)數(shù)據(jù)庫(kù)能力的要求不只是混合搜索，Agent 記憶中存儲(chǔ)的數(shù)據(jù)可能是向量、張量、文本或者結(jié)構(gòu)化數(shù)據(jù)，所以 RAG 未來(lái)會(huì)對(duì)數(shù)據(jù)庫(kù)提出更高要求，只有滿足這些要求，才可能去解鎖出更加復(fù)雜的記憶增強(qiáng)的 Agent，從而在企業(yè)場(chǎng)景中落地。

六、Q&A

Q1：請(qǐng)問(wèn) ColBERT 的收益圖中 Sparse Vector 和 BERT 分別是用的什么模型？

A1: Sparse Vector 用的是 BGE-M3。BGE-M3 是目前我們使用比較多的一種模型，它可以輸出向量、稀疏向量和張量。但張量輸出存在一些問(wèn)題，其張量達(dá)到了 1024 維，其實(shí)是完全沒(méi)有必要的，對(duì)于張量來(lái)說(shuō)，維度達(dá)到 128 就已經(jīng)足夠了。

BERT 的話，我們現(xiàn)在用的就是 ColBERT 模型，大家可以去 HuggingFace 下載。Jina-ColBERTv2 是 Jina 大概兩三周前剛剛開(kāi)源出來(lái)的模型，大家可以去嘗試一下，主要是其中文指標(biāo)，比 BGE-M3 還是要低不少，該模型有很大的改進(jìn)余地。

Q2：表格表示存儲(chǔ)的時(shí)候是用 HTML 嗎？這樣向量模型會(huì)因?yàn)樽畲箝L(zhǎng)度導(dǎo)致信息損失嗎？表格的問(wèn)答大模型，對(duì)于表格的數(shù)字不是太敏感，容易產(chǎn)生幻覺(jué)。

A2：表格我們現(xiàn)在其實(shí)是存兩塊：HTML 和向量。由于 HTML 用的是全文索引，所以表格更多的是以全文索引的方式去做召回，向量只是一種輔助。在企業(yè)里面如果不是用于多語(yǔ)言場(chǎng)景，基本上全文索引的權(quán)重會(huì)更高。

對(duì)于“大模型對(duì)于表格的數(shù)字不是太敏感，容易產(chǎn)生幻覺(jué)”，我們目前還是必須得依賴大模型，因?yàn)槲覀冊(cè)谝婚_(kāi)始的時(shí)候是把每個(gè)單元格變成一句話，這在表格絕對(duì)準(zhǔn)確的情況下的會(huì)更好。一旦單元格錯(cuò)了一個(gè)，可能就會(huì)導(dǎo)致整個(gè)的關(guān)系對(duì)齊都會(huì)出現(xiàn)錯(cuò)誤。所以有那么一兩個(gè)單元格識(shí)別的不夠準(zhǔn)，仍然有機(jī)會(huì)讓大模型去做挽回。未來(lái)希望表格模型能夠變得盡可能達(dá)到 100% 準(zhǔn)確，我們可能就又會(huì)回到把它變成一句話的方式。

Q3：請(qǐng)問(wèn)交叉編碼可以用 GPU 進(jìn)行加速嗎？

A3：可以；交叉編碼就用的 GPU。像大家用的 BGE 或者其它 MTEB 榜單的 Reranker 模型，基本上都是交叉編碼。這些模型基本上都是需要用 GPU 去跑的，否則性能很難忍受的?？赡芤粋€(gè)延遲就是幾秒、十幾秒，而 RAG 作為一個(gè)在線型應(yīng)用，對(duì)于延遲是比較敏感的。