osFoundry / Platform
Extraction de mémoire
Maestro extrait des mémoires durables de chaque conversation — faits, décisions, préférences.
Présentation
L'extraction de mémoire est la manière dont le Maestro d'osFoundry transforme un échange éphémère en connaissance durable et réutilisable. Une fois une conversation compactée, Maestro relit l'échange et en tire ce qui mérite vraiment d'être conservé : des faits énoncés (\"notre stack, c'est Postgres\"), des décisions et les raisons qui les fondent, des préférences personnelles et d'équipe, des contraintes (\"ne touche pas à la base de staging\") et tout ce que vous demandez explicitement de retenir. Chaque mémoire extraite est stockée avec un type, un score d'importance et des étiquettes, afin de pouvoir être filtrée et récupérée plutôt que perdue dès que la fenêtre de contexte défile.\n\nAu sein d'osFoundry, l'extraction est conçue pour être peu coûteuse et honnête sur son coût. Elle s'exécute en arrière-plan (fire-and-forget) après le compactage et, avant même d'appeler un modèle, applique une vérification rapide de pertinence sur vos propres mots, en cherchant la forme que prend réellement un fait durable : une identité énoncée, une préférence, une décision ou une consigne du type \"à partir de maintenant\". Les tours qui ne portent rien de mémorable n'atteignent jamais le modèle, si bien que l'extraction ne facture pas discrètement votre clé d'API à chaque message. Lorsqu'elle s'exécute, elle utilise la chaîne de modèles que vous avez configurée pour le rôle de pipeline memory_extraction : n'importe quel modèle local, cloud ou auto-hébergé pour lequel vous apportez votre propre clé, sans marge de revendeur. Un seuil d'importance écarte ensuite les candidats de faible valeur avant toute écriture.\n\nLe stockage est local-first par conception. Les mémoires extraites sont d'abord remises à un magasin sur l'appareil (la table local_memories n'est jamais synchronisée vers le cloud) et seulement ensuite, si vous avez un compte et êtes en ligne, encodées et répliquées vers un magasin de mémoire d'espace de travail. Cet ordre est délibéré : un utilisateur travaillant entièrement en local ou hors ligne obtient tout de même chaque mémoire, et les faits quasi identiques sont dédupliqués à l'écriture. Plus tard, les agents et Maestro rappellent ces mémoires par recherche sémantique : la requête est encodée, comparée au magasin, et chaque correspondance revient avec sa propre adresse citable memory://, de sorte que vous voyez exactement quel fait mémorisé a nourri une réponse. Tout le parcours est en outre modulaire : vous pouvez brancher un memory_extractor personnalisé, l'extracteur natif d'osFoundry servant de repli.
Fonctionnalités clés
- Extrait de chaque conversation, après compactage, des mémoires durables : faits énoncés, décisions et leurs raisons, préférences, contraintes et demandes explicites de \"retiens ceci\".
- Applique un filtre de pertinence peu coûteux avant tout appel au modèle, de sorte que l'extraction ne dépense votre propre clé d'API que sur les tours susceptibles de porter quelque chose à conserver, pas à chaque échange.
- Utilise votre propre chaîne de modèles BYOK pour le rôle memory_extraction, en local ou dans le cloud, sans marge de revendeur sur les appels qu'elle effectue.
- Stockage local-first : les mémoires extraites sont écrites d'abord dans un magasin sur l'appareil (jamais synchronisé vers le cloud), donc elles persistent même hors ligne ou sans compte.
- Note chaque mémoire par importance et par type, déduplique les faits quasi identiques et les rend récupérables ensuite via une recherche sémantique avec des sources citables memory://.
Cas d’usage
- Ingénieur consultant : Maestro se souvient qu'un client a insisté pour Postgres plutôt que DynamoDB, et pourquoi, de sorte que des semaines plus tard l'agent ne rouvre pas une décision déjà tranchée.
- Chercheur soucieux de sa vie privée : préférences et faits de projet restent dans le magasin de mémoire sur l'appareil qui ne se synchronise jamais vers le cloud, utilisable entièrement hors ligne avec vos propres clés.
- Responsable d'équipe uniformisant les conventions : dès que vous dites \"notre équipe préfère les tabulations\" ou \"ne touche pas aux fichiers de migration\", cette contrainte est capturée et resurgit dans le travail ultérieur.
Questions fréquentes
L'extraction de mémoire envoie-t-elle mes conversations aux serveurs d'osFoundry ?
Non. Les mémoires extraites sont écrites d'abord dans un magasin sur l'appareil, et cette table de mémoire locale n'est jamais synchronisée vers le cloud. Ce n'est que si vous avez un compte et êtes en ligne que les mémoires sont en plus encodées et répliquées vers votre propre magasin de mémoire d'espace de travail. L'appel au modèle d'extraction s'exécute lui-même sur la clé que vous apportez : les serveurs d'osFoundry n'appellent jamais un LLM en votre nom.
Cela déclenche-t-il un appel d'IA coûteux après chaque message ?
Non. L'extraction n'a lieu qu'après le compactage d'une conversation et, même alors, un filtre de pertinence peu coûteux passe d'abord : une vérification rapide de motifs dans votre message pour repérer des préférences énoncées, des décisions ou des tournures du type \"retiens ceci\". Le bavardage ordinaire de tâche est écarté avant tout appel au modèle, si bien que votre clé d'API n'est pas facturée sur les tours qui ne contiennent rien à conserver.
Comment Maestro utilise-t-il une mémoire une fois extraite ?
Les mémoires sont stockées avec un type, un score d'importance et des étiquettes, puis rendues récupérables par recherche sémantique. Quand c'est pertinent, l'agent encode une requête, interroge le magasin et rapporte les faits correspondants, chacun avec une source citable memory:// pour que vous retraciez quel détail mémorisé a façonné la réponse. Vous choisissez le modèle de memory_extraction via les rôles de pipeline BYOK d'osFoundry.