Modelado del oponente: construye IA que anticipa, no que reacciona

La mayoría de la "IA de negociación" es un ciclo de reacción disfrazado de estrategia. El otro lado dice algo, el modelo escribe la respuesta más fluida que le sale, y la conversación se va hacia donde la empuje la frase más fuerte. Eso se siente ágil, y lo ágil pasa por inteligencia, por eso justamente engaña a la gente. Pero la estrategia es otra cosa. Sostienes un modelo de lo que la otra parte está tratando de lograr, simulas cómo reacciona a tus jugadas y eliges la jugada que sigue en pie después de que respondan. Este ensayo es el ciclo que de verdad uso para eso, los puntos donde se rompe sin que te des cuenta y lo que cuesta de verdad mantenerlo corriendo, para que termines pudiendo decidir si tu problema siquiera lo necesita.

Metí buena parte de estas ideas en Proyección, nuestra herramienta para practicar negociación. La gracia de Proyección no es ganar un chat. Es que una persona pueda ensayar frente a una contraparte con objetivos, temperamento y memoria, una contraparte que va por su propio resultado en vez de seguirte la corriente por cortesía. Construir una contraparte que valiera la pena enfrentar me obligó a concretar tres cosas que la exageración suele saltarse: qué creemos sobre el otro lado, cómo simulamos sus contrajugadas y qué tan honestas son de verdad esas predicciones.

01 · Separa la hipótesis del guion

El primer error, y se ve por todos lados, es meter el comportamiento del oponente dentro de un system prompt y llamarlo personalidad. "Eres un comprador duro que quiere precio bajo" produce un personaje. Va a improvisar, va a sonar creíble, y por debajo va a hacer lo que sea que le marque la última frase. Un personaje no es un modelo. Un modelo es una hipótesis estructurada que puedes inspeccionar, actualizar y hasta contradecir.

Así que mantén la hipótesis explícita y separada del diálogo. Como mínimo quieres sus objetivos probables (con pesos, porque la gente quiere varias cosas a la vez), sus restricciones duras, su punto de quiebre (una estimación del BATNA) y un nivel de confianza para cada uno. Guárdalo como datos, no como prosa.

type OpponentBelief = {
  goals: { label: string; weight: number }[]      // what they optimize for
  batna: { estimate: number; confidence: number }  // best alternative to a deal
  constraints: string[]                            // budget, deadline, authority
  temperament: "patient" | "anchored" | "volatile"
  uncertainty: number                              // 0..1, how unsure we are
}

Una vez que la hipótesis es un objeto aparte, cada turno tiene dos tareas en vez de una, y separarlas es casi toda la disciplina.

1. Actualizar la hipótesis con lo que acaban de decir. Si de repente mencionan una fecha límite, sube una restricción de tiempo y su temperamento se mueve hacia "anclado". Una oferta muy por encima de tu estimado es señal de que tu número de BATNA estaba mal: ensánchalo y baja tu confianza, en vez de tomar un solo dato como verdad absoluta.
2. Actuar según la hipótesis actualizada. Elige tu jugada contra el modelo, no contra el último mensaje.

Separar esto evita que el agente se sobreajuste a la frase más reciente, que es justo el modo de fallo reactivo. El otro lado se da cuenta rápido: apenas nota que el agente solo refleja el último mensaje, lo empieza a manejar con frases emocionales o extremas. Una hipótesis que se actualiza de forma incremental es mucho más difícil de zarandear, porque un mensaje fuerte la mueve un poco, no del todo.

02 · Simula la contrajugada antes de comprometerte

Los agentes reactivos evalúan una respuesta candidata por lo bien que suena por sí sola. Los agentes anticipatorios la evalúan por lo que pasa después. No necesitas una búsqueda completa del árbol de juego ni self-play para lograrlo. La versión barata y sorprendentemente efectiva es un lookahead de un nivel: para cada jugada que podrías hacer, le preguntas al modelo del oponente cómo respondería con más probabilidad y luego calificas la posición que queda, no la respuesta en sí.

async function bestMove(belief: OpponentBelief, moves: Move[]) {
  const scored = await Promise.all(moves.map(async (m) => {
    const replies = await simulateOpponent(belief, m)  // weighted responses
    const value = replies.reduce(
      (acc, r) => acc + r.prob * scorePosition(belief, m, r),
      0,                                               // expected value, not best case
    )
    return { move: m, value }
  }))
  return scored.sort((a, b) => b.value - a.value)[0].move
}

Toda la fuerza vive en simulateOpponent. Córrela con Claude, pero ponle límites estrictos: pásale el objeto de la hipótesis y pídele las dos o tres respuestas más probables con probabilidades aproximadas, nunca una sola respuesta segura. Tener varios resultados ponderados es lo que evita que planifiques contra un único oponente imaginario que, qué casualidad, hace justo lo que esperabas. Calificas la posición esperada sobre esas ramas, y por eso una jugada con un mejor caso buenísimo pero un caso probable catastrófico saca puntaje bajo, como debe ser.

Un ejemplo concreto

Estás comprando. Tus jugadas candidatas son anclar bajo en 70, acercarte a su 95 y hacer una pregunta de diagnóstico. El modelo, que cree que el vendedor es volátil y anclado, predice que "anclar en 70" provoca una amenaza de retirarse el 60% de las veces y una contraoferta en 110 el resto. Anclar saca mal puntaje, y fíjate por qué: no porque sea grosero, sino porque el siguiente estado simulado es peor para ti en promedio. La pregunta de diagnóstico saca buen puntaje por otra razón: poco riesgo a la baja digan lo que digan, y encima afina la hipótesis para todos los turnos siguientes. Ese segundo beneficio, información que mejora decisiones futuras, es invisible para un agente reactivo y obvio para uno anticipatorio. Ahí es donde la idea hace trabajo de verdad.

03 · La calibración lo es todo

Aquí viene la parte incómoda. Un modelo que se equivoca con seguridad es peor que uno que admite duda, porque actúas sobre lo que te dice. Un agente que dice "70% de que se retira" y acierta el 40% de las veces te va a convencer una y otra vez de descartar buenas jugadas. Así que la pregunta no es "¿se siente inteligente el lookahead?". Es "¿coinciden las probabilidades que predice con la realidad?".

Mídelo de frente. Después de cada turno, registra qué predijiste que haría el oponente y qué hizo de verdad. A lo largo de muchos turnos, cuando dices "70% probable", debería pasar cerca del 70% de las veces. Dos prácticas baratas y honestas:

• Lleva un Brier score corrido sobre tus predicciones por turno. Es nada más el error cuadrático medio entre tu probabilidad predicha y el resultado 0/1. Más bajo es mejor, y la tendencia te dice si el modelo está aprendiendo o pudriéndose. No necesitas un tablero; un número registrado por sesión basta para detectar el deterioro a tiempo.
• Invierte en información cuando la incertidumbre es alta. Cuando la incertidumbre de la hipótesis pasa cierto umbral, inclínate por jugadas que la reduzcan (una pregunta de diagnóstico, una concesión pequeña que revele sus prioridades) antes que por jugadas que te comprometen. Una pregunta que despeja tu incertidumbre muchas veces vale más que la oferta localmente óptima hecha a ciegas.

04 · Cuándo no hacer esto

El modelado del oponente tiene un costo real en latencia, tokens y complejidad, y es la herramienta equivocada con más frecuencia de la que admite la exageración. Úsalo a propósito, no por defecto.

• Intercambios cooperativos o de una sola ronda. Si ambos lados ganan siendo directos, modelar agrega latencia y un leve tufo adversarial sin ningún beneficio. Un asistente para agendar reuniones no necesita una estimación del BATNA de la persona con la que coordina.
• Información escasa. Casi sin señal sobre el otro lado, tu "modelo" es una corazonada disfrazada de datos, que es la versión peligrosa. Una persona en el prompt bien hecha sale más barata y, sobre todo, es más honesta sobre lo poco que sabe.
• Turnos de alto riesgo y baja latencia. Un lookahead de varias ramas cuesta tokens y segundos. A veces una respuesta rápida y decente le gana a una lenta y óptima, sobre todo cuando la persona del otro lado interpreta una pausa larga como debilidad o como un fallo del sistema.
• Donde una predicción segura pero errada sea peligrosa. Mira la sección anterior. Sin calibración, no hay anticipación.

También hay una línea que tienes que trazar antes de lanzar, no después. Modelar a una contraparte para encontrar un acuerdo que de verdad sirva a ambos lados está bien. Eso es escuchar, nada más, pero formalizado. Modelarla para fabricar una presión que rechazaría si pudiera ver la maquinaria por dentro es manipulación, y disfrazarlo de "personalización" no lo cambia. En Proyección el oponente es simulado y el usuario es quien practica, así que la ética queda limpia por diseño. En producción contra personas reales, decide dónde va la línea, déjala por escrito y asegúrate de que la función de puntuación no la pueda cruzar a escondidas.

Anticipar no es un prompt más grande ni una persona más astuta. Es una disciplina pequeña y aburrida: sostén una hipótesis explícita, actualízala de forma incremental en cada turno, simula la respuesta del otro lado antes de comprometerte, califica la posición en la que terminarías y revisa si tus predicciones sirvieron de algo. La mayor parte del valor llega en el momento en que dejas de calificar cómo suena tu respuesta y empiezas a calificar el estado en el que quedas después de que ellos respondan. Construye ese ciclo, mantenlo honesto, y el agente deja de reaccionar. Empieza a jugar.