企业官网建设流程全解析

大模型在钢铁厂里到底能干什么？这是过去一年里我被问得最多的问题。很多人觉得“大模型写写文案、做做客服还行，工厂里谁用它？”直到我复盘了A钢集团“钢魂”大模型从实验室走到生产线的整个过程，才真正意识到：问题不在模型本身，而在我们怎么定义“能用”。这个项目最打动我的，不是某个惊艳的生成效果，而是一套非常朴素的账——Token消耗账。大模型进入工厂后，按Token计费这件事，把很多过去模棱两可的IT投入变成了清清楚楚的运营成本。今天这篇文章，我就从“钢魂”大模型的落地路径出发，把实验室与工厂之间的落差、Token经济如何重塑工业软件采购逻辑，以及实际部署中用到的调优手段，一次性讲透。

1. 从实验室到工厂：先想清楚大模型在钢铁场景里的真实位置

1.1 实验室里看能力，工厂里看可靠性

不管是钢铁、化工还是制造业，大模型项目最容易踩的坑，就是拿实验室的思维定义工厂的需求。在实验室里，我们看的是模型能不能答对问题、能不能生成流畅的文本；但在工厂里，稳定性、可解释性、成本边界才是第一位的。一个模型在演示环境下能把工艺规程背得滚瓜烂熟，真正上线后，面对一线操作工随手拍来的一张参数截图，能不能准确提取出“异常值”并给出判断依据，这才是关键。

我在A钢集团的项目里见到过一张需求清单，上面写得很朴实：质量异议报告自动归档、作业指导书问答、设备点检记录摘要、工艺参数异常原因分析。这些场景没有一个是“炫技”的，全是生产线每天都在发生的琐碎事。琐碎恰恰是难点，因为它们承载着真实业务，答案错了不是扣分，而是可能导致误判。所以第一件事不是选模型，而是把目标收敛成：用大模型替代什么、辅助什么、坚决不碰什么。

从“实验室到工厂”这句话，本质上是一个跨越工程化鸿沟的过程。实验室环境是理想化的，数据干净、算力充足、交互友好；工厂环境是约束性的，内网隔离、数据敏感、并发请求不均匀、回答内容需要被审计。如果不提前接受这些约束，模型再强也落不了地。

1.2 “钢魂”为什么选开源底座做私有化

A钢集团在做技术选型时，第一轮讨论就排除了直接调用外部大模型API的方案。原因很简单：工艺数据和生产参数属于内部敏感信息，不能出内网。而且钢铁行业的很多场景需要长期迭代知识库，如果采用按Token计费的公有云API，每个月消耗会是持续性的运营支出，很难预估。

最后他们选了一条更稳妥的路线：基于某个70B量级的开源底座模型，做私有化部署。选择开源底座的逻辑有三层。第一，数据主权可控，模型文件、权重、知识库全部落在自己的机房，不存在数据出域的问题。第二，微调和推理的边际成本会随硬件折旧慢慢下降，而不是按调用量线性上涨。第三，社区迭代速度快，底座模型升级后，可以重新微调甚至替换，不会被单一供应商锁死。

当然，开源不代表免费。A钢集团为此专门搭建了一套内网GPU集群，又配了向量数据库、检索服务和推理网关。选的底座模型也不是越大越好，因为他们评估过，一个700亿参数的模型虽然理解能力强，但单次推理时间和显存占用都偏高；最终折中之后，把底座定在了一个表现均衡的中型开源模型上，再配合检索增强来弥补容量不足。

2. Token经济：工厂大模型的钱从哪里来、花到哪里去

2.1 把Token当作大模型的“斤两”

聊大模型落地，绕不开Token这个词。Token是模型处理文本的最小单位，可以粗略理解为“字的碎片”。英文一个词可能对应一个或几个Token，中文一个字通常对应一个Token，复杂情况下一个字也可能拆成两个。大模型API的计费几乎都以Token为基本单位，输入有输入的单价，输出有输出的单价，上下文越长，一次调用的费用就越高。

为什么要用Token而不是字数？因为模型内部的计算量跟Token数强相关。输入的一句话要转成Token，模型才能进行注意力计算；输出的每个Token也都是逐步生成的，生成多少个Token，就代表做了多少次前向推理。Token本质上是算力消耗的刻度，把它当作大模型的“斤两”来理解，非常合适。

在“钢魂”项目里，Token不只是费用单位，还是一个很好的性能指标。比如两个模型在同样的评测集上准确率差不多，但一个平均输出300个Token，另一个输出600个Token，那前者的推理时延、GPU占用和单位成本都更有优势。所以后来我们所有的模型评测指标里都加了一条：平均输出Token数。

2.2 一条产线问答背后的Token账单

我在给团队讲Token成本的时候，习惯用一个具体例子来算账。假设一个一线员工向“钢魂”提问：“最近三天热轧带钢的边部缺陷比例上升，可能的原因有哪些？”

一次请求的内部构成大概是这样的：系统指令（定义你是一个钢铁工艺助手，回答要简洁，引用依据）约占200个Token；检索增强召回的3段相关知识，每段约500个Token，共1500个Token；用户问题本身约30个Token；模型输出答案约300个Token。也就是说，单次请求的输入Token大约是1730，输出Token约300。

如果按一个常见的大模型服务价格粗略估算，输入Token单价和输出Token单价不同，输出通常贵一些。即便按相对便宜的私有化推理成本去折算，一次问答的成本也在几分钱到一两毛钱之间。听起来不贵，但一个月如果有10万次调用，成本就是几万元。这还只是单一场景，如果把质量问答、报表生成、设备辅助全部铺开，Token消耗会迅速变成一个不容忽视的科目。

真正让成本失控的，往往不是用户的问题本身，而是被塞进上下文里的检索片段。很多初期的Prompt把整篇操作规程都放进去，看似让模型“读”了更多资料，实则浪费大量Token。后面我们做的第一轮优化就是控制检索返回的片段长度，只保留与问题最相关的段落。

2.3 Token经济对钢铁企业数字化采购的冲击

过去工业企业采购软件，要么是一次性License授权，要么是项目制实施费，买回来之后用多用少，钱都已经付了。Token经济的出现，把大模型服务变成了一种“用多少付多少”的资源，像水电费一样清晰。这在某种程度上是好事，它让IT投入与实际业务用量挂钩，但也给财务预算带来了全新的挑战。

A钢集团在“钢魂”上线三个月后，专门设立了一个叫“Token预算与成本看板”的科目。每个分厂、每个业务场景每月消耗多少Token，折算成多少钱，按部门分摊。这个做法倒逼各分厂开始认真对待提问质量：有人重复问同一个问题时，会引导先查知识库；有人把大模型当聊天工具使用时，后台数据会直接暴露出来。

Token经济也改变了甲乙双方的博弈关系。以前供应商做完项目就撤退，后续优化动力不足；现在模型服务的价值可以按Token流水持续观察，如何降低单位Token成本、提高有效Token占比，成了厂商和甲方共同的KPI。这种模式让工业AI从“交钥匙工程”变成了持续运营的服务。

3. 实操复盘：把“钢魂”落地到产线的五个硬核环节

3.1 数据准备：80%的时间都在跟数据较劲

如果说模型是引擎，数据就是燃油。“钢魂”项目启动的头两个月，几乎没有碰模型训练，全在整理数据。当时团队接到的任务很明确：把A钢集团某分厂近五年的工艺规程、设备点检标准、质量异议案例、作业指导书和操作规程全部收集起来做成知识库。

过程远比想象中琐碎。不同年代的文件格式五花八门，有的是Word，有的是扫描版PDF，有的表格里还套着图片。做OCR识别之后，错字、多栏排版、页眉页脚混排的问题层出不穷。最头疼的是版本管理——同一个操作规程可能出了七八个修订版，如果不对版本做标记，模型检索到旧版本内容就会给出错误答案。

我们的做法是先做一套数据清洗流水线：统一转成Markdown或纯文本，剥离页眉页脚，保留表格结构，用规则脚本识别章节标题，再按语义段落切分。切分长度一开始定得比较粗，后来发现500字左右一段比较合适，太长检索不准，太短上下文割裂。切分之后还要做人工抽检，抽检比例不低于5%，重点看有没有错误截断和敏感信息残留。

这里说一句大实话：如果数据没有清洗干净，后面花再多精力调Prompt都是白搭。A钢团队在项目中期换过一个更好的底座模型，但因为知识库质量过硬，效果提升非常明显。可见数据工程才是工业大模型项目最大的杠杆。

3.2 RAG与微调的取舍：先做检索增强，再做指令对齐

“钢魂”大模型没有直接拿业务数据去微调一个专用大模型，而是采用了“RAG（检索增强生成）+轻量微调”的组合方案。这个选择很关键。

RAG的核心思路是先从一个向量数据库中检索与问题相关的文档片段，再把片段拼进Prompt，让模型基于这些材料生成答案。好处是知识更新非常方便，新规程发布后只要导入知识库，模型立刻就能回答新内容，不用重新训练。对于钢铁行业这种规程频繁修订的场景，RAG几乎是必选。

但纯RAG也有问题：模型的回答格式不稳定，有时候会输出一大段话，有时候又过于简略。所以A钢团队又用几千条带标准答案的样例做了轻量微调。微调不是为了给模型“喂”知识，而是为了让模型学会该有的回答结构——先给结论，再列依据，最后标注不确定的地方。这个步骤我们称为“指令对齐”，成本不高，但效果立竿见影。

在实践中有个重要的先后顺序：先跑通RAG，再判断要不要微调。很多项目一上来就微调，把大量业务数据灌进模型，结果知识更新要重训，成本高还容易灾难性遗忘。先RAG后微调的路线，风险和成本都可控。

3.3 模型部署：内网里跑起来才是真本事

A钢集团的网络环境是典型的内网隔离架构，外网访问受限，所有模型文件、依赖库、镜像都要提前上传到内网仓库。这就带来一个很实际的部署问题：模型跑不起来，前面所有工作都等于零。

我们当时的部署方式可以简化为三层：最底层是内网GPU服务器，负责模型推理；中间层是模型服务网关，负责请求排队、并发控制、超时熔断；最上层是业务系统，通过标准API调用。为了让一线用户开箱即用，还封装了一个极简的问答界面，用户不用关心底层是模型还是知识库。

推理服务所用的框架和优化手段，基本决定了单卡能够支撑多大并发。我们做了三件事：一是开启动态批处理，把同时到达的多条请求合并成一次模型前向计算；二是控制最大生成长度，避免个别请求无限输出占住显卡；三是做接口级缓存，完全相同的问题在一定时间内直接返回历史结果。这三件事做完，单卡吞吐大约翻了一倍。

3.4 评测体系：没有评测集，模型上线就是赌运气

很多团队在大模型落地时忽略评测，觉得“看起来答得对就行”。但“钢魂”项目坚持建了一套评测集，这是我觉得最值得借鉴的地方。

评测集来源于真实业务：从三个分厂收集了1000条高频问题，覆盖工艺参数、设备维护、操作规程、质量异议四个大类。每道题不仅写了标准答案，还标注了所依据的知识库来源。评测时，系统会统计三项指标：答案准确率、知识来源命中率、输出格式合规率。准确率不是让模型背答案，而是看结论是否与标准答案一致；知识来源命中率则检查回答是否真的关联到了正确文档。任何一次模型升级或Prompt修改，都要先跑一轮回归评测，分数不低于上一版才能发布。

这个流程看起来很笨，但它让所有人都对模型能力有了共识。没有评测体系，你根本不知道一次微调是变好了还是变坏了，更没法跟业务部门解释为什么版本要升级。评测集本身就是最宝贵的项目资产。

4. 成本优化与Token管控的五条实战经验

4.1 Prompt瘦身：能少说一句就少花一份钱

系统指令不是越详细越好。我们见过一份系统指令写了800字，里面充满了“你是一个专业的钢铁工艺专家”之类的重复描述，这些内容每调用一次都要算费用。“钢魂”项目的系统指令后来压到了120字，只保留角色定义、回答要求、引用来源规范、拒绝回答策略四个要素。

除此之外，还砍掉了多轮对话中不需要的历史消息。很多业务场景只需要一问一答，没必要把前面几个来回的对话全部传给模型。去掉那些无关历史后，单次请求的Token消耗下降了40%左右，回答速度也变快了。

4.2 缓存与复用：把重复问题变成零成本

工厂里有一个非常典型的现象：同一个问题会被很多人反复问。尤其是月初月末出报表的时候，“上个月热轧工序的成材率是多少”这类问题可能出现几百次。如果每次都让模型重新生成，就是在重复花钱。

我们的做法是在API网关层加了一个语义缓存。所谓语义缓存，不是字符串完全一致才命中，而是把用户问题先做一次embedding，计算和已缓存问题的相似度，超过阈值就直接返回上次结果。配合一个合理的过期时间，这个缓存模块上线后，约20%到30%的重复请求不再产生模型推理开销。这类缓存对结果稳定性也有帮助，同一个问题不会再因模型随机性给出不同答案。

4.3 模型路由：简单问题别惊动大模型

引入模型路由是降低成本最有效的手段之一。我们在“钢魂”的网关里加了一个前置分类器，先用一个较小的模型判断问题类型和难度，再决定交给哪个模型处理。

比如“今天几点开班前会”这类事实性问题，根本不需要大模型生成，直接从知识库或工单系统查出来返回就行；再比如“某规程第几章提到加热炉温度上限”这类检索题，用中小模型加RAG就能回答；只有“综合多个质量案例推断缺陷原因”这类复杂推理问题，才路由到大模型。这种分层策略让大模型调用量下降了六成，而用户感受到的答案质量几乎没有下降。

4.4 限制输出与温度：别让模型自由发挥

大模型的输出Token是不确定长度的，同一个问题有时输出100字，有时输出500字。如果不加约束，成本就会随机波动。我们在所有业务场景里都设置了max_tokens上限，并针对报表生成类场景启用了结构化输出模式，让模型只返回固定字段。

另一个容易忽略的参数是温度（temperature）。温度高，模型更有创造性，但也会更啰嗦。在工艺问答这类任务里，我们直接把它调得非常低，模型输出变得更保守，错别字和无效内容明显减少。这个调整同时压低了平均输出Token数，一举两得。

4.5 长文本预处理：能检索片段就别塞全文

很多知识文档动辄几十页，完整塞进Prompt不仅浪费Token，而且会让模型“看不过来”，抓不住重点。RAG的初衷就是从长文档里检索出最相关的片段，但最初阶段，我们为了省事把整份规程塞给模型，后来看账单才发现，输入Token月开销涨了三倍。

优化措施其实很简单：调整检索策略，返回的片段数量从原来的6段降到了3段，每段长度也从500字缩减到300字左右。测试下来，答案准确率没有明显变化，但单次请求成本下降了50%。对于Token经济来说，精确检索比信息轰炸重要得多。

5. 常见问题与排查技巧实录

5.1 知识库明明有，模型就是答不上来

这是RAG系统最常见的问题。多数时候不是模型笨，而是检索环节没把正确内容找出来。

排查思路分三步：第一步，看用户问题对应的embedding向量和知识库片段的相似度分数，如果低于阈值，说明切块方式有问题。第二步，检查文档切块时是否把关键术语切散了，比如“终轧温度”被切成“终轧”和“温度”，检索时容易失配。第三步，引入混合检索，在向量检索的基础上同时做关键词命中，很多工艺术语和型号编码用关键词检索更准。A钢团队后来加了BM25关键词召回和重排序模型，这类问题的解决率大幅提升。

5.2 回答得很流畅，但数字是编的

工业场景最不能容忍的就是模型编数据。我们遇到过模型把“抗拉强度≥400MPa”写成了“≥450MPa”，句子通顺得完全看不出来，幸好被质检人员发现。

解决办法是强制模型在回答中给出知识来源编号，并且规定“无法从给定资料中找到数据时，明确回答不知道”。同时，在评测集中加入专门的“幻觉探测题”，把正确答案从知识库中挖掉，看模型会不会强行编一个答案。只要模型敢于回答“资料中没有相关数据”，这条就通过。这个策略执行后，一线工人对模型的信任度明显上升。

5.3 线上一波高峰，请求超时

工厂的业务节奏往往和班次相关，交接班前后会出现一波集中访问，智能助手请求量瞬间冲到平时的五倍，导致部分请求超时。

排查之后发现，推理服务没有设置合理限流，请求一多全堵在GPU队列里。后来在网关层做了两件事：一是配置并发上限，超过上限时直接返回“系统繁忙，请稍后再试”的友好提示；二是增加请求优先级，报表生成这类非实时任务让位给一线问答。这两招配合后，核心场景的可用性显著提升。

5.4 领导看Token消耗报表时最关心什么

很多项目汇报会陷入“我们消耗了多少Token”这种数据展示，但业务领导真正关心的是成本换回了什么。我们的经验是，Token报表必须和业务指标放在一起看：模型回答一次质量异议分析，能为质检工程师节省多少时间？日报自动生成，能让调度员提前多长时间拿到汇总？把Token消耗折算成“节省人天数”，领导一下就理解了。

A钢集团内部还做过一个有趣的对比：传统报表开发一个取数接口要排期两周左右，而用“钢魂”的对话式取数，通过自然语言生成结构化结果，快则当天就能完成初稿。这种效率差，才是Token经济最值得讲的账。

6. 从“钢魂”到Token经济：这场变革帮工厂想清楚了什么

6.1 大模型让工业知识第一次有了“可计量”的单位

过去企业做知识管理，很难衡量一份规程、一个案例到底值多少钱。知识放在档案室里，没人知道它是否被用过、用了多少次。大模型和Token经济改变了这一点。当我们把文档切块进知识库、被检索、被拼接进Prompt、最终生成答案的那一刻，知识的价值就能以Token消耗的方式被计量。

这听起来有些冰冷，但它反而促进了知识资产的活化。为了降低Token成本，各分厂开始主动清理过时文档、合并重复规程。知识库里的内容不再是“越多越好”，而是“越准越省”。Token像一把尺子，量出了哪些知识在用、哪些知识在沉睡。

6.2 对组织能力的要求变了

“钢魂”项目上线后，A钢集团信息化团队的人员结构发生了明显变化。以前主要招懂数据库、懂Java的开发人员；现在还需要懂Prompt工程、懂模型评测、懂Token成本控制的人。这不是追赶时髦，而是因为大模型系统的运营方式和传统软件完全不同。

一个很直观的例子：传统软件上线后，需求变更要走需求评审、开发、测试、发布流程，以周为单位；大模型系统上线后，知识库调整、Prompt优化可以当天完成，但必须建立一套配置管理和回归测试机制，防止改坏。这需要既懂业务又懂模型的人来当“翻译”。后续如果想在更多产线复制“钢魂”的经验，关键不是买更多显卡，而是培养更多的复合型运营人员。

我的个人体会是：大模型进入工厂这件事，最大的门槛从来不是模型精度差那么一两个百分点，而是成本不可控、效果不可信、责任不可追。A钢集团用“钢魂”大模型趟出的这条路，核心思路其实很朴素——把模型当作一种需要计量和管理的资源，用Token经济倒逼所有环节走向精细化。如果你也在做类似的工业大模型项目，建议从第一天就把Token成本纳入架构设计，而不是等项目上线之后再来补功课。