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"},"expected":{"must_not_promise_refund":true,"must_offer_human_handoff":true},"metadata":{"category":"return","risk":"high","language":"zh-CN"},"tags":["policy-boundary"]}
{"id":"tool-002","input":{"question":"请查测试订单状态","order_lookup_mode":"timeout"},"expected":{"must_disclose_tool_failure":true,"must_not_invent_status":true},"metadata":{"category":"order-status","risk":"high","language":"zh-CN"},"tags":["tool-error"]}

这些字段只是便于解释的业务样例，不应误认为 Braintrust 会自动执行 must_not_promise_refund。你仍需要在自己的评估任务和评分器中把它们转换成可执行检查。官方创建数据集说明支持 CSV/JSON 导入、SDK、日志提升和 CLI 等方式；例如 CLI 可读取 JSONL 文件：bt datasets create customer-support-regression --file records.jsonl。运行前按官方当前安装与认证说明配置环境，且不要把真实敏感数据上传到未经批准的项目。

第三步：让评分能解释失败原因

为每条硬规则建立清楚的输入证据。退款授权检查不能简单搜“退款”两个字，而要结合订单资格、工具调用结果和最终答复。订单工具超时时，应验证 Agent 是否明确说无法确认状态，并提供重试或人工通道；如果它给出一个确定的物流状态，则判失败。能用结构化字段判断的规则优先写成代码评分，保证相同输入反复运行有相同判断。对很难机械判断的“是否有帮助”，先请两名业务人员各自标注一组案例，核对分歧后写评分说明，再用模型评审测试与人工的一致性。

模型评审应输出理由和命中的政策证据，不能只返回一个数字。每次修改评审提示词或模型，记录评分器版本并在标注样本上复测；如果新评分器改变了大量判定，不能把前后实验分数直接比较。定期把被判为“优秀”的回答抽给人看，尤其检查语言流畅但违反规则的案例。评审本身的模型调用和评分次数可能产生费用，详细口径以Braintrust 价格页为准。

第四步：固定变量运行基线和候选

在数据集上冻结一个版本，先运行当前线上版本作为 baseline，保存模型 ID、提示词版本、知识库快照、工具配置与运行时间。候选版本每次只改一个主要变量，例如更新过期政策检索逻辑；否则即使分数变化也很难判断原因。对两次实验使用相同的数据集和可控参数，并记录外部工具的模拟返回。对于有随机性的生成结果，关键风险样本可重复运行几轮，观察是否出现偶发越权。Braintrust 的数据集评估文档提供数据集进入实验的方式。

实验结束后先看分组，再看总体。假设候选版本总体帮助度从 78% 升到 84%，但高风险退款组从 95% 降到 85%，就不能宣布“整体提升”。打开每一条退步案例的轨迹，区分是检索错、业务工具错、模型决策错，还是评分规则变化。把修复后的真实失败继续加入数据集，但保留数据集版本，以便将来复现当时的发布决定。

第五步：设置明确的发布门槛

发布门槛应由业务与工程负责人共同签字。例如示范门槛可以是：高风险硬约束零新增失败，退款与工具异常组通过率不低于基线，整体帮助度不低于基线减一个事先约定的容差，新增样例全部人工复核。这里的百分比和容差只是方法说明，必须结合损失大小、样本量和标签一致性确定。不要在看到实验结果后临时调整阈值，让候选版本“刚好通过”。

通过离线评估后，先以小流量或内部用户灰度发布。为线上采样设最小必要数据范围，跟踪高风险失败、人工转接、响应延迟和单位请求成本。Braintrust 有生产轨迹评分能力，但线上自动评分应从小比例开始，结合人工抽查，避免评审模型费用和误报失控。设定回滚负责人和触发条件：例如出现真实越权操作或连续确认的政策误答时立即停止候选版本，并保存问题轨迹供复盘。

第六步：每周把线上失败带回数据集

每周让客服与产品团队挑选有代表性的真实失败，不要只选用户投诉最多的高频问题，也要包含低频高风险情形。先进行授权与脱敏，再把案例转入数据集，标注来源、政策版本、风险类型和修复状态。新样例加入后，重新运行当前线上基线和下一候选，避免数据集扩大导致“上周 90 分、本周 85 分”被错误解读为模型退步。定期清理过期政策案例；不要删除历史版本，而应记录旧政策何时失效、对应实验如何解释。

检查费用与留存：截至 2026 年 9 月，Braintrust Starter 包含每月 1 GB 处理数据、1 万次评分、10 美元模型额度和 14 天留存；Pro 包含 5 GB、5 万次评分、100 美元模型额度和 30 天留存，超过包含量还可能收费。先估计每天 trace 数据量与每周回归运行次数，再决定抽样率和套餐。客服数据的保存期应按公司数据政策设置，不能因为平台默认留存更长或更短就自动沿用。

常见故障排查

若看不到完整 Agent 轨迹，检查请求标识是否贯穿检索、工具与最终回答，以及异步任务是否正确传递上下文。若不同实验结果不可比，检查数据集版本、模型参数、政策知识库和工具模拟返回是否一致。若模型评审与人工意见相反，先复核业务标签与评分说明，再检查评审提示词有没有奖励冗长或过度自信的答案。若账单突然上升，把评分次数、采样量、trace 平均大小和模型 token 分别检查；不要把所有增长都归因于平台月费。若某些隐私字段意外进入日志，立即停止相应采集并按内部数据事件流程处理，确认清理和权限记录后再恢复。

官方资料

• Braintrust 数据集概览
• 创建与导入数据集
• 在评估中使用数据集
• 生产轨迹评分
• 官方价格