DiDi Contact Center QA sostituisce una scatola nera con Amazon Bedrock
DiDi ha sostituito uno strumento opaco di assicurazione qualità dopo che i suoi controlli sugli intent avevano raggiunto appena il 38% di accuratezza. Secondo quanto riportato, il nuovo sistema DiDi contact center QA ha portato tale valore all'86%.
L'azienda ha realizzato la sostituzione con AWS per il suo International Business Group. Elabora conversazioni di supporto in spagnolo e portoghese nei servizi di ride-hailing, consegna di cibo e servizi finanziari. Il sistema assegna inoltre punteggi alla conformità e individua i reclami emergenti dei clienti.
Non si tratta semplicemente di un'altra azienda che aggiunge un grande modello linguistico al supporto clienti. DiDi ha trasferito un importante controllo interno da un fornitore esterno a un'architettura che il proprio team può ispezionare e modificare. Il confronto principale è quindi tra automazione esternalizzata opaca e AI trasparente gestita internamente.
AWS e DiDi hanno presentato il sistema in un caso di studio sul contact center QA dell'8 settembre 2026. La maggior parte delle metriche di performance proviene dalla validazione in produzione di DiDi e non è stata sottoposta a verifica indipendente.
I risultati meritano comunque attenzione. Mostrano come un contesto ristretto, controlli deterministici e output strutturati possano contare più della continua riscrittura di un prompt.
Cosa è cambiato all'interno di DiDi Contact Center QA
DiDi non ha sostituito un modello con un altro. Ha suddiviso l'assicurazione qualità in tre pipeline controllate, con compiti e requisiti di evidenza differenti.
La prima pipeline verifica l'intent. I rappresentanti del servizio clienti assegnano a ogni conversazione una ragione di contatto, collocando il caso nell'albero di classificazione gerarchico di DiDi. Il sistema verifica se tale ragione assegnata corrisponde a quanto discusso dal cliente.
Se l'etichetta sembra errata, la pipeline suggerisce un'alternativa. Esamina anche le conversazioni etichettate come “Other”, per le quali nessuna categoria esistente sembrava appropriata. Questi casi possono rivelare lacune nella tassonomia stessa.
La seconda pipeline valuta la conformità. Attribuisce un punteggio a diversi criteri di qualità, estraendo al tempo stesso insight operativi dalla stessa conversazione. DiDi afferma che l'accuratezza media del punteggio di conformità ha superato il 90% durante la validazione in produzione.
La terza pipeline analizza i dati Voice of Customer. Voice of Customer, o VOC, indica evidenze aggregate relative a problemi dei clienti, sentiment, esiti e cause ricorrenti. DiDi utilizza questa pipeline su richiesta quando i team operativi devono comprendere un andamento in evoluzione.
I record delle chat in tempo reale e le trascrizioni telefoniche entrano prima in un livello di pre-elaborazione. L'output speech-to-text delle chiamate viene normalizzato nello stesso formato di conversazione utilizzato per le chat. I record risultanti passano quindi attraverso le pipeline QA appropriate.
Questo schema comune è importante. Le differenze tra voce e chat non dovrebbero costringere ogni componente di analisi a valle a implementare una propria logica di acquisizione. Il sistema separa l'elaborazione dei canali dalle attività di ragionamento successive.
Secondo le aziende, l'attività internazionale di DiDi opera in 14 paesi e regioni. La sua organizzazione di supporto gestisce conversazioni in spagnolo e portoghese per decine di milioni di utenti su tre linee di business.
Su questa scala, la revisione manuale può ispezionare solo una porzione limitata delle interazioni. Tuttavia, anche l'alternativa esternalizzata presentava un problema. DiDi afferma che il suo sistema precedente non offriva sufficiente trasparenza sul ragionamento per spiegare giudizi storici o supportare modifiche rapide.
Un punteggio di conformità non superato può influire sul coaching, sugli audit e sulle priorità operative. Un'etichetta di intent errata può distorcere i report sulle ragioni per cui i clienti richiedono assistenza. Un giudizio non spiegato non è quindi soltanto scomodo per uno sviluppatore.
La sostituzione associa una catena di ragionamento a ciascun giudizio del modello. I revisori possono vedere la motivazione dichiarata per un punteggio, esaminare la conversazione originale e confrontare la decisione con la regola applicabile.
Questa tracciabilità crea la tensione centrale dell'articolo. Portare il sistema all'interno di DiDi migliora visibilità e controllo, ma rende anche DiDi responsabile di validazione, sicurezza, configurazione e accuratezza nel tempo.
DiDi ora possiede le definizioni che modellano il risultato. Possiede anche le conseguenze quando tali definizioni sono incomplete o errate.
Perché l'isolamento del contesto ha superato un maggiore prompt tuning
Il maggiore incremento di accuratezza riportato è derivato dal mostrare al modello meno informazioni nel momento giusto, non dall'aggiungere più istruzioni.
Il progetto iniziale di DiDi per la verifica dell'intent seguiva un approccio intuitivo. Affiancava l'intero albero delle ragioni di contatto alla conversazione e chiedeva al modello di giudicare l'etichetta selezionata dal rappresentante.
Il modello confrontava quindi l'etichetta scelta con ogni alternativa disponibile. Quando trovava una categoria apparentemente appena più precisa, tendeva a respingere una selezione altrimenti ragionevole.
Questo comportamento generava correzioni eccessive. Un modello incaricato di trovare l'etichetta migliore può comportarsi diversamente da uno a cui viene chiesto se un'etichetta esistente sia accettabile. Combinare queste decisioni in un unico prompt confondeva la distinzione.
DiDi afferma che diversi cicli di prompt tuning non hanno risolto il problema. Il team ha concluso che al modello fosse stato fornito l'ambiente decisionale sbagliato.
La pipeline per l'intent riprogettata separa la verifica dalla classificazione. Durante la verifica, il modello riceve la conversazione e soltanto l'attuale ragione di contatto del rappresentante. Decide se tale etichetta si adatta ragionevolmente all'interazione.
L'intero albero di classificazione resta nascosto in questa fase. Tale isolamento delle informazioni impedisce al modello di cercare alternative marginalmente migliori prima di rispondere alla domanda più circoscritta.
Solo una verifica non superata apre la fase di classificazione. Il modello riceve quindi la tassonomia completa, insieme al ragionamento della prima fase. Suggerisce un'altra categoria e fornisce un punteggio di confidenza e una motivazione.
DiDi gestisce le etichette “Other” tramite un processo separato a tre livelli. Il sistema cerca prima una corrispondenza adeguata tra le categorie sorelle. Cerca quindi nell'intero albero se il ramo locale non offre una risposta.
Se nessuna delle due ricerche produce una categoria appropriata, la pipeline individua una possibile lacuna nella tassonomia. Può quindi suggerire agli operatori di aggiungere un'etichetta anziché forzare la conversazione in un contenitore esistente non adatto.
Secondo DiDi, questo progetto a due livelli ha aumentato l'accuratezza della verifica dell'intent dal 38% all'86%. Si tratta di un aumento di 48 punti percentuali, basato sulla validazione in produzione dichiarata dall'azienda.
Il meccanismo offre una lezione pratica ai team AI aziendali. Un contesto maggiore non è automaticamente un contesto migliore. Opzioni aggiuntive possono modificare il compito che il modello sembra risolvere.
Questo è importante perché molti prompt aziendali combinano diverse decisioni per ragioni di efficienza. Una singola richiesta potrebbe chiedere a un modello di classificare una conversazione, giustificare il risultato, verificare la conformità alle policy, riassumere il caso e raccomandare un'azione.
Ogni obiettivo aggiuntivo crea un'ulteriore opportunità di interferenza tra istruzioni ed evidenze. Rende inoltre più difficile l'analisi dei fallimenti, poiché gli sviluppatori non possono identificare facilmente quale parte del contesto abbia modificato la risposta.
L'approccio di DiDi tratta invece il contesto come parte dell'architettura applicativa. Il team decide quali informazioni diventano visibili in ciascun punto decisionale, proprio come il software convenzionale controlla l'accesso a variabili e stato.
Questo progetto produce anche confini di errore più chiari. Un risultato di verifica discutibile appartiene alla prima fase. Un'etichetta sostitutiva inadeguata appartiene alla seconda. Una categoria mancante appartiene alla governance della tassonomia.
Il risultato non è un'affermazione universale secondo cui i sistemi multi-fase superano sempre i prompt singoli. Ogni fase aggiuntiva crea latenza, complessità operativa e un altro componente da monitorare.
DiDi non ha pubblicato dimensione del campione, distribuzione delle classi, intervalli di confidenza o performance per lingua e linea di business. Queste omissioni limitano i confronti con altri sistemi di contact center QA.
Tuttavia, il cambiamento riportato mette in discussione un'abitudine aziendale comune. I team spesso rispondono a un comportamento del modello deludente ampliando le istruzioni o cambiando modelli foundation. DiDi ha invece modificato il flusso delle informazioni.
Questa è una forma più profonda di prompt engineering. Sposta la responsabilità dalla formulazione ingegnosa al design del sistema, alle definizioni dei dati e a confini decisionali espliciti.
Un sistema gestito internamente mette sotto pressione l'AI esternalizzata
La sfida più forte di DiDi ai fornitori QA terzi non è l'affermazione sull'accuratezza del modello. È l'argomento secondo cui la logica di giudizio è diventata un'infrastruttura strategica.
Una piattaforma esternalizzata può ridurre il lavoro di implementazione. Può riunire trascrizione, valutazione, dashboard e workflow in un unico prodotto gestito. Gli acquirenti evitano di mantenere autonomamente ogni componente.
Tuttavia, questa comodità diventa un vincolo quando il fornitore non espone come abbia raggiunto un giudizio. DiDi afferma che la sua soluzione precedente prendeva decisioni QA senza una pista di audit sufficiente.
La limitazione è diventata più seria con il cambiamento degli standard. Il supporto in spagnolo per il ride-hailing non utilizza necessariamente gli stessi criteri del supporto in portoghese per i servizi finanziari. Le nuove policy creano ulteriori combinazioni.
Un'implementazione controllata dal fornitore può richiedere modifiche personalizzate, riaddestramento o aggiornamenti del prodotto prima che tali standard arrivino in produzione. Durante quell'intervallo, vecchie e nuove regole possono coesistere.
DiDi ha spostato le definizioni delle policy in una configurazione esterna. La pipeline di valutazione utilizza un template di prompt, quindi inserisce lingua, linea di business, definizione del criterio, regola di superamento e regola di non superamento per ciascun ticket.
L'aggiunta di un ulteriore criterio non richiede la riscrittura di ogni prompt specifico per lingua. Gli operatori aggiornano la configurazione e l'applicazione compone il contesto necessario quando riceve una conversazione.
La pipeline valuta diversi elementi di conformità in un'unica chiamata al modello. Restituisce inoltre insight aziendali strutturati, comprese metriche relative alla risoluzione dei problemi e alla soddisfazione dei clienti.
Amazon Bedrock Tool Use vincola la risposta a una struttura JSON definita. Ogni elemento di punteggio contiene un giudizio e la relativa motivazione. La pertinente capacità di tool use consente alle applicazioni di descrivere l'input atteso dello strumento e di elaborare i dati strutturati risultanti.
L'output strutturato risolve soltanto il problema del formato della risposta. Un JSON valido non garantisce che il punteggio sottostante sia corretto. DiDi aggiunge pertanto controlli deterministici dopo la generazione.
Per esempio, il modello può identificare possibili errori ortografici. Il codice dell'applicazione conta quindi soltanto gli errori nei messaggi del rappresentante e applica la soglia definita al numero verificato.
Il sistema calcola inoltre nel codice i tempi di attesa delle risposte. Inserisce tali valori nel prompt invece di chiedere al modello di dedurli dai timestamp.
Questo schema ibrido assegna i giudizi semantici al modello linguistico e i fatti calcolabili al software convenzionale. Evita di utilizzare la generazione probabilistica laddove un calcolo diretto possa fornire una risposta riproducibile.
Questa distinzione è centrale nell'approccio gestito internamente. DiDi può ispezionare quali decisioni appartengono al modello, quali al codice e quali dipendono dalla configurazione aziendale.
L'architettura utilizza inoltre Amazon Bedrock perché il servizio espone più modelli foundation attraverso un'interfaccia comune. DiDi afferma che la scelta del modello può cambiare senza ricostruire ogni pipeline attorno a un'altra integrazione specifica del fornitore.
La portabilità dei modelli ha ancora dei limiti. Modelli diversi interpretano prompt e schemi in modo diverso, quindi cambiare modello richiede una nuova valutazione. Un'API comune riduce parte del lavoro di integrazione, ma non rende i comportamenti intercambiabili.
La sicurezza crea un ulteriore punto di pressione. Le conversazioni con i clienti possono contenere nomi, informazioni di contatto, dati finanziari, dati di localizzazione e reclami sensibili. Trasferire questi dati in un flusso di lavoro basato sull'AI amplia il sistema che deve essere governato.
DiDi afferma che l'implementazione utilizza endpoint VPC tramite AWS PrivateLink, crittografia e controlli granulari di Identity and Access Management. AWS documenta che una connessione privata può raggiungere Bedrock senza un internet gateway né un indirizzo IP pubblico.
Il sistema applica inoltre Amazon Bedrock Guardrails prima dell'inferenza del modello. Maschera le informazioni personali identificabili e utilizza controlli di grounding contestuale per segnalare risposte prive di un supporto sufficiente.
AWS descrive Guardrails come policy che valutano prompt e risposte in aree quali informazioni sensibili, argomenti vietati e contenuti indesiderati. I suoi controlli dei guardrail possono bloccare o mascherare contenuti secondo la policy configurata.
Queste misure non eliminano il lavoro di governance. DiDi deve comunque definire regole di accesso, conservazione, escalation, revisione e gestione regionale dei dati dei clienti.
Lo stesso onere vale per la logica di business. Possedere un sistema trasparente significa mantenerne tassonomie, criteri di valutazione, set di validazione e processo di monitoraggio. L'azienda ha sostituito l'opacità del fornitore con la responsabilità interna.
I fornitori terzi sono quindi sotto pressione da due lati. Devono eguagliare la praticità di un prodotto gestito, esponendo al contempo prove, configurabilità e controllo sufficienti affinché i clienti enterprise possano fidarsi di giudizi con conseguenze rilevanti.
La risposta non deve necessariamente essere la divulgazione completa del codice. I fornitori possono offrire tracce decisionali, regole versionate, strumenti di valutazione, risultati esportabili e una separazione più chiara tra l'output del modello e i controlli deterministici.
Il caso DiDi suggerisce che una semplice dashboard sull'accuratezza non sia più sufficiente. Gli acquirenti hanno sempre più bisogno di sapere quale modello, versione del prompt, definizione della policy e regola di post-elaborazione abbia prodotto ciascun punteggio.
Questo requisito trasforma l'osservabilità in una funzionalità di prodotto. Rende inoltre la proprietà interna più interessante per aziende con capacità ingegneristiche sufficienti e operazioni adeguatamente specializzate.
Cosa non mostrano i numeri sull'accuratezza
I miglioramenti riportati sono significativi, ma le prove pubbliche non possono stabilire come il sistema si comporti in ogni mercato, lingua, categoria o in presenza di policy in evoluzione.
I dati del 38% e dell'86% relativi all'intento provengono dalla validazione in produzione di DiDi. Il resoconto AWS non rivela quante conversazioni siano state testate né come i valutatori abbiano definito un risultato corretto.
Non fornisce nemmeno dati di accuratezza per lo spagnolo rispetto al portoghese. Le prestazioni possono variare in base ad accenti, vocabolario regionale, canali di supporto, linee di business e profondità della classificazione.
Anche il bilanciamento delle classi conta. Un dataset dominato da domande comuni sul ride-hailing può produrre un punteggio complessivo elevato, nascondendo però risultati deboli per casi meno frequenti relativi ai servizi finanziari.
La stessa cautela vale per i punteggi di conformità superiori al 90%. Il materiale pubblicato non indica quanti criteri fossero inclusi, se ogni criterio avesse lo stesso peso o come gli esseri umani abbiano risolto i disaccordi.
L'accuratezza può inoltre nascondere costi d'errore diversi. Una falsa violazione ortografica è scomoda, mentre una valutazione errata che riguarda una condotta regolamentata nei servizi finanziari può avere conseguenze più gravi.
Una valutazione in produzione dovrebbe quindi monitorare precisione e richiamo per i singoli criteri, non soltanto una media unica. Dovrebbe inoltre monitorare i disaccordi tra revisori umani e sistema automatizzato.
Le tracce di ragionamento aiutano i revisori a indagare le decisioni, ma non sono una prova. Un modello linguistico può produrre una spiegazione plausibile per una risposta errata.
Il livello di validazione deterministica riduce questo rischio per i fatti misurabili. Non può trasformare ogni giudizio di policy in un calcolo. Tono, qualità della risoluzione, empatia e appropriatezza contestuale richiedono ancora interpretazione.
I guardrail introducono un'altra limitazione. Possono filtrare informazioni sensibili e verificare il grounding, ma AWS stessa raccomanda una validazione continua man mano che le salvaguardie sottostanti cambiano. Un controllo configurato non dovrebbe essere considerato una garanzia permanente.
La supervisione umana resta necessaria, soprattutto per punteggi contestati e criteri a rischio più elevato. I team di revisione necessitano di un percorso di ricorso in grado di correggere sia la singola decisione sia la regola sottostante.
Il resoconto pubblico manca anche di misurazioni operative. Non riporta latenza del modello, costo di elaborazione, tasso di override, carico di lavoro dei revisori o percentuale di conversazioni che richiedono escalation.
Questi dati rivelerebbero se una maggiore accuratezza del modello si traduca in operazioni migliori. Un sistema accurato può comunque incontrare difficoltà se risponde troppo lentamente, richiede frequenti correzioni manuali o diventa costoso a pieno volume.
Il confronto con altre implementazioni aggiunge una prospettiva utile. Il fornitore di servizi finanziari Empower aveva in precedenza descritto un'altra implementazione QA basata su Bedrock, in grado di elaborare migliaia di trascrizioni al giorno.
Il suo sistema QA automatizzato combinava Amazon Connect Contact Lens con Bedrock. Empower ha affermato di aver ampliato di venti volte la copertura QA e ridotto il tempo di revisione da giorni a minuti.
Le implementazioni non sono direttamente comparabili. Empower utilizzava trascrizioni pre-redatte provenienti da uno stack AWS per contact center, mentre DiDi ha descritto il proprio preprocessing e un'architettura a tre pipeline.
Tuttavia, entrambi i casi indicano la stessa direzione competitiva. Le imprese vogliono esaminare più conversazioni, spiegare le valutazioni e ridurre il divario tra i problemi dei clienti e l'azione operativa.
Il contributo distintivo di DiDi è il resoconto di una progettazione fallita. Inserire l'intera tassonomia in un'unica chiamata ha prodotto una verifica dell'intento debole, nonostante i ripetuti aggiustamenti del prompt.
Questo fallimento rende il caso più utile di una semplice storia di successo del fornitore. Mostra che il solo accesso al modello non garantisce un quality assurance affidabile.
L'incertezza rimanente riguarda la manutenzione. Le tassonomie cambiano, il comportamento dei clienti si modifica e il linguaggio delle policy evolve. Anche i fornitori di modelli aggiornano le versioni disponibili e le funzionalità di supporto.
DiDi avrà bisogno di set di valutazione versionati che conservino esempi rappresentativi di ogni lingua, canale, linea di business e criterio ad alto rischio. In caso contrario, un miglioramento della configurazione in un'area può ridurre silenziosamente le prestazioni altrove.
I team che sviluppano sistemi simili dovrebbero conservare le evidenze alla base di ogni rilascio. Una base di conoscenza ingegneristica ricercabile può collegare requisiti, risultati dei test, versioni dei prompt e revisioni degli incidenti senza trattare le spiegazioni generate come verità assolute.
Questa pratica sostiene la vera promessa della trasparenza. La visibilità è utile solo quando i team possono ricostruire cosa è cambiato, perché è cambiato e come si è comportata la nuova versione.
Il prossimo test è capire se DiDi può scalare il controllo
Tre segnali determineranno se l'architettura di DiDi diventerà un sistema operativo durevole per il QA o resterà un'implementazione di successo con una validazione pubblica limitata.
Il primo segnale riguarda le prestazioni in ulteriori lingue e linee di business. DiDi afferma di voler espandere il sistema oltre la copertura attuale.
Questa espansione metterà alla prova se la configurazione dinamica limiti davvero il lavoro di manutenzione. Una nuova lingua cambia più delle istruzioni tradotte. Può introdurre formulazioni regionali, aspettative culturali, errori di trascrizione e requisiti di policy differenti.
Se l'accuratezza resterà stabile nelle nuove implementazioni, il risultato rafforzerà la tesi di DiDi sulla gestione del contesto. Calo marcati suggerirebbero che i guadagni attuali dipendano fortemente dall'attuale ambiente di validazione in spagnolo e portoghese.
Il secondo segnale è l'integrazione tra pipeline. DiDi intende collegare più strettamente la verifica dell'intento, il punteggio di conformità e l'analisi VOC.
Oggi, ogni pipeline ha uno scopo distinto. L'integrazione può creare un ciclo di feedback in cui le tendenze nei reclami rivelano classificazioni mancanti, i ripetuti fallimenti di classificazione aggiornano la tassonomia e i risultati di conformità orientano il coaching.
Può però anche diffondere gli errori. Un cluster di problemi difettoso potrebbe influenzare le modifiche alla tassonomia, che a loro volta incidono sui controlli dell'intento e sui report di gestione.
Un'integrazione riuscita richiede quindi la provenienza dei dati. Ogni raccomandazione a valle dovrebbe conservare collegamenti alle conversazioni, ai campi estratti, alla versione della configurazione e all'output del modello che l'hanno prodotta.
Il terzo segnale è costituito da evidenze operative oltre l'accuratezza. Le future divulgazioni dovrebbero includere tassi di override umano, schemi di falsi positivi, latenza di elaborazione, tempi di revisione e prestazioni per categoria.
Queste misurazioni mostrerebbero se il sistema resta utile dopo il periodo di validazione iniziale. Aiuterebbero inoltre gli acquirenti a confrontare architetture di proprietà con prodotti gestiti per contact center.
L'analisi VOC offre il test immediato più chiaro. DiDi ha descritto un aumento dei reclami relativi alle commissioni di cancellazione nei mercati latinoamericani. Il personale operativo ha avviato un'analisi che ha raggruppato conversazioni multilingue e prodotto un report strutturato in pochi minuti.
La pipeline inizia estraendo in parallelo i campi da ogni conversazione. Questi campi includono il tipo di problema, il sentiment, l'esito e la possibile causa principale.
Un modello di embedding misura quindi la somiglianza semantica tra le etichette dei problemi. Gli embedding sono rappresentazioni numeriche che collocano significati correlati vicini tra loro, consentendo al sistema di unire reclami formulati in modo diverso.
Questa fase utilizza calcoli di distanza e classifiche di frequenza anziché output generativo. DiDi afferma che il design rende il clustering deterministico e riproducibile.
Durante la generazione del report, il modello linguistico riceve solo i cluster ad alta frequenza. Crea un riepilogo per il management, identifica i punti critici e suggerisce azioni a partire da un insieme di evidenze più piccolo e strutturato.
Anche questa pipeline applica l'isolamento delle informazioni. Il modello non riceve migliaia di conversazioni grezze in un unico prompt sovradimensionato. Ogni fase restringe le evidenze necessarie alla decisione successiva.
DiDi afferma che il processo ha ridotto da ore a minuti il lavoro precedentemente necessario. L'affermazione diventerà più convincente se i futuri report mostreranno se i team operativi abbiano agito più rapidamente o prevenuto danni ripetuti ai clienti.
La velocità da sola non è l'obiettivo. Un report rapido con una causa principale errata può indirizzare le risorse verso l'intervento sbagliato.
L'implementazione più solida assocerà un rilevamento più rapido a risultati misurabili. Questi potrebbero includere meno contatti ripetuti, una migliore risoluzione dei problemi, una minore ricorrenza dei reclami o una correzione più rapida di un problema di policy.
Per gli sviluppatori, la lezione immediata è progettare i confini del modello prima di perfezionare i prompt. Occorre decidere quali evidenze servono a ogni chiamata, quali output richiedono uno schema e quali fatti dovrebbero essere calcolati nel codice.
Gli acquirenti enterprise dovrebbero richiedere ai fornitori la stessa chiarezza. Dovrebbero chiedere regole versionate, decisioni verificabili, validazione per categoria, flussi di escalation e controlli di accesso che riflettano la sensibilità dei dati delle conversazioni.
I knowledge worker dovrebbero interessarsene perché questo schema va oltre il supporto clienti. Qualsiasi sistema che classifica documenti, valuta il lavoro o riassume problemi ricorrenti può soffrire quando vede opzioni irrilevanti o combina attività incompatibili.
Il QA del contact center di DiDi è quindi una prova della capacità organizzativa tanto quanto delle prestazioni del modello. L’azienda si è assunta la responsabilità del contesto, delle definizioni e della validazione, invece di esternalizzare l’intero livello di giudizio.
Questa responsabilità produrrà risultati stabili con l’evoluzione di lingue, policy e modelli? Osservate le metriche di espansione, le tracce di evidenza tra pipeline e i tassi di intervento umano. Questi segnali mostreranno se un’AI aziendale trasparente possa superare nel tempo la scatola nera.
