Экспресс-курс · No. 13
ИИ-фича построена на недетерминированном компоненте — один и тот же ввод может дать разный вывод, а «выглядело хорошо, когда я попробовал» — это не тест. Эвал — это набор тестов для этого компонента: известные входы, оценённые выводы, прогон на каждом изменении. Это негламурная дисциплина, что отделяет демо, на которое ты надеешься, от продукта, про который ты знаешь.
Только суть · Один образ на идею · Меряй, не гадай
Обычный код можно юнит-тестировать, потому что один и тот же ввод даёт один и тот же вывод. LLM это ломает, так что нужен другой вид теста — а без него ты летишь вслепую.
Угадыватель не юнит-тестируется
Оценить эссе — не то же, что проверить сумму: нет единственной верной строки для сверки, и один и тот же промпт каждый раз даёт слегка другое эссе.
Обычный тест утверждает output === expected. LLM недетерминирована и открыта: один и тот же промпт даёт разный текст, а «верно» — часто качество, а не точная строка. Так что модель утверждения ломается. Эвал её заменяет: набор входов, у каждого — способ оценить, насколько хорош вывод, прогоняемый раз за разом, — тестирование, построенное для компонента, что не возвращает одно и то же дважды.
Ощущения не переживают контакта с изменением
Повар, что никогда не пробует блюдо, а просто крутит рецепт и надеется, — он не может понять, помогло ли вчерашнее изменение или тихо его испортило.
Без эвала ты настраиваешь промпты на ощупь: попробовал, окинул взглядом пару выводов, отгрузил, если ощущается лучше. Ловушка в том, что ты не видишь регрессий — изменение, что чинит один случай, часто ломает три, что ты не перепроверил. Эвал превращает «ощущается лучше» в «набрал 84% против 79%», а это разница между инженерией и гаданием.
Дойти до 80% быстро; 95% — это весь проект
Первый черновик чего угодно приходит быстро. Превращение грубого черновика в надёжное — вот куда уходит реальное время.
Вот тяжёлая правда, ради которой эвалы и существуют: демо, что верно в 80% случаев, занимает вечер; вытягивание оттуда до 95% — это бо́льшая часть работы. Этот последний отрезок находится случай за случаем — краевые входы, редкие сбои, — и найти и починить их можно, только если меришь. Эвал — это прибор, что делает долгий подъём видимым.
Эвал — это твоя сеть от регрессий и твоя спека
Страховка позволяет скалолазу попробовать тяжёлый ход, потому что срыв не будет смертельным, — она делает смелые изменения безопасными.
Как только у тебя есть эвал, ты можешь поменять промпт, заменить модель или перестроить конвейер и сразу увидеть, помогло это или навредило. Он ловит регрессии раньше пользователей и тихо становится настоящей спецификацией «как выглядит хорошо» для твоей фичи. Без него каждое изменение — азартная игра; с ним улучшение становится циклом, что ты реально можешь крутить.
Недетерминированный компонент не юнит-тестируется. Эвал оценивает его вместо этого — а без него каждое изменение это догадка.
«Оно хорошее?» не измеримо. Первая реальная работа эвалов — превратить этот смутный вопрос в конкретные вещи, что ты можешь оценить, выбранные под работу, что делает твоя фича.
Преврати «хорошо» в конкретные проверки
Экзамен по вождению не спрашивает «ты хороший водитель?» — он оценивает конкретное: подал ли сигнал, держался ли полосы, полностью ли остановился, припарковался ли в линиях.
«Качество» слишком смутно, чтобы оптимизировать. Разбей его на измеримые свойства: был ли ответ верен, был ли заземлён в источнике, валиден ли формат, вызвал ли нужный инструмент, верны ли длина и тон? Каждое — то, что можно оценить. Навык — выбрать те немногие свойства, что реально важны для твоей задачи, а не мерить всё.
Подбери метрику под работу
Переводчика судишь по верности и беглости, кассира — по скорости и точности; не тот аршин — бесполезная оценка.
Разным фичам нужны разные метрики. RAG-система: извлекла ли нужные чанки и верен ли ответ им? Классификатор: точность против меток. Агент: выбрал ли нужные инструменты и достиг ли цели? Сводка: верна, полна, кратка. Бери метрики, что отображают, что сбой реально значит для твоей задачи, иначе будешь оптимизировать цифру, что не важна.
Верность и правильность — разные вещи
Студент может написать красиво аргументированный ответ, что неверен, или неуклюжий, что верен. Стиль и истина — отдельные оценки.
Два из важнейших свойств путают. Правильность — верен ли ответ на деле; верность — подкреплён ли он предоставленным контекстом без выдумки. Заземлённая система может быть верна источнику (она его использовала) и при этом неправа (источник был неверен) или права и при этом неверна источнику (угадала, а не из контекста). Измерение их отдельно говорит тебе, где сбой.
Одна цифра прячет слишком много
Средняя температура «комфортно» может прятать морозную комнату и знойную. Агрегат стирает случаи, что нужнее всего увидеть.
Единый общий балл — стартовая точка, а не картина. Разбей результаты по категории и сложности — лёгкие против тяжёлых, каждый тип вопроса, каждый режим сбоя, — потому что ровные 85% могут быть 100% на лёгких и 40% на тех, что важны. Ценность эвала — в разбивке, что показывает ровно, куда целиться дальше.
«Оно хорошее?» — не метрика. Разбей качество на конкретные, оцениваемые свойства под свою задачу — и никогда не доверяй единой агрегатной цифре.
Эвал честен ровно настолько, насколько примеры в нём. Датасет — входы и их известные хорошие исходы — это настоящий актив, и бо́льшая часть заботы идёт сюда.
Золотой набор: входы с известными хорошими исходами
Ключ ответов учителя — вопросы в паре с тем, как выглядит верный ответ, чтобы оценка была последовательной, а не по настроению.
Ядро эвала — золотой набор: коллекция представительных входов, у каждого — известный хороший ответ или ясное определение успеха. Это то, против чего ты оцениваешь. Его построение — реальная работа, именно здесь ты пришпиливаешь, что вообще значит «верно» для твоей фичи, — и это актив, что делает каждое будущее изменение измеримым.
Покрой края и известные сбои
Мост нагружают-испытывают самыми тяжёлыми грузовиками и худшими штормами, а не средней машиной в солнечный день.
Набор только из лёгких, типичных входов даёт льстивый, бесполезный балл. Намеренно включай тяжёлые случаи: неоднозначные вопросы, краевые входы, состязательные промпты и особенно сбои, что ты уже видел. Каждый раз, когда баг доходит до прода, добавляй его в эвал, чтобы он не смог тихо вернуться. Набор должен концентрироваться там, где система вероятнее всего сломается.
Собирай реальные примеры из прода
Лучшие тестовые вопросы приходят из реального экзамена, что сдавали студенты, а не из того, что учитель вообразил, что они спросят.
Богатейший источник эвал-случаев — реальное использование: что пользователи на деле спрашивали, особенно то, что спросили и что пошло не так. Майни свои логи и фидбек на реальные входы и вплетай их в набор. Выдуманные примеры отражают то, что ты думаешь, происходит; продовые отражают то, что происходит, включая грязные формулировки и странные запросы, что ты бы и не выдумал.
Маленький и острый бьёт большой и затхлый
Пятьдесят хорошо подобранных вопросов, что прощупывают реальные слабые места, учат тебя большему, чем тысяча случайных, в которые ты толком не смотришь.
Не нужны тысячи случаев, чтобы начать, — пары десятков хорошо подобранных, покрывающих главные поведения и известные режимы сбоя, хватит, чтобы ловить большинство регрессий и направлять настройку. Начни с малого, держи честно и расти его по мере того, как узнаёшь, где система ломается. Эвал, что ты реально гоняешь, бьёт огромный, что не гоняешь.
Золотой набор — это актив. Спаривай реальные входы с известными хорошими исходами, концентрируйся на тяжёлом и сломанном и расти его по мере того, как узнаёшь.
Когда у тебя есть входы и ожидания, нужен способ оценить каждый вывод. Методы идут от дешёвых и точных до гибких и ошибающихся — и ты тянешься к самому дешёвому, что подходит.
Используй точные и правиловые проверки, где можешь
Проверка теста с выбором ответа не требует суждения — ответ верен или нет, и машина оценивает его мгновенно.
Когда вывод ограничен, оценивай его детерминированно: точное совпадение для классификации, регэксп или проверка схемы для формата, вызвал-ли-нужный-инструмент для агента, верна-ли-цифра для извлечения. Эти проверки дёшевы, быстры и неоспоримы. Всегда проталкивай как можно бо́льшую часть эвала в эту категорию — это самая надёжная оценка из всех.
LLM-as-judge для размытого
Для эссе ты приводишь второго экзаменатора с ясным рубриком — суждение, но направленное явными критериями, чтобы оно было последовательным.
Для открытых выводов — верна ли эта сводка? полезен ли этот ответ? — точного совпадения нет, так что ты используешь модель для оценки, LLM-as-judge: дай второй модели вывод, контекст и ясный рубрик и пусть оценит. Это масштабирует человекоподобное суждение на тысячи случаев. Это стандартный инструмент для качеств, что не проверить правилом, — но он идёт с оговорками.
Судью тоже надо судить
Второй рефери может быть предвзят — благоволить ответу подлиннее или тому, что звучит уверенно, — так что ты сверяешь рефери с парой человеческих решений, прежде чем ему доверять.
У LLM-судьи есть режимы сбоя: он может предпочитать многословные ответы, поддаваться уверенному тону или дрейфовать от твоего намерения. Так что валидируй судью против человеческих оценок на выборке, дай ему острый рубрик с примерами и держи его простым. Судья, что ты не проверил, — это просто ещё одна неизмеренная модель; не доверяй его баллам, пока не подтвердил, что они отслеживают то, что тебя реально волнует.
Держи людей в контуре, малыми дозами
Даже с автоматической оценкой шеф всё равно пробует еду — быстрая выборочная проверка, что приборы тихо не разошлись.
Автоматическая оценка масштабируется, но периодически читай реальные выводы сам. Выборочно проверяй, всматривайся в сбои и проверяй на здравость, что твои метрики всё ещё отражают реальное качество. Человеческое ревью не масштабируется на каждый случай, но малая, регулярная доза ловит то, что твои автоматические баллы упускают, — и не даёт тебе оптимизировать цифру, что отъехала от реальности.
Оценивай детерминированно, где можешь, используй LLM-судью для размытого остатка — и валидируй судью, потому что непроверенный оценщик — просто ещё одна догадка.
Агентам нужно больше, чем оценка финального ответа, потому что они могут прийти к чистому ответу через сломанный процесс. Чтобы доверять агенту, ты меряешь путь, а не только пункт назначения.
Чистый финальный ответ может прятать сломанную середину
Экзамен по математике, оценённый лишь по финальной цифре, пропускает студента, что пришёл к ней через две взаимно сокращающиеся ошибки, — ты не узнаёшь ничего о том, что реально случилось.
В многошаговом агенте промежуточная ошибка может пройти проверку финального вывода, испортив процесс: он достаёт нужный источник, на полпути приписывает факт не туда и пишет чистую сводку, что неверна. Оценивай только финальный ответ — и ты это пропустишь. Сбои, что нужнее всего поймать, — те, к которым проверка-только-пункта-назначения слепее всего.
Оценивай траекторию
Экзаменатор по вождению смотрит всю поездку — каждый сигнал, проверку зеркал и смену полосы, — а не только прибыл ли ты по адресу.
Для агентов ты оцениваешь траекторию: на каждом шаге выбрал ли он нужный инструмент, передал ли нужные аргументы, извлёк ли нужный контекст и рассуждал ли здраво? Это ловит сломанную середину, что финальная проверка упускает, и говорит тебе, какой шаг сбоил, — куда полезнее, чем знать лишь, что конец был неверен. Шаги — вот где надёжность агента реально делается или теряется.
Проверяй вызовы инструментов и извлечения напрямую
Аудит научного ассистента — это проверка, какие источники он реально вытянул и какие вызовы сделал, а не только чтение его финальной записки.
Бо́льшая часть поведения агента конкретна и оцениваема без суждения: вызвал ли он send_email, когда должен был, с верным получателем? извлёк ли релевантный документ? остался ли в пределах прав на инструменты? Это детерминированные проверки на шагах, дешёвые и точные, и они пришпиливают большую долю сбоев агента в точности.
Меряй и скучные операционные истины
Службу доставки судят не только по тому, прибыла ли посылка, но по тому, сколько заняло, сколько попыток и сколько стоило.
Помимо правильности, отслеживай операционные метрики агента: сколько шагов он взял, как часто зацикливался или повторял, задержку и стоимость на задачу. Цикл, что приходит к верному ответу за двадцать дорогих шагов, когда хватило бы трёх, — это проблема надёжности и стоимости, что твой балл финального ответа не покажет. Эти цифры вскрывают агентов, что работают, но не переживут прода.
Агент может прийти к чистому ответу через сломанный процесс. Оценивай траекторию — инструменты, извлечения, шаги, — а не только пункт назначения.
Эвалы бывают двух видов, что делают разную работу: набор тестов, что гоняешь до выкатки, и измерение, что держишь работающим в проде. Нужны оба, потому что мир — не твой тестовый набор.
Оффлайн-эвалы: гейт до выкатки
Тестовый трек, где ты прогоняешь машину через испытания, прежде чем она хоть раз повезёт пассажира, — контролируемо, повторяемо, до релиза.
Оффлайн-эвал — это твой золотой набор, прогнанный против изменения до выкатки: набрал ли этот новый промпт или модель лучше на случаях, что ты собрал? Это контролируемо и повторяемо, место, где ты ловишь регрессии и безопасно сравниваешь варианты. Это эвал, что ты вшиваешь в цикл разработки — в идеале гейтом в CI, чтобы ничто не отгрузилось, что роняет балл.
Онлайн-эвалы: измерение реального мира
Как бы хорош ни был тестовый трек, ты всё равно мониторишь машины, когда они на реальных дорогах, — потому что у реальных дорог есть ямы, которых у трека не было.
Прод ведёт себя так, как ни один оффлайн-набор полностью не предскажет: реальные пользователи формулируют то, чего ты не вообразил, и распределение входов смещается. Так что ты меряешь и онлайн — выбираешь и оцениваешь живые выводы, следишь за метриками качества и собираешь сигналы пользователей. Оффлайн-набор доказывает, что изменение безопасно выкатить; онлайн-измерение говорит, что реально происходит, когда оно вышло.
Фидбек пользователей — бесплатный эвал-сигнал
Кнопка «палец вверх» и ящик жалоб — это непрерывный, бесплатный опрос о том, реально ли штука работает для тех, кто ею пользуется.
Твои пользователи оценивают тебя, собираешь ты это или нет. Лови сигналы — палец вверх/вниз, правки, повторы, отказы, эскалации — и возвращай их назад. Всплеск повторов или пальцев вниз — раннее предупреждение; конкретные сбои становятся завтрашними эвал-случаями. Это замыкает цикл: прод учит эвал-набор, как выглядит реальность, а эвал-набор защищает следующий релиз.
Следи за дрейфом
Весы медленно уходят из калибровки — ничего драматичного, просто каждое показание чуть больше мимо, пока однажды цифры не станут неверными.
Система, что набирала хорошо, может деградировать тихо: провайдер модели обновляется, твои данные смещаются, паттерны использования меняются. Без постоянного онлайн-измерения ты узнаёшь это от злых пользователей, а не с дашборда. Отслеживай качество во времени, чтобы дрейф проявлялся трендом, на который можно реагировать, а не сюрпризом. Эвал — не одноразовый гейт; это жизненный показатель, что ты держишь под наблюдением.
Оффлайн-эвалы гейтят релиз; онлайн-эвалы следят за реальностью. Первое доказывает, что изменение безопасно, второе говорит, что реально происходит.
Эвалы — это практика, а не разовое дело. Навык — начать раньше, чем чувствуешь себя готовым, вшить измерение в цикл и не дать цифре стать целью, что тебе врёт.
Сначала эвал, потом настройка
Ты калибруешь термометр, прежде чем начать крутить духовку, — иначе каждая регулировка это гадание, наряженное прогрессом.
Частая ошибка — бесконечно крутить промпт и лишь потом, может быть, строить эвал. Переверни: напиши маленький эвал до того, как оптимизируешь, чтобы каждое изменение мерилось с самого начала. Даже десять случаев бьют ноль. Настройка без эвала ощущается продуктивной и в основном не является — ты двигаешь цифры, что не видишь.
Сделай эвал гейтом в CI
Код не мёржится, если тесты падают, — и та же дисциплина не даёт тихо-худшему промпту дойти до пользователей.
Как только у тебя есть эвал, гоняй его автоматически на каждом изменении и блокируй релиз, если балл падает ниже планки. Это превращает эвалы из того, что делаешь, когда вспомнишь, в защиту, что всегда включена, — ИИ-эквивалент проходящего набора тестов. «Эвалы или это не выпущено» — стандарт, что стоит держать: неизмеренное изменение ИИ-фичи это непротестированный деплой.
Не дай метрике стать целью
Преподавание чисто под тест рождает студентов, что блестяще сдают экзамен и не могут делать работу, — балл вырос, а то, что он мерил, нет.
Когда мера становится целью, она перестаёт быть хорошей мерой — закон Гудхарта. Можно переобучить промпты под твои конкретные эвал-случаи и смотреть, как балл растёт, пока реальное качество стоит. Защищайся: держи часть случаев отложенными, освежай набор новыми продовыми сбоями и помни, что эвал — это прокси ценности для пользователя, а не сама ценность. Растущая цифра, что пользователи не чувствуют, — предупреждение, а не победа.
Начни с малого, расти со сбоями
Хороший набор тестов не пишется разом — он накапливается, по случаю на баг, пока тихо не покроет всё, что когда-либо шло не так.
Не жди идеального, всеохватного эвала — никогда не выкатишь. Начни с горстки случаев для ядрового поведения и добавляй один каждый раз, когда что-то ломается. Со временем набор растёт ровно по контурам того, где твоя система реально сбоит, а это в точности там, где тебе нужно покрытие. Эвал зреет вместе с продуктом, и он никогда по-настоящему не закончен.
- Есть ли эвал вообще — набор входов со способом оценить выводы? - Отображают ли метрики на работу, разбитые по сложности и типу сбоя, а не один ровный балл? - Включает ли набор тяжёлые, странные и ранее-сломанные случаи, взятые из реального использования? - Самый ли дешёвый надёжный метод оценки — детерминированный, где можно, валидированный судья, где нет? - Для агентов оцениваются ли шаги, а не только финальный ответ? - Гоняется ли это в CI, и как ты будешь мерить качество, когда оно вживую?
- Настройка промптов чтением пары выводов и выкаткой, когда ощущается лучше. - Единый агрегатный балл без разбивки по типу случая или сложности. - Эвал-набор только из лёгких, типичных входов — без краевых случаев, без прошлых сбоев. - LLM-судья, что ты никогда не валидировал против человеческих оценок. - Никакого мониторинга прода — о падении качества ты узнаешь из жалобы.
- Золотой набор реальных входов с известными хорошими исходами, сконцентрированный на тяжёлых случаях. - Метрики, что отображают на задачу, оценённые самым дешёвым надёжным методом и разбитые. - Оценка на уровне шагов для агентов и валидированный судья для размытых частей.
- Эвал — это гейт в CI, и регрессия добавляет случай, а не проскальзывает. - Онлайн-измерение и фидбек пользователей возвращают новые сбои назад в набор.
Эвалы — не разовый тест. Это цикл — меряй, находи сбои, вплетай их назад, — что превращает недетерминированный компонент в то, чему можно доверять и что можно улучшать.