Appearance
05. 多模态评测、成本与治理
版本：
v1.1最后更新：
2026-07-08适用对象：要把图像、语音、视频、多模态工作流真正上线运营，而不是只做 demo 的产品、研发、平台、安全和交付同学
多模态系统最容易出现一种假象：
- 演示很惊艳，但上线很难控。
按 2026-07-08 可访问的 OpenAI Evaluation best practices、Graders guide、Managing costs for Realtime、Data controls in the OpenAI platform、Moderation 官方资料来看，多模态上线最容易被低估的不是模型效果，而是：
如何把预处理、模型输出、任务结果、成本、留存和审核放进同一套治理框架。
1. 多模态评测要拆成四层
如果只看“最终回答好不好”，大多数多模态系统都很难定位问题。
1.1 预处理层
重点看：
- 图片裁切是否合理
- PDF / 页面切分是否正确
- 音频切片是否稳定
- 视频抽帧是否命中关键片段
这一层出错，后面再强的模型也救不回来。
1.2 模态能力层
重点看：
- 视觉识别是否准确
- 转写是否稳定
- 视频片段理解是否保住时序
- 生成结果是否可交付
1.3 任务完成层
重点看：
- 字段抽取是否完成
- 语音会话是否完成意图
- 视频摘要是否可回放
- 生成任务是否达到业务目标
1.4 运营治理层
重点看：
- 延迟
- 单任务成本
- 重试率
- 人工复核率
- 安全审核命中率
2. 不同模态为什么不能共用一套评测口径
2.1 图像 / 文档系统更像字段和证据问题
更适合看：
- 字段准确率
- 漏抽率
- schema 合法率
- 页码或证据回引率
2.2 语音系统更像交互和时延问题
更适合看：
- 首响应延迟
- interruption 恢复成功率
- 转写稳定性
- 对话完成率
2.3 视频系统更像时间轴问题
更适合看：
- 关键片段召回率
- 时间顺序正确率
- 证据片段定位成功率
- 异步任务完成率
2.4 生成类系统更像交付问题
更适合看：
- 审核通过率
- 风格一致性
- 可编辑率
- 批量交付成功率
3. 自动评测和人工评测应该怎么分工
OpenAI 当前把 Evaluations 和 Graders guide 单独列出来，本身就说明评测不是“跑个脚本”这么简单。
3.1 自动评测更适合兜底这些问题
- 输出是否符合 schema
- 关键字段是否缺失
- 是否带时间戳或证据引用
- 是否命中过滤规则
- 是否超出成本或时延预算
3.2 人工评测更适合兜底这些问题
- 图像结果是否真的可用
- 语音是否自然
- 视频摘要是否抓住重点
- 生成内容是否具备交付感
3.3 更稳的做法不是二选一
而是：
- 自动规则先筛。
- 高风险或高价值样本再做人审。
- 人审结果反哺回归集。
3.4 多模态 grader 最好拆成“硬校验”和“体验校验”
OpenAI 当前 Graders guide 和 Evaluation best practices 放在一起看，一个很实用的启发是：
- 不同 grader 负责不同问题
放到多模态系统里，至少可以先拆成两层：
硬校验 grader- schema 是否合法
- 时间戳 / 页码 / 引用是否存在
- 是否超预算
- 审核标签是否命中
体验 grader- 摘要是否抓住重点
- 语音回复是否自然
- 视觉输出是否真正可交付
- 视频总结是否保住时间顺序
这样做的价值在于：
- 先把明显错误自动拦住
- 再把“能不能上生产”的判断交给更贵但更接近业务的 grader 或人工复核
3.5 评测资产最好保留“中间产物”，不要只留最终答案
很多多模态评测失败后追不回去，不是因为没打分，而是因为只保存了最后结果。
更稳的样例结构通常还会保留：
- 原始媒体引用
- 预处理产物
- 页面切分结果
- 抽帧点
- 音频分段
- 中间结构化输出
- 最终任务结果
- 人工复核标注
这会直接影响后续能不能做：
- root cause 分析
- grader 修正
- 失败样例复用
- 版本间可解释对比
4. 多模态回归集应该长什么样
4.1 图像 / 文档类
至少要覆盖：
- 模糊图
- 低分辨率图
- 多栏文档
- 扫描件
- 表格页
- 中英混排或复杂格式
4.2 语音类
至少要覆盖：
- 噪声环境
- 弱网
- 不同口音
- 用户打断
- 长会话
- 工具等待
4.3 视频类
至少要覆盖：
- 长视频
- 快切镜头
- 音画不完全同步
- 关键事件很短的片段
- 多人、多场景切换
4.4 生成类
至少要覆盖：
- 风格模板
- 批量变体
- 审核边界案例
- 不同品牌 / 角色连续性
5. 成本为什么一定要单独建账
OpenAI 当前把 Managing costs for Realtime 单独拿出来，本身就说明多模态成本不适合简单按“文本 token”思维理解。
5.1 多模态成本通常来自多部分叠加
- 媒体输入
- 推理
- 媒体输出
- 长连接或持续会话
- 异步任务和重试
- 存储和下载
5.2 语音系统最容易出现“对话变长，成本失控”
因为它会同时叠加：
- 音频输入
- 转写或推理
- 音频输出
- 工具等待与会话持续
5.3 视频系统最容易出现“推理之外的运营成本更大”
因为它常伴随：
- 文件存储
- 抽帧
- 转写
- 异步队列
- 结果下载
5.4 图像 / 文档系统最容易出现“重试把成本放大”
因为一旦没有做：
- 页面切分
- 区域裁切
- 结构化校验
就会反复整页重跑。
5.5 更稳的成本视角通常是一张“多模态账本”
OpenAI 当前 Managing costs for Realtime、Pricing、Batch API 放在一起看，一个特别重要的现实是：
- 多模态成本不是一个模型单价，而是一条流水线账本
更实用的记账维度通常包括：
- 输入成本
- 图像
- 音频
- 文件
- 推理成本
- 输出成本
- 音频播报
- 生成图片 / 视频
- 会话成本
- 长连接
- turn 数
- 中断恢复
- 工作流成本
- 抽帧
- 转写
- rerun
- 下载与存储
如果没有这张账本，团队很容易只盯着：
- 模型贵不贵
却忽略：
- 预处理和重试才是大头
5.6 成本治理最好和任务路由一起设计
更贴近生产的做法通常不是：
- 所有媒体任务都走同一个最强模型
而是按任务拆 route，例如：
- 文档抽取：先轻量视觉 + schema 校验，再决定是否升级
- 实时语音：先低延迟 route，复杂问题再切 reasoning / tool route
- 视频理解：先抽帧摘要 route，必要时再做深分析
- 批量生成：优先异步 lane，而不是同步阻塞
这背后的关键不是“省一点钱”，而是：
把高成本能力留给真正需要它的任务
6. 多模态系统上线前最好先定三种预算
6.1 单任务预算
例如：
- 单份文档最多多少钱
- 单次语音对话最多几分钟
- 单条视频任务最多多久
6.2 峰值预算
例如：
- 高并发会议转写
- 高峰期素材生成
- 批量视频渲染
6.3 失败预算
例如：
- 重试上限
- 人工兜底阈值
- 自动降级策略
没有失败预算，很多系统一出问题就会“越救越贵”。
6.4 多模态系统最好预先定义降级层级
比起“失败后再想办法”，更稳的做法通常是提前写清：
- 图像 / 文档
- 整页失败时是否切区域重跑
- 是否降级成只抽摘要、不给结构化字段
- 语音
- 是否从实时语音降级到仅转写
- 是否从语音回复降级到文字回复
- 视频
- 是否从全片理解降级到关键片段
- 是否从同步分析降级到异步任务
- 生成
- 是否先给低保真草稿
- 是否把高质量导出切到后台任务
降级层级的价值在于：
- 出问题时系统还能服务
- 失败预算不会被无限重试吃掉
6.5 Batch / async lane 很适合吞掉低实时性媒体任务
OpenAI 当前 Batch API、Realtime、Audio and speech 放在一起看，很容易得到一个实用判断：
- 不是所有多模态任务都应该跑在同步交互路径里
更适合异步或批处理的通常包括：
- 大量文档抽取
- 历史录音转写
- 素材批量生成
- 视频长任务分析
这样做的价值通常是：
- 成本更可控
- 高峰时不挤占实时 lane
- 更容易做重试、重跑和人工兜底
7. 治理不只是权限，也包括数据生命周期
OpenAI Data controls in the OpenAI platform 官方资料把图片、文件、视频等数据路径单独说明出来，本身就说明多模态数据和纯文本数据的治理边界不同。
7.1 多模态系统要单独回答这些问题
- 原始图片、录音、视频留多久
- 中间产物留多久
- 哪些结果能长期存，哪些只能短存
- 哪些内容要脱敏
- 谁能下载、谁能复盘
7.2 文件和媒体更容易碰到“留着有用，不留又难追责”
所以更实用的做法通常是分层保留：
- 排障层
- 审计层
- 运营层
- 用户可见层
7.3 安全治理必须和多模态一起看
因为多模态会额外带来：
- 图片隐私
- 录音合规
- 视频人物与场景敏感度
- 内容审核风险
7.4 更稳的生命周期模型通常会把“原件”和“派生物”分开
多模态系统里最容易被忽略的一点是：
- 原始媒体
- 中间派生物
- 最终结果
往往不应该共用同一套保留策略。
一个更实用的分层通常是：
原始媒体层- 图片、录音、视频、PDF 原件
派生物层- 切页图、抽帧图、波形片段、OCR 文本、转写文本
结果层- 结构化字段
- 摘要
- 标签
- 生成成品
这样后续才能更清楚地回答：
- 哪些可以长留
- 哪些只能短留
- 哪些只允许审计角色看
- 哪些可以回到用户界面
8. 内容审核和权限控制要进入媒体工作流
OpenAI Moderation 官方资料本身就提醒我们，安全过滤不是只对文本输出做一下判断。
8.1 图像与视频生成要补审核
重点通常包括：
- 对外素材风险
- 品牌内容边界
- 版权和风格风险
- 人像和敏感元素
8.2 语音助手要补动作审批
重点通常包括：
- 语音下单
- 语音改配置
- 语音发消息
- 语音执行高风险工具
8.3 文档系统要补权限和最小可见
重点通常包括：
- 哪些页能看
- 哪些字段能导出
- 哪些文件只能摘要不能原文暴露
8.4 更稳的审核设计通常是“按媒体阶段进策略”
多模态审核如果只放在最终输出层，经常会漏掉很多问题。
更贴近生产的控制点通常包括：
- 输入审核
- 原始媒体是否合法、可处理
- 预处理审核
- 是否切出了敏感区域
- 生成前审核
- 生成请求是否越过品牌 / 人像 / 版权边界
- 结果审核
- 输出内容是否适合交付
- 导出审核
- 哪些结果可以下载、外发、长期保存
这样做的好处是：
- 问题不会只在最后一层才暴露
- 审核策略更容易映射到真实工作流节点
9. 多模态系统最值得建设的可观测性
9.1 图像 / 文档链路
至少要能看到：
- 原始输入
- 页面 / 区域切分
- 结构化输出
- 校验失败点
9.2 语音链路
至少要能看到：
- turn 边界
- interruption 事件
- 工具触发点
- 用户放弃点
9.3 视频链路
至少要能看到：
- 抽帧点
- 片段边界
- 总结中间结果
- 下载和交付状态
9.4 生成链路
至少要能看到：
- 任务状态
- 版本
- 审核流
- 最终交付
9.5 更适合多模态系统的 trace，通常要带“媒体谱系”
OpenAI 当前 Trace grading 和多模态输入 / Realtime 资料放在一起看，一个非常实用的启发是：
- 只记录最终 response trace，通常不够排查多模态问题
更适合多模态的 trace 结构通常还会补：
- media asset id
- preprocess version
- page / frame / segment lineage
- model route
- grader route
- moderation route
- export / delivery status
这样当质量退化时，团队至少能回答：
- 是原始媒体变了
- 是预处理变了
- 是路由变了
- 还是审核 / 导出阶段变了
9.6 运营面板最好按模态拆，而不是只看一个总 dashboard
更稳的可观测面板通常至少拆三层：
媒体处理面板- 切页成功率
- 抽帧耗时
- 音频分段失败率
模型输出面板- 字段缺失率
- 实时 turn latency
- 视频总结完成率
治理面板- 审核命中率
- 人工复核率
- 下载 / 导出异常
- 长留素材数量
否则很容易出现：
- 总体看着正常
- 某一模态链路其实已经持续退化
10. 最容易踩的坑
- 只做 end-to-end 主观体验，不做分层评测。
- 多模态成本没有单独记账。
- 文件、录音、视频留存边界上线后才补。
- 生成类和理解类共用一套质量标准。
- 只看模型输出，不看预处理和中间产物。
- 把同步交互链路和异步批处理链路混成一套预算。
- 只保存最终结果，不保存预处理和中间结构化产物。
- 审核只卡最终输出，不看输入、预处理和导出阶段。
- 出问题后只有总成本，没有 route / lane / asset 级账本。
11. 推荐搭配阅读
12. 重点官方资源
以下资源在 2026-07-08 核查可访问：
- OpenAI Evaluation best practices
- OpenAI Graders guide
- OpenAI Managing costs for Realtime
- OpenAI Data controls in the OpenAI platform
- OpenAI Moderation
13. 什么时候该跳到别的目录
- 当你开始做具体视觉、语音、视频链路时，分别跳到 02-图像理解、文档解析与视觉工作流、03-实时语音、转写与语音助手架构、04-视频理解、生成与时间轴设计。
- 当你开始做更细的线上评测、失败复盘和业务指标体系时，跳到 评测运营与案例。
- 当你开始治理媒体权限、安全审核和合规策略时，跳到 安全治理。