1. 為什么我要在 Python 3.7 上死磕文檔掃描 OCR先亮明背景。我手頭有一批紙質(zhì)合同和票據(jù)需要電子化歸檔數(shù)量大概在兩千頁上下。找現(xiàn)成的商業(yè)服務(wù)當(dāng)然省事但數(shù)據(jù)要過別人的服務(wù)器心里總歸不踏實(shí)而且有些票據(jù)格式很偏通用接口識(shí)別率并不理想。于是我決定自己搭一套文檔掃描 OCR流水線跑在本地一臺(tái)舊筆記本上環(huán)境就鎖定Python 3.7——不是我不想用新版本而是這臺(tái)機(jī)器上還跑著幾個(gè)老項(xiàng)目依賴鎖死在 3.7動(dòng)不了。這個(gè)標(biāo)題看起來簡單真做起來你會(huì)發(fā)現(xiàn)它其實(shí)是三件事疊在一起文檔掃描把手機(jī)或掃描儀拍的歪斜照片矯正成規(guī)整的文檔圖、OCR把圖里的文字摳出來、以及后處理把摳出來的文字整理成能用的結(jié)構(gòu)化數(shù)據(jù)。很多人一上來就pip install一個(gè) OCR 庫然后image_to_string結(jié)果發(fā)現(xiàn)識(shí)別出來的東西錯(cuò)得離譜就下結(jié)論說開源 OCR 不行。問題往往不在 OCR 引擎本身而在前面那一步——你喂給它的圖質(zhì)量太差了。這篇文章適合誰看如果你手頭有紙質(zhì)文檔要批量電子化又不想把數(shù)據(jù)傳出去或者你正在做一個(gè)票據(jù)識(shí)別、證件識(shí)別、表單錄入的小工具再或者你只是好奇掃描全能王那類 App 背后的原理——那這篇內(nèi)容應(yīng)該能幫到你。我會(huì)把整條流水線拆開講包括每一步為什么這么做、參數(shù)怎么定、以及我在兩千頁實(shí)測里踩過的那些坑。全程基于 Python 3.7代碼可以直接抄。需要提前說明的是下面涉及的具體閾值、核大小這些參數(shù)都是我在自己那批文檔上試出來的經(jīng)驗(yàn)值你的場景比如文檔底色、字體、拍攝角度不同需要微調(diào)。我會(huì)把調(diào)整的思路也講清楚而不是只丟一堆數(shù)字給你。2. 整條流水線的骨架先想清楚數(shù)據(jù)怎么流2.1 從一張歪照片到一行可用文字中間到底發(fā)生了什么在動(dòng)手寫代碼之前我習(xí)慣先把數(shù)據(jù)流畫在紙上。文檔掃描 OCR 這條鏈路我最終定下來是五個(gè)階段圖像預(yù)處理灰度化、去噪、二值化把彩色照片變成干凈的黑白圖。邊緣檢測與透視矯正找到文檔的四個(gè)角把歪斜的四邊形拉平成正矩形。版面分析區(qū)分文字區(qū)域、表格區(qū)域、圖片區(qū)域決定 OCR 的調(diào)用順序。文字識(shí)別調(diào)用 OCR 引擎逐區(qū)域識(shí)別。后處理與結(jié)構(gòu)化糾錯(cuò)、合并、按業(yè)務(wù)規(guī)則輸出 JSON 或 CSV。這個(gè)順序不是拍腦袋定的。早期我圖省事跳過第 2 步直接識(shí)別結(jié)果一張傾斜 15 度的 A4 紙識(shí)別率直接從 95% 掉到 60% 出頭。原因很簡單主流 OCR 引擎不管是 Tesseract 還是 PaddleOCR在訓(xùn)練時(shí)用的都是水平文本行你給它一個(gè)斜的它的行分割算法就崩了。所以透視矯正是整條鏈路里性價(jià)比最高的一步花十分鐘寫代碼能省下后面幾小時(shí)的糾錯(cuò)。2.2 Python 3.7 環(huán)境下庫的選型與版本坑Python 3.7 是個(gè)分水嶺版本很多庫的新版本已經(jīng)不支持它了。我在選型時(shí)踩的第一個(gè)坑就是直接pip install opencv-python裝到了最新版結(jié)果 import 時(shí)報(bào)undefined symbol因?yàn)樾掳?OpenCV 編譯時(shí)用的 C 標(biāo)準(zhǔn)在舊系統(tǒng)上不兼容。最終我鎖定的版本組合是這樣的庫版本用途備注opencv-python4.5.5.64圖像預(yù)處理、透視變換4.6 開始對 3.7 支持變差numpy1.21.6矩陣運(yùn)算1.22 要求 Python 3.8pytesseract0.3.10Tesseract 的 Python 封裝需另裝 Tesseract 引擎Pillow9.5.0圖像讀寫、格式轉(zhuǎn)換10.x 不再支持 3.7paddleocr2.6.1.3中文識(shí)別備選安裝包較大按需提示裝 OpenCV 時(shí)如果遇到編譯問題優(yōu)先用pip install opencv-python4.5.5.64指定版本別用--upgrade。我在這上面浪費(fèi)了整整一個(gè)下午。選 Tesseract 還是 PaddleOCR我的經(jīng)驗(yàn)是純英文、印刷體、版面規(guī)整的文檔Tesseract 足夠而且輕量中文、混排、有表格的PaddleOCR 的中文模型明顯更強(qiáng)。我最后是兩個(gè)都裝了按文檔類型分流——英文合同走 Tesseract中文票據(jù)走 PaddleOCR。這個(gè)分流策略后面會(huì)詳細(xì)講。3. 圖像預(yù)處理90% 的識(shí)別錯(cuò)誤都出在這一步3.1 灰度化與自適應(yīng)二值化為什么不能用全局閾值拿到一張手機(jī)拍的文檔照片第一步是灰度化。這個(gè)沒什么好說的cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)一行搞定。真正有講究的是二值化。新手最容易犯的錯(cuò)是用全局閾值比如cv2.threshold(gray, 127, 255, cv2.THRESH_BINARY)。為什么不行因?yàn)槭謾C(jī)拍照必然有光照不均——左上角亮、右下角暗是常態(tài)。你用一個(gè)固定閾值 127亮的地方文字全糊成一片白暗的地方背景全變成黑。我實(shí)測過同一張圖全局閾值下識(shí)別率 72%換成自適應(yīng)閾值后直接到 91%。自適應(yīng)閾值的核心思想是每個(gè)像素的閾值由它周圍一小塊區(qū)域的統(tǒng)計(jì)量決定而不是全圖統(tǒng)一。代碼長這樣import cv2 import numpy as np def preprocess_image(image_path): img cv2.imread(image_path) gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) # 自適應(yīng)閾值blockSize 必須是奇數(shù)C 是常數(shù)修正項(xiàng) binary cv2.adaptiveThreshold( gray, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, blockSize31, C10 ) return binaryblockSize31和C10這兩個(gè)值怎么來的blockSize是計(jì)算閾值時(shí)考慮的鄰域大小太小比如 11會(huì)把文字筆畫本身也算進(jìn)去導(dǎo)致筆畫中間被掏空太大比如 101就退化成全局閾值了。31 是我在 300 DPI 掃描件上試出來的平衡點(diǎn)。C是從計(jì)算出的均值里減去的常數(shù)用來抑制噪點(diǎn)10 是個(gè)比較穩(wěn)的起點(diǎn)噪點(diǎn)多就往上加。3.2 去噪與形態(tài)學(xué)操作別把文字也一起抹掉了二值化之后圖上通常還有一堆椒鹽噪點(diǎn)小黑點(diǎn)小白點(diǎn)。這時(shí)候很多人會(huì)直接上高斯模糊結(jié)果文字邊緣也糊了。我的做法是先中值濾波去椒鹽再用形態(tài)學(xué)開運(yùn)算去掉細(xì)小的孤立噪點(diǎn)# 中值濾波核大小 3 對文字損傷最小 denoised cv2.medianBlur(binary, 3) # 開運(yùn)算先腐蝕后膨脹去掉小噪點(diǎn)但保留文字主體 kernel np.ones((2, 2), np.uint8) opened cv2.morphologyEx(denoised, cv2.MORPH_OPEN, kernel)這里有個(gè)反直覺的點(diǎn)形態(tài)學(xué)操作的核不能太大。我一開始用了 3x3 的核結(jié)果細(xì)體字的筆畫比如一、十直接被腐蝕沒了。后來改成 2x2效果好很多。如果你處理的文檔字體特別細(xì)甚至可以考慮跳過開運(yùn)算只做中值濾波。還有一個(gè)坑去噪和銳化是矛盾的。去噪越狠文字邊緣越鈍OCR 越容易把0認(rèn)成O、把1認(rèn)成l。我的經(jīng)驗(yàn)是寧可保留一點(diǎn)噪點(diǎn)也不要過度平滑。判斷標(biāo)準(zhǔn)很簡單——把處理后的圖放大看文字邊緣如果筆畫還是清晰的黑色實(shí)心就對了如果邊緣發(fā)灰、發(fā)虛就是處理過頭了。3.3 實(shí)測對比不同預(yù)處理組合對識(shí)別率的影響為了讓你有個(gè)直觀感受我拿同一張中文票據(jù)做了組對比實(shí)驗(yàn)識(shí)別引擎統(tǒng)一用 PaddleOCR結(jié)果如下預(yù)處理方案識(shí)別準(zhǔn)確率耗時(shí)(ms)原圖直接識(shí)別58%420僅灰度化67%380灰度全局二值化72%390灰度自適應(yīng)二值化89%410灰度自適應(yīng)中值濾波91%430灰度自適應(yīng)中值開運(yùn)算90%445可以看到自適應(yīng)二值化是那個(gè)質(zhì)變點(diǎn)從 72% 跳到 89%。后面的濾波和形態(tài)學(xué)只是錦上添花甚至開運(yùn)算因?yàn)閾p傷了細(xì)筆畫反而掉了 1 個(gè)百分點(diǎn)。所以如果你時(shí)間有限優(yōu)先把自適應(yīng)二值化調(diào)好其他可以慢慢來。4. 透視矯正把歪的文檔拉正的核心算法4.1 怎么找到文檔的四個(gè)角透視矯正的前提是找到文檔在照片里的四個(gè)頂點(diǎn)。主流做法是邊緣檢測 輪廓查找 多邊形逼近。思路是文檔通常是一塊面積最大的、近似四邊形的亮色區(qū)域。def find_document_corners(binary_img): # 邊緣檢測 edges cv2.Canny(binary_img, 50, 150) # 膨脹一下讓斷開的邊緣連起來 edges cv2.dilate(edges, np.ones((3, 3), np.uint8), iterations1) # 找輪廓 contours, _ cv2.findContours( edges, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE ) # 按面積排序取最大的幾個(gè) contours sorted(contours, keycv2.contourArea, reverseTrue)[:5] for c in contours: # 多邊形逼近epsilon 是精度參數(shù) peri cv2.arcLength(c, True) approx cv2.approxPolyDP(c, 0.02 * peri, True) # 如果逼近出 4 個(gè)點(diǎn)就認(rèn)為是文檔 if len(approx) 4: return approx.reshape(4, 2) return NoneapproxPolyDP的epsilon參數(shù)這里是0.02 * peri是關(guān)鍵。它控制逼近精度太小四邊形會(huì)被逼近成很多個(gè)點(diǎn)太大四邊形會(huì)被簡化成三角形。0.02 倍周長是個(gè)經(jīng)驗(yàn)值對大多數(shù)文檔都適用。如果你的文檔邊緣有破損或卷曲可以適當(dāng)放大到 0.03。4.2 四個(gè)點(diǎn)的排序邏輯以及為什么順序錯(cuò)了圖就廢了找到四個(gè)點(diǎn)之后必須按固定順序排列通常是左上、右上、右下、左下否則透視變換會(huì)把圖扭成麻花。排序邏輯我用的是坐標(biāo)和差法def order_points(pts): rect np.zeros((4, 2), dtypefloat32) s pts.sum(axis1) diff np.diff(pts, axis1) # 左上角xy 最小 rect[0] pts[np.argmin(s)] # 右下角xy 最大 rect[2] pts[np.argmax(s)] # 右上角x-y 最小diff 是 y-x取最小 rect[1] pts[np.argmin(diff)] # 左下角x-y 最大 rect[3] pts[np.argmax(diff)] return rect這個(gè)方法的原理很直觀在圖像坐標(biāo)系里原點(diǎn)在左上左上角的 xy 一定最小右下角一定最大而右上角的 x 大 y 小所以 x-y 最大注意np.diff算的是 y-x所以取最小。我見過有人用最左的點(diǎn)是左上這種邏輯遇到文檔旋轉(zhuǎn)超過 45 度就全亂了。坐標(biāo)和差法對任意旋轉(zhuǎn)都穩(wěn)。4.3 透視變換的矩陣計(jì)算與輸出尺寸確定有了排好序的四個(gè)點(diǎn)就可以算變換矩陣了。這里有個(gè)細(xì)節(jié)輸出圖的寬高要根據(jù)四邊形的實(shí)際邊長算不能寫死否則文檔會(huì)被拉伸變形。def four_point_transform(image, pts): rect order_points(pts) (tl, tr, br, bl) rect # 計(jì)算輸出寬度上下邊取最大值 widthA np.linalg.norm(br - bl) widthB np.linalg.norm(tr - tl) maxWidth max(int(widthA), int(widthB)) # 計(jì)算輸出高度左右邊取最大值 heightA np.linalg.norm(tr - br) heightB np.linalg.norm(tl - bl) maxHeight max(int(heightA), int(heightB)) # 目標(biāo)點(diǎn) dst np.array([ [0, 0], [maxWidth - 1, 0], [maxWidth - 1, maxHeight - 1], [0, maxHeight - 1] ], dtypefloat32) M cv2.getPerspectiveTransform(rect, dst) warped cv2.warpPerspective(image, M, (maxWidth, maxHeight)) return warped為什么寬高要取上下邊、左右邊的最大值因?yàn)榕恼諘r(shí)文檔會(huì)有透視形變上邊和下邊長度不一樣。如果取最小值文檔內(nèi)容會(huì)被裁掉取最大值最多是邊緣多留一點(diǎn)白不會(huì)丟內(nèi)容。這個(gè)取舍原則在圖像處理里很常見——寧可多留不可少留。實(shí)測下來透視矯正這一步對傾斜文檔的識(shí)別率提升是決定性的。我做過測試一張傾斜 20 度的文檔不矯正識(shí)別率 61%矯正后 93%。而且矯正后的圖看起來正了后續(xù)的版面分析也好做很多。5. OCR 引擎的調(diào)用策略與參數(shù)調(diào)優(yōu)5.1 Tesseract 的頁面分割模式PSM選錯(cuò)等于白干Tesseract 有一個(gè)極其重要但經(jīng)常被忽略的參數(shù)--psmPage Segmentation Mode。它告訴引擎這張圖是什么版面結(jié)構(gòu)選錯(cuò)了識(shí)別結(jié)果天差地別。常用的幾種模式PSM 值含義適用場景3全自動(dòng)分割默認(rèn)規(guī)整的整頁文檔4假設(shè)是一列可變大小的文本單列排版6假設(shè)是一個(gè)統(tǒng)一的文本塊裁剪好的單段文字7把圖當(dāng)成單行文本單行、標(biāo)題11稀疏文本盡量找文字票據(jù)、表單這種零散文字我的經(jīng)驗(yàn)是整頁合同用 3裁剪后的段落用 6票據(jù)這種文字零散的用 11。有一次我處理一批發(fā)票用默認(rèn)的 3識(shí)別率慘不忍睹換成 11 之后直接起飛。原因是發(fā)票上文字分散、有大片空白PSM 3 的分割算法會(huì)被空白區(qū)域帶偏。調(diào)用代碼import pytesseract def ocr_with_tesseract(image, langeng, psm3): config f--psm {psm} --oem 3 text pytesseract.image_to_string( image, langlang, configconfig ) return text--oem 3是 OCR 引擎模式3 表示默認(rèn)LSTM 傳統(tǒng)引擎混合一般不用改。lang參數(shù)要注意中文是chi_sim中英混排是chi_simeng但混排會(huì)慢不少按需選。5.2 PaddleOCR 的中文優(yōu)勢與初始化開銷PaddleOCR 在中文場景下確實(shí)強(qiáng)尤其是對印刷體中文的識(shí)別準(zhǔn)確率比 Tesseract 高一個(gè)檔次。但它有個(gè)明顯的缺點(diǎn)初始化慢。第一次調(diào)用要加載模型大概 3-5 秒。如果你要處理幾千張圖這個(gè)開銷可以忽略但如果只是偶爾識(shí)別一張?bào)w驗(yàn)就很差。我的做法是把 PaddleOCR 實(shí)例做成全局單例程序啟動(dòng)時(shí)初始化一次后續(xù)復(fù)用from paddleocr import PaddleOCR _ocr_engine None def get_ocr_engine(): global _ocr_engine if _ocr_engine is None: _ocr_engine PaddleOCR( use_angle_clsTrue, # 自動(dòng)糾正文字方向 langch, show_logFalse ) return _ocr_engine def ocr_with_paddle(image): engine get_ocr_engine() result engine.ocr(image, clsTrue) # result 是嵌套列表逐層拆出文字和置信度 lines [] for line in result[0]: text line[1][0] confidence line[1][1] if confidence 0.6: # 置信度過濾 lines.append(text) return \n.join(lines)use_angle_clsTrue這個(gè)參數(shù)建議開著它會(huì)自動(dòng)判斷文字是不是倒的、旋轉(zhuǎn)的對手機(jī)拍的文檔很有用。confidence 0.6這個(gè)過濾閾值是我試出來的——低于 0.6 的識(shí)別結(jié)果基本都是錯(cuò)的與其留著添亂不如直接丟掉后面用業(yè)務(wù)規(guī)則補(bǔ)。5.3 雙引擎分流什么文檔走哪條路前面提到我最后是 Tesseract 和 PaddleOCR 雙引擎。分流規(guī)則很簡單但很實(shí)用純英文、印刷清晰、版面規(guī)整→ Tesseract快且準(zhǔn)。含中文、中英混排、有表格→ PaddleOCR。票據(jù)、發(fā)票、表單→ PaddleOCR PSM 11 的思路PaddleOCR 沒有 PSM但它的檢測模型本身對稀疏文本友好。怎么自動(dòng)判斷走哪條我的做法是先跑一個(gè)輕量的語言檢測——用 Tesseract 的eng模式快速識(shí)別一遍如果識(shí)別出的字符里非 ASCII 占比超過 30%就判定為中文文檔轉(zhuǎn) PaddleOCR 重跑。這個(gè)先探路再?zèng)Q定的策略比無腦上重引擎要省資源。6. 版面分析與后處理讓結(jié)果真正能用6.1 按行聚類把零散的文字塊拼回段落OCR 引擎返回的往往是零散的文字塊位置信息是有的但順序可能是亂的。尤其是 PaddleOCR它返回的是檢測框坐標(biāo)加文字你需要自己按位置排序。我的做法是按 y 坐標(biāo)聚類成行再按 x 坐標(biāo)排序def sort_ocr_results(results, y_threshold10): # results: [(box, (text, conf)), ...] items [] for box, (text, conf) in results: # box 是四個(gè)點(diǎn)的坐標(biāo)取左上角 x min(p[0] for p in box) y min(p[1] for p in box) items.append((x, y, text, conf)) # 先按 y 排序 items.sort(keylambda t: t[1]) # 再把 y 相近的歸為同一行 lines [] current_line [] last_y None for item in items: if last_y is None or abs(item[1] - last_y) y_threshold: current_line.append(item) else: current_line.sort(keylambda t: t[0]) lines.append(current_line) current_line [item] last_y item[1] if current_line: current_line.sort(keylambda t: t[0]) lines.append(current_line) # 拼成文本 return \n.join( .join(t[2] for t in line) for line in lines)y_threshold10是判斷兩個(gè)文字塊是否在同一行的像素閾值。這個(gè)值要跟你的圖像分辨率匹配——300 DPI 的掃描件行高大概 40-50 像素閾值設(shè) 10-15 比較合適如果是低分辨率圖要相應(yīng)調(diào)小。設(shè)太大相鄰兩行會(huì)被合并設(shè)太小同一行會(huì)被拆開。6.2 常見 OCR 錯(cuò)誤的糾正規(guī)則OCR 出來的文字尤其是數(shù)字和英文有幾類高頻錯(cuò)誤。我整理了一份糾錯(cuò)規(guī)則用正則批量處理錯(cuò)誤類型典型表現(xiàn)糾正規(guī)則數(shù)字 0 與字母 O1O0 應(yīng)為 100數(shù)字上下文中 O→0數(shù)字 1 與字母 l/Il23 應(yīng)為 123數(shù)字上下文中 l/I→1數(shù)字 5 與字母 SS00 應(yīng)為 500數(shù)字上下文中 S→5數(shù)字 8 與字母 BB8 歧義結(jié)合上下文判斷小數(shù)點(diǎn)丟失1234 應(yīng)為 12.34金額字段按規(guī)則補(bǔ)import re def correct_ocr_text(text): # 在純數(shù)字串里把常見字母替換成數(shù)字 def fix_numeric(m): s m.group(0) trans str.maketrans(OolISs, 001155) return s.translate(trans) # 匹配長度3的、由數(shù)字和易混字母組成的串 text re.sub(r[0-9OolISs]{3,}, fix_numeric, text) return text這個(gè)規(guī)則要小心用。比如英文單詞 SO 會(huì)被誤傷成 50。所以我的做法是只在特定字段上應(yīng)用——比如金額、日期、編號(hào)這些明確是數(shù)字的字段才跑數(shù)字糾錯(cuò)正文段落不跑。這個(gè)分字段處理的思路比全局糾錯(cuò)安全得多。6.3 輸出結(jié)構(gòu)化數(shù)據(jù)JSON 還是 CSV最后一步是輸出。我的建議是中間結(jié)果存 JSON最終交付看用途。JSON 能保留層級(jí)和字段名方便后續(xù)程序處理CSV 適合直接給業(yè)務(wù)人員看。import json def build_structured_result(lines, doc_typecontract): result { doc_type: doc_type, raw_text: \n.join(lines), fields: {} } # 按文檔類型提取關(guān)鍵字段 if doc_type contract: for line in lines: if 甲方 in line: result[fields][party_a] line.split()[-1].strip() elif 乙方 in line: result[fields][party_b] line.split()[-1].strip() return result字段提取這塊簡單場景用關(guān)鍵詞匹配就夠了復(fù)雜場景比如表格就得上專門的表格識(shí)別模型或者用坐標(biāo)做單元格切分。我處理的那批合同字段比較固定關(guān)鍵詞匹配加正則就搞定了沒必要上重型方案。能用簡單方法解決的別過度設(shè)計(jì)這是我踩了很多坑之后的體會(huì)。7. 兩千頁實(shí)測那些文檔里不會(huì)寫的坑7.1 內(nèi)存泄漏PaddleOCR 連續(xù)調(diào)用會(huì)漲內(nèi)存這個(gè)坑我踩得最慘。批量處理到第 800 多張的時(shí)候程序突然被系統(tǒng) kill 了。查了半天發(fā)現(xiàn)是 PaddleOCR 在連續(xù)調(diào)用時(shí)內(nèi)存緩慢上漲每張圖漲幾 MB累積下來就爆了。解決辦法有兩個(gè)一是分批處理每處理 200 張就重啟一次引擎二是顯式釋放中間變量。我最后用的是分批加重啟def batch_process(image_paths, batch_size200): results [] for i in range(0, len(image_paths), batch_size): batch image_paths[i:ibatch_size] engine get_ocr_engine() for path in batch: results.append(process_single(path, engine)) # 處理完一批釋放引擎 global _ocr_engine _ocr_engine None import gc gc.collect() return results重啟引擎有 3-5 秒開銷但相比程序崩潰重跑這點(diǎn)代價(jià)完全值得。如果你用的是 Tesseract它每次調(diào)用都是獨(dú)立進(jìn)程反而沒這個(gè)問題。7.2 圖像方向EXIF 信息導(dǎo)致的躺平文檔手機(jī)拍的照片很多帶 EXIF 方向信息。用 OpenCV 讀進(jìn)來的時(shí)候它不讀 EXIF所以一張豎著拍的照片讀進(jìn)來可能是橫的。我第一次處理時(shí)就遇到這個(gè)一批圖全是躺著的OCR 識(shí)別率極低。解決方法是讀圖時(shí)用 Pillow 處理 EXIF再轉(zhuǎn)給 OpenCVfrom PIL import Image, ImageOps import numpy as np def read_image_with_exif(path): img Image.open(path) img ImageOps.exif_transpose(img) # 根據(jù) EXIF 自動(dòng)旋轉(zhuǎn) return cv2.cvtColor(np.array(img), cv2.COLOR_RGB2BGR)ImageOps.exif_transpose會(huì)自動(dòng)根據(jù) EXIF 里的方向標(biāo)記旋轉(zhuǎn)圖像。這一行代碼解決了我 90% 的文檔躺平問題。剩下的 10% 是 EXIF 信息丟失的只能靠 OCR 引擎的use_angle_cls兜底。7.3 處理速度優(yōu)化從每張 3 秒到每張 0.8 秒兩千頁如果每張 3 秒就是 100 分鐘。我優(yōu)化到了每張 0.8 秒總耗時(shí)降到 27 分鐘。幾個(gè)關(guān)鍵優(yōu)化點(diǎn)圖像降采樣如果原圖是 4000x3000先縮到 2000x1500 再處理。OCR 對分辨率的需求沒那么高2000 寬足夠速度卻能快一倍多。預(yù)處理用 OpenCV 的原地操作很多cv2函數(shù)支持dst參數(shù)可以避免創(chuàng)建新數(shù)組。多進(jìn)程Python 的 GIL 讓多線程在 CPU 密集任務(wù)上沒用但多進(jìn)程有效。我用multiprocessing.Pool開了 4 個(gè)進(jìn)程速度提升接近 3 倍。from multiprocessing import Pool def process_wrapper(args): path, doc_type args return process_single(path, doc_type) if __name__ __main__: tasks [(p, contract) for p in image_paths] with Pool(processes4) as pool: results pool.map(process_wrapper, tasks)注意多進(jìn)程下每個(gè)進(jìn)程會(huì)各自初始化一份 OCR 引擎內(nèi)存占用會(huì)翻倍。如果你的機(jī)器內(nèi)存緊張進(jìn)程數(shù)要相應(yīng)減少。我那臺(tái)舊筆記本 8G 內(nèi)存開 4 個(gè)進(jìn)程剛好開 6 個(gè)就開始 swap 了。7.4 識(shí)別質(zhì)量的最后一公里人工抽檢策略再好的 OCR 也不可能 100% 準(zhǔn)確。我的做法是按置信度分層抽檢置信度高于 0.9 的抽 5% 人工核對0.7-0.9 的抽 30%低于 0.7 的全部人工核對。這樣既保證了質(zhì)量又不會(huì)讓人工成本失控。具體實(shí)現(xiàn)就是在輸出結(jié)果里帶上置信度然后按閾值分流def split_by_confidence(results, high0.9, mid0.7): high_conf, mid_conf, low_conf [], [], [] for r in results: if r[confidence] high: high_conf.append(r) elif r[confidence] mid: mid_conf.append(r) else: low_conf.append(r) return high_conf, mid_conf, low_conf這套策略跑下來我那兩千頁文檔最終的錯(cuò)誤率控制在 0.5% 以內(nèi)人工核對只花了大概 3 小時(shí)。如果全部人工核對至少得 20 小時(shí)。把人力用在刀刃上這是批量 OCR 項(xiàng)目里最值錢的經(jīng)驗(yàn)。8. 寫在最后的一點(diǎn)個(gè)人體會(huì)這套流水線我前后迭代了大概三周從最初能識(shí)別就行到后來識(shí)別率 95% 以上中間踩的坑基本都寫在上面的章節(jié)里了。如果讓我給正在做類似項(xiàng)目的朋友一句建議那就是別急著調(diào) OCR 引擎的參數(shù)先把圖像預(yù)處理和透視矯正做扎實(shí)。我見過太多人把時(shí)間花在換引擎、調(diào)模型上結(jié)果喂進(jìn)去的圖還是歪的、糊的怎么調(diào)都沒用。另外Python 3.7 雖然老但生態(tài)其實(shí)夠用關(guān)鍵是鎖死版本別讓pip自作主張升級(jí)。我現(xiàn)在的做法是每個(gè)項(xiàng)目都配一個(gè)requirements.txt把版本號(hào)寫死換機(jī)器時(shí)pip install -r requirements.txt一把梭省心。最后分享一個(gè)小技巧如果你處理的文檔類型比較固定比如都是同一種發(fā)票可以把第一張識(shí)別正確的圖存下來當(dāng)模板后續(xù)的圖先跟模板做配準(zhǔn)再按模板的坐標(biāo)去切字段。這樣字段提取的準(zhǔn)確率能再上一個(gè)臺(tái)階比純靠關(guān)鍵詞匹配穩(wěn)得多。這個(gè)思路我在處理一批格式統(tǒng)一的票據(jù)時(shí)用過效果很好值得一試。