Bekommt jeder Nutzer seine eigene Memory?

Ja. Jeder Endnutzer hat seine eigene Memory und jede Workspace ihre eigenen Dokumente. Zwischen ihnen wird nichts geteilt, und die Isolation steckt in der Konstruktion statt in der Konfiguration.

Kann die Memory eines Nutzers gelöscht werden?

Ja. Ein Call löscht alles, was zu einem Endnutzer gespeichert ist. Abgerufene Fakten werden von der Firewall pseudonymisiert, bevor sie die EU verlassen, ein Löschverlangen ist also ein einziger Vorgang.

Wo laufen die Modelle, die meine Dokumente lesen?

Auf EU-residenten Endpoints. Das Modell, das Fakten aus einem Gespräch zieht, und das Modell, das Ihre Dokumente embeddet, laufen beide innerhalb der EU, von Anfang bis Ende.

Wie unterscheidet sich das von einem größeren Kontextfenster?

Ein Kontextfenster enthält nur das, was Sie bei dieser Request mitschicken. Recall hält Fakten zwischen Requests, gleicht sie ab, wenn sie sich ändern, und folgt den Verbindungen dazwischen, statt Widersprüche anzuhäufen.

Muss ich die Memory selbst verwalten?

Nein. Schicken Sie eine User-ID mit Ihrer Request und legen Sie Ihre Dokumente in eine Collection. Fakten werden im Hintergrund gelernt und von selbst abgerufen.

Recall

Ihre Modelle erinnern sich an Nutzer und kennen Ihre Dokumente.

Recall lernt dauerhafte Fakten aus jedem Gespräch und belegt Antworten mit Ihren eigenen Dokumenten, und hält beides in einem Knowledge Graph. Stellen Sie eine Frage, und es holt die passenden Fakten und Passagen, entlang der Verbindungen dazwischen. Extraktion und Retrieval laufen auf EU-residenten Modellen, abgegrenzt pro Endnutzer und Workspace, und auf Verlangen löschbar.

Kostenlos starten Docs lesen

lernen · verbinden · abrufen

Ihr Modell vergisst jeden Nutzer und hat Ihre Docs nie gelesen.

Ein Modell hält zwischen Requests nichts fest und antwortet nur aus seinem Training, nicht aus Ihrem Handbuch oder der Entscheidung der letzten Woche. Also schicken Sie bei jeder Call denselben Kontext mit und verpassen trotzdem, worauf es ankommt. Bauen Sie es selbst, betreiben Sie einen Store, einen Extraktionsschritt und einen Retrieval-Schritt, und halten das alles richtig, während sich Fakten ändern, oft über eine US-API, die Ihre Daten außer Landes schickt. Zwei halbe Lösungen, Memory und Retrieval, die nie teilen, was sie wissen.

Wie es funktioniert

Lernen, verbinden, abrufen.

Schicken Sie einen User mit Ihrer Request, legen Sie Ihre Dokumente einmal dazu, und Recall macht den Rest. Nichts zu markieren, kein Kontext zum Mitschicken, keine Retrieval-Call zu verkabeln.

01LernenLernen und einlesenNach jedem Austausch zieht ein EU-residentes Modell im Hintergrund dauerhafte Fakten heraus: Präferenzen, Rollen, Entscheidungen. Dokumente, die Sie hinzufügen, werden geparst, geteilt und in denselben Graphen gelesen. Das läuft nach der Response und kostet keine Latenz.
02VerbindenVerbinden und abgleichenFakten und Dokumente werden Entitäten und Beziehungen in einem temporalen Graphen. Neue Fakten werden gegen das Bekannte abgeglichen: geänderte aktualisieren, widersprochene werden zurückgezogen. Der Graph bleibt richtig, statt nur zu wachsen.
03AbrufenAbrufen mit QuellenBei einer Request, die einen User trägt, mischt Recall die passenden Fakten und Passagen, folgt den Verbindungen dazwischen, und legt sie als Kontext dazu, bevor das Modell läuft. Jede Antwort kann die Fakten und Dokumente nennen, die sie benutzt hat.

Zwei Felder. Fakten werden von selbst gelernt und abgerufen.

Warum es anders ist

Mehr als ein größeres Kontextfenster, mehr als ein Index nebenan.

Die ganze Historie in jeden Prompt zu stopfen ist langsam, teuer und vergisst trotzdem, worauf es ankommt. Ein selbstgebauter Retrieval-Stack ist eine Vector Database plus eine Embedding-API plus Klebstoff. Recall ist eine Knowledge-Schicht, in der Memory und Dokumente einen Graphen teilen.

Ein Graph, keine zwei Silos
Gesprächsfakten und Dokumentfakten liegen beieinander, damit eine Frage der Verbindung von einem Nutzer zu seiner Organisation zu dem Dokument folgen kann, das sie beantwortet.
Automatisch, nicht manuell
Schicken Sie eine User-ID mit und legen Sie Ihre Dokumente in eine Collection. Fakten werden von selbst gelernt und abgerufen und Passagen gefunden, ohne einen eigenen Service, den Sie zuerst aufrufen müssten.
Abgeglichen, nicht angehäuft
Wenn ein Nutzer seine Meinung ändert oder ein Dokument aktualisiert wird, aktualisiert sich der Graph, statt Widersprüche anzuhäufen.
Belegt und mit Quellen
Antworten können die Fakten und Dokumente nennen, die sie benutzt haben, die Audit Trail bleibt bei reinen Metadaten, und die Memory jedes Nutzers ist auf Verlangen löschbar.

Eine Knowledge-Schicht

Hinter die Sie sich stellen können.

Abgetrennt by Design

Jeder Endnutzer hat seine eigene Memory, und jede Workspace ihre eigenen Dokumente. Recall liest die Memory des handelnden Endnutzers plus diese Workspace und ihre Collections, nie die eines anderen Nutzers, einer anderen Workspace oder eines anderen Tenants.

EU-resident, von Anfang bis Ende

Die Modelle, die das Gespräch lesen und Ihre Dokumente embedden, laufen auf EU-residenten Endpoints, und der Graph liegt in einem EU-residenten Store. Die Memory Ihrer Nutzer und Ihre Wissensbasis verlassen die EU nie.

Erfasst und löschbar

Abgerufene Fakten werden von der Firewall vor dem Egress pseudonymisiert, jede Antwort kann ihre Quellen nennen, die Audit Trail enthält nur Metadaten, und ein Call löscht alles, was zu einem Endnutzer gespeichert ist.

FAQ

Fragen zu Recall.

Bekommt jeder Nutzer seine eigene Memory?: Ja. Jeder Endnutzer hat seine eigene Memory und jede Workspace ihre eigenen Dokumente. Zwischen ihnen wird nichts geteilt, und die Isolation steckt in der Konstruktion statt in der Konfiguration.
Kann die Memory eines Nutzers gelöscht werden?: Ja. Ein Call löscht alles, was zu einem Endnutzer gespeichert ist. Abgerufene Fakten werden von der Firewall pseudonymisiert, bevor sie die EU verlassen, ein Löschverlangen ist also ein einziger Vorgang.
Wo laufen die Modelle, die meine Dokumente lesen?: Auf EU-residenten Endpoints. Das Modell, das Fakten aus einem Gespräch zieht, und das Modell, das Ihre Dokumente embeddet, laufen beide innerhalb der EU, von Anfang bis Ende.
Wie unterscheidet sich das von einem größeren Kontextfenster?: Ein Kontextfenster enthält nur das, was Sie bei dieser Request mitschicken. Recall hält Fakten zwischen Requests, gleicht sie ab, wenn sie sich ändern, und folgt den Verbindungen dazwischen, statt Widersprüche anzuhäufen.
Muss ich die Memory selbst verwalten?: Nein. Schicken Sie eine User-ID mit Ihrer Request und legen Sie Ihre Dokumente in eine Collection. Fakten werden im Hintergrund gelernt und von selbst abgerufen.

Hier anfangen

Geben Sie Ihren Modellen eine Knowledge-Schicht.

Legen Sie einen Key an, schicken Sie einen User mit Ihren Requests, legen Sie Ihre Dokumente dazu, und hören Sie auf, bei jeder Call denselben Kontext mitzuschicken.