Dans une pipeline mémoire LangGraph : du message au souvenir
Anatomie de la pipeline d'extraction d'iRemember : pourquoi LangGraph, comment un message devient un candidat-mémoire structuré, la déduplication, le traitement asynchrone et les choix de schéma qui rendent la récupération possible.
La plupart des tutoriels montrent un prompt : « extrais les faits de cette conversation ». Ce prompt représente 10 % environ d'une pipeline de production. Voici les 90 % restants, tels que construits pour iRemember.
Pourquoi LangGraph
L'extraction mémoire n'est pas un appel unique. C'est un workflow avec état :
lot_de_messages
-> extraction_candidats (LLM : faits, événements, personnes, décisions)
-> resolution_entites (LLM + règles : qui est « elle » ? fusion d'alias)
-> dedup_consolidation (match vectoriel vs mémoires existantes)
-> scoring_importance (signaux -> poids)
-> ecriture (seulement si tout est survécu)
Chaque étape a ses propres modes de défaillance et mérite sa propre évaluation. LangGraph nous donne un graphe explicite avec un état typé entre les nœuds : nous testons la consolidation indépendamment de l'extraction, réessayons les échecs du magasin vectoriel sans rappeler l'extracteur, et branchons (zéro écriture pour le small talk).
Le schéma qui rend la récupération possible
Chaque mémoire stockée porte :
- content — un fait atomique, formulé de façon autonome (« Sara préfère les messages vocaux aux appels »), jamais de pronoms
- type — préférence | événement | fait | décision | relation
- entités — références résolues vers personnes/lieux/projets
- horodatages — dit quand, valide du / au
- importance — poids appris, pas une impression
- embedding — pgvector, calculé à l'écriture
L' discipline qui compte le plus : un contenu atomique et autonome. Un extracteur autorisé à stocker « ils ont parlé du mariage » n'a rien stocké de récupérable.
Tout est asynchrone
L'extraction tourne dans des workers Celery une fois la réponse diffusée. La boucle de chat ne paie que la récupération. Deux conséquences à ingénierer :
- Fenêtres lecture-après-écriture — l'utilisateur dit « retiens que je suis allergique aux arachides », l'assistant confirme, mais l'extraction se termine deux secondes plus tard. Les demandes explicites passent par une voie d'écriture rapide.
- Idempotence — les retries arrivent. Chaque tâche porte une clé de plage de messages pour qu'une relance ne double-stocke pas.
La consolidation plutôt que l'append-only
La mémoire en append-only est la façon dont commence le bloat. Quand un candidat correspond à une mémoire existante (recouvrement d'entités + similarité au-dessus du seuil), le graphe route vers un nœud de consolidation : mettre à jour, fusionner ou remplacer avec horodatage. Les contradictions sont des entrées attendues, pas des erreurs — les gens changent de travail et de ville.
Ce que je dirais à mon ancien moi
- Écrire la logique de consolidation avant de peaufiner les prompts d'extraction ; la qualité de la dédup domine la précision perçue.
- Évaluer chaque nœud indépendamment avec des jeux dorés. Les chiffres bout-en-bout cachent quelle étape a régressé.
- Le small talk ne doit jamais atteindre l'extracteur. Une porte de classification bon marché nous a épargné ~40 % des appels d'extraction.
FAQ
Pourquoi utiliser LangGraph plutôt que de simples appels LLM ?
L'extraction mémoire est un workflow multi-étapes avec état : extraire des candidats, résoudre les entités, dédupliquer contre l'existant, décider des écritures. LangGraph modélise cela en graphe explicite avec état typé — testable nœud par nœud, au lieu d'un méga-prompt fragile.
L'extraction mémoire ajoute-t-elle de la latence aux réponses ?
Elle ne devrait pas. L'extraction tourne de façon asynchrone après l'envoi de la réponse — via des workers Celery chez nous. La boucle de conversation n'attend que la récupération, jamais les écritures.
Comment éviter les souvenirs dupliqués ou contradictoires ?
Les candidats sont comparés aux mémoires existantes par recouvrement d'entités et similarité d'embedding au-delà d'un seuil. Les correspondances déclenchent une consolidation (mise à jour/fusion/remplacement) plutôt qu'un insert aveugle.