工业机器人对话数据集IRWOZ 2.0：LLM驱动的构建方法与工程实践

1. 项目定位工业机器人为什么需要一份专门的对话数据集1.1 需求背景从示教器到自然语言的跨越在车间里待过的人都清楚传统工业机器人的交互方式有多不友好。示教器上密密麻麻的菜单、坐标系、点位数据、速度百分比操作工要经过几周培训才能勉强上手换个型号又要重新学一遍。产线上临时要改一个抓取位置、调整一段焊接路径都得喊工程师到场拿着示教器蹲在设备旁边一行一行调参数。这种模式的瓶颈不在机器人本身而在“人机沟通”的效率。这几年大语言模型LLM的火热让不少人开始琢磨一个很自然的问题能不能让操作工直接用自然语言跟机器人对话“把3号工位的速度降到50%”“机械臂在到达B点之前先停一下”“刚才那道焊缝的电流参数是多少”——如果这些话能直接被机器人理解并翻译成控制指令产线调整的效率会提升一个量级。想法很美好落地却卡在数据上。通用对话数据集比如MultiWOZ、TaskMaster覆盖的是订酒店、查公交、点外卖这类开放域任务领域词表和对话逻辑跟工业场景完全不搭。工业机器人对话涉及设备控制、参数查询、报警处置、安全确认等专用任务槽位结构、语句表达、交互约束都和日常对话差别巨大。没有领域数据再强的LLM也跑不出靠谱的工业对话系统。这正是IRWOZ 2.0这类项目存在的根本原因——它要填补“工业机器人自然语言交互”这个细分方向上的数据空白。1.2 IRWOZ 2.0是什么不是又一个闲聊数据集IRWOZ全称是Industrial Robot Wizard-of-Oz命名沿用了Wizard-of-OzWOZ数据收集范式。所谓WOZ通俗讲就是让真人扮演“背后的大脑”模拟系统跟用户对话从而快速采集真实交互数据早期对话系统研究大量使用这种方法。IRWOZ 2.0把这个范式往前推了一步不再完全依赖人工编排而是引入大语言模型来驱动对话数据的生成、标注和质量控制。从数据集内容来看IRWOZ 2.0覆盖的是工业机器人运维与操作场景中的多轮对话核心任务包括设备启停控制、运动参数调整、运行状态查询、报警信息处置、维护保养建议等。对话中的用户不仅会直接下达指令也会以自然口语的方式提出模糊请求比如“这边产线有点不对劲二号机好像过热了”——这时候系统需要做出状态判断和意图澄清而不是简单匹配关键词。这个数据集的定位非常明确它服务的是“工业对话系统”的研发而不是通用聊天机器人。用它微调出来的模型目标是理解“夹爪开度调到15毫米”意味着什么并序列化成机器人可执行的指令目标是知道用户说“急停”时必须走安全确认流程而不是闲聊式地回应“好的呢”。这种“面向执行”的对话数据才是工业场景真正稀缺的资产。1.3 适合谁参考如果你是做对话系统、任务型机器人研发的工程师这个数据集是很好的领域微调语料和评测基准。如果你在做工业自动化相关的AI应用想给产线设备加一个“能聊天的操作界面”IRWOZ 2.0的意图体系和对话结构可以直接当模板用。即使你不做工业方向只对“如何用LLM构建领域数据集”这个方法论感兴趣这个项目的思路——用LLM做数据生成后用规则和人工双重校验——同样有很强的参考价值。2. 工业对话场景的特殊性与任务体系拆解2.1 与开放域对话的核心差异很多人第一次看到“工业机器人对话数据集”会觉得不就是对话数据吗把MultiWOZ换个场景不就完了真做起来会发现完全不是一回事。第一工业对话是“低容错”的。订错一家酒店可以取消重订但给机器人下错一条运动指令轻则撞机、重则伤人。所以工业对话系统的每一个关键指令都需要确认机制对话数据里必须包含大量的“系统复述—用户确认”交互对。这种安全确认在开放域数据集里几乎不存在。第二工业对话强依赖数值与单位。开放域对话的槽位大多是地名、人名、商品名这类离散符号而工业场景里大量槽位是连续的速度百分比、温度阈值、距离毫米数、加速度曲线。同一个数值用户可以说“五十”“50”“5成”“一半”系统都要能解析成标准化的数值槽位。更麻烦的是单位换算“一米半”“1500毫米”“1.5m”表达同一个意思工业数据集必须显式处理这种多表征对齐。第三工业对话经常出现多设备协同与上下文回溯。用户可能先讨论了3号机械臂的抓取速度过了五轮对话又回头问“刚才的速度参数别动只改加速度”。这种跨轮次引用、指代消解和部分状态更新的能力对数据集的对话结构设计提出了很高要求。这三个差异决定了简单套用开放域数据的意图标签和对话状态表示DST根本行不通。IRWOZ 2.0的价值就在于把这些工业特性显式地建模进了数据集的schema里。2.2 意图体系设计不只是“控制”和“查询”数据集的核心是意图体系。IRWOZ 2.0的意图设计我拆解下来大致可以分成四个层级。设备控制类包括启动、停止、急停、暂停、恢复、切换模式、执行程序等。这类意图最大的特点是必须伴随参数槽位和执行确认。比如“把1号机械臂切到自动模式”“切换模式”是意图“1号机械臂”是对象“自动模式”是参数整条指令在执行前需要系统复述确认。状态查询类查询设备运行状态、实时参数、历史数据、报警记录等。查询类对话通常是单轮为主但难点在于查询条件的组合表达。“查看今天下午3点之后2号工位出现过哪些报警”时间、设备、事件类型三个约束条件叠加对语义解析的要求比单纯控制指令更高。参数调节类设置或修改机器人的运动参数、工艺参数如速度、加速度、力矩阈值、焊接电流等。这类意图与数值槽位绑定最紧数据集中会出现大量带单位、带范围、带比较关系的表达。报警与异常处置类这是工业对话最特殊的部分。报警发生后用户可能说“3号机在响红灯怎么办”系统需要识别报警类型、查询报警代码、给出处置建议必要时执行安全联动操作。这类对话往往是多轮的因为处置过程本身就是一个流程确认报警—排查原因—执行操作—验证恢复。2.3 槽位与约束表达数值、单位、范围槽位设计直接决定了数据集的可用性。IRWOZ 2.0里的槽位除了常规的“设备ID”“动作类型”之外工业特色体现在下面几类数值槽位。比如speed_percent、temperature_threshold、distance_mm每个槽位都允许数值多表达。数据集在设计时会为每个数值槽位记录原始表述和标准化数值两份信息方便训练模型做“自然语言数值到结构化参数”的转换。约束槽位。用户在提需求时经常带约束条件“在3号工位完成当前任务后再执行”“速度不能超过80%”“加速度调到之前的1.5倍”。这类约束或比较关系如果被忽略生成的执行指令就是错的。数据集在DST里单独设计了constraint字段来承载这些比较逻辑。对象槽位。工业场景的设备往往有层级关系车间—产线—工位—设备—部件。用户说“把那边的机械臂停一下”“那边”可能是通过手势或视线指定的这在纯文本对话里无法消解数据集会通过预置场景上下文来模拟部分这种引用但更复杂的空间指代则需要结合视觉这也是后续版本可以扩展的方向。槽位设计的核心原则是“宁可细不可粗”。粗粒度槽位训练出来的模型上线后遇到真实场景的细分参数就会手足无措细粒度槽位虽然初期标注成本高但一旦LLM进入标注链路这部分成本能被显著压缩。3. 从1.0到2.0LLM驱动的数据构建方法论3.1 WOZ范式与第一版的瓶颈第一版IRWOZ采用的是传统WOZ流程编写对话脚本—招募标注员扮演用户和系统—人工录制多轮对话—事后标注意图和槽位。这种方法的优点是数据真实、贴近实际表达缺点是慢、贵、规模上不去。做过数据采集项目的人都懂这种痛苦。一个覆盖20种意图、40个槽位的工业对话数据集如果要做到对话轮次分布合理、意图覆盖均匀、表达多样性足够人工录制至少需要上千组对话。每组对话从场景设计到录制完成到标注校验熟练团队也要半小时以上。算下来一个人日最多产出不到20组合格对话而要支撑一个大模型微调数据量至少需要五位数。这个成本在工业场景预算里几乎不可接受。更大的问题在一致性。十个标注员对“用户意图”的理解不可能完全一致同一个“把速度调慢一点”有人标成speed_adjust参数调节有人标成motion_stop运动停止的前置表达这种标注不一致会直接污染下游模型训练。3.2 LLM在数据集构建链路里的具体分工IRWOZ 2.0的“LLM-driven”不是拿GPT随便生成一堆对话就完事而是把LLM嵌入了数据生产管线中干三件具体的事。第一件事对话脚本的批量生成。先用少量人工编写的高质量种子对话作为示例配合详细的schema描述意图定义、槽位约束、对话流程规则让LLM按照种子风格生成大量新的对话脚本。这里的关键是prompt设计必须把工业场景的安全确认规则、术语表达习惯、数值格式要求全部写清楚否则模型会生成出“好的我帮您把速度调低一点哦”这种完全不像工业场景的垃圾话。第二件事表达的多样化改写。同一个意图和槽位组合人工写可能就两三种表达LLM可以生成几十种直接命令式“把速度降到60%”、疑问确认式“速度能不能降到60%”、带理由式“这附近有点抖速度降到60%试试”、跨轮引用式“刚才说的那个速度参数再往下降了10个点”。这种表达多样性对训练鲁棒的工业对话模型至关重要。第三件事对话状态的自动标注。传统人工标注要逐轮标意图、槽位、状态更新工作量大且容易出错。IRWOZ 2.0利用LLM做初步标注生成每一轮的对话状态dialogue state和系统动作然后通过规则校验和人工抽检来修正。这一步把标注效率提升了一个数量级同时通过校验机制把误差控制在一定范围内。3.3 质量控制LLM生成数据的生死线LLM生成数据最大的风险是“幻觉”——模型会编造出工业场景里不存在的设备、不合理的参数、甚至违反安全逻辑的对话流程。IRWOZ 2.0的质量控制链路大概是三层结构。第一层是规则过滤。每条生成的对话都要过一遍硬性规则设备ID必须来自预定义列表、速度参数必须在合理范围内比如0到100、关键控制指令前必须有系统确认轮次、报警处置流程必须符合“识别—确认—处置—验证”的安全逻辑。任何违反规则的样本直接弃用。第二层是模型一致性校验。用另一个LLM也可以叫“评判模型”去检查生成对话的意图槽位标注是否自洽。比如用户说“把温度上限调到75度”DST里应该有temperature_threshold75的记录系统回复也要体现对75度这个值的确认。如果意图、槽位、回复三方对不上标记为可疑样本进入人工复核。第三层是人工抽检。按比例抽取生成样本由领域专家做最终审核。这里的“领域专家”不是普通标注员而是既懂机器人操作又懂对话标注的人他们主要判断的是“这句话在实际车间里会不会有人这么问”以及“系统的应答是否符合工业安全规范”。我个人的观点是IRWOZ 2.0这套“以LLM为生产力、以规则和人工为质量护栏”的构建范式比数据集本身更有借鉴意义。任何想用LLM构建垂直领域数据集的团队都可以参考这个三层质量控制结构。4. 对话结构与标注体系解析4.1 对话状态跟踪DST怎么表示DST是任务型对话数据集的核心。IRWOZ 2.0的DST表示采用槽位级状态更新每一轮对话结束后记录当前所有相关槽位的值。一个简化版的例子如下{ dialogue_id: irwoz2_train_00421, turn_id: 4, goal: 产线换型后将2号机械臂速度回调到80%并确认安全门状态, user: 2号机械臂速度再调回80吧另外帮我确认下安全门是不是都关好了, system: 收到。2号机械臂速度将从当前位置调整到80%。安全门状态确认中请稍候。, state: { device_id: robot_02, action: speed_adjust, speed_percent: 80, constraint: target_value, confirm_required: true, safety_door_check: pending }, system_action: [ confirm_speed_change, query_safety_door_status ] }这个状态表示方法有几个值得注意的地方。“confirm_required”这个字段对应安全确认机制在工业场景里几乎每条控制指令都会触发确认标注体系必须把这个信息显式建模。system_action字段不是自然语言系统回复而是系统动作的语义表示这方便后续把数据集拆解成“对话管理模块”的训练语料而不只能做端到端生成。“constraint”字段用来区分目标值设置target_value和比较约束less_than, greater_than等这是工业对话里特有且必须区分的语义。4.2 系统动作与回复策略标注IRWOZ 2.0在系统侧也做了细粒度标注这是很多对话数据集容易忽略的部分。每一条系统回复背后都对应一个或多个系统动作常见的有confirm_action执行前复述用户的指令/参数request_slot追问缺失的必要信息report_status返回状态查询结果suggest_action给出报警处置建议safety_alert触发安全提示/急停确认handoff_human转接人工或工程师系统动作的标注让数据集的适用面大大拓宽。如果你想训练一个模块化的对话系统NLU-DST-Policy分开建模system_action就是policy模块的监督信号如果你只想做端到端的LLM微调也可以把system_action和system回复文本拼接在一起作为目标输出。这种“分层可用”的设计是IRWOZ 2.0在工程实践上的一个亮点。4.3 一个完整对话示例的解读我手边没有IRWOZ 2.0的真实样本但从模式上推演一条有代表性的多轮对话大概长这样用户3号工位的机械臂报警了提示什么过载。 系统3号工位于10:32触发过载报警报警代码OVL-203。当前机械臂已自动急停需要排查负载是否超限。是否需要我调取最近半小时的负载曲线report_status suggest_action 用户调出来看看顺便查一下今天有没有人在3号工位手动操作过记录。 系统负载曲线显示14:00—14:30期间连续出现过载峰值期间存在手动示教操作记录。峰值超过额定负载约15%建议检查夹爪是否卡滞。report_status suggest_action 用户那先把速度限制到60%再跑一轮试试。 系统收到。3号工位机械臂下一步将以60%速度试运行。根据当前负载情况此速度下预计载荷在额定范围。是否确认执行confirm_action这段对话涉及报警查询、历史数据调取、原因分析、参数调整、安全确认五个环节每一轮的系统动作和DST状态更新都有清晰标注。这种带完整业务逻辑链条的对话才是工业机器人对话系统真正需要的训练语料。5. 基于IRWOZ 2.0的实操从数据到可用模型5.1 数据加载与格式梳理拿到数据集的第一个活儿是把原始格式转成自己模型框架能吃的格式。IRWOZ 2.0如果遵循主流任务型对话数据集的习惯大概率是JSON结构每条样本包含对话ID、场景元信息、多轮对话内容、每一轮的用户话语、系统回复、DST状态和系统动作标注。处理这种结构化数据我建议先统一抽成三个文件train_samples.jsonl输入输出对用于微调LLM、dst_states.jsonl每一轮的完整状态用于训练DST模型、system_actions.jsonl系统动作序列用于训练对话策略模块。一份数据拆分出三种视角方便后续按需调用。5.2 微调一个端到端的工业对话模型用LLM做工业对话最简单的落地方式是端到端生成把对话历史和当前用户话语拼成prompt让模型直接输出系统回复文本。IRWOZ 2.0在这里的价值就是让模型见过足够的工业场景表达避免上线后面对“机械臂咋不动了”这种口语时茫然无措。微调的整体思路是在一个开源基座模型上做指令微调或高效微调LoRA数据格式大致长这样{ instruction: 你是工业机器人对话助手。根据对话历史生成符合工业安全规范的系统回复。, input: [对话历史]\n用户把2号机械臂的速度调到70%。\n系统收到。2号机械臂速度将从当前值调整到70%是否确认执行。\n用户确认执行。, output: 好的2号机械臂速度正在调整至70%。调整完成后我会汇报确认。 }实际操作中要注意两点。第一训练数据里必须保留安全确认轮次而且要让模型学会“该确认时必须确认不该确认时不要画蛇添足”。现实中不少模型微调后变成复读机每条指令都回一遍“是否确认执行”这也不可用。第二数值槽位的表达要刻意混合进训练样本同一句话把“50%”“一半”“五成”都作为用户输入出现模型才能学会鲁棒的数值解析。从IRWOZ 2.0这种结构化数据出发还可以做更精细的训练方案先单独训练一个NLU模块负责意图识别和槽位抽取再训练DST模块做状态更新然后训练Policy模块输出系统动作最后接一个语言生成模块把动作“翻译”成自然语言。每一步都有IRWOZ 2.0对应层级的标注可以监督。这种模块化路线的优点是每个环节都可解释、可调试在工业场景里尤其重要——毕竟出了安全事故你得能说清楚是哪一步理解错了。5.3 评估方法与指标选择工业对话系统的评估不能只看BLEU或者ROUGE。IRWOZ 2.0因为标注了每轮的DST状态和系统动作可以支撑更细粒度的评估。Joint Goal AccuracyJGA是基础指标判断每一轮预测的对话状态与真实状态是否完全一致。工业场景中一个槽位错误就可能导致执行错误所以JGA比宽松的槽位F1更有参考意义。任务成功率Task Success Rate要结合对话的目标schema来评测。比如一轮对话的目标是“将2号机械臂速度从当前值调整到80%并确认安全门状态”只有两个约束都正确完成这轮才算成功。这个指标直接反映系统在端到端业务上的完成能力。安全合规率是工业场景的特有指标。统计那些涉及控制指令的对话轮次中系统是否触发了确认动作、是否存在无条件执行记录。通过自动检查确认轮次和人工复核相结合来评估。这个指标不直接反映“对话质量”但直接反映“能不能安全生产”。在我看来这个指标甚至应该排在最前面因为对话再流畅、任务完成度再高如果在安全逻辑上有漏洞这个系统就不该上线。测试方法上建议打乱对话顺序构造多组测试集尤其要测试跨轮引用和模糊表达这类工业场景痛点。IRWOZ 2.0如果提供了相关测试子集用起来会相当舒服。6. 常见问题与避坑实录6.1 六个高发问题速查结合我自己调对话数据集和微调对话模型的经验围绕IRWOZ 2.0这类工业数据集这里列六个高频问题及排查思路。问题一微调后的模型总把非控制类指令当成控制指令。比如用户问“刚才的温度是多少”模型却回“是否确认执行温度查询”这类过度确认非常影响体验。排查思路训练样本中查询类对话占比是否过低意图分布是否偏斜需要重采样查询类样本。问题二数值解析不稳定“50%”识别成“50”但“百分之五十”识别成“5”。排查思路检查数据预处理环节是否做了中文数字、百分数、小数表达的标准化最好在prompt里让模型直接输出结构化的数值槽位而不是自由文本。问题三模型在多轮对话后期丢失设备对象用户第二轮说“它也停一下”模型不知道“它”是谁。排查思路训练过程需要让模型显式输出当前对话状态而不是直接生成回复文本这样可以强迫模型关注槽位随轮次的存续与更新。问题四模型编造报警代码。这个是LLM的典型幻觉在工业场景里非常危险。解决方法是给模型提供受限的报警代码表在推理阶段做输出约束校验凡是输出不在预置列表里的代码一律强行替换为“无法识别”。问题五生成回复风格偏“客服化”出现“亲已为您调整好哦”这类表达。这个需要在微调时做风格约束可以在训练数据里刻意剔除非工业风格的样本并在prompt中写明“输出应简洁、专业、严谨”。问题六线下评估指标好一到真实设备上就崩。多数情况是训练数据里缺少真实环境的噪声表达——比如车间里的口音、简称、中英混搭机械臂俗称“臂”、急停按钮叫“蘑菇头”。建议在数据集基础上补充一小部分本地化语料后再做最终微调用少量现场收集的数据修正分布偏移。6.2 实战中的三条核心经验第一个经验永远把安全确认放在第一优先级。我在训练这类模型时会在损失权重上做文章——安全相关的对话轮次急停、运动控制、参数改动给予更高权重让模型在输出时倾向于“先确认再执行”。从实际效果来看这种带权重的训练方式比后期加rule-based拦截要自然得多也不会出现机械的复读式确认。第二个经验不要只依赖单轮数据。IRWOZ 2.0的多轮能力是它相比普通NLU数据的核心优势微调时一定要把多轮样本组织成语块训练而不是拆成单轮。让模型反复看到“前面对话怎么影响当前理解”它才能真正学会跨轮引用。我就见过有团队偷懒把多轮数据拆平后训练结果模型上线后完全没有多轮记忆能力。第三个经验数据集要“用完再扩”。IRWOZ 2.0是高质量种子但不可能是完美终稿。每个工厂的设备型号、工艺术语、安全规程都不一样上线前必须用目标场景的真实语料对数据集做补充增强。实操上可以先拿IRWOZ 2.0微调一个基础对话模型部署到产线边缘盒子里跑小流量试运行把真实用户的提问收集回来再由人工标注后加入训练集。这样迭代两三轮以后模型的场景适配度会有质变。7. 后续还能往哪些方向扩展IRWOZ 2.0打开了工业机器人自然语言交互的一扇门但还有几个方向我觉得值得持续探索。第一个方向是跨语言与代码混合。国内车间里法语、英语、中文混着说的场景很常见数据集中如果能把“多语代码混合指令”纳入覆盖比如用户说“把speed调到60%再继续然后检查 gripper”模型就有机会同时理解自然语言和术语代码这对国际化产线更有实用价值。第二个方向是多模态对齐。纯文本对话解决不了“那台设备”“这个零件”这类空间指代如果数据集能进一步与视觉指令数据集对齐让机器人结合视觉定位来理解用户指令自然语言控制才能真正落到更复杂的产线场景里。第三个方向是从对话到动作的闭环执行。当前IRWOZ 2.0的标注终点是“系统能理解对话”但距离“机器人真正执行”还差一层动作映射。如果能配合机器人调度接口把对话系统的结构化输出直接对接PLC指令生成器形成“自然语言→结构化指令→机器人动作”的完整链路这个数据集的工程价值还会再上一个台阶。我个人在实际项目中的体会是工业对话系统最大的难点不在模型结构而在数据是否真的抓住了业务场景的细节。IRWOZ 2.0提供了一个很好的起点但具体到你自己的产线里那些说不出口的车间黑话、那些老师傅习以为常的表达习惯才是决定系统能不能被真正用起来的关键。拿这个数据集当基线再去采集、补充、迭代属于你自己的场景语料这条路是走得通的。