Ejemplos (few-shot) para casos ambiguos y formato constante

Escribiste instrucciones detalladas y la salida igual sale distinta en cada corrida: fechas en dos formatos, severidades que cambian, etiquetas inventadas. Cuando las instrucciones solas no logran consistencia, la técnica más efectiva es mostrar ejemplos (few-shot examples): pares de entrada y salida que el modelo puede imitar.

Para qué sirven

• Formato constante: un ejemplo por cada patrón de entrada (fecha escrita, fecha numérica, fecha con hora), todos con la salida en el formato exacto que querés. Si un hallazgo de revisión tiene que traer ubicación, problema, severidad y arreglo sugerido, los ejemplos muestran esos cuatro campos, siempre iguales.
• Casos ambiguos (ambiguous cases): qué herramienta usar ante un pedido que podría ir a dos, si un hueco de cobertura de ramas merece un test, si una reseña con una queja menor es “positiva” o “mixta”.
• Distinguir lo aceptable de lo problemático: código que parece un bug pero es un patrón aceptado del equipo, al lado de uno que sí es un problema. Así bajan los falsos positivos.
• Documentos con estructuras variadas: citas en el texto o bibliografía al final, metodología en su sección o mezclada en el cuerpo, medidas informales (“dos tazas”, “un puñado”). Los ejemplos muestran dónde buscar el dato en cada estructura y reducen tanto las alucinaciones como los campos obligatorios que vuelven vacíos.

Cómo elegirlos

La guía habla de 2 a 4 ejemplos dirigidos, no de decenas. Lo que más enseña:

1. Los casos de frontera, con el porqué. Cada ejemplo explica por qué se eligió esa acción y no la alternativa plausible. Con el razonamiento, el modelo generaliza el criterio a casos que no viste, en lugar de buscar coincidencias con los ejemplos.
2. Una mezcla balanceada. Los casos típicos fijan el patrón; los casos límite (edge cases) que ya viste fallar marcan las fronteras.
3. Todas las categorías representadas. Si los dos ejemplos de severidad son “crítico”, el modelo va a decir “crítico” para casi todo. Rebalanceá para que aparezca cada nivel, con pares que solo difieren en el punto que separa dos niveles vecinos.
4. La misma correspondencia que necesita producción, detalles de formato incluidos. Un ejemplo que no se parece al caso real enseña otra tarea.

Si el modelo inventa etiquetas para pedidos raros, sumá ejemplos de pedidos raros asignados a la etiqueta permitida más cercana y aclarale que la salida tiene que ser una de la lista.

Medir en lugar de adivinar

Un clasificador que acierta en los ejemplos que ya vio puede caerse con frases nuevas. Medí la consistencia en un conjunto reservado (held-out set) que los ejemplos no cubren y agregá ejemplos solo donde falla. Si el prompt corre cientos de miles de veces por día, probá con menos ejemplos sobre una muestra etiquetada y quedate con el conjunto más chico que mantiene el resultado.

Un error estable en un caso puntual suele indicar un hueco en los ejemplos: fijate si ese caso está cubierto y si agregar uno etiquetado cambia la respuesta.

Las trampas típicas

• Pedir “usá el formato correcto” o arreglar la salida con posprocesamiento: esconde el problema.
• Ejemplos todos fáciles, o todos de la misma categoría.
• Ejemplos sin razonamiento, que el modelo copia literalmente sin entender la frontera.
• Medir sobre los mismos casos que están en los ejemplos.

En el examen

Si el escenario dice que las instrucciones son detalladas pero la salida es inconsistente, la respuesta va por ejemplos. Después elegí la opción que mejor apunta a la falla: un ejemplo por patrón de entrada para formato, casos ambiguos con su porqué para juicio, ejemplos de estructuras distintas para una extracción que deja campos vacíos.