1. 問題源頭PDF 為什么是 RAG 導(dǎo)入的第一道坎如果你搭過 RAG 知識(shí)庫你大概率經(jīng)歷過這種場景文檔明明導(dǎo)進(jìn)去了檢索的時(shí)候卻發(fā)現(xiàn)答非所問。查來查去問題出在解析環(huán)節(jié)——PDF 里的文字沒提出來或者提出來的是亂碼、是空字符、是一大團(tuán)擠在一起的文本塊。PDF 這個(gè)格式誕生三十多年它的設(shè)計(jì)哲學(xué)是“保證打印效果一致”而不是“方便提取文字”。這就導(dǎo)致了 PDF 內(nèi)部結(jié)構(gòu)的極端分裂有的 PDF 自帶文本層鼠標(biāo)一劃能選中文字有的 PDF 本質(zhì)是掃描圖片里面一個(gè)文字都沒有還有的 PDF 是電子簽名、表單、打印流生成的混合體每一頁結(jié)構(gòu)都不同。RAG 系統(tǒng)把 PDF 喂給向量模型之前必須先完成“從字節(jié)流到干凈文本”的轉(zhuǎn)換。這個(gè)環(huán)節(jié)沒做好后面的一切——切片、向量化、召回——都是在錯(cuò)誤的地基上蓋樓。我見過不少團(tuán)隊(duì)花大量時(shí)間調(diào) embedding 模型、調(diào) rerank 閾值最后發(fā)現(xiàn)問題的根源只是 PDF 解析器選錯(cuò)了。所以解析這件事值得單獨(dú)拿出一篇來說。這篇就聚焦兩塊圖文混合內(nèi)容的 OCR 解析以及 PDF 場景下的工具選型。2. 圖文解析的兩個(gè)方向傳統(tǒng) OCR 與多模態(tài)大模型2.1 傳統(tǒng) OCR 的技術(shù)棧與選型邏輯OCR光學(xué)字符識(shí)別解決的問題很簡單把圖片里的文字變成可編輯的文本。但在 RAG 語境下OCR 的要求更高不只是“識(shí)別出字”還要“保留版面結(jié)構(gòu)”——標(biāo)題、段落、表格、圖片位置這些信息如果全部拍平成純文本語義就丟了。先看離線方案。PaddleOCR 目前是中文場景下綜合能力最穩(wěn)的開源方案PP-OCRv4 系列模型的識(shí)別精度和速度都經(jīng)過了大量工業(yè)場景驗(yàn)證。Tesseract OCR 是老牌開源工具支持上百種語言但中文識(shí)別精度一直不太理想尤其是遇到復(fù)雜排版和低清晰度掃描件時(shí)錯(cuò)誤率會(huì)明顯上升。如果做多語言文檔Tesseract 可以作為備選如果主力是中文PaddleOCR 更靠譜。在線 API 方案主要分兩類一類是通用云廠商的 OCR 接口另一類是專門的文檔解析服務(wù)。通用 OCR 接口的優(yōu)勢是開箱即用不需要自己部署模型但劣勢也很明顯——圖片里大段文字之外的版面信息標(biāo)題層級(jí)、段落邊界、表格結(jié)構(gòu)它不會(huì)幫你還原。而文檔解析服務(wù)比如各類 DocAI 類產(chǎn)品會(huì)額外輸出版面分析結(jié)果這一步對(duì) RAG 后續(xù)的切片策略影響很大。這里要特別提醒一個(gè)事情線上 OCR 服務(wù)對(duì)圖片格式和大小有嚴(yán)格限制超出限制會(huì)被拒。我在實(shí)際項(xiàng)目里遇到過拍照的合同文件因?yàn)?EXIF 旋轉(zhuǎn)信息異常直接被 OCR 接口報(bào)“file format error”的坑。處理方式是先用圖像庫統(tǒng)一做方向校正和重編碼再送進(jìn) OCR。2.2 多模態(tài)大模型解析圖片的實(shí)際用法傳統(tǒng) OCR 就是把像素變成文字多模態(tài)大模型則是把像素變成“理解”。兩者的核心差異在于OCR 只做字符識(shí)別不識(shí)語義多模態(tài)模型能識(shí)別字符、理解版面、描述圖表、提取關(guān)鍵信息甚至可以理解表格里的邏輯關(guān)系。在 RAG 場景里多模態(tài)大模型的價(jià)值主要體現(xiàn)在兩個(gè)地方。第一是高精度 OCR 補(bǔ)錯(cuò)先讓傳統(tǒng) OCR 出初稿再用多模態(tài)模型對(duì)關(guān)鍵區(qū)域二次校驗(yàn)?zāi)茱@著降低錯(cuò)誤率。第二是結(jié)構(gòu)化信息提取合同里的甲方、乙方、金額、日期發(fā)票里的發(fā)票號(hào)、稅額這些關(guān)鍵字段直接跳過 Fine-tuning用多模態(tài)大模型的 Prompt 就能抽出來。舉個(gè)實(shí)際例子。我處理過一批掃描版技術(shù)協(xié)議里面含蓋章、手寫批注、表格混排。PaddleOCR 能識(shí)別出文字但分不清哪些是條款正文、哪些是批注。換成多模態(tài)方案后通過一個(gè)簡單的 Prompt 要求區(qū)分正文與批注、保留表格結(jié)構(gòu)輸出結(jié)果的質(zhì)量提升非常明顯。多模態(tài)模型選型上開源簡單場景完全可以部署本地模型但要注意顯存占用和推理速度商用 API 的識(shí)別精度、速度都不錯(cuò)但成本需要評(píng)估。個(gè)人建議流程可以這樣設(shè)計(jì)優(yōu)先跑離線 OCR遇到結(jié)構(gòu)化復(fù)雜或識(shí)別置信度低的頁面才調(diào)用多模態(tài)接口兜底。這樣既有性能和成本的平衡又能保證整體解析質(zhì)量。2.3 表格與版面的特殊處理表格是圖文解析里最容易被低估的一塊。PDF 里的表格提取出來之后如果拍平成一串帶制表符的文本向量化的時(shí)候語義就散了——每一行被切開列與列之間的對(duì)應(yīng)關(guān)系全部丟失。推薦的做法是走“表格結(jié)構(gòu)識(shí)別 轉(zhuǎn) HTML/JSON”的路徑復(fù)雜表格轉(zhuǎn)成 Markdown 或 HTML 之后再做切片。可以試試這樣的思路先做版面分析把頁面切分成標(biāo)題區(qū)、正文區(qū)、表格區(qū)、圖片區(qū)。標(biāo)題區(qū)可以和下文合并成一個(gè)語義塊正文區(qū)按段落邊界切片表格區(qū)單獨(dú)走表格還原流程圖片區(qū)如果是信息圖或者流程圖調(diào)用多模態(tài)模型生成一段描述性文本再作為該區(qū)域的向量化內(nèi)容。這種分區(qū)處理方案比“整頁轉(zhuǎn)文本再切分”的召回效果要好得多。3. 九種 PDF 解析工具的橫向選型3.1 以語言生態(tài)分類Python 系與系統(tǒng)級(jí)工具PDF 解析工具的選型首先要看你的項(xiàng)目技術(shù)棧。Python 生態(tài)里PyPDF2 和 pdfplumber 是兩條相反的路線。PyPDF2 主打輕量適合快速提取文本和水印、合并拆分 PDF但它對(duì)復(fù)雜排版幾乎無能為力提取出來的文字經(jīng)常亂序。pdfplumber 則更像一個(gè)精工細(xì)作的工具箱它基于 PDFMiner 構(gòu)建能提取每個(gè)字符的坐標(biāo)信息可以精確還原版面。代價(jià)是速度慢、內(nèi)存占用高。PDFMiner.six 是另一個(gè)值得了解的名字。它是很多高級(jí)解析工具的內(nèi)核對(duì)文本提取的底層支持非常扎實(shí)如果你需要自定義解析邏輯直接在 PDFMiner 的基礎(chǔ)上做二次開發(fā)可控性是最好的。系統(tǒng)級(jí)工具里poppler-utils 是 Linux 服務(wù)器上的標(biāo)配。它的 pdftotext 命令保留了相對(duì)簡單的版面布局pdfimages 可以批量導(dǎo)出 PDF 里的圖片。在 Linux 服務(wù)器上做批處理時(shí)這套工具比寫十幾行 Python 代碼更高效。但要注意pdftotext 對(duì) CJK中日韓字符的排版處理存在一些固有的問題遇到豎排文字、復(fù)雜注音符號(hào)時(shí)提取結(jié)果會(huì)出問題。3.2 以場景分類掃描件、原生 PDF 與復(fù)雜版式選用什么工具取決于你手上的 PDF 是哪種類型。原生 PDF文本型這類 PDF 自帶文本層文字可以直接提取。用 pdfplumber 或 PDFMiner 都可以獲得較好的結(jié)果速度也快。如果是簡單版式的學(xué)術(shù)論文PyPDF2 就夠用如果版面較復(fù)雜建議直接上 pdfplumber。掃描型 PDF這類 PDF 本質(zhì)上是一堆圖片套了一個(gè) PDF 外殼。任何純文本提取工具對(duì)它都無效必須走 OCR 流程。處理鏈?zhǔn)窍扔霉ぞ邔?dǎo)出頁面圖片pdfimages 或者 PyMuPDF 的 get_pixmap再對(duì)圖片做 OCR。如果頁數(shù)不多也可以直接用具備 OCR 能力的文檔解析 API 一次性處理。復(fù)雜版式 PDF表格、多欄、頁眉頁腳這類是 RAG 項(xiàng)目里最容易出問題的。用 pdfplumber 提取表格時(shí)可以用 extract_table 方法但前提是表格必須有明確的線框。沒有線的表格識(shí)別率會(huì)大幅下降。這里有個(gè)小實(shí)戰(zhàn)建議拿到 PDF 后先用工具建議 pdfplumber把第一頁的文字坐標(biāo) dump 出來觀察文本流的順序和坐標(biāo)分布判斷這個(gè) PDF 是不是“正常排版”再做后續(xù)處理決策。3.3 九種工具速查對(duì)比我按“適用場景 優(yōu)缺點(diǎn) 建議指數(shù)”整理了一張速查表可以直接抄作業(yè)。工具類型適用場景核心優(yōu)勢主要缺點(diǎn)建議指數(shù)PyPDF2Python庫輕量文本提取、PDF合并拆分簡單易用、社區(qū)活躍復(fù)雜排版提取亂序中等pdfplumberPython庫精確文本提取、表格提取支持字符坐標(biāo)、表格識(shí)別較好速度慢、內(nèi)存占用高高PDFMiner.sixPython庫自定義解析邏輯底層控制力強(qiáng)、穩(wěn)定性好上手門檻高中等PyMuPDFPython庫高性能文本圖片導(dǎo)出速度快、支持格式多API偶爾變動(dòng)高CamelotPython庫線框表格提取表格提取精度高對(duì)無框表格無效中等poppler-utils系統(tǒng)工具Linux批處理、圖片導(dǎo)出輕量快速、無需編碼中文復(fù)雜排版處理一般中等Apache TikaJava/Python多格式統(tǒng)一解析格式覆蓋廣、自動(dòng)探測解析質(zhì)量不如專用工具較低Adobe Acrobat商業(yè)軟件人工處理復(fù)雜文檔還原度極高貴、無法自動(dòng)化視場景商用文檔解析API云服務(wù)全類型文檔一體化解析開箱即用、報(bào)表分析強(qiáng)成本高、有數(shù)據(jù)隱私考慮高選型的核心邏輯就一條先看 PDF 類型再選工具。掃描件直接免談純文本提取工具原生 PDF 優(yōu)先開源 Python 庫復(fù)雜場景優(yōu)先商用 API 或自建多模態(tài)方案。4. 實(shí)操一條可落地的“PDF 解析流水線”4.1 解析流程設(shè)計(jì)我在幾個(gè)項(xiàng)目里沉淀了一套解析流水線整體思路是判斷類型 → 分類處理 → 版面還原 → 輸出標(biāo)準(zhǔn)格式。這套流程在長文檔幾十頁到幾百頁和短文檔幾頁合同上都驗(yàn)證過。第一步用 PyMuPDF 檢查 PDF 是否包含文本層。這個(gè)判斷很簡單提取每頁的文本長度如果接近 0說明該頁是掃描頁。第二步按頁面類型分流。文本頁走 pdfplumber 提取文本和表格掃描頁走 PaddleOCR 做文字識(shí)別同時(shí)對(duì)有表格的區(qū)域調(diào)用多模態(tài)模型做結(jié)構(gòu)還原。第三步版面合并。將 OCR 結(jié)果、文本提取結(jié)果、表格還原結(jié)果按頁面順序拼接成結(jié)構(gòu)化 Markdown并保留坐標(biāo)信息用于后續(xù)的可視化調(diào)試。第四步清洗與歸一化。統(tǒng)一處理中文標(biāo)點(diǎn)、編碼問題、多余空行和亂碼字符。實(shí)際項(xiàng)目中環(huán)節(jié)順序可以這樣安排。4.2 硬核示例從 PDF 到干凈文本的完整實(shí)現(xiàn)下面這套代碼是我在實(shí)際項(xiàng)目里用的邏輯可以直接復(fù)現(xiàn)。核心思路是針對(duì)混合型 PDF既有文本頁又有掃描頁做分流處理。import fitz # PyMuPDF import pdfplumber from paddleocr import PaddleOCR ocr PaddleOCR(use_angle_clsTrue, langch, show_logFalse) def is_scanned_page(page) - bool: 判斷當(dāng)前頁面是否為純掃描頁 text page.get_text().strip() return len(text) 10 # 文本量極低判定為掃描頁 def extract_text_page(pdf_path, page_num): 文本頁提取優(yōu)先用 pdfplumber 保留版面順序 text_result [] with pdfplumber.open(pdf_path) as pdf: page pdf.pages[page_num] # 提取表格 tables page.extract_tables() for table in tables: if table: text_result.append([TABLE_START]) for row in table: text_result.append( | .join([str(c).replace(\n, ) if c else for c in row])) text_result.append([TABLE_END]) # 提取文本 text_result.append(page.extract_text()) return \n.join(text_result) def extract_scan_page(pdf_path, page_num, zoom2.0): 掃描頁提取渲染高清圖走 OCR doc fitz.open(pdf_path) page doc[page_num] mat fitz.Matrix(zoom, zoom) pix page.get_pixmap(matrixmat) img_path f/tmp/page_{page_num}.png pix.save(img_path) result ocr.ocr(img_path, clsTrue) lines [] if result and result[0]: for item in result[0]: box, (text, confidence) item, None # 實(shí)際 PaddleOCR 返回結(jié)構(gòu)為 [box, (text, score)] text item[1][0] lines.append(text) return \n.join(lines) def parse_mixed_pdf(pdf_path): 主流程逐頁判斷類型分流處理 doc fitz.open(pdf_path) full_text [] for page_num in range(len(doc)): page doc[page_num] if is_scanned_page(page): page_text extract_scan_page(pdf_path, page_num) else: page_text extract_text_page(pdf_path, page_num) full_text.append(f!-- PAGE {page_num 1} --\n{page_text}) return \n\n.join(full_text) if __name__ __main__: output parse_mixed_pdf(your_document.pdf) with open(output.md, w, encodingutf-8) as f: f.write(output)這段代碼里幾個(gè)細(xì)節(jié)值得說清楚zoom2.0用于控制渲染清晰度。對(duì)中文 OCR至少 200 DPI 起步不然小字號(hào)文字識(shí)別率下降非常明顯。測試下來 2.0 倍縮放是一個(gè)性價(jià)比合理的閾值。pdfplumber.extract_tables()輸出的是嵌套列表結(jié)構(gòu)需要自己拼接。拼接時(shí)用豎線分隔這樣轉(zhuǎn)成 Markdown 后格式依然保留。OCR 結(jié)果中每個(gè)元素的結(jié)構(gòu)是[box_coordinates, (text, confidence)]提取文本時(shí)注意別把坐標(biāo)當(dāng)成文字輸出了。這套流水線的處理耗時(shí)大約在每秒 2~3 頁取決于頁面復(fù)雜度對(duì)于大部分企業(yè)級(jí)知識(shí)庫的文檔量級(jí)來說完全夠用。如果吞吐要求高可以用多進(jìn)程按頁并行處理再用頁碼號(hào)合并結(jié)果。4.3 多模態(tài)模型接入的接口設(shè)計(jì)只靠 PaddleOCR 做圖文解析遇到復(fù)雜版面會(huì)不夠用。我建議在流水線上預(yù)留一個(gè)“多模態(tài)模型補(bǔ)充解析”的接口。設(shè)計(jì)上不需要所有頁面都走多模態(tài)還是那句話傳統(tǒng) OCR 先兜底多模態(tài)負(fù)責(zé)補(bǔ)漏。import base64 import requests def ocr_with_visual_model(image_path, prompt請?zhí)崛D中的全部文字信息保留原文結(jié)構(gòu)輸出為Markdown格式。): with open(image_path, rb) as f: img_base64 base64.b64encode(f.read()).decode() payload { model: your-visual-model, messages: [{ role: user, content: [ {type: text, text: prompt}, {type: image_url, image_url: {url: fdata:image/png;base64,{img_base64}}} ] }} ] resp requests.post(http://your-endpoint/v1/chat/completions, jsonpayload) return resp.json()[choices][0][message][content]Prompt 的設(shè)計(jì)是這類場景的關(guān)鍵。我個(gè)人在大量測試后推薦用下面的 Prompt 模板要求模型“原樣輸出”“不要總結(jié)”“保留表格結(jié)構(gòu)”“區(qū)分標(biāo)題正文”。一個(gè)常見的問題是模型會(huì)自動(dòng)做摘要式回答把原文改寫一遍這對(duì) RAG 是致命的。在 Prompt 里顯式聲明“逐字輸出原文”能有效減少這種情況。5. 實(shí)操中的五個(gè)高頻坑5.1 掃描件文字 OCR 識(shí)別不出韓文、日文等多語言熱詞里有個(gè)問題很有代表性“以下 OCR 代碼識(shí)別不了韓文”。PaddleOCR 默認(rèn)的langch是只識(shí)別中英文的。要識(shí)別韓文必須顯式指定langkorean。同理日文用langjapan。ocr PaddleOCR(use_angle_clsTrue, langkorean, show_logFalse)這里要額外提醒混合語言的文檔如中英夾雜的合同建議使用langch它內(nèi)部覆蓋中英文但如果同一文檔里既有中文又有韓文PaddleOCR 目前沒法在單次調(diào)用中同時(shí)處理。折中方案是分區(qū)域裁剪后分別識(shí)別或者直接換多模態(tài)模型做識(shí)別。5.2 PDF 里的文字是“加密子集”或自定義編碼有些 PDF 生成工具尤其是部分國產(chǎn)辦公軟件會(huì)對(duì)內(nèi)嵌字體做子集化處理導(dǎo)致文本層的 Unicode 映射異常。表現(xiàn)是用 PDF 閱讀器打開顯示正常用代碼提取卻是亂碼或空白。這種只能靠 OCR 兜底。排查方法很簡單先用 pdfplumber 提取前幾頁文本看是否亂碼。如果亂碼放棄文本層方案直接把頁面渲染成圖片走 OCR。這種情況下渲染清晰度非常關(guān)鍵建議zoom參數(shù)設(shè)為 3.0 以上。5.3 表格提取結(jié)果串行錯(cuò)位很多 RAG 項(xiàng)目導(dǎo)入 PDF 后表格內(nèi)容的召回效果特別差。原因基本都在解析環(huán)節(jié)表格被拍平成了無序文本序列。Camelot 對(duì)有線框的表格提取效果極佳但它依賴 Ghostscript安裝時(shí)容易出錯(cuò)。如果不想引入這個(gè)依賴pdfplumber 的 extract_table 是更輕量的替代。實(shí)測經(jīng)驗(yàn)表格提取后先用 Markdown 表格格式輸出再讓語言模型把 Markdown 表格轉(zhuǎn)成 JSON 或帶 schema 的結(jié)構(gòu)化數(shù)據(jù)召回時(shí)按字段查詢的效果遠(yuǎn)好于純文本檢索。這條經(jīng)驗(yàn)我驗(yàn)證過多次值得收藏。5.4 PDF 頁面方向顛倒導(dǎo)致識(shí)別率暴跌掃描儀出來的 PDF 經(jīng)常會(huì)有個(gè)別頁面方向不對(duì)。PaddleOCR 自帶use_angle_clsTrue的方向分類器能在一定程度上糾正但對(duì)旋轉(zhuǎn) 180°的頁面效果有限。最穩(wěn)的方法是預(yù)處理階段用圖像方向檢測模型統(tǒng)一校正。另外手機(jī)拍攝的文檔照片常常帶著 EXIF 旋轉(zhuǎn)信息。直接把這個(gè)圖喂給 OCR 接口部分 API 會(huì)報(bào)格式錯(cuò)誤或者識(shí)別出完全無意義的內(nèi)容。處理方式是用PIL.ImageOps.exif_transpose()先消除 EXIF 旋轉(zhuǎn)再保存。5.5 處理流程的性能太低PDF 解析在很多知識(shí)庫項(xiàng)目里是離線批處理任務(wù)但也有實(shí)時(shí)解析的需求。優(yōu)化思路有三條多用進(jìn)程池并行處理頁面避免 GIL 限制。用 PyMuPDF 替代 pdfplumber 做純文本提取速度能快一個(gè)數(shù)量級(jí)只有需要坐標(biāo)時(shí)才用 pdfplumber。對(duì)大量重復(fù)模板的文檔如統(tǒng)一格式的報(bào)告跑一次解析后保存解析結(jié)果緩存后續(xù)直接復(fù)用。6. 選型決策樹走到這一步該怎么選拿到的 PDF 類型不同最優(yōu)的工具鏈組合也不同。給你一個(gè)可以直接對(duì)照的決策路徑純文本型 PDF不追求表格結(jié)構(gòu)PyMuPDF 提取全文 → 按段落做切片。最優(yōu)先速度快、質(zhì)量穩(wěn)。文本型 PDF含表格、多欄排版pdfplumber 提取文本表格 → 表格轉(zhuǎn) Markdown → 與正文合并后切片。純掃描型 PDFPaddleOCR中文或 Tesseract多語言→ 版面合并 → 結(jié)構(gòu)化輸出?；旌闲?PDF先用 PyMuPDF 逐頁判斷類型 → 按頁面類型分流處理。這一步已經(jīng)在上面的代碼示例里實(shí)現(xiàn)了。含大量復(fù)雜表格、票據(jù)、蓋章合同的 PDF直接上商用文檔解析 API或多模態(tài)大模型 OCR 雙通道處理不要再浪費(fèi)精力調(diào)開源方案。7. 資料引用與后續(xù)內(nèi)容預(yù)告關(guān)于 PDF 格式本身的技術(shù)細(xì)節(jié)推薦查閱 PDF 規(guī)范文檔ISO 32000以及各類開源解析器的源碼實(shí)現(xiàn)。在實(shí)際項(xiàng)目中pdfplumber 的源碼是了解 PDF 結(jié)構(gòu)的最佳教材之一。補(bǔ)充兩個(gè)實(shí)用資料PaddleOCR 的官方文檔里包含完整的模型列表和參數(shù)說明建議優(yōu)先看 PP-OCRv4 的模型對(duì)比商用解析服務(wù)的技術(shù)文檔里提到版面分析能力對(duì)接前建議先做小規(guī)模效果驗(yàn)證。這篇講完了圖文與 PDF 解析下一篇適合接著討論“解析后的文本如何做清洗與切片”因?yàn)榻馕鲚敵龅慕Y(jié)果直接決定了后續(xù)向量化的質(zhì)量。比如清洗時(shí)要不要統(tǒng)一全角半角、切片時(shí)按固定長度還是按語義邊界、標(biāo)題和正文如何組合成上下文塊——這些問題都是從解析到召回的必經(jīng)之路。準(zhǔn)備接上一篇的目錄索引保持系列內(nèi)容連貫方便讀者按順序查閱。