受前段时间看过的一篇帖子启发，同时用 ocr 和视觉大模型进行识别，结果相同的才输出，输出质量感觉会非常高，缺陷是可能存在没输出的情况
 |
1
8355 1 天前
这样的策略本质上是通过降低识别率来提高正确率
按我的理解一定是没有只使用 ocr 来的好 |
 |
3
RotkPPP 1 天前
vlm 还真没有 ocr 好用，而且 vlm 如果能正确识别出来，ocr 一定可以，但 ocr 能识别的，vlm 还真不一定。主要看业务场景吧
|
 |
5
huangzhiyia 1 天前  5
在 GitHub 上看到个挺有意思的开源解决方案 iOS OCR Server ，它把 iPhone 手机变成强大的本地 OCR 服务器。
基于苹果的 Vision Framework 实现高精度文字识别，支持多语言自动检测，只需在同一网络下通过 IP 地址访问即可使用。 GitHub： http://github.com/riddleling/iOS-OCR-Server |
 |
6
gpt5 1 天前
这本来就是通过提高 frr 来降低的 far ，“缺陷”当然就是 frr 高了。far/frrd 的平衡，一般看具体场景。
|
 |
8
cctrv 1 天前 via iPhone
VLM 的問題主要在 OCR 精度問題。
我是把 OCR 文本和圖像一併送入 VLM 。 那麼就可以完美降低 VLM 的 OCR 錯誤問題。 |
 |
9
paopjian 1 天前
前两天才看到的逆天例子 https://www.zhihu.com/question/302170944/answer/1952029733140268672, 日常里 OCR+VLM 应该是没问题, 恶意攻击那可真是防不胜防
对于清晰文字, 普通 OCR 已经很能打了, 手写识别这种上 VLM 可以解决部分, 但是两个一起问题就是 VLM 的准确性了, 差一个字这种你就舍弃会被认为阈值过高 |
 |
12
Julaoshi 1 天前
忘了哪里看到的，似乎可以先放大再进行 OCR ，这样识别准确率就会提高
|
 |
13
ltmst 1 天前
阿里已经有了
我前些阵子测试了一下 效果只能说一般 |
 |
15
surbomfla 1 天前
但这样做计算开销比较大
|
 |
16
InkAndBanner 1 天前
我们使用了 QwenVL2.5 7B 在资质图片场景下做了大量的结构化信息提取 ，总的效果还是比 OCR 要好的，但是存在一定幻觉 比如信息自动补全，和联想的情况。如果图片重点字段出现的位置类似 可以在对话的时候 提供左上和右下两个点位的坐标 来提示模型提取重点区域 会优化提取效果。至于 ocr 信息辅助模型进行提取，也是已经验证过的好办法，但是模型结果用来和 ocr 做对比 我觉得只会在一些对准确容忍度非常低的场景 如金融票据才会采用。但是金融票据往往是标准票据 ocr 已经很能打了，非标场景才是 VL 模型的发挥阵地
|
 |
17
Suinn OP @InkAndBanner 感谢分享，vlm 这块你们有试过 InternVL 或者 glmVL 吗，看最近的分数都挺高但是不知道实际能力和 qwen 比如何
|
 |
18
dem0ns 1 天前
既然是代码+代码实现 100%，那为什么不一步到位？既然能够一步到位，那么早就该有 100%的 OCR 。
|
 |
19
MIUIOS 1 天前
还有一个缺陷吧，速度下去了
|
|
20
InkAndBanner 1 天前
@dem0ns #18 抱歉 没有 我们是阿里系的 优先用 qwen
|
 |
21
AutumnVerse 1 天前 via iPhone
这不就是多源对比纠错吗？
完整方案应该是这样的，3 个源 ocr 对比，如果有 2 个源一样，就直接取用，3 个全都不一样，丢给大模型或人工纠错。 纠错结果丢给 ocr 模型二次训练 |
|
22
MIUIOS 1 天前
我遇到你这个问题，我的做法是 OCR 出来后丢给 llm 大模型去修复
|
 |
23
malusama 1 天前
直接 ocr 丢给 LLM 修复呗。 你这样一致的能有多少，准确率上去了不得看看能召回多少吗？
你这都没有多少是输出一致的吧 |
|
24
AutumnVerse 1 天前 via iPhone 1
@Julaoshi 不可能，机器学习网络参数是固定的，无论你什么尺寸，前向传播前都会 resize 成固定尺寸
你觉得识别率高了仅仅是插针拉伸裁剪之类的算法导致识别结果不一样了而已，从算法原理上放大不可能影响识别率 |
 |
25
Insolitude 1 天前 via Android
调用过 Google 的 ai ocr 的接口，效果感觉还不如本地的 ocr ，，可能手写体 ai 会更好点。让 llm 优化传统 ocr 的结果，感觉是个不错的思路。目前我用的本地 ocr 主要就中文的标点会识别成英文标点的问题，发给 llm 很容易解决。
|
 |
28
canteon 1 天前
人工校对
|
 |
29
tusj 1 天前
先 OCR 识别生成文本结果，再大模型对文本纠正一下低级错误。这样组合怎样？
|
 |
30
hccsoul326 1 天前 1
月薪 3000 招个大学生人工识别
|
 |
31
kingofzihua 1 天前
@hccsoul326 你这个最靠谱
 |
 |
32
billbob 1 天前
100% 目前任何的技术方案都实现不了。能上 90%已经优秀了。专门场景识别的，特定数据训练能达到 99%往上
|
 |
33
retrocode 1 天前 2
很久之前研究过 ocr, 然后自己训练. 是个金融项目反爬很厉害, 让 OCR 识别, 只识别数字然后导入到"老板自己的秘密算法"里出结果, 结果 OCR 不是很理想正确率 97/98 左右速度也慢, 完了老板还是不满意, 因为金融项目数字很多人工校对很麻烦, 折腾了快三月, 图片二值化,图在切碎些全全搞了, 最后切成了一个数字一张几 B 的图片.
在看之前编写的一堆规则把图片都切的细碎了, 一咬牙一跺脚,把所有图片的数字像素转成了字符串硬编码(类似 X 黑 X 白 X 黑 X 白这种字符串), 然后花了两天跑了下数据看有没有遗漏的没记下的像素组成, 结果识别率 100%(因为没走 OCR 直接比字符串). 速度还快以前转 OCR 一张小图 2~3 秒,现在 30 张图 2~3 秒. 这应该也算"要么识别准"的一种方案了,不过只适合固定来源的数字识别. |
|
34
Suinn OP @billbob 目前这个方案虽然无限降低了召回率，但几乎也过滤了所有假阳性的情况，现在比较头疼的点确实在于没法论证能达到百分百的准确率，直觉上来说总感觉就是无限逼近 100%😂
|
 |
36
showonder 1 天前
你这不如多换几个技术路线不同的 OCR ，效率更高还更便宜
|
 |
38
kinkin666 1 天前
要不试试先 ocr ，再连图带字（甚至可以包含文字流的坐标位置）一起给多模态的大模型归纳一下，
ocr 效率可能高，但是归纳能力不大好吧，大模型可以直接把扫出来的东西归纳成结构化数据（几级标题、表格列表、水印页码都能识别出来），这点通用 ocr 比不了 |
 |
39
mingtdlb 1 天前
你自己都讲了“输出质量感觉会非常高，缺陷是可能存在没输出的情况”，那还说啥呢
100 个样本，本来 vlm 能识别 80%，ocr 只能 50%，结果你输出就成 50% 了 |
 |
40
hmxxmh 1 天前
感觉存在几个问题：1 、成本 2 、速度 3 、如果完全一致才输出，要求太严苛了，错一个标点就不输出
|
 |
42
Meteora626 1 天前
指定是本地微调的 ocr 更准，这个没有争议的，百度现在就是靠一个 ocr 维持着 ai 体面，
|
 |
43
Leon6868 1 天前
我的理解是，看你 OCR 想要做什么任务？
如果要版面还原，VLM 绝对强于任何形式的 OCR 模型，因为真正复杂的 OCR 甚至接近 AGI 。 如果只是提取文字，也许可以模仿 OCR pipeline ，版面处理后再用模型做识别，同时用识别数据微调模型，我认为 3B 就能胜任大多数文字提取任务。 |
 |
44
kuanat 1 天前
实践中所有这种需求场景几乎都采用人工复核的方式，倒不是因为人一定对，而是因为人可以担责。如果你的方案里要求去掉人，那这个问题就无解，除非你能为出错的数据兜底。你能兜底的程度越低，相应的置信度阈值就要拉得越高，实践中能够自动化识别的样本比例就越低。
另外单据 ocr 识别是个多少年的需求了，做这个的外包公司或者团队怕不是遍地走。这事根本没必要上大模型，传统 ocr 算法完全够用。 各种 ocr 算法方案在归一化之后的性能表现差距很小。差别大的方面是，在没有前置信息的情况下，先识别出哪里有文字，字符间如何分隔，以及判断文字可能的语言的阶段，以及整体的识别速度。 对 2000 年前后基于传统算法的方案来说，ocr 识别能力属于有多少人工就有多少智能的水平。只要是标准化印刷单据加手写的识别场景，几乎都可以暴力解决。算法判定不准文字位置、字符集，但是人知道啊，提前对单据照片或者扫描图进行畸形校正、裁切和二值化，再把手写的部分抠出来切分，最后只把识别的过程交给 ocr 。这个流程差不多是过去 20 年最主要的方案，基本上只看你归一化做得是不是细致。据我了解有些团队做久了，积攒下几千种不同的单据模板。 2010 年之后 ocr 算法过渡到了 cnn 为主，但相对于之前的暴力解法来说，没什么差别。原来甲方用了 ocr 还是要有个人负责复核，现在一样需要这个人，就算用上了什么大模型，即便出错概率极低，还是需要一个人来兜底。 |
 |
46
ZiChun 15 小时 55 分钟前
你如果自己用过 VLM 的话，你会发现，VLM 用于 OCR 场景会选择性输出部分更关键的内容，但是 OCR 不会，这个时候是很难对齐的。
|
|
47
retrocode 15 小时 33 分钟前
@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 ""; } } ``` |
Select Language