DeepSeek-OCR实测：8张专利图3.3B模型翻车225次

一张旋转90度的专利图纸，能把3.3B参数的本地视觉模型逼成"文盲"。测试者用8张真实专利图跑DeepSeek-OCR，2张完美、6张出错，最惨的一张 hallucinated 出225个不存在的"+"符号。这不是模型太弱，是专利图的设计本就反人类——或者说，反机器。

专利图：OCR的地狱难度副本

US11423567B2是一份人脸识别深度映射系统的专利，8张附图涵盖了流程图、密集仪器界面截图、带散落编号的技术架构图。这些图纸的"恶意"在于：文字方向混乱（整张纸旋转90度）、参考编号极小（"41"或"7025"这种尺寸）、白字黑底的密集数据屏、以及那些长得太像文字的框线箭头。

Sheet 01就是典型。整张图横躺着，标签"BP"、"DR"、"1"、"D"像撒落的芝麻。DeepSeek-OCR在0度角下只抓到2个可用结果，漏掉大半；转到270度，32个标签全中——包括那个横着印的"Figure 1"。

同一个模型，同一张图，旋转一下准确率差16倍。

DeepSeek-OCR的grounding模式本是个亮点：输入<|grounding|>OCR this image.，它返回带边界框的文本，格式像<|ref|>camera 110<|det|>[[412, 8, 455, 63]]。本地运行、3.3B参数，听着很香。但专利图这关，它过得磕磕绊绊。

干净流程图 vs 真实世界的泥沼

测试里唯一没悬念的是Sheet 00。 upright flowchart，线条清晰、文字水平，DeepSeek-OCR全对。这给了人虚假的希望。

其他图纸迅速暴露问题。旋转文本直接乱码："Acquiring"变成"Accurling"。小编号"61"被读成"19"。靠近绘图元素的小标签系统性丢失。最离谱的是Sheet 03——那张密集仪器截图。网格线被当成文字，模型一口气 hallucinated 出225个"+"检测框，满屏彩色方框像中了病毒。

二值化（转成纯黑白、拉高对比度）毫无帮助。专利图本来就是干净线稿，没什么可"清理"的。Tesseract的OSD旋转检测反而添乱：它会被横着的"Figure X"标签骗到，把本该直立的图强行旋转，结果更差。

专利图的旋转是全局的，但"Figure X"标签的旋转是局部的——这个矛盾让自动方向检测成了陷阱。

暴力穷举：128个token的廉价探针

既然自动检测不靠谱，测试者换了种笨办法：每张图跑三个角度（0°、90°、270°），手动比对结果。Sheet 01的16倍差距就是这么发现的。0度时模型只看见几个大编号（100、10、110、120、121），"BP"、"DR"、"D"、"1"全瞎；270度 upright 后，小字一个没落，连"Figure 1"都认对了。

但手动比对8张图×3个角度不现实。测试者试了"廉价探针"：每个角度只跑128个输出token，快速筛一遍。5/8的图选对了最佳角度——剩下3张，探针太短，差距细微时无法区分。

这个精度够用吗？看场景。专利分析要的是 reference number 和文本的对应关系，漏一个就可能误解技术方案。225个假阳性可以人工过滤，但系统性漏检（小编号、旋转文本）是硬伤。

本地模型的甜蜜与苦涩

DeepSeek-OCR的定位很清晰：3.3B参数、本地跑、带grounding。这在数据敏感场景（比如律所内部专利分析）是刚需。但专利图这个用例暴露了视觉模型的普遍困境——训练数据里有多少"旋转90度的技术图纸带散落编号"？

测试者没有公布后续优化方案。可能的路线包括：更聪明的旋转检测（或许先跑个轻量级分类器判断全局方向）、针对专利图的微调、或者接受"人工选角度"的半自动流程。

一个有趣的细节：模型对"看起来像文字的非文字"极度敏感。网格线、框线、箭头——这些在人类眼里是图形元素，在模型眼里都是候选字符。专利图的设计规范（为了清晰表达技术方案）恰好撞上了视觉模型的认知盲区。

如果专利局强制要求所有附图必须 upright 且文字水平排列，OCR准确率能飙升多少？这个假设本身就很讽刺——技术文档的"人类可读性"和"机器可读性"至今仍是两套标准。