Прототипування, відстеження, оцінка, тестування з боку атакуючої групи: робочий процес штучного інтелекту в Microsoft Foundry.

Щоб отримати кілька хороших відповідей від штучного інтелекту, потрібно кілька хвилин. Однак вирішення про те, чи готово це рішення до випуску, займає набагато більше часу, адже команда спочатку мусить з’ясувати, чи вартує обраний модель своєї ціни, чи використовує агент правильні дані, які інструменти він застосовує, як оцінюються його відповіді та як він справляється з тими, хто активно намагається його обійти.

Microsoft Foundry об’єднує більшу частину цього процесу в одне робоче середовище браузера, яке включає порівняння моделей, інструкції, інструменти та знання, відстеження, оцінку, генеровані тестові дані та автоматизовані тести з боку „червоної команди“. Його справжня цінність полягає не в тому, що код можна відкладати на невизначений час, а у тому, що він дозволяє приймати дорогі рішення щодо проекту, поки змінити його ще недорого, перш ніж код для виробництва стане жорстко закріпленим.

У наступному описі простежується шлях одного агента від початкового проекту до прототипу, який ґрунтується на даних, піддається аналізу, оцінюванню та тестуванню, а потім позначається момент, коли робота переходить від порталу до SDK. Середовищем є роздрібне середовище Microsoft Build для агентів у новому досвіді 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, а також способи обходу захисту та інші адверсарські трюки; сценарії ризиків включають шкідливий контент, витік конфіденційних даних, заборонені дії та непряме введення команд. Цей процес приносить результати тоді, коли отримані дані спонукають до чергового етапу розробки, а не тоді, коли все закінчується лише одним скріншотом для дотримання вимог. Сприймайте це як цикл:

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 переносять цю роботу у реальну інженерію виробництва. Розробляйте швидко, якомога раніше додавайте засоби моніторингу, тестуйте кожну зміну на тому самому навантаженні, перевіряйте власну систему раніше, ніж це зроблять сторонні особи, і переходьте на код, як тільки браузер почне давати правильні відповіді.