上周一个做设备维护的朋友给我打电话说他们公司老板从某个行业峰会回来要求把大模型用起来先做一个内部知识问答系统。他问我到底什么是token为什么别人都说要用RAG模型微调是不是必须做如果不动手就永远只能看热闹一动起手来全是概念和术语的拦路虎。这篇指南就是给他写的也是给所有想搞明白大模型、又想真正落到工业现场的小白和程序员写的。我用实际落地的视角把核心概念拆开揉碎再讲讲在工厂、设备、质检、运维这些场景里大模型到底能干什么、不能干什么、以及怎么下手。1. 工业现场的真实变化大模型不再只是聊天玩具1.1 从客服问答到班组看板的转变去年大家聊大模型十有八九都在聊写文案、画图、陪聊天。但今年我在各种制造企业的交流里明显感觉到风向变了。企业老板问的不再是AI能不能帮我写周报而是能不能把老师傅脑子里的经验留下来能不能让新人快速学会设备操作能不能自动看一遍质量检测报告。这些问题有一个共同点它们都发生在生产现场离聊天很远离干活很近。我见到的一个实际案例是某机械加工厂他们用大模型接入了班组的设备点检记录。工人每天要把巡检数据、异常情况、维修过程写成纸质单子再录入电脑。现在大模型可以先把照片里的手写点检表识别出来再自动生成结构化记录最后按模板生成当天的设备状态报告。整个过程不是炫技就是把原来3小时的手工活压缩到20分钟。这就是工业领域的变化大模型开始从内容生成工具变成流程自动化工具。它不再只负责说还要负责看读整理判断。1.2 工业场景里大模型能稳住的三个位置我把能落地的场景归纳成三类知识问答、文档处理、过程辅助。知识问答最容易理解就是让大模型基于厂里的设备手册、工艺文件、安全规程回答问题。文档处理是把扫描件、手写单、PDF表格变成结构化数据再送进ERP或MES系统。过程辅助是让大模型参与具体流程比如依据实时数据生成参数调整建议或者帮质检员预判缺陷类型。这三类场景有一个共同特征它们都不要求大模型提供终极正确答案而是要求它把重复劳动自动化同时把人的经验固化下来。这不是取代人而是让人有更多时间去做真正需要判断的事情。1.3 为什么偏偏是现在这个时间窗口三年前也有人说要搞工业AI但那时候成本高得离谱。一个定制模型要几百万识别精度还不稳定小企业根本玩不起。现在不一样。大模型把通用理解能力变得极其便宜工业落地不再需要从零训练而是可以在一个强大的底座上做适配。加上开源模型的成熟本地化部署的硬件门槛也降下来了。一台工业级服务器就能跑起百亿参数级别模型这在三年前是难以想象的。时间窗口的意义在于现在花小钱就能试错试错成本低了企业才敢迈第一步。这个阶段最怕的不是做不好而是不知道从哪下手。2. 三个基础概念务必在动手前吃透2.1 Token计费、速度和上下文长度的计量单位第一次接触大模型的人对token这个词肯定很懵。我打个比方模型不吃字吃词块。一个token可以是半个词、一个词、一个标点也可以是几个字符组合。英文里一个单词通常约等于一个token中文里一个字大概能拆成0.6到1.5个token。这玩意儿直接决定了你要掏多少钱也决定了模型响应有多快。以目前主流商用接口价格来看假设输入百万token收几十元输出百万token收一两百元一次普通问答消耗几百到上千token成本确实很低。但工业场景一旦跑批量任务比如每天处理几千份文档这个成本就需要认真估算它不是实验室里那点试玩量。# 一个简单的估算思路 # 假设平均每1000个汉字约等于1500个token # 单份设备维修报告约2000字生成结构化摘要需输入输出约5000个token single_doc_tokens 5000 daily_docs 800 monthly_cost single_doc_tokens * daily_docs * 30 / 1000000 * price_per_million # 如果输入输出均价约为每百万token 60元 price_per_million 60 print(f月成本约: {monthly_cost:.0f} 元)所以第一个要吃的概念就是token它既是理解能力的边界也是成本的基本单位。在做方案的时候先把每天的token消耗估算清楚预算数字才靠谱。2.2 预训练与微调从读过万卷书到带过一条产线大模型出厂前已经被喂过海量互联网文本这叫做预训练。你可以把一个预训练模型想象成一个读过万卷书的实习生他什么都懂一点但完全不了解你们厂里的操作流程。微调就是在这些通用知识的基础上用你们厂自己的语料再做一轮额外的训练让模型更贴合特定术语和表达习惯。投喂几百条到几千条高质量样例模型就能学会说话方式——哪种缺陷叫发纹哪种叫折叠设备报警背后的处置顺序是什么。但是这里必须说一句大实话微调不是万能的。它擅长改变模型的说话风格和输出形式但如果你的核心需求是让模型知道某个具体文档里的内容那应该用后面要讲的RAG而不是微调。因为微调是让模型记住规律RAG是让模型查资料。2.3 上下文窗口模型能看到多长的作业指导书上下文窗口描述的是模型一次能处理多少token的上限。主流模型从几万到几十万token不等。工业场景里一份长的设备说明书可能上万字塞进模型前必须考虑它能不能一口吃完。如果你的上下文窗口不够大面对长文档就只能截断而截断往往丢掉关键参数。所以选模型的时候不光要看价格还要看窗口长度。我的经验是不要只看窗口上限还要看在窗口较长时模型的实际表现会不会变差。做到后面你会发现长文本能力比多一个百分点的准确率更重要。3. 从理解概念到能干活RAG、微调与Agent的分工很多初学者会陷入一个误区拿到大模型先想着微调。实际上工程上最常用、见效最快的第一个动作是搭一套RAG系统。3.1 RAG给模型配一个可以实时更新的厂区档案室RAG全称是检索增强生成。核心流程是把你们厂的文档先切块、向量化存进一个向量数据库用户提问时先从库里检索出最相关的几个片段再把这些片段连同问题一起交给大模型让它基于这些材料作答。我用一个模拟项目X来解释整套流程这是某设备制造企业的一个知识库问答系统。语料包括设备说明书、维修案例、安全规程一共约两千份PDF。第一步是文档切块。注意切块策略直接影响检索效果。我建议先用章节标题做粗切再把过长的段落按固定长度切重叠部分设成几十个token避免关键信息被截断。from langchain.text_splitter import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size400, chunk_overlap50 ) chunks text_splitter.split_text(document_text) print(f共切出 {len(chunks)} 个片段)第二步是向量化。把每个片段转成一个高维向量意思相近的文本在向量空间里距离也近。第三步是检索用户问题也转成向量在库里找最接近的那几个片段。最后一步才是生成模型看到问题和检索结果组织出回答。我在这个模拟项目里试过纯靠模型直接回答准确率不到六成加上RAG之后在题库里的准确率能到九成以上。原因是RAG绕开了模型死记硬背的短板让模型做它最擅长的事从给定的材料里整理答案。3.2 微调当通用能力不够时教它说行话RAG解决了模型不知道的问题但有时候你需要的是模型按你的格式说话。举个例子某铸造车间的质检报告要求输出固定格式缺陷IDXXXX 缺陷类型气孔/缩孔/裂纹 位置冒口 / 侧壁 / 底角 严重等级A/B/C 处置意见抛光/补焊/报废通用模型也能写但经常出现格式漂移甚至自创等级。这时候我用几百条真实标注样本做了一次微调效果立竿见影。微调的本质是让模型学习你的输出分布相当于给它看了一堆标准答案它就知道你要的是什么形状的回复。微调需要注意样本质量远大于数量。我见过有人堆了上万条杂乱数据效果还不如五百条精心整理的数据。另外微调后的模型不能替代RAG的实时检索二者是配合关系。3.3 Agent从回答问题到代替人跑流程RAG和微调还是停留在问-答层面Agent则更进一步模型不光回答问题还能调用工具、制定计划、执行一系列动作。工业场景里一个典型Agent流程可以是收到设备报警→调用接口获取实时参数→读取历史维修记录→判断故障类型→生成处置建议→通知对应班组。每一步由大模型决策工具负责执行。我在另一个模拟场景里做过一个小实验让Agent帮工艺工程师找参数异常原因。它先查了当日生产记录又比对过去一周的良率曲线最后定位到冷却水温波动并给出了调整建议。整个过程大约花了三分钟换成人来做可能要翻三个系统、查两小时。但Agent的问题也很现实只要中间一步判断错了后面可能全错。工业场景不能容忍这种链式错误所以我对Agent落地的建议是可执行的步骤加人工确认节点严禁全自动闭环。3.4 三者的选型决策什么时候用哪个我给自己定的决策逻辑很简单需求类型首选方案原因让模型基于厂内文档回答问题RAG实时更新、可追溯、无需训练成本让模型按固定格式输出微调控制输出结构和术语习惯让模型替代多步骤操作流程Agent工具调用任务编排混合场景RAG微调 / RAGAgent根据瓶颈在哪决定加什么先用RAG解决信息获取再根据输出格式问题判断要不要微调最后才考虑用Agent编排流程。这个顺序可以省掉大量试错时间。4. 落地前必须算清的账成本、数据与效果验证4.1 一次真实的成本估算过程做方案最怕拍脑袋报价。我按照某中型工厂的实际情况估算过一次推理成本。该厂每天新增设备维修工单约200条系统在每条工单生成后自动调用模型做结构化提取和摘要平均每条消耗输入输出共5000token左右。每日消耗约100万token每月约3000万token。如果采购商用接口按输入百万token收费几十元、输出百万token收费几十至两百元不等综合均价每百万token约60元月成本约1800元。加上向量化、人力和开发时间首期试点成本完全可以控制在数万元内。我的建议是先把成本模型写进方案里并且留出3到5倍的冗余因为真实工业数据的复杂度通常会让token消耗超出你的预期。4.2 数据准备工业数据比想象中更脏我接触过不少工厂的知识库文档格式五花八门扫描版PDF、照片、Excel表格、老旧的txt。更麻烦的是同一个名词在不同部门有不同叫法点检和巡检可能是同一件事间隙和游隙经常混用。数据清洗是大模型落地里最不起眼、但最花时间的一环。我惯用的流程是文档去重同一个文件在不同服务器上存了多份先做哈希去重。格式统一PDF转文本图片做OCR表格转Markdown。术语对齐建一个同义词表把游隙/间隙合并成标准词。敏感信息标注设备参数可以进库人员姓名、薪酬信息必须脱敏。这个过程很枯燥但没有干净的数据后面RAG检索效果会很差模型生成的内容也会连累整个系统的可信度。4.3 评测集没有评测就没有改进大模型项目的效果不能靠感觉回答得不错。一定要建立一套评测集把常见的、易错的问题固定下来每次改动之后都跑一遍。我做过一个评测集包含100个知识问答题目20个文档提取任务10个格式生成任务。每次调整切块方式、换模型、改提示词都在同一套题上打分。用这个办法我能明确知道某次改动是变好了还是变差了而不是靠拍脑袋。评测集要覆盖三类问题基础检索类、推理判断类、格式输出类。每一类单独算分。这样改进的时候你能精确知道短板在哪一块。4.4 供应商选择和私有化部署的取舍工业企业的数据敏感度很高不一定愿意把工艺参数传到外部接口。所以选型时必须考虑私有化部署的可能。开源模型方案是当前一条性价比很高的路径。显存需求相对可控百亿参数级别的模型用一到两张工业级显卡就能跑起来。但这个方案意味着你要自己处理工程问题推理加速、并发调度、模型更新、运维监控每一样都需要人。另一个选择是商用接口配合私有化网关。这样既能用上更强的模型能力又能把数据流转记录留在自己的系统里。看起来成本高一些但对于很多制造企业来说省下的运维人力可能更划算。我的经验是先在线跑通业务逻辑再评估要不要私有化。很多项目根本走不到私有化那一步因为业务验证阶段就发现ROI算不过来了。5. 小白最容易踩的四个坑以及绕坑方法5.1 把幻觉当功能缺陷到处救火大模型会一本正经地胡说八道。这不叫bug这叫幻觉是当前技术阶段固有的特性。很多第一次做项目的人遇到模型输出错误信息第一反应是去调参数、换模型折腾一圈发现依然存在。正确做法是建立事实锚点关键数据要么来自检索到的文档要么来自外部系统接口模型不应该被要求凭空记住精确数字。在提示词里明确写仅根据给定的资料回答资料不足时明确说不清楚能在一定程度上减少幻觉但真正可靠的做法是在流程上做验证。我在实际系统里给模型生成的内容加了一道复核让模型把自己给出的关键结论与检索片段再次比对不一致就打回重新生成。这个方法不完美但能把明显幻觉拦下一个数量级。5.2 一开始就追求100%准确率见过很多项目在起步阶段就要求准确率必须达到99%以上结果项目一两年都上不了线。工业场景里正确率当然重要但要分场景讨论。对于辅助类场景比如帮助生成点检建议、整理文档摘要90%以上的准确率配合人工复核完全可以使用。对于自动判级场景比如质量缺陷自动分类那确实需要极高精确率和召回率否则产线误判代价太高。正确路线是第一版跑通流程把人工复核放在输出端跑一段时间积累真实业务数据后再逐步收紧自动化范围。先让人机协同跑起来比闷头打磨一年算法有用得多。5.3 忽略权限与审计大模型系统在工厂里最大的隐性风险不是技术本身而是权限失控。不同岗位能看到的知识范围不同工艺员能看完整配方产线工人只应该看操作相关的部分。如果系统不做权限隔离或者聊天记录没有留存审计出了问题就是大事故。做系统设计时我会强制要求每个知识片段带上访问权限标签用户提问时先做身份验证再决定检索范围。同时所有问答记录保留至少六个月关键操作留痕。这些在原型阶段就要考虑不要等上线后补。5.4 只买模型不建团队很多企业以为买一个模型API就万事大吉。事实上模型只是一个引擎真正的价值在于数据准备、提示词工程、业务对接、效果评测这些都需要有人持续维护。我在某企业的经验是核心成员不需要很多两三个人足够。一个懂业务的工艺老手负责数据梳理和效果验收一个熟悉工程实现的开发者负责系统搭建和接口对接。这个配置小到能跑起来大到能持续迭代。比采购昂贵平台更重要的是有人理解这套系统是怎么工作的。6. 给两类读者的起步路线图6.1 非技术背景的读者如果你不是程序员不要先学编程。你的优势在于懂业务、手上有数据、知道痛点在哪。我建议的路线是找三个最重复、最耗时的日常工作把它们写成清单。试用现成的大模型产品把清单里的任务贴进去看输出质量。熟悉token和上下文窗口的基本概念能看懂技术方案。和技术同事一起做一个小范围试点比如一个班组、一类文档。你要做的是产品和业务之间的桥梁不需要写代码但需要能把需求讲清楚输入是什么、输出要什么、谁能验收。6.2 程序员读者如果你是程序员重点应该放在工程链路而不是天天刷模型排名。我的建议是先搭一个最小RAG系统文档切块→向量化→检索→生成跑通整条流水线。掌握提示词调优用结构化的指令约束输出格式这是成本最低的优化手段。学会评估系统建评测集、跑分、对比不同配置让每个改动有据可循。再考虑优化缓存、并发、流式输出、模型量化这些工程细节决定生产可用性。不要一上来就分布式、高并发工业场景的量级往往不需要那么复杂的架构。先把一条链路的完整度做扎实比炫技重要得多。6.3 我个人的经验和一个小技巧做这类项目多了我最大的体会是大模型落地工业的成功率不取决于模型聪明不聪明而取决于你是否理解现场的水有多深。数据整齐程度、权限边界、操作习惯任何一个环节都可能让系统做出来的效果跟概念演示完全两样。最后分享一个小技巧在做任何大模型方案之前花一天时间跟着产线工人或者工程师走一遍流程。记录他们真正怎么做而不是看SOP怎么写。很多需求文档写的自动生成报告实际上只是最不痛的一环真正让人头痛的是数据进来的那一段稳定、准确地把分散在各处的信息收拢到一起这才是最值得投入的地方。我见过太多项目倒在这一步之前也希望看到这篇文章的你第一步就能踩对地方。