★ FEATURED ARTICLE 我见过太多做工业智能的团队折腾了好几年上了一堆大屏和报表系统最后真正被一线工人用起来的却没几个。但大模型是个例外——它是少数能让老师傅主动天天打开来问问题的AI技术。原因不复杂因为它真的能“听懂人话”你用大白话问它它就用大白话回你还告诉你依据在哪。这份指南想做的事情就三件第一把大模型那些绕口的概念用大白话讲清楚确保一个没写过代码的小白也能听懂第二讲透这些概念在工业现场到底怎么用尤其是知识问答、文档处理、辅助排查这些真正能落地出效果的场景第三给出一套可以直接抄作业的实操流程从文档整理到提示词编写从效果评估到问题排查完整走一遍。适合谁看呢一类是从零起步的产品经理、项目经理、设备工程师你想搞清楚大模型能在自己工厂里干什么另一类是写过代码但对大模型不熟的开发者你想跳过理论轰炸直接掌握落地需要的核心知识。两类人读这一篇都够了看完你能对“工业大模型”这件事建立一套完整的判断框架而不是零碎地刷一堆名词。1. 为什么工业场景需要大模型到底能帮我们干什么1.1 先看清工业数据的真实模样很多人在谈工业智能的时候开口就是“大数据”“传感器”“数字孪生”听着很高级。但真正在现场待过的人知道工业环境里最值钱的往往不是那些采集上来的时序数据反而是散落在各处的非结构化文本——设备说明书、检修规程、工艺卡、历史工单、化验报告还有老师傅脑子里那些没写下来的经验判断。这些文本有几个让人头疼的特点。形态极其杂乱。有PDF有Word有Excel有扫描件甚至还有手写的点检记录。PDF里有的能复制文字有的就是一张图片得OCR才能读出来。页眉页脚、目录、页码混在一起直接扔给模型它很容易抓到一些没用的内容。知识高度分散。同一个设备的故障排查方法可能散落在操作手册的第80页、一张三年前的维修工单、和某个老师傅的培训记录里。你要查完整得把好几份文档来回翻。更麻烦的是很多流程中“怎么做”和“为什么这么做”是断开的操作步骤写在一份文件里原因和注意事项又写在另一份里。严重依赖人的经验。老师傅能通过声音判断设备异常能靠一次故障的现象快速锁定几个可能的根因。这些东西他讲得出来但没人及时记录下来等项目一过、人一退休经验和知识就永久性流失了。我见过不少工厂做过“老师傅经验访谈”但访谈记录整理完就进了文件夹之后再没人打开过。一句话总结工业场景的真实痛点不是没有数据而是数据里的知识密度太高、太分散传统的检索工具和看板根本挖不出来。1.2 大模型在工业里最值钱的几类用途搞清楚痛点之后大模型能干的活就很清晰了。我把它归成四类也是工业落地目前最成熟、ROI最明显的几类场景。第一类知识问答与检索。这是当之无愧的第一落地场景。把设备手册、维修案例、安全规范全部塞进知识库现场工人用自然语言提问“液压站压力上不去先查哪里”系统返回的不是一份80页的PDF而是精确到步骤的排查流程并且每一步都标注了出处。这就相当于给每个班组配了一个24小时在线的、永远不嫌烦的专家。第二类文档处理与结构化。工业现场每天产生大量文本记录维修工单、巡检记录、交接班日志、事故调查报告。这些文字有用但格式乱、描述口语化、关键信息埋没在叙事里。大模型可以把一段“今天三号机有点响换了轴承后来正常了”转成结构化字段设备编号、故障现象、处理措施、处理结果、工时直接对接MES工单系统。这一个场景的落地价值往往被低估其实它是真正能上线进业务流程的硬需求。第三类辅助排查与根因分析。把设备当前的状态信息和历史故障案例交给大模型让它列出最可能的排查方向。这个场景要谨慎因为工业设备一旦误判后果严重所以我更愿意称它为“辅助决策”——模型给出建议和依据人来判断。它最大的价值是打开思路尤其对经验不足的年轻维修工非常像“一个见多识广的同事在旁边提建议”。第四类培训与知识传承。把老师傅和徒弟的对话录下来把维修案例问答整理成培训材料大模型可以根据这些语料生成试题、模拟问答、甚至“虚拟专家陪练”。这件事在老龄化严重的制造业里价值会越来越突出。我顺便列个表方便你对照自己所在的行业找切入点应用场景输入输出落地难度价值量级设备知识问答手册工单案例排查步骤出处低高工单自动结构化口语化维修记录MES格式数据低高事故调查报告分析历史报告文本原因归类建议中中高工艺参数辅助优化历史工艺数据文本记录参数调整建议中高高培训材料生成访谈记录案例库试题模拟陪练中中要特别说明一件事大模型在工业场景里多数情况下不是取代原有的MES、SCADA、专家系统而是补上它们最薄弱的一环——让人用自然语言就能拿到结构化的知识。它更像是给老系统装上一个“会说话的接口层”。2. 吃透核心概念从Token到微调一次搞清楚2.1 大模型的底层直觉一本会接龙的书想理解大模型不用先陷进注意力机制或者反向传播这些数学细节先从直觉上建立一个模型。你把大模型想象成一本非常会“接龙”的书。给它看一句开头“设备启动后出现异响首先应该检查______”它根据读过的海量资料预测这里最可能接的词是“轴承”或“润滑”。训练阶段做的事情就是让它读天文数字一样的文本不断练习“根据前面的话猜后面的话”猜错了就调整内部参数慢慢参数里就沉淀下了语言规律和世界知识。到了使用阶段输入你的问题就是给它一个开头它就开始一个接一个地预测后续的词最终生成一段连贯的回答。明白了这个原理你就能理解大模型一个让人头疼的特性它并不知道自己“知道什么”它只是在做一个概率选择。所以当训练数据里没有相关内容时它不会说“我不知道”而是会顺着你的话头“编一个最像样的答案”——这就是大家常说的“一本正经地胡说八道”。大模型的完整能力分成两个阶段。预训练阶段注入知识让模型会说话、懂常识对齐阶段让它学会“听话”也就是按照人的偏好来回答。后者是为什么你用现在的大模型感觉比前几年的好用很多的关键——它不仅知道得多还知道怎么答你才满意。2.2 绕不开的关键术语一个一个说透下面这些词你会在各种资料里反复碰到我挑工业落地相关的重点讲。Token词元。这是模型处理文本的最小单位。中文场景下一个字大约对应一到两个Token但也不是绝对一个常见中文词语可能是一个Token一个英文单词可能被切成好几个Token。为什么它重要因为按字数计价、按上下文长度计算全部以Token为单位。一个10万字的设备手册大概相当于十几万Token。商用模型API按Token收费开源自部署则决定你需要的显存和算力。上下文窗口。指模型一次能“看到”多少Token。以前的模型只有4K、8K换算成中文也就三四千字到一万多字一份小手册都放不下。现在主流能到32K甚至更大但窗口大不等于效果好——塞进去的东西越多模型越容易“看不过来”捡了芝麻丢了西瓜。工业落地中宁可控制塞进上下文的资料数量也不要一味追求大窗口。参数与模型规模。常说7B、13B、70B指的是模型的参数数量分别是70亿、130亿、700亿。参数越多通常代表学到的知识越多、能力越强但推理成本也越高。70B模型跑一次得到的答案不一定比7B模型强多少尤其在垂直领域的专业问答里喂给模型的知识质量往往比模型本身大小更关键。Embedding向量化与向量检索。把一段文字变成一串数字坐标含义相近的文字在坐标空间中距离更近。“轴承损坏”和“轴承故障”在文字上不完全一样但向量距离很近机器能据此判断它们是同一类问题。这个技术是RAG检索增强生成的底层基础也是工业知识检索中识别同义表达的关键手段。想象一下地图App每个地址是一个坐标你要找“公司附近最近的咖啡店”靠的就是坐标距离。向量检索就是这个逻辑。Temperature温度与采样。控制生成的随机性。温度越低输出越保守、越可预测温度越高越有创造性、越发散。工业问答建议用偏低的温度范围在0.1到0.3之间因为现场要的是确定性和可靠性不是创意写作。文档摘要可以稍微高一点让表达更自然但也别超过0.5。LoRA微调。这是一种参数高效微调技术。通俗讲原模型像个已经训练好的大厨你不想把整个后厨推翻重来只想教他几道你们本店的特色菜——那就只训练一个很小的“调味模块”挂在他身上这就是LoRA。工业场景里如果模型输出的术语习惯、格式风格和你们行业不符用LoRA调整一下是性价比很高的做法。提示词工程Prompt Engineering。字面意思就是设计给模型的输入指令。有人觉得它是“雕虫小技”但说实话在工业落地项目里提示词的质量直接影响上线效果而且是调整成本最低的手段。我后面会专门展开讲。2.3 部署侧的显存账必须学会自己算程序员或者项目经理迟早要面对一个问题这个模型要跑在什么硬件上这里教你一个最常用的估算方法。模型权重占用的显存大致等于参数量乘以精度字节数。一个7B模型用FP16半精度每参数2字节加载约需14GB显存。但这只是权重推理时还有KV Cache、计算中间态实际跑起来至少再加几GB。所以你要部署一个7B模型单张24GB显存的卡是刚刚好能动的但并发一多就容易撑不住。如果量化为INT8每参数1字节权重降到7GB左右一张16GB显存的卡就能跑INT4甚至可以把权重压到4GB级别但精度有所损失对中文和专业术语的理解力会下降工业场景要谨慎使用。在硬件需求上我做项目会这样估算7B模型量化为INT8配32GB内存的服务器一张24GB显存的显卡足够支撑车间内几十个低并发客户端的问答服务。如果并发要求高优先横向加推理卡而不是换更大的模型。工业场景的核心诉求是稳定和低延迟对“模型很博学但回复要等一分钟”这种事根本不能接受。关于算力我再多说一句部署大模型不是越高端越好而是匹配你的场景。做知识库问答7B-13B量级的开源模型配合RAG效果已经相当能打硬上70B模型除非你有充裕的GPU预算否则性价比往往不合算。3. 工业落地怎么选型提示词、RAG还是微调3.1 三条技术路线先分清谁管什么凡是做大模型落地的绕不开三个名词提示词工程、RAG检索增强生成、微调。很多新手一上来就想微调觉得不训练一下就不算“自己做大模型”这是最大的误区。这三条路线解决的问题根本不同。提示词工程解决的是“怎么让模型按我的要求输出”。买现成的模型设计一套指令模板让模型按照模板来回答。比如规定“只根据提供的资料回答如果资料没有答案就明确说不知道”就属于提示词工程。它的优点是零成本、见效快缺点是模型本身不知道你们公司的内部知识。RAG解决的是“怎么让模型知道我不知道的事情”。把公司文档、手册、案例做成知识库用户提问时先检索相关知识再把“检索结果问题”一起塞给模型让模型结合资料回答。你可以理解为让模型开卷考试——先翻书再作答。这是目前工业知识类应用的最优解没有之一。微调解决的是“怎么让模型的行为方式和风格变成你们的”。让模型学会你们行业的术语习惯、工单格式、语气风格。但它不能给模型注入新知识因为训练数据中模型记不牢具体事实这是工业场景中最容易被误解的一点以为微调能让模型掌握内部知识做完了才发现该不知道还是不知道。三者的适用关系我的经验是维度提示词工程RAG微调知识来源模型内置外部知识库训练数据知识更新无法更新即时更新需重新训练幻觉控制弱强有引用中开发成本极低低-中高适合场景通用问答、格式控制企业知识问答风格与术语适配一个典型的决策路径是先写提示词试试满足需求就收工不满足上RAG解决知识缺失还不够做小规模LoRA微调调整风格。我今年做过的项目里九成需求在“提示词RAG”这一层就解决了真正走到微调的很少。3.2 工业RAG的典型链路把RAG再拆细一点完整链路包含四段文档预处理、检索、组装、生成校验。文档预处理是地基。PDF要转文字扫描件要OCR图片要加说明文字然后按章节切分成小块每块配上标题和上下文信息最后用Embedding模型把每一块转成向量存进向量数据库。这个环节最耗时也最决定天花板。资料没弄干净后面做什么都白搭。检索阶段包括查询改写和召回。用户问“液压站为啥压力上不去”系统先把这句话改写得更适合检索比如“液压站 压力不足 原因”然后同时做向量检索找语义相似的内容和关键词检索找字面匹配的内容最后把两路结果合并、去重、重排取最相关的3到5段。组装阶段是把检索回来的资料和用户的问题拼成一个完整的Prompt。工业场景对Prompt要求比较严格一般要包括角色设定、任务说明、资料内容、输出格式要求。这一步看起来简单实际对最终效果影响非常大我后面会给一个可以直接用的模板。生成与校验阶段模型根据Prompt生成最终回答。更稳妥的做法是要求模型在回答中标注引用来源再做一个后置校验如果回答里的关键信息在检索资料中找不到对应文本就判定为可疑打回重生成或直接拒答。这一步能大幅降低幻觉让业务方建立信任。3.3 数据安全与系统边界先解决问题再谈智能工业环境的数据安全要求比其他行业高一个量级这不是空话。设备参数、工艺配方、故障记录都属于企业核心资产出不去厂门。所以工业落地第一条原则就是优先考虑私有化部署或者混合部署。私有化部署就是把开源模型跑在工厂内部的服务器上数据全程不出内网这是最稳妥的。成本上一套小模型RAG的服务硬件投入基本可控相比每年给云厂商交推理费用长期看更划算。如果确实想用商用大模型API至少要做到数据和提示词层面的脱敏把设备编号、人员姓名、工艺参数全部替换成代号。其次是权限设计。不同角色的员工应该只能访问各自范围内的知识库。操作工能查操作手册和故障代码但不该能查工艺配方工艺工程师能查配方但不该能查薪酬相关的文档。知识库的权限管理和文档管理要一一对应否则就会出问题。还要设计“模型挂了怎么办”的降级方案。大模型服务一旦出现故障前端系统要能自动切换为一个简单的关键词检索模式宁可答得粗糙一点也不能让现场工人面对一个打不开的工具。这一条在项目初验和复盘中是必查项。4. 手把手实操从零搭一个“设备故障问答助手”4.1 先想清楚使用者、场景和知识范围理论知识说够了下面用一套完整的实操流程带你从零搭一个可靠性比较高的“设备故障问答助手”。我选这个场景是因为它需求具体、答案有标准、出错不会引发安全事故非常适合作为第一个大模型落地项目。先回答三个灵魂问题。给谁用给车间现场的维修工和操作工。他们的问题是口语化的比如“空压机老跳机咋回事”没什么技术规范性但要求答案落地、能照做。问什么集中在设备故障排查、保养规范、备件更换标准。比如“液压报警代码E023是啥意思该查哪里”“皮带多久换一次”这类。答到什么程度要给出明确的步骤顺序每一步写清楚操作内容和注意事项同时注明这句话出自哪份文档的哪个章节。答不上来的情况下明确说不确定而不是硬编一个答案。把这三个问题定清楚后面所有的数据整理、提示词编写、效果评估都有了标尺。4.2 把散文档变成可检索的知识库知识库建设是整个项目里工作量最大、最影响效果的一步我习惯把它拆成五个步骤来走。收集文档。从设备管理员、技术科、老师傅手里把相关手册、保养记录、故障案例、整改报告全部收上来。这一步重点不是“多”而是“新”——一定要用最新版本文档旧版标准反而会误导模型。解析文档。PDF先试直接提取文字不行就上OCR。Excel要用程序读表格图片类的运行记录要按页转文本。解析完成后人工抽查10%-20%确认没有严重乱码。清洗内容。去掉页眉页脚、重复的封面版权页、目录和页码把表格转成“字段:值”的文本描述因为模型读表格的能力有限转成文本更稳定对明显残缺的段落标注“原文不完整”。切分文本。按照标题层级和自然段落把文档切成200到400字的小块相邻两块保留50字左右的重叠。为什么要这么切太长了相关知识点淹没在无关内容里检索召回精度下降太短了上下文断裂模型理解不了前后逻辑。重叠是为了避免句子被从中间截断导致语义不完整。向量化入库。用Embedding模型把每一块文本转成向量连同标题、文档来源、原文内容一起存进向量数据库。这一步完全是批量处理的活跑完就算知识库建好了。注意这一步占了整个项目60%的工作量也决定了最终效果的60%。别指望跳过它直接让模型“自己学”模型不会自己读你公司的内部文档。4.3 写Prompt和跑通主流程附Python示例知识库建好之后写一套能稳定运行的Prompt。我提供一套验证过多次的模板你按需改。角色你是一名设备维修助手服务于生产车间的维修工。 任务根据【参考资料】回答用户关于设备故障排查和保养的问题。 原则 1. 只能根据【参考资料】回答不得使用资料之外的假设。 2. 如果参考资料中没有明确答案直接回复“资料库中没有找到相关说明建议联系设备厂家或查阅最新手册。” 3. 回答必须按操作步骤列出步骤要具体可执行。 4. 每条步骤后标注来源格式为“【来源文档名/章节名】”。 5. 如果用户描述的现象模糊先请他补充关键信息再给出排查建议。 【参考资料】 {检索回来的文本片段} 【用户问题】 {用户输入}你看到这个Prompt的核心价值在哪吗它把模型的角色限定死把回答边界框死把“不装懂”写成了硬性规定把引用来源变成了必答项。这一套组合拳下来模型就算想“自由发挥”也无从发挥。跑通整个流程核心逻辑其实不复杂给你一段简化的Python伪代码帮助理解主流程def answer_question(user_query: str) - str: # 1. 查询改写 rewritten_query rewrite_query(user_query) # 2. 向量检索 关键词检索 融合重排 candidates vector_search(rewritten_query, top_k20) candidates keyword_search(rewritten_query, top_k20) best_chunks rerank(candidates, user_query, top_k5) # 3. 组装Prompt reference_text \n\n.join( f[{chunk.meta[doc]}/{chunk.meta[chapter]}]\n{chunk.text} for chunk in best_chunks ) prompt PROMPT_TEMPLATE.replace({参考资料}, reference_text) prompt prompt.replace({用户问题}, user_query) # 4. 调用模型生成回答 answer call_llm(prompt, temperature0.2) # 5. 简单可靠性校验关键信息是否能在参考资料中找到 if not verify_answer(answer, reference_text): answer 无法根据现有资料确认答案建议联系设备厂家。 return answer这段代码就是RAG的全部核心。看到没真正复杂的不是调用模型而是前两步——把问题找对、把相关资料找全。这两步做扎实了最后生成的答案往往是高质量的。第一版代码跑通后强烈建议你做一次“人工走查”挑10个问题先手动从文档里找出对应的参考资料把“正确资料问题”喂给模型看输出是否合格。合格说明Prompt没问题不合格先改Prompt不要急着怀疑模型。4.4 用20条真实问题做效果评估系统跑起来之后要有据可依地判断它行不行不能光靠“感觉还行”。我的做法是建一套迷你评测集。收集20条真实问题分成三类高频故障类如“泵打不上压”、模糊描述类如“设备有异响怎么回事”、资料中无答案类如“xx型号停产了没有”。前两类测模型能不能答对、答全第三类测模型会不会老老实实拒答。评估指标设四个答案正确率、引用命中率、格式合规率、拒答率。正确率也就是跟标准答案比对是否给出正确的排查方向引用命中率看答案标注的来源是否真实存在于知识库格式合规率看是否按步骤输出拒答率看“无答案的题”中模型是否克制住没瞎编。这四组数字跑完你基本知道问题出在哪层。如果答案内容对但引用是编的那问题出在“模型自由发挥”调Prompt、加校验如果答案里根本没有相关信息那问题出在检索排查切分和重排如果特定主题老答错大概率是知识库里这块资料太少补充文档比调模型更有效。记住这个调优顺序先检索再Prompt最后才考虑微调。5. 工业落地中的常见问题与排查心得5.1 模型答错、胡编、查不到怎么办工业落地现场你会遇到的九成问题归纳起来就三种答非所问、答案里掺了假东西、明明有资料却查不到。答非所问先看是不是用户的问题太模糊。“设备坏了”和“设备启动时报E023报警电机不转”前者神仙难救。解法是在Prompt里加一条“如果用户描述模糊先引导补充关键信息”同时系统层面做一次查询改写把口语问题补全成更完整的描述。答案里掺假也就是幻觉是最破坏信任感的问题。缓解手段我已经说了不少这里再补充一个细节在Prompt里明确写“你的回答中每个关键结论必须能从参考资料的原文中找到”并且把所有不明确的地方都换成保守表达。再配合最后的引用校验能挡掉八成以上的明显幻觉。查不到资料先怀疑切分粒度。如果正确内容被切成了两三块没被召回到前5名那模型看不到就答不出来。把窗口从5提到8一两个反复实验就明白了。还有一个常见坑是Embedding模型对专业词支持不好厂里的“E023”“离心泵机封”这种词在向量空间里没有得到很好区分这时就要补充关键词检索或者给知识库里的文本做二次清洗把专业名词单独列出和正文关联。我整理了一张排查速查表项目上线初期你大概率用得上现象可能原因处理方式答案与资料矛盾Prompt未限定资料来源加强Prompt边界引用校验相关段落未被召回切分粒度不合理调整切分长度、补充关键词检索回答过于笼统检索内容覆盖不全增加召回数、补充知识库资料相同问题答案不稳定Temperature过高调到0.1-0.2特定型号设备老答错该型号资料缺失补充对应文档而非调模型引用来源不存在模型编造引用强制引用格式后置校验5.2 性能上不去、成本兜不住怎么办工业系统对响应时间的要求很现实现场工人没耐心等一个超过10秒才出答案的工具。性能排查先分清慢在哪一段。是检索慢向量库里数据量也不大不太可能是模型生成慢7B模型生成100个Token大约需要两三秒属于正常范围。如果并发一高就卡最常见的原因是显存带宽不够模型同时处理太多请求。优先解法不是换更强的卡而是给推理服务加副本、加负载均衡同时控制单请求的输入长度——把召回的片段从5段减到3段对响应时间的改善立竿见影。成本控制在工业项目里同样不可忽视。建议从日志里统计每天每个问答平均消耗的Token数你会惊讶地发现大量成本浪费在“用户重复提问同样的问题”和“上下文里塞了太多没用资料”上。前者可以做缓存一模一样的提问直接返回缓存答案后者靠优化检索质量别让模型每次开卷都看一大堆无关内容。5.3 最难的不是技术是让业务方相信它做工业落地久了你会发现技术问题都有解真正磨人的是人。老师傅不信任AI怎么办我的经验是从一个低风险、可快速验证的场景切入。别上来就做“工艺参数自动优化”这种动辄影响产品质量的项目先做一个“查手册”工具让工人自己验证答案的正确性。系统每一条答复都标注来源工人可以亲手去翻原文核对核对了几次没问题信任就建立了。专家不愿把知识写成文档怎么办别指望专家坐在那里写知识文档他们没这个时间也不擅长。换个思路让工程师去和专家聊天录下来整理成问答记录导入知识库。或者让模型根据历史工单生成一版案例初稿专家只需要做修改确认。把专家的角色从“作者”变成“审核者”配合度能高好几倍。跨部门协同散怎么办项目要成立一个虚拟小组IT负责部署和开发工艺部门负责提供资料和审核答案车间班组负责实际试用和反馈。没有这个三角结构项目多半会在某个环节断掉。从一个具体场景、一个明确痛线出发做出可量化的效果再逐步扩展范围。这比一开始就承诺“给全厂做大模型平台”靠谱得多。最后分享一点个人的经验。这两年我做过多个大模型项目最大的体会是先把一个最小闭环跑通比规划一个宏大体系重要一百倍。哪怕只是“一个设备、两份文档、二十个测试问题”跑通了团队的信心、业务方的信任才有基础后续推广只是复制粘贴。另一个体会是工业场景里一个“不太聪明但稳定可靠、每个答案都有依据”的系统远比一个“聪明但偶尔胡编”的系统更有生命力。在这一点上RAG加严格Prompt永远是我的首选方案不是因为它最先进而是因为它最能守住底线。
阅读完成 · 觉得有帮助？
