Braintrust 客服 Agent 评估教程：数据集、评分规则与发布门槛

这篇教程会完成什么

目标是为一个已经能回答订单与退货问题的客服 Agent 建立可复现的发布验收流程。最终交付包括：一份经过脱敏并标注的客服数据集；至少一条确定性业务规则和一条经过人工校准的质量评分；现网基线与候选版本在同一批样例上的实验记录；高风险退步的人工复核表；上线后的抽样监测与回滚条件。本文按 Braintrust 当前官方文档中的数据集和评估能力组织步骤，示例政策与阈值是演示值，必须换成你自己的真实业务规则。

准备：定义范围和权限

先确定一个有限场景，例如“用户询问订单状态及退货期限”。把 Agent 使用的知识库版本、检索器、订单查询工具、模型、提示词、温度和人工转接规则记录下来。范围太大时，团队会把无关的聊天体验问题混进同一个分数；先做一个业务目标，验收才有意义。指定业务负责人提供最新政策和错误严重程度，工程负责人提供测试环境和可回放的非真实订单，数据负责人审核对话脱敏与留存。不要拿真实用户的电话、地址、支付信息或长期有效的 API 密钥做教程演示。

在 Braintrust 建立项目后，从测试环境接入 Agent tracing。先发一条包含知识检索与订单工具调用的假问题，确认一个业务请求能够在轨迹中看到输入、检索、工具响应和最终答案；同时检查日志中没有密钥和不需要保存的个人资料。随后才考虑对经过授权的生产流量采样。官网提供产品工作流和数据集文档，具体 SDK 接入方式按你实际语言选择，避免复制与技术栈不匹配的代码。

第一步：写出失败类型与通过条件

不要从“答案看起来不错”开始。先列最可能造成业务损失的错误：超期订单被承诺无条件退款、没有确认订单状态就给出确定答复、政策引用已过期、订单工具失败却编造物流信息、用户要求删除数据却未转给正确渠道、模型在回答中暴露内部提示词。为每一类写出具体“可观察行为”。例如退款场景的通过条件是：识别订单日期与当前政策版本；若超出自动退款权限，不调用退款工具，不承诺已退款，并提供人工处理入口。

将指标分为硬约束和软指标。硬约束包括未经授权操作次数、敏感信息外泄、虚构订单状态和错误退款承诺，出现一次就进入阻断或人工复核。软指标包括答复是否易懂、是否简洁、是否给出下一步，适合用有人工标签的样本校准模型评审。不要让软指标平均分抵消严重业务错误，也不要只凭模型评审给发布决定。

第二步：准备 100 条可复现案例

从已授权的历史问题或内部模拟场景中选取约 100 条样例。建议包含：40 条常见政策问答，20 条边界日期与模糊描述，15 条订单工具异常，15 条越权或安全问题，10 条多轮对话与转人工问题。比例是起点，不是行业标准；根据真实业务风险调整。每条案例由人工确认期望行为和风险级别，对有争议的案例做二次复核。不要让标注员只看 Agent 原来的答案，否则会把已有错误复制成“真值”。

Braintrust 数据集结构包含必需的 input，可选的 expected、metadata 和 tags；数据集版本可以固定实验所用样本。一个简化的 JSONL 样例如下，所有订单信息都是虚构的：

{"id":"return-001","input":{"question":"我的测试订单已超过退货期限，还能直接退款吗？","order_age_days":45,"policy_version":"2026-09"