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