尝试使用DeepSeek-OCR

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，这样会把模型下载到本地缓存。

我的用处主要是识别一些文字截图，之前主要使用白描和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经常会把它漏掉。
  • 可以正确识别章节符号「§」。
• 在有水印的图片识别要好得多。DeepSeek-OCR不会被水印干扰，还能猜出被水印盖住部分的字，而Umi-OCR则会造成连续几行的排版混乱。

二者共同存在的问题：

• 无法正确识别一些字形相近的字，如「己」和「已」，「忽」和「忍」，「脑」和「胸」，「允」和「充」，「十」、「干」和「王」，「页」、「贞」和「负」等等。
• 无法正确合并段落。DeepSeek-OCR甚至发生了把原来在一行的内容给换行了。不过DeepSeek-OCR整体合并段落的情况要好于Umi-OCR。
• 偶尔会有漏字。不过DeepSeek-OCR漏字的情况要少一些。

但是，DeepSeek-OCR有一个缺点很严重，那就是会擅自修改内容！！！

• 擅自改字。例如，DeepSeek-OCR把「当事者」识别成了「当事人」，这显然不是识别本身出的错，而是在识别之后改的。
  （当然，把原文中的错别字改对的情况也很多，但更多的是按照它自己错误的理解改的。）
• 如果一个图片的最后一句话没完（剩下的在下一张图片上），DeepSeek-OCR会自动猜上。
• 擅自在行末加标点。
• 甚至还有在行末擅自加表情的……
• 擅自修改逗号和顿号。（虽然有的时候改对了……）

另外，DeepSeek-OCR的速度要慢得多。

看了一下论文，从它的架构图

可以看到，在最后负责解码输出的是一个DeepSeek-3B-MOE模型，也就是一个小型的DeepSeek模型，乱改识别到的内容显然是这部分的「杰作」。