Cada nuevo modelo de IA llega acompañado de una pregunta casi inevitable: ¿es mejor que el anterior? Se comparan capacidades de razonamiento, programación, comprensión multimodal, contexto o rendimiento en diferentes benchmarks. Durante unos días o unas semanas, un modelo ocupa la primera posición hasta que aparece el siguiente.
Para quienes construyen sistemas empresariales, sin embargo, existe una pregunta bastante más útil: ¿es este el modelo adecuado para lo que necesitamos hacer?
Porque el modelo con mayor capacidad no siempre es el que ofrece la mejor solución. Coste, velocidad, privacidad, ubicación del dato, disponibilidad, especialización, capacidad de integración y nivel de riesgo pueden ser tan importantes como la inteligencia del propio modelo.
Elegir correctamente implica dejar de pensar en términos de mejor modelo y empezar a pensar en términos de modelo adecuado.
No existe un único criterio para definir «mejor»
Comparar modelos es necesario. Las evaluaciones permiten conocer sus fortalezas y limitaciones y ofrecen información útil para tomar decisiones. El problema aparece cuando convertimos esa comparación en una clasificación universal.
Un modelo puede obtener resultados extraordinarios en tareas complejas de razonamiento y resultar innecesariamente caro para clasificar miles de documentos sencillos.
Otro puede responder con enorme rapidez, pero no ofrecer la precisión necesaria para determinado proceso.
Un modelo abierto desplegado en infraestructura propia puede no alcanzar el rendimiento general de los modelos más avanzados y, sin embargo, ser la opción correcta cuando existen determinados requisitos de privacidad, control o soberanía del dato.
La pregunta sobre «cuál es el mejor modelo» está incompleta. Hay que añadir, ¿mejor para qué?
La tarea debe determinar la tecnología
No todas las tareas requieren el mismo nivel de inteligencia. Extraer campos de una factura, clasificar un documento, resumir una conversación, generar código, analizar un contrato o resolver un problema complejo son actividades diferentes.
Utilizar el modelo más potente disponible para todas ellas puede funcionar técnicamente. Eso no significa que sea una buena arquitectura.
Los modelos de mayor capacidad suelen implicar compromisos en otras dimensiones: coste, latencia o consumo de recursos, entre otras. En sistemas con grandes volúmenes, esas diferencias pueden multiplicarse rápidamente.
Un proceso que ejecuta millones de inferencias no debería optimizarse con los mismos criterios que una aplicación utilizada unas pocas veces al día para resolver problemas complejos.
La eficiencia comienza por ajustar la capacidad a la necesidad.
Coste y latencia también forman parte de la inteligencia del sistema
Cuando evaluamos una solución de IA solemos concentrarnos en la calidad de la respuesta.
En producción hay más variables.
- ¿Cuánto tarda en responder?
- ¿Cuánto cuesta cada operación?
- ¿Qué ocurre cuando aumenta el volumen?
- ¿Qué disponibilidad ofrece el proveedor?
Una diferencia aparentemente pequeña puede resultar decisiva cuando se multiplica por miles o millones de ejecuciones.
Esto introduce una idea importante: la optimización no debería hacerse únicamente a nivel de modelo, sino a nivel de sistema completo.
Puede tener más sentido utilizar un modelo ligero para resolver la mayoría de los casos y recurrir a uno más avanzado únicamente cuando la complejidad lo requiere.
Incluso una misma tarea puede seguir rutas diferentes según sus características.
La arquitectura puede decidir.
Los datos también condicionan la elección
Existe otra variable que no aparece en muchos benchmarks: dónde puede estar el dato.
No toda la información tiene la misma sensibilidad ni está sometida a los mismos requisitos. Una organización puede aceptar que determinada información sea procesada mediante un servicio público en la nube y exigir que otros datos permanezcan dentro de una infraestructura específica.
En algunos casos, puede necesitar ejecutar un modelo en una nube privada o incluso on-premise. En otros, la ubicación geográfica del procesamiento o las condiciones contractuales del proveedor pueden ser determinantes.
Por eso, seleccionar un modelo no es únicamente una decisión sobre capacidades.
También es una decisión sobre arquitectura del dato, seguridad y gobierno.
Especialización frente a capacidad general
Los grandes modelos generalistas son extraordinariamente versátiles. Pero versatilidad y especialización son cualidades distintas.
Determinadas tareas pueden resolverse mejor mediante modelos específicamente entrenados o ajustados para una función concreta. En otros casos, modelos más pequeños pueden ofrecer resultados suficientes con mucha mayor eficiencia.
Incluso puede que la solución adecuada no consista únicamente en cambiar de modelo.
Proporcionar mejor contexto, mejorar la recuperación de información, estructurar correctamente las instrucciones o dividir un problema en varias etapas puede producir mejoras mayores que sustituir el modelo por otro más potente. Esto obliga a mirar el sistema en su conjunto.
Cuando una solución no alcanza el resultado esperado, la respuesta no debería ser automáticamente «necesitamos un modelo mejor».
Quizá necesitemos mejores datos, una arquitectura diferente o una definición más precisa del problema.
La dependencia también tiene un coste
Elegir un modelo tiene además consecuencias a largo plazo. Si una aplicación se construye directamente alrededor de las características particulares de un proveedor, cambiar posteriormente puede resultar complejo.
Aparecen dependencias en APIs, formatos, herramientas, instrucciones y comportamientos específicos. Esto no significa que toda dependencia tecnológica sea negativa. Cualquier arquitectura toma decisiones y asume compromisos.
Pero esas dependencias deberían ser conscientes. En un mercado tan dinámico como el de la IA, preservar cierto grado de capacidad para sustituir modelos puede tener un valor considerable.
No solo por razones económicas. Un proveedor puede cambiar sus condiciones, retirar un modelo, modificar sus límites, alterar su disponibilidad regional o dejar de cumplir los requisitos que llevaron a seleccionarlo inicialmente.
La capacidad de adaptación debe formar parte del diseño.
Un sistema puede necesitar varios modelos
Si diferentes tareas tienen diferentes necesidades, la consecuencia lógica es sencilla: una misma organización puede necesitar diferentes modelos.
Incluso una misma aplicación puede hacerlo. Un modelo rápido y económico puede clasificar una petición. Otro puede recuperar o procesar información. Un tercero puede encargarse del razonamiento complejo. Un modelo especializado puede resolver una función muy concreta.
La aplicación no debería necesitar conocer toda esa complejidad. Una capa de abstracción puede determinar qué modelo utilizar según políticas y criterios definidos por la organización.
Este es uno de los principios sobre los que en LAUDE hemos desarrollado KLIA: desacoplar las aplicaciones de los modelos y proporcionar una capa desde la que gobernar su acceso y selección.
El objetivo no es utilizar más modelos. Es poder utilizar el modelo adecuado cuando aporta valor, sin trasladar toda esa complejidad a cada aplicación.
Del model routing al intelligent routing
Seleccionar modelos según reglas predeterminadas es un primer paso. Pero el problema puede llevarse más lejos.
Imaginemos que una solicitud llega a un sistema y este puede analizar automáticamente su complejidad, sensibilidad, requisitos de latencia o coste antes de decidir qué modelo debe resolverla.
Las peticiones sencillas podrían dirigirse a modelos eficientes. Las complejas, a modelos con mayor capacidad. Los datos sensibles, a entornos específicamente autorizados.
La selección deja entonces de ser estática. Se convierte en enrutamiento inteligente.
Este enfoque permite optimizar simultáneamente varias dimensiones del sistema y modificar los criterios a medida que cambian los modelos disponibles. La inteligencia ya no reside únicamente en el modelo que responde. También reside en la arquitectura que decide cómo utilizarlo.
Evaluar con nuestros propios casos de uso
Los benchmarks públicos son útiles, pero tienen una limitación evidente: no representan necesariamente nuestros problemas.
La prueba realmente relevante consiste en evaluar los modelos con tareas, datos y condiciones similares a las que encontrarán en producción.
- ¿Qué calidad obtenemos con nuestros documentos?
- ¿Qué errores comete con nuestras consultas?
- ¿Qué latencia observamos con nuestro volumen?
- ¿Cuánto cuesta alcanzar el nivel de calidad que necesitamos?
- ¿Cómo se comporta ante nuestros casos límite?
Estas evaluaciones permiten tomar decisiones basadas en evidencia propia y no únicamente en resultados publicados por terceros.
Además, deberían repetirse. El modelo elegido hoy no tiene por qué seguir siendo la mejor opción dentro de un año.
Diseñar para poder elegir
La velocidad a la que evoluciona la IA hace difícil anticipar qué modelos dominarán dentro de unos años. Probablemente tampoco sea necesario hacerlo.
Una arquitectura robusta no debería depender de acertar hoy cuál será el proveedor ganador mañana. Debería permitir elegir. Cambiar de modelo cuando aparezca una alternativa mejor. Combinar diferentes proveedores. Ejecutar determinados modelos en infraestructura privada. Optimizar costes. Adaptarse a nuevos requisitos regulatorios o de seguridad. En definitiva, mantener capacidad de decisión.
La pregunta estratégica no es qué modelo elegir, cómo construir sistemas que permitan elegir el modelo adecuado en cada momento.
Porque en IA, la ventaja no estará necesariamente en disponer siempre del modelo más potente, sino en saber cuándo utilizar cada uno.