В предыдущих главах мы проектировали агентов, у которых есть инструменты, память и разделение работы между несколькими агентами. Здесь многие разработчики упираются в стену — в проблему «сделал-то сделал, но по-настоящему не понимаю, работает ли это как надо». Агент действует вероятностно, поэтому при одной и той же инструкции каждый раз действует не совсем одинаково. Именно поэтому «механизм измерения (оценка)» и «механизм визуализации (наблюдаемость)» становятся жизненной артерией при выводе в реальную работу. В этой главе мы заложим фундамент, чтобы схватывать качество в цифрах, воспроизводить сбои и без устали крутить улучшения.
Цель — «улучшать агента не по наитию, а по измеренным цифрам»
Почему оценка важнее всего
Обычная программа при одном и том же входе возвращает один и тот же результат. Но в центре агента — LLM, и её выход вероятностен. При одной и той же инструкции выбираемые инструменты, порядок шагов и формулировки каждый раз слегка меняются. То есть то, что раз сработало, ничуть не гарантирует, что сработает в следующий раз.
Здесь кроется ловушка, свойственная именно разработке агентов. На демо всё блестяще отработало, но стоит реальному пользователю попросить чуть иначе — и всё рушится; это не редкость. Причина проста: «сработало» не значит «правильно». Может, случайно вытянули верный ответ, а из 10 раз в 3 ошибаетесь. Чтобы это знать, остаётся только считать.
💡 Что нельзя измерить, то нельзя улучшить. «Кажется, стало как-то лучше» — это не улучшение. Поменяли промпт — доля успеха выросла или упала? Добавили один инструмент — не стало ли лишне медленно и дорого? Только когда можно сравнить в цифрах, вы можете судить, шаг это вперёд или назад. Оценка — не «домашка на потом», а фундамент разработки.
Ещё одно важное — не откладывать оценку. Идеальная база оценки с самого начала не нужна. Но если идти «сначала сделаю, заработает — подумаю об оценке», оценка, как правило, так и не появляется. Пусть маленькое, но начать измерять сразу после первого агента — вот кратчайший путь, кажущийся окольным. Общую картину оценки см. в практическом руководстве по оценке ИИ-агентов, а что это вообще означает — в что такое оценка агентов (evals).
Что оценивать — результат и траектория
Услышав «оценивать», многие представляют себе только верен ли финальный ответ. Это, безусловно, отправная точка, но у агента одного этого мало. Ведь у агента очень важно, «что он делал по пути». Даже дойдя до верного ответа, если он 10 раз впустую вызывал инструменты и растратил время и деньги, на практике это негодно. И наоборот — бывает, что ответ обидно неверен, но промежуточные решения были правильны.
Поэтому объект оценки делят на четыре стороны. Держа эти четыре в голове, вы избавитесь от метаний «не пойму, что измерять».
Достигнута ли поставленная цель. Точен ли ответ, удовлетворяет ли требованиям. Самый базовый показатель.
Какой инструмент, в каком порядке и почему вызывал. Обоснован ли процесс. Нет ли крюков и лишних шагов.
Вызвал ли верный инструмент с верными аргументами. Не вызывал ли несуществующий инструмент, не оставлял ли сбои без внимания.
Объём токенов, стоимость и время, потраченные за один прогон. Соразмерны ли качеству.
📊 Измерять «траекторию» — вот суть оценки агентов. Если оценка обычного ИИ-вывода — это «сверка ответа», то оценка агента смотрит на «ответ + путь к нему». Агент с грязным процессом легко рушится при малейшем изменении условий. Наоборот, агент со стройным процессом даже при отклонении способен выправиться. Именно глядя на процесс, вы находите зацепки для улучшения.
Пять методов оценки
«Так как же измерять» — вот сердцевина практики. Методов оценки несколько видов, и у каждого свои сильные и слабые стороны. Не полагаться на один, а комбинировать под объект измерения — вот канон. Разберём пять характерных, с плюсами и минусами.
Сопоставляем заранее заготовленный «правильный ответ» с выходом агента и измеряем совпадение. Подходит для задач с единственным ответом — классификация, извлечение, вычисление.
Плюс: ясно, легко автоматизируется, не шатается.
Минус: плохо годится для свободных ответов, где «нет единственного правильного».
Механически проверяем по заданным условиям: «содержится ли обязательное слово», «валиден ли формат JSON», «нет ли запрещённых слов».
Плюс: быстро и дёшево, силён в проверке формата и условий безопасности.
Минус: размытое качество вроде «верно ли по смыслу» измерить не может.
Даём другой LLM критерии оценки и заставляем оценить, хорош выход или плох. Можно измерять задачи без единственного ответа — качество сводки, приветливость ответа.
Плюс: свободные ответы и субъективное качество можно массово оценивать автоматически.
Минус: сам оценщик шатается / смещён. Нужны письменные критерии и выборочная проверка людьми.
Собираем характерные задачи в тестовый набор и при каждом изменении прогоняем его целиком. Механизм, оберегающий от «не сломало ли сегодняшнее исправление то, что вчера проходило».
Плюс: рано обнаруживает деградацию от изменений.
Минус: подготовка и поддержка тестового набора требуют труда.
После релиза непрерывно наблюдаем прогоны реальных пользователей. Собираем динамику доли успеха, затрат, задержек и оценки пользователей (👍/👎), отслеживая реальную производительность.
Плюс: находит проблемы, всплывающие только в реальной среде, и неожиданные способы использования.
Минус: постфактум. Проблема видна лишь «после того, как случилась». Предполагает сочетание с предварительной оценкой.
⚠️ Основа — комбинация. Формат и условия безопасности — правилами, задачи с определённым ответом — сверкой с эталоном, свободные ответы — LLM-as-judge, при каждом изменении — регрессионным тестом, а после релиза — мониторингом в продакшне. Не пытайтесь покрыть всё одним методом. Дешёвыми и быстрыми методами (①②) просеивайте большую часть, а дорогой метод (③) применяйте лишь там, где нужно, — так вы удержите точность при сдержанных затратах. Подробнее см. что такое оценка LLM.
Как составить оценочные данные (тестовый набор)
Какой бы метод вы ни использовали, его основа — «материал того, что измерять» = оценочные данные (тестовый набор). По сути это подборка характерных задач вида «на такой вход хочется вот такой результат». Если здесь скудно, никакой самый достойный метод оценки не будет надёжен. И наоборот — есть хороший тестовый набор, и оценка удалась на 80%.
Способ составления прост, идём по такому порядку. Вместо стремления к идеалу железное правило — сначала начать с малого и растить.
Собрать запросы, с которыми к агенту реально обратятся, включая типичные, граничные и склонные к сбою примеры.
Написать для каждой задачи «как хочется, чтобы получилось». Это может быть правильный ответ, условия для выполнения или критерии оценки.
Сначала хватит 10–20 штук. Приоритет — не количество, а «качество», отражающее реальную практику.
Добавлять в тестовый набор примеры сбоев, найденные в продакшне. Актив, который умнеет по мере использования.
✅ Не пренебрегайте «всего 10 штуками». Может показаться, что «выборка слишком мала и бессмысленна». Но тщательно отобранные 10 штук куда полезнее небрежно собранной тысячи. Сначала сделать измеримыми 10 характерных случаев, в которых реально затрудняетесь. Уже одного этого хватит, чтобы прямо на месте судить, в хорошую или плохую сторону изменение промпта или инструмента. Тестовый набор — не «сделал и забыл», а живой актив, который растёт по одной штуке с каждым найденным сбоем.
Наблюдаемость — делаем работу видимой
Если оценка — это «измерить, хорошо или плохо», то наблюдаемость — сделать так, чтобы можно было «проследить, почему так вышло». Даже узнав по оценке, что «доля успеха упала», если нельзя увидеть, что при этом происходило внутри, чинить нечем. Агент внутри крутит несколько шагов, поэтому снаружи склонен выглядеть чёрным ящиком: «подал вход, что-то произошло, вышел результат». Открыть его и сделать внутренности видимыми — это и есть наблюдаемость.
Наблюдаемость держится в основном на трёх элементах.
Запись одного прогона от начала до конца сквозным образом. Всю цепочку «вход → размышление → вызов инструмента → результат → следующее решение» можно проследить целиком, во временном порядке.
На каждом шаге — какой промпт отправлен, с какими аргументами вызван инструмент и что вернулось. Расход токенов и затраченное время тоже оставляем здесь.
Возможность пройти проблемный прогон ещё раз с тем же входом и тем же состоянием. Только сумев воспроизвести, вы можете установить причину и проверить исправление.
Всё это можно дописывать в логи вручную, но на практике обычно используют инструменты трассировки. Инструмент трассировки автоматически ловит каждый шаг агента и наглядно визуализирует его как дерево во времени. Становится с первого взгляда видно, «на каком шаге ушло время», «где сбоился вызов инструмента», «на каком решении он свернул не туда».
📊 Трасса — «глаза для отладки». В примере выше на ④ вызов инструмента сбоился, а на ⑤ агент сам выправился. По одному результату это «успех», но по трассе видно слабое место — «склонен ошибаться в номере столбца». Это наблюдение ведёт к следующему улучшению. Подход к наблюдаемости системно разобран в что такое наблюдаемость ИИ (observability).
Крутим цикл улучшений
Инструментарий, собранный до сих пор — оценка и тестовый набор, а также наблюдаемость — полезен и по отдельности, но по-настоящему раскрывается, когда крутится как единый цикл. Разработка агента — не «сделал раз и готово», а занятие, где измеряешь, находишь слабое место, чинишь и снова измеряешь, понемногу улучшая по кругу.
Прогнать оценку по тестовому набору и вывести долю успеха, затраты и задержки в цифрах.
Прочитать трассы сбойных прогонов и установить, где и почему он ошибся.
Изменить одну часть, относящуюся к причине: промпт, описание инструмента, порядок, разделение ролей.
Переоценить на том же тестовом наборе и проверить, вышло ли задуманное улучшение и не ухудшилось ли другое.
В этом цикле есть одна важная хитрость. За раз менять по возможности только одно. Если поменять сразу и промпт, и инструмент, и порядок, то, даже если доля успеха вырастет, будет непонятно, «какое из изменений сработало». Именно меняя по одному и измеряя, вы связываете изменение и результат причинностью и накапливаете знание. Скромно, но именно это отделяет «улучшение по наитию» от «надёжного улучшения».
✅ Цикл крутить быстро и мелко. Вместо одного большого разового удара мелкие изменения, быстро и многократно, в итоге приводят к успеху быстрее. Есть тестовый набор из 10 штук — поменял и сразу измерил. Стоит вработаться в ритм «изменил → тут же измерил», и разработка агента из угадайки по наитию превращается в инженерную работу, надёжно движущуюся вперёд.
- Агент вероятностен, и «сработало» не значит «правильно». Без измерения не улучшить.
- Объектов оценки четыре — финальный результат, промежуточная траектория, вызов инструментов, затраты и задержки. Особенно «траектория» — суть оценки агентов.
- Методов пять — сверка с эталоном, правила, LLM-as-judge, регрессионный тест, мониторинг в продакшне — комбинируем под объект.
- Оценочные данные — из малого числа характерных задач. Тщательные 10 штук побеждают небрежную тысячу. Растить, добавляя сбои.
- Наблюдаемость — трасса выполнения, логи каждого шага, воспроизведение сбоя. Инструментом трассировки делаем работу видимой.
- Улучшение — цикл измерить → найти слабое место → починить → снова измерить. Изменения — по одному, мелко и быстро.
Когда вы научились измерять качество и делать действия видимыми, следующее — «как предотвращать сбои, ошибочные операции и злоупотребления». Автономность, наращённую в предыдущей главе 4 «Проектирование мультиагентных систем», изучим, как обращаться с ней безопасно. Переходим к следующей главе 6 «Ограждения и безопасность».