Selección de modelo

Seleccionar un modelo no es elegir al ganador de un benchmark general. Es encontrar la opción que cumple tu tarea con el mejor equilibrio entre calidad, costo, latencia, privacidad y operación.

Empieza por la tarea

Separa el trabajo en clases concretas:

• extracción o clasificación con schema;
• generación breve;
• razonamiento complejo;
• código y uso de herramientas;
• procesamiento multimodal;
• embeddings o reranking.

Una aplicación rara vez necesita el mismo modelo para todo. La tarea define qué capacidades debes evaluar y qué fallos importan.

La matriz de decisión

Mide costo por tarea exitosa, no sólo precio por millón de tokens. Un modelo barato que necesita tres reintentos puede salir más caro que uno mejor en la primera llamada.

Routing por dificultad

Un patrón eficaz es empezar con un modelo pequeño y escalar cuando:

• el validador rechaza la salida;
• la entrada pertenece a una categoría compleja;
• falta confianza o evidencia;
• el impacto exige una segunda revisión.

El routing también añade complejidad: más rutas que evaluar, observar y mantener. Úsalo cuando el ahorro o la calidad justifiquen esa superficie.

Proceso reproducible

1. define dataset y métricas;
2. establece un baseline;
3. compara candidatos con el mismo contexto y contrato;
4. mide calidad, costo total y latencia;
5. prueba fallos, cuotas y fallback;
6. despliega de forma gradual y conserva rollback;
7. repite al cambiar modelo, versión, prompt o retrieval.

[!TIP] El mejor modelo es el más pequeño y operable que supera el umbral de calidad de la tarea, no el más capaz del catálogo.

Temas relacionados

Necesitas Evaluaciones para comparar, API pricing para estimar y Proveedor para valorar gobierno y portabilidad.