Последняя проверка: июнь 2026 г.
Сжатый справочник архитектурных шаблонов, проверяемых на экзамене AI-103. Читайте сверху вниз или переходите к нужному разделу.
Функция чата работает с большой нагрузкой, короткими и простыми диалогами, а также жесткими ограничениями по задержке и стоимости.
Разверните малую языковую модель (SLM), такую как Phi из каталога моделей Foundry, вместо передовой LLM.
Почему: SLM сокращают затраты и задержки для узких задач; резервируйте большие LLM для сложного рассуждения. Сопоставляйте размер модели с задачей, а не с брендом.
Один agent должен обрабатывать загруженные пользователем изображения и текст в одном запросе.
Выберите multimodal модель (например, семейство GPT-4o) в каталоге Foundry вместо цепочки из vision модели и текстовой LLM.
Почему: Нативные multimodal модели принимают изображения и текст в одном prompt; текстовая модель вынуждает к неточной передаче подписей, которая теряет визуальные детали.
Ответы должны быть основаны на частной корпоративной базе знаний, а не на предварительном обучении модели.
Создайте слой извлечения: проиндексируйте корпус в Azure AI Search с vector embedding'ами и основывайте модель через RAG по этому индексу.
Почему: Grounding внедряет извлеченный, цитируемый контекст при inference; fine-tuning статически встраивает знания и не может дешево цитировать или обновлять их.
Agent должен вызывать внутренние REST API, а также извлекать данные из проиндексированного хранилища документов.
Зарегистрируйте API как agent tools (function/OpenAPI) и подключите индекс AI Search как источник знаний к agent Foundry.
Почему: Tools дают agent'у возможность действовать; источники знаний обеспечивают обоснованное извлечение. Это разные поверхности интеграции, а не один и тот же коннектор.
Несколько команд нуждаются в изолированных конфигурациях agent'ов, соединениях и развертываниях под общим управлением.
Используйте Foundry hub с Foundry проектами для каждой команды; каждый проект определяет свои соединения, развертывания и доступ.
Почему: Hub централизует сеть, политику и общие ресурсы; проект является рабочей единицей для приложения или команды. Не делите один проект между командами.
Производственному приложению требуется предсказуемое местонахождение данных и зарезервированная пропускная способность для развертывания модели.
Используйте развертывание Standard (региональное) или Provisioned Throughput (PTU) вместо Global deployment для рабочих нагрузок, чувствительных к местонахождению данных и требующих высокой пропускной способности.
Почему: Global deployments маршрутизируют в любой регион для обеспечения емкости; Standard привязывает регион, а PTU резервирует емкость для стабильной задержки. Выбирайте по потребностям в местонахождении и SLA.
Определения prompt'ов и agent'ов должны перемещаться из среды разработки в производственную с проверкой и возможностью отката.
Храните определения prompt flow / agent'ов как код в репозитории и продвигайте их через среды с помощью конвейеров Azure DevOps или GitHub Actions.
Почему: Рассматривайте prompt'ы и конфигурацию agent'ов как версионированные артефакты; ручные изменения в portal'е на production не имеют журнала аудита или пути отката.
Всплеск трафика вызывает ошибки 429 при развертывании модели.
Увеличьте квоту TPM/RPM развертывания, если доступно, добавьте повторные попытки на стороне клиента с экспоненциальной задержкой и рассмотрите развертывание PTU для гарантированной емкости.
Почему: Квота - это потолок токенов в минуту; задержка сглаживает временное throttling. Запуск дублирующих ресурсов без планирования квоты просто перемещает узкое место.
Расходы непредсказуемы и доминируют за счет длинных RAG prompt'ов.
Ограничьте максимальное количество выходных токенов, урежьте извлеченный контекст до top-k, кэшируйте многократно используемый системный контекст и отслеживайте использование токенов для каждого развертывания в Azure Monitor.
Почему: Стоимость масштабируется с входными и выходными токенами; сокращение контекста и выходных данных является прямым рычагом. Смена региона или SKU редко существенно меняет цену за токен.
В течение нескольких недель качество ответов и точность grounding'а, по-видимому, ухудшаются в production.
Проводите непрерывные онлайн-оценки в Foundry для groundedness, relevance и coherence на выборках живого трафика и оповещайте о падениях оценки.
Почему: Запланированные evaluators обнаруживают дрейф, который вы не можете увидеть в необработанных метриках задержки; одни только дашборды CPU/latency никогда не покажут регрессию grounding'а.
Ответы RAG устаревают, потому что новые документы не извлекаются.
Мониторинг истории выполнения индексатора Azure AI Search и количества документов; планирование инкрементальной индексации и оповещение о неудачных запусках индексатора.
Почему: Качество извлечения незаметно ухудшается, когда индексатор терпит неудачу или отстает; метрики на стороне модели выглядят нормально, потому что проблема в конвейере данных.
Приложение должно вызывать развертывание модели Foundry без секретов в конфигурации.
Включите managed identity в приложении и предоставьте ему роль "Cognitive Services OpenAI User"; аутентификация с помощью токенов Entra ID, а не ключей API.
Почему: Keyless Entra auth удаляет утекающие секреты и централизует RBAC; хранение ключей API, даже в Key Vault, все равно оставляет ключ для ротации и защиты.
Трафик Foundry никогда не должен проходить через общедоступный интернет.
Разместите ресурс Foundry и зависимости за private endpoints, отключите доступ к общедоступной сети и разрешайте через private DNS zones.
Почему: Private endpoints привязывают трафик к VNet; списки разрешенных IP-адресов брандмауэра все еще маршрутизируют через общедоступные endpoints и обеспечивают более слабую изоляцию.
Генерируемые ответы иногда содержат ненавистнический или насильственный контент.
Примените фильтр Azure AI Content Safety при развертывании с соответствующими порогами серьезности для категорий ненависти, сексуального контента, насилия и самоповреждения.
Почему: Фильтры контента проверяют prompt'ы и completions на стороне сервера; полагаться только на инструкцию system-prompt легко обойти с помощью jailbreaks.
Автономный agent может выполнять необратимые действия, такие как возврат средств.
Настройте шлюз одобрения с участием человека для высокоэффективных tools и ограничьте agent'а разрешенным набором действий.
Почему: Режимы одобрения и ограничения доступа к tools ограничивают автономию; несдержанный автономный agent не имеет тормоза при вызове деструктивного tool.
Аудиторы должны видеть, какие источники и вызовы tools привели к данному ответу.
Включите tracing в Foundry (OpenTelemetry) для захвата prompt'ов, извлеченных цитат, вызовов tools и выходных данных для каждого запроса.
Почему: Сквозные trace'ы дают происхождение и воспроизводимость; одни только агрегированные метрики токенов не могут реконструировать цепочку рассуждений одного ответа.
Серверная служба должна вызывать модели и agent'ы, определенные в проекте Foundry.
Используйте Azure AI Foundry SDK (AIProjectClient) со строкой подключения к проекту и DefaultAzureCredential для получения клиентов модели и agent'а.
Почему: Клиент проекта централизованно разрешает соединения и развертывания; жесткое кодирование endpoints и ключей для каждой модели обходит управление проектом.
Создайте приложение для вопросов и ответов, основанное на политических документах.
Встройте и проиндексируйте документы, извлеките top-k chunk'ов для каждого запроса и передайте их в качестве контекста в завершение чата с инструкцией "cite-your-sources".
Почему: RAG поддерживает актуальность и цитируемость знаний без переобучения; передача полного корпуса в prompt заполняет окно контекста и увеличивает стоимость.
Модель должна проверять статус живого заказа во время разговора.
Определите tool с JSON schema, позвольте модели выдать tool call, выполните его на стороне сервера и верните результат для обобщения моделью.
Почему: Вызовы функций/tools позволяют модели детерминированно вызывать реальные системы; просьба "угадать" статус приводит к вымыслам.
Задача требует нескольких зависимых вызовов tool перед окончательным ответом.
Запустите цикл использования tool: передавайте каждый результат tool обратно модели и повторяйте, пока она не вернет окончательное сообщение, с ограничением на максимальное количество итераций.
Почему: Итеративные циклы tools поддерживают многошаговое рассуждение; один цикл не может связать зависимые запросы, а неограниченный цикл может выйти из-под контроля.
Перед выпуском количественно оцените, как часто приложение RAG галлюцинирует или отклоняется от темы.
Запустите Foundry evaluators для groundedness, relevance и coherence над размеченным тестовым набором и заблокируйте выпуск на пороговых значениях оценок.
Почему: Встроенные evaluators дают измеримые сигналы качества и безопасности; просмотр нескольких образцов не обнаруживает систематических вымыслов.
Определите agent поддержки с четкой persona, целями и границами.
Установите системные инструкции agent'а (роль, цели, правила отказа) и прикрепите только те tools, которые ему нужны для его области действия.
Почему: Строгие инструкции плюс минимальный доступ к tools удерживают agent'а в рамках задачи; широкие инструкции и все tools приглашают к расширению области действия и небезопасным действиям.
Agent должен запоминать контекст между диалогами в рамках сессии.
Используйте потоки Foundry Agent Service, которые сохраняют историю сообщений для каждого разговора, чтобы каждый запуск видел предыдущие диалоги.
Почему: Потоки обеспечивают управляемую память разговоров; повторная ручная отправка всей стенограммы при каждом вызове хрупка и легко может быть неправильно обрезана.
Agent нуждается в web grounding и выполнении кода без специальной настройки.
Прикрепите встроенные agent tools Foundry, такие как Grounding with Bing Search и Code Interpreter, вместо того, чтобы самостоятельно реализовывать интеграции.
Почему: Управляемые tools регулируются и поддерживаются "из коробки"; пользовательские перереализации добавляют затраты на обслуживание и обходят средства контроля безопасности платформы.
Основной agent должен делегировать вопросы выставления счетов специализированному agent'у по выставлению счетов.
Используйте connected agents: выставляйте agent по выставлению счетов как tool, который может вызывать основной agent, чтобы он маршрутизировал подзадачи специалистам.
Почему: Connected agents позволяют иерархическое делегирование; втискивание каждой области в одного мега-agent'а раздувает инструкции и ухудшает точность.
Рабочий процесс нуждается в planner'е, researcher'е и writer'е, сотрудничающих с общим состоянием.
Оркестрируйте их с помощью multi-agent фреймворка (Semantic Kernel / AutoGen на Foundry), используя определенный шаблон оркестрации и общий контекст.
Почему: Фреймворки управляют очередностью, состоянием и завершением; передача строк между agent'ами без координации или условия остановки.
Agent работает без присмотра ночью и не должен принимать рискованные действия в одиночку.
Ограничьте его разрешенными tools, бюджетами на каждое действие, фильтрами контента и контрольной точкой, которая эскалирует высокоэффективные шаги для одобрения.
Почему: Многоуровневые меры безопасности обеспечивают безопасную автономию; автономный цикл с полным доступом к tools и без шлюза одобрения может нанести необратимый ущерб.
Agent периодически завершается с ошибкой в середине задачи, и вы должны найти ошибочный шаг.
Проверьте трассированные шаги выполнения и входы/выходы вызовов tools в Foundry, чтобы найти ошибочный tool или неправильно сформированный аргумент.
Почему: Трассировка на уровне шагов точно указывает, где произошел сбой; одно конечное сообщение об ошибке скрывает, какой вызов tool или шаг рассуждения на самом деле завершился с ошибкой.
Выходные данные непоследовательны и игнорируют инструкции по форматированию.
Используйте четкое системное сообщение, примеры few-shot и явные ограничения на выходные данные; для строгой формы включите структурированные выходные данные / JSON schema.
Почему: Структурированное prompt'ирование и выходные данные, принудительно соответствующие схеме, делают результаты надежными; повышение temperature или слепые повторные попытки не исправляют следование инструкциям.
Задача креативного копирайтинга кажется слишком повторяющейся; задача извлечения данных слишком случайной.
Увеличьте temperature/top-p для креативной задачи и уменьшите их до 0 для извлечения, чтобы сделать его детерминированным.
Почему: Параметры сэмплирования меняют компромисс между разнообразием и детерминизмом; смена моделей избыточна, когда реальной причиной является настройка параметра.
Рассуждающий agent совершает избегаемые логические ошибки в сложных задачах.
Добавьте шаг reflection / self-critique, где agent пересматривает и редактирует свой черновик, или используйте модель рассуждения для этого шага.
Почему: Chain-of-thought и self-critique улучшают точность сложных задач; одиночный прямой проход не имеет шансов обнаружить свою собственную ошибку.
Операции требуют данных о расходах токенов, задержках и сигналах безопасности для каждого запроса в production.
Отправляйте трассировки и метрики OpenTelemetry из приложения в Azure Monitor / Application Insights, захватывая токены, задержку и флаги content-safety.
Почему: Унифицированная observability связывает стоимость, производительность и безопасность; ручной анализ логов не может соотнести медленный ход с использованием токенов.
Одно приложение смешивает дешевую классификацию с иногда сложным рассуждением.
Оркестрируйте несколько развертываний: направляйте простые шаги в SLM и эскалируйте сложные шаги в передовую LLM за одним уровнем приложения.
Почему: Маршрутизация моделей оптимизирует стоимость и качество для каждого шага; использование одной premium модели для всего переплачивает за легкое большинство.
Маркетинговое приложение должно генерировать оригинальные изображения из текстовых prompt'ов.
Разверните модель генерации изображений (например, DALL-E / GPT-image в каталоге Foundry) и вызовите ее с текстовым prompt'ом и параметрами размера.
Почему: Генеративные модели изображений синтезируют новые визуальные объекты; API Image Analysis (vision) описывает только существующие изображения, он не может их создавать.
Замените только фон существующей фотографии продукта, сохраняя продукт нетронутым.
Используйте endpoint редактирования изображений (inpainting) с исходным изображением плюс mask, который отмечает только редактируемую область.
Почему: Маска ограничивает редактирование закрашенной областью; обычный вызов text-to-image регенерирует весь кадр и теряет исходный продукт.
Создавайте короткие сгенерированные видеоклипы из текстового описания.
Используйте модель text-to-video, такую как Sora в каталоге Foundry, с параметрами prompt'а, продолжительности и разрешения.
Почему: Генерация видео - это отдельное семейство моделей; модели изображений выводят отдельные кадры и не могут производить временное движение.
Пользователи задают свободные вопросы о загруженном изображении диаграммы.
Отправьте изображение плюс вопрос multimodal LLM (GPT-4o) для визуального ответа на вопросы и ответа на естественном языке.
Почему: Multimodal чат обрабатывает открытые визуальные вопросы и ответы; тегирование изображений с фиксированной таксономией возвращает метки, а не ответы на произвольные вопросы.
Автоматически генерировать описательный alt text для тысяч изображений для доступности.
Используйте возможность Image Analysis caption / dense-captions для создания удобочитаемых описаний в масштабе.
Почему: Captioning непосредственно дает краткий alt text; обнаружение объектов возвращает ограничивающие рамки, которые все еще нужно превратить в прозу.
Извлечение структурированных полей и инсайтов на уровне сегментов из длинных записанных видео.
Используйте Azure AI Content Understanding с видеоанализатором для получения структурированных, определенных схемой выходных данных по всей временной шкале.
Почему: Content Understanding производит обоснованные структурированные выходные данные по всем модальностям; покадровые вызовы изображений не дают структуру с учетом временной шкалы.
Multimodal agent считывает пользовательские изображения, которые могут содержать скрытый текст инструкций.
Включите prompt shields / обнаружение indirect-injection и рассматривайте текст внутри изображений как ненадежные данные, а не как инструкции.
Почему: Встроенный текст изображения является классическим вектором indirect prompt-injection; прямая передача OCR'd текста в system prompt позволяет злоумышленникам захватить agent'а.
Извлекать имена, даты и суммы из электронных писем в типизированную JSON запись.
Prompt'ируйте LLM с целевой JSON schema и включите структурированные выходные данные, чтобы каждое поле возвращалось в фиксированной форме.
Почему: Извлечение LLM с ограничением по схеме обрабатывает открытые форматы и гарантирует парсируемый JSON; хрупкие regex'ы ломаются при разнообразии естественного языка.
Создайте краткое, переписанное резюме длинных стенограмм поддержки.
Используйте LLM для abstractive summarization с инструкцией по длине и фокусу или навык Language service summarization.
Почему: Abstractive summaries перефразируют суть; экстрактивное выделение предложений просто копирует предложения и может упустить общий смысл.
Классифицировать сообщения клиентов по настроению и помечать агрессивный тон.
Используйте LLM (или Language sentiment API) для маркировки полярности и обнаружения тона, возвращая категорию и уверенность.
Почему: Анализ настроения/тона - это задача классификации с определенными метками; генерация свободного текста без схемы меток затрудняет дальнейшую маршрутизацию.
Точно и дешево перевести большие объемы строк пользовательского интерфейса на 30 языков.
Используйте Azure AI Translator для массового, детерминированного перевода; зарезервируйте LLM для нюансированных, контекстно-насыщенных отрывков.
Почему: Translator специально разработан, дешевле и последователен в масштабе; LLM на строку стоит дороже и может меняться в тоне между запусками.
Голосовой agent должен транскрибировать аудио звонящего в реальном времени.
Используйте Speech service real-time speech-to-text (или fast transcription) для подачи текста в конвейер agent'а.
Почему: Streaming STT дает частичные транскрипции с низкой задержкой для живого разговора; пакетная транскрипция предназначена для офлайн-файлов, а не для живых диалогов.
Транскрипция неправильно слышит названия продуктов и медицинский жаргон.
Обучите Custom Speech модель с доменным аудио и списками фраз, чтобы улучшить распознавание специализированной лексики.
Почему: Custom Speech адаптирует акустическую/языковую модель к вашим терминам; базовая модель не имеет доступа к вашему частному жаргону.
Agent должен отвечать естественным звучанием голоса.
Используйте neural Text to Speech с подходящим голосом и SSML для управления просодией, паузами и произношением.
Почему: Neural TTS плюс SSML дает реалистичную, управляемую речь; простой текст без SSML дает плоскую фразировку для чисел и имен.
Извлечение только по вектору пропускает точные ключевые слова и совпадения идентификаторов кода.
Используйте hybrid search в Azure AI Search (vector плюс keyword) с semantic ranking для переупорядочивания объединенных результатов.
Почему: Hybrid плюс semantic reranking превосходит любой сигнал по отдельности; чистый vector search может пропустить буквальные термины, чистый keyword пропускает перефразирование.
Корпус включает сканированные PDF-файлы, текст которых не поддается выделению.
Добавьте OCR cognitive skill (Document Intelligence / Vision) в набор навыков индексации, чтобы отсканированный текст извлекался перед chunking и embedding.
Почему: OCR enrichment извлекает текст из изображений для поиска; индексирование необработанного сканированного PDF не дает ничего, что можно было бы найти.
Во время ingestion вам требуется OCR, извлечение ключевых фраз и перевод для каждого документа.
Определите набор навыков AI Search, связывающий необходимые cognitive skills, проецируя выходные данные в поля индекса, которые заполняет индексатор.
Почему: Набор навыков декларативно оркестрирует enrichment во время индексации; выполнение этого в коде приложения для каждого запроса повторяет работу и нарушает повторное использование.
Вы хотите, чтобы chunking и embedding обрабатывались внутри конвейера индекса, а не в коде приложения.
Используйте интегрированную векторизацию AI Search для разделения документов и вызова модели embedding во время индексации и во время запроса.
Почему: Интегрированная векторизация сохраняет согласованность chunking/embedding между ingestion и запросом; пользовательская embedding на стороне клиента рискует несоответствием модели.
Извлечение структурированных полей из счетов с различными макетами.
Используйте предварительно обученную модель Document Intelligence для счетов или обучите пользовательскую модель, чтобы возвращать типизированные поля с уверенностью и ограничивающими областями.
Почему: Document Intelligence понимает макет и возвращает типизированные поля; дамп только OCR дает необработанный текст без семантики полей.
Вам требуется чистое, обоснованное представление markdown смешанных документов для RAG.
Используйте анализаторы Content Understanding для создания структурированного / markdown вывода, который сохраняет заголовки, таблицы и grounding полей.
Почему: Обоснованный markdown сохраняет структуру и цитаты для извлечения; уплощенный простой текст теряет таблицы и контекст разделов, которые нужны модели.
Foundry agent должен извлекать данные из вашего обогащенного поискового индекса во время выполнения.
Добавьте индекс AI Search в качестве источника знаний / tool к agent'у, чтобы каждый запуск основывал ответы на извлеченных, цитируемых результатах.
Почему: Подключение индекса в качестве agent tool обеспечивает живое обоснованное извлечение; вставка статических фрагментов в инструкции не может оставаться актуальной с корпусом.