Resumen Técnico: Pipeline de Evaluación de GenAI para Agentes Conversacionales de Retail

1. Formulación del Problema

El artículo aborda la brecha crítica en la evaluación de agentes conversacionales (chatbots) de retail a escala empresarial. Las métricas tradicionales como BLEU, ROUGE y METEOR dependen de la superposición léxica y no logran capturar las dimensiones pragmáticas esenciales en el retail, tales como la alineación de la intención, la veracidad, el tono, la utilidad y la adecuación cultural en escenarios de traducción. Si bien la evaluación humana es fiable, resulta costosa y no escalable para entornos de producción de alto volumen que generan decenas de miles de interacciones diarias. Por el contrario, los enfoques existentes de "LLM-as-a-judge" (LLM como juez) a menudo carecen de la gobernanza, la reproducibilidad y la fiabilidad operativa requeridas para el despliegue en producción, específicamente en lo que respecta a la consistencia del esquema, la auditabilidad y la gestión de costos.

El desafío central es operacionalizar un marco de evaluación multidimensional que sea:

• Escalable: Capaz de procesar ~50,000 registros diarios (más de 2 millones en total).
• Gobernado: Que imponga un esquema, versionado y trazabilidad estrictos.
• Eficiente: Minimizando la computación redundante mediante la reevaluación selectiva.
• Multidimensional: Soporte tanto para tareas generales de retail (intención, utilidad) como para tareas específicas de traducción (ajuste cultural, relevancia de venta).

2. Metodología: El Pipeline de Evaluación de GenAI

Los autores proponen GenAI Evaluation, un pipeline impulsado por configuración y gobernado, construido sobre Kubeflow Pipelines. El sistema ingiere logs de producción de chatbots desde BigQuery y los procesa a través de las siguientes etapas:

Preprocesamiento de Datos y Fragmentación (Sharding)

• Normalización: Los logs crudos se estandarizan (por ejemplo, convirtiendo context_name a context_id, convirtiendo tipos de datos para timestamps y booleanos).
• Filtrado: Se eliminan los registros inválidos (prompts/respuestas vacíos, IDs faltantes, timestamps malformados) antes de la evaluación para asegurar que los fallos reflejen la calidad del modelo y no defectos en los datos.
• Fragmentación (Sharding): El conjunto de datos se divide en fragmentos aproximadamente equilibrados (por ejemplo, $N=4$) mediante segmentación round-robin y se serializa a Parquet. Esto permite el procesamiento paralelo y aisla los fallos a fragmentos individuales.
• Aumento de Metadatos: Los registros se enriquecen con identificadores de fila globales estables, IDs de fragmento, metadatos del trabajador y hashes de configuración para soportar la trazabilidad y la deduplicación.

Ejecución Asíncrona de LLM-as-a-Judge

• Arquitectura: El pipeline utiliza una ejecución asíncrona por mini-batches con concurrencia limitada (gestionada mediante semáforos) para evitar la sobrecarga de red.
• Especificidad de la Tarea: Soporta dos flujos de trabajo distintos:
  1. Retail General: Evalúa la utilidad, claridad, coherencia, concisión, adherencia a instrucciones, alineación de tono y veracidad.
  2. Traducción: Evalúa la precisión semántica, adecuación cultural, legibilidad, relevancia de venta y ajuste de plantilla.
• Configuración: Las rúbricas específicas de la tarea, los prompts (plantillas Jinja2) y los esquemas de salida se cargan desde el almacenamiento en la nube como configuraciones YAML, garantizando la reproducibilidad versionada.

Reevaluación Selectiva y Gobernanza

• Reevaluación Selectiva: En lugar de volver a ejecutar todo el conjunto de datos ante un fallo, el sistema identifica registros incompletos, malformados o con esquemas inválidos. Regenera solo estas filas específicas utilizando identificadores de fila estables y las integra de nuevo, reduciendo significativamente el costo y la latencia.
• Gobernanza de Esquema: Todas las salidas son verificadas por tipo y validadas en rango contra un esquema bloqueado. Las violaciones activan registros de auditoría.
• Trazabilidad: Cada salida incluye metadatos de procedencia (versión del modelo, hash de configuración, ID del trabajador, índice del fragmento). Los resultados se transmiten incrementalmente a BigQuery utilizando escritores con esquema bloqueado para evitar la deriva de la salida.

3. Contribuciones Clave

El artículo detalla cinco contribuciones principales:

1. Stack de Evaluación Gobernado: Un pipeline escalable y dirigido por configuración para la evaluación de chatbots de retail a gran escala que impone consistencia de esquema y auditabilidad.
2. Mecanismo de Reevaluación Selectiva: Un proceso de regeneración dirigida para registros inválidos o incompletos que mejora la completitud evitando la computación redundante.
3. Soporte de Flujo de Trabajo Dual: Esquemas y flujos de trabajo separados para la evaluación de no-traducción (intención/calidad general) y de traducción específica (relevancia cultural/de venta).
4. Auditabilidad de Extremo a Extremo: Implementación de streaming determinista en Parquet, logs de validación, configuraciones versionadas y procedencia por registro para asegurar la reproducibilidad.
5. Benchmarking de Modelos: Un análisis comparativo de modelos evaluadores de código abierto para analizar las compensaciones entre calidad y rendimiento (throughput) en entornos de alto volumen de retail.

4. Resultados Experimentales

El marco fue evaluado en más de 2 millones de registros de chatbots de retail (aprox. 50,000 diarios), con un 95% de ejemplos de no-traducción y un 5% de traducción. La validación se realizó contra un subconjunto de 12,980 registros etiquetados por humanos mediante muestreo aleatorio estratificado, utilizando cuatro anotadores ciegos.

Métricas de Rendimiento

• Clasificación: El pipeline logró un F1 score macro de 0.93 a través de 14 intenciones, 156 sub-intenciones, 18 valores de dominio mayor y 129 valores de sub-dominio.
• Traducción: Alcanzó un 89% de precisión de aceptabilidad humana para los outputs de traducción.
• Puntuaciones de Calidad: Dimensiones como utilidad, veracidad y claridad se registraron como puntuaciones numéricas (escala 1–5).

Benchmarking de Modelos

Se compararon cinco modelos de código abierto (Llama 4B/8B/70B, Qwen3-14B, OSS-120B) bajo condiciones idénticas (cuantización de 4 bits, NVIDIA H100, tamaño de batch 512).

• Compensaciones (Trade-offs): Los modelos más pequeños (ej. Llama 4B) ofrecieron mayor rendimiento pero menores puntuaciones en tareas matizadas (F1 0.82). Los modelos más grandes (Llama 70B) lograron la mayor alineación con las etiquetas humanas (F1 0.93) pero requirieron más recursos.
• Estrategia: Los autores sugieren un enfoque por niveles donde los modelos más pequeños manejan el monitoreo diario y los modelos más grandes se reservan para casos de alto riesgo o muestras seleccionadas para auditoría.

5. Significado y Reivindicaciones

El artículo afirma que la evaluación basada en LLM con esquemas gobernados puede proporcionar señales de calidad escalables y fiables para flujos de trabajo de retail empresariales. Su importancia radica en cerrar la brecha entre las capacidades teóricas de "LLM-as-a-judge" y los requisitos prácticos de los entornos de producción (gobernanza, costo y auditabilidad).

Los autores enfatizan que:

• La evaluación automatizada es una señal diagnóstica, no un juicio final, y debe acompañarse de supervisión humana para casos sensibles.
• La reevaluación selectiva es un patrón de ingeniería crítico para mantener la completitud de los datos sin incurrir en el costo de ejecuciones completas.
• Las características de gobernanza (bloqueo de esquema, configuraciones versionadas, streaming determinista) son esenciales para la reproducibilidad y la confianza en entornos empresariales.

6. Limitaciones

Los autores reconocen modestamente varias restricciones:

• Diseño de Validación: Cada registro etiquetado por humanos fue revisado por un solo anotador, lo que significa que las métricas reportadas reflejan el acuerdo con las etiquetas disponibles más que un consenso humano plenamente adjudicado (no se computaron estadísticas de acuerdo entre anotadores como el alfa de Krippendorff).
• Generalización de Dominio: Los resultados son específicos para datos de chatbots de retail y pueden no generalizarse completamente a dominios con diferentes perfiles de riesgo (ej. salud, legal).
• Alcance: El marco se centra actualmente en la evaluación de nivel de turno basada en texto y aún no cubre entradas multimodales o conversaciones interactivas de largo horizonte.
• Reproducibilidad: La reproducibilidad a largo plazo sigue siendo un desafío en entornos dinámicos donde los pesos de los modelos o la infraestructura pueden cambiar.

Se propone como trabajo futuro la inclusión de evaluación multimodal, puntuación en tiempo real online y mediciones de fiabilidad más sólidas (ej. curvas de calibración, intervalos de confianza de bootstrap).