1. 项目概述当大语言模型“看懂”图片最近在折腾一些文档自动处理的活儿发现一个挺有意思的痛点很多场景下我们拿到的信息源是图片比如扫描的合同、手机拍的表格、或者网页截图。传统的OCR光学字符识别工具比如Tesseract或者一些商业API能把图片里的文字“抠”出来这已经解决了“识别”的问题。但很多时候我们需要的不仅仅是“识别”而是“理解”和“结构化提取”。举个例子你拍了一张包含姓名、电话、地址的名片照片。传统OCR会给你一串文本“张三 13800138000 北京市海淀区XX大厦”。这串文本你得自己写规则去分割、去判断哪个是电话、哪个是地址非常麻烦而且换一种排版的名片规则就失效了。再比如一张复杂的财务报表截图你不仅需要识别出所有数字还需要理解这些数字之间的层级关系哪个是总收入哪个是分项成本这更是传统OCR无能为力的。sunrisever/glm-ocr这个项目在我看来就是试图用当前最火的大语言模型LLM的能力来彻底解决这个“识别后理解”的问题。它不是一个简单的OCR引擎而是一个“视觉-语言”多模态理解管道。它的核心思路是先用一个强大的视觉基础模型比如Qwen-VL、GLM-4V把图片“看”懂生成一份包含图中所有视觉元素文本、表格结构、图表信息等的详细描述然后把这大段描述扔给另一个专精于文本理解和推理的大语言模型比如GLM-4、ChatGLM3让它根据我们提出的具体问题“提取所有联系人信息”、“总结报表的核心数据”从描述中精准地找到并结构化输出答案。所以这个项目的标题glm-ocr可能有点“谦虚”了它本质上做的是VQA视觉问答或文档信息提取的工作而OCR只是其能力的一部分。它适合谁呢我觉得是三类人一是需要处理大量非结构化文档票据、报告、合同的开发者或业务人员希望自动化提取关键字段二是AI应用开发者想在自己的产品里加入“看懂图片并回答问题”的智能功能三是对多模态AI技术感兴趣的极客想亲手搭建和微调一个属于自己的图文理解模型管道。2. 核心架构与方案选型解析为什么是“GLM-OCR”这个命名其实揭示了项目的技术栈选择。在当前开源多模态模型的生态里有几个主流路线OpenAI的CLIP系列、阿里云的Qwen-VL、智谱AI的GLM-4V、以及Meta的LLaVA等。这个项目选择了以GLM系列模型为核心我认为背后有非常实际的考量。2.1 视觉编码器与LLM的搭配逻辑项目的核心是一个两阶段管道视觉理解和文本推理。视觉理解阶段需要一个多模态大模型MLLM来充当“眼睛”。这个模型需要能把图片像素转换成富含语义的文本描述。GLM-4V 或 Qwen-VL 这类模型就是干这个的。它们通常在数十亿甚至上百亿的图文对上训练过学会了将图像特征与文本描述对齐。在这个项目里视觉模型的任务不是输出“A区域有文字‘张三’”而是输出更接近人类理解的描述比如“这是一张名片左上角有公司Logo中间是姓名‘张三’下方是手机号‘13800138000’最底部是一行地址‘北京市海淀区…’”。这种描述包含了空间关系和语义信息为后续的LLM理解打下了坚实基础。文本推理阶段需要一个强大的纯文本LLM来充当“大脑”。它接收来自“眼睛”的详细描述以及用户的具体指令例如“提取出姓名和电话号码”然后进行分析、推理并输出结构化的答案例如{name: 张三, phone: 13800138000}。GLM系列模型特别是ChatGLM3-6B/12B因其优秀的指令跟随和对话能力成为这个“大脑”的合适选择。它擅长理解复杂指令并从大段文本中抽取和重组信息。选择GLM全家桶GLM-4V ChatGLM3的一个关键优势是生态一致性。它们来自同一家机构在模型结构、分词器、部署工具上可能有更好的兼容性减少了适配的麻烦。而且GLM系列在中文场景下的表现通常非常出色这对于处理中文文档至关重要。2.2 与纯OCR方案及端到端方案的对比这里有必要厘清它和传统方案的区别vs. 传统OCR 规则引擎这是最古老的方案。传统OCR如Tesseract输出的是带坐标的文本行或单词。你需要写一大堆正则表达式和启发式规则来解析。它的缺点是脆弱排版一变就失效且无法理解语义无法区分“公司名称”和“人名”。glm-ocr用LLM的通用理解能力替代了手写规则泛化能力强得多。vs. 端到端信息提取模型学术界和工业界也有直接输入图片输出结构化信息如JSON的端到端模型。这类模型需要大量特定领域如票据、简历的标注数据来训练成本高且换一个任务从发票转到病历就需要重新训练。glm-ocr的方案是管道式的它的优势在于灵活性。视觉模型和文本LLM可以相对独立地升级或更换。今天我用它解析名片明天我只需修改给LLM的提示词Prompt就能让它解析病历无需重新训练任何模型。这是一种“提示词工程”驱动的敏捷开发模式。注意管道式方案的潜在缺点是误差累积。如果视觉模型“看”错了比如把“13”看成“B”那么LLM再聪明也无法给出正确答案。因此视觉模型的准确性是整个系统的基石。2.3 关键技术组件拆解基于项目仓库的常见结构我推断其核心实现可能包含以下组件图像预处理模块不是简单的缩放。可能包括对比度增强处理拍摄光线不足、透视校正摆正歪斜的文档、去噪处理扫描件噪点。这些预处理能显著提升视觉模型的识别率。OpenCV是完成这些任务的标配工具库。视觉模型调用层负责加载GLM-4V或类似模型将预处理后的图像转换为模型可接受的输入格式如图像分块、转换为特征向量并获取模型的文本描述输出。这里会涉及模型推理框架的选择如transformers,vllm或者使用模型提供的API。提示词Prompt工程模块这是项目的“灵魂”之一。给LLM的提示词需要精心设计。例如你是一个信息提取助手。以下是一段对一张图片的详细描述 “[视觉模型生成的描述文本]” 请根据描述严格提取以下信息并以JSON格式输出 - 姓名 (name) - 职位 (title) - 电话 (phone) - 邮箱 (email) 如果某项信息不存在则对应字段值为空字符串。提示词的质量直接决定了输出结果的准确性和格式规范性。大语言模型LLM调用层负责调用ChatGLM3等模型传入拼接好的提示词系统指令 视觉描述 用户问题并解析模型的文本输出。这里的关键是输出格式控制需要引导LLM输出稳定的JSON便于程序后续处理。后处理与输出模块对LLM输出的JSON进行校验、清洗如格式化电话号码、可能还会结合视觉模型提供的原始文本坐标将提取的信息映射回图片上的原始位置实现“高亮显示”等功能。3. 从零搭建与核心环节实现假设我们要在本地部署一个最小可用的glm-ocr服务用于提取名片信息。下面是我设想的实操步骤融合了常见的工程实践。3.1 环境准备与依赖安装首先需要一个Python环境3.8。建议使用conda或venv创建虚拟环境。# 创建并激活虚拟环境 conda create -n glm-ocr python3.10 conda activate glm-ocr # 安装核心依赖 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 # 根据CUDA版本调整 pip install transformers accelerate sentencepiece # Hugging Face 模型库 pip install opencv-python pillow # 图像处理 pip install pydantic # 用于数据验证和结构化 pip install fastapi uvicorn # 构建API服务可选如果使用GLM系列模型可能需要额外安装cpm-kernels或swift智谱的官方工具库具体需参考模型仓库的说明。3.2 模型下载与加载这里以使用Qwen-VL-Chat作为视觉模型ChatGLM3-6B作为文本LLM为例因为GLM-4V权重可能未完全开源Qwen-VL是优秀的开源替代。# model_loader.py from transformers import AutoModelForCausalLM, AutoTokenizer, AutoProcessor from PIL import Image import torch class MultimodalExtractor: def __init__(self, vision_model_path, llm_model_path): # 1. 加载视觉模型 (Qwen-VL) self.vision_processor AutoProcessor.from_pretrained(vision_model_path) self.vision_model AutoModelForCausalLM.from_pretrained( vision_model_path, torch_dtypetorch.float16, # 半精度节省显存 device_mapauto, # 自动分配设备 trust_remote_codeTrue # 信任自定义代码 ).eval() # 2. 加载文本LLM (ChatGLM3) self.llm_tokenizer AutoTokenizer.from_pretrained(llm_model_path, trust_remote_codeTrue) self.llm_model AutoModelForCausalLM.from_pretrained( llm_model_path, torch_dtypetorch.float16, device_mapauto, trust_remote_codeTrue ).eval() def describe_image(self, image_path): 使用视觉模型生成图像描述 image Image.open(image_path).convert(RGB) # 预处理图像并生成输入 prompt 详细描述这张图片中的所有文字和布局信息。 inputs self.vision_processor( imagesimage, textprompt, return_tensorspt ).to(self.vision_model.device) # 生成描述 with torch.no_grad(): generated_ids self.vision_model.generate( **inputs, max_new_tokens512, # 控制描述长度 do_sampleFalse # 贪婪解码保证稳定性 ) description self.vision_processor.batch_decode(generated_ids, skip_special_tokensTrue)[0] # 清理输出只保留模型生成的描述部分 description description.replace(prompt, ).strip() return description def extract_with_prompt(self, image_description, extraction_prompt): 使用LLM根据描述和提示词提取信息 # 构建给LLM的完整提示 system_prompt 你是一个精准的信息提取助手。请根据提供的图片描述严格按要求提取信息。 full_prompt f{system_prompt}\n\n图片描述{image_description}\n\n用户要求{extraction_prompt}\n\n请以JSON格式输出提取结果。 inputs self.llm_tokenizer(full_prompt, return_tensorspt).to(self.llm_model.device) with torch.no_grad(): outputs self.llm_model.generate( **inputs, max_new_tokens256, temperature0.1, # 低温度保证输出确定性 do_sampleTrue ) result_text self.llm_tokenizer.decode(outputs[0], skip_special_tokensTrue) # 从输出中解析JSON部分这里需要简单的后处理 return self._parse_json_from_text(result_text) def _parse_json_from_text(self, text): # 一个简单的解析寻找第一个 { 和最后一个 } import json try: start text.find({) end text.rfind(}) 1 if start ! -1 and end ! 0: json_str text[start:end] return json.loads(json_str) except json.JSONDecodeError: pass return {}实操心得模型加载是最容易出问题的环节。务必确认你的显卡显存足够6B模型约需12-15GB显存用于推理。如果显存不足可以考虑使用device_mapcpu或量化版本如torch_dtypetorch.int8但速度会慢很多。另一个关键是trust_remote_codeTrue参数对于很多国产大模型这是必须的因为它们的模型实现可能不在transformers标准库内。3.3 构建一个完整的处理流程现在我们将预处理、描述生成、信息提取串联起来并加入一些工程化的改进。# pipeline.py import cv2 import numpy as np from model_loader import MultimodalExtractor import json class OCRPipeline: def __init__(self, extractor): self.extractor extractor def preprocess_image(self, image_path): 基础的图像预处理 img cv2.imread(image_path) if img is None: raise ValueError(f无法读取图片: {image_path}) # 1. 转为灰度图 gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) # 2. 自适应阈值二值化增强文字对比度 binary cv2.adaptiveThreshold(gray, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 11, 2) # 3. 轻度降噪 denoised cv2.medianBlur(binary, 3) # 保存预处理后的临时文件供模型使用 processed_path temp_processed.jpg cv2.imwrite(processed_path, denoised) return processed_path def build_dynamic_prompt(self, task_typebusiness_card): 根据任务类型动态构建提示词 prompt_templates { business_card: 请从图片描述中提取以下联系人信息并以JSON格式输出 {{ name: 姓名, title: 职位/头衔, company: 公司名称, phone: 电话号码, email: 电子邮箱, address: 地址如有 }} 如果某项信息不存在请将其值设为空字符串 。 请确保只输出JSON不要有任何额外解释。 , invoice: 请从图片描述中提取以下发票信息并以JSON格式输出 {{ invoice_number: 发票号码, date: 开票日期, seller: 销售方名称, total_amount: 总金额含税, tax_amount: 税额 }} 金额请提取数字忽略货币符号。 } return prompt_templates.get(task_type, prompt_templates[business_card]) def run(self, image_path, task_typebusiness_card): 执行完整的提取流程 print(f处理图片: {image_path}) # 1. 预处理 processed_img_path self.preprocess_image(image_path) print(图像预处理完成。) # 2. 视觉模型生成描述 print(视觉模型正在分析图片...) description self.extractor.describe_image(processed_img_path) print(f生成描述长度: {len(description)} 字符) # 可选打印前200字符查看 # print(描述预览:, description[:200]) # 3. 构建任务特定提示词 extraction_prompt self.build_dynamic_prompt(task_type) # 4. LLM提取信息 print(大语言模型正在提取信息...) result self.extractor.extract_with_prompt(description, extraction_prompt) # 5. 清理临时文件 import os if os.path.exists(processed_img_path): os.remove(processed_img_path) return { image: image_path, task: task_type, raw_description_preview: description[:300], # 保存部分描述用于调试 extracted_info: result } # 使用示例 if __name__ __main__: # 初始化提取器假设模型已下载到本地路径 extractor MultimodalExtractor( vision_model_path./models/Qwen-VL-Chat, llm_model_path./models/chatglm3-6b ) pipeline OCRPipeline(extractor) # 处理一张名片图片 result pipeline.run(./samples/business_card.jpg, task_typebusiness_card) print(\n 提取结果 ) print(json.dumps(result[extracted_info], indent2, ensure_asciiFalse))这个流程展示了从原始图片到结构化JSON的完整路径。build_dynamic_prompt函数体现了管道式设计的灵活性要处理新类型的文档你只需要定义一个新的提示词模板而无需改动模型代码。4. 性能优化与部署考量本地跑通流程只是第一步。要想实用必须考虑性能和部署。4.1 推理速度优化两个模型串行推理耗时是主要瓶颈。优化点包括模型量化将模型权重从FP16转换为INT8甚至INT4可以大幅减少显存占用和提升推理速度但会轻微损失精度。可以使用bitsandbytes库进行8位量化。from transformers import BitsAndBytesConfig quantization_config BitsAndBytesConfig(load_in_8bitTrue) model AutoModelForCausalLM.from_pretrained(..., quantization_configquantization_config)使用更快的推理引擎用vllm或TGI(Text Generation Inference) 替代原生的transformers进行LLM推理它们支持连续批处理Continuous batching和PagedAttention等技术吞吐量可提升数倍。缓存视觉描述如果同一张图片需要被多次查询例如不同的人问不同问题可以将视觉模型生成的描述缓存起来避免重复进行昂贵的图像编码计算。4.2 部署为API服务使用 FastAPI 可以轻松地将整个管道封装成Web服务。# api_server.py from fastapi import FastAPI, File, UploadFile from pydantic import BaseModel from pipeline import OCRPipeline, MultimodalExtractor import tempfile import os app FastAPI(titleGLM-OCR 信息提取服务) # 全局加载模型启动时加载一次 extractor None pipeline None app.on_event(startup) async def startup_event(): global extractor, pipeline # 注意在实际部署中模型路径应从配置中读取 extractor MultimodalExtractor(./models/Qwen-VL-Chat, ./models/chatglm3-6b) pipeline OCRPipeline(extractor) print(模型加载完成服务已就绪。) class ExtractionRequest(BaseModel): task_type: str business_card app.post(/extract) async def extract_info( task: ExtractionRequest, image: UploadFile File(...) ): 上传图片并提取信息 # 保存上传的临时文件 with tempfile.NamedTemporaryFile(deleteFalse, suffix.jpg) as tmp_file: content await image.read() tmp_file.write(content) tmp_path tmp_file.name try: # 调用处理管道 result pipeline.run(tmp_path, task.task_type) # 移除临时文件 os.unlink(tmp_path) return { success: True, data: result[extracted_info], debug: {description_preview: result[raw_description_preview]} } except Exception as e: if os.path.exists(tmp_path): os.unlink(tmp_path) return {success: False, error: str(e)} if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)部署后你就可以通过POST /extract接口上传图片并获取结构化信息了。这对于集成到其他系统如OA、CRM非常方便。4.3 成本与规模化思考自建模型的成本主要是GPU机器费用。对于中小规模应用日处理几千张图片一台配备RTX 4090或A10的服务器可能就够了。如果请求量非常大或者希望免运维也可以考虑使用模型API服务直接调用智谱AI、百度文心、阿里云等提供的GLM-4V或类似模型的API。这样无需管理GPU服务器按使用量付费但数据需要上传到云端。混合架构将视觉描述生成计算密集放在自有GPU服务器上将文本LLM推理对延迟更敏感使用云上托管的LLM API。这样可以在成本和可控性之间取得平衡。5. 常见问题、排查技巧与效果提升在实际操作中你肯定会遇到各种问题。下面是我能想到的一些坑和解决办法。5.1 视觉描述不准确或遗漏信息这是最常见的问题会导致后续提取全盘皆输。现象LLM提取的结果牛头不对马嘴检查生成的描述发现关键文字没识别出来。排查与解决检查原图质量图片是否模糊、倾斜、光线不均用preprocess_image函数加强预处理比如尝试不同的二值化方法 (cv2.THRESH_OTSU)、进行更激进的角度矫正。调整视觉模型的提示词给视觉模型的指令很重要。不要只用“描述这张图片”。尝试更具体的指令如“请详细列出图片中的所有文字内容并描述它们之间的相对位置关系。对于表格请描述行列结构。” 有时候指令越具体模型越专注。尝试不同的视觉模型Qwen-VL和GLM-4V各有侧重。可以写一个简单的评估脚本用同一批测试图片跑不同的模型对比描述质量。BLIP-2、LLaVA也是不错的开源备选。分区域识别对于非常复杂的图片如一张包含多个名片的照片可以先用目标检测模型如YOLO把每个名片框出来然后对每个区域单独调用视觉模型最后合并描述。这能提升复杂场景下的精度。5.2 LLM输出格式不稳定LLM可能不按你要求的JSON格式输出或者多输出一些废话。现象_parse_json_from_text解析失败或者JSON字段名不对。排查与解决强化系统提示词在给LLM的提示词开头用非常强硬和明确的语气。例如“你必须且只能输出一个合法的JSON对象不要有任何其他文本、标记、解释。你的输出将被直接传递给json.loads()函数解析任何非JSON内容都会导致程序错误。”使用输出引导Output Guiding在提示词中给出一个极其清晰的例子One-shot/Few-shot Learning。例如在提示词里先写一个标准的输入输出示例。后处理兜底如果LLM在JSON外加了反引号或“json”这样的标记需要在解析前用正则表达式去除。也可以使用更鲁棒的解析库比如json5它能容忍一些非严格JSON的格式。考虑使用Function Calling如果使用的LLM支持Function Calling如GPT、GLM最新版本可以将其定义为一个“信息提取”函数让模型以结构化格式调用该函数这比让模型自由生成JSON要稳定得多。5.3 处理速度太慢现象处理一张图片要十几秒甚至几十秒。排查与解决分析瓶颈用time.time()分别记录视觉模型推理和LLM推理的时间看哪个是瓶颈。通常是视觉模型更耗时。启用批处理如果有大量图片需要处理不要一张一张处理。将多张图片预处理后批量输入视觉模型如果模型支持可以极大提升GPU利用率。对于LLM也可以将多个问题批量处理。降低生成参数减少max_new_tokens。视觉模型的描述不用太长512 tokens通常足够LLM的回答也可以限制在较短的范围内。硬件升级这可能是最直接的方法。使用更快的GPU如H100或者使用多卡并行推理。5.4 领域适配与效果提升当处理特定领域如医疗报告、法律文书时通用模型可能表现不佳。方法提示词工程微调Prompt Tuning和领域知识注入。构建领域知识库收集一批该领域的图片和对应的标准结构化信息JSON。制作高质量的提示词范例为每张图片精心编写视觉模型的描述指令和LLM的提取指令形成“指令-输入-输出”对。微调LLM可选但有效使用LoRA等参数高效微调方法在ChatGLM3的基础上用你的领域数据对模型进行轻微调整。这能让模型更好地理解你领域的术语和格式要求。微调视觉模型成本很高通常优先微调LLM。RAG检索增强生成对于需要外部知识的任务如根据发票上的商品名称查询税率可以先将描述中的关键实体商品名提取出来去知识库数据库里检索相关信息再把检索结果作为上下文喂给LLM让它综合判断。5.5 效果评估与迭代没有评估优化就无从谈起。建立测试集手动标注50-100张具有代表性的图片包含标准答案Ground Truth。定义评估指标字段级准确率F1-Score对于每个要提取的字段如姓名、电话计算模型提取结果与标准答案的精确匹配率。完全匹配率整张图片所有字段都提取正确的比例。自动化测试写一个脚本定期在测试集上跑你的管道生成评估报告。这样当你更换模型、调整提示词或修改预处理步骤后能清晰地看到效果是提升还是下降。从我自己的经验来看glm-ocr这类项目最大的魅力在于其“可编程性”。你不需要是机器学习专家只需要懂得如何与LLM“对话”写提示词就能快速构建出一个解决实际问题的智能工具。它把以前需要大量标注数据和模型训练的任务变成了一个快速迭代的软件工程问题。当然它的效果上限受限于基础模型的能力但对于很多常见、规范的文档已经能提供远超传统方案的体验。