1. 項(xiàng)目概述多欄和水印為什么是 RAG 解析里的兩座山先說個(gè)場景。上個(gè)月我把一批技術(shù)論文和舊版產(chǎn)品手冊塞進(jìn)自建的 RAG 知識(shí)庫原以為 PDF 解析早就不是問題結(jié)果檢索結(jié)果讓我懷疑人生同一個(gè)問題的答案碎片化有的片段左邊一欄讀到一半突然跳到右欄有的片段把每頁底部的“Confidential”水印當(dāng)成正文喂給了向量庫最后回答里全是莫名其妙的口水話。排查了一圈問題不是出在模型而是出在 bbox 這一層——我當(dāng)年用 PDF 解析庫取文本時(shí)只看字符串壓根沒想過“文字在頁面哪個(gè)位置”這件事有多重要。這個(gè)項(xiàng)目本質(zhì)上就是一個(gè) RAG 文檔解析鏈路里的高發(fā)事故區(qū)多欄排版和水印 PDF。多欄會(huì)讓純文本流式讀取順序錯(cuò)亂水印會(huì)讓文本內(nèi)容帶上大量重復(fù)噪聲兩者疊加后向量檢索的召回質(zhì)量會(huì)被拉低得慘不忍睹。我在這個(gè)系列的前兩篇里寫過 PDF 的文本抽取和表格還原這次專門把 bbox 實(shí)戰(zhàn)拿出來寫透用一套可復(fù)現(xiàn)的 Python 流程解決兩類最惡心的 PDF。適合誰看正在搭 RAG 知識(shí)庫、做文檔解析管道、或者被掃描版論文和帶水印的公開報(bào)告折磨過的人。這篇不會(huì)只講理論我會(huì)直接給出坐標(biāo)體系、列檢測算法、水印過濾規(guī)則、以及一套從 PDF 頁面到干凈文本的流水線代碼。就算你之前沒碰過 bbox 也沒關(guān)系讀完后你自己上手改參數(shù)就能用。1.1 一個(gè)真實(shí)場景從論文庫到檢索問答我最初接到的需求很樸素把 2000 篇 PDF 論文和 100 多份廠商手冊做成一個(gè)可問答的知識(shí)庫。單欄排版的白皮書幾乎沒花時(shí)間文本抽出來就能用。麻煩的是那些雙欄排版論文和帶官方水印的 PDF 報(bào)告。雙欄排版最常見的問題是文本流錯(cuò)位。很多 PDF 閱讀器或解析庫按“文本對(duì)象在文件里的出現(xiàn)順序”抽取但 PDF 內(nèi)部對(duì)象順序和人類閱讀順序經(jīng)常不一致。你可能以為在解析輸出里先看到左欄上段實(shí)際卻是左欄、右欄、左欄、右欄地交錯(cuò)出現(xiàn)。舉個(gè)例子一頁雙欄論文的文本被抽出來之后如果把這段文本直接切塊第一塊可能是左欄第一段的開頭加右欄第一段的開頭第二塊可能是左欄第一段結(jié)尾加右欄第一段結(jié)尾。嵌到一起之后語義是碎的。水印的問題就更隱蔽了。很多水印是文本對(duì)象會(huì)被普通解析器當(dāng)成正文比如“Confidential”“DRAFT”或公司名在每一頁以中等字號(hào)、半透明的樣式出現(xiàn)在頁面中央或底部。抽取文本時(shí)你會(huì)得到一份每頁都重復(fù)若干次的水印詞表向量化之后它們會(huì)占據(jù)高頻詞位置檢索時(shí)容易命中水印而不是正文。我當(dāng)時(shí)的目標(biāo)很明確解析后的文本必須盡可能接近“人眼閱讀順序”而且要把水印這類視覺噪聲從文本流里剔除。這兩件事都必須依賴 bbox。1.2 bbox 是什么跟 RAG 有什么關(guān)系bbox 是 bounding box 的縮寫指文本對(duì)象在頁面上的最小外接矩形。一般用四個(gè)數(shù)字表示左上角 x、左上角 y、右下角 x、右下角 y。對(duì) PDF 解析來說詞級(jí) bbox 是重建閱讀順序的最重要線索對(duì) OCR 來說檢測框也是 bbox只不過坐標(biāo)系的單位不同。為什么 RAG 需要它因?yàn)槲谋鞠蛄炕举|(zhì)上只處理一維字符流它不關(guān)心二維視覺位置。如果從 PDF 提取到的字符流順序錯(cuò)了那么后續(xù)的每個(gè) RAG 環(huán)節(jié)都會(huì)繼承錯(cuò)誤切塊會(huì)切出語義斷裂的片段向量檢索會(huì)召回亂七八糟的內(nèi)容生成回答時(shí)模型只能在壞素材上強(qiáng)行組織語言。換句話說RAG 系統(tǒng)的天花板很大程度取決于文檔解析是否保留了正確的版面順序而 bbox 就是修正版面順序的錨點(diǎn)。在實(shí)際項(xiàng)目中我經(jīng)常用 bbox 做三件事一是多欄檢測判斷一頁里文本分幾欄再按視覺列重組二是閱讀順序排序把同一欄內(nèi)按從上到下排序欄之間按從左到右拼接三是水印過濾識(shí)別那些位置重復(fù)、顏色異常、透明度高、字號(hào)特殊的干擾文本并剔除。下一節(jié)開始我會(huì)把 PDF 坐標(biāo)體系和版面分析的基本概念講清楚然后再給實(shí)操代碼。2. 核心概念拆解坐標(biāo)、版面分析與閱讀順序很多人用 PyMuPDF 或 pdfplumber 時(shí)直接調(diào)page.get_text()拿字符串認(rèn)為這就完成了解析。這其實(shí)是把 PDF 里的很多信息丟掉。PDF 本身是一個(gè)二維版面模型頁面上的每個(gè)字符都有精確坐標(biāo)只是大多數(shù)文本抽取接口默認(rèn)按內(nèi)部對(duì)象順序輸出而這個(gè)順序跟人類閱讀順序不完全一致。2.1 PDF 坐標(biāo)體系從頁面坐標(biāo)到詞級(jí) bboxPDF 的坐標(biāo)原點(diǎn)通常在頁面左下角x 軸向右y 軸向上單位是點(diǎn)point1 point 1/72 英寸。但 PyMuPDF 返回坐標(biāo)時(shí)用的是左上角為原點(diǎn)的轉(zhuǎn)換也就是說 y 軸向下增長0 在頁面頂部數(shù)值越大越靠下。和 PDF 原生坐標(biāo)相反。pdfplumber 則保留 PDF 原生坐標(biāo)y 軸向上0 在頁面底部。這個(gè)差異非?？?。我第一次把 PyMuPDF 和 pdfplumber 的坐標(biāo)混用做列投影時(shí)怎么都不對(duì)后來發(fā)現(xiàn)兩個(gè)庫的 y 方向是相反的。建議在一個(gè)項(xiàng)目里固定只用一個(gè)坐標(biāo)體系或者統(tǒng)一轉(zhuǎn)換成同一參考系。我自己習(xí)慣用 PyMuPDF 的坐標(biāo)因?yàn)楹罄m(xù)要畫框調(diào)試時(shí)左上角原點(diǎn)跟常見的圖像坐標(biāo)一致跟 OpenCV 也能無縫對(duì)接。拿到詞級(jí) bbox 之后每個(gè)詞的形態(tài)是這樣的# PyMuPDF 返回的 word 結(jié)構(gòu) # (x0, y0, x1, y1, word, block_no, line_no, word_no)坐標(biāo)的單位是點(diǎn)不是像素。如果 PDF 頁面寬 612 點(diǎn)對(duì)應(yīng) letter 紙的寬度如果頁面要用到 150 DPI 渲染成圖片需要做一個(gè)簡單換算像素 點(diǎn)數(shù) * DPI / 72。這個(gè)換算是 OCR 場景的常見操作也是后續(xù) bbox 過濾和圖像渲染對(duì)齊的前提。2.2 版面分析啟發(fā)式規(guī)則和版面模型的取舍版面分析不外乎兩條路一條是用規(guī)則啟發(fā)式一條是訓(xùn)練或調(diào)用版面模型。規(guī)則啟發(fā)式基于坐標(biāo)、字號(hào)、顏色、縮進(jìn)這些淺層特征做判斷版面模型則是用深度學(xué)習(xí)模型檢測段落、標(biāo)題、表格、圖片區(qū)域并輸出結(jié)構(gòu)化坐標(biāo)。對(duì)多欄問題我一開始試過基于深度學(xué)習(xí)的版面模型比如開源版面分析工具效果不錯(cuò)但部署成本和推理延遲都比較高。在實(shí)際 RAG 管道里每天解析幾百上千頁文件離線批量解析還能忍但如果是實(shí)時(shí)文檔問答每一頁都走模型推理會(huì)拖慢鏈路。更簡單的辦法是先上規(guī)則判斷頁內(nèi)是否有明顯的列結(jié)構(gòu)如果有就用列投影來做重排如果遇到特殊頁面代碼塊、表格、復(fù)雜示意圖再降級(jí)到版面模型或人工處理。我的結(jié)論是不要一開始就上模型。先用規(guī)則跑通 80% 的常規(guī) PDF剩下 20% 的特殊頁面單獨(dú)標(biāo)記定期抽檢人工修復(fù)這樣工程上更穩(wěn)妥。規(guī)則做不了的事再交給模型補(bǔ)位。2.3 多欄檢測的底層邏輯多欄檢測的核心思路是“投影”。把所有文本的最小 y 坐標(biāo)映射到 x 軸統(tǒng)計(jì)不同 x 區(qū)間里出現(xiàn)的文本密度。如果是單欄x 軸上的文字分布幾乎是連續(xù)一段如果是雙欄文字分布會(huì)出現(xiàn)中間明顯空洞——那個(gè)空洞就是欄間距。實(shí)際操作時(shí)我會(huì)按詞級(jí) bbox 的中線(x0 x1) / 2做投影也可以按行級(jí)單位做。統(tǒng)計(jì)每個(gè) x 區(qū)間內(nèi)的字符數(shù)或詞數(shù)再用一個(gè)閾值判斷空洞是否足夠?qū)捵銐驅(qū)捑颓蟹謾凇＿@個(gè)算法簡單有效尤其適用于規(guī)則排版的論文頁。還有一種老方法是找頁面里所有文字塊的左上角 x 坐標(biāo)做聚類比如 KMeans 或類似 DBSCAN 的密度聚類。聚類數(shù)大于 1 且塊之間水平分布明顯分離時(shí)就判定為多欄。但聚類對(duì)噪聲敏感而且需要預(yù)設(shè)類別數(shù)。相比之下投影直方圖的解釋更強(qiáng)也更容易調(diào)試所以我先用投影不行再上聚類。3. 工具選型與環(huán)境準(zhǔn)備工具選型決定了后邊所有代碼的寫法所以我單獨(dú)開一節(jié)講。我做 PDF 解析這幾年試過一堆庫最后在 RAG 場景里最順手的組合是 PyMuPDF 負(fù)責(zé)版面解析pdfplumber 做表格和高精度文本時(shí)需要時(shí)備用PaddleOCR 負(fù)責(zé)掃描件 OCR。3.1 工具鏈對(duì)比PyMuPDF、pdfplumber、PaddleOCRPyMuPDF 的優(yōu)勢是快安裝包里自帶了 MuPDF 渲染引擎能同時(shí)拿文本、坐標(biāo)、字體信息還能直接渲染頁面成圖片。用page.get_text(words)一行就能拿到詞級(jí) bbox性能很強(qiáng)適合批量解析。pdfplumber 的優(yōu)勢是表格抽取精細(xì)能把線框表格還原成行列結(jié)構(gòu)。但它基于 pdfminer速度偏慢遇到幾百頁的大文件容易磨嘰。我只在需要處理表格時(shí)調(diào)用日常文本抽取不用它。PaddleOCR 是目前我用下來中文掃描件識(shí)別準(zhǔn)確率最穩(wěn)的而且能輸出每個(gè)文本檢測框的坐標(biāo)和置信度。缺點(diǎn)是依賴 PaddlePaddle 環(huán)境安裝體積大。如果不想引入重依賴也可以拿 Tesseract 頂一頂?shù)形淖R(shí)別效果要差一些尤其是彎曲、低分辨率的文字。工具對(duì)比我用一個(gè)表說清楚工具定位優(yōu)點(diǎn)缺點(diǎn)適用場景PyMuPDF文本與版面快、能拿詞級(jí) bbox、渲染頁面表格還原弱原生 PDF、批量解析pdfplumber精細(xì)表格表格結(jié)構(gòu)化好、坐標(biāo)完整慢表格密集的 PDFPaddleOCROCR中文好、出檢測框依賴大、重掃描件、帶水印圖片文本TesseractOCR 備用輕量中文略差服務(wù)器環(huán)境受限時(shí)3.2 環(huán)境安裝與一個(gè)小坑我先給一套最小依賴Python 3.9 以上都行pip install pymupdf pip install paddlepaddle paddleocr pip install pdfplumber pip install opencv-python numpy裝 PaddleOCR 的時(shí)候有個(gè)容易踩的坑新版本默認(rèn)使用paddle后端如果本機(jī) Python 剛好是 3.12 或者缺少某些編譯庫可能會(huì)報(bào)一堆動(dòng)態(tài)鏈接錯(cuò)誤。我當(dāng)時(shí)的解決方法是先裝 CPU 版 PaddlePaddle再裝 paddleocr并且把模型下載路徑設(shè)置到有寫權(quán)限的目錄避免在服務(wù)器上用 root 跑下載到/root/.paddleocr。這一步看似無關(guān)緊要但卡住的人不在少數(shù)尤其是公司內(nèi)網(wǎng)環(huán)境模型下載失敗會(huì)直接中斷整個(gè)解析流程。裝完之后可以做一次冒煙測試拿一頁 PDF 試提取詞級(jí) bbox確認(rèn)坐標(biāo)不是全零、文字不是亂碼再進(jìn)下一步。4. 實(shí)戰(zhàn)用 bbox 完成多欄 PDF 的重排現(xiàn)在進(jìn)入正文戲。目標(biāo)是把雙欄論文頁面重排成正確的從上到下、從左到右的閱讀順序。我用一個(gè)簡化但真實(shí)可跑的流程先提取詞級(jí) bbox再做列檢測最后按列和行重排。4.1 提取詞級(jí) bbox第一手坐標(biāo)長什么樣用 PyMuPDF 提取每頁的詞級(jí)信息非常簡單import fitz def extract_words(page): return page.get_text(words) def draw_debug_boxes(page, words, out_path): for w in words: x0, y0, x1, y1 w[:4] page.draw_rect(fitz.Rect(x0, y0, x1, y1), color(1, 0, 0), width0.5) page.get_pixmap(dpi100).save(out_path)get_text(words)返回的每條記錄包含 x0、y0、x1、y1、word、block_no、line_no、word_no。注意這里的 word 是按空白拆分的結(jié)果中文沒有問題但英文里的連字符和跨行斷詞需要額外處理。拿到坐標(biāo)之后我建議立刻做一步調(diào)試把詞級(jí) bbox 畫回頁面渲染成 PNG。這一步的重要性怎么強(qiáng)調(diào)都不過分。有一次我發(fā)現(xiàn)某頁文本抽出來順序亂畫框之后才發(fā)現(xiàn)那頁其實(shí)是三欄但中間欄是極窄的邊注。不畫框靠肉眼很難看出這類問題。4.2 列檢測算法投影直方圖的思路列檢測我采用“x 坐標(biāo)投影”的算法。核心是統(tǒng)計(jì)每一列 x 區(qū)間內(nèi)的字符密度找到明顯空洞作為欄分隔線。實(shí)現(xiàn)時(shí)不需要真的生成圖片直接用詞級(jí) bbox 統(tǒng)計(jì)即可def detect_columns(words, page_width, gap_threshold30): # 取每個(gè)詞的橫向中線 centers [(x0 x1) / 2 for x0, y0, x1, y1, *_ in words] # 按中線排序后找相鄰中心之間的空隙 centers.sort() gaps [] for i in range(1, len(centers)): gap centers[i] - centers[i - 1] if gap gap_threshold: gaps.append((centers[i - 1], centers[i], gap)) if len(gaps) 2: midpoints [(g[0] g[1]) / 2 for g in gaps] return midpoints # 列分隔點(diǎn) return []這個(gè)簡化版適合大多數(shù)雙欄頁面。它的邏輯是雙欄論文的兩欄之間通常有一個(gè) 20 到 40 點(diǎn)的空白溝足夠大就能被檢測到。如果文字字號(hào)大、行間距寬閾值可以調(diào)大一些如果表格密集或頁邊距混亂閾值調(diào)小但也要接受誤報(bào)的可能。實(shí)際生產(chǎn)里我不會(huì)只靠這一個(gè)算法而是結(jié)合幾個(gè)特征欄間空洞寬度、左右兩欄的文字寬度是否接近、同一 y 行內(nèi)是否出現(xiàn)左右兩欄的文字同時(shí)存在。只有同時(shí)滿足這些條件才判定為多欄。這樣能避免把“標(biāo)題跨欄”或“表格列間空白”誤判成真正的欄。4.3 Z 字排序與文本拼接檢測出欄位之后接下來就是把文本按視覺順序拼接。我用兩個(gè)階段先給每個(gè)詞分配欄號(hào)再在欄內(nèi)按 y 坐標(biāo)排序。最后按左欄到右欄的順序輸出。def reassign_columns(words, column_split_x): new_words [] for w in words: x0, y0, x1, y1, word w[:5] cx (x0 x1) / 2 col 0 for split in column_split_x: if cx split: col 1 else: break new_words.append((col, y0, w)) new_words.sort(keylambda r: (r[0], r[1])) return new_words def build_text(reordered_words): lines [] last_col None last_y None line_parts [] for col, y0, w in reordered_words: if (last_col is not None and col ! last_col) or (last_y is not None and abs(y0 - last_y) 5): lines.append( .join(line_parts)) line_parts [] line_parts.append(w[4]) last_col col last_y y0 lines.append( .join(line_parts)) return \n.join(lines)這個(gè)流程有幾個(gè)細(xì)節(jié)要注意。第一判斷同一行時(shí)用的 y 坐標(biāo)不能只比 y0因?yàn)橥恍形淖值淖痔?hào)不同基線位置會(huì)有偏差最好允許 5 到 8 點(diǎn)的誤差。第二詞之間的空格偶爾會(huì)丟join的時(shí)候最好保留但中文不需要空格英文必須保留所以最好根據(jù)目標(biāo)語言調(diào)整拼接規(guī)則。第三遇到跨欄的大標(biāo)題時(shí)標(biāo)題 x 方向跨了整頁列檢測后會(huì)把它分配到第一欄這沒問題但需要把它單獨(dú)識(shí)別為“全欄標(biāo)題”否則左欄正文會(huì)跟標(biāo)題混在一起。我的經(jīng)驗(yàn)是如果一個(gè)文本行的寬度超過頁面寬度的 80%就先提取出來當(dāng)作獨(dú)立段落不參與欄內(nèi)排序。排序完成后文本流基本接近人類閱讀順序。再用這個(gè)文本流去做切塊和向量化RAG 的召回質(zhì)量會(huì)明顯好轉(zhuǎn)。5. 實(shí)戰(zhàn)水印 PDF 的過濾水印比多欄更陰險(xiǎn)。因?yàn)楹芏嗨≡陧撁嫔鲜前胪该鞯囊曈X上不影響閱讀但一旦被抽成文本就成了污染源。下面按水印的形態(tài)和處理方式拆開講。5.1 水印在 PDF 對(duì)象層的四種形態(tài)第一種是文本型水印直接在頁面上放置一串重復(fù)的文本對(duì)象顏色淺、字號(hào)不定、角度可能是斜的。PyMuPDF 的get_text(dict)能返回每個(gè) span 的文本、字體、字號(hào)、顏色和透明度。第二種是圖形型水印用矢量圖形拼出來的公司 Logo 或背景底紋文本抽取拿不到但渲染時(shí)能看到。第三種是圖片型水印水印作為半透明 PNG 或 JPEG 圖像疊加在頁面上文本抽取拿不到。第四種是復(fù)合水印既包含文本又包含圖片多用于公文和官方聲明。對(duì) RAG 來說真正會(huì)破壞文本流的是第一種和第四種里的文本部分。圖形和圖片水印如果不影響 OCR就不用太操心如果影響就需要在圖像層做去水印。5.2 用 bbox 加樣式特征過濾水印針對(duì)文本型水印我總結(jié)了一套“四看”規(guī)則。一看重復(fù)性水印文本通常每一頁都在同一個(gè)位置附近出現(xiàn)或者同一頁內(nèi)多次出現(xiàn)二看位置比如頁面底部、頁面正中央、斜穿頁面三看顏色水印一般是非黑色或者低對(duì)比度顏色四看透明度PyMuPDF 在dict模式下能拿到 span 的opacity半透明的對(duì)象很可疑。舉個(gè)例子某 PDF 每頁底部都有“DRAFT”字樣坐標(biāo)基本在(page_width*0.3, page_height*0.92)附近顏色是灰色字號(hào)固定。只要把全頁詞按 bbox 聚類出現(xiàn)頻率高且位置集中就能自動(dòng)識(shí)別。我用一段代碼說明過濾思路def is_watermark_span(span, page_width, page_height): bbox span[bbox] if bbox[3] page_height * 0.9: # 底部區(qū)域 if span.get(opacity, 1) 0.5: return True if span[color] not in [(0, 0, 0), (1, 0, 0)]: return True # 頁面中央的大范圍重復(fù)文字 return False這里color是 sRGB 顏色值PyMuPDF 默認(rèn)以 8 位整數(shù)表示。黑色是 0白色是 16777215。水印常見的灰色大約在 8421504 附近。你不需要死記這些值關(guān)鍵是建立“正文默認(rèn)黑色且不透光”的基線凡是偏離基線的都放到待剔除列表里。我踩過一個(gè)坑有些水印是“透明墨粉”處理過的實(shí)際字體顏色是黑色但透明度很低也有一些正文段落用了灰色高亮。所以“四看”規(guī)則一定要組合判斷單一規(guī)則容易誤殺。比如正文里有一條灰色注釋位置不在重復(fù)區(qū)域那就不該刪。5.3 掃描件里的水印OCR 和圖片雙重處理如果 PDF 是掃描件文本抽取拿不到內(nèi)容只能走 OCR。水印會(huì)直接出現(xiàn)在圖像上OCR 識(shí)別的時(shí)候可能會(huì)把水印文字一起識(shí)別出來。更麻煩的是水印文字覆蓋了正文區(qū)域比如“官方文件”斜跨整頁導(dǎo)致正文被遮擋OCR 結(jié)果里既有水印又有殘缺的正文。我的處理方法是兩步走。第一步先用 PaddleOCR 的檢測框輸出所有文本區(qū)域得到每個(gè)文本框的 bbox 和置信度。第二步根據(jù) bbox 的位置和面積判斷哪些框是水印。例如水印通常面積大、傾斜角明顯、每頁重復(fù)出現(xiàn)、識(shí)別置信度忽高忽低正文框則位置規(guī)整、字?jǐn)?shù)均衡。不斷言 OCR 能精準(zhǔn)“去掉”水印但至少能在文本流里把水印文本過濾掉。圖像層的水印我一般不做像素修復(fù)因?yàn)槿菀装颜囊残藓辉跇O少數(shù)必須展示截圖的場景里我才會(huì)用 OpenCV 的 inpaint 做局部修復(fù)。給一個(gè) PaddleOCR 快速調(diào)用的示例from paddleocr import PaddleOCR ocr PaddleOCR( use_angle_clsTrue, langch, show_logFalse, ocr_versionPP-OCRv4 ) result ocr.ocr(page.png, clsTrue) # result[0] 里每一項(xiàng)是 [box, (text, score)] # box 是四個(gè)角點(diǎn)坐標(biāo)可以算 bbox拿到檢測框之后把每頁出現(xiàn)的檢測框按坐標(biāo)重疊度和文本內(nèi)容聚類。如果同一個(gè)文本比如“水印”或“機(jī)密”在超過 90% 的頁面里反復(fù)出現(xiàn)并且位置相近我就把它加入全局過濾詞表。這個(gè)“全局重復(fù)檢測”是掃描件水印過濾里最實(shí)用的一招比單純看位置可靠得多。6. 完整實(shí)現(xiàn)從 PDF 到可入庫文本的流水線前面幾節(jié)把關(guān)鍵技術(shù)點(diǎn)拆開了這一節(jié)我給出一個(gè)能直接抄的流水線整體結(jié)構(gòu)。它把多欄重排、水印過濾、掃描件 OCR 兜底整合在一起最終輸出干凈的文本文件和對(duì)應(yīng)的頁面信息方便下游切片。6.1 流水線結(jié)構(gòu)與順序我設(shè)定的處理順序是先判斷頁面是原生文本還是掃描件再分別走兩條路。原生文本頁走“提取詞級(jí) bbox - 水印過濾 - 列檢測 - 排序拼文本”掃描件頁走“渲染圖片 - Ocr - 水印過濾 - 列檢測 - 排序拼文本”。最后統(tǒng)一輸出。這個(gè)順序是有講究的。水印過濾必須放在列檢測之前因?yàn)樗⊥ǔM跨多欄或者獨(dú)立于欄結(jié)構(gòu)不先刪掉會(huì)干擾列投影。列檢測需要干凈的文字分布否則水印的“中央大字”會(huì)讓投影直方圖出現(xiàn)偽欄位。流程圖我不用畫了直接看代碼結(jié)構(gòu)更實(shí)在。6.2 核心代碼從頁面到干凈文本import fitz from paddleocr import PaddleOCR class PDFParser: def __init__(self): self.ocr PaddleOCR(use_angle_clsTrue, langch, show_logFalse, ocr_versionPP-OCRv4) def parse_page(self, page): text page.get_text(words) if not text: page_pix page.get_pixmap(dpi150) page_pix.save(temp_page.png) ocr_data self.ocr.ocr(temp_page.png, clsTrue) words self._ocr_to_words(ocr_data) else: words self._words_to_struct(text) words self._filter_watermark(words, page) columns self._detect_columns(words, page.rect.width) reordered self._sort_by_columns(words, columns) return self._to_text(reordered)這段代碼故意寫得精簡重點(diǎn)在函數(shù)之間的銜接。每一個(gè)函數(shù)就是你前面看到的核心邏輯。如果你想一次性跑通還需要補(bǔ)_ocr_to_words和_words_to_struct兩個(gè)轉(zhuǎn)換函數(shù)把 OCR 輸出或 PyMuPDF 輸出統(tǒng)一成(x0, y0, x1, y1, text, page_id)的結(jié)構(gòu)。統(tǒng)一結(jié)構(gòu)是整條流水線最重要的設(shè)計(jì)決定它讓兩種數(shù)據(jù)源可以共用后面的水印過濾和列檢測邏輯。6.3 質(zhì)量評(píng)估怎么知道自己做對(duì)了解析完不等于解析對(duì)必須有一個(gè)可以量化的評(píng)估辦法。我常用三個(gè)指標(biāo)。第一是“閱讀順序還原率”隨機(jī)抽 20 頁人工看重排后的文本流統(tǒng)計(jì)連續(xù)語義片段正確拼接的數(shù)量占比。第二是“水印殘留率”檢測最終文本里是否還包含已知水印詞比如“機(jī)密”“DRAFT”等出現(xiàn)次數(shù)除以總頁數(shù)理想情況是接近 0。第三是“切塊語義完整性”把重排文本切塊后讓檢索系統(tǒng)跑一組預(yù)置問題人工判斷召回內(nèi)容里是否出現(xiàn)“一句話被硬生生截?cái)唷钡膲K。我還會(huì)做一個(gè)更粗暴的端到端測試用同一個(gè)文檔解析結(jié)果去做 RAG 問答分別對(duì)比解析前和解析后的答案質(zhì)量。如果修復(fù)解析后答案的引用片段明顯更完整就說明 bbox 這一層的功夫沒有白花。這個(gè)測試看起來不嚴(yán)謹(jǐn)?shù)珜?duì)業(yè)務(wù)方最有說服力。7. 常見問題與排查實(shí)錄這節(jié)把我在實(shí)戰(zhàn)里遇到的高頻問題整理成速查每個(gè)問題都附上我當(dāng)時(shí)的排查過程和最終解決方案。7.1 表格、首行縮進(jìn)和浮動(dòng)塊的誤判表格是多欄檢測的頭號(hào)干擾項(xiàng)。一個(gè)三列寬的表可能會(huì)被誤判成三欄但表格內(nèi)部橫向關(guān)系比列更重要。我的處理辦法是在列檢測之前先用 pdfplumber 或者 PyMuPDF 的find_tables()識(shí)別表格區(qū)域把表格 bbox 整體摳出來不參與列投影。等到文本重排完成之后再把表格內(nèi)容按單獨(dú)的結(jié)構(gòu)追加到文本流里。這樣既不會(huì)破壞正文的欄位邏輯也不會(huì)丟失表格語義。首行縮進(jìn)也很坑。中文論文常見首行縮進(jìn)兩個(gè)字符但 bbox 計(jì)算的是詞框縮進(jìn)會(huì)讓每一行的開頭 x 坐標(biāo)參差不齊。如果我的行合并邏輯只看 x0就會(huì)把縮進(jìn)造成的小位移誤當(dāng)成另起一行。解決辦法是放寬行合并閾值只看 y 坐標(biāo)是否接近不要求 x0 嚴(yán)格單調(diào)。這點(diǎn)在build_text函數(shù)里已經(jīng)體現(xiàn)。7.2 中文與英文混排中的 bbox 差異中英文混排是另一個(gè)容易翻車的場景。中文詞檢測依賴分詞結(jié)果PyMuPDF 的get_text(words)對(duì)中文往往會(huì)把整句當(dāng)作一個(gè)“詞”這會(huì)導(dǎo)致 bbox 很大造成列投影和行合并的偏差。我剛碰到這個(gè)問題時(shí)也懵了為什么有些頁面重排后列檢測總是多出一欄查了半天才發(fā)現(xiàn)某段中文長句的 bbox 橫跨到了旁邊的欄把欄間空洞堵住了。解決辦法有兩個(gè)一是用get_text(dict)按 span 提取因?yàn)?span 是按字體和樣式切分的中文 span 通常更合理二是對(duì)中文文本先不做詞級(jí)處理直接按行級(jí) bbox 走列檢測。實(shí)踐下來第二種更穩(wěn)畢竟對(duì)中文來說行才是排版的基本單元。7.3 性能問題與緩存經(jīng)驗(yàn)2000 篇 PDF 動(dòng)輒幾千頁每頁都跑 OCR 的話時(shí)間成本很嚇人。我一開始沒做緩存結(jié)果同一批文件反復(fù)解析了好幾遍CPU 全被吃掉。后來我加了一層緩存以 PDF 文件的哈希值和頁碼為 key把解析出來的 clean text 存成 JSON。第二次解析時(shí)直接讀取緩存只有當(dāng) PDF 文件變化時(shí)才重新跑。另外OCR 對(duì)低 DPI 圖片的識(shí)別率會(huì)驟降但也別盲目上 300 DPI因?yàn)殇秩緯r(shí)間和顯存占用會(huì)成倍增長。我實(shí)測 150 DPI 對(duì)大多數(shù)掃描件已經(jīng)夠用只有字體小于小五號(hào)或者圖片模糊的才需要提升到 200 到 300。處理時(shí)按頁釋放對(duì)象避免內(nèi)存被幾十張大圖撐爆。8. 實(shí)操體會(huì)與擴(kuò)展思路我在實(shí)際項(xiàng)目里最深的體會(huì)是RAG 的文檔解析質(zhì)量不取決于用了多強(qiáng)的模型而是取決于有沒有認(rèn)真對(duì)待 bbox 這類基礎(chǔ)信息。很多團(tuán)隊(duì)把大量精力花在調(diào) embedding 模型上卻忽略了文本源頭已經(jīng)亂成一團(tuán)。embedding 再強(qiáng)也救不了順序錯(cuò)亂的字符流。關(guān)于后續(xù)擴(kuò)展我認(rèn)為這套 bbox 思路還能往幾個(gè)方向深挖。第一結(jié)合版面模型把標(biāo)題層級(jí)抽出來給切塊提供結(jié)構(gòu)化上下文讓 RAG 的召回具備更細(xì)的段落邊界。第二把水印過濾和“圖像敏感區(qū)域”檢測結(jié)合在解析時(shí)直接屏蔽含審核敏感信息的區(qū)域減輕下游合規(guī)壓力。第三把多欄重排和表格識(shí)別整合成流水線算子封裝成服務(wù)每次解析結(jié)果都輸出一份帶 bbox 的 JSON 文檔方便調(diào)試和回放。最后再分享一個(gè)小技巧很多問題頁面不要急著加復(fù)雜模型先用 bbox 畫框把每頁的真實(shí)版面看一遍。頁面上一個(gè)不起眼的邊注、一個(gè)跨欄表格、一段被手動(dòng)旋轉(zhuǎn)的文字都會(huì)讓規(guī)則失效。你用視覺排查一次比讀十次文檔都管用。先把絕大多數(shù)常規(guī)頁面穩(wěn)定處理好再把異常頁面列入慢速兜底通道這套工程思路比一上來就追求“萬能解析”要?jiǎng)?wù)實(shí)得多。