去年年中集团技术委员会把“要不要引入大模型”这件事正式摆上议程的时候会议室里的气氛一点都不融洽。做工艺的老工程师觉得这玩意儿“连现场的设备编号都认不全”数字化部门担心核心数据出网会出事而我这个从互联网行业半路转过来的算法工程师当时拍着胸脯立了个flag——给我半年时间跑不通一个真正在产线上用的场景就算白干。后来的事说句实话有打脸的部分也有超出预期的部分。半年之后内部代号“铁芯”的大模型系统确实在一个钢铁联合企业的几条关键产线上跑了起来从设备故障辅助诊断到操作规程问答从质量报告生成到检修方案起草都有了一线员工在用的真实案例。这篇文章想聊的不光是“我们怎么把大模型部署进了工厂”这件事本身更想聊聊在推进过程中反复想明白的一个问题大模型从实验室走到工厂真正的障碍不是模型能力而是我们对待“成本”和“价值”的方式——也就是标题里说的“Token经济”。钢铁行业的特点很适合用来讲清楚这件事因为这里的每一项投入都以“吨”和“分钟”来精确计算一个 Token 花得值不值产线会给你最诚实的回答。1. 实验室和工厂之间的那道墙先说一个反直觉的观察。很多做 AI 的人以为大模型进工厂就是把一个类似 ChatGPT 的界面接到内部系统上剩下的问题无非是“Bug 改不改”“算力够不够”。真正下场之后才发现实验室和工厂之间隔着的不是一堵墙是三道墙数据墙、环境墙、评价墙。这三道墙不拆掉模型再强也落不了地。1.1 数据墙互联网语料和钢铁语料是两个世界我们最初拿到的“企业知识资产”听起来很丰富五百多份工艺规程、几年的设备点检记录、上千份质量异议报告、操作手册、事故复盘纪要、甚至还有老师傅手写的异常处理笔记。但这些东西和互联网语料完全是两个世界。互联网语料是海量的、冗余的、有标准答案的钢铁工业数据是分散的、残缺的、格式极其混乱的。工艺规程有 Word、有老旧的 PDF 扫描件还有从 DOS 时代系统里导出的文本质量异议报告里的缺陷描述充斥着方言和行业缩写比如“中包”“拉速”“炉况”“烂边”这些词在通用语料里出现频率极低大模型根本没见过几次。更要命的是这些数据的知识密度极低。一份设备点检记录里大量内容是“正常”“参数正常”“无异响”偶尔出现一条“二段电流偏高已通知电工待观察”这条往往才是最需要模型学习的“微弱信号”。可模型从数据里看到的是一片模糊的背景噪音。我们后来做了一个很笨但很有效的动作把喂给模型的数据当作“给新员工培训的教材”来把关而不是当作“语料”来处理。任何一段数据如果新员工看了不能迅速理解现场情况就不配进知识库。这个标准让数据治理工作从“清洗”变成了“策展”非常耗时但第一批高质量的领域问答对就是从这些策展后的材料里一点点攒出来的。1.2 环境墙私有化部署不是选择题而是必答题第二条墙是环境墙。我们最早做技术选型时最省事的路线是调用云端大模型 API效果好、迭代快、不用管推理集群。但这个方案在评审会上被秒否了原因不是成本而是安全。厂内网络和外部互联网之间是物理隔离的核心工艺参数、设备运行状态这些数据一旦出了内网不管有没有脱敏责任上就说不清楚。所以私有化部署成了唯一选项。这意味着我们要自己在厂内的 GPU 服务器上跑开源基座模型自己管推理服务自己维护向量库自己处理并发和容灾。今天回看这个“被动选择”反而帮了我们——正是因为不能随时偷偷调云端模型我们才被迫把 RAG、微调、推理优化这些工程细节做扎实了。如果当初贪图方便走了 API 路线项目大概率会卡在“数据能不能出网”的拉锯战里动弹不得。1.3 评价墙从“分数好看”到“产线好用”第三道墙是最容易忽视的——评价体系完全不同。在实验室里我们习惯用评测集分数、用“回答是否符合标准答案”来评判模型好坏。但在工厂里操作工和工程师根本不关心分数他们只关心一个问题你给我的回答能不能让我少跑一趟现场能不能帮我少一次停机能不能让我少打一个电话问老师傅。这就带来一个很实际的矛盾模型回答得“流畅、完整、结构化”在实验室是最低要求在工厂现场却可能导致不信任。工人看到一个花团锦簇的长篇回答第一反应不是“好厉害”而是“这玩意儿在绕什么弯子到底让我干嘛”。我们后来甚至不得不专门调整输出风格把答案压到最朴素的几条指令式内容让操作工扫一眼就能执行。这个经历让我彻底明白工业场景里的大模型评价指标始终应该是“决策时间缩短了多少”“行动准确率提高了多少”而不是“语言生成质量有多高”。2. 场景筛选从37个候选砍到5个的取舍逻辑项目启动后我们做了一个很“互联网风格”的动作全集团征集大模型应用场景。结果收集上来 37 个。紧接着我们就踩了一个典型的坑——试图在所有场景上“铺开做”。两周之后团队发现这 37 个场景里没有一个是容易做的全部都要重新整理数据、全部要对接系统、全部要处理安全合规。如果平均用力半年后大概率是 37 个半成品。于是我们设了三个硬性筛选条件很不客气地砍掉了绝大多数。2.1 三个筛选条件高频、高价值、可量化第一个条件是高频也就是场景本身一天之内会被反复使用而不是一个月才碰一次。一年用十次的功能就算做得再惊艳也养不起持续迭代的团队。第二个条件是高价值单次使用的价值或节省的隐性成本要足够大大到可以覆盖模型推理、维护、人工核验的综合成本。第三个条件是可量化场景的收益必须有明确的度量口径比如故障定位时间缩短了多少、报告撰写时间从多少分钟变成多少分钟而不是“感觉效率提升了”。这三个条件听起来很普通但执行起来非常苛刻。我们举一个反例有人提出要做“制度文件智能审核”听起来很有价值但盘点之后发现全集团一年只审几百份文件频率太低而且审核责任重大模型只能做辅助初筛价值很难量化最后被一票否决。2.2 留下的五个场景经过三轮筛选最终留下的五个场景是这样的场景核心功能价值度量设备故障辅助诊断操作工描述设备异常现象模型返回可能原因和排查顺序故障定位时间缩短、非计划停机减少操作规程智能问答基于 RAG 检索工艺规程原文回答操作类问题查询时间缩短、操作规范率提升质量报告自动生成质检工程师录入缺陷关键词模型生成结构化报告初稿报告撰写时间从约 40 分钟压缩到约 8 分钟检修方案生成依据检修历史数据和设备状态生成检修项目清单初稿检修方案编制周期缩短能源调度辅助分析结合产线数据和能源计划提供调度调整建议单位能耗分析效率提升这五个场景的共同特点是有明确的使用者、有高频触点、有真实数据支撑。它们都不是“工业大脑”级别的宏大叙事而是从一线最痛、最琐碎的地方切进去先让模型成为一个“可靠的小工具”再逐步扩大范围。2.3 砍掉的场景为什么自动排产不是大模型的菜被砍掉的场景里最有意思的是“大模型自动排产”。一开始团队内部很多同事对它寄予厚望理由也很有说服力——排产涉及大量约束规则和历史经验老师傅排一个星期的计划要花半天大模型看起来很适合“综合考虑各种因素”。但我们做了几次原型测试之后确认这条路在现有技术条件下走不通。原因很本质排产本质上是一个组合优化问题核心是满足约束条件下的目标函数最优化这是运筹学算法擅长的领域而不是大模型擅长的领域。大模型可以“解释”排产结果、可以“辅助输入约束”但如果让它直接输出可执行的排产计划它给出的结果要么违反设备能力约束要么忽略物料衔接关系哪怕是看起来“运气好”能跑通也难以处理突发变化后的动态重排。这个教训让我学会了一个重要的取舍思路不要因为某个场景“听起来很智能”就去做而要看该场景的核心难点到底是什么。大模型擅长的是“理解语义、检索知识、生成文本”场景的核心难点如果是这三件事就非常适合如果核心难点是精确计算、约束优化、实时控制那么大模型只能当配角强行让主角干配角的活结果一定很难看。3. 系统架构私有化底座 RAG 微调的三层搭配技术方案上我们最终采用的不是“全套微调”也不是“纯 RAG”而是“开源基座模型私有化部署 RAG 检索增强 轻量级领域微调”的三层组合。这个架构今天看不算新鲜但在一开始团队内部对“微调还是 RAG”这个问题吵了很久。3.1 底座选型与部署底座模型的选择标准只有一条在国产硬件上跑得动、跑得稳。我们测试了几个开源基座结合厂内可用的 GPU 资源和推理延迟要求最终选了 72B 级别的模型量化到 INT8部署在厂内的 GPU 服务器集群上。这里有一个非常关键的实操细节不要迷信“模型越大越好”。在一个 72B 模型和一个 32B 模型之间如果 72B 的推理延迟超过操作工的忍受阈值那么它再聪明也没用。一线工人点开一个问答界面等 3 秒还能接受等 8 秒就会直接关掉切回电话咨询。我们实测下来单机 4 卡部署 72B INT8 模型开启动态批处理之后能支撑约 80 路并发问答首 token 延迟控制在 0.8 秒左右基本满足现场使用要求。3.2 RAG 和微调的“分工”RAG 负责“知识的获取”微调负责“行为的塑造”。这两者的分工非常明确不要混在一起。知识获取方面我们把工艺规程、设备手册、历史工单、质量异议报告等文档清洗后切片入库。这里要强调一个容易踩坑的点切片策略不能只看字符数要结合文档的语义结构。钢铁行业的规程文档有大量表格、公式、嵌套标题如果按固定 512 字符硬切会把完整的一条操作要求切成两半也会把表格的上下文切得七零八落。我们后来改成“标题感知切片 表格单独建块 混合检索引擎”先按章节目录结构切大块再在大块内部按段落和表格边界切小块检索时把同一文档下的相关切片按父子关系拼回上下文效果提升非常明显。行为塑造则靠微调。我们收集了大约 1.5 万对领域问答数据做了 LoRA 微调重点不是让模型“学到更多知识”而是让模型学会“像钢铁工程师一样说话和思考”。比如面对“连铸机拉速怎么调”这种问题不微调之前的模型会给出百科全书式的通用回答微调之后的模型会追问“当前钢种、断面尺寸、中包温度是多少”这个追问习惯是从分析大量现场问答记录里学来的。后续又做了一轮偏好对齐让模型学会在信息不足时主动提问而不是硬凑一个答案。3.3 推理调度和并发控制推理侧的工程问题同样不能马虎尤其是并发控制和故障隔离。我们遇到过一个很典型的线上问题早班高峰时段操作工集中上线使用故障诊断助手并发请求从平时的一二十路瞬间跳到四五十路推理引擎显存溢出整个服务重启正在处理中的请求全部丢失。这个事故让我们补了一整套限流和降级机制——为重要场景保留独立实例、给次要场景设置最大并发数、在服务过载时优先保证“操作规程问答”这种安全相关场景的响应而不是让所有场景互相抢资源。另外上下文窗口的管理也值得说一句。在工业场景里检索回来的知识片段往往很长加上历史对话记录很容易撑满上下文。我们做了一个很朴素的策略对话窗口固定为最近 8 轮更早的对话内容只保留摘要检索回来的知识片段按和问题的相关性分数排序只取得分最高的前 4 段拼入上下文宁可少给信息也不让模型被无关内容干扰。4. “Token 经济”这杆秤大模型在工厂里怎么算账聊完架构我想重点展开标题里提到的“Token 经济”。这个词不是某个学术概念而是我在项目里反复算账时逐渐形成的一个理解框架大模型进入工厂本质上是在建立一种新的价值计量与交换方式。4.1 Token 是什么为什么说它是大模型的“货币”Token 是模型处理文本的最小单位中文里的一个词会被切成一到多个 Token一行代码也是。我们日常使用的 API 调用按 Token 计费Token 因此在某种意义上成了大模型世界的“货币单位”——输入多少、输出多少直接决定了单次调用的成本。但在工厂场景里Token 的意义不止于此。它还是一个“知识消费单位”。当一段工艺规程被切块入库当一次对话把相关知识片段调到上下文窗口当模型基于这些片段生成回答每一个环节都在消耗 Token。换句话说Token 消费量可以精确地衡量“一次知识服务消耗了多少算力资源”这让“知识服务的成本核算”第一次变得可以计算。4.2 工业场景的 Token 账本在项目推进过程中我们专门建了一个“Token 账本”把五个场景的真实消耗记录下来。以设备故障辅助诊断为例一次完整问答输入侧包含操作工描述约 200 Token、检索回来的知识片段约 1500 Token、历史工单上下文约 800 Token输出侧生成答案约 400 Token合计约 2900 Token。按照当时的私有化算力折算成本一次问答的综合算力成本在一块钱到两块钱之间算力摊销 电力 维护现实成本比很多人想象的低得多这也是大模型落地的底气之一。这笔账要放在工业价值的天平上称。在项目试点产线操作工用这个助手做故障排查平均定位时间从原来的约 45 分钟缩短到约 20 分钟。一条热轧产线非计划停机一个小时综合损失在几十万元量级哪怕这个助手一年只在十次异常处置中让定位时间缩短了 15 分钟算下来的收益也远超它一年的全部 Token 消耗。更不用说质量报告生成场景把报告撰写时间从 40 分钟压缩到 8 分钟省下来的工程师时间直接转化为更快的质量异议响应。4.3 Token 经济的三个启示第一层启示是成本结构的改变。大模型按 Token 计费的模式让“向 AI 提问”不再是买一套软件安装到电脑里的固定成本而变成了一种按使用量弹性变化的服务成本。对一个年度预算需要精确控制的钢厂来说这意味着可以用“每百次调用成本”来匡算智能化改造的投入产出而不是像传统工业软件那样“先投一笔大钱、再看什么时候回本”。第二层启示是知识资产的量化。老师傅脑海里的经验、工艺规程里的条款、历史工单里的解决方案过去都是无法被计量的“隐性知识”。现在它们被转写成文档、切块入库、被检索、被消费每一次调用都在消耗 Token。从这个角度看Token 经济真正改变的是“知识价值的计量方式”——钢厂第一次可以知道自己积累的“和既往经验知识资产”每天被调用了多少次、创造了多少可衡量的价值。第三层启示是要警惕“Token 陷阱”。Token 消耗不等于价值创造。如果模型回答本身不靠谱消耗的 Token 就是纯浪费如果答案很流畅但误导了操作工甚至可能造成比没有模型更大的损失。所以在关键场景里我们给系统加了一层“底线规则”涉及安全、涉及操作指令的回答必须检索到规程原文并引用否则直接拒答。Token 可以花但不可以花在“一本正经地胡说八道”上。5. 踩坑实录术语、OCR、语气和安全红线任何一个工业 AI 项目不踩坑是不可能的。这一节我挑几个印象最深刻的坑把排查过程和解决办法写清楚这些细节在常规的技术文档里很难看到。5.1 术语不落地一本正经地胡说八道上线初期我们遇到最搞笑也最头疼的问题是模型对钢铁行业术语的理解经常“差一点点”。它能正确说出“连铸”“钢坯”这些常见词但对“炉况”“脱磷”“精炼”“中包”“烂边”这些更专业、更口语化的词汇回答经常跑偏。有一次测试“轧辊磨损怎么处理”模型给了很长一段关于“轧辊保养周期”的通用建议几乎全是废话。后来查了一下底层原因很简单基座模型的预训练语料里这些专业词组出现的比例实在太低了模型本身对它们的语义边界就是模糊的。解决办法分两步走。第一步是构建行业词表把高频术语、设备编号规则、常见缺陷描述整理成词典在检索阶段做术语归一化比如“中包”和“中间包”要统一映射“拉速”要能关联到“拉坯速度”第二步是在微调数据里刻意加入一批“术语纠错”样本展示“面对术语模糊时应该追问而非猜测”。这两步之后术语相关回答的准确率有了肉眼可见的提升。5.2 老文档 OCR扫描件、繁体字、歪斜表格钢铁企业有大量历史文档是纸质扫描件很多还有繁体字、表格歪斜、印章遮挡的问题。我们用通用 OCR 跑了一遍效果惨不忍睹“连铸机”被识别成“连铸札”“操作规程”变成“拱作规程”。这类错误一旦进入向量库检索出来的知识片段就是“垃圾进、垃圾出”模型再聪明也救不回来。这个坑的教训是在工业知识库建设里OCR 不是“锦上添花”而是“生死攸关”。我们换成了基于视觉大模型的文档解析方案对表格结构、标题层级、混排文本的识别能力强了很多然后再加一层人工抽检闭环——每解析完一批文档抽 10% 由业务人员进行核对发现错误返回重新解析或者手工修正。步骤繁琐但为了保证知识库的“纯度”这一步绝对不能省。5.3 客服腔调 vs 老师傅语气这个问题特别有意思。模型默认的输出风格是“客服腔”——礼貌、周到、绕弯子。比如操作工问“这个故障能不能继续生产”模型回答“建议您结合现场实际情况综合评估设备当前状态必要时停机检查以确保安全并避免潜在风险”。这话听着没问题但工厂老师傅的反应是“废话。我当然知道要看情况我问的是你”操作工要的不是免责声明式的车轱辘话而是“这个情况建议优先检查液压系统压力如果压力正常再查润滑单元”。经过几轮反馈我们专门做了一批“指令式语气”微调数据和提示词模板要求输出结果包含“建议动作 检查顺序 注意事项”三个部分每个部分用最简单的话说清。这个改变的价值比我们做的大部分模型优化都高。5.4 安全边界允许胡说但不允许在安全问题上胡说最后说安全。钢铁产线的安全红线非常明确涉及安全操作规程、涉及可能导致人身伤害或重大设备损坏的操作指令模型绝对不允许自由发挥。这是原则问题。技术上怎么实现我们在系统里加了一个轻量的“安全规则前置引擎”。所有用户问题先过一遍规则引擎如果命中安全相关关键词比如“煤气”“高压”“停机”“动火”等就会强制走“检索原文 原文引用 原文摘录”的生成路径模型只能基于检索到的规程内容做摘要和结构化不能新增任何内容如果检索结果不足直接回复“未找到相关规程请咨询当班安全员”。宁可让模型“变笨”也不能让它“闯祸”。这个底线规则上线之后各类评审和一线员工的信任度都明显提升。6. 落地之后的一些思考大模型对制造业真正的改变项目从启动到产线试点再到小规模推广前后将近九个月。系统上线之后我常常在工厂的集控室里站一会儿看操作工用平板电脑对着设备输入故障描述、看模型给出排查建议。那个画面的震撼感比任何技术指标的达成都要强烈。6.1 老师傅的经验第一次有了“计量单位”钢铁厂的生产经验传统上是“人传人”的老师傅带徒弟、看火色、听设备声音、摸振动。这种经验非常珍贵但也非常脆弱——老师傅退休经验就大量流失。而在“铁芯”项目里一部分经验被转化成了文档、问答对、检索片段的组合存储在知识库里通过 Token 计量被每次调用消费。这并不是说模型“替代了老师傅”而是说老师傅的经验多了一种“数字化分身”。操作工在深夜班、在老师傅不在场的时候依然可以调用“虚拟老师傅”的经验。从某种意义上说Token 经济让“知识的传承”从口耳相传变成了可检索、可计费、可规模化调用的数字资产。这是我认为大模型带给制造业最深远的东西。6.2 技术不是壁垒数据和场景才是这个项目做到后期我发现算法团队能做的优化越来越有限真正决定系统上限的是数据和场景。我们用的基座模型是开源的微调技术也是公开的RAG 架构更是业界标准——没有什么别人学不会的秘密武器。但“把一份 20 年前的手写点检记录整理成结构化知识库”“让一线工程师愿意每天使用并反馈错误”“把安全规则引擎和现有工单系统无缝对接”这些苦活累活才是真正的护城河。这也解释了为什么大模型在制造业的落地不应该是“技术驱动”的而应该是“数据和场景驱动”的。模型能力会快速同质化但每个工厂独特的数据积累、业务流程、组织文化和一线使用习惯才是无法被复制的东西。6.3 组织协同算法工程师不能孤军奋战最后说一点个人体会。这个项目里最让我意外的不是技术难度而是组织协同的难度。算法团队可以在几天内搭出一个 Demo但让设备工程师愿意把自己的排查思路讲出来、让操作工愿意在故障时先问助手而不是直接打电话、让安全部门认可“机器给的答案可以作为参考”——这些建立信任的过程远比写代码耗时。我的体会是做工业大模型项目的算法工程师不能只把自己定位成“模型训练师”更要把自己当成“知识翻译师”——把业务专家的隐性经验翻译成模型能学习的数据把模型的能力翻译成业务人员能听懂的功能把 Token 消耗翻译成老板能看懂的投入产出。翻译得好项目就成了翻译得不好技术再强也是自嗨。回头看这九个月“铁芯”大模型谈不上什么惊天动地的创新它只是把一件件枯燥的、琐碎的、不那么“性感”的工程活做扎实了。如果非要说有什么经验值得分享那就是别急着追模型参数先搞清楚你要解决的问题到底值多少钱每一个 Token 都花在能产生“吨钢效益”的地方。大模型从实验室到工厂靠的不是一次炫技而是一笔一笔算得清楚的账。