Ejemplos few-shot: cuántos poner y qué casos elegir para lograr respuestas consistentes

Bienvenidos y bienvenidas a la cápsula dos del Módulo uno. Seguimos en el dominio cuatro con el task statement cuatro punto dos: aplicar few-shot para mejorar la consistencia y la calidad de la salida.

Few-shot significa incluir en el prompt ejemplos resueltos de entrada y salida. La guía oficial lo describe como la técnica más efectiva para lograr una salida con formato consistente y accionable, cuando las instrucciones detalladas por sí solas dan resultados inconsistentes.

Los ejemplos hacen cuatro cosas. Muestran cómo manejar casos ambiguos, por ejemplo qué herramienta elegir ante una petición ambigua o cómo tratar brechas de cobertura de tests a nivel de rama. Permiten que el modelo generalice el criterio a casos nuevos del mismo tipo, en lugar de reconocer solo los que viste. En extracción, reducen las alucinaciones con medidas informales o con documentos de estructura variada. Y fijan el formato de salida.

El detalle que pregunta el examen: la guía pide de dos a cuatro ejemplos dirigidos a escenarios ambiguos, y que cada uno muestre por qué se eligió una acción y no otra alternativa razonable. Un ejemplo que solo muestra la respuesta enseña poco. Uno que explica por qué se descartó la alternativa enseña el criterio.

Para el formato, los ejemplos muestran la estructura deseada: ubicación, problema, severidad y arreglo sugerido. Por su parte, para bajar los falsos positivos, contrastan un patrón aceptable con un problema real. Además, para extracción, cubren documentos con formatos distintos, como citas dentro del texto o una bibliografía al final. Eso ayuda cuando el modelo deja vacío un campo que sí estaba en el documento, solo que en otro formato. Y un ejemplo con el campo ausente importa tanto como los demás, porque enseña que dejarlo vacío es válido cuando el dato no existe.

Hay dos trampas. Una es llenar el prompt con reglas para cada caso borde. El artículo de ingeniería de contexto de Anthropic lo desaconseja y recomienda pocos ejemplos diversos y canónicos. La otra es creer que few-shot siempre es la primera respuesta. En una pregunta oficial del escenario de soporte, agregarlo es la opción incorrecta, porque la causa raíz eran descripciones de herramientas pobres.

Una pregunta. ¿Cuántos ejemplos son suficientes y qué casos deben cubrir?

Según la guía, de dos a cuatro, dirigidos a los casos ambiguos y con el razonamiento de cada elección.

Pregunta uno. Una radio clasifica las llamadas de los oyentes entre pedido de canción, reclamo y concurso, pero con los casos mixtos es inconsistente. ¿Qué cambio conviene? Opción A: agregar veinte ejemplos de casos fáciles. Opción B: subir la confianza mínima para aceptar cada clasificación. Opción C: repetir la instrucción de clasificar, pero en mayúsculas. Opción D: agregar de dos a cuatro ejemplos de los casos ambiguos, con el razonamiento de cada elección.

La correcta es D, porque los ejemplos fijan el criterio justo donde falla. La A no toca los casos difíciles. La B filtra con una confianza que el modelo mismo informa. La C sigue siendo una petición.

Pregunta dos, de respuesta múltiple. Elige dos. Una cervecería artesanal extrae datos de fichas de proveedores con formatos muy variables, y a veces el modelo fabrica valores. ¿Qué dos cambios ayudan? Opción A: mostrar en los ejemplos el formato de salida exacto, junto con el razonamiento. Opción B: agregar más reglas en prosa para cada caso borde. Opción C: incluir ejemplos de documentos con estructuras distintas y de campos ausentes. Opción D: pedirle al modelo que compare con su conocimiento general. Opción E: usar ejemplos solo de fichas perfectas. ¿Cuáles dos?

Las correctas son A y C. La B es la lista interminable de reglas que Anthropic desaconseja. La C enseña que un campo ausente queda vacío en lugar de inventarse, y la A fija la estructura. La D invita a inventar valores. La E no enseña los casos difíciles.

Resumen: de dos a cuatro ejemplos, dirigidos a los casos ambiguos y con el razonamiento de cada elección. Ayudan cuando el criterio es ambiguo o el formato inconsistente, pero no reemplazan información que falta. Si te sirvió, sigue el podcast, dale cinco estrellas y activa las notificaciones. En la próxima cápsula vemos salida estructurada con tool use y JSON Schema. Nos escuchamos en la próxima cápsula de EvoAcademy.