RapidOCR 開源 OCR 實測：離線就能跑，繁中直接用預設模型

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

同一張總統府官網的首頁截圖，我分別丟給 RapidOCR 的兩個模型。預設模型把「健康台灣推動委員會」原封不動讀了出來；照著網路上舊教學切到「繁體中文專用模型」之後，同一行字變成「健康合灣推動委員會」，「總統府新聞中心」前面多出一個「口」，連時刻「20:30」都被讀成「20-30」。換模型這一步，在 2026 年的 RapidOCR 上是把辨識品質往回退，而不是往前提。

這是我在 macOS 上實際安裝 rapidocr 3.9.2 跑出來的結果，也是這篇想講清楚的事：RapidOCR 是一套免費、開源、模型直接跟著安裝包走的離線 OCR，裝完直接用預設設定就好，繁體中文已經在預設模型的能力範圍內。專案從 2021 年維護到現在，採 Apache-2.0 授權，GitHub 上有七千七百多顆星，測試當天倉庫還有新的提交紀錄。

這輪實測怎麼跑：三種輸入、兩個模型、一台 Mac

安裝只有兩行：pip 裝 rapidocr 跟 onnxruntime，Python 3.8 以上都能跑。我把三種輸入餵進去：官方文件提供的簡體中文測試圖（一張電商促銷橫幅）、我自己截的總統府首頁（真實網頁的繁中版面），以及把辨識模型從預設換成繁中專用模型後的同一批圖。環境是 Apple Silicon 的 Mac、Python 3.11、onnxruntime 1.29.0，全程一般家用網路，沒有掛代理。

邊界先講清楚：這是單一機器、單次流程的對照，不是基準測試。它能回答「預設模型會不會讀繁中」這個問題，回答不了「所有繁中場景哪個模型最準」。要下判斷之前，建議拿你手上真實的文件再跑一輪。

預設模型先過兩關：簡中橫幅 18 行全對，總統府截圖也乾淨

第一關是官方那張簡中促銷圖。畫面上 18 行字全部讀出來，一個字都沒掉，連「-40℃」開頭那種符號、英數與中文擠在同一行的組合都一字不漏讀出，價格標籤裡的小字也沒有漏。單張圖的推理時間落在 0.13 到 0.23 秒之間，引擎初始化 0.17 秒，因為模型就放在安裝包裡，載入不需要下載任何東西。

第二關換真實繁中版面。總統府首頁截圖一樣抓出 18 行，「健康台灣推動委員會第 8 次會議會後記者會」這種長標題、「LIVE·直播」「2026.08.27」這類混排元素，讀出來的繁體字都是對的。早年簡中 OCR 套件遇到繁中要另外掛模型或調詞表的慣例，在這一代預設模型上已經不成立：裝完直接讀，不需要另掛任何東西。

Pin

這背後是一條三段式流程：先找字在哪裡（偵測模型），再判斷每行有沒有上下顛倒（方向模型），最後把每一行小圖翻成文字（辨識模型）。方向這一步常被忽略，但它就是手機拍文件常常整張 90 度或 180 度躺著時，輸出不至於整篇鏡像的原因。預設三個模型分工明確，也都可以單獨換掉，這點後面會用到。

換上繁中專用模型，繁中反而開始掉字

接著是我一開始也預期相反的實驗。RapidOCR 的模型清單裡有獨立的繁體中文辨識模型，直覺上「繁中場景配繁中模型」應該更準。實際輸出如下：

兩個模型抓到的行數一模一樣，都是 18 行，因為我這輪只換了辨識模型，負責找字在哪裡的偵測模型沒動。差別全部出在辨識層：把每一行小圖翻成文字的那一步。查模型清單可以找到原因，繁中專用模型的名字叫 chinese_cht_PP-OCRv3_rec_mobile，停留在 PP-OCRv3 世代、只有 mobile 一個規格；而預設模型已經是 PP-OCRv6 世代的 small 規格。兩個世代之間隔了 v4、v5 兩輪模型更新；從模型命名與這輪輸出來看，繁中場景吃到的差距很直接。

這也回頭解釋了 RapidOCR 這個專案最值錢的設計。它的起源就是把 PaddleOCR 的模型轉換成 ONNX 這類通用格式，讓模型跟推理框架脫鉤：辨識模型可以單獨升級、偵測模型維持不動，推理引擎也能照部署環境替換。模型清單上 v4 到 v6 並列，偵測、方向、辨識三種角色可以跨世代混搭，預設組合正是 v6 的偵測與辨識、搭 v4 的方向模型。專用語系模型沒跟上最新世代，就是這種「格式統一、各自升級」結構的自然結果：翻新是逐個模型來的，不是一次全上。舊教學寫的切換參數本身沒錯，錯的是它假設專用模型永遠比較新。

這個結論也不該反過來讀成「繁中專用模型永遠不要用」。如果你手上的文件剛好落在專用模型訓練針對的那類版面，或最新世代模型在你的樣本上表現異常，官方模型清單隨時都在，換一行參數就能對照出答案。這輪實測真正便宜的是對照的成本：兩個模型各跑一次同一張圖，幾秒鐘的事。貴的是把單一截圖的結論當成通則，任何模型選擇，最終都該用你自己的文件說了算。

模型跟著安裝包走：斷網與零遙測都成立

預設的三個模型（偵測 9.9 MB、方向 0.6 MB、辨識 21.2 MB，合計約 32 MB）直接包在安裝包裡，第一次跑不需要連網，之後也不需要。我把整個套件的原始碼掃過一遍網路呼叫，全部只有三個地方會對外連線：你餵給它圖片網址時去抓那張圖、下載非預設模型時連模型倉庫、以及官方的安裝自我檢查指令。找不到任何遙測、統計或錯誤回報的程式碼，文件裡也沒有註冊或金鑰的環節。文件不出本機這件事，在程式碼層面站得住。

一個要留心的細節：非預設模型的下載來源是魔搭 ModelScope，位在中國的模型託管平台。前面測的繁中專用模型第一次載入時，就是從那裡抓了 11.2 MB 下來。走預設模型的離線路線完全碰不到它，但你要部署到無法對外連線的環境，記得先把會用到的模型抓齊再封裝。

專案本身的體質也值得看一眼再決定要不要依賴它。RapidAI 這個組織從 2021 年開始圍繞 OCR 經營整個 Rapid 系列，倉庫數量接近兩百個；主力維護者一個人的提交就超過一千次，3.9.2 版在 2026 年 7 月發佈，到 9 月初倉庫仍有活動。以 OCR 這類模型與格式都在快速演進的領域，維護節奏跟得上模型世代，比星數更能說明它不是棄坑狀態。

Pin

五行程式開始用，不寫程式有另外兩個入口

整條使用鏈比想像中短：

pip install rapidocr onnxruntime

from rapidocr import RapidOCR

engine = RapidOCR()
result = engine("receipt.png")   # 也可以直接餵圖片網址
for line in result.txts:
    print(line)
result.vis("output.jpg")         # 把辨識框畫回圖上存檔

輸出除了文字，每行還附座標與信心分數，要拿來做後處理都有素材：例如只保留信心高於某個門檻的行進資料庫，或照座標把同一欄位的行排回原本的閱讀順序。要換模型或換推理引擎，都是建構引擎時丟參數進去，組合要照官方模型清單的對照表配，不是任意組合都存在，配錯了它會直接告訴你這個組合沒有對應模型。語系也是同一份清單的事：辨識模型有中文、繁中、日文、韓文、英文、阿拉伯文等十多個語系選項，多語文件拆開跑再合併，比找一個萬用模型實際。

不寫程式的話有兩個官方延伸套件：rapidocr_web 是圖形介面桌面版，rapidocr_api 把它包成跨平台服務，兩個都發佈在 PyPI 上。另外一條路是 Umi-OCR 這類以它為底層的桌面 OCR 軟體，README 上列的使用者還包含 Docling、CnOCR、langchain 這些文件處理與 AI 應用專案；這份清單是作者自己整理的，採用事實可以在 GitHub 的相依網路裡核對。同樣想把辨識能力開放給其他機器呼叫的思路，先前介紹過的把手機的文字辨識開放成區網 API 的做法可以對照著看；手上是 PDF 而不是圖片、想先判斷哪幾頁需要 OCR 的，Firecrawl 的 PDF 分流工具補的是上游這一段。

連安裝都想省的話，官方在 Hugging Face 與魔搭各放了一份線上 demo，丟一張圖就能看輸出，README 還附了 Colab 範例筆記本。把它當成安裝前的品質確認步驟最省事：先拿你真實會遇到的那種文件丟 demo，確認辨識水準符合需要，再回來裝套件做批次處理。要注意 demo 走的是網頁服務，檔案已經出本機，與套件版的離線前提是兩回事。

模型規格的取捨也有選單可挑。清單上的模型掛著 small、mobile 這類規格名，從命名就標示了取捨方向：mobile 走輕量路線，要塞進小記憶體的設備選它；要準度就留在 small。世代之間 v4、v5、v6 並列，越新的世代搭配的訓練資料越新，但每個語系跟上的速度不同，繁中專用模型就是還沒跟上的一個。套件還附了一條安裝自我檢查指令，會抓官方測試圖跑一輪並比對第一行輸出是否正確，換了環境或換了推理引擎之後跑一次，可以早點發現安裝問題。

這輪沒測到的，和你要自己驗的

沒測到的範圍先攤開：手寫字、表格結構還原、整本長文件、低光源照片，這輪都沒碰；推理引擎只跑了 onnxruntime，OpenVINO、MNN、TensorRT 這些官方宣稱支援的路線沒有實測，這輪全部用 CPU 跑，GPU 版引擎與批次平行化的加速幅度也沒有量到；準確率的結論僅限那一張截圖與一張官方測試圖，換文件、換解析度、換批次都可能不同。文件與討論區以簡體中文為主，商業支援走開發團隊的直接洽談，讀文件時要有對照簡體的心理準備。

還有一個取捨想先講：它是開發者工具的形狀。裝、跑、調參數都在命令列與 Python 裡，圖形介面要靠延伸套件補。跟雲端 OCR 服務相比，它換到的是斷網可用與檔案不出本機，付出的是沒有現成的好看介面，也沒有線上服務那句「上傳即處理完丟棄」的口頭承諾（那句承諾你本來也難以驗證）。哪一邊值得，看你手上的文件有多敏感。

誰該裝它，誰用不著

該裝的情境很明確：要批次把大量圖片轉文字、要在內網或斷網環境跑、處理的文件不適合上傳雲端，或你想把 OCR 塞進自己的自動化流程裡，RapidOCR 的離線、零遙測與可程式化正好對上，Apache-2.0 也讓商業嵌入沒有授權疑慮。舉個具體流程：一疊掃描好的收據丟進去，跑完後照信心分數過濾、按座標排回欄位順序，再匯出成試算表，全程不經過第三方伺服器。已經在用 Python 做文件處理的人，接上它之後上游可以再串PDF 投影片的重排與生成工具，整條鏈都能留在本機。

用不著的情況也一樣清楚：一個月偶爾轉一兩張圖，作業系統內建的截圖辨識或免費線上工具就夠；需要把表格轉成結構化資料、或要求出版級校對品質的，先拿樣本實測再說。至於已經裝了的人，檢查一下手上的教學是不是還叫你切繁中專用模型：以這輪樣本，把那行參數拿掉結果變好了；值不值得跟進，拿你自己的文件對照一次再定。