Cambiamos de modelo de IA dos veces en tres semanas — y ese es justo el punto

Esta parte no suele contarla nadie. El modelo que hay detrás de una funcionalidad de IA se anuncia una vez, en el post de lanzamiento, y cualquier cambio posterior ocurre en silencio. Nosotros hacemos lo contrario, porque esos cambios son lo más útil que podemos contarte sobre cómo se construyó la funcionalidad.

Seal AI es la capa de IA privada dentro de SealMetrics: haces una pregunta sobre tu analítica en lenguaje natural y responde llamando a herramientas contra tus datos — 63 en total, desde vistas generales y canales hasta embudos y segmentos. Ese trabajo castiga a los modelos de formas que los benchmarks generalistas no enseñan nunca. Esto es lo que pasó cuando probamos tres de ellos.

La línea temporal

1. 2 de julio de 2026 — gemma-4-26b-a4b. Primera elección. Sustituido tras demostrar que era demasiado débil para llamar funciones y degenerar en bucles de repetición.
2. 21 de julio de 2026 — mistral-small-3.2-24b. Denso de 24B, más rápido y más barato. Acabó con los bucles. Sustituido cuando el uso real destapó respuestas escuetas, negativas absurdas y formato roto.
3. 22 de julio de 2026 — gpt-oss-120b. El mejor de la terna en tool-calling, cero negativas, cero fallos de formato. El modelo por defecto hoy.
4. 24 de julio de 2026 — la verificación. 162 consultas reales contra tres modelos y dos idiomas, sobre el stack de producto real, para comprobar que la decisión aguantaba una medición y no solo una impresión.

Elección uno: no había parámetros activos suficientes para pensar

Empezamos con gemma-4-26b-a4b. Sobre el papel parecía una elección eficiente: un modelo mixture-of-experts, 26B de parámetros totales, barato de servir. El número que importaba era justo el que infravaloramos: solo unos 4B de parámetros activos por token.

Un modelo mixture-of-experts enruta cada token por un subconjunto pequeño de sus parámetros. El tamaño total te compra amplitud de conocimiento; el tamaño activo te compra razonamiento en cada paso. Cuatro mil millones de parámetros activos no dan para sostener un plan mientras eliges la función correcta entre 63, rellenas bien sus argumentos, lees el resultado y decides qué llamar a continuación.

El fallo no fue sutil. Fallaba al llamar funciones y, durante la fase de síntesis — la parte en la que convierte los resultados de las herramientas en prosa —, degeneraba en bucles de repetición, repitiendo la misma frase hasta dejar la respuesta inservible. Es un modo de fallo conocido de los modelos mixture-of-experts abiertos bajo presión de generación, y habíamos elegido una configuración especialmente expuesta a él.

Elección dos: se acabaron los bucles, empeoraron las respuestas

Diecinueve días después pasamos a mistral-small-3.2-24b: un modelo denso de 24B, más rápido y más barato de ejecutar. Denso significa que todos los parámetros participan en todos los tokens, así que el problema de razonamiento por paso desapareció. Combinado con controles de muestreo — temperatura baja y una penalización de frecuencia que frena la degeneración habitual de los modelos abiertos —, los bucles de repetición se acabaron.

Entonces el uso real empezó a generar otro tipo de quejas. La salida era escueta allí donde un marketer necesitaba una explicación. Producía negativas absurdas: se negaba a contestar preguntas que era perfectamente capaz de responder. Y se le rompía el formato: las partes estructuradas de una respuesta no volvían limpias de forma fiable.

Nada de eso aparece en un ranking. Todo eso aparece la primera vez que alguien pregunta algo real sobre su propio tráfico y recibe una no-respuesta de dos líneas.

Elección tres: gpt-oss-120b

Al día siguiente cambiamos a gpt-oss-120b: un modelo de pesos abiertos con licencia Apache 2.0, 117B de parámetros totales con 5,1B activos por token, ventana de contexto de 128k, cuantización nativa MXFP4 que le permite caber en una sola GPU de 80GB y soporte de primer nivel en vLLM.

Fue el que mejor llamaba a herramientas de los tres. Cero negativas. Cero fallos de formato. Y entregó una calidad a la altura de un modelo que cuesta unas cuatro veces más de ejecutar, algo que importa porque un asistente de analítica que la gente usa de verdad lanza muchísimas consultas.

Que sea de pesos abiertos tampoco es un detalle menor. Podemos fijar una versión exacta, inspeccionarla, hacerle red teaming y reproducir un resultado meses después. Una API cerrada puede cambiar bajo tus pies sin avisar; te enteras por un ticket de soporte.

Y después nos revisamos a nosotros mismos

Dos cambios en tres semanas basados en impresiones no son un proceso, así que montamos un benchmark: 18 escenarios en español e inglés, tres pasadas, tres modelos — 162 consultas reales — contra el endpoint real del asistente, el inventario real de 63 herramientas y los datos de una cuenta real, con la verdad de referencia (ground truth) calculada en vivo desde la base de datos de analítica para que cada cifra fuera comprobable.

gpt-oss-120b superó 18 de 18 trampas de grounding e inyección y acertó 144 de 144 hechos verificados. Mistral Small 3.2 superó 9 de 18. Su fallo característico no era inventar: al preguntarle por una campaña que no existe, reconoce la ausencia y luego se desvía a describir otras campañas reales con cifras que nadie había pedido. En inglés, además, alegaba una incapacidad falsa —«no tengo acceso a las herramientas necesarias»— en lugar de explicar dónde terminan realmente los datos.

Mistral fue de verdad el modelo más rápido de la tanda, con una mediana de respuesta en torno a los tres segundos, y su coste quedó a un pequeño porcentaje del ganador. Aun así perdió, porque la diferencia en las trampas era lo bastante amplia como para que los intervalos de confianza dejaran de solaparse. La velocidad vale poco si la respuesta cambia la pregunta por lo bajo.

Por qué cambiar dos veces es la funcionalidad, no el fallo

Cada uno de estos cambios fue barato para el cliente e invisible en el producto: el modelo se selecciona por configuración y el código del producto es idéntico entre modelos. Es deliberado. Si sustituir un modelo sale caro, dejas de sustituirlo y empiezas a defender el que ya tienes.

La alternativa a cambiar dos veces no es la estabilidad: es no mirar. Un equipo que no cambia de modelo en un año dentro de un campo en movimiento o tiene una suerte excepcional o no está midiendo. Preferimos decirte que nuestra primera elección fue mala antes que fingir que una trazabilidad con tres entradas solo tenía una.

Así que el resumen honesto es: pusimos en producción un modelo que no daba la talla, lo sustituimos por otro que hacía el trabajo mal de formas que solo el uso real revela, y aterrizamos en uno que después intentamos romper con ganas y no pudimos. La próxima entrada de esta trazabilidad se publicará igual.

El expediente completo de la decisión — la auditoría de mercado, los benchmarks públicos verificados y la tanda bilingüe íntegra — está en nuestro informe de selección de modelo. Si prefieres la metodología antes que el veredicto, lee cómo hacemos el benchmark de nuestra propia IA, o conoce Seal AI para ver qué hace realmente el asistente.