Ocho meses dentro de una cola de fusión (merge queue) de GitHub Actions te enseñan algo que las matrices de comparación de características nunca harán. Un framework puede ofrecer cincuenta métricas, dashboards espectaculares y citas de laboratorios de investigación respetados. Pero si bloquea tu despliegue porque una puntuación de "vibe check" varió de 0,72 a 0,68 con un código idéntico, es peor que inútil. Se convierte en una amenaza activa para tu velocidad de entrega.

Ese es el filtro que la mayoría de los resúmenes de evaluación de LLM pasan por alto. Cuentan capacidades. Rara vez hacen la única pregunta que importa en una cola de fusión: ¿pasa y falla esta comprobación exactamente de la misma manera cada vez que se ejecuta?

Aprendí esto haciendo el trabajo incómodo. Integré seis frameworks de evaluación de LLM de código abierto en un pipeline de CI real. Funcionaron contra pull requests de producción en vivo durante ocho meses. Dos ganaron el derecho de permanecer como guardianes (gatekeepers). El resto fueron degradados a dashboards de asesoramiento, movidos a trabajos nocturnos o eliminados por completo. La lección fue dura y costosa: la estructura determinista vence a la calidad probabilística cuando estás custodiando la rama principal.

El verdadero trabajo de una puerta de fusión (Merge Gate)

Una puerta de CI no es un entorno de investigación. Es un portero. Su único propósito es mirar un cambio específico y responder sí o no. Sí, este PR puede unirse a la rama principal. No, no puede. Esa respuesta debe llegar en segundos, costar céntimos y nunca cambiar retroactivamente. Si vuelves a ejecutar el mismo pipeline contra el mismo commit en un martes tranquilo y en un viernes frenético, el resultado debe ser idéntico.

Aquí es donde la mayoría de los frameworks de evaluación de LLM tropiezan. Están construidos por científicos de datos para científicos de datos. Optimizan para el conocimiento, la exploración y la puntuación matizada. Una cola de fusión optimiza para decisiones binarias, velocidad y cero inestabilidad (flakiness). Esos dos objetivos solo se solapan parcialmente.

Por qué el modelo LLM-as-Judge rompe la cola

Las herramientas que fallaron en mi prueba compartían un único pecado de diseño: dependían demasiado de las llamadas de LLM-as-judge como mecanismo de control principal.

Un prompt de LLM-as-judge pide a un modelo que puntúe una salida en una escala del uno al diez, que elija la mejor de dos respuestas o que califique la corrección factual. El enfoque es potente para entender tendencias de calidad. Es veneno para una comprobación de CI que bloquea procesos. La misma entrada puede producir puntuaciones diferentes en días distintos porque la temperatura, el versionado del modelo y el formato del prompt introducen ruido. Cuando esa puntuación está ligada a un umbral estricto y a un código de salida rígido, tu cola se bloquea por fantasmas.

Los fallos caen en cascada rápidamente. Una comprobación no determinista crea atascos en la cola. Los ingenieros aprenden a reintentar hasta que el número sale favorablemente, lo que entrena al equipo para ignorar los builds en rojo. Los costes de tokens se acumulan porque cada reintento consume más créditos de API. Lo peor de todo es que la señal pierde su sentido. Un build en rojo debería significar "has introducido un error". Si significa "el modelo juez se ha despertado exigente hoy", la confianza se erosiona.

Qué hacen de forma diferente los supervivientes

Promptfoo y DeepEval sobrevivieron porque tratan las comprobaciones deterministas como ciudadanos de primera clase y las puntuaciones de los jueces LLM como señales secundarias no bloqueantes. Entienden que una puerta de enlace necesita un código de salida, no un número de punto flotante con opinión propia.

Promptfoo, lanzado bajo la licencia MIT, está diseñado para la línea de comandos. Ejecuta aserciones como coincidencias de regex, validación de esquemas JSON, comprobaciones de contenido y comparaciones exactas de cadenas. No son sofisticadas. Son comandos grep y jq glorificados. Esa es precisamente la razón por la que funcionan en CI. Un regex coincide o no coincide. Un esquema JSON valida o lanza un error. Promptfoo devuelve códigos de salida estándar de Unix, por lo que GitHub Actions entiende nativamente cuándo detener una fusión. Es independiente del lenguaje porque opera como una herramienta CLI. No necesitas instalar un ecosistema de Python dentro de un repositorio de servicios de Node.js solo para validar salidas.

DeepEval, con licencia Apache 2.0, es la opción para los equipos de Python. Se integra como pytest. Escribes las pruebas con una sintaxis familiar y un fallo bloquea la suite de forma natural. DeepEval ofrece un catálogo enorme de métricas, pero el detalle crítico es que debes usarlas con cuidado. Apóyate en métricas deterministas o heurísticas para las puertas de enlace. Si utilizas G-Eval u otros evaluadores basados en jueces, envuélvelos en generadores de informes no bloqueantes en lugar de aserciones estrictas. Cuando se usa de esta manera, DeepEval te ofrece la ergonomía de un framework de pruebas sin la inestabilidad de un cuaderno de investigación.

Dónde encajan los otros cuatro

Los cuatro frameworks que no sobrevivieron como puertas de enlace siguen teniendo valor. Simplemente pertenecen a otro lugar de tu cadena de herramientas.

Future AGI (Apache 2.0) incluye más de cincuenta métricas y está dirigido a equipos que desarrollan SDKs personalizados. Las métricas son exhaustivas. El problema es que la herramienta espera que escribas tu propio entorno de ejecución (harness) para dirigirla en una cola de CI. En un contexto de investigación, es un intercambio razonable. En una cola de fusión (merge queue), cada capa de conexión personalizada es una nueva fuente de inestabilidad. Es un motor de evaluación capaz, pero no un guardián (gatekeeper) listo para usar.

RAGAS (Apache 2.0) destaca en la medición de la calidad de la generación aumentada por recuperación (RAG). Sus métricas de fidelidad (faithfulness) y relevancia de la respuesta son realmente útiles para entender cómo se desempeña una base de conocimientos a lo largo del tiempo. Desafortunadamente, esas métricas dependen en gran medida de jueces basados en LLM. Son excelentes para un proceso de calidad nocturno que publique tendencias en Slack. Son malos porteros para un pull request. Mueve RAGAS a tu canal de análisis programado, no a tus bloqueadores de fusión.

Arize Phoenix utiliza la Elastic License 2.0 y se sitúa en una intersección completamente distinta. Conecta el rastreo distribuido (distributed tracing) con la evaluación, proporcionándote observabilidad sobre por qué un modelo se comportó de cierta manera. Necesitas esto cuando estás depurando un incidente en producción o rastreando una alucinación hasta un fragmento de recuperación erróneo. No quieres que una herramienta de rastreo decida si la rama de una funcionalidad de un desarrollador junior puede desplegarse. Su arquitectura está diseñada para obtener información (insight), no para actuar como puertas binarias.

MLflow Evaluate (Apache 2.0) hereda su linaje del seguimiento de experimentos. Es pesado. Incluirlo en una imagen de CI ligera añade tiempo de inicio y dependencias que ralentizan cada tarea. Si es absolutamente necesario usarlo dentro de un pipeline, limítate a sus métricas heurísticas para comprobaciones estructurales. Incluso entonces, estarás luchando contra el diseño fundamental del framework. MLflow quiere registrar ejecuciones y comparar experimentos a lo largo de semanas. Una cola de fusión quiere un veredicto en menos de un minuto.

Reglas prácticas para el control (Gating)

Si no te llevas nada más de este experimento, quédate con estas tres reglas.

Primero, controla la estructura, no la "vibra". Puedes imponer que una salida sea un JSON válido. Puedes imponer que contenga las claves requeridas. Puedes imponer que una etiqueta de clasificación pertenezca a un enum permitido. Estas comprobaciones son rápidas, económicas y deterministas. No puedes imponer de forma fiable que un resumen sea "amigable" o que una reescritura sea "creativa". Esas cualidades pertenecen a la revisión humana o a la evaluación por lotes periódica, no a los controles automatizados.

Segundo, si una puntuación cambia con una entrada sin cambios, degrádala inmediatamente. Ejecuta tu suite de evaluación dos veces contra el mismo artefacto exacto. Si alguna métrica cambia de "aprobado" a "fallido", ha perdido su derecho a bloquear una fusión. Promuévela a un panel de asesoramiento donde la varianza sea esperada y tolerable.

Tercero, respeta el código de salida (exit code). Un informe HTML bonito con un banner rojo no detiene una fusión. Un código de salida distinto de cero, sí. Tu herramienta de evaluación debe hablar el lenguaje nativo de tu plataforma de CI. La salida estándar (standard out) es para humanos. Los códigos de salida son para máquinas.

Conclusión

Aún estamos en las primeras etapas de descubrir cómo probar aplicaciones impulsadas por LLM. La tentación es tratar la evaluación como una rúbrica de calificación humana: matizada, contextual y ligeramente subjetiva. Eso funciona en un artículo de investigación. Colapsa en una cola de fusión.

Tras ocho meses de tráfico en producción, mi pipeline ahora ejecuta Promptfoo para aserciones estructurales y de esquema en todos los servicios, y DeepEval para comprobaciones de comportamiento en el lado de Python que se mapean claramente a condiciones de aprobado/fallido. Todo lo demás se reporta a paneles nocturnos. La cola es estable. La señal es limpia. El equipo vuelve a confiar en una compilación roja.

No necesitas más métricas en tu punto de control. Necesitas menos métricas que digan la verdad cada vez.

Basado en las pruebas y el artículo originales compartidos en Dev.to. Para más discusiones sobre la construcción de sistemas de IA fiables, únete a la comunidad de GyaanSetu en Telegram.