1. 先搞清楚长文本处理到底卡在哪光学压缩能解决什么问题1.1 LLM 吃长文的三座大山我见过太多人做长文档问答第一反应就是把一份几十页的合同、论文或者产品手册直接塞进 Prompt让 LLM 一口气读完。这个方案在最简单的小样上确实能跑通但只要内容一多问题就一个接一个地冒出来。第一座大山是 token 成本。一页 A4 纸的正常排版纯文本大概有 500 到 800 个汉字但对大模型来说一页就对应 1500 到 2500 个 token如果再做字符级别的切分数字还会往上涨。一份 30 页的 PDF随随便便就是 5 万到 8 万 token。按现在主流模型的计费方式这还没开始干活光是把资料喂进去就已经花掉一大笔钱。第二座大山是上下文窗口的物理限制。现在不少模型对外宣传支持 128K、256K 甚至更长上下文但你真把十几万 token 一次性塞进去模型在生成时每一步都要重新计算注意力显存占用和响应延迟立刻失控。更麻烦的是很多号称支持超长上下文的模型实际在长文本中后段的召回准确率会肉眼可见地下降细节藏在第 8 页问答时就容易一本正经地胡说八道。第三座大山是“中间迷失”问题。注意力机制在处理超长序列时本质上对离当前位置越远的内容感知越弱。你让模型从第 1 页找到第 29 页的一句话它往往被中间大量的无关段落干扰最后给出一个模棱两可的答案。这个不是调 Prompt 能解决的而是架构层面的固有短板。正是因为这三座大山我开始留意“光学压缩”这条完全不同的路径。简单说就是不让 LLM 直接读原始文本而是先用 OCR 模型把文档内容做一次“精简提炼”只把最有价值的结构化信息交给 LLM。DeepSeek-OCR 就是这条路径里非常关键的一环。1.2 光学压缩的底层逻辑拍照速记而不是原文誊抄先解释一下“光学压缩”这个词。它并不是一个严格意义上的学术术语而是在工程圈里流传开的一种叫法。核心思路是把文本内容先渲染成图像再把图像交给 OCR 模型让模型用视觉理解的方式把页面上的信息提取成文本。整个过程相当于给信息做了一次“降维再还原”却不会保留原文档的全部冗余表达。我用一个生活化的类比来说你面前有一本 500 页的参考手册你不需要把它整本复印给同事只需要花十分钟翻一遍然后把关键流程、参数表和注意事项写成一页笔记交给对方。这个“翻一遍并做笔记”的动作就是光学压缩。原文还在但你交出去的是压缩后的信息。传统做法是把 PDF 里的文本流直接抽出来这种办法遇到扫描件、图片型 PDF、双栏排版、页眉页脚混杂的情况就基本失效。而光学压缩路线恰好绕开了这个痛点不管源文档是扫描件、网页截图还是表格图片只要我能把它变成一张清晰的图片OCR 模型就能处理。DeepSeek-OCR 在其中的角色就是那个“会做笔记的同事”——它能看懂构图、理解版面、识别文字并以 Markdown 这样的结构化格式输出。在实际使用中我一般把整个处理流程设计成三段式页面渲染、OCR 提取、LLM 整合。第一段把 PDF 转成图片第二段用 DeepSeek-OCR 把图片变成精简文本第三段把多页得到的精简文本拼装起来交给大模型。由于第二步已经去掉了大量页面装饰、重复段落和格式噪音LLM 面对的输入量往往只有原来的五分之一甚至十分之一这就给后续的问答、摘要和检索留下了充足的计算余量。1.3 DeepSeek-OCR 在整个链路里的准确定位很多人一听到 OCR第一反应是“不就是文字识别吗”觉得这技术已经很老了。但从我实际折腾下来的感受看传统 OCR 和 DeepSeek-OCR 之间的差距比想象中大得多。传统 OCR 解决的是“把图片里的文字变回字符串”这个单一任务它的输出结果通常是纯文本流没有段落结构、没有标题层级、没有表格关系。你把这种文本交给 LLM模型等于在看一坨没有标点的流水账理解效果自然打折。DeepSeek-OCR 这类新一代视觉语言 OCR 模型则把“看图片”和“理解文档”两件事揉在了一起。它不仅能识别字还能同时完成版面分析、阅读顺序排序、表格重组和结构化输出。最终给出来的不是一串裸文字而是一份保留了标题层级、列表嵌套、表格字段关系的 Markdown 文档。所以它在整个长文本处理链路里的定位是“信息前置压缩器”。它负责把笨重的原始文档转换成轻量、结构清晰的中间表示让 LLM 把宝贵的上下文空间留给真正需要推理的部分。如果你还在纠结怎么用 Prompt 让模型“忽略无关内容”那不如先把无关内容从源头上剪掉。2. 核心原理拆解DeepSeek-OCR 凭什么能做到高效率提取2.1 视觉编码与语言解码它先把图片“看”成特征再“说”成文字如果只看输入输出DeepSeek-OCR 干的事很朴素输入一张图片输出一段文字。但它的内部机制是典型的视觉语言模型结构而不是老式 OCR 那种“单字识别”的套路。我在一个模拟项目里试着分析过它的行为逻辑可以这样理解图片输入后会先经过视觉编码器把整张图切成一个个视觉块每个块变成一个特征向量保留位置信息、纹理信息、边缘信息。这些特征向量带着“我看到了什么”的语义被送到后面的语言解码器里。语言解码器做的事情不是逐字做模板匹配而是根据视觉特征和语言概率一起推断出最可能的文字序列。这个设计的聪明之处在于它把 OCR 问题变成了一个条件文本生成问题。模型不是在“认字”而是在“看图说话”。它能结合上下文判断一个模糊字符到底是“已”还是“己”能根据周围文字推断出一处被水印盖住的字大概率是什么。这种能力是传统识别方案不具备的。实操中的感受也很直接。我用它处理过手机拍摄的斜角照片、光线不均匀的文件扫描件、甚至是带褶皱的纸张照片都能得到相对稳定的结果。当然图片质量越差识别置信度越低但 DeepSeek-OCR 的容错空间明显比传统 OCR 大得多这也是视觉语言模型做 OCR 的核心优势。2.2 版面理解与结构化输出Markdown 不是装饰而是给 LLM 的“路标”DeepSeek-OCR 另一个让我觉得物超所值的点是它对版面结构的还原能力。传统 OCR 遇到双栏论文文字提取顺序经常乱掉左栏还没读完就跳到右栏遇到表格直接变成一行行没有分隔的字符串字段对应关系全丢。这些东西对 LLM 来说都是灾难性输入。而我实测 DeepSeek-OCR 时它对版面的处理分为几个层次先做区域检测识别哪些地方是正文、哪些是标题、哪些是图片、哪些是表格再做阅读顺序预测让文字按照人类阅读的自然顺序排列最后做结构重建把识别出的文本归纳成 Markdown标题套一级二级列表归纳成 bullet表格重新恢复成带表头的二维结构。这就给后续的逻辑链路带来两个直接好处。第一LLM 能更快定位关键信息因为标题和段落的层级关系会让长文本的语义骨架显式化。第二表格类信息不再是一坨废字模型可以直接按“行-列”去理解字段对应关系这在做合同比对、财报分析、问卷统计时非常关键。我自己做的一个实际对比实验同一份 20 页的双栏报告直接把 PDF 抽取文本交给 LLM 做摘要输出的要点经常抓错栏目先经过 DeepSeek-OCR 转成 Markdown再交给同一个 LLM摘要质量明显上升而且出错率降了一大截。原因很简单Markdown 等于给模型画了一条清晰的阅读路径它不需要自己在乱序文本里猜结构。2.3 多语言、图表、手写混合它到底扛不扛得住我在评估 OCR 模型时最看重的是混合场景下的表现。实际业务文档永远不可能是干净的纯印刷体更多时候是中文正文里夹英文术语、表格里带数字、页脚有手写批注。所以我很早就拿混合材料试过 DeepSeek-OCR。从效果看它对中文简体、中文繁体、英文以及多种常用拉丁字母类语言的支持都不错跨语言混排时的识别顺序也基本正确。中英文切换处不会出现串行行尾英文单词被正确切分标点符号的还原度也比较高。对于表格里的纯数字内容它也能保持字段位置不像一些旧模型会把数字串挤成一团。但要说完全没有短板那也不现实。手写内容仍然是难点尤其行书、连笔字识别正确率比印刷体明显下降。数学公式中的复杂上下标、积分符号、矩阵结构DeepSeek-OCR 可以部分识别但精确还原 LaTeX 级别的公式还有距离。彩色背景、艺术字体、水印叠字这类极端情况也会影响最终效果。这些问题不需要回避在工程化应用时是必须纳入预期的。3. 实操落地把 DeepSeek-OCR 接进 LLM 长文本处理管线3.1 部署准备本地加载还是走服务怎么选开始动手之前先解决跑在哪里的问题。DeepSeek-OCR 这类模型体积都不小如果只是偶尔处理几份文档完全可以走现成的推理服务如果经常大批量调用我建议本地部署可以省去不少按次计费的成本也方便在内部网络里做流水线。本地部署的核心依赖无非就是 PyTorch、Transformers 和对应的视觉语言模型组件。我用的模拟配置是 Python 3.10 环境、一张 12G 显存的显卡模型加载半精度版本后大概占 6 到 8G跑单页文档识别在可接受范围内。如果你没有显卡用纯 CPU 也能跑就是速度会慢一些更适合离线批量任务。装好环境之后我一般先跑一次最小化调用验证环境没问题再进入正式流程。这一步虽然简单却能在后面帮你省掉很多区分“是环境问题还是代码问题”的调试时间。3.2 最小化 OCR 调用一张图一段代码跑通全部逻辑这里分享一段我压箱底的最小可用代码。它对着一张本地图片调用 OCR 服务并输出 Markdown 格式的识别结果。基于我实际项目中的常见接入方式调整而成你可以把它当成脚手架import base64 import requests image_path page_01.png with open(image_path, rb) as f: image_bytes f.read() image_b64 base64.b64encode(image_bytes).decode(utf-8) resp requests.post( http://127.0.0.1:8000/v1/ocr, json{ image_base64: image_b64, language: auto, output_format: markdown, }, timeout120, ) if resp.status_code 200: data resp.json() print(data[text]) else: print(调用失败状态码, resp.status_code, resp.text)这段代码的核心逻辑很简单把图片转成 base64 传给服务指定格式为 Markdown拿到文本结果。我在实际项目里遇到过一次问题图片过大时会超出请求体限制所以通常会在传参前加一个压缩处理把图片长边限制在 2000 像素以内既能保证识别精度又能避免请求超时。另外如果你要处理的是 PDF需要先把 PDF 按页渲染成 PNG再用上面的逻辑逐页跑再把结果合并。3.3 接入 LLM从冗长 PDF 到精准问答的完整链路OCR 跑通之后真正的重头戏是把结果接入 LLM 处理链路。我以一次典型的“文档问答”为例给你看完整的处理思路。第一步先把 PDF 按页渲染成图片。这一步我习惯用 150 DPI 左右的清晰度太低了小字号会糊太高了图片体积大、传输慢。第二步逐页调用 DeepSeek-OCR得到每页的 Markdown 文本。第三步把多页 Markdown 合并成一个上下文块但要不要全量合并取决于文档长度。如果总共不到一万 token直接合并即可如果更多我会先按章节粗切再结合向量检索或关键词定位把最相关的段落挑出来。合并后的上下文给到 LLM 时我通常会在 Prompt 里加一句说明让它知道这份文本不是完整原文而是经过 OCR 提取的结构化版本避免它对缺失的页眉页脚产生困惑。这样做的好处非常明显模型的输入量小了注意力更集中回答的细节准确性明显提升。而且因为输出是 MarkdownLLM 能直接从表格字段中取数省去了原来那套反复让模型“从上文中找到对应行”的 Prompt 工程。4. 常见问题与排查我在实际跑 OCR 管线时踩过的坑4.1 识别错字、丢字、乱序先检查图片再怀疑模型我刚开始用 DeepSeek-OCR 时遇到最多的就是个别字识别错误尤其是中文里长得像“未”和“末”、“己”和“已”这类。起初我以为是模型问题后来仔细排查才发现大部分错字都出在图像质量不好的场景里。拍照抖动、光线阴影、字体太小都会让视觉特征混淆。所以我的第一条排查建议是先看原图。如果图片拍歪了先做透视矫正如果背景有阴影先用图像处理工具增强对比度如果字体太小就提高渲染分辨率。多数错字问题在图片预处理阶段就能解决完全不用换模型。如果你已经在处理高清扫描件但还是有文字错误那才是真的需要进一步确认模型版本或考虑在局部区域用更高分辨率重识别的阶段。另外多栏版面的乱序问题也很常见。如果 OCR 结果出现左右栏内容穿插优先检查图片是否被正确旋转很多扫描件带微小的倾斜角度会影响版面分析的结果。我做了一个很土但有效的预处理检测页面文字主体的整体倾斜角超过 0.5 度就先纠正一次再送入 OCR实测有效降低了乱序概率。4.2 显存不足和内存溢出批量任务最容易翻车的地方批量处理长文档时最容易翻车的不是识别精度而是资源耗尽。我印象里踩过一次最大的坑是一次性把 50 页 PDF 全部转成高分辨率大图然后循环提交 OCR。结果程序跑到第 30 页时显卡显存直接被打满进程崩溃。原因很简单我没控制图片批量处理速度和显存释放机制。后来我把方案改成“两两处理、用后即清”的节奏。每次只处理两页图片得到结果后立刻把图片和中间变量释放掉再处理下一页。如果还是紧张就在调用里显式指定使用半精度推理。对于离线大批量任务还可以用队列控制并发数比如同一时刻最多跑两个进程避免资源争抢。如果你在 CPU 环境下跑内存溢出也是常见问题。大图片转 base64 的过程本身就会占用大量内存我的做法是先用 Pillow 把图片缩放到合理尺寸再转编码处理完后主动释放变量。这些资源管理的意识甚至比模型选择本身更能决定项目成败。4.3 表格和公式识别不准针对场景做后处理修补表格识别是 DeepSeek-OCR 相对薄弱的环节尤其当表格跨度很大、单元格内文字很多时偶尔会出现列错位或字段错行。我这个领域的经验是如果文档里表格是核心信息载体最好在 OCR 输出之后加一个简单的后处理校验统计每行的分隔符数量检测是否存在明显的字段缺失再用固定规则或二次 Prompt 修正。公式识别就更依赖场景了。对于包含大量数学公式的理工科论文我会把 DeepSeek-OCR 输出中公式部分单独标记出来再用专门的公式识别组件去二次处理然后把结果重新插回 Markdown 里。这么做虽然多了一步但对最终质量提升很大。如果你处理的是社科类文档公式占比极低可以省掉这一步直接依赖 OCR 的原始输出也不会对最终 LLM 理解造成实质影响。4.4 实用排查速查表我把平时最常遇到的问题整理成了一张表放在这里方便你自查现象优先排查方向常用解决手段个别字识别错误图片清晰度、字体大小、背景干扰提升分辨率、增强对比度、局部重识别多栏顺序错乱图片倾斜、扫描方向透视矫正、旋转检测、重新渲染表格字段错位单元格长度、表格跨页增加后处理校验、列分隔符统计请求超时图片过大、并发过高压缩图片、控制并发、提高超时时间显存溢出批量任务资源未释放分页分批处理、用后即清、半精度推理公式识别一般模型本身能力边界单独抽出公式交给专用组件处理手写内容出错书写风格复杂降低预期、结合人工校对或辅助模型复核这张表是我在多次项目迭代里慢慢积累出来的能覆盖大多数常规问题。一旦你遇到表里面没有的情况我通常会建议先跑通最小化复现再逐层排查而不是一上来就去换模型或者改方案。5. 我的实操心得与扩展建议5.1 光学压缩什么时候用什么时候别硬用这里我想多说一点掏心窝子的话。光学压缩这个路线虽然效果好但它并不是所有场景的银弹。我最初也走过一段“所有文档都要过一遍 OCR”的弯路后来才慢慢摸清边界。如果文档本身就是纯文本 PDF文字层清晰完整那么直接用文本抽取会更便宜、更快。OCR 适合的是图片型 PDF、扫描件、复杂排版、混排非结构化内容。换句话说当传统方式提取不了或者提取质量太差时再上光学压缩。我的原则是先抽文本抽出来干净就直接用抽出来是乱码或者结构烂才考虑走 OCR 管线别一上来就把所有东西都转图片。另外一个需要想清楚的点是OCR 本身也是成这成本的。每一步多引入一个模型就多一份延迟和资源开销。所以在设计系统时我习惯把“是否需要 OCR”做成一个可配置的路由开关。比如用户上传 PDF先检测是否带文字层有就直接走纯文本通道没有再走渲染加 OCR。这样既兼顾了效率也保证了覆盖面。5.2 管线还可以怎么延展向量检索与多模态文档智能光学压缩做完之后得到的 Markdown 其实还可以做很多延展。我最常做的一件事是把这些结构化文本继续喂给 embedding 模型做主档向量化。因为文本已经被提炼过向量检索时命中的内容更聚焦回答质量比直接对原始超大文本切片要好。如果你要处理的是大量重复结构文档比如简历、合同、票据还可以考虑在 OCR 输出的 Markdown 上做字段抽取模板。比如先把不同版面的合同转成统一的 Markdown 模板再让 LLM 按模板抽取出“甲方、乙方、金额、条款编号”这样能极大提升结构化录入的效率。从更长远的角度看视觉语言模型的能力还在快速迭代未来 OCR 模型可能会直接理解图表语义输出更接近人类阅读笔记的结果。而“把复杂文档先变成精炼结构化信息再交给推理模型”这个思路不会变。它背后的原则其实是让每种模型做自己最擅长的那部分工作视觉模型负责看语言模型负责想。各司其职整个系统才能又快又稳。如果你手上正好有长文档问答或者文档解析的需求不妨按这个路线试一遍。先用 DeepSeek-OCR 把文档压成精炼的 Markdown再把 Markdown 交给 LLM你大概率会发现原来那些动不动就超时、答非所问的问题竟然安静了不少。这里唯一要提醒的是敢于动手做一次端到端的测试比读十篇解读文章都有用。 用DeepSeek-OCR做光学压缩，破解LLM长文本处理难题
1. 先搞清楚长文本处理到底卡在哪光学压缩能解决什么问题1.1 LLM 吃长文的三座大山我见过太多人做长文档问答第一反应就是把一份几十页的合同、论文或者产品手册直接塞进 Prompt让 LLM 一口气读完。这个方案在最简单的小样上确实能跑通但只要内容一多问题就一个接一个地冒出来。第一座大山是 token 成本。一页 A4 纸的正常排版纯文本大概有 500 到 800 个汉字但对大模型来说一页就对应 1500 到 2500 个 token如果再做字符级别的切分数字还会往上涨。一份 30 页的 PDF随随便便就是 5 万到 8 万 token。按现在主流模型的计费方式这还没开始干活光是把资料喂进去就已经花掉一大笔钱。第二座大山是上下文窗口的物理限制。现在不少模型对外宣传支持 128K、256K 甚至更长上下文但你真把十几万 token 一次性塞进去模型在生成时每一步都要重新计算注意力显存占用和响应延迟立刻失控。更麻烦的是很多号称支持超长上下文的模型实际在长文本中后段的召回准确率会肉眼可见地下降细节藏在第 8 页问答时就容易一本正经地胡说八道。第三座大山是“中间迷失”问题。注意力机制在处理超长序列时本质上对离当前位置越远的内容感知越弱。你让模型从第 1 页找到第 29 页的一句话它往往被中间大量的无关段落干扰最后给出一个模棱两可的答案。这个不是调 Prompt 能解决的而是架构层面的固有短板。正是因为这三座大山我开始留意“光学压缩”这条完全不同的路径。简单说就是不让 LLM 直接读原始文本而是先用 OCR 模型把文档内容做一次“精简提炼”只把最有价值的结构化信息交给 LLM。DeepSeek-OCR 就是这条路径里非常关键的一环。1.2 光学压缩的底层逻辑拍照速记而不是原文誊抄先解释一下“光学压缩”这个词。它并不是一个严格意义上的学术术语而是在工程圈里流传开的一种叫法。核心思路是把文本内容先渲染成图像再把图像交给 OCR 模型让模型用视觉理解的方式把页面上的信息提取成文本。整个过程相当于给信息做了一次“降维再还原”却不会保留原文档的全部冗余表达。我用一个生活化的类比来说你面前有一本 500 页的参考手册你不需要把它整本复印给同事只需要花十分钟翻一遍然后把关键流程、参数表和注意事项写成一页笔记交给对方。这个“翻一遍并做笔记”的动作就是光学压缩。原文还在但你交出去的是压缩后的信息。传统做法是把 PDF 里的文本流直接抽出来这种办法遇到扫描件、图片型 PDF、双栏排版、页眉页脚混杂的情况就基本失效。而光学压缩路线恰好绕开了这个痛点不管源文档是扫描件、网页截图还是表格图片只要我能把它变成一张清晰的图片OCR 模型就能处理。DeepSeek-OCR 在其中的角色就是那个“会做笔记的同事”——它能看懂构图、理解版面、识别文字并以 Markdown 这样的结构化格式输出。在实际使用中我一般把整个处理流程设计成三段式页面渲染、OCR 提取、LLM 整合。第一段把 PDF 转成图片第二段用 DeepSeek-OCR 把图片变成精简文本第三段把多页得到的精简文本拼装起来交给大模型。由于第二步已经去掉了大量页面装饰、重复段落和格式噪音LLM 面对的输入量往往只有原来的五分之一甚至十分之一这就给后续的问答、摘要和检索留下了充足的计算余量。1.3 DeepSeek-OCR 在整个链路里的准确定位很多人一听到 OCR第一反应是“不就是文字识别吗”觉得这技术已经很老了。但从我实际折腾下来的感受看传统 OCR 和 DeepSeek-OCR 之间的差距比想象中大得多。传统 OCR 解决的是“把图片里的文字变回字符串”这个单一任务它的输出结果通常是纯文本流没有段落结构、没有标题层级、没有表格关系。你把这种文本交给 LLM模型等于在看一坨没有标点的流水账理解效果自然打折。DeepSeek-OCR 这类新一代视觉语言 OCR 模型则把“看图片”和“理解文档”两件事揉在了一起。它不仅能识别字还能同时完成版面分析、阅读顺序排序、表格重组和结构化输出。最终给出来的不是一串裸文字而是一份保留了标题层级、列表嵌套、表格字段关系的 Markdown 文档。所以它在整个长文本处理链路里的定位是“信息前置压缩器”。它负责把笨重的原始文档转换成轻量、结构清晰的中间表示让 LLM 把宝贵的上下文空间留给真正需要推理的部分。如果你还在纠结怎么用 Prompt 让模型“忽略无关内容”那不如先把无关内容从源头上剪掉。2. 核心原理拆解DeepSeek-OCR 凭什么能做到高效率提取2.1 视觉编码与语言解码它先把图片“看”成特征再“说”成文字如果只看输入输出DeepSeek-OCR 干的事很朴素输入一张图片输出一段文字。但它的内部机制是典型的视觉语言模型结构而不是老式 OCR 那种“单字识别”的套路。我在一个模拟项目里试着分析过它的行为逻辑可以这样理解图片输入后会先经过视觉编码器把整张图切成一个个视觉块每个块变成一个特征向量保留位置信息、纹理信息、边缘信息。这些特征向量带着“我看到了什么”的语义被送到后面的语言解码器里。语言解码器做的事情不是逐字做模板匹配而是根据视觉特征和语言概率一起推断出最可能的文字序列。这个设计的聪明之处在于它把 OCR 问题变成了一个条件文本生成问题。模型不是在“认字”而是在“看图说话”。它能结合上下文判断一个模糊字符到底是“已”还是“己”能根据周围文字推断出一处被水印盖住的字大概率是什么。这种能力是传统识别方案不具备的。实操中的感受也很直接。我用它处理过手机拍摄的斜角照片、光线不均匀的文件扫描件、甚至是带褶皱的纸张照片都能得到相对稳定的结果。当然图片质量越差识别置信度越低但 DeepSeek-OCR 的容错空间明显比传统 OCR 大得多这也是视觉语言模型做 OCR 的核心优势。2.2 版面理解与结构化输出Markdown 不是装饰而是给 LLM 的“路标”DeepSeek-OCR 另一个让我觉得物超所值的点是它对版面结构的还原能力。传统 OCR 遇到双栏论文文字提取顺序经常乱掉左栏还没读完就跳到右栏遇到表格直接变成一行行没有分隔的字符串字段对应关系全丢。这些东西对 LLM 来说都是灾难性输入。而我实测 DeepSeek-OCR 时它对版面的处理分为几个层次先做区域检测识别哪些地方是正文、哪些是标题、哪些是图片、哪些是表格再做阅读顺序预测让文字按照人类阅读的自然顺序排列最后做结构重建把识别出的文本归纳成 Markdown标题套一级二级列表归纳成 bullet表格重新恢复成带表头的二维结构。这就给后续的逻辑链路带来两个直接好处。第一LLM 能更快定位关键信息因为标题和段落的层级关系会让长文本的语义骨架显式化。第二表格类信息不再是一坨废字模型可以直接按“行-列”去理解字段对应关系这在做合同比对、财报分析、问卷统计时非常关键。我自己做的一个实际对比实验同一份 20 页的双栏报告直接把 PDF 抽取文本交给 LLM 做摘要输出的要点经常抓错栏目先经过 DeepSeek-OCR 转成 Markdown再交给同一个 LLM摘要质量明显上升而且出错率降了一大截。原因很简单Markdown 等于给模型画了一条清晰的阅读路径它不需要自己在乱序文本里猜结构。2.3 多语言、图表、手写混合它到底扛不扛得住我在评估 OCR 模型时最看重的是混合场景下的表现。实际业务文档永远不可能是干净的纯印刷体更多时候是中文正文里夹英文术语、表格里带数字、页脚有手写批注。所以我很早就拿混合材料试过 DeepSeek-OCR。从效果看它对中文简体、中文繁体、英文以及多种常用拉丁字母类语言的支持都不错跨语言混排时的识别顺序也基本正确。中英文切换处不会出现串行行尾英文单词被正确切分标点符号的还原度也比较高。对于表格里的纯数字内容它也能保持字段位置不像一些旧模型会把数字串挤成一团。但要说完全没有短板那也不现实。手写内容仍然是难点尤其行书、连笔字识别正确率比印刷体明显下降。数学公式中的复杂上下标、积分符号、矩阵结构DeepSeek-OCR 可以部分识别但精确还原 LaTeX 级别的公式还有距离。彩色背景、艺术字体、水印叠字这类极端情况也会影响最终效果。这些问题不需要回避在工程化应用时是必须纳入预期的。3. 实操落地把 DeepSeek-OCR 接进 LLM 长文本处理管线3.1 部署准备本地加载还是走服务怎么选开始动手之前先解决跑在哪里的问题。DeepSeek-OCR 这类模型体积都不小如果只是偶尔处理几份文档完全可以走现成的推理服务如果经常大批量调用我建议本地部署可以省去不少按次计费的成本也方便在内部网络里做流水线。本地部署的核心依赖无非就是 PyTorch、Transformers 和对应的视觉语言模型组件。我用的模拟配置是 Python 3.10 环境、一张 12G 显存的显卡模型加载半精度版本后大概占 6 到 8G跑单页文档识别在可接受范围内。如果你没有显卡用纯 CPU 也能跑就是速度会慢一些更适合离线批量任务。装好环境之后我一般先跑一次最小化调用验证环境没问题再进入正式流程。这一步虽然简单却能在后面帮你省掉很多区分“是环境问题还是代码问题”的调试时间。3.2 最小化 OCR 调用一张图一段代码跑通全部逻辑这里分享一段我压箱底的最小可用代码。它对着一张本地图片调用 OCR 服务并输出 Markdown 格式的识别结果。基于我实际项目中的常见接入方式调整而成你可以把它当成脚手架import base64 import requests image_path page_01.png with open(image_path, rb) as f: image_bytes f.read() image_b64 base64.b64encode(image_bytes).decode(utf-8) resp requests.post( http://127.0.0.1:8000/v1/ocr, json{ image_base64: image_b64, language: auto, output_format: markdown, }, timeout120, ) if resp.status_code 200: data resp.json() print(data[text]) else: print(调用失败状态码, resp.status_code, resp.text)这段代码的核心逻辑很简单把图片转成 base64 传给服务指定格式为 Markdown拿到文本结果。我在实际项目里遇到过一次问题图片过大时会超出请求体限制所以通常会在传参前加一个压缩处理把图片长边限制在 2000 像素以内既能保证识别精度又能避免请求超时。另外如果你要处理的是 PDF需要先把 PDF 按页渲染成 PNG再用上面的逻辑逐页跑再把结果合并。3.3 接入 LLM从冗长 PDF 到精准问答的完整链路OCR 跑通之后真正的重头戏是把结果接入 LLM 处理链路。我以一次典型的“文档问答”为例给你看完整的处理思路。第一步先把 PDF 按页渲染成图片。这一步我习惯用 150 DPI 左右的清晰度太低了小字号会糊太高了图片体积大、传输慢。第二步逐页调用 DeepSeek-OCR得到每页的 Markdown 文本。第三步把多页 Markdown 合并成一个上下文块但要不要全量合并取决于文档长度。如果总共不到一万 token直接合并即可如果更多我会先按章节粗切再结合向量检索或关键词定位把最相关的段落挑出来。合并后的上下文给到 LLM 时我通常会在 Prompt 里加一句说明让它知道这份文本不是完整原文而是经过 OCR 提取的结构化版本避免它对缺失的页眉页脚产生困惑。这样做的好处非常明显模型的输入量小了注意力更集中回答的细节准确性明显提升。而且因为输出是 MarkdownLLM 能直接从表格字段中取数省去了原来那套反复让模型“从上文中找到对应行”的 Prompt 工程。4. 常见问题与排查我在实际跑 OCR 管线时踩过的坑4.1 识别错字、丢字、乱序先检查图片再怀疑模型我刚开始用 DeepSeek-OCR 时遇到最多的就是个别字识别错误尤其是中文里长得像“未”和“末”、“己”和“已”这类。起初我以为是模型问题后来仔细排查才发现大部分错字都出在图像质量不好的场景里。拍照抖动、光线阴影、字体太小都会让视觉特征混淆。所以我的第一条排查建议是先看原图。如果图片拍歪了先做透视矫正如果背景有阴影先用图像处理工具增强对比度如果字体太小就提高渲染分辨率。多数错字问题在图片预处理阶段就能解决完全不用换模型。如果你已经在处理高清扫描件但还是有文字错误那才是真的需要进一步确认模型版本或考虑在局部区域用更高分辨率重识别的阶段。另外多栏版面的乱序问题也很常见。如果 OCR 结果出现左右栏内容穿插优先检查图片是否被正确旋转很多扫描件带微小的倾斜角度会影响版面分析的结果。我做了一个很土但有效的预处理检测页面文字主体的整体倾斜角超过 0.5 度就先纠正一次再送入 OCR实测有效降低了乱序概率。4.2 显存不足和内存溢出批量任务最容易翻车的地方批量处理长文档时最容易翻车的不是识别精度而是资源耗尽。我印象里踩过一次最大的坑是一次性把 50 页 PDF 全部转成高分辨率大图然后循环提交 OCR。结果程序跑到第 30 页时显卡显存直接被打满进程崩溃。原因很简单我没控制图片批量处理速度和显存释放机制。后来我把方案改成“两两处理、用后即清”的节奏。每次只处理两页图片得到结果后立刻把图片和中间变量释放掉再处理下一页。如果还是紧张就在调用里显式指定使用半精度推理。对于离线大批量任务还可以用队列控制并发数比如同一时刻最多跑两个进程避免资源争抢。如果你在 CPU 环境下跑内存溢出也是常见问题。大图片转 base64 的过程本身就会占用大量内存我的做法是先用 Pillow 把图片缩放到合理尺寸再转编码处理完后主动释放变量。这些资源管理的意识甚至比模型选择本身更能决定项目成败。4.3 表格和公式识别不准针对场景做后处理修补表格识别是 DeepSeek-OCR 相对薄弱的环节尤其当表格跨度很大、单元格内文字很多时偶尔会出现列错位或字段错行。我这个领域的经验是如果文档里表格是核心信息载体最好在 OCR 输出之后加一个简单的后处理校验统计每行的分隔符数量检测是否存在明显的字段缺失再用固定规则或二次 Prompt 修正。公式识别就更依赖场景了。对于包含大量数学公式的理工科论文我会把 DeepSeek-OCR 输出中公式部分单独标记出来再用专门的公式识别组件去二次处理然后把结果重新插回 Markdown 里。这么做虽然多了一步但对最终质量提升很大。如果你处理的是社科类文档公式占比极低可以省掉这一步直接依赖 OCR 的原始输出也不会对最终 LLM 理解造成实质影响。4.4 实用排查速查表我把平时最常遇到的问题整理成了一张表放在这里方便你自查现象优先排查方向常用解决手段个别字识别错误图片清晰度、字体大小、背景干扰提升分辨率、增强对比度、局部重识别多栏顺序错乱图片倾斜、扫描方向透视矫正、旋转检测、重新渲染表格字段错位单元格长度、表格跨页增加后处理校验、列分隔符统计请求超时图片过大、并发过高压缩图片、控制并发、提高超时时间显存溢出批量任务资源未释放分页分批处理、用后即清、半精度推理公式识别一般模型本身能力边界单独抽出公式交给专用组件处理手写内容出错书写风格复杂降低预期、结合人工校对或辅助模型复核这张表是我在多次项目迭代里慢慢积累出来的能覆盖大多数常规问题。一旦你遇到表里面没有的情况我通常会建议先跑通最小化复现再逐层排查而不是一上来就去换模型或者改方案。5. 我的实操心得与扩展建议5.1 光学压缩什么时候用什么时候别硬用这里我想多说一点掏心窝子的话。光学压缩这个路线虽然效果好但它并不是所有场景的银弹。我最初也走过一段“所有文档都要过一遍 OCR”的弯路后来才慢慢摸清边界。如果文档本身就是纯文本 PDF文字层清晰完整那么直接用文本抽取会更便宜、更快。OCR 适合的是图片型 PDF、扫描件、复杂排版、混排非结构化内容。换句话说当传统方式提取不了或者提取质量太差时再上光学压缩。我的原则是先抽文本抽出来干净就直接用抽出来是乱码或者结构烂才考虑走 OCR 管线别一上来就把所有东西都转图片。另外一个需要想清楚的点是OCR 本身也是成这成本的。每一步多引入一个模型就多一份延迟和资源开销。所以在设计系统时我习惯把“是否需要 OCR”做成一个可配置的路由开关。比如用户上传 PDF先检测是否带文字层有就直接走纯文本通道没有再走渲染加 OCR。这样既兼顾了效率也保证了覆盖面。5.2 管线还可以怎么延展向量检索与多模态文档智能光学压缩做完之后得到的 Markdown 其实还可以做很多延展。我最常做的一件事是把这些结构化文本继续喂给 embedding 模型做主档向量化。因为文本已经被提炼过向量检索时命中的内容更聚焦回答质量比直接对原始超大文本切片要好。如果你要处理的是大量重复结构文档比如简历、合同、票据还可以考虑在 OCR 输出的 Markdown 上做字段抽取模板。比如先把不同版面的合同转成统一的 Markdown 模板再让 LLM 按模板抽取出“甲方、乙方、金额、条款编号”这样能极大提升结构化录入的效率。从更长远的角度看视觉语言模型的能力还在快速迭代未来 OCR 模型可能会直接理解图表语义输出更接近人类阅读笔记的结果。而“把复杂文档先变成精炼结构化信息再交给推理模型”这个思路不会变。它背后的原则其实是让每种模型做自己最擅长的那部分工作视觉模型负责看语言模型负责想。各司其职整个系统才能又快又稳。如果你手上正好有长文档问答或者文档解析的需求不妨按这个路线试一遍。先用 DeepSeek-OCR 把文档压成精炼的 Markdown再把 Markdown 交给 LLM你大概率会发现原来那些动不动就超时、答非所问的问题竟然安静了不少。这里唯一要提醒的是敢于动手做一次端到端的测试比读十篇解读文章都有用。