通义千问2.5实战案例：智能制造工单自动填写系统

通义千问2.5实战案例智能制造工单自动填写系统想象一下这个场景在一条繁忙的智能生产线上设备传感器实时发出告警工程师需要立刻处理。传统的流程是工程师跑到现场查看设备状态手动在电脑上填写工单——设备编号、故障现象、可能原因、处理建议……一套流程下来少说也要5-10分钟。如果遇到复杂问题还得翻手册、查资料时间就更长了。现在我们换个思路。设备告警信息通过系统自动推送到一个AI助手面前它瞬间就能理解告警内容结合设备历史数据和维修手册自动生成一份结构完整、建议专业的维修工单草稿。工程师只需要审核、确认整个过程可能只需要30秒。这不是科幻而是我们今天要实现的基于通义千问2.5-7B-Instruct大模型构建一个智能制造场景下的工单自动填写系统。我们将手把手带你完成从模型部署到应用集成的全过程让你亲眼看到AI如何为传统工业注入“智能”。1. 为什么选择通义千问2.5-7B-Instruct在开始动手之前我们先搞清楚为什么选这个模型。面对工业场景我们的模型需要满足几个硬性要求要足够聪明能准确理解设备告警文本常包含专业术语和简写并推理出可能的故障原因。要听话、格式规整生成的工单必须严格按照我们要求的JSON格式输出方便下游系统直接解析使用。要反应快、成本低生产环境要求低延迟同时也要考虑部署的硬件成本。要安全、可控工业数据敏感模型需有较好的对齐能力避免产生有害或不安全的建议。通义千问2.5-7B-Instruct几乎是为这个场景量身定做的中等体量能力全面70亿参数在C-Eval、MMLU等权威中文评测基准上名列前茅理解中文工业文本得天独厚。指令跟随能力强作为Instruct指令版本它经过专门训练能很好地理解并执行“请以JSON格式输出”这类复杂指令。支持工具调用与结构化输出原生支持Function Calling和JSON格式强制输出这是我们实现自动化流程的关键。上下文窗口巨大128K的上下文长度意味着我们可以把一整本设备手册作为参考信息喂给它辅助其做出更准确的判断。部署友好模型量化后仅需约4GB显存一张消费级的RTX 3060显卡就能流畅运行推理速度超过100 tokens/秒完全满足实时性要求。商用友好采用宽松的开源协议允许商业使用没有法律风险。简单说它就是那个“聪明、听话、跑得快还便宜”的得力助手。2. 快速部署使用vLLM与Open WebUI搭建模型服务理论说完了我们开始实战。部署大模型听起来复杂但借助现代工具链可以变得非常简单。我们采用vLLMOpen WebUI的方案一个负责高性能推理引擎一个提供美观易用的聊天界面。2.1 环境准备与一键部署假设你有一台安装了NVIDIA显卡的Linux服务器Ubuntu 20.04/22.04为例并且已经配置好了Docker环境。我们的部署将通过Docker Compose来完成几乎是一键式的。首先创建一个项目目录比如qwen-workorder然后创建docker-compose.yml文件version: 3.8 services: vllm: image: vllm/vllm-openai:latest container_name: qwen-vllm runtime: nvidia # 需要NVIDIA Container Toolkit deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu] environment: - MODELQwen/Qwen2.5-7B-Instruct - HUGGING_FACE_HUB_TOKENyour_hf_token_here # 如果需要访问gated模型 - MAX_MODEL_LEN8192 # 根据你的需求调整最大支持128K - TENSOR_PARALLEL_SIZE1 # 单GPU ports: - 8000:8000 volumes: - ./model_cache:/root/.cache/huggingface # 缓存模型避免重复下载 command: --model ${MODEL} --served-model-name qwen2.5-7b-instruct --max-model-len ${MAX_MODEL_LEN} --tensor-parallel-size ${TENSOR_PARALLEL_SIZE} --api-key “your_vllm_api_key” # 建议设置一个API密钥 restart: unless-stopped open-webui: image: ghcr.io/open-webui/open-webui:main container_name: qwen-open-webui ports: - 8080:8080 environment: - OLLAMA_BASE_URLShttp://vllm:8000 # 关键指向vLLM服务 - WEBUI_SECRET_KEYyour_secret_key_here # 用于加密会话 - WEBUI_NAMEQwen 2.5 工单助手 volumes: - ./open-webui-data:/app/backend/data depends_on: - vllm restart: unless-stopped关键参数解释MODEL: 指定我们从Hugging Face拉取的模型这里是Qwen/Qwen2.5-7B-Instruct。MAX_MODEL_LEN: 设置模型推理的最大上下文长度根据你的工单复杂度和参考文档大小来调整。OLLAMA_BASE_URLS: 这是让Open WebUI连接vLLM服务的核心配置。vLLM提供了与Ollama兼容的API接口。WEBUI_SECRET_KEY: 为你的Web界面设置一个安全密钥。创建好文件后在终端执行一条命令docker-compose up -d接下来Docker会自动完成以下工作拉取vLLM和Open WebUI的官方镜像。启动vllm服务它会自动从Hugging Face下载通义千问2.5-7B-Instruct模型首次运行需要较长时间取决于你的网络。模型加载完毕后vLLM会在8000端口提供标准的OpenAI兼容API。启动open-webui服务它连接vLLM并在8080端口提供一个类似ChatGPT的网页聊天界面。2.2 验证与访问服务等待几分钟取决于模型下载和加载速度你可以通过以下方式验证服务是否正常检查vLLM APIcurl http://localhost:8000/v1/models如果返回包含id: qwen2.5-7b-instruct的JSON信息说明模型服务已就绪。访问Open WebUI界面 打开浏览器访问http://你的服务器IP:8080。首次访问需要注册一个账号例如用演示账号kakajiangkakajiang.com/kakajiang。登录后你应该能看到一个简洁的聊天界面。在界面设置中确认模型选择器里已经出现了qwen2.5-7b-instruct这个选项。至此一个功能完整的通义千问2.5大模型服务就已经搭建成功了你可以直接在Web界面里和它对话测试它的基础能力。3. 核心实战构建工单自动填写逻辑有了模型服务接下来就是教会它如何填写工单。我们不能只是简单地和它聊天需要设计一套“提示词Prompt工程”和“后处理”流程让它的输出稳定、可靠、可直接使用。3.1 设计系统Prompt与工单模板我们的目标是让模型扮演一个“资深设备维护专家”。我们需要在每次对话开始时通过系统提示词System Prompt给它注入这个角色和任务规则。创建一个名为prompt_template.md的文件定义我们的核心提示词你是一个智能制造工厂的资深设备维护专家精通CNC机床、工业机器人、AGV小车、PLC控制柜等各类设备的故障诊断与维修。你的任务是根据设备实时告警信息自动填写标准维修工单。 ## 工单填写规则 1. **严格分析**仔细解读告警信息结合常见故障库进行推理。 2. **格式规范**输出必须是**纯JSON对象**无需任何额外解释。 3. **内容完整**必须包含以下所有字段即使无法确定也要填写“待现场确认”。 4. **语言专业**使用中文术语准确描述清晰。 ## 输出JSON格式 { “equipment_id”: “设备编号从告警信息中提取或推断” “alarm_code”: “告警代码从告警信息中提取” “alarm_description”: “告警描述原文摘要” “phenomenon”: “故障现象详细描述” “possible_causes”: [“可能原因1” “可能原因2” “可能原因3”] “suggested_actions”: [“建议处理步骤1” “建议处理步骤2”] “safety_notes”: “安全注意事项” “estimated_downtime”: “预计停机时间单位小时” “required_tools”: [“所需工具1” “所需工具2”] “spare_parts”: [“可能需要的备件1” “可能需要的备件2”] } ## 示例告警与输出 告警信息“AGV-07在导航点N12停滞超时激光雷达点云数据异常。” { “equipment_id”: “AGV-07” “alarm_code”: “NAV_TIMEOUT_ERR” “alarm_description”: “AGV在导航点N12停滞超时激光雷达异常” “phenomenon”: “自动导引车AGV-07在行驶至N12导航点时停止前进系统检测到停滞时间超过阈值。伴随激光雷达传感器上报点云数据丢失或噪声过大。” “possible_causes”: [“N12点位反光板脏污或脱落” “AGV车体激光雷达传感器镜头污损” “导航控制系统通信短暂中断” “路径上有未识别的障碍物”] “suggested_actions”: [“1. 现场查看N12点位反光板状态并清洁。” “2. 检查AGV-07激光雷达镜头用无尘布擦拭。” “3. 重启AGV导航控制模块。” “4. 清除路径上的潜在障碍物。”] “safety_notes”: “操作前确保AGV已完全停止并处于手动模式。在AGV工作区域设置警示牌。” “estimated_downtime”: “0.5” “required_tools”: [“无尘布” “螺丝刀” “万用表”] “spare_parts”: [“反光板备用” “激光雷达清洁套件”] } 现在请根据以下新的告警信息生成工单这个系统提示词做了几件关键事定义角色让模型进入专家状态。明确规则强调格式、内容和语言要求。提供模板给出了精确的JSON结构。给出示例一个完整的例子让模型快速学习任务模式。这在技术上称为“少样本学习Few-shot Learning”能极大提升模型输出的稳定性。3.2 编写Python调用脚本现在我们需要一个Python程序来连接vLLM服务发送组合好的提示词并解析返回的JSON结果。这个脚本将是我们工单自动填写系统的“大脑”。创建workorder_agent.pyimport json import requests import logging from typing import Dict, Any # 配置日志 logging.basicConfig(levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s) logger logging.getLogger(__name__) class WorkOrderAgent: def __init__(self, api_base: str “http://localhost:8000/v1” api_key: str “your_vllm_api_key”): 初始化工单智能体 :param api_base: vLLM服务的API地址 :param api_key: vLLM服务的API密钥如果设置了 self.api_base api_base self.headers { “Content-Type”: “application/json” “Authorization”: f“Bearer {api_key}” if api_key else “” } # 加载系统提示词模板 with open(‘prompt_template.md’ ‘r’ encoding‘utf-8’) as f: self.system_prompt f.read() logger.info(“WorkOrderAgent初始化完成。”) def generate_workorder(self, alarm_message: str) - Dict[str, Any]: 根据设备告警信息生成维修工单 :param alarm_message: 原始告警文本 :return: 解析后的工单字典如果失败返回None # 1. 构建对话消息 messages [ {“role”: “system” “content”: self.system_prompt} {“role”: “user” “content”: alarm_message} ] # 2. 准备请求数据这里可以调整参数以控制生成 data { “model”: “qwen2.5-7b-instruct” “messages”: messages “temperature”: 0.1 # 低温度让输出更确定、更稳定 “max_tokens”: 1500 # 预留足够token生成完整JSON “response_format”: {“type”: “json_object”} # 关键强制要求JSON输出 “stream”: False } try: logger.info(f“正在处理告警: {alarm_message[:50]}...”) # 3. 调用vLLM API response requests.post( f“{self.api_base}/chat/completions” headersself.headers jsondata timeout60 # 设置超时 ) response.raise_for_status() # 检查HTTP错误 result response.json() ai_response result[‘choices’][0][‘message’][‘content’] # 4. 解析JSON响应 workorder_data json.loads(ai_response) logger.info(“工单生成成功”) return workorder_data except requests.exceptions.RequestException as e: logger.error(f“API请求失败: {e}”) except json.JSONDecodeError as e: logger.error(f“解析AI返回的JSON失败: {e}。原始响应: {ai_response}”) except KeyError as e: logger.error(f“API响应格式异常: {e}。完整响应: {result}”) except Exception as e: logger.error(f“生成工单时发生未知错误: {e}”) return None def save_workorder(self, workorder_data: Dict[str, Any], filename: str None): 将工单保存为JSON文件 if not workorder_data: logger.warning(“工单数据为空无法保存。”) return if filename is None: import time equipment_id workorder_data.get(‘equipment_id’ ‘unknown’) filename f“workorder_{equipment_id}_{int(time.time())}.json” with open(filename, ‘w’ encoding‘utf-8’) as f: json.dump(workorder_data, f, ensure_asciiFalse, indent2) logger.info(f“工单已保存至: {filename}”) # 使用示例 if __name__ “__main__”: # 初始化智能体 agent WorkOrderAgent() # 模拟几条真实的设备告警 test_alarms [ “CNC-03主轴驱动器报警代码ALM-501显示‘过载保护’。” “喷涂机器人RBT-15在轨迹点P5抖动异常伺服电机温度传感器报75℃。” “PLC控制柜编号PLC-02的DI模块第8通道信号持续为0但传感器反馈正常。” ] for alarm in test_alarms: print(f“\n{‘’*50}”) print(f“处理告警: {alarm}”) print(f“{‘’*50}”) # 生成工单 workorder agent.generate_workorder(alarm) if workorder: # 打印工单 print(“生成的工单内容”) print(json.dumps(workorder, ensure_asciiFalse, indent2)) # 保存到文件 agent.save_workorder(workorder) else: print(“工单生成失败。”) print(f“{‘’*50}\n”)脚本核心解析response_format: {“type”: “json_object”} 这个参数至关重要它直接告诉vLLM/模型“请以JSON格式回复”能极大提高输出结构的稳定性。temperature: 设置为较低的0.1是为了减少生成内容的随机性让相同告警产生的工单尽可能一致这在生产环境中很重要。错误处理脚本包含了网络请求、JSON解析等多种异常处理确保系统的鲁棒性。可扩展性WorkOrderAgent类可以轻松集成到现有的运维平台或告警系统中通过API调用的方式提供服务。运行这个脚本你会看到针对三条不同告警模型生成了三份格式规整、内容专业的维修工单JSON。4. 效果展示与进阶优化让我们看看这个系统在实际中的表现。运行上面的测试脚本后对于“CNC-03主轴驱动器报警”这条告警你可能会得到类似下面的工单内容为模型生成示例{ “equipment_id”: “CNC-03” “alarm_code”: “ALM-501” “alarm_description”: “主轴驱动器过载保护报警” “phenomenon”: “CNC加工中心CNC-03的主轴驱动器触发ALM-501报警系统提示‘过载保护’。可能伴随主轴启动困难、运行中突然停机或扭矩不足等现象。” “possible_causes”: [ “主轴机械部分存在卡滞或负载过大如刀具磨损、切深过大” “主轴驱动器参数设置不当如加减速时间过短、电流限值过低” “驱动器内部IGBT模块或电流检测电路故障” “主轴电机绝缘不良或绕组短路” ] “suggested_actions”: [ “1. 立即停机检查主轴及刀柄是否有明显机械卡阻或异物。” “2. 查阅CNC-03的维护手册核对ALM-501报警的详细处理流程。” “3. 使用万用表测量主轴电机三相绕组电阻检查是否平衡。” “4. 进入驱动器参数界面检查并备份当前参数必要时恢复出厂设置或调整负载相关参数。” “5. 如上述步骤无效联系驱动器厂家技术支持。” ] “safety_notes”: “操作前必须切断设备总电源并上锁挂牌LOTO。确认主轴完全停止后再进行检测。注意驱动器电容放电。” “estimated_downtime”: “2” “required_tools”: [“万用表” “螺丝刀套装” “绝缘电阻测试仪”] “spare_parts”: [“主轴驱动器风扇备用” “动力线缆备用”] }效果分析信息提取准确正确提取了设备ID“CNC-03”和报警代码“ALM-501”。推理专业合理可能原因涵盖了机械、参数、电气等常见方面符合维修工程师的思维逻辑。步骤清晰可操作建议的处理步骤从易到难具有指导性。安全意识强安全注意事项提到了标准的LOTO流程这是工业安全的核心。格式完美输出是标准的JSON可以直接被MES制造执行系统或CMMS计算机化维护管理系统导入创建维修任务。4.1 如何让系统更强大这个基础版本已经能解决80%的常见问题。如果你想让它更智能、更贴合你的具体工厂可以考虑以下进阶优化方向知识库增强RAG将你的设备手册、历史维修记录、故障案例库做成向量数据库。当告警来时先从中检索最相关的3-5条资料和告警信息一起送给模型。这样模型的建议会更有据可依甚至能推荐过去成功的维修方案。工作流集成将WorkOrderAgent封装成一个RESTful API服务。当SCADA数据采集与监控系统或MES系统产生一条告警事件时自动调用这个API生成工单并推送给对应的维修班组。多模态输入如果告警信息包含设备状态图片或传感器波形图可以考虑使用通义千问的多模态版本如Qwen2-VL让模型“看图说话”诊断更精准。持续学习与反馈建立一个反馈机制。维修工程师在实际处理完故障后可以在系统里标记工单的诊断是否正确、建议是否有用。这些反馈数据可以用来微调Fine-tune模型让它越来越懂你的设备和工厂。5. 总结通过这个实战项目我们完成了一次完整的“AI赋能工业”的旅程。从选择适合工业场景的通义千问2.5-7B-Instruct模型到利用vLLM和Open WebUI轻松部署服务再到设计精妙的提示词和编写集成脚本最终构建了一个能自动理解告警、生成专业维修工单的智能系统。这个系统的价值是显而易见的效率提升将工单填写时间从分钟级缩短到秒级让工程师更专注于维修本身。知识沉淀将资深专家的经验固化到模型中避免因人员流动导致的知识流失。标准化确保每一张工单都格式统一、内容完整便于管理和分析。7x24小时值守AI不知疲倦可以实时处理夜间或节假日的告警第一时间生成初步方案。最重要的是我们使用的全部是开源、可商用的技术和模型部署成本低自主可控性强。你可以以此为基础将它扩展到质量检测报告生成、生产日志分析、智能巡检报告等更多智能制造场景中。AI不是要替代工程师而是成为工程师最得力的数字助手。从这个工单自动填写系统开始去探索和创造更多可能性吧。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。