Multi-Tenant-RAG hinter einem OpenAI-kompatiblen API-Gateway

Kundenorientierte KI-Assistenten benötigen eine abrufgestützte Generierung, aber RAG wird schwieriger, wenn Anfragen über ein OpenAI-kompatibles API-Gateway und nicht über den nativen Stack eines Modellanbieters fließen. Das Gateway muss Mandantendaten isoliert halten, Zitate über Modellanbieter hinweg bewahren, indizierte Inhalte termingerecht löschen und Einbettungs-, Abruf- und Generierungskosten dem richtigen Kunden zuordnen.

Die praktische Antwort besteht darin, den Abruf als erstklassiges Gateway-Subsystem zu behandeln. Verstecken Sie es nicht innerhalb einer Anbieterintegration. Halten Sie den Abruf von der Generierung getrennt, geben Sie jeder Anfrage einen mandantenweiten Abrufkontext, normalisieren Sie Zitate, bevor Sie sie zurückgeben, und zeichnen Sie jeden abrechenbaren Schritt in einem Hauptbuch auf.

Das Leserproblem

Ein Team, das einen KI-Assistenten für viele Kunden aufbaut, beginnt normalerweise mit einem einfachen Ablauf: Dokumente hochladen, Blöcke einbetten, die besten Übereinstimmungen abrufen, diese Snippets in die Eingabeaufforderung einfügen und ein Modell um eine Antwort bitten. Das funktioniert so lange, bis das Produkt mehrere Modellanbieter, Abrechnung auf Kundenebene, Offboarding und Überprüfbarkeit benötigt.

Das Risiko besteht nicht nur in ungenauen Antworten. Die größeren Betriebsrisiken sind Fehler im Mandanten-Namespace, nicht überprüfbare Zitate, veraltete Indizes nach dem Löschen von Dokumenten und Margen, die nicht erklärt werden können, weil die Abrufkosten in den allgemeinen Infrastrukturausgaben verschwinden.

In diesem Artikel werden Fakten, Empfehlungen und Prognosen getrennt. Die Fakten sind Implementierungsmöglichkeiten, die durch aktuelle Anbieter- und Vektordatenbank-APIs dokumentiert sind. Bei den Empfehlungen handelt es sich um Architekturoptionen für ein Gateway-Produkt. Bei den Vorhersagen wird diese Architektur wahrscheinlich Flexibilität benötigen, da sich die Anbieterabruffunktionen ständig ändern.

Referenzarchitektur

Ein RAG-Design auf Gateway-Ebene sollte fünf Komponenten haben:

• Mandantenauflöser: ordnet den eingehenden API-Schlüssel, den Arbeitsbereich, das Kundenkonto oder den Partner-API-Kunden einer kanonischen Mieter-ID zu.
• Abrufprofil: definiert, welcher Korpus durchsucht werden soll. Welches Einbettungsmodell verwendet werden soll, Ergebnisanzahl, Filter, Reranking-Optionen, Zitieranforderungen und Fallback-Verhalten.
• Abrufadapterschicht: ruft den nativen Anbieterabruf, eine externe Vektordatenbank oder einen benutzerdefinierten Suchdienst über eine interne Schnittstelle auf.
• Prompt-Assembly- und Generierungsadapter: übergibt den abgerufenen Kontext an den ausgewählten Modellanbieter, ohne den Aufrufern Vektor-Backend-Details preiszugeben.
• Nutzung und Prüfung Hauptbuch: zeichnet Einbettung, Indizierung, Abruf, Eingabeaufforderungs-Tokens, Abschluss-Tokens, Mandanten-, Modell-, Anbieter- und Ablaufverfolgungskennungen auf.

Ein minimaler Anforderungsvertrag kann anbieterneutral bleiben:

{
  „tenant_id“: „tenant_123“,
  „model“: „gpt-kompatibles-oder-claude-kompatibles-Modell“,
  „retrieval_profile“: „support_docs_v2“,
  „citation_required“: wahr,
  „Nachrichten“: [
    {"role": "user", "content": "Was ist unsere Rückerstattungsrichtlinie für Jahrespläne?"}
  ]
}

Die Antwort sollte auch anbieterneutral sein:

{
  „Antwort“: „Jahrespläne können innerhalb des konfigurierten Richtlinienfensters erstattet werden …“,
  „Zitate“: [
    {
      „source_id“: „doc_789“,
      „title“: „Abrechnungsrichtlinie“,
      „url_or_internal_ref“: „kb://billing-policy“,
      „chunk_id“: „chunk_044“,
      "offsets": {"page": 3},
      „Punktzahl“: 0,82,
      „retrieval_provider“: „vector_db“,
      „model_provider“: „openai_kompatible“,
      „provider_payload“: {}
    }
  ],
  „retrieval_trace_id“: „rt_456“,
  „billable_tenant“: „tenant_123“,
  „embedding_usage“: null,
  "retrieval_usage": {"queries": 1, "results": 6},
  „model_usage“: {„input_tokens“: 1920, „output_tokens“: 180}

Fakt: Die Funktionen zum Abrufen von Anbietern sind nicht identisch

Die Vector Stores-API von OpenAI unterstützt Vektorspeicher, die erstellt, durchsucht, mit Chunking-Strategien konfiguriert, mit Dateimetadaten verknüpft und gelöscht werden können. Die Vector Store-Suche unterstützt Abfragen, Filter, maximale Ergebnisanzahl, Ranking-Optionen, Bewertungsschwellenwerte und Steuerelemente zum Umschreiben von Abfragen. Diese Steuerelemente bieten Gateway-Autoren nützliche Regler für Latenz, Relevanz und Kosten.

Datenkontrollen der OpenAI-Plattform machen auch das Lebenszyklusdesign wichtig: Kundeninhalte in Vektorspeichern bleiben bis zur Löschung erhalten. Wenn ein Mieter aussteigt oder ein temporäres Projekt abläuft, kann das Gateway nicht davon ausgehen, dass der Anbieter indizierte Inhalte automatisch im Geschäftsplan des Produkts entfernt.

Anthropic zeigt ein anderes Muster für Zitate auf. Anwendungen können Suchergebnis-Inhaltsblöcke mit Quell- und Titelmetadaten bereitstellen, und wenn Zitate aktiviert sind, kann das Modell Zitatverweise an generierten Text anhängen. Es gibt praktische Einschränkungen: Die Zitationseinstellungen für Suchergebnisse sind alles oder nichts innerhalb einer Anfrage, Suchergebnisblöcke unterstützen Textinhalte und die Granularität der Zitate hängt davon ab, wie der Inhalt in Blöcke aufgeteilt wird.

Die Implikation ist direkt: Ein Gateway sollte die Abrufform eines Anbieters nicht als seinen öffentlichen Vertrag offenlegen, es sei denn, es beabsichtigt, diesen Anbieter zur permanenten Abrufautorität zu machen.

Empfehlung: Verwenden Sie Abrufadapter, nicht Abruf Lock-In

Erstellen Sie eine interne Abrufadapterschnittstelle. Das Gateway kann mehrere dahinterliegende Backends unterstützen:

• Nativer Anbieterabruf: nützlich, wenn ein Kunde den schnellsten Weg zu den Dateisuch- oder Vektorspeicherfunktionen eines Anbieters wünscht.
• Externe Vektordatenbank: nützlich, wenn das Produkt viele Modellanbieter mit konsistenter Mandantenisolierung und Lebenszykluskontrollen unterstützen muss.
• Vorab abgerufene Suchergebnisblöcke: nützlich, wenn das Gateway abgerufenen Text zusammenstellt und an einen übergibt Anbieter, der expliziten Zitierkontext unterstützt.

Der Adapter sollte unabhängig vom Backend dieselbe interne Struktur zurückgeben:

interface RetrievalResult {
  retrievalTraceId: string;
  Mieter-ID: Zeichenfolge;
  corpusId: string;
  chunks: Array<{
    Quell-ID: Zeichenfolge;
    Titel: Zeichenfolge;
    Text: Zeichenfolge;
    urlOrInternalRef?: string;
    chunkId: string;
    offsets?: { page?: number; byteStart?: Zahl; byteEnd?: Zahl; tokenStart?: Zahl; tokenEnd?: Zahl };
    Punktzahl?: Zahl;
    Metadaten: Record;
    ProviderPayload?: unbekannt;
  }>;
  RetrievalUsage: {
    Anbieter: string;
    queryCount: Zahl;
    resultCount: Zahl;
    billableUnits?: Zahl;
  };}

Dadurch kann die Generierungsschicht Kontext empfangen, ohne zu wissen, ob dieser aus OpenAI-Vektorspeichern, Pinecone, Weaviate, einem Datenbank-Volltextsuchindex oder einem internen Hybrid-Retriever stammt.

Die Mandantenisolierung beginnt vor der Vektorabfrage

Die Mandantenisolierung darf nicht von Eingabeaufforderungsanweisungen abhängen. Es muss vor dem Abruf an der Speicher- und Abfragegrenze erzwungen werden.

Für Systeme im Pinecone-Stil ist das dokumentierte Multitenancy-Muster ein Namespace pro Mandant in serverlosen Indizes. Datenebenenvorgänge zielen auf einen Namespace ab, was die Mandantenisolierung und das Offboarding vereinfacht, da durch das Löschen des Namespace die Datensätze dieses Mandanten entfernt werden. Pinecone dokumentiert auch Kompromisse zwischen Namespaces und Metadatenfilterung: Das Filtern innerhalb eines großen gemeinsam genutzten Namespace kann mehr Daten scannen, kostet mehr und ist langsamer als namespacebezogene Abfragen.

Bei Systemen im Weaviate-Stil speichert die Mehrmandantenfähigkeit jeden Mandanten auf einem separaten Shard, sodass die Daten eines Mandanten für einen anderen Mandanten nicht sichtbar sind. Beim Löschen des Mandanten wird der zugehörige Shard gelöscht. Weaviate unterstützt auch Mandantenzustände wie „aktiv“, „inaktiv“ und „ausgelagert“, wodurch eine Lebenszyklusoption für selten genutzte Mandanten entsteht.

Implementierungscheckliste

• Tenant_id aus der authentifizierten Gateway-Identität auflösen, nicht nur aus einem vom Benutzer bereitgestellten Textfeld.
• Mandanten_id über eine serverseitige Registrierung einem Vektor-Namespace, einem Shard oder einer Anbieter-Vektorspeicher-ID zuordnen.
• Anfragen ablehnen, wo Der API-Schlüssel-Mandant und der angeforderte Corpus-Mandant stimmen nicht überein.
• Halten Sie gemeinsam genutzte öffentliche Corpora von privaten Mandanten-Korpora getrennt.
• Verwenden Sie Metadatenfilterung für Dokumenttyp, Sprache, Produktbereich oder Datumsbereich, nachdem die Mandantengrenze bereits ausgewählt wurde.
• Protokollieren Sie Namespace, Shard, Corpus_ID, Retrieval_Profile und Retrieval_trace_id zur Überprüfbarkeit.

Reservieren Mandantenübergreifende Suche nach expliziten Verwaltungsabläufen mit separater Autorisierung, separaten Indizes oder kontrollierten Aggregationspfaden. Machen Sie die mandantenübergreifende Suche nicht zu einem zufälligen Nebeneffekt von Metadatenfiltern.

Zitate als Gateway-Objekte normalisieren

Zitate sind ein Produktvertrag, nicht nur Dekoration. Ein Kundensupport-Assistent, ein juristisches Redaktionstool oder ein interner Wissensassistent muss zeigen, warum eine Antwort erstellt wurde und woher der unterstützende Text stammt.

Das Gateway sollte Zitierdaten in sein eigenes Schema normalisieren:

{
  „source_id“: „doc_123“,
  „title“: „Erstattungsbedingungen“,
  „url_or_internal_ref“: „kb://refund-terms“,
  „chunk_id“: „chunk_006“,
  „offsets“: {“page“: 2, „byte_start“: 4410, „byte_end“: 5020},
  „Punktzahl“: 0,79,
  „retrieval_provider“: „weaviate“,
  „model_provider“: „anthropisch“,
  „model_provider_citation_payload“: {}

Halten Sie die normalisierten Felder stabil und erlauben Sie anbieterspezifische Erweiterungen. Einige Anbieter stellen ausführlichere Zitationsdetails zur Verfügung als andere. Einige zitieren Suchergebnisblöcke. Einige zitieren hochgeladene Dateien. Einige bieten nicht genau das Offset-Format, das Ihre Anwendung benötigt. Das Gateway sollte das Vorhandene bewahren, ohne so zu tun, als hätte jeder Anbieter die gleiche Zitiersemantik.

Strikter Zitiermodus

Wenn citation_required wahr ist, definieren Sie das Fehlerverhalten im Voraus. Ein strikter Modus kann erfordern, dass jeder sachliche Absatz mindestens ein Zitat enthält oder dass die endgültige Antwort Zitate aus abgerufenen Abschnitten über einem Mindestpunktzahlschwellenwert enthält. Wenn der ausgewählte Modellanbieter den Zitiervertrag nicht erfüllen kann, sollte das Gateway schnell ausfallen, einen kompatiblen Anbieter verwenden oder eine strukturierte Ablehnung zurückgeben.

Dies ist eine Empfehlung, keine universelle Regel. Der strikte Zitiermodus erhöht das Vertrauen, kann jedoch die Ablehnungen, Wiederholungsversuche und die Komplexität von Fallbacks erhöhen. Für kreative Arbeitsabläufe mit geringem Risiko können Zitate optional sein. Für kundenorientierten Support oder regulierte interne Arbeitsabläufe sollte citation_required oft Teil des Abrufprofils sein.

Index Lifecycle Is a Product Feature

RAG-Systeme sammeln Daten. Temporäre Uploads werden zufällig dauerhaft. Ehemalige Kunden hinterlassen Einbettungen. Produktteams ändern Chunking-Strategien und vergessen, alte Indizes neu zu erstellen.Ein Gateway sollte Lebenszykluskontrollen explizit machen.

Zu den empfohlenen Lebenszykluskontrollen gehören:

• Temporärer Korpusablauf: Für eine kurzlebige Sitzung hochgeladene Dokumente sollten einen Ablaufzeitstempel und einen Löschjob haben.
• Mandanten-Offboarding: Das Löschen eines Mandanten sollte das Löschen von Namespaces, Shards, Anbietervektorspeichern und zugehörigen Dateien in die Warteschlange stellen Objekte.
• Cold-Mandantenbehandlung: Wo unterstützt, können inaktive Mandanten als inaktiv markiert oder ausgelagert werden, um die Ressourcennutzung zu reduzieren.
• Versionskontrolle neu indizieren: Einbettungsmodell, Chunking-Richtlinie, Parser-Version und indexed_at für jeden Chunk speichern.
• Löschstatus-Offenlegung: Partner-API-Workflows sollten anzeigen, ob Dokumentlöschung, Vektorlöschung und anbieterseitige Löschung abgeschlossen.

Wichtig ist, dass einige Inhalte des Vektorspeichers bis zur Löschung erhalten bleiben. Die Architekturempfehlung besteht darin, das Löschen sichtbar und testbar zu machen, anstatt es in einem asynchronen Job ohne kundenorientierten Status zu vergraben.

Verfolgen Sie drei Kostenbücher

Ein einziges Token-Ledger reicht für RAG nicht aus. Ein Gateway benötigt mindestens drei Ledger:

• Einbettungs- und Indizierungskosten: Dokumentparsing, Chunking, Einbettungsaufrufe, Dateispeicherung, Indexschreibvorgänge und Neuindizierung.
• Abrufkosten: Lesen von Vektordatenbanken, native Vektorspeichersuche, Neuranking, Umschreiben von Abfragen und Ergebniserweiterung.
• Generierungskosten: Eingabetokens aus Benutzernachrichten und abgerufener Kontext, Ausgabetokens, Toolaufrufe, Wiederholungsversuche und Fallbacks.

Dies ist besonders wichtig für Agenturen, SaaS-Anbieter und interne Plattformteams, die KI-Kosten weiterverkaufen oder zuordnen. Ohne separate Hauptbücher sind die RAG-Margen schwer zu erklären. Ein Mandant mit kleiner Generationennutzung kann immer noch teuer sein, wenn er ständig Dokumente hochlädt, große Korpora neu indiziert oder umfassende Abrufabfragen ausführt.

Jedes Ledger-Ereignis sollte „manant_id“, „customer_id“, falls unterschiedlich, API-Schlüssel-ID, „retrieval_profile“, „corpus_id“, „model“, „provider“, „trace_id“ und abrechenbare Einheiten enthalten. Auf diese Weise können Nutzungsanalysen praktische Fragen beantworten: Welche Mandanten verfügen über teure Abrufprofile, welche Korpora sind veraltet, welche Modelle führen zu Zitierungsfehlern und welche Kunden generieren übergroße Eingabeaufforderungen, weil der Abruf zu viel Kontext zurückgibt.

Zu testende Fehlermodi

Ein Gateway-RAG-Subsystem sollte über Tests für die Fehlermodi verfügen, die für Kunden sichtbare Schäden verursachen:

• Fehlende Zitierungen: citation_required ist wahr, aber die Antwort des Anbieters enthält keine verwendbaren Zitatverweise.
• Veraltete Indizes: Ein Dokument wurde aktualisiert oder gelöscht, aber alte Blöcke erscheinen immer noch in den Abrufergebnissen.
• Mandantenkonflikt: Die Anfrage wird zu Mandant A aufgelöst, während der Korpus oder Namespace zu Mandant B gehört.
• Zu breiter Abruf: Das Profil gibt zu viele zurück Blöcke, was die Kosten erhöht und die Antwortqualität beeinträchtigt.
• Nichtübereinstimmung der Blockgröße: Blöcke sind so groß, dass Zitate ungenau sind, oder so klein, dass der Kontext ihre Bedeutung verliert.
• Nichtübereinstimmung der Anbieterfunktionen: Ein Modell kann Zitate in der erforderlichen Form ausgeben, während ein anderes dies nicht kann.
• Lebenszyklusfehler: Löschung wird angefordert, aber der anbieterseitige Speicher bleibt aktiv oder nicht überprüft.

Diese Tests sollten auf Gateway-Vertragsebene ausgeführt werden, nicht nur innerhalb eines Provider-Adapters. Ziel ist es zu beweisen, dass das öffentliche Verhalten stabil bleibt, wenn sich das Abruf-Backend oder der Generierungsanbieter ändert.

Kompromisse

Der Abruf nativer Anbieter kann Anwendungscode reduzieren und eine erste Version beschleunigen. Der Nachteil besteht darin, dass Speicherlebenszyklus, Zitierformat, Abfragesteuerung und Funktionsverfügbarkeit möglicherweise an einen Anbieter gebunden werden.

Externe Vektordatenbanken erweitern die Betriebsfläche. Der Vorteil ist eine stärkere Portabilität zwischen OpenAI-kompatiblen Modellen, Anthropic-Modellen und zukünftigen Anbietern. Sie machen es auch einfacher, bei mandantenweiten Namespaces oder Shards darüber nachzudenken, wann das Gateway für die Abrechnung und das Offboarding verantwortlich ist.

Feingranulare Blöcke verbessern die Zitiergenauigkeit und Überprüfbarkeit. Sie erhöhen außerdem die Indexgröße, das Abrufvolumen und die Komplexität der Eingabeaufforderungsassemblierung. Grobe Abschnitte sind einfacher, können aber zu Zitaten führen, die auf eine umfassende Seite oder einen Abschnitt verweisen und nicht auf die genaue unterstützende Passage.

Der strikte Zitiermodus erhöht das Vertrauen der Benutzer.Dadurch wird das Gateway auch gezwungen, Modelle zu verarbeiten, die nicht das erforderliche Zitierformat erzeugen können, was bedeuten kann, dass die Anfrage abgelehnt, Modelle geändert oder eine Antwort mit einem niedrigeren Konfidenzstatus zurückgegeben werden.

Vorhersage: Der Abruf wird nativer, aber Gateways benötigen weiterhin einen eigenen Vertrag

Anbieternative Abruffunktionen werden wahrscheinlich leistungsfähiger. Weitere Modelle akzeptieren den abgerufenen Kontext mit strukturierten Quellmetadaten. Weitere APIs stellen Ranking-Kontrollen, das Umschreiben von Abfragen und Zitiereinstellungen zur Verfügung. Dadurch entfällt jedoch nicht die Notwendigkeit eines Gateway-Vertrags.

Das Gateway verfügt weiterhin über die Mandantenidentität, Schlüsselverwaltung, Ausgabenlimits, Nutzungsanalysen, Partner-API-Workflows und kundenorientierte Löschversprechen. Anbieterfunktionen können hinter der Adapterschicht verwendet werden, aber das Produkt sollte nicht jeden Mandanten, jedes Modell und jeden Abrechnungsworkflow in die Abrufabstraktion eines Anbieters zwingen.

Umsetzbare Schlussfolgerung

Erstellen Sie mehrinstanzenfähiges RAG als Gateway-Subsystem mit expliziten Grenzen. Klären Sie die Mieteridentität vor dem Abruf. Verwenden Sie mandantenbezogene Namespaces, Shards oder Vektorspeicher. Bewahren Sie die Entnahme hinter den Adaptern auf. Normalisieren Sie Zitate in ein Gateway-eigenes Schema. Fügen Sie Lebenszyklusstatus und Löschüberprüfung hinzu. Verfolgen Sie die Einbettungs-, Abruf- und Generierungskosten separat.

Diese Architektur hält RAG auf dem Boden, ohne das Produkt an einen Abrufanbieter zu binden. Außerdem erhalten Teams die operativen Kontrollen, die sie benötigen, wenn ein KI-Assistent von einem Prototyp zu einem kundenorientierten System wechselt: Isolierung, Zitate, Portabilität, Lebenszyklusmanagement und Kostenzuordnung.

Verwandte Lektüre

• trace Abruf, Token-Nutzung und Mandantenanalyse in einem Observability-Modell
• anbieterspezifische Ausgaben hinter einem stabilen Gateway-Vertrag normalisieren
• Verbinden Sie die Mandantenbereitstellung und Nutzungsmessung mit Partner-API-Workflows