OCR 标签核对：不可读文本与错误文本

目的与适用边界

在改动已知的预期答案之前，先查明 OCR 失败始于源像素、检测几何、识别器输出，还是验证规则。

本教程定义的是一项工程评估，而不是可直接运行的产品认证。当前 Deyi Vision 公开的 PC 示例涵盖在已确认样本图像上运行的 EAN-13 工作流。工程代码中的原生 OCR 与检测部分，使用前必须对照已安装的运行环境、已绑定的模型和作业进行核查。浏览器模板并不能证明可在浏览器中执行：规划中的 OpenCV.js 后端需要另行验证。云端识别必须明确批准所涉及的图像范围、服务商、模型和费用。评审存档不是可执行的发布包。相机、固件和驱动的兼容性需要单独核查。下列记录表中的所有数值均为假设，不是 Deyi Vision 的测量结果，也不是客户结果。

准备证据

分别保留原始的窄条边界案例和正常高度的字段。每次实验中预期批号都保持不变。写出一份失败记录，使另一位工程师无需猜测用的是哪幅图像或哪个版本，就能回放。记录中要包括原始源图像、受影响的区域、实际输出、预期处置，以及第一个出现偏差的中间结果。要记明该现象出现在回放中、实时采集中，还是两者都有。修正之后，重新运行原来的失败案例，以及之前成功的相邻条件。靠排除某个区域或接受缺失结果来消除一次报警的做法，改变的是要求，而不是解决了原因。如果失败仍未解决，应让受影响的操作保持在 Review 或禁止状态，并写明原因；不要把未经测试的变通办法标成已验证的解决方案。OCR 标签核对是一项数据完整性任务，而不是在找看似合理的词。定义每个字段、字段位置、预期字符集、精确比对规则，以及预期值的可信来源。批号字段、日期字段和产品名称可能需要不同的规则。在规范化空格或大小写之前，先保留文字检测多边形和识别器的输出。不要悄悄地把 I 替换成 1，或把 O 替换成 0：这会让错误的标签看起来正确。原始工程证据中有一个窄条形的 OCR 边界案例，其结果为 NoResult 或 Review；增大裁剪范围并不能证明识别已普遍可用。可读的字段仍可能是错误的批号；而预期值本身正确，也不能成为把它填进不可读字段的理由。从最早可观察到的偏差开始排查。把保存的同一份源数据，分别送入未改动的基线和候选方案回放，并比较中间图像、区域、数值和结果状态。如果源数据本身不同，这种比较就无法再把问题隔离到算法上。一次只改动一个怀疑的原因，运行之前先写下预期的效果；假设不成立时，保留这个否定的结果。要区分不可读的证据、规则不匹配、缺少依赖项和执行故障；它们需要不同的补救办法。回放可以复现软件故障，却无法验证实时触发、照明时序或物理剔除路径。这些采集和产线检查要作为独立的后续实验另行进行。

操作步骤

1. 更改参数之前，先回放原始裁剪图，记录 NoResult/Review，不要用预期批号去替代。
2. 比较字段的实际源高度、丢失的字符边距和检测器多边形；区分准入阶段的拒绝与识别后的不匹配。
3. 先查看规范化之前的原始文本，并测试易混淆字符，但不要为了硬让它通过而放宽允许的字符集。
4. 用修正后的采集或字段几何重新采集，并作为新的输入保存，而不是当作原测试的修复版本。

解读试验

文档记载的工程边界使用 160 × 8 的素材，预期为 LOT123；NoResult 或 Review 是如实的结果。160 × 64 的基线并不能证明任意更大的字段都能正常工作。对窄条图像做填充或拉伸，会改变实验本身，也无法抹去原来的失败。

记录表

两种工程视角

故障诊断

• 如果文本只有在把答案输入给模型之后才变正确，这次实验就无效。
• 如果多边形截掉了笔画，应先修复采集或映射，再去调整词典或匹配规则。

验收与交接

只有在查明最早出现故障的环节、并评估了一次独立的新采集之后，才可关闭该诊断。要保留原来的边界结果及其完整分母。

将源图像、预期判定、确切版本和完整的结果记录放在一起保存。在选定最终参数之前，先冻结评估集。如果这些答案之后被用来调整工作流，就要把该集合标记为开发数据，并另取一套独立的验收集。Review、NoResult、执行错误和缺失的采集都要保留在分母中；不要通过过滤数据行把它们变成合格。可复现的失败案例要与成功样品一并保存。交接内容应写明：谁可以修改配方，如何恢复先前获批的版本，以及在验收之前哪些设备输出保持禁止。仅凭软件结果，并不能证明运动中的实物工件到达了正确的去向。