El Eval Gate Mínimo Viable

Por qué un gate, no un dashboard

La mayoría de los equipos que lanzan una función de LLM tienen un dashboard en algún lugar — un notebook, una hoja de cálculo con ejemplos de salidas, un canal de Slack donde alguien pega “esto se ve mejor ahora.” Nada de eso bloquea algo. Un ajuste de prompt, un salto de versión del modelo, un cambio en el retrieval: todos se lanzan porque parecen estar bien, y la regresión que causaron aparece tres semanas después en una queja de un cliente que nadie puede rastrear hasta el diff.

Un gate se diferencia de un dashboard en algo que importa: un gate puede decir que no. Vive en tu pipeline de pull request, se ejecuta en cada cambio que toca la IA, y cuando el puntaje de calidad cae por debajo de un umbral que acordaste, el merge queda en rojo. Esa es toda la idea. No necesitas una plataforma, un contrato con un proveedor, ni un equipo de etiquetado de datos para llegar ahí. Necesitas treinta ejemplos, una regla de puntaje y un job de CI.

Las tres partes

Reduce un sistema de eval a su núcleo irreducible y obtienes tres cosas. Todo lo demás — ejecutores de seguridad, métricas de retrieval de RAG, presupuestos de costo, umbrales que solo suben — es elaboración sobre estas tres.

1. El conjunto dorado

Una colección pequeña de entradas reales emparejadas con lo que se ve una buena respuesta. Treinta a cincuenta es suficiente para empezar — sacadas de tus logs reales y tickets de soporte, no inventadas en tu escritorio. Este conjunto es tu definición de “funciona,” así que tiene que reflejar los casos que realmente te importan: el camino común, los casos límite que muerden, y los que un cliente ya reclamó. (Hay una guía completa sobre cómo construir esto bien; la versión corta es: cosecha, no imagines.)

2. El juez

Algo que puntúa cada salida. Para salidas estructuradas, eso son aserciones determinísticas — coincidencia exacta, regex, validación de esquema JSON, una subcadena requerida. Para texto abierto, es un LLM-as-judge: un segundo modelo al que se le da la entrada, la respuesta y una rúbrica, y se le pide puntuar fidelidad, relevancia o seguridad en una escala fija. El truco que hace confiable a un juez es una rúbrica escrita con criterios concretos de aprobado/reprobado — no “califica esto de 1 a 10,” sino “puntúa 0 si la respuesta afirma un hecho no respaldado por el contexto provisto.”

3. El gate

Un paso de CI que hace pasar el conjunto dorado por el juez, agrega los puntajes y compara el resultado con un umbral. Por encima del umbral: exit 0, el merge se permite. Por debajo: exit distinto de cero, el check queda en rojo, el merge se bloquea. Se ejecuta en cada pull request que toca un prompt, una config de modelo, un índice de retrieval, o el código alrededor de ellos.

La construcción de una tarde

Aquí está la secuencia honesta. Ninguno de estos pasos es investigación; son ensamblaje.

• Hora 1 — cosecha. Saca 30–50 entradas reales de tus logs de producción o tu cola de soporte. Para cada una, escribe (o acuerda) qué contiene una buena respuesta. Guárdalo como un archivo plano — JSONL o YAML — en el repo, junto al código que prueba.
• Hora 2 — el juez. Escribe la rúbrica. Para cada salida, decide si es una verificación determinística (aserción) o una abierta (LLM-as-judge). Mantén la rúbrica también en control de versiones — cambia a medida que cambia tu definición de bueno, y quieres ese historial.
• Hora 3 — el ejecutor. Un script que hace pasar el conjunto dorado por tu función en un loop, puntúa cada salida y imprime un resumen. Ejecutores open-source como Promptfoo o DeepEval te dan este loop, tipos de aserción y un harness de LLM-judge listos para usar, así que escribes config, no plomería.
• Hora 4 — el gate. Conecta el ejecutor a CI como un check obligatorio en los pull requests. Haz fallar el job cuando el puntaje agregado esté por debajo del umbral. Esa es la línea que convierte un script en un gate.

El paso de CI es más pequeño de lo que la gente espera. Conceptualmente:

# .github/workflows/eval-gate.yml (shape, not gospel)
on: pull_request
jobs:
  eval-gate:
    steps:
      - run: npm ci
      - run: npx promptfoo eval -c eval/gate.yaml --output out.json
      - run: node eval/check-floor.js out.json --floor 0.85
        # check-floor.js exits 1 if the aggregate pass-rate < 0.85

Marca el job como required status check en tu rama protegida, y la plataforma hace el cumplimiento por ti: un gate en rojo significa que el botón de merge está deshabilitado. Ningún humano tiene que acordarse de revisar.

Fijar el umbral sin mentirte a ti mismo

El primer umbral es fácil de equivocar en dos direcciones opuestas. Ponlo demasiado alto y cada PR honesto queda en rojo, así que el equipo aprende a saltarse el check — un gate que todos evitan es peor que ningún gate, porque blanquea cambios malos con una insignia verde. Ponlo demasiado bajo y nada falla nunca, así que construiste un dashboard con pasos extra.

La jugada que funciona: corre la suite sobre tu main actual para obtener el puntaje base de hoy, y luego fija el umbral en ese punto base. Ahora el único trabajo del gate el primer día es “no empeorar de lo que ya estamos.” Esa es una afirmación que puedes defender y una barra que cualquier mejora real supera. Con el tiempo lo vas subiendo: cuando un cambio eleva el puntaje de forma legítima y se sostiene, subes el umbral para igualarlo. El umbral solo sube, y sube con evidencia.

Una disciplina más: cuando el gate bloquea un PR, la salida del fallo tiene que ser legible para la persona que escribió el diff — qué trazas fallaron, qué dijo el juez, y el delta respecto al punto base. Un gate que solo dice “puntaje 0.81, umbral 0.85, bloqueado” genera resentimiento. Un gate que dice “estas 3 de 40 trazas retrocedieron en fidelidad, esto dijo cada una” genera confianza, y los gates confiables sobreviven.

---

Esa es la versión mínima viable. La elaboración — una batería de sondas de seguridad, métricas de retrieval de RAG, presupuestos de costo por corrida, umbrales que suben automáticamente — es la siguiente sección del mismo sistema. Pero nada de eso importa hasta que las tres partes de arriba existan y el gate pueda ponerse en rojo. Construye eso primero.