Qué es prompting y por qué importa tanto

OpenAI define el prompting de forma simple: es el proceso de dar entrada a un modelo, y la calidad del resultado depende en gran medida de cómo esté formulada esa entrada. La idea parece obvia, pero tiene una consecuencia práctica importante: no basta con saber qué quieres; hay que saber expresarlo de una manera que el modelo pueda ejecutar con la menor ambigüedad posible. 

Promptear bien no es adornar instrucciones. Es diseñarlas. Un buen prompt reduce espacio para interpretaciones erróneas, fija el objetivo, delimita el formato de salida y, cuando hace falta, enseña con ejemplos qué patrón debe seguir el modelo. Por eso el prompting no es solo una técnica de redacción: es una forma de especificación.

La regla general sigue siendo bastante sobria: empieza con una instrucción clara, añade restricciones útiles y no compliques el prompt antes de tiempo. En la guía oficial de reasoning best practices, OpenAI resume una parte clave de esta lógica en una frase sencilla: primero zero-shot, luego few-shot si hace falta. 

Zero-shot prompting: qué es y cuándo conviene

Zero-shot prompting significa pedirle al modelo que resuelva una tarea sin mostrarle ejemplos previos de cómo debería responder. Solo recibe la instrucción, el contexto relevante y, si corresponde, las restricciones de formato. Es el enfoque más limpio y, en muchos casos, el más eficiente. OpenAI recomienda precisamente empezar por ahí antes de complicar el prompt con demostraciones.

Cuándo funciona bien

Zero-shot suele rendir bien cuando la tarea está bien especificada y el patrón de salida no es especialmente raro. Resúmenes, clasificaciones sencillas, reescrituras, extracción de datos con formato claro o redacción con reglas explícitas suelen resolverse bien sin ejemplos. La clave no es que el prompt sea corto, sino que sea preciso.

Ventajas del zero-shot

• Menos tokens: no tienes que gastar espacio en ejemplos.
• Más fácil de mantener: cambias una instrucción, no un set entero de demostraciones.
• Menor riesgo de sobreajuste al ejemplo: el modelo no copia plantillas innecesarias.
• Mejor punto de partida: sirve para medir si el problema realmente necesita más estructura.

Ejemplo práctico: antes y después en zero-shot

Antes:

Resume este texto.

Después:

Resume el siguiente texto en 5 viñetas.
Incluye solo ideas principales.
No añadas opiniones ni información nueva.
Mantén un tono profesional y claro.

Texto:
[pega aquí el texto]

En los dos casos el prompt es zero-shot. La diferencia es que el segundo elimina ambigüedad. Ya no deja al modelo decidir por su cuenta longitud, formato, tono y criterio de selección. Ese ajuste suele tener más impacto que añadir complejidad técnica al prompt. 

Otro ejemplo práctico: clasificación

Antes:

Clasifica este comentario.

Después:

Clasifica el siguiente comentario en una sola categoría:
positivo, negativo o neutral.

Devuelve la respuesta en JSON con esta estructura:
{"sentimiento":"..."}

Comentario:
"El envío llegó tarde, pero el producto funciona bien."

De nuevo, sigue siendo zero-shot. No hay ejemplos. Pero hay una tarea concreta, categorías cerradas y un formato de salida inequívoco. Muchas veces eso basta.

Few-shot prompting: qué es y por qué cambia el resultado

Few-shot prompting consiste en incluir unos pocos ejemplos de entrada y salida dentro del prompt para que el modelo aprenda el patrón que debe imitar. OpenAI lo describe como una forma de orientar al modelo hacia una tarea nueva sin hacer fine-tuning, mostrando un pequeño conjunto de demostraciones bien alineadas con el comportamiento deseado. 

La utilidad del few-shot aparece cuando la instrucción sola no basta. Ocurre mucho en tareas donde el formato es delicado, el criterio es sutil o el estilo de salida necesita una consistencia muy concreta. En ese caso, un buen ejemplo vale más que un párrafo adicional de explicación.

Cuándo conviene usar few-shot

• Cuando el formato de salida es específico o poco común.
• Cuando quieres fijar tono, longitud o estructura con precisión.
• Cuando el modelo entiende la tarea, pero falla en el patrón de respuesta.
• Cuando hay criterios sutiles que son más fáciles de mostrar que de describir. 

La regla más importante del few-shot

OpenAI advierte que los ejemplos deben alinearse muy de cerca con la instrucción principal. Si tus ejemplos contradicen lo que pides, o si mezclan estilos distintos, el modelo puede aprender el patrón equivocado. En pocas palabras: pocos ejemplos buenos ayudan; pocos ejemplos confusos estropean el prompt. 

Ejemplo práctico: soporte al cliente

Antes:

Responde este correo de un cliente molesto.

Después con few-shot:

Responde como agente de soporte.
Objetivo: ser claro, breve y resolver sin sonar robótico.

Ejemplo 1
Cliente: "Me cobraron dos veces y nadie me responde."
Respuesta: "Lamento el inconveniente. Ya revisé el caso y he solicitado la devolución del cargo duplicado. Recibirás la confirmación por correo en cuanto el proceso quede registrado."

Ejemplo 2
Cliente: "Mi pedido no llegó en la fecha prometida."
Respuesta: "Siento la demora. He comprobado el estado del envío y está en reparto. Te comparto el número de seguimiento actualizado y estaré atento si necesitas una revisión adicional."

Ahora responde este caso:
Cliente: "He intentado cancelar mi suscripción y el sistema me vuelve a cobrar."

Aquí los ejemplos no explican la tarea en abstracto. La muestran. Fijan el tono, la longitud, el nivel de empatía y el tipo de resolución. Ese patrón suele ser más fiable que una instrucción genérica como “sé amable y profesional”. 

Ejemplo práctico: extracción estructurada

Antes:

Extrae datos de este texto.

Después con few-shot:

Extrae nombre, cargo y empresa.
Devuelve solo JSON.

Ejemplo 1
Texto: "Laura Gómez, directora financiera de Nubelia, explicó los resultados del trimestre."
Salida:
{"nombre":"Laura Gómez","cargo":"directora financiera","empresa":"Nubelia"}

Ejemplo 2
Texto: "Tomás Rivas, fundador de Estudio Delta, presentó la nueva línea de producto."
Salida:
{"nombre":"Tomás Rivas","cargo":"fundador","empresa":"Estudio Delta"}

Ahora procesa este texto:
"Marina Soler, responsable de operaciones en Aster Labs, confirmó la apertura de una nueva sede."

Ese few-shot reduce un problema habitual: que el modelo devuelva un JSON con claves distintas, añada texto fuera del formato o interprete mal qué entidad corresponde a cada campo. 

Chain of Thought: qué es, para qué sirve y por qué hay que usarlo con criterio

Chain of Thought, o cadena de pensamiento, es una técnica asociada a tareas que requieren razonamiento en varios pasos. La literatura clásica la describe como pedir o demostrar una resolución paso a paso para que el modelo mejore en problemas de razonamiento. OpenAI también ha señalado, en materiales técnicos y guías, que la resolución paso a paso puede mejorar fiabilidad en tareas complejas.

Pero aquí hay un matiz importante: en modelos de razonamiento actuales, OpenAI recomienda no forzar necesariamente una cadena de pensamiento explícita, porque esos modelos ya generan razonamiento interno. La guía para o3/o4-mini lo dice de forma directa: evita chain-of-thought prompting explícito en esos casos y concéntrate más en el objetivo, las restricciones y la verificación del resultado. 

Qué significa esto en la práctica

No significa que el razonamiento paso a paso haya dejado de servir. Significa que hay que distinguir dos cosas distintas:

1. Pedir un resultado razonado o estructurado, útil en muchos casos.
2. Pedir que el modelo exponga toda su cadena interna de pensamiento, algo que no siempre mejora el resultado y que en modelos de razonamiento puede no ser la mejor estrategia. 

Cuándo puede ser útil una estructura paso a paso

• Problemas con varias restricciones simultáneas.
• Tareas de lógica o planificación.
• Casos donde necesitas que el modelo muestre el método, no solo la conclusión.
• Escenarios educativos o de auditoría donde importa la trazabilidad del resultado.

Ejemplo práctico: análisis de una decisión

Antes:

¿Qué opción de proveedor conviene más?

Después con razonamiento estructurado:

Compara estos tres proveedores y recomienda uno.
Evalúa en este orden:
1. precio
2. tiempo de implementación
3. soporte
4. riesgo operativo

Después, entrega:
- una tabla comparativa breve
- una conclusión final en 4 líneas
- una recomendación única

Datos:
[pega aquí los datos]

Este prompt no necesita pedir “piensa paso a paso” de forma literal para obtener una respuesta con estructura de razonamiento. Lo que hace es imponer un proceso visible de evaluación. Eso suele ser más útil que una instrucción abstracta. 

Ejemplo práctico: matemático o lógico

Antes:

Resuelve este problema.

Después:

Resuelve el problema mostrando:
1. datos relevantes
2. fórmula o criterio usado
3. cálculo
4. respuesta final

Problema:
Una empresa vende 120 licencias al mes a 25 euros. Si el próximo trimestre espera crecer un 15% en volumen, ¿cuál será la facturación mensual estimada?

La mejora no proviene solo de “pedir razonamiento”, sino de decir qué forma debe tomar ese razonamiento. Ese detalle cambia mucho la calidad de salida.

Diferencias reales entre zero-shot, few-shot y chain of thought

Las tres técnicas no compiten entre sí como si solo una pudiera usarse. En muchos casos se complementan. Un prompt puede ser zero-shot y funcionar perfectamente. Otro puede necesitar few-shot para fijar estilo o formato. Y otro puede requerir una estructura de razonamiento explícita para no saltarse pasos. La decisión correcta depende del problema, no de la moda del momento. 

Ejemplos de antes y después en tareas reales

1. Redacción de un artículo

Antes:

Escribe un artículo sobre ciberseguridad.

Después:

Escribe un artículo de 1.200 palabras sobre riesgos de ciberseguridad para pymes.
Usa un tono periodístico y directo.
Estructura:
- introducción
- tres riesgos principales
- errores frecuentes
- recomendaciones operativas
Evita lenguaje promocional.
No inventes estadísticas.

Esto sigue siendo zero-shot, pero ya tiene objetivo, audiencia, tono, longitud, estructura y límites. En la mayoría de los casos, ese salto explica una mejora clara sin necesidad de acudir todavía a ejemplos. 

2. Reescritura de titulares con few-shot

Antes:

Mejora estos titulares.

Después:

Reescribe los titulares con un estilo informativo, sobrio y periodístico.
No uses preguntas ni promesas exageradas.

Ejemplo 1
Original: "La herramienta que cambiará tu negocio para siempre"
Reescrito: "Una nueva herramienta empresarial gana terreno en equipos de ventas"

Ejemplo 2
Original: "Nadie te cuenta este secreto de productividad"
Reescrito: "Qué métodos de productividad están adoptando más empresas"

Ahora reescribe:
"El truco definitivo para multiplicar tus resultados con IA"

Aquí el few-shot evita que el modelo responda con otros titulares sensacionalistas. Los ejemplos fijan de forma práctica el estilo que debe sustituir al original. 

3. Toma de decisiones con estructura de razonamiento

Antes:

¿Debemos lanzar este producto?

Después:

Evalúa si conviene lanzar este producto.
Analiza en este orden:
1. demanda potencial
2. coste de adquisición
3. complejidad operativa
4. riesgo competitivo

Entrega:
- una evaluación breve por criterio
- una conclusión final
- recomendación: lanzar / no lanzar / posponer

Datos:
[pega aquí los datos]

El nuevo prompt no es “más bonito”. Es más ejecutable. Obliga al modelo a pasar por criterios definidos y reduce respuestas intuitivas o improvisadas.

Errores frecuentes en prompting avanzado

1. Añadir complejidad demasiado pronto

Uno de los errores más comunes es asumir que todo problema requiere una técnica sofisticada. OpenAI recomienda justo lo contrario: empezar por zero-shot y subir complejidad solo si el caso lo pide. Muchas veces un prompt falla no por falta de few-shot, sino por instrucciones mal escritas. 

2. Usar ejemplos malos en few-shot

Si los ejemplos son inconsistentes, el modelo aprenderá esa inconsistencia. Si cada ejemplo tiene un tono, longitud o criterio distinto, el prompt se vuelve más ambiguo que antes. La demostración debe ser una referencia, no una fuente nueva de ruido. 

3. Pedir cadena de pensamiento como muletilla universal

La idea de “pide que piense paso a paso” se volvió una receta repetida, pero no siempre es la mejor decisión. En modelos de razonamiento, OpenAI señala que esos modelos ya razonan internamente y que conviene enfocarse más en objetivos y restricciones que en exigir una cadena explícita. 

4. No definir el formato de salida

Muchos fallos atribuidos al modelo son en realidad fallos del prompt. Si no defines si quieres una tabla, un JSON, una lista, un párrafo o una recomendación cerrada, el modelo tendrá que decidirlo por su cuenta. Esa libertad rara vez ayuda en tareas operativas. 

5. Escribir prompts largos pero poco específicos

Un prompt extenso no es necesariamente un prompt bueno. A menudo lo decisivo no es la cantidad de texto, sino la claridad de la instrucción, la secuencia lógica de las restricciones y la coherencia entre ejemplo y objetivo. 

Una forma práctica de decidir qué técnica usar

La mejor secuencia de trabajo suele ser esta:

1. Empieza con zero-shot. Formula la tarea con claridad, define formato y restricciones.
2. Si falla el patrón, añade few-shot. No expliques más: demuestra mejor.
3. Si el problema exige varios pasos, estructura el razonamiento. Haz visible el proceso de evaluación o cálculo.
4. Verifica la salida. Un buen prompt también contempla revisión y ajuste. 

Ese enfoque evita dos extremos habituales: el de quien se queda con prompts vagos y el de quien convierte cualquier tarea en una maraña de ejemplos, etiquetas y metainstrucciones. 

Conclusión

Zero-shot, few-shot y chain of thought no son atajos mágicos ni marcas de sofisticación. Son herramientas distintas para problemas distintos. Zero-shot sirve cuando la instrucción ya puede sostener la tarea por sí sola. Few-shot entra cuando el modelo necesita ver el patrón exacto de respuesta. Y chain of thought, usado con criterio, ayuda cuando la tarea requiere una secuencia de razonamiento o una evaluación por pasos. 

La conclusión más útil sigue siendo sencilla: antes de añadir trucos, mejora la especificación. Un prompt claro, bien delimitado y con formato definido suele producir más resultados que una instrucción vaga envuelta en jerga. Y cuando haga falta subir de nivel, conviene hacerlo con método: primero zero-shot, luego few-shot, y después razonamiento estructurado solo si el problema lo exige.