浏览器里跑OCR这件事我从Tesseract.js时代就开始折腾中间踩过的坑能写满一个笔记本。早期方案要么模型体积大到离谱要么识别一张小票要等十几秒用户体验基本等于劝退。直到LiteRT.js这套运行时方案成熟起来配合WebAssembly和WebGPU两条推理后端才真正让打开网页就能扫收据这件事变得可用。这篇内容围绕基于浏览器的收据扫描器LiteRT.js展开把模型选型、推理后端切换、图像预处理、结构化解析这几块拆开讲透适合正在做前端OCR、想把手头识别任务搬到浏览器端、或者单纯对WebGPU推理感兴趣的朋友参考。不管你是刚接触OCR的新手还是已经用过Paddle OCR、Tesseract的老手这里面的实操细节和避坑经验应该都能用得上。1. 为什么收据扫描这件事值得单独做一套浏览器方案1.1 收据识别的场景特殊性决定了它不能照搬通用OCR很多人第一反应是OCR不是早就有了吗调个接口不就完了。但收据这个场景非常特殊通用OCR方案直接套上去识别率会让你怀疑人生。收据通常是热敏纸打印字迹偏淡、对比度低而且纸张经常有折痕、卷曲、油渍拍摄时又多半是随手一拍角度倾斜、光照不均、背景杂乱。更麻烦的是收据的版式高度非标准化——同样是超市小票不同商家的字段顺序、分隔线样式、金额对齐方式完全不同。通用OCR模型大多在规整文档上训练遇到这种脏数据就露怯。而收据识别真正要的不是把每个字都认出来而是抽取结构化字段商户名、日期、总金额、税、明细条目。这意味着整条链路要分成检测、识别、后处理三段每段都有针对性的优化空间。把这件事放到浏览器里做还要额外考虑模型体积、内存占用、推理速度复杂度直接翻倍。1.2 浏览器端推理到底解决了什么真实痛点先说清楚为什么非要在浏览器里跑而不是丢给服务端。最直接的理由是隐私。收据上往往带着消费记录、卡号后四位、甚至部分个人信息用户对把照片上传到某个服务器这件事天然警惕。本地推理意味着图片从头到尾不离开设备这对做记账类、报销类工具的产品来说是硬需求。其次是成本和延迟。服务端OCR要么按调用量付费要么自己维护GPU集群量一大成本就压不住。浏览器端推理把算力摊到用户设备上服务端只负责可选的同步和存储边际成本几乎为零。延迟上省掉了图片上传和结果回传的往返本地推理在WebGPU加持下能做到几百毫秒出结果体验比等网络请求顺畅得多。还有离线可用这一条地铁里、飞机上照样能扫这是服务端方案给不了的。1.3 LiteRT.js在这个链路里扮演的角色LiteRT.js本质上是把训练好的模型转换成能在浏览器里高效执行的格式并提供统一的推理接口。它屏蔽了底层到底是走WebAssembly还是WebGPU的差异让上层代码用同一套API调用。你可以把它理解成一个模型执行引擎模型文件通常是量化后的tflite或类似格式加载进来输入张量喂进去输出张量拿出来中间的内存管理、算子调度、后端选择都由它处理。它和Tesseract.js的区别在于定位。Tesseract.js是把一整套OCR流程含检测和识别打包开箱即用但定制性差LiteRT.js更像底层运行时你可以自由组合检测模型和识别模型针对收据场景做深度定制。代价是你得自己搭流程但换来的是识别率和性能的可控性。对于收据这种非标场景这个取舍是值得的。2. 检测与识别双模型的分工设计2.1 文本检测模型负责把收据切成行收据识别的第一步是找到文字在哪里。这一步用文本检测模型完成输出是一堆文本框通常是旋转矩形或多边形。收据场景下检测有几个要点一是要能处理倾斜文本因为拍摄角度很难保证水平二是对小字要敏感收据底部的明细行字号可能只有几个像素高三是要能区分真正的文字区域和分隔线、logo、条形码这些干扰元素。我实测下来基于DBNet思路的轻量检测模型在收据上表现比较均衡。输入分辨率建议控制在960×960以内再大推理时间会明显上升而收据文字本身不需要那么高的分辨率。检测阈值二值化阈值要调低一点大概0.2到0.3之间因为热敏纸字迹淡阈值太高会漏检。这个参数没有万能值最好准备几张典型收据做验证集手动扫一遍阈值找最优点。2.2 识别模型把每个文本框转成字符串检测出来的每个文本框裁剪出来送进识别模型。识别模型通常是CRNN或者基于Transformer的序列识别结构输出字符序列。收据识别的字符集要特别设计数字、小数点、货币符号、常见汉字、英文字母再加上一些收据上高频出现的符号如星号、斜杠、冒号。字符集越小模型越容易收敛推理也越快。这里有个容易忽略的点收据上的数字识别准确率直接决定金额字段对不对而数字恰恰是最容易混淆的0和O、1和l、5和S、8和B。我的做法是在训练数据里刻意增加数字样本的权重并且在识别后处理阶段加一层数字纠错规则——比如金额字段里如果出现字母O大概率是数字0。这种规则简单但有效能救回不少边缘case。2.3 两个模型如何串成完整流水线整条流水线的顺序是图像预处理 → 检测 → 文本框排序 → 逐框识别 → 结构化解析。排序这一步很关键但常被忽视。检测模型输出的文本框是无序的而收据是有阅读顺序的从上到下从左到右。如果不排序识别结果就是一堆乱序字符串后处理根本没法做。排序算法我推荐用先按y坐标聚类成行再在行内按x坐标排序的策略。具体做法是把所有文本框按中心点y坐标排序然后遍历如果当前框和上一个框的y坐标差值小于某个阈值比如框高的一半就认为是同一行。这样能处理轻微倾斜的情况。对于倾斜严重的收据最好先做一次透视校正把收据摆正再检测排序会简单很多。// 文本框按行聚类再排序的简化实现 function sortTextBoxes(boxes) { // 按中心点y排序 const sorted [...boxes].sort((a, b) a.cy - b.cy); const lines []; let currentLine [sorted[0]]; for (let i 1; i sorted.length; i) { const box sorted[i]; const lastBox currentLine[currentLine.length - 1]; const threshold Math.max(box.height, lastBox.height) * 0.5; if (Math.abs(box.cy - lastBox.cy) threshold) { currentLine.push(box); } else { lines.push(currentLine); currentLine [box]; } } lines.push(currentLine); // 每行内按x排序 return lines.flatMap(line line.sort((a, b) a.cx - b.cx) ); }3. WebAssembly与WebGPU两条推理后端的取舍3.1 两种后端的能力边界在哪里WebAssembly后端是保底方案几乎所有现代浏览器都支持兼容性没得说。它跑在CPU上通过SIMD指令和多线程需要SharedArrayBuffer支持能获得不错的性能。缺点是CPU推理终究有上限模型稍大一点延迟就上去了而且会占用主线程资源处理大图时页面可能卡顿。WebGPU后端是性能方案直接把计算丢给GPU。对于卷积密集的检测和识别模型加速比通常能到3到10倍具体取决于模型结构和GPU性能。但WebGPU的浏览器支持还在铺开阶段而且不同厂商的GPU驱动质量参差不齐偶尔会遇到算子不支持或者结果异常的情况。我的策略是运行时探测优先尝试WebGPU初始化失败或者推理结果异常时自动降级到WebAssembly保证功能始终可用。3.2 后端切换的探测与降级逻辑探测逻辑不能只看navigator.gpu是否存在那个只能说明API可用不代表能跑通你的模型。稳妥的做法是初始化时用一个极小的测试张量跑一次推理验证输出是否在合理范围内。如果这一步失败或者超时就切到WebAssembly。async function selectBackend() { if (!navigator.gpu) return wasm; try { const adapter await navigator.gpu.requestAdapter(); if (!adapter) return wasm; // 用微型模型做一次冒烟测试 const ok await smokeTest(webgpu); return ok ? webgpu : wasm; } catch (e) { console.warn(WebGPU初始化失败降级到WASM, e); return wasm; } }注意冒烟测试一定要设超时。有些设备上WebGPU初始化会卡住不返回没有超时保护的话整个应用就挂起了。我一般设3秒超时超时直接判定为不可用。3.3 实测性能对比与内存占用在一台中端笔记本集成显卡上我用同一张1200×1600的收据照片做了对比测试。WebAssembly单线程下整条流水线约2.8秒开启多线程后降到1.4秒左右。WebGPU下约450毫秒提升非常明显。内存占用方面WebAssembly峰值约180MBWebGPU约220MBGPU方案略高但可接受。后端配置检测耗时识别耗时总耗时峰值内存WASM单线程1.6s1.2s2.8s180MBWASM多线程0.8s0.6s1.4s195MBWebGPU0.25s0.2s0.45s220MB需要说明的是WebGPU的首次推理会包含着色器编译开销可能比后续推理慢好几倍。所以第一次扫描感觉慢是正常的第二次开始就快了。可以在应用启动时用一张占位图预热一次把编译开销提前消化掉。4. 图像预处理决定识别率上限的关键环节4.1 透视校正让倾斜收据站直用户拍收据很少能拍得方方正正透视畸变会让文字行变成斜线直接影响检测和排序。校正的思路是找到收据的四个角点然后做透视变换把它映射成矩形。角点检测可以用边缘检测加轮廓拟合也可以让用户手动点四个角体验差但准确。自动方案我推荐用轮廓面积筛选找出图像中最大的四边形轮廓大概率就是收据边界。变换之后收据就摆正了后续检测和排序都省事。这一步的收益非常大我实测在倾斜30度的收据上校正前后识别准确率能差20个百分点以上。校正的代价是一次矩阵运算开销可以忽略。4.2 灰度化、二值化与对比度增强的组合拳热敏纸收据的通病是对比度低字和背景灰度接近。直接送进模型检测模型可能连框都找不准。预处理要做几件事先灰度化降维再做自适应直方图均衡CLAHE提升局部对比度最后根据情况决定是否二值化。二值化要谨慎。全局阈值二值化在光照不均的收据上会灾难性失败——亮的地方全白暗的地方全黑。如果一定要二值化用自适应阈值局部阈值每个像素根据邻域计算阈值。但我更倾向于不做硬二值化而是把增强后的灰度图直接送模型让模型自己去学特征。现代检测识别模型对灰度输入的鲁棒性已经足够好硬二值化反而会丢失信息。4.3 分辨率与缩放的权衡输入分辨率是个需要权衡的参数。分辨率太低小字糊成一团识别不了分辨率太高推理时间线性增长内存也吃不消。收据的特点是长条形宽高比可能到1:3甚至更极端。如果直接缩放到正方形要么宽度被压扁要么高度被拉伸都会变形。我的做法是保持宽高比缩放让长边不超过一个上限比如1280短边按比例算。如果短边缩得太小导致小字不可读就分段处理——把长收据切成上下几段分别识别最后拼接结果。切分点选在空白行处避免把一行文字切断。这个策略在处理超长超市小票时特别有用。5. 从识别文本到结构化字段的解析实战5.1 收据字段的抽取规则设计识别出来的是一行行文本要变成商户名、日期、总金额这样的结构化数据得靠解析规则。收据的字段有几个强特征可以利用总金额通常出现在合计总计应付这类关键词附近且是整张收据里数值最大的金额之一日期有固定的格式模式年月日、斜杠、横杠分隔商户名一般在收据顶部字号较大。我的解析策略是关键词定位 正则匹配 数值校验三层。先用关键词找到候选行再用正则从候选行里抠出具体值最后做合理性校验比如日期不能是未来、金额不能为负、明细项之和应该接近总金额。校验这层能过滤掉大量误识别。5.2 金额与日期的正则匹配细节金额的正则要兼容多种写法12.34、12,34、¥12.34、12.34元、-12.34退款。我用的模式大致是/[-¥]?\s*(\d{1,3}(?:[,]\d{3})*(?:[.。]\d{2})?)/注意小数点可能被识别成中文句号千分位可能是中文逗号这些都要覆盖。日期更麻烦格式五花八门2024-01-15、2024/01/15、2024年1月15日、15/01/2024日月顺序还可能颠倒。我的做法是准备一组正则模式逐个尝试匹配成功后再用日期库校验合法性。对于日月顺序歧义的情况比如03/04/2024优先按本地习惯解析同时保留原始字符串供用户确认。const amountPattern /[-¥]?\s*(\d{1,3}(?:[,]\d{3})*(?:[.。]\d{1,2})?)/g; const datePatterns [ /(\d{4})[-/年.](\d{1,2})[-/月.](\d{1,2})/, /(\d{1,2})[-/](\d{1,2})[-/](\d{4})/, ]; function normalizeAmount(str) { return parseFloat( str.replace(/[,]/g, ) .replace(/[。]/g, .) .replace(/[¥\s]/g, ) ); }5.3 明细条目的对齐与金额校验收据的明细行通常是商品名 ... 金额的格式中间用空格或点号填充。识别后这些填充符可能变成各种奇怪字符需要归一化。我的做法是把连续的非字母数字字符除了小数点都当作分隔符然后取最后一个数值作为该行金额前面的作为商品名。校验环节是提升可信度的关键。把所有明细金额加起来和识别出的总金额比对如果差值在合理范围比如几分钱以内考虑四舍五入就认为解析可信如果差得离谱说明某处识别错了标记出来让用户复核。这个机制能显著降低错误数据进入账本的概率。6. 工程化落地中的性能与体验优化6.1 模型加载与缓存策略模型文件动辄几MB到几十MB每次打开页面都重新下载体验很差。用Cache API或者IndexedDB把模型缓存到本地第二次打开直接读缓存。缓存要带版本号模型更新时能正确失效。加载过程要有进度反馈用户看到进度条在动才不会以为卡死。WebAssembly的编译也有开销可以用WebAssembly.compileStreaming边下载边编译比先下载完再编译快不少。如果模型支持分片还可以做懒加载——检测模型先加载识别模型在检测出文本框后再加载让首屏更快。6.2 大图处理与内存控制手机拍的照片动辄4000×3000直接送进模型内存直接爆。预处理阶段就要把图缩到合理尺寸并且及时释放中间张量。LiteRT.js的张量对象用完要显式释放不然内存会持续增长直到页面崩溃。我踩过这个坑连续扫十几张图后页面就卡死了排查半天才发现是张量没释放。处理大图的另一个技巧是用OffscreenCanvas在Worker里做预处理避免阻塞主线程。整个OCR流程其实都适合放进Worker主线程只负责UI和结果展示这样即使推理耗时较长页面也不会失去响应。6.3 用户交互中的容错设计再好的模型也会有识别错的时候交互设计要承认这一点。我的做法是识别结果全部可编辑用户能直接改。对于低置信度的字段模型输出的概率低于阈值用颜色标出来提示用户重点核对。金额字段做二次确认因为金额错了后果最严重。还要处理识别失败的情况。如果检测不到任何文本框或者解析不出关键字段不要直接报错而是引导用户重拍——提示可能是光线太暗、角度太斜、或者收据没放平。给出具体的改进建议比一句识别失败有用得多。7. 踩过的坑与实测经验汇总7.1 WebGPU结果异常但无报错的隐蔽问题最坑的一次是WebGPU在某些设备上推理不报错但输出全是NaN或者乱码。这种问题最难查因为流程看起来完全正常。后来发现是某些GPU驱动对特定算子实现有bug。解决办法就是前面说的冒烟测试——初始化时跑一次已知输入的推理验证输出是否符合预期不符合就降级。这个检查一定要做否则线上会出现一批用户识别结果全错但没有任何错误日志的情况。7.2 中文标点与全角字符的归一化中文环境下识别结果里混入全角字符是常态全角数字、全角小数点、全角逗号。这些字符直接参与数值解析会失败。必须在解析前做一次归一化把全角转半角。这个转换要覆盖数字、字母、标点用Unicode码点范围判断即可。我一开始漏了全角小数点导致一批金额解析失败排查了好久。7.3 多线程WASM的兼容性陷阱WebAssembly多线程依赖SharedArrayBuffer而SharedArrayBuffer需要特定的响应头COOP和COEP才能启用。如果你的部署环境没法设置这些头多线程就用不了只能退回单线程。这个限制在开发环境容易忽略因为本地开发服务器可能默认就带了这些头一上线就发现多线程失效。部署前一定要确认响应头配置。7.4 模型量化带来的精度损失为了减小体积和加速模型通常会做量化比如从float32量化到int8。量化能带来2到4倍的速度提升和体积缩减但精度会有损失。收据识别对数字精度敏感量化后可能出现原本能认对的数字认错了。我的经验是检测模型可以大胆量化识别模型要谨慎最好在量化后做一轮验证集测试确认精度损失在可接受范围内再用。如果损失太大考虑用混合量化对精度敏感的层保持高精度。8. 后续可以继续深挖的方向这套方案跑通之后还有不少可以优化的空间。比如引入版面分析模型自动识别收据的表格结构对明细条目的解析会更准。再比如做端上的增量学习把用户手动修正的结果收集起来定期微调模型让识别率随使用逐步提升。还有多语言支持不同地区的收据格式差异很大字符集和解析规则都要适配。性能上模型蒸馏是个方向用大模型教小模型在保持精度的同时进一步压缩体积。WebGPU的算子优化也值得跟进随着浏览器实现成熟能解锁的加速空间还很大。我个人比较看好的是把整条流水线做成可插拔的模块检测、识别、解析各自独立方便针对不同场景替换组件——毕竟收据只是文档识别的一个子集同一套框架稍微调整就能用到发票、名片、表单上。