Por qué ChatGPT olvida tus definiciones de métricas y cómo solucionarlo (2026)

El nombre de una métrica no es una métrica

"Margen bruto" son cuatro sílabas que podrían significar seis cosas diferentes. AtScale abre su artículo sobre el coste de la deriva semántica con tres equipos que responden a la pregunta "¿Cuál fue nuestro margen bruto el trimestre pasado?" y devuelven un 30%, un 32% y un 31%: tres números defendibles a partir de tres definiciones de lo que se considera coste de ingresos.

Tu asistente hereda esta ambigüedad sin heredar tu resolución de la misma. Cuando dices "churn" (pérdida de clientes), el modelo tiene una fuerte suposición previa sobre lo que significa churn en general y ninguna información sobre el hecho de que tu empresa lo mide sobre los ingresos en lugar de sobre las cuentas, de forma mensual en lugar de anual, y excluyendo las reducciones de plan (downgrades). A falta de tu definición, utiliza la suposición previa. Eso no es un fallo de memoria en el sentido estricto; es un fallo de memoria que se presenta como una respuesta segura.

La definición vive en las personas, no en los datos

Esta es la parte que hace que las definiciones de métricas sean más difíciles que el esquema. Una tabla tiene una forma que puedes inspeccionar; el modelo puede leer los nombres y tipos de las columnas. Una definición es una decisión (alguien decidió, en algún momento, que las pruebas no cuentan) y esa decisión queda registrada en un hilo de Slack, en el SQL de un cuadro de mando o en la cabeza de alguien.

El consenso de la industria al respecto es inusualmente tajante. Como señala AtScale: "Los sistemas de IA no solo no logran conciliar definiciones en conflicto. Empeoran el problema al presentar con total confianza respuestas inconsistentes". El fallo no es que el modelo invente las matemáticas. Es que el modelo ejecuta fielmente cualquiera de las diversas definiciones de tu organización que haya logrado reconstruir.

Observa en qué se diferencia esto de que ChatGPT pierda el rastro de tu esquema de datos. La pérdida del esquema produce errores que notas: una columna que no existe, una unión (join) que falla. La pérdida de la definición produce números que no cuadran con nada, y te enteras en plena reunión.

Nada transmite una definición entre sesiones

Incluso cuando lo haces bien en una conversación, el mecanismo que la llevaría adelante no existe para este tipo de contenido. La memoria integrada almacena un par de páginas de datos breves sobre ti; una definición de nueve cláusulas de pipeline cualificado con sus exclusiones no es para lo que está dimensionada. Las instrucciones personalizadas pueden albergar dos o tres definiciones antes de desplazar todo lo demás. Los archivos de proyecto ayudan, pero están limitados a ese Proyecto y a esa herramienta.

Así que la definición se vuelve a proporcionar a mano, lo que significa que se proporciona de forma aproximada. La versión que escribes el jueves es más corta que la del lunes, porque estás escribiendo de memoria y las exclusiones son la parte aburrida. La desviación se introduce a través de tu propio resumen.

Las definiciones cambian y la versión antigua no se retira

El problema agravado: revisas la definición en el tercer trimestre (Q3), y cada análisis anterior se calculó con la versión del segundo trimestre (Q2). Un flujo de trabajo basado en chat no tiene un lugar para registrar que una definición reemplazó a otra en una fecha determinada. Así que terminas con números calculados bajo reglas diferentes y nada que te diga cuál es cuál: el equivalente analítico a una documentación sin fecha.

Pegar las definiciones al principio de cada chat. Es eficaz, y por eso es el enfoque más común. También se degrada: el bloque pegado se acorta con las semanas y es por chat, por lo que cualquier otra persona del equipo estará pegando su propia versión.

Poner las definiciones en las instrucciones personalizadas. Es mejor para las dos o tres métricas que usas a diario, y realmente vale la pena hacerlo. Luego se queda sin espacio y habrás gastado tu presupuesto de instrucciones en definiciones en lugar de en cómo quieres que se comporte el asistente.

Usar un Proyecto con un documento de definiciones adjunto. La mejor de las opciones integradas en el producto. Sin embargo, está limitado a ese Proyecto, y si también trabajas en un agente de programación o en una herramienta de BI, ese documento no será visible desde allí.

Permitir que el asistente lea el SQL. Ingenioso y parcialmente eficaz: la definición realmente está en la consulta. Lo que se pierde es la intención y las excepciones: el SQL muestra una cláusula WHERE status != 'internal', pero no que la cláusula existe debido a un hallazgo de auditoría, y muestra la versión de un cuadro de mando sin decirte que es la que está en disputa.

Construir una capa semántica. Esta es la respuesta profesional real, y debe decirse claramente: una capa semántica (la Semantic Layer de dbt, AtScale, Cube y otras de esa categoría) existe precisamente para definir una métrica una sola vez y hacer que cada herramienta la calcule de la misma manera. AtScale describe el objetivo como: "Cuando alguien pregunta: '¿Cuáles son nuestros ingresos?', hay una sola respuesta porque la definición se aplica de manera consistente en todas partes". Si tu organización funciona con métricas compartidas, esta es la inversión que debes realizar, y una capa de memoria no la sustituye.

AtScale también informa que los LLM que consultan bases de datos directamente alcanzan aproximadamente un 20% de precisión en preguntas comerciales, aumentando a una precisión prácticamente total cuando una capa semántica proporciona definiciones gobernadas, lógica de negocio multidimensional y relaciones contextuales. Esa cifra proviene de un proveedor interesado en la conclusión y no debe tratarse como un punto de referencia independiente, pero la dirección no es controvertida y es el argumento más sólido disponible a favor de las definiciones gobernadas.

La brecha que la capa semántica no cierra es en la que te encuentras actualmente: el asistente en el que pegas un CSV a las 6 de la tarde, la pregunta ad-hoc que nunca pasa por la capa modelada, la definición que existe como una decisión pero que aún no se ha implementado como métrica, y cada análisis realizado por alguien que no tiene acceso a BI. Ahí es donde se pierden las definiciones, y es la mayor parte del análisis que realmente ocurre.

Mantén las definiciones fuera del chat, en un almacén que el asistente lea en cada solicitud. No una nota desde la que pegas, sino una capa que suministre la definición como parte de la respuesta.

Lo que hace que esto funcione no es el almacenamiento; es que la definición llega con su contexto. Una definición almacenada puede contener las exclusiones, el motivo de cada exclusión, quién la aprobó, cuándo cambió por última vez y cuál era la versión anterior. Esa es la diferencia entre "activo = pagado en 90 días" y una definición por la que realmente se puedan exigir responsabilidades a alguien.

MemoryLake es una capa de memoria diseñada para eso: tus definiciones, registros de decisiones y documentos de origen en un solo almacén que ChatGPT lee a través de la API y que las herramientas compatibles con MCP como Claude y Codex leen directamente. De este modo, la misma definición llega al chat ad-hoc, al agente de programación que escribe la consulta y al analista que se incorporó la semana pasada.

Dos límites, expresados claramente porque este es un ámbito donde la sobreventa causa un daño real:

• Una capa de memoria hace que las definiciones estén disponibles, sean consistentes y trazables. No las impone. La imposición es lo que hace una capa semántica: calcular cada consulta a través de una única definición. Una capa de memoria suministra la definición a quien la solicite; no puede evitar que a un modelo se le entregue una tabla sin procesar y realice su propia aritmética. Si un número va a ir a una presentación para la junta directiva o a un informe oficial, debe provenir de tu capa gobernada, no de un chat.
• Las definiciones necesitan sus metadatos, o de lo contrario habrás trasladado el problema. Una tabla de dos columnas con nombres de métricas y fórmulas es exactamente el artefacto que causó la desviación. Lo que debe viajar es el nivel de detalle (grain), la ventana de tiempo, las exclusiones y su porqué, el propietario y la fecha de entrada en vigor.

Paso 1: Crea una clave de API

Genera una clave y realiza tu primera solicitud en unos 30 segundos. Manténla en tu entorno o en un gestor de secretos en lugar de incluirla directamente en una configuración o cuaderno que se comparta.

Paso 2: Sube tus primeros recuerdos

Arrastra los documentos, imágenes y archivos donde realmente viven tus definiciones: el documento de métricas, la especificación del cuadro de mando, el hilo de Slack donde se decidió la exclusión, la nota de auditoría que la provocó. Sube las fuentes, no un resumen simplificado. El resumen simplificado es donde "excluyendo cuentas internas" desaparece silenciosamente.

Paso 3: Conecta tu IA y agentes

Dale a Claude, Codex, OpenClaw y otros agentes de IA acceso a la memoria a través de MCP o la API. ChatGPT no tiene cliente MCP, así que recupera las definiciones relevantes a través de la API e inyéctalas en el prompt, en un GPT personalizado o en el flujo de trabajo que llama al modelo. Para las herramientas que admiten MCP, añade el servidor a la configuración de esa herramienta y leerán del mismo almacén, que es de lo que se trata: una definición, varios consumidores.

El número del jueves coincide con el del lunes. Ese es todo el titular, y vale la pena expresarlo sin adornos: la misma pregunta calculada con la misma definición produce la misma respuesta, porque la definición no tuvo que volver a escribirse.

El segundo cambio es que el desacuerdo se vuelve productivo. En este momento, cuando dos números no coinciden, pasas una hora reconstruyendo qué medía cada uno. Cuando la definición se almacena con sus exclusiones y fecha de entrada en vigor, comparas definiciones en lugar de aplicar ingeniería inversa a la aritmética, y a menudo descubres que ambos números eran correctos y respondían a preguntas diferentes.

El tercero es la incorporación (onboarding). El primer mes de un nuevo analista se dedica en gran parte a aprender que las pruebas no cuentan. Cuando eso está en un almacén que leen sus herramientas, comienzan con la versión institucional en lugar de tener que reconstruirla a partir de cuadros de mando.

Y las revisiones se vuelven legibles. Una definición con una fecha de entrada en vigor te permite decir "este análisis utilizó la definición anterior a agosto" en lugar de esperar que nadie pregunte. Esa única propiedad (saber bajo qué reglas se calculó un número) es la mayor parte de lo que hace que un análisis sea defendible.

Escribe las exclusiones y el motivo, no solo la fórmula

"Activo = factura pagada en los últimos 90 días" es la mitad de una definición. La mitad que evita la desviación es: excluyendo pruebas (inflaron el número antes del cambio de precios de 2025), excluyendo cuentas internas (hallazgo de auditoría, marzo), contabilizado a nivel de cuenta, no a nivel de usuario (seat). Los motivos importan porque son lo que evita que alguien vuelva a discutir la exclusión cada trimestre.

Pon fecha a cada definición y conserva la antigua

Cuando una definición cambie, añade la nueva versión con una fecha de entrada en vigor y conserva la anterior marcada como reemplazada. Eliminar la definición antigua destruye tu capacidad para interpretar los números del trimestre pasado. Este es el hábito de mayor valor en toda la práctica y el que más se pasa por alto.

Nombra al propietario

Cada definición debe indicar quién la decide. No por burocracia, sino porque la pregunta "¿sigue siendo esto correcto?" necesita un destinatario. Las definiciones sin propietarios se desvían silenciosamente; las definiciones con propietarios se corrigen.

Mantén la capa gobernada como la fuente de referencia

Utiliza la capa de memoria para que las definiciones estén disponibles en todas partes, y mantén tu capa semántica o los modelos de tu almacén de datos como lo que realmente calcula los números reportados. Cuando ambos no coincidan, la capa gobernada gana y la entrada de memoria se corrige. Invertir esa jerarquía es la forma de acabar con un número incorrecto bien documentado.

ChatGPT olvida tus definiciones de métricas porque una definición es una decisión, no una propiedad de tus datos, y nada en un flujo de trabajo basado en chat transmite decisiones entre sesiones. Lo que obtienes en su lugar es la suposición previa del modelo sobre lo que suele significar el nombre de la métrica, ejecutada con confianza; por eso el fallo se manifiesta como un número que no cuadra en lugar de un error que puedas ver.

Mantener definiciones en un almacén que lean tus herramientas soluciona el problema de disponibilidad: la definición, sus exclusiones, su propietario y su fecha de entrada en vigor llegan con la pregunta. Conserva tu capa semántica para la imposición y para cualquier dato que se reporte. Entre ambas, la versión de "cliente activo" que explicaste el lunes seguirá siendo la que se use el jueves, y podrás demostrar qué versión utilizó cualquier número dado.