企业官网建设流程全解析

1. 工业大模型和消费级AI，本质上是两种物种

如果只是把一个大模型聊天机器人接到工厂的服务器上，那不叫工业AI。过去两年我在几家制造企业里做LLM（大型语言模型）落地，最大的感受是：工业场景对大模型的容忍度极低——答错一道设备排查步骤，产线可能就停两个小时；多给一条模糊的工艺建议，整批产品质量可能直接波动。这决定了LLM在工业里的每一个应用，都不是"开个对话框"这么简单。

这篇博文想做的事情很朴素：把LLM在工业领域里真正跑得通的十个应用场景，一个一个掰开讲清楚。每个场景我都尽量说清楚核心逻辑、需要准备的数据、典型的落地形态，以及我实测下来觉得最关键的坑。适合三类人看：制造企业里负责数字化和智能化的工程师、正在给工业客户做AI方案的创业者或售前，以及好奇"大模型到底能在工厂里干多少活"的算法同学。

在展开十个应用之前，先把我的分组逻辑说清楚。工业企业的价值链大致可以分成三段：生产制造是核心现场，研发与供应链是上游支撑，管理与决策是运营中枢。我观察到的落地案例，基本也都落在这三段里。生产制造侧的四个场景跑得最快，因为痛点最硬、数据最现成；研发供应链侧的三个场景增量最大，但需要更多工程化投入；管理决策侧的三个场景老板最容易买单，因为效果可以直接体现在报表上。先看一张总览表，后面逐个展开。

这十个场景里，有四个我亲自参与过完整落地，其余几个是在同行交流和客户现场看到过比较成熟的方案。接下来说说每个场景到底怎么做，以及做了之后到底能解决什么问题。

1.1 为什么工业场景突然需要LLM了

过去工业AI的主流是传统小模型和规则系统：视觉检测用目标检测网络，设备预测性维护用振动特征加分类器，排产优化用运筹算法。这些方案有一个共同前提——问题边界是事先定义死的。缺陷种类是固定的，故障模式是枚举好的，排产约束是写在模型里的。

但工业现场大量的问题恰恰是"边界模糊"的。一台压缩机报警，可能是润滑油路堵塞，可能是温度传感器漂移，也可能是负载波动叠加环境温度过高。老师傅能凭经验快速收敛，但经验沉淀在老师傅脑子里，写不成结构化规则。LLM的价值就在这里：它能读懂非结构化的维修记录、操作手册、故障代码表，然后把分散的经验组织成可以对话、可以检索、可以推理的知识服务。

我见过一个很典型的例子：某汽车零部件工厂的老师傅退休前，把自己二十多年的调机经验口述录了几十个小时的音频。后来团队用语音识别转成文本，再用LLM做成知识问答接口，新来的技术员在产线上遇到毛刺缺陷，直接问"刀具磨损导致的毛刺，除了换刀还能怎么临时处理"，系统给出三条建议，其中两条和老师傅本人在场时给的思路完全一致。这就是LLM在工业里最本质的价值——把隐性经验变成显性服务。

1.2 工业LLM落地绕不开的三个硬约束

不过，把消费级的对话大模型直接搬进工厂，大概率会翻车。我总结下来有三个硬约束，做方案设计时必须一开始就想清楚。

**第一个约束是数据私有化。**工厂的设备数据、工艺参数、质量记录都是商业机密，不可能发到公有云API上去处理。这意味着模型要么私有化部署，要么做混合架构——敏感数据走本地，非敏感内容走云端。我遇到的客户里，超过七成明确要求"数据不出厂"，所以后面讲技术底座时，部署方案是绕不开的话题。

**第二个约束是实时性。**对话式交互天然要求低延迟，但工业现场还有一层要求：当LLM被嵌入到设备巡检、质量判定这类流程里时，它不能是"等用户来问"的模式，而必须主动处理事件、推送结论。架构上就得把LLM和事件流、消息队列接在一起，而不是单纯做一个聊天页面。

**第三个约束是可解释性。**消费级用户问错了可以重问，但工厂里给维修班长推一条"建议停机检查"，如果说不清依据，没人敢执行。所以工业LLM应用基本都得配"引用溯源"——回答里附上知识来源、相关标准条款、历史案例记录，让现场人员能复核。这一点在后面每个应用场景里都会反复出现。

2. 生产制造侧：最先跑出效果的四个场景

生产制造是工业LLM落地最密集的区域，原因很简单：痛点明确、预算体感直接、数据积累充分。下面这四个场景，按我接触到的实施频率排序。

2.1 设备故障诊断：把老师傅的经验变成7x24小时在线的知识助手

设备运维是LLM在工业里公认的"第一落地点"。工厂里几乎都有这样的困境：设备手册几百页，故障代码表密密麻麻，维修工单积累了十几年，但真正遇到突发故障时，能快速给出判断的还是那一两个老师傅。老师傅不在现场，产线就得等。

LLM在这里做的事，本质是对非结构化经验做编码和检索。落地时我建议用RAG（检索增强生成）架构，把三类资料整理成知识库：设备手册和电路图说明、历史维修工单和故障案例分析、故障代码表和参数范围表。维修人员用自然语言提问，系统先检索出最相关的文档片段，再由LLM组织成可操作的排查步骤。为了减少幻觉，回答必须附上引用来源，并且有一步算一步，不直接给出"更换某某部件"这种拍脑袋结论。

这里有个容易踩的坑：维修工单的文本质量参差不齐，很多是口语化的速记，比如"空压机异响，换了轴承好了"。这类数据直接建向量索引，效果很差。我的做法是先做一轮清洗和结构化：把工单拆成"现象-检查动作-根因-解决动作-结果"五个字段，再灌进知识库。清洗之后，检索准确率能提高二十个百分点以上。

下面给一个我在项目里用过的Prompt框架，方便你理解这类助手的工作方式：

你是一名设备运维专家。请根据提供的知识库资料回答用户问题。 规则： 1. 只依据资料回答，资料中没有的信息，明确说"未找到相关记录"； 2. 按"先检查-再判断-后操作"的顺序组织排查步骤； 3. 必须标注每步依据的资料编号； 4. 涉及停机、拆装等操作时，补充安全注意事项。

这套方案上线后，最直观的收益是维修响应时间缩短——一线人员自己查系统就能覆盖大部分常见故障，老师傅的时间被解放出来处理真正复杂的问题。我接触的一家化工企业甚至把老师傅的维修语音实时转写，回填到知识库里，形成了持续自增的经验池。

2.2 工艺参数辅助优化：从工艺卡到对话式参数分析

工艺参数的优化，传统做法是工艺工程师对着历史数据做统计分析，或者靠试错。这个活儿的核心难点在于：影响质量的因素太多，温度、压力、速度、湿度、材料批次之间的耦合关系复杂，EXCEL透视表和统计软件能给出相关性，但很难给出"下一步怎么调"的语义解释。

LLM在这个场景里，我看到的可行定位是"参数分析副驾驶"而不是自动调参器。工程师把产线控制系统导出的历史数据、工艺卡片的参数范围、质量检测结果喂给系统，然后用自然语言提问，比如"注塑件出现缩水，模温和保压压力怎么调合理"。系统结合数据和工艺知识，给出一个带推理过程的建议范围，并标注哪些参数之间有强耦合关系，提醒工程师不要单变量调整。

做这个场景，数据工程的工作量比模型本身的工程量更大。首先要解决数据对齐问题——工艺数据和质量数据往往来自不同系统，时间戳对不齐；其次是参数范围的业务校验，LLM给出的建议必须落在工艺卡片允许的范围内，超出范围必须强提示。我的做法是给LLM接入一个参数范围校验接口，任何输出先过规则校验再展示给用户。

一个值得注意的经验：工艺参数场景不要指望LLM给出精确数值，它的强项是"缩小搜索范围"和"提供排查方向"。真正的最优参数求解，还是得交给优化算法，LLM在其中做的是把工程师的模糊问题翻译成可计算的约束目标，再把算法结果解释成工程师能听懂的语言。这也是工业场景里典型的"LLM+传统算法"协同模式。

2.3 质量缺陷根因分析：让检验报告自己开口说话

质量部门积压的数据是最多的——来料检验记录、过程检记录、终检报告、客户投诉分析、8D报告。但这些数据大多数时候是"死数据"：写进了档案，却很难在下次出现同类问题时被快速调用。一个质量工程师排查根因时，往往要翻几周甚至几个月的历史报告，靠记忆找相似案例。

LLM应用在这里有两个层次。第一层是缺陷记录的智能检索：用自然语言查历史案例，比如"去年三月份出现的电镀起泡，当时是什么原因导致的，怎么解决的"。第二层是检验报告辅助解读：系统读取当天的检验数据，自动对比历史异常模式，生成一份初步的根因分析草稿，包括可能的影响因素、对应的历史案例、建议的排查步骤。注意这里说的是"草稿"，最终的根因判定必须由人来确认，LLM的角色是帮工程师把80%的检索和整理工作做掉。

落地时，最有价值的技术动作是把质量数据进行结构化——把缺陷现象按照"位置-形态-尺寸-产生工序"四个维度打标。比如"壳体端面划伤""密封面气孔""焊道裂纹"，每个维度都有标准词表。这么做有两个好处：一是检索和聚类效果远好于全文搜索，二是为后续做缺陷根因的知识图谱打基础。有了结构化标签，LLM在回答时就能准确关联到"同样的缺陷、同样的位置、大概率是同样的根因"这样的推理链。

我给客户做的一个案例里，把过去五年的3万多条质量记录做了结构化处理，配合LLM问答。质量工程师排查一次客诉的时间，从平均两天半压缩到半天。这个场景的ROI（投入产出比）非常清晰，也是最容易向老板汇报成果的应用之一。

2.4 安全生产：操作规程问答与隐患描述标准化

安全生产场景的数字化基础相对薄弱，但LLM落地门槛却很低，因为它的核心是文本处理。工厂里有大量安全规程、岗位操作规程、应急处置卡，这些内容一线员工真正记住的比例并不高——不是员工不认真，而是文本太长、太难查、更新频繁。

比较有效的一种落地方式是"安全规程对话助手"。员工用自然语言问"氢气泄漏了第一步该干什么""动火作业票有效期多久"，系统直接给出对应条款和操作步骤，并附上规程原文链接。这个应用的技术含量不算高，就是一个标准的RAG问答，但实际价值很大——尤其对新员工和转岗员工，相当于配了一个24小时在线的安全老师。

另一个容易被忽视的应用是隐患描述标准化。企业做安全巡检时，一线人员记录的隐患描述五花八门："那个管道有点渗""三楼电箱门坏了""灭火器压力不够了"。这些描述进到安全管理系统后，很难做统计分析。用LLM做一次语义归一化：把自由文本的隐患描述自动映射到标准隐患分类体系，同时抽取设备、位置、风险等级等结构化字段。这样一来，隐患数据的归因分析、趋势分析才做得起来。

这个场景实施时要注意一个问题：安全规程更新频繁，知识库必须和规程管理系统做联动，规程一更新，知识库要同步刷新。我见过一家企业因为知识库没跟上，员工问到了已经废止的旧规程，这种错误在安全场景里是不能接受的。所以做安全问答，知识库版本管理是第一优先级，宁可少一个功能，也要保证答案引用的版本绝对正确。

3. 研发与供应链侧：被低估的三个增量场景

如果说生产制造侧的四个场景是"痛点驱动"，那研发和供应链侧的应用就是"效率驱动"。这些场景不像设备故障那么惊心动魄，但天花板更高，优化空间更大。

3.1 产品需求分析与设计文档辅助生成

研发部门有一类活特别费人：把客户需求转化成产品设计输入。一份招标文件或者客户需求说明，可能几十页到几百页，里面混杂了性能指标、环境适应性要求、认证需求、交付条件。研发工程师要把这些内容逐条抽取、分类、映射到设计规范和物料清单。这项工作熟练工程师做起来平均要两三天，而且极其枯燥。

LLM在这里的价值是"结构化抽取+草稿生成"。把客户需求文档喂给大模型，自动抽取需求条目，按功能、性能、接口、环境、法规等维度分类，再和产品标准库比对，标出哪些需求是现有产品已经满足的，哪些需要新设计或新选型。系统还能进一步生成设计需求规格书的初稿，研发人员只需要做审核和修正。

这个应用的技术关键是领域术语对齐。客户说"设备能在高原环境下正常工作"，研发体系里对应的是"海拔2000米以上降容设计"；客户说"防尘"，对应的是"IP防护等级"。LLM必须学会做这种术语映射，否则抽出来的需求没法直接进入研发流程。我的做法是用企业积累的历史项目文档做微调，或者预先构建一个术语映射表放在Prompt里，让LLM在抽取时对照映射表翻译。两三百条映射规则就能让抽取结果上一个台阶。

3.2 标准、专利与技术情报的智能检索：让LLM基于本体和图谱回答问题

研发人员和知识产权工程师每天要面对海量的标准文件和专利文献。国标、行标、企标，再加上竞争对手的专利，光靠关键词搜索很难找到真正相关的内容——因为技术方案往往不是用一模一样的词来表达的。比如说你搜"轴承润滑"，但相关专利可能写的是"滚动体减摩""保持架脂润滑"，语义相近但词面不同。

这里就要说到热词里反复出现的那个概念：LLM Ontology（本体）。通俗理解，本体就是用一个结构化的语义模型，把工业领域里的实体和关系定义清楚：设备包含哪些部件，部件之间怎么连接，工艺参数影响哪些质量特性，故障现象对应哪些根因。有了本体，就可以构建领域知识图谱，再叠加GraphRAG（图检索增强生成）——不只是按向量相似度找文档片段，而是沿着知识图谱的关联关系做多跳推理。

举个例子：一个研发工程师问"提高电机绕组的绝缘寿命有哪些技术方向"。传统的向量检索可能只返回几篇包含"绝缘"的文档；而基于本体的GraphRAG，可以沿着"绕组-绝缘材料-老化因素-改进工艺"这一关系链，把分散在专利、论文、失效案例里的信息串联起来，生成一份带知识来源的综述性回答。

这个场景里有一个非常实用的经验，就是理解LLM处理信息时的"三元组思维"，对应到检索系统的设计上其实可以用一句话概括：每个知识块都要想清楚它的Key（我是谁）、Query（用户在找什么时会命中我）、Value（我能提供什么答案）。很多人做知识库时只做向量化，结果检索效果差。真正专业的做法是在切块和元数据标注阶段，就按这个三元组思维给每个知识块设计标签——这块文档属于什么设备、什么工序、什么故障类型，用户可能会怎么问，它能回答什么。这样检索召回率会有质的提升。

3.3 供应链协同与合同文本处理：把采购从文书堆里解放出来

供应链侧的文本处理需求，比多数人想象的要大得多。一家中型制造企业的采购部门，每年经手的询价单、报价单、采购合同、技术协议、交货计划，少说也有上万份。这些文档大多是电子版PDF，格式各异，关键条款散落在各处。采购工程师大量时间花在"找信息"和"对条款"上，而不是花在真正的供应商谈判和风险管控上。

LLM应用在这块已经相当成熟，主要做三件事：合同关键条款抽取（价格条款、付款条件、违约责任、知识产权归属、保密期限）、供应商报价单的标准化比对（把不同格式的报价单统一成结构化表格，自动标出哪家价格低、哪家交期短、哪家质保好）、技术协议的合规性检查（对照企业的标准采购条款，标出差异项和风险点）。

这个场景落地相对快，因为文档处理管线是通用的，不需要做复杂的模型调优。我建议第一步从"报价单标准化"切入，因为它的业务规则清晰、效果可量化，一个采购工程师每周至少省出三到四个小时。做的时候只需要注意一点：报价单扫描件的OCR（光学字符识别）质量必须核查，有些扫描件骑缝章、水印、表格线会影响识别率，识别错了后面全错。我的习惯是先跑完OCR，抽样十份人工核对，再决定接不接受这批数据进LLM流程。

4. 管理与决策侧：老板最容易买单的三个场景

管理侧的AI应用，效果直接对着经营指标，领导看得懂、能拍板。这三个场景我放在一起讲，因为它们共同的特点是"重交互、轻模型"——核心不在大模型本身多强，而在和现有业务系统的集成深度。

4.1 ChatBI：用自然语言查经营数据，让报表自己说话

制造业的管理层，十个里有九个抱怨报表系统难用：想看一个数据，得知道它在哪个系统、哪个菜单、怎么设置筛选条件。传统BI工具做了很多年，最终还是只有少数几个数据分析师会写复杂的查询。ChatBI（对话式商业智能）解决的就是这个问题——让管理层用大白话问数据，系统自动翻译成数据库查询，返回结果并用自然语言解释。

比如总经理问"上个月华东区的交付及时率是多少，和年初比变化了多少"，系统要做三步处理：首先通过LLM理解问题里的维度（华东区、交付及时率、月度）和时间范围（上个月、年初），其次把这个语义映射到数据模型的字段和指标定义上，然后生成查询、执行、返回结果并附上"这个数字是这么算出来的"的解释。

实施ChatBI最麻烦的不是模型，而是指标口径管理。同一个"交付及时率"，供应链部门按订单准时率算，销售部门按客户签收时间算，财务部门可能按开票口径算。如果指标口径不统一，LLM再强也是答非所问。所以我强烈建议：做ChatBI之前，先做指标字典，把每个指标的名称、口径、计算公式、数据来源定义清楚，让LLM在生成查询前先对照指标字典做意图映射。这个工程做扎实了，ChatBI的成功率才有保障。

4.2 售后技术问答与说明书生成：客服和售后工程师的效率杠杆

产品卖出去之后，服务才刚刚开始。售后部门每天要面对大量重复咨询：安装调试怎么做、某个故障代码代表什么、备件型号怎么选、保养周期是多少。这些内容在产品说明书、维修手册、FAQ库里其实都有，但客服人员现场搜起来效率很低，客户体验也不好。

LLM做售后问答，和前面讲的安全规程问答技术架构是一样的，区别在于知识库的结构更复杂——不同的产品线、不同的机型、不同批次的软件版本，对应的说明书和维修手册都不一样。做知识库时，每一个文档块都必须打上产品型号和版本标签，回答时先限定型号范围再检索。我见过翻车案例：客户问的是新款机型，系统答的是旧款机型的操作方式，这种错误在售后场景里会造成实打实的客诉。

另一个增量价值是说明书自动生成。很多制造企业产品迭代快，说明书更新跟不上。LLM可以从研发输出的技术文档、检测报告、变更记录中，自动生成说明书初稿，人工审核后发布。当然，说明书涉及安全声明和性能参数，审核流程一步都不能省。我的建议是生成和审核分开，LLM只做初稿，所有的安全注意事项、性能参数必须由工程师人工确认。

4.3 工业软件研发辅助：代码生成与AI测试开发双管齐下

最后一个应用，算是对IT部门自己的降本增效。工业企业的信息化团队普遍不大，但系统不少：MES（制造执行系统）、ERP（企业资源计划）、WMS（仓储管理系统）、设备数据采集系统，还有各种报表和审批流。这些系统的开发和维护工作量大，且大量是重复性工作。

LLM辅助工业软件开发，比较务实的用法有两个。第一是领域代码生成：利用LLM生成MES系统里的基础CRUD接口、报表查询、表单页面。工业软件有大量的标准化模块，比如工单管理、物料批次追踪、质量检验记录，这些模块的代码结构高度相似。先用Prompt写好一套带工业语义的模板代码，再让LLM按新的业务对象生成变体，开发效率能提升一半以上。这里要注意的是，生成代码不能直接进生产，必须过代码评审和测试，工业系统的稳定性和数据准确性要求极高，不能因为AI赋能就把底线放掉。

第二是AI测试开发。工业系统的测试比互联网系统更烦琐——需要构造大量的工艺数据、设备数据、物料批次数据来做业务场景测试。LLM可以根据系统接口文档和数据结构定义，自动生成测试用例和测试数据，甚至自动断言预期结果。我和团队做过一个实践：用LLM为一个设备数据采集系统生成了两百多条测试用例，覆盖了常规情况、边界情况和异常流，测试设计和准备时间缩短了三分之二。

这个场景实施时有一个能力关卡：AI编程提示词的质量。同一个需求，提示词写得好不好，生成的代码质量天差地别。对于工业软件这种强业务逻辑场景，提示词里必须包含业务对象定义、字段约束、错误处理要求、数据校验规则，甚至要给出一个参考实现样例。我建议每个团队建立一个"工业软件生成提示词资产库"，把常用的模块生成模板沉淀下来，越用越顺手。

5. 十个应用背后的同一套技术底座

看到这里你可能会问：这十个应用听着各不相同，底层有没有共通的东西？有。实际上，工业LLM应用的技术架构收敛得很厉害，核心就是四件事：检索（RAG/GraphRAG）、智能体（Agent）、网关与模型管理、部署与评测。任何一个应用跑得好，都是这四件事配合得好。

5.1 RAG到GraphRAG：解决幻觉问题的最实用路径

工业场景不允许LLM凭空编造知识，所以RAG是事实上的标配。RAG的本质是把知识库分割成片段，向量化存储，用户提问时先检索相关片段，再让LLM基于片段回答。但工业领域关系复杂，设备之间、工序之间、故障与根因之间都有强关联，把RAG升级成GraphRAG，把检索从"找相似文本"升级为"沿关系链找答案"是更优的选择——这就是前面提到的本体和知识图谱的作用。

实施GraphRAG，关键要建好三层：本体层定义核心实体和关系，比如"设备-包含-部件""部件-影响-工艺参数""工艺参数-决定-质量特性"；知识图谱层把企业已有的结构化数据（设备树、物料清单、工艺路线）导入图数据库；检索层对话时同时做两路召回——向量相似度召回文本片段，图谱路径召回关联实体和关系，最后用LLM把两路结果融合成回答。

这里有个务实建议：不要一开始就来完整版的GraphRAG。先从简易RAG跑通业务，攒出用户反馈数据，再针对检索不到、答不准的case逐步加图谱关系。因为图谱的构建和维护成本不低，工业企业的数据和业务还在持续变化，维护一个过时的图谱比没有图谱更糟糕。

5.2 Agent与多AI协作：从"回答问题"走向"执行任务"

RAG解决的是"答得准"，Agent解决的是"干得了"。工业场景里很多需求不只是问答，而是要一连串动作。比如一个质量工程师问"帮我汇总这批不合格品的所有检测数据，对比标准，找出异常项，生成一份分析报告发给相关人员"——这中间涉及查询数据库、调用统计函数、生成报告、触发流程通知，单靠一个问答模型完成不了，必须由Agent编排。

工业Agent的典型形态是"规划-调用-验证"循环：大模型作为大脑，把复杂任务拆解成多个子任务；每个子任务通过调用工具完成，工具包括数据库查询接口、分析算法服务、报表服务、流程引擎。执行过程中，Agent会检查每一步的结果是否符合预期，不符合就调整策略重试，最后汇总输出。

更进一步，多Agent协作也在工业场景里出现了——比如设备运维Agent负责定位故障，工艺优化Agent负责给出参数建议，质量Agent负责验证建议对质量指标的影响，三个Agent对话协作形成完整方案。做多Agent协作时，最怕的是Agent之间传递的信息失真。我的经验是给每个Agent规定好输入输出Schema，用结构化的JSON传递信息，而不是让它们用自然语言自由对话。结构化传递能大幅降低信息损耗，也让每一步都可审计。热词里提到"deepseek公开AI智能体训练新方法"，其实说明各家大模型厂商都在推Agent能力，但工业落地还是要以自己场景里的稳定可控为主，别追新。

5.3 模型选型、部署与Token成本：开源模型还是API，怎么选

工业客户普遍要求私有化部署，所以模型选型基本在开源LLM里选。具体选哪个，我建议参考公开榜单看综合能力，更重要的是拿自己的业务数据测——在设备维修问答、质量分析这种垂直任务上的表现，公开榜单的通用分数参考意义有限。我一般的做法是准备一二百条企业真实问答，做成评测集，让待选模型跑一遍，人工打分，对比后再定。

部署环节，工业现场往往没有强大的GPU集群，所以模型压缩和优化是躲不开的。我实测可用的路径包括：ONNX Runtime做推理加速、模型量化（8比特甚至4比特）、蒸馏一个小模型做高频简单问答。我的习惯是"大小模型搭档"：一个几十亿参数的小模型跑高频的基础问答，响应快、成本低；一个上百亿参数的大模型跑复杂推理和报告生成，保证质量。两层之间用路由规则分流。这种架构在成本和体验之间平衡得很好。

模型网关也是容易被忽略的一环。当企业里同时有几个模型在服务（一个负责质检报告解读、一个负责合同抽取、一个负责ChatBI），没有统一的网关，每个系统各接各的，管理会乱成一团。网关统一负责模型路由、限流、密钥管理、日志审计，以后模型升级换代也方便，业务系统只需要面对网关，不需要跟着改。热词里提到的"LLM网关"，现在已经是工业AI架构里的标配组件。

5.4 效果评测：没有评测集，就谈不上迭代

工业LLM应用上线之后，一定会有人质疑"它回答得对不对"。没有一个量化的评估机制，技术团队连改进的方向都找不到。所以做任何工业LLM项目，我开工第一件事就是搭评测集。

评测集的做法不复杂：把真实业务里的高频问题、历史疑难问题整理出来，配上标准答案（答案来源是权威手册、确认过的工单、或者是几位专家评审通过的标注），分好难度等级。每次模型或知识库更新，都跑一遍评测集，看准确率变化。评测集需要持续扩充——每出现一个线上答错的case，就把它加进去，让评测集成为团队的记忆库。

评测维度上，工业场景除了"准确"，还要关注"安全"和"可解释"。安全指的是那些可能引发误操作的回答会被特殊标记；可解释指的是回答是否附上了引用来源、推理链是否清楚。我见过一些项目只顾着刷准确率，把评测集简化为选择题对错，忽略了引用完整性，结果线上用户反馈"答案是对的但我怎么知道该不该信"。好在工业用户对"有出处的回答"尤其买账，这一点做扎实了，系统信任度会显著提升。

6. 我在工业LLM落地中踩过的几个坑

这部分的每条注意事项，都是拿真金白银换来的。写出来，希望你能少走一些弯路。

6.1 幻觉的根子不在模型，在语料治理

很多团队遇到LLM答错，第一反应是换更大的模型、加更强的Prompt。但我在项目里反复验证下来，大部分幻觉问题的根因是知识库语料质量不行——文档本身过时了、不同文档之间自相矛盾、切块把语义切碎了、元数据标注缺漏。模型只是个传声筒，语料是脏的，再强的模型也只能用错误信息组织出自信满满的错误答案。

所以做工业LLM，我建议把60%的精力放在语料治理上。这活儿很细，需要业务专家参与标注，但回报也是实实在在的。有一个客户案例：某装备制造企业的知识库里有新旧两版操作规程同时存在，旧版规定了某个扭矩值，新版修订了。LLM检索时随机命中，导致同一个问题有时答旧版、有时答新版。后来排查出来，在对知识块做版本元数据标注之后，规定"同类型资料只保留最新有效版本进检索库"，问题立刻消失。像这种工程化手段，比换模型有效得多。

6.2 知识库永远在过时：本体和图谱需要持续维护

工业企业的业务是活的：设备在改型、工艺在优化、标准在更新、组织在调整。这意味着任何静态的知识库、图谱、本体，上线三个月后就开始贬值。我见过不止一个项目，上线时效果惊艳，半年后没人用，因为里面的信息跟不上现场了。

解决思路不是一劳永逸，而是把知识更新做成一个流程闭环。第一，每次变更，业务系统通过接口主动推送更新事件给知识库；第二，定期用LLM做一次知识库的一致性检查，自动标出相互矛盾的条目，推给业务专家人工确认；第三，维护一个"知识过期清单"，跟踪每类资料的最近核实时间，超过一年未核实的自动降级。知识治理不是一个项目，而是一个持续运营的岗位职责，哪怕每周只花半天，也比放任不管强。

6.3 别一上来就微调：先RAG后微调，是性价比最高的路径

不少算法团队一接到需求，第一反应是对开源模型做微调，觉得微调才显得专业。但工业企业的数据量往往不足以支撑高质量微调，而且微调对推理成本、部署复杂度的影响是实打实的。我自己的原则是：先做RAG，把知识库和检索做到位，如果还是答不准，再考虑针对特定任务做微调。微调最适合的场景是"格式控制"和"术语一致"，比如要求模型始终按照企业特定的报告模板输出，这种需求用微调效果很好，成本也可控。

这里有个容易踩的坑：微调数据的质量校验。企业里整理的微调数据通常来自业务系统，可能带着历史偏见或错误标注，模型学进去就麻烦了。我做微调前一定会人工抽检20%的数据，错的标记出来重新清洗，绝不直接丢给训练脚本。模型学到错的东西，比模型学不到东西更难纠回来。

6.4 工业用户要的不是聊天框，而是流程闭环

最后也是最重要的一条认知：工厂里的用户不会为了"用AI"而打开一个聊天框。一线维修工遇到故障时在赶时间，质检员在产线边看数据，采购在邮件和系统之间来回切换。如果LLM应用是一个孤立的对话页面，用户得专门登录、专门输入、专门等答案，那使用率一定高不起来，新鲜感过了就废弃了。

真正让LLM产生持续价值的做法，是把它嵌入到用户已有的工作流里。在MES系统里加一个"智能助手"入口，维修工人在工单界面直接唤起故障排查；在质量管理界面，点一下就能触发缺陷报告解读；在BI报表页面，自然语言提问框就放在右上角。用户不是在"用AI"，而是在"做自己本来要做的事，只是更快了"。这才是工业LLM应用设计的终极目标。

从我自己的实操体会来说，这十个场景里没有一个是纯模型问题，全都是"业务理解+数据工程+交互设计"的综合题。大模型提供了前所未有的交互能力，但真正决定项目成败的，还是你愿不愿意把脏活累活做细。做工业AI，慢就是快，先把一个场景打透，再往外扩，比铺一堆半成品更有价值。希望这篇梳理，能帮你在自己的项目里少走几步弯路，早点跑出第一个真正被现场用户天天使用的应用。