Cómo elegir un modelo de IA: latencia, ventana de contexto, precisión y coste por token
Cada pocos meses aparece un modelo nuevo que encabeza las clasificaciones. Lo normal es querer usarlo en todo. Pero si pasas todas las tareas de tu sistema al modelo más potente del momento, lo más probable es que tus costes suban, que las respuestas tarden más y que la calidad apenas mejore.
En el capítulo anterior viste cómo dividir el trabajo entre agentes especializados. Ahora toca decidir qué motor necesita cada uno. Verás por qué no existe un «mejor modelo» para todo, qué cuatro criterios debes valorar y qué tipo de modelo encaja con cada función. También verás cómo proteger tus flujos frente a los cambios de los proveedores.
No existe el «mejor modelo»
Con cada nueva generación de modelos, las clasificaciones públicas (leaderboards) publican sus resultados en pruebas estandarizadas como MMLU, HumanEval, GSM8K o MATH. Muchos equipos reaccionan enviando todas sus peticiones al modelo que va primero en ese momento.
Esta práctica tiene tres problemas.
1. Las pruebas no reflejan tu trabajo real
Algunas preguntas de estas pruebas pueden haber acabado, sin querer, en los datos de entrenamiento de los propios modelos. Es lo que se llama contaminación de las pruebas (benchmark contamination). Cuando pasa, la puntuación sube, pero eso no significa que el modelo funcione mejor con tus documentos, tus correos o tus contratos.
Además, aunque no haya contaminación, una prueba general mide capacidades generales. Tu sistema necesita resolver tareas concretas.
2. Pagas de más por tareas sencillas
Usar un modelo de máxima capacidad para clasificar un correo, extraer una fecha o generar un JSON es como contratar a una cirujana para poner una tirita. Funciona, pero el coste se come el margen de cualquier servicio que quieras escalar.
3. Esperas de más
Los modelos más grandes, y sobre todo los que razonan paso a paso antes de responder, suelen tardar más. En un chat de atención al cliente o en un flujo con varios agentes seguidos, esa espera se nota.
La idea clave: no existe el mejor modelo en general. Existe el modelo adecuado para cada paso de tu flujo.
El equilibrio entre razonamiento, velocidad y coste
PROFUNDIDAD DE RAZONAMIENTO
▲
/ \
/ \ ◄── Modelos de frontera
/ \ (más coste, más espera)
/ \
/ \ ◄── Modelos intermedios
/ \
Modelos pequeños ──► \
(barato y rápido) /______________\
VELOCIDAD ◄──────► COSTE BAJO
Casi nunca puedes tener a la vez el máximo razonamiento, la máxima velocidad y el mínimo coste. Elegir un modelo consiste en decidir qué priorizas en cada paso.
Los cuatro criterios para elegir un modelo
1. Qué tipo de tarea tiene que resolver
Antes de mirar modelos, clasifica la tarea:
Tipo de tarea
Ejemplos
Modelo adecuado
Razonamiento complejo
Resolver problemas lógicos difíciles, detectar contradicciones sutiles en un contrato, hacer un análisis pericial, rediseñar software complejo
Modelos de frontera, con razonamiento explícito o gran capacidad
Transformación de texto
Resumir textos claros, cambiar el tono, traducir, redactar variantes a partir de una plantilla
Modelos de gama media
Operaciones mecánicas y extracción
Clasificar, enrutar, extraer nombres, importes o NIF, dar formato a un JSON cerrado
Modelos pequeños (SLM)
Recuerda lo que vimos en el capítulo 2: ningún modelo es fiable para hacer cálculos exactos solo con texto. Para eso, conecta una herramienta de cálculo.
2. La ventana de contexto y lo bien que la aprovecha
Algunos modelos aceptan uno o dos millones de tokens de contexto. Pero que un modelo acepte mucha información no significa que la use bien toda.
Un estudio publicado en 2023 por Nelson F. Liu y otros investigadores describió el fenómeno «perdido en el medio» (lost in the middle). Los modelos tendían a aprovechar mejor la información situada al principio y al final del contexto, y peor la que estaba en la zona central. Los modelos más recientes han mejorado en este aspecto, pero conviene no dar por hecho que leen igual de bien cada página de un documento muy largo.
Criterio práctico: para trabajar con documentación técnica o legal extensa, suele ser mejor usar una arquitectura RAG con fragmentos cortos y precisos, como vimos en el capítulo dedicado a los Brains, que volcar un archivo de 500 páginas entero en la ventana de un modelo gigante. Además, también es más barato: pagas por cada token que envías.
Una forma sencilla de comprobarlo es la prueba de la «aguja en el pajar» (needle in a haystack). Consiste en esconder un dato concreto en un documento largo y preguntar por él. Si el modelo no lo encuentra cuando está en el medio, tienes una señal clara.
3. La latencia
Hay dos medidas que conviene distinguir:
- Tiempo hasta el primer token (time to first token, TTFT): lo que tarda en aparecer el primer carácter de la respuesta. Es lo que más nota una persona en un chat o en un asistente de atención al público.
- Tokens por segundo (TPS): la velocidad con la que se genera el resto del texto. Es clave en flujos con varios agentes en cadena, porque el segundo agente no puede empezar hasta que el primero termine.
Ejemplo: en un flujo de cinco agentes seguidos, si cada uno tarda ocho segundos, el usuario espera cuarenta. Si pasas los tres primeros pasos a modelos rápidos que tardan un segundo cada uno, la espera baja a unos diecinueve.
4. El coste por token
Los proveedores cobran por separado dos tipos de tokens:
- Tokens de entrada: todo lo que envías al modelo (instrucciones, documentos, historial). Suelen ser más baratos.
- Tokens de salida: lo que el modelo genera. Suelen costar varias veces más que los de entrada; muchas veces entre 3 y 5 veces, aunque depende del proveedor y del modelo.
La fórmula básica es:
Coste de una petición = (tokens de entrada × precio de entrada) + (tokens de salida × precio de salida)
Los precios suelen expresarse por cada millón de tokens.
Un ejemplo con precios ficticios
Imagina un agente extractor que procesa 100 expedientes al día. Cada expediente supone 8.000 tokens de entrada y 1.000 de salida. Comparamos dos modelos con precios inventados, solo para ilustrar el cálculo:
Modelo de frontera
Modelo pequeño
Precio de entrada (por millón)
3,00 €
0,15 €
Precio de salida (por millón)
15,00 €
0,60 €
Coste por expediente
0,039 €
0,0018 €
Coste al mes (30 días)
117 €
5,40 €
En este ejemplo, el modelo grande cuesta unas 20 veces más por la misma extracción. Y si el modelo pequeño ya extrae bien los datos, esa diferencia no mejora en nada el resultado final. Ahora multiplícalo por los cinco agentes de un flujo.
Consulta siempre los precios actuales en la página de cada proveedor, porque cambian con frecuencia.
Cómo probar modelos con tus propios casos
En lugar de fiarte de las clasificaciones públicas, crea tu propio conjunto de pruebas:
- Reúne entre 20 y 50 casos reales de la tarea, incluidos algunos difíciles o poco habituales. Elimina los datos personales.
- Define cómo es una respuesta correcta en cada caso, antes de probar ningún modelo.
- Prueba primero con el modelo más pequeño. Si resuelve bien la tarea, no necesitas uno mayor.
- Sube de nivel solo si hace falta, y mide si la mejora compensa el coste y la espera.
- Repite la prueba cada vez que cambies de modelo, de versión o de instrucción de sistema.
Así eliges con datos de tu negocio y no con promesas generales.
Protege tus flujos: versiones fijas y modelos de respaldo
Elegir bien el modelo no basta. También tienes que evitar que tu sistema cambie de comportamiento sin que te des cuenta.
Usa versiones fijas
Muchos proveedores ofrecen nombres genéricos, como modelo-latest, que apuntan siempre a la última versión. Son cómodos para probar, pero arriesgados en producción. Cuando el proveedor actualiza el modelo, tu agente puede empezar a seguir las instrucciones de otra forma. Es lo que se conoce como deriva en el seguimiento de instrucciones (instruction drift).
Buena práctica: en tus flujos de negocio, usa siempre la versión concreta con fecha que ofrezca el proveedor, por ejemplo, nombre-modelo-2026-03. Cuando quieras actualizar, hazlo a propósito y después de pasar tus pruebas.
Ten en cuenta también que los proveedores retiran modelos antiguos cada cierto tiempo. Revisa sus avisos y planifica el cambio con margen.
Ten un modelo de respaldo
Define para cada paso crítico un modelo alternativo compatible. Lo usarás si el principal falla, si el servicio se interrumpe o si superas los límites de uso del proveedor. Estos límites suelen medirse en tokens por minuto (TPM) y peticiones por minuto (RPM).
Prueba el modelo de respaldo con el mismo conjunto de casos que el principal. Si cambia el formato de salida o la calidad baja mucho, no es un respaldo real.
Si eliges modelos de otro proveedor como respaldo, revisa también sus condiciones de tratamiento de datos. Es la soberanía del dato que vimos en el capítulo 1.
Lista rápida para elegir el modelo de cada agente
- Sé qué tipo de tarea resuelve: razonamiento, transformación o extracción.
- He probado primero con el modelo más pequeño que podría servir.
- Tengo un conjunto de casos reales para comparar modelos.
- Sé cuánta información necesita leer y si conviene usar RAG.
- Conozco la espera máxima aceptable en ese paso.
- He calculado el coste mensual con los precios actuales del proveedor.
- Uso una versión fija, no un nombre genérico como
latest. - Tengo un modelo de respaldo probado.
Conclusión
Elegir un modelo no consiste en buscar el más potente, sino el más adecuado para cada paso. Un modelo pequeño puede clasificar y extraer datos con rapidez y a muy bajo coste. Un modelo de frontera aporta valor donde hace falta razonar a fondo, como en la revisión de riesgos. Si valoras cada paso según el tipo de tarea, el contexto, la latencia y el coste, lo pruebas con tus propios casos y fijas versiones con un respaldo preparado, construirás sistemas más rápidos, más baratos y más estables.
¿Quieres elegir el modelo adecuado para cada uno de tus agentes? Visita libertadia.com y regístrate en la aplicación.