OCF 2026 AI RESEARCH INTERNSHIP · CASE STUDY
開源 VLM 繁體中文 OCR 與文件解析評測
只是換了一段 prompt，為什麼同一個模型的分數差這麼多？
這個意外，成為我們九週 VLM OCR 評測實習真正開始研究的問題。我們從兩套獨立建立、卻對同一模型得到不同分數的評測流程出發，透過 OFAT 消融實驗逐一比較 prompt、推論參數、後處理與評分器對結果的影響；確認設定後，再使用 TC-STR 與 OmniDocBench 比較不同 VLM 在繁體中文短文字辨識與整頁文件解析上的表現，並完整記錄模型、資料、prompt、參數與原始輸出，建立可重跑、可追溯的評測流程。
透過實驗發現，Benchmark 分數不只取決於模型能力，評測設定本身也可能大幅改變結果：同一模型、同一份 TC-STR 資料，在不同設定下 Exact Match 可從 0% 到 64.84%，單是調整 repeat_penalty 就相差 17.78 個百分點。此外，模型規模也無法直接預測表現，小模型有時能超過更大的模型，而同一模型的優勢也會隨短文字辨識、表格、公式與整頁文件解析等不同任務而改變。
最終我們了解到，Benchmark 不只是把模型放進資料集跑一次再按照分數排名，而是模型、prompt、推論參數、後處理與評分器共同作用後的結果；如果這些條件沒有被控制、記錄與公開，分數之間就未必具有可比較性。
因此，比起只問「哪個模型分數最高」，更重要的是先確認我們究竟測量了什麼，以及這個結果是否能在一致、透明且可重現的條件下再次得到。
01 / PROJECT OVERVIEW
怎麼才算「公平地」評測 VLM OCR 模型？
本研究屬於 OCF 贊助計畫的研究路線，我們想知道：在「考驗」一個 LLM（Large Language Model，大型語言模型）時，我們該如何控制 prompt（提示詞）、參數、後處理流程、評分器等諸多細節，讓不同模型的結果可以被公平比較，也能被後續研究者重現與驗證。
FLAGSHIP FINDING
同一模型、同一資料集，只改評測設定，結果卻大相逕庭
「只是改了一點參數，模型的分數直接提升 17%」「不一樣的 prompt，讓模型產生的答案也大不相同」這些問題在我們的實習研究過程中不斷發生，俗話說「牽一髮而動全身」在評測模型的過程中也是如此，評測模型的過程中有太多細節與設定，任何一點改動都有可能對結果造成不小的影響。於是，我們透過消融實驗逐一拆解這些變因，並把過程中得到的經驗落實成一套可重現、可追溯、可試錯的評測流程，盡可能讓不同模型的比較建立在一致而透明的條件上。
WHY IT MATTERS
政府公報、判決書、歷史報刊等開放資料常以掃描影像存在；本地可執行的開源 VLM（Vision-Language Model，視覺語言模型）若能被可靠評估，可降低外部 API（Application Programming Interface，應用程式介面）成本與資料外流風險。
RESEARCH QUESTION
當任務不只是一般的短文字辨識，還加入了表格拆解、文件解析等題目，此時 VLM OCR（Optical Character Recognition，光學文字辨識）的回答就不只有唯一評分方式；不論是標點、空白、後處理與額外解釋都可能改變分數的公平性，因此我們必須先界定「怎麼量」。
PROJECT VALUE
最後主要成果為一套可重跑、可追溯來源、失敗可見、且能交接給後續研究者的 evaluation infrastructure；當未來我們想打造屬於台灣自己的模型時，該如何公平地「考驗」它。
02 / TEAM & JOURNEY
團隊分工與歷程
實習初期為了熟悉評測工具與流程，兩位實習生分別運用 VLM 各自進行評測，發現儘管相同的模型、benchmark（基準測試），因為 prompt、評分方式、參數設定等細微差異而造成相異甚遠的結果，經過仔細的消融實驗與分析分數落差來源後，確認了後續進行正式實驗時選擇的技術細節。
EVALUATION METHOD
游聿堂
- 參與初期 Ollama VLM 評測流程與測試
- 製作與編輯互動式成果報告
- 檢驗評測流程
REPRODUCIBILITY & INFRA
黃以信
- 設計後處理規則與 EM（Exact Match）／CM（Containment Match）／ANLS（Average Normalized Levenshtein Similarity）／F1（Character F1）四項指標
- 完成初期 7 組 OFAT（One-Factor-At-a-Time）消融實驗與分析
- 建立
benchmark_suite/ 與 TC-STR_and_OminDoc/ 長時間評測系統
- 把 model digest、dataset fingerprint、prompt hash、evaluator commit 納入來源追溯
PROJECT TIMELINE · FOUR STAGES
STAGE 01
研究問題確認
討論研究方向與熟悉相關技術。
STAGE 02
初期測試
以消融實驗確定後續實作之技術細節。
STAGE 04
報告製作
撰寫報告與視覺化呈現，校對內容正確性。
03 / ABLATION EXPERIMENT
消融實驗：分數落差從何而來
eval/ 與 Sixhuang/ 兩套獨立流程，同一模型、同一資料卻算出不同分數，讓「模型能力」與「評測流程效果」混在一起，難以判斷分數真正代表什麼。為了拆開兩者，我們把兩套流程對齊成同一個 baseline（基準組），再用OFAT 消融實驗（每次只改一項設定）逐一量出各變因的影響。
GLM-OCR Q8_0
單一模型 × TC-STR 3,706 筆測試資料
7 組
variant，5 組需要重新推論、2 組離線重算
18,530
次 Ollama request，API error 數為 0
0% – 64.84%
同模型同資料，EM 隨評測設定變動的區間
每組僅相對 baseline 更動一項設定。EM（完全相符）、CM（是否包含正解）、ANLS（編輯距離正規化相似度）、F1（字元級精確與召回的綜合分數）四項指標的完整定義見 08 章。
| 實驗 |
相對 baseline 的唯一改動 |
EM↑ |
CM↑ |
ANLS↑ |
F1↑ |
平均延遲 |
| Aligned baseline |
/api/generate、長 prompt、repeat_penalty = 1.6、num_predict = 80 |
47.06% |
76.52% |
54.54% |
59.17% |
0.602 s |
| Endpoint：/api/chat |
改用 /api/chat，其餘不變 |
47.06% |
76.52% |
54.54% |
59.17% |
0.582 s |
| Sixhuang short prompt |
171 字長 prompt 改成 39 字短 prompt |
0.00% |
79.06% |
0.00% |
13.56% |
0.594 s |
| 不指定 repeat_penalty = 1.6 |
回到 Ollama／模型預設值，不再顯式傳入 1.6 |
64.84% |
82.46% |
72.08% |
76.62% |
0.583 s |
| num_predict = 25 |
輸出長度上限由 80 降至 25 |
46.03% |
76.34% |
53.29% |
65.07% |
0.293 s |
| Sixhuang minimal postprocess |
baseline raw response 改用最小後處理，離線重算 |
0.00% |
76.79% |
0.00% |
6.88% |
離線重算 |
| Sixhuang scorer |
baseline prediction 不變，改用另一套 scorer 計分 |
47.87% |
77.63% |
55.02% |
59.96% |
離線重算 |
KEY 01
repeat_penalty 是最大單一效益
不指定 repeat_penalty = 1.6、回到預設值後，EM 增加 17.78 個百分點；779 題由錯轉對、120 題由對轉錯，淨增 659 題完全正確。1.6 對這個模型可能過高。
KEY 02
EM 歸零 ≠ 完全沒辨識到文字
短 prompt 讓 EM／ANLS 歸零，但 CM 反而升到 79.06%（全實驗組最高）：答案仍藏在輸出裡，只是後面接了 Markdown、解釋、英文分析與 prompt 複誦，導致嚴格比對失敗。
KEY 03
後處理決定了分數能不能看
aligned 後處理修改了 3,704／3,706 筆 raw response；同一批輸出換成最小後處理，EM 立刻歸零。目前分數衡量的是「模型＋後處理」的系統表現，不是模型原始輸出。
KEY 04
endpoint 可從嫌疑名單中排除
/api/generate 與 /api/chat 的 3,706 筆 processed prediction 逐字相同，四項指標無差異，0.02 秒的延遲差不足以判定孰快。
KEY 05
換 scorer，分數就會不一樣
prediction 完全沒變，只換 scorer，EM 就多判 30 題正確（+0.81pp）。差異來自空白／標點正規化與 CM 單向或雙向判定，屬報告層次差異，不是模型變強——跨團隊比分前應先對齊 scorer。
KEY 06
縮短輸出：快 51%，但有隱藏代價
num_predict 由 80 降到 25，平均延遲降 51%，但 EM 降 1.03 個百分點；部分 prompt 複誦被截成不完整片段，反而躲過了針對完整片語設計的後處理規則。
本次建議設定
—aligned 長 prompt、num_predict = 80、不顯式指定 repeat_penalty = 1.6、aligned 後處理、團隊統一 scorer；/api/generate 或 /api/chat 皆可，但同一場評測要固定同一種。
—此組合得到 EM 64.84%、CM 82.46%、ANLS 72.08%、F1 76.62%，是本次已測組合中最佳結果，也是後續 benchmark_suite/ 固定推論設定的依據之一。
解讀限制：這是 OFAT 單變因主效應分析，各列 delta 不能直接相加，且只代表 GLM-OCR Q8、TC-STR 與當時的 Ollama 環境，未必可推廣至其他模型。CM 只檢查 prediction（模型輸出）是否包含 ground truth（正解），答案藏在大量錯誤內容中仍可能得分，不應單獨用 CM 判斷 OCR 品質；temperature = 0 也不保證跨 Ollama 版本、推論後端或硬體逐字一致。
04 / EVALUATION TASKS
評測任務與資料
這是一套可重現（reproducible，任何人重跑都能得到相同結果）的評測工具，比較多個VLM在兩件任務上的表現。兩套工具都用Ollama依序載入不同模型、餵同一批圖片並記分。
TASK A · TC_STR
繁體中文短文字辨識
辨識圖片中的繁體中文短文字，類似傳統 OCR（光學文字辨識）。資料集為 esun-ai/traditional-chinese-text-recogn-dataset 官方 test split。
TASK B · OMNIDOCBENCH
整頁文件解析
把整頁文件（標題、表格、公式、多欄排版）轉成結構化 Markdown。原始筆記寫作 OminDocBench，正確名稱為 OmniDocBench。
核心堅持是「公平比較」：所有模型看到的圖片、提示詞、參數完全一致，不會為表現差的模型偷偷調整。
05 / PRINCIPLES
設計原則
R1
同題同料
同一場評測，每個模型看到的圖片、提示詞、參數都一樣。
R2
一次一張圖
每次請求只送一張圖，不批次塞多張。
R3
依序換模型
測完一個才卸載、換下一個，避免 GPU（Graphics Processing Unit，圖形處理器）記憶體被多模型同時占用。
R4
暖機不計分
模型剛載入時速度不穩，這段 warm-up 的結果不算分。
R5
保留爛表現
答錯、答空白、被截斷都算模型自己的實力，不事後清理答案。
R6
原始回應永久保留
不論好壞都存起來，方便日後查證。
這樣可以確保分數低是模型能力問題，而不是測試流程出錯造成的誤判。
06 / PIPELINE
整體運算流程
TC_STR 與 OmniDocBench 都走同一條流程，中間有兩道人工／自動關卡。
準備工作
下載資料集、確認模型清單，並用SHA-256（Secure Hash Algorithm 256-bit）記錄每張圖的指紋。
Preflight 事前檢查
確認模型版本、顯示卡是否 100% 由本次評測占用。
Smoke 小規模測試
TC_STR 取 20 題／OmniDocBench 取 20 頁先跑一次。
流程不會自動跑到底：smoke 結果須經人工確認沒問題，才進入正式全量評測。
操作者手動啟動正式全量評測
避免無人監督下產生一堆錯誤結果。
逐題／逐頁推論
寫入 SQLite checkpoint，中斷可續跑。
正式評分
TC_STR 自行計算；OmniDocBench 使用官方 Docker 評分程式。
簽章比對（signature）
資料版本、模型版本、提示詞、參數任一改變，系統就判定是「不同的一次評測」，新舊結果不會混在一起計分。
07 / ENVIRONMENT
系統環境
顯示卡
NVIDIA L40S
≈45GB VRAM
Video RAM · 顯示記憶體
可重建暫存區
關機會消失，但能重新下載，例如資料集本身。
永久保存區
存放檢查點、原始回應與報告，不因關機消失。
08 / TC_STR
TC_STR：繁體中文短文字辨識
資料來源為 esun-ai/traditional-chinese-text-recogn-dataset 的官方 test split，共 3,706 筆。提示詞要求模型「只輸出圖片中看到的文字」，所有模型逐字相同；temperature = 0、num_predict = 80、逾時 180 秒。
8.1 參與比較的 8 個模型
卡片內為參數量與量化方式；標記 MoE（Mixture of Experts） 者為混合專家模型。
Gemma 4 26B A4B
25.2B
實際啟用 ≈3.8B
Q4_0MoE
GLM OCR BF16 (0.9B)
0.9B
F16計分例外
GLM-4.6V-Flash 9B
9.4B
Q4_K_M
Kimi-VL-A3B-Instruct
16B
實際啟用 ≈3B
Q4_K_MMoE
8.2 評分指標（皆為越高越好）
Exact Match
答案跟正確答案（ground truth, GT）一字不差才算對。
Containment Match
正確答案是否完整出現在模型答案裡（允許多輸出）。
ANLS
用編輯距離算相似度，低於 0.5 直接以 0 分計。
Character F1
拆成單字比對，答對多少、又多打多少，綜合算分。
計分例外：GLM OCR BF16 (0.9B) 有時回傳正常文字，卻同時標記 done=false 且缺統計欄位。人工確認後，只有這個模型放寬規則：有回傳文字就納入計分，但註記「無法判斷是否截斷」，效率數據不能與其他模型比較。
09 / OMNIDOCBENCH
OmniDocBench：整頁文件解析
使用 Hugging Face 的 opendatalab/OmniDocBench，鎖定 v1.6、共 1,651 頁，涵蓋多語言、多欄排版、表格、公式、模糊掃描等情境。提示詞要求輸出整頁 Markdown：保留閱讀順序、表格轉成保留合併儲存格的 HTML table、公式以 LaTeX 表示。
Gemma 4 系列
E2B · E4B · 12B
26B A4B · 31B
InternVL3.5
4B · 38B
社群轉換 GGUF（GPT-Generated Unified Format） 版
9.1 評分方式：官方 evaluator
與 TC_STR 自行算分不同，這裡用 OmniDocBench 官方釘死版本的評分程式，跑在 Docker 容器裡，確保評分邏輯不因主機環境而異。
↓ 越低越好
Text 編輯距離
純文字與正確答案差多少（正規化後）。
↑ 越高越好
Formula CDM（Character Detection Matching）
公式結構與內容是否比對正確。
↑ 越高越好
Table TEDS（Tree-Edit-Distance-based Similarity）
表格樹狀結構的相似度。
↓ 越低越好
Reading Order
閱讀順序是否與正確答案一致。
官方綜合
Overall
((1−text edit)×100
+ TEDS + CDM) ÷ 3
另保留與 TC_STR 相同的 4 個補充診斷指標，但標註「非官方排行榜指標」，避免與正式分數混淆。
用參數量較小的模型（如 Gemma 4 E2B）跑完整測試集時，約 30% 的輸出會出現「答案不斷復讀」。這類輸出流入官方 matching 流程後，連內建用來處理長輸入的chunked Hungarian algorithm備援機制也會一起卡死、不回傳結果。
temperature: 1.0
temperature 設太低容易誘發復讀，故 OmniDocBench 固定 1.0（TC_STR 為 0）。
10 / RESULTS
研究結果
以下圖表寬度均依表格數值等比例縮放，與數字完全一致。
10.1 跑分參數與設定
兩套 benchmark 都採「固定 prompt ＋ 固定 generation 參數，全模型共用」的設計，設定檔裡沒有任何 per-model 覆寫；模型之間唯一的差別只有 tag、量化方式與 model id。以下數值皆直接取自實際執行時的設定檔。
TC-STR
TC_STR/config.yaml · models.yaml
8 個模型共用同一組參數與 prompt：tc_str_bench/config.py 強制要求剛好 8 個 model id，且 settings.prompt／settings.options 為全域讀取，無 per-model 覆寫。
Ollama 呼叫
- endpoint/api/generate
- streamfalse
- thinkfalse
- keep_alive5m
- timeout180 s
- max_attempts3
- retry_backoff2 s · 5 s
※ keep_alive = 5m 由 runner 在呼叫時傳入；config.yaml 內的 keep_alive: 0 只用於模型的 preload／unload。
Generation options
- num_ctx65536
- num_predict80
- temperature0
- repeat_penalty1.0
- top_k64
- top_p0.95
Prompt · 繁體中文短文字辨識
你是一個專業的OCR文字辨識引擎。請仔細觀察圖片，只輸出圖片中看到的文字內容（繁體中文為主，若同時有英文或數字也一併輸出），只回傳純文字本身，不要輸出HTML標籤、Markdown或JSON等任何格式化標記，不要加任何解釋、前綴或後綴、標點符號以外的內容，不要翻譯，不要加引號。如果部分文字模糊、傾斜或被遮擋，也要盡量根據字形推斷最可能的字。
OMNIDOCBENCH
OminDocBench/config/benchmark.json
所有模型共用同一組推論參數與 prompt：core.py 的報告區塊本身即標示「Common prompt/options」，並以 SHA-256 雜湊記錄一致性。
Ollama 呼叫
- endpoint/api/generate
- streamfalse
- thinkfalse
- batch_size1
- keep_alive10m
- timeout1800 s
- max_attempts3
- backoff5 s · 20 s
- kv_cache_typefp16
Generation options
- num_ctx65536
- num_predict16384
- temperature1.0
- repeat_penalty1.0
- top_k64
- top_p0.95
- seed20260731
Prompt · 整頁文件轉 Markdown
請將這一頁文件完整解析為 Markdown。依照原始閱讀順序保留所有可見文字；標題、段落、清單與程式碼請使用適當的 Markdown；表格請以能保留列、欄與合併儲存格結構的 HTML table 輸出；行內公式與獨立公式請使用 LaTeX；不要描述圖片內容，不要加入解釋、前言、結語或 code fence，只輸出解析後的文件內容。
※ prompt_source 標明這是 user-specified fallback：官方 OmniDocBench v1.6 repo 並未提供 Gemma 專用推論腳本，也沒有通用的 end-to-end VLM prompt。
取樣參數：兩套 benchmark 完全一致
top_k 與 top_p 在兩邊都是寫死在設定檔裡的固定值，不是沿用 Ollama 的內建預設，而且兩套 benchmark 使用的值完全相同。真正的差別只有 temperature（TC-STR 為 0，OmniDocBench 為 1.0，用來抑制復讀迴圈）與 num_predict（80 對 16384）。
| 參數 | TC-STR | OmniDocBench |
|---|
| top_k | 64 | 64 |
| top_p | 0.95 | 0.95 |
OmniDocBench 評分器參數（官方 evaluator，非模型端設定）
—match_method = quick_match、match_workers = 1、cdm_workers = 3、teds_workers = 3
—quick_match_truncated_timeout_sec = 300、match_timeout_sec = 420
—逾時備援：timeout_fallback_max_chunk_span = 10、timeout_fallback_order_penalty = 0.1
—match_workers 由官方預設的 4 降為 1，是為了避免小模型的復讀輸出讓評分程式卡死（詳見 09 章 DEBUG LOG）。
10.2 TC_STR 全量跑分結果
全量 3,706 筆測試集，依 EM 由高到低。數值取自 run tcstr_20260729T162125139376Z 的 primary leaderboard。
Kimi-VL-A3B-Instruct
38.5
GLM-4.6V-Flash
Gemma 4（越深＝模型越大）
Kimi-VL-A3B
GLM OCR BF16 (0.9B)（截斷率最高）
事後驗證
GLM-4.6V-Flash（9.4B）為何贏過 Gemma 4 31B（30.7B）？
逐題比較後發現，GLM 的優勢並不是平均出現在所有題目：在 sign 類別領先 14.2 個百分點，明顯高於 billboard 的 6.8pp 與 poster 的 4.5pp。進一步抽查 194 筆「GLM 答對、Gemma 答錯」的 sign 題目後，我們發現 Gemma 常在小型裁切文字上出現形近字誤判，也較容易因圖片模糊或解析度不足而直接放棄作答。這些現象可能是 sign 類別差距較大的原因之一。
因此，從目前的結果看來，我們更傾向推測「兩個模型對困難短文字的辨識能力有所差異」，而不只是模型參數量大小造成的差別。
事後驗證
Gemma 4 26B A4B（MoE，實際啟用≈3.8B）以些微差距超過 31B 稠密模型
在 TC-STR 短文字 OCR 測試中，Gemma 4 26B A4B 雖然是 MoE 架構、每次推論只啟用約 3.8B 參數，仍以 82.0% 略高於 Gemma 4 31B 的 80.6%。這表示在這類短文字辨識任務上，模型規模較大不一定就會取得更高分。
不過，到了 OmniDocBench 的整頁文件解析任務，結果正好相反：31B 反而領先 26B A4B 8.5 分。這顯示 26B A4B 的優勢可能與任務特性有關，並不代表 MoE 架構本身優於稠密模型。（詳見下方 10.3 節）
EM 完全相符
CM 包含比對
GLM OCR BF16 (0.9B) 是唯一 EM 遠低於 CM 的模型，落差達 40.5 個百分點。
事後驗證
GLM OCR BF16 (0.9B) 的 EM／CM 為何差這麼多？
GLM OCR BF16 (0.9B) 的 EM 與 CM 相差 40.5 個百分點，代表不少回答雖然包含正確文字，卻因為多輸出了其他內容而無法通過 EM。可惜這次沒有保留 BF16 的逐題原始輸出，因此我們改用同模型家族的 GLM-OCR Q8_0 資料做參考分析。
在 Q8_0 的 3,706 筆回答中，約 19.8% 出現格式失控，例如多餘的 Markdown 標記或回答正確後繼續生成文字。這些案例的 EM 為 0%，但 CM 達 76%，呈現與 BF16 類似的落差型態。
不過，真正「同一句話反覆重複」的案例只有 0.24%。更常見的是模型已經答對，卻又繼續輸出額外內容。此外，回答越長，格式失控的比例也越高。這些結果顯示，過度生成可能是 EM／CM 落差的重要原因之一。
平均延遲
秒／題 · 越低越好
Kimi-VL-A3B-Instruct
0.33s
GLM OCR BF16 (0.9B)
0.27s
截斷樣本比例
佔 3,706 筆 · 越低越好
Kimi-VL-A3B-Instruct
12.2%
GLM OCR BF16 (0.9B)
54.9%
事後驗證
Kimi-VL-A3B 的高截斷率，主要來自重複生成失控
逐題分析發現，Kimi-VL-A3B 的 453 筆截斷案例全部都是撞到 80-token（模型處理文字的最小單位）的生成上限，其中 452 筆甚至沒有包含正確答案。多數輸出會陷入單字、短詞或提示詞的重複迴圈，而不是「答案太長來不及輸出完」。
這類問題特別集中在 1–4 字的短答案與招牌類圖片。相同題目下，Gemma 4 26B A4B 只有極少數案例出現類似現象，顯示這不是資料本身太難就足以解釋的結果。
兩個模型使用相同的生成設定：temperature=0、repeat_penalty=1.0。這組設定會讓模型一旦開始重複，就缺少機制跳出迴圈，因此可能把原本短暫的辨識失誤放大成一路生成到上限。不過，為什麼 Kimi-VL 比 Gemma 更容易掉進這種迴圈，目前仍無法確認；量化版本、模型本身的生成穩定性或模板設定都還需要額外實驗才能判斷。
| # |
MODEL |
EM↑ |
CM↑ |
ANLS↑ |
F1↑ |
延遲 |
截斷 |
| 1 |
GLM-4.6V-Flash 9B |
88.37% |
88.45% |
94.07% |
94.30% |
0.41s |
0 / 3,706 |
| 2 |
Gemma 4 26B A4B |
81.98% |
82.46% |
88.71% |
89.58% |
1.18s |
7 / 3,706 |
| 3 |
Gemma 4 31B |
80.63% |
81.17% |
87.82% |
88.55% |
1.20s |
0 / 3,706 |
| 4 |
Gemma 4 12B |
58.90% |
60.39% |
72.89% |
75.06% |
1.27s |
4 / 3,706 |
| 5 |
Gemma 4 E4B |
48.95% |
49.19% |
69.99% |
72.87% |
1.22s |
109 / 3,706 |
| 6 |
Gemma 4 E2B |
43.20% |
43.82% |
66.52% |
70.09% |
1.16s |
126 / 3,706 |
| 7 |
Kimi-VL-A3B-Instruct |
38.51% |
39.64% |
49.86% |
53.69% |
0.33s |
453 / 3,706 |
| 8 |
GLM OCR BF16 (0.9B) |
36.70% |
77.23% |
40.72% |
45.41% |
0.27s |
2,034 / 3,706 |
指標提醒
ANLS 的 0.5 閥值對中文短詞不夠細緻
傳統 ANLS 在計算時通常設有一個 0.5 的閥值（Threshold），大於或等於 0.5 算有效辨識，低於 0.5 則歸零。這對拼音文字（如英文單字容許拼錯部分字母）很有效，但對短小精悍的中文詞彙（如兩三個字的專有名詞、數字、代碼），稍微錯一個字就直接低於 0.5 而被判為 0 分，對中文不夠公平與細緻。
KEY 01
GLM-4.6V-Flash 9B 全面最強
EM／CM／ANLS／F1 四項全部最高，零截斷、零異常、成功率 100%，速度也是數一數二快（0.41 秒／題）。
KEY 02
Gemma 越大越準，但非線性
26B A4B（MoE，實際啟用 ≈3.8B）以 82.0 些微超過參數更大的 31B 稠密模型（80.6），與 10.3 節「嚴格隨參數量遞增」不同。
KEY 03
GLM OCR BF16 (0.9B) 的 EM／CM 落差
54.9%（2,034／3,706）樣本被標記截斷：答案常「藏」在輸出裡（CM 高），但格式失控而在嚴格比對下失分（EM 低）。
延伸觀察
—推論速度跟架構的關係比參數量更直接：三個非 Gemma 模型延遲都在 0.27～0.41 秒，遠快於所有 Gemma 4（1.15～1.27 秒），可能與量化方式（F16／Q4_K_M vs Q4_0）或推論架構有關。
—Kimi-VL-A3B-Instruct 雖是 MoE、實際啟用參數小，異常率卻不低（453 筆截斷），EM 僅 38.5%：MoE 本身不保證穩定性，仍要看個別模型的訓練與量化品質。
10.3 OmniDocBench 全語料庫跑分
官方 evaluator 在全語料庫 1,651 頁上的正式分數，依 Overall 由高到低。Overall 只吃 text、table、formula 三項。
Qwen3-VL
Gemma 4
InternVL3.5
事後驗證
短文字 OCR 的優勢，到了整頁文件解析就消失了
在 TC_STR 短文字 OCR 中，Gemma 4 26B A4B 曾以些微差距勝過 Gemma 4 31B；但到了 OmniDocBench 的整頁文件解析，結果完全反轉：26B A4B 得分 63.4，31B 則是 71.9，領先 8.5 分。
我們推測，這可能和任務複雜度有關。整頁文件解析除了辨識文字，還要同時處理版面、表格與公式等資訊，因此比短文字 OCR 更需要整合多種能力。
四維能力雷達
全部換算為 0–100，越外圈越好
Text／Order 已由編輯距離換算為準確度（1 − edit）。點選右側模型即可疊圖比較。
選擇要疊圖的模型
| # |
MODEL |
OVERALL↑ |
TEXT EDIT↓ |
TEDS↑ |
CDM↑ |
ORDER↓ |
| 1 |
Qwen3-VL 32B |
85.31 |
0.111 |
0.785 |
0.885 |
0.206 |
| 2 |
Qwen3-VL 4B |
75.62 |
0.149 |
0.676 |
0.742 |
0.243 |
| 3 |
Gemma 4 31B |
71.93 |
0.286 |
0.632 |
0.813 |
0.276 |
| 4 |
InternVL3.5 38B |
70.47 |
0.255 |
0.579 |
0.790 |
0.282 |
| 5 |
InternVL3.5 4B |
69.64 |
0.196 |
0.593 |
0.693 |
0.258 |
| 6 |
Gemma 4 26B A4B |
63.43 |
0.374 |
0.553 |
0.724 |
0.351 |
| 7 |
Gemma 4 12B |
37.46 |
0.644 |
0.301 |
0.467 |
0.502 |
| 8 |
Gemma 4 E4B |
26.89 |
0.714 |
0.204 |
0.317 |
0.549 |
| 9 |
Gemma 4 E2B |
17.32 |
0.801 |
0.068 |
0.252 |
0.627 |
KEY 01
Qwen3-VL 32B 全面領先
Overall 把第二名拉開近 10 分，表格 TEDS 與公式 CDM 都是九個模型中最好的。
KEY 02
Gemma 4 幾乎與參數量成正比
從 E2B（17.3）一路爬到 31B（71.9），沒有中途停滯，顯示文件解析能力很吃模型規模。
KEY 03
小模型不一定輸大模型
Qwen3-VL 4B（75.6）打贏 Gemma 4 31B；InternVL3.5 從 4B（69.6）放大到 38B（70.5）也只好一點點。
延伸觀察
—Gemma 4 E2B 的 table TEDS 只有 0.068，幾乎等於「看不懂表格」；同系列放大到 31B 才追到 0.632，表格結構理解對小模型特別吃力。
—formula CDM 普遍是九個模型裡相對最好的一項，即使最小的 E2B 也有 0.252，推測與 LaTeX 符號結構相對固定有關。
—Qwen3-VL 4B 與 InternVL3.5 4B 的 Overall 都超過「號稱較大」的 Gemma 4 26B A4B（63.4）：架構與訓練資料品質，有時比帳面參數量更關鍵。
事後驗證
Gemma 4 E2B 表格分數崩到 0.068，真的是「版面類型」造成的嗎？
我們原本懷疑是跨頁表格、合併儲存格或多欄排版等複雜版面造成，但 OmniDocBench 並沒有完整提供這些表格類型的標註，因此目前無法直接驗證。現有資料甚至顯示，含表格的頁面並沒有特別集中在多欄版面，讓「多欄排版是主因」這個解釋缺乏支持。
另一條可能的線索是小模型常出現長篇復讀，而表格通常需要輸出較長、結構較複雜的內容。我們推測，這可能讓 E2B 在表格任務上更容易失控，進而拉低分數。
事後驗證
公式辨識受模型規模影響較小，但並不是完全沒有影響
我們原本以為，可能只是 OmniDocBench 裡的公式比較簡單，所以小模型也能拿到不錯的分數。但檢查 2,066 條公式後發現，測試集中其實有不少矩陣與複雜 LaTeX 結構，因此「題目太簡單」並不足以解釋這個現象。從結果來看，公式 CDM 確實比表格 TEDS 更不容易因模型變小而大幅下降。不過，CDM 仍會隨模型規模增加而提升，因此比較準確的說法是：公式辨識對模型規模相對不敏感，而不是完全不受影響。
我們推測，這可能與公式中的符號與結構具有較固定的視覺模式有關；相較之下，表格還需要同時理解欄列位置與跨儲存格關係，因此可能更依賴模型的整體能力。不過目前沒有逐公式的分析可以直接證實這個原因。
10.4 結果呈現方式
README 特別強調不把「正在跑」的分數寫死在文件裡，實際數字以每次評測輸出資料夾裡的報告為準。工具本身還會產出：
互動式比較報告（HTML）
可依任何指標排序、篩選「表現最好／最差／隨機抽樣」的頁面，快速找出模型的弱點情境。
詳細統計
成功率、API 失敗次數、重試次數、空白輸出次數、平均延遲，區分「模型能力問題」與「系統工程問題」。
逐頁／逐題原始紀錄
模型原始回答完整保留，供之後追查或人工複核。
11 / ENGINEERING CHALLENGES
技術挑戰的核心：如何讓分數可信
以下三個案例最能呈現這份實習的研究工程性質：這三個案例的根源都在實驗設計，會直接影響分數能不能被解讀，不只是程式寫錯這麼簡單。
Problemprompt、答案處理方式和評分規則不同，可能讓分數差異不只來自模型本身。
Action先把兩套測試流程調成相同設定，再每次只改一項條件，共比較 7 組設定，其中 5 組需要重新讓模型作答。
Outcome結果顯示，僅僅只改一項設定就可能讓 EM 分數大幅變動。我們也因此在之後的實驗都會完整記錄下實際使用的設定。
Problem部分小模型會不斷重複輸出相同內容，比例約三成。這些過長的回答不只影響模型表現，也可能讓 OmniDocBench 的評分程式無法順利完成。
Action我們將 temperature 從 0 調整為 1，長篇重複輸出的情況明顯減少。同時參考
官方 issue #228，將 match_workers 從 4 降為 1，並先用小規模測試確認設定能穩定執行。模型的原始輸出也完整保留，方便後續追查。
Outcome調整後，評分流程可以穩定完成。模型的重複輸出仍會照實計入結果，不會在評分前額外刪除或修正。
Problem模型 tag、資料 revision 或 evaluator commit 只要悄悄改變，舊結果和新結果就可能被錯誤混用。
Actionresume key / run signature 納入 model digest、dataset fingerprint、prompt hash 與 dependency lock；第三方 GGUF 另存來源與風險。
Outcome任一關鍵設定不同即視為新實驗，不與舊資料混跑；每一個分數都能沿 metadata 回溯到實際執行條件。
12 / DELIVERABLES & REFLECTION
實習結束後留下的成果
01 · EVALUATION PIPELINES
可重跑的評測工具
eval/、ablation_experiment/、benchmark_suite/、TC-STR_and_OminDoc/，涵蓋短文字 OCR、整頁解析與多模型比較。
02 · REPRODUCIBILITY METADATA
讓結果具備來源證明
run manifest、dataset manifest、model digest、prompt hash、version pinning、protocol exceptions，避免「同名但不同實驗」被混為一談。
03 · EVIDENCE & REPORTS
原始證據與互動式成果
raw response、逐筆 CSV／JSON／SQLite、消融結果與自包含 HTML 報告，讓結論可以被人工複核，而不是只剩最後一個百分比。
04 · HANDOFF DOCUMENTATION
可交接的研究文件
方法論、指標、版本釘選、模型來源、執行環境與例外紀錄被寫成文件，降低研究只存在於原作者記憶中的風險。
WHAT THIS INTERNSHIP TAUGHT US
Benchmark 分數是整條 pipeline 的產物
模型、prompt、generation options、後處理與 scorer 都可能改變結果。比較模型之前，先確認測量方式是否對齊。
可重現性不是報告附錄
長時間 benchmark 必須從一開始就設計 resume、版本身分、異常紀錄與原始輸出保存，而不是跑完再補文件。
失敗案例本身就是研究資料
復讀、截斷、metadata 缺失與 evaluator hang 不該被靜默清除；留下它們，才能知道系統真正的使用邊界。
後續事後驗證：六個假說的結果（詳見 10.2／10.3 各圖表下方的「事後驗證」區塊）
—六項假說沒有一項能被完整證實：根本原因是 TC_STR bench 與 OmniDocBench 的逐題／逐頁原始輸出從未提交到 repo，只留下彙總分數——這也印證了上方「可重現性不是報告附錄」這一課。
—最重要的修正：Gemma 26B A4B「以小勝大」只在 TC-STR 短文字任務成立，換到 OmniDocBench 整頁解析反而輸 31B 8.5 分，不是穩定的 MoE 優勢，而是任務依賴的個案。
—Kimi-VL 的不穩定原本被歸咎於 MoE 架構，反向證據推翻了這個猜測，改指向第三方非官方量化版本這條更有根據的線索。
—GLM-4.6V-Flash 勝過 Gemma 31B 已排除計分不公平造成假象，但「為什麼」在架構或訓練資料層面仍是未解之謎，留待補齊逐題資料後再驗證。
13 / SUMMARY
研究限制、未來展望與結語
這份專案的核心價值，是建立一套嚴謹、可重現、可驗證的評測方法；「哪個模型比較強」只是過程中的副產品。做法是：固定資料、提示詞與推論設定，搭配雜湊指紋、版本鎖定、檢查點與例外紀錄，使每一次分數都能回溯到具體條件。這無法消除所有 benchmark 偏差，但能讓本次模型比較中的非模型因素更透明，也讓後續研究者知道哪些結果可以比較、哪些必須保留限制。
研究限制
GLM OCR BF16 (0.9B) 需搭配例外規則解讀
因 completion metadata 缺失採用放寬計分，EM／CM 落差與截斷率並非與其他 7 個模型完全同等條件。
部分模型為社群轉換版本
InternVL3.5（4B／38B）是社群自行轉換的 GGUF 量化版，效能可能與官方原生版本有落差。
MoE 的「實際啟用參數」是估算值
Gemma 4 26B A4B、Kimi-VL-A3B-Instruct 標注的啟用參數為概念性估算，非官方精確數字。
抽樣報告與全語料庫結果不可互換
互動式比較報告只挑最佳／最差／隨機各 5 頁（共 15 頁）；本頁採用全語料庫 1,651 頁官方分數。
跨環境重現性有其極限
即使固定 temperature=0、鎖定 digest 與資料版本，換了 Ollama 版本、驅動或硬體仍不保證逐字元一致。
未來展望
GLM OCR BF16 (0.9B) 異常樣本錯誤分析
逐題檢視 2,034 筆截斷樣本，釐清哪類文字（長句、密集小字、特殊符號）容易誘發復讀。
弱項子指標細部分析
針對小模型的 table TEDS，找出是哪類版面（跨頁、合併儲存格、多欄）造成失分。
整合成可持續更新的 dashboard
把互動式比較報告與靜態圖表整合，新模型跑完就能自動併入比較。
14 / ACKNOWLEDGEMENTS
致謝
本報告經費來自 FreeSEED 結餘款，感謝 FreeSEED 所有捐款人
感謝 Twinkle AI 創辦人 黃亮勳 提供技術指導