Évaluation et comparaison

Dimensions de l'évaluation architecturale

L'évaluation d'un système de mémoire pour agents ne peut se limiter à la simple recherche vectorielle de surface : elle exige d'analyser l'architecture de production sous-jacente (modèle de stockage, isolation multi-locataire, garanties de cohérence, conformité aux protocoles, latence et lisibilité par les machines).

• Modèle de stockage : Métadonnées relationnelles hybrides associées à des plongements vectoriels par opposition aux bases plates purement vectorielles. Le socle relationnel garantit un filtrage pushdown exact, des journaux d'audit immuables et un partitionnement strict des portées.
• Isolation multi-locataire : Cloisonnement strict des locataires au niveau matériel ou serveur par opposition au filtrage par métadonnées au niveau applicatif. Les espaces partagés nécessitent des liaisons d'espace cryptographiquement signées.
• Garanties de cohérence : Cohérence lecture-après-écriture (read-your-writes) à travers les appels d'outils distribués par opposition aux fenêtres de cohérence éventuelle provoquant des hallucinations dans les boucles d'agents autonomes.
• Conformité aux protocoles : Points de terminaison natifs Model Context Protocol (MCP) Streamable HTTP par opposition aux wrappers propriétaires nécessitant des adaptateurs SDK spécifiques par framework.
• Lisibilité par les machines : Réponses JSON structurées et déterministes respectant strictement les schémas d'outils, sans bavardage textuel superflu ni enrobage conversationnel.

Éléments à évaluer dans toute couche de mémoire

Évaluez tout système de mémoire pour agents selon sept dimensions fondamentales en production : isolation des portées, attribution des appelants, suppression du cycle de vie, intégration des protocoles, limites de débit en concurrence, bancs d'essai reproductibles et fonctionnalités dépendantes du forfait.

• Isolation des portées : Demandez à tout fournisseur comment sont cloisonnées les mémoires d'utilisateur, de session, d'agent et d'espace de travail. XMemo applique une hiérarchie orthogonale de portées à 4 niveaux (user, session, agent, team/space) avec une isolation de projet native à la frontière de stockage (voir /docs/concepts/scopes et /docs/concepts/projects).
• Attribution et provenance : Demandez à tout fournisseur si chaque écriture et mutation de mémoire remonte à une identité d'appelant vérifiée et à un événement source. XMemo consigne l'attribution de l'appelant, les empreintes d'instance d'agent et les métadonnées de provenance dans des journaux d'audit et conserve l'historique des versions (versions superseded) avec des DAG de mise à jour (voir /docs/concepts/agent-instance-identity et /docs/concepts/memory-model).
• Suppression et export : Demandez à tout fournisseur comment la plateforme gère la suppression réversible par tombstone, le caviardage permanent et l'exportation massive de données. XMemo propose des états de cycle de vie régis (active, archived, deleted), une suppression réversible avec restauration, le caviardage permanent de contenu et l'exportation JSON structurée (voir /docs/concepts/memory-deletion et /docs/api/memory).
• Intégration MCP et REST : Demandez à tout fournisseur si la couche de mémoire offre une prise en charge native du Model Context Protocol (MCP) aux côtés des points de terminaison REST standards. XMemo fournit un serveur MCP natif en Streamable HTTP exposant un catalogue d'outils standard gelé aux côtés de points de terminaison REST authentifiés sous /v1/ (voir /docs/mcp/overview et /docs/api/authentication).
• Limites de débit : Demandez à tout fournisseur comment le débit des requêtes et les limites de concurrence sont appliqués et communiqués aux clients. XMemo applique une limitation de débit à l'exécution régie par la couche api-authentication plutôt que des quotas statiques publiés, et les clients ne doivent pas intégrer d'hypothèses de quotas codées en dur (voir /docs/api/authentication).
• Bancs d'essai reproductibles : Demandez à tout fournisseur si les affirmations relatives à la précision du rappel et à la latence sont vérifiables de manière indépendante avec des harnais ouverts et des jeux de données déterministes. XMemo publie des contrats de bancs d'essai gérés par le référentiel avec des jeux de données déterministes Golden Set (recall_golden_set.jsonl) et des historiques d'exécution immuables, distinguant l'évaluation en mémoire des I/O réseau (voir /docs/guides/evaluate#reproducible-benchmark-methodology).
• Fonctionnalités dépendantes du forfait : Demandez à tout fournisseur quels processus d'arrière-plan et fonctionnalités avancées sont inclus dans le moteur de base versus soumis à des forfaits commerciaux. XMemo intègre le stockage, la recherche, le rappel de base et l'outil reflect à 5 actions dans l'exécution de base, tandis que la réflexion Dream planifiée en arrière-plan dépend d'indicateurs de fonctionnalités et des forfaits/droits (préréglages : manual, daily ou weekly ; voir /docs/concepts/how-xmemo-works et /docs/concepts/dream-reflection).

{
  "evaluation_checklist": {
    "dimensions": [
      {
        "dimension": "Scope isolation",        "question": "How are user, session, agent, and workspace memories segregated?",        "xmemo_answer": "4-tier orthogonal scope hierarchy (user, session, agent, team/space) enforced at storage boundary (/docs/concepts/scopes)"      },
      {
        "dimension": "Attribution and provenance",        "question": "Can every memory mutation be traced to a specific caller and event?",        "xmemo_answer": "Caller attribution and agent instance fingerprints recorded in audit logs with version history (/docs/concepts/agent-instance-identity)"      },
      {
        "dimension": "Deletion and export",        "question": "Does the system support soft deletion, hard redaction, and data export?",        "xmemo_answer": "Tombstone soft-deletion with restoration, hard redaction, and structured export (/docs/concepts/memory-deletion)"      },
      {
        "dimension": "MCP and REST integration",        "question": "Is the memory layer accessible via native MCP as well as HTTP REST?",        "xmemo_answer": "Native Streamable HTTP MCP server with frozen tool catalog and authenticated REST endpoints (/docs/mcp/overview)"      },
      {
        "dimension": "Rate limits",        "question": "How are request quotas communicated and enforced?",        "xmemo_answer": "Runtime rate limiting governed by api-authentication without hard-coded client quotas (/docs/api/authentication)"      },
      {
        "dimension": "Reproducible benchmarks",        "question": "Are retrieval accuracy and performance metrics independently verifiable?",        "xmemo_answer": "Open repository-owned benchmark harness with deterministic golden set datasets and run traces (/docs/guides/evaluate#reproducible-benchmark-methodology)"      },
      {
        "dimension": "Plan-dependent features",        "question": "Which features are core runtime versus gated by tier entitlements?",        "xmemo_answer": "Core operations and 5-action reflect tool in base runtime; background Dream reflection is plan/entitlement-dependent (/docs/concepts/dream-reflection)"      }
    ]
  }
}

Guide de sélection par scénario

Évaluez la topologie de vos charges de travail, l'organisation de votre équipe et vos exigences de gouvernance pour choisir le modèle d'architecture de mémoire adéquat.

• Flux multi-agents multi-environnements : Choisissez une couche de mémoire avec prise en charge native de MCP, portées de projet partagées et synchronisation multi-clients pour orchestrer des agents sur Claude Code, Cursor, ChatGPT, Codex et Gemini CLI.
• Espaces d'entreprise et réglementés : Privilégiez les architectures offrant une hiérarchie de portées orthogonale (user, session, agent, team/space), des journaux d'audit avec attribution de l'appelant et un cloisonnement des locataires imposé au niveau matériel ou serveur.
• Boucles autonomes à forte concurrence : Sélectionnez des architectures dotées d'arbres de mises à jour versionnés, d'un verrouillage optimiste et d'une cohérence lecture-après-écriture (read-your-writes) pour éviter les mises à jour contradictoires et les hallucinations liées à une mémoire obsolète.

Méthodologie de banc d'essai reproductible

XMemo fournit un harnais de banc d'essai ouvert et intégré au référentiel pour évaluer la précision du rappel et les contraintes de gouvernance dans des conditions contrôlées. Le système distingue strictement l'évaluation synthétique interne, la latence de production réelle et les déclarations publiques vérifiées.

• Contrat méthodologique : Les bancs d'essai respectent un contrat de méthode figé et reproductible avec des jeux de données golden déterministes et des traces de vérification enregistrées.
• Bancs d'essai synthétiques internes : Exécutés de manière hermétique via scripts/benchmark_runner.py avec tests/data/recall_golden_set.jsonl (SHA-256 7533FBDC...) afin de mesurer la qualité de l'algorithme de rappel en mémoire et la logique de classement, sans I/O réseau ni base de données.
• Latence de production réelle : La latence de bout en bout comprend la négociation TLS, le transit réseau, les transactions de base de données et la surcharge d'isolation multilocataire. Elle varie selon la topologie de déploiement (SaaS cloud vs Docker auto-hébergé) et la distance géographique, et n'est pas représentée par des chiffres synthétiques en mémoire.
• Déclarations publiques de performances : Toutes les métriques rapportées doivent mentionner un benchmark_run_id immuable et le rapport de vérification brut issu des sessions de vérification. Les affirmations non vérifiées des fournisseurs et les raccourcis synthétiques sont exclus des assertions de référence.
• Analyse des cas limites : Signalement d'un cas limite documenté où des entités homonymes ('config.py' dans deux projets distincts) sont entrées en concurrence de classement sans qualification explicite de portée ; résolu par l'ajout de contraintes de portée de projet.

# Execute reproducible retrieval benchmark against golden set
python scripts/benchmark_runner.py \
  --track standard \
  --dataset tests/data/recall_golden_set.jsonl \
  --cache-state COLD_CACHE \
  --output reports/custom_run_raw.json

Guide de migration vers XMemo

La transition depuis un stockage clé-valeur historique, une base purement vectorielle ou un service tiers vers XMemo s'effectue en quatre étapes structurées.

• Étape 1 : Exportez les enregistrements existants sous la forme de flux JSON Lines comprenant text, user_id, session_id et les horodatages created_at.
• Étape 2 : Mappez les identifiants sur la hiérarchie de portées de XMemo (user_id vers owner, session_id vers agent_instance_id ou project_id) et catégorisez les faits selon leur durabilité.
• Étape 3 : Importez les données via l'outil par lots remember ou l'API REST (/v1/memories) en renseignant les attributs de portée et de provenance.
• Étape 4 : Validez l'exactitude des rappels et les frontières d'isolation avec recall_context avant d'activer les autorisations d'écriture des agents.

import requests

def migrate_legacy_record(legacy_item, api_key):
    payload = {
        "content": legacy_item["content"],
        "path": f"migration/{legacy_item.get('id', 'item')}",
        "scope": "project" if legacy_item.get("project_id") else "user",
        "metadata": {"source": "legacy_migration", "original_id": legacy_item.get("id")}
    }
    response = requests.post(
        "https://xmemo.dev/v1/memories",
        headers={"Authorization": f"Bearer {api_key}"},
        json=payload
    )
    response.raise_for_status()
    return response.json()

Limites connues et frontières opérationnelles

Pour éviter toute inadéquation fonctionnelle, veillez à respecter les limites de conception et les frontières opérationnelles de XMemo.

• Pas une base relationnelle universelle : XMemo est optimisé pour les faits, les états et les compétences d'agents ; il ne remplace pas une base opérationnelle pour des transactions SQL arbitraires.
• Pas un espace de déversement de fichiers non structurés : Les documents de plus de 32 Ko doivent être indexés dans les bases de connaissances (Knowledge Bases) plutôt que stockés en tant que nœuds individuels.
• Périodicité de réflexion Dream : L'API et l'outil MCP reflect n'exposent pas de planificateur ; la planification Dream en arrière-plan dépend d'indicateurs de fonctionnalités et des forfaits/droits (préréglages : manual [par défaut], daily à 03:00 heure locale du propriétaire, ou weekly), et la consolidation n'est pas synchrone avec les écritures.
• Limites de débit : Les points de terminaison hébergés appliquent une limitation de débit à l'exécution régie par api-authentication plutôt que des quotas statiques publiés ; les clients ne doivent pas coder en dur d'hypothèses de quotas.