Prompt Engineering avanzado: técnicas, formatos y las diferencias reales entre GPT, Gemini y Claude | GHEN

Hay algo que la mayoría de tutoriales de prompt engineering no te cuentan: el mismo prompt, con el mismo contenido, produce resultados distintos dependiendo del modelo al que se lo envíes. No porque uno sea mejor que otro, sino porque cada arquitectura tiene sus propios patrones de entrenamiento, sus propias convenciones y sus propios puntos fuertes.

El propio whitepaper oficial de Google sobre prompt engineering lo reconoce explícitamente: “Los prompts pueden necesitar optimizarse para tu modelo específico, independientemente de si usas Gemini en Vertex AI, GPT, Claude, o un modelo open source como Gemma o LLaMA.”

En esta guía voy a cubrir dos capas. Primero, las técnicas fundamentales que funcionan en todos los modelos, con sus matices de implementación. Después, las diferencias reales en cómo GPT, Gemini y Claude procesan distintos formatos de prompt: XML, Markdown, JSON, YAML y texto plano. Hay una distinción crítica que la mayoría de comparativas ignora.

Con fuentes. Porque hay demasiada opinión y poco rigor en este campo.

Qué es realmente el prompt engineering

El prompt engineering no es “hablar bien con la IA”. Es entender que un modelo de lenguaje, en el fondo, hace una sola cosa: predecir el token más probable dado el contexto. Cuando diseñas un prompt, estás configurando ese contexto para que la distribución de probabilidad se desplace hacia la salida que necesitas.

Esto tiene implicaciones prácticas inmediatas:

El orden de la información importa (lo que está al final tiene más peso en modelos tipo GPT por efecto de recencia)
El formato del prompt influye en el formato de la respuesta
Los ejemplos en el contexto son instrucciones implícitas mucho más potentes que las instrucciones explícitas
Los parámetros de configuración: temperatura, top-K, top-P, interactúan entre sí y afectan al comportamiento de formas contraintuitivas

El prompt engineering es también un proceso iterativo. Como indica el whitepaper de Google, “prompts inadecuados pueden llevar a respuestas ambiguas e imprecisas, e inhibir la capacidad del modelo de producir output significativo.”

Las técnicas fundamentales

Estas funcionan con GPT, Gemini y Claude. Las diferencias de implementación vienen después.

Zero-shot prompting

La instrucción sin ejemplos. El modelo infiere el comportamiento a partir del entrenamiento previo.

Clasifica el sentimiento de este texto como positivo, negativo o neutro:
"El producto llegó tarde y estaba defectuoso."

Funciona bien para tareas sencillas y bien definidas. Para tareas complejas o con requisitos de formato específico, necesitas más estructura.

Few-shot prompting (aprendizaje con pocos ejemplos)

Proporcionas 2-5 pares de entrada/salida que muestran el patrón deseado. La investigación de Min et al. (2022) demostró algo contraintuitivo: lo que más importa es la distribución del espacio de etiquetas y el formato, más que la corrección de las etiquetas individuales. Los modelos modernos son robustos a ejemplos imperfectos siempre que el patrón sea consistente.

Titular: "La Copa del Rey ya tiene campeón"
Categoría: Fútbol

Titular: "El Ibex 35 cierra con pérdidas del 2%"
Categoría: Economía

Titular: "Nadal anuncia su retirada definitiva"
Categoría: Tenis

Titular: "El Barça ficha a un nuevo portero"
Categoría:

El whitepaper de Google recomienda empezar con 6 ejemplos para few-shot en tareas de clasificación. Además, mezcla las clases en el orden de los ejemplos; si todos los ejemplos positivos van juntos y los negativos juntos, el modelo puede sobreajustarse al orden en lugar de aprender la distinción de clase.

Chain of Thought (CoT)

Le pides al modelo que razone paso a paso antes de dar la respuesta. Wei et al. (2022) establecieron que CoT solo produce ganancias consistentes en modelos de ~100B parámetros o más. En modelos más pequeños puede degradar el resultado.

La forma más sencilla (zero-shot CoT):

Cuando tenía 3 años, mi pareja tenía el triple de mi edad. Ahora tengo 20 años.
¿Cuántos años tiene mi pareja? Piensa paso a paso.

La forma más potente combina CoT con few-shot (single-shot CoT):

P: Cuando mi hermano tenía 2 años, yo tenía el doble de su edad. Ahora tengo 40.
¿Cuántos años tiene mi hermano? Piensa paso a paso.

R: Cuando mi hermano tenía 2 años, yo tenía 4. Diferencia: 2 años, y yo soy mayor.
Ahora tengo 40, así que mi hermano tiene 40 - 2 = 38 años. La respuesta es 38.

P: Cuando tenía 3 años, mi pareja tenía el triple de mi edad. Ahora tengo 20 años.
¿Cuántos años tiene mi pareja? Piensa paso a paso.

R:

Regla de oro de CoT (Google whitepaper): Pon siempre el razonamiento antes de la respuesta —la generación del razonamiento cambia la distribución de tokens del modelo para predecir la respuesta final—. Y establece temperatura a 0 para CoT: hay una respuesta correcta única, no queremos variabilidad.

Self-consistency

Extensión de CoT que combina muestreo y votación mayoritaria. En lugar de generar una sola cadena de razonamiento, generas múltiples con temperatura alta y tomas la respuesta más frecuente. Mejora la precisión a costa de aumentar el coste de inferencia. Útil para tareas donde la incertidumbre es alta y el coste de errores es mayor que el coste computacional.

Step-back prompting

Técnica documentada en el whitepaper de Google (Zheng et al., 2023). Antes de responder la pregunta específica, le pides al modelo que considere una pregunta general relacionada:

Paso 1 — Pregunta general:

Basándote en los géneros de videojuegos de éxito, ¿cuáles son los 5 escenarios ficticios
que mejor funcionan para un nivel de un FPS desafiante y atractivo?

Paso 2 — Usar el contexto generado en la pregunta específica:

Contexto: [respuesta del paso 1]

Usando uno de esos escenarios, escribe un párrafo de storyline para un nuevo nivel
de FPS que sea desafiante y atractivo.

El “paso atrás” activa conocimiento de fondo relevante en los parámetros del modelo antes de abordar el problema específico. Reduce alucinaciones en tareas que requieren razonamiento sobre principios generales.

Tree of Thoughts (ToT)

Generalización de CoT (Yao et al., 2023). En lugar de una cadena lineal de razonamiento, el modelo explora simultáneamente múltiples rutas de razonamiento como un árbol. Especialmente adecuado para tareas complejas que requieren exploración y planificación. Su implementación requiere código —no es una técnica de prompt puro—, pero se puede aproximar con prompts que piden al modelo explorar varias hipótesis antes de converger en una respuesta.

ReAct (Reason & Act)

Paradigma que combina razonamiento en lenguaje natural con el uso de herramientas externas (búsqueda web, intérprete de código, APIs). El modelo razona, actúa, observa el resultado, y actualiza su razonamiento en un bucle. Es la base de los sistemas agénticos modernos. Los tres modelos soportan ReAct a través de tool use / function calling en sus respectivas APIs.

Automatic Prompt Engineering (APE)

Usar el propio modelo para generar y evaluar variantes de prompts. El proceso:

Genera 10+ variantes del prompt con diferentes formulaciones
Evalúa cada variante con métricas objetivas (BLEU, ROUGE, o con un LLM juez)
Selecciona y refina las mejores variantes
Repite

Especialmente útil cuando el volumen de iteración manual sería prohibitivo.

Role prompting

Asignar un rol mejora la consistencia y el tono. El whitepaper de Google incluye estilos útiles para los roles: confrontacional, descriptivo, directo, formal, humorístico, influyente, informal, inspiracional, persuasivo. No es solo “eres un experto en X” —el estilo del rol también es un vector de control.

Eres un guía de viajes con estilo humorístico e irreverente.

Especificación de output

Decirle al modelo exactamente qué formato quieres en la salida. El consenso entre los tres modelos es el mismo: usa instrucciones positivas, no restricciones negativas.

Menos efectivo:

No uses listas. No uses markdown.

Más efectivo:

Tu respuesta debe estar compuesta por párrafos de prosa fluida. Sin listas. Sin encabezados.

La diferencia crítica que nadie explica: XML en el prompt vs XML en el output

Aquí está el error más común en los artículos que comparan formatos entre modelos. Hay una distinción fundamental que se mezcla constantemente:

XML como estructura del prompt (las instrucciones que envías al modelo)
XML como formato del output (la respuesta que recibes del modelo)

Estos son casos de uso completamente distintos, y cada modelo los adopta de formas diferentes.

Claude y XML: estructura del prompt

Anthropic recomienda explícitamente el uso de etiquetas XML en el cuerpo del prompt para Claude. No para el output —para el input. La razón es técnica: Claude ha sido entrenado con grandes cantidades de datos que incluyen XML, y el formato le permite delimitar sin ambigüedad secciones del contexto mezcladas en el mismo mensaje.

La documentación oficial lo dice: “XML tags help Claude parse complex prompts unambiguously, especially when your prompt mixes instructions, context, examples, and variable inputs.”

<instrucciones>
Eres un analista de contenido. Extrae entidades del artículo y clasifícalas por tipo.
</instrucciones>

<formato_salida>
JSON con esta estructura:
{
  "personas": [],
  "organizaciones": [],
  "lugares": [],
  "fechas": []
}
</formato_salida>

<articulo>
{{ARTICULO}}
</articulo>

Las etiquetas más útiles en Claude:

<instrucciones>, <contexto>, <input>, <ejemplos>, <formato_salida>
<documents> con <document index="n"> para múltiples documentos
<thinking> y <answer> para separar razonamiento de respuesta en CoT
<example> / <examples> para few-shot

Beneficio documentado: En contextos largos (20K+ tokens), colocar la query al final con el contenido en etiquetas XML mejora la calidad de respuesta hasta un 30% en las pruebas de Anthropic.

La sintaxis de variables en Claude sigue la convención {{VARIABLE}} (doble llave).

Gemini y JSON/XML: formato del output

Gemini usa un enfoque diferente. El whitepaper oficial de Google (Lee Boonstra, 2025) recomienda JSON y XML como formatos de output, no como estructura del prompt en sí. La recomendación es:

“Para tareas no creativas como extraer, seleccionar, parsear, ordenar, rankear o categorizar datos, prueba a devolver el output en un formato estructurado como JSON o XML.”

Y los beneficios que cita son para el output: responde siempre en el mismo estilo, foco en los datos que quieres recibir, menos posibilidad de alucinaciones, tipado de datos y capacidad de ordenar resultados.

Para el prompt en sí, Gemini favorece texto directo y claro, con variables en formato {variable} (llave simple):

VARIABLES
{ciudad} = "Madrid"

PROMPT
Eres una guía de viajes. Dime un dato curioso sobre: {ciudad}

Gemini también soporta JSON Schema para el input —proporcionar la estructura esperada de los datos como contexto para el modelo, especialmente útil en pipelines de datos complejos.

Advertencia del whitepaper de Google: El output JSON consume significativamente más tokens que texto plano, lo que impacta en coste y tiempo de respuesta. Si el output es truncado por límite de tokens, el JSON queda inválido. Para esto recomiendan la librería json-repair (PyPI).

GPT y Markdown/separadores: claridad estructural

La documentación de Azure OpenAI para GPT no tiene una preferencia tan fuerte como las otras dos. La recomendación es usar lo que aporte claridad: “Si no estás seguro de qué sintaxis usar, considera Markdown o XML. Los modelos se han entrenado con grandes cantidades de contenido web en ambos formatos.”

Lo que sí es específico de GPT:

Separadores (---) entre secciones del prompt para reducir ambigüedad
Variables en mayúsculas para distinguirlas del resto del texto (convención, no requisito)
Tablas son más eficientes en tokens que JSON para datos relacionales
Priming de output: incluir las primeras palabras de la respuesta esperada al final del prompt para guiar el formato

PÁRRAFO:
John Smith trabaja en Microsoft y tiene cinco hijos.
---
INSTRUCCIÓN:
Extrae los hechos verificables del párrafo anterior.
---
AFIRMACIONES OBJETIVAS:
1.

GPT también tiene un efecto documentado de sesgo de recencia: la información al final del prompt tiene más influencia sobre el output. Por tanto, si hay instrucciones críticas, repítelas al final del prompt además de al inicio.

YAML: el caso de uso legítimo

YAML tiene un nicho específico: system prompts y configuraciones donde la legibilidad humana importa más que la eficiencia.

rol: analista de datos senior
expertise:
  - Python
  - SQL
  - visualización de datos
tono: técnico pero accesible
idioma: español (España)
restricciones:
  - Sin código excepto si se solicita
  - Respuestas máximo 200 palabras

GPT maneja YAML bien en system prompts —fue entrenado con cantidades masivas de código y configuraciones técnicas en YAML. Es válido para system prompts de aplicaciones donde el prompt es mantenido por un equipo de desarrollo.

Claude lo procesa correctamente, pero para prompts complejos en producción las etiquetas XML son más robustas y consistentes con el entrenamiento del modelo.

Gemini acepta YAML, pero el whitepaper no lo menciona. Para inputs estructurados, recomienda JSON Schema sobre YAML.

Comparativa directa: la misma tarea en los tres modelos

La tarea: analizar una reseña de producto y extraer sentimiento + aspectos mencionados.

Prompt óptimo para Claude

<instrucciones>
Analiza la siguiente reseña de producto. Identifica:
1. El sentimiento general (positivo, negativo, mixto)
2. Los aspectos específicos mencionados y si son positivos o negativos
</instrucciones>

<formato_salida>
JSON con esta estructura exacta:
{
  "sentimiento_general": "positivo|negativo|mixto",
  "aspectos": [
    {"aspecto": "", "valoracion": "positivo|negativo|neutro"}
  ]
}
</formato_salida>

<resena>
{{RESENA}}
</resena>

Prompt óptimo para GPT

Eres un analista de reseñas de producto especializado en análisis de sentimiento.

TAREA: Analiza la siguiente reseña e identifica el sentimiento general y los aspectos
específicos mencionados.

FORMATO DE SALIDA:
Devuelve exclusivamente JSON válido con esta estructura:
{
  "sentimiento_general": "positivo|negativo|mixto",
  "aspectos": [
    {"aspecto": "", "valoracion": "positivo|negativo|neutro"}
  ]
}

---
RESEÑA:
[CONTENIDO DE LA RESEÑA AQUÍ]
---

Responde solo con el JSON. Sin texto adicional.

Prompt óptimo para Gemini

Eres un analista de reseñas de producto.

Analiza la siguiente reseña y devuelve el resultado en JSON con este schema:

{
  "sentimiento_general": "positivo|negativo|mixto",
  "aspectos": [{"aspecto": string, "valoracion": "positivo|negativo|neutro"}]
}

Reseña:
{resena}

Devuelve solo el JSON válido.

Las diferencias revelan los principios de cada modelo:

Claude estructura con XML para delimitar secciones; usa {{VARIABLE}} para las partes dinámicas; el JSON va dentro de la etiqueta de instrucciones como especificación de formato
GPT usa separadores --- para delimitar el contenido del contexto; variables implícitas por posición; las instrucciones de formato preceden al contenido
Gemini no requiere estructura formal en el prompt; pasa el schema JSON como referencia directa; usa {variable} para las partes dinámicas; pide el JSON en el output sin estructurar el input con XML

Los parámetros de configuración: dónde las diferencias son reales

Temperature

El parámetro más importante. Controla la aleatoriedad de la generación.

Modelo	Rango	Para análisis	Para creatividad	Nota clave
GPT	0-2	0.1-0.3	0.7-1.2	Rango extendido hasta 2
Claude	0-1	0	0.7-1.0	Rango estándar 0-1
Gemini	0-1+	0 para CoT	1.0 default	En v3: bajar de 1.0 puede causar comportamientos inesperados

La advertencia de Gemini 3 sobre temperatura es relevante. El whitepaper de Google la menciona explícitamente: “Changing the temperature (setting it below 1.0) may lead to unexpected behavior.” Para obtener outputs JSON deterministas en Gemini, la solución correcta es usar responseMIMEType: "application/json" en la API, no bajar la temperatura.

Top-K y Top-P

Los tres modelos usan nucleus sampling pero con configuraciones default distintas. Para Gemini, el whitepaper proporciona puntos de partida concretos:

Tareas estándar: temperature 0.2, Top-P 0.95, Top-K 30
Resultados más creativos: temperature 0.9, Top-P 0.99, Top-K 40
Resultados menos creativos: temperature 0.1, Top-P 0.9, Top-K 20

La regla universal: ajusta o temperatura o Top-P, no ambos a la vez. Si temperatura = 0, Top-K y Top-P son irrelevantes.

Structured outputs (nivel API)

Para garantizar JSON válido en el output, cada modelo tiene su mecanismo nativo:

GPT: response_format: { type: "json_object" }
Claude: Structured Outputs + instrucciones en el prompt
Gemini: responseMIMEType: "application/json" en GenerateContentConfig

Tabla de referencia rápida

Técnica / Formato	GPT	Claude	Gemini
XML en el prompt (estructura)	Funciona, no es nativo	Recomendado oficialmente	No documentado
XML en el output (formato)	Funciona	Funciona	Recomendado junto a JSON
Markdown en el prompt	Estándar	Funciona (afecta formato del output)	Funciona bien
JSON schema en el prompt	Funciona	Funciona en instrucciones	Recomendado para input estructurado
YAML en system prompt	Válido	Válido, XML preferible	Funciona, no documentado
Separadores (`---`)	Recomendados oficialmente	Menos necesarios con XML	Útiles pero no requeridos
Variables en el prompt	Convención libre	`{{VARIABLE}}`	`{variable}`
Query al final (contexto largo)	Ayuda (sesgo recencia)	Mejora hasta 30%	Recomendado
Few-shot (nº de ejemplos)	3-5	3-5, en `<example>` tags	6 como punto de partida; mezclar clases
Chain of Thought	“Piensa paso a paso”	`<thinking>` tags	“Piensa paso a paso” + temp=0
Self-consistency	Soportado	Soportado	Documentado en whitepaper
Step-back prompting	Soportado	Soportado	Documentado oficialmente
Temperature para CoT	0	0	0 (explícito en whitepaper)
JSON garantizado en output	`response_format` en API	Structured Outputs API	`responseMIMEType` en API
Thinking / reasoning	o-series models	`<thinking>` / adaptive	Thinking levels (low/mid/high)

Lo que esto significa en la práctica

Si trabajas con un solo modelo, adapta tu estilo al nativo:

Claude en producción: Invierte en una biblioteca de etiquetas XML consistente. Define una vez tu estructura de <instrucciones>, <contexto>, <input> y reutilízala como plantilla. Los modelos Claude 4.x siguen instrucciones con precisión alta —no necesitas técnicas agresivas.

GPT en producción: Los separadores claros (---) y las instrucciones en el system prompt con Markdown estructurado son tu mejor herramienta. Para JSON garantizado usa response_format: json_object en la API. Ten en cuenta el sesgo de recencia: repite instrucciones críticas al final del prompt.

Gemini en producción: Instrucciones directas y claras. No sobre-ingenierices el formato del prompt. Para outputs estructurados usa responseMIMEType en la API. Para CoT, temperatura a 0. Usa JSON Schema para estructurar el input cuando trabajas con datos complejos.

Si trabajas con múltiples modelos: Lo más pragmático es usar Markdown con separadores claros y, para prompts complejos, XML ligero. Ambos funcionan aceptablemente en los tres modelos aunque no sean igualmente óptimos en cada uno.

Un punto de proceso que pocas guías mencionan

El whitepaper de Google incluye una recomendación genuinamente útil que se ignora sistemáticamente: documenta cada intento de prompt en una tabla estructurada con estos campos:

Campo	Descripción
Nombre/Versión	Identificador del intento
Objetivo	Una frase de qué intentas conseguir
Modelo	Nombre y versión exacta
Temperature	Valor usado
Token Limit	Límite de tokens de output
Top-K / Top-P	Valores usados
Prompt	El prompt completo
Output	La respuesta obtenida
Resultado	OK / NOT OK / A VECES

La razón es práctica: los outputs varían entre modelos, entre versiones del mismo modelo, y a veces entre ejecuciones idénticas. Sin documentación, el trabajo de prompt engineering es irreproducible. Con documentación, puedes comparar versiones, diagnosticar regresiones cuando el modelo se actualiza, y reutilizar lo que funcionó.

Conclusión

El prompt engineering es un campo donde la práctica supera a la teoría. Pero entender por qué ciertos formatos funcionan mejor en ciertos modelos —y no solo que funcionan— te da ventaja real para diseñar prompts que escalen.

El resumen que me llevo de revisar las documentaciones oficiales de los tres modelos:

Claude habla XML en el input. Las etiquetas son la gramática nativa para estructurar el contexto. Si usas Claude en producción y no usas XML en el prompt, estás dejando rendimiento sobre la mesa.

Gemini habla JSON en el output. El formato de la respuesta es donde Google pone énfasis en la estructura. El prompt puede ser texto directo y claro. Para CoT: temperatura cero siempre.

GPT habla Markdown con separadores. Es el más agnóstico en cuanto a formato del prompt, pero el más sensible al orden —el sesgo de recencia es real y documentado.

No hay un formato universal óptimo. Hay formatos óptimos para cada contexto.

Fuentes

Microsoft Azure — Técnicas de ingeniería de prompts para GPT
Documentación oficial de Azure OpenAI / Microsoft Foundry — Actualizada: marzo 2026
https://learn.microsoft.com/es-es/azure/foundry/openai/concepts/prompt-engineering
Anthropic — Prompting Best Practices para Claude
Documentación oficial de Anthropic — Claude Opus 4.6, Sonnet 4.6, Haiku 4.5
https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
Google AI Dev — Gemini Prompting Strategies
Documentación oficial de la Gemini API
https://ai.google.dev/gemini-api/docs/prompting-strategies
Lee Boonstra (Google) — Prompt Engineering Whitepaper v7
Google, febrero 2025
Wei, J. et al. (2022) — Chain-of-Thought Prompting Elicits Reasoning in Large Language Models
NeurIPS 2022 — https://arxiv.org/pdf/2201.11903.pdf
Min, S. et al. (2022) — Rethinking the Role of Demonstrations for Few-Shot Prompting
EMNLP 2022 — https://arxiv.org/abs/2202.12837
Zheng, L. et al. (2023) — Take a Step Back: Evoking Reasoning via Abstraction in Large Language Models
https://arxiv.org/abs/2310.06117
Wang, X. et al. (2023) — Self-Consistency Improves Chain of Thought Reasoning in Language Models
https://arxiv.org/pdf/2203.11171.pdf
Yao, S. et al. (2023) — Tree of Thoughts: Deliberate Problem Solving with Large Language Models
https://arxiv.org/pdf/2305.10601.pdf
Yao, S. et al. (2023) — ReAct: Synergizing Reasoning and Acting in Language Models
https://arxiv.org/pdf/2210.03629.pdf