Excellence opérationnelle pour l’entreprise Agentic

Excellence opérationnelle pour Agentic Enterprise

L’excellence opérationnelle pour les systèmes agentiques étend les pratiques DevOps traditionnelles pour répondre aux caractéristiques uniques des agents IA : comportement non déterministe, raisonnement et mémoire dépendants du contexte, complexité des objectifs et coûts d’inférence variable. Les applications conventionnelles suivent des chemins de code prévisibles, mais les agents génèrent de nouvelles réponses basées sur le contexte. La surveillance traditionnelle suit les métriques connues alors que l’observabilité des agents nécessite de comprendre le raisonnement du modèle de langage et les modèles de décision. Les tests standard valident les résultats déterministes, mais la validation de l’agent évalue la qualité de la réponse dans plusieurs dimensions, notamment la précision, la pertinence, la sécurité et l’équité.

Les produits et les systèmes évoluent au fil du temps. Par conséquent, appliquez les cinq principes de conception ci-dessous pour intégrer l’excellence opérationnelle à votre façon de les exécuter : évoluer avec observabilité, standardiser les procédures opérationnelles, adopter une culture DevOps, automatiser pour plus d’efficacité et apprendre de tous les événements opérationnels. Le principe d’excellence opérationnelle de base, « Évoluer avec l’observabilité », devient critique pour les systèmes agentiques, car le comportement des agents résulte d’interactions complexes entre les invites, le contexte récupéré, le comportement du modèle et l’historique des conversations plutôt que de l’exécution de code déterministe. Les architectes ne peuvent pas prédire chaque réponse de l’agent au moment de la conception, car les réponses sont façonnées par le modèle, l’invite et le contexte live. Par conséquent, concevez pour l’observabilité et les garde-fous. L’observabilité complète révèle le comportement réel des agents dans des conditions réelles. Cette visibilité permet des améliorations pilotées par les données et un diagnostic rapide des problèmes lorsque les agents produisent des sorties inattendues.

“Operations as Code” prend de nouvelles dimensions pour les agents. L’infrastructure en tant que code traditionnelle s’étend à la gestion des versions rapides, à la gestion de la configuration du modèle et à l’automatisation du déploiement des agents. Les procédures opérationnelles des agents traitent des changements de version de modèle, de l’évolution rapide et des mises à jour de la base Knowledge, ainsi que des opérations classiques de déploiement et de restauration.

« Apprendre de tous les événements opérationnels » devient encore plus précieux avec les systèmes agentsiques. Les incidents des agents révèlent souvent de subtils problèmes d’ingénierie d’invites, des erreurs de script et d’orchestration, des écarts dans la base Knowledge ou des modèles d’interaction utilisateur inattendus. Les post-mortems combinés à l’analyse systématique de la télémétrie des agents transforment l’expérience opérationnelle en capacité organisationnelle qui se décompose au fil du temps.

La consignation complète des conversations constitue la base de l’observabilité des agents. Capturez chaque conversation, y compris les entrées des utilisateurs, les réponses des agents, les étapes de raisonnement, les actions invoquées, les données récupérées et les résultats finaux. Cette télémétrie sert à de multiples fins : débogage d’incidents spécifiques, analyse de la qualité dans de nombreuses interactions, audit de conformité, amélioration du modèle et analyse des modèles d’utilisation.

Utilisez le modèle natif de traçage des sessions au lieu de la consignation personnalisée. Le Traçage des sessions Agentforce capture les données d’interaction des agents dans un modèle de données unifié sur Data 360 plutôt que de vous obliger à élaborer un système de télémétrie parallèle. Le modèle de données de traçage de session (STDM) enregistre la conversation en tant que hiérarchie de traces. Chaque session contient des interactions (tourne), chaque interaction contient des étapes (UserInputStep, LLMExecutionStep, FunctionStep) et les étapes contiennent des messages (communications de l’utilisateur et de l’agent). STDM utilise des objets Data 360 standard tels que AIAgentSession, AIAgentSessionParticipant, AIAgentInteraction, AIAgentInteractionStep et AIAgentInteractionMessage. Les interactions portent des identificateurs de traçage distribué (TelemetryTraceId et TelemetryTraceSpanId), et les étapes portent un identificateur d’étendue (TelemetryTraceSpanId), reflétant un modèle d’étendue de style OpenTelemetry.

La modélisation des conversations des agents en tant que traces et étendues est l’approche standard de l’industrie pour l’observabilité des agents. La réutilisation du modèle natif évite les problèmes d’échelle que rencontrent les objets élaborés à la main : stockage de conversations à plusieurs tours, charges de travail JSON importantes et croissance rapide des données. L’élaboration d’objets transactionnels personnalisés pour consigner des conversations est une exception délibérée, par exemple un objet personnalisé léger qui associe le comportement des agents aux résultats métiers, pas le substrat principal de consignation.

Les métadonnées de session et de conversation capturent le contexte critique, notamment les identifiants de session et d’interaction, l’identité de l’utilisateur, l’identité de l’agent, l’heure de début et l’heure de fin. STDM associe également chaque étape d’interaction à ses enregistrements d’appel de grand modèle de langage (LLM) (via GenerationId et GenAiGatewayRequest/Response references). Les détails d’utilisation, de modèle et d’invite de jeton sont disponibles via ces jointures plutôt que stockés en tant que champs de session. Les métadonnées permettent de filtrer et d’agréger les conversations pour l’analyse des modèles.

Les détails de l’interaction et de l’étape capturent chaque tour, notamment l’entrée de l’utilisateur, la réponse de l’agent, l’explication du raisonnement (lorsqu’elle est disponible), les scores de confiance, le contexte récupéré, les actions tentées et les erreurs rencontrées. Le traçage au niveau de l’étape permet une enquête détaillée sur les incidents qui reconstitue exactement ce qui s’est passé à chaque point de la chaîne de raisonnement.

Les étapes d’action enregistrent chaque action exécutée par un agent, y compris les appels d’API, les modifications de données, les interactions système externes et les intégrations invoquées. Les enregistrements d’action répondent à des questions telles que « Qu’a changé cet agent ? » et “à quels systèmes cet agent a-t-il accédé ?”. Ces réponses prennent en charge les enquêtes de sécurité et les exigences de conformité. STDM capture les actions nativement en tant qu’étapes d’interaction.

Les traces de raisonnement du Moteur de raisonnement Atlas révèlent les processus de décision des agents, ce qui aide à diagnostiquer les raisons pour lesquelles les agents ont choisi des actions spécifiques ou généré des réponses particulières. Le traçage de session enregistre les étapes du planificateur dans le cadre de chaque interaction. La profondeur du raisonnement exposé dépend du modèle et du planificateur, mais lorsque ces traces sont disponibles, elles améliorent considérablement la débogabilité.

Le journal d’audit de l’IA générative de la couche Einstein Trust capture chaque interaction IA générative, le texte de l’invite et de la réponse, y compris les versions masquées des informations d’identification personnelle (PII), les données d’ancrage récupérées, les scores de sécurité et de toxicité des réponses, et les détails du modèle LLM, le tout transmis et stocké dans Data 360. Activez la collecte et le stockage des données d’IA générative et de commentaires Einstein pour capturer les données d’audit et de commentaires dans Data 360, où vous pouvez les interroger et les analyser avec des rapports Data 360 pour une rétention à long terme.

Exemple :

Bien : Journaux de conversation stockés dans des objets Salesforce personnalisés avec des champs d’entrée utilisateur, de réponse de l’agent, d’actions exécutées, de consommation de jeton et de résultat de conversation. Le tableau de bord affiche les taux de réussite des conversations par agent et cas d’utilisation. Mieux : La consignation complète inclut des traces de raisonnement montrant le processus de décision de l’agent, le contexte récupéré montrant les réponses fondées sur des informations et des scores de confiance indiquant une incertitude. Meilleur : Les analytiques des conversations corrèlent le comportement des agents aux résultats métiers, identifient les opportunités d’amélioration par l’analyse des modèles et alimentent les pipelines d’apprentissage continu avec des exemples étiquetés de qualité.

Surveillez les performances opérationnelles pour vous assurer que les agents atteignent les niveaux de service et fonctionnent dans les paramètres attendus.

La latence des réponses suit l’heure de bout en bout depuis l’entrée de l’utilisateur jusqu’à la réponse de l’agent. La latence affecte directement l’expérience utilisateur. Mesurez la latence aux percentiles (p50, p95, p99) en révélant des performances typiques et des expériences dans le pire des cas. Alerte lorsque la latence p95 dépasse les seuils indiquant une dégradation des performances.

Les facteurs de latence des agents comprennent le temps d’inférence du modèle, la durée de récupération des données et du contexte, l’exécution d’outils et d’actions externes, et la latence du réseau. Instrumentez chaque phase séparément pour activer l’optimisation ciblée lorsque la latence globale dépasse les objectifs.

La consommation de jetons mesure les jetons utilisés par conversation, par agent et par cas d’utilisation. La consommation de jetons entraîne des coûts d’inférence et affecte le temps de réponse (plus de jetons nécessitent plus de calcul d’inférence). Suivez la distribution des jetons pour déterminer si l’utilisation réelle correspond aux projections. Détectez les conversations aberrantes qui consomment des jetons excessifs suggérant des problèmes rapides ou une mauvaise utilisation.

Les métriques de jeton comprennent les jetons d’invite (entrée dans le modèle), les jetons de réalisation (sortie du modèle) et le nombre total de jetons (somme des invites et des réalisations). Les jetons d’invite sont plus contrôlables que les jetons de réalisation. Optimisez les invites et le contexte récupéré en réduisant la consommation de jetons d’invite tout en préservant la qualité.

La surveillance du débit suit les conversations simultanées, les demandes par seconde et les tendances du volume de conversations, et peut aider à projeter les capacités et les exigences d’échelle. Comparez le débit actuel aux limites tarifaires connues ou aux niveaux de référence de capacité alertant lorsque vous approchez des seuils.

Le suivi des taux d’erreur surveille les échecs par type, notamment les erreurs spécifiques au modèle, les échecs d’expiration, les erreurs refusées d’autorisation et les échecs d’intégration externe. Les modèles d’erreur révèlent des problèmes systématiques qui nécessitent une correction. Calculez les taux d’erreur en pourcentage du nombre total de requêtes afin de comparer les agents et les périodes.

Distinguez les catégories d’erreur qui nécessitent des réponses différentes. Les erreurs spécifiques au modèle peuvent nécessiter des ajustements rapides ou basculer vers un meilleur modèle. Les erreurs d’autorisation nécessitent des changements de configuration de sécurité. Les erreurs d’intégration nécessitent une enquête système externe ou l’activation du disjoncteur.

La surveillance de disponibilité mesure le temps de fonctionnement des agents et les périodes d’exploitation réussies. Calculez la disponibilité en pourcentage de temps pendant lequel les agents ont répondu aux demandes. Suivez la disponibilité par rapport aux objectifs de niveau de service (SLO), en activant une réponse proactive lorsque la disponibilité est inférieure aux objectifs.

Proactive Monitoring évalue votre organisation pour détecter les anomalies de la plate-forme et les problèmes d’utilisation des ressources qui peuvent affecter la santé de l’infrastructure des agents. Il expose les signaux avant qu’ils ne dégénèrent en problèmes visibles pour l’utilisateur. Utilisez-le pour devancer les conditions au niveau de l’infrastructure, telles que l’activité inhabituelle de l’API ou la tendance à la consommation de ressources vers les limites de la plate-forme, qui peuvent dégrader les performances des agents. Examinez ses signaux par rapport à la base de fonctionnement normale de vos agents afin de distinguer les anomalies actionnables des variations attendues.

Surveillez en permanence la qualité des réponses, en détectant les dégradations avant qu’elles n’impactent les résultats métiers. Lorsque la plate-forme offre des outils d’évaluation intégrés, utilisez-les au lieu de processus personnalisés ou manuels. Commencez par les outils de test et d’évaluation natifs. Le Centre de test Agentforce permet de gérer des ensembles de requêtes de test réutilisables et d’exécuter des agents par lot, en vérifiant si l’agent a sélectionné la rubrique et l’action attendues et produit une réponse acceptable plutôt que d’élaborer et d’exécuter votre propre harnais de test. Il prend également en charge les évaluateurs natifs, notamment les dimensions de qualité prêtes à l’emploi et une approche LLM en tant que juge pour le score de la qualité conversationnelle, et permet de créer des évaluateurs personnalisés pour des critères spécifiques à l’organisation. Utilisez des conversations représentatives dans vos ensembles de tests pour refléter l’utilisation réelle.

La précision des réponses mesure si les réponses des agents contiennent des informations correctes. Une évaluation précise nécessite des assertions connues ou un examen humain. Pour les questions factuelles avec des réponses connues, l’évaluation automatisée compare les réponses des agents aux réponses correctes. Gardez-les sous forme de cas tests dans le Centre de test pour une évaluation répétitive. Pour des questions ouvertes, les évaluateurs humains évaluent la précision des conversations échantillonnées. Suivez les tendances de précision au fil du temps, en indiquant si des changements rapides, des mises à jour de modèle ou des modifications de base Knowledge améliorent ou dégradent les performances.

La pertinence des réponses mesure si les réponses des agents répondent correctement aux questions des utilisateurs, même si elles ne sont pas parfaitement précises. Les réponses pertinentes comprennent l’intention de l’utilisateur et fournissent des informations utiles, même lorsqu’une réponse complète n’est pas possible. Évaluez la pertinence par l’intermédiaire d’évaluateurs natifs, si disponible, d’un examen humain des conversations échantillonnées et des signaux utilisateur. Pour les agents basés sur une base Knowledge, l’analyse native de la qualité de la récupération peut évaluer la pertinence du contexte, la pertinence des réponses et la fidélité (ancrage) des réponses.

Les garde-fous détectent les réponses dangereuses, inappropriées ou préjudiciables, notamment les biais, les contenus offensants, les conseils dangereux et les réponses hors champ. La couche de Trust Einstein applique la détection de la toxicité aux interactions LLM à l’exécution, qui est votre première ligne de défense. Améliorez la surveillance de la sécurité en filtrant les contenus, en examinant manuellement l’échantillonnage, en créant des mécanismes de rapport pour les utilisateurs et en évaluant la distribution des résultats entre les groupes démographiques.

Les métriques de satisfaction utilisateur capturent la qualité subjective de l’expérience. Les commentaires Agentforce alimentent les modèles de données Audit IA générative et Commentaires d’Einstein (GenAIFeedback/GenAIFeedbackDetail dans Data 360). Ces modèles capturent des signaux utilisateur explicites (pouce vers le haut/vers le bas, acceptation/rejet, modifications et commentaires textuels) à partir d’une source humaine ou système, avec les données de requête et de génération de la passerelle.Capturez des commentaires explicites (demander avant l’escalade, après la fin d’une conversation et par le biais d’enquêtes de suivi) là où vous en avez besoin, et combinez des signaux explicites et implicites pour une perspective de qualité complète.

Salesforce fournit diverses surfaces de modèle. Le niveau génératif fournit les agents de raisonnement conversationnel exécutés sur : Les modèles hébergés par Agentforce offrent un raisonnement prêt à l’emploi dans les limites de Salesforce Trust, et apportent vos propres liens LLM (BYOLLM) à des LLM externes ou à des fournisseurs. Le niveau prédictif fournit les scores structurés dans lesquels les agents fondent leurs décisions : BYOM extrait les scores prédictifs zéro copie des plates-formes hébergées en externe et les modèles Einstein natifs produisent un score et une classification automatisés sur les objets CRM. Ensemble, ces surfaces permettent à un agent autonome de raisonner en langage naturel tout en fondant son workflow sur des données statistiques structurées.

Surveiller la dérive du modèle, qui indique des performances dégradées au fil du temps ou des conditions changeantes nécessitant une adaptation. Examinez les notes de publication et testez les cas d’utilisation critiques dans une organisation sandbox avant la mise en production de chaque version majeure. Utilisez la matrice de publication et la fenêtre d’aperçu sandbox pour détecter les problèmes de compatibilité à l’avance.

Un écart de performance se produit lorsque la précision, la pertinence ou la sécurité de l’agent se dégrade au fil du temps. Suivez les métriques de qualité au fil du temps en détectant les baisses statistiquement significatives. Un écart dans les performances peut résulter d’une dégradation du modèle, de l’enlisement de la base Knowledge, d’un désalignement rapide avec l’évolution des modèles d’utilisation ou d’un écart dans les concepts où les relations entre les entrées et les sorties souhaitées évoluent.

Établissez les performances de référence immédiatement après le déploiement initial de l’agent en mesurant la précision, la pertinence, la sécurité et la satisfaction dans des cas types représentatifs. Réévaluez périodiquement par rapport aux mêmes cas tests en révélant des changements de performance indépendants des changements de schéma d’utilisation.

Alertez lorsque les métriques de qualité diminuent au-delà des seuils acceptables. Définissez des seuils basés sur la tolérance à l’impact métier. Certains cas d’utilisation tolèrent une légère dégradation de la qualité; d’autres nécessitent une réponse immédiate à tout déclin.

Un écart de distribution se produit lorsque les modèles d’entrée des utilisateurs changent considérablement par rapport aux distributions de données de formation ou d’ajustement. La dérive de la distribution dégrade les performances lorsque les agents rencontrent des types d’entrée qu’ils n’ont pas été conçus pour gérer. Surveillez les caractéristiques d’entrée, notamment la longueur des questions, la distribution des rubriques, la complexité linguistique et la terminologie des domaines, en détectant les changements importants.

Comparez les distributions d’entrée actuelles aux données de référence historiques. Les déplacements importants de distribution peuvent indiquer de nouveaux cas d’utilisation, un changement de comportement des utilisateurs ou l’évolution des processus métiers. Les postes de travail de distribution peuvent nécessiter des mises à jour rapides, une extension de la base Knowledge ou des améliorations des capacités des agents.

Un écart comportemental se produit lorsque les modèles de réponse des agents changent de façon inattendue. Surveillez les caractéristiques des réponses, notamment la longueur moyenne des réponses, les taux d’invocation d’actions, les fréquences d’escalade et les modèles d’erreur. Des changements de comportement importants peuvent indiquer des problèmes rapides, des problèmes de modèle ou des changements sous-jacents du système.

Établissez des niveaux de référence comportementaux tôt en production, en capturant les caractéristiques de fonctionnement normales telles que les modèles de performance réguliers, l’utilisation des outils et les parcours de décision. Ces valeurs de référence deviennent la référence contre laquelle la détection ultérieure des anomalies est mesurée. Comparez le comportement en cours aux valeurs de référence, en alertant lorsque les écarts dépassent la variation attendue.

Les alertes automatisées activent la réponse proactive aux dérives. Configurez le déclenchement d’alertes lorsque les métriques de dérive dépassent les seuils déclenchant une investigation et des correctifs potentiels, notamment un affinement rapide, des mises à jour de la base Knowledge, une extension d’ensemble de tests ou un réentraînement du modèle BYOM.

Détectez automatiquement les comportements inhabituels des agents qui nécessitent une enquête.

Les anomalies de coût comprennent les pics de consommation de jetons, les augmentations de taux d’inférence ou l’accélération du coût total. Les pics de coûts peuvent indiquer des problèmes rapides entraînant une génération excessive de jetons, des abus ou une mauvaise utilisation conduisant à une utilisation inattendue, ou des problèmes d’infrastructure entraînant des appels redondants.

Surveillez les distributions de consommation de jetons qui détectent les conversations aberrantes. Examinez les conversations qui consomment 10 fois le nombre de jetons typique pour déterminer si elles représentent des requêtes ou des problèmes légitimes qui nécessitent une correction.

Des pics de taux d’erreur, notamment des augmentations soudaines des taux d’échec, l’apparition de nouveaux types d’erreur qui n’existaient pas dans la référence ou des concentrations d’erreurs localisées affectant des utilisateurs, des agents ou des cas d’utilisation spécifiques. Les pics d’erreur précèdent souvent les problèmes de dégradation de la qualité que les clients peuvent observer. La détection proactive permet de remédier avant un impact généralisé.

Modifications du schéma de réponse, y compris des changements soudains de longueur de réponse, de fréquence d’invocation d’actions ou de taux d’escalade. Les changements de modèle peuvent indiquer des problèmes d’invite, des changements de comportement du modèle ou l’évolution des modèles d’utilisation.

L’abandon de conversation augmente lorsque les utilisateurs abandonnent des conversations à des taux plus élevés, ce qui suggère une diminution de la qualité, une augmentation de la latence ou des écarts dans les fonctionnalités. Suivez les abandons par étape de conversation en identifiant si les utilisateurs abandonnent pendant l’interaction initiale, en pleine conversation ou après une tentative de réalisation de tâches. Les modèles d’abandon révèlent des opportunités d’amélioration spécifiques.

Concevez une architecture d’alerte équilibrant notification rapide et fatigue des alertes. Acheminez immédiatement les défaillances critiques des agents vers les ingénieurs de garde. Acheminez les avertissements de dégradation de la qualité vers les équipes produit pour enquête pendant les heures ouvrables. Agréger les anomalies mineures dans des résumés quotidiens pour l’analyse des tendances.

Invites de contrôle de version, configurations et métadonnées de modèle qui activent l’annulation, les tests A/B et la maintenance du journal d’audit.

Les modèles d’invite sont des invites réutilisables créées dans le Générateur de répliques qui définissent l’objectif, les contraintes et les directives de marque de l’agent, plus des espaces réservés pour les données d’ancrage dynamiques, telles que les détails des clients ou des produits. Stockez les modèles d’invite dans Git avec le code de l’application, en traitant les invites comme une logique d’application critique qui mérite la même rigueur que le code. Les modifications rapides passent par la révision du code, les tests et le déploiement contrôlé.

Utilisez Générateur de répliques pour le développement itératif d’invites avec l’historique des versions et des capacités de test. Lors de l’utilisation de modèles d’invite en tant qu’actions d’agent, prévisualisez le modèle dans Générateur de répliques pour confirmer la résolution correcte des champs de fusion. Utilisez ensuite le Centre de test pour exécuter des tests de bout en bout qui confirment que l’agent sélectionne l’action et génère les sorties correctes.

Exportez les invites prêtes pour la production vers le contrôle de version afin de créer une synchronisation entre le développement Générateur de répliques et les pipelines de déploiement contrôlé par la source.

La gestion de configuration suit la sélection du modèle, les paramètres de température, les configurations de récupération et les indicateurs de fonctionnalité. Stockez les configurations sous forme de code pour pouvoir utiliser des valeurs spécifiques à l’environnement, automatiser les déploiements et détecter les écarts de configuration.

La version sémantique s’applique aux versions des agents. Les versions majeures indiquent des changements de rupture tels que des contrats d’entrée/sortie modifiés ou un changement de comportement significatif. Les versions mineures indiquent des ajouts ou des améliorations de fonctionnalités maintenant la compatibilité. Les versions correctives indiquent des correctifs de bogues. La numérotation des versions communique l’impact des modifications aux équipes opérationnelles et aux utilisateurs.

Implémentez la gestion des versions sémantiques pour les composants des agents, notamment les modèles d’invite, les configurations d’agent et les bases Knowledge. Les numéros de version dans les journaux activent la corrélation des incidents avec des déploiements spécifiques.

La documentation sur les modifications explique les changements rapides, les modifications de configuration et les mises à jour de modèle. Documentez les modifications, les raisons pour lesquelles elles ont changé, les tests qui ont validé la modification et les procédures d’annulation existantes. La documentation sur les modifications accélère les enquêtes sur les incidents et le transfert Knowledge.

Tenez à jour un registre complet des versions, invites, configurations et historiques de déploiement de modèle.

Le registre du modèle enregistre les versions déployées, notamment la famille du modèle, la version spécifique, l’état d’ajustement, l’environnement de déploiement (production, mise en scène et développement), la date de déploiement et l’équipe responsable. Le registre fournit une source de preuve unique pour l’état de l’infrastructure de l’agent.

Le suivi de déploiement consigne chaque déploiement d’agent, y compris la version déployée, l’environnement, l’horodatage du déploiement, l’utilisateur déployant, les approbations obtenues et le résultat du déploiement. Utilisez l’historique de déploiement pour évaluer l’impact en cas de problème (par exemple, « quels agents ont été déployés avant le début de cet incident ? ») et pour prendre en charge les rapports de conformité.

Le suivi des dépendances cartographie les relations entre les agents, les invites, les bases Knowledge, les actions et les intégrations. Lors de la mise à jour de la base de Knowledge partagée, le suivi des dépendances révèle les agents affectés. Lorsque l’intégration externe change, le suivi des dépendances identifie les agents impactés.

Documentez explicitement les dépendances au lieu de les découvrir pendant les incidents. Créez des cartes de dépendance gérées via des processus de développement et de déploiement.

Les politiques de dépréciation définissent les cycles de vie des versions de modèle, notamment la durée de support, la chronologie de dépréciation et les exigences de migration. Des stratégies de dépréciation claires gèrent la dette technique empêchant la prise en charge indéfinie des anciennes versions de modèle. Établir un calendrier d’amortissement communiquant des calendriers suffisamment à l’avance pour permettre des migrations planifiées plutôt que des interventions d’urgence en cas de dépréciation forcée. Une période de préavis minimale bien communiquée et étayée par des politiques offre un temps de migration suffisant pour les changements critiques.

Les procédures de restauration permettent aux équipes de récupérer rapidement après des déploiements problématiques. Documentez les procédures de restauration pour chaque agent et incluez les éléments suivants :

Conditions qui déclenchent une restauration
Quelle version rétablir
Comment exécuter la restauration
Qui autorise et effectue la restauration
Quels tests confirment la réussite de la restauration et quelles équipes notifier.

Testez régulièrement les procédures de restauration dans des environnements de non-production pour vérifier leur fonctionnement avant d’en dépendre en cas d’incident de production. Répétez avec des déploiements fictifs pour indiquer à l’équipe ce qu’elle doit faire. Les procédures de restauration non testées échouent souvent lorsque nécessaire.

Maintenez la qualité des agents grâce à des workflows de formation continue, d’ajustement et d’amélioration.

La collecte de commentaires recueille systématiquement les commentaires des utilisateurs, les corrections des examens humains, les évaluations de la qualité et les mesures des résultats. Les commentaires fournissent une matière première pour l’amélioration. Sans collecte systématique, l’amélioration devient hésitation. Recueillez des commentaires explicites par le biais de questions posées avant l’escalade, après la fin d’une conversation ou par le biais d’enquêtes de suivi. Recueillez des commentaires implicites à travers des taux de réalisation, des fréquences d’escalade et des modèles de nouvelle tentative. Combinez des signaux explicites et implicites pour offrir une perspective de qualité complète.

La curation des données maintient des jeux de données d’entraînement de haute qualité par le biais de la curation, de l’examen de la qualité et de la vérification des biais. La qualité des données d’entraînement détermine directement la qualité du modèle. Des données médiocres produisent des modèles peu fiables. D’excellentes données permettent des performances exceptionnelles.

Organiser les journaux de conversation dans des jeux de données d’entraînement en :

Filtrage de la qualité - y compris les conversations les mieux notées et les résultats réussis
Suppression des exemples problématiques - y compris les infractions et les erreurs de sécurité
Garantir la représentativité - y compris divers scénarios et requêtes périphériques
Déduplication - retrait d’exemples quasi identiques

Adaptez les agents à votre domaine (vocabulaire spécialisé, processus métiers uniques, Knowledge spécifique à l’organisation), principalement grâce à la génération augmentée de récupération (RAG) basée sur Data 360 et au réglage rapide, la voie native de Salesforce.

Aucun modèle génératif n’est affiné dans Salesforce. Vous sélectionnez et configurez des modèles via des modèles IA et Générateur de répliques. Lorsque la mise à la terre est insuffisante, ajustez en externe, puis connectez-vous via BYOLLM.

Affiner les répliques améliore itérativement les répliques en fonction des données de performance en utilisant le Générateur de répliques. L’ingénierie des invites est une pratique continue plutôt qu’un exercice unique. À mesure que les modèles d’utilisation évoluent, que les processus métiers changent et que les attentes des utilisateurs évoluent, les invites doivent être ajustées afin de maintenir des performances optimales.

Définissez une cadence d’examen rapide régulière examinant les conversations récentes, les métriques de qualité et les commentaires des utilisateurs identifiant les opportunités d’amélioration. Implémentez les modifications des invites de façon incrémentielle avec des tests A/B qui valident les améliorations avant le déploiement complet.

L’automatisation de l’évaluation exécute l’évaluation de la qualité sur des ensembles de tests disponibles, ce qui permet d’évaluer rapidement les candidats à l’amélioration. L’évaluation automatisée fournit une mesure objective qui complète l’évaluation subjective humaine.

Gérez des ensembles de tests couvrant les parcours heureux, les requêtes périphériques, les entrées contradictoires et les scénarios de problèmes historiques. Définissez l’automatisation des tests pour exécuter vos scénarios de test sur une cadence régulière. Incluez une surveillance automatisée des résultats, des seuils et des notifications pour alerter les administrateurs des anomalies. Ces tests automatisés sont essentiels pour détecter les effets néfastes de facteurs externes tels que la dérive du modèle.

Agrandissez continuellement les ensembles de tests à mesure que de nouveaux boîtiers de bord sont exposés en production. L’automatisation des tests est essentielle, mais effectuez également des contrôles manuels périodiques, des tests uniques et des tests de gorille pour vous assurer que votre déploiement d’agents résiste aux requêtes périphériques.

Déployez progressivement les modifications des agents et surveillez la qualité avant le déploiement complet afin de limiter le rayon d’explosion des problèmes. Lorsqu’une modification couvre plusieurs domaines (invites, configuration du modèle, actions, ancrage, intégrations), elle peut dégrader le comportement sans que les tests aient réussi. Lorsque cela se produit, la régression de qualité qui en résulte pointe rarement vers une cause première unique et évidente. Expédiez les petites modifications individuellement afin de tracer une régression jusqu’à sa source, puis relâchez chacune dans une tranche limitée du trafic d’abord pour limiter l’impact pendant que vous diagnostiquez.

Les indicateurs de fonctionnalité découplent le déploiement de la version en déployant les agents dont les fonctionnalités sont désactivées derrière la configuration. Implémentez des indicateurs de fonctionnalité en utilisant des types de métadonnées logiques ou personnalisées, ou des paramètres personnalisés. Les indicateurs de fonctionnalité activent les tests dans l’environnement de production sans exposer les fonctionnalités aux utilisateurs, les déploiements progressifs dans des segments d’utilisateurs spécifiques, les tests A/B comparant les implémentations et l’annulation instantanée en désactivant les indicateurs sans redéploiement.

Utilisez des indicateurs de fonctionnalité pour les changements importants d’agents, lorsque le rayon d’explosion d’une panne peut être grave, par exemple Changements affectant les agents critiques pour l’entreprise, Nouveaux modèles de raisonnement avec un comportement de production incertain Intégrations à des systèmes externes où les modèles d’interaction peuvent différer des tests.

Les déploiements Canary libèrent les modifications apportées par les agents aux petits sous-ensembles d’utilisateurs, en commençant par surveiller les taux d’erreur, les métriques de qualité et les performances avant un déploiement élargi. Utilisez des ensembles d’autorisations pour contrôler les déploiements canaris, limiter l’accès des agents à un sous-ensemble d’utilisateurs ou filtrer dans une logique d’orchestration basée sur des attributs utilisateur.

Surveillez et mesurez les taux de réussite, la qualité des réponses et les commentaires des utilisateurs. Comparez les métriques canaries à des groupes de contrôle en utilisant la version précédente de l’agent. Élargissez le déploiement uniquement lorsque Canary démontre des performances équivalentes ou améliorées.

Les tests A/B comparent les variations des agents qui mesurent la qualité, le coût et la satisfaction des utilisateurs. Les tests A/B fournissent des preuves empiriques pour les décisions d’amélioration. Déployez des variantes dans des sous-ensembles d’utilisateurs sélectionnés de façon aléatoire afin de garantir la validité statistique. Mesurez les résultats à travers plusieurs dimensions (précision, satisfaction, coût et latence) en offrant une comparaison complète.

Définissez des critères de réussite et une hypothèse avant de commencer les tests A/B. Des critères clairs évitent les résultats ambigus lorsque certaines métriques s’améliorent et d’autres se dégradent. Les critères de réussite devraient correspondre aux objectifs opérationnels (par exemple, « la variante B doit correspondre à la précision de la variante A dans les 2 % tout en réduisant le coût de 15 % »).

Le test Champion-challenger déploie des versions d’agent améliorées dans des sous-ensembles de trafic par rapport aux versions Champion actuelles. Le modèle champion-challenger gère le risque d’amélioration en maintenant la version éprouvée en tant que solution de repli. Si le challenger est moins performant, redevenez champion sans impact utilisateur. Si le challenger surpasse, faites-le la promotion du nouveau champion.

Établir des critères objectifs de promotion, notamment la taille minimale de l’échantillon pour la validité statistique, les seuils de qualité que les contestataires doivent dépasser et la durée d’évaluation avant les décisions de promotion. Documentez les décisions de promotion en créant un journal d’audit indiquant les raisons pour lesquelles les versions des agents ont changé.

Définissez rapidement la détection des incidents en identifiant les problèmes opérationnels des agents grâce à une surveillance complète.

Les modes d’échec des agents diffèrent des échecs d’application traditionnels. Les modes d’échec courants comprennent :

Hallucinations - générer des informations plausibles mais incorrectes
Réponses hors sujet - Incompréhension de l’intention de l’utilisateur
Consommation excessive de coûts - génération galopante de jetons
Échecs d’expiration - inférence trop longue
Erreurs d’autorisation - tentatives d’actions non autorisées
Échecs d’intégration - indisponibilité du système externe
Infractions à la sécurité - génération de contenus inappropriés

Détectez les échecs en alertant par surveillance automatisée sur les taux d’erreur, la dégradation des métriques de qualité, les anomalies de coût, les augmentations de latence et les escalades utilisateur. Complétez les mécanismes d’auto-rapport des utilisateurs, notamment les demandes de commentaires et des conseils clairs sur la façon et l’emplacement de soumettre des commentaires, afin de corriger les lacunes signalées dans l’automatisation.

La classification de gravité achemine les incidents vers les intervenants appropriés avec l’urgence appropriée. Des incidents critiques indiquent une indisponibilité en production affectant de nombreux utilisateurs, un risque de corruption des données lié aux actions des agents, une atteinte à la sécurité ou des violations de la sécurité nécessitant une réponse immédiate. Une sévérité élevée indique une dégradation de la qualité affectant les agents critiques de l’entreprise ou des dépassements de coûts importants. La gravité moyenne indique des problèmes isolés ou des seuils proches nécessitant une enquête pendant les heures ouvrables. Une faible sévérité indique des problèmes mineurs suivis hors du processus de gestion des incidents.

Définissez objectivement des critères de sévérité basés sur l’impact utilisateur, le rayon d’explosion, le risque d’intégrité des données et l’urgence de récupération. Des critères objectifs empêchent la sous-escalade des problèmes réels et la surescalade des problèmes mineurs. Tenir à jour la documentation sur les conclusions de la résolution des incidents afin d’améliorer continuellement le processus.

Les procédures initiales guident les actions immédiates visant à stabiliser la situation. Les procédures comprennent :

Désactiver l’activation de l’agent défaillant - disjoncteur
Acheminer les utilisateurs vers des options de repli - transfert humain, agent plus simple, réponses statiques
Collecter des informations de diagnostic - conversations récentes, journaux d’erreur, métriques de ressource
Notifier les parties prenantes - ingénieurs d’astreinte, propriétaires de produits, utilisateurs affectés
Initier la communication sur les incidents - mises à jour de page de statut, canaux de coordination interne
Documentez les procédures de réponse initiale sous forme de runbooks permettant une exécution rapide sans nécessiter d’enquête spécifique à un incident.
Les runbooks doivent être exécutables par des ingénieurs d’astreinte sans expertise approfondie des agents.

Évitez les échecs en cascade et maintenez une fonctionnalité partielle pendant les incidents avec les agents.

Le disjoncteur désactive automatiquement les agents défaillants afin d’éviter les pannes répétées et l’impact sur l’utilisateur pendant que les problèmes sont résolus. Implémentez des disjoncteurs pour surveiller les taux d’erreur et l’ouverture (agent désactivant) lorsque le taux d’erreur dépasse le seuil pendant une période prolongée.

Configurez des disjoncteurs avec seuil d’erreur, fenêtre de durée et test de récupération. Par exemple, un taux d’erreur de 50 % avec une fenêtre glissante de cinq minutes et une évaluation périodique qui demande de tester si l’agent a récupéré. À l’ouverture du circuit, acheminez les requêtes vers des options de repli. Après une période d’expiration, le circuit passe à un état semi-ouvert permettant aux demandes d’évaluation d’être acceptées. Lorsque les demandes d’évaluation réussissent régulièrement, fermez le circuit et reprenez un fonctionnement normal.

Les hiérarchies de repli offrent une dégradation gracieuse lorsque les agents principaux échouent. Concevez des séquences de repli en essayant des options de plus en plus simples jusqu’à ce qu’une réponse acceptable soit obtenue. Exemple de hiérarchie de repli : Agent sophistiqué principal → Agent de sauvegarde plus simple → Réponses FAQ statiques → Transfert humain.

Implémentez une logique de repli dans la couche d’orchestration plutôt qu’au sein des agents afin de permettre un comportement cohérent dans l’écosystème des agents. Testez régulièrement les parcours de secours pour vérifier leur fonctionnement en cas de besoin.

Le transfert humain s’escalade vers les agents humains lorsque les agents IA ne peuvent pas gérer les requêtes. Concevez des workflows de transfert en préservant le contexte de la conversation, en communiquant le motif du transfert, en acheminant vers les agents humains appropriés qui ont l’expertise appropriée et en suivant la fréquence de transfert pour révéler des opportunités d’amélioration.

Surveillez les taux d’escalade par rubrique, agent et motif d’échec. Des taux plus élevés indiquent des lacunes dans les capacités des agents qui nécessitent des améliorations rapides, une extension de la base Knowledge ou une amélioration des cas d’utilisation.

Une dégradation gracieuse maintient une fonctionnalité partielle pendant un fonctionnement dégradé. Lorsque le raisonnement sophistiqué échoue, revenez à une logique plus simple. Lorsque les données en temps réel ne sont pas disponibles, utilisez des données mises en cache. Lorsque les intégrations externes échouent, fonctionnez en mode lecture seule. La dégradation gracieuse permet à un système de continuer à fonctionner en capacité réduite au lieu de tomber en panne complète.

Effectuez des examens post-incident irréprochables en vous concentrant sur les améliorations du système plutôt que sur la création d’une faute individuelle créant une sécurité psychologique pour une évaluation honnête.

La reconstruction chronologique crée une séquence détaillée depuis les conditions initiales jusqu’au premier signal, la détection, l’accusé de réception, l’enquête, les actions de réponse, la récupération et la validation. Horodatage de chaque événement permettant d’analyser la durée de chaque phase pour déterminer où la réponse à l’incident a été retardée.

Insérez les éléments suivants dans votre chronologie :

Quels éléments ont été déployés récemment (invites, configurations, modèles, intégrations) ?
Quels changements dans les modèles d’utilisation (augmentation soudaine du trafic, nouveaux types de conversation) ont été observés ?
Quels facteurs externes ont contribué (dégradation du service tiers, mises à jour de la plate-forme) ?
Qu’est-ce qui rend la détection plus lente que l’idéal ?

L’identification des causes premières détermine la cause technique directe. Distinguez la cause immédiate (expiration du modèle) des facteurs contributifs (conception d’invites dépassant les limites en jetons dans des modèles de conversation spécifiques). L’analyse des causes premières empêche les conclusions simplistes (« l’agent avait un bogue ») en faveur de conclusions spécifiques qui entraînent une correction efficace.

Utilisez la technique « Cinq pourquoi », forant des symptômes aux causes fondamentales.

Exemple de surface : « L’agent a produit des informations incorrectes » → « Pourquoi ? Le contexte récupéré contenait des données obsolètes” → “Pourquoi ? La base Knowledge n’a pas été mise à jour avec les récentes modifications des produits” → “Pourquoi ? Aucun processus n’existe pour que l’équipe produit déclenche les mises à jour de la base Knowledge” → Cause première: Workflow manquant reliant les versions de produits à la maintenance de la base Knowledge.

Les facteurs contributifs révèlent des conditions organisationnelles, de processus ou architecturales permettant ou amplifiant l’impact des incidents. Parmi les facteurs courants figurent les lacunes dans la surveillance qui laissent les problèmes persister plus longtemps que détectés, les lacunes dans les tests qui laissent les scénarios d’échec découverts, les lacunes dans la documentation qui ralentissent le diagnostic rapide, les lacunes dans l’automatisation qui forcent les étapes de récupération manuelles et les lacunes architecturales telles que les points de défaillance uniques ou les redondances manquantes.

L’analyse des facteurs contributifs révèle des opportunités d’amélioration qui dépassent la correction immédiate des causes premières. La plupart des incidents ont plusieurs facteurs contributifs, chacun amplifiant l’impact.

L’analyse de détection examine comment l’incident a été détecté et si la détection aurait pu être plus rapide. De nombreux incidents impliquant des agents sont d’abord signalés par les utilisateurs plutôt que par la surveillance automatisée, ce qui indique une lacune dans la surveillance. Déterminer : Quel signal aurait dû détecter le problème plus tôt ? Quelle surveillance permettrait une détection plus rapide ? Quels critères d’alerte auraient été déclenchés de façon appropriée ?

Les améliorations de l’analyse de la détection comprennent : Ajout d’une couverture de surveillance manquante, réglage des seuils d’alerte pour éliminer les faux négatifs, enrichissement du contexte des alertes pour accélérer le tri et amélioration des tableaux de bord pour l’identification proactive des problèmes.

L’évaluation des réponses évalue ce qui s’est bien passé et ce qui a été plus lent ou plus difficile que nécessaire. Questions d’évaluation des réponses : Les runbooks étaient-ils utiles et précis ? Les voies d’escalade étaient-elles claires et efficaces ? Les procédures de restauration ont-elles été testées et prêtes? Les outils fournissaient-ils les informations diagnostiques nécessaires ? La communication était-elle rapide et efficace?

Les améliorations apportées à l’évaluation des réponses comprennent : mise à jour des runbooks avec les leçons apprises, clarification des critères d’escalade, test régulier des procédures de restauration, ajout d’outils de diagnostic et amélioration des modèles de communication sur les incidents.

Les éléments d’action spécifient des améliorations concrètes, attribuées et assorties de délais afin d’empêcher la récurrence ou d’améliorer les interventions futures. Évitez les éléments d’action vagues, tels que « améliorer la surveillance », en faveur de tâches spécifiques, telles que « ajouter une alerte pour le taux d’erreur de l’agent supérieur à 5 % sur une période de 10 minutes, attribué : Alex, dû : 2 semaines.”.

Suivez l’exécution des éléments d’action dans les examens suivants afin de vous assurer que l’amélioration continue est effective. Examinez les éléments d’action en cours des incidents précédents pendant chaque examen postérieur à l’incident. Les faibles taux de réalisation indiquent que l’échec du processus d’amélioration continue nécessite une attention particulière.

Knowledge sharing documente les examens postérieurs à un incident dans un wiki, une base Knowledge ou un espace de collaboration partagé, avec balisage permettant d ’ analyser les schémas d ’ incidents multiples. Les rétrospectives d’incidents devraient pouvoir être recherchées par mode de défaillance, composants affectés et période permettant aux futurs intervenants d’apprendre des incidents historiques.

Partagez les examens postérieurs à un incident au-delà des intervenants immédiats. L’apprentissage organisationnel nécessite la propagation de l’information. Envisagez de présenter les apprentissages sur les incidents majeurs lors de réunions d’équipe ou de séances de déjeuner-apprentissage pour diffuser Knowledge et renforcer les capacités collectives.

Demandez l’approbation avant de déployer des agents de production pour garantir l’examen, l’évaluation des risques et l’alignement des parties prenantes.

La liste de contrôle préalable au déploiement valide la préparation, notamment :

Test complet terminé - fonctionnalité, qualité, sécurité, performance
Contrôle de sécurité approuvé - limites des autorisations, accès aux données, autorisation d’action
Conformité validée - exigences réglementaires, adhésion aux politiques
Documentation complète - runbooks, procédures de restauration, parcours d’escalade
Surveillance configurée - métriques de qualité, taux d’erreur, suivi des coûts
Approbation des parties prenantes obtenue - propriétaire du produit, sécurité, conformité

Liste de contrôle fournit des critères d’évaluation cohérents entre les agents. Adaptez la liste de contrôle au profil de risque des agents en fonction de la criticité, de la sensibilité des données et du niveau d’autonomie des agents.

L’évaluation des risques évalue l’impact potentiel des défaillances des agents, notamment :

Rayon d’explosion - nombre d’utilisateurs affectés par une panne
Sensibilité des données - ce à quoi l’agent de données accède
Autorité d’action - quelles modifications l’agent peut apporter
Dépendances d’intégration - quel agent système affecte
Complexité de la récupération - quelle est la difficulté d’annuler
Conséquences sur la conformité - Quels règlements s’appliquent

L’évaluation des risques détermine les exigences d’approbation. Les agents à risque élevé doivent obtenir l’approbation de la direction, un contrôle de sécurité et un déploiement progressif, alors que les agents à faible risque peuvent nécessiter un examen par les pairs et des tests standard.

Les workflows d’approbation acheminent les demandes de déploiement via les examinateurs appropriés. Implémentez des workflows d’approbation en utilisant des processus d’approbation Salesforce ou des outils de déploiement externes. Automatisez, suivez et auditez les workflows d’approbation pour activer les rapports de conformité et les enquêtes sur les incidents.

Documentez les décisions d’approbation, en créant un journal d’audit indiquant qui a approuvé les déploiements, quelles informations ont éclairé les approbations, quelles conditions ou restrictions ont été appliquées et quels engagements de surveillance ont été pris.

Les procédures de contournement d’urgence permettent un déploiement rapide en cas d’incident de production lorsque les processus d’approbation normaux retardent les correctifs critiques. Les procédures d’urgence doivent être approuvées par le cadre supérieur, inclure des documents justificatifs et déclencher un examen accéléré après le déploiement qui valide les changements d’urgence.

Suivez les déploiements d’urgence séparément des versions standard. La fréquence de déploiement d’urgence élevée indique des problèmes de processus qui nécessitent une enquête.

Définissez des barrières de qualité que les agents doivent franchir avant le déploiement en production afin d’empêcher les agents problématiques d’atteindre les utilisateurs.

Les tests fonctionnels vérifient que les agents exécutent correctement les tâches prévues dans des scénarios représentatifs. Testez des parcours heureux qui couvrent des interactions typiques, des requêtes périphériques qui couvrent des scénarios peu fréquents mais valides, des parcours d’erreur qui testent si les agents gèrent gracieusement les entrées non valides, et des conditions aux limites qui vérifient si l’agent respecte les limites du gouverneur, les limites en jetons et les limites en volume de données.

Le test fonctionnel des agents diffère du test traditionnel, car les sorties non déterministes empêchent la correspondance exacte. Les caractéristiques de sortie du test (contient les informations requises, conserve le ton approprié, inclut les citations nécessaires) plutôt que le texte exact.

Les tests de qualité des réponses évaluent la précision et la pertinence des réponses dans les scénarios de test. Les tests de qualité nécessitent une évaluation humaine ou des jeux de données de base-vérité avec les résultats attendus. Établir des seuils de qualité minimale que les agents doivent atteindre (par exemple, « 95 % de précision sur l’ensemble de tests retenus, zéro infraction à la sécurité, la vérification de l’équité ne révèle aucune disparité démographique supérieure à 5 % »). Gérez et agrandissez en permanence les ensembles de tests à mesure que de nouveaux cas de bord sont découverts.

Les tests de sécurité vérifient que les agents refusent les demandes dangereuses, contraires à l’éthique ou hors de portée. Les essais de sécurité tentent des entrées contradictoires, notamment :

Tentatives d’injection d’invites - en essayant de remplacer les instructions
Tentatives de jailbreak - essayer de contourner les contraintes de sécurité
Demander l’escalade - demander des actions de plus en plus sensibles
Requêtes hors champ - tentatives de tâches non autorisées

Attribuez des tests de sécurité aux membres indépendants de l’équipe qui n’ont pas participé à l’élaboration de l’agent. Pour les agents à haut risque, faites appel à des spécialistes de l’équipe rouge.

Les tests de performance vérifient que la latence, le débit et le coût répondent aux attentes. Testez sous une charge réaliste, y compris les conversations simultanées, la durée typique des conversations et le volume d’utilisation projeté. Les tests de performance révèlent des problèmes de limitation du gouverneur, des contraintes en ressources et des blocages d’évolutivité invisibles dans les tests mono-utilisateur.

Mesurez la consommation d’environnement de test pendant les tests de performance et utilisez-la pour projeter les besoins en capacité de production.

Les tests de sécurité valident les limites des autorisations, les contrôles d’accès aux données et l’autorisation d’action. Les tests de sécurité confirment : les agents ne peuvent pas accéder à des données non autorisées, les agents ne peuvent pas exécuter des actions non autorisées, l’injection rapide ne peut pas escalader les privilèges et la consignation d’audit capture toutes les activités des agents.

Intégrez la lecture statique de la sécurité du code au pipeline de déploiement en utilisant Salesforce Code Analyzer, qui analyse Apex, Flows, Lightning et Visualforce pour détecter les failles de sécurité et peut être exécuté en intégration/déploiement continu (CI/CD) via son interface de ligne de commande (CLI) ou son action GitHub. Utilisez des tests de sécurité spécialisés IA/agents pour détecter les vulnérabilités d’injection rapide et les risques d’exposition à des données confidentielles, car il s’agit de menaces d’entrée LLM à l’exécution hors du cadre de l’analyse de code statique.

Appliquez une discipline de gestion des modifications aux déploiements d’agents en veillant à ce que les modifications soient documentées, révisées et communiquées.

Captures de la documentation de modification :

Ce qui a changé - modifications des invites, mises à jour de configuration, changements de modèle
Pourquoi cette modification a été effectuée - amélioration de la qualité, optimisation des coûts, correction de bogues
Quels tests ont validé cette modification - résultats de test, scores de qualité, analyses de sécurité
Quelle procédure de restauration existe

La documentation sur les modifications permet d’effectuer des enquêtes sur les incidents, de générer des rapports de conformité et de transférer Knowledge. Les modifications documentées créent une organisation apprenante qui s’appuie sur l’expérience précédente plutôt que de redécouvrir les leçons.

La planification des communications notifie les parties prenantes des changements d’agent, notamment les utilisateurs affectés, les équipes opérationnelles, les équipes de support et les parties prenantes de l’entreprise. La communication doit décrire : ce qui change, quand le changement se déploie, quels avantages les utilisateurs verront, quels risques existent et qui contacter en cas de problème.

Établissez des modèles de communication pour différents types de modification afin de standardiser les messages et de réduire les coûts de préparation du déploiement.

La planification du déploiement permet aux agents de planifier les déploiements pendant les périodes de faible utilisation, en s’appuyant sur les données de Surveillance des événements qui montrent les modèles d’utilisation réels. Évitez les déploiements pendant les pics d’utilisation, les fermetures de fin de mois, les fermetures de trimestre ou les événements commerciaux majeurs. Communiquez les fenêtres de déploiement, notamment la durée prévue et le calendrier de décision d’annulation.

Envisagez de planifier des changements majeurs pour le début à la mi-semaine et évitez les déploiements en fin de semaine afin de résoudre les problèmes avec des ressources adéquates. Donnez la priorité à l’annulation rapide et à la surveillance post-déploiement forte sur n’importe quelle règle de calendrier fixe.

Les modifications de fenêtres et les gels protègent les périodes commerciales critiques. Établissez des périodes de suspension des modifications avant les événements commerciaux majeurs (fin d’exercice fiscal, lancement de produits et campagnes marketing majeures) afin d’éviter les problèmes liés au déploiement pendant les périodes à fort enjeu.

Le calendrier de suspension des modifications des documents communique chaque année des périodes restreintes suffisamment à l’avance pour permettre aux équipes de planifier en conséquence. Les gels excessifs ralentissent la vitesse; un gel insuffisant crée un risque commercial.

Établissez des boucles de rétroaction reliant la télémétrie opérationnelle à l’amélioration des agents.

La collecte de commentaires recueille des commentaires explicites par le biais de questions ou d’enquêtes de suivi. Recueillez des commentaires implicites à travers des taux de réalisation, une escalade vers des agents humains, des modèles de nouvelle tentative et des questions de suivi indiquant une insatisfaction. Combinez des signaux explicites et implicites, offrant une perspective de qualité complète.

Recueillez des commentaires en ligne, au moment opportun et pas plus tard. Le report de la collecte de commentaires réduit les taux de réponse et introduit un biais de rappel.

Les analytiques d’utilisation exposent des modèles de conversation réels, tels que des rubriques, des questions et des tendances récurrentes. Ils vérifient si la complexité d’un agent mérite d’être conservée, si les capacités sont inutilisées en raison d’une faible découvrabilité et si l’utilisation réelle valide les hypothèses de conception d’origine.

Interrogez les journaux de conversation en analysant les types de question, la durée des conversations, les taux de réussite par rubrique et la satisfaction des utilisateurs par caractéristiques de conversation. L’analyse des modèles d’utilisation guide l’affinement rapide, l’expansion de la base Knowledge et la priorisation des capacités.

L’analyse des modèles d’erreur identifie les problèmes de qualité systématiques qui nécessitent une correction. Analysez le regroupement des journaux d’erreur par type d’erreur, utilisateurs affectés, modèles de conversation et distribution temporelle. Les modèles d’erreur révèlent des problèmes d’invite, des lacunes dans la base Knowledge, des problèmes d’intégration ou des requêtes périphériques nécessitant un traitement.

Priorisez la correction des erreurs par fréquence et impact. Les erreurs fréquentes affectant de nombreux utilisateurs nécessitent une attention immédiate. Les erreurs peu fréquentes peuvent représenter des cas marginaux acceptables selon l’impact commercial et le coût de la correction.

La surveillance des tendances de qualité suit la précision, la pertinence, la sécurité et la satisfaction au fil du temps en détectant les dégradations avant qu’elles ne deviennent graves. Établissez des niveaux de référence de qualité après le déploiement initial de l’agent. Surveillez la qualité continue par rapport aux alertes de référence lorsque les tendances diminuent au-delà des seuils acceptables.

La surveillance de la qualité indique si des changements rapides, des mises à jour de modèle ou des modifications de base Knowledge améliorent ou dégradent les performances permettant des décisions d’amélioration pilotées par les données.

Suivez les expériences en informant systématiquement les décisions d’amélioration avec des données empiriques.

Le cadre expérimental fournit une structure cohérente pour les améliorations des tests, notamment :

Hypothèse - quelle amélioration est attendue
Conception expérimentale - comment les variantes sont déployées
Métriques - quels résultats sont mesurés
Taille de l’échantillon - nombre d’interactions nécessaires pour la validité statistique
Critères de réussite - quels résultats justifient la promotion

Documentez les expériences avant l’exécution afin d’éviter une interprétation ambiguë des résultats. Les critères de réussite prédéfinis permettent de prendre des décisions de promotion claires, ce qui évite de longs débats sur la question de savoir si les résultats sont « assez bons ».

Les journaux de suivi des variantes indiquent quels utilisateurs ont reçu quelles variantes activent la corrélation des résultats. Suivez l’attribution de variantes dans les métadonnées de conversation afin d’analyser la qualité, le coût et la satisfaction par variante.

La validité statistique garantit que les expériences durent suffisamment longtemps avec une taille d’échantillon suffisante pour des conclusions fiables. Calculez la taille de l’échantillon requise avant les expériences en fonction de la taille de l’effet attendu, des besoins en puissance statistique et des taux d’erreur acceptables. L’insuffisance d’échantillons produit des résultats bruyants qui entraînent de mauvaises décisions.

L’optimisation multibras bandit alloue dynamiquement plus de trafic aux variantes les plus performantes pendant les expériences. Les approches de banditisme multi-armes réduisent les coûts d’opportunité de l’expérimentation en réduisant l’exposition aux variants inférieurs tout en recueillant suffisamment de données pour l’analyse statistique.

Le catalogue des expériences consigne les variantes, les résultats et les décisions de chaque expérience. Il empêche les équipes de tester de nouveau les approches échouées, dissémine les apprentissages à travers l’organisation et crée un enregistrement partagé des éléments qui fonctionnent réellement.

L’excellence opérationnelle des systèmes agents nécessite d’étendre les pratiques DevOps traditionnelles pour répondre aux caractéristiques uniques de l’IA. L’observabilité complète permet de comprendre le comportement des agents émergents. La gestion systématique du cycle de vie garantit la qualité, la sécurité et le contrôle des coûts. Les procédures de réponse aux incidents traitent des modes d’échec spécifiques à l’agent. L’amélioration continue transforme l’expérience opérationnelle en capacité organisationnelle.

Pratiques clés pour l’excellence opérationnelle dans les systèmes agentsiques :

Consignez des conversations complètes, y compris des entrées, des sorties, des traces de raisonnement, des actions et des résultats.
Surveillez en permanence la qualité des réponses grâce à des métriques de précision, de pertinence, de sécurité et de satisfaction.
Détecter les dérives du modèle et les changements de comportement grâce à une comparaison de référence et à la détection d’anomalies.
Invites de contrôle de version, configurations et modèles qui activent l’annulation et les tests A/B.
Implémentez un déploiement progressif avec des indicateurs de fonctionnalité et des déploiements de canaris limitant le rayon d’explosion.
Concevez des disjoncteurs et des hiérarchies de secours évitant les pannes en cascade des agents.
Effectuez des examens post-incident irréprochables axés sur des améliorations systématiques.
Établissez des barrières de qualité et des processus d’approbation afin d’empêcher les agents problématiques d’atteindre la production.
Élaborez des boucles de rétroaction reliant la télémétrie opérationnelle à l’amélioration des agents.
Suivez systématiquement les expériences en utilisant des preuves empiriques pour guider les décisions d’amélioration.

Les organisations qui investissent dans l’excellence opérationnelle des agents bénéficient d’un avantage concurrentiel durable grâce à des capacités IA fiables et de grande qualité qui évoluent en permanence en fonction des besoins métiers.

Partagez vos commentaires sur l'infrastructure bien archivée.