评估

是什么

• 通过一套明确的标准和测试方法，判断 AI 的表现是否符合预期
• 跟传统的软件测试的区别
  • 传统软件测试在面对开放式输出、概率性行为和难以直接判定正确性的问题时，需要增加一些技术。
    • 1. 从「测试断言」扩展到「质量评分」
    • 2. 从「检查被测系统」扩展到「校验评分器」
    • 3. 从「一次测试结果」扩展到「统计意义上的表现」
  • AI 评估相对于传统软件测试，最核心的扩展就是引入更灵活的「评分器（Evaluator）」来判断输出质量。
    • 评分器类型 / 实现方式 / 示例 / 规则评分器 / 传统断言、程序化检查 / JSON Schema 验证 / 功能评分器 / 执行测试并检查结果 / 代码单元测试 / 相似度评分器 / 与参考答案比较 / ROUGE、语义相似度 / AI 评分器 / LLM-as-a-Judge / 评价回答的准确性、可读性 / 人工评分 / 人工按规则评价 / 专家评价专业内容
• 思想
  • 评估驱动开发

AI 评估有什么特殊困难

• 质量不一定能直接量化
• 开放式问题
  • 不一定存在唯一标准答案
• 越智能，越难评估
• 模型现在是黑盒，缺少公开细节
• 基准测试跟不上模型的进步

怎么评估

• 1. 了解评估标准
  • 有哪些评估维度
    • 1. 领域特定能力：能不能做？
      • 是什么
        • 模型能否完成特定领域的任务
      • 评估内容
        • 编程能力
        • 数学能力
        • 科学知识
        • 推理能力
        • 专业领域知识
    • 2. 生成能力：做出来的东西好不好？
      • 是什么
        • 模型生成的内容是否符合质量要求
      • 评估内容
        • 基础质量
          • 流畅性：表达是否自然
          • 连贯性：结构与逻辑是否合理
          • 忠实性：是否忠于原始内容
          • 相关性：是否覆盖重要信息
        • 事实一致性
          • 是什么
            • 生成内容是否有事实依据
          • 局部事实一致性
            • 是否符合给定上下文
            • 适用于 RAG、文本摘要
          • 全局事实一致性
            • 是否符合外部可信事实
            • 适用于通用问答、事实核查
        • 安全性
          • 有害内容或建议
          • 歧视和仇恨言论
          • 暴力内容
    • 3. 指令遵循能力：有没有按要求做？
      • 是什么
        • 模型能否按照指定要求完成任务
      • 评估内容
        • 格式约束
          • JSON、YAML 等结构化输出
        • 长度约束
          • 字数、段落数量等限制
        • 关键词约束
          • 必须包含或禁止包含指定词语
        • 内容约束
          • 只讨论指定主题或范围
        • 语言和风格约束
          • 指定语言、语气、表达风格
        • 角色扮演
          • 保持角色的风格和知识一致性
    • 4. 成本和延迟：做这件事划不划算？
      • 是什么
        • 模型运行速度和成本是否符合实际要求
      • 评估内容
        • 延迟
          • 首 Token 延迟（TTFT）
          • 每 Token 生成时间（TPOT）
          • 总响应时间
        • 成本
          • 输入、输出 Token 费用
          • 自托管计算资源成本
          • 工程与维护成本
• 2 了解评估方法
  • 具体有哪些评估方法
    • 语言模型指标
      • 难不难-模型预测下一个 Token 有多准？
        • Subtopic 2
          • 熵
            • 是什么
              • 一个token平均携带的信息量。
            • 单位
              • bit
            • 作用
              • 熵越大，token携带信息量越大，那么比特数越大
              • 熵越大，下一个token越难预测
              • 衡量数据本身的不可预测性
          • 交叉熵
            • 是什么
              • 衡量LM预测该数据集下一个token的难度
            • 单位
              • bit
            • 作用
              • 衡量某个模型预测这些数据的表现
          • BPC和BPB
            • BPC
              • 是什么
                • 模型预测每个字符的平均比特代价
                  • 如果每个token占用6bit，每个token能承载2个字符，那么每个字符占用6/2=3
              • 单位
                • bits/character
            • BPB
              • 是什么
                • 每字节对应的平均预测比特代价
                  • 如果每个字符占用8bit，那么3/（7/8）
              • 单位
                • bits/byte
            • 为什么需要
              • 不同语言模型的 Token 切分方式不一样。 / 例如： / 模型A把 hello 当成一个 Token。 / 模型B把它拆成五个字符 Token。 / 如果直接比较每 Token 的交叉熵，就很不公平。 / 所以需要将预测代价换算到相同单位。
          • 困惑度
            • 是什么
              • 熵或交叉熵的指数形式
              • 本质上和熵和交叉熵一个意思
            • 作用
              • 衡量预测下一个token时的不确定程度
            • 规律
              • 结构化程度越高，困惑度通常越低
              • 词表越大，困惑度越高
              • 上下文长度越长，困惑读越低
        • 是什么：
          • 通过模型给真实 Token 分配的概率，衡量其预测表现。
    • 精确评估
      • 对不对-代码运行起来对不对？
        • 是什么
          • 利用明确的检查规则或参考答案，对输出进行自动化评分。
          • 举例
            • 任务：生成一个求最大公约数的函数 / 模型生成代码 / ↓ / 运行单元测试 / ↓ / 全部通过：正确 / 存在失败：不完全正确
        • Subtopic 3
          • 功能正确性
            • 是什么：通过执行测试或检查约束条件，判断 AI 输出是否满足功能要求。
              • 例如，AI 生成了一段排序算法代码，我们通过单元测试来判断它是否正确。
            • 任务有没有做对
          • 与参考答案比较
            • 是什么：通过比较 AI 输出与预先准备的参考答案，计算两者的相似程度。
            • 生成的结果与标准答案有多像
    • AI 作为评委
      • 好不好-代码写得好不好？解释是否合理？
        • 为什么不能全部使用精确评估？
          • 因为有些问题没有明确的正确
        • 是什么
          • 使用另一个 AI 模型，按照指定标准评价目标模型的输出。
          • 举例
            • 任务：评价一段 Go 代码 / 输入 / 代码 / 评估标准 / 可读性 / 可维护性 / 是否存在明显的并发风险 / AI 裁判 / ↓ / 输出评分及依据
        • 注意
          • 一致性：相同输入多次评估，是否得到类似结果？
          • 准确性：裁判的评分是否真的符合预期标准？
          • 偏差：是否更偏爱自己的回答、靠前的回答或者更长的回答？
    • 比较式评估
      • 谁更好-模型A和模型B，谁写得更好
        • 为什么还需要比较式评估？
          • 因为有时判断哪个更好，比给每个结果打一个绝对分数更容易。 / 例如： / 让你分别给两篇技术文章打分，你可能不知道该给82分还是85分。 / 但如果把两篇文章放在一起，你可能很容易判断哪一篇解释得更清晰。 / 这就是比较式评估的价值。
        • 是什么
          • 直接比较多个模型的输出，再根据比较结果确定排名。
          • 举例
            • 相同任务 / ↓ / 模型A生成代码 / 模型B生成代码 / ↓ / 比较两份代码 / ↓ / A更好 / B更好 / 平局 / ↓ / 对多个任务重复比较 / ↓ / 计算胜率或模型排名
  • 怎么选评估方法
    • 精确方法优先；不能精确验证时，再考虑 AI 裁判；重要结论结合人工或独立证据复核。
      • 第一问：能不能直接验证结果？
        • 能，就优先使用功能正确性测试或程序化规则检查。
        • 例如 GoTiny 是否正确执行工具、返回的 JSON 是否符合 Schema。
      • 第二问：有没有可靠的参考答案或证据？
        • 有，就考虑精确匹配、参考答案相似度、NLI 或其他证据核验方法。
        • 注意，参考答案相似度只能提供相似性信号，并不能直接证明结果正确。
      • 第三问：是不是需要主观判断？
        • 如果需要评价可读性、连贯性、表达风格等，就考虑 AI 裁判或人工评估。
      • 第四问：需要比较多个模型吗？
        • 如果需要，就可以在上述方法的基础上进行比较式评估。
• 3. 构建并执行评估流水线
  • 是什么
    • 将评估标准、方法和数据组织成可重复执行的评估流程
  • 为什么
    • 需要客观衡量系统质量
    • 需要发现和定位失败环节
    • 需要验证不同版本的改进效果
  • 怎么做
    • 1. 确定评估目标
      • 为什么
        • 只评价最终结果，难以定位中间步骤的问题
        • 类似于明确测试目标
      • 怎么做
        • 选择具体标准和方法
        • 确定评估层级
          • 任务级（Task）
            • 是什么
              • 评价整个用户任务是否完成
            • 例如
              • Agent 是否成功修复代码缺陷
          • 轮次级（Turn）
            • 是什么
              • 评价每一轮交互的质量
            • 例如
              • Agent 本轮是否正确理解用户要求
          • 中间输出级
            • 是什么
              • 评价系统内部关键组件的输出
            • 例如
              • 工具选择是否正确
              • 检索结果是否相关
              • 工具执行结果是否被正确理解
          • 可以对应传统软件工程中的端到端测试、交互过程检查和组件测试。
        • 评分规则（Rubric）
          • 如何制定带示例的评分标准。
            • 例如评价技术文章的可读性： / - 1分：逻辑混乱，难以理解。 / - 3分：基本清晰，但部分概念解释不足。 / - 5分：结构清晰，概念准确，有充分示例。 / 这与普通测试断言的关系很直接。 / 传统测试通常是： / assert(actual == expected) / AI开放式任务不一定存在唯一预期结果，因此需要把「什么叫好」转换成可执行的评分规则。
    • 2. 准备评估数据
      • 是什么
        • 准备具有代表性、可以用于验证系统质量的测试样本
        • 类似于准备测试用例
      • 数据类型
        • 正常场景
          • 覆盖常见任务
        • 边界场景
          • 长输入、特殊格式等
        • 历史失败场景
          • 验证已经发现的问题
        • 越界场景
          • 验证系统是否正确拒绝或处理超出范围的请求
    • 3. 运行系统并执行评估
      • 是什么
        • 使用第二步选定的方法，评价待评估模型或系统
        • 类似于执行测试用例
      • 怎么评估
        • 开发阶段：以离线评估为主。
          • 类似于自动化测试和回归测试
        • 生产阶段：使用在线评估持续观察。
          • 类似于可观测性。log、metrics和Traces
    • 4. 分析评估结果
      • 是什么
        • 将测试结果转化为系统质量的判断依据
      • 怎么做
        • 统计整体指标
        • 分析失败案例
        • 按需进行数据切片
          • 按测试用例类别统计结果
          • 发现被总体指标掩盖的问题
          • 数据切片（Data Slicing）
            • 是什么
              • 按照不同特征把数据分成子集
            • 为什么
              • 总体平均指标可能掩盖局部问题
                • 假设你准备了100个测试用例，用来验证 Agent 是否能够正确选择工具并完成任务。 / 你的评估标准是：任务成功率至少达到85%。 / 执行结果： / 测试用例 / 数量 / 成功 / 成功率 / 全部测试 / 100 / 86 / 86% / 结果：86%超过85%，整体评估通过。 / 但现在，我们将100个测试用例按输入长度分类。 / 数据切片 / 用例数量 / 成功 / 成功率 / 短输入任务 / 80 / 76 / 95% / 长输入任务 / 20 / 10 / 50% / 整体 / 100 / 86 / 86% / 这时候发现了什么？ / 模型整体成功率86%，但它在长输入任务上的成功率只有50%。 / 也就是说，整体表现看起来不错，但实际上存在一个明显的薄弱场景。 / 如果我们只看总体指标，可能就会忽略这个问题。 / 这就是数据切片的意义。
            • 怎么做
              • 按任务类型切分
              • 按输入长度切分
              • 按数据来源切分
              • 分别评价每个子集
            • 注意
              • 辛普森悖论
                • 模型A整体表现比模型B好，但模型B在每个对应的子集上反而都比A好。
                  • 例如： / 任务类型 / 模型A / 模型B / 简单任务 / 90/100 = 90% / 19/20 = 95% / 困难任务 / 1/10 = 10% / 12/20 = 60% / 总体 / 91/110 = 82.7% / 31/40 = 77.5% / 观察结果： / - 简单任务：B更好。 / - 困难任务：B更好。 / - 总体成功率：反而A更高。 / 为什么？ / 因为模型A的测试集中，简单任务占比更高。 / 所以在比较模型时，不仅要比较整体成功率，还要注意不同测试集的样本分布。 / 这也是为什么评估两个模型时，通常应该尽量使用同一批测试任务。否则总体分数可能造成误导。 / 不过，辛普森悖论不是每次做数据切片都需要单独分析的复杂问题，你理解它的产生原因即可。
            • 类似于给测试用例分类
        • 比较不同版本的表现
    • 5. 根据评估结果做决策
      • 是什么
        • 利用评估结果判断系统是否满足需求，并决定选择、优化或继续验证
      • 为什么
        • 评估本身不是目的
        • 评估结果需要转化为实际工程决策
        • 评估指标改善不一定代表业务价值提升
      • 2. 模型选择
        • 是什么
          • 从候选模型中选择最适合实际应用的模型
        • 为什么
          • 不存在适合所有任务的最佳模型
          • 模型质量、成本和延迟存在权衡
          • 还需要考虑部署方式和其他硬约束
        • 怎么做
          • 第一步：筛选候选模型
            • 区分硬属性和软属性
              • 硬属性
                • 无法改变或难以改变的属性
                • 例如许可协议、数据隐私、部署限制
              • 软属性
                • 可以通过适配或优化改善的属性
                • 例如部分情况下的准确率、延迟
            • 排除不满足硬约束的模型
          • 第二步：公开基准初筛
            • 选择与业务相关的基准
            • 检查基准是否饱和
            • 检查训练数据污染
            • 检查不同基准之间的相关性
            • 根据业务重要性考虑指标权重
            • 保留有潜力的候选模型
          • 第三步：私有评估
            • 复用第三步建立的评估流水线
            • 使用相同业务任务测试候选模型
            • 比较各模型的实际质量
            • 比较成本和延迟
          • 第四步：综合选择
            • 排除不满足硬约束的模型
            • 选择满足业务质量要求的模型
            • 在合格模型中权衡质量、成本和延迟
            • 确定部署方式
              • 商业模型 API
              • 开放权重模型托管 API
              • 自托管开放权重模型
            • 综合考虑
              • 数据隐私
              • 数据溯源
              • 性能表现
              • 功能性
              • 成本
              • 控制权
              • 设备端部署