Última revisão: junho de 2026
Uma referência rápida dos padrões arquiteturais que o exame NCP-AAI avalia. Leia de cima a baixo ou pule para uma seção.
Escolher entre um único agent e um sistema multi-agent para um fluxo de trabalho complexo.
Opte por um único agent com ferramentas. Divida em múltiplos agents apenas quando os limites das tarefas forem distintos, o contexto transbordar ou diferentes níveis de modelo se adequarem a diferentes sub-tarefas.
Por quê: Cada agent adicionado multiplica a latência, a superfície de erro e o custo de orquestração; a maioria das cargas de trabalho é bem-sucedida com um único agent bem equipado.
O orquestrador deve despachar sub-tarefas heterogêneas para especialistas.
Use um agent supervisor que decomponha o objetivo, encaminhe para agents trabalhadores com seus próprios prompts e ferramentas, e agregue os resultados.
Por quê: O controle centralizado mantém o estado coerente e torna o limite de decisão auditável, em comparação com um enxame livre para todos.
O fluxo do agent tem ramificações condicionais, loops e distribuição paralela.
Modele o fluxo de trabalho como um grafo explícito de nós e arestas, em vez de um loop de forma livre, para que o fluxo de controle seja determinístico e retomável.
Por quê: Um grafo torna as ramificações testáveis e permite checkpoints e replay de qualquer nó após uma falha.
As solicitações recebidas variam amplamente em tipo e custo.
Coloque um agent roteador leve na frente do sistema para classificar a intenção e despachar para o agent ou ferramenta downstream mais barato e capaz.
Por quê: O roteamento evita o custo de modelos de fronteira para solicitações triviais e isola as preocupações por caminho.
Múltiplos agents devem ler e escrever o estado comum do fluxo de trabalho.
Externalize o estado para um armazenamento compartilhado (chave-valor ou documento) indexado por sessão, em vez de passar a transcrição completa entre os agents.
Por quê: Um armazenamento compartilhado limita o crescimento do contexto e evita cópias divergentes do estado entre os agents.
Projetando agents para escala horizontal.
Mantenha a computação do agent sem estado; persista a conversação e a memória externamente para que qualquer réplica possa atender a qualquer solicitação.
Por quê: Nós sem estado dimensionam automaticamente de forma limpa e sobrevivem a reinícios de pods sem perder trabalho em andamento.
Um sub-agent ou ferramenta falha no meio do fluxo de trabalho.
Projete etapas idempotentes com retry/backoff, ações compensatórias para efeitos colaterais e um caminho de fallback ou escalonamento humano quando as retries se esgotarem.
Por quê: Sistemas agentic falham parcialmente; a recuperação deve ser uma preocupação de design de primeira classe, não um adendo.
Sub-agents são desenvolvidos por equipes separadas.
Defina o contrato de entrada/saída de cada agent como um esquema tipado e trate os agents como serviços por trás de interfaces estáveis.
Por quê: Contratos explícitos permitem que os agents evoluam independentemente e sejam testados unitariamente de forma isolada.
A qualidade da saída do agent é inconsistente em tarefas difíceis.
Adicione uma etapa de crítico/reflexão que revise o rascunho em relação aos critérios e acione uma retry limitada antes de retornar.
Por quê: A autocrítica detecta erros de forma barata, mas limite as iterações para evitar loops descontrolados e custos.
O agent deve interagir com APIs externas, bancos de dados ou arquivos.
Exponha capacidades como definições de função/ferramenta tipadas; o modelo emite uma chamada de ferramenta, seu código a executa e retorna o resultado, então o loop continua.
Por quê: A chamada de ferramenta estruturada é mais confiável e auditável do que a análise de instruções em texto livre.
O agent deve raciocinar sobre as observações antes de agir novamente.
Implemente um loop ReAct: o modelo produz um pensamento, seleciona uma ferramenta, recebe a observação e repete até que uma condição de parada seja atingida.
Por quê: O raciocínio e a ação intercalados expõem a cadeia para depuração e melhoram a precisão em várias etapas.
O modelo usa indevidamente ou alucina argumentos de ferramenta.
Escreva descrições precisas das ferramentas, restrinja os tipos de argumentos e enums, e forneça um ou dois exemplos de uso por ferramenta.
Por quê: A maioria dos erros de chamada de ferramenta remonta a esquemas vagos; a descrição é o prompt para a ferramenta.
O código downstream precisa de JSON confiável do agent.
Restrinja a geração a um JSON schema (saída estruturada) em vez de analisar texto livre e valide antes de usar.
Por quê: A decodificação restrita por esquema elimina a análise frágil de regex e a deriva de formato silenciosa.
Construindo um agent de produção na stack NVIDIA.
Use o NeMo Agent Toolkit para compor agents, ferramentas e fluxos de trabalho, conectando chamadas de modelo a backends servidos por NIM.
Por quê: O toolkit padroniza o encanamento do agent e se integra nativamente com o serving da NVIDIA.
Uma ferramenta retorna um erro ou expira.
Retorne o erro ao modelo como um resultado da ferramenta para que ele possa tentar novamente, ajustar argumentos ou escolher um caminho alternativo.
Por quê: Apresentar falhas ao agent permite a recuperação; engoli-las deixa o agent cego.
Várias chamadas de ferramentas independentes são necessárias em uma única etapa.
Execute chamadas de ferramentas em paralelo quando o modelo suportar e as chamadas não tiverem dependência de ordem, então combine os resultados.
Por quê: A execução paralela reduz a latência real para trabalhos de distribuição, como pesquisas em múltiplas fontes.
Uma capacidade especializada deve ser reutilizável em vários fluxos de trabalho.
Envolva um sub-agent por trás de uma única interface de ferramenta para que o pai o invoque como qualquer outra ferramenta.
Por quê: Tratar sub-agents como ferramentas mantém a composição uniforme e oculta a complexidade interna.
O agent se desvia da tarefa ou ignora restrições.
Defina a função, ferramentas permitidas, formato de saída e restrições rígidas em um system prompt conciso; reafirme regras críticas perto do fim.
Por quê: Um system prompt bem elaborado é o controle mais barato e de maior alavancagem sobre o comportamento do agent.
Medir se um agent resolveu uma tarefa de múltiplas etapas corretamente.
Avalie tanto a resposta final quanto a trajetória — precisão da chamada de ferramenta, ordem das etapas e ações desnecessárias — em relação a um conjunto rotulado.
Por quê: Uma resposta correta de uma trajetória quebrada é frágil; a pontuação da trajetória detecta falhas latentes.
Não existem rótulos de ground-truth para saídas de agent de propósito aberto.
Use um LLM-as-judge com uma rubrica para pontuar as saídas, calibrado contra uma pequena amostra rotulada por humanos.
Por quê: Modelos de juiz escalam a avaliação, mas devem ser calibrados ou codificam seu próprio viés.
Você precisa detectar regressões antes de cada lançamento.
Crie um sistema de avaliação offline com um conjunto de cenários fixos que é executado em cada alteração e bloqueia implantações se não atingir um limiar de aprovação.
Por quê: O comportamento agentic muda sutilmente com alterações de prompt ou modelo; um conjunto de regressão é a rede de segurança.
O agent escolhe a ferramenta errada ou os argumentos errados.
Rastreie a precisão/recall da seleção de ferramentas e a validade dos argumentos como métricas autônomas, não apenas o sucesso da tarefa final.
Por quê: Isolar a camada de chamada de ferramenta aponta se as falhas vêm da seleção ou do esquema.
A taxa de aprovação da avaliação caiu após uma alteração.
Inspecione trajetórias completas de casos de falha, agrupe os modos de falha e corrija o cluster dominante primeiro.
Por quê: Pontuações agregadas ocultam a causa raiz; o agrupamento por trace revela o defeito real.
O agent tem desempenho abaixo do esperado e você deve melhorá-lo.
Itere prompts e descrições de ferramentas primeiro; só escale para um modelo maior ou fine-tuning quando as alterações de prompt estabilizarem.
Por quê: A iteração de prompt é rápida e barata; as trocas de modelo adicionam custo e devem ser baseadas em evidências.
Comparando dois designs de agent que ambos atingem as metas de precisão.
Adicione custo por tarefa e latência p95 à avaliação para que o design mais barato e rápido vença os empates.
Por quê: A viabilidade de produção é precisão mais custo mais latência, não apenas precisão.
Servir inferência de modelo para agents em produção.
Implante modelos como microsserviços NIM, dando aos agents um endpoint de inferência padronizado e acelerado por GPU com batching integrado.
Por quê: NIM empacota inferência otimizada por trás de uma API estável para que os agents não precisem gerenciar os internos do serving.
O tráfego do agent é instável e imprevisível.
Containerize agents e serving, execute no Kubernetes e dimensione automaticamente com base na concorrência ou utilização de GPU com limites mínimos/máximos sensatos.
Por quê: O autoscaling absorve picos, enquanto as réplicas mínimas evitam a latência de cold-start no caminho crítico.
O custo de inferência de GPU é muito alto sob carga.
Habilite o batching dinâmico/contínuo na camada NIM para aumentar os tokens por segundo de GPU antes de adicionar hardware.
Por quê: O batching melhora drasticamente a utilização da GPU; escalar nós primeiro desperdiça capacidade.
Agents lançam chamadas de ferramenta e modelo paralelas ilimitadas.
Aplique limites de concorrência por agent e globais com uma fila para que o sistema degrade graciosamente sob carga.
Por quê: A distribuição ilimitada esgota as cotas de GPU e downstream, cascateando em falhas.
Escolhendo hardware de GPU para uma carga de trabalho de inferência de agent.
Dimensionar para o footprint do modelo e metas de latência — H100 para modelos grandes estabelecidos, Blackwell onde a largura de banda da memória e o throughput de raciocínio dominam.
Por quê: Correspondência de hardware com o modelo evita tanto o subdimensionamento quanto o pagamento por capacidade ociosa.
Lançando uma nova versão de agent ou modelo com segurança.
Implante via canary para uma pequena fatia de tráfego, compare métricas ao vivo com a linha de base, então progrida ou reverta.
Por quê: Mudanças de comportamento do agent são difíceis de prever completamente offline; o canary limita o raio de impacto.
Longas cadeias de agent arriscam solicitações travadas.
Defina orçamentos de timeout por etapa e ponta a ponta; cancele e volte quando excedidos.
Por quê: Sem orçamentos, uma única ferramenta lenta pode prender um slot de GPU e privar outras solicitações.
A tarefa requer muitas etapas interdependentes.
Use um padrão de planejar e executar: gere um plano explícito primeiro, depois execute as etapas, replanejando quando uma suposição for quebrada.
Por quê: O planejamento prévio reduz o "andar a esmo" e fornece um ponto de verificação para validar antes de gastar chamadas de ferramentas.
A qualidade da decomposição é o gargalo.
Encaminhe a etapa de planejamento para um modelo de raciocínio Nemotron enquanto usa modelos mais baratos para execução.
Por quê: Gaste poder de computação de nível de raciocínio onde realmente importa — o plano — não em cada sub-etapa de rotina.
O agent deve lembrar fatos ao longo de uma sessão longa.
Mantenha turnos recentes no contexto de trabalho; persista fatos duráveis em um armazenamento de memória de longo prazo recuperado sob demanda.
Por quê: Colocar tudo no contexto inflaciona o custo e a latência e, eventualmente, transborda a janela.
Escolhendo como armazenar a memória do agent.
Armazene o histórico de interação episódica separadamente dos fatos semânticos; recupere a memória semântica por similaridade, e a episódica por recenticidade/sessão.
Por quê: Diferentes padrões de acesso exigem diferentes armazenamentos; um único bucket recupera mal para ambos.
Uma conversa de longa duração se aproxima do limite de contexto.
Resuma os turnos mais antigos em um resumo compacto e contínuo e descarte o histórico bruto, mantendo apenas os turnos recentes verbatim.
Por quê: O resumo contínuo preserva a continuidade enquanto limita o custo de tokens e evita erros de truncamento.
O agent deve basear as respostas em dados corporativos privados.
Dê ao agent uma ferramenta de recuperação sobre um vector store para que ele decida quando e o que recuperar, em vez de sempre preceder o contexto.
Por quê: A recuperação agentic busca apenas quando necessário, reduzindo tokens e contexto irrelevante.
Construindo um pipeline de recuperação de alta qualidade na NVIDIA.
Use os microsserviços NIM de embedding e reranking do NeMo Retriever para RAG acelerado e de nível de produção.
Por quê: NeMo Retriever fornece modelos de embedding/rerank ajustados e servidos eficientemente na GPU.
A pura vector search perde consultas de correspondência exata e por palavras-chave.
Combine vector search densa com recuperação esparsa/por palavra-chave e reclassifique os candidatos mesclados.
Por quê: A recuperação híbrida recupera termos precisos (IDs, códigos) que os embeddings podem embaçar.
Os chunks recuperados são muito grosseiros ou muito fragmentados.
Divida em chunks em limites semânticos com uma sobreposição modesta e anexe metadados; ajuste o tamanho ao modelo de embedding e ao tipo de consulta.
Por quê: A granularidade do chunk impulsiona diretamente a relevância da recuperação; ambos os extremos degradam o grounding.
O agent retorna informações desatualizadas do índice.
Pipeline de reindexação incremental em alterações de fonte e carimbe documentos com timestamps para ranqueamento com base na recenticidade.
Por quê: Sem o tratamento de freshness, o RAG baseia confiantemente as respostas em dados desatualizados.
Escolhendo um backend de modelo para o raciocínio do agent.
Selecione um modelo Nemotron dimensionado para a carga de raciocínio e sirva-o via NIM para um endpoint padronizado.
Por quê: As variantes de raciocínio Nemotron são ajustadas para planejamento agentic e uso de ferramentas; NIM padroniza o serving.
Mapeando uma necessidade agentic para o componente NVIDIA certo.
Use o NeMo Agent Toolkit para orquestração, NIM para serving, NeMo Retriever para RAG, NeMo Guardrails para segurança e Nemotron para raciocínio.
Por quê: Saber qual componente é responsável por qual preocupação é uma decisão recorrente de exame e design.
Montando uma aplicação agentic de ponta a ponta na NVIDIA.
Componha microsserviços NIM discretos (LLM, embedding, rerank, guardrails) por trás da camada do agent, escalando cada um independentemente.
Por quê: A decomposição em microsserviços permite que cada capacidade escale e seja versionada por conta própria.
As regras de residência de dados proíbem o envio de dados para APIs externas.
Auto-hospede microsserviços NIM em infraestrutura de GPU própria para que modelos e dados permaneçam dentro do limite.
Por quê: A embalagem portátil do NIM suporta implantação on-prem que atende aos requisitos de residência.
Um agent de produção se comporta mal e você deve diagnosticá-lo.
Emita traces distribuídos capturando cada chamada de modelo, chamada de ferramenta e decisão, então inspecione a trajetória falha de ponta a ponta.
Por quê: As falhas do agent são multi-etapas; sem traces completos, você não consegue localizar onde o raciocínio falhou.
O gasto de tokens do agent e a latência aumentam com o tempo.
Rastreie tokens, custo e latência p95 por agent e por ferramenta, com alertas sobre violações de limite.
Por quê: O custo e a latência mudam silenciosamente à medida que os prompts e o tráfego evoluem; as métricas detectam isso cedo.
A qualidade degrada gradualmente sem alterações de código.
Execute o conjunto de avaliação continuamente contra amostras de produção e alerte sobre o desvio de métricas da linha de base.
Por quê: A deriva de dados e de modelos upstream corroem a qualidade invisivelmente entre os lançamentos.
O agent deve permanecer no tópico e recusar solicitações inseguras.
Aplique NeMo Guardrails com trilhos de entrada, saída, tópicos e diálogo ao redor do agent.
Por quê: Trilhos programáveis impõem políticas independentemente e como um respaldo ao próprio comportamento do modelo.
Conteúdo não confiável pode sequestrar o agent via dados recuperados ou de ferramentas.
Trate todo o conteúdo externo como não confiável, isole-o das instruções e restrinja a autoridade das ferramentas para que comandos injetados não possam escalar.
Por quê: A injeção explora o poder do agent; a defesa é o princípio do privilégio mínimo mais a separação de instruções/dados.
O agent lida com dados regulamentados ou pessoais.
Redija ou tokenize PII antes das chamadas do modelo e escreva logs de auditoria à prova de adulteração das ações do agent e invocações de ferramentas.
Por quê: A conformidade exige tanto minimizar a exposição quanto provar o que o agent fez.
O agent pode realizar ações de alto risco, como pagamentos ou exclusões.
Insira um gate de aprovação humana antes de chamadas de ferramentas irreversíveis ou de alto impacto, pausando o fluxo de trabalho até a confirmação.
Por quê: A autonomia é boa para etapas reversíveis; ações com consequências precisam de um humano no loop.
O agent está incerto ou falha repetidamente em uma tarefa.
Defina um limiar de confiança/falha que escala para um humano com contexto completo, em vez de tentar adivinhar.
Por quê: A transferência graciosa é melhor do que uma resposta errada confiante em trabalhos de alto risco.
As partes interessadas desconfiam das saídas do agent.
Exponha o resumo do raciocínio do agent, as fontes e as ferramentas usadas para que os humanos possam revisar e anular decisões.
Por quê: A explicabilidade constrói confiança e é frequentemente exigida para supervisão e auditoria.