DeepSeek 前几天发布了DeepSeek-OCR，当天就关注到了。特别值得注意的是模型大小只有6个多G，用我的笔记本（RTX4060 8G）就能够勉强运行。
今天尝试了一下，部署的是deepseek_ocr_app。
部署的注意事项：
- 后端用到的镜像最低支持的NVIDIA驱动版本是580.82，低于这个版本会报错；
- 在后端ENV部分可以添加
HF_ENDPOINT=https://hf-mirror.com，支持镜像进行下载； - 前端镜像可使用
docker.m.daocloud.io代理； - 在compose文件中，可以将主机的
$HF_HOME目录挂载到/models，这样会把模型下载到本地缓存。
我稍微修改了一下，可以直接提交多个图片，然后识别完了之后可以把所有结果保存在一个文件中。
由于我不懂前端，所以完全是面向Gemini编程。
我的用处主要是识别一些文字截图，之前主要使用白描和Umi-OCR（使用的是PaddleOCR v2.6/v2.8 cpp infer）。
对比了一下Umi-OCR和DeepSeek-OCR对同一批截图进行识别的结果，应该说有好有坏。
优点非常多：
- 对标点的识别要准确地多：
- 可以正确识别破折号。Umi-OCR总是将破折号「──」识别成「一一」。即使是最新的PP-OCR-v5也有这个问题。
（但DeepSeek-OCR会把「一一」识别成破折号……） - 可以正确处理引号。Umi-OCR对引号的识别一言难尽。同样是「”」，一会儿识别成「"」，一会儿识别成「“」，一会儿又把它漏掉，而且错误率特别高。又尝试了一下最新的PP-OCR-v5，正确率高了一些，但是会经常出错。
- 可以正确区分冒号和分号。Umi-OCR经常二者搞混。
- 可以正确识别行末的标点符号。Umi-OCR经常会把它漏掉。
- 可以正确识别章节符号「§」。
- 可以正确识别破折号。Umi-OCR总是将破折号「──」识别成「一一」。即使是最新的PP-OCR-v5也有这个问题。
- 在有水印的图片识别要好得多。DeepSeek-OCR不会被水印干扰，还能猜出被水印盖住部分的字，而Umi-OCR则会造成连续几行的排版混乱。
二者共同存在的问题：
- 无法正确识别一些字形相近的字，如「己」和「已」，「忽」和「忍」，「脑」和「胸」，「允」和「充」，「十」、「干」和「王」，「页」、「贞」和「负」等等。
- 无法正确合并段落。DeepSeek-OCR甚至发生了把原来在一行的内容给换行了。不过DeepSeek-OCR整体合并段落的情况要好于Umi-OCR。
- 偶尔会有漏字。不过DeepSeek-OCR漏字的情况要少一些。
但是，DeepSeek-OCR有一个缺点很严重，那就是会擅自修改内容！！！
- 擅自改字。例如，DeepSeek-OCR把「当事者」识别成了「当事人」，这显然不是识别本身出的错，而是在识别之后改的。
（当然，把原文中的错别字改对的情况也很多，但更多的是按照它自己错误的理解改的。） - 如果一个图片的最后一句话没完（剩下的在下一张图片上），DeepSeek-OCR会自动猜上。
- 擅自在行末加标点。
- 甚至还有在行末擅自加表情的……
- 擅自修改逗号和顿号。（虽然有的时候改对了……）
另外，DeepSeek-OCR的速度要慢得多。
看了一下论文，从它的架构图
可以看到，在最后负责解码输出的是一个DeepSeek-3B-MOE模型，也就是一个小型的DeepSeek模型，乱改识别到的内容显然是这部分的「杰作」。
20251025更新：
今天又试了一下DeepSeek-OCR对数学公式的识别，确实牛，基本上都对了。
不过问题和前面一样，就是它总喜欢自作聪明地去对结果进行修改。
例如上面对于一个考试试卷的识别，一共只有三处错误。第一个显然是它觉得不完整自己给补全的，就像之前我发现它特别喜欢补全标点符号一样。后两个错误看上去是识别错误，但我严重怀疑也是被改错的，特别是最后一个。