Elegir el modelo adecuado para la tarea (y el presupuesto)

Un modelo mental útil: primero el tipo de tarea, después el modelo

En la práctica, clasifico las cargas de trabajo de los LLM según cinco ejes antes siquiera de mirar los nombres de los modelos:

Elegir un modelo se vuelve mucho más fácil cuando deja de preguntar «¿qué modelo es más inteligente?» y empieza a preguntar «¿qué tipo de fallo estoy pagando por reducir?».

Por ejemplo:

• Un sistema de resumen de solicitudes de restablecimiento de contraseñas necesita coherencia y un coste bajo.
• Un asistente de migración de código necesita razonamiento y uso de herramientas.
• Una herramienta de comparación de contratos necesita un contexto largo, pero también una atribución cuidadosa.
• Un agente de cara al cliente necesita una latencia predecible más que una calidad máxima en las pruebas de referencia.
• Un flujo de enriquecimiento por lotes puede dar más importancia al volumen procesado por dólar que a la elegancia de las respuestas.

A menudo, el modelo equivocado no lo es desde el punto de vista técnico. Lo es desde el punto de vista económico.

Una escala práctica de modelos

Esta es la escala que utilizo para la mayoría de los sistemas de producción.

Modelos de la categoría de Haiku: la opción predeterminada para tareas de lenguaje rápidas y económicas

Los modelos de la categoría de Haiku son excelentes para una primera pasada. Los utilizo en tareas donde la respuesta es breve, la entrada está limpia y el formato de salida está restringido.

Usos adecuados:

• Etiquetado de solicitudes de soporte
• Resúmenes breves
• Clasificación de sentimientos
• Normalización de asuntos de correo electrónico
• Identificación de coincidencias con preguntas frecuentes
• Extracción sencilla de JSON
• Prefiltros de moderación de bajo riesgo

Ejemplo de prompt para un clasificador económico de primera pasada:

{
  "model": "claude-haiku-4.5",
  "temperature": 0,
  "max_tokens": 120,
  "response_format": { "type": "json" },
  "messages": [
    {
      "role": "system",
      "content": "Classify the support ticket. Return only valid JSON."
    },
    {
      "role": "user",
      "content": "Subject: Refund not received\nBody: I canceled two weeks ago and still see a charge."
    }
  ]
}

Salida esperada:

{
  "category": "billing",
  "urgency": "medium",
  "needs_human": true,
  "reason": "Refund dispute involving payment status"
}

Un problema habitual: los equipos piden a los modelos económicos que razonen y den un formato perfecto a la vez. Si el modelo a veces genera JSON no válido, no pases inmediatamente a Opus. Primero, delimita mejor la tarea:

• Configura temperature: 0
• Usa un esquema JSON o una llamada a una herramienta
• Reduce el alcance de las instrucciones
• Separa la clasificación de la explicación
• Valida la salida y reintenta una vez

Para muchas tareas en producción, un reintento con un modelo de la clase Haiku sigue siendo más barato y rápido que recurrir por defecto a un modelo de razonamiento de vanguardia.

Modelos de la clase Sonnet: el motor de la lógica real del producto

Los modelos de la clase Sonnet suelen ser mi elección para las funciones interactivas de un producto. Son lo bastante capaces para razonar, lo bastante estables para usar herramientas y, por lo general, lo bastante rápidos para los flujos orientados al usuario.

Usos adecuados:

• Redacción de respuestas de atención al cliente
• Flujos de trabajo de agentes con herramientas
• Explicación de código y refactorización ligera
• Preguntas y respuestas sobre documentos en varios pasos
• Flujos de trabajo con copilotos para ventas o éxito del cliente
• Extracción estructurada a partir de entradas desordenadas

En la práctica, Sonnet suele ser la mejor opción cuando quieres evitar pensar demasiado en el enrutamiento. Si solo puedes integrar una categoría de modelos en una función nueva, empieza por esta.

Ejemplo: un agente de soporte que puede consultar un pedido, una política y los tickets anteriores.

SYSTEM = """
You are a support resolution assistant.
Use tools before making claims about orders, refunds, or account state.
If policy is ambiguous, say what is ambiguous and escalate.
Return:
- summary
- recommended_action
- customer_reply
- escalate: true/false
"""

request = {
    "model": "claude-sonnet-4.6",
    "temperature": 0.2,
    "max_tokens": 900,
    "tools": [
        {"name": "get_order", "description": "Fetch order state"},
        {"name": "get_refund_policy", "description": "Fetch current refund rules"},
        {"name": "search_prior_tickets", "description": "Search customer history"}
    ],
    "messages": [
        {"role": "system", "content": SYSTEM},
        {"role": "user", "content": "Customer says they returned item A but were charged again."}
    ]
}

Lo que realmente ocurre cuando ejecutas este tipo de flujo de trabajo en producción: la mayoría de los fallos no se deben a que «el modelo sea torpe». Son fallos de integración.

• La herramienta devuelve un estado desactualizado.
• El modelo recibe demasiado contexto irrelevante.
• El documento de políticas contiene texto contradictorio.
• Se permite que el agente continúe tras una llamada fallida a una herramienta.
• El prompt pide tanto un análisis interno como un texto listo para el cliente sin separarlos.

Un modelo de la clase Sonnet ofrece suficiente inteligencia para resolver algunos problemas derivados del desorden, pero no elimina la necesidad de contratos de herramientas bien definidos.

Modelos de la clase Opus: caros, pero a veces más baratos que los errores

Los modelos de la clase Opus están pensados para tareas en las que el coste de una mala respuesta supera con creces el coste de la inferencia.

Recurro a Opus cuando:

• La entrada es ambigua y hay mucho en juego
• Hay muchas restricciones que interactúan entre sí
• El usuario espera un razonamiento profundo
• La tarea implica decisiones sobre código, políticas o arquitectura que requieren sopesar ventajas e inconvenientes
• Un intento fallido con un modelo económico haría perder tiempo a las personas

Ejemplos:

• Revisar un plan de migración de una base de datos
• Analizar la cronología de un incidente en producción
• Generar una comparación compleja de políticas legales para su revisión humana
• Depurar un fallo de un agente que abarca varios servicios
• Evaluar si una acción automatizada es segura

No uso Opus para todas las tareas «importantes». La importancia y la dificultad son cosas distintas. Un millón de tickets de restablecimiento de contraseñas son importantes para los usuarios, pero cada uno de ellos no es difícil. Una sola migración de eliminación de datos con implicaciones sutiles puede ser importante y difícil a la vez.

Un patrón útil es «escalar ante la incertidumbre»:

def choose_model(task):
    if task["context_tokens"] > 700_000:
        return "fable-5"

    if task["risk"] == "high" and task["requires_reasoning"]:
        return "claude-opus-4.8"

    if task["requires_tools"] or task["multi_step"]:
        return "claude-sonnet-4.6"

    return "claude-haiku-4.5"

Es deliberadamente sencillo. El enrutador debe ser lo bastante simple como para que tu equipo pueda depurarlo a las 2 de la madrugada.

Fable 5 y el contexto de 1M: úsalo cuando el problema sea la recuperación de información

Los modelos de contexto largo resultan tentadores porque evitan mucho trabajo de ingeniería de recuperación de información. La ventana de contexto de 1M de Fable 5 cambia lo que puedes abordar directamente: revisión de documentos completos, síntesis de transcripciones enormes, inspección de repositorios grandes y análisis de políticas repartidas en varios archivos.

Pero el contexto largo no es magia.

Una ventana de 1M tokens ayuda cuando la dificultad es que «el dato relevante podría estar en cualquier parte». No garantiza que el modelo razone perfectamente sobre el millón de tokens, ni hace que el contexto irrelevante sea gratis. Los prompts largos siguen costando dinero, añaden latencia y pueden dispersar la atención.

Uso contexto largo al estilo de Fable cuando:

• El corpus está demasiado interconectado para una división simple en fragmentos
• Omitir un detalle es peor que pagar por contexto adicional
• El usuario puede tolerar respuestas más lentas
• La tarea se beneficia de ver el material circundante sin procesar

Ejemplo de arquitectura para revisar documentos extensos:

User request
  -> lightweight classifier
  -> retrieve obvious relevant sections
  -> if confidence high: Sonnet answer with citations/quotes from chunks
  -> if confidence low or query is global: Fable 5 over full document set
  -> optional Opus review for high-risk final answer

Este enfoque híbrido funciona mejor que «meter siempre todo en el contexto». En la práctica, los modelos de contexto largo son más valiosos como vía de escape cuando la confianza en la recuperación de información es baja.

Modelos de pesos abiertos: control, coste y capacidad de procesamiento

Los modelos de pesos abiertos como Llama, Qwen, DeepSeek, MiniMax y Kimi no son solo «alternativas más baratas». Son decisiones operativas.

Tienen sentido cuando necesitas:

• Despliegue local o en una VPC
• Costes predecibles para el procesamiento por lotes de gran volumen
• Ajuste fino o destilación
• Optimizaciones personalizadas de inferencia
• Control de la residencia de los datos
• Un coste marginal extremadamente bajo tras la configuración inicial

Son especialmente buenos para tareas específicas y repetitivas. Por ejemplo, una variante de Qwen o Llama servida mediante vLLM puede gestionar clasificación, extracción y enriquecimiento interno con una alta capacidad de procesamiento si controlas la longitud del prompt y el formato de salida.

Ejemplo de configuración para servir un modelo localmente:

vllm serve Qwen/Qwen3-14B \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 2 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90

Después, llámalo mediante un cliente compatible con OpenAI:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="local"
)

result = client.chat.completions.create(
    model="Qwen/Qwen3-14B",
    temperature=0,
    messages=[
        {"role": "system", "content": "Return valid JSON only."},
        {"role": "user", "content": "Classify: user cannot access invoice PDF"}
    ]
)

La contrapartida es asumir la responsabilidad de ingeniería. Con los modelos de vanguardia alojados, otra persona se encarga de la capacidad, los parches, las decisiones de cuantización y el trabajo de rendimiento a nivel de kernel. Con los modelos abiertos, todo eso pasa a ser tu responsabilidad.

Los modelos de pesos abiertos encajan muy bien cuando la carga de trabajo es estable. Encajan peor cuando el producto cambia cada semana y la calidad del prompt importa más que el coste puro de servir el modelo.

Enrutamiento con modelos económicos primero y escalado posterior

Un buen enrutador no es una clasificación de rendimiento. Es un sistema de control de riesgos.

Aquí tienes un patrón adecuado para producción:

1. Prueba el modelo más barato que debería ser capaz de realizar la tarea.
2. Valida la salida mediante comprobaciones automáticas.
3. Pide al modelo una autocomprobación calibrada basada únicamente en criterios observables.
4. Escala si falla la validación, la confianza es baja o el riesgo es alto.
5. Registra la ruta y el resultado para realizar ajustes posteriores.

Ejemplo de enrutador:

def run_with_escalation(task, input_text):
    first_model = pick_first_model(task)

    response = call_model(
        model=first_model,
        input=input_text,
        schema=task["schema"],
        temperature=0
    )

    validation = validate(response, task["schema"])

    if not validation.ok:
        return call_model(
            model="claude-sonnet-4.6",
            input=input_text,
            schema=task["schema"],
            temperature=0
        )

    if task["risk"] == "high" and response.get("needs_review"):
        return call_model(
            model="claude-opus-4.8",
            input=input_text,
            schema=task["schema"],
            temperature=0
        )

    return response

Lo importante es que el escalado se base en señales medibles, no en impresiones.

Señales útiles para escalar:

• JSON no válido
• Faltan campos obligatorios
• Respuesta contradictoria
• Falló la llamada a una herramienta
• La evidencia recuperada es débil
• El usuario solicita una acción irreversible
• La entrada supera la longitud habitual
• El modelo indica explícitamente que hay incertidumbre
• El clasificador detecta contenido legal, médico, de seguridad o financiero

Evita usar únicamente la «confianza del modelo» como puntuación numérica. La confianza de un LLM no es una probabilidad calibrada. Aun así, resulta útil cuando se limita a comprobaciones específicas: «¿La entrada contenía información suficiente para responder?» es mejor que «¿Qué grado de confianza tienes?».

Latencia, precio y experiencia de usuario

El modelo más rápido no siempre ofrece la mejor experiencia de usuario. La mejor experiencia es la que lleva al usuario a un resultado correcto con una espera tolerable.

Para los sistemas interactivos, pienso en presupuestos de latencia:

No oculte un razonamiento lento detrás de un indicador de carga sin ofrecer información. Si una tarea de Opus o Fable necesita 90 segundos, preséntela como una tarea de análisis explícita:

Analyzing 184 files...
✓ Indexed repository structure
✓ Found 12 migration scripts
✓ Checking rollback safety

Eso cambia la percepción del usuario porque el sistema está realizando un trabajo visible.

Además, utilice streaming siempre que sea posible. El streaming no reduce el tiempo total de ejecución, pero mejora considerablemente la latencia percibida en los flujos de trabajo de chat y redacción.

Decisiones reales según la tarea

Estas son las decisiones concretas que tomaría hoy.

Clasificación inicial de tickets de soporte

Utilice Haiku primero.

• Entrada: texto breve del ticket
• Salida: categoría, urgencia, cola de asignación
• Escale a Sonnet en caso de disputas de facturación, clientes enfadados o ambigüedad en las políticas
• Revisión humana para reembolsos que superen el umbral

Este es un flujo de trabajo clásico que empieza por la opción más económica.

Agente de soporte de cara al cliente

Utilice Sonnet.

• Requiere el uso de herramientas
• Requiere control del tono
• Requiere gestionar políticas
• Requiere un escalamiento adecuado

Utilice Haiku solo para el preprocesamiento. Utilice Opus para la revisión de supervisión en casos de alto riesgo.

Asistente de revisión de código

Utilice Sonnet para la revisión habitual de PR. Utilice Opus para cambios sensibles a la arquitectura, concurrencia, seguridad, migraciones de datos y tareas de verificación de corrección que exijan atención a detalles sutiles.

Un error habitual es proporcionar todo el repositorio por defecto. Empiece con el diff, el grafo de dependencias y los archivos relacionados. Escale a Fable u otro modelo de contexto largo solo cuando el cambio abarque muchas áreas.

Comparación de contratos o políticas extensos

Utilice recuperación de información junto con Sonnet para preguntas acotadas. Utilice Fable 5 cuando la pregunta sea global, como «encuentre todas las contradicciones entre estos documentos».

Si la salida influye en una decisión real de carácter jurídico o de cumplimiento normativo, utilice el modelo para preparar el análisis, no para tomar la decisión.

Enriquecimiento de datos a gran escala

Utilice un modelo de pesos abiertos si el volumen es alto y la tarea es estable.

Ejemplo:

• Normalizar nombres de empresas
• Extraer etiquetas de sector
• Clasificar clientes potenciales entrantes
• Generar resúmenes internos breves

Ejecute lotes nocturnos, valide muestras y escale los casos excepcionales a un modelo alojado.

Asistente de investigación sobre grandes archivos documentales

Utilice Gemini 3, GPT-5.5, Opus o Fable según la longitud del contexto y las necesidades de razonamiento. No empezaría por la opción más económica para esto, salvo que la consulta sea claramente sencilla. Los fallos de investigación suelen ser silenciosos: el modelo da una respuesta plausible, pero pasa por alto el documento clave.

Elaborar presupuestos sin engañarse

La forma más fácil de gastar de más es optimizar el coste por llamada ignorando los reintentos, las correcciones humanas y los flujos de trabajo fallidos.

Registre estas métricas por tipo de tarea y modelo:

• Tokens de entrada
• Tokens de salida
• Latencia p50/p95
• Tasa de fallos de validación
• Tasa de escalamiento
• Tasa de correcciones humanas
• Tasa de reintentos de los usuarios
• Coste por tarea completada con éxito, no coste por llamada

La última métrica importa. Un modelo económico que requiere tres reintentos y aun así provoca una revisión manual puede resultar más caro que Sonnet. Una llamada a Opus que evita una migración fallida puede ser la decisión más económica de la semana.

Si utiliza una pasarela multimodelo, como el acceso mediante API de AI Prime Tech a las familias Claude, GPT y Gemini, la principal ventaja no es solo poder elegir entre proveedores. También facilita el enrutamiento y la medición entre distintas categorías de modelos. Pero la parte difícil sigue siendo el diseño de sus tareas.

Conclusiones prácticas

• Empiece por la naturaleza de la tarea: transformación, extracción, razonamiento, síntesis de contexto largo o enriquecimiento por lotes.
• Utilice modelos de la categoría Haiku para trabajos económicos, rápidos y acotados con validación mecánica.
• Utilice modelos de la categoría Sonnet como opción predeterminada para funciones de producto que necesiten razonamiento, herramientas o calidad de cara al usuario.
• Utilice modelos de la categoría Opus cuando los errores sean costosos, la ambigüedad sea alta o importe el razonamiento profundo.
• Utilice un contexto largo del tipo Fable 5 cuando la incertidumbre en la recuperación de información sea el problema principal, no como estrategia predeterminada para volcar información en el prompt.
• Utilice modelos de pesos abiertos cuando la estabilidad de la carga de trabajo, la privacidad, la capacidad de procesamiento o el control del despliegue justifiquen gestionar su propia inferencia.
• Implemente un enrutamiento que empiece por la opción más económica, con señales explícitas de escalamiento: salida no válida, evidencias débiles, fallos de herramientas, acciones de alto riesgo e incertidumbre.
• Mida el coste por tarea completada con éxito, no el coste por token ni por llamada.
• Mantenga los enrutadores lo bastante sencillos como para depurarlos bajo presión.
• Trate la elección del modelo como un mecanismo de control de ingeniería, no como una decisión puntual sobre un proveedor.