Por PromptRentable 
Hay una fase por la que pasa casi todo el mundo que trabaja con IA de forma seria: la fase del «a ver qué sale». Escribes un prompt, el resultado es bueno, lo celebras. Escribes el mismo prompt al día siguiente y el resultado es completamente diferente. No entiendes por qué y empiezas a pensar que estos modelos son impredecibles por naturaleza.
No lo son. Lo que pasa es que no has configurado las condiciones para que se comporten de forma predecible. Y eso es algo que puedes controlar, tanto desde los parámetros técnicos de la API como desde el propio prompt si no tienes acceso a esos parámetros.
Este artículo es lo que aprendí cuando pasé de usar la IA de forma casual a integrarla en flujos de trabajo reales donde los errores tenían consecuencias. No es teoría, es lo que uso cada día.
El primer problema: la temperatura y por qué importa más de lo que parece
Cuando la gente habla de que la IA «alucina» o da respuestas inconsistentes, la mayoría de las veces el problema tiene una causa técnica muy concreta: la temperatura está demasiado alta.
La temperatura es un parámetro que controla cuánta aleatoriedad introduce el modelo en sus respuestas. Una temperatura de 0 hace que el modelo elija siempre la opción estadísticamente más probable, lo que produce resultados muy consistentes pero a veces un poco planos. Una temperatura alta hace que el modelo explore opciones menos probables, lo que genera creatividad pero también inconsistencia.
Para tareas donde necesitas precisión, como extracción de datos, generación de código o respuestas factuales, temperatura baja o cero. Para tareas creativas donde quieres variedad, temperatura más alta. El error clásico es usar temperatura alta para todo por defecto y luego frustrarse con los resultados impredecibles.
Si trabajas directamente con la API, esto lo controlas con un parámetro. Si usas interfaces de chat, puedes simularlo en el propio prompt siendo muy explícito y restrictivo en las instrucciones: «responde únicamente con los datos solicitados, sin interpretaciones ni añadidos». Esa instrucción empuja al modelo hacia comportamientos más deterministas aunque no tengas acceso al parámetro técnico.
Hay otra forma de controlar esto que muy poca gente usa: el logit bias. Es un mecanismo que permite aumentar o reducir la probabilidad de que el modelo use ciertas palabras. Lo uso para eliminar muletillas de IA que delatan que el texto es generado, frases como «en el vasto panorama de» o «es importante destacar que». Con logit bias puedes penalizar esas palabras directamente en lugar de pedirle al modelo que las evite, que es mucho menos fiable.
Por qué necesitas que la IA te devuelva JSON y no texto
Este es el cambio que más impacto tuvo en mis flujos de trabajo cuando lo adopté: dejar de pedir texto libre y empezar a pedir datos estructurados.
El problema del texto libre es que es imposible procesarlo de forma automática de forma fiable. Si le pides a la IA que analice diez documentos y te diga si cada uno es positivo, neutro o negativo, y te los devuelve como párrafos de texto, tienes que leer esos párrafos para extraer la clasificación. Si te los devuelve como JSON con un campo «sentimiento» con valores «positivo», «neutro» o «negativo», puedes procesarlos automáticamente sin leer nada.
La clave es ser muy explícito en el prompt sobre la estructura exacta que quieres. No «responde en JSON», sino definir el schema completo:
«Responde exclusivamente con un objeto JSON con esta estructura exacta: {«documento_id»: string, «sentimiento»: «positivo»|»neutro»|»negativo», «confianza»: number entre 0 y 1}. No incluyas ningún texto fuera del JSON.»
Cuanto más específico seas con el schema, menos variación habrá en los outputs. Y añadir un campo de «confianza» es una práctica que recomiendo siempre: le pides al modelo que te diga cuánta certeza tiene en su respuesta. Cuando la confianza es baja, puedes marcarlo para revisión humana en lugar de aceptarlo automáticamente.
El árbol de pensamientos: cuando una solución no es suficiente
Hay problemas donde la primera respuesta que genera la IA no es la mejor, pero tampoco es obvio cuál sería mejor. Para estos casos existe una técnica llamada árbol de pensamientos, que es básicamente pedirle al modelo que explore varias soluciones antes de decidirse por una.
En lugar de «resuelve este problema», le dices: «genera tres enfoques posibles para resolver este problema, evalúa los pros y contras de cada uno, y luego elige el que tiene más probabilidades de éxito explicando por qué descartaste los otros dos».
Lo uso mucho cuando estoy diseñando la arquitectura de un flujo de trabajo o cuando necesito tomar una decisión con múltiples variables. El modelo a veces llega a soluciones que yo no habría considerado, y el proceso de evaluación que hace antes de elegir es frecuentemente más útil que la respuesta final en sí.
Para tareas creativas también funciona bien: pide tres enfoques narrativos para un texto, tres estructuras posibles para un artículo, tres ángulos para abordar un tema. Luego tú eliges o combinas elementos de los distintos enfoques. Es una forma de usar la IA como un colaborador que genera opciones en lugar de como un ejecutor que toma decisiones.
RAG: cuando necesitas que la IA trabaje con tus propios datos
RAG significa Retrieval-Augmented Generation, y es la técnica que permite que un modelo de lenguaje trabaje con información que no estaba en su entrenamiento original: tus documentos, tu base de conocimiento, los datos de tu empresa.
La idea básica es sencilla: antes de enviarte el prompt al modelo, el sistema busca en tu base de datos los fragmentos de texto más relevantes para esa consulta y los incluye como contexto. El modelo entonces responde usando tanto su conocimiento general como esa información específica que le has proporcionado.
Lo que muy poca gente hace bien es la parte de preparación de los datos. La mayoría sube documentos enteros y espera que funcione. El problema es que los fragmentos demasiado largos incluyen mucho ruido junto con la información relevante, y los fragmentos demasiado cortos pierden el contexto necesario para entender el dato.
Lo que funciona mejor es fragmentar por unidades semánticas, no por longitud fija. Un párrafo completo suele ser una buena unidad. Una sección con su título es mejor todavía. Y añadir metadatos a cada fragmento (a qué documento pertenece, de qué fecha es, qué sección) permite hacer filtrados antes de enviar el contexto al modelo, lo que reduce el ruido considerablemente.
Una técnica adicional que mejora mucho los resultados es el re-ranking: una vez que el sistema ha recuperado los diez fragmentos más relevantes, usas un segundo paso para ordenarlos por relevancia real antes de enviárselos al modelo. Los primeros de la lista reciben más atención del modelo, así que quieres que sean los más útiles para esa consulta concreta.
Cómo depurar un prompt que no funciona
Cuando un prompt da resultados malos, el instinto es cambiarlo todo a la vez. Es el error más común y el que más tiempo hace perder.
Lo que funciona es tratar el debugging de prompts exactamente igual que el debugging de código: cambiar una sola variable cada vez y medir el resultado. Si cambias la instrucción principal, el formato de salida y el tono en el mismo intento, no sabes qué cambio produjo la mejora.
Mi proceso cuando algo no funciona es crear un conjunto pequeño de entradas de prueba, entre cinco y diez, que cubran los casos típicos y los casos límite. Luego cambio un elemento del prompt, paso todas las entradas de prueba y mido cuántas dan el resultado correcto. Si la tasa de éxito sube, el cambio era bueno. Si no sube o baja, lo descarto.
Parece lento comparado con simplemente probar cosas al azar, pero en la práctica es mucho más rápido porque cada intento te da información real sobre qué está causando el problema.
Memoria sintética: cómo hacer que la IA recuerde conversaciones anteriores
Los modelos de lenguaje no tienen memoria entre sesiones. Cada conversación empieza desde cero. Pero hay una forma de simular esa memoria que funciona sorprendentemente bien: resumir las conversaciones anteriores e inyectar ese resumen como contexto al inicio de cada nueva sesión.
Al final de cada conversación importante, le pido al modelo que genere un resumen compacto de los puntos clave: decisiones tomadas, preferencias expresadas, información relevante sobre el proyecto. Ese resumen lo guardo y lo incluyo al inicio de la siguiente sesión con una instrucción simple: «este es el contexto de conversaciones anteriores con este usuario».
No es memoria real, pero el resultado práctico es muy similar. El modelo tiene acceso a lo que importaba de las interacciones previas sin necesidad de repetir todo el historial, que consumiría demasiados tokens.
Combinado con RAG para información estructurada y JSON para outputs procesables, esto forma la base de cualquier sistema de IA que necesite funcionar de forma fiable a lo largo del tiempo.
Lo que separa usar IA de forma amateur de usarla profesionalmente
No es la creatividad de los prompts ni el conocimiento de técnicas avanzadas. Es la disciplina de medir. Los profesionales tienen benchmarks, tienen conjuntos de prueba, saben exactamente cuál es la tasa de éxito de cada componente de su sistema y cuándo ha empeorado.
La IA sin medición es superstición. Cambias cosas y crees que mejoran porque los últimos resultados parecen mejores, pero no tienes datos reales. Con medición, sabes exactamente qué funciona, por qué funciona y cuándo deja de funcionar.
Esa disciplina es lo que más me ha costado construir y lo que más diferencia hace en la calidad de los resultados.