GLM-OCR保姆级部署教程基于Dify构建自动化工作流你是不是经常遇到一堆纸质文件、截图或者图片需要转换成文字手动录入费时费力用传统的OCR工具吧识别率时好时坏格式还经常乱。今天咱们就来聊聊一个更聪明的办法把强大的GLM-OCR模型部署起来然后塞进Dify这个可视化工具里搭一个自动化的文档处理流水线。简单来说这个工作流就是你丢一张图片进去它自动识别出里面的文字并且按照你想要的格式比如表格、段落整理好还能直接传给下一个步骤比如存进数据库或者触发一个机器人流程。整个过程你几乎不用写代码在Dify里拖拖拽拽就能搞定。听起来是不是挺省事的接下来我就手把手带你走一遍。1. 准备工作理清思路与备好工具在开始动手之前咱们先花两分钟把整个事情想明白。我们的目标是搭建一个自动化流程核心是让GLM-OCR模型在Dify里干活。你需要准备的东西不多一台服务器可以是云服务器也可以是你本地性能不错的电脑。操作系统推荐Linux比如Ubuntu 20.04或以上用起来最顺手。基础的命令行操作知识知道怎么用cd、ls、pip这些命令就行。一个Dify账号去Dify官网注册一个它有云端版和自托管版。为了部署自定义模型我们通常选择自托管Self-hosted方式自由度更高。GLM-OCR模型我们需要获取这个模型的部署文件或API。它可能以多种形式提供比如Docker镜像、Python包或者一个可以直接调用的API服务地址。本教程会以部署一个独立的GLM-OCR API服务为例这样最灵活。整个流程可以分成三大步先把GLM-OCR模型服务跑起来然后在Dify里把它配置成一个可以调用的“工具”最后在Dify的工作流画布上把图片输入、OCR识别、文本处理、结果输出这些节点像拼乐高一样连起来。2. 第一步部署GLM-OCR模型服务我们的第一步是让GLM-OCR模型变成一个随时待命的“服务员”。这里假设我们通过Python来启动一个简单的API服务。首先连接上你的服务器创建一个干净的工作目录mkdir glm-ocr-service cd glm-ocr-service接着准备一个Python虚拟环境避免包版本冲突python3 -m venv venv source venv/bin/activate # Linux/macOS # 如果是Windows使用 venv\Scripts\activate然后安装必要的依赖。你需要根据GLM-OCR模型官方提供的具体安装说明来操作。这里是一个假设性的requirements.txt文件示例你需要替换成实际所需的包# requirements.txt 示例内容 fastapi uvicorn pydantic pillow torch # 以及其他GLM-OCR模型特定的库例如 # glm-ocr (假设的包名请以官方为准)使用pip安装pip install -r requirements.txt核心步骤是编写API服务代码。创建一个名为app.py的文件内容大致如下。请注意以下代码是概念性示例关键的函数调用如glm_ocr.predict需要你替换为GLM-OCR模型实际的使用方法。# app.py from fastapi import FastAPI, File, UploadFile, HTTPException from fastapi.middleware.cors import CORSMiddleware from pydantic import BaseModel import io from PIL import Image import json import logging # 假设的OCR处理函数此处需要替换为真实的GLM-OCR模型调用代码 def process_image_with_glm_ocr(image_bytes: bytes) - dict: 调用GLM-OCR模型处理图片返回结构化的识别结果。 这是一个示例函数你需要根据GLM-OCR的实际API进行实现。 try: # 1. 将字节流转换为PIL Image image Image.open(io.BytesIO(image_bytes)) # 2. 此处应调用真实的GLM-OCR模型推理代码 # 例如: result glm_ocr_model.predict(image) # 假设返回的result是一个字典包含文本、框、置信度等信息 # 示例返回结构 (请根据模型实际输出调整) mock_result { text: 这是从图片中识别出的文本内容。, blocks: [ {text: 段落1, bbox: [10, 20, 100, 30], type: text}, {text: 段落2, bbox: [10, 60, 100, 70], type: text} ], status: success } return mock_result except Exception as e: logging.error(fOCR处理失败: {e}) return {status: error, message: str(e)} # 定义响应模型 class OCRResponse(BaseModel): status: str text: str None blocks: list None message: str None # 创建FastAPI应用 app FastAPI(titleGLM-OCR Service) # 添加CORS支持方便Dify可能在不同端口调用 app.add_middleware( CORSMiddleware, allow_origins[*], # 生产环境应限制为具体域名 allow_credentialsTrue, allow_methods[*], allow_headers[*], ) app.post(/ocr, response_modelOCRResponse) async def process_ocr(image: UploadFile File(...)): 接收图片文件调用OCR模型处理返回结构化文本。 if not image.content_type.startswith(image/): raise HTTPException(status_code400, detail请上传图片文件) # 读取上传的图片数据 contents await image.read() # 调用处理函数 result process_image_with_glm_ocr(contents) # 构建并返回响应 if result.get(status) success: return OCRResponse(**result) else: raise HTTPException(status_code500, detailresult.get(message, OCR处理错误)) app.get(/health) async def health_check(): return {status: healthy} if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)代码说明我们创建了一个FastAPI应用提供了一个/ocr接口用于接收图片。process_image_with_glm_ocr函数是核心你需要在这里填入调用真实GLM-OCR模型的代码。模型可能返回纯文本也可能返回带位置信息的结构化数据。我们定义了OCRResponse模型来规范返回的数据格式这对后续Dify集成很重要。添加了/health接口用于健康检查。服务运行在8000端口。现在运行这个服务python app.py如果看到类似Uvicorn running on http://0.0.0.0:8000的提示说明你的GLM-OCR API服务已经在本地的8000端口跑起来了。你可以用curl或者Postman测试一下/ocr接口是否正常工作。为了让服务在后台稳定运行建议使用进程管理工具如systemd或supervisor。这里以systemd为例创建一个服务文件/etc/systemd/system/glm-ocr.service[Unit] DescriptionGLM-OCR API Service Afternetwork.target [Service] Useryour_username WorkingDirectory/path/to/your/glm-ocr-service ExecStart/path/to/your/glm-ocr-service/venv/bin/python app.py Restartalways [Install] WantedBymulti-user.target然后启用并启动服务sudo systemctl daemon-reload sudo systemctl enable glm-ocr sudo systemctl start glm-ocr sudo systemctl status glm-ocr # 检查状态3. 第二步在Dify中配置自定义模型节点GLM-OCR服务已经就位现在我们要让Dify知道它的存在并学会怎么调用它。登录你的Dify后台自托管版。首先进入“模型供应商”或“自定义模型”配置区域。在Dify中通常可以通过添加“自定义API”的方式来集成外部服务。创建新的API端点在相应配置页面点击“添加”或“创建”。我们需要填写以下关键信息名称起个易懂的名字比如“GLM-OCR”。API类型选择OpenAI-Compatible或Custom。由于我们的服务是自定义的REST API通常选Custom。基础URL填写你的GLM-OCR服务地址例如http://你的服务器IP:8000。如果Dify和OCR服务在同一台机器也可以用http://localhost:8000。API密钥如果我们的服务没有鉴权这里可以留空。为了安全生产环境建议加上API Key验证并在Dify和OCR服务代码中实现。其他参数根据Dify界面提示可能还需要填写组织ID等非必填的可以先不管。配置模型参数映射这是最关键的一步告诉Dify如何调用我们的/ocr接口。Dify通常期望以类似调用大模型的方式发送JSON来调用自定义模型。我们需要“适配”一下。在模型配置中找到“请求参数映射”或“端点配置”。请求路径填写/ocr这是我们服务的端点。请求方法选择POST。请求头需要设置Content-Type: multipart/form-data因为我们是上传文件。请求体这里需要构造一个表单数据form-data。通常需要映射一个变量比如{{image_file}}到名为image的文件字段。具体映射语法请严格参照Dify的文档说明不同版本可能有差异。响应解析告诉Dify如何从我们服务的响应OCRResponse里提取出它需要的“文本内容”。例如如果我们的响应是{status:success, text: 识别出的文字}, 那么响应解析路径可能是data.text或text取决于Dify的解析规则。这个过程可能需要一些调试。Dify通常提供了“测试连接”或“发送测试请求”的功能你可以上传一张测试图片看看返回的数据是否符合预期解析是否正确。4. 第三步设计自动化工作流模型配置好了现在进入最有趣的部分——用Dify的可视化画布搭建工作流。我们目标是上传图片 → OCR识别 → 处理文本 → 输出或传递结果。创建新应用与工作流在Dify中创建一个新应用选择“工作流”模式。添加起始节点从节点库中拖入一个“文件上传”或“HTTP输入”节点作为流程的起点用于接收用户上传的图片。添加OCR处理节点拖入一个“LLM”或“知识库检索”节点不对这里应该使用“自定义工具”或“HTTP请求”节点。在Dify中我们刚才配置的“GLM-OCR”自定义模型可能会出现在可用的工具或模型列表中。将其拖入画布。或者使用更通用的“HTTP请求”节点手动配置去调用我们部署的http://你的服务地址:8000/ocr接口。你需要配置请求方法为POST内容类型为form-data并将起始节点传来的图片文件变量绑定到名为image的文件字段上。连接节点用连线将“文件上传”节点的输出如图片文件变量连接到“GLM-OCR”节点的输入。添加文本处理节点可选但推荐OCR识别出的原始文本可能比较“粗糙”。我们可以接一个“文本处理”或“代码执行”节点。在这个节点里你可以编写简单的Python代码或使用内置函数对OCR返回的文本进行清洗、格式化。例如去除多余空格、按行整理、或者提取特定格式的信息如发票金额、日期。# 在“代码执行”节点中可能用到的示例逻辑 def format_ocr_text(raw_result): # raw_result 是从上一个OCR节点传来的数据 full_text raw_result.get(text, ) # 简单的清洗和格式化 lines full_text.split(\n) cleaned_lines [line.strip() for line in lines if line.strip()] formatted_text \n.join(cleaned_lines) return formatted_text添加输出与后续动作节点拖入一个“答案”节点将处理好的文本输出给用户。如果你想实现自动化可以继续连接其他节点。例如发送到数据库连接一个“HTTP请求”节点将结构化文本POST到你自己的业务系统或数据库API。触发RPA连接一个“Webhook”节点将结果发送给RPA工具如影刀、UiPath的触发接口启动后续的桌面自动化流程。生成摘要或翻译再接一个“LLM”节点如ChatGPT让大模型对识别出的文本进行摘要、翻译或分类。调试与发布点击“运行”测试你的工作流。上传一张测试图片观察每个节点的输入输出确保数据流转正确。调试无误后保存并发布这个应用。Dify会生成一个独立的访问链接或API端点供你或你的系统调用。5. 总结走完这三步一个基于GLM-OCR和Dify的自动化文档处理流水线就搭建完成了。回头看看我们其实做了三件事让一个专业的OCR模型在服务器上待命在一个可视化工具里把它包装成一个即插即用的组件最后像设计流程图一样把数据处理的各个环节串联起来。这种做法的好处很明显你不需要从头到尾写一大堆脚本去处理图片上传、模型调用、错误处理和结果转发。Dify的图形化界面让流程设计和调试变得直观而且它本身也具备一定的并发处理和状态管理能力。一旦流程跑通无论是内部员工通过一个简单页面上传图片还是其他业务系统通过API调用这个服务都非常方便。当然这只是个起点。你可以根据实际需求在这个工作流里加入更复杂的逻辑比如支持批量图片处理、添加不同格式的模板、或者与更多的企业内部系统对接。希望这个教程能帮你打开思路把AI模型的能力快速、灵活地融入到实际业务中去。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。