Lista de verificación de enrutamiento de proveedores LLM para startups de agentes

Alinea el proveedor principal con la tarea de mayor riesgo

Tu agente llamará a un LLM para redacción, extracción, clasificación, llamadas a herramientas, revisión de documentos largos y respuestas orientadas al usuario. Antes del lanzamiento, elige un proveedor principal, un proveedor de respaldo y una regla de enrutamiento para cada llamada. En el momento de la publicación, solo Gemini 1.5 de Google podía manejar hasta 2 millones de tokens, y solo estaba disponible como servicio en la nube de Google.

OpenAI lanzó ChatGPT en noviembre de 2022. Las pilas de un solo proveedor son fáciles de construir y difíciles de abandonar. Las startups lanzan rápido sobre una API, pero la pila hereda los límites, los precios y la disponibilidad de ese proveedor. Elige el principal para la tarea con mayor coste de fallo, no para la marca más ruidosa. Un ticket mal clasificado puede ser barato; un resumen legal incorrecto puede costar mucho más.

Elige el modelo para la tarea, el camino de datos y el modo de fallo. Elige el proveedor para el equipo de operaciones.

Pesa la disponibilidad frente al tamaño del contexto. Una ruta solo en la nube añade una dependencia para cada llamada.

Anthropic lanzó Claude 2.1 en noviembre de 2023 con una ventana de contexto de 200.000 tokens, equivalente a aproximadamente 150.000 palabras. Las ventanas de contexto grandes importan para agentes que deben mantener historiales largos, documentos recuperados y salidas de herramientas en un prompt. Si el proveedor principal no puede contener el prompt de trabajo, la ventana se convierte en el cuello de botella. Ajusta el tamaño del prompt a la ventana antes de la demostración.

El modelo Llama 3.2 1B de Meta tiene una ventana de contexto de 128K tokens, admite entrada solo de texto multilingüe y requiere aproximadamente 2 GB de VRAM de GPU. Reserva un modelo local pequeño para pasos de bajo riesgo y alto volumen donde la privacidad o las restricciones de edge importen. Mantén el principal para el resto.

Construye el respaldo antes de la caída

Designa el proveedor de respaldo antes del incidente en producción. Cada tarea principal necesita un proveedor alternativo, una comprobación de salud y un tiempo de espera. El alternativo debe ejecutar la misma forma de prompt, no solo un modelo similar. Debe preservar el contrato de salida: mismos campos, mismo formato de llamada a herramientas, mismo comportamiento de rechazo y el mismo nivel de revisión de seguridad.

No elijas el respaldo solo por precio. Los modelos más baratos fallan de formas distintas. Si una tarea toca datos de clientes, decisiones de pago o contenido regulado, el alternativo debe cumplir el mismo estándar de manejo de datos. Si no puede, el redireccionamiento se convierte en una transferencia de riesgo.

Prueba el redireccionamiento bajo carga. La prueba está completa cuando puedes redirigir un proveedor en fallo sin perder el estado del agente. Mantén la conversación, los resultados de herramientas y las acciones pendientes en tu propia capa. Almacena prompts y contratos de salida en control de versiones. Cuando cambia el principal, el alternativo no debería requerir una reescritura. Cuando cambia el alternativo, el principal no debería necesitar un prompt nuevo.

Enruta cada llamada con cuatro campos nombrados

Construye una regla de enrutamiento con cuatro campos nombrados. Cada paso del agente recibe una entrada que decide qué modelo se ejecuta, cuándo puede degradarse y quién captura el fallo.

• Necesidad de contexto: enruta primero por contexto. Los clasificadores cortos se ejecutan en modelos pequeños. La revisión de documentos largos puede necesitar una ventana mayor. Si el prompt crece más allá del límite de trabajo del modelo, divide el trabajo o pasa a un proveedor de mayor contexto.
• Presupuesto de latencia: define el presupuesto de latencia a continuación. Las respuestas orientadas al usuario necesitan respuestas rápidas. Las tareas en segundo plano esperan. Basa el presupuesto en la experiencia de usuario, no en la página de marketing del modelo.
• Tope de coste: limita el coste una vez definida la calidad. Evita forzar un paso que puede gastar más en un modelo barato solo porque es barato. Evita quemar un modelo premium en un paso que puede gastar menos.
• Proveedor de respaldo: designa el alternativo para cada entrada. Debe ejecutar la misma forma de prompt, preservar el contrato de salida y cumplir el mismo estándar de manejo de datos. La entrada nombra al proveedor que captura el fallo.

Revisa la configuración de enrutamiento cuando el agente cambie. Una nueva llamada a herramienta, un documento más largo o un requisito de usuario más estricto pueden mover una tarea de una opción barata a una opción premium. Haz visible ese cambio en la regla. Registra qué campo forzó cada decisión de respaldo para que el operador vea la ruta de redireccionamiento.