Agents AI axés sur l'évaluation : comment Zepto met à l'échelle le support client sur Databricks et MLflow

L'engagement de Zepto pour un support client fiable et en temps réel

Zepto est l'une des plateformes de commerce rapide connaissant la croissance la plus rapide en Inde, avec plus de milliers de produits, une présence dans plus de 60 villes et des délais de livraison mesurés en minutes. Dans un secteur où la rapidité est le produit lui-même, le support client doit être tout aussi rapide.

Pour répondre à cette attente, Zepto gère son support client sur un système AI multi-agent qui traite plus de cent mille tickets par jour. Au début, l'équipe pouvait concevoir et déployer des agents rapidement. La question la plus difficile était de savoir comment maintenir la fiabilité de ces agents à mesure que le volume augmentait, que les catégories se diversifiaient et que le comportement des clients continuait d'évoluer. Zepto s'est associé à Databricks pour répondre à cette question, non pas en déployant plus d'agents, mais en faisant de l'évaluation la méthode principale pour concevoir, tester et exploiter les agents.

Ce blog retrace ce parcours : l'architecture du système, le framework d'évaluation sur Databricks et MLflow, les retours d'expérience en production qui ont prouvé sa valeur, ainsi que les résultats et les enseignements qui en découlent.

Pourquoi « se contenter de déployer l'agent » ne fonctionne plus à grande échelle

Dans une entreprise à rythme soutenu, « se contenter de déployer l'agent » fonctionne jusqu'à ce que cela ne marche plus à grande échelle. Avec plus de 100 000 tickets d'agents AI par jour, même un taux d'erreur de 1 % génère des milliers de résultats insatisfaisants et de réelles pertes de revenus chaque jour.

La pression est arrivée par vagues irrégulières. Les intempéries, Diwali et le début de l'été ont entraîné de forts pics de volume de tickets. L'expansion de l'épicerie vers l'habillement, l'électronique et la beauté a introduit de nouveaux parcours de remboursement, d'échange et de retour. Par ailleurs, une base de clients plus diversifiée et multilingue a entraîné un éventail plus large de demandes de support, et de nouveaux modes de défaillance sont apparus toutes les quelques semaines.

Le problème de fond est le déficit de fiabilité. Les systèmes agentiques fonctionnent comme des workflows multi-étapes (classification des intentions, récupération des connaissances, analyse des entrées, raisonnement pour la prise de décision, appel d'outils transactionnels et génération de réponses), de sorte que des défaillances peuvent survenir à n'importe quelle étape du parcours, et pas seulement dans la réponse finale.

Ce déficit de fiabilité s'est traduit par des problèmes concrets :

• Les défaillances restaient invisibles jusqu'à ce que les clients se plaignent
• Les corrections étaient lentes
• La réponse finale masquait des erreurs internes
• Absence de méthode structurée pour équilibrer le coût, la performance et la qualité de l'agent
• La conception de l'agent ne prenait pas en compte tous les points de vue essentiels des parties prenantes
• La fiabilité était difficile à garantir face à l'évolution rapide des agents

L'objectif est devenu clair : concevoir un framework d'évaluation sur Databricks et MLflow afin qu'il serve d'infrastructure AI de base pour la conception et l'exploitation des agents.

Pourquoi un framework d'évaluation et quels en sont les résultats

Un framework d'évaluation solide influe directement sur cursive cinq axes de préparation à la production :

• Fiabilité : des garanties au niveau du système que les agents se comportent correctement à chaque étape, et pas seulement qu'ils « semblent cohérents »
• Vélocité : des itérations plus rapides et plus sûres sur les prompts, les politiques et les modèles, car les modifications font l'objet de tests de régression automatiques
• Contrôle des coûts, de la qualité et des performances : capacité à choisir les modèles optimaux, les stratégies de prompt ou les stratégies de routage hybrides pour trouver le juste équilibre face aux contraintes, sur la base de données d'évaluation concrètes
• Gouvernance : des traces auditables, des bases de référence d'évaluation versionnées et des seuils bien définis pour le déploiement et le retour en arrière. Passer de décisions basées sur l'intuition (« cette version semble meilleure ») à des décisions basées sur des preuves (« cette version surpasse la base de référence selon les métriques convenues »)
• Collaboration avec les parties prenantes : intégrer les critères de réussite et de fiabilité du point de vue des parties prenantes, et rendre les compromis explicites et mesurables pour tous

Avec Databricks + MLflow comme pilier d'évaluation et une architecture d'agent axée sur l'évaluation, Zepto a obtenu :

Coût et efficacité

• Plus de 80 % des tickets entièrement gérés par des agents AI avec une supervision humaine
• Réduction de 65 % des coûts de support ou des tickets de support
• Un retour sur investissement en moins d'un mois

Qualité et réputation

• Amélioration de 20 % de la satisfaction client (CSAT)
• Amélioration de 8 % de la précision

Performance et opérations

• Cycles de développement 3 fois plus rapides
• Résolution 4 fois plus rapide

Construire le framework : une double boucle pour la confiance et le contrôle

Au cœur de cette approche se trouve le modèle à double boucle : une boucle de développement et une boucle de production, reliées par une porte de qualité. Cette section décrit comment ces boucles fonctionnent ensemble.

• Boucle de développement : où vous concevez, itérez et évaluez les versions des agents pour les créer en toute confiance avant de les déployer
• Boucle de production : où vous surveillez le comportement en direct et détectez les défaillances pour exploiter les agents en toute confiance
• Boucle de rétroaction : où les défaillances de production sont renvoyées au développement pour enrichir l'itération suivante
• Porte de qualité : contrôlant le passage d'une boucle à l'autre, elle décide quelles versions sont autorisées en production et lesquelles sont renvoyées au développement pour de meilleures itérations

Ensemble, ces deux boucles garantissent que les agents sont conçus et exploités de manière contrôlée. Toute défaillance est automatiquement capturée, signalée et corrigée. Ainsi, les agents sont créés en toute confiance, exécutés de manière contrôlée et s'améliorent continuellement pour mieux gérer les défaillances de production au fil du temps. La double boucle est au cœur de notre framework.

Phase 0 : Activer le traçage : des agents transparents dès la conception

Chaque appel d'agent génère une trace d'exécution riche qui capture les prompts, les complétions, les documents récupérés, les appels d'outils, les latences et les chemins de décision, de sorte que l'ensemble du workflow est observable à un niveau granulaire plutôt que de se limiter à une entrée et une sortie finale.

Nous avons mis cela en place grâce à une approche hybride utilisant MLflow. Une seule ligne, mlflow.<library>.autolog(), active le traçage automatique, et le décorateur @mlflow.trace ajoute des spans personnalisés partout où nous avons besoin de plus de détails. Les traces sont émises en temps réel sous forme de spans OpenTelemetry avec des ID uniques afin de rester combinables, et l'intégration de MLflow avec Unity Catalog centralizes la journalisation dans des tables Delta.

Phase 1 : Définir les dimensions d'évaluation : piliers et portes

Une fois le traçage activé, l'étape suivante consiste à définir, du point de vue de chaque partie prenante, « Que signifie la réussite de cet agent pour vous ? ». Nous formalisons cela sous forme de piliers d'évaluation, chacun comportant des portes spécifiques.

Cela transforme un débat multipartite en un contrat partagé et mesurable. Les agents sont évalués selon les dimensions qui comptent réellement pour chaque partie prenante. Les piliers typiques comprennent l'expérience client, l'efficacité opérationnelle, les risques et la conformité, ainsi que l'impact financier ; chaque pilier comporte des seuils numériques clairs qui doivent être atteints avant le déploiement.

Phase 2 : Le jeu de données de référence (Golden Dataset) : pierre angulaire de la fiabilité

Le jeu de données de référence (golden dataset) est la source unique de vérité pour évaluer le comportement de l'agent dans la boucle de développement. Il doit :

• Couvrir les cas normaux, les cas limites (edge cases) et les cas d'erreur que l'agent doit gérer
• Inclure les attentes des différentes parties prenantes sous forme d'exemples
• Être richement annoté avec des métadonnées (type de scénario, secteur d'activité, niveau de risque, etc.)

Toutes les parties prenantes collaborent pour façonner le jeu de données. Par exemple, l'équipe de sécurité fournit des exemples de schémas contradictoires tels que l'injection de prompt, les attaques d'identité ou les tentatives d'exfiltration de données, garantissant ainsi que la fiabilité est mesurée par rapport à des scénarios réels ainsi qu'à un usage normal.

Les jeux de données sont des ressources vivantes dont la qualité s'améliore avec le temps. L'écart de précision entre le développement et la production est en soi un indicateur de la qualité du jeu de données. Zepto a investi régulièrement dans les jeux de données d'évaluation MLflow sur une période de six mois, passant de 500 exemples et un écart de précision dev-prod de 8 points, à 2 000 exemples et un écart de 2 points, puis à 5 247 exemples et un écart de 0,4 point. Chaque heure consacrée à la qualité du jeu de données permet d'économiser environ dix heures de débogage en production. Le jeu de données de référence devient ainsi un multiplicateur par 10 : chaque défaillance en production ajoute des traces d'erreur au jeu de données de référence, rendant le système plus robuste pour toutes les versions futures.

Phase 3 : Automatiser l'ingénierie des prompts : génération et optimisation automatiques

Plutôt que d'écrire les prompts à la main, nous avons fait de l'ingénierie des prompts un processus automatisé et axé sur les données. La conception des prompts est la phase critique où les ingénieurs passent le plus clair de leur temps, et la qualité des prompts a un impact disproportionné sur la qualité et les performances des résultats des agents.

Grâce à l'outil d'optimisation des prompts de MLflow, nous enregistrons un prompt initial, générons et optimisons des variantes par rapport aux mêmes évaluateurs qui valident le déploiement, exécutons automatiquement des évaluations A/B et déployons le meilleur résultat. L'optimiseur s'appuie sur un modèle puissant et évalue les candidats en production avec un modèle plus économique, afin que la recherche elle-même reste rentable en production. Cela a permis de réduire l'expérimentation manuelle des prompts, d'améliorer la précision et de garantir que les améliorations des prompts soient toujours mesurées par rapport au jeu de données de référence avant d'atteindre la production.

Phase 4 : Définir les évaluateurs et mettre en place un jury d'IA

Avec les traces qui circulent dans la boucle de production, nous devons les évaluer selon les dimensions qui comptent pour la qualité de l'agent (dimensions d'évaluation). Voyez cela comme un jury d'IA, où chaque évaluateur tire parti de ses points forts. MLflow propose trois options pour créer des évaluateurs.

• Juges intégrés - évaluateurs prêts à l'emploi
• Juges personnalisés - créez des juges personnalisés pour répondre à des besoins uniques
• Évaluateurs basés sur du code - pour des métriques déterministes comme la latence des outils ou le nombre d'appels d'outils

Nous utilisons des évaluateurs basés sur des LLM uniquement lorsqu'un jugement de type humain est nécessaire, et nous nous appuyons sur des règles simples lorsque la logique déterministe suffit. Nous calibrons les juges par rapport à des annotations humaines pour atteindre une concordance de 80 à 90 %, et nous utilisons plusieurs juges pour les décisions à enjeux élevés.

Phase 5 : Configurer la flexibilité des modèles

La flexibilité des modèles est un composant essentiel qui permet au framework de basculer entre de nombreux modèles propriétaires et open source simplement en modifiant les noms des modèles dans Databricks. Cela signifie que la boucle de développement peut continuellement chercher une meilleure combinaison afin de trouver le meilleur compromis entre coût, performance et qualité.

Phase 6 : Mettre en place l'auto-régression

Nous automatisons l'évaluation de la régression pour créer une boucle de développement reproductible, configurable et évolutive. Tout changement déclenche une auto-régression et, lorsque la fiabilité est garantie, un auto-déploiement.

En assemblant toutes ces pièces, un changement typique suit ce parcours :

1. Quelqu'un modifie la logique, le prompt ou le modèle de l'agent.
2. Le workflow d'évaluation se déclenche automatiquement avec trois entrées : la nouvelle version de l'agent, le jeu de données de référence et la référence actuelle en production.
3. Le système exécute les évaluations et produit des métriques pour l'ensemble des évaluateurs et des piliers.
4. La barrière de qualité (quality gate) vérifie :
   • La nouvelle version respecte-t-elle tous les critères (coût, qualité, performance, etc.) ?
   • Ses performances sont-elles au moins équivalentes ou supérieures à celles de la référence en production ?
5. Si oui, la nouvelle version est déployée en production ; sinon, elle est rejetée et l'agent existant continue de traiter le trafic.

Phase 7 : Créer la boucle de production - Mettre en place un filet de sécurité en temps réel

Évaluer 100 % du trafic est coûteux, mais un échantillonnage uniforme naïf de 10 % laisse de côté la plupart des cas limites (edge cases). Nous avons mis en œuvre un échantillonnage stratifié où les taux d'échantillonnage d'évaluation dépendent des clients à forte valeur, des nouvelles fonctionnalités ou des flux récemment modifiés, des sentiments négatifs ou du risque élevé d'escalade, ainsi que des interactions basées sur des images ou sujettes à la fraude. Cela permet d'obtenir un échantillon d'évaluation effectif de 18 à 20 % (~14 400 traces par jour) à un coût gérable, tout en capturant 45 à 60 % des cas limites et en détectant les problèmes en l'espace de 4 à 6 minutes.

La logique financière est imparable : par rapport à une approche d'échantillonnage uniforme, la méthodologie stratifiée a permis de réduire de 86 % le coût d'examen par problème identifié, tout en multipliant par 9 la détection des cas limites, rendant le processus d'assurance qualité nettement plus efficace et évolutif.

Les résultats de l'évaluation sont écrits dans des tables Delta et présentés via des tableaux de bord et des règles d'alerte dans Databricks. Les alertes critiques (vérifiées toutes les 5 minutes) surveillent les baisses de précision de l'intention, les violations de factualité (groundedness), les risques élevés d'escalade et les dépassements de latence P95. Les alertes de niveau élevé/moyen suivent la dégradation de l'empathie, les pics de coûts, les taux d'échec des outils, les tendances du CSAT, le taux de détection des fraudes et la latence multimodale. Cela permet des opérations de type SRE pour les agents d'IA : détection, tri et atténuation rapides.

La pile d'agents à architecture composable

Un bon framework d'évaluation fonctionne bien mieux lorsque l'architecture de l'agent est conçue dès le départ pour être observable et décomposable. La pile de support de Zepto est construite autour de cette idée.

Une requête client, sous forme de chat ou d'image, passe d'abord par un orchestrateur et un routeur d'agents. Le routeur peut passer le relais à un humain à tout moment. En dessous, le système se divise en deux types d'agents.

Les agents verticaux sont des spécialistes, chacun gérant une seule famille d'intentions bien définie :

• WIMO : pour le suivi des commandes et les questions sur l'heure d'arrivée prévue (ETA)
• Missing : pour les commandes non livrées ou partielles
• Expiry : pour les produits emballés périmés
• Returns : pour le statut et le traitement des remboursements
• Quality : pour les produits frais gâtés ou pourris
• Unable to Pay : pour les échecs liés au portefeuille, aux codes promo et au paiement
• General, comme solution de repli

Les agents horizontaux agissent comme des couches de supervision transversales aux cas d'usage :

• Image Deduplication : détecte les images réutilisées d'une réclamation à l'autre
• Item Matching and Image Manipulation Detection : vérifient que les images téléchargées correspondent aux articles du catalogue et n'ont pas été modifiées

Cette séparation est doublement payante. Les métriques peuvent être calculées par agent vertical, comme le score F1 d'intention WIMO ou la précision de l'OCR d'expiration, tandis que les agents horizontaux peuvent être évalués sur des problématiques transversales telles que la précision de la détection de fraude, la réutilisation d'images et la détection de manipulation. Chaque élément peut être mesuré de manière isolée ou combinée.

Le framework en action

Lorsque vous lancez pour la première fois un agent d'IA en production, vous avez l'impression d'envoyer un stagiaire brillant mais imprévisible pour représenter votre entreprise. Vous lui donnez des instructions en espérant que tout se passe bien, mais tant qu'il n'est pas mis à l'épreuve, vous naviguez essentiellement à vue.

Très tôt, nous avons réalisé que la surveillance logicielle traditionnelle est totalement inutile pour l'IA. Un agent peut afficher une disponibilité serveur parfaite et zéro erreur tout en répétant exactement la même mauvaise réponse à un client frustré. Pour les ingénieurs, le tableau de bord est au vert. Pour le client, c'est une catastrophe.

Nous savions que nous ne pouvions pas faire évoluer notre IA en nous reposant uniquement sur l'espoir. Nous avions besoin d'un framework d'évaluation qui ne se contente pas de vérifier si l'IA parlait, mais qui comprenne réellement ce qu'elle disait et là où elle échouait. Les histoires suivantes illustrent les moments où ce framework a fait ses preuves, démontrant qu'un bon système d'évaluation permet de débloquer de toutes nouvelles fonctionnalités produit.

Histoire 1 : L'ETA qui ne bougeait jamais

Un problème en production a bloqué des livreurs dans les embouteillages alors que l'agent continuait de répondre en boucle « arrivée dans 10 min », car il lisait des données en cache. Le client a demandé où en était sa commande, a reçu la même réponse, a demandé à nouveau, et a obtenu encore une fois la même réponse.

Le compteur de tokens (surveillant l'utilisation des tokens) et les indicateurs d'alerte ont détecté la répétition et le risque élevé d'escalade en moins de 5 minutes, faisant remonter des traces de livreurs immobiles avec des ETA inchangés. Cela a déclenché un changement de règle. Si un livreur reste immobile pendant plus de 10 minutes, l'agent fournit désormais une mise à jour honnête et propose de manière proactive une annulation avec remboursement intégral, plutôt que de répéter une promesse obsolète.

Une seule observation, détectée par l'évaluation en ligne, s'est transformée en une gamme complète de fonctionnalités : annulation en cas de retard, proposition proactive d'annulation en cas de pénurie de livreurs, annulation automatique si aucun livreur n'est attribué dans un délai défini, et annulation sans poser de questions pour les clients à forte valeur.

Histoire 2 : Détecter la régression sur les annulations avant les clients

Lorsque Zepto a ajouté la gestion des annulations à l'agent WIMO, le modèle a commencé à confondre trois intentions très différentes : « où est ma commande », « je veux annuler » et « ma commande a-t-elle été annulée ».

L'évaluation MLflow en phase de développement l'a immédiatement détecté. La précision globale des intentions est passée d'environ 92,1 % à 87,4 %, avec un faible score F1 sur les nouvelles intentions WIMO_CANCEL et WIMO_CANCEL_STATUS. Comme la régression est apparue par rapport au jeu de données de référence, aucun client ne s'en est rendu compte. L'optimisation des prompts et les mises à jour du jeu de données ont rétabli la précision globale à environ 94,2 %, soit un meilleur résultat que la baseline initiale, avec un score F1 d'appel d'outils (tool-calling) presque parfait sur les API d'annulation. La fonctionnalité a été mise en ligne sans aucun retour en arrière (rollback).

Histoire 3 : Calibrer les agents multimodaux par rapport au jugement humain

La qualité des produits frais est réellement difficile à évaluer, et les humains ne sont pas toujours d'accord. La même image de champignons peut obtenir une note de 2 sur 5 de la part d'un évaluateur et de 3 sur 5 de la part d'un autre. Nous avons mesuré ce désaccord avec le Kappa de Cohen et l'avons considéré comme notre plafond de fiabilité, car aucun modèle ne peut être plus cohérent que les humains dont il apprend.

Nous avons également constaté que l'IA jouait la carte de la sécurité. Livrée à elle-même, elle accumulait les notes de 3 pour éviter de prendre une décision difficile, alors que les notes humaines culminaient à 4 et 5. Nous n'avons donc pas seulement minimisé l'erreur par rapport à la moyenne. Nous avons reproduit la forme de la distribution des scores humains. L'évaluation en ligne a également fait ressortir des cas pour lesquels le système n'avait pas été conçu, comme le lait caillé qui est stocké comme un produit emballé mais doit être jugé comme un produit frais, ou les plaintes concernant le goût ou l'odeur qu'une photo ne peut tout simplement pas montrer, qui ont été redirigées vers un parcours distinct.

Cette baseline calibrée nous permet de décider quels modèles utiliser par type de produit, comment itérer sur les prompts par rapport au jugement humain, et comment ajuster la politique de remboursement par segment de clientèle en fonction des performances réelles de l'agent.

Histoire 4 : Fermer les failles liées aux abus

Les tentatives d'abus de remboursement utilisaient des images de catalogue, des photos retouchées et des images réutilisées d'une réclamation à l'autre. Le pipeline d'évaluation multimodal soumettait les images à des contrôles de prétraitement pour le flou, la luminosité et la résolution, les validait par OCR, puis utilisait un jury de trois modèles de vision avec des règles de consensus pour décider entre l'approbation automatique et l'examen humain. À cela s'ajoutaient la détection du flou, la détection des captures d'écran, la détection des doublons, la correspondance image-produit (SKU), la vérification de la cohérence entre l'image et le motif invoqué, et la validation de la preuve de livraison.

Ce que nous avons appris en gérant cela à grande échelle

L'exploitation de ce framework à grande échelle nous a enseigné quelques principes qui se généralisent au-delà du commerce rapide (quick commerce).

• N'optimisez jamais une seule métrique. Nous avons un jour cherché à optimiser la précision des intentions de manière isolée et avons vu le CSAT chuter. L'optimisation de l'intention seule a permis de gagner 5 points de précision, mais a augmenté la latence de 133 % et a coûté 0,4 point de CSAT. Un score composite multi-objectif a permis de gagner 3 points d'intention avec seulement 17 % de latence en plus et a ajouté 0,2 point de CSAT. La combinaison de perspectives multiples, de juges LLM, de vérifications basées sur des règles, de labels humains et de métriques de production permet de dégager la vérité. Cette redondance est une assurance, pas un gaspillage.
• Les jeux de données de référence sont la base. Investissez tôt pour obtenir des milliers d'exemples variés et de haute qualité. Suivez l'écart de précision entre le développement et la production, et ajustez jusqu'à ce qu'il converge. L'écart dev-prod est un indicateur de la qualité du jeu de données, pas un mystère.
• Les juges LLM ont besoin d'être calibrés. Traisez les juges comme des modèles ayant leur propre évaluation. Mesurez leur accord avec les humains, utilisez des ensembles pour les cas à enjeux élevés, et recalibrez-les à mesure que les modèles de base évoluent.
• La stratégie d'échantillonnage importe plus que le taux d'échantillonnage. Un échantillonnage uniforme naïf est peu coûteux mais aveugle. Un échantillonnage stratifié axé sur les flux à haut risque offre une détection des problèmes nettement supérieure pour chaque dollar investi.
• Automatisez la boucle de rétroaction dès le premier jour. La détection, la labellisation, le réentraînement, le déploiement et la surveillance doivent tous être automatisés, chaque échec venant enrichir automatiquement le cycle d'entraînement suivant. Pour nous, cela a permis d'économiser environ 155 heures par mois, soit l'équivalent de deux ingénieurs à plein temps réaffectés au développement de fonctionnalités.
• Traitez l'évaluation comme une interface produit. Les tableaux de bord et les métriques sont utilisés par les équipes de support, produit, fraude et opérations. Ils doivent être interprétables et exploitables, et pas seulement techniquement corrects.

Recommandations pour les concepteurs d'agents

Pour les organisations qui conçoivent des systèmes d'agents sur Databricks, l'expérience de Zepto suggère la feuille de route suivante :

• Partez des traces, pas seulement des modèles : imposez un schéma de trace partagé et enregistrez tout dans Delta
• Faites des évaluations MLflow une étape obligatoire dans la CI/CD : aucun déploiement sans dépasser la baseline sur les métriques convenues
• Constituez des jeux de données de référence comme un actif, avec des KPI dédiés (taille, écart dev-prod, couverture des cas limites)
• Utilisez le LLM-as-judge pour ce que les humains évaluent aujourd'hui (qualité, empathie, factualité), mais calibrez-le et limitez-le aux bons segments
• Implémentez l'échantillonnage stratifié et les alertes en temps réel le plus tôt possible ; intégrer la visibilité opérationnelle a posteriori coûte cher
• Concevez des agents verticaux (spécialisés) et horizontaux (supervision), afin de pouvoir les évaluer de manière isolée et combinée

Conclusion

Dans la transition des démos expérimentales vers des infrastructures critiques, la contrainte principale s'est déplacée de la simple capacité du modèle vers la garantie du système. Le parcours de Zepto démontre qu'en établissant l'évaluation comme primitive de développement fondamentale, les organisations peuvent faire évoluer leurs agents de manière fiable pour gérer des dizaines de milliers d'interactions quotidiennes complexes sur des entrées multimodales, le tout soutenu par des garanties rigoureuses sur la qualité, les coûts et l'atténuation des risques.

Databricks et MLflow constituent le socle essentiel de cette évolution, en fournissant une infrastructure de données centrée sur les traces sur Unity Catalog et Delta, ainsi qu'une évaluation évolutive, une optimisation automatisée des prompts et une intégration CI/CD fluide. Cette pile modulable, combinée à la flexibilité du choix des modèles, permet aux équipes d'ajuster précisément l'équilibre entre performances et dépenses pour chaque tâche spécifique.

En fin de compte, l'avantage concurrentiel réside dans la décision stratégique de traiter l'évaluation non pas comme un simple contrôle final, mais comme une infrastructure AI essentielle. Le modèle de fonctionnement des agents à l'échelle de la production n'est plus un mystère ; Zepto et Databricks ont apporté la réponse. Le défi réside désormais dans la rapidité d'adoption. Dans un paysage de l'AI en évolution rapide, les leaders ne seront pas ceux qui attendent une certitude absolue, mais ceux qui conçoivent pour la fiabilité dès le premier jour.

Pour les développeurs qui conçoivent des agents devant gagner la confiance dans des environnements de production, ces mêmes briques de base sont prêtes sur Databricks et MLflow 3. Les organisations qui définiront la prochaine frontière seront celles qui entameront dès aujourd'hui leur parcours axé en priorité sur l'évaluation.

Créez des agents sur Databricks
Démarrez avec l'évaluation et la surveillance MLflow

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original