Die versteckten Kosten von RAG: Re-Embedding, Hosting und Token-Rechnungen

Das Versprechen vs. die Rechnung

Das Versprechen von Cloud-RAG ist einfach: Dokumente hochladen, Fragen stellen, Antworten bekommen. Die betriebliche Realität ist unordentlicher. Drei Kostenstellen werden in Hersteller-Dokumentation, Konferenzvorträgen und den ersten begeisterten Blogposts durchweg untertrieben. Sie tauchen später auf: in Infrastruktur-Rechnungen, in Entwicklungsstunden, in API-Kosten, die schneller wachsen als der Wert des Projekts.

Kostenstelle 1: die Vektordatenbank hosten

Jede RAG-Pipeline braucht einen Ort, an dem sie Vektoren speichert. In einem selbst-gehosteten Setup heißt das, eine Instanz von Chroma, Weaviate, Milvus oder Qdrant zu betreiben: einen Server oder Cluster, persistenten Speicher, Backups, Uptime-Monitoring und jemanden, der weiß, wie man das Ding aktualisiert, wenn sich das Schema ändert.

In einem Managed-Cloud-Setup wird typischerweise pro gespeichertem Vektor, pro Anfrage oder pro Indexgröße abgerechnet. Die kostenlose Stufe verschwindet, sobald der Index über den Proof-of-Concept-Maßstab hinauswächst.

Beide Wege tragen laufende Kosten: Geld für den Managed-Dienst oder Entwicklungszeit für die selbst-gehostete Variante. Anders als eine Datenbank, die deine Quelle der Wahrheit hält, hält ein Vektor-Index eine abgeleitete Repräsentation davon. Ändert sich die Quelle, muss sich der Index mit ändern. Die Hosting-Kosten verschwinden nicht, wenn sich das Projekt stabilisiert. Sie summieren sich.

Kostenstelle 2: Re-Embedding bei jeder Dokumentänderung

Ein Vektor-Index ist eine Momentaufnahme. Sobald sich ein Quelldokument ändert (eine aktualisierte Richtlinie, eine überarbeitete Produktspezifikation, eine korrigierte Klausel), müssen die betroffenen Abschnitte neu zerlegt, neu eingebettet und neu in den Index geschrieben werden.

Das erzeugt eine Wartungspflicht. In der Praxis bedeutet das eine geplante Pipeline: geänderte Dokumente erkennen, neu verarbeiten, die Updates einspielen. Ein verpasster Durchlauf erzeugt stille Veralterung: Der Index beantwortet Anfragen mit der alten Version eines Dokuments, während die Quelle etwas anderes sagt. Die meisten Setups haben keine eingebaute Drift-Warnung. Du entdeckst das Problem erst, wenn das Modell eine selbstbewusst falsche Antwort gibt.

Die Re-Embedding-Kosten summieren sich über die Zeit. Jeder einzelne Embedding-API-Aufruf oder lokale GPU-Zyklus ist klein. Für eine lebendige Wissensbasis (aktiv gepflegte Dokumentation, Richtlinien, die sich nach regulatorischen Fristen ändern, häufig wechselnde Produktinhalte) ist die kumulierte Re-Embedding-Last nicht trivial, sowohl in Rechenleistung als auch in der Entwicklungszeit, die nötig ist, um die Pipeline zuverlässig zu halten.

Kostenstelle 3: Tokens, bei jeder Frage erneut gesendet

Ein Vektor-Retrieval-System schickt die abgerufenen Abschnitte bei jeder Anfrage an das Sprachmodell. Die Größe dieser Abschnitte multipliziert sich direkt mit dem Anfragevolumen. Selbst mit Deduplizierung wird derselbe Hintergrundkontext immer wieder neu verpackt und übertragen.

Für eine abgegrenzte Wissensbasis (eine Produkt-FAQ, eine technische Spezifikation, ein Dokumentensatz, der eine definierte Klasse von Fragen beantwortet) ist das meiste davon redundant. Der relevante Hintergrund bleibt weitgehend gleich, nur die Frage ändert sich. Jede Anfrage zahlt die Token-Kosten dafür, Kontext erneut zu liefern, den das Modell nicht erneut empfangen müsste.

Bei niedrigen Anfragevolumen ist das unsichtbar. Im Produktivmaßstab (Hunderte Anfragen pro Tag, jede mit mehreren Abschnitten von einigen Hundert Tokens) wird die Token-Rechnung zu einer spürbaren wiederkehrenden Ausgabe. Genau diese Kosten unterschätzen RAG-Architekturen häufig, wenn sie die Produktionskosten hochrechnen.

Was der OKF-Ansatz beseitigt

Grep über ein strukturiertes OKF-Bundle eliminiert alle drei Kostenstellen.

Keine Datenbank zu hosten. Ein OKF-Bundle ist ein Verzeichnis aus einfachen Markdown-Dateien. Es liegt auf einem Dateisystem. Ein Agent liest es mit normalem Datei-I/O. Kein Datenbankprozess, kein Managed-Dienst, kein Index zum Sichern oder Migrieren.

Kein Re-Embedding bei Änderungen. Ändert sich eine Konzeptdatei, dann ändert sie sich. Der Agent liest die aktuelle Version bei der nächsten Anfrage. Es gibt keine Pipeline auszulösen, keinen Re-Indexing-Job zu planen, keine Synchronisation zu prüfen.

Weniger Tokens pro Anfrage. Ein Agent, der ein OKF-Bundle durchsucht, liest nur die Konzeptdateien, die die Frage tatsächlich braucht: typischerweise eine kleine Zahl fokussierter Dateien, nicht einen festen Abschnitts-Dump der ganzen Wissensbasis. Für ein abgegrenztes, strukturiertes Korpus ist das Navigieren über Überschrift und Dateiname deutlich token-effizienter als Top-k-Retrieval.

Der Ansatz tauscht etwas Reales ein: In sehr großem Maßstab (viele Tausend heterogene, unstrukturierte Dokumente) kostet das Navigieren über Dateiname und Überschrift mehr Rechenleistung als ein vorgebauter Ähnlichkeitsindex. Dieser Kompromiss ist echt und sollte verstanden werden. Für eine abgegrenzte Wissensbasis greift er selten.

Eine andere Architektur, keine Abkürzung

Die drei versteckten Kosten von RAG sind keine unvermeidlichen Eigenschaften KI-gestützter Dokumentensuche. Sie sind der Preis einer bestimmten architektonischen Entscheidung: Inhalte vorab in eine undurchsichtige numerische Repräsentation zu indexieren, die in einer dedizierten Datenbank liegt.

Eine andere Architektur (strukturierte Klartext-Konzeptdateien, die ein Agent direkt navigiert) beseitigt sie von vornherein. Die Wahl geht nicht darum, Arbeit zu vermeiden. Sie geht darum, wo die Arbeit getan wird und wer sie über die Zeit bezahlt.

pdf2okf wandelt PDFs in OKF-kompatible Bundles um: strukturierte Markdown-Konzeptdateien, die jeder Agent direkt lesen kann. Keine Embedding-Pipeline zu betreiben, keine Vektordatenbank bereitzustellen, kein Re-Indexing-Job zu pflegen. Das umgewandelte Wissen bleibt schlank, lesbar und frei von Infrastruktur-Ballast. Die drei Kosten, die einem RAG-Deployment sonst folgen, erscheinen schlicht nicht auf der Rechnung.