Por qué la IA no te da lo que quieres

Casi todo el que trabaja a diario con un modelo de lenguaje ha vivido la misma escena. Le pides algo, te devuelve un texto impecable, bien escrito, correcto, y no te sirve. La reacción instintiva es siempre la misma: activar el modo razonamiento, pedirle que piense más, plantearte cambiar de modelo.

Y casi nunca funciona, porque el fallo rara vez estaba donde miras.

Detrás de cualquier encargo a una IA hay tres operaciones distintas, y las tratamos como si fueran una sola. Especificar es que entienda lo que ya quieres. Explorar es que te enseñe opciones que no sabías que existían. Ejecutar es que lo haga bien.

Son independientes: puedes acertar en una y fallar de lleno en otra. Puedes tener un encargo perfectamente definido y una ejecución nefasta. Puedes recibir una ejecución impecable de un encargo que no era el tuyo. Y puedes acertar en las dos cosas y no enterarte nunca de que existía una tercera vía mejor.

Cada una falla de una forma distinta y se arregla con un remedio distinto. El error caro, el que se comete todos los días, es aplicar el remedio de una a un fallo de otra.

Eje 1: especificar, que entienda lo que ya quieres

El síntoma es reconocible al instante: pides algo y recibes una respuesta correcta pero genérica, la que está bien escrita, no se moja y no te sirve para nada.

No es que el modelo sea torpe. Es que tu petición admite muchas interpretaciones razonables y el modelo no elige una: te devuelve algo parecido al promedio de todas. Ese promedio es exactamente lo que reconocemos como "respuesta de manual".

Piensa en un encargo tan común como «hazme un plan de sesiones para mi equipo». Ahí dentro caben cientos de encargos distintos, todos defendibles. ¿Para quién es? ¿Cuánto ocupa? ¿Qué nivel técnico asume? ¿En qué formato sale? ¿Con qué tono? ¿Hasta dónde llega? ¿Cómo sabremos que ha quedado bien? El modelo no adivina ninguna de esas cosas: las mezcla todas.

Y lo importante es que el fallo no es proporcional, sino multiplicativo. Si el modelo acierta cuatro de cada cinco veces en cada una de esas decisiones por separado, algo bastante generoso, la probabilidad de que acierte en todas a la vez cae a poco más de una de cada seis. Por eso la experiencia resulta tan desconcertante: el modelo parece competente en cada frase, porque lo es, pero tú solo ves el resultado agregado.

El remedio es que te haga preguntas antes de empezar. No es cortesía con la máquina: es que cada respuesta que le das elimina de golpe un montón de interpretaciones.

La instrucción que converge

Antes de ejecutar, hazme las 3 preguntas cuya respuesta más cambiaría el resultado final. Solo preguntas donde no puedas anticipar mi respuesta, que yo pueda contestar, y que no estén ya en este encargo. Espera mis respuestas antes de empezar.

Cada línea hace un trabajo concreto. «La que más cambiaría el resultado» descarta el detalle irrelevante. «Donde no puedas anticipar mi respuesta» evita que te pregunte lo que ya sabe. «Que yo pueda contestar» impide ese interrogatorio incómodo sobre cosas que tú tampoco sabes. Y el límite de tres es lo que separa una conversación útil de un formulario.

Pocas preguntas y bien apuntadas ganan a muchas.

Preguntar antes no es lo mismo que corregir después

La objeción razonable es «ya se lo corrijo en el siguiente mensaje». Misma información, distinto orden, ¿qué más da?

Da mucho. Estos modelos generan palabra a palabra, condicionados por todo lo que ya han escrito. En cuanto fijan una interpretación en los primeros párrafos, esa interpretación entra a formar parte del contexto y sesga todo lo que viene detrás. El error no se diluye a lo largo del texto: se amplifica.

Cuando preguntas antes, la información entra en un contexto limpio. Cuando corriges después, tu corrección compite contra dos mil palabras de compromiso ya escrito. No es la misma jugada.

Hay un caso, eso sí, en el que esto no aplica: si lo que pides tiene una única respuesta correcta, un cálculo cerrado o una traducción literal, no hay nada que preguntar. Ahí preguntar es puro coste.

Eje 2: explorar, que te enseñe lo que no sabías que había

Aquí está la parte que casi nadie separa, y es la más valiosa.

Todo lo anterior asume que tú sabes lo que quieres y el problema es transmitirlo. En buena parte de los casos reales eso es falso. Cuando el tema es complejo y estás empezando, no tienes una intención clara: tienes una idea vaga. No hay nada que transmitir, porque todavía no lo has formado.

Lo que necesitas del modelo entonces no es que adivine lo que quieres, sino que te enseñe el mapa del terreno para que descubras dónde quieres estar.

Un ejemplo que lo deja claro

Alguien tiene que montar cuatro sesiones de formación interna sobre una herramienta que el equipo acaba de empezar a usar. Lo encarga con todo el detalle bien puesto: catorce personas de perfil no técnico, sesiones de noventa minutos, nada de teoría, que salgan sabiendo hacer tres cosas concretas, en formato de guion para quien imparte.

Está impecablemente especificado. Con la instrucción convergente de antes, el modelo devuelve tres preguntas razonables: si las sesiones son consecutivas o semanales, si hay un entorno de pruebas disponible, si quien imparte ya conoce la herramienta o va a aprenderla sobre la marcha. Las tres mejoran el material. Ninguna toca el fondo.

Con una instrucción de exploración aparece otra cosa muy distinta. Entre las decisiones que el modelo señala como críticas hay una que nadie había formulado: ¿el problema del equipo es que no sabe usar la herramienta, o que no sabe cuándo usarla?

Son dos formaciones incompatibles. Una es formación de producto: clics, funciones, práctica guiada. La otra es criterio de decisión: en qué situaciones esta herramienta es la buena y en cuáles vas a perder la tarde. En cuatro sesiones de noventa minutos puedes hacer una de las dos bien, o las dos mal.

Y aquí está lo interesante: ninguna cantidad de especificación mejor lo habría evitado. La persona que hizo el encargo no omitió ese dato por prisa. Lo omitió porque no había caído en que era una decisión. Su encargo era correcto y completo dentro del marco que tenía en la cabeza, y el marco era lo que estaba mal.

Tampoco lo habría salvado un modelo mejor. Con el encargo original, cualquier modelo competente produce un buen curso de producto, con una ejecución impecable. Sencillamente no era el curso que hacía falta.

El patrón se repite en todas partes. Rediseñar una página de precios cuando el problema estaba en el modelo de precios. Migrar la documentación cuando lo que tocaba era borrar el setenta por ciento. El encargo es correcto, la ejecución sería buena, y la decisión real estaba un nivel más arriba.

La instrucción que diverge

No ejecutes todavía. Antes: dime en qué 4 o 5 decisiones se juega este encargo, aunque yo no las haya mencionado; para cada una, dame las alternativas reales, incluida alguna que la gente de mi sector no suela considerar; y señala cuáles son incompatibles entre sí. Luego espera a que elija.

La tercera parte es la que más se olvida y la que más aporta. Saber qué opciones se excluyen mutuamente te dice dónde está la decisión de verdad, en vez de dejarte eligiendo entre quince variantes cosméticas.

Un límite que conviene conocer

El modelo te va a devolver las alternativas convencionales de tu dominio: las que un profesional competente del sector habría mencionado. Eso lo convierte en un inventario de omisiones excelente, y esa es la parte que sale a cuenta casi siempre.

Funciona bastante peor como fuente de originalidad. Por construcción te devuelve el centro de lo ya pensado. Si esperas la idea que no se le había ocurrido a nadie, le estás pidiendo justo lo contrario de lo que su mecanismo produce. Merece la pena igual, siempre que no confundas cubrir el espacio conocido con acceder al espacio nuevo.

Eje 3: ejecutar, que lo haga bien

Si el modelo va a inventarse una cifra, a equivocarse en un cálculo o a citar una fuente que no dice lo que él cree, lo hará igual con el encargo perfecto y con las cinco alternativas encima de la mesa.

Preguntar te protege de resolver bien el problema equivocado. No te protege de resolver mal el problema correcto. La verificación sigue siendo tuya y no hay atajo.

Aquí el remedio sí es otro: razonamiento extendido, verificación, descomponer en pasos. Y funciona, cuando el fallo es de este eje.

El problema es que la gente activa el razonamiento cuando lo que ha fallado es la especificación. Y ahí no solo no ayuda: empeora las cosas. El modelo no crea la información que le falta; lo que hace es construir una justificación más elaborada y más convincente de la suposición equivocada. El resultado es peor que el original, porque ahora cuesta mucho más detectar que arrancó del sitio equivocado.

Dos tipos de pregunta que no son la misma cosa

Una pregunta de especificación es discriminante: separa hipótesis, cierra una opción, converge. «¿En Word o en PDF?» es perfecta para eso.

Una pregunta de exploración es generativa: abre territorio, te sorprende, diverge. «¿Qué decisiones están en juego que yo no he mencionado?» es de este otro tipo.

La pregunta óptima para un eje es mediocre para el otro. Por eso una única instrucción del tipo «hazme tres preguntas» solo te cubre la mitad del trabajo.

Merece la pena un apunte sobre las herramientas que han convertido esto en botones de opción. Son buenas para especificar y flojas para explorar: discriminan bien entre alternativas que ya están sobre la mesa, pero no pueden darte la que no está. Y arrastran un riesgo poco evidente: si ninguna opción es lo que querías y eliges la menos mala, acabas de meterle una creencia equivocada con toda la confianza. Eso es peor que no haber preguntado, porque ahora ni él ni tú vais a volver a revisar esa decisión.

El diagnóstico cuando algo sale mal

La pregunta útil no es «qué modelo uso» ni «cómo lo prompteo mejor». Es en qué eje ha fallado. Hay tres síntomas y cada uno tiene su remedio, y también su remedio contraproducente.

• Está bien hecho, pero no es lo que yo quería. Es un fallo de especificación. Lo arregla: preguntas discriminantes antes de empezar. Lo empeora: pedirle que razone más.
• Es lo que pedí y está bien, pero al leerlo veo que había otra vía mejor. Es un fallo de exploración. Lo arregla: preguntas generativas, con las incompatibilidades marcadas. Lo empeora: especificar más, porque solo habrías ejecutado antes en la dirección equivocada.
• Era lo que quería, la vía era la buena, y está mal hecho. Es un fallo de ejecución. Lo arregla: razonamiento extendido, verificación y descomponer en pasos. Lo empeora: preguntar más, que no habría cambiado nada.

El error caro es el cruce: aplicar el remedio del tercer eje a un fallo del primero. Se hace a diario, es lo que promete buena parte de la divulgación sobre IA, y produce respuestas más largas, más seguras de sí mismas y exactamente igual de inútiles.

Lo que casi nunca falta es capacidad

Si te quedas con una sola idea, que sea esta: cuando algo sale mal, la reacción instintiva es pedirle al modelo que piense más, y eso casi solo consigue hacer más convincente la suposición equivocada.

Lo que falta casi nunca es capacidad. Es una información que sigue estando en tu cabeza, o una alternativa que nadie ha puesto sobre la mesa.

Y una última nota para quien esté montando agentes autónomos: si el agente pregunta hacia fuera, hacia otros sistemas y no hacia una persona, ese canal de aclaración amplía la superficie de ataque. Alguien puede contestar por ti. En una conversación normal, con una persona al otro lado, esto no aplica.