Prompt Engineering: diagnostica el fallo antes de iterar

TL;DR

Qué aprendí	Qué hacer
El modelo puede saber la respuesta y descartarla igualmente	Diagnostica si es un fallo de confianza, no de razonamiento
Más iteraciones en el prompt no siempre ayudan	Identifica el tipo de fallo primero
Hay 4 tipos de fallo distintos con soluciones distintas	Ver tabla de taxonomía más abajo
Los 5 elementos base son necesarios pero no suficientes	Técnica + diagnóstico = resultado

¿Cuándo el problema no es el prompt?

Después de 17 versiones de un prompt para un problema de probabilidad, descubrí algo que cambió mi forma de trabajar con LLMs:

El modelo encontraba la respuesta correcta en su razonamiento… y luego la descartaba por “no ser lo estándar”.

No era un problema de prompt. El modelo sabía la respuesta. Pero no se atrevía a darla. Estaba corrigiendo su propio razonamiento correcto para conformarse con lo que consideraba la respuesta esperada.

Eso no se arregla con más contexto, más ejemplos, ni chain of thought. Se arregla dándole permiso explícito para discrepar de “lo estándar”. El tipo de intervención depende del tipo de fallo — y ahí está la clave que la mayoría de guías de prompt engineering ignora.

El proceso completo está documentado en la serie:

El modelo sabe razonar, no se atreve a elegir — El descubrimiento inicial
Llegó a 0 y lo llamó contradicción — Por qué separar contextos no basta
Más tokens no es mejor resultado — Los límites de la fuerza bruta
El prompt que resuelve problemas ambiguos — La solución: prompt v17b
Taxonomía de fallos de LLMs — Cuándo usar cada técnica

¿Cuáles son los 4 tipos de fallo de un LLM?

Antes de tocar el prompt, identifica cuál de estos cuatro fallos está ocurriendo. Cada uno tiene una solución distinta — mezclarlos es perder el tiempo.

Tipo de fallo	Síntoma observable	Qué hacer
Ambigüedad interpretativa	El modelo elige una lectura del problema y la defiende aunque sea incorrecta	Dale permiso explícito para explorar lecturas alternativas; incluye “si el problema admite más de una interpretación, explóralas”
Cálculo puro	Se equivoca en aritmética, cuentas de fechas, operaciones con muchos pasos	No iteres el prompt: usa herramientas de código (calculadora, code interpreter). El texto no resuelve aritmética por sí solo — el extended thinking ayuda al razonamiento, no al cálculo exacto
Error conceptual	Confunde términos técnicos o aplica un concepto en el dominio equivocado	Da pistas específicas sobre el concepto correcto o cambia a un modelo más capaz
Conocimiento externo	Inventa datos o dice que no sabe algo que requiere información posterior a su entrenamiento	Proporciona búsqueda web o el documento con los datos; no hay prompt que lo resuelva

Por qué importa esto antes de tocar el prompt: En el experimento, las primeras 10 iteraciones asumían que el fallo era de ambigüedad o instrucción insuficiente. No lo era. Era un fallo de confianza: el modelo razonaba bien pero autocorregía su respuesta. Hasta no diagnosticar eso, ningún ajuste de prompt funcionó.

¿Qué elementos tiene un prompt que funciona?

Los fundamentos no han cambiado, pero tienen más sentido ahora que sabes cuándo no son suficientes.

Contexto

Dile al modelo quién eres y qué situación enfrentas. No tiene que ser largo — tiene que ser relevante.

Malo:

¿Cómo optimizo una consulta SQL?

Mejor:

Soy data engineer junior trabajando con PostgreSQL.
Tengo una consulta que tarda 30 segundos en una tabla de 10M de registros.
¿Cómo puedo optimizarla?

Instrucción clara

La instrucción es el núcleo. Necesita verbo de acción, objeto, y restricciones.

[Verbo] + [qué] + [cómo] + [restricciones]

Analiza este código Python
identificando posibles problemas de rendimiento
y sugiere optimizaciones
sin cambiar la lógica del negocio.

Formato de salida

Si no lo especificas, el modelo elegirá. A veces acertará.

Responde en formato JSON con esta estructura:
{
  "resumen": "...",
  "puntos_clave": ["...", "..."],
  "siguiente_paso": "..."
}

Ejemplos (Few-shot)

Mostrar ejemplos es más efectivo que explicar reglas. 2-3 ejemplos suelen ser suficientes.

Clasifica estos tweets por sentimiento.

Ejemplos:
- "Me encanta este producto!" → positivo
- "Pésimo servicio, nunca más" → negativo
- "Llegó el paquete hoy" → neutro

Ahora clasifica:
- "No está mal, pero esperaba más"
- "¡Increíble experiencia!"

Restricciones

Decirle al modelo lo que NO debe hacer es tan importante como lo que sí debe hacer.

- No inventes datos. Si no sabes algo, di "no tengo esa información".
- No uses jerga técnica; el público es no técnico.
- Limítate a los hechos del documento adjunto.

¿Para qué sirve el Chain of Thought?

Pedir que razone paso a paso mejora la precisión en problemas complejos — pero no resuelve fallos de cálculo puro ni de conocimiento externo. Para aplicarlo bien, ayuda entender cómo ‘piensa’ el modelo (Sistema 1 vs Sistema 2) y en qué tipo de tareas cada modo falla.

Sin CoT:

¿Cuántos días hay entre el 15 de marzo de 2024 y el 22 de junio de 2024?

Con CoT:

¿Cuántos días hay entre el 15 de marzo de 2024 y el 22 de junio de 2024?
Piensa paso a paso, contando los días de cada mes.

La versión CoT es más lenta pero más precisa para lógica y razonamiento encadenado. Para aritmética compleja, usa herramientas — CoT no es suficiente.

¿Funciona el roleplay para mejorar las respuestas?

Ajusta el tono y el enfoque, no las capacidades. Un modelo que no sabe matemáticas avanzadas no las aprenderá por fingir ser matemático. Y cuidado con otro efecto colateral: el modelo tiende a darte la razón, especialmente cuando le asignas un rol que “debería” validar tu idea.

Úsalo cuando necesites una perspectiva específica, no para compensar limitaciones reales del modelo.

¿Cómo iterar sin perder el hilo?

Flujo básico:

Prompt inicial → respuesta parcialmente útil
Identificas qué tipo de fallo es (usa la tabla de taxonomía)
Aplicas la intervención correcta para ese tipo
Ajustas formato si es necesario

Lo que NO funciona: seguir añadiendo instrucciones y ejemplos sin diagnosticar primero. Las iteraciones 4 a 12 del experimento cayeron exactamente en esa trampa.

Errores comunes a evitar:

Error	Por qué falla	Qué hacer
Prompt demasiado vago	El modelo llena los huecos a su manera	Especifica objeto, formato y restricciones
15 instrucciones en un prompt	El modelo prioriza algunas e ignora otras	Divide en pasos secuenciales
No especificar formato	El modelo elige, a veces mal	Pide exactamente lo que necesitas
Esperar que “adivine” la ambigüedad	El modelo resuelve la ambigüedad sin avisar	Elimina la ambigüedad antes de enviar
Iterar sin diagnosticar	Más iteraciones del tipo equivocado = más pérdida de tiempo	Diagnostica el tipo de fallo primero

Templates para casos frecuentes

Para análisis de texto:

Analiza el siguiente texto y extrae:
1. Tema principal
2. Tono (formal/informal/técnico)
3. 3 puntos clave
4. Posibles sesgos o limitaciones

Texto:
[pegar texto]

Para revisión de código:

Revisa este código buscando:
1. Bugs o errores lógicos
2. Problemas de rendimiento
3. Violaciones de buenas prácticas
4. Sugerencias de mejora

Prioriza por impacto. No comentes estilo menor.

Código:
[pegar código]

Para resúmenes:

Resume este documento en:
- 1 frase de contexto
- 3-5 bullet points con los puntos clave
- 1 frase de conclusión

Máximo 200 palabras total.

Documento:
[pegar documento]

FAQ

¿Hay palabras “mágicas” que mejoran cualquier prompt? No. “Piensa paso a paso” ayuda en razonamiento encadenado; “responde en JSON” ayuda si necesitas estructura. Pero no hay fórmula universal — el tipo de tarea determina qué funciona.

¿Cuántos ejemplos debo incluir en few-shot? 2-3 suelen ser suficientes. Más ejemplos no siempre mejoran el resultado y añaden coste en tokens. Si el modelo sigue fallando con 3 ejemplos, el problema probablemente no es la cantidad de ejemplos.

¿El roleplay hace al modelo más capaz? No. Ajusta el tono y el estilo de respuesta, no las capacidades subyacentes. No le des un rol para compensar limitaciones reales.

¿Cuándo debo parar de iterar el prompt? Cuando identifiques que el fallo es de tipo 2 (cálculo), 3 (conceptual con modelo incapaz) o 4 (conocimiento externo). En esos casos, más prompt no resuelve el problema.

¿Sirve el system prompt para proyectos largos? Sí. Es la forma más eficiente de mantener contexto persistente sin repetirlo en cada mensaje. Si usas Claude, los Projects hacen esto de forma nativa.

¿Qué significa que el modelo “sepa la respuesta pero no se atreva a darla”? Que en su razonamiento intermedio llega a la conclusión correcta, pero en la respuesta final la descarta para conformarse con lo que considera la respuesta “esperada” o “estándar”. El post sobre sicofancia en LLMs explica el mecanismo con más detalle.

¿Chain of Thought resuelve los problemas de cálculo? No de forma fiable. Para aritmética compleja con muchos pasos, CoT reduce errores pero no los elimina. La solución real es usar herramientas de código o calculadoras — el texto no es el medio adecuado para cálculo preciso.

¿Cómo sé si el fallo es de ambigüedad o de conocimiento externo? Si el modelo da una respuesta coherente pero incorrecta con datos internos que existen, es ambigüedad o error conceptual. Si inventa datos específicos (fechas, nombres, cifras) que deberían ser recientes, es conocimiento externo.

Si buscas ejemplos listos para copiar, tengo 50 prompts probados para ChatGPT que funcionan en cualquier LLM. Y si programas con IA, Cursor lleva el prompting al siguiente nivel integrando el contexto completo de tu proyecto.