2、技术选型与架构设计：OCR技术对比、深度学习框架选择、系统整体架构设计

好，咱们进入第二章。说实话，技术选型这块，我见过太多人一上来就追新——哪个框架火用哪个，哪个模型准上哪个。结果呢？部署的时候发现环境搭不起来，或者跑起来卡得要命。嗯，今天我就把我在几个货架项目里踩过的坑、试过的方案，掰开揉碎了跟你聊聊。

2.1 OCR技术对比：谁才是货架场景的王者？

货架标签识别，核心就是OCR。但OCR技术流派很多，我简单分三类：传统OCR、轻量级深度学习OCR、以及大模型OCR。

先看一张对比表，心里有个底：

技术方案	代表工具	识别精度	推理速度	部署难度	适用场景
传统OCR	Tesseract 4.x	低（60-70%）	快	低	印刷体、清晰标签
轻量级深度学习OCR	PaddleOCR、EasyOCR	高（85-95%）	较快	中	货架标签、价签
大模型OCR	GPT-4V、Qwen-VL	极高（95%+）	慢	高	复杂版面、手写

我个人习惯，货架场景首选PaddleOCR。为什么？

• 中文识别强：PaddleOCR对中文、数字、特殊符号（比如￥、.、-）的支持，比Tesseract好太多。我在一个超市项目里，Tesseract把“￥12.50”识别成“Y12.50”，这种错误在结算环节会出大问题。
• 轻量可定制：它自带超轻量模型（MobileNetV3），在树莓派上都能跑。而且你可以用自己标注的标签数据微调，我试过，200张标注图就能把精度从88%提到94%。
• 部署友好：支持C++、Python、Java多种语言，还能转ONNX。我曾经在ARM开发板上部署过，内存占用不到200MB。

2.2 深度学习框架选择：PyTorch vs PaddlePaddle vs TensorFlow

框架选型，说白了就是选生态。我这些年用过TensorFlow、PyTorch、PaddlePaddle，说说真实感受。

PyTorch：学术界首选，社区资源最丰富。如果你要做模型创新、发论文，PyTorch没得选。但部署时有点折腾——转ONNX、量化、剪枝，每一步都可能踩坑。我记得有一次把PyTorch模型转TensorRT，折腾了两天才跑通。

PaddlePaddle：百度出品，工业部署极其方便。它有个“动静统一”的机制，训练时用动态图调试，部署时一键转静态图。我在一个零售项目中，从训练到部署到ARM板，只花了半天。而且PaddleOCR本身就是基于PaddlePaddle的，天然兼容。

TensorFlow：曾经的老大，现在有点尴尬。TF2.x虽然整合了Keras，但生态分裂严重。我建议除非团队有历史包袱，否则别从零开始用TF。

我的建议很直接：

• 做原型验证：用PyTorch，灵活、调试方便。
• 做产品落地：用PaddlePaddle，省心、部署快。
• 别碰TensorFlow（除非你老板逼你）。

2.3 系统整体架构设计：从采集到入库

好，技术选型定下来了，咱们看看整个系统怎么搭。我习惯把系统分成四层，每一层各司其职。

2.3.1 数据采集层

这一层负责“看”和“拍”。硬件上，我推荐用工业相机（比如海康威视的MV系列），分辨率至少500万像素。为什么？货架标签上的字很小，比如“生产日期：2024-03-15”，如果像素不够，OCR根本看不清。

软件上，用OpenCV做图像预处理。我常用的流水线是：

# 图像预处理流水线
1. 转灰度图（cv2.cvtColor）
2. 高斯模糊去噪（cv2.GaussianBlur）
3. 自适应二值化（cv2.adaptiveThreshold）
4. 形态学操作（开运算去噪点）
5. 透视校正（如果标签倾斜）

你想想看，如果标签拍歪了，OCR直接崩。所以透视校正是关键一步。我一般用四点变换，找到标签的四个角，然后拉正。

2.3.2 识别推理层

这一层是核心。我建议用PaddleOCR的PP-OCRv4模型，它包含三个子模块：

• 文本检测：找到标签上哪些区域有文字。
• 方向分类器：判断文字是正着还是倒着。
• 文本识别：把文字区域识别成字符串。

部署时，我习惯用Paddle Inference，比PaddleHub快30%左右。如果你用GPU，记得开启TensorRT加速，推理时间能从50ms降到15ms。

2.3.3 数据后处理层

OCR识别出来的结果，往往是“￥12.50\n生产日期：2024-03-15”这种原始字符串。我们需要解析成结构化数据。

我常用的方法是正则表达式+规则引擎。比如：

import re

def parse_label(text):
    # 提取价格
    price_match = re.search(r'￥?(\d+\.?\d*)', text)
    price = price_match.group(1) if price_match else None
    
    # 提取日期
    date_match = re.search(r'(\d{4}-\d{2}-\d{2})', text)
    date = date_match.group(1) if date_match else None
    
    return {"price": price, "date": date}

当然，如果标签格式很乱，可以考虑用规则引擎（比如Drools）或者小模型做实体抽取。但说实话，货架标签的格式相对固定，正则就够了。

2.3.4 数据存储与展示层

最后，识别结果要存起来。我推荐用时序数据库（比如InfluxDB）存价格变化，用关系型数据库（比如PostgreSQL）存标签元数据。为什么分开？因为价格是随时间变化的，而标签信息（如商品名称、规格）相对固定。

展示层，用Grafana或者自建Web界面。我习惯用Flask+Vue搭一个轻量级看板，实时显示当前货架标签的识别状态、错误率、处理速度。

2.4 架构图（文字描述）

整个系统的数据流是这样的：

[工业相机] → [OpenCV预处理] → [PaddleOCR推理] → [正则解析] → [数据库] → [Web看板]
     ↑                                                                       ↓
     └────────────────────── 反馈闭环（错误数据重新采集）──────────────────────────┘

嗯，这个闭环很重要。如果识别出错，系统应该自动触发重新拍照，或者推送到人工审核队列。别让错误数据一直躺在数据库里。

2.5 本章小结

说白了，技术选型没有银弹。我的原则是：先跑通，再优化，最后才考虑炫技。PaddleOCR + PaddlePaddle这套组合，我在三个货架项目里验证过，稳定、高效、好维护。如果你刚开始做，照着这个架构搭，至少能少走两个月弯路。

下一章，咱们聊聊数据采集的具体实现——怎么拍、怎么存、怎么保证质量。到时候我会分享一些我在现场踩过的坑，比如反光、遮挡、模糊……嗯，都是血泪史。

---

公众号:蓝海资料掘金营，微信deep3321