评估与可观测性

先定义任务成功标准,再用离线评估、人工抽检和线上指标组合判断。Agent 不只看回答对不对,还要看工具调用是否正确、步骤是否可控、成本延迟是否可接受、失败时是否能安全退出。

• +指标要覆盖任务成功率、事实正确性、工具成功率、人工接管率、成本和延迟
• +开放式答案适合人工评审或 LLM-as-a-Judge,结构化任务适合规则和单元测试
• +评估集要包含常见问题、边界问题、恶意输入和真实线上样本

LLM-as-a-Judge 方便扩展,但会有偏见、标准漂移、被长答案迷惑和对事实不敏感的问题。它适合做辅助评分和趋势观察,关键结论仍要用人工、规则或真实结果校准。

• +Judge prompt 要固定标准,并用少量人工标注样本校准一致性
• +同一个模型既当选手又当裁判会有偏好,必要时换模型或多裁判投票
• +事实类评估最好提供参考答案和证据,不要让裁判凭记忆判断

先看完整 trace:用户输入、系统提示、模型输出、工具调用、工具结果、重试和最终回答。然后判断问题发生在检索、规划、工具、权限、模型输出还是前端展示层,再用相同上下文复现。

• +没有 trace 的 Agent 很难排障,因为错误可能出在多轮中任一步
• +日志要能关联 request id、user id、session id 和 tool call id
• +复现时要固定模型版本、prompt、检索结果和工具返回,否则难以比较

Golden Dataset 是一组代表真实业务的高质量测试样本,包含输入、期望行为、参考答案或评分标准。建设时要从真实问题出发,覆盖高频、边界、失败和安全场景,并持续更新。

• +样本不必一开始很多,但必须有代表性和明确判分标准
• +数据集要版本化,否则模型和 prompt 迭代后无法公平比较
• +不要只收成功样例,线上失败案例反而最有评估价值

Trace 记录一次完整请求的链路,Span 记录链路中的一个步骤,比如模型调用、检索、工具执行、重排或人工确认。它们帮助你知道每一步花了多久、输入输出是什么、哪里失败了。

• +模型调用要记录模型名、token、延迟、成本和关键参数
• +工具 span 要记录参数摘要、结果状态和错误类型,敏感字段要脱敏
• +好的 trace 能把一次用户投诉还原成可调试的时间线

A/B 测试要把用户或会话稳定分流到不同策略,比较任务成功率、满意度、成本、延迟和安全指标。Agent 场景不能只看点击率,还要看答案质量和失败后果。

• +实验变量要单一,否则不知道是模型、prompt、检索还是 UI 影响结果
• +高风险改动先灰度小流量,并设置自动回滚或人工监控
• +对长任务要按会话维度分流,避免同一任务中途切换策略