Questions Fréquentes

Seizn Memory est une infrastructure de mémoire IA qui fournit une mémoire persistante et recherchable pour les applications IA. Contrairement aux bases de données vectorielles qui ne font que stocker/rechercher des vecteurs, Seizn inclut la couche produit complète : extraction de mémoire, gestion des politiques, gestion des clés, suppression, journaux d'audit et SDKs. Il résout le problème du maintien du contexte entre les sessions IA et permet des expériences IA personnalisées.

Les bases de données vectorielles sont une infrastructure de stockage/recherche pour les vecteurs. Seizn est un système de mémoire complet construit dessus, fournissant : extraction automatique de mémoire des conversations, classification des types de mémoire, gestion namespace/scope, rotation des clés API, journaux d'audit, SDKs et fonctionnalités de gouvernance. Pensez-y comme 'infrastructure de mémoire' vs 'infrastructure de recherche'.

Non. Le point de départ le plus courant est : stocker la mémoire -> rechercher -> injecter dans le prompt. RAG (composition automatique de contexte + génération de réponse) est l'étape suivante. Vous pouvez commencer simple et ajouter de la complexité selon les besoins.

1) POST /api/memories pour stocker une préférence utilisateur. 2) GET /api/memories pour rechercher. 3) Injecter les résultats dans votre prompt LLM. 4) Plus tard, ajouter /api/extract pour l'auto-extraction et /api/query pour les réponses augmentées par la mémoire.

Stockez les informations qui restent valides entre les conversations : préférences (ton, langue, format), faits (travail, outils, structure du projet), instructions ("toujours résumer en tableaux"), relations ("Alice est la responsable d'équipe"). Évitez de stocker des données temporaires ou spécifiques à la session sauf si vous utilisez le scope session.

Ne jamais stocker : mots de passe, clés API, tokens, cookies de session (infos d'auth), SSN, numéros de passeport, comptes bancaires (PII), infos de carte de crédit (données de paiement). Pour les données temporaires, utilisez le scope session avec TTL si nécessaire.

Le namespace sépare les mémoires par projet/tenant/environnement. Sans lui, les données se mélangent, la qualité de recherche baisse, et la suppression/export devient difficile. Recommandé : 'org:acme/app:chat/env:prod' ou 'project:myapp/env:staging'. N'utilisez jamais juste 'default' en production.

user : Préférences qui s'appliquent globalement à un utilisateur. session : Objectifs ou contexte valide uniquement pour cette conversation. agent : Règles spécifiques à un agent dans un système multi-agent. Utiliser correctement le scope réduit la longueur du prompt et améliore la cohérence des réponses.

memory_type classifie les mémoires : fact (info immuable), preference (choix utilisateur), instruction (règles à suivre), relationship (connexions personnes/org), experience (événements passés). C'est l'axe le plus puissant pour le filtrage, la suppression et l'application des politiques.

limit : Nombre de mémoires candidates à récupérer (trop bas = manquer des pertinentes, trop haut = contexte bruyant). threshold : Seuil de similarité 0-1 (plus haut = plus strict). Commencez avec limit=10, threshold=0.7. Si vous manquez des mémoires, baissez threshold à 0.6 et montez limit à 20. Si vous obtenez des résultats non pertinents, montez threshold à 0.75-0.8.

Généralement l'un de ces cas : 1) namespaces mélangés, 2) trop de mémoires stockées (bruit), 3) threshold trop bas, 4) contenu trop abstrait ('aime les choses' vs faits spécifiques). Solution : séparer les namespaces, rendre le contenu spécifique, augmenter threshold.

Ajouter un scoring d'importance et ne garder que les mémoires importantes. Utiliser TTL pour auto-expirer les anciennes mémoires. Fusionner périodiquement les mémoires similaires en résumés. Séparer les namespaces pour réduire la portée de recherche.

Flux recommandé : 1) Appeler avec auto_store=false pour prévisualiser les mémoires extraites. 2) Montrer les résultats à l'utilisateur pour confirmation. 3) Ne stocker que les mémoires approuvées. 4) Une fois la qualité d'extraction prouvée, passer à auto_store=true pour l'automatisation.

haiku : Plus rapide, moins cher, bon pour la plupart des cas. sonnet : Plus précis, meilleur pour les extractions importantes (onboarding, contrats, politiques). Utilisez haiku pour l'extraction en masse/initiale, sonnet pour les scénarios à haut risque.

Oui, mais le pattern recommandé est : créer une nouvelle mémoire + supprimer/archiver l'ancienne. Cette approche est meilleure pour les pistes d'audit et prévient les problèmes de régression.

Deux approches : 1) Supprimer par ID (précis), 2) Supprimer par namespace (nettoyage en masse). Pour entreprise/conformité, assurer 'suppression complète + journal d'audit'. Documenter clairement votre politique de suppression.

Vous avez atteint la limite de taux. Solutions : 1) Implémenter un backoff exponentiel (1s -> 2s -> 4s). 2) Mettre en file d'attente les requêtes côté serveur. 3) Réduire la fréquence des requêtes : cacher les requêtes dupliquées, opérations par lots, réduire la fréquence d'extraction.

Principaux facteurs de coût : 1) Fréquence d'extraction - réduire les appels. 2) Portée de recherche - utiliser namespace pour réduire. 3) Choix du modèle - utiliser haiku pour la routine, sonnet pour l'important. 4) Cache - cacher les requêtes répétées. 5) Opérations par lots quand c'est possible.

Non recommandé - risque élevé d'exposition de clé. Appelez Seizn depuis votre serveur (Next.js Route Handler, Cloudflare Worker, fonction serverless) et faites appeler votre serveur par le navigateur. N'exposez jamais les clés API au code côté client.

Ils voudront : 1) Portée des données (ce qui est stocké/pas stocké), 2) Chiffrement (au repos : AES-256, en transit : TLS), 3) Méthode d'isolation des tenants, 4) Politique de suppression/rétention, 5) Accès aux journaux d'audit, 6) Politique de rotation/expiration des clés. Garder une page Sécurité et Gouvernance dans vos docs.

Seizn utilise une architecture Graph-RAG qui combine les embeddings vectoriels avec les relations de graphe de connaissances. Les mémoires sont stockées comme des nœuds avec des arêtes typées (relates_to, supports, contradicts, etc.). Cela permet : le rappel contextuel via la traversée du graphe, la détection automatique de communautés pour le clustering thématique, et le suivi temporel des connaissances avec des périodes de validité.

Seizn organise automatiquement les mémoires en niveaux selon l'utilisation : niveau Hot (accès fréquent, gardé en cache rapide), niveau Warm (accès occasionnel, récupération standard), niveau Cold (rarement utilisé, archivé mais recherchable). Le gestionnaire de niveaux promeut/dégrade automatiquement les mémoires selon les patterns d'accès, optimisant à la fois la performance et le coût.

Seizn stocke à la fois le contenu original et une représentation canonique en anglais pour chaque mémoire. Les requêtes de recherche sont comparées aux deux embeddings, permettant des scénarios comme rechercher en anglais et trouver des mémoires en hindi. Nous utilisons des modèles d'embedding multilingues (BGE-M3, LaBSE) qui supportent plus de 100 langues avec un alignement cross-lingual élevé.

Seizn supporte plus de 35 langues pour l'extraction et la recherche de mémoire, incluant : anglais, chinois (simplifié/traditionnel), hindi, espagnol, français, allemand, japonais, coréen, russe, ukrainien, arabe, et toutes les principales langues indiennes (tamoul, télougou, bengali, etc.). La langue est auto-détectée avec plus de 95% de précision.

MCP (Model Context Protocol) permet aux assistants IA comme Claude Desktop d'accéder directement aux mémoires Seizn. Installez notre serveur MCP (npx @seizn/mcp-server), ajoutez-le à votre configuration Claude Desktop, et l'assistant peut automatiquement sauvegarder et récupérer des mémoires pendant les conversations. Cela permet une personnalisation persistante entre les sessions.

Seizn est construit sur : Next.js 16 avec React Server Components, Supabase (PostgreSQL + pgvector pour la recherche vectorielle), modèle Voyage AI voyage-3 (embeddings 1024 dimensions), Claude pour l'extraction et l'analyse de mémoire. Nous utilisons des index HNSW pour une recherche vectorielle sub-100ms, des abonnements WebSocket en temps réel, et Redis pour le cache.

Trois approches principales : 1) REST API - appels HTTP directs pour un contrôle total, 2) SDKs (TypeScript/Python) - wrappers typés avec logique de retry, 3) Serveur MCP - intégration automatique avec Claude Desktop et autres assistants compatibles MCP. Pour la production, nous recommandons le SDK avec des appels côté serveur pour protéger votre clé API.

L'API Context (GET /api/context) retourne une chaîne pré-formatée prête à injecter dans votre prompt LLM. Elle combine : profil utilisateur, mémoires récentes, faits pertinents et contexte du graphe. Utilisez format=brief (~500 tokens), detailed (~1500 tokens), ou extended (~3000 tokens) selon votre budget de contexte.