Cómo elegir un LLM para producción sin depender del ranking

1. Define qué significa resolver la tarea

Un asistente que redacta borradores y un extractor de facturas pueden usar el mismo modelo, pero necesitan criterios de aceptación distintos. Antes de probar proveedores, escribe el contrato del producto: qué recibe, qué devuelve, cuánto puede tardar y qué acciones necesitan revisión humana. Una respuesta convincente no basta si inventa un identificador o cambia el importe de una factura.

Para un extractor, separa campos obligatorios, formato, evidencia y reglas de negocio. Para un asistente de código, comprueba que la propuesta compila, respeta permisos y supera pruebas relevantes. Un JSON válido solo prueba la forma de la respuesta. La aplicación todavía debe validar referencias, rangos y autorización antes de ejecutar una acción.

2. Construye un conjunto que te pueda contradecir

Parte de ejemplos representativos y autorizados de tu aplicación. Incluye entradas incompletas, documentos largos, español con variaciones regionales y casos donde la respuesta correcta sea abstenerse. Conserva una partición que no uses para ajustar prompts. Si optimizas y apruebas con las mismas preguntas, terminas midiendo cuánto recuerdas tu examen.

• Guarda entrada, salida esperada, criterios de aceptación y criticidad. Evita secretos o datos personales innecesarios.
• Etiqueta los fallos por causa: recuperación, razonamiento, formato, herramientas o infraestructura.
• Ejecuta la misma versión del conjunto con el mismo prompt, presupuesto y herramientas en cada candidato.

Puedes empezar con un conjunto pequeño revisado manualmente y ampliarlo con fallos observados. Ese conjunto inicial sirve para descubrir problemas, no para sostener una promesa estadística de precisión. Reporta siempre tamaño, distribución y número absoluto de errores.

3. Calcula costo por resultado aceptado

La tarifa por millón de tokens es una entrada de la decisión. La cuenta de una tarea incluye también reintentos, recuperación, herramientas y revisión. Un modelo barato que obliga a repetir tres veces puede superar el gasto de otro con una tarifa mayor. Usa tokens facturados cuando estén disponibles y registra por separado entrada, salida y caché.

type Run = { costUsd: number; accepted: boolean };

function costPerAcceptedTask(runs: Run[]) {
  const accepted = runs.filter(r => r.accepted).length;
  const total = runs.reduce((sum, r) => sum + r.costUsd, 0);
  return accepted === 0 ? null : total / accepted;
}

Compara ventanas de contexto y condiciones de tarifa antes de multiplicar. En el catálogo, las fichas explican si el precio cambia con el horario o la longitud. El costo normalizado facilita una primera selección; tu presupuesto final debe salir de una reproducción de la carga esperada.

Documentación: DeepSeek: condiciones de precios ↗ · xAI: contexto y precios de Grok 4.6 ↗

4. Mide la experiencia completa

El tiempo hasta el primer token importa en una interfaz conversacional; el tiempo hasta terminar la tarea importa cuando el usuario espera un archivo o una acción. Mide ambos donde corresponda. Separa tiempo de cola, recuperación, llamada al modelo y herramientas para evitar culpar al componente equivocado.

No publiques diferencias de milisegundos obtenidas con tres solicitudes como si fueran un benchmark. Repite en distintas ventanas, documenta región y concurrencia y observa dispersión. El objetivo es saber si el producto cumple su presupuesto, no ganar una carrera artificial.

5. Diseña el fallo antes del cambio de proveedor

Un timeout puede llegar después de que una herramienta ya haya escrito en otro sistema. Reintentar toda la conversación sin una clave de idempotencia puede duplicar ese efecto. Separa generación de propuesta y ejecución autorizada; impón límites de intentos, tiempo total y costo. El modelo de respaldo también debe pasar las validaciones del contrato.

Repite los casos difíciles con el candidato de respaldo. Si no cumple, la salida segura puede ser pedir información adicional o entregar una tarea para revisión. Define qué errores permiten fallback y cuáles deben detener el flujo. Cambiar automáticamente de proveedor no arregla una entrada inválida ni una falta de permisos.

6. Publica una decisión reproducible

Guarda un manifiesto con identificador de modelo, fecha, prompt, versión del conjunto, configuración y resumen de resultados. Fija versiones cuando el proveedor las ofrezca y revisa su ciclo de vida. Promueve de forma gradual, con capacidad de volver a la configuración anterior y métricas que separen errores del modelo de errores de la aplicación.

• Selecciona dos o tres candidatos por capacidad, condiciones y presupuesto.
• Ejecuta la evaluación y revisa manualmente los errores de mayor impacto.
• Aprueba calidad, latencia y costo con criterios definidos antes del experimento.
• Reevalúa cuando cambien modelo, prompt, herramientas o distribución de datos.

Documentación: Mistral: catálogo y ciclo de vida de modelos ↗