银行OCR搬进手机

小米 2026 年 10 月 30 日开源 0.8B 文档理解模型 Xiaomi-OCR-0，权重和推理代码同步上线 Hugging Face 和 GitHub。

它一个模型同时干三件事：文档解析（正文、表格、公式，按阅读顺序输出 Markdown）、关键字段抽取（身份证、发票、业务表单输出 JSON）、视觉问答（跨区域查找、数值计算、图表推理）。

OmniDocBench v1.6 上 96.83 分，1B 以下模型第一；在模拟扫描、卷边、屏幕翻拍、光照变化和倾斜拍摄的 Real5 测试上仍有 95.24。

它已经在小米手机"超级小爱"里跑，从屏幕上提取取件码、排队号、账单详情和会议时间——端侧 OCR 不再是实验室指标，而是手机日常功能。

对银行的意义：身份证、营业执照、发票流水这些敏感影像，可以在客户手机本地完成结构化，不必原图回传银行云端。

一、这个 0.8B 到底能做什么

1. 基座与数据：从 Qwen3.5-0.8B-Base 继续训练，用约 1.7 亿 OCR 与文档样本。标签由多个专家 OCR 模型交叉投票过滤，难表格和难公式走"预测—重渲染回图片—像素级比对"的闭环，合成样本还专门加了多语言、历史手写、屏幕摩尔纹和畸变光照。
2. 训练三阶段：先用 Q-Mask 把视觉区域和文本 token 对齐做文本锚定，再在数百亿 token 上继续 OCR 预训练，最后用结构编辑距离、表格匹配分这类可验证奖励做混合任务强化学习。
3. 文档解析：识别正文、表格、数学公式，按阅读顺序输出结构化结果，原生支持 Markdown 和 LaTeX。
4. 关键字段抽取：面向发票、收据、身份证、业务表单，定位到字段位置并输出 JSON，直接对接自动化流程。
5. 视觉问答：不止转写，还能跨区域查找、做数值计算、对图表做推理。
6. 基准（小米自报）：OmniDocBench v1.6 96.83（1B 以下第一，总榜第二仅差榜首 0.04）；Real5-OmniDocBench 95.24；Wild-OmniDocBench 87.94；公式 UniMER-Test 97.84；表格 PubTabNet 92.27；跨 DocVQA/InfoVQA/ChartQA/OCRBench/TextVQA 平均 83.2，超过 8B 的 MiniCPM-V-4.5（82.6）和 HunyuanOCR-1.5（76.5）。

二、为什么银行要关心一个手机能跑的 OCR

1. 远程开户和面签是高频刚需：客户在异地、在县域、在支行没覆盖的地方，要靠手机完成身份证、银行卡、营业执照的识别。传统做法是把高清影像传回银行 OCR 云，再把字段回传 App。
2. 敏感个人信息最小必要：身份证号、金融账号属于敏感个人信息。按《个人信息保护法》的最小必要原则，能在端侧本地完成的识别，就不必把原图上传云端。端侧 OCR 是天然的"数据不出手机"方案。
3. 离线和弱网可用：县域、地铁、飞机上、地下车库，客户网络不稳定；端侧识别不依赖上传，体验和合规双受益。
4. 延迟与成本：0.8B 模型量化后大约几百 MB，手机 NPU 推理百毫秒级，省去一次跨网上传下载，也省了云端 OCR 的调用费用。
5. 已经被手机厂商验证：小米把它放进超级小爱做屏幕理解，说明工程化上手机端跑得动，不是只能在服务器跑分。

三、四个银行 App 智能服务场景

1. 拍卡拍证自动填单：客户拍身份证自动填姓名、证件号、有效期；拍银行卡自动填卡号和有效期；拍营业执照自动填企业名称、统一社会信用代码。端侧抽字段后，原图可立即销毁，只把加密字段送银行。
2. 拍单据转账和报销：拍支票、汇款单自动填收款人、金额、用途；拍发票、回单自动进报销或对账流程。表格结构识别输出 Markdown，比传统 OCR 的纯文本更适合做后续结构化。
3. 信贷进件材料包：拍工资流水、财报、抵押物证件、购销合同，端侧先做第一遍结构化，把关键字段抽成 JSON；敏感原件留在客户手机，银行只拿到脱敏后的字段和必要的核验影像。
4. 屏幕级智能助手：客户在别的 App 看到一段利率、一个还款日、一个金额，超级小爱因式的屏幕理解可以直接读到并唤起银行 App；银行 App 自己也能做屏幕级识别，减少客户复制粘贴。

四、远程端侧金融服务怎么搭

1. 第一道在端侧：0.8B 模型做粗识别和字段抽取，输出 JSON。敏感字段（身份证号、卡号、金额）在端侧直接进入 App 的安全区，不写日志、不做截屏。
2. 第二道在云端：银行风控和反欺诈模型在云端做判断——这张证件是不是真的、有没有被篡改、客户是不是本人、交易是不是合理。端侧负责"读对"，云端负责"判准"。
3. 不要端侧做防伪和反欺诈：识别是 OCR 的活，防伪是另一个模型的活。印章核对、光变图案、翻拍检测、深度伪造证件识别，仍要云端多模态模型，不要指望 0.8B 端侧包打天下。
4. 字段校验必须保留：OCR 抽出来还要过规则——身份证校验位、银行卡 Luhn 校验、发票代码校验、金额大小写一致。端侧抽错一个字符，云端规则立刻拦下，不让错字段进核心系统。
5. 模型分发与更新：0.8B 模型随 App 发版，或按区域、按业务灰度下载；银行要保留模型版本号和识别记录，出了争议能回放是哪个版本识别的。
6. 适配策略：低端机跑不动时降级到传统 OCR 或云端识别；高端机和新机型才默认端侧大模型。不要一刀切强制端侧。

五、三个冷静判断

1. 基准是小米自报：96.83、95.24 都是官方数字。银行落地前必须用自己的样本——不同光照、不同版本身份证、不同地方公章、不同扫描 App——做一轮内部评测，特别是扭曲和反光场景。
2. 0.8B 不是全能：跨基准平均 83.2 仍低于 Qwen3.5-4B 的 84.9，复杂图表推理和长文档不是它的强项。它的甜区是"单页、字段明确、手机拍的证件和单据"，不是整本合同逐页精读。
3. 端侧识别不等于高枕无忧：恶意 App 截屏重放、深度伪造证件、客户主动配合欺诈，这些都不是 OCR 模型能防的。端侧 OCR 解决的是"敏感数据少跑路"，不是"交易不出风险"。

结语

0.8B 级别的文档模型被手机厂商做进日常助手，意味着端侧 OCR 从"高端机型专属"变成"可大规模铺的基础能力"。对银行 App 和远程金融服务，真正值钱的不是又快了几百毫秒，而是身份证、营业执照、发票流水这些敏感影像终于可以不必原图回传——这与《个人信息保护法》的最小必要原则天然契合。搭法很朴素：端侧读对、云端判准、规则兜底、模型可回放。把这四道做齐，银行 OCR 才算真的搬进了客户手机。

（口径说明：模型参数、训练数据、OmniDocBench 等基准分数、已在超级小爱落地等信息来自 Pandaily 报道和 arXiv 技术报告，基准为小米自报；文中银行场景、混合架构和落地建议为作者分析，不构成具体技术方案；实际部署需做内部样本评测、合规审查和机型适配。）