9 種 AI 模型辨識台灣發票實測：Gemini、Claude、Gemma4、PaddleOCR 準確率、速度、費用完整比較
實測 9 種模型辨識台灣發票，gemini-3.1-flash-lite 以 1.8 秒、94.9% 準確率、費用便宜，拿下綜合第一，Gemma4:26b 卻意外輸給更小的 e4b。
我最近在為一個發票自動化系統挑選 OCR 引擎，測試範圍從免費本機方案到最強的雲端 LLM，最終結果讓我大吃一驚——最便宜的那個幾乎打敗了所有對手。
這篇文章把完整測試數據整理成讀者做決策所需的精華，包含準確率、速度、每萬張費用的三維比較，以及各模型在台灣發票上最常見的失分原因。
測試設計
使用 3 張台灣二聯式發票（含手寫欄位、方格統編、民國年日期），每張評分 13 個欄位（9 個表頭 + 4 個品項），共 39 分滿分。
測試環境為 Apple M4 Pro（48GB 統一記憶體），這讓本機 ollama 模型得以直接利用 GPU / Neural Engine，但即便如此，結果也未必如預期。
參與比較的 9 個模型：
- 雲端模型：gemini-3.1-flash-lite、gemini-3-flash-preview、gemini-3.1-pro-preview、claude-sonnet-4-6、claude-opus-4-7
- 本機 ollama：gemma4:e2b（7GB）、gemma4:e4b（9GB）、gemma4:26b（17GB）
- 傳統 OCR：PaddleOCR PPStructureV3
準確率：雲端模型大勝，本機差距明顯
| 模型 | 準確率 | 平均耗時 | 每萬張費用 |
|---|---|---|---|
| gemini-3.1-pro-preview | 97.4% | 37.3s | $37.13 |
| gemini-3.1-flash-lite | 94.9% | 1.8s | $2.17 |
| gemini-3-flash-preview | 94.9% | 8.0s | $3.26 |
| claude-sonnet-4-6 | 94.9% | 19.6s | $1,093 |
| claude-opus-4-7 | 94.9% | 8.5s | $3,080 |
| gemma4:e4b（本機） | 61.5% | 9.7s | 免費 |
| PaddleOCR PPStructureV3 | 38.5% | 24.8s | 免費 |
| gemma4:e2b（本機） | 20.5% | 6.2s | 免費 |
| gemma4:26b（本機） | 17.9% | 4.3s | 免費 |
前五名清一色是雲端模型，本機 ollama 最好的 gemma4:e4b 僅達 61.5%，且更大的 gemma4:26b 反而更差——這背後有重要原因值得留意。
真正的贏家：gemini-3.1-flash-lite
如果只能推薦一個模型，答案是 gemini-3.1-flash-lite。它用 1.8 秒完成辨識、每萬張只需 $2.17，準確率卻達 94.9%——與最強的 gemini-3.1-pro-preview 相比只差 1 分（在方格統編欄位失分），但快 20 倍、便宜 17 倍。
在綜合評分（準確率 50%、速度 25%、費用 25%）中，它以 0.942 高居第一，第二名的 gemini-3-flash-preview 僅有 0.733。
各模型最常見的失分原因
1. 手寫買受人名稱
「金鋐源管理顧問社」中的「鋐」字，所有雲端 LLM 都讀錯一兩個字（金銳/鎂/鑽/鑲），這是字跡先天難辨的問題，連人工也無法 100% 確認。這類欄位應標記為低信心值，留人工複核。
2. 方格統編（每格獨立印刷）
統編「42364761」印在 8 個獨立小方格內，較弱的模型把「7」誤讀為「2」。Pro 等級的模型（gemini-3.1-pro-preview、claude-opus-4-7、claude-sonnet-4-6）可正確辨識；flash-lite 與 flash-preview 在這欄失分。
3. 民國年沒有自動轉換
gemma4:e4b 把日期輸出為「111-09-26」、「114-08-25」，沒有自動轉換成西元年。所有雲端模型都正確輸出 YYYY-MM-DD 格式。
4. gemma4:26b 輸出不穩定
17GB 模型在 M4 Pro 上多次回傳壞 JSON（如 2thoughtful_user_request_analysis），準確率跌至 17.9%，比只有 7GB 的 e2b 更差。不建議用於生產環境。
5. Claude CLI 費用被高估
Claude 在這次測試中費用偏高（每萬張 $1,093–$3,080），是因為透過 claude -p 子程序每次冷啟動都載入 CLAUDE.md、hooks、skills 等系統 prompt（約 36k cache 創建 tokens）。若直接呼叫 Anthropic API，費用可降至 1/10 以下，與 Gemini Pro 同等量級。
依情境的推薦組合
| 情境 | 推薦模型 | 理由 |
|---|---|---|
| 生產預設（雲端） | gemini-3.1-flash-lite | 速度、成本、準確率最佳平衡 |
| 精確模式（雲端） | gemini-3.1-pro-preview | 手寫、方格統編準確率最高 |
| 離線（不送雲端） | gemma4:e4b | 9GB ollama vision 模型，準確率 61.5% |
| 純文字辨識 | PaddleOCR PPStructureV3 | 完全本機、零費用，但需自寫 regex |
常見問題
Q：用 Claude API 直接呼叫，費用真的會低很多嗎？
是的。本次測試透過 claude -p CLI 的費用包含每次約 36k tokens 的系統提示載入，直接呼叫 API（搭配 prompt cache）成本可降低 80-90%，與 Gemini Pro 相比就不再懸殊。
Q：PaddleOCR 可以做到同等水準嗎？
目前不行。PaddleOCR PPStructureV3 缺乏語意理解，無法抽取 invoice_number、issue_date、buyer_name 等結構化欄位（依賴 regex，invoice2/3 全部 null）。它適合大量純文字辨識，不適合結構化表單擷取。
Q：本機 Gemma4 可以達到雲端水準嗎？
目前 e4b（9GB）是可接受的本機選項，61.5% 對某些非精確場景夠用，但缺乏民國年轉換、品項名稱偶有幻覺。更大的 26b 在我的機器上反而更不穩定，不建議直接部署。
結語
這次測試最大的啟示是：模型大小不等於效果好。gemma4:26b（17GB）輸給了 e4b（9GB），而雲端的 gemini-3.1-flash-lite（極輕量）卻打敗了幾乎所有對手。對發票 OCR 這類需要語意理解的結構化擷取任務，選擇有 vision 能力的多模態 LLM 是正確方向，費用與速度的取捨再依業務量決定。
如果你在做類似評估，建議先以 gemini-3.1-flash-lite 為基準線，在失分嚴重的欄位（手寫、方格統編）加上 low-confidence 旗標，再考慮是否需要升級到 Pro 等級。
