7 главных метрик для оценки мультимодального ИИ

Если бы мне пришлось свести всё к одной мысли, она звучала бы так: я бы никогда не судил о мультимодальной системе ИИ только по точности. Модель может показать хороший результат и всё равно провалиться по задержке, обоснованности, безопасности или стоимости успешно выполненной задачи. И эти промахи быстро проявляются в продакшене.

Вот краткая версия:

• Я бы проверял 7 метрик вместе: качество, задержку, масштаб, безопасность, согласование, UX и стоимость

• Я бы отслеживал хвостовую задержку, а не только средние значения, потому что среднее в 900 мс всё равно может скрывать задержки p99 более 8 секунд

• Я бы измерял галлюцинации и опору на изображение, потому что некоторые модели звучат правдоподобно, почти не используя картинку

• Я бы использовал стоимость успешно выполненной задачи, а не цену за вызов, поскольку повторы, модерация и хранение могут быстро поднять расходы

• Я бы перезапускал замороженный набор из 100–500 живых примеров после каждого обновления модели, чтобы рано выявлять дрейф

Для меня суть проста: лучшая мультимодальная модель — это не та, у которой топовый балл на бенчмарке. Это та, которая остаётся точной, обоснованной, достаточно быстрой для пользователей, безопасной при «грязном» вводе и укладывается в бюджет в долларах США ($).

Оценка мультимодальных LLM: лучшие приёмы и типичные ошибки

Быстрое сравнение

Если бы я настраивал оценку сегодня, 6 июля 2026 года, я бы относился к этим семи проверкам как к одной оценочной карте, а не к семи отдельным отчётам.

Почему мультимодальной оценке нужна не одна метрика

Один балл не скажет вам, выдержит ли мультимодальная система продакшен.

Модель может показать сильный результат и при этом быть слишком медленной для использования. Или она может звучать гладко и отполировано, упуская то, что на самом деле изображено на картинке. В этом и ловушка: одно число может скрыть именно тот тип сбоя, который позже вызовет проблемы.

Слабые места тоже меняются от задачи к задаче. Модель для счетов может правильно читать текст, но упускать разметку и затем вытащить неверную итоговую сумму. Голосовой ассистент может транскрибировать слова с высокой точностью, но всё равно упустить тон. Это очень разные ошибки, и именно поэтому оценку нужно разбивать на отдельные метрики, а не втискивать всё в один балл.

«Оценка мультимодальных систем требует смены парадигмы. Метрики оценки только для текста, такие как BLEU или accuracy, недостаточны… оценка мультимодальных систем требует метрик, чувствительных к согласованию между модальностями, а не только к производительности внутри каждой модальности по отдельности.» — eval.qa ^[8]

Есть и сторона затрат. Лучшая обоснованность может поднять цену за инференс, поэтому контроль затрат должен быть частью оценки с самого начала, а не тем, на что вы смотрите уже после развёртывания. Если модель точна, но слишком дорога, в продакшене она всё равно проваливается.

Семь метрик ниже покрывают эти проверки.

1. Точность задачи и оценки качества

Начните с качества под конкретную задачу. Мультимодальная модель может выглядеть сильной на бумаге и всё равно буксовать на том единственном типе вывода, который вам важен.

Таблица ниже сопоставляет распространённые мультимодальные задачи с основными метриками их оценки, чтобы вы могли подобрать измерение под работу:

Агрегированные оценки могут замазывать слабые места. Например, модель Visual Question Answering (VQA) может набрать 95% на простых вопросах о цвете, а затем упасть до 40% на более сложных задачах на рассуждение. Это огромный разрыв. Поэтому прежде чем доверять итоговому числу, разбивайте точность по типам вопросов.

Топовые оценки VQAv2 теперь превышают 85%, а значит бенчмарк стал меньше разделителем и больше базовой проверкой ^[3].

Отслеживайте галлюцинации отдельно. У открытых VLM в среднем 38%, тогда как ведущие модели около 12% ^[8]. Метрика CHAIR (Caption Hallucination Assessment with Image Relevance) измеряет это напрямую. Во многих продакшен-сценариях хорошей целью является значение ниже 0.15 ^[8].

Для мониторинга в продакшене держите замороженный внутренний набор из 100–500 реальных примеров и перезапускайте его по регулярному расписанию. Это один из простейших способов заметить дрейф качества раньше, чем он превратится в проблему для пользователя.

Как только качество перешагнёт планку, следующий шаг — проверить, может ли модель выдавать это качество достаточно быстро для продакшена.

2. Задержка, время отклика и пропускная способность

Задержка — это время до первого полезного вывода. Время отклика — полное сквозное ожидание, которое переживает пользователь. Пропускная способность — сколько запросов или токенов система может обработать в секунду.

С мультимодальными системами эти числа могут меняться быстро.

Изображение 1024×1024 может использовать около 1 500 промпт-токенов, а prefill изображения может стоить в 15–30 раз дороже, чем стандартный текстовый запрос ^[11]. Видео ещё тяжелее. 10-минутный клип, сэмплированный с частотой 1 кадр в секунду, может использовать около 153 600 токенов ^[11]. Во многих случаях замедление начинается до инференса. Изменение размера, транскодирование и извлечение кадров часто становятся главным узким местом.

Вот почему средние значения не рассказывают всю историю. Измеряйте задержку в перцентилях, а не в средних, потому что средние могут скрывать неприятные хвостовые всплески ^[9].

Система может показывать среднее в 900 мс и при этом иметь всплески p99 выше 8 секунд ^[7]. И для продуктов вроде голосовых ассистентов или живых субтитров именно эту хвостовую задержку люди замечают. Короткая пауза кажется мелочью. 8-секундное зависание кажется поломкой. Стремитесь к Time to First Token (TTFT) ниже 600 мс для голосовых агентов ^[12] и задавайте SLO для каждой модальности. Например:

• p95 ниже 2 секунд для 30-секундных аудиоклипов

• p95 ниже 10 секунд для 30-минутных аудиофайлов ^[7]

В продакшене измеряйте весь путь запроса, а не только инференс модели. Логируйте каждый этап: загрузку медиа, предобработку, сборку промпта, сетевой транзит, постобработку и валидацию. Если задержка подскакивает, вам нужно видеть, пришла ли задержка от самой модели или от чего-то выше по конвейеру, например от шага транскодирования.

Также полезно тестировать всплески трафика перед запуском. Проводите бенчмарк при 2x и 5x ожидаемой пиковой нагрузки, чтобы поймать провалы пропускной способности и всплески таймаутов до того, как они попадут в продакшен ^[13].

Если скорость держится, следующий вопрос — остаётся ли система надёжной и эффективной при масштабе.

3. Масштабируемость, надёжность и эффективность ресурсов

Модель может выглядеть быстрой сама по себе и всё равно развалиться, когда придёт трафик. Масштабируемость означает стабильную пропускную способность при всплесках трафика. Надёжность означает стабильный вывод, когда входы становятся грязными, зашумлёнными или отклоняются от того, что модель видела раньше. Эффективность ресурсов означает делать и то и другое без сжигания денег или вычислений впустую. В этом большая разница между лабораторным тестом и продакшен-тестом.

Как только вы знаете, что система выдерживает масштаб, следующим ограничением становится стоимость. И именно здесь команды часто спотыкаются. Одна лишь цена API не скажет вам, сколько вы заплатите в продакшене. Реальная формула выглядит скорее так:

Оценочная стоимость = стоимость входа + стоимость выхода + стоимость обработки модальности + стоимость повторов + стоимость модерации + стоимость оркестрации ^[13]

Так что не останавливайтесь на цене за токены. Измеряйте полную стоимость успешно выполненной задачи, включая повторы, модерацию и оркестрацию. Мультимодальные запросы могут добавлять много накладных расходов на токены и полезную нагрузку, а значит эффективность — это больше, чем ценник модели. ^[13][2]

Для надёжности отслеживайте частоту ошибок, но не останавливайтесь на этом. Вам также нужна калибровка и устойчивость при зашумлённых или смещённых входах. Expected Calibration Error (ECE) проверяет, соответствует ли уверенность модели тому, как часто она права. Если модель говорит, что уверена на 70%, она должна быть права примерно в 70% случаев. Relative Robustness (RRM) можно вычислить как $(\text{acc}{\text{corrupted}} - \text{acc}{\text{random}}) / (\text{acc}{\text{clean}} - \text{acc}{\text{random}})$ ^[18]. Эти метрики очень важны в областях с высокими ставками, таких как понимание медицинских документов или финансовое выставление счетов, где гладко звучащий неверный ответ может причинить реальный вред. ^[17][6]

Со стороны эффективности держите логику маршрутизации простой. Отправляйте лёгкие запросы к меньшим моделям. Понижайте разрешение изображения или сэмплируйте меньше кадров видео, когда мелкие детали не важны. ^[16][13] А для тяжёлых задач вроде индексации видео разделяйте синхронные и асинхронные пути. Так крупные задания не забивают интерактивные пользовательские потоки.

Одна простая проверка — тест с удалением (blank-drop): уберите изображение и измерьте, насколько упадёт точность. Если производительность почти не меняется, визуальный вход, возможно, не оправдывает стоимость своей обработки. ^[6] После масштаба и эффективности следующий шаг — посмотреть, что происходит, когда входы становятся неряшливыми, странными или откровенно враждебными.

4. Устойчивость и безопасность по модальностям

Как только скорость и масштаб в хорошем состоянии, следующий шаг прост: проверить, продолжает ли модель следовать входу, когда всё становится грязным.

Устойчивость означает, что модель может продолжать работать при зашумлённых, странных или грязных входах. Безопасность означает, что она избегает вредного, вводящего в заблуждение или необоснованного вывода. В мультимодальном ИИ и то и другое сложнее, чем в системах только для текста, потому что каждая модальность может отказать по-своему.

Паттерны сбоев не одинаковы для разных входов. Изображения могут вызывать ошибки с наложением текста или пространственные. Аудио может скрывать prompt injection. Видео может перепутать временной порядок. ^[10] И худший сценарий — не сбой и не явный промах. Это гладкий, уверенный ответ, который тихо игнорирует вход.

Это не мелкая проблема. Открытые VLM галлюцинируют в среднем на уровне 38%, тогда как дообученные коммерческие модели снизили это до примерно 12%. ^[8]

«Самый тревожный мультимодальный вывод не в том, что модели иногда ошибаются. А в том, что они могут казаться работающими, почти не используя визуальный вход вообще.» — Conor Bronsdon, Head of Developer Awareness, Galileo ^[6]

Для оценки не останавливайтесь на простой точности. Вам нужны метрики, которые показывают, когда ломается обоснованность.

• Используйте CHAIR для измерения галлюцинаций в подписях.

• Используйте POPE для проверки ошибок обоснованности типа да/нет.

• Отслеживайте Visual Reliance Score, сравнивая результаты на корректно сопоставленных парах изображение-вопрос с несоответствующими парами. Если разрыв мал, модель, возможно, уделяет мало внимания визуальному доказательству. ^[8][18][6]

Со стороны безопасности внимательно следите за кросс-модальными prompt injection и раскрытием PII, особенно в регулируемых областях вроде здравоохранения и финансов. Отслеживайте размытие, неоднозначность и флаги prompt injection на входе. Затем фильтруйте выводы перед доставкой. Для флагованных случаев с высокими ставками используйте проверку человеком. ^[6][2][4]

5. Кросс-модальная согласованность и выравнивание

После устойчивости следующее, что нужно проверить, — указывают ли модальности всё ещё на один и тот же смысл.

Кросс-модальная согласованность задаёт простой вопрос: если вы передаёте одно и то же намерение через текст, изображение, аудио или видео, даёт ли система один и тот же ответ? Выравнивание спрашивает, связаны ли эти модальности с одними и теми же понятиями ^[19][1][15]. Если один запрос ведёт к разным ответам по тексту, аудио или зрению, доверие начинает быстро рушиться ^[15][19].

По сути паттерн сбоя примерно одинаков во всех сценариях: модель ИИ должна привязывать одно понятие одинаково во всех модальностях ^[2].

Используйте метрики, подходящие под тип вывода, но держите фокус на кросс-модальном согласии:

Один балл сам по себе мало что скажет. Разбивайте результаты по парам модальностей, чтобы видеть, где текст, изображение, аудио или видео начинают расходиться ^[8].

Продакшен-данные тоже помогают. Следите за правками и отклонениями пользователей. Эти сигналы часто ловят проблемы согласования, которые формальные метрики упускают ^[2].

Мультимодальный LLM-судья может хорошо оценивать согласование, но есть компромисс: больше задержки и больше затрат ^[2]. Для повседневного мониторинга простых проверок обычно достаточно. Оценку на основе судьи приберегите для запросов с высоким риском ^[2].

Как только выводы остаются согласованными, следующий шаг — посмотреть, как они держатся в реальном взаимодействии.

6. Пользовательский опыт и качество взаимодействия

Как только выводы остаются синхронными по модальностям, метрики UX говорят, держится ли это с реальными пользователями. Главная проблема здесь — eval gap: вывод, который звучит гладко, но не работает со входом. Эти метрики показывают, переживает ли согласование контакт с реальными пользователями, а не только с аккуратными промптами бенчмарка.

User acceptance rate — как часто пользователи принимают вывод ИИ без правок или отклонения — один из самых ясных продакшен-сигналов ^[2]. Он ловит проблемы качества, которые бенчмарки могут полностью упустить. Используйте Blank Drop только как проверку со стороны пользователя, чтобы подтвердить, что принятие исходит из реальной обоснованности, а не из угадывания по одному тексту.

Для голосовых и медиа-задач метрики на основе восприятия важны не меньше, чем частота принятия. Mean Opinion Score (MOS) по шкале 1–5 измеряет воспринимаемую естественность для аудио- и видеопроцессов. Для задач с большим объёмом документов или следованием инструкциям Match Ratio (MR) — доля выводов, следующих правилам формата и ограничениям, — показывает, насколько надёжно модель уважает намерение пользователя ^[18].

Таблица ниже сопоставляет самые полезные суб-метрики UX с тем, что они измеряют и почему это важно:

Запускать полного мультимодального судью на каждый запрос непрактично при масштабе. Лучшее решение — адаптивное сэмплирование: запускайте дорогих мультимодальных судей на репрезентативной выборке трафика, чтобы мониторинг UX оставался рабочим ^[6][7]. Затем отправляйте флагованные выводы на проверку человеком.

После UX стоимость определяет, сможет ли опыт удержаться при масштабе.

7. Стоимость, ценообразование и телеметрия использования

Как только пользовательский опыт в хорошей форме, стоимость решает, сможете ли вы удержать это качество при масштабе. Вот почему стоимость находится близко к центру любого обзора модели. А с мультимодальными системами математика быстро усложняется, потому что текст, изображение, аудио и видео у каждого свои паттерны ценообразования.

Отслеживайте стоимость по модальностям: за изображение, за минуту аудио и за видеоклип. И не останавливайтесь только на инференсе. Нужно также учитывать предобработку, хранение, логирование, редактирование, пропускную способность, повторы и модерацию ^[20][14].

Метрика, которая обычно формирует продакшен-решения, — стоимость успешно выполненной задачи:

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

Это важно, потому что модель может выглядеть дешёвой в расчёте за вызов и всё равно стать дорогой, как только начнут накапливаться повторы и проверка человеком ^[9][20]. Видео — то, где это часто бьёт сильнее всего. Хранение, рендеринг и пропускная способность для крупных артефактов могут быстро накопиться ^[14]. APIMart поддерживает видео-, изображенческие и языковые модели, поэтому полезно отслеживать стоимость за секунду видеовывода отдельно от затрат на текстовые токены. Это разделение даёт вам куда более ясное представление о том, куда уходят деньги.

Телеметрия использования помогает заметить дрейф бюджета до того, как он появится в месячном счёте. Проще говоря, телеметрия превращает стоимость из строки в бухгалтерии в нечто, чем вы можете управлять изо дня в день. Вот как основные сигналы и драйверы затрат разбиваются по модальностям:

Следите за внезапными скачками длины промпта, разрешения изображения или частоты повторов. Эти сдвиги могут быстро поднять расходы, даже когда показатели производительности выглядят стабильными ^[20]. Чтобы снизить стоимость успешно выполненной задачи, используйте многоуровневый инференс, понижайте разрешение изображений, сэмплируйте меньше кадров видео и обрезайте контекст, который не помогает задаче ^[16][13].

Быстрая сравнительная таблица метрик

Используйте таблицу ниже, чтобы сравнить семь метрик бок о бок перед установкой порогов. Каждая строка суммирует одну из рассмотренных выше метрик.

Как применять эти метрики на практике

Самая большая ошибка команд — судить о модели по одной метрике. Это почти всегда ведёт к плохим решениям.

Семь метрик из этой статьи — качество, скорость, масштаб, безопасность, согласование, UX и стоимость — работают лучше всего вместе. Сложная часть, и та, что важнее всего, — компромисс между ними. Именно там принимаются решения. Ваш следующий шаг — превратить эти метрики в чёткие пороги и веса.

Начните с установки ваших Service Level Objectives (SLO) прежде чем запустить хотя бы один бенчмарк. Определите пороги задержки для каждой нагрузки и нормализуйте бюджет через стоимость успешно выполненной задачи вместо цены с ценника ^[9][5].

Затем постройте взвешенную оценочную карту, которая связывает каждую метрику с той работой, что вам нужна. Колл-центр должен придавать наибольший вес точности транскрипции и задержке. Дизайн-студии стоит больше заботиться о верности изображений и следовании промпту.

Есть три компромисса, за которыми стоит внимательно следить:

• Точность

• Задержка

• Стоимость

В интерактивных процессах небольшой прирост точности обычно не стоит больших потерь в задержке или стоимости ^[3]. А если вы ослабляете фильтры безопасности, чтобы срезать задержку, этот риск не остаётся маленьким — он растёт при масштабе ^[8].

После каждого обновления модели перезапускайте тот же замороженный тестовый набор. Версии моделей меняются часто, и обновление, помогающее точности, может тихо навредить задержке или безопасности. Установите месячный ритм ре-бенчмаркинга. APIMart может централизовать перезапуски по текстовым, изображенческим и видеомоделям.

Заключение

Эти семь метрик — точность задачи, задержка, масштабируемость, безопасность, кросс-модальное согласование, пользовательский опыт и стоимость — покрывают основные компромиссы в мультимодальной оценке. Когда вы смотрите на них вместе, выбор модели становится куда более ясным продакшен-решением. А то, какие метрики важнее всего, зависит от того, что нужно делать вашему бизнесу.

Прежде чем выбрать модель, постройте повторяемый фреймворк оценки. Установите минимальные пороги для безопасности, обоснованности, задержки и стоимости успешно выполненной задачи ^[5]. Затем запускайте тот же тестовый набор снова после каждого обновления модели.

Эта часть важнее, чем может показаться. Модель может выглядеть сильной на бенчмарке и всё равно промахнуться по вашему бюджету задержки или провалить проверки безопасности при масштабе. Если так происходит, она не подходит, как бы хорошо ни выглядела на бумаге.

Для команд из США в регулируемых областях вроде здравоохранения или финансов фреймворк также должен учитывать риски раскрытия PII и проверку человеком в ключевых точках принятия решений.

Цель не в том, чтобы выжать максимум из каждой метрики. Она в том, чтобы найти модель, которая проходит ваши ворота качества, подходит под вашу нагрузку и укладывается в бюджет, — а затем внимательно за ней следить, чтобы вы могли поймать дрейф раньше пользователей. APIMart может централизовать оценку по текстовым, изображенческим и видеомоделям.

Часто задаваемые вопросы

::: faq

Как мне расставить приоритеты среди этих семи метрик?

Начните с определения задач вашего продукта и порогов приёмки вместо опоры на общие бенчмарки. Привяжите каждую реальную работу к чётким критериям успеха, вроде лимитов задержки или требований к точности, прежде чем выбирать модель.

Затем оценивайте слоями. Сначала проверьте понимание входа и обоснованность. После этого измерьте стоимость и задержку под продакшен-нагрузкой.

Для высокообъёмных задач используйте быстрые автоматические проверки. Для ценных или неоднозначных случаев добавьте точечную проверку человеком или валидацию LLM-as-a-judge. :::

::: faq

Что должна включать моя первая оценочная карта?

Ваша первая оценочная карта должна фокусироваться на метриках под конкретную задачу, а не на общих бенчмарках. Начните с точного сценария использования, вроде извлечения из документов или ответов на вопросы по изображению.

Включите:

• Точность и качество для каждой модальности

• Операционные метрики, такие как задержка p50/p95 и полная стоимость

• Проверки зависимости, чтобы подтвердить, что модель использует входное медиа

• Устойчивость и безопасность с зашумлёнными, краевыми и враждебными примерами :::

::: faq

Как часто мне стоит перетестировать мультимодальную модель?

Перетестируйте мультимодальную модель всякий раз, когда меняются промпты, предобработка или версия базовой модели. Это помогает сохранять повторяемость результатов.

Мультимодальные системы могут ломаться так, как проверки только для текста не поймают. Поэтому не останавливайтесь на статических тестах. Запускайте офлайн-бенчмарки на фиксированных датасетах, затем используйте ограниченные теневые развёртывания или canary-нагрузки, чтобы проверить живую задержку и пропускную способность. APIMart может помочь поддерживать согласованность оценки по мультимодальным процессам. :::