Respuesta a la pregunta
Históricamente, el soporte al cliente ha evolucionado de la monopolización de operadores humanos hacia la automatización a través de chatbots basados en reglas, los cuales, sin embargo, a menudo frustran a los usuarios debido a sus escenarios rígidos. La etapa moderna se caracteriza por la implementación de Modelos de Lenguaje Grande (LLM) como GPT-4 o Claude, capaces de llevar a cabo diálogos contextuales y resolver tareas complejas sin programación rígida de lógica. El problema de evaluar la efectividad de tales sistemas se agrava porque las métricas tradicionales (tiempo de resolución, costo por ticket) correlacionan con la calidad del servicio de manera no lineal: la reducción de costos puede llevar a una caída del CSAT, y el aumento de la automatización puede generar frustración en escalaciones fallidas.
La formulación del problema requiere el aislamiento del efecto puro del asistente de IA, desligado de la estacionalidad (las ventas navideñas cambian el perfil de las solicitudes), el efecto de novedad (los usuarios experimentan con el bot de manera más activa durante las primeras semanas) y la endogeneidad de la auto-selección (las solicitudes simples son dirigidas al bot, las complejas a personas). La aleatorización clásica es imposible, ya que desconectar el soporte para el grupo de control durante horas pico crea riesgos éticos y comerciales, y la escalación del diálogo del bot a un humano contamina el efecto puro.
La solución óptima es utilizar Diseño de Discontinuidad de Regresión (RDD) en el umbral de longitud de la cola de espera. Cuando el número de usuarios en espera excede el umbral N (por ejemplo, 5 personas), el sistema ofrece automáticamente al asistente de IA como alternativa a la espera del operador. Esto crea un experimento natural: los usuarios a la izquierda y a la derecha del umbral son estadísticamente idénticos en características observables y no observables. Para tener en cuenta el efecto de aprendizaje del modelo, se aplica Diferencia en Diferencias con un grupo proxy — por ejemplo, los usuarios durante la noche, donde el bot funciona constantemente, se comparan con una ventana temporal similar antes de la implementación. Para analizar la heterogeneidad de los efectos (diferente impacto para diferentes categorías de solicitudes) se utilizan Bosques Causales, que permiten construir efectos medios condicionales de impacto (CATE).
Situación de la vida real
En un gran proyecto de comercio electrónico con 500K solicitudes al mes, el equipo decidió implementar un asistente de LLM para manejar solicitudes del tipo "dónde está mi pedido" y "cambiar la dirección de entrega". El problema era que el piloto coincidía con la temporada previa a las festividades, cuando el tráfico creció 3 veces, y los datos históricos mostraban una disminución estacional del CSAT debido a retrasos en la logística independientemente de la calidad del soporte.
La primera opción considerada fue la comparación directa de métricas un mes antes y un mes después de la implementación. Ventajas: simplicidad de implementación, no requiere cambios en la infraestructura. Desventajas: completa falta de control de estacionalidad, imposible separar el efecto de la IA del efecto del aumento del tráfico general y de los cambios en el surtido (los productos navideños tienen un perfil diferente de devoluciones). Este enfoque fue rechazado de inmediato.
La segunda opción fue una prueba A/B de división geográfica, donde en algunas regiones el bot estaba habilitado, en otras no. Ventajas: aleatorización pura, interpretación simple. Desventajas: efectos de red (el usuario puede vivir en la región A, pero hacer el pedido en la región B para un amigo), la infraestructura logística variable influye en la naturaleza de las solicitudes, y en horas pico, la sobrecarga en una región crearía riesgo de pérdida de clientes. Se decidió buscar una alternativa.
La solución elegida fue RDD con un umbral de longitud de cola de 3 personas. Cuando la cola superaba las 3 personas en espera, el sistema ofrecía al asistente de IA con la posibilidad de quedarse en la cola para hablar con un humano. Para corregir el efecto de escalación se utilizó el análisis Intent-to-Treat (ITT): se compararon todos a quienes se les ofreció el bot, independientemente del uso real, evitando el sesgo de auto-selección por habilidades técnicas. Adicionalmente, se construyó un Control Sintético de datos históricos de categorías similares de solicitudes donde no se utilizaba el bot (por ejemplo, quejas complejas) para filtrar las fluctuaciones estacionales.
El resultado final: se logró medir que el asistente de IA reduce el tiempo medio de resolución de solicitudes simples de 8 a 2 minutos sin una caída estadísticamente significativa del CSAT (una diferencia de 0.1 puntos dentro del intervalo de confianza). Sin embargo, se descubrió un efecto negativo para el segmento de "devoluciones": al escalar de un bot a un humano, el CSAT fue un 15% más bajo que en el contacto directo con un operador, lo que llevó a la creación de una ruta rápida separada para tales solicitudes. Los costos operativos se redujeron en un 30% gracias a la descompresión de la primera línea.
Lo que los candidatos a menudo pasan por alto
¿Cómo manejar correctamente la endogeneidad de la escalación, cuando el usuario, al desilusionarse con el bot, se pasa a un humano con mayor frustración?
Los candidatos a menudo proponen comparar solo los diálogos exitosos con el bot contra los diálogos con un humano, ignorando el sesgo de supervivencia. El enfoque correcto es el análisis del Efecto de Tratamiento Local Promedio (LATE) a través de variables instrumentales: el uso de fallos técnicos aleatorios en el funcionamiento del bot (cuando está temporalmente no disponible) como instrumento para evaluar el efecto solo para aquellos que habrían sido atendidos por el bot si hubiera estado disponible. Esto permite separar el efecto de la propia tecnología del efecto de selección según el tipo de solicitud.
¿Por qué las métricas estándar de precisión del bot (F1-score, BLEU) son incorrectas para la evaluación del impacto causal del producto?
A menudo, los analistas se enfocan en la calidad de la generación de respuestas, olvidando que el objetivo del producto es el cambio en las métricas comerciales, no la perfección técnica. LLM puede generar respuestas gramaticales pero irrelevantes, o viceversa: proporcionar instrucciones técnicamente imprecisas pero que resuelven el problema del usuario (por ejemplo, "intente reiniciar la aplicación"). El enfoque correcto es evaluar el uplift a nivel de la sesión del usuario utilizando el Emparejamiento de Puntajes de Propensión para comparar la complejidad de las solicitudes, no la precisión de generación de texto.
¿Cómo tener en cuenta la no estacionaridad del efecto al continuar entrenando el modelo con nuevos datos?
Los candidatos pasan por alto que el LLM en producción está sujeto a aprendizaje continuo: el modelo se entrena con diálogos etiquetados a diario, por lo que el efecto de la semana 1 no es comparable con el efecto de la semana 4. Es necesario utilizar modelos de Efectos de Tratamiento Variables en el Tiempo con evaluación de ventana deslizante o Series Temporales Estructurales Bayesianas (BSTS) para un ajuste dinámico de la línea base. Ignorar esto conduce a una subestimación del efecto a largo plazo, cuando el bot "aprende" de la especificidad del producto, o a una sobreestimación del efecto de novedad.