扫描件转文本：OCR如何为LLM构建可消费的上下文管道

整理历史资料时我常会遇到一种让LLM应用直接失效的场景PDF页面明明是扫描图片文字看起来清清楚楚但鼠标一滑复制不了CtrlC后粘贴出来的不是文字而是图片。把它直接交给大模型做摘要模型只会礼貌地告诉你无法从图片中读取文字。我最早以为这是模型能力不够后来发现问题出在一个更底层的位置这些文档里根本没有文本层LLM能消费的是token而token并没有进入它的视野。OCR It这类工具要补的正是这个缺口——pull text out of un-copyable documents for your LLM。这个标题值得拆开看不只是“识别文字”而是“把文字从不可复制的文档里拉出来交给你的大模型”。今天想从工程实践的角度聊聊为什么这个定位比单纯讨论OCR准确率更有价值以及真正要跑通一条“扫描件→LLM上下文”的链路时你会遇到哪些容易被忽略的问题。1. 大模型读不了不可复制的文档问题不在模型而在数据链路1.1 文档只要没有文本层LLM就相当于“失明”我们平时作为输入喂给LLM的必须是tokenize后的文本。模型不可能直接从扫描图片的像素里抽取信息。扫描件、纯图片、截图、老一辈的影印本甚至某些按图片形式保存的电子书都只有像素没有文本层。这种情况下不管上面的字有多清楚LLM都拿不到。这不是模型能力问题。任何一个纯文本LLM都无法从扫描图片本身读取文字除非你在前面接一个多模态模型。但多模态模型不等于OCR工具它更适合理解图像语义但要抽取一段稳定、完整、带结构的文本仍然需要OCR层。这就像你让一个阅读能力很强的人去读一份被密封在玻璃罩里的文件。他看得见却拿不到纸。问题不在阅读能力而在“纸”没有传递到他手上。1.2 为什么“复制粘贴”不是答案很多人会想那我把扫描件里的文字手工敲一遍不就行了少量文档可以但一旦进入批量场景成本就上来了。更麻烦的是这种方法几乎不可能成为可复用流程。你这次敲完下次还有100份你交给别人别人无法复现你的操作也无法判断你漏了哪一段。还有一种情况是PDF本身以图片形式保存或者有文本保护限制。如果使用场景合法通过OCR把文本抽取出来再处理往往是更稳妥、可自动化的方式。但要注意如果涉及权限或合规边界必须先确认自己有权处理这些文档。这类问题我不展开只强调一点工具只是管道使用场景和权限是使用者自己的责任。1.3 OCR It真正要解决的是“可消费性”而不是“识别率”项目标题里有两个关键词un-copyable documents和for your LLM。把这两个词放在一起说明它不再是传统意义上的“文字识别工具”而更像是“LLM数据准备管道”。它关心的不是这一页识别对了几个字而是输出的文本是否能直接作为LLM的上下文、进入RAG知识库、或者作为Agent任务的输入。所以我对这类工具的评价标准排在准确率前面的是三件事输入是否稳定、输出是否干净、流程是否可复用。准确率固然重要但最终效果取决于整条数据链路而不是某个算法。2. 选型OCR工具时四个比准确率更重要的判断维度2.1 输出格式是否站在“下一步”的角度设计传统OCR通常会返回纯文本字符串这看起来够用但喂给LLM之前你还得处理一堆问题断行、分页、表格错位、页眉页脚噪声。更好的做法是输出带位置、带层级、带段落结构的JSON或Markdown这样下游可以按需裁剪。OCR It这类项目的价值往往不在于重新发明识别算法而在于把识别引擎的输出做一次“再包装”清洗断行、去掉页眉、把表格转成结构化格式。这个再包装环节决定了LLM拿到的是“毛坯”还是“精装”。2.2 可编程性和自动化能力一个小工具如果只能通过图形界面一次处理一张图它就无法嵌入流水线。落地时我一般会优先看三样东西有没有命令行入口、有没有Python SDK或HTTP接口、能不能自定义输出目录和日志。只有这些能力齐全你才有机会把它做成批处理管道的一部分。很多开源OCR引擎都提供了命令行工具比如网上常见的Tesseract。但要注意命令行可用并不代表自动化简单。你还得处理文件编码、语言包、临时文件、并发控制这些才是实际工作量的大头。2.3 部署边界和数据隐私有一类场景特别容易踩坑把公司内部合同、病历、技术图纸上传到云端OCR服务虽然识别效果好但数据出了内网。如果下游LLM又是外部API相当于两条链路都在外送数据。所以在做选型前要先回答三个问题文档内容是否敏感处理过程是否允许离开本地LLM本身是本地部署还是API调用如果三个环节都有隐私要求建议优先考虑本地OCR引擎或端侧私有化模型。比如在RK3588这类边缘设备上部署OCR模型搜索里经常有人问类似问题其实很多端侧推理方案可以做但需要先确认模型大小、推理速度和开发板资源。2.4 成本与批量扩展OCR的边际成本不能只看单张费用。对于本地引擎主要成本是机器时间和运维对于云服务主要成本是调用量和并发额度对于私有化模型主要成本是初期模型适配和硬件投入。一个实用的建议先用几十张代表性页面同时跑几种路线记录准确率、耗时、费用和“下游LLM是否需要额外清洗”。很多情况下准确率最高和实际效果最好并不一致因为清洗成本可能把高准确率带来的收益吃掉了。2.5 常见路线对比用一张表把几条典型路线列出来可以帮助你快速定位路线输出特点自动化难度隐私边界典型成本本地开源引擎纯文本/hOCR表格较弱中文件不出本地低成本云OCR服务JSON/文本版式较完整低数据会上云按量计费端侧私有化模型文本/坐标可定制中高本地推理前期适配时间OCR为LLM准备的数据管道清洗后的文本/Markdown/JSON中高取决于后端后期维护成本选择时先看文档类型和数据边界再谈识别精度。3. 跑通一条最小可用的“扫描件→LLM上下文”流水线3.1 输入先行扫描分辨率不要低于300 DPI很多人一拿到扫描件就急着调OCR参数结果识别出来乱码一片。其实很多时候问题在输入质量。对印刷体文档扫描时分辨率最好保持在300 DPI以上低于150 DPI的小字号内容识别率会明显下降。如果手头只有PDF可以先看PDF本身是否是扫描版。可以用命令行或工具把页面导出为PNG或JPEG。导出时注意不要重复压缩尽量保持原始清晰度。3.2 图像预处理旋转、裁剪、灰度化OCR对图像方向很敏感。页面歪斜几度识别结果就可能错位。所以第一步是先做方向检测把歪斜的页面转正然后做裁剪、去边缘、灰度化。彩色信息对印刷体识别帮助有限反而会增加计算量。二值化也是一个常用步骤把灰度图变成黑白。但要注意不是所有内容都适合直接二值化如果背景有噪声反而会破坏字符。我一般会先保留灰度输出只在测试后决定是否需要二值化。3.3 OCR识别一个可跑的示例下面是一个用Python配合常见OCR引擎的最小流程结构上可以作为参考。不同环境下需要先安装Tesseract OCR引擎和中文语言包Python侧再安装Pillow和pytesseract。from PIL import Image import pytesseract # 打开扫描页并转灰度 image Image.open(sample_page.png).convert(L) # 设置语言中文英文识别模式用psm 6区块识别 text pytesseract.image_to_string( image, langchi_simeng, config--psm 6 ) print(text)这里有几个点值得解释langchi_simeng表示简体中文和英文混排--psm 6表示把整页当作一个均匀文本块适合普通文字页面。如果是多栏排版可能要试--psm 3或--psm 4。参数不是固定的你应该根据自己的页面版式做几组对照。3.4 清洗文本这一步直接决定LLM的效果OCR输出的原始文本通常不能直接用。常见问题包括不该出现的换行在句中被截断、页眉页脚重复出现、表格内容变成无结构顺排、字符“0”和“O”混用。清洗任务是把这些噪声去掉同时尽量保留章节结构。一个通用处理顺序是去掉页眉页脚和页码。把“软换行”合并成完整段落。根据关键词或行首缩进识别一级/二级标题。表格部分用制表符或Markdown表格重排。最后保存为带有清晰结构的纯文本或Markdown。这一步需要大量样例来调规则。不要追求一次写对而是把规则做成可配置、可回滚的脚本。3.5 投喂LLM直接给文本还是先进入RAG清洗后的文本可以交给LLM做摘要、结构化提取也可以先切成chunk再进入向量数据库做RAG。这两种方式对文本质量要求不同直接做摘要要求前几千字信息密度高不要给一长串噪声做RAG则要求每个chunk语义完整不要切在句子中间。以下是常见调用方式以兼容Chat Completions接口的服务为例import requests BASE_URL http://your-llm-endpoint API_KEY your-key MODEL_NAME your-model resp requests.post( f{BASE_URL}/v1/chat/completions, headers{Authorization: fBearer {API_KEY}}, json{ model: MODEL_NAME, messages: [ {role: user, content: 请对下面的资料做结构化摘要\n\n cleaned_text[:4000]} ] } ) print(resp.json()[choices][0][message][content])实际使用中BASE_URL、API_KEY、MODEL_NAME都需要替换成你自己的配置如果是本地模型也要保证服务地址可从当前机器访问。注意控制文本长度一次性把整本扫描书喂进去并不可取。4. 从单次跑通到批量处理先补四块工程拼图4.1 文件队列与失败重试单页跑通只是起点。一旦进入几十上百个文件你第一件要做的事就是把任务变成“可失败、可重跑”的队列。不要用一个脚本写死路径而是定义好输入目录、处理状态、输出目录让每一页可以单独重跑。失败重试要区分两类一类是OCR自身偶发识别失败另一类是文件损坏或路径不存在。前一种可以自动重试后一种应该记录下来人工介入。如果不区分程序会反复尝试毫无意义的重试。4.2 日志与质量抽检批量处理最怕的是“没有一份报告”。结束后你只知道处理完了但不知道哪些页面识别差、哪些清洗规则把正文删了。所以日志要记录三个层级每页是否成功、识别置信度或字符数是否异常、清洗时触发过哪些规则。抽检时再配一个简单页面直接定位异常页。很多问题的定位靠的不是看代码而是看中间产物。建议每个处理阶段都保留一个中间文件原图、预处理图、OCR原始文本、清洗后文本。这样一旦下游LLM结果不对你可以反向排查是识别错了还是清洗把内容删了。4.3 输出规范和版本固化输出文件的命名应从输入页名推导同时保留输入来源。比如page_001.md、page_001.json、page_001.error.txt。还要保存处理参数比如使用的OCR引擎、语言包、PSM、清洗开关。这样以后换了新版本引擎或改了参数可以对比之前的结果。这一套规范虽然不是功能但它决定了后续能不能长期维护。很多人离开项目三个月后回来看代码不知道当时的输出是怎么生成的就是因为缺少版本记录。4.4 不要一次跑全量先建立小样本基准批量操作前建议先抽5到10页代表性页面包含普通正文、表格、标题、页眉页脚手工标记一份正确文本。用这条小样本跑完整流程记录三项指标字符级准确率、清洁度也就是是否还有明显噪声、下游LLM效果比如摘要是否偏离原文。调整参数直到小样本稳定再扩大到全量。这里有一个可以长期使用的框架小样本基准集参数快照输出复核。先跑通再固化最后才谈自动化。如果团队里有人想优化OCR参数可以用基准集对比而不是各说各话。注意不要一上来就把批量数和并发数拉满。先用一条样例确认输入、输出和日志都正常否则后面排查成本会成倍上升。5. 常见问题排查从乱码、表格错位到LLM摘要不准5.1 现象识别结果全是乱码先别怀疑模型不行。按这个顺序排查输入图片是否过小或分辨率太低。页面是否旋转或歪斜。语言包是否匹配中英文是否混排。OCR参数中的--psm是否适合当前版式。图片是否用了过重的压缩。通常乱码主要来自前两个原因。把分辨率提高到300 DPI并做旋转校正大部分问题能解决。5.2 现象表格和版式错乱普通OCR引擎对复杂表格支持较弱。如果表格被识别成一串连续字符你需要考虑两种方案一是改用带表格提取能力的引擎二是把表格区域先裁剪出来单独识别再按坐标映射回原位置。清洗阶段如果发现表格列对齐不对可以查一下原始输出是否保留了制表符或空格。有时候是清洗规则把空白字符合并得太激进了表格结构反而被破坏。5.3 现象批量任务慢或卡住速度问题先确认资源瓶颈单线程、CPU占用、内存、是否每页都在重新加载语言包。可以尝试把语言模型预加载或者做多线程并发。但并发数不要一上来拉得很高先测一个并发量观察内存和错误率。如果任务卡住检查是不是文件本身损坏或者某些页分辨率过大导致内存溢出。通常把异常页单独放一个目录不要让它们阻塞整个队列。5.4 现象LLM基于OCR文本给出的摘要不靠谱问题可能不是LLM而是OCR文本里有隐藏噪声。比如识别了错误的年份、删除了关键表格、把“0”识别成“O”这些都可能让摘要产生偏差。有一个很有效的验证方法把OCR文本跟原始图片并排展示人工抽查20%的页面。如果抽查发现关键信息错误率高就需要回到OCR层或清洗层修复而不是只改Prompt。再补一点投喂给LLM的内容如果太长摘要容易丢失局部信息。更稳妥的做法是先按章节切分分段提取关键事实再合并做最终摘要。5.5 通用排查链路面对任何“OCR结果不好”的问题我建议按这个链路走输入质量→图像预处理→OCR参数→清洗规则→下游调用。每一步都留下日志和中间产物这样你能快速定位是哪一层出了问题。不要一上来就频繁换OCR引擎很多问题换引擎也解决不了因为根源在输入或清洗不在识别。提示如果问题只在少数几页出现优先排查输入图像本身是否清晰、有没有污损不要为异常页单独开发一整套规则。工程上稳定覆盖80%的页面比在少数页上追求100%更现实。6. 这类方案到底适合谁又不适合谁6.1 适合的三种场景第一种是历史纸质资料的数字化。扫描件、影印本、老书没有文本层OCR It这类工具可以把它们变成可检索的语料再交给LLM做问答或综述。这里的价值不是“更快识别”而是让过去不可搜索的资料变得可搜索。第二种是给RAG系统补数据。企业内部有大量展示型PPT、合同扫描件、产品手册这些内容没法直接嵌入。先抽取文本再切块、向量化才能进入知识库。很多RAG项目试了半天效果不佳回头一看是原始文档根本没有进入文本管线。第三种是跨软件的信息流。有一些文档虽然在屏幕上可以显示但复制不出来比如某些阅读器里限制复制的PDF。如果使用场景合法一个可编程的OCR管道能把它拉取为文本然后自动喂给下游模型。关键是有编程接口能嵌入自动化。6.2 不建议硬刚的场景如果文档是高度复杂的排版比如彩色杂志、艺术字体、手写批注密集、多栏混排通用OCR的效果会明显下降。这时需要专门训练模型或者让多模态大模型辅助理解而不是只用通用OCR管道跑流水线。如果只是偶尔需要识别一两张图片也没有必要搭建全套流程。一个图形化小工具可能更快。要清楚OCR It这类方案的价值在规模和复用它适合频繁、重复、需要稳定的场景。为了两个PDF搭一套服务成本并不划算。6.3 从脚本升级成数据管道的长期思路我见过不少项目最初只是一段Python脚本跑完一批文件就堆在硬盘里。真正长期使用的团队会把它做成有输入、有状态、有输出的数据管道并且定期用基准集回归测试。每次升级OCR引擎或清洗规则都能看见指标变化而不是凭感觉觉得“效果好了一些”。这些听起来不是新东西但“for your LLM”这个定位加进来后事情就不一样了。你不仅是在识别文字你是在为模型准备上下文。上下文的质量直接决定了模型输出的上限。OCR这层做得不够后面加多少Prompt技巧都很难弥补。建议找一个长期维护的文件夹每次处理结果都附带“参数快照抽样复核已知问题”。三个月后再回来看你会感谢当时的记录习惯。结尾所以我一直提醒自己对待“OCR It”这类工具不要把注意力只放在“识别率”上。把一张扫描件变成一段干净、稳定、可复用的文本让LLM真正读得进去这才是核心。如果你现在手头正好有一批不可复制的文档我的建议是先选3到5张代表性页面手工标记一段满意文本然后跑一遍最小流程看看差距在哪里。这一步做完你会比讨论一百个工具参数都更有数。