在找 Amazon Textract 的替代方案嗎？
公允、經過事實查核地探討何時該選擇 Amazon Textract 的替代方案——逐值的來源座標、明確指出該複核哪些值的清單、CJK（日文／韓文／中文）支援、可查詢的表格、單一固定定價、免設定 AWS。
Amazon Textract 是一個能力出色、相當成熟的 OCR 服務，對於一條以 AWS 為核心、大規模處理英文文件的流水線來說，把它當作預設選擇是合理的。但「能力出色」和「適合你這份工作」並不是同一件事，而有幾個實際的限制，會讓人開始尋找 Amazon Textract 的替代方案：
- CJK 不在支援語言清單上。 Textract 的印刷文字、表單和表格功能涵蓋一組拉丁字母語言（英文、法文、德文、義大利文、葡萄牙文、西班牙文）；手寫、發票／收據（AnalyzeExpense）、證件（AnalyzeID）和 Queries 則被標示為僅限英文。日文、韓文和中文都不在那份清單上。
- AWS 的引力。 用它就意味著要有一個 AWS 帳號、IAM、SDK、一個有支援的區域，通常還有 S3——如果你只是想送一張影像、拿回欄位，這就是一筆實實在在的設定成本。
- 按功能堆疊的單頁計價。 你按頁付費，費率取決於你呼叫的是哪個功能（純文字 vs. 表單 vs. 表格 vs. queries vs. expense），而把多個功能組合起來會讓成本疊加。
- 逐值審核是另一個服務。 Textract 回傳信心分數；人在環中的審核由 Amazon Augmented AI（A2I）負責，要你自己接起來。
這份指南是一份公允的比較——Textract 強在哪、以及像 space-ocr 這樣的替代方案適合用在哪。
評估 Textract 替代方案時該比較什麼
這兩個工具都會讀文件，並回傳帶座標的結構化資料。差別在於：你如何驗證一個值、哪些語言被涵蓋、資料如何離開工具，以及起步要花多少成本。下表為兩者列出經過驗證的事實——把它當成衡量你自己工作負載的檢查清單。
| 能力 | Amazon Textract | space-ocr |
|---|---|---|
| 定界框 | 有——每個 block 一個正規化 0–1 的 BoundingBox 加一個 Polygon | 有——每個值一個 box（{ xmin, ymin, xmax, ymax }）加一個四點 quad，都在 0–1000 的正規化網格上 |
| 逐值驗證訊號 | 每個 block 一個辨識信心（%） | 判定放在 verified，觸發的原因依排序列在 review.reasons，佐證放在 evidence（text_match、source、match_ratio） |
| 內建逐值審核 UI | Textract 本身沒有；人工審核是另一個服務（Amazon A2I） | 內建於 App——點一個儲存格，它在原圖上的確切區域就會亮起來 |
| 收據／發票欄位 | AnalyzeExpense（另一個 API），僅限英文 | 用 fields 自己宣告要擷取的欄位，或讓 autoFields 提出一份 schema——引擎讀得懂的語言都可以 |
| 明細項目 | AnalyzeExpense 的明細項目（ITEM／QUANTITY／PRICE） | 一個帶 children 的 array 欄位，每個儲存格都能用自己的路徑（items[0].price）取用 |
| 日文／韓文／中文 | 未列入（6 種拉丁字母語言；Expense／ID／手寫僅限英文） | 一個引擎自動偵測日文、韓文、中文、英文等等 |
| 可查詢的儲存 | 結果由你自己儲存與查詢 | 已儲存的表格可透過 GET /view（where、sort、select）在伺服器端查詢——不重跑 OCR，也不另外收費 |
| CSV 匯出 | 你自己從 JSON 兜出來 | 一鍵——UTF-8 BOM，明細項目已展開 |
| 計價模式 | 按頁、按功能計費；組合功能會疊加成本；還要再加上一個 AWS 帳號 | 單一固定 每張影像 $0.05；免費方案每月 100 點數、免綁卡；Pro 每月 $39 |
| 設定 | AWS 帳號 ＋ IAM ＋ SDK，區域性服務，通常還有 S3 | 一個帶 Bearer 金鑰的 HTTPS 呼叫；同一套 API 也以 MCP 端點對 AI 代理開放 |
關於「可驗證」：這些座標不是聽模型一面之詞得來的。 語言模型只回傳每個欄位的文字——外加它用到了哪些 word token 的提示——但從不自己給出那些框。引擎接著拿這段文字，去跟視覺 OCR 在頁面上實際偵測到的符號做字元層級的比對，於是框會落在這些字元真正被找到的像素上。凡是跑過這道比對的值，其儲存格會帶上 evidence.match_ratio，代表它被定位到的程度（≥ 0.85 視為高信心命中）；比對無法進行時，這個鍵就不會出現。模型給的 token 提示可能有雜訊——它有時會在重複的列之間把提示張冠李戴——所以系統用欄一致性與列一致性檢查來驗證它們，而不是盲目相信。重點不在於 AI 不會出錯：兩套機制也可能在同一個誤讀上取得一致。重點在於，安靜出錯的值會被攤開來——成為儲存格的 review 原因，以及 data.review.flagged 裡的一列。
Textract 在哪些情況下是更好的選擇
一場公允的比較，也會點出既有方案勝出的地方。以下情況請選 Textract：
- 你已經深耕 AWS，想要一個能直接接進 S3 → Lambda → Textract、搭配你既有的 IAM 和 SNS 的 OCR。
- 你的文件是英文／拉丁字母，而且你需要在極大規模下處理表單、表格和 queries。
- 你想要針對自己文件類型訓練的自訂轉接器（adapter），或是 AWS 原生的合規與資料落地保證。
如果這就是你，Textract 非常合適，換成替代方案能帶給你的好處有限。
space-ocr 反而適合用在哪
當下列其中一項或多項對你很重要時，Textract 的替代方案就有了用武之地：
- 你要處理日文、韓文或中文文件。 space-ocr 用同一個引擎跑 CJK 和拉丁字母，並自動偵測語言——不必設定任何語言參數。
- 你想驗證，而不只是相信。 業務資料留在
data.values，同一個路徑可以取到data.cells，裡面有box、quad、作為判定的verified、作為原因的review，以及作為佐證的evidence。該複核的清單只有一份，就是data.review.flagged；在 App 裡點一個儲存格，就會精確高亮它被讀出來的位置。 - 你不想自己架設儲存。 結果落在一張你可以在伺服器端查詢（
GET /view）並一鍵匯出成 CSV 的表格裡——不用資料庫，也不用 AWS 帳號。 - 你想要可預估的定價。 單一固定每張影像 $0.05、每月 100 點數、免綁信用卡的免費方案，以及每月 $39 的 Pro 方案——不會按功能堆疊頁數計費。
- 你用 AI 代理來打造東西。 同一套 API 以 MCP 端點
https://mcp.space-ocr.com/mcp對外開放——一行claude mcp add --transport http，或在mcp.json裡寫上 URL 和 Bearer 標頭即可，沒有東西要安裝。
整個呼叫就是一個 HTTP request——不用 SDK。引擎讀的是點陣影像，所以 PDF 要先把頁面轉成影像再送出（網頁版會替你完成這一步）。
curl -s https://api.space-ocr.com/ocr/fields \
-H "Authorization: Bearer $SPACE_OCR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"image": "https://example.com/invoice.jpg",
"imageType": "url",
"fields": [
{ "name": "invoice_no", "type": "string", "required": true },
{ "name": "date", "type": "date" },
{ "name": "items", "type": "array",
"children": [
{ "name": "name", "type": "string" },
{ "name": "qty", "type": "string" },
{ "name": "price", "type": "string" }
] },
{ "name": "total", "type": "number", "required": true }
]
}'值會照你送出的 schema 原樣回到 data.values。這個結構裡的每個路徑——total、items[0].price——就是 data.cells 的鍵，那裡放著 box（0–1000 網格上的 { xmin, ymin, xmax, ymax }）、一個會跟著手機歪斜照片走的四點 quad，以及 verified、review 和 evidence；座標所依據的頁面寬高由 data.image 給出。要複核的東西只列在一個地方，也就是 data.review.flagged，每一項把 path 和它的 reasons 配成一組。因為 date 和 total 宣告了純量型別，解析後的值會以稀疏的 data.normalized 樹並排回傳。完整的座標模型，請看 一個帶定界框的 OCR API；至於非同步、以 Webhook 驅動的那一面，請看 發票資料擷取 API 指南。
語言：最清楚的分界線
如果你的文件是日文收據、韓文發票或中文表單，這通常就是決定性因素。Textract 的印刷文字、表單和表格功能支援六種拉丁字母語言，而它的手寫、AnalyzeExpense、AnalyzeID 和 Queries 功能僅限英文——日文、韓文和中文都不在支援清單上。space-ocr 在同一個引擎裡把多種文字正規化（全形與半形字元、連字號變體、CJK 間距、直書漢字、混排文字），並自動偵測語言，不必傳任何提示。
定價：按功能計頁 vs. 單張固定費率
Textract 採用按頁、按用量的計價，費率取決於功能——純文字偵測的計費方式不同於表單、表格、queries 或 AnalyzeExpense，而在同一頁上呼叫多個功能會讓成本疊加——這一切還要再加上一個 AWS 帳號。space-ocr 則是單一固定 每張影像 $0.05，無論你拉出多少欄位都一樣，並有一個每月 100 點數、免綁信用卡的免費方案，以及每月 $39 的 Pro 方案，內含 1,100 點數、無限工作表，和 100 GB 儲存空間。擷取失敗不收費，而查詢已儲存的表格（GET /view）是免費的。
如何把 space-ocr 當作 Textract 替代方案來試
- 拿一把金鑰——免 AWS 帳號註冊免費方案（每月 100 點數、免綁信用卡），取得你的 spocr_ API 金鑰。不必設定 IAM、區域或 S3。
- 送出影像把文件 POST 到 /ocr/fields，imageType 用「url」或「base64」。引擎讀的是點陣影像，所以請先把 PDF 頁面轉成影像；語言會自動偵測。
- 宣告你的欄位把你要的欄位列進 fields——每個給 name 和 type，明細項目用一個帶 children 的 array 欄位。不想自己寫，就把 autoFields 設為 true，讓模型從文件裡提出 schema。
- 驗證每個值依路徑讀取 data.cells[path]：box 和 quad 給出來源區域，verified 是判定，review 是原因，evidence 是佐證。審核佇列請用 data.review.flagged 來組，而不是用某個分數門檻。在 App 裡，點一個儲存格就能精確高亮它被讀出來的位置。
- 查詢或匯出——不必自建儲存用 /upload 把影像推進一張表格，用 GET /view（where、sort、select）在伺服器端查詢，或下載帶有展開明細項目的 CSV——不用資料庫，也不收重跑 OCR 的費用。