3. Memoria de los Modelos de Lenguaje
(Actualizado octubre 2025)
3.1 Qué llamamos "memoria" en un LLM (y la naturaleza stateless)
Un modelo de lenguaje de gran escala (LLM) no "recuerda" como un sistema de cómputo tradicional. El modelo base es sin estado (stateless): no conserva información alguna de una solicitud (request) a otra. Lo que se percibe como "memoria" surge exclusivamente de capas arquitectónicas externas al modelo base:
- Memoria Contextual (temporal): El historial de tokens recientes de la conversación que la plataforma vuelve a inyectar en el prompt de cada turno hasta agotar la ventana de contexto.
- Memoria Persistente (infraestructura): Datos guardados por la plataforma (preferencias, rasgos inferidos, hechos del usuario) que se almacenan en bases de datos externas y sistemas de recuperación.
⚠️ Punto crítico La persistencia de la conversación es una función de la aplicación envolvente (el wrapper), no del LLM. Toda "memoria" depende de cómo la aplicación reinyecta texto o recupera datos guardados.
3.2 Arquitectura en capas: dónde reside la "memoria"
La memoria surge del diseño de la aplicación que envuelve y orquesta las llamadas al modelo, operando en distintas capas funcionales. Es en la capa de Cliente/Plataforma donde se implementan los mecanismos de memoria:
Tabla 1 – Capas funcionales y alcance de la memoria
| Capa | Función | Memoria Propia | Duración |
|---|---|---|---|
| Transformador (Modelo) | Predice el siguiente token mediante el mecanismo de atención. | No | Solo durante la inferencia |
| Generador/Runtime | Tokeniza y mantiene un buffer de salida y gestión transitoria. | Mínima (transitoria) | Hasta EndOfText |
| Cliente/Plataforma | Gestiona el historial, resume, recupera datos externos y perfila al usuario. | Sí (contexto + DB) | Según el diseño de la sesión y la infraestructura |
Mecanismos habituales de persistencia:
- Contexto temporal: Reinyectar los últimos turnos o resúmenes condensados en el prompt.
- Recuperación Aumentada (RAG/Retrieval) - (Referido a menudo como Long-Term Memory): Seleccionar la información relevante (de DBs externas) y pre-instruir al modelo con el texto recuperado en el prompt de cada turno.
- Persistencia externa: Bases de datos de la plataforma con preferencias y "hechos" del usuario para personalizar la experiencia.
3.3 Memoria contextual: ventana de contexto y lost in the middle
Los modelos tienen un límite físico de tokens que pueden procesar por interacción. Esta es la ventana de contexto. Cuando una conversación excede este límite, las partes más antiguas se descartan automáticamente del prompt de entrada.
- Límite duro: El modelo "olvida" lo que ya no cabe en la ventana.
- Efecto blando (lost in the middle): Incluso antes de alcanzar el límite físico, la calidad de la respuesta se degrada. El modelo mantiene mejor la información reciente y pierde precisión con referencias a mensajes antiguos o intermedios en el prompt.
La pérdida de coherencia es común en sesiones muy largas: aparecen inconsistencias, referencias cruzadas incorrectas o respuestas que ignoran información crucial. Esto es una consecuencia directa de la gestión limitada del contexto secuencial de la arquitectura transformer.
⚠️ No confundir Una ventana de contexto más grande no equivale a "memoria real". Significa solo más texto simultáneo en la entrada, con un incremento de costes de cómputo y riesgos de degradación de la calidad si el contexto crece sin control.
Nota: En octubre de 2025, los modelos principales ofrecen ventanas que van desde 128K hasta 2M tokens teóricos, pero esto no elimina los efectos de degradación descritos; simplemente los retrasa a conversaciones aún más largas.
3.4 Implicaciones operacionales de la ventana de contexto
La re-inyección del historial en cada solicitud (request) impacta directamente en el rendimiento y los costes del sistema:
- Coste y Latencia: En entornos de API de pago, cada solicitud suele reenviar todo el historial útil (lo que incluye no solo la conversación anterior sino también cualquier contenido anexo o multimodal adjunto). A mayor contexto, más tokens procesados, lo que incrementa la factura y la latencia debido a la mayor carga de cómputo en la capa del transformador.
- Optimización por Caching (Ejemplo Gemini): Algunas plataformas, como Gemini, emplean sistemas de caching de contexto para reducir la latencia y el coste. La plataforma puede almacenar en caché (cachear) los cálculos intermedios de las claves y valores (Keys y Values) del transformer. Esta técnica de caching de contexto no es "memoria de usuario", sino una memoria operativa que mejora el rendimiento del backend, actuando como un sistema de "memoria caliente". Técnicas similares se han generalizado
Nota: técnica — los términos Keys y Values se refieren a las matrices internas del mecanismo de atención del transformador, no a variables de usuario., pues Claude, OpenAI y otros también implementan variantes de esta técnica, reduciendo coste computacional al no reprocesar partes estáticas del contexto.
- Estrategia: El recorte periódico de conversaciones o la separación en hilos temáticos mejora la calidad de la respuesta y reduce el gasto de tokens y la latencia. Este tipo de soluciones se hace imprescindible, pues las ventanas de contexto crecen dramáticamente en las sucesivas versiones de cada modelo.
3.5 Perfilado de usuario: persistencia inferida
Algunas plataformas ejecutan un proceso de perfilado automático (mediante otro LLM, reglas NLP o heurísticas) que infieren rasgos del usuario (tono, intereses, formatos preferidos). Estos rasgos se almacenan en un perfil persistente externo.
- Ese perfil se inyecta como instrucciones internas ("este usuario prefiere X tono y Y formato") en el System Prompt o Instrucción de Sistema de cada nueva sesión, antes del prompt del usuario.
- No es un "recuerdo mágico" del LLLM, sino una persistencia externa diseñada para personalizar la experiencia.
- Aunque la interfaz ofrezca "control total" sobre la memoria, este puede referirse solo a una capa (p.ej., las notas persistentes), y no a todo lo que el sistema infiere y almacena en tiempo real.
3.6 Riesgos de la persistencia: contexto residual y privacidad
El diseño en capas puede generar un riesgo de contexto residual o persistencia no liberada.
Caso de estudio (Copilot): Tras eliminar un chat específico de la interfaz, el modelo sugirió detalles del chat "borrado" al abrir uno nuevo sobre un tema distinto.
Análisis técnico: La interfaz había ocultado la referencia al historial (capa UI), pero el contexto de la sesión (session state) en la plataforma (backend) no había sido liberado o limpiado. Esto demuestra una disociación entre la capa de interfaz de usuario y la capa backend que gestiona el contexto activo.
⚠️ Privacidad "Borrar" en la interfaz no garantiza la liberación inmediata del contexto en la memoria de la plataforma. Para el manejo de datos sensibles, la única garantía práctica es el cierre completo de la aplicación/navegador (o uso de modo incógnito) antes de ceder el dispositivo o cambiar de tema.
3.7 Buenas prácticas de operación y mitigación de riesgos
Para maximizar la calidad y minimizar los riesgos de exposición o degradación:
- Diseña la sesión: Define un objetivo acotado y una duración razonable (idealmente 20–30 turnos).
- Recapitula y reinicia: Cierra el hilo con un resumen conciso y comienza el siguiente hilo con ese resumen como prompt de inicio.
- Aísla lo sensible: Usa navegadores/ventanas dedicadas o modo incógnito; evita mezclar contextos de trabajo y personales.
- Ancla lo crítico: Repite datos clave (como una restricción, un role, o un token de acceso) con formulaciones breves en momentos clave de la conversación.
- Controla costes: Evita contextos gigantescos; utiliza resúmenes útiles y poda el "ruido" informativo.
3.8 Implementación en plataformas (Tabla comparativa)
| Plataforma | Memoria persistente | Perfilado automático | Estrategia Operacional Clave | Transparencia y control |
|---|---|---|---|---|
| Copilot | Amplia (proyectos/notebooks) | Puede ser intrusivo | Gestión de sesión vinculada a la cuenta. | Mensajes de control a veces contradictorios. |
| ChatGPT Plus | Configurable (memoria/Projects) | Moderado | Enfoque en resúmenes (condensación de contexto). | Controles claros y diferenciados en la interfaz. |
| Gemini | Usa historial extenso | Bajo/ninguno | Caching de contexto para optimización. | Comunicación mejorable; luego clara |
| Perplexity | Moderada | Discreta | Enfoque profesional en fuentes (RAG especializado). | Control limitado. |
| Claude | Ninguna entre sesiones por defecto. Configurable mediante Projects. | Ninguno | Sin estado (stateless) por diseño (requiere RAG externo o Projects). | Directo y explícito. |
Nota: Tabla basada en pruebas de uso en 2025. El comportamiento puede variar por cuenta, región y actualizaciones de producto.
3.9 Conflictos, inercia y degradación por sobrecarga
La mala gestión de la memoria se manifiesta como una degradación progresiva de la calidad:
- Conflictos de preferencia: Lo guardado en el perfil ("el usuario prefiere POO") entra en conflicto con lo pedido ahora ("usa programación procedural"). La prioridad varía según la plataforma.
- Inercia temática: El sistema "empuja" ideas pasadas fuera de contexto (un perfilado mal calibrado o un resumen defectuoso).
- Degradación por sesiones largas: Respuestas desconectadas, referencias cruzadas erráticas, o salidas "de relleno". Medidas de mitigación: Sesiones más cortas, recapitulaciones explícitas, y reinicios de hilo con un resumen.
3.10 análisis estadístico
Aunque los proveedores de IA generativa declaran no utilizar los mensajes de los usuarios para reentrenar sus modelos principales sin consentimiento expreso, sí realizan análisis estadísticos y operativos sobre el uso del sistema. Estos análisis suelen estar anonimizados y agregados, y se emplean para medir rendimiento, detectar abusos o mejorar la infraestructura (no el conocimiento del modelo).
En términos técnicos, se distingue entre:
- Entrenamiento: ajustar parámetros del modelo con nuevos datos.
- Análisis agregado: estudiar patrones de uso sin modificar el modelo.
Algunas plataformas registran no solo métricas técnicas (tokens, duración, idioma), sino también indicadores semánticos automáticos sobre el contenido generado. Estos sistemas, conocidos como telemetría semántica, evalúan de forma agregada aspectos como coherencia, precisión o ambigüedad, y pueden marcar flags —por ejemplo, “metáfora imprecisa”, “cambio brusco de idioma” o “respuesta circular”.
Su finalidad no es reentrenar el modelo base, sino monitorizar la calidad y el comportamiento global del sistema.
Estos análisis se realizan mediante clasificadores automáticos o LLM secundarios, y sus resultados se almacenan de forma anonimizada y estadística, como parte del proceso de mejora continua del servicio.
Como usuario debes ser consciente de que, aunque tus datos no “enseñen” directamente al modelo, sí pueden contribuir a la mejora del servicio a través de métricas, auditorías y filtros automáticos.
3.11 Síntesis y conclusiones
El concepto de "memoria" en los LLM debe entenderse como una función arquitectónica externa y no una capacidad intrínseca del modelo.
- Modelo stateless: Ningún "recuerdo" vive dentro del LLM entre mensajes.
- Memoria útil = arquitectura externa: La continuidad es producto del contexto reinyectado y la persistencia/recuperación (RAG).
- Optimización: Técnicas como el caching de contexto son clave para gestionar la latencia y el coste.
- Asimetría de control El feedback directo del usuario impacta primariamente en el prompt reinyectado; sin embargo, no garantiza la modificación del perfil persistente o de las reglas algorítmicas de inferencia, que residen en capas de la plataforma sin acceso de escritura directo por parte del modelo conversacional.
Comprender las capas de memoria es clave para un uso seguro y eficiente de los LLMs.