1. 为什么要把识别和大模型搬回本机1.1 从一次断网办公说起上个月帮一个做专利代理的朋友处理一批技术交底书大概两百多页扫描件需要提取里面的文字做检索比对。本来想直接用在线OCR接口跑一遍就完事结果他们单位的网络策略比较特殊外网访问时断时续批量上传到一半就卡死重试几次之后我直接放弃了在线方案。当天晚上回去就把整个流程改成了本地跑OCR用本机引擎文本清洗和摘要用本地部署的大模型全程不依赖任何外部接口。跑完之后朋友问我要不要把这个流程整理一下我说行正好把踩过的坑都记下来。这件事让我重新审视了一个问题离线OCR加本地大模型这套组合到底适合什么人。我的答案是三类人。第一类是处理敏感文档的比如合同、病历、内部技术资料这些东西从合规角度就不应该离开本机。第二类是网络环境不稳定的比如工厂车间、野外作业、内网隔离环境。第三类就是单纯想省钱或者想折腾的在线API按量计费量大之后成本并不低而本地跑一次配置好之后边际成本几乎为零。1.2 离线方案的核心关键词拆解标题里提到的几个词我逐个说一下我的理解。OCR光学字符识别本质是把图片里的像素模式映射成字符编码。离线OCR意味着这个映射过程完全在本机CPU或GPU上完成不调用任何远程服务。AI和大模型这里指的是本地部署的大语言模型用来做OCR之后的文本后处理比如纠错、结构化提取、摘要生成、问答检索。它和OCR是上下游关系OCR负责“看见”大模型负责“理解”。tesseract.js和WASM这是浏览器端离线OCR的典型技术路线。tesseract.js是Tesseract引擎的JavaScript移植版WASM是WebAssembly一种可以在浏览器里以接近原生速度运行的二进制指令格式。把这两者结合就能在网页里直接做OCR不需要装任何软件也不需要联网。本地部署这个词在热词里出现频率很高说明大家对这个方向的需求是真实存在的。但本地部署不等于简单下载一个安装包它涉及到模型选型、量化、推理框架、硬件适配等一系列工程决策。1.3 这套方案能解决什么实际问题我总结下来离线OCR加本地大模型主要解决四类问题。第一类是批量文档数字化。比如把一堆纸质合同扫描成PDF之后批量提取文字建立全文索引后续可以按关键词检索。这个场景下OCR的准确率要求不是百分之百但召回率要高不能漏掉关键段落。第二类是敏感信息的本地处理。有些文档涉及商业机密或者个人隐私上传到第三方服务存在合规风险。本地跑的好处是数据不出机器处理完直接删除中间文件就行。第三类是网络受限环境下的自动化。比如内网办公环境、离线设备、边缘计算节点这些地方根本连不上外部API只能靠本地能力。第四类是成本控制。在线OCR和大模型API都是按调用量计费的文档量大了之后费用很可观。本地部署一次性投入硬件后续跑多少都不额外花钱。注意本地部署的前期配置成本不低如果你的文档量很小比如一个月就几十页那用在线服务反而更划算。本地方案适合的是量大、持续、对数据安全有要求的场景。2. 离线OCR的技术路线怎么选2.1 三条主流路线的对比离线OCR目前有三条比较成熟的技术路线我分别说一下各自的适用场景。第一条是传统OCR引擎本地安装代表是Tesseract。它是最老牌的开源OCR引擎支持一百多种语言安装包不大CPU就能跑。缺点是对于复杂版面、手写体、低质量扫描件的识别率一般需要配合图像预处理才能达到可用水平。第二条是深度学习OCR模型本地推理代表是PaddleOCR、EasyOCR这些。它们基于深度学习模型对复杂场景的适应能力强很多但模型体积大推理需要GPU或者性能较好的CPU。部署起来比Tesseract复杂但效果确实好。第三条是浏览器端WASM方案代表就是tesseract.js。它的最大优势是零安装、跨平台只要有浏览器就能跑。缺点是性能受限于浏览器环境大批量处理时速度不如原生程序而且对系统资源的调用权限有限。路线代表工具硬件要求识别效果部署难度适用场景传统引擎TesseractCPU即可中等低印刷体、清晰扫描件深度学习PaddleOCRGPU优先高中高复杂版面、多语言浏览器WASMtesseract.js浏览器中等极低轻量、跨平台、零安装2.2 我为什么最终选了Tesseract加本地大模型的组合说实话我一开始是想用PaddleOCR的效果确实好。但朋友的机器是一台老笔记本没有独立显卡装PaddleOCR之后CPU推理速度慢得让人抓狂一页A4扫描件要跑十几秒。后来换成Tesseract配合图像预处理单页速度降到两秒左右识别率虽然略低一点但后续用本地大模型做纠错之后最终效果反而更稳定。这里的关键决策点是OCR的识别错误可以由大模型来兜底但OCR的速度瓶颈很难绕过。与其追求OCR单环节的极致准确率不如把OCR当作一个高召回率的粗提取工具把精确率的任务交给大模型。这个思路在实际跑下来之后证明是可行的。2.3 图像预处理被大多数人忽略的关键环节很多人装完Tesseract直接拿原图去识别然后抱怨效果差。其实问题往往不在OCR引擎而在输入图像的质量。我总结了几步必做的预处理。第一步是灰度化。彩色信息对文字识别没有帮助反而增加计算量。转成灰度图之后后续的二值化处理会更稳定。第二步是二值化。把灰度图转成黑白两色文字和背景的对比度拉到最大。Tesseract内部虽然也会做二值化但它用的是全局阈值对于光照不均匀的扫描件效果不好。我一般用自适应阈值OpenCV里的adaptiveThreshold函数就能做。第三步是去噪。扫描件上经常有细小的噪点可以用中值滤波或者形态学操作去掉。但要注意不要过度处理否则会把细笔画也去掉。第四步是倾斜校正。扫描的时候如果纸张放歪了文字行不水平Tesseract的版面分析会出错。可以用霍夫变换检测直线角度然后旋转校正。第五步是分辨率调整。Tesseract官方建议输入图像的文字高度在30到40像素之间。如果原图分辨率太低可以适当放大如果太高可以缩小以减少计算量。import cv2 import numpy as np def preprocess_image(image_path): img cv2.imread(image_path) gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) binary cv2.adaptiveThreshold( gray, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 15, 8 ) denoised cv2.medianBlur(binary, 3) coords np.column_stack(np.where(denoised 0)) angle cv2.minAreaRect(coords)[-1] if angle -45: angle 90 angle (h, w) denoised.shape[:2] center (w // 2, h // 2) M cv2.getRotationMatrix2D(center, angle, 1.0) rotated cv2.warpAffine( denoised, M, (w, h), flagscv2.INTER_CUBIC, borderModecv2.BORDER_REPLICATE ) return rotated这段代码是我实际在用的预处理流程跑下来对普通扫描件的效果提升很明显。注意adaptiveThreshold的两个参数需要根据实际图像调整block size一般取15到25之间C值取5到10之间。提示预处理不是越多越好。我试过加锐化、加对比度拉伸结果反而引入了伪影识别率下降。建议先用原图跑一遍看错误类型再决定加哪些预处理步骤。3. 本地大模型怎么选和怎么跑3.1 模型选型的三个维度本地跑大模型选型主要看三个维度模型能力、硬件需求、推理速度。这三者互相制约不可能同时最优。模型能力方面参数越大通常越强但也不是绝对的。有些7B的模型在特定任务上能打过13B的关键看训练数据和微调质量。对于OCR后处理这种任务主要用到的是文本纠错、信息抽取、摘要生成不需要模型有太强的推理能力7B到13B的模型基本够用。硬件需求方面模型参数和显存占用大致是1:2的关系。也就是说7B的模型如果用FP16精度大概需要14GB显存如果用4-bit量化大概需要4GB左右。CPU推理也可以但速度会慢很多。推理速度方面除了模型大小和硬件还跟推理框架有关。目前本地部署比较常用的框架有Ollama、llama.cpp、vLLM等。Ollama上手最简单一条命令就能跑llama.cpp对CPU优化好适合没有显卡的机器vLLM吞吐量高适合批量处理。模型规模FP16显存4-bit量化显存CPU推理速度适用场景7B约14GB约4GB较慢文本纠错、摘要13B约26GB约8GB慢复杂信息抽取34B约68GB约20GB很慢高质量生成3.2 量化让小显存也能跑大模型量化是本地部署大模型的核心技术之一。简单说就是把模型权重从高精度浮点数转换成低精度整数减少存储和计算量。常见的量化精度有8-bit、4-bit、3-bit甚至2-bit。量化的代价是模型能力会有一定下降但4-bit量化在大多数任务上的损失是可以接受的。我实测下来7B模型4-bit量化之后在文本纠错任务上的表现和FP16版本差距很小但显存占用从14GB降到了4GB左右一台普通游戏本就能跑。量化的具体操作取决于推理框架。用Ollama的话它自带量化模型下载直接拉取带q4_0后缀的模型就行。用llama.cpp的话需要自己用quantize工具转换。# 用Ollama拉取4-bit量化的7B模型 ollama pull qwen2:7b-instruct-q4_0 # 运行模型 ollama run qwen2:7b-instruct-q4_0这两条命令是我最常用的下载完之后模型就存在本地后续调用不需要联网。Ollama会自动管理模型文件不用手动指定路径。3.3 提示词设计让大模型做好OCR后处理本地大模型跑起来之后关键是怎么写提示词。OCR后处理这个任务提示词设计有几个要点。第一是明确任务边界。不要让模型做太多事情一次只做一件事。比如先做纠错再做结构化提取分两步走比一步到位效果好。第二是提供上下文。OCR结果里经常有断行、错字、乱码如果直接把整段文本丢给模型它可能不知道哪些是错误。我一般会在提示词里说明“以下文本来自OCR识别可能存在字符错误和断行问题请修正明显的识别错误并合并断行”。第三是给出输出格式。如果需要结构化输出比如JSON要在提示词里明确说明字段名和格式。本地小模型对格式的遵循能力不如大模型需要给例子。import requests def correct_ocr_text(raw_text): prompt f以下文本来自OCR识别可能存在字符错误和断行问题。 请修正明显的识别错误合并被错误断开的行保持原意不变。 只输出修正后的文本不要添加任何解释。 原文 {raw_text} 修正后 response requests.post( http://localhost:11434/api/generate, json{ model: qwen2:7b-instruct-q4_0, prompt: prompt, stream: False, options: { temperature: 0.1, top_p: 0.9 } } ) return response.json()[response]这段代码是我实际在用的纠错函数。temperature设成0.1是为了让输出更稳定减少随机性。top_p设成0.9是常规选择兼顾多样性和质量。注意本地小模型有时候会“自作主张”改写原文尤其是当原文本身有语法问题的时候。如果对原文忠实度要求高可以在提示词里强调“不要改写原文只修正明显的OCR错误”。4. 完整实操流程从扫描件到可检索文本4.1 整体流程设计整个流程我分成了五个阶段图像预处理、OCR识别、文本清洗、大模型后处理、索引构建。每个阶段的输出是下一个阶段的输入中间结果都保存成文件方便排查问题。这个设计的好处是每个环节可以独立调试。比如OCR识别率不高可以单独看预处理之后的图像大模型纠错效果不好可以单独看OCR的原始输出。如果做成一条龙管道出了问题很难定位。4.2 批量处理的目录结构我习惯用这样的目录结构来组织批量处理任务project/ ├── input/ # 原始扫描件 ├── preprocessed/ # 预处理后的图像 ├── ocr_raw/ # OCR原始输出 ├── ocr_clean/ # 清洗后的文本 ├── llm_output/ # 大模型处理结果 └── index/ # 检索索引每个阶段处理完就把结果写到对应目录处理失败的记录到日志里。这样即使中途中断也能从上次的进度继续不用从头跑。4.3 OCR识别的参数调优Tesseract的命令行参数很多但常用的就那么几个。我一般用这样的配置tesseract input.png output -l chi_simeng --psm 6 --oem 3-l chi_simeng指定识别中文简体和英文如果文档里还有其他语言可以加上对应的语言包。--psm 6是页面分割模式6表示“假设是一个统一的文本块”适合大多数文档。--oem 3是OCR引擎模式3表示“默认使用可用的引擎”。页面分割模式PSM对识别效果影响很大我整理了一个对照表PSM值含义适用场景3全自动分割通用但可能出错4假设单列文本单栏文档6假设统一文本块大多数扫描件7假设单行文本单行图片11稀疏文本散落文字我实测下来对于普通的A4文档扫描件PSM 6的效果最稳定。如果是表格或者多栏排版可能需要用PSM 3让Tesseract自动分析版面。4.4 大模型后处理的批量化单条文本调用大模型纠错很简单但批量处理的时候要注意几个问题。第一是并发控制。本地大模型推理是计算密集型任务同时跑太多请求会把显存打满。我一般设置并发数为1到2用队列串行处理。虽然慢一点但稳定。第二是超时处理。有些文本特别长大模型处理时间可能超过预期。需要设置超时时间超时之后记录到失败列表后续单独处理。第三是结果校验。大模型输出有时候会包含额外的解释文字需要做后处理提取纯文本。我一般用正则表达式匹配“修正后”之后的内容。import re import time from concurrent.futures import ThreadPoolExecutor def process_batch(text_list, max_workers1): results [] failed [] def process_one(idx, text): try: corrected correct_ocr_text(text) match re.search(r修正后\s*(.*), corrected, re.DOTALL) if match: return idx, match.group(1).strip() return idx, corrected.strip() except Exception as e: return idx, None with ThreadPoolExecutor(max_workersmax_workers) as executor: futures [ executor.submit(process_one, i, text) for i, text in enumerate(text_list) ] for future in futures: idx, result future.result(timeout120) if result is None: failed.append(idx) else: results.append((idx, result)) return results, failed这段代码是我实际在用的批量处理逻辑。max_workers设成1就是串行设成2就是两个并发。超时时间设的120秒对于大多数文本够用了。4.5 索引构建与检索文本处理完之后最后一步是建立检索索引。我用的是Whoosh一个纯Python的全文检索库不需要额外安装服务适合本地部署。from whoosh.index import create_in from whoosh.fields import Schema, TEXT, ID from whoosh.qparser import QueryParser import os def build_index(text_dir, index_dir): schema Schema( doc_idID(storedTrue), contentTEXT(storedTrue) ) if not os.path.exists(index_dir): os.mkdir(index_dir) ix create_in(index_dir, schema) writer ix.writer() for filename in os.listdir(text_dir): if filename.endswith(.txt): with open(os.path.join(text_dir, filename), r, encodingutf-8) as f: content f.read() writer.add_document( doc_idfilename, contentcontent ) writer.commit() return ix def search(index_dir, query_str): from whoosh.index import open_dir ix open_dir(index_dir) with ix.searcher() as searcher: query QueryParser(content, ix.schema).parse(query_str) results searcher.search(query, limit10) return [(r[doc_id], r.score) for r in results]Whoosh的中文分词需要额外配置默认的分词器对中文支持不好。可以装jieba分词库然后自定义分词器。不过如果只是做简单的关键词检索不配置分词也能用只是召回率会低一些。5. 常见问题与排查技巧实录5.1 OCR识别率低的排查思路OCR识别率低是最常见的问题排查的时候按这个顺序来。先看输入图像质量。把预处理之后的图像打开看一眼如果人眼都看不清那OCR肯定也识别不了。常见问题包括分辨率太低、对比度不够、噪点太多、倾斜角度太大。再看语言包是否安装。Tesseract默认只装英文语言包中文需要单独下载chi_sim.traineddata放到tessdata目录。如果识别中文全是乱码大概率是语言包没装。然后看PSM参数是否合适。不同的版面结构需要不同的PSM值可以多试几个值看哪个效果最好。最后看字体是否特殊。有些艺术字体、手写体、古籍字体Tesseract的识别率确实有限这种情况可能需要换深度学习OCR方案。5.2 大模型输出不稳定的处理本地小模型输出不稳定是另一个常见问题表现包括输出格式不对、内容被改写、重复输出、中途截断。输出格式不对通常是提示词不够明确。可以在提示词里加例子告诉模型期望的输出格式是什么样的。内容被改写是因为模型“太聪明”了觉得原文有问题就自动改了。解决办法是在提示词里强调“只修正OCR错误不要改写原文”。重复输出是模型的复读机问题通常和temperature参数有关。把temperature调低或者加repeat_penalty参数可以缓解。中途截断是因为输出长度超过了模型的上下文窗口。可以设置max_tokens参数或者把长文本切分成小段处理。问题现象可能原因解决方法格式不对提示词不明确加输出示例内容改写模型过度发挥强调忠实原文重复输出温度过高降低temperature中途截断超出上下文分段处理5.3 性能优化的几个实用技巧如果处理速度太慢可以从这几个方面优化。OCR环节可以开多进程并行处理。Tesseract是CPU密集型的多开几个进程能充分利用多核CPU。但要注意不要开太多否则内存会爆。大模型环节可以用流式输出减少等待时间。Ollama支持stream模式边生成边返回用户体验更好。另外如果GPU显存够大可以把模型全部加载到显存里避免频繁的内存交换。整体流程可以把中间结果缓存起来。如果某个文件已经处理过就直接读缓存不用重新跑。我用文件哈希值作为缓存键文件内容没变就跳过处理。提示性能优化不要过早做。先把流程跑通确认效果没问题再考虑优化速度。我见过太多人一开始就纠结性能结果流程还没跑通就放弃了。5.4 我踩过的几个坑第一个坑是语言包路径问题。Tesseract默认从系统目录找语言包但有时候装完之后路径不对需要手动设置TESSDATA_PREFIX环境变量。这个问题折腾了我半个多小时。第二个坑是大模型显存不足。一开始用FP16精度跑7B模型显存直接爆了。后来换成4-bit量化才跑起来。如果你的显卡显存小于8GB建议直接用4-bit量化模型。第三个坑是中文编码问题。Windows系统默认编码是GBK读写UTF-8文件的时候经常乱码。解决办法是在所有文件操作里显式指定encodingutf-8。第四个坑是Whoosh索引更新。Whoosh的索引是只读的更新需要重建或者用update_document方法。我一开始直接往索引目录里加文件结果检索不到新内容。后来改成每次处理完一批就重建索引虽然慢一点但不会出错。6. 这套方案的扩展方向6.1 从单机到局域网共享如果团队里有多个人需要用到这套能力可以把OCR和大模型部署到一台性能较好的机器上其他人通过局域网调用。Ollama默认只监听本地端口可以配置成监听所有网络接口这样局域网内的其他机器就能访问。# 设置Ollama监听所有网络接口 export OLLAMA_HOST0.0.0.0:11434 ollama serve这样配置之后局域网内的其他机器就可以通过http://服务器IP:11434来调用大模型。OCR部分可以封装成一个HTTP服务用FastAPI或者Flask都很简单。6.2 结合向量数据库做语义检索全文检索只能匹配关键词如果用户搜的是“合同违约责任”但文档里写的是“违约方应承担的赔偿责任”全文检索可能匹配不到。这时候可以用向量数据库做语义检索。具体做法是用一个文本嵌入模型把每段文本转成向量存到向量数据库里。检索的时候把查询也转成向量然后找最相似的向量。本地可以用的嵌入模型有text2vec、bge等向量数据库可以用Chroma、FAISS这些。6.3 自动化触发与监控如果文档是持续产生的可以做一个监控目录有新文件进来就自动触发处理流程。用watchdog库可以监听文件系统事件配合前面的处理流程就能实现全自动化。监控方面可以记录每个文件的处理状态、耗时、识别率等指标定期生成报告。如果某个文件的识别率明显偏低可以标记出来人工复核。这套流程我从最初的手动跑单文件到后来批量处理再到现在的自动化管道前后迭代了大概两个月。中间踩的坑不少但跑通之后确实省了很多事。如果你也在做类似的事情建议先从单文件跑通开始不要一上来就搞全自动化那样出了问题很难定位。先把每个环节都摸清楚再逐步串联起来这样最稳妥。