煤矿安全领域的智能化最忌讳的就是“花架子”。这个项目一句话说清楚把通用大模型在煤矿事故案例、安全规程、操作规程这些专业语料上做指令微调让它在回答煤矿安全问题时不再像通用模型那样“正确地说废话”而是能直接给出符合规程的、可参考的处置思路。项目核心工作围绕internlm2基座模型展开从数据处理、微调训练到评估部署走了一遍完整流程。这篇文章把整个过程的思路、步骤和踩过的坑都摊开来讲适合正在做垂直领域大模型应用的开发者和煤矿信息化从业者参考。1. 项目想解决什么问题煤矿安全知识管理的三个痛点煤矿行业积累了海量的安全知识资产——几十年的事故调查报告、逐年更新的安全规程、岗位操作规程、应急预案、瓦斯治理技术措施等等。但这些知识的利用效率说实话低得可怜。1.1 传统知识库的检索困境某矿业集团的案例很有代表性。他们早期做了安全知识库走的是关键词检索路线基于传统搜索引擎方案搭建把各类规程文档电子化、建立索引。实际用得怎么样一线安全员反馈很直接搜“瓦斯超限怎么处理”系统返回一堆标题含“瓦斯”的文档点进去得自己翻章节、对照条款、再结合现场情况判断。一次查询少说花十分钟有毒有害气体浓度都到临界值了谁有时间去翻文档传统检索的本质缺陷在于它匹配的是字面不是语义。同一种情境文档里写“掘进工作面回风流瓦斯浓度达到1.0%时必须停止作业、撤出人员、切断电源”安全员提问可能是“迎头瓦斯有点高怎么办”——字面上和“掘进”“回风流”“浓度1.0%”没有任何重叠检索系统自然给不出有效结果。1.2 为什么直接套通用大模型也不行通用大模型能力很强但拿到煤矿安全场景直接用会暴露两个硬伤。第一是领域知识的不完整性。通用模型训练数据里煤矿安全的语料占比极低。它能背出通用的安全生产方针但你要是问“采煤工作面回采期间上隅角瓦斯积聚如何处理”它的回答往往是综合了其他行业气体治理经验的“通用版”放到煤矿现场不一定能直接用。第二是安全敏感性。煤矿安全问答有个特殊要求答案必须严格对齐现行规程。通用模型没有经过针对性约束很容易出现“貌似合理、实则与规程条款有出入”的回答。比如问到瓦斯爆炸触发条件它可能给出一个通用可燃气体的爆炸极限范围但煤矿井下环境有特殊性规程里对瓦斯浓度的处置阈值有明确分级规定。这种东西含糊不得答错了真会出事。所以在数据工程和微调路线上投入精力是这类项目的必然选择。1.3 微调方案的整体思路项目的完整技术链路是收集煤矿安全领域原始语料 → 构建指令问答对数据集 → 基于internlm2基座模型进行参数高效微调 → 评估对比基座模型效果 → 部署推理服务。整个过程看起来不复杂但每个环节都有大量细节。下面按实操顺序拆开讲。2. 数据工程微调项目的生死线做过大模型微调的同行都有同感模型微调的代码工作其实标准化程度很高真正决定最终效果天花板的是数据。数据质量的好坏直接决定了微调是“让模型变聪明”还是“让模型背答案”。2.1 数据从哪来三类核心数据源煤矿安全领域的数据整理我把它分成三类第一类是权威规程类包括《煤矿安全规程》、各省级实施细则、行业标准。这类数据是最重要的微调模型必须能准确引用这些条款。但采集时要注意版本问题——规程有过修订不同年份的版本并存混在一起训练会让模型回答自相矛盾。第二类是案例复盘类包括历年煤矿事故调查报告、案例分析文章。这类数据能让模型具备“举一反三”的能力理解事故链条、违章行为、直接原因与间接原因之间的关系。某矿“一通三防”事故案例调查结论里对瓦斯传感器位置是否合规的分析对模型理解规程适用场景极有价值。第三类是岗位知识类包括各工种的操作规程、危险源辨识清单、岗位风险告知卡。这类数据贴近一线使用场景对应的是安全员、班组长、一线工人的常见问题场景。2.2 数据清洗的四个关卡原始数据不能直接拿来训练必须经过清洗。我实际流程中设了四道关卡第一关去噪去掉页眉页脚、水印文字、扫描件OCR产生的乱码符号。煤矿事故报告很多是红头文件扫描件OCR出来的文本经常混入“— 1 —”这类页码标记清洗时必须处理干净。第二关去重不同来源的数据大量重复同一个规程条款可能出现在规程原文、解读材料、培训讲义、考试题库四个地方多份文件措辞略有差异。直接丢进训练集会导致模型对同一知识点的表达不稳定。我的做法是基于MinHash做近似去重再人工抽查重复率高的段落确定保留版本。第三关版本对齐规程修订前后的条款内容冲突如何处理我的做法是只保留现行有效版本旧版本文档只保留事故案例中作为背景资料引用的段落且原始描述中明确标注的旧版条款要改写成现行表述。第四关质量复核文本压缩乱码、专业术语OCR错误。比如“瓦斯涌出量”被OCR成“瓦斯涌山量”“锚杆”变成“锚抒”这类错误在专业语料里尤其致命因为模型没法靠上下文猜出来训练完了就一直错下去。2.3 指令数据格式与示例微调数据集不是“提示词回答”这么简单。我基于实践效果推荐带任务描述的指令格式。针对煤矿问答场景我把指令任务划分为几个类型知识问答类直接回答规程条款和安全知识。案例分析类分析事故原因、责任认定逻辑。风险辨识类针对岗位操作场景识别危险因素。应急处置类给出处置流程和注意事项。数据格式示例{ instruction: 你是煤矿安全咨询专家请依据现行煤矿安全规程回答以下问题。如果问题涉及应急处置请分步骤说明。, input: 掘进工作面甲烷传感器报警值是多少达到报警值后现场人员应该怎么处理, output: 根据《煤矿安全规程》掘进工作面甲烷传感器的报警浓度设置为≥1.0%CH4。当甲烷传感器报警时现场作业人员必须立即停止作业撤出人员至进风巷中并切断掘进巷道内全部非本质安全型电气设备电源然后向调度室汇报。待采取措施、瓦斯浓度降至报警值以下并经检查确认后方可恢复作业。 }instruction字段描述任务背景和身份设定input是用户问题output是期望的标准回答。训练时模型学习的是看到特定的instruction和input生成对应的output。里面有个细节值得说在很多开源模型的训练格式里input字段和instruction是分开的但推理时可以拼接。实际使用中我们发现instruction如果写得过于具体模型会过度依赖某些固定句式写得过于简单回答又缺乏约束。经过多次对比实验最终定型为上面这种简洁版本——点明“专家身份依据规程分步骤”三个关键约束。2.4 数据量级与质量控制的几个关键经验很多人问“煤矿安全数据要做多少条才够”这个项目初期以为数据越多越好拿到接近6万条问答对结果训练效果并不理想。后来分析发现大量重复语义的问题占据了训练样本的很大比例。最终采用的有效策略是控制总量在1.5万到3万条高质量指令对优先保证数据的多样性而不是单纯堆量。严格保持各类任务均衡。知识问答占40%案例分析占25%风险辨识占20%应急处置占15%。比例失衡会导致模型在某一类任务上表现出色、其他任务上明显偏弱。对涉及明确数值、浓度、温度、距离等硬性指标的回答逐条由审核人员核对规程原文。这是整个数据标注过程中最耗时但绝对值得的一个环节。提示标注数据时绝对不能只让标注人员“对照文档改写”——必须要求标注人员具备一定的煤矿安全知识背景。否则标注者会把“瓦斯浓度达到1.0%时停止作业”改写成“瓦斯浓度高时需要停止作业”数值信息丢失了模型再训练也学不会准确的数字。3. 模型选型与微调方案设计数据处理好了下一个核心决策是用什么方式微调、用哪个模型。这两个决策会影响整个项目的算力需求、成本和技术路线。3.1 为何选internlm2作为基座模型开源社区的大模型很多选择internlm2主要是基于几个实际考量第一是中文语料能力。internlm2系列在中文数据上做了专门优化对中文长文本理解表现稳定。煤矿安全领域涉及大量中文专业术语和长段落描述对模型的语义理解要求很高。第二是长文本扩展能力。interlm2系列支持较长上下文这一点在做事故案例类问答时优势明显——很多事故调查报告本身就几千字模型需要综合理解前后因果关系才能回答完整的问题。第三是开源生态成熟度。模型权重公开、社区集成度高、配套训练工具链完善对团队做二次开发比较友好。当时也对比过其他同级别参数规模的模型但综合中文能力和工具链成熟度选择internlm2作为项目的基座模型实际效果确实稳。3.2 微调路线LoRA vs QLoRA vs 全量微调微调方式的选择本质是在效果、显存、时间之间权衡。全量微调Full Fine-tuning所有参数都更新效果上限最高但显存需求大一个7B级别的模型全量微调即使有足够显存支持训练时间也相当可观对硬件要求比较高。LoRALow-Rank Adaptation冻结基座模型参数只训练注入的低秩矩阵显存占用大幅下降效果在指令微调场景下通常追平全量微调。QLoRAQuantized LoRA在LoRA基础上对基座模型做4bit量化进一步降低显存门槛。一台24GB显存的消费级显卡也能跑7B模型微调。这个项目最终选了QLoRA路线。原因很直接没有多卡服务器只有单张24GB显存的显卡可用。全量微调完全不现实LoRA虽然也能跑但余量太小QLoRA框架下还能给训练留出充足的batch size提升空间。3.3 训练环境与显存规划显存是整个微调项目最紧的约束条件。7B模型按Q4量化后基座权重约5-6GB加上LoRA适配器、优化器状态、梯度、激活值配上一系列可调的缓解手段才在24GB卡上跑稳定。数据集每批样本的token长度差异很大有些事故案例分析类样本会突破2000 token。为了在有限显存内稳住训练最终设置的cutoff_len为2048训练数据中超过这一长度的样本做截断处理——优先保留output部分的内容保证关键知识不丢。关于训练轮数epoch和步数也做了实际对比实验。训练数据量1.8万条batch size搭配出来每轮约1000步。经验是epoch设为3-5比较合适超过5轮后开始出现过拟合迹象——训练损失持续下降但在验证集上Rouge分数反而回落。最终选取第3轮的检查点效果最均衡。4. 核心实操基于XTuner的QLoRA微调全过程工具链选型上采用XTuner作为微调框架。选择它的核心理由是它原生支持internlm系列模型集成了QLoRA整套实现配置简单直接。下面按实操顺序一步步说明。4.1 环境准备与依赖安装基础环境建议直接使用官方镜像省去不少兼容性问题。conda环境创建和依赖安装命令如下conda create -n xtuner python3.10 -y conda activate xtuner pip install xtunerXTuner官方镜像里的依赖版本搭配经过验证比自己一个个装稳得多。装完验证一下xtuner version能正常输出版本号说明环境OK。4.2 数据集格式化与配置XTuner的数据格式要求比较简洁。最终整理的训练数据是JSON格式每行一个样本形如{conversation: [ {system: 你是煤矿安全咨询专家请依据现行煤矿安全规程回答以下问题。如果问题涉及应急处置请分步骤说明。, input: 掘进工作面甲烷传感器报警值是多少, output: 根据《煤矿安全规程》掘进工作面甲烷传感器的报警浓度为1.0%CH4。} ]}这里要说一个关键经验system字段在数据构造阶段就要固定下来后续训练和推理必须使用同一个system提示词。我一开始没太在意这个问题数据里system写得不统一导致训练出来的模型对提示词非常敏感推理时换一个说法回答质量和稳定性立刻下降。后来把所有样本统一成同一套system设定问题才解决。数据准备好后按照XTuner的规范在数据集配置脚本中指定数据路径这个过程中需要注意数据路径别用相对路径直接写绝对路径最省心——别问我怎么知道的。4.3 训练启动与关键参数解读XTuner提供配置模板生成功能执行配置后生成配置文件然后需要修改几个关键参数。训练的核心配置如下# 模型路径 pretrained_model_name_or_path /path/to/internlm2-7b # LoRA配置 lora_rank 64 lora_alpha 128 lora_dropout 0.05 # 训练参数 data_path /path/to/coal_safety_train.json max_length 2048 batch_size 4 accumulative_counts 8 learning_rate 1e-4 max_epochs 3对于不熟悉LoRA机制的同学这里简要说明几个参数的逻辑lora_rank决定低秩矩阵的维度数值越大代表可学习的参数越多模型适应能力越强但过大的rank容易让模型在特定数据集上有“死记硬背”的倾向反而影响泛化。lora_alpha是缩放因子控制LoRA权重在原始权重上的叠加幅度经验上设为rank的两倍左右表现较好。learning_rate设置为1e-4比全量微调的常见学习率略高——LoRA只更新少量参数用较大的学习率才能让参数有效更新。训练启动命令xtuner train config.py --deepspeed deepspeed_zero2实测下来deepspeed zero2在单卡场景下能优化一部分优化器状态占用的显存虽然单卡环境zero2的收益不如多卡明显但聊胜于无。4.4 训练监控、断点续训与产物导出训练过程中的监控主要看两个指标loss下降曲线和验证集rouge分数变化。loss下降到一定程度后不再明显下降说明模型开始收敛。每次保存检查点后可以用验证集快速评测一轮打几个实际问题的回答样例看效果比纯看loss值可靠得多。训练中途中断是最常见的问题。显存不够、断电、机器被重启都有可能。XTuner和大多数框架都支持断点续训重新执行训练命令并指定--resume参数框架会自动从最近的检查点继续。不过建议每500-1000步保存一次检查点这样最多只丢失一小段训练进度。训练完成后需要把LoRA适配器权重和基座模型合并得到完整的微调模型xtuner convert pth_to_hf adapter_model.pth adapter_hf xtuner convert merge /path/to/internlm2-7b adapter_hf merged_model合并完成后微调模型就可以像基座模型一样做推理了。5. 效果评估模型到底能不能用在现场评估环节最考验耐心也是很多项目容易草草了事的一环。这个项目的评估分为自动化指标评估和人工专业评估两层侧重点不一样。5.1 自动化指标评估自动化评估使用一个独立的测试集包含500条精心筛选的问答对覆盖5类任务。评测指标用ROUGE-L和BERTScore这组搭配ROUGE-L衡量生成文本和标准答案在n-gram层面的重合度BERTScore则从语义相似度角度做补充。对比的重点是基座模型和微调模型的一组数据评估维度基座模型微调模型ROUGE-L0.210.57BERTScore0.620.84准确引用条款率12%78%问答长度平均字符240480基座模型的回答长度偏短内容概括性强很多错误集中在数值不准和条款混用上。最典型的表现是“甲烷传感器报警浓度”这类问题基座模型经常给出一个通用数值或者干脆编一个数值。微调后模型能够稳定输出规程规定数值并且附带了处理流程信息量和准确性都明显提升。5.2 人工专业评估维度自动化指标只能部分反映效果最终可信度还需要靠人工打分。邀请在煤矿安全工作多年的工程师从安全性、准确性、完整性、可操作性四个维度打分每个维度1-5分。安全性回答内容是否可能造成误导、引发错误操作是最关键的维度。准确性陈述的事实、数据、规程条款是否准确。完整性对问题的覆盖是否全面是否遗漏关键点。可操作性回答建议是否能直接用于现场参考。人工评估的结果微调模型在所有维度上都显著高于基座模型但在“可操作性”上仍然有提升空间——模型给出的处置步骤偏“规程语言”对现场快速响应要求下的简短指令式表达还是不够贴合。这个发现问题为后续迭代提供了方向。5.3 典型对比案例举一个差旅场景下的典型案例问题某回采工作面在放炮后出现大面积瓦斯涌出放炮员应首先采取什么措施基座模型的回答放炮后瓦斯涌出是正常现象应加强通风注意观察瓦斯浓度必要时佩戴自救器撤离。具体措施要结合现场情况确定。这个回答“看似正确”但信息极其模糊。“大面积瓦斯涌出”在规程语境下有明确的应对顺序基座模型完全没有触及。微调模型的回答放炮后出现大面积瓦斯涌出时放炮员应立即按规定发出警报停止工作面所有作业同时切断回采工作面及回风巷内非本质安全型电气设备电源人员沿避灾路线撤至安全地点。随后由瓦斯检查工对瓦斯浓度进行检查若瓦斯浓度超过规定值则按瓦斯超限停电撤人程序汇报调度室并由通风部门制定专项排放措施。两者的对比不用多说微调模型的回答能在现场直接指导操作。6. 部署落地与常见问题排坑模型训练出来只是第一步真正落地到实际应用还有不少工作。6.1 轻量化部署方案考虑到煤矿现场的硬件条件部署方案需要兼顾性能和成本。实际采用了两套部署路径。第一套是中心服务器方案在集团信息中心部署GPU服务器通过Web页面和API对外提供服务。适合有统一算力条件的场景集团机关和矿端可以通过浏览器访问。第二套是边缘轻量方案把模型量化后部署在一体机上供矿端无网络环境使用。实测下来量化后的模型4bit回答质量相比原版几乎无损失推理速度能满足交互式问答要求。煤矿安全生产的现场环境决定了很多矿井果然存在网络受限的情况——井下终端无法连接中心服务器。边缘部署虽然资源紧张但保证了核心场景可用性。6.2 我在实际项目中踩过的8个坑整理一下这个项目从头到尾最值得分享的排坑经验坑一数据里埋了“位置编码泄露”——训练数据的instruction字段统一以“你是煤矿安全咨询专家...”开头但推理时用户不会重复说这句话。如果不单独设置system prompt模型会以为用户的问题前面带着身份设定导致生成内容偏“说教”。解决办法就是前面强调的训练和推理必须使用完全一致的提示词模板。坑二标注人员对规程理解不一致——多名标注人员各自理解不同“浓度达到1%时停止作业”有的写“达到”、“超过”还是“达到或者超过”细节表述不一致。这类偏差在训练数据里累积会让模型给出的数值边界产生模糊。花了整整一周做标注规范统一重标了部分数据。坑三cutoff_len设置过小——初始设置为1024导致大量需要完整答完的应急处置类问答被强行截断回答后半段的内容训练不到。调整到2048并做样本截断优先级处理后这类问题明显改善。坑四训练显存溢出——batch size设为8直接OOM。通过降batch size和提高累积步数来等价扩大有效批大小代价只是训练时间延长但稳定性大幅提升。坑五过拟合与通用能力丧失——训练轮数超过5轮后模型在煤矿安全问答上表现越来越好但通用对话能力退化明显问它“今天天气怎么样”都会往瓦斯浓度上靠。这是典型的灾难性遗忘。给出的建议是控制epoch数在3轮左右或者在训练数据中混入10%的通用对话数据保留基础能力。坑六LoRA rank选择过大——实际试过把rank设为128发现训练时间增加明显但评测分数没有提升反而在某些案例题上泛化变差。最终64更合适。坑七推理温度设置不当——煤矿安全问答要求确定性高默认temperature值偏高会导致同样的提问每次回答细节有出入。将temperature调低到0.1后回答稳定性显著提升。这个调整虽小但对落地体验影响非常明显。坑八测试集与训练集信息泄露——早期评估结果虚高最终排查发现测试集里有大约80条问题和训练集存在语义重复相当于“开卷考试”。重做了测试集的隔离处理后分数回落到了真实的水平线。做评估时“干净测试集”这条红线一定要守住。6.3 后续还可以怎么做这个项目做完第一版微调模型后我认为还有几个明确的迭代方向。一是与检索增强结合把微调模型作为生成底座再外挂实时更新的规程库和案例库解决“模型知识过时”的问题。煤矿安全规程发生变化后重训模型成本高、周期长检索增强能够快速把更新内容纳入知识体系。二是多模态扩展。煤矿安全很多信息存在于图纸、照片、监控视频中——比如采掘工程平面图的通风系统标注、机电设备的隐患照片。接入视觉多模态能力后用户可以直接拍照问模型。这对现场应用的实用价值会更大。三是继续做垂直场景细化。目前模型是“煤矿安全问答通用版”下一步可以针对“一通三防”“机电运输”“顶板管理”等专业方向分别微调专属版本的模型每个方向的回答会更加专业深入而不是面面俱到但每个方向都不够深。从我个人实际经验来说做这类垂直领域大模型项目最核心的心得就是不要被模型训练本身迷惑数据质量、评估闭环、工程落地的扎实程度才是决定项目成败的胜负手。一个经过了扎实数据治理和严谨评估的微调模型哪怕技术上没有特别花哨也会在实际使用中表现稳定可靠。