这样是否可以保证 OCR 识别率接近百分之 100

@8355 #1 不是说了吗 ocr 和大模型输出一致才有输出，大模型出幻觉了就没输出了啊

指定是本地微调的 ocr 更准，这个没有争议的，百度现在就是靠一个 ocr 维持着 ai 体面，

我的理解是，看你 OCR 想要做什么任务？
如果要版面还原，VLM 绝对强于任何形式的 OCR 模型，因为真正复杂的 OCR 甚至接近 AGI 。
如果只是提取文字，也许可以模仿 OCR pipeline ，版面处理后再用模型做识别，同时用识别数据微调模型，我认为 3B 就能胜任大多数文字提取任务。

实践中所有这种需求场景几乎都采用人工复核的方式，倒不是因为人一定对，而是因为人可以担责。如果你的方案里要求去掉人，那这个问题就无解，除非你能为出错的数据兜底。你能兜底的程度越低，相应的置信度阈值就要拉得越高，实践中能够自动化识别的样本比例就越低。

另外单据 ocr 识别是个多少年的需求了，做这个的外包公司或者团队怕不是遍地走。这事根本没必要上大模型，传统 ocr 算法完全够用。

各种 ocr 算法方案在归一化之后的性能表现差距很小。差别大的方面是，在没有前置信息的情况下，先识别出哪里有文字，字符间如何分隔，以及判断文字可能的语言的阶段，以及整体的识别速度。

对 2000 年前后基于传统算法的方案来说，ocr 识别能力属于有多少人工就有多少智能的水平。只要是标准化印刷单据加手写的识别场景，几乎都可以暴力解决。算法判定不准文字位置、字符集，但是人知道啊，提前对单据照片或者扫描图进行畸形校正、裁切和二值化，再把手写的部分抠出来切分，最后只把识别的过程交给 ocr 。这个流程差不多是过去 20 年最主要的方案，基本上只看你归一化做得是不是细致。据我了解有些团队做久了，积攒下几千种不同的单据模板。

2010 年之后 ocr 算法过渡到了 cnn 为主，但相对于之前的暴力解法来说，没什么差别。原来甲方用了 ocr 还是要有个人负责复核，现在一样需要这个人，就算用上了什么大模型，即便出错概率极低，还是需要一个人来兜底。

@retrocode 意思是这个图片像素的组合是有限的吗。。

你如果自己用过 VLM 的话，你会发现，VLM 用于 OCR 场景会选择性输出部分更关键的内容，但是 OCR 不会，这个时候是很难对齐的。

@Ming5Ming 是的, 我找了下当时的代码, 核心那段方法是这样的. 90 多个 case, 涵盖 0-9 和小数点还有-号. 因为最后已经把图片处理的高度一致了,二值化后把所有独立的白色像素按块全部切出来, 本意是缩小图片在能识别出来的同时加速 ocr 速度, 最后单数字尺寸都极小了, 索性从上到下从左到右直接数连续的白色像素了, 跑了两天把遗漏的 case 加进去, 效果还算不错反正是解决问题了.
```java
public static String isNumber(StringBuffer tempStr) {
switch (tempStr.toString()) {
case "11111":
case "111111":
return "-";
case "11111161111116":
return "-0";
case "2":
return ".";
case "11":
case "22":
return ":";
case "61111116":
case "51111117":
case "52211117":
case "71111115":
case "71111117":
case "72211227":
return "0";
case "1181":
case "129":
case "1229":
case "1299":
case "2299":
return "1";
case "2211111111121":
case "22312112141":
case "111311111131":
case "112212112141":
case "121312112131":
case "122413113141":
case "121312112141":
return "2";
...
...
...
case "42221111117":
case "411111111117":
case "411221112227":
case "412221111117":
return "9";
case "1210111021":
return "↑";
case "132121911132121911":
case "132131911132131911":
return "44";
case "4141111111141132121911":
case "4141111111141132131911":
return "54";
case "4141111111141132121911132121911":
return "544";
default:
int err = 1 / 0;
return "";
}
}

```

@kuanat 感谢分享，我图像处理和 vlm 学的还行，但确实没从事过真正生产端的 ocr 开发，你提到的需求场景几乎都采用人工复核的方式，我思考的点正是源自于是否能提供另一种模式，仅在服务不提供输出时再进行人工复核，对于输出部分的内容可以百分百信任