Supermemory AI: prouver que la mémoire est prête, scopée et courante

Supermemory AI est une couche de mémoire et de contexte pour les agents: il ingère des conversations et des documents, dérive des souvenirs, prend en charge la récupération et maintient des profils. La question opérationnelle est plus étroite que l'API a t elle accepté mon écriture? Une mémoire utile n'est prête que lorsque le traitement de la source est terminé, le fait attendu peut être rappelé à partir du conteneur correct, et la version retournée est toujours actuelle. Cette distinction est importante parce que Supermemory enregistre deux lignes chronologiques distinctes. Un document atteignant done signifie que son parcours de document est recherchable. Avec le mode de rêve dynamic par défaut, l'extraction de mémoire peut se poursuivre après cet état. Un opérateur qui transforme done en signal vert de santé de la mémoire peut donc signaler le succès avant que l'agent puisse rappeler le fait dont il a besoin. Le défaut pratique est de conserver dynamic pour une ingestion normale de production, puis de vérifier le rappel avant de permettre une action dépendante de la mémoire. Utilisez instant uniquement lorsque l'étape suivante nécessite réellement le fait de graphiser immédiatement, et prenez en compte l'opération supplémentaire documentée par Supermemory. Dans les deux modes, conservez containerTag , customId , timestamps et hashes de preuve sans contenu dans un seul reçu. Un statut de document vert n'est pas un verdict de mémoire verte Le documentation actuelle du pipeline de Supermemory nomme les étapes du document: file d'attente, extraction, fractionnement, intégration, indexation et finition. Il dit aussi que la même entrée peut produire trois sorties différentes: les pièces de document pour la mise à terre de la source; les mémoires graphiques pour les faits extraits et les mises à jour temporelles; un profil pour le contexte toujours en marche. Ces résultats répondent à des questions différentes. Une recherche réussie des documents prouve que le matériel source indexé est disponible. Une recherche de mémoire prouve qu'un fait dérivé est récupérable. Une réponse de profil prouve qu'un résumé sélectionné est disponible. Aucun des trois ne prouve par lui même les autres. Le démarrage rapide officiel définit explicitement la limite de temps. add retourne alors que le traitement est asynchrone. Avec dreaming: "instant" , le tutoriel attend que le document atteigne done avant de vérifier les mémoires et les profils. Avec le mode dynamic par défaut, le document RAG peut être prêt pendant que l'extraction de la mémoire est encore en train de charger le matériel connexe. Transformez cela en un reçu de cinq champs plutôt qu'un seul booléen: Les preuves Ce que cela prouve Ce qu'il ne prouve pas ingestStatus: done Traitement du document terminé La mémoire graphique attendue est déjà récupérable en mode dynamic requête de rappel a été exécutée Une tentative de lecture s'est produite Le fait retourné est celui attendu ou actuel hash attendu correspondant Le canary sans contenu correspond au fait attendu Le résultat est venu du bon locataire ou projet un conteneur correspondant La récupération est restée dans le champ d'isolement prévu. Le fait n'a pas été remplacé la version actuelle vérifiée Le fait retourné est la version que le flux de travail devrait utiliser L' agent a terminé sa tâche en aval. C'est un canary synthétique créé pour le test. Ne pas hasher la mémoire privée de l'utilisateur et l'appeler anonyme: des valeurs prévisibles peuvent encore être devinées. Gardez les instructions de production, le contenu récupéré, les clés API et les données d'utilisateur hors du dossier médical. Construire un reçu de mémoire qui peut représenter l'attente L'état important n'est pas seulement sain ou brisé. dynamic rêve délibérément regroupe les documents connexes en unités cohérentes, de sorte qu'un court intervalle de rappel après la fin du document peut être une attente légitime. La même erreur après une fenêtre d'observation convenue est un échec. Dans le mode instant , une erreur après done mérite une enquête immédiate car l'objectif documenté de ce mode est la disponibilité rapide après traitement. Une preuve compacte peut ressembler à ceci: La fenêtre d'observation est votre politique d'exploitation, pas une promesse au niveau du service Supermemory. Mesurez le pour vos types de contenu et votre charge de travail. Une courte conversation, une longue vidéo et une synchronisation du connecteur n'ont pas de distributions de traitement interchangeables. Le classifiant utilisé pour l'article présente la priorité suivante: J'ai reproduit sept cas dans cet ordre: entrée en file d'attente, termination de document seulement, retard dynamique autorisé, mémoire instantanée manquante, récupération croisée de conteneur, un fait remplacé, et un reçu sain. Seul le dernier cas était sûr d'utiliser. La distinction entre memory waiting et memory missing a empêché un retard normal de batchage de devenir un incident, tandis que l'état séparé de recall unverified a empêché l'achèvement du document d'être mal étiqueté comme la préparation de la mémoire. Cet artefact est intentionnellement un classifiateur, pas une sonde de Supermemory vivante. Il fait confiance aux preuves normales fournies par votre adaptateur. Valider l'adaptateur de manière indépendante, en particulier les champs de portée et de version. Département d'essai et fraîcheur avec canaries jumelles Supermemory décrit containerTag comme une limite d'isolement dure et recommande un customId stable pour le contenu qui sera mis à jour. Ces deux identifiants devraient faire partie de chaque test de santé de la mémoire. Créer deux conteneurs synthétiques qui ne peuvent jamais être confondus avec les vrais utilisateurs: 1. écrire un fait canarien unique et non secret sur le conteneur A sous un customId stable; 2. écrire un canary différent du conteneur B; 3. attendre en fonction du mode de rêve choisi; 4. A recherche le canary d'A et vérifie son hash; 5. recherche B pour le canarien d'A et ne nécessite aucun résultat correspondant; 6. mettre à jour le fait d'A sous la même identité logique; 7. vérifier que la récupération sélectionne le nouveau fait et ne favorise pas la valeur remplacée; 8. redémarrer l'agent d'appel ou commencer une nouvelle session, puis répéter la lecture. La requête négative est aussi importante que la requête positive. Une réponse correcte du conteneur A ne prouve pas l'isolement. Vous avez besoin de preuves que le conteneur B ne peut pas récupérer le canary d'A. De même, la récupération de toute mémoire connexe après une mise à jour ne prouve pas la précision temporelle. L'enregistrement retourné doit correspondre à la version actuelle attendue. Ne pas exécuter des tests destructeurs d'oubli ou de suppression de conteneurs contre la portée d'un utilisateur réel. Supermemory expose la mise à jour de la mémoire et le comportement d'oubli, mais un contrôle de santé planifié devrait utiliser des conteneurs synthétiques dédiés avec une politique de nettoyage explicite et des informations d'identification limitées. Si le nettoyage échoue, enregistrez le comme son propre problème plutôt que de le cacher à l'intérieur de l'appel de santé. Chaque défaillance doit être effectuée jusqu'à la plus petite réparation. Un verdict utile devrait indiquer une action limitée suivante: État Première action processing Continuez à attendre et préservez l' ID du document original memory waiting Revérifiez après la fenêtre dynamique mesurée; ne réingérez pas encore ingest failed Vérifiez l'échec du document et le type d'entrée avant de réessayer recall unverified Effectuer la vérification du rappel synthétique; ne pas déclarer la mémoire saine memory missing Comparer le mode de rêve, le temps de traitement, la requête et le conteneur avant une nouvelle tentative limitée scope unverified Arrêter les actions dépendantes de la mémoire jusqu'à ce que l'adaptateur puisse prouver le conteneur prévu scope leak Traiter comme une défaillance d'isolation de haute gravité et bloquer l'utilisation du résultat stale or wrong memory Inspectez l'identité des mises à jour et l'historique des versions; ne pas écraser aveuglément ready Permettez l'étape dépendante de la mémoire, puis vérifiez son résultat réel séparément La réingestion n'est pas une réparation universelle. Si l'écriture originale a réussi et que l'extraction de mémoire est simplement en attente, une autre écriture peut créer un travail dupliqué et rendre le diagnostic temporel plus difficile. Le passage de chaque écriture à instant n'est pas non plus une solution neutre: la documentation le présente comme un compromis de latence avec une opération facturée supplémentaire, tandis que dynamic est la production par défaut pour le regroupement de matériel connexe. Enfin, la préparation de la mémoire n'est toujours pas une réussite des tâches. Un agent peut récupérer la préférence correcte et ensuite l'ignorer, appeler l'outil incorrect, ou ne pas produire le produit de livraison. Gardez un reçu de résultat séparé pour l'action qui a consommé la mémoire. L'orientation pertinente du produit de Sidewisp est de rendre la mémoire et la santé du contexte visibles aux côtés de l'accessibilité des agents, de l'accès aux outils, des progrès et des résultats. Sidewisp est actuellement en préversion privée. Son moteur de surveillance de la production, ses adaptateurs hôtes et son exécuteur de récupération ne sont généralement pas expédiés, donc cet article est un modèle géré par l'opérateur plutôt qu'une affirmation selon laquelle Sidewisp contrôle actuellement les installations Supermemory.