Grounding: por qué una buena IA de analítica no debe saber nada, sino consultar

Hay un principio de producto detrás de la analítica con IA que suena mal la primera vez que lo oyes: el modelo no debería saber nada.

No «no debería saber mucho». No debería depender de saber. Cada dato que afirme sobre tu negocio debería haber llegado en los últimos cientos de milisegundos, desde tu base de datos, a través de una llamada a una herramienta — y no desde una matriz de pesos entrenada hace meses con el internet público.

Esa restricción tiene nombre. Se llama grounding — anclar cada afirmación al dato recuperado — y es la diferencia entre un asistente que puedes poner delante de un equipo de marketing y un generador de texto muy seguro de sí mismo.

Saber frente a consultar

Un chatbot generalista responde desde sus parámetros. Le preguntas cuál es la capital de Perú y produce «Lima» porque esa asociación está codificada en sus pesos. No hay consulta, ni fuente, ni cita: solo una conjetura estadística muy buena. Casi siempre acierta. Cuando falla, falla exactamente con el mismo tono de voz.

Un asistente de analítica no puede funcionar así, por una razón evidente: tus entradas del martes pasado nunca estuvieron en los datos de entrenamiento de nadie. No hay nada que recordar. Si el modelo produce un número, o lo ha consultado o lo ha fabricado. No hay tercera opción.

Así que el objetivo de diseño se invierte. En lugar de hacer al modelo más listo sobre el mundo, lo haces estructuralmente incapaz de responder sin ir antes a buscar el dato.

Qué es el grounding dentro del stack, en la práctica

El grounding no es una línea en el system prompt que diga «no te inventes nada». Los modelos aceptan esa instrucción y luego se inventan cosas igualmente. Es una forma que le das a todo el recorrido de la petición:

1. La pregunta llega en lenguaje natural. «¿Qué canal generó más conversiones el mes pasado?»
2. El modelo elige herramientas, no respuestas. El asistente de Seal AI dispone de un inventario de 63 herramientas: visión general, canales, campañas, embudos, segmentos, landing pages, etcétera. Su primer trabajo es decidir cuáles llamar y con qué parámetros.
3. Las herramientas consultan tus datos. Filas reales, agregados reales, acotados a tu cuenta y a tu zona horaria.
4. Los resultados vuelven al prompt. Los números están ahora literalmente delante del modelo, en forma de texto.
5. El modelo narra e interpreta. Lee lo que ha vuelto, lo ordena, detecta la tendencia, sugiere qué mirar después. Está haciendo trabajo lingüístico sobre evidencia, no recuperación desde la memoria.

El paso cinco es el único en el que la inteligencia del modelo se gasta en la pregunta real. Todo lo anterior es fontanería — y la fontanería es lo que hace que la respuesta sea cierta.

La recompensa: un modelo «malo» puede ser el modelo adecuado

Esta es la versión honesta de nuestro propio caso. El modelo que hay dentro de Seal AI es gpt-oss-120b. En SimpleQA — un benchmark de preguntas factuales cortas sobre el mundo — obtiene 0,168 de precisión con una tasa de alucinación de 0,782. Leído en frío, parece descalificante. Un modelo que se inventa con aplomo la respuesta a cuatro de cada cinco preguntas de cultura general no es algo que quieras narrando un informe de ingresos.

Salvo que nunca se le hace una pregunta de cultura general. Nadie abre una herramienta de analítica para averiguar quién ganó unas elecciones de 1994. Al asistente se le pide que lea entradas, conversiones, canales y tasas de rebote que han llegado a su ventana de contexto hace un instante, y que explique qué significan. La capacidad que mide SimpleQA es justo la que el producto ha decidido no usar.

Lo que el producto sí usa, ese mismo modelo lo hace bien: MMLU 90,0, MMLU-Pro 80,8, GPQA Diamond 80,1 sin herramientas y — lo más relevante aquí — tool-calling fiable contra un inventario grande de herramientas. El grounding es lo que te permite gastar el presupuesto de modelo en las capacidades que importan e ignorar las que no.

El grounding en el que confías es el grounding que has probado

Una arquitectura que debería impedir la invención no es lo mismo que una que la impide. Un modelo puede llamar a una herramienta, obtener una respuesta parcial y rellenar el hueco discretamente con algo razonable. La única forma de saberlo es comprobar todos los números.

Así ejecutamos nuestro benchmark interno: 18 escenarios en dos idiomas, tres pasadas, tres modelos candidatos — 162 consultas en vivo contra el endpoint real del asistente en producción, con el inventario real de 63 herramientas. Antes de cada ejecución, el harness calculaba la verdad de referencia directamente desde la base de datos analítica — entradas, conversiones, tasa de rebote, ingresos, canal principal, fuente principal, dispositivo principal — para que cada cifra afirmada por el asistente pudiera compararse con la realidad mediante un corrector determinista, y no por un humano leyendo y asintiendo.

El modelo que enviamos a producción afirmó correctamente 144 de 144 hechos verificados. Todos y cada uno de los fallos factuales de la ejecución completa se remontan a una pregunta mal formulada por nuestra parte, sobre la que volveremos.

Trampas: preguntar por cosas que no existen

Comprobar las respuestas correctas solo cuenta la mitad de la historia. El fallo interesante no es un número equivocado: es un número donde debería haber habido un reconocimiento de que no hay dato.

Por eso cada bloque de idioma incluía trampas de grounding: preguntas sobre una campaña que nunca se lanzó, o sobre un periodo del que la cuenta no tiene datos. Solo hay un comportamiento correcto: decir que el dato no está, y decir por qué. Cualquier cosa fluida y con números es un fallo, por bien escrita que esté.

Los resultados fueron más interesantes que una tabla de apto y no apto. El modelo que enviamos a producción superó 18 de 18 trampas (intervalo de confianza de Wilson al 95%: 0,82-1,00). Una de las alternativas, mistral-small-3.2, superó 9 de 18 — y su modo de fallo era sutil. Preguntado por una campaña inexistente, reconocía correctamente la ausencia y después se iba por las ramas describiendo otras campañas reales con cifras que nadie había pedido. Eso no es invención: los números eran ciertos. Es responder a otra pregunta, que en un informe es otra forma de estar equivocado. En inglés, además, alegó una incapacidad falsa — «no tengo acceso a las herramientas necesarias» — en lugar de explicar el límite temporal de los datos.

Los intervalos de Wilson importan aquí: el del ganador ya no se solapa con el de mistral, así que con este tamaño de muestra la diferencia es estadísticamente significativa y no una racha de suerte.

La pregunta que formulamos mal

Un escenario pedía «tráfico por dispositivo del último mes». Eso admite dos lecturas: los últimos 30 días, que era nuestra verdad de referencia, o el mes natural anterior. Algunos modelos eligieron el mes natural, en el que la cuenta de prueba solo tenía cinco días de datos, y respondieron con esos números reales. El corrector los marcó como fallos.

No eran alucinaciones. Eran respuestas correctas a una pregunta que habíamos redactado mal. El cien por cien de los fallos factuales de toda la ejecución se remonta a ese único escenario. Lo reformulamos, y mantenemos el defecto documentado, porque un benchmark que solo publica los resultados que le favorecen es una demo. Lo mismo vale para nuestra primera ejecución completa, que descartamos entera: el harness reveló que el asistente estaba reutilizando la sesión de chat entre consultas, lo que permitía que unos modelos leyeran el historial de los anteriores. Lo arreglamos, repetimos y archivamos ambas.

Qué significa esto cuando usas el asistente

En la práctica: pregúntale por qué. Un asistente con grounding puede decirte qué métrica, qué periodo y qué desglose han producido una cifra, porque los ha consultado hace segundos. Si un asistente no puede enseñarte su evidencia, ese número es una afirmación, no una medición.

Y pruébalo una vez con algo que no existe: una campaña que nunca lanzaste, un mes anterior a la instalación del tracker. La respuesta que quieres es la aburrida: no hay datos de eso. Un asistente dispuesto a decir «eso no lo tengo» es el único en el que merece la pena creer cuando dice que sí lo tiene.

Más sobre cómo se eligió el modelo en el análisis del benchmark de 162 consultas, y sobre la arquitectura que hay detrás en la documentación de arquitectura de Seal AI.