iT邦幫忙

鐵人檔案

2026 iThome 鐵人賽
回列表
AI Engineering

從 LLM 到 Harness: 打造隱私與可信任的繁中進階 OCR Agent 系列

hi 鐵人賽 我又回來啦

繁體中文文件辨識長期面臨字型多變、排版複雜、手寫與印刷混雜,以及大量領域專有名詞與專業術語的挑戰。傳統 OCR 僅能做到「看到字」,卻難以真正「理解字義」。當文件涉及法律、醫療、財務或技術領域時,單一字元錯誤就可能導致整段語意失真。

本系列從「LLM OCR」出發——不只是用大型語言模型輔助後處理,而是讓 LLM 深度參與辨識流程,結合視覺與語言能力進行端到端的文字提取與校正。更關鍵的是,系統會導入領域字義理解機制,透過領域知識庫、術語詞典與上下文推理,讓模型能辨識並正確詮釋專業詞彙,大幅降低「看對字卻解錯意」的情況。

參賽天數 16 天 | 共 16 篇文章 | 0 人訂閱 訂閱系列文 RSS系列文 |團隊nutc imac
DAY 1

Day 1 - 從 LLM 到 Harness:打造隱私與可信任的繁中進階 OCR Agent 開賽宣言

去年寫完《Android 不會只更新 UI!用 Vibe Coding 加速打造 AI-native App》的最後一篇,我就在想一件事那系列在講「怎麼讓 AI...

2026-09-15 ‧ 由 onedream 分享
DAY 2

Day 2 - 單一模型 baseline:Gemma 4 直接跑整頁會怎樣

昨天我說,先讓你看它壞掉。 今天直接跑這個測試。 規則很簡單:不搭架構。一頁圖丟進去,叫它把字讀出來。 沒有版面偵測、區塊分流、前後處理,也沒有驗證。 這是刻意...

2026-09-16 ‧ 由 onedream 分享
DAY 3

Day 3 - DGX Spark GB10:硬體限制怎麼反過來決定架構

昨天我們看到一顆 26B 的模型直接吃整頁文件會怎麼壞 今天要講的是另一半:就算你想用更大的模型去救它,你的硬體也不會答應 而且不是「跑不動」那種不答應 是跑得...

2026-09-17 ‧ 由 onedream 分享
DAY 4

Day 4 - vLLM 部署與量化格式選擇

昨天結論是:單序列速度撞到記憶體頻寬的物理上限,調參救不回來,只剩兩條路 今天走第一條:量化 我先講結論,因為這篇會有點長: 量化不是「把模型變小」,是「用精度...

2026-09-18 ‧ 由 onedream 分享
DAY 5

Day 5 - Batch 推理、Speculative Decoding 與 Phase 1 收斂

Day 3 的結論是「調參救不回來,只剩量化跟推測解碼兩條路」 Day 4 走完第一條 今天走第二條,然後把 Phase 1 收掉 先預告今天的結局:我們會得到...

2026-09-19 ‧ 由 onedream 分享
DAY 6

Day 6 - 繁體中文字型與版面難點:為什麼「進階」不是行銷詞

昨天收 Phase 1 的時候我講了一句可能會害到自己的話:今天測的法說會簡報,版面其實相當乾淨 今天這篇就是去把髒的找出來 而且不是我用眼睛翻頁挑的,是用分數...

2026-09-20 ‧ 由 onedream 分享
DAY 7

Day 7 - 繁簡混排與異體字:正規化前先搞懂差異

昨天結尾我留了一個問題:錯誤分類表裡,簡體字、異體字、形近字三個類別的計數全是 0 而我明明在第 24 頁親眼看到「綠」被讀成「線」 今天這篇要講一個「沒炸」的...

2026-09-21 ‧ 由 onedream 分享
DAY 8

Day 8 - 繁中挑戰總結:這些問題怎麼倒推出系統設計

兩天前我說要把繁中的難點攤開,現在攤完了 桌上有一堆壞掉的東西:位置跑掉的貨幣符號、被吃掉的總數、讀成「線」的「綠」、重複一百次的材料名、以及三個誠實的 0 今...

2026-09-22 ‧ 由 onedream 分享
DAY 9

Day 9 - 為什麼選 Gemma 4:26B MoE vs 31B Dense 架構差異

繁中的難點攤開之後,總要有一顆模型去承擔它們 所以今天回到最基本、也最容易被跳過的那一題:選型 而我要先講一句可能有點掃興的話——這一題在我這台機器上,有一半是...

2026-09-23 ‧ 由 onedream 分享
DAY 10

Day 10 - 純文字區與表格區實測:50 tok/s 與 7 tok/s 的取捨

昨天的結論是「平均而言 MoE 比較划算」 今天要處理的是那個「平均」兩個字 因為 Day 2 就已經告訴我們一件事:這份文件根本不是均質的。純文字頁覆蓋率 9...

2026-09-24 ‧ 由 onedream 分享