space ocr
指南文章價格文件

具備稽核軌跡的文件 OCR

大多數 OCR 只丟給你一堆得照單全收的文字。space-ocr 則為每個數值附上一個已驗證的頁面位置——邊界框、頂點與比對比例(match ratio)——讓任何欄位都能回溯到它原本所在的像素。

從文件中擷取資料,做個展示很容易,要讓人信得過卻很難。一個模型讀了一張發票,回傳 total: 2,045,於是你面對一個任何信心分數都無法真正回答的問題:這到底是頁面上實際印著的數字,還是模型自己生出來的? 如果只是臨時查一筆資料,這倒無所謂。但換成會計、理賠處理、法遵合規,或任何你日後得接受稽核的場景,「相信模型就對了」根本稱不上是一種控管。

稽核軌跡正好補上這一塊。每個欄位回傳的不再只是一個光禿禿的數值,而是附帶一個已驗證的頁面位置——這樣一來,人(或另一套系統)就能直接跳到該數值被讀取出來的那組像素加以確認。這正是「一個答案」與「一個你能站得住腳的答案」之間的差別。

親眼看看:每個數值都回溯得到源頭

把游標移到下方任一欄位上。收據上那個框,就是該數值被讀取出來的位置——而且每個欄位都各自帶著自己的比對比例。

Receipts with extracted-field bounding boxes
Verified fields
KINSHO · 合計 2,045
ライフ · 合計 4,286

Each value with a box carries a verified on-page location — bbox + 4-point vertices + match_ratio — on a 0–1000 normalized grid (0,0 top-left → 1000,1000 bottom-right), the same shape the live API returns. Hover a field to trace it back to the pixels it came from.

「已驗證的位置」實際上是什麼意思

space-ocr 在每個擷取出來的數值旁,會一併回傳三樣東西:

  • bbox — 一個與座標軸對齊的矩形 { xmin, ymin, xmax, ymax },落在 0–1000 normalized 的網格上(0,0 = 左上角,1000,1000 = 右下角),與圖片的像素尺寸無關。
  • vertices — 四個有序的點 {x, y}(左上 → 右上 → 右下 → 左下),構成一個會跟著文件傾斜角度走的帶方向邊框,因此就算是拍歪的手機照片,框線也能貼合得乾乾淨淨。
  • match_ratio — 該數值中,實際在頁面上定位到的字元所占的比例(0–1)。當這個值達到 ≥ 0.85 時,該欄位就被視為高信心比對成功;1.0 表示每個字元都被找到了。

因為位置資訊是跟著數值一起回傳的,結果就不再是個黑盒子。你可以把框畫出來、引用座標,或重新查核某個被標記的欄位,完全不必再跑一次 OCR。

✓ Verified

這些座標並不是直接採信模型講的。 語言模型會回傳每個數值的文字——以及它用到了哪些 word token 的提示——但從不回傳框本身。接著引擎會拿那段文字,去和視覺 OCR 在頁面上實際偵測到的符號做字元比對,讓框落在那些字元真正被找到的像素上,並為每個數值算出一個比對比例:它的字元中實際被定位到的占比。模型給的 token 提示可能有雜訊——在重複的列之間有時還會張冠李戴——所以引擎會用欄與列的一致性檢查去驗證它們,而不是盲目採信。重點不在於 AI 不會出錯,而在於每個數值都會回頭對照頁面查核,並附上一個說明它比對得多吻合的分數。

點一下數值,直接落在像素上

在 App 裡,這變成了一種互動:點任一格,原始圖片就會把該數值所來自的那個框精準地標亮出來,還附上放大裁切與一條連接線。要抽查一整批資料,這是最快的方式——你的視線直接落到那個點上,而不必把整份文件從頭掃一遍。

點任一格 → 對應的區域就會在原始圖片上亮起來。

修改紀錄同樣可稽核

稽核軌跡不只關乎機器的輸出——也關乎人到底改了什麼。當你編輯一格時,space-ocr 會把你的修改與原始 OCR 數值分開保存。Original 提示框永遠會顯示引擎一開始讀到的內容,讓審核者能把機器的數值與人工覆寫的值並排對照。

編輯某一格後,原始的 OCR 數值會被保留在 Original 提示框底下。

它就在 API 裡,附在每個數值上

這並不是只有 UI 才有的功能。POST /ocr/fields 會在每個擷取出來的數值上回傳同樣的 bboxverticesmatch_ratiobbox_source,並用一份 field_bboxes 對照表逐欄位給出座標。當你用 GET /view 查詢已儲存的試算表時,這些框預設就會一起帶回來——只有在你想要更精簡的回應內容時,才加上 boxes=0

POST /ocr/fields → 回應(節錄)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
  "status": "success",
  "data": {
    "total": "2,045",
    "field_bboxes": {
      "total": {
        "bbox": { "xmin": 595, "ymin": 974, "xmax": 781, "ymax": 1000 },
        "vertices": [
          { "x": 594, "y": 975 }, { "x": 781, "y": 972 },
          { "x": 781, "y": 998 }, { "x": 595, "y": 1000 }
        ],
        "match_ratio": 0.93,
        "bbox_source": "vision_symbol_match"
      }
    }
  }
}

bbox_source 會告訴你每個座標是怎麼推導出來的——vision_symbol_match 是常見的字元比對路徑(會帶著它真正的 match_ratio),token_id 表示用到了 word-token 提示,而 low_confidence 則標記出一個值得再看一眼的弱比對。這是一份你可以記錄、過濾,或呈現給審核者看的中繼資料(metadata)。

實務上如何驗證一個數值

  1. 打開擷取結果
    打開試算表,或呼叫 GET /view——每個數值都帶著它的 bbox、vertices 與 match_ratio。
  2. 點一下該數值
    點該格,就能在原始圖片上標亮它被讀取出來的確切區域。
  3. 查看比對比例
    match_ratio 為 1.0 表示每個字元都被定位到了;低於 0.85 則標記出一個值得再仔細看一眼的數值。
  4. 必要時加以修正
    編輯該格即可覆寫它——為了稽核軌跡,原始的 OCR 數值會被保留在 Original 提示框底下。
什麼是 OCR 稽核軌跡?
稽核軌跡意味著每個擷取出來的數值,都能回溯到它在原始文件上的確切位置。在 space-ocr 中,每個數值都會帶著一個邊界框、四個帶方向的頂點,以及一個比對比例(match ratio),因此結果可以被引用、被重新查核,而不是只能照單全收。
AI 會不會乾脆把邊界框給編出來?
模型從不回傳座標——它只回傳數值的文字,外加它用到了哪些字詞的提示。接著引擎會拿那段文字,去和視覺 OCR 在頁面上實際偵測到的符號做字元比對,並回報一個 match_ratio,說明其中有多少被找到了。模型給的 token 提示同樣不會被盲目採信——它們會與欄、列的一致性交叉查核——因此一個框反映的是某個數值的字元真正被找到的位置,而不是模型「以為」它們所在的位置。一個根本不在頁面上的數值,是不可能拿到高 match_ratio 的。
回傳的座標是以像素為單位嗎?
API 回傳的是一個 0–1000 normalized 的網格(0,0 為左上角,1000,1000 為右下角),與圖片的解析度無關。換算成像素的公式為 pixel_x = bbox_x / 1000 × image_width。
驗證會額外收費,或是會重跑一次 OCR 嗎?
不會。框是標準回應的一部分,而用 GET /view 查詢已儲存的試算表,絕不會重跑 OCR,也不會產生任何費用。當你不需要框時,可以用 boxes=0 把它們去掉,換取更精簡的回應內容。

拿你自己的文件來試試看

免費方案——每月 100 次掃描,免綁信用卡。每個數值回傳時都附帶它在頁面上的位置。

相關