6.8 Оценка и тестирование ИИ

Обзор и мотивация

Тестирование обычных программ опирается на утешительное допущение: при том же входе программа возвращает тот же выход, и вы можете утверждать, каким именно должен быть этот выход. Искусственный интеллект ломает это допущение. Модель может ответить на один и тот же вопрос двумя способами, оба приемлемы. Её можно оценивать по спектру от неверного до блестящего, а не «прошёл или не прошёл». И нередко нет единственного верного ответа, против которого можно утверждать. Поэтому дисциплина оценки (измерение того, насколько хорошо модель ведёт себя по многим репрезентативным случаям, а не проверка одного вывода против одного ожидаемого значения) становится хребтом любой заслуживающей доверия системы ИИ. Когда команды выпускают функции ИИ, ставящие их в неловкое положение, корень причины почти всегда в том, что у них не было серьёзного способа измерить качество до выпуска.

Для больших команд оценка то, что делает изменения безопасными. Вы будете менять модели, переписывать промпты, настраивать поиск и добавлять инструменты, и каждое из этих изменений может молча ухудшить поведение, которое вы считали надёжным. Без повторяемого способа измерения качества каждое изменение азартная игра, а каждую регрессию обнаруживает пользователь. Эта глава измерительный спутник строительных глав: генеративный ИИ и приложения на LLM (глава 6.3), ИИ-агенты и агентные системы (глава 6.7) и инженерия машинного обучения и MLOps (глава 6.2). Она расширяет вашу общую стратегию тестирования (глава 2.4) в вероятностный мир.

Корпоративная и государственная среда поднимают ставки ещё выше. Корпорации, ведущей десятки функций ИИ, нужна общая платформа оценки, чтобы каждая команда не изобретала оценку с нуля. Государственному ведомству нужна оценка документированная и проверяемая, потому что «мы протестировали» должно стать «вот свидетельство, набор данных, метрика и подпись». Оценка то место, где ответственный и надёжный ИИ (глава 6.5) перестаёт быть заявлением о ценностях и становится тем, что можно показать регулятору.

Ключевые принципы

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

Рекомендации

Принимайте разработку, управляемую оценками

Прежде чем настраивать промпт или выбирать модель, напишите оценку. Это отражает разработку через тестирование: вы определяете, что значит «хорошо» в измеримых терминах, затем строите к этому. Оценка здесь означает набор данных входов в паре со способом подсчёта, возвращающим число или балл для каждого вывода. Начинайте с малого. Двадцать тщательно выбранных случаев, отражающих реальное намерение пользователей, лучше тысячи случайных. Растите набор по мере того, как узнаёте, где система проваливается, добавляя каждый отказ в эксплуатации обратно как постоянный случай, чтобы та же ошибка не могла вернуться незамеченной.

Разработка, управляемая оценками, меняет поведение команды. Когда определение хорошего записано и запускаемо, споры о том, помогло ли изменение, становятся проверяемыми, а не делом вкуса. Делайте набор оценки рецензируемым артефактом под контролем версий рядом с промптами и кодом, которые он измеряет.

Разделяйте офлайн- и онлайн-оценку и используйте обе

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

Соедините обе в контур. Когда онлайн-метрики проседают или пользователи отмечают плохой ответ, зафиксируйте этот случай, разметьте и влейте в офлайн-набор. Направляйте эксперименты через то же контролируемое сравнение, что вы используете для любого изменения продукта, а это территория аналитики продукта и экспериментирования (глава 7.4). A/B-тест, показывающий, что новая модель повышает успех задач, стоит больше любой офлайн-оценки, но именно офлайн-оценка позволила вам осмелиться запустить тест.

Стройте репрезентативные наборы оценки и защищайтесь от загрязнения

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

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

Выбирайте метрики, подходящие задаче

Подбирайте измерение под форму вывода. Для классификации и извлечения, где есть верная метка, применимы классические метрики: точность и полнота (из отмеченного вами сколько было верно и из верных сколько вы нашли), F-мера, уравновешивающая их, и точность точного совпадения. Для всего, где важна уверенная вероятность, измеряйте калибровку: верна ли заявленная 80-процентная уверенность примерно в 80 процентах случаев, потому что хорошо калиброванная модель, знающая, когда она не уверена, гораздо безопаснее самоуверенной.

Генеративные выводы труднее. Метрики на основе эталона вроде BLEU и ROUGE, изначально построенные для машинного перевода и резюмирования, сравнивают порождённый текст с эталонным подсчётом пересекающихся слов и фраз. Они дёшевы и повторяемы и слабые заместители качества: они вознаграждают поверхностное пересечение и наказывают верный ответ, сформулированный иначе, чем эталон. Используйте их как грубые сигналы регрессии, а не определение хорошего. Для открытых задач лучше работает оценка по рубрике: определите явные критерии (заземлён ли, полон ли, безопасен ли и правильно ли отформатирован) и оценивайте каждый. Рубрики делают субъективное качество читаемым и рецензируемым.

Используйте LLM-как-судью, но калибруйте её против людей

Ручная оценка генеративного вывода не масштабируется, поэтому команды всё чаще используют сильную большую языковую модель как автоматического судью, подавая ей вход, вывод и рубрику и прося оценить. Этот подход LLM-как-судья быстр и удивительно способен, но несёт реальные предвзятости, которыми вы должны управлять. Судьи склонны предпочитать более длинные ответы, отдавать преимущество первому варианту в попарном сравнении (предвзятость позиции), вознаграждать собственный стиль письма и могут поддаваться связным, но неверным рассуждениям. Без контроля предвзятый судья даёт вам уверенные, точные, неверные числа.

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

Держите людей в контуре для эталонной истины

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

Проводите «красные команды» на безопасность и состязательную устойчивость

Стандартные наборы оценки измеряют, делает ли система правильное на разумных входах. «Красная команда», намеренная атака на собственную систему для поиска, где она ведёт себя плохо, измеряет, что происходит под давлением. Прощупывайте внедрение через промпт, взлом ограничений, небезопасное содержимое, утечки приватности и предвзятые выводы. Сделайте это повторяемым набором, а не разовым упражнением: превращайте каждую успешную атаку в постоянный случай регрессии, чтобы исправленная уязвимость оставалась исправленной. Эта работа напрямую связана с ответственным и надёжным ИИ (глава 6.5), а в регулируемой среде нередко и есть свидетельство, удовлетворяющее рецензии безопасности.

Оценивайте агентов по сквозному успеху задачи

Агентов, планирующих и действующих в много шагов, нельзя оценивать по одному выводу. Важно, удалась ли вся задача: забронировал ли агент встречу, решил ли заявку или завершил рабочий процесс правильно и безопасно. Стройте оценки на уровне задач в изолированной среде, где агент может действовать против реалистичных, но безопасных фикстур, и оценивайте итоговые результаты плюс траекторию, то есть последовательность шагов и вызовов инструментов, которыми он дошёл. Верный ответ, достигнутый опасным или расточительным путём, всё равно проблема. Это существенно для ИИ-агентов и агентных систем (глава 6.7), где одно неверное действие может иметь реальные последствия.

Подключайте оценки к CI и мониторьте эксплуатацию

Сделайте оценку автоматической. Запускайте ваш офлайн-набор в непрерывной интеграции (CI) на каждое изменение промпта, модели или поиска и управляйте слияниями им так же, как вы управляете ими модульными тестами, практика, уходящая корнями в вашу более широкую стратегию тестирования (глава 2.4). Поскольку баллы шумны, управляйте по порогам и трендам, а не требуя безупречного запуска, и заваливайте сборку, когда ключевая метрика падает ниже своего пола или регрессирует сверх заданного запаса. Затем продолжайте наблюдать в эксплуатации: мониторьте сигналы качества, распределения выходов и дрейф входов, чтобы ловить медленную деградацию, которую пропускают офлайн-тесты, что связано с практиками наблюдаемости инженерии машинного обучения и MLOps (глава 6.2). Модель, точная при запуске, может распадаться, когда мир, который она описывает, меняется под ней.

Компромиссы: плюсы и минусы

Подход к оценке	Плюсы	Минусы	Лучше всего, когда
Человеческая оценка	Наивысшая точность, ловит нюансы	Медленно, дорого, трудно масштабировать	Эталонная истина, высокие ставки, калибровка судей
LLM-как-судья	Быстро, дёшево, масштабируется на большие наборы	Предвзята, нужна калибровка	Частые офлайн-запуски на генеративном выводе
Метрики на основе эталона (BLEU, ROUGE)	Дёшево, детерминированно, повторяемо	Слабый заместитель реального качества	Грубые сигналы регрессии, а не окончательные вердикты
Классические метрики (точность, полнота, F-мера)	Объективно, хорошо понятно	Подходят только задачам с верными метками	Классификация, извлечение, поиск
Публичные бенчмарки	Сопоставимо между моделями, не нужна настройка	Загрязнение, плохо подходят вашей задаче	Ранний отбор моделей, а не барьеры выпуска
Онлайн-оценка (A/B, обратная связь)	Отражает реальных пользователей и результаты	Медленно, приходит после воздействия	Подтверждение, что изменение действительно помогло

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

Вопросы для обсуждения с командой

Какова наша планка «достаточно хорошо» и кто владеет набором оценки, который её определяет? У каждой функции ИИ есть неявный порог качества, и пока он остаётся неявным, каждый инженер устанавливает свой на ощущение, а споры решаются тем, кто в комнате старше. Запись планки как запускаемого набора оценки с целевыми баллами по сегментам превращает эти споры в измеримые вопросы. Принесите ваше текущее определение успеха, данные за ним и честный отчёт о том, кто его на самом деле сопровождает, потому что набор оценки без владельца гниёт так же быстро, как любой другой неухоженный код. Решите, различается ли планка по уровню риска, поскольку публичный юридический ответ должен проходить более высокую планку, чем внутреннее средство для мозгового штурма. Ответ должен сказать, может ли кто-либо сейчас выпустить изменение ИИ, когда между ним и пользователями не стоит никакого измерения.
Как мы знаем, что наши числа оценки честны, а не загрязнены или переобучены? Балл полезен, только если предсказывает реальное качество, и есть много способов, которыми он перестаёт это делать: данные бенчмарка утекают в обучение, разработчики настраивают промпты против тестового набора, пока число не станет бессмысленным, или золотой набор построен на ответах, которые никогда не проверялись. Принесите свидетельства о том, откуда взялись ваши данные оценки, какая часть держится приватной и как часто обновляется. Обсудите, держите ли вы свежий отложенный набор, на который смотрите редко, чтобы иметь хотя бы одно число, против которого никто не оптимизировал. Если вы не можете объяснить, почему ваши баллы всё ещё держались бы на данных, на которые модель никогда не влияла, вы измеряете собственное отражение.
Где люди остаются в контуре и как мы держим наших автоматических судей откалиброванными относительно них? LLM-как-судья и метрики на основе эталона позволяют оценивать в масштабе, а они отходят от человеческого суждения способами, невидимыми, пока вы не проверите. Принесите вашу текущую долю согласия между автоматической оценкой и человеческой рецензией, как недавно вы её измеряли и на какие предвзятости (длина, позиция, стиль) вы тестировали. Решите, какие решения требуют человеческого оценщика независимо от цены, обычно наивысших ставок и те, что используются для перекалибровки автоматического судьи. Поговорите и о качестве разметки, потому что судья, откалиброванный против непоследовательных человеческих меток, наследует эту непоследовательность. Ответ должен дать расписание перекалибровки, а не разовое благословение.
Какие изменения ИИ сегодня закрыты барьером оценки, а какие всё ещё достигают пользователей на одной уверенности кого-то? Барьер, работающий на одних изменениях, но не на других, даёт иллюзию безопасности, оставляя реальным регрессиям проскальзывать по незакрытому пути: тихая правка промпта, настройка поиска, повышение версии модели, которое никто не счёл изменением. Для большой команды опасность растёт с числом людей, которые могут коснуться промпта, потому что каждый незакрытый путь способ выпустить регрессию, которую не видел ни один набор данных. Принесите список типов изменений, сейчас запускающих офлайн-набор в непрерывной интеграции, тех, что нет, и последние несколько инцидентов, прослеженных до незакрытого изменения. Решите, какой порог и тренд принуждает барьер, поскольку шумный балл требует пола и запаса регрессии, а не требования безупречного запуска. В корпоративной и государственной среде привяжите барьер к самой записи выпуска, чтобы свидетельство того, что изменение было измерено, было частью следа аудита, а не снимком экрана, сделанным однажды.
Сколько мы тратим на оценку и соответствует ли этот расход риску каждой функции? Оценка не бесплатна: труд разметки, вычисления, сжигаемые автоматическими судьями на каждый запуск, и постоянная работа по поддержанию золотых наборов репрезентативными стоят реальных денег, а команда, никогда не называющая эти затраты, склонна либо недоинвестировать в функцию высоких ставок, либо золотить одноразовую. Конкурирующее тяготение между точностью и бюджетом, потому что самый надёжный метод, экспертная человеческая рецензия, также наименее масштабируем, поэтому вы не можете позволить его везде и должны решить, где он оправдывает свою цену. Принесите текущую цену на запуск оценки, часы разметки на функцию и честный уровень риска для каждой системы, чтобы комната видела, куда идут деньги против того, где живёт опасность. Для корпорации это сильнейший аргумент в пользу общей платформы оценки, амортизирующей разметку и вычисления по многим командам; для государственного ведомства уровень риска должен напрямую отображаться на глубину свидетельств, которых позднее потребует орган надзора.
Когда приходит лучшая модель, как быстро мы можем доказать, помогает ли она, и кому разрешено делать переключение? Ценность набора оценки реализуется острее всего в день, когда выходит более сильная модель, потому что команда, способная прогнать свои золотые наборы и набор «красной команды» против новой модели за полдня, может принять улучшения, которые команда, оценивающая вручную, упустит месяцами. Напряжение между скоростью и осторожностью: вы хотите двигаться в день появления лучшей модели и не можете позволить замене молча ухудшить категорию ответов, которую скрывает ваш средний балл. Принесите время, которое сейчас занимает полное офлайн-сравнение против нового провайдера, переносимы ли ваши наборы оценки между моделями и сегменты, где регрессия имела бы наибольшее значение. В регулируемой и публичной среде назовите, у кого полномочия утверждать смену модели и каких документированных свидетельств он требует, потому что недокументированная замена модели за решением, обращённым к гражданину, именно то изменение, которое аудитор попросит вас обосновать.

Взгляд по секторам

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

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

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

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

Примеры

Стартап. Компания из четырёх человек, строящая ИИ-помощника для рецензии контрактов, начала с таблицы из сорока реальных пунктов, каждый размечен штатным юристом с риском, который он должен отмечать. Каждое изменение промпта прогонялось против этого набора скриптом перед слиянием, а балл печатался в запросе на слияние. Когда пользователи отмечали пропущенный пункт, он шёл прямо в таблицу, так что набор рос вместе с продуктом. По мере роста объёма они добавили LLM-как-судью для оценки качества объяснений, но только проверив, что он согласуется с юристом на выборке. Дёшево, приватно и честно лучше любого публичного бенчмарка для их ниши.

Крупная организация. Крупный банк вёл дюжину функций ИИ в поддержке, поиске и внутренних инструментах, и каждая команда оценивала по-своему. Они построили общую платформу оценки: общее место для хранения золотых наборов данных, запуска офлайн-наборов в CI, регистрации промптов LLM-судей с их баллами калибровки и отслеживания онлайн-метрик на функцию. Сверху сидело управление с уровнями риска, задающими требуемую планку и подпись, нужную перед выпуском. Новая функция объяснения мошенничества не могла выйти, пока её набор оценки не был отрецензирован, набор «красной команды» не был пройден, а подотчётный владелец не подписал результаты. Повторное использование платформы означало, что команды спорили о своей области, а не о том, как измерять.

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

Бизнес-обоснование: мотивы, ROI и TCO

Оценка окупает себя, делая каждое другое вложение в ИИ безопаснее и быстрее. Её возврат инвестиций (ROI) проявляется как меньше инцидентов в эксплуатации, более быстрая итерация, потому что команды могут менять промпты и модели уверенно, и способность принимать лучшие модели в день их появления, потому что вы можете доказать, помогают ли они. Яснейший способ оценить её цена её отсутствия: одна публичная галлюцинация, предвзятый вывод или утечка данных могут стоить гораздо больше в устранении, потерянном доверии и регуляторной экспозиции, чем годы инфраструктуры оценки. Это разница между бесплатным нахождением регрессии в CI и нахождением её в газете.

Совокупная стоимость владения (TCO) реальна и заслуживает названия. Вы платите за труд разметки, за вычисления, которые потребляют автоматические судьи, и за постоянную работу по поддержанию наборов оценки репрезентативными по мере сдвигов использования. В масштабе корпорации общая платформа амортизирует большую часть этого по многим командам, что сильнейший аргумент в пользу её построения, а не позволения каждой группе импровизировать. Обосновывайте перед руководством, сочетая конкретный риск (цена одного плохого публичного ответа в вашей области) с конкретной возможностью (скорость безопасного принятия каждой новой модели) и формулируя оценку как средство контроля, позволяющее организации двигаться быстро, не двигаясь безрассудно.

Антипаттерны и ловушки

Выпуск на ощущениях. Оценка изменений ИИ пробой нескольких промптов вручную без набора данных и повторяемого балла.
Театр бенчмарков. Доверие сильному баллу публичного бенчмарка как доказательству пригодности системы вашей задаче, игнорирование загрязнения и несоответствия распределения.
Переобучение под набор оценки. Настройка промптов против того же фиксированного набора, пока число не станет высоким и бессмысленным, без свежего отложенного набора.
Некалиброванные судьи. Развёртывание LLM-как-судьи и доверие его баллам без проверки согласия с человеческими оценщиками.
Поклонение метрикам. Оптимизация BLEU или ROUGE как будто это качество и выпуск худших ответов, случайно пересекающихся с эталонным текстом.
Разовая «красная команда». Атака на систему один раз перед запуском и никогда не превращение находок в постоянные тесты регрессии.
Уверенность только офлайн. Вера, что хороший офлайн-балл значит работающую функцию, без онлайн-измерения реальных результатов.
Осиротевшие наборы оценки. Наборы данных, которыми никто не владеет, никогда не впитывающие отказы эксплуатации и медленно перестающие отражать реальность.

Модель зрелости

Уровень 1, Начальный: Изменения ИИ оцениваются вручную на нескольких примерах, реактивно, когда кто-то случайно встревожен. Нет ни набора данных, ни повторяемого балла, ни барьера. Регрессии находят пользователи, и никто не может сказать, лучше или хуже система, чем в прошлом месяце.
Уровень 2, Развитие: Некоторые команды ведут малые золотые наборы данных и запускают их вручную перед большими изменениями, и существуют несколько классических баллов или баллов на основе эталона. Человеческая рецензия происходит для важных функций, но оценка непоследовательна по командам, не автоматизирована и не закрыта барьером, а каждая группа делает по-своему.
Уровень 3, Стандартизация: Офлайн-наборы запускаются в непрерывной интеграции на каждое изменение промпта, модели или поиска и управляют слияниями по одной документированной практике по организации. LLM-как-судья откалиброван против человеческих меток, «красная команда» повторяемый набор, а наборы данных имеют владельцев, версионируются и питаются отказами эксплуатации с активной защитой от загрязнения.
Уровень 4, Управление: Оценка измеряется и контролируется данными относительно базовых значений. Доли согласия судьи и человека, доли прохождения «красной команды», баллы по сегментам, онлайн-успех задач и дрейф отслеживаются во времени, а слияния управляются порогами и запасами регрессии, а не единым безупречным запуском. Цена разметки и вычислений на запуск бюджетируется на функцию, перекалибровка происходит по расписанию, а каждый результат несёт подотчётного владельца и подпись.
Уровень 5, Оркестрация: Общая платформа оценки обслуживает всю организацию, а офлайн- и онлайн-оценка образуют непрерывный контур, привязанный к бизнес-результатам. Новые модели доказываются на переносимых наборах оценки в день появления, портфель адаптируется по мере сдвигов использования и риска, свидетельства оценки проверяемы для регуляторов и надзора, а уроки отказов одной команды перетекают в наборы данных каждой команды.

Идеи для обсуждения

Как решить, достаточно ли силён офлайн-балл, чтобы оправдать онлайн-эксперимент, и когда нет?
Каково правильное отношение человеческой оценки к автоматической для вашего профиля риска и как часто пересматривать его?
Когда публичный бенчмарк и ваш приватный набор оценки расходятся в том, какая модель лучше, чему вы верите и почему?
Как держать набор оценки репрезентативным по мере сдвигов поведения пользователей, не давая ему раздуться до слишком медленного для CI?
Что принадлежит набору «красной команды» для вашей области и кто квалифицирован проектировать атаки?
Как оценивать траекторию агента, а не только его итоговый ответ, не утонув в цене оценки каждого шага?

Главные выводы

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

Источники и дополнительное чтение

Chip Huyen, AI Engineering: Building Applications with Foundation Models.
Lianmin Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.
Kishore Papineni et al., BLEU: A Method for Automatic Evaluation of Machine Translation.
Chin-Yew Lin, ROUGE: A Package for Automatic Evaluation of Summaries.
Percy Liang et al., Holistic Evaluation of Language Models (HELM).
Deep Ganguli et al., Red Teaming Language Models to Reduce Harms: Methods, Scaling Behaviours, and Lessons Learned.
OWASP Foundation, OWASP Top 10 for Large Language Model Applications.
National Institute of Standards and Technology, AI Risk Management Framework.