作為一個長期和文檔數(shù)據(jù)打交道的開發(fā)者我最近又仔細(xì)把 PaddleOCR 的前前后后翻了一遍。原因很簡單手里幾個項(xiàng)目和 OCR 相關(guān)的部分已經(jīng)越來越多地從零散的臨時腳本遷移到 PaddleOCR 作為底座來做。說它是目前 OCR 開源領(lǐng)域里熱度最高的項(xiàng)目基本沒有爭議——GitHub 的數(shù)據(jù)一直立在那里Star 數(shù)穩(wěn)穩(wěn)排在同類項(xiàng)目最前面。熱度歸熱度真正讓我愿意長期用的還是它的工程完成度OCR 從一個需要自己折騰模型訓(xùn)練、調(diào)參、做數(shù)據(jù)集的偏門方向變成了普通后端開發(fā)者也能在十分鐘內(nèi)跑通的組件。這篇文章我會用一套完整的實(shí)操記錄把環(huán)境搭建、核心原理、業(yè)務(wù)落地和踩坑經(jīng)驗(yàn)都過一遍適合正打算用 OCR 做文檔識別、票據(jù)處理或內(nèi)容抽取的開發(fā)者參考。1. Star 數(shù)之外的體驗(yàn)OCR 開源項(xiàng)目的格局變化1.1 一個老問題OCR 告別“需要專屬訓(xùn)練師”的階段聊 Star 數(shù)之前先說一個普遍誤區(qū)Star 多不等于每個功能都好用但它至少代表一個信號——大量開發(fā)者在實(shí)際項(xiàng)目中驗(yàn)證過這條路遇到問題能找到的案例多社區(qū)填過的坑也多。對我這種偏業(yè)務(wù)開發(fā)的工程師來說這比“論文里效果好”重要得多。早在 PaddleOCR 流行之前我做過一段時間的文檔識別需求。當(dāng)時如果要上 OCR通常要面臨兩件事一是把老牌開源 OCR 引擎編譯進(jìn)項(xiàng)目二是準(zhǔn)備一堆訓(xùn)練樣本去適配業(yè)務(wù)字體。老牌引擎的問題不在原理而在工程鏈路太散。它更像一個“識別核心”前面的圖片預(yù)處理、版面分析、文字檢測后面的結(jié)果清洗、結(jié)構(gòu)化都得自己拼。中文場景下效果更是看運(yùn)氣遇到印刷體還行遇到掃描件、手機(jī)拍照、帶背景色的單據(jù)準(zhǔn)確率就開始放飛自我。那時候做 OCR 項(xiàng)目的周期不是按天算是按周算。PaddleOCR 給我的第一感覺是“這是一整套完整方案”文字檢測、方向分類、文本識別三個模型打包在一起裝完就能直接用默認(rèn)支持簡繁中文和英文不用自己造輪子。這種差異不是某一個小功能強(qiáng)了多少而是把整個使用門檻降下來了。從我的經(jīng)驗(yàn)看它能在 GitHub 上拿到頭部 Star 數(shù)核心原因不是所謂“參數(shù)最大”“論文最潮”而是“普通開發(fā)者拿來就能干活”。1.2 為什么我在評估過后愿意換掉原有方案我當(dāng)時專門拉了一個測試集做過對比大概兩百張圖覆蓋截圖、手機(jī)拍攝、掃描件、表格和帶印章的合同。老鏈路結(jié)果需要大量人工修正而 PaddleOCR 開箱即用的版本大多數(shù)場景已經(jīng)能給出可繼續(xù)清洗的結(jié)果。差別最明顯的是中文長文本和復(fù)雜排版老方案經(jīng)常把一行文字切斷或者把標(biāo)點(diǎn)識別成亂碼PaddleOCR 至少能把文本行完整撈出來置信度分?jǐn)?shù)也能幫助后續(xù)篩選。需要說明的是我不認(rèn)為這是某個“引擎碾壓”的故事而是項(xiàng)目定位的差別。老牌開源引擎的設(shè)計目標(biāo)偏向通用識別和輕量集成而 PaddleOCR 從一開始就圍繞“文檔場景怎么落地”來組織流程。兩者面向的問題不同但在今天的實(shí)際業(yè)務(wù)里我要的是能快速接入、效果夠用、遇到問題好排查的解決方案。單憑這一點(diǎn)遷移就是值得的。下面這張表是我自己評估時的簡化對比不談具體指標(biāo)只說體感維度老牌開源 OCR 方案PaddleOCR 方案中文識別效果依賴字體和訓(xùn)練數(shù)據(jù)波動大默認(rèn)模型對常見場景較穩(wěn)使用門檻需要自行搭建檢測、識別鏈路安裝后一條命令即可試跑訓(xùn)練與擴(kuò)展數(shù)據(jù)集、格式、流程需要自己摸索文檔和工具鏈相對完整社區(qū)案例問題反饋分散同類業(yè)務(wù)案例多方便搜到解法部署方式多為本地庫服務(wù)化要自己封裝集成度高適合做服務(wù)化封裝2. 檢測、分類、識別三步鏈路到底在干什么2.1 文字檢測先回答“字在哪里”很多人第一次用 OCR以為就是把圖片丟給模型模型直接吐字符串。實(shí)際上正規(guī)的 OCR 流程是把“找字”和“讀字”分開的PaddleOCR 也不例外。文字檢測環(huán)節(jié)解決的是“這張圖里哪些區(qū)域有文字”。它不像識別模型那樣逐字輸出而是輸出文本框的坐標(biāo)信息。PaddleOCR 默認(rèn)的檢測模型會給出文本行的四邊形坐標(biāo)比如四個點(diǎn)圍成的框。為什么要先做檢測因?yàn)閳D片里往往有大片無關(guān)區(qū)域背景、表格線、Logo、插圖。如果直接把整張圖送去識別模型會浪費(fèi)大量計算在空白區(qū)域還容易被噪聲帶偏。檢測框縮小了識別范圍讓識別模型只在候選文本區(qū)域內(nèi)工作準(zhǔn)確率和速度都能保證。實(shí)際調(diào)試時檢測環(huán)節(jié)的問題很容易被忽略。比如兩張圖上文字大小差不多但一張背景干凈、一張背景是密密麻麻的水印檢測效果會差很多。這時候去調(diào)識別模型是沒有意義的先看檢測結(jié)果是否把文本行完整框住才是正確思路。2.2 方向分類與文字識別讓讀圖更像人的閱讀過程方向分類器是 PaddleOCR 流程里比較有特色的一環(huán)。手機(jī)拍照、掃描件經(jīng)常會旋轉(zhuǎn) 90 度、180 度甚至倒置文字識別模型對“字是正的”這件事比較敏感圖片轉(zhuǎn)個 90 度再送進(jìn)去正確率會明顯下降。方向分類器負(fù)責(zé)判斷文本的朝向并在送入識別模型之前把圖片擺正。識別模型則是把剪裁出來的文本行圖像轉(zhuǎn)換成字符串。它的本質(zhì)是把視覺特征映射成文字序列靠的是大量圖文樣本訓(xùn)練出的映射關(guān)系。PaddleOCR 的識別模型輸出通常包含識別出的文本和置信度分?jǐn)?shù)置信度代表模型對這個結(jié)果的把握程度。業(yè)務(wù)系統(tǒng)里我會用這個分?jǐn)?shù)做后續(xù)過濾分?jǐn)?shù)低的結(jié)果要么重試識別要么轉(zhuǎn)入人工處理而不是直接入庫。這里有一個常見誤解以為 OCR 準(zhǔn)不準(zhǔn)完全看“識別模型強(qiáng)不強(qiáng)”。實(shí)際上檢測框偏了、方向沒糾正、圖像過暗或者拉伸變形識別模型再強(qiáng)也沒用。整條鏈路的準(zhǔn)確率是三個環(huán)節(jié)的乘積任何一個環(huán)節(jié)掉鏈子最終結(jié)果都會受影響。2.3 三個模型的協(xié)作關(guān)系我在項(xiàng)目里習(xí)慣把 PaddleOCR 的一次調(diào)用理解為“流水線作業(yè)”環(huán)節(jié)輸入輸出作用文字檢測整張圖片文本行坐標(biāo)框定位文字區(qū)域過濾背景方向分類每個檢測框角度判斷/糾正保證文字方向正確文本識別糾正后的文本行圖像字符串 置信度輸出最終可讀內(nèi)容理解這個協(xié)作關(guān)系最大的好處是排查問題時有清晰的優(yōu)先級。結(jié)果缺字先看檢測框是否完整結(jié)果亂碼先看方向分類是否出錯結(jié)果不準(zhǔn)確再看識別模型的適用范圍。我以前經(jīng)常一碰到效果差就盲目換模型后來才意識到大部分問題出在檢測和方向這兩個容易被忽視的環(huán)節(jié)。3. 五分鐘跑通環(huán)境準(zhǔn)備、最小代碼與參數(shù)認(rèn)知3.1 環(huán)境準(zhǔn)備與依賴安裝PaddleOCR 的運(yùn)行依賴底層深度學(xué)習(xí)框架所以安裝順序建議是先裝框架、再裝 OCR 庫。以我常用的 Python 環(huán)境為例python -m pip install --upgrade pip python -m pip install paddlepaddle python -m pip install paddleocr如果是 GPU 環(huán)境通常需要安裝帶 CUDA 能力的框架版本具體根據(jù)顯卡驅(qū)動選擇匹配版本。首次導(dǎo)入 PaddleOCR 時系統(tǒng)會在后臺根據(jù)當(dāng)前環(huán)境自動適配這一步比較容易出問題的是 Python 版本和框架版本不匹配。建議新建虛擬環(huán)境不要直接裝在系統(tǒng)全局環(huán)境里。安裝完成后可以運(yùn)行一個最簡單的腳本驗(yàn)證環(huán)境from paddleocr import PaddleOCR ocr PaddleOCR(use_angle_clsTrue, langch) result ocr.ocr(test.png, clsTrue) print(result)第一次執(zhí)行會自動下載模型文件網(wǎng)絡(luò)正常情況下幾分鐘就能完成?？吹?result 里輸出帶有坐標(biāo)、文本和置信度的列表就說明鏈路已經(jīng)通了。3.2 用十行代碼完成首次識別PaddleOCR 的輸出格式需要稍微理解一下它通常是一個嵌套列表。外層列表對應(yīng)每一張輸入圖片內(nèi)層每一項(xiàng)對應(yīng)一個識別結(jié)果結(jié)構(gòu)大致是第一個元素文本框坐標(biāo)通常是四個點(diǎn)的坐標(biāo)集合第二個元素一個二元組[識別出的文本, 置信度]寫代碼提取結(jié)果時要注意我建議先把完整結(jié)構(gòu)打印出來看一遍再寫清洗邏輯。不少人直接按字典取值結(jié)果發(fā)現(xiàn)數(shù)據(jù)結(jié)構(gòu)和自己想的不一樣當(dāng)場卡殼。from paddleocr import PaddleOCR ocr PaddleOCR(use_angle_clsTrue, langch) res ocr.ocr(sample.jpg, clsTrue) for item in res[0]: box item[0] text, score item[1] print(f文本: {text}, 置信度: {score:.4f})這段代碼雖然短但已經(jīng)覆蓋了核心流程傳入圖片、執(zhí)行完整檢測識別、按文本行輸出結(jié)果。跑通這個之后再往業(yè)務(wù)里集成就順手多了。3.3 參數(shù)解讀與運(yùn)行結(jié)果判斷PaddleOCR 初始化時的一些參數(shù)直接影響最終效果和性能我按照實(shí)際使用頻率整理了一張表參數(shù)作用建議use_angle_cls是否啟用方向分類器手機(jī)拍攝、掃描場景建議開啟lang識別語言如 ch、en、chinese_cht根據(jù)業(yè)務(wù)文本語言設(shè)置det是否執(zhí)行文字檢測已有檢測框時可關(guān)閉rec是否執(zhí)行文本識別僅做檢測時可關(guān)閉第一次跑通時不要急著追求高參數(shù)配置。先用默認(rèn)參數(shù)在幾張有代表性的圖上測試觀察哪些類型的圖效果好、哪些差。基于觀察結(jié)果去調(diào)參效率遠(yuǎn)高于猜參數(shù)。4. 把識別結(jié)果變成業(yè)務(wù)數(shù)據(jù)模擬項(xiàng)目X的完整落地方案4.1 場景設(shè)定某內(nèi)部文檔歸檔系統(tǒng)的字段抽取為了說清楚落地過程我拿一個虛構(gòu)的場景舉例某內(nèi)部文檔歸檔系統(tǒng)需要把一批掃描的證件照片和表格圖片自動提取出關(guān)鍵字段比如姓名、編號、日期然后寫入業(yè)務(wù)庫。這就是典型的“OCR 后處理”任務(wù)PaddleOCR 負(fù)責(zé)把圖像變成文本后處理代碼負(fù)責(zé)從文本里抽字段。這種場景下OCR 不是終點(diǎn)。識別出的一大段文本如果不做結(jié)構(gòu)化業(yè)務(wù)系統(tǒng)沒法直接用。所以我把整個流程分成了四步圖片預(yù)處理、OCR 識別、規(guī)則抽取、結(jié)果入庫。4.2 圖像預(yù)處理到底要不要做實(shí)際圖片不會像測試樣本那樣干凈。我處理過的情況有光照不均、傾斜、紙張褶皺、紅色印章壓住文字。預(yù)處理的目標(biāo)不是把圖片“美化”而是讓檢測和識別環(huán)節(jié)更容易工作。一個經(jīng)驗(yàn)是不要一開始就做灰度化和二值化。某些舊教程強(qiáng)調(diào)先轉(zhuǎn)灰度再二值化那種處理對清晰印刷體有效但對低對比度圖片反而會丟掉細(xì)節(jié)。我更推薦先做尺寸標(biāo)準(zhǔn)化和對比度增強(qiáng)比如把圖片統(tǒng)一縮放到適當(dāng)寬度用直方圖均衡來提升文字和背景的區(qū)分度。import cv2 img cv2.imread(input.jpg) gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) gray cv2.equalizeHist(gray) _, processed cv2.threshold(gray, 0, 255, cv2.THRESH_BINARY cv2.THRESH_OTSU) processed_path processed.png cv2.imwrite(processed_path, processed)是否需要二值化取決于圖片本身。我的建議是準(zhǔn)備幾組對照實(shí)驗(yàn)同一張圖原始圖直接識別、二值化后識別、增強(qiáng)對比度后識別看哪一組結(jié)果更穩(wěn)定。用數(shù)據(jù)說話比憑經(jīng)驗(yàn)拍板可靠。4.3 結(jié)構(gòu)化輸出的后處理手法OCR 識別結(jié)果一般是文本行列表要變成業(yè)務(wù)字段還需要做兩層處理。第一層是按行合并多行文本可能屬于同一個邏輯段落第二層是字段定位通過關(guān)鍵詞或正則把目標(biāo)字段抽出來。from paddleocr import PaddleOCR import json ocr PaddleOCR(use_angle_clsTrue, langch) res ocr.ocr(processed.png, clsTrue) lines [] for item in res[0]: box item[0] text, score item[1] lines.append({text: text, box: box, score: score}) def extract_field(lines, keyword): for line in lines: if keyword in line[text]: return line[text].replace(keyword, ).strip() return name extract_field(lines, 姓名) id_no extract_field(lines, 編號) print(json.dumps({姓名: name, 編號: id_no}, ensure_asciiFalse))這個例子很簡單但邏輯框架是通用的。實(shí)際業(yè)務(wù)往往還要處理“字段在下一行”的情況或者同一字段存在多個候選值。遇到這種情況可以先把文本按坐標(biāo)排序再根據(jù)關(guān)鍵詞位置取相鄰行的內(nèi)容而不是單純搜包含關(guān)系。4.4 效果評估準(zhǔn)確率、召回率與業(yè)務(wù)容忍度技術(shù)分析文檔很少提“業(yè)務(wù)容忍度”但這是決定項(xiàng)目成敗的關(guān)鍵。有些字段識別錯了影響很大另一些字段錯了無所謂所以不能一刀切地用“整體準(zhǔn)確率”來衡量。我的做法是把字段分級。核心字段比如證件編號要求高置信度低于閾值直接轉(zhuǎn)人工輔助字段比如備注可以接受一定錯誤率。評估時分別計算每個字段的召回率和精確率而不是只看一個平均數(shù)。以我經(jīng)歷的項(xiàng)目為例通用模型在常見印刷體上的表現(xiàn)足夠應(yīng)付多數(shù)場景但遇到特殊字體、藝術(shù)字、反色字識別率會明顯下滑。這時候與其硬調(diào)模型參數(shù)不如在流程里加一道人工復(fù)審機(jī)制。OCR 的價值是減少人工量而不是完全不讓人工介入。5. 從單張圖片到批量服務(wù)吞吐、負(fù)載與部署姿勢5.1 別把 OCR 當(dāng)作單張圖片工具批量與吞吐很多人在本地用 PaddleOCR 處理單張圖片覺得挺快但一上線就發(fā)現(xiàn)扛不住并發(fā)。核心原因通常是每次請求都構(gòu)造了新的 OCR 實(shí)例或者只處理單張圖片沒有發(fā)揮批量優(yōu)勢。PaddleOCR 的 API 支持傳入圖片列表一次調(diào)用處理多張圖。設(shè)備能力越強(qiáng)批量提升越明顯。GPU 環(huán)境下批量識別尤其劃算因?yàn)閳D形處理器擅長大批量并行計算單張圖反而浪費(fèi)資源。image_list [d1.png, d2.png, d3.png] results ocr.ocr(image_list, clsTrue)批量處理的另一個好處是方便做超時控制和錯誤重試。單張圖可能因?yàn)楦鞣N原因失敗批量任務(wù)可以整體記錄進(jìn)度中斷后從斷點(diǎn)繼續(xù)而不是全部重來。5.2 模型加載與服務(wù)化部署的常見誤區(qū)生產(chǎn)環(huán)境里最忌諱的做法是每次接口請求都創(chuàng)建一個新的 PaddleOCR 實(shí)例。模型加載、參數(shù)初始化、圖計算這些操作非常耗時請求量一高必然把 CPU 打滿。正確的做法是設(shè)計成單例模式進(jìn)程啟動時加載模型整個生命周期復(fù)用同一個 OCR 對象。代碼結(jié)構(gòu)大致是class OcrService: _instance None classmethod def get_instance(cls): if cls._instance is None: cls._instance PaddleOCR(use_angle_clsTrue, langch) return cls._instance def recognize(self, image_path): ocr self.get_instance() return ocr.ocr(image_path, clsTrue)部署方式上本地進(jìn)程直接復(fù)用模型對象是最省事的方式。如果要做成獨(dú)立服務(wù)我會建議把 OCR 邏輯放在獨(dú)立的進(jìn)程池里避免業(yè)務(wù)接口的請求線程和 OCR 的計算互相爭搶資源。換句通俗的話說不要讓 OCR 和普通接口住在同一個線程里否則一次 OCR 調(diào)用就可能阻塞其他請求。5.3 性能預(yù)算與硬件選型建議性能這個東西談參數(shù)不如談預(yù)算。CPU 環(huán)境跑 PaddleOCR 是可行的但吞吐量有限GPU 環(huán)境效果好但成本高。我的建議是先穩(wěn)住業(yè)務(wù)需求再談性能指標(biāo)。場景建議方案說明內(nèi)部低頻工具CPU 環(huán)境即可瓶頸在人不在機(jī)器文檔歸檔批處理CPU 多線程或 GPU批量任務(wù)看重吞吐高并發(fā) API 服務(wù)GPU 環(huán)境 批量隊(duì)列單張調(diào)用成本高輕量嵌入式場景關(guān)閉方向分類 小模型精度做一定取舍需要特別提醒的是不要為了省事把所有圖片堆到一個請求里處理。大面積超時、內(nèi)存溢出的風(fēng)險都會上升。合理的做法是控制批量大小配合異步任務(wù)隊(duì)列讓請求盡量平滑。6. 中文文檔識別里的高發(fā)問題預(yù)處理優(yōu)先還是換模型優(yōu)先6.1 表格、印章、復(fù)雜背景的預(yù)處理優(yōu)先級中文文檔里最常見的問題是“干擾元素太多”。表格線會把文本行切割成碎片印章會壓住手寫或印刷文字背景水印會干擾檢測模型判斷。遇到表格線我通常會先用形態(tài)學(xué)操作把橫線豎線檢測出來再從原圖中淡化或移除。這個操作要小心過度處理會把文字也一并消掉。折中辦法是只移除長線保留短線和文字筆畫。遇到印章最簡單的處理是降低紅色通道的干擾。把 RGB 圖片轉(zhuǎn)為灰度時紅色印章的灰度值通常和黑色文字差異不大但通過通道分離可以剔除一部分章印。另一種思路是準(zhǔn)備一套帶印章的測試集確認(rèn)通用模型在這些樣本上的失敗模式再決定要不要針對性地做數(shù)據(jù)增強(qiáng)。6.2 豎排、傾斜、混排文本的識別優(yōu)化豎排文本是中文場景的特殊難點(diǎn)。方向分類器能處理圖片旋轉(zhuǎn)問題但整頁豎排文本不是“旋轉(zhuǎn)一下就能解決”的它需要模型真正支持豎排文本行檢測。通用模型的豎排能力相對弱于橫排遇到整頁豎排古籍、豎排海報時我通常會把圖片手動旋轉(zhuǎn) 90 度再試一遍。傾斜問題主要影響檢測框的穩(wěn)定性。如果圖片只是輕微傾斜預(yù)處理階段做一個角度校正通常能帶來明顯提升。校正方法不復(fù)雜檢測圖片中的文字輪廓用輪廓的最小外接矩形估算角度再對整張圖旋轉(zhuǎn)?；炫盼谋緳M排和豎排同時存在目前仍然依賴后續(xù)處理較多。我會先按坐標(biāo)把結(jié)果分組橫排一組、豎排一組再分別走不同的識別參數(shù)。這個過程雖然繁瑣但結(jié)果比“一把梭”的方式穩(wěn)定得多。6.3 長尾字體與生僻字什么時候該認(rèn)命什么時候該換模型通用 OCR 模型不是萬能的。生僻字、藝術(shù)字、手寫體這些場景的準(zhǔn)確率勢必低于印刷體。我在項(xiàng)目里經(jīng)常遇到“識別錯了一個生僻字業(yè)務(wù)方覺得整個模型不行”的情況。這時候要先判斷是模型能力問題還是數(shù)據(jù)覆蓋問題。如果只是個別生僻字可以在后處理環(huán)節(jié)做字典替換把容易混淆的字對放進(jìn)去。如果整個字體風(fēng)格都不在模型覆蓋范圍內(nèi)比如某種特定的裝飾字體那就要考慮新增訓(xùn)練數(shù)據(jù)微調(diào)模型。我的經(jīng)驗(yàn)是與其追求一個萬能模型不如在前面做分類印刷體走通用模型特殊字體走專用模型手寫體走人工或?qū)ｍ?xiàng)方案。不同業(yè)務(wù)場景的文本特征差異太大指望單一模型通吃所有情況往往會讓項(xiàng)目進(jìn)度卡在性價比極低的地方。6.4 內(nèi)存、顯存與服務(wù)穩(wěn)定性問題最后說一個工程上很現(xiàn)實(shí)的問題資源泄漏和穩(wěn)定性。OCR 涉及圖像解碼、模型推理內(nèi)存占用比普通文本接口大不少。服務(wù)跑一天之后內(nèi)存持續(xù)上漲最終被系統(tǒng)殺掉這是我在真實(shí)環(huán)境里遇到過的。排查思路并不復(fù)雜先確認(rèn)是不是模型對象被反復(fù)創(chuàng)建再檢查圖片解碼后的大數(shù)組引用是否及時釋放最后看并發(fā)情況下是否控制住了批處理大小。還有一個容易被忽略的點(diǎn)圖片格式多種多樣個別損壞圖片會讓解碼庫直接崩潰。我習(xí)慣在 OCR 前置階段做一次圖片有效性校驗(yàn)格式不對或不完整的文件直接跳過。服務(wù)穩(wěn)定性不只是“EXE 穩(wěn)定運(yùn)行”這么簡單更重要的是失敗重試機(jī)制。OCR 識別結(jié)果天然帶有不確定性一次識別失敗或者低置信度未必是程序 bug。把它設(shè)計成可重試、可標(biāo)記、可轉(zhuǎn)人工的流程比追求“每次都成功”現(xiàn)實(shí)得多。留給新項(xiàng)目的一句話經(jīng)驗(yàn)如果現(xiàn)在讓我啟動一個新的文檔識別項(xiàng)目我不會再先寫一堆識別腳本而是會先定義清楚哪些結(jié)果必須高可信哪些結(jié)果可以接受人工兜底。PaddleOCR 確實(shí)把 OCR 的門檻拉低了一大截但工程落地里的臟活累活比如圖片預(yù)處理、字段抽取、異常重試、置信度過濾一分都省不掉。最后分享一個小技巧處理大批量圖片時先用低分辨率快速過一遍只把置信度較低的結(jié)果拿出來單獨(dú)放大重識別這樣能在速度和準(zhǔn)確率之間找到很好的平衡點(diǎn)也是我最近實(shí)測下來性價比最高的優(yōu)化手段。