Mai 2026 · 10 min de lecture · Fran Olivares, fondateur d’OlivaresAI
Un stockage de mémoire persistante seul ne fait rien. Le stockage doit être interrogé, pondéré et façonné en un prompt système qui tient dans la fenêtre de contexte du modèle avant que le prochain message utilisateur n’arrive. Cette étape — l’assemblage de contexte — est la différence entre « nous avons une base mémoire » et « l’IA se souvient ». Ce guide est le compagnon long-format de la référence technique sur /docs/context-assembly et parcourt chaque étape du pipeline, les valeurs qu’Alma utilise par défaut et les compromis que vous pouvez ajuster.
Parce que le modèle ne voit que ce qui est dans le prompt. Un stockage mémoire de dix mille entrées est invisible pour le modèle à moins que quelque chose ne sélectionne les bonnes trente pour ce tour. Si la sélection est mauvaise, le modèle rate le fait pertinent et produit une réponse générique. Si elle est trop large, le prompt déborde la fenêtre de contexte ou gaspille des tokens en bruit. L’assemblage est le gardien — une étape silencieuse que l’utilisateur ne voit jamais, mais toute la sensation « l’IA se souvient » repose sur sa qualité.
L’assemblage doit aussi respecter un budget de latence strict. L’utilisateur attend ; tout ce qui dépasse ~100 ms commence à paraître lent avant même qu’un seul token du modèle n’ait été streamé. C’est pourquoi l’assemblage s’appuie sur la recherche indexée plutôt que sur des balayages complets, pourquoi la pondération est une somme pondérée (pas un appel LLM) et pourquoi les budgets de tokens par niveau sont calculés à l’avance plutôt que négociés dynamiquement.
Recherche hybride à travers les trois couches de mémoire — mémoires, épisodes, procédures — utilisant à la fois des signaux mot-clé et sémantiques. La requête de l’utilisateur est embeddée avec le même modèle qui a indexé le stockage (bge-m3 1024-dim dans la configuration par défaut d’Alma) et l’embedding tourne contre l’index vectoriel pour faire remonter les entrées sémantiquement similaires. En parallèle, une recherche par mots-clés interroge l’index relationnel pour les correspondances de terme exact que la recherche sémantique manque parfois (noms propres, identifiants de code, termes techniques rares).
Les deux ensembles de résultats sont fusionnés, dédupliqués et plafonnés au budget de candidats (par défaut 100 par couche — le maximum que l’index vectoriel sous-jacent supporte par requête). Le pool de candidats est ce qui entre dans la pondération ; rien au-delà de cette étape ne récupère une entrée que la recherche n’a pas fait remonter.
Cinq signaux, pondérés comme suit dans la fonction de pondération en production :
Les poids sont volontairement ajustés : la pertinence domine, mais les signaux secondaires comptent quand la pertinence est à égalité (ce qui arrive souvent dans les stockages mémoire denses). Les poids sont des invariants inviolables dans le code ; toute modification requiert un benchmark A/B parce que la qualité ressentie de « l’IA s’est-elle souvenue de la bonne chose » dépend précisément de ce dosage.
Chaque niveau (mémoires, épisodes, procédures, blocs Soul) a son propre budget de tokens. Valeurs par défaut : mémoires ~2 K tokens, épisodes ~1 K, procédures ~500, blocs Soul ~500. Total ~4 K — bien en dessous de la fenêtre de contexte de tout modèle moderne, et assez petit pour rester cache-friendly. À l’intérieur de chaque niveau, les entrées pondérées sont ajoutées dans l’ordre du classement jusqu’à atteindre le budget.
Le budget existe pour deux raisons. Premièrement, le contexte effectif du modèle rétrécit si vous le bourrez au-delà d’une certaine densité — les éléments pertinents au bas d’un prompt de 100 K tokens sont de facto invisibles pour le motif d’attention. Deuxièmement, le prompt caching ne fonctionne que si le préfixe en cache est stable ; gonfler le prompt avec des mémoires de faible signal casse le cache et fait payer le plein tarif en tokens à chaque tour. Des budgets serrés gardent qualité et économie en ligne.
Un prompt système structuré avec cinq sections (dans cet ordre) : identité (blocs Soul actifs rendus en XML), préférences (entrées mémoire de haute importance marquées comme préférences), faits pertinents (mémoires les mieux classées pour cette requête), contexte récent (épisodes les mieux classés), workflows (procédures les mieux classées). La structure compte : placer l’identité en haut signifie qu’elle reçoit toute l’attention ; placer les workflows en bas signifie qu’ils ne sont consultés que si le modèle décide que la requête est procédurale.
Le message utilisateur est ensuite ajouté comme tour suivant. Le modèle reçoit le prompt assemblé + message utilisateur et produit une réponse. Du point de vue de l’utilisateur, l’IA a simplement répondu. En coulisses, l’assemblage a silencieusement consulté des milliers d’enregistrements mémoire et présenté au modèle les trente bons.
Dans le déploiement de production d’Alma, la latence d’assemblage end-to-end se situe dans la plage 30–80 ms pour un utilisateur typique (quelques centaines de mémoires, une douzaine d’épisodes). La recherche vectorielle domine (~20–40 ms), la recherche par mots-clés tourne en parallèle (~5–10 ms), la pondération est en ms à un chiffre et la construction du prompt est essentiellement gratuite. La cible de 100 ms est tenue avec une marge confortable même pour les utilisateurs avec des milliers de mémoires — le plafond de candidats et les budgets par niveau bornent le travail à mesure que le stockage grandit.
Avant la pondération, une passe de détection de contradiction sur le pool de candidats marque les paires dans la plage de similarité 0,75–0,92 qui se contredisent sémantiquement. L’entrée la plus récente l’emporte par défaut ; la plus ancienne est marquée comme supersédée et retirée de l’ensemble de candidats pour ce tour (et globalement, lors de la prochaine passe de consolidation). Cela empêche le modèle de recevoir « vous avez dit X » à côté de « vous avez dit non-X » et d’improviser une synthèse que l’utilisateur n’a jamais validée.
Le cycle de vie complet (déduplication, supersession, décroissance) est documenté dans le guide complet de la mémoire persistante; l’assemblage est juste l’endroit où ces décisions de cycle de vie apparaissent au moment de la requête.
Architecturalement similaire (les deux récupèrent, les deux classent, les deux injectent dans le prompt) mais le corpus et le cycle de vie sont différents. Le RAG récupère d’un corpus de documents externe rédigé une fois et réindexé selon un planning ; les entrées n’évoluent généralement pas. L’assemblage mémoire récupère du stockage en croissance continue de l’utilisateur, avec des entrées qui se contredisent, fusionnent et déclinent. Les poids de pondération diffèrent aussi — le RAG classe surtout par similarité et autorité du document ; l’assemblage mémoire pondère l’importance, la récence et la fréquence parce que ces signaux comptent davantage quand le stockage est personnel. Voir la comparaison approfondie dans Mémoire persistante vs RAG.
Oui. L’endpoint POST /api/v1/context/assemble accepte des surcharges pour les budgets par niveau, le seuil de score minimum, le plafond de candidats et les poids de boost pour les étiquettes de catégorie (pour qu’un agent PM puisse booster les décisions, qu’un agent rédacteur puisse booster les règles de voix). La plupart des équipes restent sur les valeurs par défaut — elles ont été ajustées pour être utiles dès la sortie de la boîte — mais les leviers existent pour les verticales spécialisées.
Commencez sur alma.olivares.ai, peuplez vingt ou trente mémoires sur un projet qui vous tient à cœur, puis lancez un chat. La première réponse du modèle dans la nouvelle conversation référencera des faits spécifiques de votre stockage mémoire — c’est l’assemblage, simplement caché derrière le chat visible. Pour les développeurs qui intègrent directement : la REST API expose le prompt assemblé brut afin que vous puissiez inspecter exactement ce qui a été sélectionné pour chaque requête.
Lecture associée : Référence technique Context Assembly · Architecture de mémoire à trois couches · Persistent Memory for AI: Complete 2026 Guide · Mémoire persistante vs RAG · Soul Engine expliqué.