      
      artefacto gratuito — sin muro de email
    

El checklist de evaluación pre-lanzamiento para funcionalidades de LLM

Dieciocho checks antes de que tu funcionalidad de LLM llegue a un cliente — destilados de una plataforma de QA con 85 runners y diez evals de seguridad de IA dedicados. Si puedes marcar cada casilla, lanza. Si no puedes, sabes exactamente qué construir primero.

Ground truth

sin esto, cualquier otro check es solo una opinión

Existe un golden set: 30–200 inputs reales con outputs acordados como correctos, versionado en el repo junto al código — no en la hoja de cálculo de alguien. Alguien con autoridad de dominio dio el visto bueno a los outputs golden — no el ingeniero que escribió el prompt. El golden set incluye casos difíciles: inputs ambiguos, formulaciones adversariales, solicitudes fuera de alcance, y al menos un ejemplo "debería rechazarse".

Medición

"parece mejor" no es una métrica

Un LLM-as-judge (o un scorer determinista) puntúa la fidelidad y la relevancia frente al golden set — que sea imperfecto está bien, que sea consistente es obligatorio. Los scores del juez se calculan mediante un comando, de forma reproducible — lo ejecutas dos veces y obtienes el mismo número. Se registra un score base para que el siguiente cambio de prompt o modelo produzca un diff, no un debate. Existen presupuestos de costo y latencia por request, y la corrida de evaluación reporta contra ellos.

Batería de seguridad

los modos de falla que terminan en capturas de pantalla

Alucinación: las afirmaciones se verifican contra los datos fuente en respuestas basadas en retrieval; los caminos de generación sin cita quedan cerrados o marcados. Inyección de prompt: los inputs adversariales que intentan anular las instrucciones del sistema se prueban y se bloquean. Jailbreak y rechazo: la funcionalidad rechaza lo que debe rechazar — y no rechaza lo que no debe. Toxicidad y sesgo: los outputs se puntúan sobre tus inputs reales de usuario, no solo sobre un set de benchmark. Fuga de PII: la funcionalidad no puede repetir datos de otros usuarios ni residuos de entrenamiento; los logs están depurados.

El gate

un eval en rojo que no bloquea nada es decoración

La suite de evaluación corre en CI en cada PR que toca prompts, modelos, retrieval o tools. Un score por debajo del piso bloquea el merge — el gate detiene el deploy, no la retro. El piso solo sube: cada mejora se convierte en el nuevo mínimo.

Control del radio de impacto

la autonomía se gana con evidencia, nunca se asume

Hay un punto de aprobación humana donde está el riesgo: antes de cada envío (nuevo), antes de casos novedosos (probado), o revisión posterior (maduro). Los pasos de LLM emiten output estructurado y validado por schema con una etiqueta de respaldo cuando falla el parseo — el input crudo siempre queda registrado junto a la decisión. Existe un kill switch que puede operar alguien que no sea ingeniero, y todos saben dónde está.

¿No puedes marcar todas las casillas?

Esa es la brecha que cierro en un proyecto de 4 semanas con alcance fijo — la suite, el gate y el runbook, en tu repo.

Cómo construyo esto → Descargar el PDF