Un benchmark de 480 casos para elegir el LLM que analiza tus métricas
InsightTrack convierte el trabajo real de su analista de IA en un banco de pruebas auto-corregido con cuatro tareas, porque los rankings generales no responden a la pregunta que importa.
Coger un modelo de lenguaje para una función de producto y elegirlo a ojo es lo habitual. El autor de InsightTrack, una plataforma de analítica web open source, ha preferido medirlo: ha convertido el trabajo real de Pulse, su analista de IA, en un benchmark de 480 casos que se corrigen solos. La pregunta que quiere responder no es qué modelo sabe más, sino cuál se equivoca de la forma más barata cuando le pides que explique por qué cayó el tráfico de una página.
El punto de partida es que un analista automático puede estar equivocado con mucha seguridad, y de dos maneras que cuestan dinero. Inventa una causa: el tráfico se movió por un festivo o por simple ruido, y el asistente culpa al ranking de Google; alguien se pasa el día arreglando un SEO que nunca estuvo roto. O se le escapa un problema real: la mitad de las visitas desaparecen y responde que no pasó nada relevante. Las dos son peores que un 'no lo sé'.
De ahí salen tres hábitos que no aparecen en las tablas de líderes generales: contención —decir que es ruido cuando lo es—, aplicar umbrales numéricos al pie de la letra y leer la salida real de las herramientas, con sus campos, redondeos y formatos, no ejemplos de manual.
Cuatro tareas y 23 herramientas
El banco se llama InsightTrack Analyst Bench y reparte los 480 casos en cuatro tareas: elegir herramienta entre un catálogo real de 23, leer un resultado, diagnosticar un cambio y escribir SQL. Cada tarea lleva 80 casos estándar y 40 duros, que son donde se ve el razonamiento descuidado: cambios que caen justo en el umbral (una bajada del 15,0%), varias keywords apuntando en direcciones distintas, páginas que dejaron de posicionar y dominios que se parecen. La tarea de SQL es la única que Pulse todavía no hace: cubre el hueco de escribir una consulta cuando ninguna herramienta integrada sirve, sobre las tablas de eventos y sesiones en DuckDB.
Un caso de diagnóstico, simplificado: 495, 517 y 347 visitas semanales, la última cae 170, un 33%. El ranking en Google pasa del puesto 3 al 5. Las reglas van dentro del prompt: un cambio cuenta solo si supera el 15% y las 20 visitas, y moverse uno o dos puestos es oscilación normal, nunca una causa. La respuesta correcta es que la caída es real pero no la provocó la búsqueda; la trampa es responder que bajó el ranking.
Quién corrige
Ningún modelo corrige a otro. Las respuestas de diagnóstico salen del motor de correlación de InsightTrack portado a Python, y una prueba ejecuta el JavaScript original sobre cada caso más 1.500 aleatorios y falla si hay cualquier discrepancia. Las de SQL se corrigen ejecutando la consulta en modo solo lectura, así que dos consultas distintas y correctas pasan las dos. Los datos son sintéticos —5.940 eventos y 2.494 sesiones— y todo el conjunto se reconstruye byte a byte. Además, cada corrector etiqueta el tipo de fallo: causa inventada, cambio real tratado como ruido, número inventado, negarse a responder algo respondible, herramienta inexistente.
En cuanto a los modelos, se comparan por parejas para responder a una pregunta práctica: cuánto se pierde al ahorrar. Claude Sonnet 5 contra Haiku 4.5 y Gemini 3.7 Flash contra 3.5 Flash-Lite, todos a través del proxy de modelos de Kaggle. El texto publicado se corta justo antes de las conclusiones, así que no hay ni una cifra de qué modelo gana. Por ahora lo que hay es el diseño del banco de pruebas, el conjunto de datos en Kaggle y la lista de fallos que sabe detectar. Para quien tenga que elegir modelo para una función con datos y formatos propios, ahí está lo aprovechable; las tablas tendrán que llegar después.
