💬 NLP

Building Customer Support AI Agents at 100M-User Scale: An Evaluation-Driven Framework

Este artículo presenta un marco unificado, impulsado por la evaluación, desarrollado en Nubank que integra ingeniería de contexto estructurada, iteración con intervención humana y una rigurosa evaluación mediante jueces de LLM para desplegar con éxito agentes de IA de atención al cliente listos para producción en cinco dominios para más de 100 millones de usuarios, logrando mejoras significativas en la satisfacción y las tasas de autoservicio al demostrar una fuerte correlación entre las métricas offline y el impacto online.

Autores originales: Aman Gupta, Kevin Rossell, Edesio Alcobaça, Jose Chrystian Lima Pacheco, Carolina Baptista de Lima, Shao Tang, Luiz Paulo Rabachini, Luis Moneda, Herbert Fei, Daniel Silva, Rohan Ramanath

Publicado 2026-06-09

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Aman Gupta, Kevin Rossell, Edesio Alcobaça, Jose Chrystian Lima Pacheco, Carolina Baptista de Lima, Shao Tang, Luiz Paulo Rabachini, Luis Moneda, Herbert Fei, Daniel Silva, Rohan Ramanath

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que diriges un banco masivo con 100 millones de clientes. Cada día, millones de personas llaman o chatean haciendo preguntas como: "¿Dónde está mi tarjeta de crédito?" o "¿Por qué debo tanto?".

En el pasado, necesitarías un ejército de agentes humanos para responder a esto. Pero ahora, quieres construir un robot de IA superinteligente para manejar estas conversaciones. El problema es que, si el robot da una respuesta incorrecta, un cliente se enoja, pierde la confianza y se va. No puedes simplemente "adivinar" si el robot es bueno; necesitas estar 100% seguro antes de dejarlo hablar con personas reales.

Este documento es un plano de Nubank (un banco gigante) sobre cómo construyeron estos robots de IA de forma segura y exitosa. Así es como lo hicieron, explicado de forma sencilla:

1. El Problema: Construir un Robot sin una Prueba de Choque

Normalmente, cuando la gente construye IA, escribe instrucciones, la prueba un poco y espera lo mejor. Los autores dicen que esto es como construir un coche y conducirlo hacia un acantilado para ver si los airbags funcionan. En el servicio de atención al cliente, un choque es demasiado costoso.

Necesitaban una forma de probar el robot miles de veces en un "simulador" antes de dejarlo hablar con un solo humano real.

2. La Solución: La Fábrica "Impulsada por la Evaluación"

En lugar de solo escribir instrucciones, construyeron una línea de producción con cuatro estaciones principales. Piensa en esto como tunear un coche de carreras:

Estación 1: El Kit Modular (Ingeniería de Contexto)
En lugar de escribir un manual de instrucciones gigante y desordenado para el robot, lo dividieron en bloques de Lego.
- Las Reglas: Cómo debe hablar el robot (educado, conciso).
- El Playbook (Libro de Estrategia): Guías paso a paso para problemas específicos (por ejemplo, "Si la tarjeta se perdió, haz el paso A, luego el paso B").
- Las Herramientas: Una lista de cosas que el robot realmente puede hacer (como consultar una base de datos o reemitir una tarjeta).
- La Memoria: Un bloc de notas donde el robot anota lo que aprendió durante el chat.
- Por qué importa: Si el robot se equivoca en el saludo, solo tienes que cambiar el "bloque de Lego del Saludo". No tienes que reconstruir todo el coche.
Estación 2: Los Jueces Robot (LLM-as-a-Judge)
¿Cómo sabes si el robot está haciendo un buen trabajo? No puedes pedirle al robot que se califique a sí mismo. Así que usaron otra IA (un "Juez") para calificar las respuestas del primer robot.
- El inconveniente: A veces, la IA Juez es sesgada o perezosa. Para solucionar esto, usaron una técnica especial llamada GEPA. Imagina a un entrenador que observa al Juez de IA calificar un examen, se da cuenta de que el Juez fue demasiado estricto y reescribe la rúbrica de calificación para que sea más justa. Hicieron esto automáticamente hasta que la calificación se volvió súper consistente.
Estación 3: La Red de Seguridad Humana (Confiabilidad Inter-Evaluador)
Antes de confiar en el Juez de IA, hicieron que humanos reales calificaran las mismas respuestas. Verificaron si los humanos estaban de acuerdo entre sí. Si los humanos estaban de acuerdo el 90% de las veces, sabían que la prueba era justa. Luego, se aseguraron de que el Juez de IA estuviera tan de acuerdo con los humanos como ellos.
Estación 4: La Prueba del Mundo Real (Pruebas A/B)
Una vez que el robot pasó las pruebas del simulador, lo dejaron hablar con un pequeño grupo de clientes reales (como el 1% de los usuarios). Compararon este robot con el sistema anterior. Si el nuevo robot hacía más felices a los clientes, lo dejaron hablar con más personas.

3. Los Resultados: El Robot Gana

Probaron este sistema en cinco tipos diferentes de problemas:

Entrega de Tarjeta: "¿Dónde está mi tarjeta?"
Gestión de Deuda: "¿Cómo pago mi préstamo?"
Límites de Crédito: "¿Puedo obtener un límite más alto?"
Gestión de Tarjeta: "Cambiar mi PIN."
Explicador de Producto: "¿Qué hace esta función?"

Los Números Mágicos:

Felicidad: Para el robot de "Entrega de Tarjeta", la felicidad del cliente (medida por una puntuación llamada tNPS) aumentó 37 puntos. Ese es un incremento masivo.
Autoservicio: Más personas resolvieron sus problemas sin necesidad de un humano. La "tasa de autoservicio" aumentó 29 puntos.
Humano vs. Robot: En cuatro de los cinco casos, el robot fue casi tan bueno como un experto humano de alto nivel (con una diferencia de pocos puntos porcentuales). El único lugar donde tuvo dificultades fue en el área de "Gestión de Deuda", que es muy compleja, lo cual tiene sentido porque es el problema de matemáticas y empatía más difícil.

4. La Gran Lección: "Si puedes medirlo, puedes arreglarlo"

La conclusión más importante del documento es esta: La calidad de tu prueba determina qué tan rápido puedes mejorar.

Debido a que construyeron un sistema de prueba tan riguroso (el "simulador"), podían hacer cambios en las instrucciones del robot y saber inmediatamente si mejoraba o empeoraba. No tenían que esperar semanas para ver si los clientes estaban felices. Podían iterar (mejorar) el robot docenas de veces en el simulador, y cuando finalmente lo lanzaron, ya era un campeón.

En resumen: No solo construyeron una IA inteligente; construyeron un laboratorio de pruebas inteligente para la IA. Y debido a que el laboratorio era tan bueno, el robot que enviaron al mundo era increíblemente confiable, generaba felicidad y estaba listo para 100 millones de usuarios.

Resumen Técnico: Construcción de Agentes de IA para Atención al Cliente a Escala de 100 Millones de Usuarios

Planteamiento del Problema

El rápido avance de los Modelos de Lenguaje Extensos (LLMs) ha hecho que los agentes de IA sean viables para tareas complejas; sin embargo, desplegar agentes orientados al cliente listos para producción a escala sigue siendo un desafío significativo. En el dominio de la atención al cliente (CS), específicamente dentro de entornos de alto riesgo como la banca, los agentes enfrentan restricciones únicas:

Umbrales de Fiabilidad Elevados: Un solo fallo puede erosionar la confianza y provocar la pérdida de clientes; los errores financieros pueden derivar en pérdidas significativas.
Sensibilidad de los Datos: Los agentes deben manejar datos reales de clientes (saldos, transacciones) bajo estrictas restricciones de privacidad y regulatorias.
Especialización vs. Diversidad: Los agentes utilizan conjuntos de herramientas estrechos y específicos del dominio (5–15 herramientas), pero deben gestionar una diversidad sustancial de casos límite.
Traspaso Fluido (Graceful Handoff): Los agentes deben operar dentro de un flujo de trabajo con intervención humana (human-in-the-loop), transfiriendo el control con todo el contexto preservado cuando la automatización falla.

Se ha identificado una brecha crítica: la metodología de evaluación, la ingeniería de contexto, el entrenamiento y la medición en línea se desarrollan típicamente de forma aislada. Esto crea "puntos ciegos" que solo surgen tras el despliegue, ralentizando la velocidad de iteración y arriesgando fallos en producción.

Metodología: Un Marco Impulsado por la Evaluación

Los autores presentan un marco unificado que conecta el desarrollo offline con el impacto online, validado en una empresa que atiende a más de 100 millones de usuarios. La filosofía central es que la calidad del pipeline de evaluación determina directamente la velocidad de iteración.

1. Ingeniería de Contexto Modular

En lugar de prompts monolíticos, el sistema emplea una arquitectura modular con versionado semántico, donde los componentes se gestionan de forma independiente:

Instrucciones: Definiciones de rol, restricciones de comportamiento y salvaguardas de cumplimiento.
Rutinas: Procedimientos ordenados paso a paso derivados de los Procedimientos Operativos Estándar (SOPs) humanos (por ejemplo, flujos de investigación de entrega de tarjetas).
Macros: Plantillas de respuesta preescritas adaptadas por el agente.
Especificaciones de Herramientas: Descripciones independientes de las herramientas (esquema, entrada/salida, condiciones de invocación) que permiten la recombinación.
Memoria de Trabajo (Working Memory): Un bloc de notas persistente que rastrea el estado de la conversación para evitar llamadas redundantes.

2. Pipeline de Evaluación Riguroso

El marco utiliza un enfoque de LLM-como-Juez (LLM-as-a-Judge), mejorado por medidas de fiabilidad específicas:

Iteración con Intervención Humana (HITL): Expertos en el dominio anotan los datos con etiquetas binarias y racionalizaciones textuales.
Optimización GEPA: El sistema utiliza GEPA (dent la estructura de DSPy) para refinar automáticamente los prompts de los jueces. Un modelo robusto critica los errores y sintetiza revisiones basadas en el feedback humano, optimizando la consistencia.
Fiabilidad Inter-Evaluador (IRR): El marco impone umbrales mínimos de acuerdo (medidos mediante el $\kappa$ de Cohen) entre múltiples modelos de jueces. Los prompts solo se consideran confiables si arrojan puntuaciones estables a través de diferentes arquitecturas de modelos (ej. GPT-4.1, GPT-5, o3).
Validación Cross-Model: Asegura que las rúbricas bien especificadas produzcan puntuaciones estables independientemente del modelo de juez específico utilizado.

3. Ciclo de Vida de Desarrollo

El proceso opera en dos bucles anidados:

Bucle Rápido (Fast Loop): Los resultados de la evaluación offline (puntuaciones de simulación) impulsan correcciones inmediatas de los prompts. Si un evaluador detecta un fallo, el componente específico del prompt se modifica quirúrgicamente y se vuelve a evaluar.
Bucle Lento (Slow Loop): Las métricas online (de pruebas A/B) informan cambios arquitectónicos, como la adición de nuevas rutinas o el rediseño de interfaces de herramientas.

4. Infraestructura y Despliegue

Diseño de Herramientas: Las herramientas están diseñadas para ser idempotentes y de orquestación determinista (envolviendo la lógica de múltiples pasos en herramientas únicas) para reducir la latencia y los errores.
Despliegue Progresivo: Los nuevos agentes se despliegan con el 1–5% del tráfico con escalada basada en la confianza hacia agentes humanos.
Portabilidad del Modelo: La arquitectura modular permite una adaptación rápida al migrar entre modelos fundacionales (ej. de GPT-4.1 a GPT-5) ajustando componentes específicos del prompt en lugar de reescribir todo el sistema.

Contribuciones Clave

Marco Unificado: Un sistema de bucle cerrado que conecta la arquitectura del agente, el versionado de prompts, la evaluación offline y la medición online.
Ingeniería de Contexto Modular: Un patrón de diseño que permite el versionado independiente de instrucciones, rutinas, macros y herramientas.
Pipeline de LLM-como-Juez Calibrado: Un sistema de evaluación riguroso que cuenta con requisitos de fiabilidad inter-evaluador, prompts de juez optimizados mediante GEPA y validación cross-model.
Resultados Validados en Producción: Evidencia empírica de cinco despliegues de producción distintos (Entrega de Tarjetas, Gestión de Deuda, Límite de Crédito, Gestión de Tarjetas, Explicación de Productos).

Resultados

El marco fue validado en cinco casos de uso de producción, siendo el agente de Entrega de Tarjetas (Card Delivery) el caso de estudio principal.

Despliegue de Entrega de Tarjetas (Resultados Principales)

Satisfacción del Cliente: Logró una mejora de 37 puntos porcentuales (p.p.) en el NPS transaccional de IA (tNPS) en comparación con variantes previas.
Automatización: Alcanzó una ganancia de 29 p.p. en la Tasa de Autoservicio (SSR).
Paridad Humana: El tNPS final de la IA quedó dentro de un margen de 10 p.p. respecto a los agentes expertos humanos.
Correlación Offline-Online: Se observó una fuerte correlación positiva entre las tasas de fallo de la evaluación offline y las ganancias de tNPS/SSR online. Las versiones con las mayores mejoras offline (ej. V10) entregaron las mayores ganancias online.

Rendimiento Cross-Domain

A través de los cinco dominios, el marco entregó ganancias consistentes:

Gestión de Deuda: Ganancia de +40 p.p. en tNPS (aunque permaneció una brecha mayor de -23.6 p.p. respecto a los humanos, reflejando la complejidad del dominio).
Límite de Crédito: Ganancia de +4.5 p.p. en tNPS; reducciones significativas en las tasas de fallo del evaluador para contexto y empatía.
Gestión de Tarjetas: Ganancia de +38.3 p.p. en tNPS.
Explicador de Productos: Ganancia de +12.3 p.p. en tNPS.

Eficacia del Pipeline de Evaluación

Optimización de Prompts: La optimización automatizada (GEPA) superó consistentemente la ingeniería de prompts manual y las líneas base de clase mayoritaria. Por ejemplo, en el Eval E3, la precisión aumentó del 58.07% (manual) al 73.01% (optimizado).
Acuerdo Inter-Evaluador: Los prompts "iniciales" no optimizados resultaron en un acuerdo insignificante entre modelos ( $\kappa \approx 0.00$ a $0.10$). Los prompts optimizados por GEPA aumentaron significativamente el acuerdo (ej. $\kappa = 0.745$ entre GPT-4.1 y GPT-4.1-mini; $\kappa = 0.950$ entre modelos con alta capacidad de razonamiento).

Significación y Reivindicaciones

El documento sostiene que la calidad de la evaluación es el determinante principal de la velocidad de iteración. Al establecer un "bucle rápido" fiable mediante jueces calibrados y un riguroso acuerdo inter-evaluador, los equipos pueden iterar con confianza offline sin esperar señales online dispersas.

Los autores afirman que su marco logra cerrar la brecha entre la simulación offline y la realidad online, demostrando que el desarrollo impulsado por la evaluación predice de forma fiable el impacto en producción. La metodología demuestra ser generalizable en diversos dominios de atención al cliente, permitiendo a las organizaciones escalar agentes de IA a más de 100 millones de usuarios manteniendo una alta calidad, cumplimiento y satisfacción del cliente. El trabajo enfatiza que, si bien los agentes de IA pueden acercarse al rendimiento de nivel humano en muchos dominios, las tareas más difíciles (como la gestión de deuda) aún requieren supervisión humana cuidadosa y refinamiento iterativo.