“OCR It”这个名字从功能上讲很直白把那些不能复制、不能搜索、只能靠截图保存的文字从文档里“抠”出来变成大语言模型真正能吃进去的文本。实际做 LLM 应用的人应该都有体会卡住整个流程的往往不是模型能力而是数据入口——扫描版 PDF、图片型文档、网页预览、网盘转存之后的不可复制文件这些材料直接丢给 LLM 是没有任何意义的必须先做 OCR 文本提取。我这次就以 OCR It 为切入点把一个完整可落地的方案拆开讲OCR It 定位是什么、解决什么问题、部署在哪一层以及如何在本地完成环境准备、启动服务、功能测试、API 调用和批量任务。文章里会用一套通用的 OCR LLM 文档处理流程来演示因为实际项目中很多工具都是类似架构学会一条链路后面换具体引擎也不会慌。如果你正在做 RAG、文档问答、LLM Agent 工具调用或者只是被“复制不了”的 PDF 折磨过这篇文章可以直接收藏。1. 核心能力速览项目定位面向 LLM 的文档文本提取工具把不可复制的文档转换为文本核心功能扫描件/PDF/图片中的文字识别、Markdown/JSON/纯文本导出、批量处理部署方式本地命令行、Docker、API 服务具体以项目实现为准推理方式支持 CPU 推理部分实现可切换 GPU/ONNX 加速需按实际版本确认显存占用视 OCR 引擎而定需按实际模型和图片分辨率测试输出格式纯文本、JSON、Markdown 等结构化文本与 LLM 的衔接输出文本可直接用于 RAG 索引、LLM 上下文注入、Agent 工具返回结果API 能力一般会提供 HTTP 接口具体路径和参数需看项目文档批量任务支持目录级批量识别配合脚本可做失败重试和任务队列适合读者LLM 应用开发者、RAG 知识库构建者、文档处理自动化工程师先确认一个大前提OCR It 这类工具重点不是“把图片转文字”这一个动作而是解决“从文档到 LLM 可用输入”的完整链路。所以你在评估它的时候不要只看单张识别准不准还要看导出格式是否方便后续程序读取、API 是否好接入、批量处理是否稳定。这几个维度才是决定它能不能进生产流程的关键。需要说明的是具体到某个版本的 OCR It它底层用的是什么 OCR 引擎、模型文件放在哪里、API 路径怎么写都要以项目 README 和实际安装包为准。下面给出的环境准备、启动命令、接口示例都是通用模板关键在于把思路跑通。2. 适用场景与使用边界OCR It 最适合的场景有几类RAG 知识库的文档预处理环节。把扫描版 PDF、图片型文档先转成文本再切分和向量化这样检索质量才稳定。LLM Agent 或自动化工作流里的“文档读取工具”。代理需要读取用户上传的图片或 PDF 内容时OCR 接口是必要的工具类型。批量资料归档。合同、票据、论文、内部通告这类以扫描件为主的文档需要统一转成可搜索文本。无法直接复制文本的场景。比如某些阅读器、网页预览、只读文档只要能被截图或导出为图片就能用 OCR 提取。它不适合的场景也要提前说清楚对手写体、艺术字、复杂表格要求极高的场景通用 OCR 方案的准确率会不稳定。对版面还原要求超过文本提取的场合比如必须保留原 PDF 里的字号、颜色、位置关系那需要更专业的版面分析工具。敏感文档不能出本机的场景如果工具本身是云服务就要特别注意数据合规优先考虑本地离线部署版本。不要拿它去绕过付费内容保护、爬取无授权资料或者处理你没有使用权限的文档。这是底线性问题OCR 只是技术工具使用边界由使用者自己负责。还有一个容易被忽略的点很多 LLM 场景其实不需要“高精度全文识别”而是要“把关键信息提取出来”。所以有时候结合 LLM 做二次结构化比单独追求 OCR 准确率更划算。OCR 负责把文本粗提出来LLM 负责按模板抽取字段这种“OCR LLM”组合在票据录入、简历解析、合同审阅里很常见。3. 本地部署环境准备在动手安装之前先列一份通用的环境检查清单。不需要全部满足但至少要确认自己缺哪一项免得启动时报错再回头补。操作系统Windows 10/11、macOS、Linux 均可。如果你的 GPU 环境在 Windows 上优先确保显卡驱动和 CUDA 版本匹配。Python 版本建议 3.9 到 3.11。部分 OCR 库对 Python 3.12 的兼容性不一定好如果项目文档没有明确说明先使用 3.10 是最稳妥的选择。依赖管理使用虚拟环境避免和系统 Python 包冲突。推理后端CPU 模式一般开箱即用GPU 加速需要安装对应版本的 PyTorch 或 OnnxRuntime。模型文件OCR 项目通常需要下载检测模型和识别模型如果项目是首次启动自动下载要保证网络通畅如果项目提供离线模型包就放在指定目录。磁盘空间OCR 模型通常不大但涉及批量处理大量 PDF 时输出文件建议单独挂载目录。端口号如果项目带 Web 服务或 API注意检查 8000、7860 这类常用端口是否被占用。下面是一个通用虚拟环境准备命令实际项目如果提供了一键脚本可以直接用项目的脚本# 创建并激活虚拟环境 python -m venv ocrit_env source ocrit_env/bin/activate # Windows PowerShell: ocrit_env\Scripts\Activate.ps1 # 安装依赖具体文件名以项目为准 pip install -r requirements.txt如果项目本身是用 Docker 分发那么宿主机只需要装好 Docker 和显卡驱动运行时即可Python 环境可以完全隔离在容器里。4. 安装部署与一键启动OCR It 这类工具的部署方式通常有几种命令行启动、Web 服务启动、Docker 启动。下面给出通用模板。4.1 命令行启动如果项目提供了 CLI 入口一般在激活环境后执行python main.py --input ./inputs/test.png --output ./outputs/test.md参数含义可能需要调整常见的有--input输入图片或 PDF 路径。--output输出文件路径。--format输出格式如txt、json、markdown。--device推理设备如cpu或gpu。--lang识别语言如ch、en、chen。如果你把命令写错了程序会打印帮助信息可以执行python main.py --help查看支持的全部参数。4.2 API 服务启动要让 OCR It 变成一个可供 LLM 应用调用的服务推荐走 API 模式python app.py --host 127.0.0.1 --port 8000如果项目基于 FastAPI 或 Flask启动后访问http://127.0.0.1:8000/docs通常能看到 Swagger 文档页面这算是服务启动成功的最直观标志。这个页面里面会列出所有接口包括请求参数和返回格式是后续调试的最好入口。4.3 Docker 启动Docker 部署的好处是环境隔离不会污染宿主机 Python 环境。通用模板如下docker run -d \ --name ocr-it-service \ -p 8000:8000 \ -v /path/to/models:/app/models \ -v /path/to/inputs:/app/inputs \ -v /path/to/outputs:/app/outputs \ ocr-it:latest这份命令里-p是端口映射-v把模型目录、输入目录、输出目录挂载到宿主机便于管理文件。如果你需要在 NVIDIA GPU 上运行还要额外加--gpus all前提是宿主机已经安装 NVIDIA Container Toolkit。4.4 第一次启动建议第一次启动时不要一上来就处理几百页 PDF。先用单张图片试跑一遍确认三件事服务能不能起来模型加载有没有报错输出文件是不是期望的格式。这三件事都没问题再放开批量任务。否则堆一起排查会非常痛苦。5. 功能测试与效果验证部署完成后建议按下面六个维度做功能验证。每一条都给出测试目的、输入素材、判断标准和失败排查思路。5.1 单张图片文字识别测试目的确认基础 OCR 能力正常。输入素材一张包含清晰中文和英文的截图或扫描图建议文字字号偏大、背景干净。操作步骤启动服务后用 CLI 或 API 传入这张图片输出txt文件。预期结果输出文本里的内容与图片中文字基本一致无乱码、无漏行。判断标准对比原文重点看数字、英文、标点是否有错误。失败排查如果识别为空先检查图片是否太暗、文字是否太小、模型语言是否设置正确。5.2 PDF 批量解析测试目的验证批量处理能力和 PDF 文档兼容性。输入素材一个包含 5 到 10 页的扫描版 PDF既有文字版 PDF也有纯图片型 PDF。操作步骤把 PDF 放入输入目录执行批量命令观察输出目录里每个 PDF 是否都生成对应文本文件。预期结果每页或每份 PDF 都有对应输出图片型 PDF 能被成功识别。判断标准检查页数是否完整不能只有首页或中间丢页。失败排查如果某一页失败通常是该页图片分辨率过低或倾斜严重可以先用图像预处理工具矫正再识别。5.3 图文混排与标题结构测试目的确认输出内容保留基本文档结构而不只是一堆杂乱文字。输入素材一张包含标题、正文、列表、图片说明的截图。操作步骤用markdown格式输出。预期结果标题被识别并转换为#或加粗形式列表保持缩进图文位置有基本顺序。判断标准Markdown 文件能否直接作为 LLM 上下文阅读而不是需要再清洗。失败排查如果 Markdown 结构混乱可以检查该项目是否有“版面分析”开关或者考虑在高精度模式下重试。这里的核心关注点是OCR 结果不能只停留在“文字抽离”层面还要保留顺序和层级。因为 LLM 阅读长文本时标题和列表结构直接影响理解效果。RAG 切分时结构化程度高也能提升检索命中率。5.4 表格识别测试目的验证表格这类复杂版面。输入素材用一张带边框的表格图片比如考勤表、报价单。操作步骤输出json或markdown观察表格结构是否保留。预期结果表格行、列关系基本正确单元格内容没有串位。判断标准把结果导入 Excel 或结构化 JSON看是否能还原出大意。失败排查如果单元格错位严重说明模型对表格结构支持一般建议在后续 LLM 后处理中加入“表格重排”提示词来修正。这个场景最实用的方式是OCR 先把表格转成近似 Markdown 表格然后让 LLM 根据上下文重排成 JSON 数组。这样即使 OCR 对边框不敏感也能得到可用的结构化数据。5.5 CPU 与 GPU 对比测试目的确认本机推断资源是否够用决定是否需要 GPU。操作步骤同一张图分别用--device cpu和--device gpu跑一次。预期结果GPU 模式耗时明显下降CPU 模式也能完成但耗时随图片尺寸增加。判断标准记录两次耗时并观察显存占用。失败排查如果 GPU 模式报错大概率是 CUDA 版本不匹配或推理后端没装对。先执行python -c import torch; print(torch.cuda.is_available())确认 PyTorch 是否能用 GPU不能的话就先用 CPU 跑通业务。这个测试的结论直接关系到生产环境部署选型。如果你只是给个人 LLM 工作流做数据入口CPU 往往就够用如果是每天处理上千页文档的高频服务那必须上 GPU 或至少用多进程并行。5.6 输出格式与重跑验证测试目的确认项目支持重复执行而不产生脏数据。操作步骤对同一文件跑两次检查输出目录是否覆盖旧文件还是重复新建。预期结果建议项目应支持覆盖写入避免重复执行后磁盘碎片膨胀。判断标准批量任务重启后已处理过的文档不会重复生成或者重复生成无影响。失败排查如果每次输出都新增文件且没有确认机制可以自己在脚本里加一个“如果输出文件存在就跳过”的幂等逻辑。6. 接口 API 与批量任务OCR 工具单独跑命令行是能用但真正要接进 LLM 应用必须有一套稳定的 HTTP 接口。下面给出通用调用示例。6.1 API 请求与返回假设服务运行在http://127.0.0.1:8000接口路径为/api/v1/ocr。用 Python requests 调用import requests import json url http://127.0.0.1:8000/api/v1/ocr with open(test.png, rb) as f: resp requests.post( url, files{file: f}, data{ lang: ch, format: markdown }, timeout60 ) if resp.status_code 200: result resp.json() print(result.get(text)) print(json.dumps(result, ensure_asciiFalse, indent2)) else: print(请求失败:, resp.status_code, resp.text)用 curl 是同样效果curl -X POST http://127.0.0.1:8000/api/v1/ocr \ -F filetest.png \ -F langch \ -F formatmarkdown接口返回的 JSON 字段通常包括识别文本、耗时时长、识别语言、状态码。如果服务端没有返回text字段可以到/docs页面查看实际响应结构。6.2 将 OCR 结果接入 LLMOCR 接口返回的文本就是 LLM 的输入。如果本机有一个 OpenAI 兼容的 LLM 服务可以这样把文档喂给模型from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY ) doc_text open(outputs/scan.md, r, encodingutf-8).read() resp client.chat.completions.create( modelyour-local-llm, messages[ {role: system, content: 你是一个文档解析助手请根据文档内容回答问题。}, {role: user, content: f这是从扫描文档中提取的文本\n{doc_text}\n\n请总结这份文档的要点。} ] ) print(resp.choices[0].message.content)这种流程比把二进制 PDF 直接塞给模型更稳定也是一个最基本的 RAG 雏形文档先过 OCR 变成文本文本再过向量化入库查询时先检索再生成。OCR It 在链路里就是那个最前端的“文档转文本”组件。6.3 批量任务目录设计批量处理建议按如下目录组织project/ ├── inputs/ │ └── contracts/ │ ├── a.pdf │ └── b.png ├── outputs/ │ └── contracts/ │ ├── a.md │ └── b.md ├── logs/ │ └── ocr_batch.log └── run_batch.py批量脚本的配置可以做成 JSON{ input_dir: ./inputs, output_dir: ./outputs, format: markdown, max_workers: 2, retry_times: 2, timeout_seconds: 60 }建议在批量脚本里加三样东西日志、失败重试、跳过已处理文件。日志能帮你在跑了几百个文件时定位哪一页出了问题重试机制应对偶发的网络或显存波动跳过已处理文件能让你中途失败后从断点继续而不是从头再来。import os import json import time from pathlib import Path config json.load(open(config.json)) resource Path(test.png) target Path(outputs/test.md) # 幂等处理已有输出就跳过 if target.exists(): print(skip already processed:, resource) else: # 这里调用 OCR It 的命令行或 API print(process:, resource) time.sleep(1) target.write_text(ocr result, encodingutf-8)这只是一个示意实际项目可以把ocr_it_client封装成一个类把请求超时、重试、日志都收敛进去。6.4 API 服务的扩展方向如果要做成并发服务还要注意限制单次请求的并发数因为 OCR 是 CPU/GPU 密集型操作并发太高会把显存或者 CPU 跑满。给长 PDF 设置更长的超时时间避免 API 网关 504。如果使用 FastAPI可以给接口加一个任务 ID客户端先提交任务再轮询结果避免请求超时。7. 资源占用与性能观察OCR 类任务的资源占用核心看三块模型加载的内存/显存、图片解码时的临时内存、推理时的峰值显存。观察方式# NVIDIA 任务中实时观察显存 nvidia-smi -l 2Windows 下可以打开任务管理器查看 GPU 显存和 CPU 占用曲线。在跑批量任务时重点观察两点显存是否持续上涨。如果持续上涨可能是任务完成后显存没有及时释放需要在脚本里加显存清理或进程重启策略。CPU 是否打满导致系统卡顿。CPU 推理时可以让多个进程同时跑但要注意内存峰值。不同推理方式的表现差异很明显CPU 推理不需要初始化 CUDA模型加载慢但稳定适合低并发、时延不敏感的任务。GPU 推理首次加载显存占用大但推理速度快适合高吞吐场景。ONNX Runtime 优化有些项目会提供 ONNX 模型推理速度比纯 PyTorch 快且 CPU/GPU 切换更灵活。影响耗时的因素主要有图片分辨率、文字数量、语言数量、是否启用版面分析、并发数。如果发现处理速度太慢先降低图片分辨率比如把 4000px 的扫描图缩到 2000px识别精度损失有限但速度提升非常明显。如果发现显存不足可以减小并发、使用 CPU 推理、或者换用精度更低的量化模型。端口冲突是另一个常见问题。启动 API 服务时报address already in use说明端口被占用。先查占用进程# Linux / macOS lsof -i :8000 # Windows PowerShell netstat -ano | findstr :8000然后换一个端口启动即可python app.py --host 127.0.0.1 --port 80018. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后页面打不开端口被占用或服务未启动查看启动日志、检查端口状态更换端口或重启服务依赖安装失败Python 版本不兼容、缺少编译工具查看 pip 报错信息切换 Python 版本或安装依赖后重试模型文件缺失首次启动自动下载失败检查项目 models 目录手动下载模型文件并放入指定目录CUDA 不可用显卡驱动或 CUDA 版本不匹配执行torch.cuda.is_available()安装匹配版本的 PyTorch 或转 CPU 模式显存不足图片分辨率过高或并发过大观察nvidia-smi显存占用降低分辨率、减小并发、使用 CPU 推理API 调用失败或超时请求格式不对、长文档处理慢查看 API 返回错误码和日志修改请求体、加长超时时间、使用任务队列批量任务中途卡住单个文件异常导致进程挂起查看日志目录中最后处理文件加入重试和超时机制跳过异常文件OCR 结果乱码语言参数设置错误或图片质量差检查识别语言和原始图片切换语言模型、提高图片清晰度、增加图像预处理输出质量不稳定脚本型小字、倾斜、多层表格对比不同页面识别结果调高分辨率、开启版面分析、加 LLM 后处理修正这份排查表的核心原则是先看日志再看硬件最后看模型。不要一上来就重装项目大多数问题都不是项目代码问题而是环境不匹配。9. 最佳实践与使用建议把 OCR It 真正用起来之后有几条工程化建议值得直接照做。第一第一次跑通之后保存一套“最小可运行配置”。把虚拟环境、模型目录、启动命令、测试输入输出都固定下来。这样以后再启动不会因为找不到环境而浪费时间。第二模型文件、输入素材、输出结果、日志分目录管理。千万不要混在一个文件夹里。批量任务一多混在一起基本等于自杀。第三批量处理要加日志、失败重试和幂等判断。日志可以定位问题重试可以处理偶发失败幂等判断可以让你随时中断恢复。这三点加在一起批量任务才能算“可运维”。第四OCR 结果不要直接作为最终答案。把 OCR 结果喂给 LLM 之前先做一次质量检查比如检查行数、乱码比例、关键字段是否缺失。如果文本质量太差LLM 会被带偏。第五API 服务一定要限制访问范围。如果是本机使用绑定127.0.0.1就好如果是局域网服务要加访问验证避免被其他设备滥用。OCR 接口一旦被滥用CPU 和显存会被瞬间打满。第六合规问题必须前置确认。只处理你有权处理的文档涉及他人隐私、版权、商业机密的内容要确认授权和使用边界。OCR 技术本身没有错但拿它去抓取付费内容或未授权资料就属于使用边界问题了。尤其在接 LLM 的时候等于是把文档内容送到模型服务里如果模型是云端服务还要评估数据合规风险。第七把 OCR 后的文本接入 RAG 时建议先切块再入库。OCR 输出的长文本结构通常不如原生数字文档好切块策略需要单独测试。可以尝试按标题结构切分或者按固定长度带着重叠窗口切分跑几次检索效果对比后再固定参数。10. 总结与下一步OCR It 这类面向 LLM 的文档文本提取工具最值得尝试的点是它把“不可复制的文档”变成“LLM 可读的文本”这一层打通了。你最先应该验证的不是它能识别多少种语言而是单张图片识别是否准确、PDF 批量是否稳定、输出格式是否方便后续程序读取。这三个点验证通过整个文档管道的地基就稳了。最容易踩的坑也有几个模型文件下载失败、GPU 环境不匹配、长 PDF 处理超时。其中 GPU 环境是最让人头疼的如果你对 CUDA 不熟悉建议先用 CPU 模式把业务跑通后续再考虑加速。后续可以继续扩展的方向很明确把 OCR It 接到你本地的 LLM 推理服务里形成“OCR 文本提取 向量检索 LLM 问答”的完整链路。更进一步可以让 LLM Agent 把它当做一个工具来调用用户发来一张图片或 PDFAgent 自动调用 OCR 接口提取文本再根据文本内容回答问题。这套架构同样可以用在 Spring AI MCP RAG 的工程化框架里也可以用一个轻量编排引擎把任务流程串起来。如果现在正卡在“文档数据无法进入 LLM”这个阶段不用追求大而全的系统先把 OCR It 跑通手动从一张扫描图里得到一份干净的 Markdown 文本再拿这份文本去测你的 LLM 或者 RAG 效果。链路通了后面扩批量、加接口、接 Agent 都是水到渠成的事。