Продолжаем разбирать руководство Google по ИИ-Агентам (Часть 1 - Агенты, Часть 2 - Инструменты, Часть 3 - Память). Если прошлые части были про создание, то эта - про то, как не сойти с ума при тестировании.
▶️ Что такое Качество Агента?
Традиционное ПО детерминировано (вход А всегда дает выход Б). Агенты - вероятностны. Они "думают", планируют и могут выбирать разные пути решения одной задачи.
Традиционный тестировщик спрашивает: "Мы собрали продукт правильно?" (по спецификации).
Оценщик Агента спрашивает: "Мы собрали правильный продукт?" (решает ли он задачу пользователя).
Аналогия от Google: Линейный повар vs Шеф-повар.
Традиционный софт - это линейный повар в фастфуде. У него есть жесткая инструкция: жарить котлету 90 секунд, положить один ломтик сыра. Мониторинг здесь - это просто чек-лист.
ИИ-Агент - это шеф-повар на кулинарном шоу с "черным ящиком". Ему дают цель ("сделай вкусно") и набор продуктов (инструменты, данные). Единого рецепта нет. Чтобы оценить его работу, недостаточно просто попробовать блюдо в конце. Нужно наблюдать за всем процессом готовки.
▶️ Три кита наблюдаемости (Observability):
Чтобы видеть "мыслительный процесс" агента, Google предлагает архитектуру из трех элементов:
Чтобы видеть "мыслительный процесс" агента, Google предлагает архитектуру из трех элементов:
Логи (Logs) - "Дневник Агента"
Атомарная единица информации. Это запись конкретного события во времени.
Пример: "В 10:01:33 я решил использовать инструмент 'погода'".
Это сырые факты о том, что произошло.
Трейсы (Traces) - "Следы"
Если логи - это отдельные улики, то трейсы - это красная нить детектива, связывающая их. Трейс показывает весь путь выполнения одной задачи: от запроса пользователя через цепочку размышлений (Chain of Thought) и вызовы инструментов до финального ответа.
Именно трейсы помогают понять "почему" агент ошибся (например, выбрал не тот инструмент или неверно прочитал ответ API).
Метрики (Metrics) - "Табель успеваемости"
Агрегированные данные из логов и трейсов. Это не просто "работает/не работает", а количественная оценка здоровья системы.
Делятся на два типа:
Системные: задержка (latency), стоимость токенов, количество ошибок.
Качественные: точность ответа, полезность, безопасность (нет ли галлюцинаций или токсичности).
▶️ Стратегия оценки: Снаружи-Внутрь
Нельзя сразу лезть в код. Оценка идет слоями:
Черный ящик (Black Box)
Сначала смотрим на результат. Решил ли агент задачу пользователя?
Метрики: Успех задачи (Task Success Rate), удовлетворенность пользователя.
Стеклянный ящик (Glass Box)
Если результат плохой, открываем "капот" и смотрим траекторию.
Планирование: Логична ли была цепочка рассуждений?
Инструменты: Правильно ли выбраны инструменты и параметры?
RAG: Были ли найдены релевантные документы?
LLM как судья (LLM-as-a-Judge)
Как оценить "полезность" ответа автоматически? Использовать другую, более мощную модель в качестве судьи.
Вы скармливаете "Судье" (например, Gemini Ultra) запрос пользователя, ответ вашего агента и критерии оценки. Судья выставляет оценку и объясняет причины. Это позволяет масштабировать тестирование, не привлекая людей.
Изучаем, тестируем.
