Few-shot: mostrarle a la IA dos o tres casos ya resueltos en vez de describirlos

Qué es

Few-shot —"con pocos ejemplos"— es pedirle algo a un modelo de inteligencia artificial incluyendo en la misma instrucción dos o tres casos ya resueltos: la entrada y la salida que tú consideras correcta. Esas muestras le sirven de referencia.

Es una técnica de prompt, no una modificación del modelo. Los ejemplos viajan en la ventana de contexto y se acaban con la conversación: si mañana no los vuelves a poner, ya no están.

En palabras de contador

Es enseñar con los papeles del año pasado. En un despacho nadie explica desde cero cómo se redacta una observación: se saca el expediente anterior y se dice "así quedó". Dos o tres muestras transmiten el formato y el nivel de detalle mejor que media hoja de instrucciones.

Con la IA ocurre por la misma razón: describir un criterio cuesta trabajo, mostrarlo no. Si esperas un entregable con cierta estructura, cierto vocabulario y cierta forma de anotar el fundamento, pegar dos anteriores lo dice de una vez. Del otro lado está el zero-shot: ahí describes el resultado sin enseñar ninguna muestra.

Ejemplo aplicado

Clasificación de gastos. Le pegas quince conceptos del estado de cuenta ya clasificados por ti y luego el lote nuevo. Sigue tu criterio de catálogo en vez de proponer uno genérico.

Redacción de observaciones. Le muestras dos observaciones de una revisión anterior —hallazgo, evidencia, criterio, recomendación— y le pides la tercera con el caso de hoy. Sale en el formato de la firma, no en el suyo.

La cédula del despacho. Le pegas dos cédulas anteriores, con el encabezado de la firma y el orden de conceptos de siempre, y le pides la del periodo en curso. Respeta la estructura de la casa en vez de inventar una.

Para qué sirve en un despacho

• Trasladar el formato de un entregable sin redactar todo el instructivo.
• Fijar el criterio de clasificación de tu catálogo, no uno de manual.
• Homologar la salida entre las personas del equipo.
• Reducir las idas y vueltas hasta el resultado útil.

Riesgos o limitaciones

Los ejemplos se copian tal cual, lo bueno y lo de más. Si las muestras comparten un vicio de redacción o un criterio que ya cambió, el modelo lo reproduce igual. Y si todas se parecen, el caso distinto acaba forzado a ese molde.

El otro costo se nota tarde: cada muestra consume tokens, y en una conversación larga las primeras pierden peso. Tampoco vuelve verificada una cifra: el formato se hereda, el dato no. Eso sigue siendo asunto del grounding.

Buena práctica

Compruébalo con una prueba corta: toma un caso cuya respuesta ya conoces, pídeselo sin ejemplos y luego con dos o tres. Si la segunda versión se parece más a tu papel de trabajo, la técnica rinde; si no cambia nada, las muestras solo llenan el contexto.

Elige ejemplos que se distingan entre sí, no tres versiones del mismo caso, e incluye uno donde lo correcto sea señalar que falta un dato. Guárdalos en un archivo del despacho: con el tiempo vale más que la instrucción, y ahí ya haces context engineering.

Preguntas frecuentes

¿Cuántos ejemplos conviene poner? Dos o tres suelen bastar para el formato. Sube de uno en uno: pasado cierto punto el contexto se llena y ya no mejora.

¿Los ejemplos se quedan guardados en el modelo? No. Viven mientras dura la conversación o mientras estén en el system prompt de la herramienta. Modificar el modelo de forma permanente es fine-tuning, otra cosa.

¿Puedo usar casos reales de clientes como muestra? Con cuidado: son datos de tus clientes. Sustituye nombres, RFC e importes, o arma casos ficticios con la misma estructura: eso es anonimización.

Escrito y revisado por Ernesto Sobrino, contador.
Última revisión: 24 de agosto de 2026.