TL;DR:
Los sistemas de memoria de agentes de IA desalojan el contexto antiguo mediante una ventana deslizante: si algo no se ha tocado en N turnos, desaparece. Esto trata un hecho fundamental declarado una vez en el turno 1 y un registro de depuración descartable del turno 40 como idénticos: el que sea más antiguo pierde, sin importar cuántas veces se haya usado cualquiera de ellos. Construí un motor de memoria que califica la retención usando la curva de olvido de Ebbinghaus, donde cada retiro refuerza la estabilidad de un artículo y extiende su horizonte de desalojo de manera no lineal. A lo largo de 50 sesiones preestablecidas, mantuvo una tasa de recuperación fundamental del 100% frente a una tasa del 0% para la línea de base de solo lo reciente, y rastreé la razón matemática exacta, luego encontré el caso de falla específico donde su ventaja desaparece por completo.
Conclusiones clave
El problema aquí es estructural, no es algo de lo que puedas salir sintonizando. Con una ventana de actualidad fija, te topas con una dura pared matemática: si no tocas un elemento dentro de los turnos del tamaño de la ventana, se borra de la memoria. No importa si fue el elemento más utilizado en el sistema hace cinco minutos; una vez que pasa esa ventana, desaparece.
En segundo lugar, los compuestos de refuerzo donde falla la actualidad. Al permitir que la retención aumente con la frecuencia de recuperación, el motor de descomposición amplía el horizonte de supervivencia efectivo de un elemento en órdenes de magnitud basándose en solo unas pocas interacciones tempranas.
En tercer lugar, seamos claros: esto no es una “mejor memoria” en todos los ámbitos. Para asegurarme de que esto no fuera un artefacto de referencia, construí una prueba de caso de falla. Cuando un hecho se introduce una vez y nunca se recuerda, el motor de decaimiento funciona de manera idéntica a la línea de base. Ése es el límite honesto de este mecanismo.
Cuarto, es completamente determinista. Todo se basa en un contador de turnos explícito, no en el tiempo de un reloj de pared. Para verificarlo, ejecuté la suite en dos máquinas y sistemas operativos diferentes; las salidas diferentes eran en bytes idénticos.
Finalmente, siempre audite sus puntos de referencia. Dos errores ocultos casi invalidaron toda esta ejecución. Los estoy desglosando porque detectar estos problemas es la diferencia entre datos en los que puedes confiar y datos que te mienten silenciosamente.
Código completo: https://github.com/Emmimal/memory-decay-engine/
El hecho que sobrevivió a su propia ventana
Veamos cómo se desarrolla esto en la práctica. Imagina que tienes 150 turnos en una sesión con un agente. En el primer turno, el usuario le da al agente una regla básica, como un requisito de cumplimiento o una restricción de pila tecnológica específica. El agente hace referencia a él varias veces durante los primeros treinta turnos mientras se orienta, pero luego la conversación continúa. Durante los siguientes cien turnos, el agente está ocupado haciendo otras cosas, como analizar registros, realizar llamadas únicas a herramientas y manejar tareas secundarias aleatorias.
Más adelante en la sesión, mucho más allá de esa ventana inicial, haces una pregunta que depende completamente de esa regla del primer turno.
Con una ventana corredera estándar, ya has perdido esa regla. La ventana no sabe que la regla es crítica y no le importa que el agente ya la haya usado cinco veces. Simplemente ve un recuento de turnos que aumentó demasiado y descarta los datos. Eso no es memoria. Es sólo un cronómetro de cuenta regresiva.
Ejecuté este escenario exacto en 50 sesiones preestablecidas. En este punto de referencia, el motor de decaimiento retuvo todos los hechos fundamentales hasta el final de la sesión, mientras que la línea de base de solo lo reciente no retuvo ninguno. El resultado fue consistente en las 50 semillas. He aquí por qué sucede eso.
¿Para quién es esto?
Este enfoque se aplica a cualquier sistema en el que un agente necesite mantener el contexto durante una sesión larga de varios turnos. Piense en agentes de codificación que trabajan en tareas de varios días, robots de atención al cliente que manejan hilos extendidos de solución de problemas, bucles de investigación autónomos o cualquier canal en el que la memoria tenga que significar algo más que los últimos mensajes.
Lo más importante es que tus sesiones sigan un patrón específico. Algo importante se establece desde el principio, luego se queda en silencio durante un largo período mientras se realiza otro trabajo, y debe seguir activo cuando finalmente resurge.
Puede omitir esto por completo si sus sesiones son lo suficientemente cortas como para que todo encaje en la ventana contextual de todos modos. Tampoco lo necesita si todos los hechos de su sesión tienen aproximadamente la misma relevancia todo el tiempo. Una ventana simple funciona bien para eso y no tiene sentido crear una solución para un problema que no se tiene.
Por qué esto es importante para los sistemas reales
Esta no es sólo una cuestión abstracta para los puntos de referencia. Este patrón exacto se ve en producción todo el tiempo.
Tomemos como ejemplo los agentes codificadores. Si un agente trabaja en una tarea durante varios días, es posible que reciba instrucciones estrictas el primer día, como una versión de biblioteca específica que debe usar o un archivo que nunca debe editar. Una vez que la sesión se vuelve demasiado larga, una ventana ingenua de actualidad simplemente elimina esa instrucción y el agente rompe su código base.
O tomemos los bots de atención al cliente. Si un hilo de solución de problemas dura demasiado, los intercambios se acumulan hasta que el bot olvida por completo los detalles de la cuenta del usuario o el problema real con el que comenzó. Lo siguiente que sabes es que el bot hace preguntas que el usuario ya respondió hace diez minutos.
Se ve el mismo problema en las tuberías RAG. El sistema descarta agresivamente hechos sólo porque no han sido mencionados en los últimos turnos. No importa si esos hechos son centrales para toda la tarea y cruciales para los pasos finales; si no están activos en este momento, se podan.
Cuando estos sistemas fallan, no fallan ni arrojan errores limpios. Simplemente te dan silenciosamente una respuesta incorrecta o incompleta porque la única información que realmente importa ya no existe en el sistema.
Una confesión antes de ir más lejos
He construido decadencia antes. En un proyecto anterior[6], Configuré una caída de tiempo exponencial para un corpus de documentos RAG. Era una curva simple que rebajaba la clasificación de los documentos obsoletos en el momento de su recuperación en función de su antigüedad en días. Si lees ese artículo, las matemáticas aquí pueden parecer similares a primera vista. Pero quiero dejar clara la diferencia antes de que pienses que estoy repitiendo la misma vieja idea.
Ese viejo enfoque sólo funcionaba en una dirección: hacia abajo. El sistema no sabía si un documento todavía importaba. Un documento de política recuperado cincuenta veces se descompuso exactamente al mismo ritmo que otro que nadie volvió a mirar, porque el único dato para la fórmula era la edad calendario. También estaba resolviendo un problema completamente diferente. Se trataba de clasificar documentos en un corpus persistente, no de decidir qué sobrevivirá en la memoria de trabajo de una sola sesión.
Este proyecto agrega la pieza que me perdí antes, que es el uso. Cuando se recupera un elemento aquí, no solo recibe un impulso temporal para una consulta. Su estabilidad subyacente cambia permanentemente, remodelando toda su curva de decadencia futura. Ese es un mecanismo completamente diferente, y es la única razón por la que escribo esto en lugar de simplemente agregar una nota a pie de página a la publicación anterior.
Por qué Ebbinghaus, específicamente
No inventé las matemáticas detrás de esto. En realidad tiene unos 140 años.
En 1885, un psicólogo llamado Hermann Ebbinghaus realizó los primeros experimentos reales sobre cómo se desvanece la memoria humana.[1]. Se utilizó a sí mismo como sujeto de prueba, memorizando sílabas sin sentido para ver cuánto tiempo durarían. Su principal hallazgo fue que nuestra retención disminuye increíblemente rápido al principio, pero cada vez que revisas la información, esa curva de olvido se aplana. Ese concepto todavía impulsa la investigación moderna sobre la repetición espaciada en la actualidad, incluidas revisiones importantes sobre cómo el espaciado afecta el recuerdo verbal.[2].
Definitivamente no soy la primera persona que relaciona esta idea con los agentes de IA. Recientemente, varios proyectos de código abierto han adoptado la curva de olvido de Ebbinghaus para la memoria del agente, incluido el proyecto YourMemory de Mishra.[4]. El proyecto compara este enfoque con el conjunto de datos de memoria conversacional a largo plazo de LoCoMo.[3]e informa aproximadamente una mejora de 16 puntos porcentuales en el recuerdo con respecto a una herramienta de memoria comparable. El artículo sobre Agentes Generativos de Stanford adoptó un enfoque similar, aunque combinó actualidad, importancia y relevancia en lugar de depender de una pura curva de olvido.[5].
Mi objetivo aquí no era construir algo totalmente novedoso. No estoy afirmando que este sea un concepto completamente nuevo. Solo quería ver si podía construir yo mismo la versión más pequeña y totalmente determinista de esto sin dependencias, ejecutarla contra la ventana deslizante básica que la mayoría de los sistemas realmente usan y encontrar el punto exacto donde se rompe.
Los dos modos de falla, uno al lado del otro
Antes de profundizar en el código, vale la pena mirar exactamente qué estamos comparando. El resto de esta pieza depende de esta distinción.
Esta línea de base no es una hipótesis. La mayoría de los sistemas de producción funcionan con esta base porque es increíblemente barata y casi no requiere esfuerzo para implementarla. Pero las cosas se rompen en el momento en que su sesión coincide con el patrón que vimos anteriormente. Si una regla básica se establece desde el principio, se usa varias veces y luego se deja intacta durante docenas de turnos, el sistema simplemente la descarta.
La Arquitectura
La configuración utiliza dos clases que comparten exactamente la misma interfaz. La única diferencia entre ellos es cómo deciden desechar los datos.
La fórmula de puntuación
En cualquier distancia de giro t transcurrida, la puntuación de retención para un elemento con estabilidad S se calcula como:
Ret = e^(-t / S)
Cada vez que se recupera un elemento, su estabilidad se refuerza de forma no lineal:
S_nuevo = S_antiguo × (1 + ln(1 + recuento_recuperación))
El sistema desaloja un artículo en el momento en que su puntuación de retención cae por debajo de un umbral establecido (que por defecto es 0,20, aunque veremos 0,10 y 0,30 más adelante). Reducido a su lógica central, la verificación de desalojo se ve así en Python:
puntaje = math.exp(-elapsed / item.stability) si transcurrió > 0 más 1.0 si puntaje < umbral_desalojo: desalojar(mem_id)
La verificación de desalojo de la línea de base es una comparación única, sin exponencial:
if (turno_actual – item.last_touched_turn) > tamaño_ventana: desalojar (mem_id).
Una opción específica aquí es que cada turno dependa de un contador entero explícito en lugar de time.time(). En realidad, mi primer borrador utilizó el tiempo del reloj de pared, lo que resultó ser un gran error. Analizaremos por qué se rompió en la sección de errores a continuación.
Debido a que ambos motores exponen exactamente los mismos cinco métodos (registro, recuperación, paso, is_present y work_set_size), el arnés de simulación que controla las pruebas no sabe ni le importa qué motor está ejecutando. Cualquier variación en los resultados finales se debe enteramente a la propia política de desalojos.
Visualizando la divergencia
Esto es lo que separa los dos mecanismos. Este gráfico muestra datos reales del proyecto y muestra la puntuación de retención frente al número de turnos desde la última vez que se tocó un elemento.
Puede ver la diferencia entre un solo retiro (sin refuerzo, donde la estabilidad se mantiene en la base de 8) y un elemento retirado cuatro veces (donde la estabilidad aumenta a aproximadamente 292):
Ambos elementos comienzan exactamente en el mismo lugar con una puntuación de retención de 1,0. Pero en el turno 15, el elemento simple ya cayó a 0,153, superando nuestro umbral de 0,20. Mientras tanto, el elemento reforzado todavía se mantiene en 0,950. Estamos usando exactamente las mismas matemáticas y exactamente el mismo umbral para ambos aquí. La única diferencia es que la estabilidad del artículo reforzado aumentó durante esos primeros retiros del mercado.
La línea de base de la ventana corrediza es esa línea vertical que la atraviesa. Ignora por completo ambas curvas y deja caer los datos en un límite fijo, sin importar cuán estable sea realmente cualquiera de las memorias.
Dos errores que casi me mienten
Quiero desglosar estos dos errores, de forma muy parecida a cómo manejé el error de los tres estados en el último proyecto. Detectar cosas como esta antes de confiar en sus números de referencia es el objetivo de realizar una prueba de cordura.
Error 1: El período de gracia que no fue
Inicialmente, configuré baseline_stability en 2.0. Parecía un incumplimiento razonable sobre el papel. Pero luego tracé los cálculos para ver exactamente cuándo un artículo recién registrado y nunca retirado provocaría un desalojo.
baseline_stability=2.0 → desalojo ingenuo en el turno 3.22 baseline_stability=4.0 → desalojo ingenuo en el turno 6.44 baseline_stability=6.0 → desalojo ingenuo en el turno 9.66 baseline_stability=8.0 → desalojo ingenuo en el turno 12.88
Con S = 2,0, un hecho central registrado en el turno 1 decayó más allá de nuestro umbral de 0,20 en el turno 3. Eso fue incluso antes de que tuviera lugar el primer retiro programado de ese hecho. El motor estaba desperdiciando datos antes de que tuvieran la oportunidad de ser reforzados, haciendo que todo el mecanismo quedara inactivo al llegar.
Entendí esto calculando el giro de desalojo en un rango de valores de estabilidad antes de ejecutar una única sesión inicial, en lugar de mirar los promedios de referencia finales y adivinar por qué los números parecían fuera de lugar. Aumenté el valor predeterminado a S = 8,0, lo que da un período de gracia limpio de 13 turnos: tiempo suficiente para que un hecho sobreviva hasta su primer refuerzo.
Error 2: un punto de referencia que era secretamente imposible de superar
El segundo error fue más sutil y, sinceramente, más vergonzoso. En mi primera versión del generador de sesiones sintéticas, programé turnos de recuperación utilizando un muestreo aleatorio uniforme puro durante toda la sesión. Para una sesión de 150 turnos, eso significaba que el primer recuerdo de un hecho central podía realizarse en cualquier momento desde el turno 10 hasta el turno 150. La mayoría de las veces, aparecía 30, 40 o incluso 60 turnos después del registro.
Ambos motores tienen algún tipo de período de gracia antes de que un elemento intacto sea desalojado. Cuando ejecuté el punto de referencia con esta programación aleatoria, la línea base de actualidad obtuvo exactamente 0,000 en las 50 semillas, con una desviación estándar cero.
Mi primera reacción fue que parecía una gran victoria. Mi segunda reacción, la que realmente me salvó, fue que un resultado con variación cero en 50 semillas aleatorias es una enorme señal de alerta, no una victoria. Un punto de referencia que produce exactamente el mismo resultado independientemente de su semilla aleatoria generalmente significa que la aleatoriedad en realidad no llega a la parte del sistema que está tratando de medir.
Lo rastreé: con los retiros dispersos uniformemente al azar, el primer retiro casi siempre llegaba mucho después de que hubieran expirado los períodos de gracia de ambos motores. No estaba midiendo si el refuerzo ayuda a la retención. Simplemente estaba midiendo si el generador de números aleatorios había programado un retiro con suficiente anticipación como para importar, y la respuesta casi siempre fue “no” para ambos sistemas. La línea de base no estaba fallando porque fuera una política peor; estaba fallando porque el escenario de prueba hacía que el éxito fuera estructuralmente imposible.
Solucioné esto desechando la ubicación de retiro aleatorio uniforme y reemplazándola con un programa que imita intervalos de repetición espaciados reales: un breve espacio antes del primer retiro (3 turnos), seguido de espacios cada vez más amplios para retiros posteriores (resultados 8, 20, 45, 90 y 150). También agregué ±30% de fluctuación multiplicativa para que no haya dos semillas que produzcan una forma idéntica.
Esto nos da un modelo mucho más realista de cómo se utiliza realmente un hecho en una sesión real: se hace referencia a él poco después de ser declarado, y luego progresivamente con menos frecuencia a medida que se establece. Este es el cronograma en el que se basa cada número de este artículo.
El punto de referencia
Cada número a continuación se copia y pega directamente desde una ejecución de terminal real de benchmark.py sin ninguna edición. Ejecuté toda la suite dos veces en configuraciones completamente separadas: una vez en Linux y otra en una máquina con Windows que ejecuta un entorno Python diferente. Una diferencia byte por byte de las salidas resultó idéntica. Esto no es sólo una afirmación sobre la reproducibilidad; es un hecho verificado sobre este código base.
1. Comparación de titulares (N=50 semillas, sesiones de 150 turnos, 3 hechos fundamentales, ruido=3/turno)
Ambos motores logran una reducción de huella similar. Alrededor del 90% de todos los elementos creados se mantienen fuera de la memoria de trabajo en un momento dado con ambos enfoques. Esto tiene sentido porque la mayor parte del ruido (tres artículos desechables por turno durante 150 turnos) debería eliminarse mediante cualquier política decente. La verdadera diferencia no es la agresividad con la que podan, sino lo que queda atrapado en la limpieza.
Quiero evitar simplemente lanzarte una división limpia de 1.000 contra 0.000 y seguir adelante. Una división perfecta con variación cero entre 50 semillas puede parecer falsa incluso cuando el código realmente la produjo. Aquí está el mecanismo exacto detrás de esos números, verificado directamente desde los registros. Después de cuatro retiradas repartidas en los primeros 45 turnos, la estabilidad de un solo elemento aumenta a aproximadamente 292. En el turno 150 (que son 111 turnos después de que fue tocado por última vez), su puntuación de retención se sitúa en 0,684. Eso todavía está muy por encima del umbral de desalojo de 0,20.
2. Barrido de resistencia al ruido (N=20 semillas por nivel, duración de la sesión fijada en 150)
Quiero dejar claro lo que realmente muestra esta tabla. Demuestra que los resultados no son sensibles al ruido de fondo. El motor Ebbinghaus mantiene su ventaja incluso cuando el ruido se multiplica por veinte.
Esto no significa que el ruido no importe. Ambos motores tienen que trabajar mucho más para eliminar el desorden a niveles de ruido más altos, pero el resultado de nuestro hecho central no cambia.
Presento esto como una tabla en lugar de comprimir los datos en un único valor de pendiente. Debido a que la FRR está estrictamente limitada entre 0 y 1, asumir una relación lineal sería una historia engañosa.
3. Barrido de sensibilidad (N=20 semillas por configuración, 15 combinaciones de umbral × ventana probadas)
Probé las 15 combinaciones de esos tres umbrales y cinco tamaños de ventana. El resultado se mantuvo en todos los ámbitos, no solo en las pocas configuraciones enumeradas anteriormente.
Incluso intenté aumentar el tamaño de la ventana hasta 50, que es más del triple del valor predeterminado, solo para ver si la línea base podía recuperarse. Todavía no fue así. El problema no es que las ventanas corredizas sean inútiles, sino más bien que una ventana fija simplemente no puede cubrir un enorme espacio de silencio después de un refuerzo temprano. Si abres la ventana lo suficiente como para sobrevivir a un período de sequía de 100 turnos, de todos modos pierdes la capacidad de podar la memoria de manera efectiva.
4. El caso del fracaso: donde la ventaja desaparece
Esta es la sección que más importa y suele ser la parte exacta que omiten la mayoría de los artículos.
Si el refuerzo es el mecanismo central, entonces un hecho que se afirma una vez y nunca se recuerda no debería beneficiarse en absoluto de este motor. Simplemente no hay nada que reforzar. Configuré esta prueba específicamente para descubrir si el resultado principal era simplemente una afirmación genérica de "este sistema es mejor", o una prueba más estrecha y honesta de lo que realmente le ayuda a obtener refuerzo.
Tenemos una división cero contra cero. Sin ningún refuerzo, el motor Ebbinghaus nunca consigue aumentar su estabilidad más allá de la línea de base. Se descompone y cae básicamente al mismo ritmo que un elemento intacto en el ingenuo sistema de ventanas.
El mecanismo no rescata hechos que nadie vuelve a utilizar. Premia específicamente y únicamente los hechos que realmente se reutilizan. Ésta es una afirmación mucho más limitada y honesta que decir "este es un mejor sistema de memoria". Preferiría publicar la afirmación verdadera más limitada que una amplia que se desmorona en su propio caso límite.
Cómo se ve esto en la práctica
El momento que realmente me convenció no fue una estadística. Fue observar una sola sesión paso a paso y ver el momento exacto en que se solicitó un hecho central y simplemente ya no estaba allí.
En las curvas 5, 10 y 20, ambos motores recuerdan el mismo hecho central tres veces. Hasta este punto, parecen idénticos. Ambos muestran una tasa de recuperación perfecta en el punto de control de la curva 30.
En la curva 36, la línea de base de la ventana corrediza abandona el hecho. Han pasado dieciséis turnos desde la última vez que se tocó en el turno 20, que es un turno más allá de nuestro límite de ventana de 15.
Al cumplir 39 años, la sesión vuelve a preguntar por ese hecho exacto. Con la línea de base, ya se fue. El sistema busca silenciosamente el ID, no encuentra nada y devuelve Falso. No hay fallas, advertencias ni entradas de registro. Simplemente obtienes una respuesta incompleta o incorrecta, a pesar de que el hecho estaba perfectamente bien hace apenas tres turnos.
Con el motor Ebbinghaus, el retiro del mercado en el año 39 es un éxito. La estabilidad generada a partir de esas tres primeras retiradas mantuvo la tasa de deterioro superficial, manteniendo el hecho muy por encima del umbral de desalojo. Ese cuarto retiro aumenta nuevamente su estabilidad, llevando el hecho de manera segura hasta el final de la sesión.
Misma sesión, mismo patrón de recuperación. Uno terminó en una pérdida silenciosa e irrecuperable. El otro funcionó tan bien que ni siquiera se dio cuenta de que existía un riesgo.
Convertir la traza en una línea de tiempo
Aquí hay una forma más de visualizar esta divergencia. Si mapeamos si nuestro hecho central está realmente presente en el conjunto de trabajo durante toda la sesión, podemos condensar todo el historial en una sola barra para cada motor.
Una vez que un sistema de ventana de actualidad deja caer un hecho, el mecanismo en sí no ofrece forma de recuperarlo. La pérdida es permanente hasta que algo la registre explícitamente desde cero.
La barra del motor de descomposición se mantiene sólida no porque los elementos nunca se acerquen al punto de desalojo, sino porque el refuerzo empuja activamente ese punto de desalojo más lejos, más rápido de lo que el tiempo puede cerrar la brecha.
Lo que esto no resuelve
Aquí hay algunos límites honestos:
El recuento de elementos es un proxy de recuento de tokens, no algo real. Este punto de referencia trata cada artículo sintético como un peso aproximadamente igual para la métrica de reducción de huella. El contenido real varía enormemente en cuanto a la longitud del token. Una versión de producción debe ponderar la huella según el recuento real de tokens, no el recuento de artículos. Estoy afirmando esto explícitamente en lugar de dejar que los números de huella impliquen más precisión de la que realmente tienen.
La simulación activa explícitamente el recuerdo, no lo infiere. En este punto de referencia, ocurre un evento de recuperación porque el generador de sesión sintética dice que sucede. En un sistema real, sería necesario definir qué se considera un retiro genuino. ¿Este elemento de memoria realmente ayudó a producir una respuesta o simplemente estaba presente en el contexto? Esa lógica de detección es un problema separado y más difícil que este proyecto no aborda.
Los valores predeterminados son ajustados, no universales. Un umbral de desalojo de 0,20 y una estabilidad de referencia de 8,0 surgieron del barrido de sensibilidad y del cálculo del período de gracia, no de la nada. Pero son puntos de partida para esta forma específica de sesión (establecimiento temprano, un punto medio tranquilo y un resurgimiento tardío), no constantes. Una sesión con un ritmo diferente, como el uso continuo de luz en lugar de un patrón de explosión y silencio, merece su propio análisis antes de confiar en estos números en la producción.
Esto no resuelve recuerdos conflictivos. Si dos hechos contradictorios quedan reforzados, este motor mantiene ambos. Decidir cuál es actualmente cierto es un problema completamente diferente a decidir qué permanece en el conjunto de trabajo en primer lugar.
La conclusión
Una ventana de actualidad no es una mala idea si se implementa mal. Es una política sencilla y barata diseñada para responder exactamente a una pregunta: ¿cuándo se tocó esto por última vez? Eso funciona perfectamente para sesiones donde la importancia y lo reciente se alinean. Se rompe silenciosamente en el momento en que no lo hacen, como cuando algo se establece temprano, se usa varias veces y aún necesita permanecer fiel cien vueltas de ruido no relacionado después.
La solución no es una ventana más grande. Una ventana lo suficientemente ancha como para salvar una brecha silenciosa de cien vueltas deja de ser un mecanismo de poda significativo. Simplemente se queda con todo y lo llama póliza. La solución plantea una pregunta diferente: no cuándo se modificó esto, sino en qué medida dependió realmente de que se mantuviera correcto. El refuerzo responde directamente a esa pregunta y la agrava de una manera que un límite fijo estructuralmente no puede hacerlo.
Preferiría que recordara esa distinción que cualquier porcentaje en este artículo, y también me gustaría que tuviera en cuenta el caso de fracaso. Esto no significa que los motores de desintegración tengan mejor memoria. Es una afirmación de que protegen específicamente lo que se sigue utilizando y no ofrecen nada adicional por lo que no. Construir la prueba que demostró que ese límite fue, honestamente, más útil que el número del titular.
Código completo: https://github.com/Emmimal/memory-decay-engine/
Recursos
[1]Ebbinghaus, H. (1885). Über das Gedächtnis: Untersuchungen zur experimentellen Psychologie. Duncker y Humblot. Traducción al inglés: Ebbinghaus, H. (1913). Memoria: una contribución a la psicología experimental (HA Ruger y CE Bussenius, trad.). Teachers College, Universidad de Columbia.
[2]Cepeda, Nueva Jersey, Pashler, H., Vul, E., Wixted, JT y Rohrer, D. (2006). Práctica distribuida en tareas de recuerdo verbal: una revisión y síntesis cuantitativa. Boletín psicológico, 132(3), 354–380. https://doi.org/10.1037/0033-2909.132.3.354
[3]Maharana, A., Lee, D.-H., Tulyakov, S., Bansal, M., Barbieri, F. y Fang, Y. (2024). Evaluación de la memoria conversacional a muy largo plazo de agentes LLM. arXiv. https://arxiv.org/abs/2402.17753
[4]Mishra, S. (2026). YourMemory: Memoria de IA agente con Ebbinghaus olvidando el deterioro de la curva [software de computadora]. GitHub. https://github.com/sachitrafa/YourMemory
[5]Park, JS, O'Brien, JC, Cai, CJ, Morris, MR, Liang, P. y Bernstein, MS (2023). Agentes generativos: simulacros interactivos del comportamiento humano. arXiv. https://doi.org/10.48550/arXiv.2304.03442
[6]Alejandro, EP (2026). RAG es ciego al tiempo: construí una capa temporal para arreglarlo en producción. Hacia la ciencia de datos. https://towardsdatascience.com/rag-is-blind-to-time-i-built-a-temporal-layer-to-fix-it-in-production/
Divulgación
Todo el código de este artículo fue escrito por mí y es un trabajo original, desarrollado y probado en Python 3.12. Los números de referencia y los resultados del terminal que se muestran provienen de ejecuciones reales de sanity_check.py, demo.py y benchmark.py, y se pueden reproducir mediante la clonación del repositorio. Verifiqué esto de forma independiente ejecutando el conjunto completo en dos máquinas y sistemas operativos separados (Linux y Windows) y diferenciando la salida byte por byte; los resultados fueron idénticos en ambos. Este proyecto tiene cero dependencias externas. Todas las funciones se ejecutan únicamente en la biblioteca estándar de Python, sin necesidad de llamadas LLM ni claves API en ninguna parte del punto de referencia.
El mecanismo de desintegración de Ebbinghaus se basa en la investigación histórica de la curva de olvido citada anteriormente y sigue el mismo enfoque general que los proyectos de memoria de agentes de código abierto existentes también citados anteriormente; La implementación, el diseño de referencia, el generador de sesiones y todo el código específico de este proyecto son mi trabajo original, independientemente de cualquiera de esas bases de código. No tengo ninguna relación financiera con ninguna herramienta, biblioteca o empresa mencionada en este artículo.
Ponte en contacto
Si este artículo le resultó útil o tiene alguna idea sobre los sistemas de memoria de IA, me encantaría saber de usted.
Conéctate conmigo: