1. 电商商品图里的信息为什么非要靠 OCR 才能规模化吃掉做电商自动化久了你会发现最花时间的往往不是接口对接而是图片里的文字。这里说的不是详情页那种整版文案而是商品图上散落的品名、规格、成分表、条形码、促销标签——这些信息在内部系统里经常根本没有独立字段却实打实影响上架、库存和价格策略。我最近在自己机器上搭了一个模拟项目X核心就是做一件事用 OCR API 批量识别商品图片文字把原来得靠人工一张张看的图片信息变成结构化数据。整套方案跑通后录入效率提升明显这篇文章把完整环节、代码示例和踩坑记录都整理出来适合手上有大量商品图、想解放人力的开发者和电商运营团队参考。1.1 一张商品图里到底藏了多少关键字段很多人以为商品图就是“给买家看的图”但从数据处理角度看它是一张信息密度极高的非结构化载体。以一张常见的化妆品包装图为例正面主标上有品牌名、品名、净含量、色号背面可能有全成分列表、生产许可证号、委托方信息侧面还可能贴了条形码和限期使用日期。这些内容如果都能自动抽出来上架建档、合规审查、价格监控全都变得有据可依。我平时主要关注这几类字段信息分类常见内容业务价值基础属性品名、品牌、规格、型号商品建档、类目映射包装标签条形码、生产日期、保质期库存追溯、临期预警卖点文案限时特惠、0糖0卡、第二件半价竞品分析、价格监控法定信息生产许可证、执行标准、成分表违规词检测、合规审查这些字段大多以中文字为主又经常夹着英文成分或数字和普通扫描件不太一样OCR 处理时会有专属的难点。后面章节会展开讲。1.2 人工录入一件商品要付出多少隐性成本以前团队处理这批图片的流程很原始运营打开一张图把文字抄进 Excel再逐项核对。一张图快的 30 秒复杂的配料表可能要 2 分钟。当时模拟项目X里有一批约 3000 张的历史商品图算下来光录这些字段就需要两三个全职运营忙一星期而且这种高强度重复劳动在下午特别容易出错——某次饮料营养成分表里的“碳水化合物”被手误录成了另一位数字商品详情页上线后消费者直接投诉。人工录入的成本其实有两个层面一是时间成本二是出错后的纠错成本。错误数据进入订单系统、库存系统后排查链路往往要跨好几个系统远比重录一次贵得多。所以当时我的判断是这类“看图取字”的环节必须用 OCR 自动化掉哪怕初期需要花时间调参和补规则也比长期养人工划算。1.3 我为什么选 OCR API 而不是自建模型确定要用 OCR 之后第一个问题是自建还是调用现成 API。我们内部讨论过基于开源模型自建方案最后放弃了。原因很现实数据成本高印刷体中英文混排的微调数据集至少需要几万张标注图商品包装风格又五花八门光标注人员就要投入大量工时。工程成本高GPU 推理服务、训练流水线、模型版本管理每一样都得有专人维护而这些并不在业务主线上。迭代成本高电商图片里的字体、排版、促销贴纸年年变自建模型需要持续标注、重训API 服务方通常已经在不同行业场景里做了大量迭代。调用现成 OCR API 的本质是用“按次计费”换“免运维 持续迭代”。它的劣势也很明确按量付费、图片数据需要出域所以不适合处理涉密或敏感资料。我们这个模拟项目处理的都是公开商品图风险可控于是最终选了 API 路线。2. 整套方案的链路拆解图片进结构化文本出OCR 不是一个单点函数而是一条数据流水线。我把它拆成四个环节图片来源采集、图片预处理、OCR 识别、结果结构化清洗与存储。每个环节都有可优化的空间也都有各自的坑。2.1 数据从哪来本地目录与图片链接两种输入方式模拟项目X的输入数据主要有两种形态。一种是历史商品图当时都堆在共享目录里文件名基本是 SKU 编号加简短描述格式以 jpg/png 为主。这种本地批量扫描最简单用 glob 把目录下的图片全部找出来就行。另一种是运营发来的图片链接需要先下载再进入后续流程。这里要特别提醒一点凡是做图像数据批处理合规边界要先想清楚。处理公司自有或明确授权的图片没有问题但不要拿未经授权的外部图片、竞品私域图片批量跑 OCR否则后续使用时会面临侵权风险。我们只处理内部有权使用的商品图。2.2 预处理必须做的事尺寸、格式、方向图片读进来不能直接丢给 API先要过三关第一关是格式处理。用 PIL 读图时经常遇到 RGBA 模式的 PNG直接转 JPEG 会出错要先转成 RGB。有些扫描件有 EXIF 方向信息打开后旋转不对也要在预处理阶段校正。第二关是尺寸控制。多数通用 OCR API 对图片大小有限制比如最长边 4096 像素内、文件体积 8MB 内。电商原图很多是 2000 到 4000 像素的高清图直接传不一定报错但传输慢、解码慢成本也没必要。我会先等比压缩到最长边 2000 像素左右能让识别速度和费用都更友好。第三关是图像增强。低分辨率小字、过暗图片、艺术字体这些是 OCR 失败的重灾区。增强手段包括放大截图区域、灰度化、二值化但要看图施法后面第 5 章会详细讲哪些场景该用什么方法。2.3 识别完的文本如何变成可用字段OCR API 返回的内容本质上是一堆“文字块 坐标 置信度”不是业务字段。要把它们变成可用数据还有两步关键工作。第一步是坐标排序。API 返回的文字块往往不是自然阅读顺序尤其是多栏排版、圆形包装标签直接拼接会得到天书一样的文本。我会按文字的 top 坐标聚类成行同一行内再按 left 坐标从左到右排序这样拼出来的文本至少人类能读懂。第二步是规则清洗。商品图上的文字有比较强的规律可循比如日期可以匹配\d{4}-\d{2}-\d{2}条形码可以匹配 13 位数字规格可以匹配“净含量500ml”这类模式。用正则加品类词典做后处理能把“一堆文字”变成“多个字段”这一步才是 OCR 真正产生业务价值的地方。2.4 存储设计为什么必须保留完整原始结果存储环节我做了一个后来觉得非常重要的决定把所有 OCR 原始返回结果按 JSONL 格式完整保留同时把结构化后的结果导出成 CSV 给运营使用。JSONL 的好处是后续想调整排序逻辑、清洗规则、置信度阈值时不需要重新调一遍 OCR 接口直接基于原始坐标和文字重新计算就行。这相当于给数据留了一个可以回放的原始档排查问题时非常有用。CSV 则用来给业务同事在 Excel 里做核验和修改他们不需要理解任何技术细节打开表格就能干活。3. 完整代码示例批量OCR识别商品图片的Python实现下面直接给出我在模拟项目X里使用的核心代码。整体思路是预处理图片、调用 OCR API、解析返回结果、并发批量处理、落盘输出。3.1 环境准备与依赖清单运行环境是 Python 3.8依赖不多pip install requests pillow pandas tqdm如果后续要做透视变换、图像增强会用到 opencv-python基础版可以先不装。代码里通过环境变量控制 API 地址、密钥、并发数不要把密钥硬编码进脚本。import os import io import json import time import glob import base64 from pathlib import Path from concurrent.futures import ThreadPoolExecutor, as_completed import requests from PIL import Image import pandas as pd from tqdm import tqdm OCR_API_URL os.getenv(OCR_API_URL, https://ocr-api.example.com/v1/general) OCR_API_KEY os.getenv(OCR_API_KEY, YOUR_API_KEY) LANGUAGE_TYPE os.getenv(OCR_LANGUAGE_TYPE, CHN_ENG) MAX_WORKERS int(os.getenv(OCR_MAX_WORKERS, 5))3.2 单图识别接口的封装预处理、编码与请求第一个函数负责把图片文件转成合格的 Base64 字符串。核心逻辑是读图、转 RGB、等比压缩、保存到内存缓冲再编码def encode_image(image_path: str, max_side: int 2000, quality: int 92): try: img Image.open(image_path) if img.mode in (RGBA, P, LA): img img.convert(RGB) w, h img.size if max(w, h) max_side: ratio max_side / float(max(w, h)) img img.resize((int(w * ratio), int(h * ratio)), Image.LANCZOS) buffer io.BytesIO() img.save(buffer, formatJPEG, qualityquality) return base64.b64encode(buffer.getvalue()).decode(utf-8) except Exception as exc: print(f[skip] {image_path}: {exc}) return None接下来封装 OCR 请求。我习惯把鉴权头、参数、超时都集中在这里方便统一调整def call_ocr(image_b64: str) - dict | None: headers { Authorization: fBearer {OCR_API_KEY}, Content-Type: application/json, } payload { image: image_b64, language_type: LANGUAGE_TYPE, detect_direction: True, probability: True, } try: resp requests.post(OCR_API_URL, headersheaders, jsonpayload, timeout30) resp.raise_for_status() data resp.json() if data.get(error_code) not in (None, 0): raise RuntimeError(data.get(error_msg, unknown error)) return data except Exception as exc: print(f[ocr error] {exc}) return None这里有个细节需要注意detect_direction和probability两个参数并不是所有 OCR 服务都默认返回但几乎所有主流服务都支持。开启方向检测会消耗一点额外时间但电商图片经常存在上下颠倒、顺时针 90 度的情况不检测的话识别结果全废。3.3 解析返回结果并按坐标重组文本顺序OCR 返回的 JSON 结构一般是这样的{ direction: 0, words_result_num: 3, words_result: [ { words: 2025新款, location: {left: 10, top: 20, width: 100, height: 30}, probability: {average: 0.98, min: 0.95} } ] }拿到words_result后第一件事不是直接拼接文本而是按坐标排序。我的实现是先按 top 聚类行再在行内按 left 排序def conf_of(word): prob word.get(probability) if isinstance(prob, dict): return prob.get(average, 0.5) if isinstance(prob, (int, float)): return prob return 0.5 def group_into_lines(words, line_tol15): items [] for w in words: loc w[location] items.append({ text: w[words], left: loc[left], top: loc[top], right: loc[left] loc[width], bottom: loc[top] loc[height], conf: conf_of(w), }) items.sort(keylambda x: x[top]) lines [] for item in items: if lines and abs(item[top] - lines[-1][top]) line_tol: lines[-1][words].append(item) else: lines.append({top: item[top], words: [item]}) for line in lines: line[words].sort(keylambda x: x[left]) return lines之后再把每一行的文字用空格或制表符拼接形成人类可读的整段文本。注意不要让 line_tol 太小否则一行文字的 top 坐标略有波动就会被错误拆成多行。3.4 批次入口并发控制、失败重试与进度展示批量处理的核心函数长这样。我用ThreadPoolExecutor控制并发数默认 5 个线程对大多数 API 来说已经是安全速度识别失败会指数退避重试 3 次def process_with_retry(image_path: str, max_retries: int 3) - dict: b64 encode_image(image_path) if b64 is None: return {file: image_path, ok: False, error: encode_failed} for attempt in range(max_retries): data call_ocr(b64) if data is not None: lines group_into_lines(data.get(words_result, [])) full_text \n.join([ .join(w[text] for w in line[words]) for line in lines]) confs [w[conf] for line in lines for w in line[words]] avg_conf sum(confs) / len(confs) if confs else 0 return { file: image_path, ok: True, text: full_text, words_count: len(confs), avg_conf: round(avg_conf, 3), direction: data.get(direction, 0), } time.sleep(min(30, 0.5 * (2 ** attempt))) return {file: image_path, ok: False, error: ocr_failed} def run_batch(image_dir: str, out_jsonl: str, out_csv: str) - None: files [] for suffix in (*.jpg, *.jpeg, *.png, *.webp): files.extend(glob.glob(os.path.join(image_dir, suffix))) if not files: print(no images found) return results [] with ThreadPoolExecutor(max_workersMAX_WORKERS) as pool: future_map {pool.submit(process_with_retry, f): f for f in files} with open(out_jsonl, w, encodingutf-8) as f_out: with tqdm(totallen(files)) as bar: for fut in as_completed(future_map): result fut.result() results.append(result) f_out.write(json.dumps(result, ensure_asciiFalse) \n) f_out.flush() bar.update(1) df pd.DataFrame(results) df.to_csv(out_csv, indexFalse, encodingutf-8-sig) print(f[done] total{len(df)}, ok{df[ok].sum()}, failed{len(df) - df[ok].sum()})这段代码可以直接放进脚本跑也可以封装成一个 CLI 函数反复调用。我特意把 JSONL 写入和 CSV 导出放在同一个批次里保证每一张图的结果都能即时落盘避免程序中途崩掉导致前面的工作全丢。3.5 复用技巧如何做到“改清洗规则不重调 OCR”前面提到保留原始返回结果这里补一个很实用的设计把 OCR 原始 JSON 和结构化文本分开存储。原始 JSON 里带坐标和置信度可以随时重跑“排序 正则清洗”这一步如果只存最终文本后面想调整成分提取规则就得重新调一遍付费接口。我在目录结构上做了三层raw/存放原始图片按日期归档ocr_json/每张图对应一个 JSON 文件完整保留 API 返回output/存放 CSV 或 Excel给运营和业务使用。这样分层之后改规则只是读ocr_json/里的旧数据重新算一遍成本和效率都可控。4. 参数调优与成本控制别让 API 费拖垮自动化收益OCR API 按调用次数计费批量处理商品图时参数选得对不对直接影响费用和效果。我在这套模拟项目X上做过几轮对比下面这些经验都是实测后沉淀下来的。4.1 语言识别范围与中英混排电商商品图最常见的情况是中英文混排正面是中文品名背面成分表或说明书里夹着英文术语甚至日文假名。我一开始直接把语言参数设成中文结果英文成分被识别成乱码。后来改成CHN_ENG混合模式准确率提升非常明显。如果业务里还有日韩商品、欧洲商品要提前确认所选 API 是否支持多语种混合识别不要指望一个中文模型硬扛。语言参数一旦调对后面清洗规则的复杂度也会降低。4.2 方向检测和高精度模式该不该开方向检测建议在批量处理时保持开启尤其是图片来源复杂的情况下。我实测过一批运营上传的图片其中有大约 15% 的图片存在 90 度、180 度旋转问题开启detect_direction后这些问题基本都被自动校正。代价是每次请求多消耗一点时间但对批量任务来说可接受。高精度模式要不要开取决于图片质量。如果图片是干净的印刷体、白底黑字标准模型足够如果图片有复杂背景、艺术字、水印叠加开高精度模式能挽回不少错误识别但单价和时间都会上涨。我的建议是先跑 50 张测试图看错误集中在哪种图再决定全局是否开启高精度避免为一批 90% 都清晰的图多付费用。4.3 置信度阈值筛选把人工干预成本降到最低OCR 不可能做到 100% 正确关键是要设计一个“低置信度人工复核”机制而不是盲目信任识别结果。我设定了一条分档策略置信度区间处理策略 0.92直接入结构化数据不复核0.70 - 0.92输出到“待复核”队列运营抽查确认 0.70标记为识别异常进入人工补录流程这个阈值不是拍脑袋定的而是先用 100 张测试图跑了一遍观察错误率和置信度的关系后得到的。不同 API、不同图片来源最优阈值会不一样建议每接入一批新数据都做一次小样本校验。4.4 并发、限速与每日配额批量任务最容易踩的坑是并发调太高直接把 API 打爆触发限频甚至封禁账号。我在代码里默认设置 5 个并发跑下来一般不会触发限流如果 API 文档明确给出 QPS 上限就按上限的一半保守设置。另外我在脚本里加了每日配额参数。批量任务一旦跑起来很容易在无人值守时持续扣费成本不可控。设置一个MAX_CALLS_PER_DAY上限达到上限后脚本自动停止并输出日志提示“今日配额已用完”比事后看账单再后悔要省心得多。5. 我在商品图 OCR 上踩过的五个坑本地 Demo 实测记录理论和代码都到位之后真正跑起来才是问题的高发期。下面五个坑每个都是我在本地 Demo 测试中实际遇到并通过调整方案解决的。5.1 低分辨率小字放大反而更准处理某批次缩略图时图里成分表文字的高度只有 7 到 10 像素直接识别准确率惨不忍睹。后来我把图片按 2 到 3 倍放大使用Image.LANCZOS插值后再传给 OCR API效果立刻改善。实测对比很直观同一批 200 张图不放大时字符识别准确率约 63%放大 3 倍后提升到 89%。原理并不复杂——OCR 对笔画细节非常敏感小字在缩放和压缩过程中已经损失了大量细节放大等于帮模型补回了轮廓信息。5.2 艺术字和描边字容易串字符电商海报上常见的“SALE”“限量”“新品”经常是艺术字或带白色描边这类文字周围有一圈额外像素OCR 模型容易把字符边缘和背景混在一起结果出现“saleee”“限量量”这种错误。针对简单背景的图片我会先灰度化再去掉抗锯齿边缘局部区域甚至做二值化加大对比。但这里必须提醒二值化对复杂背景反而有害容易把花纹当文字输出大批量处理前一定要抽样验证。5.3 水印与促销贴纸叠字干扰商品图左上角经常被压一个“限时五折”的促销标签半透明水印叠在商品原包装文字上两个文字层混在一起识别结果经常出现“五折限折”这种串行内容。我的处理思路是给图片做区域划分根据运营确认的模板把固定被促销标签覆盖的区域裁剪掉只识别剩余干净区域。这招在自有商品图、版式固定的场景下特别有效如果图片版式每张都不同就需要用目标检测模型先定位贴纸再决定裁切策略复杂度会高不少。5.4 包装盒透视变形导致识别错乱有一部分图片是用户实拍的包装盒拍摄角度是斜的盒子上的文字呈梯形或平行四边形OCR 对这类变形文字的识别率直线下降。我的解决方法是做四点透视变换用 OpenCV 把梯形区域拉正为矩形后再识别。import cv2 import numpy as np def perspective_fix(image_path: str, pts) - np.ndarray: img cv2.imread(image_path) src np.array(pts, dtypenp.float32) width max(int(np.linalg.norm(src[1] - src[0])), int(np.linalg.norm(src[2] - src[3]))) height max(int(np.linalg.norm(src[3] - src[0])), int(np.linalg.norm(src[2] - src[1]))) dst np.array([[0, 0], [width - 1, 0], [width - 1, height - 1], [0, height - 1]], dtypenp.float32) matrix cv2.getPerspectiveTransform(src, dst) return cv2.warpPerspective(img, matrix, (width, height))不过透视矫正很难全自动化角点定位不准反而会引入新噪声。所以我的策略是能拿运营重新拍照的平拍图就不费劲矫正实在没有平拍图才用半自动方式人工框选角点跑透视变换后再识别。5.5 模拟测试集上的效果复盘为了验证整套方案的真实效果我选了 300 张覆盖不同品类的商品图做了测试。整体数字如下图片类型预处理前字符准确率预处理后字符准确率字段级正确率白底平拍图92.1%95.8%93.2%复杂背景海报图78.4%86.3%81.5%艺术字/水印图61.7%78.9%72.4%总体的字符级识别准确率约 94%但字段级正确率会低一些因为个别字段如生产日期、批号对错一个字符就算整条错误。跑完复盘我的结论是OCR 规则清洗能解决八成以上问题剩下 10% 到 15% 交给置信度过滤后的“低置信度人工复核”队列是投入产出比最高的现实方案。不要追求 100% 自动化那会把你拖进无底洞。如果你也想做类似的事我的建议是先从自己手头二三十张图跑一遍重点看失败集中在哪类文字上再决定要不要加预处理逻辑。实际情况里很多看似是 OCR 能力不足的问题其实在图片预处理阶段就已经能规避掉大半。另外一定记得保留 JSONL 原始结果后续改了排序、清洗规则可以直接重跑不用再付一遍识别费用排查问题的时候真的省心很多。