1. 為什么圖文與 PDF 解析是 RAG 落地的第一道生死關(guān)做過 RAG 項(xiàng)目的人都有一個(gè)共同體會(huì)模型選型、向量庫調(diào)優(yōu)、檢索策略這些看起來高級(jí)的環(huán)節(jié)往往不是最耗時(shí)間的。真正讓人熬夜的是數(shù)據(jù)導(dǎo)入和解析這一段——尤其是當(dāng)你的知識(shí)庫里混著掃描件、截圖、帶復(fù)雜表格的 PDF、雙欄排版的論文、甚至手機(jī)拍的合同照片時(shí)。我在過去兩年里幫團(tuán)隊(duì)搭過好幾個(gè) RAG 知識(shí)庫從最開始的純文本 Markdown 一把梭到后來不得不面對(duì)一堆 PDF 和圖片踩的坑足夠?qū)懸槐緯?。這一篇就專門聊圖文與 PDF 解析這條鏈路OCR 怎么選、多模態(tài)大模型在什么場(chǎng)景下值得上、九種主流 PDF 解析工具各自適合什么活。核心關(guān)鍵詞 RAG、OCR、多模態(tài)大模型、PDF、工具選型會(huì)貫穿全文我會(huì)盡量把每個(gè)選擇的為什么講清楚而不是甩一張對(duì)比表就完事。先說清楚這篇適合誰看如果你正在搭 RAG 知識(shí)庫手里有一批 PDF 和圖片要處理或者你已經(jīng)跑通了純文本流程現(xiàn)在卡在掃描件識(shí)別不準(zhǔn)表格全亂公式丟失這些問題上再或者你在做技術(shù)選型想知道什么場(chǎng)景該用傳統(tǒng) OCR、什么場(chǎng)景該上多模態(tài)大模型——那這篇就是給你寫的。全文基于我自己的實(shí)操經(jīng)驗(yàn)參數(shù)和步驟都可以直接抄作業(yè)但請(qǐng)結(jié)合你的數(shù)據(jù)特點(diǎn)做調(diào)整。2. RAG 數(shù)據(jù)導(dǎo)入的整體設(shè)計(jì)與解析鏈路拆解2.1 一條完整的解析鏈路長(zhǎng)什么樣很多人一上來就問用哪個(gè) PDF 工具最好這個(gè)問題本身就問錯(cuò)了。PDF 解析從來不是單點(diǎn)工具的事而是一條鏈路。我習(xí)慣把它拆成五段格式探測(cè)先判斷這個(gè)文件是原生電子 PDF還是掃描件/圖片 PDF。這一步?jīng)Q定了后面走哪條路。原生 PDF 里文字是可提取的掃描件里文字是像素必須 OCR。版面分析識(shí)別出標(biāo)題、正文、表格、圖片、頁眉頁腳、腳注、雙欄結(jié)構(gòu)。這一步做不好后面提取出來的文字順序就是亂的。內(nèi)容提取文字走文本層或 OCR表格走表格識(shí)別圖片走圖像描述或直接存圖。結(jié)構(gòu)化重組把提取出來的碎片按閱讀順序拼回有語義的塊chunk保留層級(jí)關(guān)系。元數(shù)據(jù)標(biāo)注給每個(gè) chunk 打上來源、頁碼、章節(jié)、類型正文/表格/圖注等標(biāo)簽方便檢索時(shí)過濾和溯源。這五段里第一段和第二段是最容易被忽略、卻最影響最終效果的。我見過太多人直接拿 PyPDF2 把文字抽出來就丟進(jìn)向量庫結(jié)果檢索出來的內(nèi)容順序錯(cuò)亂、表格串行模型答非所問然后回頭怪 embedding 模型不行。2.2 為什么解析質(zhì)量直接決定 RAG 上限打個(gè)比方RAG 就像一個(gè)開卷考試的學(xué)生向量庫是他的參考書檢索是翻書生成是答題。如果參考書本身是錯(cuò)亂的、缺頁的、表格串行的那這個(gè)學(xué)生翻得再準(zhǔn)也答不對(duì)。解析就是編參考書的過程它決定了知識(shí)的上限。具體來說解析質(zhì)量影響三個(gè)環(huán)節(jié)切塊chunking如果解析出來的文字沒有正確的段落和標(biāo)題邊界切塊就會(huì)把一句話切成兩半或者把兩個(gè)不相關(guān)的段落塞進(jìn)一個(gè) chunk。檢索時(shí)要么召回不全要么召回噪聲。檢索命中表格如果被解析成一行行錯(cuò)位的文字用戶問某年某月的營(yíng)收是多少檢索根本匹配不到。生成溯源如果沒保留頁碼和章節(jié)元數(shù)據(jù)模型答完你沒法驗(yàn)證它是不是在胡說也沒法給用戶展示引用來源。所以我的原則是寧可解析慢一點(diǎn)、貴一點(diǎn)也要保證質(zhì)量。后面講工具選型時(shí)這個(gè)原則會(huì)反復(fù)出現(xiàn)。2.3 方案選型的三個(gè)核心權(quán)衡維度面對(duì)一堆工具怎么選我一般看三個(gè)維度維度說明影響文檔類型原生電子版 / 掃描件 / 混合決定是否需要 OCR內(nèi)容復(fù)雜度純文字 / 表格 / 公式 / 多欄 / 圖文混排決定是否需要版面分析和多模態(tài)成本與吞吐本地免費(fèi) / API 按量 / 自建 GPU決定長(zhǎng)期可行性這三個(gè)維度不是獨(dú)立的。比如你有一批掃描的財(cái)務(wù)報(bào)表那掃描件 復(fù)雜表格 大批量三個(gè)條件疊加基本就排除了純本地輕量方案要么上商用 OCR API要么自建帶表格識(shí)別的多模態(tài)管線。3. OCR 與多模態(tài)大模型到底該用哪個(gè)3.1 傳統(tǒng) OCR 的能力邊界在哪里傳統(tǒng) OCR比如 Tesseract、PaddleOCR、以及各家云廠商的通用 OCR本質(zhì)上是檢測(cè)文字框 識(shí)別字符兩階段。它在規(guī)整的印刷體、清晰掃描件上表現(xiàn)非常好速度快、成本低、可本地部署。但它的邊界也很明顯版面理解弱它告訴你這一塊是文字但不告訴你這是標(biāo)題還是正文這是表格的第幾行第幾列。表格識(shí)別需要額外的表格結(jié)構(gòu)識(shí)別模型。手寫體吃力印刷體識(shí)別率能到 99%手寫體可能掉到 70% 以下尤其是連筆。公式和特殊符號(hào)數(shù)學(xué)公式、化學(xué)結(jié)構(gòu)式基本無能為力。多語言混排中英混排還行但小語種、豎排文字容易翻車。我實(shí)測(cè)過某些 OCR 對(duì)韓文的識(shí)別直接返回空或者亂碼這種情況要么換模型要么換方案。所以傳統(tǒng) OCR 的定位很清楚大批量、規(guī)整、以純文字為主的掃描件它是性價(jià)比之王。3.2 多模態(tài)大模型補(bǔ)上了哪塊短板多模態(tài)大模型能同時(shí)理解圖像和文字的模型在解析場(chǎng)景里的價(jià)值不是識(shí)別得更準(zhǔn)而是理解得更深。它能把一張圖或一頁 PDF 直接看懂輸出結(jié)構(gòu)化的 Markdown包括正確的閱讀順序雙欄、多欄都能處理表格轉(zhuǎn)成 Markdown 表格公式轉(zhuǎn)成 LaTeX圖片生成描述文字甚至能理解圖表里的趨勢(shì)并寫成一句話我拿同一頁雙欄論文做過對(duì)比傳統(tǒng) OCR 輸出的是左右兩欄文字交錯(cuò)的一坨多模態(tài)模型直接輸出結(jié)構(gòu)清晰的 Markdown標(biāo)題、正文、公式、圖注各歸各位。這個(gè)差距在 RAG 場(chǎng)景里是決定性的。但多模態(tài)大模型也有代價(jià)成本高按 token 或按頁計(jì)費(fèi)大批量處理時(shí)賬單很嚇人。速度慢一頁可能要幾秒到幾十秒不適合實(shí)時(shí)。有幻覺風(fēng)險(xiǎn)它可能腦補(bǔ)出原文沒有的內(nèi)容尤其是模糊的掃描件。這點(diǎn)在 RAG 里很危險(xiǎn)因?yàn)殄e(cuò)誤內(nèi)容會(huì)被當(dāng)成事實(shí)檢索出來。3.3 混合策略什么場(chǎng)景用什么我的實(shí)操建議是分層處理而不是二選一第一層格式探測(cè)。原生電子 PDF 優(yōu)先走文本層提取根本不用 OCR又快又準(zhǔn)。第二層規(guī)整掃描件走傳統(tǒng) OCR。清晰、印刷體、純文字的用 PaddleOCR 或云 OCR 批量跑成本可控。第三層復(fù)雜版面/表格/公式走多模態(tài)。只把那些 OCR 搞不定的頁面挑出來送給多模態(tài)模型控制成本。第四層人工抽檢。對(duì)多模態(tài)輸出的結(jié)果做抽樣校驗(yàn)尤其是數(shù)字和金額防止幻覺。提示多模態(tài)模型輸出的內(nèi)容凡是涉及數(shù)字、金額、日期、專有名詞的務(wù)必做二次校驗(yàn)。我吃過虧模型把1,234識(shí)別成1,284檢索出來直接導(dǎo)致答錯(cuò)。3.4 一個(gè)容易被忽略的點(diǎn)圖片本身要不要入庫熱詞里有人問RAG 知識(shí)庫能存儲(chǔ)圖片嘛。答案是能但要分情況裝飾性圖片logo、背景圖直接丟棄別浪費(fèi)存儲(chǔ)和檢索額度。信息性圖片流程圖、架構(gòu)圖、截圖用多模態(tài)模型生成文字描述把描述入庫原圖存對(duì)象存儲(chǔ)chunk 里放圖片鏈接。這樣檢索時(shí)能命中描述展示時(shí)能調(diào)出原圖。圖表柱狀圖、折線圖讓多模態(tài)模型把數(shù)據(jù)點(diǎn)讀出來轉(zhuǎn)成表格比純描述有用得多。這個(gè)策略的核心是入庫的是可檢索的語義原圖只是附件。別指望向量庫直接檢索像素。4. 九種 PDF 解析工具選型實(shí)戰(zhàn)4.1 選型前先明確你的文檔畫像在列工具之前先做一件事抽樣 20 份文檔人工標(biāo)注它們的類型。統(tǒng)計(jì)一下原生電子版占比、掃描件占比、含表格占比、含公式占比、多欄占比。這個(gè)畫像直接決定選型。我見過團(tuán)隊(duì)上來就買最貴的商用方案結(jié)果發(fā)現(xiàn) 90% 的文檔是原生電子版用免費(fèi)庫就夠了純屬浪費(fèi)。4.2 九種工具逐一拆解下面這九種是我實(shí)際用過或深度評(píng)估過的按輕量到重量排序。1. PyPDF2 / pypdf最基礎(chǔ)的純 Python 庫只能提取原生 PDF 的文本層。優(yōu)點(diǎn)是零依賴、快缺點(diǎn)是遇到掃描件直接返回空版面信息基本沒有表格會(huì)串行。適合做格式探測(cè)的第一道篩子不適合做主力解析。2. pdfplumber同樣是 Python 庫但比 PyPDF2 強(qiáng)在能提取表格和字符坐標(biāo)。它的表格提取基于線條和文字位置對(duì)規(guī)整表格效果不錯(cuò)。缺點(diǎn)是速度慢復(fù)雜表格容易漏。適合原生電子版、表格結(jié)構(gòu)規(guī)整的場(chǎng)景。3. PyMuPDFfitz速度和功能平衡得最好的本地庫。文本、圖片、坐標(biāo)、頁面渲染都能做還能把 PDF 頁渲染成圖片喂給 OCR 或多模態(tài)模型。我?guī)缀趺總€(gè)項(xiàng)目都會(huì)裝它作為萬能工具。缺點(diǎn)是表格結(jié)構(gòu)識(shí)別需要自己寫邏輯。4. pdfminer.six老牌庫文本提取的精細(xì)度高能拿到每個(gè)字符的位置和字體信息。適合需要深度分析版面的場(chǎng)景但 API 比較難用速度也一般。新手不太推薦直接上手。5. Tesseract老牌開源 OCR 引擎支持多語言。優(yōu)點(diǎn)是免費(fèi)、可本地、社區(qū)大缺點(diǎn)是中文識(shí)別率一般版面分析弱需要配合預(yù)處理去噪、糾偏、二值化才能出好效果。適合預(yù)算為零、文檔規(guī)整的個(gè)人項(xiàng)目。6. PaddleOCR國(guó)產(chǎn)開源 OCR中文識(shí)別率明顯優(yōu)于 Tesseract自帶版面分析和表格識(shí)別模塊。我實(shí)測(cè)下來規(guī)整的中文掃描件識(shí)別率能到 95% 以上。缺點(diǎn)是部署稍重需要裝 PaddlePaddle。適合中文為主、需要本地部署的場(chǎng)景。7. 云廠商通用 OCR API各家云都有通用 OCR 和文檔解析服務(wù)識(shí)別率高、支持表格和版面、按量計(jì)費(fèi)。優(yōu)點(diǎn)是省心、準(zhǔn)缺點(diǎn)是數(shù)據(jù)要出本地、長(zhǎng)期成本高、有并發(fā)限制。適合對(duì)準(zhǔn)確率要求高、數(shù)據(jù)敏感度低、批量不算特別大的場(chǎng)景。8. 商用文檔解析 API專門做 PDF 結(jié)構(gòu)化的這類服務(wù)專門針對(duì)復(fù)雜 PDF能輸出結(jié)構(gòu)化 Markdown表格、公式、多欄都處理得不錯(cuò)。適合金融、法律這類對(duì)結(jié)構(gòu)要求極高的行業(yè)。成本最高但省下的開發(fā)時(shí)間往往值這個(gè)價(jià)。9. 多模態(tài)大模型 API前面講過適合復(fù)雜版面、表格、公式、圖文混排。用法是把 PDF 頁渲染成圖片直接丟給模型讓它輸出 Markdown。適合作為兜底方案處理其他工具搞不定的硬骨頭。4.3 工具選型對(duì)照表工具類型中文效果表格版面成本推薦場(chǎng)景PyPDF2本地庫依賴文本層差無免費(fèi)格式探測(cè)pdfplumber本地庫依賴文本層中弱免費(fèi)原生規(guī)整表格PyMuPDF本地庫依賴文本層中中免費(fèi)萬能預(yù)處理pdfminer.six本地庫依賴文本層弱中免費(fèi)深度版面分析Tesseract本地 OCR中弱弱免費(fèi)個(gè)人小項(xiàng)目PaddleOCR本地 OCR優(yōu)中中免費(fèi)中文掃描件云通用 OCRAPI優(yōu)良良按量高準(zhǔn)確率需求商用解析 APIAPI優(yōu)優(yōu)優(yōu)高金融法律多模態(tài)大模型API優(yōu)優(yōu)優(yōu)高復(fù)雜兜底4.4 我的組合拳方案實(shí)際項(xiàng)目里我很少只用一種通常是組合PyMuPDF 做格式探測(cè)和頁面渲染先判斷有沒有文本層沒有就渲染成圖。原生電子版走 pdfplumber PyMuPDF文本和表格分別提取。掃描件走 PaddleOCR批量、本地、成本低。復(fù)雜頁面走多模態(tài)大模型只處理 OCR 效果差的頁面。最后統(tǒng)一做結(jié)構(gòu)化重組把各路結(jié)果拼成一致的 chunk 格式。這套組合的核心思想是分級(jí)處理、按需升級(jí)把貴的資源用在刀刃上。5. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)5.1 環(huán)境準(zhǔn)備與依賴安裝先裝基礎(chǔ)環(huán)境。我習(xí)慣用 conda 建獨(dú)立環(huán)境避免依賴沖突。conda create -n rag-parse python3.10 conda activate rag-parse pip install pymupdf pdfplumber pypdf pillow pip install paddlepaddle paddleocr如果要用多模態(tài)模型再裝對(duì)應(yīng) SDK。注意 PaddleOCR 首次運(yùn)行會(huì)下載模型國(guó)內(nèi)網(wǎng)絡(luò)可能需要配置鏡像源。5.2 第一步格式探測(cè)與分流這一步的目標(biāo)是給每個(gè) PDF 打標(biāo)簽原生電子版還是掃描件。import fitz # PyMuPDF def detect_pdf_type(pdf_path, sample_pages5): doc fitz.open(pdf_path) total_chars 0 pages_to_check min(sample_pages, len(doc)) for i in range(pages_to_check): page doc[i] text page.get_text() total_chars len(text.strip()) doc.close() avg_chars total_chars / pages_to_check # 經(jīng)驗(yàn)閾值平均每頁少于 50 個(gè)字符基本可判定為掃描件 if avg_chars 50: return scanned return digital這個(gè)閾值 50 是我實(shí)測(cè)調(diào)出來的。原生電子版每頁通常幾百到幾千字符掃描件即使有隱藏文本層也往往很少。你可以根據(jù)自己文檔調(diào)整。5.3 第二步原生電子版的文本與表格提取原生電子版優(yōu)先走文本層別浪費(fèi) OCR 資源。import pdfplumber def extract_digital_pdf(pdf_path): result [] with pdfplumber.open(pdf_path) as pdf: for page_num, page in enumerate(pdf.pages): text page.extract_text() or tables page.extract_tables() result.append({ page: page_num 1, text: text, tables: tables }) return result表格提取出來后要轉(zhuǎn)成 Markdown 格式再入庫這樣檢索和生成都友好def table_to_markdown(table): if not table: return header table[0] rows table[1:] md | | .join(str(c or ) for c in header) |\n md | | .join([---] * len(header)) |\n for row in rows: md | | .join(str(c or ) for c in row) |\n return md5.4 第三步掃描件的 OCR 處理掃描件先用 PyMuPDF 渲染成高分辨率圖片再喂給 PaddleOCR。渲染的 DPI 很關(guān)鍵我一般用 300太低識(shí)別不準(zhǔn)太高速度慢。import fitz from paddleocr import PaddleOCR ocr PaddleOCR(use_angle_clsTrue, langch) def ocr_scanned_pdf(pdf_path, dpi300): doc fitz.open(pdf_path) all_text [] for page_num in range(len(doc)): page doc[page_num] # 渲染成圖片 mat fitz.Matrix(dpi / 72, dpi / 72) pix page.get_pixmap(matrixmat) img_path f/tmp/page_{page_num}.png pix.save(img_path) # OCR result ocr.ocr(img_path, clsTrue) page_text \n.join([line[1][0] for line in result[0]]) if result[0] else all_text.append({page: page_num 1, text: page_text}) doc.close() return all_text注意use_angle_clsTrue會(huì)做方向分類能糾正倒置的文字但會(huì)稍微拖慢速度。如果文檔方向都正?？梢躁P(guān)掉提速。5.5 第四步復(fù)雜頁面交給多模態(tài)大模型哪些頁面算復(fù)雜我的判斷標(biāo)準(zhǔn)是OCR 置信度低、檢測(cè)到表格線條多、頁面有公式或圖表、雙欄排版。把這些頁面挑出來渲染成圖送給多模態(tài)模型。import base64 import fitz def page_to_base64(pdf_path, page_num, dpi200): doc fitz.open(pdf_path) page doc[page_num] mat fitz.Matrix(dpi / 72, dpi / 72) pix page.get_pixmap(matrixmat) img_bytes pix.tobytes(png) doc.close() return base64.b64encode(img_bytes).decode(utf-8) # 調(diào)用多模態(tài)模型偽代碼按你用的 SDK 替換 def parse_with_multimodal(pdf_path, page_num): img_b64 page_to_base64(pdf_path, page_num) prompt 請(qǐng)把這頁文檔轉(zhuǎn)成結(jié)構(gòu)化的 Markdown要求 1. 保持正確的閱讀順序雙欄按左欄后右欄 2. 表格轉(zhuǎn)成 Markdown 表格 3. 公式轉(zhuǎn)成 LaTeX 4. 圖片用 [圖片: 描述] 標(biāo)注 5. 不要添加原文沒有的內(nèi)容 # response multimodal_client.chat(imageimg_b64, promptprompt) # return response return 模型返回的 Markdown這里 prompt 的最后一句不要添加原文沒有的內(nèi)容非常重要能顯著降低幻覺。我還會(huì)在 prompt 里要求它對(duì)不確定的內(nèi)容標(biāo)注[不確定]方便后續(xù)人工復(fù)核。5.6 第五步結(jié)構(gòu)化重組與切塊各路結(jié)果拿到后要統(tǒng)一成一致的 chunk 格式。我的 chunk 結(jié)構(gòu)長(zhǎng)這樣chunk { content: 正文內(nèi)容, source: 文件名.pdf, page: 12, section: 第三章 財(cái)務(wù)分析, type: text, # text / table / image_desc parser: paddleocr # 記錄來源方便排查 }切塊策略上我一般按語義邊界切而不是固定字?jǐn)?shù)。標(biāo)題作為分隔符段落作為基本單位表格單獨(dú)成塊。chunk 大小控制在 300 到 800 字之間太大檢索不準(zhǔn)太小語義不全。5.7 參數(shù)選擇背后的計(jì)算邏輯幾個(gè)關(guān)鍵參數(shù)我是這么定的渲染 DPI300 是 OCR 的甜點(diǎn)。公式是DPI 72 * 縮放倍數(shù)300 DPI 對(duì)應(yīng)約 4.17 倍縮放。低于 200 識(shí)別率明顯下降高于 400 收益遞減還費(fèi)時(shí)間。chunk 大小假設(shè) embedding 模型上下文 512 token中文約 1 字 1.5 token那 800 字約 1200 token 會(huì)超。所以我實(shí)際控制在 500 字左右留出余量。overlap相鄰 chunk 重疊 50 到 100 字防止邊界信息丟失。這些數(shù)字不是拍腦袋都是根據(jù)模型能力和實(shí)測(cè)效果反推的。6. 常見問題與排查技巧實(shí)錄6.1 問題速查表現(xiàn)象可能原因排查方向解決OCR 返回空?qǐng)D片太模糊/語言不支持檢查渲染 DPI、語言參數(shù)提高 DPI、換語言模型表格串行版面分析失敗看是否有合并單元格換多模態(tài)模型文字順序亂雙欄未識(shí)別檢查頁面布局用多模態(tài)或分欄處理數(shù)字識(shí)別錯(cuò)OCR 混淆相似字符抽樣對(duì)比原文二次校驗(yàn)、多模態(tài)復(fù)核多模態(tài)幻覺模型腦補(bǔ)對(duì)比原文加約束 prompt、人工抽檢處理速度慢DPI 過高/模型太大看耗時(shí)分布降 DPI、分級(jí)處理6.2 幾個(gè)我踩過的坑坑一以為所有 PDF 都有文本層。早期我直接用 pdfplumber 批量跑結(jié)果掃描件全返回空還以為是庫的問題。后來加了格式探測(cè)才解決。教訓(xùn)是永遠(yuǎn)先探測(cè)再處理?？佣﨩CR 語言參數(shù)沒設(shè)對(duì)。有次處理中英混排文檔只設(shè)了langch英文識(shí)別率暴跌。PaddleOCR 支持langch時(shí)其實(shí)也帶英文但混排復(fù)雜時(shí)最好用支持多語言的配置或者分區(qū)域處理?？尤嗄B(tài)模型把表格讀錯(cuò)。一份財(cái)務(wù)報(bào)表模型把1,234,567讀成1,234,567沒問題但把某行的負(fù)號(hào)漏了導(dǎo)致金額正負(fù)顛倒。這種錯(cuò)誤在 RAG 里是災(zāi)難性的。后來我加了規(guī)則所有數(shù)字類內(nèi)容用 OCR 結(jié)果和多模態(tài)結(jié)果交叉驗(yàn)證不一致的標(biāo)記出來人工看?？铀腸hunk 切太碎。一開始我按 200 字切結(jié)果檢索出來的都是半句話模型沒法答。后來改成按段落切配合標(biāo)題層級(jí)效果好很多。6.3 獨(dú)家避坑技巧先小樣本驗(yàn)證再批量拿 10 份文檔跑通全流程人工檢查質(zhì)量再上批量。別一上來就處理幾千份錯(cuò)了重來成本太高。保留中間產(chǎn)物渲染的圖片、OCR 的原始結(jié)果都存下來。后面發(fā)現(xiàn)解析錯(cuò)了不用重新跑一遍。記錄 parser 來源每個(gè) chunk 標(biāo)注是哪個(gè)工具解析的。出問題時(shí)能快速定位是哪個(gè)環(huán)節(jié)的鍋。數(shù)字和專有名詞雙重校驗(yàn)這是 RAG 里最不能出錯(cuò)的部分值得多花一道工序。定期抽檢上線后每周抽 20 個(gè) chunk 人工核對(duì)防止模型或數(shù)據(jù)漂移。6.4 關(guān)于成本和吞吐的現(xiàn)實(shí)考量如果文檔量在幾百份以內(nèi)多模態(tài)模型隨便用成本可忽略。上千份就要算賬了假設(shè)一頁多模態(tài)解析成本 0.01 到 0.05 元一萬頁就是 100 到 500 元還能接受十萬頁就是幾千到幾萬這時(shí)候就得上分級(jí)策略把大部分頁面用便宜的 OCR 處理只把硬骨頭給多模態(tài)。吞吐上本地 PaddleOCR 單機(jī)大概每秒 1 到 3 頁取決于 DPI 和 CPU多模態(tài) API 受并發(fā)限制。批量處理建議用隊(duì)列 多進(jìn)程別串行跑。7. 關(guān)于解析這件事我最后想說的做 RAG 這兩年我越來越覺得解析是整個(gè)系統(tǒng)里最臟也最值錢的活。臟是因?yàn)樗鼪]有標(biāo)準(zhǔn)答案每批數(shù)據(jù)都有新花樣值錢是因?yàn)樗苯記Q定了下游的天花板。模型再?gòu)?qiáng)檢索再準(zhǔn)喂進(jìn)去的是垃圾出來的還是垃圾。我的個(gè)人體會(huì)是別追求一步到位的完美方案先跑通再優(yōu)化。先用最簡(jiǎn)單的組合PyMuPDF 探測(cè) pdfplumber 提文本 PaddleOCR 兜底把流程跑起來看看實(shí)際效果再針對(duì)具體問題升級(jí)。多模態(tài)大模型是好東西但它是手術(shù)刀不是大砍刀用在對(duì)的地方才值。最后分享一個(gè)小技巧建一個(gè)疑難雜癥文件夾把每次解析出問題的文檔存進(jìn)去。攢到一定量你會(huì)發(fā)現(xiàn)自己的文檔其實(shí)就那么幾類問題針對(duì)性寫幾個(gè)處理規(guī)則比盲目換工具有效得多。這個(gè)文件夾也是你后續(xù)優(yōu)化最好的測(cè)試集。