Elegir el modelo con evidencia, no por tamaño

Un clasificador corre en Opus “porque fue el modelo del prototipo”. Ahora producto pide la etiqueta en menos de un segundo y finanzas marcó el costo mensual. En otro equipo, alguien pasó todo a Haiku para ahorrar y los casos difíciles empezaron a fallar. Los dos errores tienen la misma raíz: elegir el modelo sin evidencia.

Los tres ejes y el árbitro

Un modelo se elige balanceando capacidad, velocidad y costo. Las familias se ordenan más o menos así: Opus para lo más exigente, Sonnet para el día a día con buen equilibrio, Haiku para lo que necesita la menor latencia y el menor precio. Pero esa tabla es un punto de partida, no la decisión.

El árbitro es un set de evaluación (evaluation set) propio: casos reales de tu tarea, con los casos borde incluidos, corridos con tus prompts y tus datos. Con eso comparás modelos en precisión, calidad y manejo de casos difíciles, y recién ahí ponés en la balanza costo y latencia.

• Si el modelo chico iguala al grande en tus evals para esa tarea, conviene el chico: cumple igual, cuesta menos y responde más rápido.
• Si el modelo chico falla solo en un segmento, no lo descartes entero: ruteá ese segmento.
• La decisión vale para esa tarea. Que Haiku iguale a Opus clasificando tickets no dice nada sobre el agente que concilia pagos.

Hay dos formas razonables de arrancar: por eficiencia (empezar con el chico y subir solo si hay brechas de capacidad) o por capacidad (empezar con el más fuerte, ajustar el prompt y bajar cuando las evals lo permitan). Las dos terminan en lo mismo: medir.

Carga mixta: rutear, no promediar

Con una carga mixta (mixed workload), por ejemplo 85% de consultas simples y 15% de análisis complejos, mandar todo a un solo modelo es perder de los dos lados: todo al grande revienta el presupuesto, todo al chico rompe los casos difíciles.

El ruteo por complejidad (complexity-based routing) manda cada pedido al modelo que alcanza. La señal para rutear tiene que ser confiable: el tipo de pedido que elige el usuario, la categoría que asigna un clasificador o el flujo de la aplicación. Confirmá con evals que cada ruta cumple.

Antes de cambiar de modelo, mirá también el esfuerzo (effort): en los modelos que lo soportan, bajar o subir ese parámetro cambia inteligencia por latencia y costo dentro del mismo modelo, y muchas veces es una palanca mejor que mudarse de familia.

Cómo reconocer un modelo inadecuado

Un modelo inadecuado (model mismatch) se diagnostica con evidencia: mismo prompt, mismas herramientas, y los casos complejos fallan en el modelo chico pero no en el anterior. Si las respuestas terminan normalmente y el fallo se reproduce al reintentar, no es un problema de truncado ni de errores transitorios. La respuesta es rutear ese segmento al modelo que lo resuelve, conservando el ahorro en el resto.

Las trampas típicas

• “El modelo más grande siempre es lo más seguro en producción”.
• Achicar el modelo sin correr las evals, o con un benchmark público en lugar de tus datos.
• Generalizar una eval: “Haiku igualó en esta tarea, así que pasemos todo a Haiku”.
• Recortar tokens de salida esperando que eso arregle la latencia de un modelo sobredimensionado.
• Agregar “pensá más en las preguntas difíciles” en lugar de rutear.
• Culpar a “cambios silenciosos del modelo” sin comparar contra la versión anterior.

En el examen

Buscá si el escenario menciona un set de evaluación con casos reales: si existe y muestra paridad, la respuesta es mover esa carga al modelo más eficiente. Si describe una mezcla de pedidos simples y complejos con una señal clara para separarlos, buscá el ruteo. Descartá las opciones que mueven todo de un extremo al otro o que deciden sin medir.