企业官网建设流程全解析

去年年中，集团技术委员会把“要不要引入大模型”这件事正式摆上议程的时候，会议室里的气氛一点都不融洽。做工艺的老工程师觉得这玩意儿“连现场的设备编号都认不全”，数字化部门担心核心数据出网会出事，而我这个从互联网行业半路转过来的算法工程师，当时拍着胸脯立了个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 留下的五个场景

经过三轮筛选，最终留下的五个场景是这样的：

这五个场景的共同特点是有明确的使用者、有高频触点、有真实数据支撑。它们都不是“工业大脑”级别的宏大叙事，而是从一线最痛、最琐碎的地方切进去，先让模型成为一个“可靠的小工具”，再逐步扩大范围。

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 都花在能产生“吨钢效益”的地方。大模型从实验室到工厂，靠的不是一次炫技，而是一笔一笔算得清楚的账。