LLM-Aided OCR：用大模型修复 Tesseract 的错字，但先想清楚成本

它解决什么问题，谁该关心

Tesseract 对扫描 PDF 的识别结果往往充满错字、断行和乱码，尤其是旧式字体或低分辨率页面。这个项目把 Tesseract 的输出交给大语言模型做两轮处理：先纠正 OCR 错误，再按需转成 Markdown。目标用户是那些需要把纸质档案数字化成可编辑文档的人，比如历史信件整理者、法律文件扫描者或研究者。它并不试图改进 OCR 引擎本身，而是用 LLM 的语义理解来修补机械识别的缺陷。

管线拆解：从 PDF 到 Markdown 的每一步

流程分四段。第一段用 pdf2image 把 PDF 转成图片，支持 max_pages 和 skip_first_n_pages 参数，可以只处理部分页面。第二段用 pytesseract 做 OCR，之前先对图像做灰度化、Otsu 二值化和膨胀预处理，目的是增强文字清晰度。第三段把整篇文本按句子边界切成块，块与块之间保留重叠，避免切断上下文。每个块先经过一次 LLM 纠错，再进入可选的 Markdown 格式化步骤。格式化时还会删除重复段落，因为扫描件常见页眉或页脚重复。最后一步是质量评估，用 LLM 对比原始 OCR 与最终输出，给出分数和解释。整个管线是串行的，但 API 调用部分用 asyncio 并发，同时保持输出顺序。

LLM 接入方式：本地与 API 的取舍

项目支持三种后端：OpenAI、Anthropic 和本地 llama_cpp。环境变量 USE_LOCAL_LLM 控制走哪条路，API_PROVIDER 选择具体的云服务。本地模式需要兼容的 GGUF 模型，并支持自定义 grammar 来限制输出结构。API 模式实现了重试逻辑和动态调整请求大小，避免超出 token 限制。异步并发只用于 API 调用，本地推理则是同步的，因为 GPU 资源通常单一。文档没有说明本地模型的最低显存要求，也没有给出推荐的 GGUF 文件，这意味着用户需要自己找模型并试错。

配置与运行：真实命令和关键参数

安装步骤明确要求 Python 3.12，并建议用 pyenv 管理版本。克隆仓库后，运行 python -m venv venv 创建虚拟环境，然后 pip install -r requirements.txt。系统层面需要安装 Tesseract，Ubuntu 用 sudo apt-get install tesseract-ocr，macOS 用 brew install tesseract。配置写在 .env 文件里，核心键包括 USE_LOCAL_LLM、API_PROVIDER、OPENAI_API_KEY 和 ANTHROPIC_API_KEY。文档还提到 TOKEN_BUFFER 和 TOKEN_CUSHION 两个常量，用于控制 token 估算的安全余量，但没给出默认值。使用方式是把 PDF 放在项目目录，然后修改 input_ 开头的变量，README 在此处截断，所以具体的命令行入口并未展示。

明显的局限：成本、语言与维护风险

最直接的局限是每次处理都要调用 LLM，且每个块至少两次调用（纠错和格式化），如果开启质量评估还要第三次。这意味着处理一本书的成本可能高到不现实。项目只提供了英文样例，没有提到对其他语言的支持，Tesseract 的语言包和 LLM 的纠错能力在非英文场景下会大打折扣。另一个隐患是依赖链很长：pdf2image 需要 poppler，pytesseract 需要系统级 Tesseract，本地 LLM 需要 GGUF 模型，任何一环缺失都会中断流程。仓库没有发布任何 release，也没有版本号，依赖更新可能导致行为变化。许可证显示 NOASSERTION，这意味着你没有明确的法律授权来使用或修改代码，商业采用前必须联系作者确认。

替代方案：直接后处理与专用 OCR 引擎

一个现实的替代是跳过 LLM，用传统规则修正 OCR 输出，例如用正则表达式处理常见错误模式，或使用 spellchecker 库。这种方法成本为零，但无法理解上下文，比如把“c1ear”修正为“clear”就需要语义判断。另一个替代是使用专门的 OCR 后处理工具，比如 OCRfeeder 或 Tesseract 自带的 --psm 模式调整，它们改变识别参数但不会修复语义错误。更接近的方案是使用像 Nougat 这样的端到端模型，它直接从页面图像生成 Markdown，不需要中间 OCR 文本，但需要 GPU 训练或推理。llm_aided_ocr 的差异在于它保留 Tesseract 的原始输出作为可审计的中间产物，而 Nougat 是黑盒。

维护成本与升级路径

项目最近一次推送是 2026 年 8 月，但没有任何 release，说明仍处于快速变动期。升级时你需要手动拉取 main 分支，并检查 requirements.txt 的变化。由于没有版本锁定机制，依赖库的大版本更新可能破坏 API 调用或 pdf2image 的兼容性。文档中的安装步骤包含大量系统级依赖，换一台机器就要重来一遍。对于长期使用，建议将 .env 和输入 PDF 放入版本控制，但注意不要把 API 密钥提交。质量评估功能能给你一个分数，但该分数由 LLM 自评，主观性很强，不能作为绝对指标。

编辑结论

这个项目适合那些需要把历史扫描件、信件或合同转成结构化 Markdown，并且愿意为每页文本支付 LLM 调用费用的个人或小团队。它不适合追求零成本批处理、对延迟敏感或需要处理非英文文档的用户，因为项目只示例了英文，且未提供任何语言适配的说明。若你决定采用，先验证三件事：确认本机 Tesseract 版本与语言包是否匹配你的 PDF 语言，检查 .env 中 API_PROVIDER 与密钥是否指向你实际可用的服务，并用一个 10 页内的样张跑通完整流程，对比 raw OCR 与 LLM 修正后的质量评分，再决定是否扩大范围。

官方来源

1. Dicklesworthstone/llm_aided_ocr on GitHub
2. Issues
3. README