Microsoft 2 июня представила ASSERT — open source-фреймворк для проверки поведения AI-систем, который превращает текстовые требования в набор тестов и оценок. Для команд, которые уже встроили AI-агентов в продукт, это попытка закрыть неприятный пробел между красивым демо и реальной эксплуатацией: модель может быть мощной, но бизнесу важнее, не нарушит ли она политику компании, не сольет ли лишнее и не начнет ли импровизировать там, где нужна дисциплина.
Новый инструмент, как пишет TechCrunch, называется Adaptive Spec-driven Scoring for Evaluation and Regression Testing, или ASSERT. Microsoft описывает его как фреймворк, который берет заданные обычным языком цели, правила и ожидаемое поведение AI-системы, переводит их в структурированный список допустимых и недопустимых действий, затем сам генерирует сценарии, тест-кейсы, прогоняет их через целевую систему и выставляет оценку результатам. Идея проста: разработчику не нужно вручную сочинять десятки искусственных кейсов на каждый риск, часть этой рутинной работы берет на себя сама AI-система.
На практике это выглядит довольно приземленно, и именно поэтому новость важна. Допустим, команда делает AI-агента для работы с внутренними документами. Ему можно поручить искать материалы, готовить краткие сводки и отвечать на вопросы сотрудников. Но вместе с этим нужно зафиксировать ограничения: не отправлять письма за пределы компании, не раскрывать конфиденциальную информацию кому попало, учитывать уровень доступа адресата, отвечать кратко и с учетом предыдущего контекста. ASSERT должен взять такие правила и превратить их в проверяемые сценарии, которые покажут, соблюдает ли агент эти ограничения регулярно, а не только в одном удачном демо на презентации.
Отдельно Microsoft делает ставку на разбор сбоев. Фреймворк может записывать путь, по которому проходит AI-система во время выполнения задачи, включая промежуточные действия и вызовы инструментов. Для разработчиков это, пожалуй, не менее важно, чем сама итоговая оценка. В реальных agentic-сценариях проблема часто не в финальном ответе как таковом, а в цепочке шагов: модель выбрала не тот инструмент, обошла ограничение, дернула лишний источник данных или слишком вольно интерпретировала инструкцию. Если тест просто говорит «провалено», пользы немного. Если он показывает, где именно агент свернул не туда, это уже материал для инженерной работы, а не для философских споров о природе интеллекта.
Microsoft явно пытается занять нишу между большими академическими бенчмарками и повседневной разработкой прикладных AI-сервисов. За последние годы отрасль неплохо научилась измерять безопасность, соответствие требованиям, склонность моделей к поддакиванию и другие общие свойства. Но когда компания внедряет AI в конкретный продукт, этих метрик быстро становится мало. Модель может прилично выглядеть на усредненном тесте и одновременно проваливаться на том, что действительно важно для бизнеса: нарушать внутренние политики, не учитывать роль пользователя, неверно работать с корпоративными инструментами или вести себя нестабильно после очередного обновления. ASSERT как раз и подается как способ проверять не «AI вообще», а поведение системы в контексте конкретного приложения, его ограничений и его набора инструментов.
Эту мысль в комментарии TechCrunch подчеркивает Сара Бёрд, chief product officer of Responsible AI в Microsoft. По ее словам, оценка поведения критична для принятия нормальных решений о том, готова ли система к использованию и соответствует ли она требованиям организации. Бёрд отдельно отмечает, что для надежной системы недостаточно смотреть на общие показатели: нужно оценивать куда больше прикладных измерений, завязанных на конкретный сценарий использования. И это, вероятно, самый практичный тезис во всей истории. У AI-рынка накопилась странная привычка обсуждать модели в категориях «умнее/глупее», хотя для бизнеса болезненнее вопросы вроде «не нарушит ли агент регламент закупок» или «не начнет ли чат-бот обещать клиенту то, чего сервис не предоставляет».
Для русскоязычной IT-аудитории здесь есть вполне прикладной вывод. Если команда уже использует LLM не как игрушку, а как часть продукта, поддержки, аналитики, внутренней базы знаний или документооборота, ей почти неизбежно нужна проверка поведения AI-систем не только перед релизом, но и после него. Причина банальна: модели, промпты, системные инструкции и подключенные инструменты меняются постоянно. Добавили новую функцию, обновили внешний API, пересобрали оркестрацию агента, заменили модель на более дешевую — и вчерашние гарантии испарились. В этом смысле ASSERT выглядит не просто как еще один фреймворк «для responsible AI», а как попытка встроить проверку поведения AI-систем в обычный инженерный цикл рядом с регрессионными тестами, логированием и мониторингом.
Новость хорошо ложится в более широкий тренд. По мере того как модели становятся способнее, индустрия все меньше спорит о магии и все больше занимается скучной, но полезной работой: повторяемыми тестами, регрессией и измерением поведения в разных условиях. TechCrunch в этом контексте упоминает Stanford HELM, MLCommons AILuminate и группы вроде METR, которые развивают бенчмарки и подходы к оценке моделей. Разница в том, что ASSERT нацелен не столько на сравнение моделей между собой, сколько на проверку того, как конкретная AI-система ведет себя внутри конкретного продукта. Для разработчика это, возможно, даже важнее очередной таблицы лидеров: пользователю безразлично, какое место модель заняла в абстрактном рейтинге, если в проде она отправила не тот файл не тому человеку.
Теперь главный вопрос в том, насколько такие инструменты приживутся в реальной разработке и не останутся красивой прослойкой поверх хаотичных промптов. Если рынок действительно движется к AI-агентам, которые получают доступ к данным, почте, CRM, документам и внутренним сервисам, спрос сместится с «какая модель умнее» на «какую систему можно безопасно выпускать в прод и обновлять без инфаркта у compliance-команды». В этом смысле запуск ASSERT выглядит не как побочная open source-инициатива, а как симптом взросления всего сегмента.