Mémoire IA : Quand l'archive devient un obstacle à l'intelligence

La persistance problématique des mémoires IA

Dans le domaine de l'intelligence artificielle, la gestion de la mémoire est souvent perçue comme un simple problème de stockage et de récupération. Cependant, cette approche peut entraîner des dysfonctionnements inattendus. Par exemple, un assistant IA a conservé une mémoire avec un score d'importance de 8/10 concernant une enquête sur Bun.js, un projet qui n'a jamais été poursuivi. Cette mémoire est restée active pendant six mois, influençant les recommandations de l'IA malgré son obsolescence.

Ce cas illustre un problème fondamental : les systèmes de mémoire IA actuels ne sont pas conçus pour gérer l'évolution des informations. Ils se contentent de stocker et de récupérer des données, sans tenir compte des changements de contexte ou de la pertinence des informations au fil du temps.

Nick Lawson a écrit un excellent article sur TDS où il décrit comment il a mis en œuvre un système de mémoire IA. Son architecture de stockage et de récupération est particulièrement bien pensée, mais elle soulève des questions sur la gestion des mémoires au fil du temps. Quand une mémoire devrait-elle disparaître ? Quelle mémoire est plus fiable qu'une autre ? Combien de mémoires qui se chevauchent devraient être combinées en une seule ?

Les limites des systèmes actuels

Les systèmes de mémoire IA traditionnels fonctionnent sur un modèle en deux étapes : écrire et lire. Cela peut suffire pour des tâches simples, mais devient problématique pour des applications nécessitant une fiabilité sur le long terme. Une mémoire enregistrée en début de projet peut rester prioritaire des semaines plus tard, même si la décision initiale a été révisée.

Ce manque de mise à jour dynamique conduit à des situations où l'IA s'appuie sur des données obsolètes, compromettant ainsi la qualité des décisions prises. Le véritable défi réside dans la capacité à oublier ou à mettre à jour les informations devenues non pertinentes.

À quoi cela ressemble-t-il concrètement ? Une mémoire écrite au cours de la première semaine reste, huit semaines plus tard, aussi fraîche et prioritaire que le jour où elle a été créée, même si la décision prise a été inversée deux semaines auparavant. L'autre mémoire, qui contredit la décision précédente, a été rangée sans cérémonie et n'a tout simplement jamais eu le temps de devenir une priorité car elle n'a pas reçu suffisamment d'accès pour se hisser dans la file d'attente.

Ainsi, sans hésitation, l'assistant sort une décision qui a été annulée. Ce n'est qu'à la troisième tentative que l'on réalise enfin que l'assistant s'est appuyé sur des informations obsolètes tout le temps. Le problème n'est pas de se souvenir, c'est de ne pas savoir laisser aller.

Vers une mémoire IA plus humaine

L'objectif est de développer une mémoire IA qui fonctionne plus comme un cerveau humain que comme une base de données. Cela implique d'intégrer des mécanismes de dégradation et de remplacement des mémoires. Par exemple, chaque mémoire pourrait être associée à un decay_score qui diminue avec le temps, en fonction de son utilisation.

Certaines mémoires ne sont pas très fiables dès le départ. D'autres expirent après une certaine période. Le cerveau gère tout cela automatiquement et sans intervention. C'était l'objectif de l'auteur de la tribune.

La Fondation (Promis, c'est bref)

Faisons un rapide point de contexte. Plutôt que d'encoder les mémoires et d'exécuter des recherches de similarité cosinus, elles sont conservées en texte brut dans une base de données SQLite, que le LLM peut consulter pour un index concis à chaque demande. Il n'est pas nécessaire d'avoir un processus d'embedding, une API tierce ou des fichiers supplémentaires. La compréhension linguistique du LLM effectue la tâche de récupération. Cela semble trop simple. Mais cela fonctionne en réalité étonnamment bien sur un plan personnel.

Le schéma repose sur cela avec des champs de cycle de vie :

# memory_store.py
from datetime import datetime
from pathlib import Path
from contextlib import contextmanager
DB_PATH = Path("agent_memory.db")
conn = sqlite3.connect(DB_PATH)
conn.row_factory = sqlite3.Row
with _db() as conn:
    conn.execute("
    CREATE TABLE IF NOT EXISTS memories (
    id              INTEGER PRIMARY KEY AUTOINCREMENT,
    content         TEXT NOT NULL,
    summary         TEXT,
    tags            TEXT DEFAULT '[]',
    -- Champs de cycle de vie — c'est ce que cet article ajoute
    importance      REAL DEFAULT 5.0,
    confidence      REAL DEFAULT 1.0,
    access_count    INTEGER DEFAULT 0,
    decay_score     REAL DEFAULT 1.0,
    status          TEXT DEFAULT 'active',
    contradicted_by INTEGER REFERENCES memories(id),
    created_at      TEXT NOT NULL,
    last_accessed   TEXT,
    expires_at      TEXT
    ")

Les colonnes intéressantes sont celles que l'on ne voit pas dans un schéma de mémoire standard : confiance, decay_score, statut, contradicted_by, expires_at. Chacune répond à une question sur la santé d'une mémoire que « existe-t-elle ? » ne peut pas.

Le premier problème est assez simple : les anciennes mémoires ne se nettoient pas toutes seules. Chaque mémoire dans la base de données se voit attribuer un decay_score de 0 à 1. Il commence à 1.0 au moment de sa création et se dégrade avec le temps, en fonction de la dernière fois que la mémoire a été consultée.

Les mémoires qui continuent à être référencées restent fraîches. Tandis que les mémoires qui ne sont pas consultées pendant plusieurs mois s'effacent vers zéro. Une fois qu'elles tombent en dessous du seuil de pertinence, elles sont archivées, non supprimées, car s'effacer ne signifie pas qu'elles étaient fausses, juste plus utiles.

from datetime import datetime
from memory_store import _db, log_event
HALF_LIFE_DAYS = 30  # ajustez cela — 30 fonctionne bien pour la mémoire conversationnelle,
# poussez à 90+ si vous suivez des projets de longue durée
def _decay_score(last_accessed: str | None, created_at: str, access_count: int) -> float:
    ref = last_accessed or created_at
    days_idle = (datetime.now() - datetime.fromisoformat(ref)).days
    # Décroissance exponentielle standard : e^(-ln2 * t / half_life)
    # (En pratique, le score diminue de moitié tous les HALF_LIFE_DAYS.)
    score = math.exp(-0.693 * days_idle / HALF_LIFE_DAYS)
    # Les mémoires fréquemment consultées gagnent un petit bonus de fraîcheur.
    # Limitez à 1.0 — cela n'est pas censé gonfler au-delà de frais.
    return min(1.0, score + min(0.3, access_count * 0.03))

Détection de Contradiction

C'est la partie que personne ne construit et celle qui cause le plus de dommages lorsqu'elle est manquante. Prenons ce scénario : une personne dit à l'IA qu'elle utilise PostgreSQL. Puis, trois mois plus tard, elle migre vers MySQL, en le mentionnant brièvement dans la conversation.

Maintenant, il y a quatorze mémoires liées à PostgreSQL avec une grande importance, tandis que l'unique mémoire concernant MySQL a une faible importance. Ainsi, lorsque des informations sur la configuration de base de données sont demandées six mois plus tard, l'IA dit avec confiance « vous utilisez PostgreSQL », et la personne passe dix minutes confuse avant de réaliser ce qui se passe.

L'auteur de la tribune a rencontré cela lui-même. Il avait arrêté d'utiliser poetry et commencé à utiliser uv comme gestionnaire de dépendances, il l'a mentionné une fois, sans déclencher un score d'importance élevé, et a passé une semaine à se demander pourquoi l'assistant continuait à suggérer des commandes poetry. L'ancienne mémoire n'était pas fausse ; elle n'avait tout simplement pas été remplacée.

La solution : lorsqu'une nouvelle mémoire est créée, il est nécessaire de vérifier si elle contredit quelque chose déjà stocké et de marquer activement les anciennes comme remplacées.