Guide - NCP-AAI NVIDIA-Certified Professional: Agentic AI

Choisir entre un agent unique et un système multi-agents pour un flux de travail complexe.

Privilégier un agent unique avec des outils. Ne diviser en plusieurs agents que lorsque les limites des tâches sont distinctes, que le contexte déborde, ou que différents niveaux de modèle conviennent à différentes sous-tâches.

Pourquoi: Chaque agent ajouté multiplie la latence, la surface d'erreur et le coût d'orchestration ; la plupart des charges de travail réussissent avec un agent unique bien équipé en outils.

L'orchestrateur doit distribuer des sous-tâches hétérogènes à des spécialistes.

Utiliser un agent superviseur qui décompose l'objectif, achemine vers des agents travailleurs avec leurs propres invites et outils, et agrège les résultats.

Pourquoi: Le contrôle centralisé maintient l'état cohérent et rend la limite de décision vérifiable par rapport à un essaim libre.

Le flux de l'agent comporte des branches conditionnelles, des boucles et une dispersion parallèle.

Modéliser le flux de travail comme un graphe explicite de nœuds et d'arêtes plutôt que comme une boucle libre, afin que le flux de contrôle soit déterministe et reprenable.

Pourquoi: Un graphe rend les branches testables et permet de créer des points de contrôle et de rejouer à partir de n'importe quel nœud après un échec.

Les requêtes entrantes varient considérablement en type et en coût.

Placer en amont du système un agent routeur léger qui classe l'intention et la distribue à l'agent ou à l'outil aval le moins cher et le plus capable.

Pourquoi: Le routage évite de payer le coût du modèle de pointe pour des requêtes triviales et isole les préoccupations par chemin.

Plusieurs agents doivent lire et écrire un état de flux de travail commun.

Externaliser l'état vers un magasin partagé (clé-valeur ou document) indexé par session, plutôt que de passer la transcription complète entre les agents.

Pourquoi: Un magasin partagé limite la croissance du contexte et empêche les copies divergentes d'état entre les agents.

Concevoir des agents pour une mise à l'échelle horizontale.

Maintenir le calcul de l'agent sans état ; persister la conversation et la mémoire en externe afin que toute réplique puisse prendre en charge n'importe quelle requête.

Pourquoi: Les nœuds sans état s'auto-échelonnent proprement et survivent aux redémarrages de pods sans perdre le travail en cours.

Un sous-agent ou un outil échoue en cours de flux de travail.

Concevoir des étapes idempotentes avec réessai/retrait, des actions compensatoires pour les effets secondaires, et un chemin de secours ou une escalade humaine lorsque les réessais sont épuisés.

Pourquoi: Les systèmes agentiques échouent partiellement ; la récupération doit être une préoccupation de conception de premier ordre, et non une réflexion après coup.

Les sous-agents sont développés par des équipes distinctes.

Définir le contrat d'entrée/sortie de chaque agent comme un schéma typé et traiter les agents comme des services derrière des interfaces stables.

Pourquoi: Des contrats explicites permettent aux agents d'évoluer indépendamment et d'être testés unitairement de manière isolée.

La qualité de la sortie de l'agent est incohérente sur les tâches difficiles.

Ajouter une étape de critique/réflexion qui examine le brouillon par rapport aux critères et déclenche un réessai limité avant de retourner le résultat.

Pourquoi: L'auto-critique détecte les erreurs à moindre coût, mais limitez les itérations pour éviter les boucles infinies et les coûts.

L'agent doit interagir avec des API externes, des bases de données ou des fichiers.

Exposer les capacités sous forme de définitions de fonctions/outils typées ; le modèle émet un appel d'outil, votre code l'exécute et retourne le résultat, puis la boucle continue.

Pourquoi: L'appel d'outils structuré est plus fiable et vérifiable que l'analyse d'instructions en texte libre.

L'agent doit raisonner sur les observations avant d'agir à nouveau.

Implémenter une boucle ReAct : le modèle produit une pensée, sélectionne un outil, reçoit l'observation et répète jusqu'à ce qu'une condition d'arrêt soit remplie.

Pourquoi: L'alternance de raisonnement et d'action expose la chaîne pour le débogage et améliore la précision des tâches multi-étapes.

Le modèle utilise mal ou hallucine les arguments des outils.

Rédiger des descriptions d'outils précises, contraindre les types d'arguments et les énumérations, et fournir un ou deux exemples d'utilisation par outil.

Pourquoi: La plupart des erreurs d'appel d'outil proviennent de schémas vagues ; la description est l'invite pour l'outil.

Le code en aval a besoin de JSON fiable de la part de l'agent.

Contraindre la génération à un schéma JSON (sortie structurée) plutôt que d'analyser du texte libre, et valider avant utilisation.

Pourquoi: Le décodage contraint par schéma élimine l'analyse fragile par regex et la dérive silencieuse de format.

Construire un agent de production sur la pile NVIDIA.

Utiliser le NeMo Agent Toolkit pour composer des agents, des outils et des flux de travail, en reliant les appels de modèle aux backends servis par NIM.

Pourquoi: Le kit d'outils standardise la plomberie des agents et s'intègre nativement à la diffusion de NVIDIA.

Référence

Un outil renvoie une erreur ou expire.

Retourner l'erreur au modèle comme résultat de l'outil afin qu'il puisse réessayer, ajuster les arguments ou choisir un chemin alternatif.

Pourquoi: Remonter les échecs à l'agent permet la récupération ; les ignorer rend l'agent aveugle.

Plusieurs appels d'outils indépendants sont nécessaires en une seule étape.

Émettre des appels d'outils en parallèle lorsque le modèle le supporte et que les appels n'ont pas de dépendance d'ordre, puis fusionner les résultats.

Pourquoi: L'exécution parallèle réduit la latence d'horloge pour les tâches de dispersion comme les recherches multi-sources.

Une capacité spécialisée doit être réutilisable à travers les flux de travail.

Envelopper un sous-agent derrière une interface d'outil unique afin que le parent l'invoque comme n'importe quel autre outil.

Pourquoi: Traiter les sous-agents comme des outils maintient la composition uniforme et masque la complexité interne.

L'agent dévie de sa tâche ou ignore les contraintes.

Épingler le rôle, les outils autorisés, le format de sortie et les contraintes strictes dans une invite système concise ; reformuler les règles critiques vers la fin.

Pourquoi: Une invite système concise est le contrôle le moins cher et le plus puissant sur le comportement de l'agent.

Mesurer si un agent a résolu correctement une tâche multi-étapes.

Évaluer à la fois la réponse finale et la trajectoire (précision des appels d'outils, ordre des étapes et actions inutiles) par rapport à un ensemble étiqueté.

Pourquoi: Une réponse correcte provenant d'une trajectoire défectueuse est fragile ; le score de trajectoire détecte les défaillances latentes.

Aucune étiquette de vérité terrain n'existe pour les sorties d'agents à réponses ouvertes.

Utiliser un LLM comme juge avec une grille d'évaluation pour noter les sorties, calibré à l'aide d'un petit échantillon étiqueté par des humains.

Pourquoi: Les modèles juges permettent d'échelonner l'évaluation, mais doivent être calibrés, sinon ils encodent leur propre biais.

Vous devez détecter les régressions avant chaque publication.

Construire un harnais d'évaluation hors ligne avec une suite de scénarios fixe qui s'exécute à chaque changement et bloque les déploiements si un seuil de réussite n'est pas atteint.

Pourquoi: Le comportement agentique évolue subtilement avec les changements d'invites ou de modèles ; une suite de régression est le filet de sécurité.

L'agent choisit le mauvais outil ou les mauvais arguments.

Suivre la précision/le rappel de la sélection d'outils et la validité des arguments comme des métriques autonomes, et pas seulement la réussite de la tâche finale.

Pourquoi: L'isolation de la couche d'appel d'outils permet de déterminer si les échecs proviennent de la sélection ou du schéma.

Le taux de réussite de l'évaluation a chuté après un changement.

Inspecter les trajectoires complètes des cas d'échec, regrouper les modes d'échec et corriger d'abord le groupe dominant.

Pourquoi: Les scores agrégés cachent la cause première ; le regroupement par trace révèle le défaut réel.

L'agent sous-performe et vous devez l'améliorer.

Itérer d'abord sur les invites et les descriptions d'outils ; n'escalader vers un modèle plus grand ou un fine-tuning que lorsque les changements d'invites plafonnent.

Pourquoi: L'itération d'invites est rapide et bon marché ; les échanges de modèles ajoutent des coûts et doivent être basés sur des preuves.

Comparer deux conceptions d'agents qui atteignent toutes deux les objectifs de précision.

Ajouter le coût par tâche et la latence p95 à l'évaluation afin que la conception la moins chère et la plus rapide l'emporte en cas d'égalité.

Pourquoi: La viabilité en production est la précision plus le coût plus la latence, et non la précision seule.

Servir l'inférence de modèle pour les agents en production.

Déployer les modèles comme des microservices NIM, offrant aux agents un point d'accès d'inférence standardisé et accéléré par GPU avec batching intégré.

Pourquoi: NIM encapsule l'inférence optimisée derrière une API stable afin que les agents n'aient pas à gérer les détails internes du service.

Référence

Le trafic des agents est en dents de scie et imprévisible.

Conteneuriser les agents et le service, exécuter sur Kubernetes, et auto-échelonner en fonction de la concurrence ou de l'utilisation du GPU avec des limites min/max raisonnables.

Pourquoi: L'auto-mise à l'échelle absorbe les pics tandis que les répliques minimales évitent la latence de démarrage à froid sur le chemin critique.

Le coût d'inférence GPU est trop élevé sous charge.

Activer le batching dynamique/continu au niveau de NIM pour augmenter les tokens par seconde GPU avant d'ajouter du matériel.

Pourquoi: Le batching améliore considérablement l'utilisation du GPU ; la mise à l'échelle des nœuds en premier gaspille la capacité.

Les agents lancent des appels d'outils et de modèles parallèles illimités.

Appliquer des limites de concurrence par agent et globales avec une file d'attente afin que le système se dégrade gracieusement sous charge.

Pourquoi: Une dispersion illimitée épuise les quotas de GPU et aval, entraînant des échecs en cascade.

Choisir le matériel GPU pour une charge de travail d'inférence d'agent.

Dimensionner en fonction de l'empreinte du modèle et des objectifs de latence - H100 pour les grands modèles établis, Blackwell là où la bande passante mémoire et le débit de raisonnement dominent.

Pourquoi: Faire correspondre le matériel au modèle évite à la fois le sous-provisionnement et le paiement d'une capacité inactive.

Livrer une nouvelle version d'agent ou de modèle en toute sécurité.

Déployer en version canary sur une petite tranche de trafic, comparer les métriques en direct par rapport à la référence, puis progresser ou revenir en arrière.

Pourquoi: Les changements de comportement des agents sont difficiles à prévoir entièrement hors ligne ; le canary limite le rayon d'impact.

Les longues chaînes d'agents risquent de bloquer les requêtes.

Définir des budgets de délai d'attente par étape et de bout en bout ; annuler et revenir en arrière lorsqu'ils sont dépassés.

Pourquoi: Sans budgets, un seul outil lent peut bloquer un emplacement GPU et affamer d'autres requêtes.

La tâche nécessite de nombreuses étapes interdépendantes.

Utiliser un modèle planifier-exécuter : générer d'abord un plan explicite, puis exécuter les étapes, en replanifiant lorsqu'une hypothèse est violée.

Pourquoi: La planification préalable réduit les errances et fournit un point de contrôle à valider avant de dépenser des appels d'outils.

La qualité de la décomposition est le goulot d'étranglement.

Acheminer l'étape de planification vers un modèle de raisonnement Nemotron tout en utilisant des modèles moins chers pour l'exécution.

Pourquoi: Dépenser la puissance de calcul de raisonnement là où c'est important - le plan - et non sur chaque sous-étape de routine.

L'agent doit se souvenir de faits tout au long d'une longue session.

Garder les tours récents dans le contexte de travail ; persister les faits durables dans un magasin de mémoire à long terme récupéré à la demande.

Pourquoi: Entasser tout dans le contexte augmente les coûts et la latence et finit par déborder la fenêtre.

Choisir comment stocker la mémoire de l'agent.

Stocker l'historique des interactions épisodiques séparément des faits sémantiques ; récupérer la mémoire sémantique par similarité, la mémoire épisodique par récence/session.

Pourquoi: Des schémas d'accès différents exigent des stockages différents ; un seul seau récupère mal pour les deux.

Une conversation longue approche la limite de contexte.

Résumer les tours plus anciens en un résumé compact et continu et supprimer l'historique brut, en ne conservant que les tours récents textuels.

Pourquoi: La summarisation continue préserve la continuité tout en limitant le coût des tokens et en évitant les erreurs de troncature.

L'agent doit fonder ses réponses sur des données d'entreprise privées.

Donner à l'agent un outil de récupération sur un magasin de vecteurs afin qu'il décide quand et quoi récupérer, plutôt que de toujours préfixer le contexte.

Pourquoi: La récupération agentique ne récupère que lorsque c'est nécessaire, réduisant les tokens et le contexte non pertinent.

Construire un pipeline de récupération de haute qualité sur NVIDIA.

Utiliser les microservices NIM d'embedding et de reranking de NeMo Retriever pour une RAG accélérée et de qualité production.

Pourquoi: NeMo Retriever fournit des modèles d'embedding/rerank ajustés, servis efficacement sur GPU.

Référence

La recherche vectorielle pure manque les correspondances exactes et les requêtes par mots-clés.

Combiner la recherche vectorielle dense avec la récupération sparse/par mots-clés et reranker les candidats fusionnés.

Pourquoi: La récupération hybride récupère les termes précis (ID, codes) que les embeddings estompent.

Les chunks récupérés sont trop grossiers ou trop fragmentés.

Découper en chunks aux limites sémantiques avec un léger chevauchement et attacher des métadonnées ; ajuster la taille au modèle d'embedding et au type de requête.

Pourquoi: La granularité des chunks affecte directement la pertinence de la récupération ; les deux extrêmes dégradent l'ancrage.

L'agent retourne des informations obsolètes de l'index.

Mettre en place un pipeline de réindexation incrémentielle lors des changements de source et horodater les documents pour un classement tenant compte de la fraîcheur.

Pourquoi: Sans gestion de la fraîcheur, RAG ancre en toute confiance les réponses dans des données obsolètes.

Choisir un backend de modèle pour le raisonnement de l'agent.

Sélectionner un modèle Nemotron dimensionné pour la charge de raisonnement et le servir via NIM pour un point d'accès standardisé.

Pourquoi: Les variantes de raisonnement Nemotron sont optimisées pour la planification agentique et l'utilisation d'outils ; NIM standardise le service.

Référence

Mapper un besoin agentique au bon composant NVIDIA.

Utiliser NeMo Agent Toolkit pour l'orchestration, NIM pour le service, NeMo Retriever pour le RAG, NeMo Guardrails pour la sécurité, et Nemotron pour le raisonnement.

Pourquoi: Savoir quel composant est responsable de quelle préoccupation est une question récurrente aux examens et une décision de conception.

Assembler une application agentique de bout en bout sur NVIDIA.

Composer des microservices NIM discrets (LLM, embedding, rerank, guardrails) derrière la couche d'agent, en mettant à l'échelle chacun indépendamment.

Pourquoi: La décomposition en microservices permet à chaque capacité de s'adapter et de se versionner indépendamment.

Les règles de résidence des données interdisent l'envoi de données à des API externes.

Auto-héberger les microservices NIM sur une infrastructure GPU possédée afin que les modèles et les données restent dans la limite.

Pourquoi: L'empaquetage portable de NIM prend en charge le déploiement sur site qui répond aux exigences de résidence.

Un agent de production se comporte mal et vous devez le diagnostiquer.

Émettre des traces distribuées capturant chaque appel de modèle, appel d'outil et décision, puis inspecter la trajectoire défaillante de bout en bout.

Pourquoi: Les échecs d'agents sont multi-étapes ; sans traces complètes, vous ne pouvez pas localiser où le raisonnement a échoué.

La consommation de tokens et la latence de l'agent augmentent avec le temps.

Suivre les tokens, le coût et la latence p95 par agent et par outil, avec des alertes sur les dépassements de seuil.

Pourquoi: Le coût et la latence dérivent silencieusement à mesure que les invites et le trafic évoluent ; les métriques le détectent tôt.

La qualité se dégrade progressivement sans modifications de code.

Exécuter la suite d'évaluation en continu sur des échantillons de production et alerter sur la dérive des métriques par rapport à la référence.

Pourquoi: La dérive des données et des modèles en amont érode la qualité de manière invisible entre les versions.

L'agent doit rester dans le sujet et refuser les requêtes dangereuses.

Appliquer NeMo Guardrails avec des garde-fous d'entrée, de sortie, thématiques et de dialogue autour de l'agent.

Pourquoi: Les garde-fous programmables appliquent la politique indépendamment du comportement du modèle, et comme un filet de sécurité.

Référence

Un contenu non fiable pourrait détourner l'agent via des données récupérées ou des outils.

Traiter tout contenu externe comme non fiable, l'isoler des instructions et limiter l'autorité des outils afin que les commandes injectées ne puissent pas s'intensifier.

Pourquoi: L'injection exploite le pouvoir de l'agent ; la défense est le moindre privilège plus la séparation des instructions/données.

L'agent gère des données réglementées ou personnelles.

Rédiger ou tokeniser les informations personnelles identifiables (PII) avant les appels de modèle et écrire des journaux d'audit infalsifiables des actions de l'agent et des invocations d'outils.

Pourquoi: La conformité exige à la fois de minimiser l'exposition et de prouver ce que l'agent a fait.

L'agent peut effectuer des actions à haut risque comme des paiements ou des suppressions.

Insérer une porte d'approbation humaine avant les appels d'outils irréversibles ou à fort impact, en mettant le flux de travail en pause jusqu'à confirmation.

Pourquoi: L'autonomie convient pour les étapes réversibles ; les actions importantes nécessitent une intervention humaine.

L'agent est incertain ou échoue à plusieurs reprises à une tâche.

Définir un seuil de confiance/échec qui déclenche une escalade vers un humain avec un contexte complet plutôt que de deviner.

Pourquoi: Un transfert gracieux est préférable à une mauvaise réponse confiante dans un travail à enjeux élevés.

Les parties prenantes ne font pas confiance aux sorties de l'agent.

Afficher le résumé du raisonnement de l'agent, les sources et les outils utilisés afin que les humains puissent examiner et annuler les décisions.

Pourquoi: L'explicabilité renforce la confiance et est souvent requise pour la supervision et l'audit.