本页目录9
AI 摘要 · 已核查整理于 2026-06-06原文:Define Success Criteria and Build Evaluations(Anthropic)Claude评估测试Prompt工程LLM评测
要点速览
- 成功标准需满足具体(Specific)、可衡量(Measurable)、可实现(Achievable)、相关(Relevant)四要素,合称类似 SMART 原则的检验框架
- 常见成功标准维度包括:任务保真度、一致性、相关性与连贯性、语气与风格、隐私保护、上下文利用、延迟、价格,多数场景需要多维度评估
- 评估设计三原则:任务针对性(覆盖边缘情况)、尽量自动化打分(多选题/字符串匹配/代码打分/LLM 打分)、优先保证数量而非单条质量
- 官方给出 6 个具体评估示例,分别对应不同任务类型与打分方法(精确匹配、余弦相似度、ROUGE-L、LLM 李克特量表、LLM 二分类、LLM 顺序量表)
- 所有示例代码遵循统一实现模式:定义测试用例 → 调用 `client.messages.create()` 获取补全 → 用任务专属指标评估输出 → 汇总计算整体分数,支持 Python/TypeScript/C#/Go/Java/PHP/Ruby 等语言
本文是对官方参考页「Define Success Criteria and Build Evaluations」的中文整理,完整与最新内容以原文为准:https://platform.claude.com/docs/en/test-and-evaluate/develop-tests
概述
构建成功的 LLM 应用需要清晰定义成功标准,并设计评估(evaluation)来衡量表现。整体遵循的循环是:测试用例 → 初步 Prompt → 迭代测试与优化 → 最终验证 → 上线。
成功标准的四要素
| 要素 | 说明 | 示例(差) | 示例(好) |
|---|---|---|---|
| 具体(Specific) | 清晰定义要达成的目标,而非泛泛而谈 | 「表现良好」 | 「准确的情感分类」 |
| 可衡量(Measurable) | 使用量化指标或定义清晰的定性量表 | 「输出安全」 | 「10,000 次试验中,被内容过滤器标记为有毒的输出低于 0.1%」 |
| 可实现(Achievable) | 目标基于行业基准、既往实验、AI 研究或专家知识设定,应与前沿模型能力相匹配 | — | — |
| 相关(Relevant) | 标准要与应用目的和用户需求对齐 | — | 医疗类应用中引用准确性可能是关键,休闲聊天机器人则不然 |
可衡量标准的常见方法
| 类别 | 举例 |
|---|---|
| 量化指标 · 任务相关 | F1 score、BLEU score、perplexity |
| 量化指标 · 通用 | Accuracy、precision、recall |
| 量化指标 · 运营 | 响应时间(ms)、可用率(%) |
| 量化方法 | A/B 测试(对比基线模型或旧版本)、用户反馈(如任务完成率)、边缘情况分析(无错误处理的边缘案例占比) |
| 定性量表 | 李克特量表(如「从 1 不连贯到 5 完全逻辑清晰对连贯性打分」)、专家评分标准(如语言学家按既定标准评估翻译质量) |
常见成功标准维度
| 维度 | 说明 |
|---|---|
| 任务保真度(Task fidelity) | 模型在任务上的表现如何,包括边缘情况处理 |
| 一致性(Consistency) | 相似输入应得到多相似的响应 |
| 相关性与连贯性(Relevance and coherence) | 模型是否切题作答并逻辑清晰地呈现信息 |
| 语气与风格(Tone and style) | 输出风格是否符合预期、适合目标受众 |
| 隐私保护(Privacy preservation) | 模型应如何处理个人或敏感信息 |
| 上下文利用(Context utilization) | 模型对提供的上下文的利用效果 |
| 延迟(Latency) | 可接受的响应时间 |
| 价格(Price) | 运行模型的预算 |
多数应用场景需要多维度评估(multidimensional evaluation),即同时考察上述多个标准。
评估设计三原则
| 原则 | 说明 |
|---|---|
| 任务针对性(Be task-specific) | 评估应还原真实任务的输入分布,包括边缘情况:不相关或不存在的输入数据、过长的输入数据、质量差/有害/不相关的用户输入、模糊的测试用例 |
| 尽量自动化(Automate when possible) | 将问题结构化为可自动打分的形式:多选题、字符串匹配、代码打分、LLM 打分 |
| 数量优先于质量(Prioritize volume over quality) | 大量信号略弱的自动化评估题目,优于少量人工评分的评估题目 |
示例评估一览
| 编号 | 维度 | 场景示例 | 评估方法 | 测试集规模 |
|---|---|---|---|---|
| 1 | 任务保真度 | 情感分析 | 精确匹配(Exact Match):规范化空白/大小写后与预定义正确答案比对,适合分类类任务 | 1,000 条带人工标注情感的推文 |
| 2 | 一致性 | FAQ 机器人 | 余弦相似度(Cosine Similarity):基于 Sentence-BERT(SBERT)的句向量相似度,越接近 1 相似度越高 | 50 组含改写变体的问题 |
| 3 | 相关性与连贯性 | 摘要生成 | ROUGE-L:计算候选摘要与参考摘要的最长公共子序列(LCS),分数高说明关键信息以连贯顺序被捕获 | 200 篇带参考摘要的文章 |
| 4 | 语气与风格 | 客服 | LLM 李克特量表:由 LLM 对共情、专业度、耐心等主观态度按 1-5 分打分 | 100 条带目标语气标注的客户咨询 |
| 5 | 隐私保护 | 医疗聊天机器人 | LLM 二分类:判断响应是否包含 PHI(个人健康信息),需具备对显式、假设性、隐含 PHI 的上下文感知检测能力 | 500 条模拟患者咨询 |
| 6 | 上下文利用 | 对话助手 | LLM 顺序量表:按 1-5 分评估响应对对话历史的利用程度 | 100 段含依赖上下文问题的多轮对话 |
各量表打分说明
| 评估 | 分数 1 含义 | 分数 5 含义 |
|---|---|---|
| 语气与风格(Tone) | 完全不符合目标语气(Not at all [target_tone]) | 完美符合目标语气(Perfectly [target_tone]) |
| 上下文利用(Context Utilization) | 完全忽略上下文 | 完美利用上下文 |
PHI(个人健康信息)构成示例
| 类别 | 内容举例 |
|---|---|
| 标识符 | 姓名、地址、出生日期、社保号(SSN)、病历号 |
| 健康数据 | 诊断结果、治疗方案、检验结果、用药信息 |
| 财务信息 | 保险详情、支付记录 |
| 沟通记录 | 医护人员记录、健康相关邮件 |
代码实现统一模式
官方所有评估示例均遵循以下四步模式:
| 步骤 | 内容 |
|---|---|
| 1. 定义测试用例 | 包含输入(input)与预期输出/评判标准(expected output / criteria) |
| 2. 获取模型补全 | 调用 client.messages.create() 从模型获取输出 |
| 3. 评估输出 | 使用任务专属指标(如精确匹配、ROUGE-L、LLM 打分等)评估每条输出 |
| 4. 汇总计算 | 在全部测试用例上计算整体聚合分数 |
代码示例支持的语言:Python、TypeScript、C#、Go、Java、PHP、Ruby。