一、RAG1.0 的痛點和解決方向

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

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

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

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

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

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

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

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

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

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

4. Infiniflow

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

二、如何有效 Chunking

1. Chunking 的流程

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

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

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

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

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

3. 表格識別模型

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

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

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

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

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

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

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

4. 文檔“大”模型

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

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

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

1. Indexing Database

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

2. Benchmark

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

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

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

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

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

4. 幾路召回？

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

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

5. 排序模型

第二個問題是張量究竟是怎么回事兒？

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

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

6. ColBERT 的收益

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

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

7. ColBERT 的收益

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

8. ColBERT ranker 還是 reranker

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

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

9. 延遲交互是 RAG 的未來

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

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

10. 延遲交互是 RAG 的未來

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

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

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

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

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

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

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

3. 復(fù)雜問答之知識圖譜

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

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

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

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

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

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

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

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

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

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

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

3. 記憶增強的 Agent

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

六、Q&A

Q1：請問 ColBERT 的收益圖中 Sparse Vector 和 BERT 分別是用的什么模型？

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

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

Q2：表格表示存儲的時候是用 HTML 嗎？這樣向量模型會因為最大長度導(dǎo)致信息損失嗎？表格的問答大模型，對于表格的數(shù)字不是太敏感，容易產(chǎn)生幻覺。

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

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

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

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