Técnicas fundamentales

📐 Fundamento

La capacidad de aprender de ejemplos en el prompt — sin reentrenar el modelo — se llama aprendizaje en contexto (in-context learning) y fue el hallazgo central del paper de GPT-3 (Brown et al. 2020, Language Models are Few-Shot Learners). El modelo no "estudia" tus ejemplos: detecta el patrón y lo continúa, que es exactamente lo que su entrenamiento lo optimizó a hacer.

Cuándo few-shot rinde más:

• Tareas con formato de salida específico (clasificar, etiquetar, convertir formatos, estilo de redacción particular).
• Tareas donde la instrucción verbal es ambigua pero el ejemplo no ("informal pero respetuoso" vs. verlo escrito).
• Tareas repetitivas sobre muchos ítems: el costo de escribir 3 ejemplos se amortiza en cada uso.

Cómo elegir los ejemplos (esto importa tanto como ponerlos):

1. Representativos y variados. Si clasificás comentarios en positivo/negativo/neutro, poné un ejemplo de cada clase — no tres positivos. El modelo imita la distribución que le mostrás.
2. Incluí un caso difícil o limítrofe. Los casos fáciles el modelo los saca solo; el ejemplo del caso ambiguo es el que enseña dónde está tu frontera ("este comentario sarcástico cuenta como negativo").
3. Formato idéntico entre ejemplos. Misma estructura, mismos delimitadores, mismo orden. Cualquier inconsistencia es ruido que el modelo puede imitar.
4. Correctos. Parece obvio, pero un ejemplo con error le enseña el error. Revisalos como si fueran a un examen.

📐 Fundamento

La técnica fue documentada por Wei et al. (2022) en Chain-of-Thought Prompting Elicits Reasoning in Large Language Models: mostrar ejemplos con razonamiento intermedio (o simplemente agregar "pensemos paso a paso", variante de Kojima et al. 2022) mejoraba notablemente el desempeño en problemas de aritmética, lógica y sentido común. Una técnica emparentada, self-consistency (Wang et al. 2022), genera varias cadenas de razonamiento y se queda con la respuesta mayoritaria.

Pero atención al contexto de 2025-2026: los modelos razonadores modernos (las familias recientes de Claude, GPT y Gemini con "razonamiento extendido") ya hacen razonamiento interno automático antes de responder. Para estos modelos, agregar "pensá paso a paso" aporta poco o nada — el modelo ya lo hace, y mejor, por su cuenta.

¿Significa que CoT murió? No exactamente. Lo que cambió es dónde está el cuello de botella:

La lección general: con modelos modernos, lo que más rinde no es el conjuro "pensá paso a paso", sino claridad, contexto, ejemplos y criterios de éxito explícitos — todo lo del capítulo 1. CoT pasó de técnica estrella a herramienta de nicho.

📐 Fundamento

Del capítulo 1 ya sabés que "pedir todo a la vez" es un error. La técnica formal se llama descomposición de tareas: convertir una tarea grande en una secuencia de subtareas, donde la salida de cada una alimenta a la siguiente.

¿Por qué funciona? Tres razones:

1. Atención concentrada. En cada paso, todo el "esfuerzo" del modelo está en una sola cosa. Las tareas mezcladas compiten entre sí.
2. Puntos de control. Entre paso y paso, vos revisás. Si el paso 2 salió mal, lo corregís antes de que contamine los pasos 3, 4 y 5. Con la tarea monolítica, un error temprano arruina todo y no sabés dónde empezó.
3. Reutilización. Los pasos buenos se vuelven plantillas independientes en tu biblioteca.

Cómo descomponer: preguntate "si delegara esto a un equipo de personas, ¿en qué pasos lo dividiría y qué le entregaría cada una a la siguiente?". Esa entrega intermedia — el formato exacto de lo que sale de un paso y entra al otro — es la parte que más cuidado merece.

📐 Fundamento

Hay dos convenciones principales, y ambas funcionan bien:

Etiquetas XML — práctica recomendada y documentada por Anthropic en su guía oficial de prompting para los modelos Claude:

<instrucciones>
Resumí el documento en 5 viñetas para un gerente sin tiempo.
</instrucciones>

<documento>
...texto largo acá...
</documento>

<pregunta>
¿El contrato permite rescindir sin penalización?
</pregunta>

Secciones Markdown — encabezados ## o delimitadores """:

## Instrucciones
Resumí el documento en 5 viñetas.

## Documento
"""
...texto largo acá...
"""

Las ventajas son las mismas en ambos casos:

1. Separación inequívoca entre instrucciones y datos. Crucial cuando el documento pegado contiene frases imperativas ("envíe su respuesta antes del viernes") que el modelo podría confundir con órdenes tuyas.
2. Referencia precisa: podés decir "usando solo lo que está en <documento>..." y el modelo sabe exactamente a qué te referís.
3. Prompts mantenibles: cuando la plantilla tiene secciones, editás una sin tocar las demás.

Reglas prácticas: usá nombres de etiqueta descriptivos (<documento>, <ejemplos>, <datos_cliente>), cerrá siempre cada etiqueta, y sé consistente — si abriste con XML, no mezcles con """ en el mismo prompt. Para prompts cortos (un par de líneas), nada de esto hace falta; la estructura paga cuando el prompt tiene datos pegados o múltiples partes.

📐 Fundamento

Los modelos de lenguaje tienden a responder algo aunque no tengan base — el famoso problema de las alucinaciones: texto plausible pero falso. Una de las mitigaciones más baratas y efectivas es darle al modelo una salida de escape: una respuesta alternativa explícitamente permitida para cuando no hay información suficiente.

Si el documento no contiene la información necesaria para responder,
respondé exactamente: "No encuentro esa información en el documento."
No completés con conocimiento general ni con suposiciones.

¿Por qué funciona? Sin la salida de escape, el modelo está implícitamente forzado a elegir entre las respuestas "con contenido" — decir "no sé" ni siquiera está sobre la mesa. Al ofrecerla explícitamente, "no sé" se vuelve una respuesta legítima y disponible, y el modelo la usa cuando corresponde.

Dónde es obligatoria:

• Preguntas sobre un documento que pegaste (¿está o no está la respuesta ahí?).
• Datos verificables: fechas, cifras, nombres, artículos de ley, dosis.
• Clasificación con casos que no encajan: agregá la categoría OTRO/NO_CLARO o el modelo forzará todo en tus cajas.

El matiz: la salida de escape reduce respuestas inventadas, pero un modelo muy presionado a decir "no sé" puede volverse perezoso y usarla de más. Si te pasa, ajustá: "si la respuesta está parcialmente en el documento, respondé con lo que haya y aclará qué falta".

📐 Fundamento

Tres perillas de control de salida que se piden explícitamente:

Formato estructurado. Si vas a comparar, pedí tabla ("columnas: criterio, opción A, opción B"). Si vas a procesar la salida con un programa o pegarla en otra herramienta, pedí JSON con el esquema exacto:

Respondé únicamente con JSON válido, sin texto antes ni después:
{
  "sentimiento": "positivo" | "negativo" | "mixto",
  "tema_principal": "<máximo 5 palabras>",
  "urgente": true | false
}

Dar el esquema con los valores posibles enumerados es mucho más confiable que "dame un JSON con el análisis". (Si usás la API — opcional, con código — muchos proveedores ofrecen modos de salida estructurada que garantizan JSON válido; en el chat, el esquema en el prompt es tu mejor herramienta.)

Longitud. Los modelos no cuentan palabras con precisión, así que las instrucciones de longitud funcionan mejor por estructura que por número: "3 viñetas" o "2 párrafos" se cumple casi siempre; "exactamente 147 palabras" no. Para acortar de verdad, las instrucciones más efectivas son estructurales: "una sola frase por punto", "sin introducción ni conclusión, andá directo a la lista".

Tono. "Formal", "informal", "académico" funcionan como brocha gorda. Para afinar, combina tres recursos: audiencia ("como si se lo explicaras a tu abuela"), referencia ("estilo artículo de divulgación, no paper") y — el más potente — un ejemplo del tono deseado (capítulo 1: mostrá, no solo digas).