Capítulo 4: Enrutamiento, cascadas y presupuestos de razonamiento

Visión general#

El enrutamiento y las cascadas son técnicas relacionadas. El enrutamiento elige un modelo para una petición. Una cascada empieza con un modelo y escala a otro tras un fallo detectable o un resultado insuficiente.

Si tu aplicación tiene endpoints distintos para clasificación y para análisis complejo, probablemente ya sabe qué modelo necesita cada uno. Una consulta determinista es más sencilla que pedirle a un LLM que enrute a otro LLM.

El enrutamiento dinámico tiene sentido cuando un mismo endpoint recibe peticiones con requisitos muy distintos. Aun así, los dos tipos de error no cuestan lo mismo: una tarea fácil enviada a un modelo caro desperdicia dinero, mientras que una tarea difícil enviada a uno inadecuado puede hacer fallar toda la operación.

Práctica#

Empieza con políticas estáticas:

MODEL_BY_OPERATION = {
    "classification": "small-model",
    "extraction": "extraction-model",
    "incident_analysis": "reasoning-model",
}

def choose_model(operation: str) -> str:
    return MODEL_BY_OPERATION.get(operation, "default-model")

Cuando una cascada está justificada, su coste esperado simplificado es:

Por ejemplo, una llamada inicial de 0,005 $, un 20 % de escalado a un modelo de 0,020 $ y 0,001 $ de validación dan un coste esperado de 0,010 $ antes de otro trabajo de recuperación. Esa cifra depende de tu señal de escalado y de tus requisitos de aceptación.

Algunos modelos de razonamiento exponen controles de esfuerzo o de pensamiento, que pueden recortar la generación interna innecesaria en tareas acotadas sin cambiar de modelo. Los valores admitidos, los valores por defecto y la facturación varían según el modelo y el proveedor; no des por hecho que un ajuste genérico none, low o high funciona en todas partes.

Fija el esfuerzo de razonamiento por operación, junto a la elección del modelo. Un clasificador básico puede necesitar poco razonamiento extendido, mientras que una investigación de código difícil puede justificar más. No uses un límite bajo de tokens de salida como sustituto de un esfuerzo bajo: puede truncar la respuesta final después de que el razonamiento interno ya haya consumido el presupuesto.

Ledgerline. Seis de cada diez preguntas de soporte de Ledgerline preguntan en qué punto del flujo de aprobación está una factura. La aplicación ya lo sabe por su propia API, así que esas 18.000 preguntas pasan ahora por una consulta y un modelo pequeño con esfuerzo de razonamiento bajo, a 0,010 $ cada una. Las otras 12.000 mantienen la configuración actual a 0,020 $. Soporte baja de 600 $ a 18.000 × 0,010 $ + 12.000 × 0,020 $ = 420 $ al mes, sin modelo enrutador.

En profundidad#

El enrutamiento dinámico añade coste de clasificación y latencia. Si el enrutador cuesta 0,001 $ y evita de media 0,003 $ de inferencia posterior, la diferencia bruta es de 0,002 $ por petición, antes de contar las rutas equivocadas y el mantenimiento. A pequeña escala, puede que la arquitectura no compense.

Las cascadas dependen de una señal de escalado útil. Las comprobaciones de esquema y las violaciones de reglas de negocio son baratas de detectar; la corrección semántica es más difícil. Un modelo que declara una confianza alta puede seguir equivocándose, y pedir a otro modelo que juzgue cada respuesta puede borrar parte del ahorro.

Los controles de esfuerzo de razonamiento afectan a todo el flujo de trabajo. Con menos razonamiento, un agente puede hacer más llamadas a herramientas o repetir trabajo. En una API de pago por uso, menos tokens de razonamiento facturables pueden bajar el cargo de una llamada; en capacidad dedicada, el beneficio inmediato suele ser rendimiento (throughput) liberado.

Referencias: Esfuerzo de razonamiento de OpenAI, Esfuerzo de Anthropic, Niveles de pensamiento de Gemini.