1. 为什么要把EasyOCR和LangChain放在同一个项目里如果你最近在做AI开发相关的图片处理大概率纠结过一个问题图片里的文字到底应该怎么提出来。我在一个模拟项目X里试过直接把图丢给多模态大模型也试过用EasyOCR提取后交给LangChain框架去整理最后留下的是后者。这篇就来完整拆解一下这个组合把EasyOCR图片文字提取从环境搭建到LangChain接入、再到批量落地的细节一次讲清楚。1.1 我遇到的真实场景去年我在整理一批存量业务截图时内容全是票据、对话记录和系统报错页人工录入实在熬人。一开始我图省事直接把图片丢给多模态大模型让它看图说话。结果很直观单张处理要等好几秒费用按张算成本很快就压不住了而且遇到密集小字的时候识别经常漏行输出格式还不稳定同一张图跑两遍给出来的字段都不一样。后来我换了个思路——先用EasyOCR把图片里的文字抠出来再交给LangChain去做整理、分类和结构化输出。这一换速度和准确率都实实在在提上来了。单张截图在普通办公本上处理基本在一两秒以内批量跑完还能留一份带置信度的原始识别结果哪一单出了问题直接回查不用对着黑盒模型猜原因。需要说明的是这绝不是EasyOCR比多模态模型更智能而是定位不同OCR干的是看见文字这件事多模态模型干的是理解内容这件事。把两步拆开每一步都用最顺手的工具整个链路反而更好控。这篇文章就把这个组合的落地过程完整写一遍环境、参数、接入LangChain的两种姿势、一个可跑的完整示例还有我踩过的几个坑。1.2 这条链路到底解决了什么问题很多人问既然已经有能直接读图的大模型为什么还要绕一圈我的理解是这个组合解决的不是能不能识别的问题而是成本、速度和可控性的问题。先说成本。批量场景里OCR是本地推理图片再多也只是吃机器资源不存在按张计费的问题。再说速度。EasyOCR在GPU下处理一张普通截图基本是毫秒到秒级比反复调大模型接口快得多。最后说可控性。OCR吐出来的是坐标加文本加置信度你可以按置信度过滤、按位置排序、按段落合并每一步都有原始数据可以核对。LangChain在这里承担的是编排角色。OCR只负责把文字提取出来至于这段文字是什么类型、里面哪些字段重要、要不要转成JSON这些是LangChain里的Prompt和链来定义的。换句话说EasyOCR提供原料LangChain提供加工线。在模拟项目X里这条加工线承担了字段提取、格式统一、去噪整理三件事原本需要人工逐条看的截图现在能自动归档成结构化的记录。1.3 技术选型为什么是EasyOCR而不是其他方案EasyOCR能成为这个项目的主力核心是三个点多语言、易用性和自由度。多语言不用多解释中文加英文混合的场景它默认就支持而且模型权重自动下载不用自己折腾训练数据。易用性体现在API设计上——几行代码就能跑通识别对做应用开发的人来说非常友好。自由度是我最看重的它能返回每个文字块的位置框和置信度这让我可以针对不同版式的图片做后处理而不是拿到一坨不可拆分的文本。当然EasyOCR不是银弹。遇到复杂表格、手写体、艺术字它的表现会明显下降这些场景可能需要更强的前处理或者换其他OCR方案。但在截图、票据、文档页这个范围内它的性价比很高。我最后定的方案就是EasyOCR负责提取LangChain负责把提取结果变成有用的东西。2. 环境准备装依赖和下载模型时的注意事项2.1 基础环境与安装命令老规矩先建一个干净的虚拟环境。我用的是Python 3.10太低版本的Python在部分依赖上会有编译问题太高版本也可能遇到个别轮子还没跟上。创建环境后直接安装三个包pip install easyocr pip install langchain pip install langchain-community langchain-openai这里有个细节easyocr会自动拉取torch和torchvision版本往往不是最新的如果机器上已经装了别的torch版本建议先确认一下版本兼容关系避免出现import error。如果之前在别的项目里装过torch可能会出现版本覆盖的情况我建议在独立环境里重装别图省事用全局环境。另外虽然langchain本体已经拆出了langchain-core这种分层结构但日常开发直接装langchain和社区包就够了用的时候按需从langchain_community或langchain_core导入。就拿Tool来说新版推荐从langchain_core.tools导入而不是老的langchain.tools代码更清晰以后升级也少踩坑。2.2 模型下载与缓存位置第一次调用Reader时EasyOCR会把对应语言的模型权重下载到本地缓存目录。默认位置在用户主目录下的.EasyOCR/model不同操作系统路径略有差异。这个行为对开发是省事的但对生产环境是个隐患——如果你的部署机器在网络受限的环境里跑第一次运行就会卡死在下载环节。我的习惯是在初始化Reader时显式指定两个参数reader easyocr.Reader( [ch_sim, en], gpuTrue, model_storage_directory./models/easyocr, download_enabledTrue )model_storage_directory把模型固定到项目目录方便随项目一起分发。download_enabled当成开关用开发环境保持True首次跑通后可以改成False避免每次启动都去检查网络。这个做法在模拟项目X的部署阶段帮我省了不少事模型文件直接打进镜像不用在运行时依赖外部资源。2.3 GPU与CPU的选择逻辑EasyOCR默认在可用时会用GPU但实际项目里不能只看有没有GPU还要看机器上有没有配套的CUDA环境。装了GPU版torch但驱动不对程序可能直接报错没装GPU版torch时即便有显卡也不会被用上只会在日志里看到一行提示告诉你用的是CPU。如果你的目标是跑通功能而不是追求极致速度CPU完全可以接受。我在一台普通办公本上测试单张1500像素宽的截图大约需要1到2秒这个速度对批量离线处理是够的。如果图片量大、要求实时再上GPU此时建议显存至少4GB否则遇到高分辨率大图也会吃紧。还有一个容易忽略的点GPU推理时显存占用和图片尺寸是强相关的一张三四千像素的长图可能直接把显存撑满后面我会说到怎么用canvas_size控制这个风险。3. EasyOCR提取文本的核心参数与调用方式3.1 Reader的初始化参数Reader构造函数的核心参数是两个数组和两个开关语言列表、gpu开关、模型目录、是否自动下载。语言列表的写法要特别注意顺序——[ch_sim, en]表示简体中文加英文如果只识别中文就只传[ch_sim]不要图省事把一堆语言全塞进去因为每多一种语言就会多拉几份模型文件内存占用也会跟着涨。我在项目里遇到过一个问题一开始为了兼容繁体场景语言列表写成了[ch_sim, ch_tra, en]结果Reader初始化时间从几秒涨到十几秒内存占用也高了不少。后来确认业务里根本没有繁体内容把ch_tra去掉一切恢复正常。这个经验就是语言列表按需最小化不要为了以防万一付出不必要的代价。3.2 单张图片识别的关键参数readtext是核心方法签名乍一看参数很多但真正常用的就几个result reader.readtext( sample.jpg, detail1, paragraphTrue, text_threshold0.7, low_text0.4, canvas_size2560, mag_ratio1.5 )detail1时返回结果是[坐标框, 文本, 置信度]的列表这是我最常用的模式因为后续要解析位置信息。paragraphTrue会把相邻的短文本行按阅读顺序合并成段落这个开关在处理票据上的说明文字时特别有用。text_threshold和low_text是一对互相关联的置信度阈值前者决定多像文字才认为是文字后者控制低置信度候选的保留力度默认值对大多数截图够用但遇到浅色文字或水印背景时适当调低low_text到0.3左右能救回不少漏掉的文字。canvas_size和mag_ratio是专门对付清晰度问题的。图片文字太小时默认的缩放可能识别不出来把mag_ratio调到1.5或2.0相当于模拟放大镜识别率提升明显代价是推理时间变长。canvas_size则限制了送入模型的图像最大边长超过会先做等比缩放防止大图把显存撑爆。这两个参数在批量场景里通常要配合着调不能只看单张效果。3.3 中文混合场景的参数建议中文和英文混排的截图是最常见的场景参数调整一般围绕两个方向。一是把上面的阈值参数配合使用避免只识别出英文而漏掉中文小字二是处理输出顺序。EasyOCR返回的文字块顺序是按照检测到的位置排序的多栏排版时经常出现跨栏乱序这时我发现先按每个文字块中心点的纵坐标排序、再按横坐标排序能有效恢复大部分阅读顺序。举一个具体的例子一张左右两栏的说明页EasyOCR默认可能先输出右栏上半部分再跳回左栏这种顺序交给LLM整理时语义会被打乱。我的处理是解析detail1返回的坐标框计算每个框的中心点用纵坐标做第一排序键、横坐标做第二排序键实测大部分版式都能恢复正常顺序。这个方法不复杂但效果立竿见影。另一个小细节如果同一张图里既有横排文字又有竖排文字EasyOCR对竖排的支持一般必要时得先把图片旋转90度再识别一遍。这个操作虽然笨但比训练模型省事。4. 把EasyOCR封装成LangChain可调用的组件4.1 用Tool包装OCR能力LangChain接入自定义能力最直接的方式是Tool。用装饰器写一个函数标明输入输出剩下的交给框架去处理。from langchain_core.tools import tool tool def extract_text_from_image(image_path: str) - str: 当用户提供图片路径或图片文件名时调用此工具提取其中的全部可见文字。 reader get_reader() results reader.readtext(image_path, detail1, paragraphTrue) lines [] for bbox, text, conf in results: if conf 0.5: lines.append(text) return \n.join(lines)这里有几个工程上的讲究。第一Reader不要每次调用都重新初始化模型加载很慢全局做一个懒加载的单例就够了。第二置信度过滤放在这里而不是放在上层能保证所有调用方拿到的都是干净文本。第三输入参数用image_path字符串而不是直接传二进制是因为LangChain的Agent在规划调用时更容易生成文件路径这种参数而不是一坨字节流。4.2 在链中编排OCR与LLM的处理流程Tool只是把OCR能力暴露给了LLM真正的编排发生在链或Agent里。我常用的模式是让模型先调用OCR工具拿到文本再根据任务要求整理输出。LangChain的老写法是initialize_agent加AgentExecutor新版本则更推荐直接写链把工具挂在模型上。如果你不需要Agent自主判断只是固定流程先OCR再整理那连Agent都可以不用。直接写一个链from langchain_core.prompts import ChatPromptTemplate prompt ChatPromptTemplate.from_messages([ (system, 你是信息整理助手。下面是OCR识别的原始文本请提取其中的关键字段。), (human, {raw_text}) ]) chain prompt | llm这种方式更可控、更省token因为模型不需要做要不要调工具的判断流程是死的。我做模拟项目X的初期用的是Agent结果发现模型偶尔会跳过OCR直接说我无法读取图片后来改成固定链这个问题就消失了。4.3 两种接入方式的适用场景对比我把两种方式的分界点总结成一句话流程固定用链流程不确定用Agent。固定场景比如一张票据进来必定要走提取→分类→转JSON三步直接串成链速度快、结果稳。不确定场景比如让模型面对一堆不同类型的图片自己判断哪些需要OCR、哪些不需要那就用Agent让它自己决定调用时机。我自己实践下来项目里80%的OCR需求其实都是固定流程真正需要Agent自主调工具的场景并不多。还有一点容易被忽略Tool的description写得好不好直接决定模型会不会用。我见过太多人随手写一句图片文字提取模型在关键场景下就是不调。我的经验是写成带使用条件的描述比如当用户提供图片路径或图片文件名时调用此工具提取其中的文字内容模型命中率会高很多。这个细节在调试Agent时能省掉不少时间。5. 完整示例图片票据内容自动归档5.1 数据准备与目标定义为了把上面的内容串起来我用模拟项目X做了一套完整的代码输入一张票据截图输出结构化档案包括日期、金额、项目名称、备注四个字段。这个例子的价值在于它不是一个玩具Demo而是真实流程的最小版本。OCR提取的原始文本往往包含大量无关信息比如页脚、页码、广告语整理成结构化字段恰好是LangChain最擅长的活。我这里用的是自己的测试图片你可以随便拿一张票据截图试逻辑是通用的。5.2 完整代码实现整个流程分三步初始化OCR、封装工具函数、组装链。import json import easyocr from langchain_core.tools import tool from langchain_core.prompts import ChatPromptTemplate _reader None def get_reader(): global _reader if _reader is None: _reader easyocr.Reader( [ch_sim, en], gpuTrue, model_storage_directory./models/easyocr, download_enabledTrue ) return _reader tool def extract_text_from_image(image_path: str) - str: 当用户提供图片路径时提取图片中的全部可见文字。 reader get_reader() results reader.readtext(image_path, detail1, paragraphTrue) lines [] for bbox, text, conf in results: if conf 0.5: lines.append(text) return \n.join(lines) prompt ChatPromptTemplate.from_messages([ (system, ( 你是票据归档助手。根据OCR提取的原始文本提取以下字段 日期、金额、项目名称、备注。 金额统一为数字格式日期统一为YYYY-MM-DD。 无法确定的字段填空字符串。 只输出JSON对象不要额外解释。 )), (human, 原始文本如下\n{raw_text}) ]) def archive_receipt(image_path: str, llm) - dict: raw_text extract_text_from_image.invoke({image_path: image_path}) chain prompt | llm response chain.invoke({raw_text: raw_text}) return json.loads(response.content)这块代码里extract_text_from_image.invoke这种调用方式是LangChain Tool的标准接口和直接在Agent里使用是同一套约定。llm参数换成任意一个兼容LangChain调用的大模型客户端实例即可接本地模型也好、云端接口也好只要能跑Prompt就行。5.3 运行效果与结构分析以一张常见的报销票据截图为例OCR提取出的原始文本可能是散乱的几行包括发票号码、开票日期、金额、商品名称等。经过链的整理得到的是类似这样的输出{date: 2024-06-18, amount: 286.50, item: 办公用品, note: }这个结果看着简单但背后有两层作用在叠加。OCR负责的是把文字从图像里捞出来即使捞出来的顺序是乱的、带噪音的都无所谓LLM负责的是理解并重新组织。如果OCR漏字导致金额缺了LLM并不能凭空补上——这也正是为什么我坚持保留置信度过滤而不是盲目把所有文本都交给模型。真正的项目里我会再加一层校验逻辑金额字段解析失败时把原始OCR文本和图片路径一起留给人工审核。6. 实战中绕不开的那些坑6.1 识别结果里的乱码和误识别最常见的乱码来源是字体差异。票据上的数字经常和字母混淆0和O、1和l、8和B这类错误几乎是OCR的通病。我的经验是不要指望模型完美要把纠错放在下游。对于金额这类关键字段在Prompt里明确要求只输出数字和小数点忽略单位再配合正则校验能把误识别的影响降到最低。另一个高发问题是水印和背景纹理。浅色水印文字很容易被当成正文提取出来污染后续的字段整理。处理办法是在OCR前做一步图像预处理把低对比度内容压掉或者直接提高text_threshold让模型少捡垃圾。我在做模拟项目X时就遇到过页脚水印混入备注字段的情况后来在函数里加了一个简单的黑名单过滤问题就解决了。6.2 性能瓶颈与批处理策略批量处理图片时最容易踩的坑是逐张调用Reader导致重复加载模型。正确的姿势是初始化一次Reader循环里只调readtext。还有一个容易被忽视的点readtext底层本身支持GPU批处理但如果你在for循环里一张张调批次大小始终是1完全发挥不出GPU的并行能力。我的做法是把图片路径收集成列表分批喂进去每批4到8张吞吐量能提升好几倍。代价是单批里如果有一张超大图内存会瞬间冲高所以批处理时最好先按图片尺寸排个序把大图单独处理。这里补充一句如果你是在Windows机器上跑注意readtext里的n_workers参数多线程在某些环境下会引发奇怪的崩溃设成0最稳。6.3 参数调优的经验清单最后整理一份我实际用下来比较顺手的参数起点方便直接抄作业场景关键参数推荐值说明普通截图text_threshold / low_text0.7 / 0.4默认值即可浅色小字low_text0.3多捞回低置信度文字清晰度不足mag_ratio1.5~2.0放大后识别率提升段落整理paragraphTrue把碎片行合并过滤噪音置信度过滤0.5以上在Tool层统一处理这里要特别提醒这些参数不是越高越好text_threshold调到0.9会漏掉大量正常文字mag_ratio调得太大推理时间成倍增加。我的做法是拿三张最有代表性的图片做基准调一版参数让这三张都达到预期再放回全量数据里验证而不是一开始就对着全部数据反复调。最后说个题外话。这个项目做完之后我把同样的套路用在了另外两个地方一个是对旧文档扫描件做检索另一个是把聊天截图批量转成工单记录。核心思路都一样——先用EasyOCR把图片翻译成文本再用LangChain把文本加工成业务数据。如果你正在纠结图片处理要不要上大模型我建议先算一笔账量有多大、要求的实时性有多高、误识别能不能接受。如果答案是量大、离线、可以接受少量人工复核那这个组合大概率是比直接用多模态更划算的方案。 
长河君 · 2026/10/21 13:05:16 · 阅读 1.2k EasyOCR+LangChain：图片文字提取结构化落地实战
1. 为什么要把EasyOCR和LangChain放在同一个项目里如果你最近在做AI开发相关的图片处理大概率纠结过一个问题图片里的文字到底应该怎么提出来。我在一个模拟项目X里试过直接把图丢给多模态大模型也试过用EasyOCR提取后交给LangChain框架去整理最后留下的是后者。这篇就来完整拆解一下这个组合把EasyOCR图片文字提取从环境搭建到LangChain接入、再到批量落地的细节一次讲清楚。1.1 我遇到的真实场景去年我在整理一批存量业务截图时内容全是票据、对话记录和系统报错页人工录入实在熬人。一开始我图省事直接把图片丢给多模态大模型让它看图说话。结果很直观单张处理要等好几秒费用按张算成本很快就压不住了而且遇到密集小字的时候识别经常漏行输出格式还不稳定同一张图跑两遍给出来的字段都不一样。后来我换了个思路——先用EasyOCR把图片里的文字抠出来再交给LangChain去做整理、分类和结构化输出。这一换速度和准确率都实实在在提上来了。单张截图在普通办公本上处理基本在一两秒以内批量跑完还能留一份带置信度的原始识别结果哪一单出了问题直接回查不用对着黑盒模型猜原因。需要说明的是这绝不是EasyOCR比多模态模型更智能而是定位不同OCR干的是看见文字这件事多模态模型干的是理解内容这件事。把两步拆开每一步都用最顺手的工具整个链路反而更好控。这篇文章就把这个组合的落地过程完整写一遍环境、参数、接入LangChain的两种姿势、一个可跑的完整示例还有我踩过的几个坑。1.2 这条链路到底解决了什么问题很多人问既然已经有能直接读图的大模型为什么还要绕一圈我的理解是这个组合解决的不是能不能识别的问题而是成本、速度和可控性的问题。先说成本。批量场景里OCR是本地推理图片再多也只是吃机器资源不存在按张计费的问题。再说速度。EasyOCR在GPU下处理一张普通截图基本是毫秒到秒级比反复调大模型接口快得多。最后说可控性。OCR吐出来的是坐标加文本加置信度你可以按置信度过滤、按位置排序、按段落合并每一步都有原始数据可以核对。LangChain在这里承担的是编排角色。OCR只负责把文字提取出来至于这段文字是什么类型、里面哪些字段重要、要不要转成JSON这些是LangChain里的Prompt和链来定义的。换句话说EasyOCR提供原料LangChain提供加工线。在模拟项目X里这条加工线承担了字段提取、格式统一、去噪整理三件事原本需要人工逐条看的截图现在能自动归档成结构化的记录。1.3 技术选型为什么是EasyOCR而不是其他方案EasyOCR能成为这个项目的主力核心是三个点多语言、易用性和自由度。多语言不用多解释中文加英文混合的场景它默认就支持而且模型权重自动下载不用自己折腾训练数据。易用性体现在API设计上——几行代码就能跑通识别对做应用开发的人来说非常友好。自由度是我最看重的它能返回每个文字块的位置框和置信度这让我可以针对不同版式的图片做后处理而不是拿到一坨不可拆分的文本。当然EasyOCR不是银弹。遇到复杂表格、手写体、艺术字它的表现会明显下降这些场景可能需要更强的前处理或者换其他OCR方案。但在截图、票据、文档页这个范围内它的性价比很高。我最后定的方案就是EasyOCR负责提取LangChain负责把提取结果变成有用的东西。2. 环境准备装依赖和下载模型时的注意事项2.1 基础环境与安装命令老规矩先建一个干净的虚拟环境。我用的是Python 3.10太低版本的Python在部分依赖上会有编译问题太高版本也可能遇到个别轮子还没跟上。创建环境后直接安装三个包pip install easyocr pip install langchain pip install langchain-community langchain-openai这里有个细节easyocr会自动拉取torch和torchvision版本往往不是最新的如果机器上已经装了别的torch版本建议先确认一下版本兼容关系避免出现import error。如果之前在别的项目里装过torch可能会出现版本覆盖的情况我建议在独立环境里重装别图省事用全局环境。另外虽然langchain本体已经拆出了langchain-core这种分层结构但日常开发直接装langchain和社区包就够了用的时候按需从langchain_community或langchain_core导入。就拿Tool来说新版推荐从langchain_core.tools导入而不是老的langchain.tools代码更清晰以后升级也少踩坑。2.2 模型下载与缓存位置第一次调用Reader时EasyOCR会把对应语言的模型权重下载到本地缓存目录。默认位置在用户主目录下的.EasyOCR/model不同操作系统路径略有差异。这个行为对开发是省事的但对生产环境是个隐患——如果你的部署机器在网络受限的环境里跑第一次运行就会卡死在下载环节。我的习惯是在初始化Reader时显式指定两个参数reader easyocr.Reader( [ch_sim, en], gpuTrue, model_storage_directory./models/easyocr, download_enabledTrue )model_storage_directory把模型固定到项目目录方便随项目一起分发。download_enabled当成开关用开发环境保持True首次跑通后可以改成False避免每次启动都去检查网络。这个做法在模拟项目X的部署阶段帮我省了不少事模型文件直接打进镜像不用在运行时依赖外部资源。2.3 GPU与CPU的选择逻辑EasyOCR默认在可用时会用GPU但实际项目里不能只看有没有GPU还要看机器上有没有配套的CUDA环境。装了GPU版torch但驱动不对程序可能直接报错没装GPU版torch时即便有显卡也不会被用上只会在日志里看到一行提示告诉你用的是CPU。如果你的目标是跑通功能而不是追求极致速度CPU完全可以接受。我在一台普通办公本上测试单张1500像素宽的截图大约需要1到2秒这个速度对批量离线处理是够的。如果图片量大、要求实时再上GPU此时建议显存至少4GB否则遇到高分辨率大图也会吃紧。还有一个容易忽略的点GPU推理时显存占用和图片尺寸是强相关的一张三四千像素的长图可能直接把显存撑满后面我会说到怎么用canvas_size控制这个风险。3. EasyOCR提取文本的核心参数与调用方式3.1 Reader的初始化参数Reader构造函数的核心参数是两个数组和两个开关语言列表、gpu开关、模型目录、是否自动下载。语言列表的写法要特别注意顺序——[ch_sim, en]表示简体中文加英文如果只识别中文就只传[ch_sim]不要图省事把一堆语言全塞进去因为每多一种语言就会多拉几份模型文件内存占用也会跟着涨。我在项目里遇到过一个问题一开始为了兼容繁体场景语言列表写成了[ch_sim, ch_tra, en]结果Reader初始化时间从几秒涨到十几秒内存占用也高了不少。后来确认业务里根本没有繁体内容把ch_tra去掉一切恢复正常。这个经验就是语言列表按需最小化不要为了以防万一付出不必要的代价。3.2 单张图片识别的关键参数readtext是核心方法签名乍一看参数很多但真正常用的就几个result reader.readtext( sample.jpg, detail1, paragraphTrue, text_threshold0.7, low_text0.4, canvas_size2560, mag_ratio1.5 )detail1时返回结果是[坐标框, 文本, 置信度]的列表这是我最常用的模式因为后续要解析位置信息。paragraphTrue会把相邻的短文本行按阅读顺序合并成段落这个开关在处理票据上的说明文字时特别有用。text_threshold和low_text是一对互相关联的置信度阈值前者决定多像文字才认为是文字后者控制低置信度候选的保留力度默认值对大多数截图够用但遇到浅色文字或水印背景时适当调低low_text到0.3左右能救回不少漏掉的文字。canvas_size和mag_ratio是专门对付清晰度问题的。图片文字太小时默认的缩放可能识别不出来把mag_ratio调到1.5或2.0相当于模拟放大镜识别率提升明显代价是推理时间变长。canvas_size则限制了送入模型的图像最大边长超过会先做等比缩放防止大图把显存撑爆。这两个参数在批量场景里通常要配合着调不能只看单张效果。3.3 中文混合场景的参数建议中文和英文混排的截图是最常见的场景参数调整一般围绕两个方向。一是把上面的阈值参数配合使用避免只识别出英文而漏掉中文小字二是处理输出顺序。EasyOCR返回的文字块顺序是按照检测到的位置排序的多栏排版时经常出现跨栏乱序这时我发现先按每个文字块中心点的纵坐标排序、再按横坐标排序能有效恢复大部分阅读顺序。举一个具体的例子一张左右两栏的说明页EasyOCR默认可能先输出右栏上半部分再跳回左栏这种顺序交给LLM整理时语义会被打乱。我的处理是解析detail1返回的坐标框计算每个框的中心点用纵坐标做第一排序键、横坐标做第二排序键实测大部分版式都能恢复正常顺序。这个方法不复杂但效果立竿见影。另一个小细节如果同一张图里既有横排文字又有竖排文字EasyOCR对竖排的支持一般必要时得先把图片旋转90度再识别一遍。这个操作虽然笨但比训练模型省事。4. 把EasyOCR封装成LangChain可调用的组件4.1 用Tool包装OCR能力LangChain接入自定义能力最直接的方式是Tool。用装饰器写一个函数标明输入输出剩下的交给框架去处理。from langchain_core.tools import tool tool def extract_text_from_image(image_path: str) - str: 当用户提供图片路径或图片文件名时调用此工具提取其中的全部可见文字。 reader get_reader() results reader.readtext(image_path, detail1, paragraphTrue) lines [] for bbox, text, conf in results: if conf 0.5: lines.append(text) return \n.join(lines)这里有几个工程上的讲究。第一Reader不要每次调用都重新初始化模型加载很慢全局做一个懒加载的单例就够了。第二置信度过滤放在这里而不是放在上层能保证所有调用方拿到的都是干净文本。第三输入参数用image_path字符串而不是直接传二进制是因为LangChain的Agent在规划调用时更容易生成文件路径这种参数而不是一坨字节流。4.2 在链中编排OCR与LLM的处理流程Tool只是把OCR能力暴露给了LLM真正的编排发生在链或Agent里。我常用的模式是让模型先调用OCR工具拿到文本再根据任务要求整理输出。LangChain的老写法是initialize_agent加AgentExecutor新版本则更推荐直接写链把工具挂在模型上。如果你不需要Agent自主判断只是固定流程先OCR再整理那连Agent都可以不用。直接写一个链from langchain_core.prompts import ChatPromptTemplate prompt ChatPromptTemplate.from_messages([ (system, 你是信息整理助手。下面是OCR识别的原始文本请提取其中的关键字段。), (human, {raw_text}) ]) chain prompt | llm这种方式更可控、更省token因为模型不需要做要不要调工具的判断流程是死的。我做模拟项目X的初期用的是Agent结果发现模型偶尔会跳过OCR直接说我无法读取图片后来改成固定链这个问题就消失了。4.3 两种接入方式的适用场景对比我把两种方式的分界点总结成一句话流程固定用链流程不确定用Agent。固定场景比如一张票据进来必定要走提取→分类→转JSON三步直接串成链速度快、结果稳。不确定场景比如让模型面对一堆不同类型的图片自己判断哪些需要OCR、哪些不需要那就用Agent让它自己决定调用时机。我自己实践下来项目里80%的OCR需求其实都是固定流程真正需要Agent自主调工具的场景并不多。还有一点容易被忽略Tool的description写得好不好直接决定模型会不会用。我见过太多人随手写一句图片文字提取模型在关键场景下就是不调。我的经验是写成带使用条件的描述比如当用户提供图片路径或图片文件名时调用此工具提取其中的文字内容模型命中率会高很多。这个细节在调试Agent时能省掉不少时间。5. 完整示例图片票据内容自动归档5.1 数据准备与目标定义为了把上面的内容串起来我用模拟项目X做了一套完整的代码输入一张票据截图输出结构化档案包括日期、金额、项目名称、备注四个字段。这个例子的价值在于它不是一个玩具Demo而是真实流程的最小版本。OCR提取的原始文本往往包含大量无关信息比如页脚、页码、广告语整理成结构化字段恰好是LangChain最擅长的活。我这里用的是自己的测试图片你可以随便拿一张票据截图试逻辑是通用的。5.2 完整代码实现整个流程分三步初始化OCR、封装工具函数、组装链。import json import easyocr from langchain_core.tools import tool from langchain_core.prompts import ChatPromptTemplate _reader None def get_reader(): global _reader if _reader is None: _reader easyocr.Reader( [ch_sim, en], gpuTrue, model_storage_directory./models/easyocr, download_enabledTrue ) return _reader tool def extract_text_from_image(image_path: str) - str: 当用户提供图片路径时提取图片中的全部可见文字。 reader get_reader() results reader.readtext(image_path, detail1, paragraphTrue) lines [] for bbox, text, conf in results: if conf 0.5: lines.append(text) return \n.join(lines) prompt ChatPromptTemplate.from_messages([ (system, ( 你是票据归档助手。根据OCR提取的原始文本提取以下字段 日期、金额、项目名称、备注。 金额统一为数字格式日期统一为YYYY-MM-DD。 无法确定的字段填空字符串。 只输出JSON对象不要额外解释。 )), (human, 原始文本如下\n{raw_text}) ]) def archive_receipt(image_path: str, llm) - dict: raw_text extract_text_from_image.invoke({image_path: image_path}) chain prompt | llm response chain.invoke({raw_text: raw_text}) return json.loads(response.content)这块代码里extract_text_from_image.invoke这种调用方式是LangChain Tool的标准接口和直接在Agent里使用是同一套约定。llm参数换成任意一个兼容LangChain调用的大模型客户端实例即可接本地模型也好、云端接口也好只要能跑Prompt就行。5.3 运行效果与结构分析以一张常见的报销票据截图为例OCR提取出的原始文本可能是散乱的几行包括发票号码、开票日期、金额、商品名称等。经过链的整理得到的是类似这样的输出{date: 2024-06-18, amount: 286.50, item: 办公用品, note: }这个结果看着简单但背后有两层作用在叠加。OCR负责的是把文字从图像里捞出来即使捞出来的顺序是乱的、带噪音的都无所谓LLM负责的是理解并重新组织。如果OCR漏字导致金额缺了LLM并不能凭空补上——这也正是为什么我坚持保留置信度过滤而不是盲目把所有文本都交给模型。真正的项目里我会再加一层校验逻辑金额字段解析失败时把原始OCR文本和图片路径一起留给人工审核。6. 实战中绕不开的那些坑6.1 识别结果里的乱码和误识别最常见的乱码来源是字体差异。票据上的数字经常和字母混淆0和O、1和l、8和B这类错误几乎是OCR的通病。我的经验是不要指望模型完美要把纠错放在下游。对于金额这类关键字段在Prompt里明确要求只输出数字和小数点忽略单位再配合正则校验能把误识别的影响降到最低。另一个高发问题是水印和背景纹理。浅色水印文字很容易被当成正文提取出来污染后续的字段整理。处理办法是在OCR前做一步图像预处理把低对比度内容压掉或者直接提高text_threshold让模型少捡垃圾。我在做模拟项目X时就遇到过页脚水印混入备注字段的情况后来在函数里加了一个简单的黑名单过滤问题就解决了。6.2 性能瓶颈与批处理策略批量处理图片时最容易踩的坑是逐张调用Reader导致重复加载模型。正确的姿势是初始化一次Reader循环里只调readtext。还有一个容易被忽视的点readtext底层本身支持GPU批处理但如果你在for循环里一张张调批次大小始终是1完全发挥不出GPU的并行能力。我的做法是把图片路径收集成列表分批喂进去每批4到8张吞吐量能提升好几倍。代价是单批里如果有一张超大图内存会瞬间冲高所以批处理时最好先按图片尺寸排个序把大图单独处理。这里补充一句如果你是在Windows机器上跑注意readtext里的n_workers参数多线程在某些环境下会引发奇怪的崩溃设成0最稳。6.3 参数调优的经验清单最后整理一份我实际用下来比较顺手的参数起点方便直接抄作业场景关键参数推荐值说明普通截图text_threshold / low_text0.7 / 0.4默认值即可浅色小字low_text0.3多捞回低置信度文字清晰度不足mag_ratio1.5~2.0放大后识别率提升段落整理paragraphTrue把碎片行合并过滤噪音置信度过滤0.5以上在Tool层统一处理这里要特别提醒这些参数不是越高越好text_threshold调到0.9会漏掉大量正常文字mag_ratio调得太大推理时间成倍增加。我的做法是拿三张最有代表性的图片做基准调一版参数让这三张都达到预期再放回全量数据里验证而不是一开始就对着全部数据反复调。最后说个题外话。这个项目做完之后我把同样的套路用在了另外两个地方一个是对旧文档扫描件做检索另一个是把聊天截图批量转成工单记录。核心思路都一样——先用EasyOCR把图片翻译成文本再用LangChain把文本加工成业务数据。如果你正在纠结图片处理要不要上大模型我建议先算一笔账量有多大、要求的实时性有多高、误识别能不能接受。如果答案是量大、离线、可以接受少量人工复核那这个组合大概率是比直接用多模态更划算的方案。