报销单不只要识字：Mistral OCR 可以按你的字段交出 JSON

拿到一张报销单，你真正想交给财务系统的，通常是日期、商户和金额几个字段。整页文字当然有用，但从文字再整理成表单，还是一道工序。Mistral Document AI 值得了解的地方，就在于它把“读出文档”和“按指定结构取信息”放进了同一套文档处理接口。

这是一项商业 API 服务，不是下载即用的开源 OCR 权重。它更适合已经知道下一步要填什么表、接什么系统的人。

先看清它交出的两层结果

基础 OCR 文档展示的结果以页面组织。每页可以返回 Markdown，图片、图片位置和表格也有相应信息。这样一来，正文与页面上的视觉内容不必挤成一大段纯文字。

如果下一步只是整理阅读材料，Markdown 已经是有用的交接物；如果要填报销表，还需要再约定字段。Annotations 就是后一层：你通过 JSON Schema 描述需要怎样的结构，让系统按这个结构提供抽取结果，而不只是回答一段自然语言。

以教学情境来说，一份报销记录可以先约定 merchant、invoice_date、total_amount 三项，再规定金额字段的类型。这个例子解释的是组织方法，并不是模型已经识别过的中文发票。字段名称可以由业务系统决定，关键是让输入材料与接收方的约定对得上。

Annotations 说明区分两种范围。文档级注释处理整份材料；边界框注释则面向文档里的图片区域。前者适合提取整张申请单的主要信息，后者更接近为某个图像对象补上结构化描述。

这也解释了它为什么不只是“把 OCR 文本再问一遍”。文档级处理会用到识别后的 Markdown，并把有限数量的图片区域交给视觉语言模型；当前说明中这一流程使用前八个图片区域。若关键内容藏在很长文档后面的图里，不能因为定义了字段，就推断所有图片都已被完整理解。

Schema 约束的是结果怎么组织，也不会自动赋予答案真实性。系统交出的金额字段，仍应能够回到票据位置核对；空白、涂改和多个合计值，也需要业务方规定怎样处理。对需要入账的系统，保留原页与抽取值的对应关系，比只留下一个格式漂亮的 JSON 更实用。

基础接口的页面结构在不同模型版本间有差异。官方说明将 include_blocks 标为 OCR 4 及以上能力，而表格格式、页眉和页脚等选项有各自的版本要求。开发时应按选定模型看参数，不能把文档里所有字段都当成每个旧版本都会返回。

如果手头任务已经有明确字段表，这套服务提供了一条值得比较的路径：先把一份材料的阅读结果留下，再把需要的内容交成固定结构。它能省掉的，是人工把识别文字重新搬进表单的部分；票据是否有效、金额是否应当报销，仍属于下一步的判断。