檢索增強(qiáng)生成（RAG）已成為連接大語言模型與企業(yè)數(shù)據(jù)的標(biāo)準(zhǔn)范式，但該方法存在一個鮮少被討論的致命缺陷：當(dāng)前生產(chǎn)環(huán)境中的 RAG 系統(tǒng)幾乎全部依賴光學(xué)字符識別（OCR）技術(shù)處理 PDF、掃描件、演示文稿等文檔，并默認(rèn)假設(shè)識別結(jié)果足以支撐下游 AI 任務(wù)。

我們的深度分析表明，這一假設(shè)存在根本性缺陷。OCR 的識別質(zhì)量形成了一個隱形的天花板，甚至限制了最先進(jìn) RAG 系統(tǒng)的性能。理想的文本提?。╬erfect text extraction）所能達(dá)到的效果與當(dāng)前 OCR 技術(shù)所能達(dá)到的效果之間的差距，是當(dāng)今企業(yè)級 AI 領(lǐng)域最重大卻被忽視的挑戰(zhàn)之一。

TLDR：

• OCR 帶來了一個隱形的性能天花板。文本提取誤差極大地制約了 RAG 系統(tǒng)的檢索精度與生成質(zhì)量。
• 在基準(zhǔn)測試上表現(xiàn)出了巨大的差距。即便是頂尖的 OCR 解決方案，較理想的文本提取的性能仍存在約 4.5% 的差距（使用 NDCG@5 指標(biāo)評估），尤其是在復(fù)雜版式的文檔上。
• 純視覺生成方案尚未成熟。盡管多模態(tài)模型進(jìn)步很快，但仍無法可靠地從多個文檔圖像中生成精準(zhǔn)答案。
• 多模態(tài)檢索（Multimodal retrieval）超越了理想的 OCR 文本提取。我們的向量數(shù)據(jù)庫在檢索精度（使用 NDCG@5 指標(biāo)評估）上較理想的 OCR 文本提取提升性能約 12%，可挽回 70% 因 OCR 錯誤損失的生成質(zhì)量，同時還能簡化系統(tǒng)架構(gòu)并增強(qiáng)未來的兼容性。

1.為何 OCR 仍是 AI 系統(tǒng)的關(guān)鍵環(huán)節(jié)

企業(yè)的內(nèi)部核心知識大多封存在 PDF、掃描文檔、發(fā)票、演示文稿、圖像等非結(jié)構(gòu)化格式中。大語言模型（LLM）要處理這些知識，必須先將可視化的或半結(jié)構(gòu)化的原始格式轉(zhuǎn)化為純文本。

這一文本轉(zhuǎn)換環(huán)節(jié)通常由 OCR 引擎主導(dǎo)，它直接影響 RAG 系統(tǒng)的兩大核心組件：

1.1 檢索系統(tǒng)（The Retrieval System）

大多數(shù)檢索系統(tǒng)依賴提取的文本作為主要搜索依據(jù)。當(dāng) OCR 質(zhì)量低下時，生成的文本表征會出現(xiàn)偏差或“失真”。這會導(dǎo)致文本表征存在錯誤，從而使檢索系統(tǒng)在用戶提問時難以或無法找到相關(guān)文檔。若文本無法準(zhǔn)確反映內(nèi)容，搜索甚至還沒開始就已經(jīng)失敗了。

1.2 生成模型（LLM）

大語言模型僅能基于給定的上下文生成答案。若檢索到的文檔片段存在 OCR 錯誤（缺詞漏字、表格錯位、數(shù)字失真），LLM 接收到的信息就會有缺陷。即便檢索系統(tǒng)成功定位到了正確的文檔頁，最終仍會產(chǎn)生信息殘缺、邏輯混亂或事實錯誤的回答。

簡言之，OCR 產(chǎn)生的錯誤絕非止步于文本層面，而是會貫穿整個 RAG 流程 —— 既影響信息檢索的能力，又破壞答案生成的準(zhǔn)確性。

2.OCR 性能測試：基準(zhǔn)實驗設(shè)計方法論

為了量化 OCR 技術(shù)的“性能天花板”并評估其對實際應(yīng)用的影響，我們需要一種可靠的評測方法，以衡量其在各種具有挑戰(zhàn)性的文檔上的表現(xiàn)。為此，我們基于 OHR（OCR hinders RAG） v2 基準(zhǔn)測試[1]展開了全面實驗。

該基準(zhǔn)測試專為評估 OCR 性能對 RAG 任務(wù)的影響而設(shè)計，主要包含以下核心模塊：

• 多樣化的、有挑戰(zhàn)性的文檔庫：精選 8500 余頁 PDF 文檔，覆蓋教材、法律文書、金融報表、報刊雜志、技術(shù)手冊、學(xué)術(shù)論文及行政公文七大專業(yè)領(lǐng)域。這些文檔普遍包含復(fù)雜版式、數(shù)據(jù)表格、數(shù)學(xué)公式、統(tǒng)計圖表、技術(shù)圖解及非常規(guī)閱讀順序等 OCR 系統(tǒng)公認(rèn)的識別難點。
• 有針對性的問題：針對文檔特性構(gòu)建的 8498 組問答對，專門用于測試上述 OCR 難點信息相關(guān)的檢索與理解能力。每組答案均嚴(yán)格對應(yīng)文檔中的具體頁面，確保評估結(jié)果可驗證、可追溯。
• 經(jīng)過驗證的問題答案：經(jīng)過人工校驗過的理想的文本抽取結(jié)果與精心標(biāo)注的答案集，為比較、評估提供了可靠的“gold standard”。

根據(jù)這一基準(zhǔn)測試，我們評估了一系列 OCR 和檢索方法：

• Gemini 2.5 Flash[2]：前沿的閉源多模態(tài)模型（具備 OCR 功能）
• MinerU[3]：集成學(xué)術(shù)界先進(jìn) OCR 方法的開源工具庫
• Azure Document Intelligence[4]：行業(yè)主流的商業(yè) OCR 解決方案
• Qwen-2.5-VL[5]：前沿的開源多模態(tài)模型（具備 OCR 功能）
• Unstructured[6]：高市占率的開源文檔解析工具庫
• Mixedbread 多模態(tài)向量數(shù)據(jù)庫[7]：基于自研多模態(tài)模型 mxbai-omni-v0.1 實現(xiàn)原生的多模態(tài)檢索（直接處理頁面圖像而非依賴 OCR 文本），繞過了傳統(tǒng)檢索對 OCR 的依賴

這一完整的實驗框架使我們能夠隔離不同 OCR 方法質(zhì)量的影響，并將傳統(tǒng)基于文本的檢索方法與我們的多模態(tài)檢索系統(tǒng)進(jìn)行直接性能對比。

3.檢索環(huán)節(jié)的測試方法與實驗結(jié)果

我們首先聚焦檢索環(huán)節(jié) —— 即在海量文檔中精準(zhǔn)定位目標(biāo)信息的能力。若 RAG 系統(tǒng)無法精準(zhǔn)定位相關(guān)文檔，大語言模型就沒有機(jī)會準(zhǔn)確回答問題。

3.1 檢索環(huán)節(jié)的實驗設(shè)計

我們將 OHR 基準(zhǔn)測試的問答對（question-answer pairs）轉(zhuǎn)化為檢索任務(wù)：將提問作為查詢指令（query），相關(guān)的證據(jù)頁面（evidence pages）則是要檢索的目標(biāo)文檔。

傳統(tǒng)的基于文本的 OCR 方法采用 BM25 算法[8]（這是一種基于關(guān)鍵詞權(quán)重的經(jīng)典檢索算法，廣泛用于搜索引擎）。（我們也嘗試了基于嵌入向量的檢索與重排序方案，但發(fā)現(xiàn) OCR 噪聲會污染語義嵌入的質(zhì)量，導(dǎo)致其性能反而不如 BM25 的基準(zhǔn)方案，詳細(xì)分析參見此技術(shù)文檔[9]。）

Mixedbread 多模態(tài)向量數(shù)據(jù)庫調(diào)用自研的 mxbai-omni-v0.1 多模態(tài)嵌入模型，直接處理文檔頁面截圖。這種方法能夠感知頁面布局、結(jié)構(gòu)特征與可視化元素，本質(zhì)上具備抵御 OCR 錯誤干擾的能力。

我們使用兩項標(biāo)準(zhǔn)指標(biāo)來衡量檢索性能：

• NDCG@5（Normalized Discounted Cumulative Gain @ 5）：評估前 5 位檢索結(jié)果的質(zhì)量，既考察正確的文檔是否被檢出，還關(guān)注這些文檔的排名高低 —— 排名越靠前的相關(guān)文檔得分越高。選定 K=5 的依據(jù)在于：研究表明大語言模型對上下文窗口中的文檔順序極為敏感，排名靠前的文檔對其決策影響更大。
• Recall@5：這個指標(biāo)衡量的是前 5 個結(jié)果中是否至少檢索到了一個正確的證據(jù)頁面（evidence pages）。該指標(biāo)反映系統(tǒng)能否檢索到必要的信息，而不管其具體排名如何。

3.2 對檢索環(huán)節(jié)的評估結(jié)果顯示：OCR 的性能天花板確實存在

我們對檢索環(huán)節(jié)的基準(zhǔn)測試清晰地展現(xiàn)了傳統(tǒng)依賴 OCR 的方法與多模態(tài)方案之間的顯著差異。

NDCG@5 指標(biāo)表現(xiàn)（在七大文檔領(lǐng)域上的平均值）

image.png

本圖表展示各檢索方法在七大文檔領(lǐng)域的平均 NDCG@5 得分。該指標(biāo)同時考量前 5 位檢索結(jié)果中相關(guān)文檔的存在情況及排序質(zhì)量 —— 數(shù)值越高代表檢索越準(zhǔn)確，其中排名靠前的相關(guān)頁面的權(quán)重也越高。

圖片

Recall@5 指標(biāo)表現(xiàn)（在七大文檔領(lǐng)域上的平均值）

圖片

本圖表顯示了各方法在七大文檔領(lǐng)域測試中的平均 Recall@5 值。該指標(biāo)反映了前 5 位檢索結(jié)果中出現(xiàn)至少一個正確的證據(jù)頁面的提問占比 —— 數(shù)值越高代表系統(tǒng)性能越佳。

1748586968948.jpg

這些實驗結(jié)果揭示了幾個重要的觀點：

• OCR 形成了“性能天花板”：所有被測 OCR 方案均落后于基準(zhǔn)值。最優(yōu) OCR 方案的 NDCG@5 指標(biāo)平均值僅為 0.74，與基準(zhǔn)值 0.773 存在 4.5% 的絕對差距，這證實了 OCR 誤差從本質(zhì)上限制了檢索效率。
• 文檔的復(fù)雜度放大了 OCR 方案存在的問題：在 finance、textbooks、news 等布局復(fù)雜的文檔領(lǐng)域，性能差距進(jìn)一步擴(kuò)大。表格、數(shù)學(xué)公式、多欄文本等元素大大加劇 OCR 的識別難度。
• 多模態(tài)系統(tǒng)通過視覺-文本聯(lián)合理解實現(xiàn)性能突破：Mixedbread Vector Store 的性能始終優(yōu)于其他傳統(tǒng)方案，它的 NDCG@5 平均值為 0.865（較基準(zhǔn)方法提升了近 12%），因為它能通過直接解析頁面圖像中的版式結(jié)構(gòu)、表格圖表等視覺信息，獲取更豐富的語義關(guān)聯(lián)線索。

在基準(zhǔn)文本上，使用 Mixedbread Vector Store，Recall@5 指標(biāo)從基準(zhǔn)方法的 0.84 躍升至 0.92，具體表現(xiàn)為：

• 基準(zhǔn)方法（perfect OCR）：Recall@5=84% → 每 100 份相關(guān)文檔中，有 84 份被檢索到，且排在前 5 位。
• 多模態(tài)方案（Mixedbread Vector Store）：Recall@5=92% → 每 100 份相關(guān)文檔中，有 92 份進(jìn)入了前 5 名。

該指標(biāo)實現(xiàn)了 8% 的絕對提升（相對提升達(dá) 9.5%），這意味著檢索性能的大幅提高。本組基準(zhǔn)測試量化了單純依賴 OCR 技術(shù)所帶來的性能瓶頸。雖然更好的 OCR 有所幫助，但多模態(tài)路徑才是實現(xiàn)檢索能力飛躍的根本方向。

4.生成環(huán)節(jié)的測試方法與實驗結(jié)果

現(xiàn)在好了，多模態(tài)檢索能夠找到更優(yōu)的文檔，從而突破了 OCR 的性能上限。但這種檢索效果的提升，是否真能讓大模型給出更準(zhǔn)確的最終答案呢？為了找出答案，我們測試了端到端的 RAG 的性能。

4.1 生成環(huán)節(jié)的試驗設(shè)置

我們設(shè)置了三種場景，將每種場景檢索到的前 5 篇文檔輸入同一個強(qiáng)大的 LLM（gemini-2.5-flash-preview-04-17）進(jìn)行答案生成：

1）Perfect OCR & Perfect Retrieval (Ground Truth)：使用經(jīng)過人工驗證的文本進(jìn)行生成，并將真實的證據(jù)頁面（evidence pages）作為輸入（也就是所謂的“Perfect Retrieval”）。這代表了在擁有正確上下文和理想的文本提取能力的情況下，當(dāng)前模型可達(dá)到的理論最高性能。

2）Perfect OCR & Retrieval：在 BM25 檢索、Top 5 文本片段選取及生成階段均采用經(jīng)過人工校驗的文本。這代表了在 OCR 處于理想情況下，系統(tǒng)所能提供的理想質(zhì)量。

3）Mixedbread OCR（基于文本的 RAG）：在 BM25 檢索（獲取前 5 個文本片段）和生成上下文環(huán)節(jié)中，均采用我們高質(zhì)量 OCR 引擎提取的文本。這就模擬了一個標(biāo)準(zhǔn)的、高質(zhì)量的純文本 RAG 流程。

4）Mixedbread Vector Store（多模態(tài)檢索）：使用我們的多模態(tài)模型檢索前 5 頁的圖像，但隨后使用 Mixedbread OCR 提取的對應(yīng)干凈文本作為生成上下文。這種做法既保留了視覺檢索的優(yōu)勢，又能確保生成環(huán)節(jié)的輸入模態(tài)（文本）保持一致。

為評估效果，我們主要關(guān)注"正確答案率"指標(biāo)。具體做法是：以 GPT-4.1 作為中立裁判，向其提供原始問題、標(biāo)準(zhǔn)答案、標(biāo)準(zhǔn)證據(jù)文本，以及 gemini-2.5-flash-preview-04-17 在各測試場景下生成的答案。最終得分按"正確回答數(shù)除以總問題數(shù)"的簡單公式計算。

4.2 對生成環(huán)節(jié)的評估結(jié)果顯示：檢索質(zhì)量提升 = 答案準(zhǔn)確率提高

對生成環(huán)節(jié)的測試驗證了我們的假設(shè)：更優(yōu)質(zhì)的檢索能直接帶來更準(zhǔn)確的答案。

正確答案率

image.png

本圖表展示了每種生成方法的正確答案占比（基于7個領(lǐng)域的平均值，由 GPT-4.1 評判）。數(shù)值越高，表明大模型生成的答案越準(zhǔn)確，越接近正確答案（ground-truth）。

1748587243677.jpg

這些實驗結(jié)果揭示了幾個重要的觀點：

• OCR 的缺陷在生成階段被放大：與使用 perfect text（0.913 的基準(zhǔn)值）相比，依靠標(biāo)準(zhǔn) OCR 技術(shù)進(jìn)行檢索和生成會導(dǎo)致正確答案減少 25.8%（0.677）。錯誤的輸入上下文大大降低了 LLM 生成準(zhǔn)確答案的能力。
• 優(yōu)質(zhì)的檢索能夠大幅提升準(zhǔn)確率：僅將標(biāo)準(zhǔn)的使用 OCR 技術(shù)的檢索過程替換為使用 Mixedbread 向量數(shù)據(jù)庫的多模態(tài)檢索（生成環(huán)節(jié)仍使用相同的存在潛在缺陷的 OCR 文本），平均正確答案率即從 0.677 躍升至 0.843。僅此一項改進(jìn)，就挽回了標(biāo)準(zhǔn) OCR 流程 70% 的準(zhǔn)確率損失。
• 找到正確的文檔頁面至關(guān)重要：在生成過程中，檢索質(zhì)量往往比所提取文本的完美程度更關(guān)鍵。即便存在輕微的 OCR 提取缺陷，讓大模型獲取到正確文檔的收益，遠(yuǎn)高于提供錯誤文檔中稍干凈的文本。

這些生成環(huán)節(jié)的測試證明，最先進(jìn)的多模態(tài)檢索技術(shù)能有效抵消 OCR 過程中產(chǎn)生的錯誤對下游任務(wù)的大部分負(fù)面影響。

5.Direct Image Generation：僅依賴視覺的 RAG 系統(tǒng)是否可行？

視覺信息在檢索階段的成功引發(fā)了一個關(guān)鍵問題：能否在生成階段完全跳過 OCR？若將檢索到的頁面圖像直接輸入 Gemini 2.5 Flash 等多模態(tài)大語言模型，并讓其通過“閱讀”圖像生成答案，效果會如何？我們測試了這種“端到端圖像理解”的方案：

正確答案率（在三大文檔領(lǐng)域上的平均值）

1748587361949.jpg

1748587445380.jpg

這些實驗結(jié)果揭示了三個重要的觀點：

• 純圖像輸入方案的表現(xiàn)欠佳：直接向大語言模型輸入頁面圖像進(jìn)行生成時，平均正確率最低（0.627）
• Visual Retrieval vs. Visual Generation：多模態(tài)模型擅長利用視覺線索進(jìn)行檢索，但在生成環(huán)節(jié)直接從多個文檔圖像中提取細(xì)節(jié)信息的能力，仍顯著弱于處理預(yù)處理文本
• 高質(zhì)量的 OCR 文本仍然是生成環(huán)節(jié)的最佳選擇（現(xiàn)階段）：目前，向 LLM 提供干凈、清晰的文本可以得到最準(zhǔn)確的答案。

結(jié)論：雖然僅依賴視覺的 RAG 系統(tǒng)充滿想象空間，但現(xiàn)階段通過多模態(tài)檢索獲取文檔，再結(jié)合高質(zhì)量的 OCR 文本進(jìn)行生成，仍是綜合性能最優(yōu)的解決方案。

6.典型案例：標(biāo)準(zhǔn) OCR 的失效場景

為使 OCR 技術(shù)局限性的影響具象化，我們將基于基準(zhǔn)數(shù)據(jù)剖析幾個典型場景。這些案例既揭示了基于 OCR 的傳統(tǒng)系統(tǒng)的常見失效場景，也論證了多模態(tài)檢索方法如何實現(xiàn)更精準(zhǔn)的文檔解析。

6.1 案例1：Regulatory Filings 中手寫數(shù)據(jù)的挑戰(zhàn)

場景特征：以電信公司提交的 PUCO 年度報告為例，此類 Regulatory filings（譯者注：企業(yè)/機(jī)構(gòu)依法向監(jiān)管部門提交的標(biāo)準(zhǔn)化文件）通常將結(jié)構(gòu)化的打印內(nèi)容與關(guān)鍵的手寫財務(wù)數(shù)據(jù)混合排版在一起。這種混合內(nèi)容對傳統(tǒng) OCR 系統(tǒng)構(gòu)成了嚴(yán)峻的挑戰(zhàn) —— 手寫內(nèi)容常被錯誤識別，可能導(dǎo)致合規(guī)風(fēng)險與數(shù)據(jù)分析結(jié)果偏離。

image.png

典型的 OCR 輸出及其局限性

當(dāng)采用標(biāo)準(zhǔn)的 OCR 引擎處理此類文件時，關(guān)鍵的手寫財務(wù)數(shù)據(jù)往往會完全丟失或被錯誤解析：

圖片

對 RAG 系統(tǒng)的影響：當(dāng)用戶提出類似“TSC Communications 的總營收是多少？”的查詢（query）時，依賴此類有缺陷的 OCR 輸出的 RAG 系統(tǒng)可能返回："無法從當(dāng)前文檔獲取營收數(shù)據(jù)"。這種情況將迫使人工介入審核，嚴(yán)重延誤監(jiān)管報送與決策分析。

多模態(tài)解決方案：相比之下，多模態(tài)系統(tǒng)通過分析文檔的視覺布局與筆跡特征，可同步解析結(jié)構(gòu)化表格與手寫財務(wù)數(shù)據(jù)。這種全局理解能力使其能夠準(zhǔn)確識別出總營收為 2,775,060 美元（其中運營收入 2,325,472 美元，其他收入 449,588 美元），從而生成關(guān)于公司財務(wù)狀況及監(jiān)管義務(wù)的精準(zhǔn)自動化響應(yīng)。

6.2 案例 2：如何從金融圖表中提取趨勢信息

情景概述：在季度投資分析報告中，常運用堆疊面積圖等可視化工具呈現(xiàn)資產(chǎn)配置變化。傳統(tǒng) OCR 技術(shù)在此場景下僅能識別表層文本信息（如標(biāo)題、圖例標(biāo)注），卻無法捕捉承載核心趨勢的可視化數(shù)據(jù)。

image.png

傳統(tǒng) OCR 技術(shù)的輸出及其局限性

標(biāo)準(zhǔn) OCR 工具可能只會提取標(biāo)簽和標(biāo)題，而忽略了核心數(shù)據(jù)：

Portfolio Allocation Trends (Q1 2023 - Q4 2024)

Percentage (%)

100

75

50

25

0

Q1 2023, Q2 2023, Q3 2023, Q4 2023, Q1 2024, Q2 2024, Q3 2024, Q4 2024

Cash, Commodities,Real Estate,Fixed Income, Equities

對 RAG 系統(tǒng)的影響：當(dāng)客戶咨詢"我的權(quán)益類資產(chǎn)占比過去一年如何變化？"時，基于傳統(tǒng) OCR 輸出的 RAG 系統(tǒng)只能提供有關(guān)投資組合組成部分的一般信息，完全無法解讀圖表中揭示的關(guān)鍵趨勢 —— 例如權(quán)益類資產(chǎn)配置有 13 個百分點的增幅，而這正是評估投資風(fēng)險的核心依據(jù)。

多模態(tài)解決方案：多模態(tài)系統(tǒng)通過直接對圖表進(jìn)行直觀分析，既能識別每個時間點的配置比例，也能識別整體趨勢模式。這樣，它就能準(zhǔn)確地做出反應(yīng)："您的權(quán)益類資產(chǎn)配置在過去的一年內(nèi)從 45% 攀升至 58%，這是您的投資組合構(gòu)成中最大的變化。" 系統(tǒng)甚至可以提取特定季度的數(shù)據(jù)來補充說明這一情況。

6.3 示例 3：復(fù)雜財務(wù)報表的精準(zhǔn)解析

情景描述：財務(wù)報表中常包含多欄表格，詳細(xì)列出收入明細(xì)與運營開支。使用 OCR 對此類復(fù)雜表格結(jié)構(gòu)進(jìn)行識別，其難點在于保持行與列的正確對齊 —— 當(dāng)表格識別出現(xiàn)對齊錯誤時，會導(dǎo)致財務(wù)數(shù)據(jù)被錯誤歸類（例如將"研發(fā)支出"的數(shù)值誤關(guān)聯(lián)到"市場營銷"下）

image.png

傳統(tǒng) OCR 技術(shù)的輸出及其局限性

即便文字內(nèi)容被提取，OCR 的細(xì)微對齊錯誤或解析錯誤仍會破壞表格結(jié)構(gòu)：

圖片

對 RAG 系統(tǒng)的影響：當(dāng)財務(wù)分析師詢問"2025 年研發(fā)支出占收入的比例相較 2024 年有何變化？"時，基于 OCR 識別出的錯誤表格結(jié)構(gòu)數(shù)據(jù)的 RAG 系統(tǒng)可能曲解數(shù)據(jù)之間的關(guān)系，產(chǎn)生諸如"2025 年研發(fā)占比 49%，而 2024 年高達(dá) 8,675%"的荒謬回答。這類錯誤源于系統(tǒng)無法正確理解表格的視覺結(jié)構(gòu)與語義邏輯。

多模態(tài)解決方案：通過分析表格的視覺結(jié)構(gòu)，系統(tǒng)能準(zhǔn)確識別標(biāo)題、金額與百分比數(shù)字之間的復(fù)雜對應(yīng)關(guān)系。這樣就能做出準(zhǔn)確的答復(fù)："盡管研發(fā)支出絕對值增長了 49%，但其占凈收入的比例從 2024 年的 14.2% 下降至 2025 年的 9.9%。"系統(tǒng)可以同時把握財務(wù)數(shù)據(jù)的空間布局與語義關(guān)聯(lián)。

7.Mixedbread Vector Store 所使用技術(shù)方案的核心功能與實施價值

該向量數(shù)據(jù)庫專為解決 OCR 依賴型 RAG 系統(tǒng)的固有缺陷而設(shè)計，其核心架構(gòu)基于 mxbai-omni-v0.1 多模態(tài)模型實現(xiàn)跨模態(tài)信息檢索。該模型可直接分析文檔頁面截圖、視頻等原始視覺內(nèi)容并生成嵌入向量，從而在其原始上下文中理解布局、結(jié)構(gòu)、表格和圖表?；鶞?zhǔn)測試表明，相較理想的文本提取方案（perfect text extraction），該方案將檢索準(zhǔn)確率（NDCG@5）提升約 12 個百分點。

系統(tǒng)在進(jìn)行視覺分析的同時，通過 OCR 引擎并行處理文本內(nèi)容。提取的文本數(shù)據(jù)將與視覺嵌入向量同步存儲，形成雙模態(tài)協(xié)同優(yōu)勢：

• 增強(qiáng)檢索能力：當(dāng)純文本檢索因 OCR 錯誤或特殊內(nèi)容（如圖表、復(fù)雜表格）失效時，視覺分析能精準(zhǔn)定位相關(guān)文檔
• 優(yōu)化生成上下文：保留高質(zhì)量 OCR 文本，適配當(dāng)前以文本輸入為主的大語言模型生成需求
• 自動化文檔處理：系統(tǒng)自動完成視覺嵌入與文本提取，用戶無需干預(yù)數(shù)據(jù)預(yù)處理流程
• 對未來 LLM 的適配：同步存儲視覺表征與文本數(shù)據(jù)，為未來多模態(tài) LLM 直接利用圖像信息生成內(nèi)容做好技術(shù)儲備

這種一體化設(shè)計方案能夠大大提升 RAG 系統(tǒng)的綜合性能：基準(zhǔn)測試顯示這種技術(shù)路線不僅能夠?qū)崿F(xiàn)檢索效率的大幅提升，更在統(tǒng)一框架內(nèi)挽回傳統(tǒng)流程因 OCR 問題損失的 70% 生成準(zhǔn)確率。

8、結(jié)論：利用多模態(tài)檢索突破 OCR 的性能瓶頸

基準(zhǔn)測試數(shù)據(jù)表明，光學(xué)字符識別（OCR）的質(zhì)量是制約 RAG 系統(tǒng)性能的核心瓶頸，尤其是在處理復(fù)雜的現(xiàn)實世界文檔時。文本提取過程中的錯誤與遺漏不僅會限制準(zhǔn)確檢索相關(guān)信息的能力，更會直接影響大語言模型生成最終答案的質(zhì)量。

將多模態(tài)分析納入檢索流程的策略（如 Mixedbread Vector Store 技術(shù)方案）可解決其中的部分限制。通過直接解析頁面圖像的視覺語義，這種方法在測試中相較理想的文本提取基準(zhǔn)方法提升 12% 檢索準(zhǔn)確率（NDCG@5）。檢索性能的提升，使傳統(tǒng)流程因 OCR 錯誤損失的 70% 的生成準(zhǔn)確率得以恢復(fù)。

雖然現(xiàn)階段大語言模型在答案生成環(huán)節(jié)仍依賴高質(zhì)量文本輸入，但多模態(tài)系統(tǒng)展現(xiàn)的強(qiáng)大檢索能力為文檔理解開辟了一條較為有效的技術(shù)路徑。同時集成視覺驅(qū)動檢索與高質(zhì)量 OCR 文本的 RAG 系統(tǒng)，不僅為當(dāng)前實際應(yīng)用需求提供了有效的解決方案，更為未來大語言模型直接利用圖像數(shù)據(jù)進(jìn)行生成任務(wù)奠定了基礎(chǔ)。

本研究證實：在處理多樣化、結(jié)構(gòu)復(fù)雜的文檔場景時，將多模態(tài)理解能力融入檢索流程是提升 RAG 系統(tǒng)準(zhǔn)確性與可靠性的關(guān)鍵考慮因素。

文中鏈接

[1]https://arxiv.org/abs/2412.02592

[2]https://ai.google.dev/gemini-api/docs/models

[3]https://github.com/opendatalab/MinerU

[4]https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/overview?view=doc-intel-4.0.0

[5]https://github.com/QwenLM/Qwen-VL

[6]https://github.com/Unstructured-IO/unstructured

[7]https://www.mixedbread.com/docs/vector-store

[8]https://en.wikipedia.org/wiki/Okapi_BM25

[9]https://docs.google.com/spreadsheets/d/1zBGOIOCzZZjw1HXBGGI8BzNx_kYj34LlYaFteZTU7Bg/edit?usp=sharing