Прототипирование, отслеживание, оценка, тесты на проникновение: рабочий процесс ИИ-агента в Microsoft Foundry

Чтобы заставить ИИ-агента дать несколько хороших ответов, требуется всего несколько минут. Однако принятие решения о том, стоит ли его выпускать, занимает гораздо больше времени, поскольку команде сначала необходимо выяснить, оправдывает ли выбранный модель свою стоимость, использует ли агент правильные данные, какие инструменты он применяет, насколько хороши его ответы и как он справляется с теми, кто активно пытается его обойти.

Microsoft Foundry объединяет большую часть этих процессов в единую рабочую среду браузера, включающую сравнение моделей, инструкции, инструменты и знания, отслеживание, оценку, генерацию тестовых данных и автоматизированные тесты на прочность. Его истинная ценность заключается не в возможности откладывать работу над кодом на неопределенный срок. Он позволяет принимать дорогостоящие решения по проектированию, пока изменить проект еще дешево, до того как будет сформирован окончательный код.

Далее описывается путь одного агента от начальной стадии проекта до прототипа, основанного на данных, который проходит тестирование, оценку и анализ, после чего работы переходят из портала в SDK. Средой для этого является среда Microsoft Build retail-agent в рамках нового интерфейса Foundry, размещенная в регионе Sweden Central. Портал служит инструментом для быстрой итерации, а путь к продакшену остается внутри того же проекта Foundry, поэтому ничего не приходится создавать заново.

Начните с уже работающего решения

Новый проект Foundry — это рабочее пространство, содержащее агентов, модели, инструменты, знания, механизмы оценки и возможности для отслеживания. Точные шаги настройки, стандартные параметры и доступные функции различаются в зависимости от региона и меняются со временем, поэтому сам портал следует считать окончательным источником информации о возможностях проекта.

После создания агента именно здесь начинается основная работа. Здесь задаются модель и инструкции, добавляются инструменты или знания, а результаты тестируются в поле чата. Именно здесь также впервые становится ясно, насколько слаб прототип. Если задать слабо настроенному агенту общий вопрос о продукте, ответ обычно бывает банальным. Он может звучать уверенно, хотя агент ничего не знает о каталоге, правилах или бизнес-среде. Сохраняйте такой ответ в качестве эталона, поскольку любые последующие изменения следует оценивать по сравнению с ним.

Выбор модели на основе данных

Хорошая стандартная модель не обязательно является наилучшей для промышленного использования. Некоторые задачи требуют глубоких рассуждений, в то время как другие ценят скорость или низкую стоимость, поэтому выбор должен основываться на оценке, а не на интуиции. Foundry предоставляет несколько инструментов для отбора моделей из каталога:

• Таблица лидеров, отсортирующая модели по таким критериям, как качество, безопасность, производительность и связанные с затратами показатели.
• Диаграммы компромиссов, отображающие два параметра на одном графике, например качество по отношению к цене.
• Вид с сопоставлением, сужающий список до моделей, подходящих для конкретной нагрузки.
• Маршрутизатор моделей, который назначает каждый запрос соответствующей модели в соответствии с политикой баланса между затратами и качеством, так что одной модели не обязательно отвечать на все запросы.

Сами показатели тестирования являются слабым доказательством. Более надежным способом является выполнение одинаковой нагрузки на каждую из кандидатских моделей. Маршрутизатор проявляет свою эффективность, когда запросы сильно различаются по сложности. В настоящее время он предлагает режимы «Сбалансированный», «Затраты» и «Качество», а текущие версии автоматически переключаются на другую подходящую модель, если выбранная выйдет из строя.

Следующим шагом является отправка одинаковых промптов каждой кандидатской конфигурации с последующим сравнением качества ответов, времени отклика и затрат. Бенчмарки сужают круг возможных вариантов, а ваш рабочий объем определяет победителя. В документации Microsoft Learn описываются как процесс выполнения бенчмарков, так и механизмы их реализации в Foundry.

Инструкции — самый экономичный инструмент

Изменение моделей не всегда является правильным первым шагом. Нечеткие инструкции могут превратить дорогостоящую модель в обычного чат-бота. Инструмент Prompt Optimizer в Foundry переписывает и реструктурирует инструкции, объясняет причины изменений в отдельных разделах и позволяет провести несколько этапов обработки перед тем, как что-либо применить. Благодаря этому инструкции превращаются в версионированный ввод для инженеров, а не просто в свободно написанный абзац, который переписывается до тех пор, пока ответ не станет более приемлемым.

Красивая переработка мало что доказывает. Более надежная проверка заключается в сравнении одного набора данных для оценки как старой, так и новой версий. Любые правила поведения агента, формат ответа, действия при сбоях или ограничения на запросы вне темы должны быть указаны как в его инструкциях, так и в критериях оценки его выводов.

Связывание ответов с утвержденными данными

Инструкции определяют, как должен вести себя агент, тогда как знания определяют, на что он способен ответить. В небольших случаях прикрепление файлов и их предоставление с помощью инструментов поиска позволяет в ответах ссылаться на исходные материалы.

В более крупных корпоративных системах можно использовать Foundry IQ — общий слой знаний, объединяющий множество источников. База знаний может связываться с Azure Blob Storage, SharePoint, OneLake, существующими индексами поиска и публичным веб-контентом; агентские механизмы поиска планируют запросы, выбирают источники, выполняют поиск и возвращают обоснованные результаты с соответствующими ссылками.

Существует одно предупреждение, касающееся контроля доступа. Разрешения на уровне документа применяются только к источникам и конфигурациям, которые их поддерживают, поэтому никто не должен называть базу знаний системой с поддержкой разрешений до тех пор, пока разрешения источника и механизмы аутентификации не будут действительно настроены.

Чтобы увидеть эффект, задайте один вопрос дважды — до и после настройки. Первый ответ покажет общие знания модели, а второй должен продемонстрировать, каково влияние ваших данных.

Включите отслеживание заранее

Особенно полезна возможность наблюдения, когда агент всё ещё дает сбои. Система отслеживания Foundry соответствует стандартам OpenTelemetry и интегрируется с Azure Monitor Application Insights, записывая путь выполнения агента или приложения, что позволяет впоследствии анализировать вызовы модели, использование инструментов, входные и выходные данные, а также временные характеристики.

Три уровня используют эту общую операционную картину, каждый из них отвечая на свой собственный вопрос:

• Отслеживание показывает, что происходило во время конкретной эксплуатации.
• Оценка позволяет определить, соответствовало ли поведение установленным стандартам.
• Мониторинг информирует о тенденциях в ходе эксплуатации со временем.

Помните, что телеметрия Application Insights имеет стоимость, зависящую от объема данных и срока их хранения. Выделяйте бюджет на возможности отслеживания как часть архитектуры производства, а не как бесплатный инструмент для отладки.

Измеряйте поведение, а не догадки

Практические тесты полезны для исследований, но они не могут подтвердить, улучшила ли внесенная изменение работу агента. Foundry предоставляет готовые инструменты оценки по нескольким критериям поведения: качество, риски и безопасность, а также специфические показатели для агента — была ли выполнена задача, завершена ли она, понята ли цель и насколько эффективно использовались инструменты.

Пользовательские оценщики обычно бывают одного из двух типов. Те, что основаны на рубриках или указаниях, используют модель в качестве судьи для критериев, которые субъективны или зависят от контекста. Детерминистические оценщики представляют собой простые функции для критериев, которые можно вычислить напрямую. Оценка того, насколько дружелюбным является ответ, может требовать использования рубрик, в то время как ограничение по длине никогда не требует этого. Оценка сама по себе добавляет затраты и «шум», поэтому когда функция может надёжно сделать вывод, дополнительный вызов модели — это пустая трата денег.

Наборы данных делают итерации более строгими

Один пример запроса показывает, что та или иная функция работает, но набор данных раскрывает закономерности. Foundry может оценивать файлы JSONL или CSV, подготовленные вами, уже имеющиеся у вас трассы или синтетические тестовые данные. Синтетические данные удобны до запуска и тогда, когда объём реального трафика слишком мал, чтобы покрыть интересующие случаи использования.

В результате получается цикл, который можно повторять:

1. Исправьте примерный набор тестов, чтобы он оставался неизменным.
2. Запустите на нем текущую версию агента.
3. Измените ровно одну переменную — будь то модель, инструкции, настройки инструментов или параметры обработки данных.
4. Снова оцените результаты на том же наборе.
5. Сравните оценки, время ответа и затраченные ресурсы.
6. Примите или отклоните внесенные изменения.

На этом этапе работа уже не похожа на корректировку промптов, а скорее напоминает тестирование на откаты в программном обеспечении.

Работа красной команды выявляет то, что ускользает от обычной оценки

Обычные проверки качества направлены на оценку того, хорошо ли агент выполняет возложенные на него задачи. Метод красной команды позволяет выяснить, что делает система, когда в неё намеренно вводят вредоносные данные. Агент для красной команды искусственного интеллекта в Foundry сочетает проект с открытым исходным кодом PyRIT с механизмами оценки рисков и безопасности Foundry. Он тестирует поддерживаемые модели и агенты с использованием методов атак, разработанных для обхода стандартных защитных мер, и сообщает коэффициент успеха атак (ASR).

Среди используемых методов — преобразования вроде Flip и Tense, а также техники jailbreak и другие адверсарные приемы; сценарии рисков включают вредоносный контент, утечку конфиденциальных данных, запрещенные действия и косвенную инъекцию команд. Такие тесты приносят пользу, когда их результаты стимулируют новый этап разработки, а не когда они заканчиваются просто одним скриншотом для подтверждения соответствия стандартам. Рассматривайте их как цикл:

1. Проведите сканирование в месте, которое не является продакшн-средой.
2. Определите, какая категория рисков и метод атаки проникли в систему.
3. Устраните причину проблемы — будь то ошибка в инструкциях, ограничения инструментов, проблемы с контролем содержимого или настройками разрешений.
4. Проведите сканирование снова.
5. Отслеживайте, снижается ли уровень успешности атак.

Наблюдение за всем парком устройств

После того как агенты введены в эксплуатацию, вопрос уже не касается того, сработало ли одно конкретное задание, а скорее того, как ведет себя система в течение нескольких недель. Возможности мониторинга и управления показывают показатели для всего объема работы: количество звонков, использование токенов, количество сбоев и метрики, связанные с затратами; при необходимости можно углубиться до отдельных агентов и моделей.

Мышление в терминах микросервисов здесь полезно, но только в определенных пределах. Агент может рассматриваться как единая единица поведения с собственной версией, состоящая из инструкций, инструментов, знаний, модели политики и результатов, которые можно наблюдать. Не каждый агент обязан становиться отдельно развернутым сервисом. Главное — провести границы так, чтобы один агент можно было изменять, оценивать и повышать в статусе без переписывания всего, что находится рядом с ним.

Цикл, лежащий в основе портала

На практике цикл включает этапы создания, измерения, оптимизации, управления и возвращения к началу каждый раз, когда данные показывают, что агент еще не готов. Прогресс достигается тогда, когда треки и показатели превышают заранее установленные пороги, а не потому, что демо-версия выглядела хорошо. Интерфейсы продукта меняются, но процедура остается прежней: прототипирование, отслеживание, оценка, укрепление, мониторинг и повторение.

Одно ограничение на данный момент: Microsoft планирует прекратить поддержку Foundry Workflows 1 декабря 2026 года и направляет разработку новых рабочих процессов на Microsoft Agent Framework. Новая архитектура не должна строиться на том, что будет устаревать.

От прототипа в браузере до кода для производства

Портал должен сокращать путь к коду, а не заменять его. Такие потребности, как пользовательская оркестрация, CI/CD, более глубокая интеграция или хостинг кода агента, требуют использования Foundry SDK и соответствующих инструментов, доступных в настоящее время для Python, C#, JavaScript и Java. С архитектурной точки зрения ресурсы проекта и его конечные точки остаются центральными. Портал, SDK и инструменты — это просто разные способы доступа к одному проекту Foundry и его ресурсам; представьте себе проект с единым конечным пунктом, без отдельной платформы для прототипов и производственной платформы. Начало этого перехода — гайд по быстрому старту с SDK на Microsoft Learn.

Следующие эксперименты

Далее рассматриваются два аспекта. Первый — это оркестрация множества агентов, при которой независимо тестируемые агенты, у каждого из которых есть четко определенный контракт и базовые критерии оценки, объединяются с помощью современной системы оркестрации, а не сгружаются в один огромный запрос. Второй аспект — настройка модели, которую стоит рассматривать только тогда, когда методы формулировки запросов, обеспечения основы для работы, маршрутизации и проектирования инструментов оказались недостаточными. Оба этих аспекта относятся к области оценки, описанной здесь.

Заключительные мысли

Первый рабочий ответ агента запускает процесс, но не завершает его. Кандидат на выпуск требует подтверждения по нескольким аспектам: выбор модели, который оказался эффективным при сравнении в различных нагрузках, факторы, заметно влияющие на ответы, вызовы инструментов, которые можно проследить, возможность повторной оценки, а также показатель риска от группы атакующих, снижающийся со временем. Портал обеспечивает быстрый цикл работы, а проект и SDK переносят результаты в реальную производственную среду. Разрабатывайте быстро, с самого начала внедряйте инструменты для отслеживания, тестируйте каждое изменение на одинаковых нагрузках, проверяйте собственную систему раньше, чем это сделают посторонние, и переходите на код, как только браузер будет эффективно обрабатывать задачи.