Cómo elegir un modelo de IA sin mirar el ranking

Los rankings de modelos responden una pregunta que casi nadie hace: quién gana en un conjunto fijo de tareas ajenas. Tu problema es distinto. Tienes un caso, un presupuesto y una tolerancia al error. La decisión sale de ahí, no de una tabla.

Qué miden realmente los benchmarks

Un benchmark es un examen estandarizado: mismas preguntas, respuesta correcta, condiciones controladas. Sirve para comparar capacidad bruta. No sirve para predecir qué pasará con tu formulario de cobro.

Por qué no predice tu caso:

• Contaminación. Los casos pueden estar en el entrenamiento: el modelo no los resuelve, los recuerda.
• Tarea única. Premian una respuesta correcta, no una aceptable dentro de un flujo con herramientas.
• Sin tu contexto. No incluye tu repo, tus datos ni tus reglas de negocio.
• Formato. Un cambio pequeño en la respuesta mueve el resultado más que la capacidad.
• Varianza. La diferencia entre dos puestos seguidos suele caber en el ruido.
• Coste ignorado. El ranking no dice cuánto cuesta acertar.

El sesgo de fondo es que los benchmarks premian la respuesta única. Tu trabajo casi nunca tiene una respuesta única; tiene una respuesta aceptable, que un humano reconoce en segundos y que el modelo no puede definir solo.

Un modelo puede subir en el ranking y empeorar en lo tuyo. No es una contradicción. Es que midieron otra cosa.

Los cinco criterios que sí importan

Criterio | La pregunta real | Cómo lo mides | Señal de alarma
Calidad en tu tarea | ¿Acierta con tus entradas y tus criterios? | 30 casos reales, evaluación a ciegas | Acierta en ejemplos limpios y falla en los reales
Coste por operación | ¿Cuánto cuesta una tarea terminada, con reintentos? | Coste total entre tareas aceptadas | El precio por token es bajo y la factura no
Latencia | ¿Cuánto espera una persona en el flujo real? | p50 y p95 por paso | La media está bien y la cola se siente lenta
Ventana de contexto | ¿Aguanta tu documento más largo sin perder el medio? | Prueba con tus documentos, no con números | El nominal es enorme y el resultado ignora la mitad
Privacidad y dependencia | ¿Dónde van los datos y qué tan caro es salir? | Revisión de términos y prueba de cambio | No puedes cambiar de proveedor sin reescribir el producto

El orden de estos criterios no es universal. En una herramienta interactiva, la latencia puede valer más que un punto de calidad. En un proceso por lotes, al contrario. Lo que no cambia es que los cinco se deciden con tu caso, no con una tabla pública.

La ventana de contexto nominal no es la útil. Un modelo que acepta un documento enorme puede perder el centro. Mide con tu contrato más largo y tu hilo de soporte más enredado.

Cómo montar una evaluación casera con 30 casos

1. Saca 30 entradas reales. Del histórico, de los tickets, de los correos. No las inventes.
2. Respeta la distribución: 20 típicas, 7 difíciles y 3 raras. Las raras son las que rompen el promedio.
3. Define qué es aceptable antes de ver resultados. Tres niveles: sirve, sirve con edición, no sirve.
4. Congela el prompt y la configuración. Cambia una variable por vez.
5. Corre cada modelo dos o tres veces. Si tu producto usa temperatura mayor que cero, la varianza es parte del resultado.
6. Evalúa a ciegas. Quita el nombre del modelo de las salidas.
7. Guarda los fallos con la entrada exacta. Los fallos valen más que los aciertos.

Treinta casos bien elegidos baten a tres mil genéricos.

Lo que necesitas no es cobertura estadística: es saber dónde se rompe y si ese fallo te cuesta dinero.

Dos advertencias. Evalúa el flujo completo, no la llamada suelta: preprocesado, herramientas, reintentos y formato final. Y si dos personas puntúan distinto el mismo caso, el problema no es el modelo; es que tu criterio no está definido. Ese desacuerdo es el hallazgo más útil de la evaluación.

Coste por tarea, no precio por token

El precio por token es una unidad de facturación, no una unidad de decisión.

Coste por tarea aceptada = inferencia y herramientas, multiplicado por los intentos necesarios, más revisión humana, más coste del error.

Un ejemplo relativo. El barato cuesta una quinta parte por token, pero falla uno de cada cinco casos y necesita dos turnos en la mitad de los aciertos. El caro cuesta cinco veces más y acierta a la primera en cuatro de cada cinco. Con reintentos y revisión, la diferencia puede desaparecer. Si el fallo llega al usuario, el caro sale más barato.

Componente | Cómo se calcula | Por qué se olvida
Inferencia | Tokens de entrada y salida por tarea | Es lo único que aparece en la factura
Reintentos | Intentos medios hasta una salida aceptable | Se ve como fallo del prompt, no como coste
Herramientas | Llamadas externas, búsquedas, ejecuciones | Se factura en otro sitio
Revisión humana | Minutos por salida por coste hora | No aparece en ningún panel
Error | Soporte, reembolso, reproceso, confianza | Se atribuye a mala suerte

El componente que suele dominar es la revisión humana. Un modelo que acierta un poco más y te ahorra treinta segundos por caso puede justificar un precio varias veces mayor. Uno que acierta igual y tarda el doble, no.

La estrategia de dos modelos

Uno caro para lo difícil, uno barato para el volumen. Suena obvio y casi siempre se implementa mal.

Cómo se hace bien: enruta por tipo de tarea, no por longitud del prompt. La longitud es un mal proxy de dificultad. Un prompt corto puede pedir una decisión delicada; un prompt larguísimo puede pedir un resumen mecánico.

• Barato: clasificación, extracción, formato, borradores y resúmenes de volumen.
• Caro: decisiones con consecuencias, casos ambiguos y generación que un humano va a leer con atención.
• Verificación: un paso barato, con reglas o un modelo pequeño, decide si la salida del barato es aceptable o se escala.

Dos reglas. El barato debe cubrir la mayor parte del volumen, o pagas dos sistemas. Y dos modelos significan dos prompts, dos evaluaciones y dos comportamientos: no dupliques la arquitectura sin medir el mantenimiento.

El caro no siempre gana: a veces el barato está mejor ajustado al formato o responde más rápido. Solo tu evaluación lo dice.

Señales de que debes cambiar de modelo

• Tu tasa de aceptación cae después de una actualización, aunque el ranking del proveedor suba.
• El coste por tarea sube sin una mejora medible en la revisión.
• Aparece una tarea nueva que el modelo falla de forma sistemática, no aleatoria.
• La latencia de cola se degrada y se nota en el flujo.
• Cambian las condiciones de privacidad, retención o ubicación de los datos.
• Ya no puedes cambiar de proveedor sin reescribir prompts, herramientas o formato.
• El equipo pasa más tiempo corrigiendo salidas que construyendo.

Lo que no es una señal: un titular, un ranking nuevo, una demo impresionante. Cambiar de modelo tiene un coste real en prompts, evaluación y comportamiento. Se cambia cuando el coste de quedarse es mayor, no cuando el de moverse parece barato.

Un modelo no se elige de una vez. Se adopta con condiciones, se mide y se revisa. El día que dejas de medir, el ranking decide por ti.