能源和资源行业做数字化和互联网完全是两个脾气。我见过太多装了MES、ERP、SCADA、EAM的企业报表中心一个比一个漂亮领导驾驶舱做得跟电影海报一样但基层员工每天还是靠Excel和微信群干活老师傅的经验躺在一堆PDF规程里新来的年轻工程师查一个阀门型号要翻三个系统。这两年大模型火起来以后我们就在琢磨一件事能不能用大模型加云原生的方式把积累了十年的老系统重新做成一个真正能提效、能落地的“数字底座”。这篇文章就是记录我们团队在能源行业实际做的一次重构试点架构怎么设计、模型怎么选、验证怎么做、坑怎么踩全是实战内容。文章适合三类人看。一是能源、钢铁、化工这些重资产行业的IT和数字化负责人你们最想知道大模型到底能不能落地、怎么落地二是想从互联网转行到产业AI的算法和架构工程师可以看看真实产业环境里大模型是怎么玩的三是正在做类似“数字底座”项目的朋友可以参考我们的技术选型和验证方法少走几个月的弯路。1. 先看业务痛点老底子为什么撑不住1.1 几十套系统垒出来的“纸糊底座”能源企业的数字化现状其实相当割裂。生产端有SCADA和DCS设备侧有EAM和点检系统经营侧有ERP和财务共享安全上还有双重预防机制、两票三制系统。每套系统背后都有一个甚至多个厂商每套都有自己的一套账号、组织架构和数据字典。比如同样是“1号机组”在EAM里叫“#1机组”在SCADA里叫“UNIT_01”在调度报表里叫“一号机”数据想要打通根本没有公共主数据去对齐。这还不算Excel表单和微信工作群里的那一大堆线下数据。这导致的直接结果是什么是数据量很大、报表很多但真正要回答一个业务问题的时候特别费劲。比如领导问“这个月非计划停机的主要原因是什么”你少说得花两三天把调度记录、检修台账、缺陷单、设备报警历史翻一遍才能拼出一个答案。而且这个答案是“拼”出来的不是系统给的。换句话说老底子是“记录系统”不是一个“决策系统”。数字化转型走到现在大家不缺系统缺的是怎么把系统里的数据变成能力。1.2 大模型和云原生为什么是这一轮的关键变量大模型跟以前的AI不太一样。以前的AI在能源行业也有落地比如设备振动信号的异常检测、能耗预测、图像识别仪表读数都是单点、窄域、任务型的训练一个模型只能干一件事很难跨场景复用。大模型的特点是通用理解能力你不需要为“读懂一句话”单独训练一个模型它的语言理解、抽取、生成、规划能力是通用的。这就让“统一底座承载多种智能应用”成为可能这也是“数字底座”这个概念真正能落地的关键。但如果只是有模型远不够。能源企业的数据是敏感的内部生产数据不可能直接丢到公有大模型API里。这就带来两个问题一是模型要能在自己的私有环境里跑二是推理这种大计算量的服务要像传统微服务一样被调度、扩容、灰度发布。这两点正好都是云原生擅长的事——GPU资源池化、容器化部署、弹性伸缩、可观测性。所以我说“大模型云原生”不是时髦的拼盘它是产业智能化的必经路径大模型提供智能云原生提供算力底座和工程化能力。2. 数字底座的技术选型与架构设计2.1 底座分几层每一层放什么我们最终把底座分成了四层四层各有各的职责谁也不能混。第一基础设施层。K8s集群是必须的GPU节点单独规划用NVIDIA的GPU Operator来做驱动和容器运行时管理存储用并行文件系统挂载模型权重避免每次拉起推理服务都重新加载一次模型文件。这一层还要解决一个容易被忽视的问题GPU虚拟化和切分。很多能源企业的GPU资源并不宽裕一台A100可能同时要被好几个业务用所以vGPU能力特别重要。我们试过NVIDIA MIG也试过k8s-device-plugin配合显存配额实际用下来MIG隔离性好但切出来的显存碎片化问题要提前规划好。第二数据层。数据底座不光是原始数据入湖入仓更关键的是知识化。我们要把文档、规程、工单里的数据抽取成结构化实体和关系然后向量化存到向量数据库里。这里我多说一句向量库不是万能的它是给大模型做记忆用的真正的权威数据还是要靠关系库和数仓里的业务数据。所以我们做的是“湖仓向量库业务库”三库并用各自发挥优势RAG拿到的是加工后的上下文最终回答再通过引用来源去关联业务数据避免大模型一本正经地胡说八道。第三模型层。底座的“大脑”就是这一层。模型的选择我们后面单独说这里强调的是模型治理要有模型仓库要有版本管理要能同时运行多个模型服务要能对模型做A/B测试。推理引擎我们选的是vLLM吞吐量在对比测试里比TGI和原生FastAPI推理高出好几倍尤其是并发请求上来以后优势更明显。量化方案我们选的是AWQ 4bit精度损失在业务场景里几乎感知不到显存占用直接砍掉一大半。第四应用层。这是业务看到的东西了。上面跑着智能问答、报告生成、辅助决策、Agent编排这些应用。应用层最重要的是有一套统一的Agent编排框架让模型、工具调用、知识库、业务系统互相配合。比如我们做一个“检修工单智能复盘”的应用就是让Agent先调用工单查询API拿到过去一个月的检修记录再检索知识库里对应的故障案例最后生成复盘报告草案这三步完全编排在一个工作流里。后面如果要做“看图问检修”把设备照片和红外热像图接进来也是在这一层扩展。2.2 模型到底选多大显存到底怎么算大模型选型绕不开参数量。我们当时在7B、14B和72B之间纠结了很久。这里给一个非常实用的显存估算方法大家可以直接抄作业推理的时候FP16精度下每个参数大约占2字节的空间再加上KV Cache和激活值实际用下来大概是参数量乘以3到4。比如14B的模型FP16权重约28GB做4bit量化后权重部分约7GB加上KV Cache和运行开销一张24GB的卡跑起来比较轻松72B的模型量化后约36GB一张80GB的A100/H100能塞得下但要跑得很舒服最好还是双卡做张量并行。我们的结论是如果业务以知识问答、文档抽取、自然语言交互为主14B级别经过良好微调和RAG已经能满足大部分需求不一定非要上72B。这不是说模型越大越好而是要考虑能源行业常见的成本约束和推理延迟。我们两个测试场景一个用14B一个用72B用户主观评分差不了太多但成本差了将近五倍。后来我们干脆把72B留作离线数据分析在线业务全部走14B这个决策帮我们省了不少钱。这里也要提醒一句模型选择不要只看跑分要看你们业务文档的领域术语密度。如果行业词特别多比如地质报告、化工工艺、电网调度术语一定要先做一个小样本的词表覆盖测试再决定底座模型和下不下重金微调。开发阶段我们还会用Ollama做单机快速验证一条命令就能把模型拉起来适合开发人员先调通接口和提示词。但生产环境还是vLLM因为Ollama在高并发和K8s集成上不够灵活这是两套工具链各自分工别混着用。2.3 云原生和推理服务的结合方式这一节讲讲工程细节。我们用Kubernetes部署推理服务有几点经验值得分享。第一个是推理服务的弹性扩容策略。大模型推理不像普通Web服务CPU跑不动必须GPU。而GPU是稀缺资源应对突发流量不能直接开几十个副本太贵。我们的办法是核心业务用的推理服务保持常驻用HPA按GPU利用率和排队请求数双指标做弹性伸缩查询量少的时候缩到1个副本上班高峰扩到3到4个。排队请求数这个指标我们自己通过Prometheus暴露出来比仅看GPU利用率灵敏得多因为GPU利用率有滞后性。第二个是请求队列和超时控制。vLLM天然支持并发但当所有GPU都在忙时后续请求会排队排队超过一定时间用户就会觉得卡。我们的做法是在网关层给每个推理请求设置30秒超时超过直接返回一个降级结果比如提示用户“当前系统繁忙请稍后再试”并异步记录日志后续再做重试。这个小设计在真正上线后救了我们不少次重活压进来的时候用户反馈比之前动不动浏览器转圈等一分钟强多了。第三个是灰度发布。模型更新是高风险操作今天上线的模型可能因为微调数据质量问题生成质量还不如旧版本。我们的做法是将新旧两个模型服务同时挂在K8s Service后面通过流量切分逐步放量先放5%到10%的真实流量到新模型观察人工打点和自动监控指标确认没问题再全量切。实测下来这套流程把“模型升级出事故”的概率降了一个量级。3. 落地验证从设备检修知识助手这一个场景说起3.1 为什么选设备检修知识助手做第一个场景做技术验证最怕的就是选一个没有业务价值、没有数据、没法量化的场景。我们选“设备检修知识助手”是经过层层筛选的原因有三。一是知识密集。电力、煤炭、石化这些行业设备检修是典型的知识密集型工作光一个电厂汽轮机、发电机、锅炉、电气系统、热控系统的检修规程加起来就是几千页。老师傅经验丰富一句话能定位问题但新员工只能从头翻规程。这个场景天然适合大模型做知识问答。二是业务痛感清晰。我们在调研的时候和一个检修班班长聊他说最大的痛点不是缺数据是查数据太难了。检修的时候图纸、规程、历史缺陷单、厂家说明书分布在不同的系统里甚至有不同的介质形式纸质版、电子版、扫描版、照片都有。老师傅可以凭记忆新员工只能满地找。这让我们很确定这个场景做出来一定有人用。三是结果可以验证。问答任务是有对错标准的我们可以出测试集用准确率、覆盖率、引用正确率这些指标来评估系统效果而不是泛泛地讲“效率提升”。3.2 从数据到上线我们做了哪几步第一步数据准备。数据质量决定RAG效果的下限。我们联合生技部和检修分场把汽轮机、发电机、锅炉三大主机的检修规程、操作票、历史缺陷工单、厂家技术资料全部收上来。有PDF、Word还有扫描件优先识别成文本实在识别不了的做OCR再用规则和大模型混合的方式做清洗和信息抽取把每份文档的标题、章节、适用设备、检修步骤、风险点切成一个个信息块打上设备类型和系统标签然后向量化。这个过程最花时间的不是模型而是数据标注和清洗差不多占了整个项目时间的四成。第二步搭建RAG检索。我们一开始用的是纯向量检索效果一般因为领域术语多同义词和简称多比如“给水泵汽轮机”简称“小机”在向量空间里检索“小机跳闸”和“给水泵汽轮机故障”的相关性就很不稳定。后来从社区借鉴了一个成熟方案混合检索向量检索加BM25关键词检索再加一个rerank模型把两者结果合并重排。改完之后检索Top20的命中率从68%提升到89%这是一个非常明显的进步。第三步提示词和输出约束。一问一答的模式太初级我们做了任务拆分先判断用户问题是设备缺陷、操作规程还是知识学习然后交给不同的提示词模板处理。回答中要求模型必须输出引用来源引用不了就直接说不知道。这个“强约束”是大模型在企业场景里必须做的设定否则模型容易生成一篇一本正经但根本找不到依据的内容业务人员用几次就不用了。我们还做了提示词注入的基础防护测试比如有人故意让系统忽略已有知识库只输出模型自带的通用知识我们要能识别并拦截这类异常请求。第四步微调。在这个场景里我们没有一上来就微调因为RAG已经解决了大部分领域知识问题。后来我们发现两个必须微调的痛点一是模型不熟悉设备编号和术语比如“TSI系统轴振超标”模型能理解“轴振超标”但不理解“TSI”在业务里指的是汽轮机监测仪表系统经常解释得很外行二是生成报告的格式严重不符合行标生成出来的检修报告结构和实际工单差得远。这时候微调就派上用场了。我们用一个几百条的高质量业务指令集做了LoRA微调成本不高但业务术语理解明显好了很多报告格式也基本能对齐模板。第五步业务验证。验证不能自己说了算。我们组织了三类评测人一线检修工程师、专业主管、数字化部门同事。让他们分别对系统的回答准确性、引用相关性、回复速度打分。同时我们还做了一个“盲评”对比把系统答案和之前人工整理的常见问题标准答案放在一起让人看不出哪个是AI写的凭专业经验打分。最后的结果盲评里45个问题中AI答案优于或与标准答案持平的有32个剩下的虽然错了但引用来源都标出来了业务人员能立刻发现并纠正这比给一个自信但错的答案好太多。4. 实施中踩过的坑与排查技巧实录4.1 显存不够引发的连锁反应项目中途我们差点翻车问题就出在模型服务部署的时候。当时我们拿了一台只有4张24GB显卡的服务器做试点想同时跑14B的问答模型、一个embedding模型、一个rerank模型。结果上线当天服务频繁OOMGPU的可用显存一路飙红K8s反复重启容器有时候刚拉起就被杀掉。排查过程很有意思用nvidia-smi看了半天发现embedding和rerank这两个小模型反而占了大量显存因为它们被部署成常驻服务后每个都占了一整张卡根本没做资源限制。解决办法其实很简单给每个推理服务都加上显存和GPU数量限制embedding和rerank这种小模型可以共卡跑同时把流水线里的模型加载改成懒加载只有被调用时才加载到内存。这个问题不解决后面全没戏。4.2 RAG答非所问和幻觉排查RAG上线后我收到最多的反馈就是“它怎么总是答非所问”。排查下来发现很大一部分原因是文档切片粒度不对。一开始我们按256字符切看起来挺工整但一个检修步骤被拦腰截断语义不完整导致检索到的内容经常是一坨看不明白的半截话。后来改成按段落切对于特别长的段落再按句号切并做重叠窗口检索效果一下好了很多。还有一次我们发现用户问“汽轮机振动大怎么处理”系统检索出来的却是“汽轮机振动大的原因分析”小节内容偏原理措施部分没检索到。解决办法是给知识块加元数据比如“原因”“措施”“现象”这样的标签检索的时候结合用户意图做后过滤命中率又有提升。关于幻觉我的态度是产业场景里不能指望大模型完全没有幻觉但可以通过技术和流程把它约束到可控范围。我们做了三件事第一所有回答必须附带引用没有引用就提示“该回答基于模型知识非本厂数据请核实”第二设置了置信度阈值排序分数低于阈值时不返回生成结果直接提示用户换关键词第三在业务端加了人工复核流程AI生成的报告只能作为草案必须经过负责人确认才能归档。这套机制不一定解决100%的问题但至少让错误不会直接进入生产环节。4.3 评测做不好等于白干我见过不少项目模型部署上线了但你说不出它到底好不好。原因就是评测没做好。这方面我们也踩过坑一开始我们用一个100题的小测试集测出来准确率很不错但一上线就翻车。为什么因为测试题都是我们自己出的基本是“送分题”覆盖不到真实用户那些问得很绕、很口语化的问题。后来我们做了一个关键改进上线后把真实用户问题全部脱敏收集每周人工标注一批回流到测试集里。三个月后测试集从100题涨到800多题其中夹杂了大量真实世界中稀奇古怪的问法。这时候再跑评测分数变得有参考价值了模型迭代也有了标尺。这里特别要强调一点评测集是一个活资产不是一次性交付物。每次模型微调、RAG参数调整、提示词改动之后都要全量跑一遍评测集对比历史分数才能知道这次改动到底是变好还是变坏。我们后来把评测流程做成一个独立流水线代码仓库里一提交模型版本自动触发评测出来一份对比报告。没有这套机制后面的模型迭代基本就是瞎搞。5. 效能提升怎么度量业务验证之后的思考5.1 我们测出来的“增效”到底是多少项目的核心目标是效能提升那到底提升在哪里我们把验证做了两个维度。一个是时间维度让检修工程师用系统查一个规程或者历史案例平均从原来的15到20分钟缩短到2到3分钟这个提升主要来自RAG检索的准确和回答的直给。另一个是质量维度检修报告起草时间从大概1个多小时压缩到15到20分钟而且错别字和格式问题大幅减少。我们还测了新员工培训的适应期几位新入职的同事在知识助手的辅助下两周内就能独立完成以前要一个月才能上手的资料检索任务。有一个数字让我印象很深在对真实用户做了三个月的使用追踪后系统每周的活跃用户占比超过了项目组预期的两倍。很多一线工程师中午吃饭时还拿手机在问系统“这个阀门型号对应的备件是什么”。这说明不是我们自嗨是真有人用、真有用。不过我也要泼一盆冷水这些数字是在一个比较成熟的试点场景里测出来的放到全公司全业务域效果大概率会打折。所以做效能提升度量一定要先选冷启动条件好的场景把标杆打出来再去复制比铺一个大摊子效果好得多。5.2 从试点到常态化运行还差什么试点成功不等于项目完成。我们遇到的第一个问题是模型更新之后老用户不习惯。模型换了回答风格变了有用户反馈“之前问同样的问题答案更详细现在怎么变短了”。这个问题本质上不是bug是产品问题。我们后来做了行为埋点对比新旧版本的用户满意度反馈再去做优化而不是凭感觉来回切版本。第二个问题是安全权限。能源企业的数据有明确的密级和权限体系AI服务必须继承这些权限。我们在RAG检索层做了权限过滤在回答生成后做了敏感信息脱敏比如身份证号、手机号、内部工号这些都要打码。避免一个问题用户有权限查A专业的知识但通过AI绕道拿到了同系统内B专业的敏感数据。这个设计在一开始没有引起足够重视后来是安全部门提出来我们又花了一个迭代周期去补的。第三个问题是长期运营。模型不是装完就完事的知识库里的规程过半年就要更新设备换了厂家检修方法变了向量库里的旧切片就会过时。我们定了一个流程知识变更由业务部门的文档管理员发起经过与技术部门的联合审核才能更新知识库模型的重训和评测也纳入版本发布流程。这套流程已经运行了半年目前看是可持续的。6. 最后几点体会与提醒如果让我给后来者一个最朴素的建议那就是不要被“重构数字底座”这种大词吓住也不要上来就规划几千万的“AI中台”。我们整个项目最核心的部分其实就是一个混合检索的RAG套件、一个经过少量微调的14B开源模型、一个K8s上的推理服务再加一段比较扎实的业务验证流程。真正难的不是技术而是选场景、找数据、组织业务方和你一起做评测。数字化这件事这几年我见过太多“系统建好了没人用”的案例。要避免这个结局技术团队一定要跟业务方坐在一起听他们的痛点让他们参与测试让他们看到这个东西真的能省事。只要这一步做扎实了后面扩场景、扩业务就是水到渠成的事。我自己的经验里还有个后续可以扩展的方向多模态。能源行业有大量设备图纸、仪表读数照片、红外热像图文字问答只解决了一部分问题。我们现在正在试点一个看图问检修的小功能让模型识别仪表盘照片上的读数和报警代码。这个方向一旦跑通数字底座覆盖的业务场景还能再上一个台阶。最后再分享一个小经验大模型项目的验收永远不要只看模型本身的指标一定要看业务指标。技术指标好看可能只是自嗨业务上真有人天天用、用了真有实效这个项目才算真正立住了。