Главная мысль урока: агентная система без проверки качества — это сотрудник, чью работу никто никогда не смотрел. «Вроде нормально отвечает» на демо ничего не говорит о том, что будет на сотом реальном запросе. Дисциплина проверки называется evals, и её главный секрет неожиданно прост: сначала смотреть на реальные ошибки глазами, и только потом строить автоматику.
Почему «на демо работало» — ловушка
Обычный софт детерминирован — ведёт себя одинаково каждый раз: кнопка либо работает, либо нет, проверил раз — работает всегда. Агент вероятностен: на один и тот же запрос он может ответить чуть по-разному, на похожие — кардинально по-разному.
Поэтому десять удачных демо-запросов не говорят почти ничего о тысяче реальных: там будут опечатки, странные формулировки, злые клиенты и вопросы, которых никто не предвидел.
Поэтому у агентных систем проверка качества — не финальный этап («потестируем перед запуском»), а постоянный процесс, встроенный в жизнь приложения. У этой дисциплины устоявшееся имя — evals (от evaluations, «оценки»).
Секрет, о котором забывает большинство: сначала — глазами
Главный методологический текст области (Hamel Husain и Shreya Shankar — практики, обучившие 700+ инженеров и продакт-менеджеров) начинается с правила, которое звучит почти оскорбительно просто: начните с error analysis — ручного разбора реальных случаев. (Evals FAQ, Hamel Husain & Shreya Shankar)
Возьмите ~100 настоящих диалогов/прогонов вашей системы, прочитайте каждый и запишите, что именно пошло не так. Без этого вы будете автоматически измерять то, что легко измерить, а не то, что реально ломается.
Это работа, которую нельзя полностью делегировать: что считать хорошим ответом ассистента вашей школы, знаете вы, а не разработчик и не нейросеть. Хорошая новость: 100 примеров — это вечер работы, и обычно уже после тридцати видны повторяющиеся типы ошибок: «выдумывает условия тарифов», «слишком длинно отвечает», «не передаёт сложные случаи человеку».
Три слоя контроля качества
Когда типы ошибок известны, строится автоматика. Индустрия 2026 сошлась на трёхслойной схеме: (Evals FAQ; обзоры observability-инструментов 2026)
Слой 1 · Трейсы: видеть, что агент делал
Трейс — полная запись одного прогона: какие сообщения пришли, какие инструменты агент вызвал, что они вернули, что он ответил. Без трейсов отладка агента — гадание. Стандартные инструменты — Langfuse (open-source стандарт, 100 тыс.+ инженеров) и аналоги; они подключаются к любому фреймворку. (langfuse.com) Это как камера в магазине: не для красоты, а чтобы при инциденте посмотреть запись.
Слой 2 · Тестовый набор + LLM-судья: проверять до выкатки
Из error analysis рождается тестовый набор: 30–100 реальных вопросов с критериями хорошего ответа. Перед каждым изменением (новый промпт, новая модель, новый инструмент) система прогоняется по набору.
Проверять ответы вручную каждый раз дорого, поэтому используется LLM-судья: отдельный вызов модели, который оценивает ответ по вашим критериям («условия тарифа указаны верно? тон вежливый? длина уместна?»). Важно: судью самого надо один раз проверить вручную — согласен ли он с вашими оценками.
Слой 3 · Выборочный контроль продакшна: смотреть, что происходит вживую
После запуска — регулярная выборка реальных трейсов (например, 20 случайных диалогов в неделю) с ручным просмотром + автоматические сигналы: доля диалогов с эскалацией к человеку, негативные реакции, аномально длинные сессии. Цикл замыкается: находки из продакшна пополняют тестовый набор.
Заметьте: в evals победила методология, а не инструмент. Неважно, Langfuse у вас или другой сервис — важно, что есть error analysis, тестовый набор и регулярный взгляд на реальные диалоги. Покупка инструмента без методологии — популярный способ потратить деньги и ничего не узнать.
Знакомый паттерн, не правда ли?
LLM-судья — это evaluator из урока 5 (паттерн evaluator-optimizer), применённый к контролю качества. А «агент проверяет свою работу» — третий шаг формулы Claude Code из урока 1 (gather context → take action → verify work). Evals — это та же идея верификации, поднятая на уровень всей системы: не «агент проверил себя разок», а «у системы есть постоянный механизм проверки».
Зачем это вам как заказчику
Заказывая приложение, заказывайте и контроль качества: «покажи мне трейсы», «давай соберём тестовый набор из 50 реальных вопросов», «как мы узнаем, что обновление ничего не сломало?»
Error analysis — ваша работа, не разработчика: выделите вечер на чтение первых 100 реальных диалогов. Это самый окупаемый вечер проекта.
Красный флаг: «протестировали, всё работает» без тестового набора и трейсов. Спросите: «на скольких реальных примерах? где посмотреть прогоны?»
Проверьте себя
Повторение урока 6. Ассистент «забыл», что клиентка перешла на новый тариф, и назвал старую цену. Где, скорее всего, проблема?
Верно, урок 6 в деле! Устаревание — главная боль памяти агентов. В хорошей архитектуре факты перезаписываются, а не копятся.
Симптом указывает на слой долгосрочной памяти (урок 6): факт изменился, а запись — нет. Это архитектурная проблема обновления памяти, не «слабость модели».
Разработчик сдал ассистента: «я задал ему 10 вопросов, отвечает отлично». Что вы попросите первым делом?
Именно! 10 демо-вопросов разработчика ≠ реальный трафик. Нужен тестовый набор из настоящих вопросов и трейсы для разбора. Это и есть минимальный eval.
Ещё 10 вопросов того же рода ничего не добавят, а смена модели — лечение без диагноза. Сначала: реальные вопросы + критерии + трейсы. Диагноз раньше лекарства.
Почему error analysis (ручной разбор ~100 реальных прогонов) идёт ДО построения автоматических метрик?
Верно! Типы ошибок конкретной системы нельзя угадать заранее — их можно только увидеть. Метрики, построенные до разбора ошибок, измеряют чужие проблемы.
Дело не в цене, и нет — судья проверяет только те критерии, которые вы ему дали. А правильные критерии берутся ровно из ручного разбора реальных ошибок. Сначала смотрим глазами, потом автоматизируем.
Что такое LLM-судья?
Точно! Это evaluator из урока 5 на службе контроля качества. Нюанс: судью один раз калибруют вручную — проверяют, что его оценки совпадают с вашими.
Нет, это автоматика: модель оценивает модель по вашим критериям. Знакомый паттерн — evaluator из урока 5. Человек нужен, чтобы один раз откалибровать судью и регулярно выборочно перепроверять.
Ассистент работает в продакшне месяц, жалоб нет. Можно расслабиться?
Верно! «Нет жалоб» — худшая метрика: молчаливый уход не оставляет тикетов. Выборка в 20 диалогов в неделю + сигналы — дёшево и вскрывает проблемы до того, как они станут трендом.
Все диалоги читать не нужно (не масштабируется), но и тишина — не сигнал здоровья: недовольные молчат и уходят. Золотая середина — регулярная выборка + автоматические сигналы.
Практика: ваш первый error analysis
🛠 Задание на 15 минут
Проведём мини-разбор на материале, который у вас уже есть, — работе любого вашего агентного процесса (письма рассылок, ответы ассистента, сгенерированные лендинги — что угодно).
Соберите 10 последних реальных результатов работы системы (например, 10 писем из последних запусков).
Прочитайте каждый и запишите одной строкой, что не так (если всё так — тоже запишите). Не оценки «3/10», а конкретика: «призыв к действию потерялся», «слишком канцелярно», «факт о дате эфира неверный».
Сгруппируйте записи: какие проблемы повторяются? Топ-3 — это и есть ваши главные типы ошибок.
Превратите топ-3 в критерии для LLM-судьи: сформулируйте каждый как вопрос с ответом да/нет («указана ли верная дата эфира?»).
Бонус: отдайте Claude Code один из результатов и критерии: «Оцени этот текст по критериям: [ваши три]. По каждому — да/нет и цитата-обоснование». Поздравляю — вы только что вручную запустили LLM-судью.
Что дальше
Следующий урок — безопасность агентов: prompt injection (почему это нерешённая проблема), «смертельная триада» возможностей, которые нельзя давать агенту одновременно, и зачем агенту человек-контролёр.