Häufig gestellte Fragen

Seizn Memory ist eine KI-Speicherinfrastruktur, die persistenten, durchsuchbaren Speicher für KI-Anwendungen bietet. Anders als Vektordatenbanken, die nur Vektoren speichern/suchen, enthält Seizn die vollständige Produktschicht: Speicherextraktion, Richtlinienverwaltung, Schlüsselverwaltung, Löschung, Audit-Logs und SDKs. Es löst das Problem der Kontexterhaltung über KI-Sitzungen hinweg und ermöglicht personalisierte KI-Erlebnisse.

Vektordatenbanken sind Speicher-/Suchinfrastruktur für Vektoren. Seizn ist ein vollständiges Speichersystem darauf aufgebaut, das bietet: automatische Speicherextraktion aus Gesprächen, Speichertyp-Klassifizierung, Namespace/Scope-Verwaltung, API-Schlüsselrotation, Audit-Logs, SDKs und Governance-Funktionen. Denken Sie an 'Speicherinfrastruktur' vs 'Suchinfrastruktur'.

Nein. Der häufigste Startpunkt ist: Speicher speichern -> suchen -> in Prompt einfügen. RAG (automatische Kontextzusammenstellung + Antwortgenerierung) ist der nächste Schritt. Sie können einfach beginnen und Komplexität nach Bedarf hinzufügen.

1) POST /api/memories um eine Benutzerpräferenz zu speichern. 2) GET /api/memories zum Suchen. 3) Ergebnisse in Ihren LLM-Prompt einfügen. 4) Später /api/extract für Auto-Extraktion und /api/query für speichererweiterte Antworten hinzufügen.

Speichern Sie Informationen, die über Gespräche hinweg gültig bleiben: Präferenzen (Ton, Sprache, Format), Fakten (Job, Tools, Projektstruktur), Anweisungen ("immer in Tabellen zusammenfassen"), Beziehungen ("Alice ist die Teamleiterin"). Vermeiden Sie temporäre oder sitzungsspezifische Daten, es sei denn Sie nutzen Session-Scope.

Niemals speichern: Passwörter, API-Schlüssel, Tokens, Session-Cookies (Auth-Infos), SSN, Passnummern, Bankkonten (PII), Kreditkarteninfos (Zahlungsdaten). Für temporäre Daten nutzen Sie Session-Scope mit TTL wenn nötig.

Namespace trennt Speicher nach Projekt/Tenant/Umgebung. Ohne ihn werden Daten vermischt, Suchqualität sinkt, und Löschung/Export wird schwierig. Empfohlen: 'org:acme/app:chat/env:prod' oder 'project:myapp/env:staging'. Nutzen Sie niemals nur 'default' in Produktion.

user: Präferenzen die global für einen Benutzer gelten. session: Ziele oder Kontext nur für dieses Gespräch gültig. agent: Regeln spezifisch für einen Agent in einem Multi-Agent-System. Korrekter Scope-Einsatz reduziert Prompt-Länge und verbessert Antwortkonsistenz.

memory_type klassifiziert Speicher: fact (unveränderliche Info), preference (Benutzerauswahl), instruction (zu befolgende Regeln), relationship (Personen/Org-Verbindungen), experience (vergangene Ereignisse). Dies ist die mächtigste Achse für Filterung, Löschung und Richtlinienanwendung.

limit: Anzahl der Kandidaten-Speicher zum Abrufen (zu niedrig = relevante verpassen, zu hoch = verrauschter Kontext). threshold: 0-1 Ähnlichkeitsgrenze (höher = strenger). Starten Sie mit limit=10, threshold=0.7. Bei verpassten Speichern threshold auf 0.6 senken und limit auf 20 erhöhen. Bei irrelevanten Ergebnissen threshold auf 0.75-0.8 erhöhen.

Meist eines davon: 1) Namespaces gemischt, 2) zu viele Speicher (Rauschen), 3) threshold zu niedrig, 4) Inhalt zu abstrakt ('mag Sachen' vs spezifische Fakten). Lösung: Namespaces trennen, Inhalt spezifisch machen, threshold erhöhen.

Wichtigkeits-Scoring hinzufügen und nur wichtige Speicher behalten. TTL nutzen um alte Speicher automatisch ablaufen zu lassen. Periodisch ähnliche Speicher zu Zusammenfassungen fusionieren. Namespaces trennen um Suchbereich zu reduzieren.

Empfohlener Ablauf: 1) Mit auto_store=false aufrufen um extrahierte Speicher vorzuschauen. 2) Ergebnisse dem Benutzer zur Bestätigung zeigen. 3) Nur genehmigte Speicher speichern. 4) Sobald Extraktionsqualität bewiesen, auf auto_store=true für Automatisierung wechseln.

haiku: Schneller, günstiger, gut für die meisten Fälle. sonnet: Genauer, besser für wichtige Extraktionen (Onboarding, Verträge, Richtlinien). Nutzen Sie haiku für Massen-/Erstextraktion, sonnet für risikoreiche Szenarien.

Ja, aber das empfohlene Muster ist: neuen Speicher erstellen + alten löschen/archivieren. Dieser Ansatz ist besser für Audit-Trails und verhindert Regressionsprobleme.

Zwei Ansätze: 1) Nach ID löschen (präzise), 2) Nach Namespace löschen (Massenbereinigung). Für Enterprise/Compliance sicherstellen 'vollständige Löschung + Audit-Log'. Ihre Löschrichtlinie klar dokumentieren.

Sie haben das Ratenlimit erreicht. Lösungen: 1) Exponentielles Backoff implementieren (1s -> 2s -> 4s). 2) Anfragen serverseitig in Warteschlange stellen. 3) Anfragehäufigkeit reduzieren: Duplikat-Abfragen cachen, Batch-Operationen, Extraktionshäufigkeit senken.

Größte Kostentreiber: 1) Extraktionshäufigkeit - Aufrufe reduzieren. 2) Suchbereich - Namespace zum Eingrenzen nutzen. 3) Modellwahl - haiku für Routine, sonnet für Wichtiges. 4) Caching - wiederholte Abfragen cachen. 5) Batch-Operationen wenn möglich.

Nicht empfohlen - hohes Risiko der Schlüsselexposition. Rufen Sie Seizn von Ihrem Server auf (Next.js Route Handler, Cloudflare Worker, Serverless-Funktion) und lassen Sie den Browser Ihren Server aufrufen. Niemals API-Schlüssel im Client-Code exponieren.

Sie wollen: 1) Datenumfang (was wird gespeichert/nicht gespeichert), 2) Verschlüsselung (ruhend: AES-256, übertragend: TLS), 3) Tenant-Isolierungsmethode, 4) Lösch-/Aufbewahrungsrichtlinie, 5) Audit-Log-Zugriff, 6) Schlüsselrotations-/Ablaufrichtlinie. Eine Sicherheits- und Governance-Seite in Ihren Docs führen.

Seizn verwendet eine Graph-RAG-Architektur, die Vektor-Embeddings mit Wissensgraph-Beziehungen kombiniert. Speicher werden als Knoten mit typisierten Kanten gespeichert (relates_to, supports, contradicts, etc.). Dies ermöglicht: kontextuellen Abruf durch Graph-Traversierung, automatische Community-Erkennung für thematisches Clustering und zeitliches Wissens-Tracking mit Gültigkeitsperioden.

Seizn organisiert Speicher automatisch in Tiers basierend auf der Nutzung: Hot-Tier (häufig zugegriffen, in schnellem Cache gehalten), Warm-Tier (gelegentlich zugegriffen, Standard-Abruf), Cold-Tier (selten genutzt, archiviert aber durchsuchbar). Der Tier-Manager befördert/degradiert Speicher automatisch basierend auf Zugriffsmustern und optimiert sowohl Leistung als auch Kosten.

Seizn speichert sowohl den Originalinhalt als auch eine kanonische englische Repräsentation für jeden Speicher. Suchanfragen werden mit beiden Embeddings abgeglichen, was Szenarien wie das Suchen auf Englisch und Finden von Hindi-Speichern ermöglicht. Wir verwenden mehrsprachige Embedding-Modelle (BGE-M3, LaBSE), die über 100 Sprachen mit hoher sprachübergreifender Ausrichtung unterstützen.

Seizn unterstützt über 35 Sprachen für Speicherextraktion und -suche, darunter: Englisch, Chinesisch (vereinfacht/traditionell), Hindi, Spanisch, Französisch, Deutsch, Japanisch, Koreanisch, Russisch, Ukrainisch, Arabisch und alle wichtigen indischen Sprachen (Tamil, Telugu, Bengali, etc.). Die Sprache wird automatisch mit über 95% Genauigkeit erkannt.

MCP (Model Context Protocol) ermöglicht KI-Assistenten wie Claude Desktop den direkten Zugriff auf Seizn-Speicher. Installieren Sie unseren MCP-Server (npx @seizn/mcp-server), fügen Sie ihn zu Ihrer Claude Desktop-Konfiguration hinzu, und der Assistent kann während Gesprächen automatisch Speicher speichern und abrufen. Dies ermöglicht persistente Personalisierung über Sitzungen hinweg.

Seizn basiert auf: Next.js 16 mit React Server Components, Supabase (PostgreSQL + pgvector für Vektorsuche), Voyage AI voyage-3 Modell (1024-dimensionale Embeddings), Claude für Speicherextraktion und -analyse. Wir verwenden HNSW-Indizes für sub-100ms Vektorsuche, WebSocket-Echtzeit-Abonnements und Redis für Caching.

Drei Hauptansätze: 1) REST API - direkte HTTP-Aufrufe für volle Kontrolle, 2) SDKs (TypeScript/Python) - typsichere Wrapper mit Retry-Logik, 3) MCP-Server - automatische Integration mit Claude Desktop und anderen MCP-kompatiblen Assistenten. Für Produktion empfehlen wir das SDK mit serverseitigen Aufrufen zum Schutz Ihres API-Schlüssels.

Die Context API (GET /api/context) gibt einen vorformatierten String zurück, der direkt in Ihren LLM-Prompt eingefügt werden kann. Sie kombiniert: Benutzerprofil, aktuelle Speicher, relevante Fakten und Graph-Kontext. Verwenden Sie format=brief (~500 Tokens), detailed (~1500 Tokens) oder extended (~3000 Tokens) je nach Ihrem Kontext-Budget.