Cómo evaluar si un modelo de IA vale la pena (checklist anti-hype)

El ranking orienta, tu prueba decide

Estás a un clic de pagar el modelo que sale primero en un leaderboard, o el que cobra como si pensar fuera un privilegio. El mercado te empuja: el 84% de los desarrolladores ya usa o planea usar herramientas de IA, según la encuesta de Stack Overflow de 2025, frente al 76% del año anterior. JetBrains, con 24.534 respuestas de 194 países, pone el uso regular en el 85% y la dependencia de al menos un asistente, agente o editor con IA en el 62%. Eso mide moda. No mide si a ti te sale a cuenta.

La tensión es esta: los modelos se venden por adopción y por casos de éxito, mientras la mayoría de los profesionales combina al menos dos suscripciones de 18-21 € al mes. Y lo más probable es que no hayan medido si el reparto tiene sentido.

Una herramienta de IA no vale la pena por ser la más cara ni por liderar una tabla. Merece la compra solo si supera tus pruebas reales y el coste encaja con tu volumen. Lo que sigue es el método para saberlo, con cinco criterios concretos y los casos que los generaron.

Antes de comparar: hay tareas que no son comparables

El A/B entre modelos tiene sentido cuando la tarea lo permite. Pero no todo es comparable.

Hay casos donde no puedes meter un modelo rápido y barato aunque quieras. Refactorizar un repositorio entero, razonar sobre código con dependencias cruzadas o resolver un problema de arquitectura complejo requieren un modelo de razonamiento avanzado. No porque sea más caro, sino porque la tarea exige esa capacidad. Meter un Haiku o un GPT-5.6 Luna a refactorizar un repo no es hacer un test A/B inteligente: es medir lo que ya sabes, que ese modelo no da para eso.

Al revés también. Si tienes que analizar y categorizar miles de leads al día, no necesitas un razonador avanzado: necesitas volumen, velocidad y precio. GPT-5.6 Luna brilla exactamente aquí: le das un input con instrucciones claras y una salida estructurada definida (un JSON con campos fijos, por ejemplo) y procesas miles de registros a un coste que escala. Meter un modelo de razonamiento profundo para esa tarea es como contratar a un cirujano para poner tiritas.

Los A/B con sentido son los del medio: tareas donde la dificultad no es obvia, donde no sabes de antemano si el modelo barato aguanta. Ahí es donde el checklist que viene a continuación decide. Modelos con características similares pero distintos precios (Fable 5 vs GPT-5.6 Sol, Grok 4.6 vs Claude 4.5 Sonnet) son los candidatos naturales para comparar. El objetivo es saber cuál te da el mismo resultado a menor coste, no demostrar que el caro es mejor.

La regla antes de montar cualquier eval: ¿la tarea requiere razonamiento profundo o es volumen con salida estructurada? Si es lo primero, elige el razonador y no lo pongas a competir con el barato. Si es lo segundo, el barato probablemente gana y el A/B solo confirma cuánto estabas tirando.

El kit mínimo (sin instalar nada mágico)

No hay binario que descargar. Hay una mesa que montar antes de gastar el primer token serio. Si te saltas esto, lo que haces después es teatro con factura.

Necesitas cuatro cosas concretas:

• Una tarea tuya, no un prompt de Twitter. Quince o treinta casos reales: el ticket que te llega el martes, el PR que siempre se rompe, el brief que tu cliente de verdad envía.
• Dos modelos comparables, no uno. El techo (el más capaz que puedas pagar en una tanda pequeña) y un candidato con características similares pero menor precio. Sin el segundo candidato no hay decisión: solo hay fe.
• Un verificador que no sea el propio modelo. Si la afirmación se puede contrastar con el mundo, el test pasa, el JSON parsea, el número coincide con la hoja. El juez con nota del 1 al 10 es el último recurso, no el primero.
• Un número de presupuesto que duele. No "vamos viendo". Un tope en euros o en llamadas que, al tocarlo, aborta y deja un resultado publicable: "con X €, esto es lo que sale".

Cuentas: una API o un plan de cada candidato. Hoja de cálculo o script, da igual, con columnas fijas: id, modelo, salida_cruda, veredicto, coste, modo_de_fallo. Eso es la configuración base. El modelo, todavía no.

Los cinco criterios que importan

1. ¿Puedo regular el esfuerzo o el coste por llamada?

Este es el primero porque es el que más se ignora en las comparativas y el que más rápido elimina candidatos en producción real.

Kimi K3 es un ejemplo concreto: aunque el modelo sea bueno, no poder regularle el esfuerzo en la llamada lo descarta para ciertos usos. Un modelo que solo tiene un modo "piensa a lo grande" te impide hacer el A/B de arriba. Si no puedes bajar el dial, el candidato barato deja de ser una opción operativa y se convierte en otra suscripción que se queda abierta por costumbre.

Lo que hay que comprobar antes de integrar: ¿el proveedor expone parámetros de razonamiento o presupuesto por llamada? ¿Puedes ajustar la profundidad según la dificultad del caso? Si la respuesta es no, ese modelo solo sirve para casos donde siempre quieres el máximo, y esos casos son menos de los que parece.

2. ¿Cómo escala el precio cuando sube el volumen?

El precio por token engaña. Lo que tienes que mirar es el precio por tarea terminada, y en volumen masivo, el precio por lote.

Para volumen masivo con salida estructurada, GPT-5.6 Luna tiene sentido por sus precios generales y especialmente por su batching price. Un modelo que parece caro por token puede ser el más barato cuando mides por trabajo terminado con batching. Y al revés: un modelo barato por token que necesita reintentos frecuentes o vueltas de corrección humana puede salirte más caro que el techo.

La columna de coste de cualquier comparativa solo es el punto de partida. Lo que necesitas calcular: coste por caso terminado, considerando reintentos, correcciones y casos que un humano tiene que rematar. Esa cifra es la que firma la factura.

3. ¿Dónde se equivoca el modelo más barato?

La media te vende el modelo. El patrón de error te dice si puedes convivir con él.

El método: mides en test A/B modelos con características similares pero distintos precios (Fable 5 vs GPT-5.6 Sol, Grok 4.6 vs otro candidato comparable), pero no te quedas con el resultado global. Buscas el patrón donde más se equivoca el más barato. ¿Son fechas? ¿Código con efectos secundarios? ¿Instrucciones largas? ¿Citas exactas? Si el barato iguala al caro en una zona clara, haces routing y usas el barato ahí. Si no hay zona clara, no inventes un router: quédate con uno y paga lo que hayas medido.

Para encontrar ese patrón sin fundirte el presupuesto: un eval pequeño aguanta con tres piezas: un run que solo llama y guarda, un grader que mira un hecho verificable, un checker que revisa validez. La salida cruda se cachea siempre.

spec.md + dataset.json → SHA (se congela)
run → cache/raw/{modelo}/{id}.txt
grader → pass/fail + evidencia del mundo
checker (modelo barato) → fail-open: si duda, no bloquea;
 si pilla basura, aborta el lote

Un piloto en el modelo más barato, leyendo el crudo y no el resumen del juez, caza fallos de validez antes de incendiar el techo. Diez casos leídos enteros evitan doscientas llamadas que devolvían basura elegante.

4. ¿Puedo cambiar de modelo sin tocar código?

El proveedor debe ser intercambiable por config, no por refactor. Si cambiar de modelo requiere tocar el código, has construido una dependencia que el proveedor no te ha cobrado todavía pero que te cobrará.

El routing por dificultad, no por marca, es el stance correcto. Defines qué casos van al razonador avanzado y qué casos van al modelo rápido según criterios medibles (longitud, tipo de tarea, presencia de ciertos patrones), y ese routing vive en configuración. Cuando un modelo nuevo entra al mercado, lo pruebas con el mismo eval congelado y decides si cambia el routing. Sin refactor.

Esto también aplica a la superficie. Cursor como IDE completo, Copilot en agent mode dentro del IDE, Claude Code en la terminal: cada superficie cambia el coste y el radio de desastre. Si no has visto fallar al barato en tu superficie, no has evaluado el producto.

5. ¿Qué pasa cuando falla o se pasa de presupuesto?

Un sistema que esconde sus abortos de presupuesto está mintiendo.

El método concreto: un post-check honesto con modelo barato y política fail-open para el checker de validez. El checker paranoico para tandas enteras por estilo; el checker honesto solo mata validez real: vacío, idioma cambiado, JSON roto, respuesta que no es de este caso. El resto lo decide el grader.

Y el cap duro: cuando el contador toca el tope, paras. No "un poquito más, que ya casi". El aborto es el entregable: con este presupuesto, con este SHA, estos son los aciertos, el coste por caso y los modos de fallo. Si no te atreves a publicar esa fila, es que estabas buscando una excusa para quedarte el modelo caro.

¿Qué pasa cuando el sistema falla en producción? Si la respuesta es "se degrada y avisa", bien. Si la respuesta es "no lo sé", el sistema te está mintiendo.

La degradación en producto es distinta al aborto en evaluación: en evals, el cap aborta y la fila es el resultado. En producción, el cap degrada a un modo más conservador o a fallback humano, y ese comportamiento tiene que estar especificado antes de desplegar, no descubierto después.

Cómo correr el checklist de principio a fin

Congela spec.md (qué cuenta como acierto, qué es innegociable, qué se ignora) y dataset.json (los casos, con la respuesta o el test que los ancla). Calcula el SHA de los dos. A partir de ahí no se tocan. Si cambias un criterio, es otra evaluación, otro hash, otra fila.

Mide primero con el mejor que puedas pagar en esa tanda corta. Eso aisla la variable: si el techo no saca el trabajo, el problema no se arregla eligiendo otro logo. Después la pregunta del modelo se vuelve binaria y barata.

¿El candidato económico mantiene lo innegociable a distancia tolerable del techo? Si sí, desplegar el caro es tirar dinero. Si no, ya sabes exactamente qué compras al pagar más.

Un embudo de viabilidad antes de la matriz grande: ¿responde en tu canal (API, local, IDE)? ¿Respeta el esquema de salida? ¿Sobrevive a los tres casos que te harían despedirlo mañana? Solo entonces corres los treinta.

Escalar viene después, nunca antes. Primero la tanda pequeña. Luego el piloto en el tráfico real, con el mismo grader. Luego el volumen. Invertir esa escalera es como contratar a alguien por el LinkedIn y medirlo el día 90.

Dónde la cagas la primera vez

Compras el compuesto del ranking como si fuera tu función de coste. Un 70/15/7,5/7,5 está hecho para ordenar un catálogo, no tu noche de producción.

Metes a comparar modelos que no son comparables: un Haiku contra un razonador en una tarea de arquitectura, o un modelo de razonamiento avanzado en un pipeline de categorización masiva. El resultado no te dice nada útil porque nunca fueron candidatos para ese trabajo.

Mides solo con el barato y concluyes que "la IA no sirve", o mides solo con el caro y concluyes que "hay que pagar el techo". Las dos conclusiones están sin aislar.

Dejas que un modelo se ponga nota. "El juez dio un 8" cuesta casi lo mismo que contar cuántos tests pasaron, y vale mucho menos.

Tiras el raw. Sin corpus congelado, cada duda ("¿y si hubiéramos penalizado X?") te obliga a volver a pagar la inferencia.

Escalas en cuanto el demo emociona. Si no has visto fallar al barato en tu superficie real, no has evaluado el producto.

Y apilas dos suscripciones de 20 € "por si acaso" mientras un modelo barato te habría cubierto el 90% de los casos que de verdad tienes. Eso no es prudencia. Es no haber hecho la tabla.

Abre la carpeta. Escribe el tope. Corre quince casos de los tuyos contra dos modelos comparables. Los cinco criterios ya los tienes. El resto no te lo va a firmar nadie.

Preguntas frecuentes

¿El modelo de IA más caro es siempre el mejor?

No. El precio por token explica muy poco de la diferencia de calidad real en tu tarea. Un modelo caro que no puedes regular por llamada, que no tiene batching price razonable o que falla en tu patrón de casos específico puede salirte más caro y peor que un candidato barato con routing inteligente. La única forma de saberlo es medirlo con tus datos.

¿Cuándo no tiene sentido comparar un modelo barato con uno caro?

Cuando la tarea requiere razonamiento avanzado de forma no negociable: refactorizar un repositorio complejo, resolver problemas de arquitectura con dependencias cruzadas, análisis que exigen múltiples pasos de razonamiento encadenado. Ahí el modelo barato no es un candidato viable y meterlo en el A/B solo confirma lo que ya sabes. Al revés también: para categorizar miles de leads con salida estructurada, el razonador avanzado es un desperdicio.

¿Puedo elegir modelo solo con un ranking?

No. Un ranking amplio sirve para filtrar candidatos, no para decidir. Los rankings ponderan calidad, coste, velocidad y latencia para un lector genérico. Tu caso, tu superficie y tu patrón de errores no están en esa mezcla. Usa la tabla para recortar la lista y mide tarea, errores y volumen con tus datos.

¿Cómo comparo dos modelos sin fundirme el presupuesto?

Congela una spec y 15-30 casos reales, hashea ese paquete y llama primero al techo para marcar el máximo. Después corre el candidato comparable sobre los mismos ids, cachea el raw y puntúa con un hecho verificable. Un piloto leyendo el crudo del barato caza basura de validez antes de quemar presupuesto. Cuando el tope de euros se toca, paras: esa fila es el resultado.