De Zero-Shot a autoconsistencia: Una escalera práctica de técnicas de prompts.

Una vez que la aplicación ha decidido qué puede ver el modelo, qué documentos se obtienen, qué se resume y qué queda fuera del alcance, surge otro problema: formular la solicitud real. No existe un método de instrucción que funcione siempre. Una práctica sensata es comenzar con la instrucción más sencilla que pueda funcionar, y añadir ejemplos o una estructura paso a paso solo cuando la tarea lo requiera.

El escenario que se presenta a continuación es el de un asistente de soporte al cliente.

Comenzar sin ningún ejemplo

Una instrucción de tipo “zero-shot” describe la tarea sin mostrar cómo debería ser el resultado adecuado. En el caso del asistente de soporte, podría tratarse de una solicitud de una sola línea para resumir una queja, con la queja pegada debajo:

Summarize the following customer complaint in one sentence.
<complaint>
The package arrived three days late and the box was damaged.
</complaint>

El modelo recibe una tarea y nada más. Esa sencillez es la razón para probarlo primero. Todo lo que se añade a un prompt tiene un costo: los ejemplos consumen contexto, las instrucciones adicionales aumentan la complejidad, y cada elemento extra representa otro lugar donde dos reglas pueden entrar en conflicto. Si una instrucción directa ya genera un resultado fiable, crear estructuras complejas es un remedio para una enfermedad que nadie padece.

Qué responde una buena instrucción

Una descripción de tarea bien formulada establece cuatro aspectos: la acción a realizar, el material del cual se debe extraer información, los límites aplicables y la forma que debe tener la respuesta. Una versión más completa del prompt de queja se ve así:

Task:
Summarize the customer complaint.

Source:
<complaint>
The package arrived three days late and the box was damaged.
</complaint>

Constraints:
- Use only the information in the complaint.
- Do not infer the cause of the damage.
- Use one sentence.

Output:
Return only the summary.

Es más detallado que un simple “Resuma esto”, pero cada línea adicional elimina una suposición. El modelo ya no tiene que preguntarse si debe especular sobre las causas, cuánto tiempo continuar o si se aceptan comentarios. Las directrices publicadas por los proveedores de modelos grandes apuntan en la misma dirección: indique cuál es la tarea, cuál debería ser el resultado, qué restricciones rigen y qué contexto es importante, en lugar de esperar que el modelo lo infiera. En pocas palabras, cualquier requisito importante para la aplicación debe ser plasmado por escrito.

Los objetivos concretos son mejores que los amigables

“Ser útil” no le da al modelo casi ningún objetivo concreto. “Nombrar el problema que describe el cliente y resumirlo en una oración” le proporciona un objetivo claro. Compare dos instrucciones para la herramienta de soporte: la débil pide ayudar al cliente, mientras que la más precisa solicita el problema de autenticación descrito por el cliente, además de hasta tres pasos para solucionarlo basados en la documentación proporcionada.

Esto es importante porque un modelo puede continuar con una instrucción en muchas direcciones plausibles. Un objetivo vago deja espacio para que elige una interpretación distinta a la intención del desarrollador, mientras que uno preciso reduce ese margen.

Los límites deben estar dentro de la tarea

Diga que el asistente nunca debe inventar una solución que no esté incluida en la documentación. Esa es una regla del producto, por lo que la instrucción debe especificarlo: usar únicamente la documentación proporcionada, y si esta no aborda la pregunta, indicar que la información disponible no es suficiente. Compare esto con “Sea preciso”, que menciona un resultado deseado pero no da instrucciones sobre cómo actuar ante la incertidumbre.

El patrón se generaliza. No basta con describir el resultado ideal; también debe describirse qué debe hacer el modelo cuando ese resultado no puede producirse de forma segura. Esto es aún más importante más adelante, para las llamadas a herramientas y la salida estructurada.

Donde el enfoque zero-shot es suficiente

Una instrucción sencilla suele ser suficiente cuando la tarea es simple, el comportamiento es fácil de describir con palabras, el modelo ya conoce el tipo de tarea, las reglas de salida son modestas y la entrada no presenta casos extremos inusuales. Pedir la versión del producto en un mensaje, únicamente el número de versión, es una de esas tareas. Traducir una oración al francés es otra. Agregar cinco ejemplos en cada caso apenas aporta beneficio.

Por lo tanto, la primera regla de la optimización de prompts es extrañamente conservadora: comenzar con enfoque sin ejemplos previos y añadir mecanismos adicionales solo después de que la evaluación demuestre su necesidad.

Maneras en que falla el enfoque sin ejemplos previos

Se repiten varios tipos de fallos.

Ambigüedad. La frase “Haz que esto sea mejor” plantea la pregunta: ¿más breve, más persuasivo, más preciso, más formal? El modelo debe adivinar. Contrástelo con una solicitud para reescribir una respuesta de soporte de modo que sea concisa, profesional y clara para un cliente no técnico, manteniendo al mismo tiempo intactas todas las afirmaciones factuales. Esa versión tiene límites mucho más definidos.

Falta de contexto. Un modelo no puede basarse en hechos que nunca le han sido proporcionados ni que pueda obtener. Pídale por qué falló la autenticación de un cliente sin ofrecer un mensaje de error ni detalles del sistema, y ninguna reredacción podrá generar las pruebas que faltan. En este caso, la solución es contar con más contexto, no con instrucciones más precisas. Es un punto obvio, pero también un límite real de la ingeniería de prompts.

Requisitos contradictorios. Una instrucción que pide una explicación completa en exactamente diez palabras exige dos cosas que no se pueden cumplir bien al mismo tiempo. Un buen diseño de instrucciones evita tales conflictos en lugar de confiar en que el modelo resuelva cada uno de ellos.

Suposiciones no expresadas. Un desarrollador que escribe “Resuma la queja” podría querer decir “enumere solo los hechos mencionados por el cliente”. El modelo, por su parte, podría devolver un resumen fluido con inferencias razonables incluidas. Si la diferencia es importante, la instrucción debe especificarlo claramente. Las suposiciones relevantes para el sistema deben convertirse en requisitos explícitos y legibles por máquinas.

Agregar ejemplos

Cuando una instrucción simple resulta insuficiente, la siguiente herramienta es el prompting de pocos ejemplos: se incluyen ejemplos ya resueltos de la tarea dentro del contexto. Un clasificador que ordena los mensajes en categorías de facturación, técnicas y de cuenta podría mostrar algunos mensajes etiquetados antes del real:

Task:
Classify the customer message as BILLING, TECHNICAL, or ACCOUNT.

Example 1:
"My invoice contains an unexpected charge."
→ BILLING

Example 2:
"The application crashes when I upload a file."
→ TECHNICAL

Example 3:
"I cannot reset my password."
→ ACCOUNT

Now classify:
"I was charged twice for my subscription."

A partir de esas demostraciones, el modelo infiere la correspondencia. Esto se denomina aprendizaje in-context, ya que el modelo modifica su comportamiento para la solicitud actual utilizando los ejemplos de su ventana, mientras que sus parámetros subyacentes permanecen sin cambios. En esencia, los ejemplos dicen: “Así es como se ve la tarea en la práctica”, y pueden transmitir detalles que resulta complicado incluir en un texto narrativo.

Las demostraciones enseñan la tarea, no solo su formato

Muchos desarrolladores consideran los ejemplos de pocos casos como una ayuda para el formato. Pero hacen más que eso. Tomemos un par de ejemplos como “la aplicación es lenta” con la etiqueta TECHNICAL: esto muestra el formato de salida, pero también indica cómo esta aplicación entiende la categoría TECHNICAL. Los ejemplos determinan cómo el modelo comprende la tarea en sí.

Por eso los ejemplos malos son riesgosos. Las etiquetas incoherentes, los sesgos accidentales o los casos extremos que contradicen la política pueden ser copiados nuevamente por el modelo.

Elegir qué ejemplos incluir

Con 10,000 tickets históricos disponibles, no es práctico incluirlos todos en una solicitud, por lo que es necesario elegir un subconjunto. La elección aleatoria es el enfoque más simple, pero uno mejor aborda deliberadamente casos representativos:

Example 1: straightforward billing issue
Example 2: straightforward technical issue
Example 3: ambiguous issue
Example 4: boundary case
Example 5: short, poorly written request

Lo que se considera una buena selección depende del trabajo. La clasificación necesita que se representen las clases principales y sus límites. Una tarea de formato requiere ejemplos que muestren la estructura necesaria. Una tarea que exige razonamiento se beneficia de ejemplos que muestren cómo descomponer el problema o verificarlo. En todos los casos, un ejemplo merece su lugar por la información que contiene, no por estar disponible.

Cuántos

Más no es automáticamente mejor. Si un ejemplo cuidadosamente seleccionado hace que el comportamiento sea evidente, treinta ejemplos más podrían añadir miles de tokens sin aportar beneficio alguno y podrían introducir patrones contradictorios. Por lo tanto, la estimulación con pocos ejemplos hereda la misma tensión en cuanto al presupuesto de contexto que todo lo demás, y es necesario encontrar la cantidad adecuada mediante pruebas.

Aquí la ingeniería de prompts comienza a parecerse a un trabajo experimental. La pregunta deja de ser si un prompt suena mejor y pasa a ser si esta versión rinde mejor en casos de prueba representativos. Ese cambio se vuelve fundamental una vez que entra en juego la evaluación.

Variedad en los ejemplos

Si cada demostración es una solicitud breve, clara y bien redactada, el modelo podría aprender un patrón limitado que los usuarios reales no siguen. Los mensajes reales se ven así:

"can't login"
"I've been locked out since yesterday"
"Password reset isn't sending me anything"
"login broken after changing phone"

Todos estos describen problemas relacionados con palabras muy diferentes. Un buen conjunto de ejemplos de pocos casos refleja la variación que espera la aplicación. Eso no significa añadir ejemplos al azar; significa abordar intencionadamente las diferencias significativas.

Mostrando qué evitar

Algunas tareas se benefician de combinar una buena salida con una mala, para que el modelo pueda identificar el límite. En el caso de soporte, un mensaje indicando que un paquete llegó tarde podría incluir un resumen aceptable y uno defectuoso:

Input:
"The customer says the package arrived late."
Good output:
"The customer reports that the package arrived late."
Bad output:
"The courier lost the package."
Reason:
The customer did not state that the courier lost it.

El mal ejemplo marca un límite: no se deben inferir hechos que la entrada no respalda. Sin embargo, los ejemplos negativos requieren cuidado. Uno etiquetado como incorrecto puede enseñar accidentalmente el mismo comportamiento que se pretendía evitar, especialmente cuando la diferencia es sutil. La aplicación debe probar si las demostraciones negativas mejoran los resultados y no asumir simplemente que lo harán.

Ejemplos para la estructura

Cuando es difícil describir el formato de una salida, un ejemplo funciona bien. Supongamos que el asistente debe responder con tres líneas etiquetadas para el problema, la evidencia y la acción:

Issue: ...
Evidence: ...
Action: ...

Una demostración en vivo hace que ese diseño sea tangible de inmediato:

Input:
"The login token expired after 30 days."
Output:
Issue: Expired authentication token
Evidence: Token expiration is reported after 30 days
Action: Regenerate the authentication token

Corrige tanto el patrón de contenido como la presentación. Sin embargo, los ejemplos no siempre son la respuesta adecuada. Si el software necesita JSON legible por máquinas con validez garantizada, una función de salida restringida por esquema puede ser más fiable que mostrarle al modelo un ejemplo.

Mantener la consistencia de los ejemplos

Los prompts de pocos ejemplos reaccionan mal ante contradicciones. Considere dos demostraciones con la misma entrada, “No puedo iniciar sesión”, etiquetada como ACCOUNT en una y TECHNICAL en la otra:

Example 1:
"Can't log in" → ACCOUNT
Example 2:
"Can't log in" → TECHNICAL

El modelo no cuenta con un método sistemático para determinar qué mapeo se pretende utilizar. Incluso las diferencias sutiles causan problemas. Si algunos ejemplos utilizan la etiqueta “BILLING” y otros la frase “Billing issue”, el espacio de salida se vuelve ambiguo. Las etiquetas, el formato, la terminología, el nivel de detalle y la forma de manejar los casos límite deben ser consistentes en todos los ejemplos. Las demostraciones forman parte de la especificación y merecen la misma atención.

Aprendizaje dentro de la ventana

El aprendizaje in-context es la idea general detrás de la inducción por pocos ejemplos: los ejemplos se encuentran en el contexto actual, y el comportamiento del modelo cambia según esa interacción. Esto no implica que el modelo los haya absorbido de forma permanente. Si la aplicación envía un ejemplo etiquetado y luego un mensaje del usuario indicando que no puede acceder a una cuenta:

Example:
"Password reset email never arrived." → ACCOUNT
User:
"I can't access my account."

El modelo puede utilizar la demostración para esta solicitud. Sus parámetros no se actualizan y el ejemplo no se agrega a su conocimiento permanente. Esto refleja la distinción entre contexto y memoria mencionada anteriormente. Los métodos que sí modifican los parámetros, como el ajuste fino con datos de entrenamiento adicionales, constituyen un mecanismo separado, y su comparación con la inducción por prompts ocurre mucho más tarde. Por ahora, la inducción por pocos ejemplos debe considerarse como una condicionamiento temporal de la tarea proporcionado a través del contexto.

Elegir entre los dos

Un proceso de toma de decisiones efectivo comienza identificando cómo falla la salida. Una tarea ambigua requiere una redacción más clara. La falta de información exige un contexto mejor. Una convención sutil que el modelo pasa por alto es cuando los ejemplos pueden ser útiles. Si la tarea necesita cálculos matemáticos exactos o acceso a una base de datos, incluir más texto en el prompt podría ser la solución completamente incorrecta.

Ese último caso conduce a un terreno más complicado. Algunas tareas son demasiado complejas para abordarlas de manera fiable con una sola instrucción y una sola respuesta. Es necesario dividirlas en operaciones más pequeñas, verificarlas o vincularlas a cálculos externos. Pasado un cierto punto, el desafío ya no es encontrar la frase perfecta, sino diseñar un procedimiento sencillo que el modelo deba seguir.

Considere un caso en el que un cliente queda bloqueado inmediatamente después de cambiar su contraseña, y al asistente se le pide que revise el historial, identifique la causa probable y responda. A simple vista parece una sola tarea. En la práctica, oculta varias: determinar qué sucedió, encontrar las pruebas relevantes, separar los hechos de las suposiciones, razonar sobre las causas posibles, decidir qué se puede recomendar de forma segura, verificar esa recomendación y redactar la respuesta final. Comprender esto es la clave para la descomposición.

Dividir una tarea en varias

La descomposición reemplaza un trabajo complicado por varios más pequeños que tienen límites claros. En lugar de solicitarlo todo de una sola vez, la aplicación puede organizar la solicitud en etapas:

Task:
Analyze this customer support case.

Step 1:
Extract the relevant facts.

Step 2:
Identify the customer's actual problem.

Step 3:
List plausible causes supported by the evidence.

Step 4:
Select the safest supported resolution.

Step 5:
Draft the customer-facing response.

El modelo no necesita literalmente la palabra “Paso”. Lo importante es que un objetivo vago se haya convertido en una secuencia de operaciones manejables. Esto resulta especialmente útil cuando las partes tienen naturalezas diferentes: extraer hechos es una tarea de información, elegir un diagnóstico es razonamiento y redactar el mensaje es comunicación. Agruparlas en una sola instrucción indiferenciada hace que sea más difícil dirigir y evaluar el resultado.

Un sistema descompuesto también ofrece más puntos para probar. Si la respuesta final es incorrecta, se puede determinar si falló la extracción de hechos, el diagnóstico o la redacción de la respuesta. El cambio de enfoque consiste en que una instrucción puede estructurarse como una cadena de procesos y no solo como una pregunta.

Planificar primero, luego actuar

Una técnica relacionada le pide al modelo que elabore un plan antes de llevar a cabo una tarea compleja. Esto es útil cuando el modelo debe decidir qué operaciones son necesarias antes de poder responder. El asistente de soporte podría comenzar con un objetivo y un plan ordenado:

Goal:
Resolve the customer's login problem using only supported evidence.
Plan:
1. Read the latest customer message.
2. Check the relevant conversation history.
3. Identify authentication-related evidence.
4. Compare the evidence with the known troubleshooting guidance.
5. Produce a response that does not claim unsupported facts.

La planificación separa la decisión sobre cómo resolver algo de la resolución real del mismo. Esta separación cobra mayor importancia cuando se utilizan herramientas, ya que el modelo puede necesitar concluir que debe buscar en una base de conocimientos, consultar un registro de cuenta o realizar un cálculo primero. La estimulación puede establecer la estructura del trabajo antes de que este comience.

Hay un costo asociado. La descomposición aumenta la longitud de las instrucciones, y cuando cada etapa es una llamada independiente, también se generan llamadas adicionales al modelo y mayor latencia. Un proceso de cinco etapas puede costar mucho más que una sola llamada. Vale la pena cuando el control y la fiabilidad adicionales justifican el precio, no porque tener más etapas sea inherentemente mejor.

Generar, criticar, revisar

Otro patrón importante permite que el modelo revise nuevamente su propio borrador. La primera respuesta no se considera definitiva; una segunda revisión la examina según criterios explícitos. En el caso del sistema de soporte, eso significa redactar la respuesta y luego verificar el borrador contra una lista de problemas específicos:

First:
Draft the response.

Then:
Check the draft for:
- unsupported claims,
- missing evidence,
- incorrect troubleshooting steps,
- promises the support team cannot make,
- failure to answer the customer's actual question.

Finally:
Revise the response to correct any problems.

Esto funciona porque la generación y la evaluación son tareas diferentes. Generar significa crear algo plausible. Revisar una respuesta existente permite al modelo buscar violaciones de una lista de verificación. Especificar los criterios suele ser más efectivo que pedirle que piense más profundamente.

El patrón se puede aplicar a diferentes niveles de profundidad: boceto, revisión, respuesta final, o, para una tarea más estructurada, extraer, verificar la extracción, clasificar, verificar la clasificación y generar. La segunda forma es más fácil de depurar porque cada etapa tiene un contrato definido.

Hay un límite importante. Un modelo al que se le pide que se critique a sí mismo no constituye por ello una fuente independiente de verdad. Si la respuesta original se basa en una suposición errónea, el crítico podría compartirla. La autocrítica puede mejorar la coherencia sin garantizar la corrección, y para decisiones de alto riesgo vale la pena verificarla con algo externo al modelo: una base de datos, una regla conocida, un cálculo, un documento recuperado o código determinista.

Indicaciones que exponen la estructura de razonamiento

La investigación sobre las indicaciones de tipo “cadena de pensamiento” reveló que mostrar al modelo ejemplos con pasos intermedios de razonamiento puede mejorar los resultados en algunos problemas de múltiples pasos, con mejoras observadas en pruebas aritméticas, de sentido común y simbólicas. La lección de ingeniería es más amplia que esa frase. Una tarea compleja puede beneficiarse cuando la indicación hace explícita su estructura intermedia:

Identify the relevant facts.
Determine which facts support each possible conclusion.
Eliminate conclusions that require unsupported assumptions.
Select the conclusion supported by the evidence.

Se trata de una instrucción orientada al razonamiento: se diseña la tarea de modo que las decisiones intermedias sean lo suficientemente claras como para guiar al modelo hacia el resultado deseado. Esto no obliga a una aplicación de producción a mostrar al usuario el razonamiento interno del modelo. A menudo, una interfaz mejor solicita el resultado de la verificación, en lugar de una explicación extensa. La aplicación puede requerir un registro interno compacto como el que se muestra a continuación, y luego generar por separado una respuesta breve para el cliente:

classification: password_reset_issue
evidence_supported: true
recommended_action: resend_reset_link
confidence: high

La estructura del razonamiento y la explicación dirigida al cliente son requisitos separados. Mantenerlos aparte también evita un error común, que es suponer que un razonamiento más visible hace que una respuesta sea más fiable. Los pasos intermedios también pueden contener errores. Los estudios sobre la inducción por cadena de pensamiento han demostrado que las propiedades de las demostraciones, como su relevancia y orden, son de gran importancia, por lo que simplemente añadir razonamientos extensos no constituye una solución universal.

Varias tentativas y luego una votación

La generación es probabilística, por lo que un mismo problema puede dar lugar a diferentes respuestas en distintas ejecuciones. La autoconsistencia aprovecha esto al muestrear múltiples rutas de razonamiento y elegir la respuesta que la mayoría de ellas respalde, en lugar de confiar en una sola ruta muestreada.

Supongamos que el sistema de soporte no está seguro de si un caso se debe a un problema de restablecimiento de contraseña o a un bloqueo de cuenta. En lugar de aceptar una sola clasificación, podría generar varios análisis y comparar las clasificaciones resultantes.

El acuerdo aún está lejos de la verdad. Si el modelo interpreta constantemente mal la situación, muchas generaciones independientes pueden llegar a la misma respuesta incorrecta. La consistencia es evidencia de estabilidad, no prueba de corrección. También requiere más cálculos y genera mayor latencia, lo que solo lo hace atractivo para tareas lo suficientemente difíciles como para que la mejora en la fiabilidad justifique los costos.

Donde los prompts deben ceder el paso al código

Aquí radica la línea que separa las instrucciones cada vez más elaboradas de un buen diseño de sistema. Imagine solicitar la suma total de una factura con 17 artículos a ₹1500 cada uno. Probablemente un modelo pueda calcular esa suma, pero cuando es importante obtener un dato financiero exacto no hay razón para hacer que simule operaciones aritméticas mediante instrucciones cada vez más extensas. Una calculadora o un programa ordinario multiplica de manera determinista.

La misma lógica se aplica a otras tareas:

• Los datos de la cuenta deben provenir de una consulta a la base de datos, no de la memoria del modelo.
• Los hechos actuales deben recuperarse, no evocarse del entrenamiento.
• Las operaciones aritméticas corresponden a una calculadora o a un programa.
• La verificación de un esquema es tarea de un analizador y validador.
• La autorización corresponde al código de la aplicación y a las reglas de control de acceso.
• Las reglas empresariales críticas deben codificarse de manera determinista siempre que sea posible.

Existe una regla útil: utilice la inducción para dirigir el comportamiento del modelo de lenguaje, y emplee software determinista cuando la tarea requiera efectivamente un cálculo o aplicación determinista.

Las acciones externas refuerzan este punto. ReAct, un enfoque de investigación bien conocido, intercala el razonamiento con acciones para que un modelo pueda consultar fuentes o entornos externos en lugar de depender únicamente de su conocimiento interno, y demostró que dicha interacción puede resolver problemas como las alucinaciones y la propagación de errores en algunas tareas.

Ese es el puente hacia lo que viene a continuación. El sistema de soporte comenzó como un prompt y ahora se asemeja a un pequeño programa. Una vez que la verificación necesita una base de datos, una base de conocimientos, una API u otra capacidad externa, el modelo ya no funciona únicamente con texto, y la cuestión pasa a la ingeniería de contexto: decidir no solo qué instrucciones escribir, sino también qué información debe recibir el modelo.