Стенды оценки ИИ-функций видео – LLM-as-judge

Кратко

Стенд оценки (eval rig) – это испытательная установка для ИИ-функции, результат которой нельзя проверить простым знаком равенства: видео-резюме, сгенерированный клип, решение модерации. В 2026 году его главный «оценщик» – это LLM-as-judge: сильная модель, которая ставит выходу оценку по написанному критерию (рубрике), а не сверяет его с одним эталонным ответом. Старые метрики (счёт совпадающих слов вроде BLEU и ROUGE или обычная точность) хвалят выход, копирующий эталон, и наказывают тот, что говорит то же самое другими словами, – поэтому они слепнут ровно там, где живёт видео-ИИ: открытый язык о движущихся картинках. Для видео судье обычно нужно ещё и видеть кадры – это делает его VLM-as-judge (модель со зрением, читающая выборку кадров вместе с оцениваемым текстом), и только такой судья ловит гладкое резюме, описывающее сцену, которой не было; этот урок показывает, как собрать такой стенд – golden set, рубрику, режим оценки, контроль смещений и проверку «а судьи кто», доказывающую, что оценщик согласен с людьми, прежде чем доверить ему блокировать релиз.

Почему это важно

Если в продукте есть ИИ-функция, которая пишет, описывает, решает или генерирует – авто-резюме записей, субтитры, решение модерации, сгенерированный b-roll, ответ о видео, – вы не определите на глаз, стало ли лучше или хуже после изменения, потому что единственного «правильного ответа» для сравнения нет. Без стенда, который оценивает качество автоматически и воспроизводимо, каждая замена модели и правка промпта – это догадка, а «на демо выглядело нормально» становится критерием релиза. Этот урок написан для продакт-менеджера, основателя или техлида, которому надо решить, достаточно ли хороша видео-ИИ функция, чтобы выпустить её и продолжать выпускать после следующего обновления модели. Собирать стенд самому не обязательно, но знать, что содержит надёжный стенд, что делает судью достоверным или предвзятым и какие вопросы выводят на чистую воду подрядчика, пропустившего эту работу, – нужно. Это глубокая, заточенная под видео сборка, которую обзор AgentOps лишь наметил: столп оценки, разобранный и собранный заново для движущихся картинок.

Что такое стенд оценки – и почему «просто проверить выход» не работает

Начнём с предмета испытаний. Видео-ИИ функция – это любая часть продукта, где модель превращает видео или вопрос о видео в результат, который человек читает или смотрит: резюме двухчасового вебинара в один абзац, дорожку субтитров, решение «можно ли публиковать этот клип», ответ на «когда спикер говорит о цене» или свежесгенерированный пятисекундный кадр. Именно такие функции чаще всего просят клиенты Фора Софт, и у них есть одно неудобное свойство – выход открытый. Единственного верного абзаца, резюмирующего вебинар, не существует. Есть тысячи хороших и тысячи плохих, и большинство плохих на первый взгляд выглядят ровно как хорошие.

Это свойство ломает привычный способ тестировать ПО. Обычный код проверяют утверждением (assertion) – строкой, говорящей «результат должен равняться этому точному значению», вроде 2 + 2 == 4. Совпало – тест пройден, не совпало – провален. Это работает, потому что обычные функции детерминированы, а их ответы точны. У функции-резюме нет ни того, ни другого: модель недетерминирована (одна и та же запись может дать разный, одинаково верный абзац при каждом запуске), а ответ – это суждение, а не значение. Утверждать, что резюме равно одному эталонному абзацу, значит провалить каждое хорошее резюме, выбравшее другие слова. Знак равенства тут – неподходящий инструмент.

Стенд оценки – это инструмент, который его заменяет. Слово «стенд» взято из испытаний техники, где испытательный стенд – это набор фиксированного оборудования, в который зажимают деталь, чтобы измерить, как она ведёт себя в известных условиях. Программный eval rig – то же самое для ИИ-функции: фиксированный набор тест-кейсов, способ прогнать функцию по всем, оценщик, ставящий балл каждому выходу, и отчёт, который можно сравнивать от прогона к прогону. Зажми функцию, нажми рычаг, посмотри на стрелку. Поменяй модель или промпт, нажми рычаг снова и смотри, выросла стрелка или упала. Без стенда у вас мнения; с ним – число, которое каждую неделю значит одно и то же.

Большую часть истории ПО оценщиком на этом стенде была метрика – формула, сравнивающая выход модели с написанным человеком эталоном и возвращающая балл сходства. Знаменитые для языка – это BLEU и ROUGE (аббревиатуры можно не расшифровывать; обе по сути считают, сколько слов и коротких фраз выход делит с эталоном) и, для систем поновее, BERTScore (сравнивает смыслы через эмбеддинги, а не точные слова). Эти рабочие лошадки два десятилетия тащили тестирование машинного перевода и резюмирования. Беда в том, что они измеряют: совпадение с одним конкретным эталоном. А совпадение – это ровно не то, что нужно мерить для открытого языка о видео.

Почему старые метрики слепнут на видео-ИИ

Представьте клип с велосипедистом. Ваша функция субтитров выдаёт: «Мужчина в красной куртке едет на велосипеде мимо фонтана». Человеческий эталон гласит: «Велосипедист в багряном пальто крутит педали у водного объекта». Эти два предложения означают одно и то же. Человек назвал бы субтитр верным. Но метрика счёта совпадающих слов видит почти нет общих слов – и ставит субтитру около нуля. Метрика наказала верный ответ за преступление – использование синонимов.

Посчитаем так, как считает метрика, чтобы провал был осязаем. Балл совпадения слов – это примерно доля слов выхода, которые есть и в эталоне. В субтитре девять значимых слов; число тех, что встречаются в эталоне дословно, – щедро говоря, одно. Это точность около 1 ÷ 9:

общие значимые слова ÷ значимые слова выхода = 1 ÷ 9 = 0,11

Балл 0,11 по шкале, где 1,0 – идеал, – за субтитр, который человек пропустил бы не глядя. Это не надуманный крайний случай; это норма для открытых выходов, поэтому в исследовательской литературе прямо сказано: традиционные метрики вроде BLEU, ROUGE и CIDEr ненадёжны для открытых ответов о видео, где допустимо много верных ответов, а в ответе часто есть лишние детали или цепочка рассуждений, которых в эталоне не было. Метрика уверенно измеряет не то.

Есть и второй, худший провал, который метрики совпадения слов даже не пытаются взять: заземление (grounding). Допустим, резюме клипа с камеры наблюдения гласит, гладко: «Курьер оставил посылку в 3:42 и уехал». Написано хорошо. Делит много слов с правдоподобным эталоном. И полностью выдумано – на клипе никакой доставки нет. Текстовая метрика, сравнивающая строки, узнать этого не может, потому что она никогда не смотрела видео. Чтобы поймать это, нужен оценщик, который умеет и судить язык, и смотреть кадры. Этот пробел и заполняет LLM-as-judge, а точнее – VLM-as-judge.

Нажмите, чтобы увеличить

LLM-as-judge – оценщик, читающий смысл

LLM-as-judge – это практика использования сильной языковой модели как оценщика на вашем стенде. Вместо посимвольного сравнения выхода функции с эталоном вы даёте сильной модели – «судье» – написанную рубрику (критерии хорошего ответа на простом языке), исходную задачу, выход функции и, по желанию, эталонный ответ для ориентира. Судья возвращает балл и короткую письменную критику с объяснением балла. Хрупкую формулу вы заменяете читателем, который понимает, что значит «хорошо».

Доверие к идее закрепило исследование 2023 года, где сильных LLM-судей столкнули с людьми на тысячах ответов моделей. Его заглавный результат – работа Zheng с коллегами на MT-Bench и Chatbot Arena – то самое число, которое сдвинуло всё поле: судья на базе GPT-4 совпадал с предпочтениями людей более чем в 80% случаев – это та же доля, с которой два человека согласны между собой. Иными словами, судья расходился с людьми примерно так же часто, как люди расходятся между собой. Эта планка превратила LLM-as-judge из диковинки в способ оценки открытых ИИ-выходов по умолчанию.

Как судье не быть расплывчатым? Сильнейший приём – заставить его думать до выставления балла. Метод G-Eval (Liu с коллегами, 2023) делает именно это: он просит судью сначала выписать шаги оценки по рубрике – что проверять и в каком порядке – и только потом заполнить балл; приём заимствован из «цепочки рассуждений» (chain-of-thought), где модель рассуждает шаг за шагом. На резюмировании G-Eval достиг наивысшего согласия с оценками людей среди всех автоматических методов того времени (корреляция Спирмена около 0,51, тогда как старые метрики были куда ниже). Урок для вашего стенда конкретен: судья, который объясняет рассуждение до того, как зафиксировать число, и точнее, и удобнее для отладки, чем тот, что выпаливает балл, – потому что можно прочитать, почему он так оценил, и поймать его на ошибке.

Каждого судью настраивают две практические ручки. Первая – рубрика: расплывчатые рубрики («оцени качество от 1 до 10») дают шумные, невоспроизводимые баллы, а конкретные («упомянуты ли все пункты повестки; нет ли выдумок сверх стенограммы; короче ли 120 слов») дают стабильные. Вторая – шкала: грубые шкалы (оценка 1–5 или «прошёл/не прошёл») согласуются с людьми куда лучше тонких (1–100), потому что ни люди, ни модели не отличают осмысленно 73 от 76. Правило большого пальца отсюда: пишите рубрику как чек-лист, а оценивайте по наименьшей шкале, всё ещё различающей хорошее и плохое.

VLM-as-judge – судья обязан смотреть видео

Вот где оценка видео расходится с оценкой текста и где большинство общих советов по оценке тихо отказывают. Обычный LLM-судья читает только текст. Если попросить его оценить резюме видео, он проверит, хорошо ли написано, внутренне ли непротиворечиво и по теме ли, – но не проверит, верно ли оно кадрам, потому что кадров он не видел. Он оценивает сочинение о фильме, который не смотрел. Для провалов заземления из прошлого раздела – выдуманной доставки, придуманного спикера – текстовый судья бесполезен.

Решение – VLM-as-judge: судья на базе vision-language model (VLM, модели «зрение + язык»), той самой, что разбирается в уроке про видео-VLM и принимает на вход изображения или кадры видео вместе с текстом. Вы даёте такому судье три вещи – рубрику, выход функции и выборку кадров из реального видео – и теперь он может то, чего не может текстовый судья: сверить описание с пикселями. Появилась ли на экране «красная куртка» из резюме? Была ли доставка в 3:42 или нет? Судья смотрит, потом оценивает. Заземление становится проверяемым.

Это активный фронт исследований, а не решённая задача, и ваш стенд должен относиться к нему с должной осторожностью. Система VideoJudge 2025 года построила небольших (на 3 и 7 миллиардов параметров) MLLM-судей, заточенных оценивать выходы по видео-пониманию, и сообщила, что её 7B-судья коррелировал с оценками людей сильнее, чем куда большие универсальные модели, – обойдя базовые 32B и 72B на трёх из четырёх мета-оценочных бенчмарков. Обнадёживающий сигнал: специализированный видео-судья может превзойти гигантского универсального и стоить в разы дешевле в работе. Предостерегающий сигнал – из родственной работы, прямо спрашивающей, надёжен ли видео-судья вообще, – в том, что VLM-судьи наследуют все смещения текстовых судей плюс новые: сколько кадров они увидели и что пропустили между выборками. VLM-судья – правильный инструмент для заземления видео; он не оракул, и остальная часть урока – о том, как держать его честным.

Нажмите, чтобы увеличить

Анатомия стенда оценки

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

Первая часть – golden set (золотой набор): отобранная коллекция представительных тест-кейсов с известными хорошими исходами, как банк экзаменационных вопросов с ключом ответов у учителя. Для функции-резюме каждый кейс – это реальная запись плюс одобренное человеком резюме (или ясная рубрика того, что хорошее резюме должно содержать). Golden set – самый ценный актив всего стенда, потому что это фиксированная почва, относительно которой меряют стрелку. Хороший набор достаточно мал, чтобы прогонять часто (десятки–сотни кейсов, не тысячи), и намеренно набит трудными, странными и состязательными случаями, которые ломают всё: немое видео, наложение двух спикеров, клип из почти пустого слайда.

Вторая часть – тестируемая функция: ваша реальная модель и промпт, прогнанные по каждому кейсу golden set ради выходов. Третья – судья: оценщик LLM или VLM со своей рубрикой, ставящий балл каждому выходу. Четвёртая – скоркарта (scorecard): сводный результат, не просто среднее, а разбивка – какие кейсы прошли, какие провалились и насколько надёжно, чтобы вы видели, где живёт и умирает качество, а не одно размытое число. Пятая – ворота (gate): правило, превращающее скоркарту в решение: заблокировать релиз, если среднее падает, если регрессирует любой критичный кейс или если доля галлюцинаций перешла порог.

Эти пять частей работают в двух разных местах, и разница важна. Офлайн-оценка прогоняет стенд по фиксированному golden set во время разработки и в релизном конвейере – это управляемые ворота качества до выпуска, ИИ-аналог запуска тестов перед слиянием кода. Онлайн-оценка прогоняет судью по выборке реального продакшен-трафика после запуска, ловя дрейф и странные реальные входы, которых не предусмотрел ни один golden set. Эти двое кормят друг друга: каждый интересный провал, пойманный онлайн, добавляется в офлайновый golden set, и стенд умнеет каждую неделю. Эта петля – продакшен-провалы становятся постоянными тест-кейсами – и отличает стенд, который ветшает, от того, что накапливает силу.

Нажмите, чтобы увеличить

Режимы оценки – pointwise, pairwise и без эталона

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

Первое решение – pointwise против pairwise. Pointwise-судья смотрит на один выход и ставит ему балл по рубрике – «это резюме: 4 из 5». Pairwise-судья смотрит на два выхода одной задачи и говорит, какой лучше – «резюме A бьёт резюме B». Парная оценка обычно надёжнее из двух, потому что «какой из этих лучше» – вопрос проще и устойчивее, чем «какого числа это стоит», и исследования мультимодальных судей это подтверждают: модели «зрение + язык» показывают сильное, человекоподобное согласие в парных сравнениях, но заметно шатаются, когда их просят об абсолютных баллах или ранжировании пачки. Компромисс – в цене и применении: pairwise идеален для выбора между двумя моделями-кандидатами или промптами (A/B-решение), а pointwise нужен для отслеживания качества одной функции во времени по фиксированной шкале. Многие стенды используют оба – pairwise, чтобы выбрать новую модель, pointwise, чтобы следить за ней потом.

Второе решение – с эталоном против без эталона. Судье с эталоном дают написанный человеком золотой ответ для сравнения; судья без эталона оценивает выход по рубрике и – для видео – только по кадрам, без всякого золотого ответа. Оценка с эталоном точнее, но дороже, ведь золотые ответы надо кому-то писать; оценка без эталона масштабируется на продакшен, где для живого трафика золотого ответа нет, ценой части точности. Практический паттерн: с эталоном – офлайн на golden set, где написанные ответы есть; без эталона – онлайн, где их нет.

Третье решение – шкала и форма рубрики, разобранные выше: грубые шкалы и рубрики-чек-листы бьют тонкие шкалы и расплывчатые формулировки. Соберём три решения в одно место:

А судьи кто – шаг, который пропускают

Вот вопрос, отделяющий стенд, которому можно верить, от того, что тихо лжёт: откуда вы знаете, что судья хорош? Предвзятый или небрежный судья о себе не объявит. Он возвращает уверенные баллы, которые случайно неверны, и если вы держите релизы на этих баллах, вы выпускаете регрессии, пока дашборд остаётся зелёным. Поэтому, прежде чем судье позволят оценивать что-то важное, он должен сдать собственный экзамен. Этот шаг называется мета-оценкой, и пропуск его – самая частая причина, по которой стенд даёт ложное спокойствие.

Экзамен прост в принципе. Возьмите пару десятков кейсов из golden set и дайте людям тщательно их оценить – это ваш калибровочный набор с доверенными, проставленными людьми оценками. Теперь прогоните судью по тем же кейсам и измерьте, как часто он согласен с людьми. Стандартные меры согласия – каппа Коэна (Cohen's kappa, балл от 0 до 1, измеряющий согласие с поправкой на то согласие, что вышло бы случайно) и корреляция Спирмена (насколько ранжирование выходов судьёй совпадает с человеческим). Если судья согласен с вашими людьми с высокой долей, ему можно доверить заменять их в масштабе. Если нет – вы чините рубрику или меняете модель-судью, прежде чем верить хоть одному автоматическому баллу. Судья, не проверенный против людей, – это слух, а не измерение.

Причина, по которой эта проверка не обсуждается, в том, что у LLM- и VLM-судей есть хорошо задокументированные смещения – систематические ошибки, выживающие даже во фронтирных моделях. Три важнейших. Смещение позиции: оценивая два выхода, судьи предпочитают тот, что видят первым, – исследование MT-Bench нашло, что судья GPT-4 менял вердикт на большой доле сравнений просто при перестановке порядка. Смещение многословия: судьи склонны награждать более длинные, развёрнутые ответы, даже когда лучше короткий. Смещение самопредпочтения (self-preference, оно же self-enhancement): судья склонен предпочитать выходы, написанные им самим или его семейством моделей. Ни одно не гипотетично; все – измеренные, воспроизводимые эффекты.

Хорошая новость в том, что у каждого есть дешёвая защита, и грамотный стенд применяет все три. Против смещения позиции: оценивайте каждое парное сравнение дважды, с переставленным порядком, и засчитывайте победу, только если один ответ побеждает в обоих направлениях, – обзорная литература прямо называет рандомизацию/перестановку порядка стандартным средством. Против многословия: впишите в рубрику лимит длины и велите судье игнорировать длину. Против самопредпочтения: используйте судью из другого семейства моделей, чем то, что породило выход, чтобы оценщик не проверял собственную работу. Смещение, которое вы нейтрализовали, безвредно; смещение, которое вы проигнорировали, – это тихий палец на весах.

Нажмите, чтобы увеличить

Разобранный пример – можно ли доверять этому судье?

Сделаем мета-оценку осязаемой, ведь арифметика – в этом вся суть. Допустим, вы строите функцию авто-резюме записанных вебинаров и хотите использовать VLM-судью для её оценки. Вы берёте 50 записей из golden set, просите двух продакт-специалистов оценить каждое резюме как «приемлемо» или «неприемлемо» и оставляете только 50 кейсов, где оба согласились, – ваши доверенные метки. Теперь вы прогоняете кандидата-судью по тем же 50.

Судья совпадает с вердиктом людей на 43 из 50 кейсов и расходится на 7. Сырое согласие считается просто:

43 совпадения ÷ 50 кейсов = 0,86 = 86% сырого согласия

Но сырое согласие льстит любому судье, потому что часть этих совпадений случилась по удаче – если 70% резюме «приемлемы», судья, говорящий «приемлемо» всему, прав в 70% случаев, не зная ничего. Каппа Коэна вносит поправку на эту удачу. При таком балансе меток 86% сырого согласия дают каппу около 0,68 – что по обычной трактовке каппы означает «существенное» согласие: достаточно хорошо, чтобы доверять как замене людям, и всё же есть что улучшать. Вернись каппа на уровне 0,2 – вы бы знали, что 86% были в основном удачей, а судья почти бесполезен, как бы уверенно ни выглядели его баллы. Число, по которому вы действуете, – поправленное на случайность, а не сырой процент.

«Частая ошибка. Доверять баллам судьи за их точность и постоянство, ни разу не проверив их против людей. Судья может быть идеально воспроизводимым и идеально неправым – он выдаст один и тот же предвзятый балл каждый раз. Воспроизводимость – не точность. Пока вы не измерили согласие судьи с людьми на размеченном наборе (и не поправили на случайность каппой), каждое его число – украшение. Сначала калибровка, потом ворота.»

Ландшафт инструментов в 2026

Собирать стенд из голых деталей не обязательно. К 2026 году есть зрелый слой инструментов оценки, и названия кластеризуются по задаче. Для написания и прогона тестов DeepEval – ближайшее подобие фреймворка модульного тестирования для ИИ-выходов: он работает как pytest, стандартный инструмент тестов на Python, и идёт с десятками готовых метрик, включая оценщиков LLM-as-judge. Promptfoo склоняется к состязательному и red-team-тестированию, управляемому простым конфиг-файлом, – полезно, чтобы сломать функцию раньше пользователей. Ragas специализируется на оценке RAG-систем, что важно, если ваша видео-функция отвечает на вопросы поиском по архиву (паттерн из урока про video RAG). Для дашбордов, трекинга экспериментов и продакшен-мониторинга, превращающих оценки в командную практику, LangSmith, Braintrust и Arize Phoenix держат скоркарты, очереди человеческой разметки и релизные ворота.

Паттерн, к которому сходится большинство опытных команд, – два инструмента, не один: лёгкий фреймворк, работающий в релизном конвейере как ворота (DeepEval, Promptfoo или Ragas), в паре с платформой, отслеживающей регрессии и хостящей человеческое ревью (Braintrust, LangSmith или Arize). Первый отвечает «выпускать ли эту сборку»; второй – «дрейфует ли функция в продакшене и где». Для видео-работы недостающая деталь в большинстве из них – это VLM-судья, проверка заземления по кадрам, – которую сегодня вы обычно подключаете сами, вызывая модель со зрением как оценщика внутри выбранного фреймворка. Этот пробел интеграции – ровно там, где окупается аккуратная инженерия, и где общий набор оценки тихо перестаёт покрывать видео.

Где сидят стандарты

Оценка – ещё и место, где управление ИИ перестаёт быть абстрактным. NIST AI Risk Management Framework, эталон трастового ИИ от стандартизующего органа США, помещает ровно эту работу в свою функцию MEASURE – часть фреймворка, посвящённую TEVV, сокращению от Test, Evaluation, Verification, Validation (тестирование, оценка, верификация, валидация). В структуре NIST измерение трастовости ИИ-системы и её непрерывный мониторинг после развёртывания – не необязательный лоск, а названная обязанность ответственного развёртывания. Стенд оценки – это, попросту, как организация выполняет функцию MEASURE для видео-ИИ функции. Стандарт ISO/IEC 42001, международный стандарт системы менеджмента ИИ, опубликованный в 2023 году, ставит то же требование со стороны управления: развёрнутую ИИ-систему надо оценивать и мониторить по заданным критериям с записанными доказательствами. Ни один документ не говорит, какую модель-судью брать. Оба говорят, что «протестировали один раз, и вроде нормально» – не защитимый ответ, а стенд и его результаты – это артефакты, которые спросит аудитор; нить, которую этот раздел подхватывает в уроке про EU AI Act и раскрытие.

Во сколько это обходится

Судья сам по себе – это вызов модели, поэтому у стенда оценки есть стоимость работы, и она ложится в двух местах. Офлайн стоимость ограничена и мала: golden set из 200 кейсов, оцениваемый судьёй на каждом релизе, – это 200 вызовов модели за прогон, копейки до пары долларов, мелочь рядом со стоимостью выпуска регрессии. Онлайн стоимость растёт с трафиком, ведь оценка выборки живых выходов – это лишние вызовы модели поверх самой функции. Стандартный контроль – выборка: вы судите не каждый продакшен-выход, а представительный срез – 1% или 5%, – что ловит дрейф, не удваивая счёт. Подробная экономика токенов живёт в уроке про стоимость ИИ и уроке про оптимизацию стоимости, а выбор серверов – запуск маленькой модели-судьи вроде 7B-видео-судьи на своём железе вместо вызова фронтирного API – относится к уроку про inference-серверы. Структурный вывод, который должен вести бюджет: дешёвый маленький судья, который вы откалибровали и доказали, что он согласен с людьми, стоит больше, чем дорогой фронтирный судья, которого вы ни разу не проверили. Тратьте деньги на калибровку, а не на модель.

Где здесь Фора Софт

Мы строим видеопродукты для конференцсвязи, стриминга и OTT, онлайн-образования, телемедицины и видеонаблюдения, и почти каждая ИИ-функция, которую мы в них добавляем, – резюме записей, авто-субтитры, решения модерации, ответы по архиву, сгенерированный b-roll – открытая, а значит, её нельзя протестировать знаком равенства. Наша практика – это описанный здесь стенд: golden set из реальных клиентских кадров, включая трудные и состязательные случаи; VLM-as-judge, оценивающий по кадрам, чтобы гладкое-но-выдуманное резюме не прошло; шаг мета-оценки, доказывающий, что судья согласен с человеческими ревьюерами, прежде чем ему позволят что-либо блокировать; и тот же стенд, прогнанный дважды – офлайн как релизные ворота и онлайн как сэмплер, чьи провалы текут обратно в golden set. Вертикали меняют рубрику, а не метод: телемедицинский «скрайб» судят за клиническую верность, резюме видеонаблюдения – за заземление, решение модерации – за точность и полноту, но каждое – это тот же пятичастный стенд с отраслевой рубрикой и судьёй, заслужившим своё место согласием с людьми.

Главное

• Стенд оценки заменяет знак равенства для ИИ-функций, чей выход – открытое суждение.
• Метрики совпадения слов (BLEU, ROUGE) наказывают синонимы и слепы к тому, отвечает ли текст видео.
• LLM-as-judge оценивает по рубрике и совпал с людьми более чем в 80% в основополагающем исследовании.
• Для видео берите VLM-as-judge, читающий выборку кадров, чтобы ловить выдуманные детали.
• Выбирайте режим осознанно: pairwise – чтобы выбрать модель, pointwise – чтобы следить за одной во времени.
• Всегда проверяйте судью – мерьте согласие с людьми (каппа Коэна) и нейтрализуйте смещения позиции, многословия и самопредпочтения.

Что почитать дальше

• Оценка, безопасность, стоимость, наблюдаемость агентов – AgentOps
• Видео-VLM в 2026 – выборка кадров против потока токенов
• vLLM, Triton, TensorRT – inference-серверы для видео-ИИ