Карта: 24 понятия в семи группах

Карта метро: сначала видишь линии целиком, потом едешь по станциям.

Сначала три основы — что такое эвал, почему настройка «на ощупь» не работает и почему последние 15% качества — это бо́льшая часть работы. Дальше шесть групп, по одной на главу: что мерить, эвал-набор, как оценивать, агенты, оффлайн и онлайн и как строить хорошо.

У каждого понятия дальше одно и то же: английское название (запомни его — это термин), образ из жизни, схема и карточка с полями: проблема, идея, пример, цена, когда брать и связи.

Eval — тест для угадывателя

Оценить эссе — не то же, что проверить сумму: нет единственной верной строки для сверки, и один и тот же промпт каждый раз даёт слегка другое эссе.

Обычный тест утверждает output === expected. LLM недетерминирована (non-deterministic) и открыта: один и тот же промпт даёт разный текст, а «верно» — часто качество, а не точная строка. Так что модель утверждения ломается. Эвал (eval) её заменяет: набор входов, у каждого — способ оценить, насколько хорош вывод, прогоняемый раз за разом, — тестирование, построенное для компонента, что не возвращает одно и то же дважды.

Tuning by vibes — настройка на ощупь

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

Без эвала ты настраиваешь промпты на ощупь (by vibes): попробовал, окинул взглядом пару выводов, отгрузил, если ощущается лучше. Ловушка в том, что ты не видишь регрессий (regressions) — изменение, что чинит один случай, часто ломает три, что ты не перепроверил. Эвал превращает «ощущается лучше» в «набрал 84% против 79%», а это разница между инженерией и гаданием.

The Last Mile — 80% быстро, 95% — это весь проект

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

Вот тяжёлая правда, ради которой эвалы и существуют: демо, что верно в 80% случаев, занимает вечер; вытягивание оттуда до 95% — это бо́льшая часть работы. Этот последний отрезок, последняя миля (last mile), находится случай за случаем — краевые входы, редкие сбои, — и найти и починить их можно, только если меришь. Эвал — это прибор, что делает долгий подъём видимым.

Эвал — это сеть от регрессий и твоя спека

Страховка позволяет скалолазу попробовать тяжёлый ход, потому что срыв не будет смертельным, — она делает смелые изменения безопасными.

Как только у тебя есть эвал, ты можешь поменять промпт, заменить модель или перестроить конвейер и сразу увидеть, помогло это или навредило. Он ловит регрессии раньше пользователей и тихо становится настоящей спецификацией (spec) «как выглядит хорошо» для твоей фичи. Без него каждое изменение — азартная игра; с ним улучшение становится циклом, что ты реально можешь крутить.

Eval Criteria — преврати «хорошо» в конкретные проверки

Экзамен по вождению не спрашивает «ты хороший водитель?» — он оценивает конкретное: подал ли сигнал, держался ли полосы, полностью ли остановился, припарковался ли в линиях.

«Качество» слишком смутно, чтобы оптимизировать. Разбей его на измеримые свойства — критерии оценки (eval criteria): был ли ответ верен, был ли заземлён в источнике, валиден ли формат, вызвал ли нужный инструмент, верны ли длина и тон? Каждое — то, что можно оценить. Навык — выбрать те немногие свойства, что реально важны для твоей задачи, а не мерить всё.

Task-specific Metrics — метрика под работу

Переводчика судишь по верности и беглости, кассира — по скорости и точности; не тот аршин — бесполезная оценка.

Разным фичам нужны разные метрики (metrics). RAG-система: извлекла ли нужные чанки и верен ли ответ им? Классификатор: точность (accuracy) против меток. Агент: выбрал ли нужные инструменты и достиг ли цели? Сводка: верна, полна, кратка. Бери метрики, что отображают, что сбой реально значит для твоей задачи, иначе будешь оптимизировать цифру, что не важна.

Faithfulness vs Correctness — верность и правильность

Студент может написать красиво аргументированный ответ, что неверен, или неуклюжий, что верен. Стиль и истина — отдельные оценки.

Два из важнейших свойств путают. Правильность (correctness) — верен ли ответ на деле; верность (faithfulness) — подкреплён ли он предоставленным контекстом без выдумки. Заземлённая система может быть верна источнику (она его использовала) и при этом неправа (источник был неверен) или права и при этом неверна источнику (угадала, а не из контекста). Измерение их отдельно говорит тебе, где сбой.

Slicing — одна цифра прячет слишком много

Средняя температура «комфортно» может прятать морозную комнату и знойную. Агрегат стирает случаи, что нужнее всего увидеть.

Единый общий балл — стартовая точка, а не картина. Разбей результаты по срезам (slicing) — по категории и сложности: лёгкие против тяжёлых, каждый тип вопроса, каждый режим сбоя, — потому что ровные 85% могут быть 100% на лёгких и 40% на тех, что важны. Ценность эвала — в разбивке, что показывает ровно, куда целиться дальше.

Golden Set — входы с известными хорошими исходами

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

Ядро эвала — золотой набор (golden set): коллекция представительных входов, у каждого — известный хороший ответ или ясное определение успеха. Это то, против чего ты оцениваешь. Его построение — реальная работа, именно здесь ты пришпиливаешь, что вообще значит «верно» для твоей фичи, — и это актив, что делает каждое будущее изменение измеримым.

Hard Cases — покрой края и известные сбои

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

Набор только из лёгких, типичных входов даёт льстивый, бесполезный балл. Намеренно включай тяжёлые случаи (hard cases): неоднозначные вопросы, краевые входы (edge cases), состязательные промпты (adversarial prompts) и особенно сбои, что ты уже видел. Каждый раз, когда баг доходит до прода, добавляй его в эвал как регрессионный случай (regression case), чтобы он не смог тихо вернуться. Набор должен концентрироваться там, где система вероятнее всего сломается.

Production Sampling — собирай реальные примеры из прода

Лучшие тестовые вопросы приходят из реального экзамена, что сдавали студенты, а не из того, что учитель вообразил, что они спросят.

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

Маленький и острый бьёт большой и затхлый

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

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

Code-based Graders — точные и правиловые проверки

Проверка теста с выбором ответа не требует суждения — ответ верен или нет, и машина оценивает его мгновенно.

Когда вывод ограничен, оценивай его детерминированно — кодом, code-based grader: точное совпадение (exact match) для классификации, регэксп или проверка схемы для формата, вызвал-ли-нужный-инструмент для агента, верна-ли-цифра для извлечения. Эти проверки дёшевы, быстры и неоспоримы. Всегда проталкивай как можно бо́льшую часть эвала в эту категорию — это самая надёжная оценка из всех.

LLM-as-Judge — модель оценивает размытое

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

Для открытых выводов — верна ли эта сводка? полезен ли этот ответ? — точного совпадения нет, так что ты используешь модель для оценки, LLM-as-judge: дай второй модели вывод, контекст и ясную рубрику (rubric) и пусть оценит. Это масштабирует человекоподобное суждение на тысячи случаев. Это стандартный инструмент для качеств, что не проверить правилом, — но он идёт с оговорками.

Judge Validation — судью тоже надо судить

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

У LLM-судьи есть режимы сбоя: он может предпочитать многословные ответы (verbosity bias), поддаваться уверенному тону или дрейфовать от твоего намерения. Так что валидируй судью против человеческих оценок на выборке, дай ему острую рубрику с примерами и держи его простым. Судья, что ты не проверил, — это просто ещё одна неизмеренная модель; не доверяй его баллам, пока не подтвердил, что они отслеживают то, что тебя реально волнует.

Human Review — люди в контуре, малыми дозами

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

Автоматическая оценка масштабируется, но периодически читай реальные выводы сам — human review. Выборочно проверяй, всматривайся в сбои и проверяй на здравость, что твои метрики всё ещё отражают реальное качество. Человеческое ревью не масштабируется на каждый случай, но малая, регулярная доза ловит то, что твои автоматические баллы упускают, — и не даёт тебе оптимизировать цифру, что отъехала от реальности.

Чистый финальный ответ может прятать сломанную середину

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

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

Trajectory Evaluation — оценивай траекторию

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

Для агентов ты оцениваешь траекторию (trajectory): на каждом шаге выбрал ли он нужный инструмент, передал ли нужные аргументы, извлёк ли нужный контекст и рассуждал ли здраво? Это ловит сломанную середину, что финальная проверка упускает, и говорит тебе, какой шаг сбоил, — куда полезнее, чем знать лишь, что конец был неверен. Шаги — вот где надёжность агента реально делается или теряется.

Step-level Checks — проверяй вызовы инструментов и извлечения напрямую

Аудит научного ассистента — это проверка, какие источники он реально вытянул и какие вызовы сделал, а не только чтение его финальной записки.

Бо́льшая часть поведения агента конкретна и оцениваема без суждения: вызвал ли он send_email, когда должен был, с верным получателем? извлёк ли релевантный документ? остался ли в пределах прав на инструменты? Это детерминированные проверки на шагах (step-level checks), дешёвые и точные, и они пришпиливают большую долю сбоев агента в точности.

Operational Metrics — меряй и скучные операционные истины

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

Помимо правильности, отслеживай операционные метрики (operational metrics) агента: сколько шагов он взял, как часто зацикливался или повторял, задержку (latency) и стоимость (cost) на задачу. Цикл, что приходит к верному ответу за двадцать дорогих шагов, когда хватило бы трёх, — это проблема надёжности и стоимости, что твой балл финального ответа не покажет. Эти цифры вскрывают агентов, что работают, но не переживут прода.

Offline Eval — гейт до выкатки

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

Оффлайн-эвал (offline eval) — это твой золотой набор, прогнанный против изменения до выкатки: набрал ли этот новый промпт или модель лучше на случаях, что ты собрал? Это контролируемо и повторяемо, место, где ты ловишь регрессии и безопасно сравниваешь варианты. Это эвал, что ты вшиваешь в цикл разработки — в идеале гейтом в CI, чтобы ничто не отгрузилось, что роняет балл.

Online Eval — измерение реального мира

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

Прод ведёт себя так, как ни один оффлайн-набор полностью не предскажет: реальные пользователи формулируют то, чего ты не вообразил, и распределение входов смещается. Так что ты меряешь и онлайн (online eval) — выбираешь и оцениваешь живые выводы, следишь за метриками качества и собираешь сигналы пользователей. Оффлайн-набор доказывает, что изменение безопасно выкатить; онлайн-измерение говорит, что реально происходит, когда оно вышло.

User Feedback — бесплатный эвал-сигнал

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

Твои пользователи оценивают тебя, собираешь ты это или нет. Лови сигналы (user feedback signals) — палец вверх/вниз, правки, повторы, отказы, эскалации — и возвращай их назад. Всплеск повторов или пальцев вниз — раннее предупреждение; конкретные сбои становятся завтрашними эвал-случаями. Это замыкает цикл: прод учит эвал-набор, как выглядит реальность, а эвал-набор защищает следующий релиз.

Drift — следи за дрейфом

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

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

Eval-driven Development — сначала эвал, потом настройка

Ты калибруешь термометр, прежде чем начать крутить духовку, — иначе каждая регулировка это гадание, наряженное прогрессом.

Частая ошибка — бесконечно крутить промпт и лишь потом, может быть, строить эвал. Переверни: напиши маленький эвал до того, как оптимизируешь, чтобы каждое изменение мерилось с самого начала, — это разработка от эвала (eval-driven development). Даже десять случаев бьют ноль. Настройка без эвала ощущается продуктивной и в основном не является — ты двигаешь цифры, что не видишь.

CI Gate — сделай эвал гейтом в CI

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

Как только у тебя есть эвал, гоняй его автоматически на каждом изменении и блокируй релиз, если балл падает ниже планки, — это гейт в CI (CI gate). Это превращает эвалы из того, что делаешь, когда вспомнишь, в защиту, что всегда включена, — ИИ-эквивалент проходящего набора тестов. «Эвалы или это не выпущено» — стандарт, что стоит держать: неизмеренное изменение ИИ-фичи это непротестированный деплой.

Goodhart's Law — не дай метрике стать целью

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

Когда мера становится целью, она перестаёт быть хорошей мерой — закон Гудхарта (Goodhart's law). Можно переобучить (overfit) промпты под твои конкретные эвал-случаи и смотреть, как балл растёт, пока реальное качество стоит. Защищайся: держи часть случаев отложенными (held-out), освежай набор новыми продовыми сбоями и помни, что эвал — это прокси ценности для пользователя, а не сама ценность. Растущая цифра, что пользователи не чувствуют, — предупреждение, а не победа.

Начни с малого, расти со сбоями

Хороший набор тестов не пишется разом — он накапливается, по случаю на баг, пока тихо не покроет всё, что когда-либо шло не так.

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

Как понятия связаны

Колесо, что крутится: каждый оборот делает набор честнее, а релиз — безопаснее.

Всё в курсе — части одного цикла. Критерии говорят, что мерить; golden set — на чём; graders (код, судья, человек) ставят балл. Offline eval с CI gate охраняет релиз, online eval смотрит за реальностью — фидбек и дрейф, — а найденные сбои становятся новыми случаями и возвращаются в набор. Для агентов оценивается траектория, а закон Гудхарта напоминает: балл — только прокси.