# Без эвала ты настраиваешь на ощупь Экспресс-курс об оценке ИИ-систем. 24 понятия — eval, golden set, eval criteria, faithfulness и correctness, LLM-as-judge, trajectory evaluation, offline и online evals, drift, CI gate, закон Гудхарта и другие — у каждого английское название, схема, пример и карточка. В конце — шпаргалка по всем понятиям на одной странице. Суть: нельзя улучшить то, что не меришь, а дойти до 95% — это бо́льшая часть работы. - **Author:** Фёдор Чищин - **Level:** intermediate - **Reading time:** ~35 минут чтения - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/ru/learn/evals-express --- ## 1. Зачем нужны эвалы Обычный код можно юнит-тестировать, потому что один и тот же ввод даёт один и тот же вывод. LLM это ломает, так что нужен другой вид теста — а без него ты летишь вслепую. ### Карта: 24 понятия в семи группах > Карта метро: сначала видишь линии целиком, потом едешь по станциям. Сначала три **основы** — что такое эвал, почему настройка «на ощупь» не работает и почему последние 15% качества — это бо́льшая часть работы. Дальше шесть групп, по одной на главу: **что мерить**, **эвал-набор**, **как оценивать**, **агенты**, **оффлайн и онлайн** и как **строить хорошо**. У каждого понятия дальше одно и то же: **английское название** (запомни его — это термин), образ из жизни, **схема** и **карточка** с полями: _проблема_, _идея_, _пример_, _цена_, _когда брать_ и _связи_. _Diagram: Основы сверху, ниже — шесть групп, по ним идут главы 2–7._ ### Eval — тест для угадывателя > Оценить эссе — не то же, что проверить сумму: нет единственной верной строки для сверки, и один и тот же промпт каждый раз даёт слегка другое эссе. Обычный тест утверждает `output === expected`. LLM **недетерминирована (non-deterministic)** и открыта: один и тот же промпт даёт разный текст, а «верно» — часто качество, а не точная строка. Так что модель утверждения ломается. **Эвал (eval)** её заменяет: набор входов, у каждого — способ _оценить_, насколько хорош вывод, прогоняемый раз за разом, — тестирование, построенное для компонента, что не возвращает одно и то же дважды. _Diagram: Обычный код: один вход — один выход — assert. LLM: один вход — разные ответы, поэтому их оценивают баллом, а не сверкой строки._ #### Eval (эвал, оценка ИИ-системы) - **Проблема:** LLM недетерминирована: `output === expected` не работает, «верно» — это качество. - **Идея:** Набор входов + способ оценить каждый вывод + прогон на каждом изменении. - **Пример:** Сто вопросов к саппорт-боту, у каждого — признак хорошего ответа; итог — «84% прошли». - **Цена:** Время на сбор случаев и на способы оценки. - **Когда брать:** Для любой фичи, где в цепочке есть LLM. - **Связи:** Строится на **golden set**, оценивается **graders**, гоняется в **CI gate**. ### Tuning by vibes — настройка на ощупь > Повар, что никогда не пробует блюдо, а просто крутит рецепт и надеется, — он не может понять, помогло ли вчерашнее изменение или тихо его испортило. Без эвала ты настраиваешь промпты **на ощупь (by vibes)**: попробовал, окинул взглядом пару выводов, отгрузил, если ощущается лучше. Ловушка в том, что ты не видишь **регрессий (regressions)** — изменение, что чинит один случай, часто ломает три, что ты не перепроверил. Эвал превращает «ощущается лучше» в «набрал 84% против 79%», а это разница между инженерией и гаданием. _Diagram: Новая версия промпта чинит случай, на который ты смотрел, и тихо ломает три других. Глазами этого не увидеть._ #### Tuning by Vibes (настройка на ощупь) - **Что это:** Меняешь промпт, смотришь пару выводов, выкатываешь, если «кажется лучше». - **Почему плохо:** Не видно регрессий: починил один случай — сломал три. - **Пример:** «Вроде стало лучше» вместо «84% против 79%». - **Лекарство:** Даже маленький **eval**, прогнанный до и после изменения. - **Связи:** Противоположность **Eval-driven Development**. ### The Last Mile — 80% быстро, 95% — это весь проект > Первый черновик чего угодно приходит быстро. Превращение грубого черновика в надёжное — вот куда уходит реальное время. Вот тяжёлая правда, ради которой эвалы и существуют: демо, что верно в **80% случаев, занимает вечер; вытягивание оттуда до 95% — это бо́льшая часть работы.** Этот последний отрезок, **последняя миля (last mile)**, находится случай за случаем — краевые входы, редкие сбои, — и найти и починить их можно, только если меришь. Эвал — это прибор, что делает долгий подъём видимым. _Diagram: До 80% — быстрый подъём за вечер. От 80% до 95% — долгая работа, случай за случаем._ #### The Last Mile (80% → 95%, последняя миля) - **Что это:** Первые 80% качества приходят быстро, оставшиеся 15% — бо́льшая часть работы. - **Почему так:** Остаток — это краевые входы и редкие сбои, их находят только по одному. - **Пример:** Демо за вечер работает; продукт на нём — недели доводки. - **Следствие:** Без измерения этот подъём не виден и не управляем. - **Связи:** Его делают видимым **eval**, **hard cases** и **slicing**. ### Эвал — это сеть от регрессий и твоя спека > Страховка позволяет скалолазу попробовать тяжёлый ход, потому что срыв не будет смертельным, — она делает смелые изменения безопасными. Как только у тебя есть эвал, ты можешь поменять промпт, заменить модель или перестроить конвейер и **сразу увидеть, помогло это или навредило.** Он ловит регрессии раньше пользователей и тихо становится настоящей **спецификацией (spec)** «как выглядит хорошо» для твоей фичи. Без него каждое изменение — азартная игра; с ним улучшение становится циклом, что ты реально можешь крутить. _Diagram: Любое изменение — промпт, модель, конвейер — проходит через тот же эвал и сразу показывает: помогло или навредило._ > **Вопрос рамки:** «Когда я меняю этот промпт или модель, как я узна́ю — цифрой, а не ощущением, — стало лучше или хуже?» > Недетерминированный компонент не юнит-тестируется. Эвал оценивает его вместо этого — а без него каждое изменение это догадка. ## 2. Что мерить «Оно хорошее?» не измеримо. Первая реальная работа эвалов — превратить этот смутный вопрос в конкретные вещи, что ты можешь оценить, выбранные под работу, что делает твоя фича. ### Eval Criteria — преврати «хорошо» в конкретные проверки > Экзамен по вождению не спрашивает «ты хороший водитель?» — он оценивает конкретное: подал ли сигнал, держался ли полосы, полностью ли остановился, припарковался ли в линиях. «Качество» слишком смутно, чтобы оптимизировать. Разбей его на **измеримые свойства — критерии оценки (eval criteria)**: был ли ответ верен, был ли заземлён в источнике, валиден ли формат, вызвал ли нужный инструмент, верны ли длина и тон? Каждое — то, что можно оценить. Навык — выбрать те немногие свойства, что реально важны для _твоей_ задачи, а не мерить всё. _Diagram: Смутное «оно хорошее?» распадается на конкретные проверки, и у каждой свой балл._ #### Eval Criteria (критерии оценки, измеримые свойства) - **Проблема:** «Оно хорошее?» нельзя измерить и нельзя оптимизировать. - **Идея:** Разбить качество на свойства: верность, заземлённость, формат, инструмент, длина и тон. - **Пример:** «JSON валиден по схеме», «ответ опирается на найденный документ». - **Цена:** Нужно решить, что важно, — и честно отказаться от остального. - **Связи:** Выбор критериев — это **task-specific metrics**; проверяют их **graders**. ### Task-specific Metrics — метрика под работу > Переводчика судишь по верности и беглости, кассира — по скорости и точности; не тот аршин — бесполезная оценка. Разным фичам нужны разные **метрики (metrics)**. **RAG**-система: извлекла ли нужные чанки и верен ли ответ им? **Классификатор**: точность (accuracy) против меток. **Агент**: выбрал ли нужные инструменты и достиг ли цели? **Сводка**: верна, полна, кратка. Бери метрики, что отображают, что сбой реально значит для твоей задачи, иначе будешь оптимизировать цифру, что не важна. _Diagram: Тип фичи определяет метрику: у RAG, классификатора, агента и сводки разные аршины._ #### Task-specific Metrics (метрики под задачу) - **Проблема:** Общая метрика «для всего» меряет не то, что ломается у тебя. - **Идея:** Метрика отражает, что значит сбой для этой конкретной фичи. - **Пример:** RAG — нужные чанки и верность им; классификатор — accuracy; агент — инструменты и цель. - **Цена:** Под каждую фичу метрики приходится продумывать отдельно. - **Связи:** Конкретизирует **eval criteria**; агентам добавляет **trajectory**. ### Faithfulness vs Correctness — верность и правильность > Студент может написать красиво аргументированный ответ, что неверен, или неуклюжий, что верен. Стиль и истина — отдельные оценки. Два из важнейших свойств путают. **Правильность (correctness)** — верен ли ответ на деле; **верность (faithfulness)** — подкреплён ли он предоставленным контекстом без выдумки. Заземлённая система может быть верна источнику (она его использовала) и при этом неправа (источник был неверен) или права и при этом неверна источнику (угадала, а не из контекста). Измерение их отдельно говорит тебе, _где_ сбой. _Diagram: Две оси дают четыре исхода. Каждый указывает на своё место поломки: поиск, заземление или всё сразу._ #### Faithfulness vs Correctness (верность и правильность) - **Что это:** Correctness — ответ верен. Faithfulness — ответ взят из данного контекста, без выдумки. - **Почему важно:** Разные сбои лечатся в разных местах. - **Пример:** Верен источнику, но неправ — чини данные или поиск. Прав, но не из источника — чини заземление. - **Подвох:** Один общий балл «качества» смешивает оба и прячет причину. - **Связи:** Главная пара метрик для **RAG**; часто оценивается **LLM-as-judge**. ### Slicing — одна цифра прячет слишком много > Средняя температура «комфортно» может прятать морозную комнату и знойную. Агрегат стирает случаи, что нужнее всего увидеть. Единый общий балл — стартовая точка, а не картина. Разбей результаты **по срезам (slicing)** — по категории и сложности: лёгкие против тяжёлых, каждый тип вопроса, каждый режим сбоя, — потому что ровные 85% могут быть 100% на лёгких и 40% на тех, что важны. Ценность эвала — в разбивке, что показывает ровно, куда целиться дальше. _Diagram: Общие 85% выглядят прилично, пока не разобьёшь: на лёгких 100%, на важных — 40%._ #### Slicing (разбивка по срезам) - **Проблема:** Средний балл стирает случаи, где система реально падает. - **Идея:** Считать балл отдельно по категории, сложности, режиму сбоя. - **Пример:** 85% в целом = 100% на лёгких + 40% на тяжёлых. - **Цена:** Случаи в наборе надо размечать по категориям. - **Связи:** Показывает, куда идти на **last mile**; опирается на разметку **golden set**. > **Вопрос измерения:** «Какие конкретные, оцениваемые свойства определяют хороший вывод здесь — и отображают ли они на деле то, чего сбой стоит моим пользователям?» > «Оно хорошее?» — не метрика. Разбей качество на конкретные, оцениваемые свойства под свою задачу — и никогда не доверяй единой агрегатной цифре. ## 3. Построение эвал-набора Эвал честен ровно настолько, насколько примеры в нём. Датасет — входы и их известные хорошие исходы — это настоящий актив, и бо́льшая часть заботы идёт сюда. ### Golden Set — входы с известными хорошими исходами > Ключ ответов учителя — вопросы в паре с тем, как выглядит верный ответ, чтобы оценка была последовательной, а не по настроению. Ядро эвала — **золотой набор (golden set)**: коллекция представительных входов, у каждого — известный хороший ответ или ясное определение успеха. Это то, против чего ты оцениваешь. Его построение — реальная работа, именно здесь ты пришпиливаешь, что вообще значит «верно» для твоей фичи, — и это актив, что делает каждое будущее изменение измеримым. _Diagram: Золотой набор — таблица: реальный вход и известный хороший исход. Против неё оценивается каждое изменение._ #### Golden Set (золотой набор, эвал-датасет) - **Проблема:** Без эталона нечем сравнивать выводы — оценка идёт по настроению. - **Идея:** Представительные входы, у каждого — хороший ответ или ясный критерий успеха. - **Пример:** «Отмени подписку» → должен вызвать `cancel_subscription`; «asdf??» → уточняющий вопрос. - **Цена:** Реальная работа: решить, что значит «верно», для каждого случая. - **Связи:** Наполняется **hard cases** и **production sampling**; по нему гоняется **offline eval**. ### Hard Cases — покрой края и известные сбои > Мост нагружают-испытывают самыми тяжёлыми грузовиками и худшими штормами, а не средней машиной в солнечный день. Набор только из лёгких, типичных входов даёт льстивый, бесполезный балл. Намеренно включай **тяжёлые случаи (hard cases)**: неоднозначные вопросы, **краевые входы (edge cases)**, **состязательные промпты (adversarial prompts)** и особенно сбои, что ты уже видел. Каждый раз, когда баг доходит до прода, добавляй его в эвал как **регрессионный случай (regression case)**, чтобы он не смог тихо вернуться. Набор должен концентрироваться там, где система вероятнее всего сломается. _Diagram: Льстивый набор — только типичные входы. Честный — плюс неоднозначные, краевые, состязательные и прошлые баги._ #### Hard Cases (edge cases, adversarial, regression cases) - **Проблема:** Набор из лёгких случаев даёт красивый и бесполезный балл. - **Идея:** Нарочно добавлять неоднозначное, краевое, состязательное и всё, что уже ломалось. - **Пример:** Баг дошёл до прода → его вход становится постоянным случаем в наборе. - **Цена:** Балл падает — зато становится честным. - **Связи:** Часть **golden set**; источник случаев — **production sampling**. ### Production Sampling — собирай реальные примеры из прода > Лучшие тестовые вопросы приходят из реального экзамена, что сдавали студенты, а не из того, что учитель вообразил, что они спросят. Богатейший источник эвал-случаев — **реальное использование**: что пользователи на деле спрашивали, особенно то, что спросили и что пошло не так. Майни свои логи и фидбек на реальные входы и вплетай их в набор. Выдуманные примеры отражают то, что ты _думаешь_, происходит; продовые отражают то, что _происходит_, включая грязные формулировки и странные запросы, что ты бы и не выдумал. _Diagram: Пользователи → логи и фидбек → отбор случаев, особенно сбоев → золотой набор._ #### Production Sampling (случаи из реального использования) - **Проблема:** Выдуманные примеры отражают то, что ты думаешь, а не то, что есть. - **Идея:** Брать входы из логов и фидбека, особенно те, где что-то пошло не так. - **Пример:** Грязная формулировка пользователя, которую ты бы сам не придумал. - **Цена:** Нужны логи, а данные пользователей надо чистить от личного. - **Связи:** Питает **golden set**; сигналы приходят из **user feedback**. ### Маленький и острый бьёт большой и затхлый > Пятьдесят хорошо подобранных вопросов, что прощупывают реальные слабые места, учат тебя большему, чем тысяча случайных, в которые ты толком не смотришь. Не нужны тысячи случаев, чтобы начать, — пары десятков **хорошо подобранных**, покрывающих главные поведения и известные режимы сбоя, хватит, чтобы ловить большинство регрессий и направлять настройку. Начни с малого, держи честно и расти его по мере того, как узнаёшь, где система ломается. Эвал, что ты реально гоняешь, бьёт огромный, что не гоняешь. > **Вопрос датасета:** «Включает ли мой эвал-набор тяжёлые, странные и ранее-сломанные случаи — или только лёгкие, что льстят баллу?» > Золотой набор — это актив. Спаривай реальные входы с известными хорошими исходами, концентрируйся на тяжёлом и сломанном и расти его по мере того, как узнаёшь. ## 4. Как оценивать Когда у тебя есть входы и ожидания, нужен способ оценить каждый вывод. Методы идут от дешёвых и точных до гибких и ошибающихся — и ты тянешься к самому дешёвому, что подходит. ### Code-based Graders — точные и правиловые проверки > Проверка теста с выбором ответа не требует суждения — ответ верен или нет, и машина оценивает его мгновенно. Когда вывод ограничен, оценивай его **детерминированно** — кодом, **code-based grader**: точное совпадение (exact match) для классификации, регэксп или проверка схемы для формата, вызвал-ли-нужный-инструмент для агента, верна-ли-цифра для извлечения. Эти проверки дёшевы, быстры и неоспоримы. Всегда проталкивай как можно бо́льшую часть эвала в эту категорию — это самая надёжная оценка из всех. _Diagram: Лестница оценщиков: слева дёшево и точно, справа гибко, дорого и с ошибками. Тянись к самой левой ступени, что подходит._ #### Code-based Grader (детерминированная проверка, exact match) - **Проблема:** Суждение дорого и спорно там, где ответ можно просто сверить. - **Идея:** Проверить вывод кодом: совпадение, регэксп, схема, нужный вызов. - **Пример:** Метка класса совпала; JSON прошёл схему; агент вызвал нужный инструмент. - **Цена:** Работает только для ограниченных выводов — эссе так не проверишь. - **Связи:** Первая ступень лестницы; для размытого — **LLM-as-judge**, для агентов — **step-level checks**. ### LLM-as-Judge — модель оценивает размытое > Для эссе ты приводишь второго экзаменатора с ясной рубрикой — суждение, но направленное явными критериями, чтобы оно было последовательным. Для открытых выводов — верна ли эта сводка? полезен ли этот ответ? — точного совпадения нет, так что ты используешь модель для оценки, **LLM-as-judge**: дай второй модели вывод, контекст и ясную **рубрику (rubric)** и пусть оценит. Это масштабирует человекоподобное суждение на тысячи случаев. Это стандартный инструмент для качеств, что не проверить правилом, — но он идёт с оговорками. _Diagram: Судья получает вывод, контекст и рубрику — и возвращает балл с коротким объяснением._ #### LLM-as-Judge (модель-судья) - **Проблема:** Открытые выводы не сверить со строкой, а людей на тысячи случаев не хватит. - **Идея:** Вторая модель оценивает вывод по контексту и явной рубрике. - **Пример:** «Верна ли сводка источнику? Оцени 1–5 и объясни одной фразой». - **Цена:** Судья сам ошибается и предвзят — его надо проверять. - **Связи:** Без **judge validation** ему нельзя верить; часто меряет **faithfulness**. ### Judge Validation — судью тоже надо судить > Второй рефери может быть предвзят — благоволить ответу подлиннее или тому, что звучит уверенно, — так что ты сверяешь рефери с парой человеческих решений, прежде чем ему доверять. У LLM-судьи есть режимы сбоя: он может предпочитать многословные ответы (**verbosity bias**), поддаваться уверенному тону или дрейфовать от твоего намерения. Так что **валидируй судью против человеческих оценок** на выборке, дай ему острую рубрику с примерами и держи его простым. Судья, что ты не проверил, — это просто ещё одна неизмеренная модель; не доверяй его баллам, пока не подтвердил, что они отслеживают то, что тебя реально волнует. _Diagram: Одну выборку оценивают и люди, и судья. Совпадают — судье можно доверять. Следи за его типичными перекосами._ #### Judge Validation (проверка судьи против людей) - **Проблема:** Судья любит длинные и уверенные ответы и может уйти от твоего намерения. - **Идея:** Сравнить баллы судьи с человеческими на выборке, до того как верить. - **Пример:** Пара десятков случаев оценены людьми; судья совпадает — значит, ему можно верить. - **Цена:** Немного ручной разметки и перепроверка при смене судьи или рубрики. - **Связи:** Обязательная пара к **LLM-as-judge**; использует **human review**. ### Human Review — люди в контуре, малыми дозами > Даже с автоматической оценкой шеф всё равно пробует еду — быстрая выборочная проверка, что приборы тихо не разошлись. Автоматическая оценка масштабируется, но периодически **читай реальные выводы сам — human review.** Выборочно проверяй, всматривайся в сбои и проверяй на здравость, что твои метрики всё ещё отражают реальное качество. Человеческое ревью не масштабируется на каждый случай, но малая, регулярная доза ловит то, что твои автоматические баллы упускают, — и не даёт тебе оптимизировать цифру, что отъехала от реальности. #### Human Review (ручная выборочная проверка) - **Проблема:** Автоматические баллы могут тихо разойтись с реальным качеством. - **Идея:** Регулярно читать выборку реальных выводов, особенно сбои. - **Пример:** Раз в неделю прочитать случаи, где балл упал, и проверить, согласен ли ты. - **Цена:** Время людей — поэтому малыми дозами, не на каждый случай. - **Связи:** Последняя ступень лестницы оценщиков; основа **judge validation**. > **Вопрос оценки:** «Каждая ли проверка — самый дешёвый надёжный метод для того, что она меряет, — и если судья это модель, проверил ли я судью против человеческих решений?» > Оценивай детерминированно, где можешь, используй LLM-судью для размытого остатка — и валидируй судью, потому что непроверенный оценщик — просто ещё одна догадка. ## 5. Эвалы на уровне шагов для агентов Агентам нужно больше, чем оценка финального ответа, потому что они могут прийти к чистому ответу через сломанный процесс. Чтобы доверять агенту, ты меряешь путь, а не только пункт назначения. ### Чистый финальный ответ может прятать сломанную середину > Экзамен по математике, оценённый лишь по финальной цифре, пропускает студента, что пришёл к ней через две взаимно сокращающиеся ошибки, — ты не узнаёшь ничего о том, что реально случилось. В многошаговом агенте **промежуточная ошибка может пройти проверку финального вывода**, испортив процесс: он достаёт нужный источник, на полпути приписывает факт не туда и пишет чистую сводку, что неверна. Оценивай только финальный ответ — и ты это пропустишь. Сбои, что нужнее всего поймать, — те, к которым проверка-только-пункта-назначения слепее всего. _Diagram: Ошибка случилась на шаге «Extract», но сводка гладкая — и проверка только финала её пропускает._ ### Trajectory Evaluation — оценивай траекторию > Экзаменатор по вождению смотрит всю поездку — каждый сигнал, проверку зеркал и смену полосы, — а не только прибыл ли ты по адресу. Для агентов ты оцениваешь **траекторию (trajectory)**: на каждом шаге выбрал ли он нужный инструмент, передал ли нужные аргументы, извлёк ли нужный контекст и рассуждал ли здраво? Это ловит сломанную середину, что финальная проверка упускает, и говорит тебе, _какой шаг_ сбоил, — куда полезнее, чем знать лишь, что конец был неверен. Шаги — вот где надёжность агента реально делается или теряется. _Diagram: Проверка каждого шага показывает, где именно сломалось. Проверка только финала видит лишь последнюю коробку._ #### Trajectory Evaluation (оценка траектории агента) - **Проблема:** Верный финал может скрывать неверные шаги. - **Идея:** Оценивать каждый шаг: инструмент, аргументы, извлечённый контекст, рассуждение. - **Пример:** Шаги 1–2 верны, на шаге 3 агент взял не тот контекст — эвал называет шаг 3. - **Цена:** Нужно логировать и размечать шаги, а не только ответ. - **Связи:** Состоит из **step-level checks**; дополняется **operational metrics**. ### Step-level Checks — проверяй вызовы инструментов и извлечения напрямую > Аудит научного ассистента — это проверка, какие источники он реально вытянул и какие вызовы сделал, а не только чтение его финальной записки. Бо́льшая часть поведения агента конкретна и оцениваема без суждения: вызвал ли он `send_email`, когда должен был, с верным получателем? извлёк ли релевантный документ? остался ли в пределах прав на инструменты? Это **детерминированные проверки на шагах (step-level checks)**, дешёвые и точные, и они пришпиливают большую долю сбоев агента в точности. #### Step-level Checks (проверки вызовов инструментов) - **Что это:** Код-проверки конкретных шагов агента, без судьи. - **Как работает:** Сверить: какой инструмент вызван, с какими аргументами, какой документ извлечён. - **Пример:** `send_email` вызван, получатель верный, прав не превышено. - **Плюс:** Дёшево, точно и сразу показывает место сбоя. - **Связи:** Это **code-based graders**, применённые к **trajectory**. ### Operational Metrics — меряй и скучные операционные истины > Службу доставки судят не только по тому, прибыла ли посылка, но по тому, сколько заняло, сколько попыток и сколько стоило. Помимо правильности, отслеживай **операционные метрики (operational metrics)** агента: сколько шагов он взял, как часто зацикливался или повторял, **задержку (latency)** и **стоимость (cost)** на задачу. Цикл, что приходит к верному ответу за двадцать дорогих шагов, когда хватило бы трёх, — это проблема надёжности и стоимости, что твой балл финального ответа не покажет. Эти цифры вскрывают агентов, что работают, но не переживут прода. _Diagram: Оба запуска дали верный ответ. Но один — за три шага, другой — за двадцать, с циклами и повторами._ #### Operational Metrics (шаги, циклы, задержка, стоимость) - **Проблема:** Балл за финальный ответ не видит, какой ценой он получен. - **Идея:** Считать шаги, циклы и повторы, задержку и стоимость на задачу. - **Пример:** Верный ответ за 20 дорогих шагов там, где хватило бы трёх. - **Цена:** Нужна трассировка каждого запуска. - **Связи:** Дополняет **trajectory evaluation**; в проде за ними следит **online eval**. > **Вопрос уровня шагов:** «Я проверяю, как этот агент пришёл к ответу — инструменты, извлечения, шаги, — или только то, выглядел ли финальный вывод верным?» > Агент может прийти к чистому ответу через сломанный процесс. Оценивай траекторию — инструменты, извлечения, шаги, — а не только пункт назначения. ## 6. Оффлайн и онлайн Эвалы бывают двух видов, что делают разную работу: набор тестов, что гоняешь до выкатки, и измерение, что держишь работающим в проде. Нужны оба, потому что мир — не твой тестовый набор. ### Offline Eval — гейт до выкатки > Тестовый трек, где ты прогоняешь машину через испытания, прежде чем она хоть раз повезёт пассажира, — контролируемо, повторяемо, до релиза. **Оффлайн-эвал (offline eval)** — это твой золотой набор, прогнанный против изменения до выкатки: набрал ли этот новый промпт или модель лучше на случаях, что ты собрал? Это контролируемо и повторяемо, место, где ты ловишь регрессии и безопасно сравниваешь варианты. Это эвал, что ты вшиваешь в цикл разработки — в идеале **гейтом в CI**, чтобы ничто не отгрузилось, что роняет балл. _Diagram: Слева от релиза — оффлайн: золотой набор, балл против базы, гейт. Справа — онлайн: живой трафик, выборка, дашборд._ #### Offline Eval (оффлайн-эвал, до релиза) - **Проблема:** Нужно знать, что изменение безопасно, до того как его увидят пользователи. - **Идея:** Прогнать золотой набор на новой версии и сравнить с базой. - **Пример:** Новый промпт: 84% против 79% у старого — можно выкатывать. - **Цена:** Видит только то, что есть в наборе, — мир шире. - **Связи:** Работает на **golden set**; автоматизируется **CI gate**; пара к **online eval**. ### Online Eval — измерение реального мира > Как бы хорош ни был тестовый трек, ты всё равно мониторишь машины, когда они на реальных дорогах, — потому что у реальных дорог есть ямы, которых у трека не было. Прод ведёт себя так, как ни один оффлайн-набор полностью не предскажет: реальные пользователи формулируют то, чего ты не вообразил, и распределение входов смещается. Так что ты меряешь и **онлайн (online eval)** — выбираешь и оцениваешь живые выводы, следишь за метриками качества и собираешь сигналы пользователей. Оффлайн-набор доказывает, что изменение безопасно выкатить; онлайн-измерение говорит, что реально происходит, когда оно вышло. _Diagram: Живые выводы идут через выборку и оценку в метрики качества, за которыми ты следишь._ #### Online Eval (онлайн-эвал, мониторинг качества) - **Проблема:** Реальные пользователи и входы не совпадают с тестовым набором. - **Идея:** Брать выборку живых выводов, оценивать её и следить за метриками. - **Пример:** Часть ответов в проде прогоняется через судью; результат — на дашборде. - **Цена:** Инфраструктура оценки в проде и стоимость судьи на трафике. - **Связи:** Ловит **drift**; собирает **user feedback**; находит новые **hard cases**. ### User Feedback — бесплатный эвал-сигнал > Кнопка «палец вверх» и ящик жалоб — это непрерывный, бесплатный опрос о том, реально ли штука работает для тех, кто ею пользуется. Твои пользователи оценивают тебя, собираешь ты это или нет. Лови **сигналы (user feedback signals)** — **палец вверх/вниз, правки, повторы, отказы, эскалации** — и возвращай их назад. Всплеск повторов или пальцев вниз — раннее предупреждение; конкретные сбои становятся завтрашними эвал-случаями. Это замыкает цикл: прод учит эвал-набор, как выглядит реальность, а эвал-набор защищает следующий релиз. _Diagram: Замкнутый цикл: прод даёт сигналы, сбои становятся случаями, набор защищает следующий релиз._ #### User Feedback Signals (сигналы пользователей) - **Что это:** Палец вверх/вниз, правки, повторы, отказы, эскалации. - **Зачем:** Бесплатная, непрерывная оценка от тех, кто реально пользуется. - **Пример:** Всплеск повторов после релиза — раннее предупреждение. - **Подвох:** Сигналы шумные: это повод посмотреть, а не готовый балл. - **Связи:** Часть **online eval**; превращается в **hard cases** в **golden set**. ### Drift — следи за дрейфом > Весы медленно уходят из калибровки — ничего драматичного, просто каждое показание чуть больше мимо, пока однажды цифры не станут неверными. Система, что набирала хорошо, может **деградировать тихо** — это **дрейф (drift)**: провайдер модели обновляется, твои данные смещаются, паттерны использования меняются. Без постоянного онлайн-измерения ты узнаёшь это от злых пользователей, а не с дашборда. Отслеживай качество во времени, чтобы дрейф проявлялся трендом, на который можно реагировать, а не сюрпризом. Эвал — не одноразовый гейт; это жизненный показатель, что ты держишь под наблюдением. _Diagram: Качество тихо сползает после обновления провайдера и смены поведения пользователей. Порог ловит это раньше жалоб._ #### Drift (дрейф качества) - **Что это:** Медленное, тихое падение качества без изменений с твоей стороны. - **Причины:** Обновление модели у провайдера, сдвиг данных, новые паттерны использования. - **Пример:** Каждую неделю чуть хуже — пока жалоба не придёт раньше дашборда. - **Лекарство:** Следить за качеством во времени и ставить порог-тревогу. - **Связи:** Ловится **online eval**; новые сбои уходят в **golden set**. > **Вопрос онлайна:** «Когда это выкатится, как я узна́ю, что его реальное качество падает, — из метрики, что я слежу, или из жалобы клиента?» > Оффлайн-эвалы гейтят релиз; онлайн-эвалы следят за реальностью. Первое доказывает, что изменение безопасно, второе говорит, что реально происходит. ## 7. Строить хорошо Эвалы — это практика, а не разовое дело. Навык — начать раньше, чем чувствуешь себя готовым, вшить измерение в цикл и не дать цифре стать целью, что тебе врёт. ### Eval-driven Development — сначала эвал, потом настройка > Ты калибруешь термометр, прежде чем начать крутить духовку, — иначе каждая регулировка это гадание, наряженное прогрессом. Частая ошибка — бесконечно крутить промпт и лишь потом, может быть, строить эвал. Переверни: **напиши маленький эвал до того, как оптимизируешь**, чтобы каждое изменение мерилось с самого начала, — это **разработка от эвала (eval-driven development)**. Даже десять случаев бьют ноль. Настройка без эвала ощущается продуктивной и в основном не является — ты двигаешь цифры, что не видишь. #### Eval-driven Development (сначала эвал, потом настройка) - **Проблема:** Промпт крутят неделями, а эвал — «потом, может быть». - **Идея:** Маленький эвал — до первой оптимизации; каждое изменение мерится. - **Пример:** Десять случаев сегодня, прогон перед каждой правкой промпта. - **Цена:** Час в начале, пока ничего «не работает». - **Связи:** Лекарство от **tuning by vibes**; дальше растёт в **CI gate**. ### CI Gate — сделай эвал гейтом в CI > Код не мёржится, если тесты падают, — и та же дисциплина не даёт тихо-худшему промпту дойти до пользователей. Как только у тебя есть эвал, **гоняй его автоматически на каждом изменении** и блокируй релиз, если балл падает ниже планки, — это **гейт в CI (CI gate)**. Это превращает эвалы из того, что делаешь, когда вспомнишь, в защиту, что всегда включена, — ИИ-эквивалент проходящего набора тестов. «Эвалы или это не выпущено» — стандарт, что стоит держать: неизмеренное изменение ИИ-фичи это непротестированный деплой. _Diagram: Каждое изменение прогоняет эвал. Балл не ниже планки — выкатка; упал — блок._ #### CI Gate (эвал как гейт в CI) - **Проблема:** Эвал, что гоняют «когда вспомнят», не ловит тихо-худший промпт. - **Идея:** Прогон на каждом изменении; балл ниже планки — релиз заблокирован. - **Пример:** PR с правкой промпта не мёржится, пока эвал не прошёл. - **Цена:** Время и деньги на прогон набора в каждом PR. - **Связи:** Автоматизирует **offline eval**; ловит регрессии до прода. ### Goodhart's Law — не дай метрике стать целью > Преподавание чисто под тест рождает студентов, что блестяще сдают экзамен и не могут делать работу, — балл вырос, а то, что он мерил, нет. Когда мера становится целью, она перестаёт быть хорошей мерой — **закон Гудхарта (Goodhart's law).** Можно **переобучить (overfit)** промпты под твои конкретные эвал-случаи и смотреть, как балл растёт, пока реальное качество стоит. Защищайся: держи часть случаев **отложенными (held-out)**, освежай набор новыми продовыми сбоями и помни, что эвал — это _прокси_ ценности для пользователя, а не сама ценность. Растущая цифра, что пользователи не чувствуют, — предупреждение, а не победа. _Diagram: Балл эвала растёт с каждой итерацией, а реальная ценность встала. Разрыв — переобучение под набор._ #### Goodhart's Law (закон Гудхарта) - **Что это:** Когда мера становится целью, она перестаёт быть хорошей мерой. - **Как проявляется:** Промпт подогнан под эвал-случаи: балл растёт, качество — нет. - **Пример:** +10 пунктов на наборе, а пользователи разницы не замечают. - **Защита:** Отложенные случаи, свежие продовые сбои, помнить, что балл — прокси. - **Связи:** Лечится **production sampling** и **human review**. ### Начни с малого, расти со сбоями > Хороший набор тестов не пишется разом — он накапливается, по случаю на баг, пока тихо не покроет всё, что когда-либо шло не так. Не жди идеального, всеохватного эвала — никогда не выкатишь. Начни с горстки случаев для ядрового поведения и **добавляй один каждый раз, когда что-то ломается.** Со временем набор растёт ровно по контурам того, где твоя система реально сбоит, а это в точности там, где тебе нужно покрытие. Эвал зреет вместе с продуктом, и он никогда по-настоящему не закончен. ### Как понятия связаны > Колесо, что крутится: каждый оборот делает набор честнее, а релиз — безопаснее. Всё в курсе — части одного цикла. **Критерии** говорят, что мерить; **golden set** — на чём; **graders** (код, судья, человек) ставят балл. **Offline eval** с **CI gate** охраняет релиз, **online eval** смотрит за реальностью — фидбек и дрейф, — а найденные сбои становятся **новыми случаями** и возвращаются в набор. Для агентов оценивается **траектория**, а **закон Гудхарта** напоминает: балл — только прокси. _Diagram: Цикл эвалов: критерии → набор → оценщики → гейт → онлайн → новые случаи → снова набор._ #### Прежде чем выкатывать ИИ-фичу - **Есть ли эвал вообще** — набор входов со способом оценить выводы? - **Отображают ли метрики на работу**, разбитые по сложности и типу сбоя, а не один ровный балл? - **Включает ли набор** тяжёлые, странные и ранее-сломанные случаи, взятые из реального использования? - **Самый ли дешёвый надёжный метод оценки** — детерминированный, где можно, валидированный судья, где нет? - **Для агентов оцениваются ли шаги**, а не только финальный ответ? - **Гоняется ли это в CI**, и как ты будешь мерить качество, когда оно вживую? #### Признаки, что ты летишь вслепую - Настройка промптов **чтением пары выводов** и выкаткой, когда ощущается лучше. - **Единый агрегатный балл** без разбивки по типу случая или сложности. - Эвал-набор только из **лёгких, типичных** входов — без краевых случаев, без прошлых сбоев. - **LLM-судья, что ты никогда не валидировал** против человеческих оценок. - **Никакого мониторинга прода** — о падении качества ты узнаешь из жалобы. #### Признаки, что ты построил хорошо - **Золотой набор** реальных входов с известными хорошими исходами, сконцентрированный на тяжёлых случаях. - Метрики, что **отображают на задачу**, оценённые самым дешёвым надёжным методом и разбитые. - **Оценка на уровне шагов** для агентов и **валидированный судья** для размытых частей. - Эвал — это **гейт в CI**, и регрессия добавляет случай, а не проскальзывает. - **Онлайн-измерение и фидбек пользователей** возвращают новые сбои назад в набор. ## Шпаргалка: все 24 понятия ### Основы - **Eval** (эвал): Набор входов + способ оценить вывод + прогон на каждом изменении. - **Tuning by Vibes** (настройка на ощупь): Посмотрел пару выводов и выкатил. Регрессий не видно. - **The Last Mile** (80% → 95%): 80% — за вечер; до 95% — бо́льшая часть работы, случай за случаем. ### Что мерить - **Eval Criteria** (критерии оценки): «Хорошо» разбито на конкретные проверяемые свойства. - **Task-specific Metrics** (метрики под задачу): RAG, классификатор, агент, сводка — у каждого свой аршин. - **Faithfulness vs Correctness** (верность и правильность): Из контекста ли ответ — и верен ли он. Меряй отдельно. - **Slicing** (разбивка по срезам): Балл по категориям и сложности: средняя цифра прячет провалы. ### Эвал-набор - **Golden Set** (золотой набор): Реальные входы с известными хорошими исходами. Главный актив. - **Hard Cases** (edge, adversarial, regression): Тяжёлое, странное и уже ломавшееся — нарочно в наборе. - **Production Sampling** (случаи из прода): Входы из логов и фидбека, особенно неудачные. ### Как оценивать - **Code-based Grader** (детерминированная проверка): Совпадение, регэксп, схема, нужный вызов. Дёшево и точно. - **LLM-as-Judge** (модель-судья): Вторая модель оценивает размытое по рубрике. - **Judge Validation** (проверка судьи): Сверить баллы судьи с людьми, прежде чем верить. - **Human Review** (ручная проверка): Малая регулярная доза чтения реальных выводов. ### Агенты - **Trajectory Evaluation** (оценка траектории): Оценивать каждый шаг, а не только финальный ответ. - **Step-level Checks** (проверки шагов): Код-проверки вызовов инструментов, аргументов и извлечений. - **Operational Metrics** (шаги, задержка, стоимость): Сколько шагов, циклов, времени и денег ушло на задачу. ### Оффлайн и онлайн - **Offline Eval** (до релиза): Золотой набор на новой версии — гейт до выкатки. - **Online Eval** (в проде): Выборка живых выводов, оценка, метрики качества. - **User Feedback Signals** (сигналы пользователей): Пальцы, правки, повторы, отказы — бесплатный эвал-сигнал. - **Drift** (дрейф): Тихое падение качества со временем. Ловится только мониторингом. ### Строить хорошо - **Eval-driven Development** (сначала эвал): Маленький эвал до первой оптимизации. - **CI Gate** (гейт в CI): Эвал на каждом изменении; балл упал — релиз заблокирован. - **Goodhart's Law** (закон Гудхарта): Мера, ставшая целью, перестаёт мерить. Балл — прокси. > Эвалы — не разовый тест. Это цикл — меряй, находи сбои, вплетай их назад, — что превращает недетерминированный компонент в то, чему можно доверять и что можно улучшать. Конец экспресс-курса · 7 глав · 24 понятия Дальше — практика: возьми одну ИИ-фичу и напиши для неё десять эвал-случаев сегодня — реальные входы, известные хорошие исходы, способ оценить каждый — и прогони их до следующего изменения промпта. Потом добавляй один случай каждый раз, когда что-то ломается. Но держи одну мысль выше прочих: демо, что работает раз, — это лёгкие 80%. Всё, что делает его продуктом, которому можно доверять, — подъём до 95%, пойманные регрессии, увиденный дрейф — возможно, только если ты меришь. Без эвала ты настраиваешь на ощупь; с ним улучшение становится циклом, что ты можешь крутить.