Microsoft ASSERT: Как заставить AI-агентов сдавать экзамены на естественном языке

Вы когда-нибудь пытались объяснить AI-агенту, что он должен делать, а он делал ровно противоположное? Я — да. Вчера мой агент для бронирования столиков решил, что «лучший ресторан» — это тот, где подают только суши, хотя я просил итальянскую кухню. И ладно бы только это — он еще и забронировал на троих, когда я был один. Знакомая боль? Добро пожаловать в мир, где AI-агенты живут по своим законам.

Проблема в том, что мы пишем промпты, молимся на них, а потом агент выдает сюрпризы. Обычное модульное тестирование тут не спасает — как заюниттестить поведение, которое описывается фразами вроде «не используй ненормативную лексику» или «если пользователь злится — передай оператору»? Вот тут на сцену выходит Microsoft ASSERT — open-source фреймворк, который умеет превращать естественный язык в тесты для AI-агентов. И нет, это не очередная игрушка из лабы Microsoft Research.

Чем ASSERT отличается от «просто напиши тесты руками»?

Да всем. Обычно для тестирования AI-агентов мы используем либо ручные чек-листы (скучно, долго), либо фреймворки вроде LangSmith или Arize AI. Но они — про мониторинг и трейсинг, а не про генерацию тестов. Вы все равно пишете case-ы сами. ASSERT же берет на себя самую муторную часть: придумывание граничных случаев.

Например, вы описали правило: «При запросе на удаление данных агент должен запросить подтверждение по email». ASSERT сгенерирует сценарии, где: email введен с ошибкой, пользователь передумал, запрос пришел через API без контекста сессии, агент уже удалил данные раньше, подтверждение пришло с другого адреса. И так далее. Человек бы вспотел, перебирая эти варианты, а ASSERT — за пару минут.

Как это работает? Без лишней магии

Внутри ASSERT — два компонента: генератор тестовых сценариев и раннер. Генератор использует LLM (по умолчанию — одна из моделей Microsoft, но можно подключить любую OpenAI-совместимую) для создания конкретных входных данных на основе текстового описания поведения. Раннер запускает эти сценарии против агента и сравнивает результат с ожиданием.

Важный момент: ASSERT не просто проверяет, что ответил агент, а анализирует всю траекторию — какие инструменты он вызвал, в каком порядке, не было ли лишних действий. Это уже не unit-тест, а полноценная поведенческая проверка.

Вот как выглядит простой сценарий тестирования с ASSERT (синтаксис упрощенный, на основе документации v2.0):

# Определяем политику поведения агента
policy = """
При запросе пользователя на удаление аккаунта агент должен:
1. Запросить подтверждение по email
2. Не удалять данные до получения подтверждения
3. Если подтверждение не пришло за 24 часа — отменить запрос
"""

# ASSERT генерирует тесты
tests = assert_generate_tests(policy, num_variations=20)

# Запускаем
results = assert_run(agent=my_support_agent, tests=tests)

# Смотрим отчет
for result in results.failed:
    print(f"Провал: {result.scenario}")
    print(f"Ожидалось: {result.expected}")
    print(f"Получено: {result.actual}")

Результат — по каждому сценарию вердикт: PASS или FAIL. В случае FAIL — лог полных действий агента, чтобы понять, где он сломался.

Реальные грабли, которые ASSERT подсветит

Недавно я тестировал агента для поддержки (пруф-оф-концепт) с помощью ASSERT. Описал правило: «Не передавать оператору, если пользователь просит повторить информацию». Звучит логично, да? ASSERT сгенерировал сценарий: пользователь пишет «Повторите, пожалуйста, еще раз» — агент не передает, повторяет. Ок. Но еще один сценарий: пользователь пишет «Повторите, а то я сейчас в суд подам». Агент видит слово «повторите» и не передает оператору, хотя тут явно эскалация нужна. Упс.

Вот такие граничные случаи ASSERT и вылавливает. Причем их количество растет, если подключать Playwright с AI-агентом для end-to-end тестов — можно комбинировать: ASSERT генерирует сценарии, Playwright их выполняет как настоящие пользовательские сессии.

Кому это реально нужно?

• Разработчикам AI-агентов, которые устали от сюрпризов в продакшене. ASSERT можно встроить в CI/CD — каждый мерж прогоняет сотню тестов.
• Тестировщикам, которые хотят автоматизировать проверку соответствия политикам (безопасность, этика, бренд-войс).
• Исследователям, изучающим поведение LLM: ASSERT генерирует четкие сценарии, которые можно повторять и сравнивать версии моделей.
• Всем, кто строит системы с AI-агентами на своем сервере, как описано в гайде по AI-автосекретарю — там тестирование поведения критично, чтобы не отправить не то письмо.

Лично я бы посоветовал не игнорировать ASSERT, даже если вы пишете агента для себя. Он спасает от когнитивного искажения «ну это же очевидно, что агент так не сделает». Ой, сделает. Еще как.

Куда катится мир AI-тестирования?

Мне кажется, через год-два мы перестанем писать тесты руками для AI-агентов вообще. ASSERT — первый ласточка. Уже сейчас ведутся работы над версией, где тесты генерируются на основе просто логов продакшена: агент накосячил в реальном сеансе, и ASSERT автоматически создает регрессионный тест на этот случай. Представляете? Больше не нужно вспоминать, что именно сломалось — система сама зафиксирует и проверит, что баг не вернулся.

Единственное, что напрягает — ASSERT пока завязан на LLM-генерацию, а значит сами тесты могут страдать от тех же проблем, что и агенты. Но Microsoft это учла: можно задавать seed-тесты вручную, а дообучать генератор на своих данных. Звучит логично, но на практике требует времени.

И да, он open-source (MIT), так что можно форкнуть, допилить под себя и даже прикрутить свой LLM-провайдер. Microsoft выложили код на GitHub, документация подробная. Единственная боль — пока нет готового Docker-образа, придется собирать из исходников. Но для тех, кто шарит, это мелочи.

В конце концов, лучше потратить час на настройку ASSERT, чем неделю на разгребание последствий того, что ваш агент по удалению аккаунтов решил, что «подтверждение» — это необязательно.

Подписаться на канал