Evaluar e iterar

📐 Fundamento

La evaluación de prompts replica, a escala personal, lo que la industria llama evals: la práctica de medir el comportamiento de sistemas con LLM contra conjuntos de casos definidos. El ciclo completo:

1. Criterios de éxito → qué significa "bien" para esta plantilla, en términos verificables.
2. Casos de prueba → entradas representativas + difíciles, con su resultado esperado.
3. Medición → correr la plantilla sobre los casos y anotar cuáles cumplen los criterios.
4. Iteración → cambiar UNA cosa, volver a medir, comparar.
5. Versión → cuando los números mejoran, la nueva versión se registra; cuando no, se descarta sabiendo por qué.

¿Exagerado para uso personal? Depende de la plantilla. La regla proporcional: el rigor de la evaluación crece con el costo del error y la frecuencia de uso. Un prompt de una vez para una curiosidad: probalo y listo. Tu plantilla de fichas de lectura que vas a usar 50 veces este ciclo y de la que dependen tus exámenes: esa merece el ciclo completo. La mayoría de tu biblioteca está en el medio: criterios escritos + 5-8 casos de prueba + un par de iteraciones.

📐 Fundamento

"Que el resumen quede bueno" no es un criterio: es un deseo. Un criterio de éxito es una afirmación que cualquier persona (o un programa) puede verificar como cumplida o no cumplida mirando la respuesta. La transformación:

Tres tipos de criterio, de más fácil a más difícil de verificar:

1. De formato (mecánicos): longitud, estructura, JSON válido, presencia de secciones. Se verifican de un vistazo o con un programa.
2. De contenido (factuales): la información correcta está, la incorrecta no, las citas existen en la fuente. Requieren comparar contra la fuente o una respuesta de referencia.
3. De calidad (de juicio): claridad, tono, utilidad. Los más difíciles — para estos sirven las escalas simples (1-3: inutilizable / usable con edición / usable directo) y, con cuidado, el LLM-as-judge de la sección 5.6.

Escribí los criterios antes de iterar. Si los escribís después de ver las respuestas, vas a escribir criterios que tus respuestas ya cumplen — el equivalente a dibujar la diana alrededor del disparo.

📐 Fundamento

Un caso de prueba para un prompt tiene tres partes: la entrada (los valores de las variables de tu plantilla), lo esperado (qué debe cumplir la salida — tus criterios aplicados a este caso) y, después de correrlo, lo obtenido.

¿Cuántos casos? Para uso personal, 5-10 por plantilla rinde la mayor parte del beneficio. Lo importante no es la cantidad sino la composición:

• 2-3 casos típicos — el uso normal. Si estos fallan, nada más importa.
• 2-3 casos difíciles — los que sospechás que pueden romper la plantilla:
  • entrada muy corta o muy larga (¿la ficha de lectura funciona con un abstract solo? ¿con 40 páginas?),
  • entrada ambigua o limítrofe (el comentario sarcástico para el clasificador),
  • entrada con trampa de inyección accidental (el documento que contiene frases imperativas),
  • el caso donde la respuesta correcta es "no sé" (¡imprescindible! — es el único modo de probar tu salida de escape).
• 1-2 casos adversarios — entradas raras de verdad: vacía, en otro idioma, fuera del dominio ("¿qué hace mi plantilla de exámenes si le pego la letra de una canción?").

Los casos difíciles salen de dos fuentes: tu imaginación de entrada... y, mucho mejor, tus fallos reales: cada vez que la plantilla falle en uso normal, ese input se convierte en caso de prueba permanente. Así los errores no se repiten — quedan vigilados para siempre. (Los desarrolladores conocen esto como tests de regresión.)

📐 Fundamento

El protocolo de iteración disciplinada:

1. Corré la versión actual sobre tus casos y anotá los resultados (tu línea base).
2. Elegí EL fallo más importante (no todos: el peor).
3. Formulá una hipótesis: "falla el caso 3 porque la plantilla no le da salida de escape cuando el texto es corto".
4. Hacé UN cambio que ataque esa hipótesis.
5. Volvé a correr TODOS los casos — no solo el que fallaba. El riesgo número uno de iterar es la regresión: arreglar el caso 3 rompiendo el 1.
6. Comparalo contra la línea base: ¿mejoró el caso objetivo? ¿se mantuvo el resto? → nueva versión. ¿No? → descartá el cambio y anotá la hipótesis fallida (vale oro: es lo que ya sabés que no es).

Sobre la variabilidad: el mismo prompt puede dar respuestas distintas en corridas distintas. Para casos donde el resultado "baila" entre ✅ y ❌, corré ese caso 2-3 veces y anotá la proporción — un caso que pasa 1 de 3 veces NO está resuelto. (Opcional, con código: en la API podés fijar temperature baja para reducir variabilidad en tareas con respuesta correcta única.)

¿Y dónde encontrar ideas de cambio? En orden de rentabilidad típica: (1) agregar/ajustar la salida de escape, (2) agregar un ejemplo few-shot del caso que falla, (3) precisar la instrucción ambigua, (4) reordenar (pregunta después del documento), (5) partir la tarea en dos eslabones. Las primeras dos resuelven la mayoría de los fallos reales.

📐 Fundamento

A veces la pregunta no es "¿mejoró este cambio?" sino "¿cuál de estos dos enfoques es mejor?" — ¿rol de "profesor" o de "compañero de estudio"? ¿ejemplos o reglas? Para eso: A/B testing manual.

El protocolo simple:

1. Dos versiones que difieren en lo que querés comparar (y solo en eso — si difieren en cinco cosas, la comparación no te dice nada atribuible).
2. Las mismas entradas para ambas, en conversaciones separadas y limpias (nada de probar B en el mismo chat donde corriste A: el historial contamina).
3. Evaluación a ciegas cuando el criterio es de juicio: copiá las respuestas a un documento como "Respuesta 1" y "Respuesta 2" sin marcar de qué versión salió cada una, dejá pasar un rato (o pedile a un compañero que juzgue), y elegí la mejor según tus criterios. Recién después mirá cuál era cuál. Suena teatral; es la única defensa contra tu propio sesgo — si sabés cuál es "tu" versión favorita, vas a verla mejor.
4. Varios casos, no uno: A puede ganar en el caso típico y perder en los difíciles. Contá victorias por caso.

Cuándo A/B y cuándo iteración simple: la iteración (5.4) optimiza una versión paso a paso; el A/B compara enfoques estructuralmente distintos. Si estás dudando entre dos filosofías de plantilla, hacé el A/B primero y después iterá sobre la ganadora.

📐 Fundamento

Evaluar a mano 8 casos × 3 versiones = 24 respuestas se vuelve trabajo. Una idea documentada y muy usada en la industria: usar un LLM para evaluar las salidas de otro prompt — LLM-as-judge. Le das al modelo-juez la respuesta, los criterios, y le pedís un veredicto.

Actuá como evaluador estricto. Calificá la RESPUESTA contra estos
criterios. Para cada criterio: CUMPLE / NO CUMPLE + evidencia textual
(citá la parte de la respuesta que lo demuestra o el hueco donde falta).
No premies la redacción bonita: evaluá solo los criterios.

<criterios>
1. Incluye la tesis del texto fuente.
2. Ninguna afirmación ausente del texto fuente.
3. Máximo 10 líneas.
4. Si falta información, lo dice explícitamente.
</criterios>

<texto_fuente>...</texto_fuente>
<respuesta>...</respuesta>

Veredicto final: APROBADA solo si cumple los 4.

Funciona razonablemente para: criterios de formato y estructura, verificar que cada afirmación tenga respaldo en la fuente (dándole la fuente), comparar dos respuestas con criterios claros, y filtrar lo claramente malo antes de tu revisión humana.

Sus riesgos, documentados en la literatura:

• Sesgo de posición: al comparar dos respuestas, los jueces-LLM tienden a favorecer una posición (p. ej. la primera). Mitigación: evaluá en los dos órdenes; si el veredicto cambia, es empate.
• Sesgo de verbosidad: tienden a preferir respuestas más largas y elaboradas, estén o no mejor.
• Auto-preferencia: un modelo tiende a evaluar mejor las salidas con su propio estilo. Si podés, juzgá con un modelo distinto del que generó.
• Criterios de juicio fino: "¿es pedagógicamente buena esta explicación?" excede lo que un juez-LLM evalúa con confianza. Para eso seguís siendo vos.

La regla sensata para uso personal: LLM-as-judge como primer filtro, vos como instancia final — y calibralo: las primeras veces, evaluá vos también los mismos casos y compará. Si el juez y vos discrepan seguido, su veredicto no te sirve.

📐 Fundamento

La habilidad final: reconocer cuándo iterar más es perder el tiempo. Tres diagnósticos:

1. La tarea es imposible (o imposible para un LLM). Hay cosas que ningún prompt arregla: datos que el modelo no tiene ("¿qué notas saqué este ciclo?" — no las sabe), información posterior a su entrenamiento sin acceso a búsqueda, certeza factual garantizada sin fuente contra la cual verificar, aritmética de alta precisión sobre listas enormes (para eso está la hoja de cálculo), predicciones del futuro. Síntoma: iteraste 5+ veces y los fallos cambian de forma pero no desaparecen — cada versión inventa distinto. Acción: reformulá la tarea (dale la fuente, conectá la búsqueda, partila) o aceptá que esta tarea va en otra herramienta.

2. Falta contexto que solo vos tenés. El prompt pide juzgar, decidir o personalizar con información que no está en el prompt: "¿está bien mi ensayo?" (¿contra qué consigna? ¿qué rúbrica?), "¿qué materia me conviene?" (¿con qué horario, qué plan, qué metas?). Síntoma: las respuestas son razonables pero genéricas, y cuando agregás contexto en un mensaje de seguimiento, mejoran de golpe. Acción: ese contexto que agregaste a mano es una variable que le falta a tu plantilla — formalizala.

3. Modelo equivocado para la tarea. Las familias de modelos difieren: los pequeños y rápidos rinden menos en razonamiento de varios pasos; los razonadores brillan en problemas complejos pero son más lentos y caros para tareas triviales; algunos aceptan imágenes o PDFs y otros no; las ventanas de contexto difieren. Síntoma: tu prompt es claro, completo, con buenos ejemplos — y el modelo igual se pierde en el paso 4 del razonamiento, o trunca el documento. Acción: probá la MISMA plantilla, sin tocar, en un modelo más capaz (o uno razonador). Si pasa de fallar a funcionar, no era el prompt. La plantilla evaluada te da el lujo de esta prueba limpia: mismo set de casos, otro modelo, comparás números.

El orden de sospecha es deliberado: primero el prompt (lo más barato de arreglar — capítulos 1-4), después el contexto, al final el modelo. La gente suele recorrerlo al revés: culpa al modelo, paga uno mejor, y le manda el mismo prompt de una línea.