Monta el conjunto de casos, los criterios y el proceso que te dicen si un cambio de prompt, de modelo o de contexto mejora o rompe tu funcionalidad, en lugar de decidir por sensación.
Cuándo usarlo: Construir un sistema de evaluación de una funcionalidad con LLM para decidir con datos si un cambio de prompt o de modelo mejora o empeora
Herramienta recomendada: Claude
Actúa como ingeniero especializado en evaluación de sistemas con modelos de lenguaje. Tengo una funcionalidad con IA en producción y cada cambio de prompt o de modelo es un salto al vacío. Quiero un sistema de evaluación. ## Contexto que necesito 1. Qué hace la funcionalidad y cuál es la salida esperada (texto libre, clasificación, extracción, código, decisión). 2. Qué significa «bien» para tu negocio en esa salida: sé concreto. 3. Volumen de uso y si tienes registros de entradas y salidas reales. 4. Qué te ha fallado hasta ahora: los tipos de error que has visto. ## Paso 1 — Definir qué se mide Traduce «que funcione bien» en criterios comprobables. Para cada uno: nombre, definición operativa, cómo se puntúa y quién decide. | Tipo de criterio | Cómo se evalúa | Fiabilidad | |---|---|---| | Determinista | Comparación exacta, expresión regular, esquema válido, test que pasa | Alta | | Programático | Reglas sobre la salida (longitud, campos presentes, moneda correcta) | Alta | | Modelo como juez | Otro modelo puntúa con rúbrica y ejemplos | Media, hay que calibrarla | | Humano | Revisión con rúbrica | Alta, caro, para la muestra | Prioriza lo determinista. El juez automático se usa para lo que no se puede medir con una regla, y siempre calibrado contra puntuaciones humanas en una muestra. ## Paso 2 — Construir el conjunto de casos - **20-30 casos reales** sacados de registros de producción, no inventados. - **Casos difíciles**: los que fallaron alguna vez, entradas ambiguas, idiomas mezclados, texto muy largo, campos vacíos. - **Casos adversariales**: intentos de inyección, contenido fuera de tema, peticiones que hay que rechazar. - **Salida esperada** por caso, escrita por una persona. Aquí está el trabajo real y no se puede saltar. Congela el conjunto y versiónalo en el repositorio. Un conjunto que cambia a la vez que el sistema no mide nada. ## Paso 3 — El proceso 1. Ejecución de todos los casos contra la configuración actual: línea base. 2. Cambio (prompt, modelo, contexto, temperatura, herramientas). 3. Nueva ejecución y comparación caso a caso, no solo del promedio: un promedio igual puede esconder que ha mejorado lo fácil y ha roto lo crítico. 4. Regla de decisión escrita antes de mirar los resultados: qué mejora justifica el cambio y qué regresión lo bloquea. 5. Registro de coste y latencia junto a la calidad: un cambio que mejora un 2% y triplica el coste no es una mejora. ## Paso 4 — Integración Propón cómo encajarlo: ejecución local antes de tocar el prompt, en integración continua para los casos deterministas y con muestreo humano semanal sobre tráfico real. ## Entregables 1. Criterios de evaluación con su definición operativa y su método. 2. Estructura del conjunto de casos y 10 casos de ejemplo redactados a partir de mi contexto. 3. Script de ejecución y formato del informe comparativo. 4. Regla de decisión para aceptar o rechazar un cambio. 5. Plan de integración con el flujo de trabajo y cadencia de revisión humana.