Elegir el modelo de IA: tres preguntas que pesan más que el ranking

Las comparativas entre GPT, Claude, Gemini y Llama cambian cada pocos meses y ninguna responde a la pregunta que importa en una empresa: qué modelo funciona con sus documentos, su volumen y sus restricciones de datos. La elección se decide con tres preguntas concretas. Y la arquitectura tiene que permitir cambiar la respuesta sin rehacer el sistema.

El ranking público responde a una pregunta distinta de la que tiene la empresa

Los benchmarks que publican proveedores y laboratorios miden capacidades generales: razonamiento, programación, comprensión de textos largos. Sirven para saber qué familia de modelos está al día. Dicen poco sobre si un modelo clasifica bien las incidencias de un servicio técnico escritas en castellano, con abreviaturas propias y adjuntos a medio escanear.

Por eso el primer paso es construir un conjunto de evaluación propio. Bastan entre 50 y 100 ejemplos reales del proceso, con la respuesta correcta anotada por alguien del negocio: correos que hay que clasificar, facturas de las que hay que extraer campos, preguntas que recibe atención al cliente. Con ese conjunto se prueban dos o tres modelos en una tarde. El resultado es un número que sí se puede comparar.

En la práctica, ese conjunto se convierte en la prueba de regresión del sistema. Cada cambio de prompt, de modelo o de proveedor se valida contra él antes de llegar a producción, igual que se valida un cambio de código.

Dónde pueden ir los datos decide la mitad de la elección

La segunda pregunta es de gobernanza. Hay procesos cuyos datos pueden viajar a la API de un proveedor y procesos en los que la información tiene que quedarse en la infraestructura de la empresa: datos financieros, historiales de clientes, documentación sujeta a contrato.

Para el primer caso, los modelos comerciales vía API (Anthropic, OpenAI, Google) son la opción más rápida y la de mejor calidad por euro. Para el segundo hay dos caminos. Azure y AWS ofrecen esos mismos modelos dentro de la cuenta y la región del cliente, a través de Azure OpenAI Service o Amazon Bedrock, de modo que los datos no salen del entorno que la empresa ya administra. Y los modelos de pesos abiertos, como Llama o Mistral, se pueden desplegar en servidores propios cuando el requisito es aún más estricto.

Lo que cambia con un modelo propio es el coste operativo. Alguien tiene que dimensionar la GPU, actualizar versiones y vigilar la latencia. Conviene asumirlo solo cuando el requisito de datos lo exige o el volumen lo compensa.

El volumen convierte el precio por token en una decisión de arquitectura

Con unos cientos de peticiones al día, el precio del modelo apenas se nota en la factura y lo razonable es usar el mejor disponible. Con decenas de miles de peticiones diarias, la diferencia entre un modelo pequeño y uno grande separa un coste asumible de uno que obliga a parar el proyecto.

La respuesta habitual es enrutar. Un modelo pequeño y rápido clasifica y resuelve los casos sencillos. Los casos que fallan una validación o superan un umbral de complejidad pasan a un modelo grande. Lo que ninguno resuelve con confianza suficiente llega a una persona. El mismo esquema sirve para atención al cliente, para extraer datos de documentos o para revisar contratos.

A cambio, hay que medir. El enrutamiento solo funciona si existe el conjunto de evaluación de la primera pregunta, porque es lo que dice qué parte de los casos puede quedarse en el modelo barato sin perder calidad. Otras dos palancas bajan la factura sin tocar la calidad: la caché de prompts que ofrecen los proveedores para los prefijos que se repiten en cada petición, y el procesamiento por lotes para todo lo que no necesita respuesta inmediata.

La arquitectura debe permitir cambiar de modelo sin reescribir el sistema

Los modelos que hoy encabezan las comparativas serán sustituidos en meses. Por eso ningún proceso debería llamar al proveedor directamente desde la lógica de negocio. En los sistemas que construimos, una capa intermedia recibe la petición, elige proveedor y modelo según el tipo de tarea, registra el coste y devuelve la respuesta con el mismo formato sea cual sea el modelo de detrás.

Esa capa hace tres cosas por la empresa. Permite probar un modelo nuevo contra el conjunto de evaluación y activarlo con un cambio de configuración. Permite tener un proveedor de respaldo cuando el principal falla o retira un modelo, algo que ocurre con más frecuencia de la que parece. Y da una visión del coste por proceso que la factura del proveedor nunca da.

Dicho de otro modo, la decisión importante es reversible. Elegir hoy Claude, GPT o un Llama desplegado en Azure importa menos que poder cambiarlo en una semana cuando el conjunto de evaluación diga que otro modelo lo hace mejor o más barato.

Por dónde empezar esta semana

• Elegir un único proceso con volumen medible y un responsable de negocio que pueda anotar respuestas correctas.
• Reunir 50 ejemplos reales con su respuesta esperada y guardarlos como conjunto de evaluación.
• Clasificar los datos de ese proceso en tres grupos: pueden salir a una API, deben quedarse en la nube propia, o no pueden salir de la empresa.
• Probar dos modelos de proveedores distintos contra el conjunto y anotar calidad, latencia y coste por mil peticiones.
• Diseñar la integración con una capa intermedia desde el primer día, aunque solo haya un modelo detrás.

Si el caso encaja, en LakeTab lo revisamos en una primera llamada de 60 minutos.