Как понять, что агент работает: оценка vs тестирование

🍽 Почему агента не «тестируют», а «дегустируют»

В прошлой теме — 11.1 — Камеры на кухне: наблюдаемость и логи — мы разобрались, как вообще заглянуть внутрь работающего агента и увидеть, что он делает на каждом шаге. Теперь следующий вопрос: окей, видим — а как понять, что увиденное хорошо? Тут и начинается развилка между двумя словами, которые легко перепутать.

Тестирование (testing) — это про обычную программу, у которой на каждый ввод ровно один правильный ответ. Это как проверить кассу: пробил товар за 100 ₽ — на чеке должно быть 100 ₽. Не 99, не 101. Ответ один, сверка механическая: совпало — прошёл, не совпало — провален. Так живёт код по фиксированному рецепту.

Но агент — это повар, а не касса. Спроси его «как вежливо отказать клиенту в возврате» — и он каждый раз сформулирует по-своему, и десяток формулировок будут одинаково хорошими. Сверять с единственным эталоном нечего. Поэтому к агенту применяют не тестирование, а оценку (eval) — и работает она ровно как на кухне: не «по вкусу шефа на глазок», а через два честных приёма.

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

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

👀 Три дегустатора: человек, LLM-судья, авто-метрика

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

Первый — человек (Human Eval, оценка человеком). Живой сотрудник читает ответы агента и оценивает по рубрике. Это самый тонкий способ: человек поймает кривой тон, неуместную шутку, упущенный нюанс — то, чего машина не чувствует. Минус очевиден: дорого и медленно. Сажать людей читать каждый из тысяч ответов в день невозможно — это как заставить шефа лично пробовать каждую тарелку в час пик.

Второй — LLM-судья (LLM-as-Judge, оценка моделью). Берём другую языковую модель и поручаем ей оценить ответы агента по той же рубрике: «оцени этот ответ от 1 до 5 по точности и вежливости и объясни почему». Это масштабируемо: судья пройдётся хоть по десяти тысячам ответов за копейки и быстро. Но у него есть слепые зоны — он может пропустить тонкую ошибку, к которой человек придрался бы, или наоборот придумать проблему на пустом месте. Это другой повар-дегустатор: быстрый, дешёвый, но не безупречный. Важное правило: судить должна отдельная модель, не та, что писала ответ — повар не должен сам ставить себе оценку, иначе он, ясное дело, всё одобрит.

Третий — авто-метрика (Automated Metrics, автоматические измерения). Это точные весы и термометр: чисто механические числа, которые считаются без всякого «мнения». Уложился ли ответ в нужную длину? Есть ли в нём обязательная ссылка на документ? За сколько секунд агент ответил? Сколько это стоило? Объективно, мгновенно, почти бесплатно. Но весы измеряют только вес — они не скажут, вкусное блюдо или нет, уместен ли тон, полон ли ответ. Метрика поймает «ответ пустой» или «отвечал 40 секунд», но не поймает «ответ складный, а по сути неверный».

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

🛤 Оцениваем не только блюдо, но и как повар к нему шёл

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

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

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

Когда что проверять? Если важен только результат, а как он получен — неважно (например, короткий справочный ответ), хватит оценки ответа. Но как только агент совершает действия — лезет в системы, что-то меняет, тратит деньги на каждом шаге, — путь становится критичным. Там верный ответ «случайно» — это бомба замедленного действия.

🗓 Две арены: на стенде (offline) и в бою (online)

Последний кусочек — где оценивать. Тут тоже две арены, и нужны обе.

Оценка на наборе примеров (offline, «на стенде»). Ты заранее собираешь набор типовых заказов с заведомо известным «как должно быть» — что-то вроде эталонного банкета на тренировочной кухне. Каждый раз, когда что-то меняешь в агенте, прогоняешь по этому набору и смотришь, не стало ли хуже. Это безопасно — ошибаешься на стенде, а не на живых клиентах. Подвох один: набор устаревает. Жизнь подкидывает новые заказы, которых на стенде не было, поэтому набор надо регулярно освежать, иначе ты идеально готов к прошлогоднему меню.

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

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

🧾 Как одна оценка выглядит изнутри (на пальцах)

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

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