¿Qué hace eval-design?
Estás diseñando la medición, no el producto. El resultado de este skill es una decisión que alguien pueda defender en una sala, no un número.
La mayoría de las veces, la decisión es qué arreglar a continuación. Una evaluación que solo clasifica sistemas es un informe; una evaluación que nombra las dos cosas que más te cuestan, y prueba que la solución funcionó cuando la vuelves a ejecutar, es un bucle de desarrollo. Construye para el segundo caso: la taxonomía de fallos y el desglose por criterio importan más que la puntuación general, porque son las partes sobre las que alguien puede actuar.
La posición
Cuatro reglas. Son opiniones, y son el punto central de este skill.
1. Sin sensaciones subjetivas. "Se siente mejor" no es un resultado. Si un cambio no se puede expresar como un movimiento en un criterio definido, medido sobre un conjunto fijo, no ha sido evaluado. Envíalo si quieres, pero no afirmes que fue probado.
2. Cada criterio debe ser discutible. Un criterio sobre el que dos revisores cuidadosos no pueden situarse en lados opuestos no está midiendo nada. "¿Es útil la salida?" no es un criterio. "¿La respuesta indica el plazo de devolución en días?" sí lo es. Cada criterio en una rúbrica lleva consigo el desacuerdo específico que fue creado para resolver; consulta references/rubric-design.md.
3. Sin LLM como juez por defecto. Un juez es un sistema con su propia tasa de error, y un juez no validado introduce ese error en tu número principal. Primero etiquetan humanos, luego el juez se calibra contra esas etiquetas, y el nivel de concordancia se publica junto a cada resultado que el juez produce. Consulta references/judges.md.
4. Reporta la línea base o la evaluación es marketing. Expresiones regulares, una regla de palabras clave, el sistema de producción actual, o no hacer nada. Aproximadamente un tercio de las funciones de IA lanzadas pierden frente a algo que no cuesta nada en al menos un criterio, y quieres descubrirlo antes de que lo haga un gerente de contratación o un VP.
Dos reglas estructurales se derivan de estas:
- Las puertas son pisos, no pesos. Un criterio de seguridad, legal o de confianza no se negocia contra el rendimiento promedio. Un sistema por debajo del piso no es candidato a ningún precio. Los promedios ponderados ocultan exactamente esto.
- Intervalos de confianza o no hay clasificación. Con n=150, una diferencia de 3 puntos es ruido. Clasificar sistemas dentro del ruido es la forma más común en que el trabajo de evaluación engaña a quien lo lee.
Flujo de trabajo
Trabaja en este orden. No te saltes a la puntuación: cada fallo de una evaluación se remonta a algo omitido arriba.
- Encuentra la decisión. ¿Qué cambia según el resultado? "Qué modelo lanzamos", "¿puede ir sin supervisión?", "¿la modificación del prompt provocó una regresión?". Si nada cambia, detente y dilo: este es el momento más valioso del proceso, y la respuesta honesta a veces es "no necesitas una evaluación".
- Escribe la taxonomía de fallos primero. Antes de los criterios. Reúne de 30 a 50 salidas reales, léelas todas y agrupa lo que salió mal. Los criterios derivados de fallos observados superan a los criterios derivados de la imaginación, siempre. →
references/failure-taxonomy.md - Convierte la taxonomía en criterios. Cada uno recibe un peso, un desacuerdo y, opcionalmente, una puerta. →
references/rubric-design.md - Construye el conjunto dorado. Estratificado, adversarial, versionado y lo suficientemente pequeño como para que un humano lo etiquete realmente. →
references/golden-sets.md - Etiqueta con humanos, mide la concordancia. Si dos etiquetadores no pueden ponerse de acuerdo, la rúbrica está rota, no los etiquetadores. Arregla la rúbrica y vuelve a etiquetar. →
references/statistics.md - Solo ahora considera un juez, y solo calibrado. →
references/judges.md - Ejecuta cada sistema, incluida una línea base no basada en IA, escribe
results.jsony renderiza. →references/scorecard-spec.md - Escribe el veredicto tú mismo. La tarjeta de puntuación muestra números; un humano expresa la compensación que se está haciendo y qué revertiría la decisión.
Renderizado
python3 skills/eval-design/scripts/render_scorecard.py results.json --md
Escribe un scorecard.html autocontenido (sin solicitudes externas, modo claro y oscuro) y un SUMMARY.md para leer en el repositorio. Esquema: references/scorecard-spec.md.
python3 skills/eval-design/scripts/validate_rubric.py results.json
Falla ante los errores que hacen que una tarjeta de puntuación sea deshonesta: pesos que no suman 1, criterios sin un desacuerdo declarado, puertas sin justificación, línea base faltante o una clasificación afirmada dentro del intervalo de confianza.
Cuándo no usar esto
- Un ajuste puntual de prompt sin ninguna decisión asociada. Solo mira la salida.
- No tienes usuarios ni ejemplos. Consigue primero 30 entradas reales. Una evaluación construida sobre entradas imaginarias mide tu imaginación.
- La tarea tiene una respuesta correcta que un programa puede verificar (aritmética, JSON válido, una compilación correcta). Escribe la comprobación, no una rúbrica.
- Alguien quiere un número para justificar una decisión ya tomada. Dilo en voz alta en lugar de construir la evaluación.
Archivos de referencia
Carga bajo demanda; no los leas todos de antemano.
| Archivo | Leer cuando |
|---|---|
references/rubric-design.md | Escribiendo o corrigiendo criterios |
references/failure-taxonomy.md | Comenzando desde salidas reales |
references/golden-sets.md | Seleccionando y estratificando casos |
references/judges.md | Alguien propone usar un LLM como juez |
references/statistics.md | Tamaño de muestra, ICs, concordancia, deriva |
references/scorecard-spec.md | Escribiendo results.json |
references/antipatterns.md | Revisando la evaluación de otra persona |