RAG ohne Vektor-Datenbank für den Kanzlei-Bot

Würdigung — die Lehrbuch-Architektur ist richtig, nur nicht immer nötig#

Die klassische RAG-Architektur löst ein echtes Problem. Wenn ein Bot aus zehntausend Dokumenten antworten soll, kann man nicht alle zehntausend bei jeder Frage an das Sprachmodell schicken — das Kontextfenster reicht nicht, und es wäre absurd teuer. Stattdessen werden die Dokumente in EmbeddingsEmbeddings · zum GlossarNumerische Repräsentation von Text — ähnliche Texte haben ähnliche Zahlen-Vektoren. umgewandelt, in einer Vektor-Datenbank abgelegt, und bei jeder Frage werden nur die paar ähnlichsten Ausschnitte herausgesucht und mitgeschickt. Der Insight zu den RAG-Grundlagen erklärt diesen Mechanismus im Detail.

Diese Architektur ist sauber und für große Wissensbestände alternativlos. Aber sie hat einen Preis: eine Vektor-Datenbank, die betrieben werden will, ein Embedding-Modell, ein Retrieval-Schritt, der gut genug treffen muss, und eine Fehlerquelle mehr in der Kette. Für einen Bot, dessen gesamtes Wissen auf ein paar Seiten passt, ist das wie ein Lastenaufzug für einen Aktenordner.

Wie viel Wissen hat ein Kanzlei-Bot wirklich?#

Der entscheidende Punkt wird oft übersprungen: Wie groß ist der Wissensbestand überhaupt, aus dem der Bot antworten soll? Bei einer Kanzlei ist das in aller Regel überschaubar — die häufigsten Fragen und ihre Antworten, das Leistungs- und Preisgefüge, die Themen-Übersicht der eigenen Inhalte. Das sind keine zehntausend Dokumente, sondern eine Handvoll gepflegter Datenquellen.

Genau das ist bei unserem Concierge der Fall. Sein Wissen besteht aus drei gepflegten Quellen: den häufigen Fragen samt Antworten, den Leistungspaketen, und den Metadaten unserer Insight-Artikel — also Titel, Kurzbeschreibung und Adresse jedes Artikels. Die vollständigen Artikeltexte werden bewusst nicht mitgegeben; das würde das Budget sprengen und bringt für den Zweck nichts. Der Bot soll den passenden Artikel finden und verlinken, nicht ihn auswendig zitieren — für die Tiefe führt er ins Erstgespräch oder zum Artikel selbst.

Context-Stuffing: das ganze Wissen in den System-Prompt#

Wenn der Wissensbestand klein genug ist, um vollständig ins Kontextfenster zu passen, braucht es kein Retrieval. Man schickt einfach das gesamte Wissen bei jeder Anfrage mit — als festen Block im System-Prompt. Das Sprachmodell hat damit bei jeder Frage alles vor sich und sucht sich die passende Stelle selbst heraus. Der Retrieval-Schritt entfällt, die Vektor-Datenbank entfällt, das Embedding-Modell entfällt. Eine ganze Fehlerquelle fällt weg: Ein schlecht treffender Retrieval-Schritt, der die relevante Stelle gar nicht erst findet, kann nicht passieren, wenn ohnehin alles da ist.

Der naheliegende Einwand: Ist das nicht teuer, bei jeder Frage das ganze Wissen mitzuschicken? Hier kommt das Prompt-Caching ins Spiel. Der feste Wissensblock wird beim Anbieter zwischengespeichert und muss nicht bei jeder Anfrage neu verarbeitet werden — nur die eigentliche Frage des Nutzers kommt frisch dazu. Damit wird der wiederkehrende Wissensblock pro Anfrage sehr günstig. Das ist der Hebel, der Context-Stuffing für einen kleinen, stabilen Wissensbestand wirtschaftlich macht.

Bei unserem Concierge läuft genau das: Der zusammengebaute Wissensblock geht als zwischenspeicherbarer Teil des System-Prompts an ein kompaktes, schnelles Modell. Wie der Bot insgesamt aufgebaut ist — mit Verbots-Logik, Kennzeichnung und Eskalation — zeigt der Insight zum grounded-only Concierge.

Was günstiger und was teurer wird#

Ehrlich gegenübergestellt: Context-Stuffing tauscht eine Art von Kosten gegen eine andere. Es spart die gesamte Retrieval-Infrastruktur — keine Vektor-Datenbank, kein Embedding-Lauf bei jeder Wissens-Änderung, kein Tuning des Retrieval-Schritts. Dafür schickt es bei jeder Anfrage mehr Text mit, was ohne Caching teuer wäre und mit Caching günstig wird.

Diese Rechnung kippt mit der Größe des Wissens. Solange alles ins Kontextfenster passt und stabil genug ist, dass sich Caching lohnt, gewinnt Context-Stuffing durch Einfachheit. Wächst das Wissen über das Kontextfenster hinaus — oder ändert es sich so schnell, dass der Cache ständig verfällt —, gewinnt irgendwann das klassische RAG mit Retrieval. Die Architektur-Wahl ist also keine Glaubensfrage, sondern eine Funktion der Wissensgröße. Derselbe nüchterne Blick auf „lokal oder Cloud, klein oder groß" steckt im Insight zum lokalen LLM gegen Cloud-API.

Der Kipppunkt — woran man ihn erkennt#

Drei Signale zeigen, dass Context-Stuffing an seine Grenze kommt und echtes Retrieval ansteht. Erstens: Das Wissen passt nicht mehr zuverlässig ins Kontextfenster, weil es zu umfangreich geworden ist. Zweitens: Das Wissen ändert sich so oft, dass der Cache kaum noch greift und der Kostenvorteil schwindet. Drittens: Das Modell findet in einem zu großen Block die relevante Stelle nicht mehr zuverlässig — dann hilft ein gezielter Retrieval-Schritt, der nur die passenden Ausschnitte vorlegt.

Solange keines dieser Signale auftritt, ist die einfachere Architektur nicht nur ausreichend, sondern überlegen: weniger Teile, die kaputtgehen können, weniger zu betreiben, weniger zu erklären. Diese Disziplin — die einfachste Lösung bauen, die das Problem löst, und Komplexität erst hinzufügen, wenn sie ihren Platz verdient — entscheidet, wie ein KI-Bot über Jahre wartbar bleibt, statt zur Black Box zu werden.

Was Kanzleien davon haben#

• Weniger Maschinerie, weniger Risiko: Ohne Vektor-Datenbank und Retrieval-Schritt gibt es weniger Teile, die ausfallen oder daneben treffen können.
• Vorhersehbare Kosten: Prompt-Caching macht einen kleinen, stabilen Wissensbestand pro Anfrage günstig — ohne laufende Datenbank-Infrastruktur.
• Schnell startklar: Ein Bot über gepflegte FAQ und Leistungsdaten ist deutlich schneller gebaut als eine vollständige Retrieval-Pipeline.
• Saubere Ausbaustufe: Wächst das Wissen, ist der Umstieg auf echtes Retrieval ein klarer, geplanter Schritt — kein Neubau.

Für eine nüchterne Einordnung, welche Bot-Architektur zu Ihrem Wissensumfang passt, empfehlen wir den Hebel-Audit (890 €, bei Mandanten-Boost-Beauftragung innerhalb von 60 Tagen voll anrechenbar) oder ein Gespräch in der KI-Werkstatt.

Zusammenfassung#

Klassisches RAG mit Vektor-Datenbank, Embeddings und Retrieval-Schritt ist für große Wissensbestände richtig — aber für einen Kanzlei-Bot mit überschaubarem, gepflegtem Wissen oft mehr Maschinerie, als der Zweck rechtfertigt. Passt das gesamte Wissen ins Kontextfenster, ist Context-Stuffing die schlichtere und meist bessere Wahl: Das ganze Wissen geht als fester Block in den System-Prompt, das Modell sucht die passende Stelle selbst, und Prompt-Caching macht den wiederkehrenden Block pro Anfrage günstig. Eine ganze Fehlerquelle — der schlecht treffende Retrieval-Schritt — fällt damit weg. Genau so arbeitet unser Concierge: grounded-only, ohne Vektor-Datenbank, aus FAQ, Leistungsdaten und Artikel-Metadaten. Der Umstieg auf echtes Retrieval ist ein geplanter Schritt für später — wenn das Wissen das Kontextfenster sprengt, sich zu schnell ändert oder zu groß wird, um zuverlässig durchsucht zu werden.

Quellen#

• Anthropic — Building effective agents — abgerufen 2026-06-13
• Anthropic — Tests entwickeln und auswerten — abgerufen 2026-06-13

Disclaimer: Allgemeine fachliche Information zum Zeitpunkt der Veröffentlichung, keine Rechtsberatung. Die beschriebene Architektur bildet den Stand des FA²-Concierge zum Veröffentlichungszeitpunkt ab; die richtige Wahl zwischen Context-Stuffing und Retrieval hängt vom konkreten Wissensumfang ab.