用cv_resnet18_ocr-detection做了个发票识别项目，全过程分享-开发者社区

用cv_resnet18_ocr-detection做了个发票识别项目，全过程分享

在日常财务和行政工作中，发票处理一直是个耗时又容易出错的环节：手动录入金额、核对税号、归类报销类型……一张发票平均要花2分钟，百张就是3个多小时。去年我接手公司差旅报销系统优化任务时，决定不再靠Excel硬扛，而是用OCR技术把发票“看懂”。经过几轮选型测试，最终选定科哥构建的cv_resnet18_ocr-detection镜像——它不是简单调用API的黑盒服务，而是一个开箱即用、可调可控、还能本地微调的OCR文字检测WebUI。今天就把从零部署到落地发票识别的完整过程，毫无保留地分享出来。不讲虚的原理，只说你真正需要的操作路径、踩过的坑、调出来的参数，以及——它到底能不能在真实发票上稳定工作。

1. 为什么选这个镜像而不是其他OCR方案

1.1 三个现实痛点，它都解决了

很多团队一开始会直接上云OCR服务（比如某度、某里），但实际跑起来才发现问题不少：

隐私顾虑：发票含公司名称、税号、金额等敏感信息，上传到公有云总让人心里打鼓；
定制困难：标准OCR对通用文本效果好，但发票上的“价税合计”“开户行”“纳税人识别号”等固定字段位置特殊、字体小、常带印章遮挡，通用模型识别率只有60%左右；
响应延迟：批量处理50张发票，每张都要走网络请求，加上排队和限流，等10分钟是常态。

而cv_resnet18_ocr-detection这个镜像，恰恰卡在了这些痛点的解法上：

纯本地运行：所有图片和数据都在自己服务器上处理，不联网、不上传，财务合规性一步到位；
检测+可视化双输出：它不只是返回文字，更关键的是返回每个文字块的精确坐标（JSON格式），这为后续“定位提取”打下基础——比如我们能精准抓取坐标(210, 45)到(380, 72)区域的文字，那基本就是“金额”字段；
WebUI友好，小白也能调参：不用写一行代码，滑动阈值条就能看到检测框实时变化，对模糊发票、带红章发票、手机拍摄倾斜发票，都能快速试出最优参数。

它不是一个“识别完就结束”的工具，而是一个“我能看清它怎么想的”透明系统。

1.2 和同类开源模型比，它的特别之处

我也试过PaddleOCR、EasyOCR这些热门方案，它们能力很强，但落地发票场景时各有短板：

方案	发票识别短板	cv_resnet18_ocr-detection优势
PaddleOCR	安装依赖复杂，GPU环境常报CUDA版本冲突；检测结果不带原始坐标，需二次解析	一键`bash start_app.sh`启动，坐标直接输出JSON，字段定位零成本
EasyOCR	CPU推理慢（单图3秒+），批量处理易内存溢出；无图形界面，调试靠改代码重跑	GPU下0.2秒/张（RTX 3090），WebUI拖拽即可试不同阈值，所见即所得
纯DBNet模型（如ModelScope原版）	只提供Python API，需自己搭服务、写前端、做错误处理	内置四Tab WebUI：单图/批量/训练/导出，开箱即用，连微信扫码登录都不用

一句话总结：它把一个工程级OCR能力，压缩成了一个运维同学都能独立部署、业务同学都能自主调试的“生产力工具”。

2. 从镜像拉取到WebUI可用：三步完成部署

整个部署过程，我是在一台4核CPU+RTX 3060（12G显存）的Ubuntu 22.04服务器上完成的。没有用Docker Compose，也没碰K8s，就是最朴素的镜像加载方式，确保你照着做，10分钟内必成功。

2.1 拉取并运行镜像

首先确认你的服务器已安装NVIDIA驱动和nvidia-docker：

# 查看驱动版本（应≥510） nvidia-smi # 确认nvidia-docker可用 docker run --rm --gpus all nvidia/cuda:11.7.1-runtime-ubuntu22.04 nvidia-smi

然后拉取镜像（注意：镜像名需替换为你实际获取的完整路径，例如registry.cn-hangzhou.aliyuncs.com/xxx/cv_resnet18_ocr-detection:latest）：

# 拉取镜像（请替换为你的实际镜像地址） docker pull registry.cn-hangzhou.aliyuncs.com/xxx/cv_resnet18_ocr-detection:latest # 创建并运行容器（映射端口7860，挂载outputs目录便于取结果） docker run -d \ --name ocr-invoice \ --gpus all \ -p 7860:7860 \ -v /root/ocr_outputs:/root/cv_resnet18_ocr-detection/outputs \ -v /root/invoice_data:/root/invoice_data \ --restart=always \ registry.cn-hangzhou.aliyuncs.com/xxx/cv_resnet18_ocr-detection:latest

✅ 关键点说明：
-v /root/ocr_outputs:/root/cv_resnet18_ocr-detection/outputs是必须的！所有检测结果都存在这个目录，挂载后你才能从宿主机直接拿到图片和JSON；
/root/invoice_data是我预置的发票测试集目录，方便批量检测时直接选；
--restart=always确保服务器重启后服务自动恢复，生产环境必备。

2.2 进入容器，启动WebUI服务

镜像启动后，它并不会自动跑WebUI（这是设计，给你控制权）。你需要进入容器执行启动脚本：

# 进入容器 docker exec -it ocr-invoice bash # 切换到项目目录并启动 cd /root/cv_resnet18_ocr-detection bash start_app.sh

你会看到类似这样的输出：

============================================================ WebUI 服务地址: http://0.0.0.0:7860 ============================================================

此时，打开浏览器访问http://你的服务器IP:7860，就能看到那个紫蓝渐变的现代化界面了。整个过程，没改一行配置，没装一个包。

2.3 首次使用前的两个必要检查

刚进界面别急着传图，先做两件事，避免后续白忙：

检查GPU是否生效：在“单图检测”页上传一张发票，点击“开始检测”，观察右上角状态栏。如果显示GPU: True且推理时间在0.3秒内，说明GPU加速已启用；如果显示GPU: False或时间＞2秒，大概率是容器没正确分配GPU，回看第一步的--gpus all参数。
验证outputs目录挂载：检测完成后，立刻去宿主机的/root/ocr_outputs目录下找最新生成的outputs_YYYYMMDDHHMMSS文件夹。如果里面既有visualization/detection_result.png又有json/result.json，说明挂载成功，结果能顺利导出。

这两步做完，你的OCR引擎就算真正“活”了。

3. 发票识别实战：单图、批量、字段定位全操作

发票识别的核心，从来不是“能不能识”，而是“能不能准确定位关键字段”。下面我就用一张真实的增值税专用发票（含红章、手写备注、轻微倾斜）为例，带你走一遍从上传到结构化提取的全流程。

3.1 单图检测：如何让模型“看清”这张发票

上传发票图片后，WebUI会自动显示预览。这时别急着点“开始检测”，先做两件事：

调整检测阈值：发票文字通常清晰，但红章会干扰检测。我把阈值从默认0.2调到0.35。为什么？因为0.2时模型会把红章边缘误判为文字框（产生大量小噪点框），0.35则过滤掉大部分干扰，只保留高置信度的文字区域。
观察预览图右下角的“图像尺寸”：我的发票扫描件是2480×3508像素。WebUI默认输入尺寸是800×800，对大图会先缩放。如果你发现检测框明显偏移（比如框住了“金额”却漏了“税率”），说明缩放损失了精度。这时可以切到“ONNX导出”Tab，把输入尺寸临时设为1024×1024再导出新模型（后文详述），但日常使用800×800已足够。

点击“开始检测”后，几秒内页面右侧就出现三块内容：

识别文本内容：带编号的纯文本列表，可直接Ctrl+C复制；
检测结果：原图上叠加了彩色矩形框，每个框对应一行文字；
检测框坐标 (JSON)：这才是发票结构化的金钥匙。

来看一段真实输出的JSON片段（已脱敏）：

{ "image_path": "/tmp/invoice_001.jpg", "texts": [ ["*增值税专用发票*"], ["发票代码：1100181130"], ["发票号码：12345678"], ["开票日期：2025年03月15日"], ["购方名称：北京某某科技有限公司"], ["销方名称：上海某某贸易有限公司"], ["金额：¥12,800.00"], ["税率：13%"], ["价税合计：¥14,464.00"] ], "boxes": [ [120, 85, 320, 85, 320, 115, 120, 115], [45, 210, 280, 210, 280, 240, 45, 240], [45, 255, 280, 255, 280, 285, 45, 285], [45, 295, 320, 295, 320, 325, 45, 325], [45, 420, 480, 420, 480, 450, 45, 450], [45, 465, 480, 465, 480, 495, 45, 495], [1200, 1280, 1520, 1280, 1520, 1310, 1200, 1310], [1200, 1320, 1380, 1320, 1380, 1350, 1200, 1350], [1200, 1360, 1580, 1360, 1580, 1390, 1200, 1390] ], "scores": [0.99, 0.98, 0.97, 0.96, 0.95, 0.94, 0.93, 0.92, 0.91], "success": true, "inference_time": 0.234 }

注意看"boxes"数组：每个子数组是8个数字，代表一个四边形的四个顶点坐标（x1,y1,x2,y2,x3,y3,x4,y4）。而"texts"数组顺序与之严格对应。这意味着——第7个文本"金额：¥12,800.00"的坐标，就是boxes[6]的那8个数字。

3.2 批量检测：一次处理50张发票的正确姿势

财务月结时，往往要处理上百张发票。单张点太慢，批量功能就是为此而生。

操作很简单：

点击“批量检测”Tab；
在“上传多张图片”区域，按住Ctrl键，一次性选中50张发票（建议不超过50张，避免内存爆）；
把检测阈值同样设为0.35；
点击“批量检测”。

等待约1分半钟（RTX 3060实测），页面会展示一个画廊，每张图下方有“查看结果”按钮。点击任一图，就能看到和单图检测完全一致的三块结果区。

但这里有个隐藏技巧：批量检测的结果，不会覆盖单图检测的outputs目录。它会在/root/ocr_outputs下新建一个以时间戳命名的文件夹（如outputs_20250315143022），里面是50张图各自的visualization/和json/子目录。这意味着你可以写个简单脚本，遍历所有result.json，用正则匹配"金额：.*"、"发票号码：.*"，再结合坐标做二次校验，10分钟就能生成一份Excel汇总表。

3.3 字段定位：从“识别文字”到“提取结构化数据”

光有文字列表还不够，财务系统需要的是结构化字段。利用JSON里的坐标，我们可以轻松实现精准定位。

以“价税合计”为例，它在发票上永远位于右下角固定区域。我观察了20张不同版式的发票，发现其Y坐标（纵坐标）普遍在1350~1400之间（基于2480×3508原图）。于是写了一段极简Python脚本，自动提取：

import json import re def extract_invoice_fields(json_path): with open(json_path, 'r', encoding='utf-8') as f: data = json.load(f) # 遍历所有检测到的文本和坐标 for i, text in enumerate(data['texts']): content = text[0].strip() box = data['boxes'][i] # 计算该文本框的中心Y坐标 y_center = (box[1] + box[3] + box[5] + box[7]) / 4 # 如果文本包含"价税合计"且Y坐标在右下角区域 if "价税合计" in content and 1350 <= y_center <= 1400: # 提取金额数字（支持¥和中文数字） amount_match = re.search(r'¥?([\d,]+\.?\d*)', content) if amount_match: return amount_match.group(1).replace(',', '') return "未找到" # 调用示例 print(extract_invoice_fields("/root/ocr_outputs/outputs_20250315143022/json/result.json")) # 输出：14464.00

这个逻辑，比任何“关键词匹配”都可靠——因为它结合了语义（含“价税合计”字）和空间（在右下角），彻底规避了“购方名称”里也带“合计”二字的误匹配。这才是OCR在业务中真正该有的样子：不是替代人，而是帮人做决策。

4. 进阶：让模型更懂发票——微调与ONNX导出

开箱即用的模型已经很好，但如果你的发票有特殊样式（比如内部定制版、带水印、特定字体），或者想把它集成到自己的App里，就需要两个进阶能力：微调和跨平台部署。

4.1 微调：用10张自家发票，提升30%准确率

微调不需要从头训练，只需少量数据。我收集了10张公司常用的内部报销发票（含水印、小字号、表格线），按ICDAR2015格式整理：

custom_invoice/ ├── train_list.txt ├── train_images/ │ ├── inv_001.jpg │ └── ... ├── train_gts/ │ ├── inv_001.txt # 内容：x1,y1,x2,y2,x3,y3,x4,y4,价税合计：¥14,464.00 │ └── ...

在WebUI的“训练微调”Tab中：

输入路径：/root/custom_invoice
Batch Size：保持默认8（小数据集够用）
训练轮数：设为10（比默认5翻倍，小数据不怕过拟合）
学习率：0.005（比默认0.007略低，更稳）

点击“开始训练”，12分钟后，页面显示“训练完成！模型保存至workdirs/finetune_20250315/”。我立刻用一张未见过的测试发票验证，关键字段识别率从82%提升到97%，尤其是水印干扰下的“金额”字段，几乎不再漏检。

💡 实践心得：微调不是玄学。10张高质量标注图，胜过100张随意截图。标注时，务必把“价税合计”“纳税人识别号”这些关键字段单独成行，不要和旁边文字合并。

4.2 ONNX导出：把模型塞进Windows客户端或手机App

WebUI很爽，但有些场景需要离线嵌入。比如财务同事的笔记本没GPU，或者要开发一个手机拍照直出金额的小程序。这时，ONNX就是桥梁。

在“ONNX导出”Tab：

输入尺寸：我选了800×800（平衡速度与精度）；
点击“导出ONNX”；
成功后，下载model_800x800.onnx。

然后，用官方提供的Python示例（稍作修改）就能在任何有ONNX Runtime的环境运行：

import onnxruntime as ort import cv2 import numpy as np # 加载ONNX模型（无需GPU环境） session = ort.InferenceSession("model_800x800.onnx", providers=['CPUExecutionProvider']) # 读取发票图片并预处理 img = cv2.imread("invoice.jpg") h, w = img.shape[:2] # 保持宽高比缩放到800，不足补黑边 scale = 800 / max(h, w) new_h, new_w = int(h * scale), int(w * scale) resized = cv2.resize(img, (new_w, new_h)) pad_h = 800 - new_h pad_w = 800 - new_w padded = cv2.copyMakeBorder(resized, 0, pad_h, 0, pad_w, cv2.BORDER_CONSTANT) # 归一化并增加batch维度 input_blob = padded.astype(np.float32) / 255.0 input_blob = input_blob.transpose(2, 0, 1)[np.newaxis, ...] # 推理 outputs = session.run(None, {"input": input_blob}) # outputs[0] 就是检测框坐标，outputs[1] 是文本内容...

从此，你的发票识别能力，不再被WebUI绑定，真正实现了“一次训练，处处运行”。

5. 总结：它不是一个OCR工具，而是一个发票自动化起点

回看整个项目，cv_resnet18_ocr-detection给我的最大价值，不是省了多少分钟，而是改变了我对自动化项目的认知：

它把“不可控”变成了“可调”：以前OCR不准，只能抱怨模型；现在我能调阈值、看坐标、微调数据，问题变得具体、可解；
它把“黑盒输出”变成了“白盒输入”：JSON坐标不只是结果，更是下一步流程的输入。我可以基于坐标做字段定位、做表格线检测、甚至做发票真伪的空间逻辑校验（比如“开票日期”必须在“发票代码”下方）；
它把“技术项目”变成了“业务项目”：财务同事现在自己就能上传发票、调阈值、下载结果，我不再是“那个修电脑的”，而是“教他们用工具的人”。

如果你也在为发票、合同、单据的数字化头疼，别再纠结“哪个API更便宜”，先试试这个镜像。它可能不会让你一夜之间成为AI专家，但一定能让你明天就少录50张发票。