«¿Cuál es el mejor modelo?» es la pregunta de quien todavía no ha montado uno
La conversación empieza siempre igual. Alguien abre un ranking, señala el primer puesto y pregunta si montamos el agente con ese. Es una pregunta razonable y está mal hecha, porque da por supuesto que un agente usa un modelo. Los agentes que aguantan producción no usan uno: usan varios. Y la decisión que de verdad importa no es cuál, sino el reparto.
El motivo es de arquitectura y es aburrido. Un agente no hace una tarea: hace una cadena. Lee un correo y decide de qué va. Busca en tu documentación y saca tres fragmentos. Redacta una respuesta que va a leer un cliente tuyo. Decide si eso sale solo o pasa por una persona. Son cuatro pasos con cuatro exigencias distintas: clasificar un correo en seis categorías es un problema resuelto desde hace años; redactar lo que lee tu cliente es donde te juegas la cara. Pagar el modelo más caro para los cuatro pasos es poner a tu mejor abogado a hacer fotocopias.
No es una opinión nuestra. La guía de OpenAI para construir agentes lo dice sin rodeos: los modelos tienen fortalezas y compromisos distintos en complejidad de tarea, latencia y coste, y no todas las tareas necesitan el modelo más inteligente. Su ejemplo es exactamente el de arriba: una recuperación simple o una clasificación de intención la puede llevar un modelo pequeño y rápido, mientras que decidir si se aprueba un reembolso se beneficia de uno más capaz. Y recomienda plantearse usar varios modelos para distintas tareas del mismo flujo en vez de uno para todo. Fuente: A practical guide to building agents, OpenAI, consultado el 12 de septiembre de 2026.
Esta guía va de tomar esa decisión con criterio: los tres ejes que sí deciden, el orden en que se recorren, cómo se reparte y qué capa hay que montar para que cambiar de modelo no sea una reforma. Lo que no es: una tabla de «mejores LLM de 2026» —esa caduca antes de publicarla— ni la factura de operar IA en producción, que es otra conversación con otros números.
Los tres ejes que sí deciden
Cuando quitas el ruido, la elección se apoya en tres preguntas. Ninguna de las tres se contesta leyendo la ficha del modelo: las tres se contestan midiendo en tu casa.
| Eje | La pregunta que contesta | Cómo se mide en tu caso |
|---|---|---|
| Acierto en tu tarea | ¿Cuántos de mis casos reales resuelve bien? | Una batería de 30-50 casos tuyos con la respuesta correcta escrita al lado |
| Latencia | ¿Aguanta el canal donde vive el agente? | El percentil 95 del tiempo de respuesta, nunca la media |
| Coste por caso resuelto | ¿Cuánto cuesta resolver uno de principio a fin? | Coste del flujo completo dividido entre casos resueltos, no precio por millón de tokens |
El acierto es el eje que más gente se salta, porque es el que da trabajo. «Acierto» no es una nota general: es el porcentaje de TUS casos que salen bien. Para tenerlo hace falta lo aburrido —treinta o cincuenta casos reales, correos de verdad con sus faltas de ortografía y sus adjuntos raros, con la respuesta correcta escrita al lado—. Sin esa batería no estás eligiendo modelo: estás opinando sobre modelos, que es otra cosa y no se puede defender en una reunión.
La latencia no es un número absoluto: es un número contra un canal. Un chat en tu web tiene un presupuesto de segundos porque hay una persona mirando la pantalla. Un proceso nocturno que concilia facturas tiene toda la noche. El mismo modelo es rápido en uno y lento en el otro, así que la pregunta «¿es rápido?» no significa nada hasta que dices dónde. Anthropic lo plantea como lo que es, un intercambio: los sistemas agénticos cambian latencia y coste por rendimiento en la tarea, y hay que decidir caso por caso cuándo ese cambio compensa. Fuente: Building effective agents, Anthropic, 19 de diciembre de 2024, consultado el 12 de septiembre de 2026.
El precio por millón de tokens es un precio de lista, no tu factura. Un modelo barato que necesita tres intentos, se deja la mitad de los campos y acaba escalando a una persona sale más caro que uno caro que acierta a la primera. La unidad correcta es el caso resuelto: coste total del flujo —todas las llamadas, todos los reintentos, también los del paso que falló— dividido entre los casos que salieron bien sin que nadie los tocara.
El ranking público no sabe nada de tu trabajo
Con los tres ejes encima de la mesa se entiende por qué el leaderboard no decide. Un ranking público mide un examen estandarizado: preguntas de concurso, problemas de código de juguete, acertijos de lógica. Tu tarea no es eso. Tu tarea son los correos de tus clientes, tu jerga interna, tus PDFs mal escaneados y tu política de devoluciones, y ninguna de esas cuatro cosas aparece en ninguna tabla. Lo desarrollamos en su día: los benchmarks de LLM no predicen tu resultado.
Lo que sí sirve un ranking público es lo contrario de lo que se hace con él: sirve para descartar, no para elegir. Te dice qué modelos están en la conversación y cuáles se quedaron atrás hace dos generaciones, y eso te ahorra evaluar quince candidatos. A partir de ahí, la lista corta —dos, tres— se ordena con tu batería de casos. Ese orden casi nunca coincide con el del ranking, y cuando coincide es una casualidad que no puedes dar por buena la próxima vez.
El reparto: barato para clasificar, caro para decidir
El patrón tiene nombre y está documentado. Anthropic lo llama enrutamiento: un primer paso clasifica la entrada y la dirige al tratamiento especializado que le toca. Su utilidad, explican, es separar responsabilidades y poder escribir prompts más especializados, porque sin ese reparto optimizar para un tipo de entrada empeora el rendimiento en los demás. Y uno de los ejemplos que dan es literalmente el reparto por coste: mandar las preguntas fáciles y comunes a modelos pequeños y económicos, y las difíciles o raras a modelos más capaces. Fuente: Building effective agents, Anthropic, 19 de diciembre de 2024, consultado el 12 de septiembre de 2026.
Traducido a los pasos de un agente típico, el reparto suele quedar así. La columna de la derecha es un punto de partida, no una ley:
| Paso del agente | Qué exige de verdad | Dónde suele caer |
|---|---|---|
| Clasificar la entrada y enrutar | Consistencia y velocidad sobre un conjunto cerrado de categorías | Modelo pequeño |
| Extraer campos de un documento | Formato estable; el error se detecta con validación | Modelo pequeño con contrato de salida |
| Buscar y resumir en tus documentos | Fidelidad a la fuente; manda la calidad de la recuperación | Modelo intermedio |
| Decidir sobre dinero, personas o datos regulados | Juicio y matiz; el error se paga en euros o en reputación | Modelo más capaz |
| Redactar lo que va a leer un cliente | Tono, precisión y cero invención | Modelo más capaz |
El único que puede confirmar esa tabla es tu conjunto de casos. Hay clasificaciones con veinte categorías solapadas donde el modelo pequeño se hunde, y hay redacciones tan acotadas —un acuse de recibo con tres variables— que el pequeño va sobrado. Por eso el reparto se decide midiendo y se revisa cuando cambia el catálogo de modelos o cambia tu volumen.
Un matiz que ahorra disgustos: enrutar solo compensa cuando las categorías son distintas de verdad y la clasificación se puede hacer con precisión. Es la condición que la propia Anthropic pone a este patrón, y es la que falla cuando alguien mete un enrutador donde no hacía falta. Si el clasificador se equivoca, no has ahorrado: has puesto un punto de fallo nuevo delante de todo lo demás, y encima uno silencioso, porque una entrada mal enrutada no da error, da una respuesta del tipo equivocado.
El orden correcto: empieza por el caro y baja hasta que se note
Con el reparto claro queda el cómo. La guía de OpenAI propone una receta que va en contra del instinto de todo el mundo: construir el prototipo con el modelo más capaz en cada tarea para fijar una línea base de rendimiento, y a partir de ahí probar a sustituirlo por modelos más pequeños para ver si siguen dando un resultado aceptable. Sus principios, en ese orden: montar evaluaciones para fijar la línea base, alcanzar el objetivo de acierto con los mejores modelos disponibles y solo después optimizar coste y latencia sustituyendo grandes por pequeños donde se pueda. Fuente: A practical guide to building agents, OpenAI, consultado el 12 de septiembre de 2026.
- Monta la batería de casos antes de tocar el agente. Treinta o cincuenta, reales, con la respuesta correcta al lado. Este paso es el que se salta todo el mundo y el que decide si el resto sirve de algo.
- Construye el agente entero con el mejor modelo disponible en cada paso. Todavía no estás optimizando: estás averiguando si tu objetivo de acierto es alcanzable.
- Mide contra la batería. Si aquí no llegas al objetivo, el problema no es el modelo: es el prompt, tus datos, la recuperación o la tarea, y bajar de modelo solo lo va a esconder.
- Con el objetivo alcanzado, baja un paso cada vez y vuelve a pasar la batería. Un cambio, una medición. Dos cambios a la vez y ya no sabes cuál fue.
- Para en el escalón anterior al que rompe. Y deja escrito qué paso usa qué modelo y con qué acierto medido, porque dentro de tres meses nadie se va a acordar.
El motivo para no hacerlo al revés es de diagnóstico, no de purismo. Si empiezas por el modelo barato y el agente no funciona, tienes cuatro sospechosos y ninguna forma de separarlos: puede ser el modelo, el prompt, tus datos o que la tarea no estuviera bien definida. Empezando por arriba, cuando algo falla al bajar sabes exactamente qué lo rompió, porque solo has cambiado una cosa.
La capa que te deja cambiar de modelo sin tocar el agente
Todo lo anterior tiene fecha de caducidad. El catálogo de modelos cambia cada pocos meses, los precios se mueven y los proveedores deprecian versiones. Si tu decisión de hoy está escrita dentro del agente —el nombre del modelo repetido en siete sitios del código—, dentro de seis meses no vas a poder rehacerla, y acabarás con el mismo problema que describimos en cómo cambiar de modelo sin romper tus automatizaciones: el flujo no se rompe con un error, se rompe con otro formato y otro tono, en silencio.
La capa que lo evita son cinco piezas, y ninguna es sofisticada:
- Una sola función que llama al modelo. Todas las llamadas pasan por ahí. Si hay siete sitios en el código con el nombre de un modelo dentro, ya tienes deuda.
- El identificador del modelo, en configuración. Un fichero con el modelo de cada paso. Cambiar de modelo tiene que ser cambiar una línea, no abrir el agente.
- Un contrato de salida validado. Antes de que el resultado toque ningún sistema, se comprueba que tiene la forma pactada. Es lo que convierte un cambio silencioso de formato en un error visible.
- La batería de casos, ejecutable con un comando. Si probar un modelo nuevo cuesta media mañana de trabajo manual, no se va a probar.
- Un registro de qué modelo atendió cada caso. Sin esto no puedes comparar el antes y el después de un cambio, ni explicar por qué la semana pasada iba mejor.
Esto no es una optimización opcional que se deja para la fase dos. Es la diferencia entre elegir un modelo hoy y poder volver a elegir dentro de seis meses. Cuando esa capa no existe, la decisión de modelo se toma una vez y se hereda para siempre, que es justo lo contrario de lo que necesita un sistema que vive en un mercado que se mueve cada trimestre.
La tabla de reparto: una página, con dueño y fecha
El cierre es el mismo que en las instrucciones de un agente de IA: si la decisión no está escrita, no existe. Una página basta, y tiene que contestar estas cinco cosas.
- Qué modelo usa cada paso, con una línea de por qué y el acierto medido contra la batería el día que se decidió.
- Qué se probó y se descartó. El candidato que no entró y el motivo. Sin esto, alguien va a volver a probarlo dentro de cuatro meses desde cero.
- Quién firma. Una persona con nombre. Una tabla sin dueño no se revisa nunca.
- Qué dispara una revisión: que aparezca un modelo nuevo relevante, que el proveedor deprecie el que usas, que el volumen cambie de orden de magnitud o que el acierto medido baje.
- Próxima revisión. Una fecha, aunque no haya pasado nada. La decisión caduca sola y nadie avisa.
Si tu agente ya está en producción y esta página no existe, empieza por los pasos que tocan dinero: qué modelo decide un reembolso, qué modelo redacta lo que lee tu cliente y con qué acierto medido. El resto puede esperar una semana.
Nosotros montamos esa capa antes que el agente: llamada aislada, modelo en configuración, contrato de salida y batería de casos ejecutable, como parte de la infraestructura de IA para empresa sobre la que después se construyen los empleados IA. Es la parte que nadie enseña en una demo y la única que decide si dentro de un año puedes cambiar de modelo en una tarde o tienes que rehacer el sistema. La lógica completa, en crear un agente de IA que aguante producción.