La pregunta «¿cuál es el mejor modelo de IA?» no tiene respuesta, y llevar dos años haciéndola es parte del problema. Es como preguntar cuál es el mejor vehículo sin decir si vas a mudarte, ir a trabajar o cruzar un desierto.

La pregunta útil es otra: qué vas a hacer con él. Esta guía está organizada por tarea, no por marca, y no incluye tablas de benchmarks a propósito. Los benchmarks cambian cada pocas semanas y se miden casi siempre en inglés; lo que no cambia tan rápido son los perfiles de cada familia de modelos y el criterio para elegir.

Antes de elegir: tres preguntas que ahorran meses

¿Vas a usarlo tú o va dentro de un producto?

Si lo vas a usar tú, desde una interfaz de chat, la decisión es barata y reversible: pruebas dos suscripciones un mes y te quedas con la que te resulte más cómoda. Si va integrado en algo que construyes, la decisión pesa mucho más: cambiar de modelo implica reescribir instrucciones, reajustar el comportamiento y volver a probarlo todo.

¿Cuánto texto vas a meterle de golpe?

Es el factor que más gente ignora y el que más rápido descarta opciones. Resumir correos no tiene nada que ver con analizar un pliego de trescientas páginas o un repositorio de código entero. La ventana de contexto —cuánta información cabe en una sola conversación— varía enormemente entre modelos y es un límite duro, no una cuestión de calidad.

¿Qué pasa si se equivoca?

Si el coste de un error es reescribir un párrafo, puedes usar el modelo más rápido y barato. Si el coste es enviar información incorrecta a un cliente o publicar un dato falso, necesitas el modelo más fiable y una persona revisando. Esta pregunta determina el presupuesto más que ninguna otra.

Escribir y redactar

Aquí lo que distingue a unos modelos de otros no es la capacidad, que a estas alturas es alta en todos, sino el registro. Unos tienden a una prosa más natural y menos formulaica; otros producen texto correcto pero con tics reconocibles: introducciones que anuncian lo que van a decir, cierres que resumen lo ya dicho, y esa estructura de «no es X, es Y» que delata el origen a distancia.

Criterio práctico: escribe el mismo encargo en dos o tres modelos y lee los resultados en voz alta. El que menos te haga tropezar es el tuyo. Es una prueba de treinta minutos que vale más que cualquier comparativa.

Trampa habitual: pedir un texto largo de una sola vez. Los resultados mejoran mucho trabajando por partes —primero el esquema, luego cada sección— y revisando entre medias.

Y si escribes en español, pruébalo en español. Los rankings públicos se miden en inglés casi siempre, y las diferencias en matiz, registro formal y variantes regionales no aparecen ahí. Un modelo que lidera en inglés puede sonar raro en castellano.

Programar

Es el terreno donde las diferencias entre modelos son más marcadas y donde más rápido se nota.

Importa menos qué modelo puntúa más alto en un benchmark que qué modelo está integrado en las herramientas que usas. Un modelo algo peor dentro de tu editor, con contexto de tu proyecto, rinde más que uno mejor al que tienes que pegar código a mano.

Criterio práctico: la prueba real no es «escríbeme una función», que todos aprueban. Es darle un fallo concreto de tu proyecto, con el contexto suficiente, y ver si lo diagnostica o solo propone parches plausibles.

Trampa habitual: aceptar código que parece correcto sin ejecutarlo. Los modelos actuales producen código muy verosímil y a veces sutilmente equivocado, que es la peor combinación posible.

Analizar documentos largos

Aquí manda la ventana de contexto, y es una decisión casi puramente técnica.

Si trabajas con contratos, pliegos, informes extensos o muchos documentos a la vez, comprueba cuántos tokens admite el modelo antes de mirar nada más. Un token equivale aproximadamente a tres cuartos de palabra en español; un documento de cien páginas ronda los 50.000 tokens.

Criterio práctico: prueba con tu documento más largo, no con uno de ejemplo. Y comprueba que responde sobre información que está a mitad del documento, no solo al principio o al final: la degradación en el medio es un problema real y conocido.

Trampa habitual: dar por hecho que «cabe» equivale a «lo ha leído bien».

Automatizar procesos y agentes

Cuando el modelo no responde a una persona sino que ejecuta pasos —leer un correo, consultar una base de datos, escribir en otra herramienta— las prioridades cambian por completo.

Deja de importar la elegancia de la redacción y pasa a importar la consistencia: que devuelva siempre el mismo formato, que no se invente campos, que falle de forma predecible. Un modelo brillante pero irregular es peor para automatizar que uno correcto y constante.

Criterio práctico: lánzale la misma petición veinte veces y mira cuántas devuelven exactamente la estructura esperada. Esa tasa te dice más que cualquier benchmark.

Trampa habitual: no prever el fallo. Toda automatización con IA necesita saber qué hacer cuando la respuesta no llega o llega mal.

Alternativas abiertas y locales

Existe una familia de modelos de pesos abiertos que puedes ejecutar en tu propia infraestructura. Rinden por debajo de los modelos de frontera, pero el hueco se ha estrechado mucho.

Tienen sentido en tres casos: cuando los datos no pueden salir de tu organización por obligación legal o contractual, cuando el volumen es tan alto que el coste por token se vuelve determinante, o cuando necesitas garantizar que el modelo no cambia bajo tus pies.

Coste real: no es cero. Sustituyes la factura del proveedor por hardware, mantenimiento y alguien que lo administre. Para volúmenes pequeños casi nunca compensa.

Y ojo con la privacidad si usas la API oficial de un proveedor extranjero: conviene saber en qué jurisdicción se procesan los datos y si se usan para entrenar. La mayoría de servicios profesionales permiten desactivarlo, pero hay que hacerlo de forma explícita.

Lo que casi nadie te dice

El modelo es la variable menos importante. En la mayoría de implantaciones que fracasan, el problema no era el modelo: era que nadie definió qué debía hacer, con qué información, ni quién revisaba el resultado.

Cambiar de modelo es más barato de lo que crees, y más caro de lo que parece. Técnicamente, cambiar de proveedor son unas líneas de configuración. En la práctica, cada modelo responde distinto a las mismas instrucciones, y migrar bien implica volver a ajustar y volver a probar.

Los precios bajan constantemente. El coste por token lleva años cayendo. Si hoy una idea no sale rentable por precio, vuelve a hacer el cálculo en seis meses.

Y ningún modelo es el mejor durante mucho tiempo. El liderazgo cambia de manos cada pocos meses. Construir sobre la suposición de que tu proveedor seguirá siendo el mejor es una apuesta; construir de forma que puedas cambiarlo es una decisión.

Cómo decidir en una tarde

1. Escribe en una frase qué tarea concreta quieres resolver
2. Elige dos modelos, no cinco
3. Prepara tres casos reales tuyos, no ejemplos de manual
4. Pásalos por ambos y compara los resultados, no las fichas técnicas
5. Quédate con uno y úsalo un mes antes de replantearte nada

 

Si después de esa tarde sigues dudando, la respuesta es que para tu caso da igual cuál elijas, y eso también es información útil.