Evals en CI: el gate que pasa en el pull request y falla en producción

Un agente de soporte empezó a informar que la ventana de reembolso era de 30 días. La política decía 14. La causa fue una línea en el system prompt, y el build salió en verde, porque el pipeline revisa sintaxis, tipos y pruebas de software, y nada de eso lee lo que el modelo responde. El primero en ver la respuesta equivocada fue el cliente.

El caso abre una guía técnica publicada el 01/10/2026 por una plataforma de agregación de modelos, y explica por qué existe el gate de eval: convertir una línea de prompt en un evento que rompe el pull request. El mecanismo tiene cuatro huecos pequeños, todos de implementación, y cada uno entrega el mismo resultado por un camino distinto: un check verde que no midió nada.

El gate protege el prompt, no la ruta. Compara el modelo contra un conjunto fijo de casos, dentro de un ambiente que el equipo controla, y se detiene ahí. La ruta de producción, con el proveedor más barato de esa semana, queda fuera del gate hasta que alguien la mida.

Qué necesita tener un gate de evals en CI antes de existir

Un gate de evals en CI es un job que corre un conjunto fijo de casos en cada cambio relevante y falla el pull request cuando la tasa de aprobación cae por debajo de un umbral medido. Antes del workflow existen tres requisitos previos: el conjunto de casos, la regla de puntuación con el umbral y repetición suficiente para confiar en la tasa.

Caso de prueba con una entrada y una regla de aceptación, nada más: la regla puede ser una verificación de texto o una verificación de lo que el agente hizo con la herramienta; lo que importa es que la ejecute una máquina y que esté en el repositorio, no en la cabeza de quien revisa.

El conjunto vive en el mismo repositorio del prompt y solo cambia por pull request revisado. Editado directo en la rama principal, no protege nada: la siguiente persona con prisa ajusta el caso en lugar del agente. La guía arranca con tres casos y crece por una sola regla, un caso nuevo por cada falla en producción. Para el conjunto inicial, la recomendación de 20 a 50 tareas simples tomadas de fallas reales es de Anthropic. Empiece pequeño.

Lo que hay que medir ya está mapeado en evaluación de agentes más allá de la respuesta final y en métricas de evaluación de agentes en el piloto. La pregunta aquí es otra: qué hace el pipeline con ese conjunto.

Requisitos previos antes del primer hueco

Tres cosas tienen que existir antes de cualquier workflow: repositorio con CI en pull request, clave de API guardada como secret y permiso para editar la protección de la rama. Sin la tercera, el gate nace sin poder para bloquear un merge, y un gate que no bloquea es un informe caro.

• Repositorio con CI en pull request, para que el eval sea un job.
• Clave como secret, con un plan para el pull request de fork, que no recibe ningún secret.
• Permiso en las reglas de protección de la rama, porque es ahí donde el check se vuelve obligatorio.

El tercer punto es el que más desaparece de la lista, porque suele estar en manos de otra persona. Sin él, nada es obligatorio. Quien escribe el workflow rara vez administra la protección de la rama, y el resultado es un gate que corre bonito y no bloquea nada.

El runtime del agente bajo prueba solo necesita ser invocable desde un job. Nexforce Code corre headless en automatización y CI; el harness de evaluación es el script del equipo.

Hueco 1: el filtro y el required check deciden si existe gate

El disparador tiene que ser un filtro de rutas a nivel del job, y el job tiene que ser un required status check en la protección de la rama. Equivocar el primero produce un check verde sin eval; equivocar el segundo produce un eval rojo que el botón de merge ignora.

Un filtro a nivel del workflow parece económico y es el peor arreglo: cuando la ruta no coincide, GitHub no crea ningún job, el required check queda pendiente y el pull request nunca queda listo para el merge. El eval que no corre se convierte en un candado permanente.

A nivel del job el comportamiento engaña al revés. Un job que no coincide con la condición no se ejecuta, y el GitHub lo reporta como check aprobado. El merge pasa, el eval no existió, y el verde documenta apenas que la condición era falsa.

La lista de rutas tiene que incluir el propio workflow y el propio script de eval. Sin ellos, un pull request que rompe la lógica de puntuación no dispara el eval, entra sin prueba, y la regresión siguiente se le atribuye al modelo.

Falta el required check, que es donde la mayoría se detiene. Sin marcar el job como obligatorio, un eval rojo aparece como X y el pull request sigue siendo mergeable, porque GitHub informa y no bloquea. Peor: si el job que decide si algo relevante cambió falla, GitHub salta el job de eval, y un job saltado cuenta como aprobado. Por eso los dos checks son obligatorios.

Concurrency con cancel-in-progress cancela la ejecución anterior cuando alguien vuelve a hacer push en la misma rama, y sin eso cada push paga un eval que nadie lee. El pull request de fork no recibe secrets y falla por clave ausente: correr el eval también en el push a la rama principal cubre el hueco.

Hueco 2: sin proveedor fijado, lo que se mide es el enrutador

El mismo slug de modelo puede ser servido por proveedores distintos en dos ejecuciones, y la diferencia aparece en el informe como regresión de prompt. Fijar un proveedor único en la llamada del eval, sin fallback, mantiene la ruta constante para que la variable medida sea el prompt.

El slug identifica el modelo, no el lugar desde donde respondió. Dos endpoints con la misma etiqueta devuelven respuestas distintas, y el informe, que solo conoce la etiqueta, registra la diferencia como si el prompt hubiera empeorado.

El resultado es el peor tipo de falso positivo: bloquea un pull request correcto y le enseña al equipo a desconfiar del gate.

En la llamada del eval, un proveedor. Y ningún fallback. En la API de la plataforma que publicó la guía, eso son un orden de proveedores y una bandera que apaga la sustitución (provider.order y allow_fallbacks); campos de esa API, no estándar de mercado, y en otro gateway el equivalente ata la llamada a un solo endpoint.

Fijar el proveedor cierra el endpoint y deja la revisión abierta. El slug tampoco identifica qué build del modelo respondió, así que un build nuevo servido bajo el mismo slug y el mismo proveedor reproduce exactamente el falso positivo de este hueco, con la fijación ya en su lugar y ningún campo del informe para registrar la diferencia. Es un límite del instrumento, no un detalle de configuración.

El límite queda escrito: fijar el proveedor dentro del eval es control de medición, no cobertura de ruta. Mantiene la ruta constante para que la diferencia medida sea del prompt, y la ruta de producción sigue fuera del gate hasta que alguien mida la ruta, con otro conjunto de casos. Evaluación de endpoint y política de enrutamiento trata ese lado: ahí, el umbral es el corte que decide a dónde va el request; aquí, el umbral decide si el pull request entra.

En producción, la ruta es una política: elección de modelo por costo, latencia y contexto, failover, techo de gasto por clave y traza por llamada. Nexforce Router es donde esa política corre en los agentes que la empresa pone en operación, y por eso el eval no puede confundir la política con el prompt. Quien elige modelo mide otra cosa, en tres evaluaciones agénticas para elegir modelo.

Quien corre agentes en producción cambia de proveedor por precio en el mismo mes en que toca el prompt, y el eval acusa regresión de prompt cuando lo que cambió fue la ruta.

Hueco 3: el umbral elegido a ojo bloquea el ruido

Elegir el umbral a ojo es el error más común, porque el número parece razonable: un umbral alto suena a exigencia seria. El mismo conjunto, corrido seis veces sin tocar nada, no devuelve la misma tasa en todas las rondas. El piso es la peor de ellas.

Un piso bajo tiene un reflejo equivocado y un orden correcto. El reflejo es bajar el umbral. El orden empieza lejos del número: la aserción, después los parámetros de determinismo y por último el muestreo. El umbral es lo último que se toca.

La primera verificación es la propia regla de aceptación. Una aserción que exige la palabra exacta reprueba cada vez que el modelo escribe el sinónimo, y el prompt no tiene cómo impedirlo. La tasa cae, el piso cae, y el número del informe mide la fragilidad de la prueba, no la calidad de la respuesta. Bajar el umbral antes de mirar la aserción convierte esa fragilidad en política permanente: el caso que reprobaba por una aserción mala pasa a no poder reprobar nada, porque el umbral se calibró para acomodarlo.

La segunda es el determinismo. temperature y seed solo ayudan en modelos que declaran los dos en supported_parameters; enviarlos sin require_parameters: true hace que el proveedor reciba e ignore los valores, lo que es peor que no enviarlos, porque produce sensación de control. Hay modelos que no declaran ninguno de los dos.

La tercera es el muestreo, y el camino que funciona en cualquier modelo es repetir la ejecución con voto por mayoría. Cuesta más y no depende del proveedor. Lo que la mayoría compra es estabilidad contra el ruido; lo que entrega a cambio es sensibilidad. Un caso que falla en minoría de las muestras cuenta como aprobado, así que un agente que empeoró y empezó a fallar en minoría de ellas sigue en verde, y solo aparece cuando la falla se vuelve mayoría. La regresión intermitente, la más difícil de ver en producción, queda fuera del informe por construcción.

Con las tres verificaciones hechas, queda medir: seis rondas en la misma rama sin cambios, y el umbral no puede quedar por encima del piso.

Con tres casos y uno de ellos inestable en seis ejecuciones, el piso es 0,67, y un umbral de 0,9 bloquea un pull request sin ninguna regresión. El problema no es el 0,9, es el tamaño. Con tres casos la tasa solo asume cuatro valores, y un umbral en el piso tiene resolución de un caso: reprueba cuando se rompen dos casos, no cuando se rompe uno. Un caso puede empeorar entero sin que el pull request se detenga. La resolución del gate es el inverso del tamaño del conjunto, y es ella la que decide qué caída alcanza a ver el pull request.

La conclusión es hacer crecer el conjunto, no convivir con el umbral flojo. La guía llega a la misma conclusión y apunta a la dirección de 20 casos o más; la franja de 20 a 50 tareas simples tomadas de fallas reales, para el conjunto inicial, es la recomendación de Anthropic citada al comienzo. Conjunto pequeño con umbral rebajado es la definición de gate de adorno.

Falta separar dos fracasos, y el script ya los separa, salvo que alguien los unifique en un solo código. El primer código cubre "el agente empeoró"; el segundo, "no se pudo medir".

Si los dos pintan de rojo igual, el equipo aprende a ignorar el rojo, y un gate ignorado cuesta más caro que ninguno.

Hueco 4: la prueba que se puede aflojar no es una prueba

CODEOWNERS por sí solo pide revisión, no bloquea el merge. Sin marcar la opción que exige aprobación del dueño del código, el camino más barato para destrabar un pull request rojo es editar el caso que falló, y el gate pasa a proteger el merge en lugar de la producción.

Considere el incentivo antes de la herramienta. La persona tiene un pull request rojo a las seis de la tarde, el caso que falló apunta a una respuesta que ella juzga aceptable, y hay una línea en el conjunto que se ajusta en treinta segundos. Ajustar el prompt lleva una hora y toca algo que ella no escribió.

En ese arreglo, el conjunto de pruebas pierde. No por mala fe, por diseño.

La defensa es tratar el conjunto como código de producción. La protección de la rama es la que exige la aprobación del dueño del archivo; sin esa marca, la solicitud de revisión es consultiva. Con ella, aflojar el caso exige la firma de quien entiende que esa línea es el contrato del agente con el cliente. La edición queda en el diff, y quien revisa ve la expectativa cambiar de 14 días a 30.

Cómo saber que el gate está funcionando

En el primer cambio de prompt después de instalar el gate, abra el log de la ejecución y confirme que el eval corrió. Un patrón de ruta equivocado deja el job en verde sin ejecutar ningún caso, y la prueba de que el gate existe está en el log, no en el check.

El check verde es la evidencia más débil del sistema. Una prueba de diez segundos que no llamó a la API y una prueba de cuatro minutos que corrió el conjunto entero producen el mismo símbolo en pantalla.

Tres verificaciones lo resuelven. Leer el log y encontrar la lista de casos con la tasa de aprobación; si el log solo tiene el mensaje de éxito, el eval no corrió. Romper un caso a propósito y ver el pull request ponerse rojo. Y confirmar el job de eval como pendiente durante la ejecución, porque un check que nunca queda pendiente no es obligatorio.

Vale repetir la prueba en cada cambio del workflow. El filtro de rutas es el tipo de configuración que alguien ajusta un viernes para destrabar un merge, y el cambio de prompt de la semana siguiente ya no dispara nada.

Cuánto cuesta correr esto

El costo es el número de casos multiplicado por las muestras por caso y por la frecuencia de pull requests que tocan el prompt. El script imprime el costo de cada ejecución a partir del campo usage.cost, que es un campo de la API de la plataforma que publicó la guía; en otro gateway no existe, y el costo sale de tokens multiplicados por precio. Es ese número el que decide si el gate cabe en el presupuesto. Sin él, queda la fe.

La cuenta crece de forma lineal con las muestras, y quien aumenta muestras para estabilizar la medición multiplica el costo por la misma constante; la calibración del umbral aparece en la factura, no en el reloj del pipeline.

Un script con verificación de umbral basta por sí solo. Las plataformas de eval agregan informe, historial de ejecuciones o métricas listas sobre el mismo patrón de código de salida, y las citadas por la guía son DeepEval, Braintrust, Arize y Galileo. El cambio es una decisión de operación, no de calidad.

Qué hacer el lunes

Cinco pasos, en este orden, cada uno dejando un artefacto en el repositorio: el conjunto de pruebas, el workflow con filtro en el job y required check, el archivo de dueños, el umbral con las seis ejecuciones registradas y el costo por ejecución impreso en el log.

1. Escriba tres casos a partir de fallas reales del agente y súbalos en un commit en el mismo repositorio del prompt. Artefacto: el conjunto versionado.
2. Cree el job de eval con filtro de rutas a nivel del job, incluyendo el propio workflow y el propio script en la lista. Artefacto: el workflow.
3. Marque el job de filtro y el job de eval como required status checks en la protección de la rama. Artefacto: la regla de protección, registrada en el runbook.
4. Corra el conjunto seis veces contra la rama principal sin cambiar nada, registre la peor tasa y configure el umbral por debajo de ella. Un piso bajo se corrige primero en la aserción y en el muestreo, y el conjunto crece antes de que el umbral baje. Artefacto: el número documentado, con fecha.
5. Active el reporte de costo en el log y revise el valor en el primer mes. Artefacto: el costo por ejecución.

El paso que los equipos se saltan es el cuarto, porque no produce nada visible y entrega un número que nadie quiere descubrir bajo. Nada de la lista exige comprar algo, y los artefactos quedan en el repositorio o en el runbook. El checklist de plataforma de agentes en producción cubre lo que viene después: el gate es la primera capa de medición.

Preguntas frecuentes

¿Un eval en CI reemplaza a la prueba unitaria? No. La prueba unitaria verifica el código que se escribió; el eval verifica el comportamiento del modelo frente a una entrada. Los dos conviven en el mismo pipeline y fallan por motivos distintos: uno apunta a una función rota, el otro a una respuesta que cambió. El gate cubre la capa que la prueba unitaria no alcanza: no verifica directamente el código de orquestación; prueba lo que el agente responde y qué herramientas llamó.

¿Hace falta una plataforma de eval para empezar? No. Un script que corre los casos, aplica la regla de puntuación y sale con un código distinto de cero por debajo del umbral resuelve el problema del gate. Las plataformas agregan informe e historial sobre el mismo patrón de salida, y el cambio se justifica cuando el equipo necesita comparar ejecuciones a lo largo del tiempo, no antes. El script resuelve primero.

¿Cómo evitar que el gate vuelva lento el pull request? Filtro de rutas a nivel del job, para que el eval corra solo cuando cambian el prompt, el conjunto de pruebas o el propio gate, y concurrency con cancel-in-progress para cancelar la ejecución anterior cuando alguien vuelve a hacer push en la misma rama. El muestreo repetido cuesta tiempo, y la calibración define cuántas muestras hacen falta para no bloquear el ruido. Un gate lento es un gate que el equipo aprende a esquivar.

El eval falló y el agente parece igual. ¿Qué hacer? Primero mire el código de salida: si es el código de eval que no corrió, el problema es la clave, el proveedor o un caso roto, no la calidad. Si es el código de regresión, corra el conjunto en la rama principal sin cambiar nada y compare con el piso registrado. Diferencia dentro del ruido es umbral alto, no un agente peor. Compare los dos números antes de tocar el prompt.

Referencias y Lectura Complementaria

• Guía técnica sobre gate de pull request en evals de LLM, publicada el 01/10/2026 por una plataforma de agregación de modelos (lectura el 21/10/2026).
• Recomendación de 20 a 50 tareas simples en conjuntos iniciales: Anthropic, Demystifying evals for AI agents, citada por la guía (lectura el 21/10/2026).
• Comportamiento de check pendiente y de job saltado: GitHub Docs, Skipping workflow runs y About protected branches (lectura el 21/10/2026).
• Evaluación de agentes más allá de la respuesta final
• Métricas de evaluación de agentes en el piloto
• Evaluación de endpoint y política de enrutamiento
• Tres evaluaciones agénticas para elegir modelo
• Checklist de plataforma de agentes en producción

El hueco que queda después del gate

El argumento aquí no es que el gate no sirve. Sirve, y sirve barato, siempre que sea un instrumento calibrado, con dueño y límite de error conocidos.

Lo que no hace es mirar la ruta. La ruta queda fuera del informe. Un agente en producción responde por una política que cambia de semana en semana, por precio, por latencia o por indisponibilidad del proveedor, y ninguno de esos cambios pasa por un pull request.

La próxima medición, entonces, no es del prompt. Es de la ruta: qué endpoint respondió, con qué latencia, a qué costo, y si la respuesta que recibió el cliente vino del modelo que la política prometía. Mientras eso no esté en el mismo informe, el gate sigue en verde y la producción sigue siendo el lugar donde aparece la verdad.