在找 Amazon Textract 的替代方案？
一篇公允、经过事实核查的分析，讲清楚什么时候该选择 Amazon Textract 的替代方案——逐值的来源坐标、明确指出该复核哪些值的清单、中日韩（中文／日文／韩文）支持、可查询的数据表、统一定价，以及无需 AWS 配置。
Amazon Textract 是一项成熟而强大的 OCR 服务，对于一条原生构建在 AWS 上、大规模处理英文文档的流水线来说，把它作为默认选择很合理。但“强大”和“适合你这份活儿”并不是一回事，有那么几条实打实的限制，会让人去寻找 Amazon Textract 的替代方案：
- 中日韩不在受支持语言名单上。 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 |
|---|---|---|
| 边界框 | 有——每个区块附带一个归一化的 0–1 BoundingBox 以及一个 Polygon | 有——每个值附带一个 box（{ xmin, ymin, xmax, ymax }）和一个四点 quad，都在 0–1000 的归一化网格上 |
| 逐值验证信号 | 每个区块一个识别置信度（%） | 判定放在 verified，触发的原因按排序列在 review.reasons，佐证放在 evidence（text_match、source、match_ratio） |
| 内置逐值复核界面 | Textract 本身没有；人工复核是一项单独的服务（Amazon A2I） | 内置于应用——点一下单元格，它在原件上的确切区域就会亮起 |
| 票据／发票字段 | 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 视为可信匹配）；比对无法进行时，这个键就干脆不存在。模型给的词元提示可能有噪声——在重复出现的行之间它有时会张冠李戴——所以系统用列一致性和行一致性检查来验证这些提示，而不是盲目相信它们。重点不在于 AI 不会出错：两套机制也可能在同一个误读上取得一致。重点在于，悄悄出错的值会被摆到台面上——作为单元格的 review 原因，以及 data.review.flagged 里的一行。
Textract 才是更好选择的场景
一次公允的对比，会点明现有方案胜出在哪。在以下情况选 Textract：
- 你已经深耕 AWS，想要一套能顺势接进 S3 → Lambda → Textract 的 OCR，并复用你已在运维的 IAM 和 SNS。
- 你的文档是英文／拉丁字母，且需要在极大规模上做表单、表格和 queries。
- 你想要在自己文档类型上训练的自定义适配器，或者需要 AWS 原生的合规与数据驻留保证。
如果这说的就是你，那 Textract 非常合适，替代方案给你带来的增益不大。
space-ocr 反而更合适的场景
当下面这些里有一项或多项对你重要时，Textract 替代方案就显出它的价值：
- 你要处理中文、日文或韩文文档。 space-ocr 用一个引擎跑中日韩和拉丁文字，并自动识别语言——没有语言参数要设置。
- 你想验证，而不只是相信。 业务数据留在
data.values，同一个路径可以取到data.cells，里面有box、quad、作为判定的verified、作为原因的review，以及作为佐证的evidence。该复核的清单只有一份，就是data.review.flagged；在应用里点一下单元格，就能高亮它被读取的确切位置。 - 你不想自建存储。 结果落进一张数据表，你可以在服务端查询它（
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 请求——不需要 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 在一个引擎里归一化处理多种文字（全角和半角字符、连字号变体、中日韩间距、竖排汉字、混合文字），自动识别语言，无需传任何提示。
定价：按功能分页计费 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 要配置。
- 发送图像把文档以 imageType 'url' 或 'base64' POST 到 /ocr/fields。引擎读的是栅格图像，所以请先把 PDF 页面转成图像；语言会被自动识别。
- 声明你的字段把你要的字段列进 fields——每个给出 name 和 type，明细行用一个带 children 的 array 字段。不想自己写，就把 autoFields 设为 true，让模型从文档里提出 schema。
- 验证每一个值按路径读取 data.cells[path]：box 和 quad 给出来源区域，verified 是判定，review 是原因，evidence 是佐证。复核队列请用 data.review.flagged 来构建，而不是用某个分数阈值。在应用里，点一下单元格就能高亮它被读取的确切位置。
- 查询或导出——无需自建存储用 /upload 把图像推入一张数据表，用 GET /view 在服务端查询它（where、sort、select），或者下载已展开明细行的 CSV——不需要数据库，也不会因重跑 OCR 而收费。