L’assurance qualité du centre de contact de DiDi remplace une boîte noire par Amazon Bedrock

DiDi a remplacé un outil opaque d’assurance qualité après que ses vérifications d’intention n’ont atteint qu’une précision de 38 %. Son nouveau système d’assurance qualité du centre de contact de DiDi aurait porté ce chiffre à 86 %.

L’entreprise a conçu ce remplacement avec AWS pour son International Business Group. Il traite des conversations d’assistance en espagnol et en portugais dans les secteurs du VTC, de la livraison de repas et des services financiers. Le système évalue également la conformité et détecte les réclamations émergentes des clients.

Il ne s’agit pas simplement d’une entreprise supplémentaire qui ajoute un grand modèle de langage au support client. DiDi a transféré un contrôle interne conséquent d’un fournisseur externe vers une architecture que sa propre équipe peut examiner et modifier. L’enjeu principal oppose donc l’automatisation externalisée opaque à une IA transparente et maîtrisée en interne.

AWS et DiDi ont présenté le système dans une étude de cas sur l’assurance qualité des centres de contact publiée le 8 septembre 2026. La plupart des chiffres de performance proviennent de la validation en production de DiDi et n’ont pas fait l’objet d’un audit indépendant.

Les résultats méritent néanmoins l’attention. Ils montrent qu’un contexte ciblé, des contrôles déterministes et des sorties structurées peuvent compter davantage que des réécritures répétées d’un prompt.

Ce qui a changé dans l’assurance qualité du centre de contact de DiDi

DiDi n’a pas remplacé un modèle par un autre. L’entreprise a divisé l’assurance qualité en trois pipelines contrôlés, aux fonctions et exigences de preuve distinctes.

Le premier pipeline vérifie l’intention. Les conseillers du service client attribuent à chaque conversation un motif de contact, qui situe le dossier dans l’arborescence hiérarchique de classification de DiDi. Le système vérifie si ce motif attribué correspond bien à ce dont le client a parlé.

Si l’étiquette semble erronée, le pipeline recommande une alternative. Il examine également les conversations étiquetées « Other », lorsqu’aucune catégorie existante ne semblait appropriée. Ces cas peuvent révéler des lacunes dans la taxonomie elle-même.

Le deuxième pipeline évalue la conformité. Il note plusieurs critères de qualité tout en extrayant des informations opérationnelles de la même conversation. DiDi affirme que la précision moyenne de ses évaluations de conformité a dépassé 90 % pendant la validation en production.

Le troisième pipeline analyse les données Voice of Customer. Voice of Customer, ou VOC, désigne des données agrégées sur les problèmes des clients, leur sentiment, les résultats et les causes récurrentes. DiDi utilise ce pipeline à la demande lorsque les équipes opérationnelles doivent comprendre une tendance émergente.

Les enregistrements de chat en direct et les transcriptions téléphoniques passent d’abord par une couche de prétraitement. Les sorties de reconnaissance vocale des appels sont normalisées dans le même format de conversation que celui utilisé pour le chat. Les enregistrements obtenus passent ensuite par les pipelines d’assurance qualité appropriés.

Ce schéma commun est important. Les différences entre la voix et le chat ne devraient pas contraindre chaque composant d’analyse en aval à mettre en œuvre sa propre logique d’ingestion. Le système sépare le traitement des canaux des tâches de raisonnement qui suivent.

Selon les entreprises, l’activité internationale de DiDi couvre 14 pays et régions. Son organisation d’assistance traite des conversations en espagnol et en portugais pour des dizaines de millions d’utilisateurs répartis sur trois lignes de métier.

À cette échelle, la revue manuelle ne peut examiner qu’une portion limitée des interactions. Toutefois, l’alternative externalisée présentait son propre problème. DiDi affirme que son système précédent n’exposait pas suffisamment le raisonnement pour expliquer les jugements historiques ou permettre des changements rapides.

Un score de conformité insuffisant peut affecter l’accompagnement, les audits et les priorités opérationnelles. Une mauvaise étiquette d’intention peut fausser les rapports expliquant pourquoi les clients demandent de l’aide. Un jugement inexpliqué n’est donc pas seulement gênant pour un développeur.

Le système de remplacement associe une chaîne de raisonnement à chaque jugement du modèle. Les réviseurs peuvent voir le fondement déclaré d’un score, examiner la conversation originale et comparer la décision avec la règle applicable.

Cette traçabilité crée la tension centrale de l’article. Internaliser le système chez DiDi améliore la visibilité et le contrôle, mais rend également DiDi responsable de la validation, de la sécurité, de la configuration et de la précision continue.

DiDi maîtrise désormais les définitions qui façonnent le résultat. L’entreprise assume aussi les conséquences lorsque ces définitions sont incomplètes ou erronées.

Pourquoi l’isolation du contexte a surpassé l’optimisation des prompts

Le plus grand gain de précision rapporté est venu du fait de montrer moins d’informations au modèle au bon moment, et non de l’ajout d’instructions supplémentaires.

La conception initiale de DiDi pour la vérification des intentions suivait une approche intuitive. Elle plaçait l’arborescence complète des motifs de contact à côté de la conversation et demandait au modèle d’évaluer l’étiquette sélectionnée par le conseiller.

Le modèle comparait alors l’étiquette choisie avec toutes les alternatives disponibles. Lorsqu’il trouvait une catégorie semblant légèrement plus précise, il avait tendance à rejeter une sélection pourtant raisonnable.

Ce comportement a créé une surcorrection. Un modèle chargé de trouver la meilleure étiquette peut se comporter différemment d’un modèle auquel on demande si une étiquette existante est acceptable. Réunir ces décisions dans un seul prompt brouillait la distinction.

DiDi indique que plusieurs cycles d’optimisation des prompts n’ont pas résolu le problème. L’équipe a conclu que le modèle recevait le mauvais environnement décisionnel.

Le pipeline d’intention repensé sépare la vérification de la classification. Lors de la vérification, le modèle reçoit la conversation et uniquement le motif de contact actuel du conseiller. Il détermine si cette étiquette correspond raisonnablement à l’interaction.

L’arborescence complète de classification reste masquée à ce stade. Cette isolation de l’information empêche le modèle de chercher des alternatives marginalement meilleures avant de répondre à la question plus ciblée.

Seul un échec de vérification ouvre l’étape de classification. Le modèle reçoit alors la taxonomie complète, accompagnée du raisonnement de la première étape. Il recommande une autre catégorie et fournit un score de confiance ainsi qu’une justification.

DiDi traite les étiquettes « Other » par un processus distinct à trois niveaux. Le système cherche d’abord une correspondance appropriée parmi les catégories sœurs. Il parcourt ensuite l’ensemble de l’arborescence si la branche locale ne fournit aucune réponse.

Si aucune des deux recherches ne produit de catégorie adaptée, le pipeline identifie une possible lacune de la taxonomie. Il peut alors suggérer aux opérateurs d’ajouter une étiquette plutôt que de forcer la conversation dans une catégorie existante inadaptée.

Selon DiDi, cette conception à deux niveaux a fait passer la précision de vérification des intentions de 38 % à 86 %. Cela représente une hausse de 48 points de pourcentage, sur la base de la validation en production déclarée par l’entreprise.

Le mécanisme offre une leçon pratique aux équipes IA d’entreprise. Davantage de contexte ne signifie pas automatiquement un meilleur contexte. Des options supplémentaires peuvent modifier la tâche que le modèle semble résoudre.

Cela compte car de nombreux prompts d’entreprise combinent plusieurs décisions par souci d’efficacité. Une seule demande peut solliciter un modèle pour classer une conversation, justifier le résultat, vérifier la conformité à une politique, résumer le dossier et recommander une action.

Chaque objectif supplémentaire crée une nouvelle occasion pour les instructions et les éléments de preuve d’interférer. Cela complique aussi l’analyse des échecs, car les développeurs ne peuvent pas facilement identifier quelle partie du contexte a modifié la réponse.

L’approche de DiDi traite au contraire le contexte comme une partie de l’architecture applicative. L’équipe décide quelles informations deviennent visibles à chaque point de décision, tout comme les logiciels conventionnels contrôlent l’accès aux variables et à l’état.

Cette conception produit également des limites d’échec plus claires. Un résultat de vérification douteux appartient à la première étape. Une mauvaise étiquette de remplacement appartient à la seconde. Une catégorie manquante relève de la gouvernance de la taxonomie.

Le résultat ne constitue pas une affirmation universelle selon laquelle les systèmes à plusieurs étapes surpassent toujours les prompts uniques. Chaque étape ajoutée crée de la latence, de la complexité opérationnelle et un composant supplémentaire à surveiller.

DiDi n’a pas publié la taille de l’échantillon, la distribution des classes, les intervalles de confiance ni les performances par langue et ligne de métier. Ces omissions limitent les comparaisons avec d’autres systèmes d’assurance qualité de centres de contact.

Néanmoins, le changement rapporté remet en cause une habitude courante dans les entreprises. Les équipes réagissent souvent à un comportement décevant du modèle en étoffant les instructions ou en changeant de modèle de fondation. DiDi a plutôt modifié le flux d’information.

C’est une forme plus profonde d’ingénierie des prompts. Elle déplace la responsabilité d’une formulation astucieuse vers la conception du système, les définitions de données et des limites décisionnelles explicites.

Un système maîtrisé en interne met l’IA externalisée sous pression

Le défi le plus fort lancé par DiDi aux fournisseurs tiers d’assurance qualité n’est pas l’affirmation sur la précision du modèle. C’est l’argument selon lequel la logique de jugement est devenue une infrastructure stratégique.

Une plateforme externalisée peut réduire le travail de mise en œuvre. Elle peut intégrer transcription, évaluation, tableaux de bord et flux de travail dans un produit géré unique. Les acheteurs évitent de maintenir eux-mêmes chaque composant.

Cependant, cette commodité devient une contrainte lorsque le fournisseur n’expose pas la manière dont il est parvenu à un jugement. DiDi affirme que sa solution précédente prenait des décisions d’assurance qualité sans piste d’audit suffisante.

La limitation est devenue plus grave à mesure que les normes évoluaient. L’assistance en espagnol pour le VTC n’utilise pas nécessairement les mêmes critères que l’assistance en portugais pour les services financiers. Les nouvelles politiques créent d’autres combinaisons.

Une mise en œuvre contrôlée par le fournisseur peut nécessiter des changements personnalisés, un réentraînement ou des mises à jour produit avant que ces normes n’apparaissent en production. Pendant cet intervalle, anciennes et nouvelles règles peuvent coexister.

DiDi a déplacé les définitions de politiques dans une configuration externe. Le pipeline d’évaluation utilise un modèle de prompt unique, puis injecte la langue, la ligne de métier, la définition du critère, la règle de validation et la règle d’échec pour chaque ticket.

L’ajout d’un critère supplémentaire ne nécessite pas de réécrire chaque prompt propre à une langue. Les opérateurs mettent à jour la configuration, et l’application assemble le contexte nécessaire lorsqu’elle reçoit une conversation.

Le pipeline évalue plusieurs éléments de conformité en un seul appel au modèle. Il renvoie aussi des informations métiers structurées, y compris des mesures liées à la résolution des problèmes et à la satisfaction client.

Amazon Bedrock Tool Use contraint la réponse à une structure JSON définie. Chaque élément de notation contient un jugement et sa justification associée. La fonctionnalité Tool Use permet aux applications de décrire l’entrée d’outil attendue et de traiter les données structurées obtenues.

La sortie structurée ne résout que le problème du format de réponse. Un JSON valide ne garantit pas que le score sous-jacent soit correct. DiDi ajoute donc des contrôles déterministes après la génération.

Par exemple, le modèle peut identifier de possibles fautes d’orthographe. Le code de l’application ne compte alors que les erreurs présentes dans les messages du conseiller et applique le seuil défini au nombre vérifié.

Le système calcule également les temps d’attente avant réponse dans le code. Il injecte ces valeurs dans le prompt plutôt que de demander au modèle de les déduire à partir des horodatages.

Ce modèle hybride attribue les jugements sémantiques au modèle de langage et les faits calculables aux logiciels conventionnels. Il évite d’utiliser une génération probabiliste lorsqu’un calcul direct peut fournir une réponse reproductible.

Cette distinction est essentielle à l’approche maîtrisée en interne. DiDi peut examiner quelles décisions relèvent du modèle, lesquelles relèvent du code et lesquelles dépendent de la configuration métier.

L’architecture utilise également Amazon Bedrock parce que le service expose plusieurs modèles de fondation via une interface commune. DiDi indique que le choix du modèle peut évoluer sans avoir à reconstruire chaque pipeline autour d’une autre intégration propre à un fournisseur.

La portabilité des modèles a encore ses limites. Les différents modèles interprètent différemment les prompts et les schémas ; changer de modèle exige donc une nouvelle évaluation. Une API commune réduit une partie du travail d’intégration, mais ne rend pas les comportements interchangeables.

La sécurité crée un autre point de pression. Les conversations clients peuvent contenir des noms, des coordonnées, des informations financières, des données de localisation et des réclamations sensibles. Déplacer ces dossiers vers un workflow d’IA élargit le périmètre du système à gouverner.

DiDi indique que le déploiement utilise des points de terminaison VPC via AWS PrivateLink, le chiffrement et des contrôles granulaires de gestion des identités et des accès. AWS précise qu’une connexion privée peut accéder à Bedrock sans passerelle Internet ni adresse IP publique.

Le système applique également Amazon Bedrock Guardrails avant l’inférence du modèle. Il masque les informations personnellement identifiables et utilise des contrôles d’ancrage contextuel pour signaler les réponses insuffisamment étayées.

AWS décrit Guardrails comme un ensemble de politiques qui évaluent les prompts et les réponses selon des critères incluant les informations sensibles, les sujets interdits et les contenus indésirables. Ses contrôles Guardrails peuvent bloquer ou masquer du contenu selon la politique configurée.

Ces mesures n’éliminent pas le travail de gouvernance. DiDi doit toujours définir les règles d’accès, de conservation, d’escalade, de revue et de traitement régional des données clients.

La même charge s’applique à la logique métier. Posséder un système transparent implique de maintenir ses taxonomies, ses critères d’évaluation, ses jeux de validation et son processus de supervision. L’entreprise a remplacé l’opacité du fournisseur par une responsabilité interne.

Les fournisseurs tiers subissent donc une pression sur deux fronts. Ils doivent égaler la simplicité d’un produit géré tout en exposant suffisamment d’éléments de preuve, de configurabilité et de contrôle pour que les clients d’entreprise puissent faire confiance aux jugements conséquents.

La réponse ne doit pas nécessairement passer par une divulgation complète du code. Les fournisseurs peuvent proposer des traces de décision, des règles versionnées, des outils d’évaluation, des résultats exportables et une séparation plus claire entre la sortie du modèle et les vérifications déterministes.

Le cas de DiDi laisse entendre qu’un simple tableau de bord de précision ne suffit plus. Les acheteurs doivent de plus en plus savoir quel modèle, quelle version de prompt, quelle définition de politique et quelle règle de post-traitement ont produit chaque score.

Cette exigence fait de l’observabilité une fonctionnalité produit. Elle rend aussi l’appropriation interne plus attrayante pour les entreprises disposant de capacités d’ingénierie suffisantes et d’opérations suffisamment spécialisées.

Ce que les chiffres de précision ne montrent pas

Les gains rapportés sont significatifs, mais les éléments publics ne permettent pas d’établir les performances du système dans tous les marchés, toutes les langues, toutes les catégories ou face à l’évolution des politiques.

Les chiffres de 38 % et 86 % relatifs à l’intention proviennent de la validation de production de DiDi. Le compte rendu AWS ne révèle pas combien de conversations ont été testées ni comment les évaluateurs définissaient un résultat correct.

Il ne fournit pas non plus la précision pour l’espagnol par rapport au portugais. Les performances peuvent varier selon les accents, le vocabulaire régional, les canaux d’assistance, les branches d’activité et le niveau de profondeur de classification.

L’équilibre des classes compte également. Un jeu de données dominé par des questions fréquentes de VTC peut générer un score global élevé tout en masquant de faibles résultats pour des cas moins fréquents liés aux services financiers.

La même prudence s’applique aux scores de conformité supérieurs à 90 %. Les documents publiés n’indiquent pas combien de critères étaient inclus, si chaque critère recevait le même poids, ni comment les humains résolvaient les désaccords.

La précision peut aussi masquer des coûts d’erreur différents. Une fausse violation orthographique est gênante, tandis qu’une évaluation incorrecte concernant une conduite réglementée en matière de services financiers peut avoir des conséquences plus graves.

Une évaluation en production devrait donc suivre la précision et le rappel pour chaque critère, et non une seule moyenne. Elle devrait aussi surveiller les divergences entre les évaluateurs humains et le système automatisé.

Les traces de raisonnement aident les évaluateurs à examiner les décisions, mais elles ne constituent pas une preuve. Un modèle de langage peut produire une explication plausible pour une mauvaise réponse.

La couche de validation déterministe réduit ce risque pour les faits mesurables. Elle ne peut pas transformer chaque jugement de politique en calcul. Le ton, la qualité de résolution, l’empathie et la pertinence contextuelle exigent toujours une interprétation.

Les garde-fous introduisent une autre limite. Ils peuvent filtrer les informations sensibles et tester l’ancrage, mais AWS recommande lui-même de poursuivre la validation à mesure que les protections sous-jacentes évoluent. Un contrôle configuré ne doit pas être considéré comme une garantie permanente.

Une supervision humaine demeure nécessaire, particulièrement pour les scores contestés et les critères à risque élevé. Les équipes de revue ont besoin d’une voie de recours capable de corriger à la fois la décision individuelle et la règle sous-jacente.

Le compte rendu public manque également de mesures opérationnelles. Il ne communique ni la latence des modèles, ni le coût de traitement, ni le taux de remplacement des décisions, ni la charge de travail des évaluateurs, ni le pourcentage de conversations nécessitant une escalade.

Ces chiffres révéleraient si l’amélioration de la précision des modèles se traduit par de meilleures opérations. Un système précis peut encore rencontrer des difficultés s’il répond trop lentement, exige des corrections manuelles fréquentes ou devient coûteux à pleine échelle.

La comparaison avec d’autres implémentations apporte une perspective utile. Le fournisseur de services financiers Empower a précédemment décrit un autre déploiement d’assurance qualité fondé sur Bedrock, qui traitait quotidiennement des milliers de transcriptions.

Son système d’assurance qualité automatisé combinait Amazon Connect Contact Lens et Bedrock. Empower a indiqué avoir multiplié par vingt la couverture de l’assurance qualité et réduit le temps de revue de plusieurs jours à quelques minutes.

Les implémentations ne sont pas directement comparables. Empower utilisait des transcriptions préalablement expurgées issues d’une pile de centre de contact AWS, tandis que DiDi a décrit son propre prétraitement et son architecture à trois pipelines.

Ces deux cas pointent néanmoins dans la même direction concurrentielle. Les entreprises souhaitent examiner davantage de conversations, expliquer les évaluations et réduire le délai entre les problèmes clients et l’action opérationnelle.

La contribution distinctive de DiDi réside dans son récit d’une conception ayant échoué. Injecter toute la taxonomie dans un seul appel a produit une mauvaise vérification des intentions, malgré des ajustements répétés des prompts.

Cet échec rend le cas plus utile qu’une simple réussite de fournisseur. Il montre que l’accès à un modèle ne suffit pas, à lui seul, à fournir une assurance qualité fiable.

L’incertitude restante concerne la maintenance. Les taxonomies évoluent, le comportement des clients change et le langage des politiques se transforme. Les fournisseurs de modèles mettent également à jour les versions disponibles et les fonctionnalités associées.

DiDi aura besoin de jeux d’évaluation versionnés préservant des exemples représentatifs de chaque langue, canal, activité et critère à risque élevé. Sans cela, une amélioration de configuration dans un domaine peut discrètement réduire les performances ailleurs.

Les équipes qui construisent des systèmes similaires devraient préserver les éléments probants associés à chaque version. Une base de connaissances d’ingénierie consultable peut relier les exigences, les résultats de test, les versions de prompts et les revues d’incidents sans traiter les explications générées comme des vérités établies.

Cette pratique soutient la véritable promesse de transparence. La visibilité n’est utile que lorsque les équipes peuvent reconstituer ce qui a changé, pourquoi cela a changé et comment la nouvelle version a fonctionné.

Le prochain test : la capacité de DiDi à faire évoluer le contrôle

Trois signaux détermineront si l’architecture de DiDi devient un système d’exploitation durable pour l’assurance qualité ou reste un déploiement réussi dont la validation publique demeure limitée.

Le premier signal concernera les performances dans des langues et branches d’activité supplémentaires. DiDi indique prévoir d’étendre le système au-delà de sa couverture actuelle.

Cette extension testera si la configuration dynamique limite réellement le travail de maintenance. Une nouvelle langue implique davantage que des instructions traduites. Elle peut introduire des formulations régionales, des attentes culturelles, des erreurs de transcription et des exigences de politique différentes.

Si la précision reste stable dans les nouveaux déploiements, le résultat renforcera la thèse de DiDi sur la gestion du contexte. De fortes baisses suggéreraient que les gains actuels dépendent fortement de l’environnement de validation espagnol et portugais existant.

Le deuxième signal sera l’intégration entre pipelines. DiDi prévoit de connecter plus étroitement la vérification des intentions, le scoring de conformité et l’analyse VOC.

Aujourd’hui, chaque pipeline a un objectif distinct. L’intégration peut créer une boucle de rétroaction dans laquelle les tendances des réclamations révèlent des classifications manquantes, les échecs répétés de classification mettent à jour la taxonomie et les constats de conformité orientent l’accompagnement.

Elle peut également propager les erreurs. Un regroupement défectueux de problèmes pourrait influencer les modifications de taxonomie, lesquelles affecteraient ensuite les contrôles d’intention et les rapports de gestion.

Une intégration réussie exige donc une traçabilité. Chaque recommandation en aval devrait conserver des liens vers les conversations, les champs extraits, la version de configuration et la sortie du modèle qui l’ont produite.

Le troisième signal sera constitué d’éléments opérationnels allant au-delà de la précision. Les futures communications devraient inclure les taux de remplacement par des humains, les tendances de faux positifs, la latence de traitement, le temps de revue et les performances par catégorie.

Ces mesures montreraient si le système reste utile après la période de validation initiale. Elles aideraient également les acheteurs à comparer les architectures auto-gérées avec les produits de centres de contact gérés.

L’analyse VOC offre le test immédiat le plus clair. DiDi a décrit une hausse des réclamations liées aux frais d’annulation sur les marchés latino-américains. Le personnel opérationnel a déclenché une analyse qui a regroupé des conversations multilingues et produit un rapport structuré en quelques minutes.

Le pipeline commence par extraire en parallèle des champs de chaque conversation. Ces champs comprennent le type de problème, le sentiment, le résultat et la cause racine possible.

Un modèle d’embedding mesure ensuite la similarité sémantique entre les libellés de problèmes. Les embeddings sont des représentations numériques qui rapprochent les significations liées, permettant au système de fusionner des réclamations formulées différemment.

Cette étape utilise des calculs de distance et des classements par fréquence plutôt qu’une sortie générative. DiDi indique que cette conception rend le regroupement déterministe et reproductible.

Le modèle de langage ne reçoit que les regroupements à haute fréquence lors de la génération du rapport. Il crée une synthèse à destination des dirigeants, identifie les points de friction et suggère des actions à partir d’un ensemble de preuves plus restreint et structuré.

Ce pipeline applique à nouveau l’isolation de l’information. Le modèle ne reçoit pas des milliers de conversations brutes dans un unique prompt surdimensionné. Chaque étape resserre les éléments nécessaires à la décision suivante.

DiDi affirme que le processus a réduit à quelques minutes un travail qui prenait auparavant des heures. Cette affirmation deviendra plus convaincante si de futurs rapports montrent si les équipes opérationnelles ont agi plus vite ou évité des préjudices répétés aux clients.

La vitesse n’est pas le seul objectif. Un rapport rapide reposant sur une cause racine erronée peut orienter les ressources vers la mauvaise intervention.

Le déploiement le plus solide associera une détection plus rapide à des résultats mesurables. Ceux-ci pourraient inclure moins de contacts répétés, une meilleure résolution des problèmes, une moindre récurrence des réclamations ou une correction plus rapide d’un problème de politique.

Pour les développeurs, la leçon immédiate consiste à concevoir les frontières du modèle avant de peaufiner les prompts. Déterminez quels éléments de preuve chaque appel nécessite, quelles sorties exigent un schéma et quels faits doivent être calculés dans le code.

Les acheteurs d’entreprise devraient exiger la même clarté de la part des fournisseurs. Demandez des règles versionnées, des décisions auditables, une validation par catégorie, des workflows d’escalade et des contrôles d’accès reflétant la sensibilité des données de conversation.

Les travailleurs du savoir devraient s’y intéresser, car ce modèle s’étend au-delà du support. Tout système qui classe des documents, évalue du travail ou résume des problèmes récurrents peut souffrir lorsqu’il reçoit des options non pertinentes ou combine des tâches incompatibles.

L’assurance qualité du centre de contact de DiDi constitue donc autant un test des capacités organisationnelles que des performances du modèle. L’entreprise a pris en charge le contexte, les définitions et la validation, plutôt que d’externaliser l’intégralité de la couche de jugement.

Cette prise en charge produira-t-elle des résultats stables à mesure que les langues, les politiques et les modèles évoluent ? Surveillez les indicateurs d’expansion, les pistes de preuve entre les différents pipelines et les taux de dérogation humaine. Ces signaux montreront si une IA d’entreprise transparente peut, à terme, surpasser la boîte noire.