---
title: "银行OCR搬进手机"
date: 2026-11-02
description: "小米2026年10月30日开源0.8B文档理解模型Xiaomi-OCR-0，单一模型同时做文档解析、关键字段抽取和视觉问答，OmniDocBench同尺寸类第一。它已经在小米手机超级小爱上从屏幕取件码、排队号和账单详情。本文分析这个0.8B模型对银行App智能服务和远程端侧金融服务的价值：身份证、营业执照、发票流水在手机本地结构化，敏感影像不回传，以及端侧第一道、云端第二道的混合架构怎么搭。"
tags: ["端侧AI","OCR","小米","文档理解","银行App","隐私计算","远程开户"]
schema_type: Article
references:
  - title: "Xiaomi Open-Sources Xiaomi-OCR-0, a 0.8B Document Model That Tops OmniDocBench in Its Size Class"
    url: "https://pandaily.com/xiaomi-ocr-0-open-source-0-8b-document-parsing-key-information-extraction-omnidocbench-96-83"
    source: "Pandaily, 2026-10-31"
  - title: "Xiaomi-OCR-0 Technical Report (arXiv 2609.36136)"
    url: "https://arxiv.org/html/2609.36136"
    source: "arXiv, 2026"
  - title: "小米开源0.8B参数OCR小模型：打通文档解析与视觉问答（IT之家）"
    url: "http://m.toutiao.com/group/7702451073788789275/"
    source: "IT之家, 2026-10-30"
---

# 银行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 技术报告，基准为小米自报；文中银行场景、混合架构和落地建议为作者分析，不构成具体技术方案；实际部署需做内部样本评测、合规审查和机型适配。）