Datenspeicher wählen und umziehen

Wähle Speicher für drei Datenarten: Anwendungsdatensätze, durchsuchbares Wissen und Originaldateien. Der Umzug einer Art verschiebt die anderen nicht. Speicherorte bestimmen auch nicht, wo ein Modellanbieter oder Connector Anfragen verarbeitet. Beziehe diese Ziele in deine Prüfung der Datenresidenz ein.

Umfang der Änderung wählen

Der mitgelieferte Stack betreibt tale_app und tale_knowledge als getrennte Datenbanken in einem Postgres-Dienst. Andere Aufbauten können eigene Dienste verwenden. Die vom Deployment erzeugten Umgebungswerte wählen die Standards. Ein allein gestarteter Anwendungsprozess erfindet keine funktionierenden Objektspeicher-Zugangsdaten.

Organisationsänderungen brauchen Admin- oder Owner-Rechte. Ohne eigene Verbindung nutzt Tale den Bereitstellungsstandard und trennt Daten nach Organisation. Eine ungültige konfigurierte Wissensverbindung verursacht einen Fehler, statt unbemerkt eine andere Datenbank zu verwenden.

Externe Datenbank vorbereiten

Stelle Datenbank und Zugangsdaten vor der Tale-Änderung bereit. Die Anwendungsdatenbank braucht eine Rolle, die ihre Schema-Migrationen anwenden darf. Für Wissen muss vector installiert sein; pg_search ergänzt den BM25-Teil der Hybridsuche. Mit pgvector allein erhältst du Vektorsuche ohne diesen Stichwortanteil. Tale legt Wissensschemata und Tabellen an, installiert aber keine Erweiterungen auf deiner Datenbank.

Nutze eine direkte oder sitzungskompatible Postgres-Verbindung. Transaction-Pooling verträgt sich nicht mit den verwendeten Sitzungssperren, LISTEN und vorbereiteten Anweisungen. Für sslmode=verify-ca oder verify-full stellst du die nötigen PEM-Stammzertifikate über POSTGRES_CA_FILE bereit und mountest die Datei in beiden Backend-Rollen. Prüfe Verbindung und Rechte aus dem Bereitstellungsnetz.

Lege vor der Umschaltung fest, wie vorhandene Anwendungs- oder Wissensdaten ans Ziel kommen, und erstelle abgestimmte Backups. Das Speichern einer Verbindung ändert nur das Ziel nachfolgender Operationen. Alte Zeilen werden nicht kopiert und Dokumente nicht automatisch neu indexiert.

Bereitstellungsstandards ändern

Ändere .env und stelle die betroffenen Backend-Dienste neu bereit oder erstelle sie neu. docker compose restart behält die bisherige Umgebung. Ziehen beide Datenbanken aus dem mitgelieferten Dienst aus, bewahre dessen altes Volume bis zur Abnahme der neuen Speicher und des Wiederherstellungsplans auf.

Beim Standard-Objektspeicher gleicht das Backend default/object-storage/connection.json und die Geheimnisdatei beim Start mit der Umgebung ab. Das Ergebnis unterscheidet seeded, reconciled, skipped bei fehlenden Zugangsdaten und ignored bei einer vom Betreiber verwalteten Datei. Mit "managedBy": "operator" übernimmst du die Dateiverwaltung selbst.

Ein anderer Standard-Bucket oder Endpunkt kopiert keine vorhandenen Dateien. Übertrage sie mit Speicherwerkzeugen unter Erhalt von Schlüsseln und benötigten Metadaten. Koordiniere die Umschaltung, bevor du den alten Speicher entfernst. Externe Datenbanken und Buckets liegen außerhalb der Datensicherung durch CLI-Volume-Snapshots. Aktualisiere dabei die Verfahren für Backups und Wiederherstellung.

Wissensdatenbank einer Organisation verbinden

1. Öffne Einstellungen > Datenresidenz in der Zielorganisation und trage unter Wissensdatenbank Host, Port, Datenbank, Benutzer, SSL-Modus und Passwort ein.
2. Wähle Verbindung testen. Der Test prüft die Felder zuerst wie Speichern und nennt einen fehlenden Host, eine fehlende Datenbank oder einen fehlenden Benutzer unter dem Feld, statt zu laufen. Prüfe Erreichbarkeit und Erweiterungen. Ein erfolgreicher Verbindungstest belegt keinen abgeschlossenen Korpusumzug.
3. Speichere erst, wenn Ziel und Plan für vorhandene Daten bereit sind. Folgende Anfragen nutzen die gewählte Verbindung ohne Container-Neustart.
4. Indexiere ein Testdokument, suche nach einer bekannten Formulierung und prüfe, ob benötigte ältere Inhalte weiter verfügbar sind.

Die Dateien liegen unter $TALE_CONFIG_DIR/<orgSlug>/knowledge/: connection.json, connection.secrets.json und embedding.json. Bei konfiguriertem age-Schlüssel nutzt die Geheimnisdatei SOPS. Das Entfernen der Verbindung leitet wieder auf den Standard um. Externe Daten bleiben bestehen, sind über die entfernte Verbindung aber nicht mehr zugänglich.

Embedding-Modell auf den Korpus abstimmen

Wähle unter Embedding-Modell Anbieter und gespeicherte Zugangsdaten und dann das Modell. Modell führt die Embedding-Modelle aus dem Katalog des Anbieters auf und füllt die Vektorbreite aus dem Katalog aus. Ein Anbieter, der überhaupt kein Embedding-Modell anbietet, etwa Anthropic, lässt sich nicht wählen: In der Zeile steht Bietet keine Embeddings, und du wählst einen anderen Anbieter. Kennt Tale für den Anbieter keine Vektorbreite, trägst du das Modell-Tag (bei Azure OpenAI den Namen deines Deployments) und die Vektorbreite ein, die dieses Modell erzeugt. Das gilt für einen mitgelieferten Anbieter, dessen Katalog kein Embedding-Modell führt, für einen von deiner Organisation selbst definierten Anbieter, dessen Modellliste keines führt, und für Azure OpenAI, dessen Deployments deine eigenen Namen tragen. Welcher der beiden Fälle vorliegt, entscheidet die embedding-Angabe des Anbieters, und das Speichern lehnt einen Anbieter ohne Embeddings ab, egal auf welchem Weg die Anfrage kommt. Kann Tale die Angaben nicht prüfen, sagt der Abschnitt das und bietet Erneut versuchen an; bis die Prüfung antwortet, lässt sich kein Modell wählen. Eine optionale Basis-URL wählt einen OpenAI-kompatiblen Endpunkt. Ohne konfiguriertes Embedding-Modell können Wissensindexierung und Suche nicht regulär arbeiten.

Eine Wissensdatenbank speichert Vektoren der Breiten 256, 384, 512, 768, 1024, 1536, 2048, 3072 und 4096 und hält jede Breite von den anderen getrennt. Organisationen auf derselben Datenbank können deshalb Modelle unterschiedlicher Breite verwenden. Eine Breite außerhalb dieser Liste lässt sich nicht speichern. Oberhalb von 2000 steht der Vektorsuche kein Index zur Verfügung; sie wird mit wachsendem Korpus langsamer.

Speicherst du ein Modell mit anderer Breite, stellt Tale die bereits indexierten Dokumente und E-Mails wieder in die Warteschlange und scannt die Websites der Organisation. Alle erhalten neue Vektoren in der neuen Breite, und dafür wird der Embedding-Anbieter für jedes davon erneut aufgerufen. Solange ein Dokument in der Warteschlange wartet, findet die Suche es weiterhin über seine Wörter. Den Wechsel zu einem Modell gleicher Breite bemerkt Tale nicht: Die vorhandenen Vektoren bleiben bestehen, obwohl ein anderes Modell sie inkompatibel macht. Plane eine Neuindexierung mit dem gewählten Modell, statt Embeddings ungeprüft zu mischen.

embedding.json kann minSimilarity als Untergrenze für den Vektoranteil der Assistentensuche setzen; der Standard ist 0.45. Das Einstellungsformular erhält diesen Dateiwert, bietet aber kein Feld dafür. Stimme ihn anhand repräsentativer Suchanfragen ab. Die REST-Wissenssuche verwendet eine Grenze nur, wenn die Anfrage sie angibt. Es ist kein allgemeiner Schwellenwert für alle Suchen.

Anfragen an einen selbst betriebenen Embedding-Server dosieren

Zwei weitere optionale Einstellungen in embedding.json beschreiben, wie viel Arbeit der Embedding-Server verkraftet. Setze sie, wenn du den Server selbst betreibst, etwa einen Modellserver auf eigener Hardware, der eine Anfrage nach der anderen berechnet und die übrigen in eine Warteschlange stellt. Wie minSimilarity gibt es sie nur in der Datei: Das Einstellungsformular behält sie beim Speichern bei, und die CLI deklariert sie in der Ressource knowledge-embedding.

• maxConcurrentRequests (1 bis 64, Standard 3) legt fest, wie viele Embedding-Anfragen an dieses Modell Tale für die Organisation gleichzeitig offen hält. Dokumentindexierung, die Indexierung eingehender E-Mails, Website-Scans und Suchen teilen sich dieses Limit. Weitere Anfragen warten in der Reihenfolge ihres Eintreffens; nur eine Suchanfrage zieht an wartenden Indexierungs-Batches vorbei. Jeder Tale-Prozess zählt für sich, sodass die API und jedes Worker-Replikat das Limit jeweils ausschöpfen können. Ein niedrigerer Wert gilt sofort, ein höherer erst, wenn die unter dem alten Wert gestarteten Anfragen abgeschlossen sind. Berechnet der Server eine Anfrage nach der anderen, erzeugt ein höherer Wert keine zusätzliche Last; jede Anfrage wartet nur länger.
• minTokensPerSecond (eine beliebige positive Zahl) ist die niedrigste Rate, mit der der Server unter seiner üblichen Last Embeddings für dieses Modell berechnet. Miss sie, während auf derselben Hardware andere Arbeit läuft, etwa ein Chat-Modell, aber zähle die Zeit nicht mit, die eine Anfrage hinter anderen Anfragen wartet. Diese Wartezeit rechnet Tale selbst hinzu.
• maxTokensPerMinute und maxRequestsPerMinute (ganze Zahlen) dosieren, was Tale diesem Modell innerhalb einer Minute schickt, für die Organisation in jedem Tale-Prozess. Setze sie auf die Minutenlimits eines gehosteten Anbieters, die pro Anbieterkonto über alle Deployments gezählt werden, die sich den Schlüssel teilen: Ein Indexierungs-Batch, der ein Limit überschreiten würde, wartet, bis genug von der letzten Minute verstrichen ist, sodass ein Crawl über Hunderte Seiten dosiert wird statt mit 429 abgewiesen zu werden. Tale schätzt Tokens anhand der Zeichen, eher zu hoch, hält zusätzlich ein Sechzigstel jedes Limits innerhalb jeder einzelnen Sekunde ein – ein Anbieter setzt seinen Minutenwert auch pro Sekunde durch – und bemisst jede Anfrage so, dass sie in diese Sekunde passt. Ein 429, das der Anbieter trotzdem schickt, hält jede Anfrage der Organisation an dieses Modell an und wird im Minutentakt wiederholt; eine Suchanfrage wird von beidem nicht gebremst. Alibaba Cloud Model Studio erlaubt für text-embedding-v4 zum Beispiel 1.800 Anfragen und 1.000.000 Tokens pro Minute.

{
  "providerSlug": "local-embedding",
  "model": "example-embedding",
  "dimensions": 1024,
  "baseUrl": "https://embeddings.example.internal/v1",
  "maxConcurrentRequests": 2,
  "minTokensPerSecond": 800,
  "maxTokensPerMinute": 1000000,
  "maxRequestsPerMinute": 1800
}

Jede Embedding-Anfrage hat eine Obergrenze: 15 Minuten für die Indexierung und 5 Minuten für eine Suchanfrage, auf die eine Chat-Antwort wartet. Ohne minTokensPerSecond weiß Tale nicht, wie lange die Warteschlange des Servers dauern kann, und lässt eine Anfrage ihre ganze Obergrenze ausschöpfen. Mit dieser Einstellung gibt Tale jeder Anfrage Zeit für die Arbeit, die auf dem Server vor oder neben ihr liegen kann, und für ihre eigene. Dazu zählen die Tokens der Anfrage selbst, großzügig aus ihren Zeichen geschätzt, die übrigen Anfragen, die dieser Tale-Prozess gleichzeitig offen haben kann, und maxConcurrentRequests weitere von anderen Clients. Jede dieser Anfragen rechnet Tale mindestens als vollen Batch aus 64 Texten mit je 1.024 Tokens. Die Summe teilt Tale durch minTokensPerSecond und schlägt 50 % auf, gibt aber nie weniger als 60 Sekunden und nie mehr als die Obergrenze. Mit dem Beispiel oben bekommt ein voller Batch mit gewöhnlichem Text rund acht Minuten und eine Suchanfrage ihre Obergrenze von fünf Minuten. Eine Suchanfrage endet außerdem nach insgesamt fünf Minuten, einschließlich der Wartezeit auf einen freien Platz. Teilen sich mehr Clients den Server als ein weiterer Tale-Prozess mit demselben Limit, gib eine niedrigere Rate an.

Eine Anfrage, deren Zeit abgelaufen ist, sendet Tale nicht sofort erneut: Der Server hatte sie die ganze Zeit, und eine Wiederholung würde seine Warteschlange nur verlängern. Eine abgelehnte Verbindung, eine Ratenbegrenzung oder ein Serverfehler wird nach einer Pause wiederholt, die mit jedem Versuch wächst, oder nach der Pause, die ein ausgelasteter Server mit Retry-After verlangt, höchstens einer Minute. Verlangt ein Server eine längere Pause, lässt Tale ihn in Ruhe. Schlägt bei einer Anfrage aus mehreren Batches einer fehl, etwa bei einer langen Webseite, bricht Tale die übrigen Batches ab, ob sie laufen oder noch warten, sodass der Server nicht weiter an ihnen rechnet.

Für die Indexierung eines Dokuments bleiben pro Versuch höchstens 15 Minuten. Braucht ein großes Dokument oder eine lange Warteschlange mehr, endet der Versuch an dieser Grenze und bricht seine offene Anfrage ab; eine Anfrage, deren Zeit abläuft, beendet den Versuch ebenfalls. Der nächste Versuch beginnt nach einer Pause, die mit jedem Versuch wächst, und macht nach den bereits gespeicherten Chunks weiter. Ist ein Dokument nach sechs Versuchen noch nicht fertig, erscheint es als fehlgeschlagen. Indexierung erneut versuchen macht dann bei den gespeicherten Chunks weiter.

Bucket einer Organisation verbinden

1. Stelle einen S3-kompatiblen Bucket mit den benötigten Objektrechten bereit. Konfiguriere CORS für die tatsächlichen Browser-Ursprünge und benötigten Methoden GET, PUT und HEAD.
2. Trage unter Objektspeicher Region, bei Bedarf Endpunkt, Bucket, optionales Schlüsselpräfix und Zugangsdaten ein. Nutze Path-Style, wenn dein Speicher es verlangt.
3. Wähle Verbindung testen und speichere danach. Eine fehlende Region, ein fehlender Bucket oder ein Wert über der Längengrenze eines Felds wird unter dem Feld genannt, bevor etwas gesendet wird. Der Servertest schreibt, liest und löscht ein Testobjekt; Browser-CORS prüft er nicht.
4. Lade im Browser eine Testdatei hoch und wieder herunter, bevor du dich auf die Verbindung verlässt.

Neue Uploads verwenden den Organisations-Bucket. Ältere Dateien im Standardspeicher können über gemischte Referenzen lesbar bleiben. Die Verbindung allein erfüllt daher keine Pflicht, auch den bisherigen Bestand umzuziehen. Die Konfiguration liegt unter $TALE_CONFIG_DIR/<orgSlug>/object-storage/connection.json und connection.secrets.json.

Entfernst du die Verbindung, gehen neue Uploads an den Standardspeicher. Vorhandene Objekte bleiben im Organisations-Bucket. Tale kann sie erst nach Wiederherstellen der Verbindung wieder lesen.

Vorhandene Dateien gezielt verschieben

Nutze nach dem Speichern des Buckets Bestehende Dateien verschieben im selben Abschnitt. Prüfe eine angebotene Vorschau, bestätige den Umzug und verfolge den Fortschritt. Halte die Verbindung bis zum Abschluss stabil.

Der Nachzug durchläuft referenzierte Dokumente samt Verlauf, hochgeladene Dateien, erzeugtes Audio und Videotranskripte dieser Organisation. Er kopiert jedes Objekt mit Inhaltstyp, prüft die Zielgröße und löscht danach die Quelle. Objektschlüssel bleiben erhalten. Bereits verifizierte Kopien lassen sich nach einer Unterbrechung abschließen. Das ist ein Umzug, kein zusätzliches Backup oder kryptografischer Inhaltsnachweis.

Das Ziel muss sich vom Standardspeicher unterscheiden. Prüfe bei einem Fehlschlag letzten Fehler und Fortschritt vor einem neuen Lauf. Bewahre beide Speicher auf, bis Ergebnis und Downloads beispielhafter alter Dateien bestätigt sind. Geheimnisse mit SOPS erklärt den Schutz der Verbindungsdateien.