简短回答： AI代理需要数据来代表随着时间的推移而采取行动,而不是对一对迅速和反应。 培训和评价单位是一个轨迹——任务说明、可用工具、采取的每一项行动、环境反应和最后结果——说明发生第一次失败的地点。 旁边是检查状态的核查员 在代理运行前写好的
核心要点
- 轨迹,不是单一的即时反应对,是动力训练和评价数据的基本单位.
- 验证员是确定任务结束状态的检查,在代理运行前写成,将一个看起来似是而非的答案变成可重复的成功信号.
- 步级失败归属——规划,工具选择,参数,状态跟踪,或核查——是导致失败运行有用而不是被丢弃的.
- 任务成功率和有效路径成功率是两个不同的数字;它们之间的一个差距意味着代理通过未经批准的路线达到目标.
- 多语言或市场特定代理人需要审查人员在市场上工作,因为可接受的行动和预期措辞因地方而异。
代理数据与普通LLM数据有何不同?.
常规语言模型的例子包含一个迅速和想要的反应;一个代理人决定、行动、观察结果、更新计划,并一直持续到目标达到或放弃。 差异会改变数据必须记录的内容、由谁来审查以及成功如何定义。
| 普通LLM数据 | 代理数据 | |
|---|---|---|
| 单位 | 一次迅速和一次答复 | 跨越许多步骤的轨迹 |
| 判断什么? | 输出文本 | 产出 和 道路走进它 |
| 事实 | 参考答案或答案之间的偏好 | 已核实的结束状态,加上可接受的路径限制 |
| 失败的归属 | 答案是错的 | 规划、工具选择、论据、状态跟踪、恢复或核查——每个类别都不同 |
| 环境 | 无 | 工具、 API、 文件、 数据库或模拟器, 每个都具有自己的状态 |
| 注释员技能 | 语言和领域判决 | 同样的,加上读取处决追踪的能力 |
| 成本驱动器 | 长度和主题难度 | 轨迹长度和需要审查的决定点数目 |
驱动其它数据的行是失败归属。 单标签上写着任务尚未完成, 无法显示您可以执行什么。 团队对代理数据处理的方式与对任务进行处理的方式相同 。 代理和基因AI系统 通常在评估过程中而不是在收集过程中被构建和评估。选择合理计划并称为有错误参数的工具的代理商需要与发明不存在的工具不同的固定,两者都不同于完成每个步骤而从未检查自己的工作。
轨迹到底包含什么?
每一步都保留生效指令,当时可用的工具,所选择的动作,其论据,环境反应,结果状态,以及系统暴露的任何推理.
轨迹是特工运行的完整逐步记录 ——记录方式是,它读作可审计的序列而不是记录。
| 步骤 | 采取的行动 | 环境反应 | 注释 |
|---|---|---|---|
| 1 | search_orders(customer_id) |
三个命令还了 | 计划有效; 工具合适 |
| 2 | get_order(id=…) 顺序 |
找到顺序; 状态“ 已发运 ” | 正确的工具, 错误的记录—— 退款请求命名为更早的命令 |
| 3 | issue_refund(order_id=…, amount=…) |
已创建的退款 | 第一次失败 以未经核实的记录行事;没有确认步骤 |
| 4 | 向用户报告成功情况 | — | 报告结果为完整;在结束状态时核查失败 |
有两个东西从那个表格中掉出来。最后的输出看起来是正确的——代理公司确实发行了退款并流利地报告了它——在2步输入错误,然后才明显出错。只有阶梯级的注释才找到它。 这也是为什么第一个结果的失败被明确标记:它被污染后的一切,然后将这些后来的步骤分级为独立的错误,夸大了失败的计数并隐藏了原因.
轨迹说明是什么?
轨迹注释在每一步都检视一个序列并标记属性:计划是否有效,工具调用是否恰当,代理商是否从它造成的错误中恢复,以及发生第一个相应的故障的地方.
它对培训和诊断都很重要,因为它记录了结果是如何取得的,而不是仅仅记录了最终产出是否正确。 只有在故障课事先确定的情况下,标签才具有可比性:
| 失败类 | 痕迹里是什么样子 |
|---|---|
| 规划 | 一致的目标被分解成无法实现的步骤 |
| 工具幻觉 | 调用不存在的工具或参数 |
| 工具选择 | 用于错误目的的真正工具 |
| 参数错误 | 调用正确工具的数值有误或错 |
| 国家跟踪 | 以陈旧或记忆不灵的环境状态行事 |
| 循环 | 同一行动在没有新资料的情况下重复 |
| 过早完成 | 报告任务完成,标准未达到 |
| 不安全或未经授权的行动 | 超出允许范围的一个步骤,无论是否成功 |
固定分类学随着时间推移变得有用,因为它让团队追踪哪些类在模型版本之间缩小,哪些类是持久性的——后面的学科是相同的. 推理追踪数据,教一个模型来显示其工作。一个从未缩小的类通常是数据问题或环境问题,而不是模型问题。
为什么代理人需要核查员和客观的成功标准?
代理人通常在可以检查最终状态的地方运作——文件应该存在,数据库记录应该已经改变,测试应该通过,保留应该满足已声明的限制——核查者将这些要求转换成可重复的评价或奖励信号.
验证员是确定状态的检查,在代理运行前写成,因为之后写出的标准往往描述代理人做了什么而不是它应该做什么.
Task success rate = Trajectories meeting every stated success criterion ÷ Trajectories attempted
与第二个数字一起报告,因为一个代理可以通过一个不可接受的途径到达正确的端态:
Valid-path success rate = Successful trajectories with no unsafe or unauthorised step ÷ Trajectories attempted
两者之间的差距是部署的关键。 一个任务成功率高、有效率低得多的代理人已经学会了以你没有认可的方式实现目标,平均两者都掩盖了这一点。 如果评价员只是判断另一种语言模式的语言模型,隐藏错误就会通过——在“E.C.C.”中检查的循环性。 如何可靠一个 LLM 做法官时将确定性检查与对主观或高风险部分的人力审查结合起来;将检查内容以及如何涵盖范围更广的设计问题结合起来。 设计企业评价基准.
如何将代理失败转化为培训数据?
保持失败的轨迹,而不是抛弃它们,因为它们携带的是节目制作的最丰富的资料。
- 标出原因 与固定分类法相对, 也就是失败进入的一步。
- 问如何是失法之证. 指令不明确、缺少工具文档、环境不匹配和真正的规划缺陷,都是失败运行,需要不同的应对。
- 写一个更正的演示文稿 ——这是值得信赖的一步步完成这项工作的例子,包括正确的行动和最终状态。
- 建立目标任务,将薄弱环节隔离开来而不是一般地更多的任务。
- 复试持戒变种. 用于计量的固定装置,而不是能力。
修正的演示和轨迹之间的偏好数据也是人类喂养背部训练方法所消耗的——欧阳等人在"训练语言模型以听从人类反馈的指示"(arXiv 2203.02155)中描述的方法,应用于动作的序列而不是单答. 决定其中哪些购买方法包含在 RLHF, SFT 和蒸馏:购买什么.
何时需要专家审查?
每当代理的行动触及专门系统或影响大的决定时,软件代理需要能够读取其所写的代码的审核员,财务工作流程需要域和遵守专业知识,内部业务代理需要一个非常了解组织政策的人,看一个步骤何时超过它们.
审核员的工作既包括任务完成,也包括流程质量. 通过不安全或未经授权路径达成正确结果的代理商不应被记录为成功——没有相关专业知识的审核员会将其记录为一体,因为结尾状态看起来是正确的.
你该问什么代理数据供应商?
询问每个轨道实际交付什么,故障是如何分类的,谁有资格写和检查验证员——答案将浅审查过程与产生可用诊断数据的审查过程分开.
- 每个轨道究竟交付了什么——完整的阶梯级记录,还是结果标签?
- 使用哪一种故障分类法,它能否延伸到我们的环境?
- 如何确定第一个失败,以及由谁确定?
- 验者在逃前有写,谁写?
- 审查人员之间如何衡量同一轨迹上的一致?
- 审查者对我们领域有何资格,如何核实?
- 失败的轨道是否被保留和交付,或过滤出去?
怎么样 Lifewood 辅助代理 AI 数据程序?
Lifewood 支持代理方案的数据操作——任务创建、步态轨迹审查、故障标签和人的评价——使用它一般适用于注释的相同结构。
结构是工作开始前商定的固定分类法,审查人员有资格获得所判断的领域,以及进行双层人-在行动审查。 95%+ 准确率 SLA如果代理商在一个以上的市场开展业务,则必须进行语言审查,这就是 50+语言 和 40+ 跨省服务中心 30+ 国家 支持。相关服务页覆盖 企业 LLM 培训数据 和 AI 数据验证.