El QA del centro de contacto de DiDi sustituye una caja negra con Amazon Bedrock

DiDi reemplazó una herramienta opaca de aseguramiento de calidad después de que sus comprobaciones de intención alcanzaran apenas un 38% de precisión. Según se informa, su nuevo sistema de QA para centros de contacto de DiDi elevó esa cifra al 86%.

La empresa desarrolló el reemplazo con AWS para su International Business Group. Procesa conversaciones de soporte en español y portugués en servicios de transporte, entrega de comida y servicios financieros. El sistema también puntúa el cumplimiento y detecta quejas emergentes de clientes.

Esto es más que otra empresa añadiendo un modelo de lenguaje grande al soporte al cliente. DiDi trasladó un control interno de consecuencias relevantes desde un proveedor externo a una arquitectura que su propio equipo puede inspeccionar y modificar. Por tanto, la competencia principal es entre la automatización externalizada y opaca, y una IA transparente y de propiedad propia.

AWS y DiDi dieron a conocer el sistema en un estudio de caso sobre QA de centros de contacto del 8 de septiembre de 2026. La mayoría de las cifras de rendimiento proceden de la validación en producción de DiDi y no han sido auditadas de forma independiente.

Aun así, los resultados merecen atención. Muestran cómo un contexto acotado, comprobaciones deterministas y resultados estructurados pueden importar más que reescribir repetidamente un prompt.

Qué cambió dentro del QA del centro de contacto de DiDi

DiDi no sustituyó un modelo por otro. Dividió el aseguramiento de calidad en tres flujos controlados con funciones y requisitos de evidencia distintos.

El primer flujo verifica la intención. Los representantes de atención al cliente asignan a cada conversación un motivo de contacto, que sitúa el caso dentro del árbol de clasificación jerárquico de DiDi. El sistema comprueba si ese motivo asignado coincide con lo que trató el cliente.

Si la etiqueta parece incorrecta, el flujo recomienda una alternativa. También examina las conversaciones etiquetadas como “Other”, para las que ninguna categoría existente parecía apropiada. Estos casos pueden revelar lagunas en la propia taxonomía.

El segundo flujo evalúa el cumplimiento. Puntúa varios criterios de calidad mientras extrae información operativa de la misma conversación. DiDi afirma que su precisión media en la puntuación de cumplimiento superó el 90% durante la validación en producción.

El tercer flujo analiza datos de Voice of Customer. Voice of Customer, o VOC, se refiere a evidencia agregada sobre problemas de clientes, sentimiento, resultados y causas recurrentes. DiDi utiliza este flujo bajo demanda cuando los equipos de operaciones necesitan comprender un patrón en desarrollo.

Los registros de chat en vivo y las transcripciones telefónicas entran primero en una capa de preprocesamiento. La salida de conversión de voz a texto de las llamadas se normaliza al mismo formato de conversación utilizado para el chat. A continuación, los registros resultantes pasan por los flujos de QA correspondientes.

Ese esquema común es importante. Las diferencias entre voz y chat no deberían obligar a cada componente de análisis posterior a implementar su propia lógica de ingesta. El sistema separa el procesamiento del canal de las tareas de razonamiento que siguen.

El negocio internacional de DiDi opera en 14 países y regiones, según las empresas. Su organización de soporte gestiona conversaciones en español y portugués para decenas de millones de usuarios en tres líneas de negocio.

A esa escala, la revisión manual solo puede inspeccionar una parte limitada de las interacciones. Sin embargo, la alternativa externalizada tenía su propio problema. DiDi afirma que su sistema anterior no exponía suficiente razonamiento para explicar juicios históricos ni respaldar cambios rápidos.

Una puntuación de cumplimiento fallida puede afectar la formación, las auditorías y las prioridades operativas. Una etiqueta de intención errónea puede distorsionar los informes sobre por qué los clientes necesitan ayuda. Por tanto, un juicio sin explicación no es solo inconveniente para un desarrollador.

El reemplazo vincula una cadena de razonamiento a cada juicio del modelo. Los revisores pueden ver la base declarada para una puntuación, examinar la conversación original y comparar la decisión con la regla aplicable.

Esa trazabilidad genera la tensión central del artículo. Llevar el sistema al interior de DiDi mejora la visibilidad y el control, pero también hace a DiDi responsable de la validación, la seguridad, la configuración y la precisión continua.

DiDi ahora es propietaria de las definiciones que dan forma al resultado. También asume las consecuencias cuando esas definiciones son incompletas o incorrectas.

Por qué el aislamiento del contexto superó a un mayor ajuste de prompts

La mayor ganancia de precisión comunicada provino de mostrar al modelo menos información en el momento adecuado, no de añadir más instrucciones.

El diseño inicial de verificación de intención de DiDi seguía un enfoque intuitivo. Colocaba el árbol completo de motivos de contacto junto a la conversación y pedía al modelo que juzgara la etiqueta seleccionada por el representante.

Entonces, el modelo comparaba la etiqueta elegida con todas las alternativas disponibles. Cuando encontraba una categoría que parecía ligeramente más precisa, tendía a rechazar una selección que, por lo demás, era razonable.

Este comportamiento provocaba una corrección excesiva. Un modelo encargado de encontrar la mejor etiqueta puede comportarse de forma distinta a uno al que se le pregunta si una etiqueta existente es aceptable. Combinar ambas decisiones en un solo prompt difuminaba la diferencia.

DiDi afirma que varias rondas de ajuste de prompts no resolvieron el problema. El equipo concluyó que al modelo se le había dado el entorno de decisión equivocado.

El flujo de intención rediseñado separa la verificación de la clasificación. Durante la verificación, el modelo recibe la conversación y únicamente el motivo de contacto actual del representante. Decide si esa etiqueta encaja razonablemente con la interacción.

El árbol completo de clasificación permanece oculto en esta fase. Ese aislamiento de información evita que el modelo busque alternativas marginalmente mejores antes de responder a la pregunta más acotada.

Solo una verificación fallida abre la etapa de clasificación. Entonces, el modelo recibe la taxonomía completa, junto con el razonamiento de la primera etapa. Recomienda otra categoría y proporciona una puntuación de confianza y una justificación.

DiDi gestiona las etiquetas “Other” mediante un proceso separado de tres niveles. El sistema primero busca una coincidencia adecuada entre las categorías hermanas. Después busca en todo el árbol si la rama local no ofrece una respuesta.

Si ninguna búsqueda produce una categoría apropiada, el flujo identifica una posible laguna en la taxonomía. Entonces puede sugerir que los operadores añadan una etiqueta, en lugar de forzar la conversación a una categoría existente inadecuada.

Según DiDi, este diseño de dos niveles elevó la precisión de la verificación de intención del 38% al 86%. Eso supone un incremento de 48 puntos porcentuales, según la validación en producción declarada por la empresa.

El mecanismo ofrece una lección práctica para los equipos de IA empresarial. Más contexto no equivale automáticamente a mejor contexto. Las opciones adicionales pueden cambiar la tarea que el modelo aparentemente resuelve.

Esto importa porque muchos prompts empresariales combinan varias decisiones para ganar eficiencia. Una única solicitud podría pedir a un modelo que clasifique una conversación, justifique el resultado, compruebe el cumplimiento de políticas, resuma el caso y recomiende una acción.

Cada objetivo adicional crea otra oportunidad para que las instrucciones y la evidencia interfieran entre sí. También dificulta el análisis de fallos porque los desarrolladores no pueden identificar fácilmente qué parte del contexto modificó la respuesta.

En cambio, el enfoque de DiDi trata el contexto como parte de la arquitectura de la aplicación. El equipo decide qué información se vuelve visible en cada punto de decisión, del mismo modo que el software convencional controla el acceso a variables y estado.

Ese diseño también produce límites de fallo más claros. Un resultado de verificación cuestionable pertenece a la primera etapa. Una etiqueta de reemplazo deficiente pertenece a la segunda. Una categoría ausente pertenece a la gobernanza de la taxonomía.

El resultado no constituye una afirmación universal de que los sistemas multietapa siempre superen a los prompts únicos. Cada etapa añadida crea latencia, complejidad operativa y otro componente que supervisar.

DiDi no ha publicado el tamaño de la muestra, la distribución de clases, los intervalos de confianza ni el rendimiento por idioma y línea de negocio. Estas omisiones limitan las comparaciones con otros sistemas de QA para centros de contacto.

Aun así, el cambio comunicado cuestiona un hábito empresarial común. Los equipos suelen responder a un comportamiento decepcionante del modelo ampliando las instrucciones o cambiando de modelos fundacionales. DiDi modificó en su lugar el flujo de información.

Esa es una forma más profunda de ingeniería de prompts. Traslada la responsabilidad de una redacción ingeniosa al diseño del sistema, las definiciones de datos y los límites explícitos de decisión.

Un sistema propio presiona a la IA externalizada

El desafío más fuerte de DiDi a los proveedores externos de QA no es la afirmación sobre precisión del modelo. Es el argumento de que la lógica de juicio se ha convertido en infraestructura estratégica.

Una plataforma externalizada puede reducir el trabajo de implementación. Puede agrupar transcripción, evaluación, paneles y flujos de trabajo en un producto gestionado. Los compradores evitan mantener por sí mismos cada componente.

Sin embargo, esa comodidad se convierte en una restricción cuando el proveedor no revela cómo llegó a un juicio. DiDi afirma que su solución anterior tomaba decisiones de QA sin una pista de auditoría suficiente.

La limitación se volvió más grave a medida que cambiaban los estándares. El soporte en español para servicios de transporte no utiliza necesariamente los mismos criterios que el soporte en portugués para servicios financieros. Las nuevas políticas crean más combinaciones.

Una implementación controlada por un proveedor puede requerir cambios personalizados, reentrenamiento o actualizaciones del producto antes de que esos estándares aparezcan en producción. Durante ese intervalo, pueden coexistir reglas antiguas y nuevas.

DiDi trasladó las definiciones de políticas a una configuración externa. El flujo de evaluación utiliza una plantilla de prompt y luego inserta el idioma, la línea de negocio, la definición del criterio, la regla de aprobación y la regla de fallo para cada ticket.

Añadir otro criterio no requiere reescribir cada prompt específico por idioma. Los operadores actualizan la configuración y la aplicación reúne el contexto necesario cuando recibe una conversación.

El flujo evalúa varios elementos de cumplimiento en una sola llamada al modelo. También devuelve información empresarial estructurada, incluidas medidas relacionadas con la resolución de problemas y la satisfacción del cliente.

Amazon Bedrock Tool Use restringe la respuesta a una estructura JSON definida. Cada elemento de puntuación contiene un juicio y su justificación correspondiente. La capacidad de uso de herramientas pertinente permite a las aplicaciones describir la entrada de herramienta esperada y procesar los datos estructurados resultantes.

La salida estructurada resuelve solo el problema del formato de respuesta. Un JSON válido no garantiza que la puntuación subyacente sea correcta. Por ello, DiDi añade comprobaciones deterministas después de la generación.

Por ejemplo, el modelo puede identificar posibles errores ortográficos. El código de la aplicación cuenta entonces solo los errores en los mensajes del representante y aplica el umbral definido al número verificado.

El sistema también calcula en código los tiempos de espera de respuesta. Inserta esos valores en el prompt en lugar de pedir al modelo que los infiera a partir de las marcas de tiempo.

Este patrón híbrido asigna los juicios semánticos al modelo de lenguaje y los hechos computables al software convencional. Evita utilizar generación probabilística cuando un cálculo directo puede proporcionar una respuesta reproducible.

Esa distinción es fundamental para el enfoque de propiedad propia. DiDi puede inspeccionar qué decisiones corresponden al modelo, cuáles corresponden al código y cuáles dependen de la configuración empresarial.

La arquitectura también utiliza Amazon Bedrock porque el servicio expone varios modelos fundacionales mediante una interfaz común. DiDi afirma que la elección de modelo puede cambiar sin reconstruir cada flujo alrededor de otra integración específica de proveedor.

La portabilidad entre modelos aún tiene límites. Distintos modelos interpretan de forma diferente los prompts y los esquemas, por lo que cambiar de modelo requiere una evaluación nueva. Una API común reduce parte del trabajo de integración, pero no hace que los comportamientos sean intercambiables.

La seguridad crea otro punto de presión. Las conversaciones de clientes pueden contener nombres, información de contacto, datos financieros, información de ubicación y reclamaciones sensibles. Incorporar esos registros a un flujo de trabajo de IA amplía el sistema que debe gobernarse.

DiDi afirma que la implementación utiliza endpoints de VPC mediante AWS PrivateLink, cifrado y controles detallados de gestión de identidades y accesos. AWS documenta que una conexión privada puede acceder a Bedrock sin una puerta de enlace a internet ni una dirección IP pública.

El sistema también aplica Amazon Bedrock Guardrails antes de la inferencia del modelo. Enmascara información de identificación personal y utiliza comprobaciones de fundamentación contextual para señalar respuestas que carecen de respaldo suficiente.

AWS describe Guardrails como políticas que evalúan prompts y respuestas en ámbitos como información sensible, temas restringidos y contenido no deseado. Sus controles de guardrails pueden bloquear o enmascarar contenido según la política configurada.

Estas medidas no eliminan el trabajo de gobernanza. DiDi aún debe definir reglas de acceso, retención, escalamiento, revisión y tratamiento regional para los datos de clientes.

La misma carga se aplica a la lógica de negocio. Poseer un sistema transparente implica mantener sus taxonomías, criterios de evaluación, conjuntos de validación y proceso de supervisión. La empresa ha cambiado la opacidad del proveedor por responsabilidad interna.

Por tanto, los proveedores externos afrontan presión desde dos frentes. Deben igualar la conveniencia de un producto gestionado y, al mismo tiempo, exponer evidencia, configurabilidad y control suficientes para que los clientes empresariales confíen en juicios con consecuencias importantes.

La respuesta no tiene por qué ser una divulgación completa del código. Los proveedores pueden ofrecer trazas de decisión, reglas versionadas, herramientas de evaluación, resultados exportables y una separación más clara entre la salida del modelo y las comprobaciones deterministas.

El caso de DiDi sugiere que un simple panel de precisión ya no basta. Los compradores necesitan cada vez más saber qué modelo, versión de prompt, definición de política y regla de posprocesamiento produjo cada puntuación.

Este requisito convierte la observabilidad en una funcionalidad del producto. También hace que la propiedad interna resulte más atractiva para empresas con suficiente capacidad de ingeniería y operaciones suficientemente especializadas.

Lo que no muestran las cifras de precisión

Las mejoras reportadas son relevantes, pero la evidencia pública no puede establecer cómo se comporta el sistema en cada mercado, idioma, categoría o política cambiante.

Las cifras de intención del 38 % y 86 % provienen de la validación de producción de DiDi. La publicación de AWS no revela cuántas conversaciones se probaron ni cómo definieron los evaluadores un resultado correcto.

Tampoco proporciona precisión por español frente a portugués. El rendimiento puede diferir según acentos, vocabulario regional, canales de soporte, líneas de negocio y profundidad de clasificación.

El equilibrio entre clases también importa. Un conjunto de datos dominado por preguntas comunes sobre transporte con conductor puede generar una puntuación global sólida mientras oculta resultados débiles en casos menos frecuentes de servicios financieros.

La misma cautela se aplica a las puntuaciones de cumplimiento superiores al 90 %. El material publicado no indica cuántos criterios se incluyeron, si cada criterio recibió el mismo peso ni cómo resolvieron los desacuerdos los revisores humanos.

La precisión también puede ocultar distintos costes de error. Una falsa infracción ortográfica es inconveniente, mientras que una evaluación incorrecta relacionada con conductas reguladas en servicios financieros puede acarrear consecuencias más graves.

Por ello, una evaluación de producción debería rastrear la precisión y la exhaustividad de cada criterio individual, no solo un promedio único. También debería supervisar el desacuerdo entre los revisores humanos y el sistema automatizado.

Las trazas de razonamiento ayudan a los revisores a investigar decisiones, pero no son una prueba. Un modelo de lenguaje puede producir una explicación plausible para una respuesta equivocada.

La capa de validación determinista reduce este riesgo para hechos medibles. No puede convertir cada juicio de política en un cálculo. El tono, la calidad de la resolución, la empatía y la adecuación contextual aún requieren interpretación.

Los guardrails introducen otra limitación. Pueden filtrar información sensible y comprobar la fundamentación, pero AWS recomienda mantener la validación a medida que cambian las salvaguardas subyacentes. Un control configurado no debe tratarse como una garantía permanente.

La supervisión humana sigue siendo necesaria, en particular para puntuaciones disputadas y criterios de mayor riesgo. Los equipos de revisión necesitan una vía de apelación que pueda corregir tanto la decisión individual como la regla subyacente.

La publicación también carece de mediciones operativas. No informa sobre la latencia del modelo, el coste de procesamiento, la tasa de anulaciones, la carga de trabajo de los revisores ni el porcentaje de conversaciones que requieren escalamiento.

Estas cifras revelarían si una mayor precisión del modelo se traduce en mejores operaciones. Un sistema preciso aún puede tener dificultades si responde con demasiada lentitud, requiere correcciones manuales frecuentes o se vuelve costoso a gran escala.

La comparación con otras implementaciones aporta una perspectiva útil. El proveedor de servicios financieros Empower describió anteriormente otra implementación de QA basada en Bedrock que procesaba miles de transcripciones al día.

Su sistema de QA automatizado combinó Amazon Connect Contact Lens con Bedrock. Empower afirmó que amplió veinte veces la cobertura de QA y redujo el tiempo de revisión de días a minutos.

Las implementaciones no son directamente comparables. Empower utilizó transcripciones previamente redactadas de una plataforma de centro de contacto de AWS, mientras que DiDi describió su propio preprocesamiento y una arquitectura de tres pipelines.

Sin embargo, ambos casos apuntan hacia la misma dirección competitiva. Las empresas quieren revisar más conversaciones, explicar las evaluaciones y acortar la distancia entre los problemas de los clientes y la acción operativa.

La contribución distintiva de DiDi es su relato de un diseño fallido. Introducir toda la taxonomía en una sola llamada produjo una verificación de intención deficiente, pese a repetidos ajustes de prompts.

Ese fracaso hace que el caso sea más útil que una simple historia de éxito de un proveedor. Demuestra que el acceso al modelo por sí solo no proporciona una garantía de calidad fiable.

La incertidumbre restante se refiere al mantenimiento. Las taxonomías cambian, el comportamiento de los clientes se desplaza y el lenguaje de las políticas evoluciona. Los proveedores de modelos también actualizan las versiones disponibles y las funciones de apoyo.

DiDi necesitará conjuntos de evaluación versionados que preserven ejemplos representativos de cada idioma, canal, línea de negocio y criterio de alto riesgo. De lo contrario, una mejora de configuración en un área puede reducir silenciosamente el rendimiento en otra.

Los equipos que construyan sistemas similares deberían conservar la evidencia detrás de cada versión. Una base de conocimientos de ingeniería con capacidad de búsqueda puede conectar requisitos, resultados de pruebas, versiones de prompts y revisiones de incidentes sin tratar las explicaciones generadas como una verdad fundamental.

Esta práctica respalda la verdadera promesa de la transparencia. La visibilidad solo es útil cuando los equipos pueden reconstruir qué cambió, por qué cambió y cómo funcionó la nueva versión.

La próxima prueba es si DiDi puede escalar el control

Tres señales determinarán si la arquitectura de DiDi se convierte en un sistema operativo duradero para QA o sigue siendo una implementación exitosa con una validación pública limitada.

La primera señal es el rendimiento en idiomas y líneas de negocio adicionales. DiDi afirma que planea ampliar el sistema más allá de su cobertura actual.

Esa expansión pondrá a prueba si la configuración dinámica limita realmente el trabajo de mantenimiento. Un nuevo idioma cambia más que las instrucciones traducidas. Puede introducir expresiones regionales, expectativas culturales, errores de transcripción y requisitos normativos distintos.

Si la precisión se mantiene estable en nuevos despliegues, el resultado reforzará la tesis de DiDi sobre la gestión del contexto. Descensos importantes sugerirían que las ganancias actuales dependen en gran medida del entorno de validación existente en español y portugués.

La segunda señal es la integración entre pipelines. DiDi planea conectar de manera más profunda la verificación de intención, la puntuación de cumplimiento y el análisis de VOC.

Hoy, cada pipeline tiene un propósito distinto. La integración puede crear un ciclo de retroalimentación en el que las tendencias de reclamaciones revelen clasificaciones ausentes, los fallos repetidos de clasificación actualicen la taxonomía y los hallazgos de cumplimiento orienten la formación.

También puede propagar errores. Un grupo defectuoso de incidencias podría influir en cambios de taxonomía, que luego afecten las comprobaciones de intención y los informes de gestión.

Por tanto, una integración exitosa requiere procedencia. Cada recomendación posterior debe conservar enlaces a las conversaciones, los campos extraídos, la versión de configuración y la salida del modelo que la produjeron.

La tercera señal es la evidencia operativa más allá de la precisión. Las futuras divulgaciones deberían incluir tasas de anulación humana, patrones de falsos positivos, latencia de procesamiento, tiempo de revisión y rendimiento por categoría.

Estas mediciones mostrarían si el sistema sigue siendo útil tras el período inicial de validación. También ayudarían a los compradores a comparar arquitecturas de propiedad propia con productos gestionados para centros de contacto.

El análisis de VOC ofrece la prueba inmediata más clara. DiDi describió un aumento de reclamaciones por tarifas de cancelación en los mercados latinoamericanos. El personal de operaciones activó un análisis que agrupó conversaciones multilingües y produjo un informe estructurado en cuestión de minutos.

El pipeline comienza extrayendo campos de cada conversación en paralelo. Estos campos incluyen el tipo de problema, el sentimiento, el resultado y una posible causa raíz.

Después, un modelo de embeddings mide la similitud semántica entre las etiquetas de incidencias. Los embeddings son representaciones numéricas que sitúan significados relacionados cerca unos de otros, lo que permite al sistema fusionar reclamaciones expresadas con palabras distintas.

Esa etapa utiliza cálculos de distancia y clasificaciones por frecuencia en lugar de salida generativa. DiDi afirma que el diseño hace que la agrupación sea determinista y reproducible.

El modelo de lenguaje recibe solo los grupos de alta frecuencia durante la generación de informes. Crea un resumen ejecutivo, identifica puntos problemáticos y propone acciones a partir de un conjunto de evidencia más pequeño y estructurado.

Este pipeline vuelve a aplicar el aislamiento de información. El modelo no recibe miles de conversaciones sin procesar en un único prompt sobredimensionado. Cada etapa delimita la evidencia necesaria para la siguiente decisión.

DiDi afirma que el proceso redujo a minutos un trabajo que antes requería horas. La afirmación será más convincente si futuros informes muestran si los equipos de operaciones actuaron más rápido o evitaron perjuicios repetidos a los clientes.

La rapidez no es el único objetivo. Un informe rápido con una causa raíz incorrecta puede dirigir recursos hacia la intervención equivocada.

La implementación más sólida combinará una detección más rápida con resultados medibles. Estos podrían incluir menos contactos repetidos, una mejor resolución de incidencias, menor recurrencia de reclamaciones o una corrección más rápida de un problema de política.

Para los desarrolladores, la lección inmediata es diseñar los límites del modelo antes de perfeccionar los prompts. Decidan qué evidencia necesita cada llamada, qué salidas requieren un esquema y qué hechos deben calcularse en código.

Los compradores empresariales deberían exigir la misma claridad a los proveedores. Soliciten reglas versionadas, decisiones auditables, validación por categoría, flujos de escalamiento y controles de acceso que reflejen la sensibilidad de los datos de conversación.

Los trabajadores del conocimiento deberían prestar atención porque este patrón se extiende más allá del soporte. Cualquier sistema que clasifique documentos, evalúe trabajo o resuma problemas recurrentes puede sufrir cuando ve opciones irrelevantes o combina tareas incompatibles.

Por lo tanto, el control de calidad del centro de contacto de DiDi es una prueba de la capacidad organizativa tanto como del rendimiento del modelo. La empresa ha asumido la responsabilidad del contexto, las definiciones y la validación, en lugar de externalizar toda la capa de juicio.

¿Producirá esa responsabilidad resultados estables a medida que cambien los idiomas, las políticas y los modelos? Observe las métricas de expansión, los rastros de evidencia entre pipelines y las tasas de intervención humana. Estas señales mostrarán si la IA empresarial transparente puede superar a la caja negra con el tiempo.