Elegir modelo para tu agente: capacidad, latencia y coste
La pregunta habitual es qué modelo es mejor para agentes. La que produce un buen sistema es qué modelo es mejor para este paso, con nuestros datos y nuestro presupuesto de latencia — y la respuesta suele ser más de uno.
Una ejecución no es homogénea. Decidir la siguiente acción requiere razonamiento. Extraer tres campos de un documento devuelto, no. Resumir un resultado para el usuario, tampoco. Tratarlo todo como una única compra es como acabas pagando precio de frontera por reformatear JSON.
Divide la ejecución antes de elegir#
| Paso | Qué necesita | Nivel de modelo sensato |
|---|---|---|
| Planificar o elegir acción | Razonamiento, seguir instrucciones | El más fuerte que puedas costear |
| Llamar herramienta con argumentos | Salida estructurada fiable | Nivel medio con esquemas estrictos |
| Extraer campos de un resultado | Precisión en texto corto | Pequeño y rápido |
| Clasificar o enrutar | Consistencia | Pequeño o clasificador ajustado |
| Escribir la respuesta al usuario | Tono y claridad | Nivel medio |
Los benchmarks son lista corta, no decisión#
Los benchmarks públicos dicen qué modelos son plausibles. No dicen cuál maneja tus esquemas, tus formatos y tus clientes difíciles, porque nada de eso está ahí. Construye treinta casos reales de tus registros — incluidos los cinco que dan vergüenza — y pasa la lista corta por ellos. La diferencia de orden respecto al benchmark suele ser suficiente para cambiar la decisión.
Incluye casos donde lo correcto es rechazar o preguntar. Los modelos se diferencian más en saber cuándo parar que en qué decir.
Las tres restricciones que atan#
- Suelo de latencia: cada llamada tiene uno y un agente hace varias. Mide toda la ejecución.
- Fiabilidad de salida estructurada: un 97 % de argumentos válidos rompe una ejecución de cada diez con tres llamadas.
- Manejo de contexto: el contexto largo cuesta y degrada la atención; mide a la longitud real, no a la máxima.
Routing sin proyecto de investigación#
El routing de modelos suena sofisticado y suele ser un fichero de configuración. Asigna un modelo por tipo de paso, permite sobrescribir por herramienta y registra qué modelo produjo cada decisión. Empieza bajando solo extracción y clasificación; eso solo suele quitar entre un tercio y la mitad de la factura sin tocar lo que el usuario ve.
Planifica las retiradas de versión#
Las versiones se retiran según el calendario del proveedor, no el tuyo. Dos hábitos lo convierten en un no-evento: fija una versión explícita en lugar de un alias móvil, y mantén tu conjunto de evaluación ejecutable con un solo comando para que recualificar sea una tarde y no un proyecto.
Preguntas frecuentes
¿Uso el modelo más grande para todo?
Solo si no has medido. El paso de decisión suele beneficiarse; extracción, clasificación y formato rara vez. Dividir por paso es la reducción de coste más fácil sin tocar la calidad visible.
¿Sirven los modelos abiertos?
Para pasos estrechos y bien definidos con esquemas estrictos, a menudo sí, y a volumen la economía convence. Para planificación abierta con muchas herramientas suelen necesitar más andamiaje. Prueba con tus treinta casos.
¿Cada cuánto reviso la elección?
Cuando salga una versión que podrías adoptar, y por lo demás cada dos trimestres. Solo es sostenible si ejecutar la evaluación es un comando.
elegir llmselección de modelo agentesrouting de modeloslatencia de agentessalida estructurada
