评估多模态 AI 的 7 大核心指标

如果要把这件事浓缩成一个观点，那就是：我绝不会只凭准确率来评判一套多模态 AI 系统。 一个模型可能得分很高，却仍然在_延迟_、接地（grounding）、_安全性_或_每个成功任务的成本_上翻车。而这些疏漏在生产环境里会很快暴露出来。

简短版是这样的：

• 我会同时考察 7 项指标：质量、延迟、规模、安全、对齐、用户体验和成本

• 我会追踪尾部延迟，而不只是平均值，因为900 ms 的平均值背后仍可能藏着8 秒以上的 p99 延迟

• 我会衡量幻觉和视觉依赖度，因为有些模型听起来很对，实际上几乎没用上图像

• 我会采用每个成功任务的成本，而不是单次调用的价格，因为重试、内容审核和存储会让开销快速攀升

• 我会在每次模型更新后，重跑一套冻结的 100 到 500 条真实样本，以便尽早发现漂移

对我来说，道理很简单：最好的多模态模型并不是基准分数最高的那个。而是那个在杂乱输入下依然保持准确、有接地、对用户来说足够快、足够安全，并且能把预算控制在**美元（$）**范围内的模型。

MultiModal LLM Evaluation: Best Techniques and Common Mistakes

快速对比

如果我今天，也就是 2026 年 7 月 6 日，来搭建评估体系，我会把这七项检查当成一张记分卡——而不是七份彼此独立的报告。

为什么多模态评估需要不止一个指标

单一分数无法告诉你一套多模态系统在生产环境里能否撑得住。

一个模型可能贴出漂亮的分数，用起来却慢得没法用。或者它听起来流畅又精致，却错过了图像里真正的内容。这就是陷阱：单个数字可能会掩盖掉那种日后会引发问题的确切失败类型。

薄弱环节也会随任务而变。一个发票模型也许能正确读出文字，却看漏了版面布局，于是拉出了错误的发票总额。一个语音助手也许能高准确率地转写词句，却仍然听不出语气。这些是截然不同的错误，正因如此，评估需要拆分成各自独立的指标，而不是把所有东西挤进一个分数里。

"评估多模态系统需要一次范式转变。像 BLEU 或准确率这样的纯文本评估指标是不够用的……评估多模态系统需要那些对模态间对齐敏感的指标，而不仅仅是单个模态内部的表现。" - eval.qa ^[8]

还有成本这一面。更好的接地能力可能会推高单次推理的价格，因此成本控制需要从一开始就成为评估的一部分，而不是部署之后才去看的东西。如果一个模型很准却太贵，在生产环境里它照样是失败的。

下面这七项指标覆盖了这些检查。

1. 任务准确率与质量分数

先从任务专属质量开始。一个多模态模型纸面上可能很强，却仍然可能在你真正在意的那一种输出类型上栽跟头。

下面这张表把常见的多模态任务和用来评判它们的主要指标一一对应起来，方便你把测量方法和具体工作匹配上：

聚合分数会掩盖薄弱环节。举个例子，一个视觉问答（VQA）模型在简单的颜色问题上可能拿到 95%，到了更难的推理任务上就跌到 40%。这是个巨大的落差。所以在你相信那个头条数字之前，先按问题类型把准确率拆开来看。

VQAv2 的顶尖分数如今已超过 85%，这意味着该基准更多是一道基线检查，而不再是区分度高的分水岭 ^[3]。

你还应该单独追踪幻觉。开源 VLM 平均为 38%，而领先模型接近 12% ^[8]。CHAIR 指标（Caption Hallucination Assessment with Image Relevance）直接衡量这一点。在很多生产场景里，低于 0.15 的分数是一个不错的目标 ^[8]。

对于生产环境的监控，保留一套冻结的内部集合，含 100–500 条真实样本，并按固定周期重跑。这是在质量漂移演变成面向用户的问题之前发现它的最简单办法之一。

一旦质量过了这道关，下一步就是检查模型能否足够快地交付这份质量，以满足生产要求。

2. 延迟、响应时间与吞吐量

延迟是产出第一个可用输出所需的时间。响应时间是用户体验到的完整端到端等待。吞吐量是系统每秒能处理多少请求或 token。

在多模态系统里，这些数字变化得很快。

一张 1024×1024 的图像可能用掉约 1,500 个提示 token，而图像预填充的成本可能比标准文本请求高 15–30 倍 ^[11]。视频还要更重。一段以每秒 1 帧采样的 10 分钟片段大约会用掉 153,600 个 token ^[11]。在很多情况下，减速在推理_之前_就开始了。缩放、转码和抽帧往往成了主要的瓶颈。

这就是平均值讲不出全部故事的原因。用百分位而不是平均值来测量延迟，因为平均值会藏住讨厌的尾部尖峰 ^[9]。

一套系统可能显示 900 ms 的平均值，却仍然出现 p99 超过 8 秒的尖峰 ^[7]。而对于语音助手或实时字幕这类产品，人们注意到的正是那段尾部延迟。短暂的停顿感觉无关紧要，8 秒的卡顿则感觉像坏掉了。对语音类智能体，把 Time to First Token（TTFT）目标定在 600 ms 以下 ^[12]，并设定针对具体模态的 SLO。例如：

• 30 秒音频片段的 p95 在 2 秒以内

• 30 分钟音频文件的 p95 在 10 秒以内 ^[7]

在生产环境里，测量完整的请求路径，而不只是模型推理。记录每一个阶段：媒体上传、预处理、提示装配、网络传输、后处理和校验。如果延迟突然跳升，你需要看清延迟到底来自模型本身，还是来自上游某个环节，比如转码步骤。

在上线前测试流量突发也很有帮助。以你预期峰值负载的 2 倍和 5 倍做基准测试，在问题冲击生产之前抓出吞吐量下滑和超时尖峰 ^[13]。

如果速度扛得住，下一个问题就是系统在规模下能否保持可靠与高效。

3. 可扩展性、可靠性与资源效率

一个模型单独看可能很快，一旦流量涌入却会分崩离析。可扩展性意味着在流量尖峰期间保持稳定的吞吐量。可靠性意味着在输入变得杂乱、嘈杂或偏离模型此前所见时仍能稳定输出。资源效率意味着在做到这两点的同时，不为了没意义的事情烧掉金钱或算力。这就是实验室测试和生产测试之间的巨大区别。

一旦你知道系统能撑住规模，成本就成了下一个限制。而这正是团队常常翻车的地方。单看 API 价格并不能告诉你在生产环境里实际要付多少钱。真正的公式更像这样：

预估成本 = 输入成本 + 输出成本 + 模态处理成本 + 重试成本 + 审核成本 + 编排成本 ^[13]

所以别停在 token 定价上。要测量每个成功任务的总成本，把重试、审核和编排都算进去。多模态请求可能带来大量额外的 token 和载荷开销，这意味着效率远不止模型的标价那么简单。 ^[13][2]

在可靠性方面，追踪错误率，但别到此为止。你还想要在嘈杂或偏移输入下的校准度和鲁棒性。**预期校准误差（ECE）**检查模型的置信度是否与它答对的频率相符。如果一个模型说自己有 70% 的把握，那它应该有大约 70% 的时候是对的。**相对鲁棒性（RRM）**可按 $(\text{acc}{\text{corrupted}} - \text{acc}{\text{random}}) / (\text{acc}{\text{clean}} - \text{acc}{\text{random}})$ 计算 ^[18]。这些指标在医疗文档理解或金融开票这类高风险场景中至关重要，因为一个听起来顺滑的错误答案可能造成实实在在的伤害。 ^[17][6]

在效率一侧，让路由逻辑保持简单。把简单请求送给更小的模型。当细节无关紧要时，降低图像分辨率或减少视频抽帧。 ^[16][13] 而对于视频索引这类重任务，把同步和异步路径拆开。这样大型作业就不会堵塞交互式的用户流程。

一个简单的检查是空图丢弃测试：移除图像，测量准确率下降了多少。如果性能几乎没变，那么视觉输入可能配不上它所消耗的处理成本。 ^[6] 在规模和效率之后，下一步是看看当输入变得潦草、奇怪或公然对抗时会发生什么。

4. 跨模态的鲁棒性与安全性

一旦速度和规模都处于良好状态，下一步很简单：检查当情况变得杂乱时，模型是否仍然遵循输入。

鲁棒性意味着模型能在嘈杂、古怪或杂乱的输入下继续工作。安全性意味着它避免产生有害、误导或缺乏接地的输出。在多模态 AI 中，这两点都比纯文本系统更难，因为每种模态都可能以自己独有的方式失败。

失败模式在不同输入之间并不相同。图像可能引发文字叠加或空间上的错误。音频可能藏着提示注入。视频可能打乱时序。 ^[10] 而最坏的情况并不是崩溃或明显的失误，而是一个顺滑、自信、却悄悄忽视了输入的答案。

这可不是小问题。开源 VLM 的平均幻觉率高达 38%，而经过微调的商用模型已把这个数字压到约 12%。 ^[8]

"多模态领域最令人不安的发现，并不是模型有时会失败。而是它们可以在几乎完全没用上视觉输入的情况下，看起来像是在正常工作。" - Conor Bronsdon, Head of Developer Awareness, Galileo ^[6]

在评估时，别止步于单纯的准确率。你需要那些能在接地崩坏时显现出来的指标。

• 用 CHAIR 衡量描述中的幻觉。

• 用 POPE 测试是/否类的接地错误。

• 通过对比正确匹配的图像-问题对与错配对的结果，追踪一个视觉依赖分数。如果差距很小，模型可能对视觉证据关注甚少。 ^[8][18][6]

在安全一侧，密切关注跨模态提示注入和 PII 泄露，尤其是在医疗和金融这类受监管的领域。在输入端追踪模糊、歧义和提示注入的标记，然后在交付前对输出做过滤。对于被标记的高风险案例，采用人工复核。 ^[6][2][4]

5. 跨模态一致性与对齐

在鲁棒性之后，下一个要检查的是各模态是否仍然指向同一个含义。

跨模态一致性问的是一个简单问题：如果你通过文本、图像、音频或视频给出同一个意图，系统是否会给出同一个答案？对齐问的则是那些模态是否连接到相同的概念 ^[19][1][15]。如果同一个请求在文本、音频或视觉之间导出不同的答案，信任就会很快开始瓦解 ^[15][19]。

究其核心，各种用例下的失败模式基本相同：AI 模型必须在不同模态间以相同的方式为同一个概念接地 ^[2]。

使用与输出类型相匹配的指标，但把关注点始终放在跨模态一致性上：

单一分数说明不了什么。按模态对拆分结果，这样你才能看清文本、图像、音频或视频从哪里开始漂移 ^[8]。

生产数据在这里也很有帮助。留意用户的编辑和拒绝。这些信号往往能抓住那些正式指标漏掉的对齐问题 ^[2]。

一个多模态 LLM 评判者可以很好地评价对齐，但有取舍：更多的延迟和更多的成本 ^[2]。对于日常监控，简单的检查通常就够用了。把基于评判者的打分留给高风险请求 ^[2]。

一旦输出保持对齐，下一步就是看它们在真实交互中如何表现。

6. 用户体验与交互质量

一旦输出在各模态间保持同步，用户体验指标会告诉你这份同步在真实用户面前是否站得住。这里的主要问题是_评估落差_：输出听起来顺滑，却没有处理输入。这些指标显示的是对齐在与真实用户接触后能否存活，而不只是在整洁的基准提示前的表现。

用户接受率——用户不加编辑或拒绝就采纳 AI 输出的频率——是最清晰的生产信号之一 ^[2]。它能捕捉到基准测试可能完全漏掉的质量问题。把空图丢弃仅作为一项面向用户的检查，用来确认接受来自真实的接地，而非纯文本的猜测。

对于语音和媒体任务，基于感知的指标和接受率同样重要。**平均意见得分（MOS）**采用 1–5 分制，衡量音频和视频工作流中感知到的自然度。对于文档密集或指令跟随类的任务，匹配率（MR）——即遵守格式与约束规则的输出所占的比例——显示模型对用户意图的遵从有多可靠 ^[18]。

下面这张表把最有用的用户体验子指标映射到它们衡量什么以及为什么重要：

在规模化条件下，对每个请求都跑一遍完整的多模态评判者并不现实。更好的办法是自适应采样：只在有代表性的一部分流量上运行昂贵的多模态评判者，这样用户体验监控才能持续可行 ^[6][7]。然后把被标记的输出送去人工复核。

在用户体验之后，成本决定了这份体验能否在规模下撑住。

7. 成本、定价与用量遥测

一旦用户体验状态良好，成本就决定了你能否在规模下保住那份质量。这就是成本在任何模型评审中都占据核心位置的原因。而在多模态系统里，这道算术会很快变得更复杂，因为文本、图像、音频和视频各有各的定价模式。

按模态追踪成本：每张图像、每分钟音频、每段视频片段。而且别只停在推理本身。你还需要把预处理、存储、日志、脱敏、带宽、重试和审核都算进去 ^[20][14]。

往往能左右生产决策的那个指标是每个成功任务的成本：

(Total Model Spend + Orchestration Cost + Retry Overhead) / Successful Completions ^[5][13]

这一点很重要，因为一个模型按单次调用来看可能很便宜，一旦重试和人工复核开始堆积，它照样会变贵 ^[9][20]。视频往往是这一点冲击最狠的地方。大产物的存储、渲染和带宽会在转眼间累积起来 ^[14]。APIMart 支持视频、图像和语言模型，所以把每秒视频输出的成本与文本 token 成本分开追踪会很有帮助。这样的拆分能让你对钱花到哪里去了看得清楚得多。

用量遥测能帮你在预算漂移出现在月度账单之前就发现它。说白了，遥测把成本从一条会计科目变成了你可以日常管理的东西。以下是主要信号和成本驱动因素按模态的分解：

留意提示长度、图像分辨率或重试率的突然跳升。即便性能数字看起来稳定，这些变化也能让开销快速上涨 ^[20]。要压低每个成功任务的成本，可采用分层推理、降采样图像分辨率、减少视频抽帧，以及裁掉对任务无益的上下文 ^[16][13]。

指标快速对比表

在设定阈值之前，用下面这张表把七项指标并排比较。每一行都概括了上文讲过的一项指标。

如何在实践中应用这些指标

团队犯的最大错误就是用单一指标去评判一个模型。这几乎总会导致糟糕的决策。

本文中的七项指标——质量、速度、规模、安全、对齐、用户体验和成本——放在一起才最有用。最难、也最要紧的部分，是它们之间的取舍。决策正是在那里做出的。你的下一步是把这些指标转化成清晰的阈值和权重。

先在你跑第一个基准测试_之前_就设定好你的服务级别目标（SLO）。为每种工作负载定义延迟阈值，并用每个成功任务的成本而不是标价来归一化预算 ^[9][5]。

然后搭建一张加权记分卡，把每个指标和你需要完成的工作挂钩。一个呼叫中心应该把最大的权重放在转写准确率和延迟上。一个设计工作室则应该更在意图像保真度和提示遵从度。

有三个取舍值得密切关注：

• 准确率

• 延迟

• 成本

在交互式工作流中，准确率上的小幅提升通常不值得在延迟或成本上付出大代价 ^[3]。而如果你为了削减延迟而削弱安全过滤，那份风险不会保持很小——它会在规模下增长 ^[8]。

每次模型更新后，重跑同一套冻结的测试集。模型版本变动频繁，一次有助于准确率的更新可能悄悄损害延迟或安全。设定一个每月重新基准测试的节奏。APIMart 可以把跨文本、图像和视频模型的重跑集中起来。

结论

这七项指标——任务准确率、延迟、可扩展性、安全性、跨模态对齐、用户体验和成本——覆盖了多模态评估中的主要取舍。当你把它们放在一起看时，模型选择就变成一个清晰得多的生产决策。而最要紧的那些指标，会取决于你的业务需要完成什么。

在你挑选模型之前，先搭建一套可重复的评估框架。为安全、接地、延迟和每个成功任务的成本设定最低阈值 ^[5]。然后在每次模型更新后再跑一遍同一套测试集。

这一点比看上去更重要。一个模型可能在基准上表现强劲，却仍然超出你的延迟预算，或在规模下通不过安全检查。如果真发生了，那它就不合适——无论纸面上看起来多好。

对于医疗或金融等受监管领域的美国团队，这套框架还需要把 PII 泄露风险和关键决策点上的人工复核考虑进去。

目标不是把每一项指标都拉满，而是找到那个能通过你的质量门槛、契合你的工作负载、并保持在预算之内的模型——然后密切盯着它，好让你在用户之前先发现漂移。 APIMart 可以把跨文本、图像和视频模型的评估集中起来。

常见问题

::: faq

我该如何为这七项指标排优先级？

先定义你的产品任务和接受阈值，而不是依赖通用基准。在挑选模型之前，把每一项真实世界的工作和清晰的成功标准挂钩，比如延迟上限或准确率要求。

然后分层评估。先检查输入理解和接地。之后，在生产负载下测量成本和延迟。

对于高流量任务，使用快速的自动化检查。对于高价值或含糊的情况，加入有针对性的人工复核或 LLM-as-a-judge 验证。 :::

::: faq

我的第一张评估记分卡应该包含什么？

你的第一张评估记分卡应该聚焦于任务专属指标，而不是通用基准。从确切的用例开始，比如文档提取或图像问答。

包含：

• 每种模态的准确率和质量

• 诸如 p50/p95 延迟和总成本之类的运营指标

• 用来确认模型确实在使用输入媒体的依赖度检查

• 用嘈杂、边缘和对抗样本做的鲁棒性与安全性

:::

::: faq

我应该多久重新测试一次多模态模型？

只要提示、预处理或基础模型版本发生变化，就重新测试你的多模态模型。这有助于让结果保持可重复。

多模态系统可能以纯文本检查抓不到的方式崩坏。所以别停在静态测试上。先在固定数据集上跑离线基准，然后用受约束的影子部署或金丝雀工作负载来验证线上的延迟和吞吐量。APIMart 可以帮助你在各种多模态工作流中保持评估的一致性。 :::