Последняя проверка: июнь 2026 г.
Сжатый справочник архитектурных шаблонов, проверяемых на экзамене NCP-AAI. Читайте сверху вниз или переходите к нужному разделу.
Выбор между одним agent и многоагентной системой для сложного рабочего процесса.
По умолчанию используйте один agent с инструментами. Разделяйте на несколько agent только тогда, когда границы задач четко определены, контекст переполняется или разные уровни моделей подходят для разных подзадач.
Почему: Каждый добавленный agent увеличивает задержку, площадь ошибок и стоимость оркестрации; большинство рабочих нагрузок успешно справляются с одним хорошо оснащенным agent.
Оркестратор должен распределять разнородные подзадачи между специалистами.
Используйте agent-супервизора, который декомпозирует цель, маршрутизирует задачи agent-работникам с их собственными подсказками и инструментами и агрегирует результаты.
Почему: Централизованное управление сохраняет состояние когерентным и делает границу принятия решений проверяемой по сравнению с анархическим роем.
Поток agent имеет условные ветвления, циклы и параллельное расхождение.
Моделируйте рабочий процесс как явный граф узлов и ребер, а не как свободный цикл, чтобы поток управления был детерминированным и возобновляемым.
Почему: Граф делает ветви тестируемыми и позволяет создавать контрольные точки и воспроизводить с любого узла после сбоя.
Входящие запросы сильно различаются по типу и стоимости.
Предварите систему легким agent-маршрутизатором, который классифицирует намерение и отправляет его самому дешевому и способному последующему agent или инструменту.
Почему: Маршрутизация позволяет избежать оплаты дорогостоящих моделей для тривиальных запросов и изолирует проблемы по каждому пути.
Несколько agent должны читать и записывать общее состояние рабочего процесса.
Вынесите состояние во внешнее общее хранилище (ключ-значение или документ), индексируемое по сессии, вместо того чтобы передавать полную стенограмму между agent.
Почему: Общее хранилище ограничивает рост контекста и предотвращает расхождение копий состояния между agent.
Проектирование agent для горизонтального масштабирования.
Сохраняйте вычисления agent stateless; сохраняйте разговор и память извне, чтобы любая реплика могла обработать любой запрос.
Почему: Stateless узлы чисто масштабируются автоматически и выдерживают перезапуски pod'ов без потери незавершенной работы.
Sub-agent или инструмент дает сбой в середине рабочего процесса.
Разработайте идемпотентные шаги с повторными попытками/отсрочкой, компенсирующие действия для побочных эффектов и запасной путь или эскалацию человеку, когда попытки исчерпаны.
Почему: Agent-ные системы частично выходят из строя; восстановление должно быть первоочередной задачей проектирования, а не второстепенной.
Sub-agent разрабатываются отдельными командами.
Определите входной/выходной контракт каждого agent как типизированную схему и относитесь к agent как к службам за стабильными интерфейсами.
Почему: Явные контракты позволяют agent развиваться независимо и быть модульно протестированными изолированно.
Качество вывода agent непоследовательно для сложных задач.
Добавьте шаг критики/рефлексии, который просматривает черновик на соответствие критериям и запускает ограниченную повторную попытку перед возвратом.
Почему: Самокритика дешево выявляет ошибки, но ограничьте итерации, чтобы избежать бесконечных циклов и затрат.
Agent должен взаимодействовать с внешними API, базами данных или файлами.
Предоставьте возможности как типизированные определения функций/инструментов; модель выдает вызов инструмента, ваш код выполняет его и возвращает результат, затем цикл продолжается.
Почему: Структурированный вызов инструмента более надежен и проверяем, чем анализ инструкций в свободной форме.
Agent должен рассуждать о наблюдениях, прежде чем снова действовать.
Реализуйте цикл ReAct: модель генерирует мысль, выбирает инструмент, получает наблюдение и повторяет до достижения условия остановки.
Почему: Чередование рассуждений и действий раскрывает цепочку для отладки и улучшает точность многошаговых операций.
Модель неправильно использует или галлюцинирует аргументы инструмента.
Напишите точные описания инструментов, ограничьте типы аргументов и перечисления, и предоставьте один или два примера использования для каждого инструмента.
Почему: Большинство ошибок вызова инструментов связаны с расплывчатыми схемами; описание является подсказкой для инструмента.
Нижестоящему коду нужен надежный JSON от agent.
Ограничьте генерацию до JSON-схемы (структурированный вывод) вместо анализа свободного текста и проверьте перед использованием.
Почему: Декодирование с ограничением по схеме устраняет хрупкий синтаксический анализ regex и неявное изменение формата.
Создание производственного agent на стеке NVIDIA.
Используйте NeMo Agent Toolkit для компоновки agent, инструментов и рабочих процессов, связывая вызовы моделей с серверными частями, обслуживаемыми NIM.
Почему: Инструментарий стандартизирует внутреннюю логику agent и нативно интегрируется с обслуживанием NVIDIA.
Инструмент возвращает ошибку или истекает время ожидания.
Верните ошибку модели в качестве результата инструмента, чтобы она могла повторить попытку, скорректировать аргументы или выбрать альтернативный путь.
Почему: Предоставление информации о сбоях agent позволяет восстановиться; их подавление делает agent слепым.
В одном шаге требуется несколько независимых вызовов инструмента.
Выполняйте вызовы инструмента параллельно, если модель это поддерживает и вызовы не имеют зависимости порядка, затем объедините результаты.
Почему: Параллельное выполнение сокращает общее время задержки для расходящихся задач, таких как поиск по нескольким источникам.
Специализированная возможность должна быть повторно используемой в различных рабочих процессах.
Оберните sub-agent за единым интерфейсом инструмента, чтобы родительский agent вызывал его как любой другой инструмент.
Почему: Рассмотрение sub-agent как инструментов сохраняет единообразие композиции и скрывает внутреннюю сложность.
Agent отклоняется от задачи или игнорирует ограничения.
Закрепите роль, разрешенные инструменты, формат вывода и жесткие ограничения в кратком системном запросе; повторите критические правила в конце.
Почему: Четкий системный запрос — это самый дешевый и наиболее эффективный способ контроля поведения agent.
Измерение того, правильно ли agent решил многошаговую задачу.
Оценивайте как окончательный ответ, так и траекторию — точность вызова инструмента, порядок шагов и ненужные действия — по отношению к размеченному набору.
Почему: Правильный ответ от нарушенной траектории хрупок; оценка траектории выявляет скрытые сбои.
Отсутствуют эталонные метки для открытых выходов agent.
Используйте LLM-as-judge с рубрикой для оценки выходов, откалиброванную по небольшой выборке, размеченной человеком.
Почему: Модели-судьи масштабируют оценку, но должны быть откалиброваны, иначе они будут кодировать свои собственные предубеждения.
Необходимо выявлять регрессии перед каждым релизом.
Создайте автономный тестовый стенд с фиксированным набором сценариев, который запускается при каждом изменении и блокирует развертывания при несоблюдении порогового значения.
Почему: Поведение agent незаметно меняется при изменении подсказок или моделей; набор регрессионных тестов — это страховочная сетка.
Agent выбирает неправильный инструмент или неправильные аргументы.
Отслеживайте точность/полноту выбора инструмента и корректность аргументов как отдельные метрики, а не только успешность конечной задачи.
Почему: Изолирование уровня вызова инструмента позволяет точно определить, исходят ли сбои от выбора или от схемы.
Процент успешных оценок снизился после изменения.
Проанализируйте полные траектории неудачных случаев, сгруппируйте режимы сбоев и сначала исправьте доминирующий кластер.
Почему: Совокупные оценки скрывают первопричину; кластеризация по трассам выявляет фактический дефект.
Agent работает неоптимально, и его нужно улучшить.
Сначала итерируйте подсказки и описания инструментов; только после достижения плато в изменениях подсказок переходите к более крупной модели или fine-tuning.
Почему: Итерация подсказок быстра и дешева; замена моделей увеличивает стоимость и должна быть основана на доказательствах.
Сравнение двух дизайнов agent, которые оба соответствуют целевым показателям точности.
Добавьте стоимость за задачу и p95 latency к оценке, чтобы более дешевый и быстрый дизайн выигрывал при равенстве.
Почему: Жизнеспособность в production — это точность плюс стоимость плюс latency, а не только точность.
Обслуживание вывода моделей для agent в production.
Разверните модели как микросервисы NIM, предоставляя agent стандартизированную, GPU-ускоренную конечную точку вывода со встроенным пакетированием.
Почему: NIM упаковывает оптимизированный вывод за стабильным API, поэтому agent не нужно управлять внутренними механизмами обслуживания.
Трафик agent является пиковым и непредсказуемым.
Контейнеризуйте agent и обслуживание, запустите на Kubernetes и автоматически масштабируйте по параллелизму или использованию GPU с разумными минимальными/максимальными границами.
Почему: Autoscaling поглощает пики, а минимальное количество реплик предотвращает задержку холодного запуска на критическом пути.
Стоимость вывода GPU слишком высока при нагрузке.
Включите динамическое/непрерывное пакетирование на уровне NIM, чтобы увеличить количество токенов в секунду на GPU перед добавлением оборудования.
Почему: Пакетирование значительно улучшает использование GPU; масштабирование узлов в первую очередь тратит впустую емкость.
Agent запускают неограниченные параллельные вызовы инструментов и моделей.
Применяйте ограничения параллелизма для каждого agent и глобальные ограничения с очередью, чтобы система gracefully деградировала под нагрузкой.
Почему: Неограниченное расхождение исчерпывает квоты GPU и нижестоящих систем, что приводит к каскадным сбоям.
Выбор оборудования GPU для рабочей нагрузки вывода agent.
Масштабируйте по объему модели и целевым показателям latency — H100 для устоявшихся больших моделей, Blackwell где доминируют пропускная способность памяти и пропускная способность рассуждений.
Почему: Соответствие оборудования модели позволяет избежать как недообеспечения, так и оплаты простаивающей мощности.
Безопасное развертывание новой версии agent или модели.
Развертывайте с помощью canary-развертывания на небольшую долю трафика, сравнивайте живые метрики с базовыми, затем продолжайте или откатывайте.
Почему: Изменения в поведении agent трудно полностью предсказать офлайн; canary ограничивает радиус поражения.
Длинные цепочки agent рискуют зависнуть запросы.
Установите бюджеты времени ожидания для каждого шага и сквозного выполнения; отмените и используйте запасной вариант при превышении.
Почему: Без бюджетов один медленный инструмент может занять слот GPU и лишить ресурсов другие запросы.
Задача требует множества взаимозависимых шагов.
Используйте шаблон "план и выполнение": сначала сгенерируйте явный план, затем выполните шаги, перепланируя, если предположение нарушается.
Почему: Предварительное планирование сокращает блуждания и дает контрольную точку для проверки перед использованием вызовов инструментов.
Качество декомпозиции является узким местом.
Направьте шаг планирования к модели рассуждений Nemotron, используя более дешевые модели для выполнения.
Почему: Тратьте вычислительную мощность для рассуждений там, где это важно — на план, а не на каждый рутинный подшаг.
Agent должен запоминать факты на протяжении длительной сессии.
Держите последние ходы в рабочем контексте; сохраняйте долговечные факты в хранилище долгосрочной памяти, извлекаемой по требованию.
Почему: Помещение всего в контекст увеличивает стоимость и latency, а в конечном итоге переполняет окно.
Выбор способа хранения памяти agent.
Храните историю эпизодических взаимодействий отдельно от семантических фактов; извлекайте семантическую память по сходству, эпизодическую — по давности/сессии.
Почему: Различные шаблоны доступа требуют различных хранилищ; одна "корзина" плохо извлекает для обоих.
Долгая беседа приближается к пределу контекста.
Суммируйте более старые реплики в компактное текущее резюме и отбрасывайте исходную историю, сохраняя только недавние дословные реплики.
Почему: Постоянное суммирование сохраняет непрерывность, ограничивая стоимость токенов и избегая ошибок усечения.
Agent должен основывать ответы на частных корпоративных данных.
Предоставьте agent инструмент для извлечения информации из vector store, чтобы он сам решал, когда и что извлекать, вместо того чтобы всегда предварительно добавлять контекст.
Почему: Agent-ное извлечение информации происходит только при необходимости, сокращая количество токенов и нерелевантный контекст.
Создание высококачественного конвейера извлечения информации на NVIDIA.
Используйте микросервисы NeMo Retriever embedding и reranking NIM для ускоренного, производственного уровня RAG.
Почему: NeMo Retriever предоставляет настроенные модели embedding/rerank, эффективно обслуживаемые на GPU.
Чистый vector search пропускает точные совпадения и запросы по ключевым словам.
Объедините dense vector search с sparse/keyword retrieval и переранжируйте объединенные кандидаты.
Почему: Hybrid retrieval восстанавливает точные термины (ID, коды), которые размываются в embedding.
Извлеченные chunk слишком грубые или слишком фрагментированные.
Разбивайте на chunk по семантическим границам с небольшим перекрытием и прикрепляйте метаданные; настройте размер под модель embedding и тип запроса.
Почему: Гранулярность chunk напрямую влияет на релевантность извлечения; обе крайности ухудшают обоснование.
Agent возвращает устаревшую информацию из индекса.
Реализуйте конвейер инкрементного переиндексирования при изменениях источника и помечайте документы временными метками для ранжирования с учетом давности.
Почему: Без обработки свежести данных RAG уверенно основывает ответы на устаревших данных.
Выбор модели backend для рассуждений agent.
Выберите модель Nemotron, соответствующую нагрузке рассуждений, и обслуживайте ее через NIM для стандартизированной конечной точки.
Почему: Варианты рассуждений Nemotron настроены для agent-ного планирования и использования инструментов; NIM стандартизирует обслуживание.
Сопоставление потребности agent с правильным компонентом NVIDIA.
Используйте NeMo Agent Toolkit для оркестрации, NIM для обслуживания, NeMo Retriever для RAG, NeMo Guardrails для безопасности и Nemotron для рассуждений.
Почему: Знание того, какой компонент отвечает за какую задачу, является повторяющимся экзаменационным и проектным решением.
Сборка end-to-end agent-ного приложения на NVIDIA.
Компонуйте дискретные микросервисы NIM (LLM, embedding, rerank, guardrails) за уровнем agent, масштабируя каждый независимо.
Почему: Декомпозиция микросервисов позволяет каждой возможности масштабироваться и версионироваться самостоятельно.
Правила резидентности данных запрещают отправку данных внешним API.
Размещайте микросервисы NIM на собственной инфраструктуре GPU, чтобы модели и данные оставались внутри границ.
Почему: Портативная упаковка NIM поддерживает on-prem развертывание, соответствующее требованиям резидентности.
Production agent ведет себя неправильно, и его необходимо диагностировать.
Отправляйте распределенные трассировки, фиксирующие каждый вызов модели, вызов инструмента и решение, затем проверяйте неудачную траекторию от начала до конца.
Почему: Сбои agent являются многошаговыми; без полных трассировок вы не сможете определить, где рассуждения пошли не так.
Расходы токенов agent и latency со временем увеличиваются.
Отслеживайте токены, стоимость и p95 latency для каждого agent и каждого инструмента, с оповещениями о превышении пороговых значений.
Почему: Стоимость и latency незаметно меняются по мере развития подсказок и трафика; метрики выявляют это на ранней стадии.
Качество постепенно ухудшается без изменений кода.
Непрерывно запускайте набор оценок по производственным выборкам и оповещайте об отклонениях метрик от базового уровня.
Почему: Дрейф данных и вышестоящих моделей незаметно снижает качество между выпусками.
Agent должен оставаться в рамках темы и отклонять небезопасные запросы.
Применяйте NeMo Guardrails с входными, выходными, тематическими и диалоговыми барьерами вокруг agent.
Почему: Программируемые барьеры обеспечивают соблюдение политики независимо от собственного поведения модели и в качестве ее подстраховки.
Недоверенное содержимое может захватить agent через извлеченные данные или данные инструмента.
Рассматривайте весь внешний контент как недоверенный, изолируйте его от инструкций и ограничивайте полномочия инструмента, чтобы внедренные команды не могли эскалироваться.
Почему: Внедрение использует мощность agent; защита заключается в наименьших привилегиях плюс разделение инструкций/данных.
Agent обрабатывает регулируемые или персональные данные.
Редактируйте или токенизируйте PII перед вызовами модели и записывайте защищенные от подделки журналы аудита действий agent и вызовов инструментов.
Почему: Соответствие требованиям требует как минимизации раскрытия, так и доказательства того, что сделал agent.
Agent может выполнять высокорискованные действия, такие как платежи или удаления.
Вставьте шлюз человеческого одобрения перед необратимыми или высокоэффективными вызовами инструментов, приостанавливая рабочий процесс до подтверждения.
Почему: Автономия хороша для обратимых шагов; для значимых действий требуется человек в цикле.
Agent не уверен или неоднократно не справляется с задачей.
Определите порог уверенности/сбоя, который приводит к эскалации человеку с полным контекстом, а не к догадкам.
Почему: Грамотная передача лучше, чем уверенный неправильный ответ при выполнении ответственной работы.
Заинтересованные стороны не доверяют результатам agent.
Отобразите краткое описание рассуждений agent, источники и используемые инструменты, чтобы люди могли просматривать и отменять решения.
Почему: Объяснимость повышает доверие и часто требуется для надзора и аудита.