LangChain + EasyOCR 图片文字提取与结构化 JSON 输出实战

想做真正能落地的 AI 应用，绕不开一个听起来不起眼、但真上手会让人头大的环节——从图片里把文字抠出来。这活儿看着简单，实际做起来全是细节：图片清晰度不够、中英混排、表格错位、文字顺序乱，每一处都能让你改到怀疑人生。这篇文章我会直接用langchain框架 + EasyOCR搭一套完整的图片文字提取链路，重点不只是“识别出文字”，而是让大模型真正把文字用起来——比如一张报销单图片传进去，直接抽取出日期、金额、收款方，输出成结构化的 JSON。

内容适合正在做 Agent 应用开发的朋友、想在本地跑一套离线 OCR 工具链的工程师、以及做文档办公自动化场景、苦于多类型图片文本处理的小团队参考。我尽量把每一步的“为什么这样做”都讲清楚，看起来像是从一个真实项目复盘里整理出来的经验，而不是一份枯燥的接口文档。

1. 为什么是 EasyOCR + LangChain：选型思路拆解

1.1 OCR 工具横评：EasyOCR 凭什么入选

做 OCR 选型，市面上大致有四类路线：传统开源 OCR、国产深度 OCR 方案、云识别服务、以及 EasyOCR 这类轻量级本地库。我先用一张表把它们的差异拉出来看：

我之前做某个模拟项目时，一开始图省事，直接调了云识别服务，效果确实不错。但一聊到图片要上传、按调用量计费、部分业务环境又不允许图片出内网，这套方案立刻就卡住了。后来换成本地方案，对比了一圈，EasyOCR 的优势非常明确：

• 安装体验极其友好，pip install easyocr一行，不需要折腾系统级的图像库依赖；
• 多语言内置，['ch_sim', 'en']直接中英混排识别，不需要自己去训练模型；
• 支持 GPU 加速，也支持纯 CPU 跑，部署下限很低；
• 模型文件本地存放，图片完全不出主机，隐私这块天然占优。

当然它也有短板，比如对极复杂的表格结构还原不如专门做表格解析的方案，遇到手写体也偏弱。但如果不是要处理天生模糊的手写病历或复杂扫描表格，EasyOCR 在“快速、够用、可控”这个三角上，平衡得相当好。

1.2 LangChain 在这里到底有什么用

很多人看到标题会问：OCR 是 OCR，LangChain 是 LangChain，我直接调 EasyOCR 拿文本不就行了，为什么要扯上大模型框架？

这里的关键在于：OCR 只是把图片翻译成文字，真正的业务问题往往出在“识别完之后怎么处理”。一张报销单，OCR 能吐出“日期：2025-03-12”“金额：1280.00”“收款方：某供应商”，但如果你要做流程自动化，需要的是结构化 JSON，甚至要结合上下文判断哪些字段属于哪个行项目。这件事属于大模型的理解范畴。

LangChain 在这里扮演的角色，是把 EasyOCR 包装成 Agent 可调用的工具，然后让大模型在对话中按需调用它。你可以理解成：EasyOCR 是眼睛，负责把图像内容变成文字；大模型是大脑，负责理解意图、抽取字段；LangChain 是神经回路，负责让两者顺畅协作。它提供的@tool装饰器，本质上会把 Python 函数转成一个带 schema 描述的“工具协议”，大模型根据函数名和描述判断要不要调用、传什么参数。

我自己的体会是，这种组合的场景非常广。比如用户上传一张截图，问“这里面的重点是什么”；比如 RAG 项目里用户传的是图片型 PDF，得先把图片转成文本才能走后续的向量化；再比如客服系统收到一张快递单照片，需要自动把单号提取出来填单。只要输入不是纯文本，OCR 工具链几乎都是躲不掉的第一环。

2. 环境搭建与依赖安装：最容易被绕晕的一步

2.1 环境要求与依赖清单

先交代环境。我建议 Python 版本至少在 3.8 以上，3.10 或 3.11 更舒服，很多依赖对解释器版本有要求。Windows、Linux、macOS 都能跑，差别主要在于 GPU 支持和模型存储路径。

依赖安装我用这一条命令：

pip install easyocr langchain langchain-openai opencv-python pillow

逐个说下用途：

• easyocr：OCR 引擎本体，依赖torch，安装时会顺带拉进 CPU 版 PyTorch；
• langchain：核心框架，用来写工具链和 Agent 编排逻辑；
• langchain-openai：LangChain 的 OpenAI 兼容 SDK，实际使用中也可以换成你正在用的其他模型 SDK，接口思路一致；
• opencv-python：图片读取、缩放、灰度化、二值化这些预处理操作都靠它；
• pillow：处理图片格式转换和基础操作，opencv 对某些格式支持不全时能补位。

有一个版本坑我必须提前说：langchain从 0.1 到 0.2 再到 0.3，API 变动不算小，网上很多教程是旧版本写法。我自己使用时是锁版本装的，比如：

pip install "langchain>=0.2,<0.4" "langchain-core>=0.2,<0.4"

避免装到某个中间版本后@tool的导入路径变了导致一堆报错。如果你有现成项目依赖，建议先建一个干净的虚拟环境再装，不要直接在系统环境里混着搞。

安装完成后，可以用一段非常简单的代码验证环境是否正常：

import torch print("CUDA available:", torch.cuda.is_available())

如果输出False，也不用慌，EasyOCR 在 CPU 上照样能跑，只是速度慢一些，后面我会讲 GPU 折腾和降级方案。

2.2 首次模型下载与目录结构

第一次执行easyocr.Reader(['ch_sim', 'en'])时，它会自动下载检测模型和识别模型。这一步很多新手心态会崩，因为看起来像是卡死了，一动不动，其实是模型在后台下载。

模型默认放在用户目录下的.EasyOCR/model里：

C:/Users/你的用户名/.EasyOCR/model/ # Windows ~/.EasyOCR/model/ # Linux/macOS

下载完成后，里面一般会有这几个关键文件：

知道这个目录结构很重要。如果新的机器上有内网限制，无法直接下载模型，你可以把模型文件从别人机器上拷贝过去，放到同样的路径下，然后初始化Reader时设置download_enabled=False，就可以完全离线运行。具体代码我在第 5 章的排查部分会贴出来。

3. 从“能用”到“好用”：三版本代码拆解

3.1 入门版：三行代码跑通 OCR

先把最简单的代码跑通，建立信心：

import easyocr reader = easyocr.Reader(['ch_sim', 'en'], gpu=False) result = reader.readtext('sample_invoice.jpg', detail=1, paragraph=False)

readtext返回的是一个列表，每个元素长这样：

[ ( [[x1, y1], [x2, y2], [x3, y3], [x4, y4]], # 四个角坐标 '识别的文字内容', 0.982712 # 置信度，0~1 之间 ), ... ]

拿一张含“2025年3月12日”的测试票据运行，输出大致是：

[([[8, 16], [178, 16], [178, 36], [8, 36]], '2025年3月12日', 0.9864), ([[210, 16], [430, 16], [430, 36], [210, 36]], '报销单', 0.9932)]

这个阶段你只需要验证一件事：文字能不能被识别出来。如果连清晰印刷体都识别不准，先别继续往下做，优先检查图片质量和模型是否下载完整。

3.2 生产化封装：单例 Reader 和后处理

入门版代码能跑，但离“能用”还差两步。第一步是初始化慢的问题：easyocr.Reader()要加载模型权重、构建计算图，第一次初始化实测可能等十几秒甚至更久，如果每次调用都重新初始化，业务上完全没法接受。

我的处理方式是把 Reader 做成全局单例，用lru_cache包一层：

from functools import lru_cache import easyocr import torch @lru_cache(maxsize=1) def get_reader(): return easyocr.Reader(['ch_sim', 'en'], gpu=torch.cuda.is_available())

依赖包第一次加载完成之后，后续每次调用都会直接命中缓存，不会再重新初始化。

第二步是后处理。OCR 识别出来的文本顺序未必符合阅读顺序，尤其是版面复杂的图片。我会先把识别结果按坐标重排，再做拼接。坐标排序的原则是：先按 y 坐标从上到下分块，同一垂直区域内的文字再按 x 坐标从左到右。简单版可以这样：

def extract_text(image_path: str) -> str: reader = get_reader() result = reader.readtext(image_path, detail=1, paragraph=False) lines = [] for bbox, text, conf in result: if conf < 0.4: continue y_center = sum(p[1] for p in bbox) / 4.0 x_center = sum(p[0] for p in bbox) / 4.0 lines.append((y_center, x_center, text, conf)) lines.sort(key=lambda item: (round(item[0] / 20), item[1])) return "\n".join(text for _, _, text, _ in lines)

注意那个round(item[0] / 20)，它代表把高度在 20 像素范围内的文字视为同一行。这个阈值不是拍脑袋定的，图片分辨率不同阈值也要跟着调，否则要么把两行并成一行，要么一行被拆成两段。我在实际项目里通常会先打印出 bbox 坐标，观察行间距再定阈值。

3.3 用 LangChain 的@tool把它变成大模型能调用的工具

封装函数后，接入 LangChain 非常顺，用@tool装饰器：

from langchain_core.tools import tool @tool def extract_text_from_image(image_path: str) -> str: """从本地图片中提取所有可见文字，返回纯文本。 适用于报销单、名片、合同扫描件、快递单等图片场景。 入参必须是本地可访问的图片文件路径。""" text = extract_text(image_path) return text if text.strip() else "图片中未识别到明确文字，请确认图片是否清晰。"

这里有一个无数新手会忽略的细节：docstring 就是大模型的说明书。模型决定什么时候调用这个工具、传入什么参数，完全靠函数描述来判断。你如果写“图片文字提取”，信息量太少，大模型遇到“帮我看看这张图里写了什么”反而犹豫要不要调；把适用场景、入参要求、返回值写清楚，调用准确率会明显提升。

另外，函数名本身就是工具名，命名建议用动词开头，比如extract_text_from_image，一眼就知道干什么。入参的类型注解image_path: str也不能省，LangChain 会基于它生成参数 schema，如果漏了类型注解，模型可能传一个 dict 进来，工具层直接炸掉。

4. 完整实战：识别报销单并输出结构化 JSON

4.1 场景设计与链路结构

纸上谈兵没意思，我拿一个真实做过的模拟项目来演示完整链路：企业内部做了一个票据报销小工具，用户上传一张报销单图片，系统需要提取“发票号码、开票日期、金额、收款方”四个字段，并以 JSON 返回给上游业务系统。

链路分成三段：

1. 图片路径进入 OCR 工具，输出整张图的文字块，并清洗拼接；
2. 拼接后的文本作为上下文交给大模型，系统提示词里限定输出 schema；
3. 大模型返回结构化 JSON，落到业务系统。

整体结构用表格拉出来更清楚：

4.2 完整代码实现

先定义 OCR 工具，这部分直接复用上一章封装好的函数和@tool。接着创建大模型实例，我用的是 LangChain 官方 OpenAI 兼容 SDK：

import os from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate llm = ChatOpenAI( model="your-model-name", # 换成你实际使用的模型名 api_key=os.getenv("YOUR_API_KEY"), # 环境变量注入，不要写成明文 base_url="http://your-llm-endpoint", # 本地模型或兼容服务地址 temperature=0.1, )

如果你用的是本地模型，也可以换成对应的 LangChain 封装类，核心逻辑不变。

接着构造 System Prompt，这一步直接决定抽取质量：

prompt = ChatPromptTemplate.from_messages([ ( "system", "你是票据信息抽取助手。你只能根据用户提供的OCR识别文本回答问题，" "不要编造任何原文中不存在的字段。输出必须严格是JSON对象，" "包含且仅包含以下字段：invoice_no, invoice_date, amount, payee。" ), ( "human", "以下是OCR识别出的报销单文字：\n{context}\n\n" "请提取指定字段，并以JSON格式输出。" ), ])

最后把工具绑定到大模型上，直接调用，不需要开一个完整 Agent：

tools = [extract_text_from_image] llm_with_tools = llm.bind_tools(tools)

但这里有个关键设计：对于“先用 OCR 工具识别，再把识别结果喂给大模型抽取字段”的流程，更稳的做法是显式控制调用顺序，而不是让 Agent 自由发挥。因为 OCR 工具本身没有副作用，大模型完全有能力判断是否需要调用，但如果你已经知道业务一定需要 OCR 这一步，就不妨直接调用函数拿结果，再交给模型处理。这样省 token、省时间、还好调试。

所以我实际跑通的代码是这样的：

image_path = "path/to/reimbursement.jpg" ocr_text = extract_text_from_image.invoke({"image_path": image_path}) chain = prompt | llm_with_tools response = chain.invoke({"context": ocr_text}) print(response.content)

模型返回的内容就是 JSON 字符串，解析一下就可以落库：

import json data = json.loads(response.content) # {'invoice_no': '...', 'invoice_date': '2025-03-12', 'amount': '1280.00', 'payee': '某供应商'}

如果想要一定格式稳定的 JSON，可以在创建大模型时加上model_kwargs={"response_format": {"type": "json_object"}}，前提是你的模型服务端支持这个参数。支持的话强烈建议加上，能省掉大量解析异常。

4.3 识别效果优化：参数选择和预处理

整个流程跑通之后，真正花时间的是调参。readtext有几个参数我几乎每次都用：

遇到识别效果差，我的处理顺序是：

1. 先放大图片。cv2.resize把短边拉到至少 1000 像素以上，很多低分辨率图在放大后识别率明显提升；
2. 转灰度图，必要时再做一个二值化，把背景噪声去掉；
3. 处理旋转。拍照上传的图片经常带一点角度，直接设rotation_info，让 EasyOCR 多角度找文本，别自己在外面绕圈校正。

预处理代码很常见：

import cv2 def preprocess(image_path: str): img = cv2.imread(image_path) gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) gray = cv2.resize(gray, None, fx=2, fy=2, interpolation=cv2.INTER_CUBIC) _, binary = cv2.threshold(gray, 0, 255, cv2.THRESH_BINARY | cv2.THRESH_OTSU) return binary

这个优化思路适用于绝大多数“OCR 识别不对”的问题：先把图变清楚，再谈模型参数。

5. 复盘：我踩过的坑与排查手册

5.1 模型下载卡住：学会离线初始化

第一次跑 EasyOCR，初始化 Reader 时卡了十几分钟，不知道的人以为程序死循环了。其实就是模型在下载，但网络质量拉胯、没有进度条反馈，观感极差。

如果碰到网络受限，正确做法是手动准备模型文件。从一台已经能正常下载的机器上，把整个.EasyOCR/model目录拷贝到目标机器对应目录，然后初始化时关闭自动下载：

reader = easyocr.Reader(['ch_sim', 'en'], download_enabled=False)

这样就不会再去尝试访问网络，整个初始化流程稳定可控。拷贝的时候注意保留目录结构，特别是craft_mlt_25k.pth这类大文件，完整文件名和路径对不上就会加载失败。

5.2 装了 GPU 版 PyTorch 却用不了

这是个非常坑的场景：明明按照网上的教程装了 GPU 版 PyTorch，一跑 EasyOCR 还是 CPU 模式，或者直接警告 CUDA initialization failed。排查顺序我建议这样：

1. 先看物理层：运行nvidia-smi，确认显卡驱动能识别；
2. 再查 PyTorch 层：运行python -c "import torch; print(torch.cuda.is_available())"；
3. 如果第一步正常、第二步返回 False，基本就是 PyTorch 版本和驱动版本不匹配，需要重装对应 CUDA 版本的 PyTorch。

这里我给个经验：如果你的业务场景不是高清大图批量识别，CPU 跑 EasyOCR 完全能接受，一张普通发票识别时间也就一两秒。不用为了“必须用 GPU”这种心理包袱折腾半天。

5.3 OCR 文字顺序和预期不一致

我在前面提到了坐标排序，这里再展开讲为什么必须做。EasyOCR 默认按检测到的文本框方式返回结果，如果图片有多个区块，顺序经常不是阅读顺序。比如报销单里金额在右下角，日期在左上角，默认输出可能把金额排在前面，大模型抽取字段时一旦依赖顺序，容易字段错位。

我的排序代码里有一个巧点：先按round(y_center / 行高)分桶，再按x_center排序。这样做比单纯按 y 排序更稳，因为实际拍摄的图片，同一行的文字 y 坐标往往有抖动，直接排序会乱掉。你可以在自己的数据上调一下行高阈值，一般取图片高度的 2% 左右，效果不错。

5.4 图片质量差导致识别错乱

当时被一张拍照亮度不均的单据折磨过，EasyOCR 识别结果有大量乱码。后来用 5.1 里的那套预处理流程，先放大两倍、再灰度化、再 Otsu 二值化，识别准确率直接上了一个台阶。

还有一个小技巧：遇到文字带有阴影或者背景有底纹，可以先做一个形态学操作把噪声去掉，或者用cv2.fastNlMeansDenoisingColored做一下降噪。图片预处理没有银弹，但“放大 + 灰度 + 二值化”是最通用的一档，适用面极广。

5.5 LangChain 工具调用失败的几个原因

这套链路里，最容易出问题的不是 OCR，而是 LangChain 和模型之间的工具调用。我总结过几个常见原因：

工具描述这事我反复强调过，它直接决定大模型的行为。你可以做一个无本试验：把 docstring 改成“这个工具能获取图像信息”，模型调用率会显著下降；改成“当用户上传报销单、截图、名片等图片时，必须优先调用此工具提取文字再回答”，模型几乎每次都能命中。

6. 落盘后的几点个人体会与下一步扩展

这一整套方案做下来，我最满意的地方是“本地可控”。图片不用上传任何外部服务，模型文件都在自己机器上，数据隐私风险小，离线也能跑，对于一个内部工具来说这是压倒性的优势。开发体验上，EasyOCR 的安装和调用足够简单，LangChain 的工具化封装又是成熟的套路，两者组合的投资回报率很高。

做下来也有几点体会。一是 OCR 工具一定不要在大模型链路里放得太“自由”，Agent 自主调工具看起来炫酷，但生产环境里显式控制调用顺序会稳得多，调试和排错都容易。二是精度优化永远优先做在输入侧，把图片处理干净比在模型参数上折腾更有效，我在多个项目里反复验证过这一点。三是别迷信某一个参数是银弹，清晰图、模糊图、旋转图、表格图，场景不同，参数组合完全不同。

后续如果你想扩展，我可以给几个明确的方向：把整份扫描 PDF 按页转图片后批量提取文本，走 RAG 流程做文档问答；对输出的 OCR 文本做表格结构重建，把块状文本还原成行列；或者把抽取出来的结构化字段接一条人工复核的 Web 界面，做成半自动的票据录入系统。手写体识别和强旋转版面识别也有空间，但那已经是 EasyOCR 能力边界之外的事了，到时候大概率要换更重的方案。至少在这些场景里，这整套工具链作为第一版完全够用，而且能让业务先跑起来。