Wiki Notes

Appearance

多模态评测案例专题 ​

版本：v1.2

最后更新：2026-07-09

适用对象：正在做图像、语音、视频、实时交互、多模态生成与审核系统，需要把“看起来能用”推进到“有评测闭环、能灰度、能回归”的产品、评测与平台同学

多模态项目最容易在评测上掉进一个坑：

  • 原型很好看，但没人说得清到底哪里算成功、哪里会失败、上线后怎么监控退化。

文本任务至少还常常能先问一句：

  • 答得对不对

多模态一旦涉及图片、语音、视频和实时交互，这个问题就不够了。

因为真正影响上线质量的，通常是五类因素同时存在：

  • 模态基础能力
  • 任务完成质量
  • 交互与产品体验
  • 成本与时延
  • 安全、审核与留存边界

所以这篇专题的重点不是抽象讲“多模态评测很重要”，而是把常见项目拆成：

  • 应该怎么分层评
  • 每层评什么
  • 哪些指标适合自动化，哪些必须人工评
  • 发布门禁和线上监控怎么接起来

1. 为什么多模态评测不能只有一个总分 ​

很多团队一开始想要一个统一分数，比如：

  • 这个视觉助手 82 分
  • 这个语音机器人 76 分

但这在工程上通常帮助不大。

因为同样一个“效果差”，可能来自：

  • 图像输入质量差
  • OCR 错
  • 提示词装配错
  • 工具调用错
  • 语音 turn detection 差
  • 视频时间点对不齐
  • 生成图主观不美观

如果这些问题都被压进一个总分里，团队根本不知道该修哪里。

1.1 更稳的做法是五层拆分 ​

第一层：模态基础能力 ​

  • 看图是否准确
  • 转写是否准确
  • 视频时间轴是否稳定
  • 图像 / 视频输入是否被正确解析

第二层：任务完成质量 ​

  • 字段抽取是否完整
  • 摘要是否覆盖关键事件
  • 工具调用是否正确
  • 结构化输出是否合法

第三层：交互体验 ​

  • 首次响应够不够快
  • 打断恢复是否自然
  • 结果是不是对下游可用
  • 多轮上下文是否稳定

第四层：运营约束 ​

  • 单次成本
  • 延迟
  • 重试率
  • 人工返工比例

第五层：治理与风险 ​

  • 是否命中高风险失败桶
  • 是否需要人工复核
  • 是否触发内容安全或隐私边界
  • 资产留存与删除是否合规

1.2 单分可以做展示，但不能做诊断 ​

更合理的实践通常是：

  • 对外展示一个聚合分或通过率
  • 对内排障永远看分桶、分层和失败类型

2. 多模态评测先问“任务 contract 是什么”，再问“模型怎么样” ​

OpenAI 当前 Working with evals 文档把 eval 拆成两个核心部分：

  • data_source_config
  • testing_criteria

这件事在多模态场景更重要，因为如果任务没定义清楚，后面评测标准必然会漂。

例如：

  • “看图回答问题” 不是一个任务
  • “从发票图片中抽取税号并返回 schema” 才更像一个任务

2.1 多模态任务要尽量写成可测 contract ​

更适合评测的数据项通常应包含：

  • 输入样本
  • 任务目标
  • 期望输出或人工标签
  • 特殊难点标签

例如视觉抽取可以额外加：

  • 是否模糊
  • 是否倾斜
  • 是否多页
  • 是否存在印章遮挡

例如语音助手可以额外加：

  • 是否多人说话
  • 是否方言或口音
  • 是否中英混说
  • 是否会发生用户打断

例如视频理解可以额外加：

  • 是否高速镜头
  • 是否有字幕
  • 是否依赖音画联合理解
  • 是否需要精确时间点

2.2 一个更像生产系统的样本对象 ​

如果团队已经进入版本治理阶段，样本最好至少保留这些字段：

  • case_id
  • task_type
  • input_artifact_ids
  • difficulty_tags
  • risk_bucket
  • expected_contract
  • grader_type
  • owner

这样后面才能做：

  • 样本分桶
  • 失败回流
  • 版本比较
  • 高风险门禁

3. 多模态 eval 最好把“媒体证据对象”单独建出来 ​

文本任务很多时候只要保留：

  • 输入
  • 输出

多模态任务通常不够。

因为你最终要复盘的往往不是一句文字，而是：

  • 哪张图
  • 哪一页 PDF
  • 哪一段音频
  • 哪一个视频区间
  • 哪一次打断前后的会话状态

3.1 一个通用的证据对象可以长什么样 ​

  • artifact_id
  • artifact_type
  • source_uri
  • start_ts
  • end_ts
  • page_no
  • frame_bucket
  • transcript_excerpt
  • ocr_excerpt
  • reference_label

3.2 为什么这一步特别重要 ​

因为没有证据对象，你很难稳定回答这些问题：

  • 模型是看错了，还是根本没看到
  • 转写错了，还是后续推理错了
  • 视频时间点偏了，还是摘要覆盖不够
  • 生成结果是审美问题，还是指令遵循问题

4. 多模态数据集怎么准备才像真实项目 ​

OpenAI Working with evals 文档强调，测试数据需要代表你期望 prompt 或系统处理的数据类型。

在多模态里，这句话尤其重要。

因为如果评测集只放：

  • 清晰图
  • 干净音频
  • 短视频
  • 理想光照
  • 单人说话

那么上线后真实数据一来，结果几乎一定会崩。

4.1 建议至少覆盖这些“脏样本” ​

  • 模糊图
  • 倾斜文档
  • 压缩截图
  • 噪音音频
  • 多说话人
  • 长视频
  • 多图混合场景
  • 中英混说
  • 低质量 OCR
  • 快速镜头切换

4.2 评测集里最好有难度标签 ​

例如：

  • blurred
  • multi_page
  • cross_lingual
  • multi_speaker
  • long_video
  • fast_motion
  • interruptible_session

这样后续回归时更容易看出退化到底发生在哪一类样本。

4.3 脏样本最好不要只占个位数 ​

如果脏样本只放 2 个、3 个，它更像示意而不是门禁。

更稳的做法通常是：

  • 主流样本集
  • 边界样本集
  • 高风险事故样本集

三套同时保留。

5. 哪些维度更适合自动 grader，哪些更适合人工 rubric ​

5.1 更适合自动 grader ​

  • schema 合法性
  • 分类标签匹配
  • 字段值是否和参考答案一致
  • 时间点是否落在允许区间
  • 转写字符错误率或关键词命中率
  • 成本 / 延迟 / 重试率

5.2 更适合人工标注或复核 ​

  • 图像美感
  • 视频镜头连续性
  • 语音自然度
  • 多模态回答是否“真理解”了上下文
  • 品牌一致性
  • 是否值得直接交付

5.3 最稳的通常是混合式 ​

  • 规则打分负责结构和协议
  • grader 负责可规模化的语义判断
  • 人工 rubric 负责高价值样本和主观维度

5.4 grader 也要分工，不要一个 grader 管所有任务 ​

更稳的团队通常会拆：

  • schema_grader
  • citation_grader
  • timestamp_grader
  • safety_grader
  • style_or_delivery_rubric

因为视觉抽取、实时语音、视频理解和图像生成，根本不是一类判分问题。

6. 案例一：图片问答系统怎么评 ​

典型任务：

  • 上传图片
  • 用户提问
  • 系统回答

6.1 不要只测“答对没” ​

更该拆成：

  • 问题类型是否被覆盖
  • 图像细节是否被正确关注
  • 是否引用了正确视觉证据
  • 输出是不是对下游可用

6.2 建议的样本分桶 ​

  • 普通自然图
  • 细节型图片
  • 多对象图片
  • 含文字图片
  • 多图对比图片

6.3 更适合自动评的部分 ​

  • 分类或标签判断
  • 字段是否命中
  • 是否返回合法 schema
  • 是否引用了正确图片编号或区域标签

6.4 更适合人工评的部分 ​

  • 是否真的理解了图中关系
  • 回答是否忽略关键细节
  • 多图对比是否合乎人的直觉

6.5 线上最值得留的证据字段 ​

  • image_count
  • image_resolution_bucket
  • question_type
  • evidence_refs
  • answer_schema_valid

7. 案例二：文档视觉理解怎么评 ​

典型任务：

  • 合同解析
  • 表单抽取
  • PDF 问答

7.1 只看 OCR 准确率会误导团队 ​

因为很多业务里，真正重要的不是字识别本身，而是：

  • 字段有没有抽全
  • 表头和字段有没有对上
  • 多页信息是否串起来
  • 关键数字有没有错

7.2 更适合拆成三层 ​

OCR 层 ​

  • 字符错误率
  • 行顺序
  • 特殊字符正确率

结构层 ​

  • 表格结构保留
  • 页内字段关系
  • 页间连续性

业务层 ​

  • 税号、日期、金额等关键字段准确率
  • 缺失字段召回
  • 高风险字段人工复核命中率

7.3 文档任务的高风险失败桶最好单列 ​

例如：

  • wrong_amount
  • wrong_date
  • missed_signature
  • page_merge_error
  • table_alignment_error

因为这些错的业务后果差异很大。

8. 案例三：语音助手怎么评 ​

典型任务：

  • 实时问答
  • 电话助手
  • 语音陪练

8.1 语音场景必须至少拆三层 ​

音频层 ​

  • 转写准确率
  • 关键词识别率
  • 口音与噪音鲁棒性

会话层 ​

  • turn 切换自然度
  • 打断处理
  • 多轮上下文保持

任务层 ​

  • 工具调用正确率
  • 最终任务完成率
  • 是否误执行

8.2 很多“模型回答不行”其实是 turn detection 问题 ​

例如：

  • 用户还没说完系统就答
  • 用户打断后状态错乱
  • 工具执行回来时继续说了过时内容

这些问题如果不单列成会话层评测，会一直被误归因成模型问题。

8.3 实时语音更该加哪些专属指标 ​

  • 首次语音响应时延
  • 用户打断后恢复时延
  • 空白 turn 比例
  • 误触发回答比例
  • tool wait 期间沉默过长比例

8.4 更像生产系统的会话事件对象 ​

  • session_id
  • turn_id
  • barge_in
  • vad_segment_count
  • transcript_finalized
  • tool_called
  • spoken_response_ms

9. 案例四：视频理解怎么评 ​

典型任务：

  • 视频摘要
  • 事件识别
  • 教学视频解析

9.1 视频评测必须把时间轴单独拿出来 ​

建议至少测：

  • 关键事件是否被召回
  • 时间点定位是否正确
  • 顺序判断是否正确
  • 画面和语音是否被一起用到了

9.2 长视频比短视频更需要分段评 ​

因为整段一个分数无法说明：

  • 是哪一段漏了
  • 是转场出了问题
  • 还是字幕和画面冲突

更稳的办法通常是：

  • 按镜头
  • 按章节
  • 按时间段

分段评测。

9.3 时间点评测不要只看“差不多” ​

更实用的做法通常是预先定义允许误差，例如：

  • <= 2s
  • <= 5s
  • same_segment

而不是上线后才争论“这个偏差算不算大”。

9.4 视频任务最值得留的证据字段 ​

  • clip_id
  • start_ts
  • end_ts
  • shot_id
  • timeline_summary
  • transcript_excerpt
  • ocr_excerpt

10. 案例五：图像生成与编辑怎么评 ​

典型任务：

  • 文生图
  • 局部编辑
  • 品牌素材生成

10.1 这类任务通常同时需要主观评和自动评 ​

适合自动评的：

  • 是否返回合法尺寸 / 格式
  • 是否触发安全拦截
  • 文本渲染是否可读
  • 是否满足基本构图要求

适合人工评的：

  • 美感
  • 品牌一致性
  • 主体可信度
  • 局部编辑保真度

10.2 更适合建立人工 rubric ​

例如每张图从几个维度给分：

  • 指令遵循
  • 视觉质量
  • 文本渲染
  • 品牌一致性
  • 可直接交付性

这样主观评才会更稳定。

10.3 生成类任务最好单列“返工桶” ​

例如：

  • style_drift
  • brand_violation
  • text_unreadable
  • subject_inconsistency
  • edit_not_preserved

这会比一个笼统的“生成失败”更能指导优化。

11. 案例六：多模态实时交互怎么评 ​

典型任务：

  • 边看屏幕边语音协助
  • 语音 + 图片 + 工具调用
  • 实时演示或培训陪练

11.1 这类任务最怕的不是单点错，而是链路错位 ​

常见失败包括：

  • 看到的画面不是用户正在说的那一屏
  • 工具调用和口语回复脱节
  • 打断后上下文没收好
  • 图像和语音分别都对，但最终结论错

11.2 更适合拆成四层 ​

  • 输入同步层：图像、语音、事件时间对齐
  • 会话层：turn、打断、恢复
  • 工具层：调用正确率与等待体验
  • 任务层：最终完成率

11.3 线上最好留哪些字段 ​

  • session_id
  • screen_frame_ref
  • audio_turn_ref
  • tool_wait_ms
  • interrupt_count
  • final_task_status

12. 多模态评测结果怎么接进发布门禁 ​

多模态项目如果只在周会里展示一次评测结果，通常不够。

更实用的做法是把 eval 结果接进：

  • 版本比较
  • 灰度门禁
  • 回归监控
  • 样本回放

12.1 发布前至少看六件事 ​

  • 整体成功率
  • 高风险样本桶是否退化
  • 成本 / 延迟是否超预算
  • 新失败是否集中在某类模态
  • 实时打断与恢复是否变差
  • 生成类审核返工率是否上升

12.2 更稳的门禁通常分三层 ​

必过门禁 ​

  • schema 合法率
  • 高风险样本桶
  • 明确安全违规项

软门禁 ​

  • 平均得分
  • 成本
  • P95 延迟

观察门禁 ​

  • 新样本分布
  • 人工返工率
  • 灰度期异常告警

12.3 门禁最好绑定版本对象 ​

至少应知道：

  • 哪个模型版本
  • 哪个 prompt 版本
  • 哪个工具定义
  • 哪个 grader 版本
  • 哪个样本集版本

否则“这次过门禁”本身都不可复现。

13. 线上监控不要只盯错误率 ​

多模态系统很多退化不会表现成 API error。

更容易出现的是：

  • 回答还能出，但图像理解偏了
  • 转写还能跑，但 turn 切分变差
  • 视频摘要还能给，但时间点偏移更大
  • 生成还能完成，但返工率变高

13.1 更值得长期看的线上指标 ​

  • 模态输入分布变化
  • 首次响应与最终完成时延
  • 打断率与恢复时延
  • 时间点偏移桶
  • 审核退回率
  • 人工接管率

13.2 最好把线上失败样本自动回流 ​

尤其是这些场景：

  • 用户频繁重试
  • 用户多次改口
  • 明显投诉
  • 审核驳回
  • 工具误执行

这类样本最适合补进高风险回归集。

14. 多模态 eval 哪些对象必须版本化 ​

除了模型和 prompt，本专题更建议版本化这些对象：

  • 样本集
  • rubric
  • grader prompt
  • 工具定义
  • 输出 schema
  • 风险分桶
  • 发布阈值

因为只要这些对象变化，分数就可能变化。

14.1 一个很容易忽视的问题 ​

很多团队看起来“分数涨了”，其实只是：

  • 样本变容易了
  • grader 变松了
  • 安全规则变少了

所以版本化不是文档洁癖，而是避免自我误导。

15. 常见反模式 ​

  • 拿文本 eval 思路硬套所有多模态任务。
  • 只做 demo 样本，不做脏样本。
  • 只有主观感受，没有结构化 rubric。
  • 只测模型，不测成本和延迟。
  • 不拆模态层、任务层、产品层。
  • 只在上线前评一次，不做回归。
  • 只存最终文字结果，不存媒体证据对象。
  • 没有时间轴误差桶，却想稳定评视频和实时语音。

16. 这章最值得立刻补上的实践动作 ​

  1. 为每类多模态任务补一个明确 contract，不要再用“看图问答”“语音助手”这种泛称做评测名。
  2. 给样本集增加难度标签和高风险失败桶，避免所有失败都混在一起。
  3. 为图像、音频、视频和实时会话统一一套媒体证据对象，保证回放与审计可追。
  4. 把自动 grader、人工 rubric 和线上运营指标明确分层，不要再让一个总分承担所有治理职责。
  5. 为视频和实时语音单独定义时间轴 / 打断 / 恢复相关指标，不要继续沿用纯文本问答口径。
  6. 把评测结果接进发布门禁和线上回流，不要只在评测报告里停留。

17. 推荐搭配阅读 ​

18. 重点官方资源 ​

以下入口在 2026-07-09 复查时可访问：