Was ein RAG-System laufend kostet: Ingestion, Vektordatenbank und Datenpflege
Kurz gesagt
Retrieval Augmented Generation verursacht Kosten vor und während jeder Anfrage — Parsing, Chunking, Embeddings, Vektorspeicher, Abfragen, gegebenenfalls Re-Ranking und laufende Datenpflege. Die reine Embedding-Berechnung ist meist der günstigste Teil; teuer werden häufige Aktualisierungen großer Dokumentbestände, Mindestgebühren von Vektordatenbanken und die Personalzeit für Datenbereinigung.
RAG ist eine Datenpipeline, kein einzelner Kostenpunkt
Ein verbreiteter Irrtum ist, RAG-Kosten allein an der Embedding-Berechnung festzumachen. Tatsächlich ist RAG eine vollständige Pipeline: Dokumente werden aufbereitet (Ingestion), in Abschnitte zerlegt (Chunking), in Vektoren umgewandelt (Embeddings), in einer Vektordatenbank gespeichert und bei jeder Anfrage durchsucht (Retrieval). Häufig folgt ein zusätzlicher Sortierschritt (Re-Ranking), bevor die gefundenen Textausschnitte als Kontext an das Sprachmodell übergeben werden. Auch Neuindizierung und das Löschen veralteter Inhalte gehören zur Pipeline — wer nur die Embedding-Rechnung betrachtet, unterschätzt den Betrieb systematisch.
Warum Embeddings günstig sind, Reindexierung aber nicht
Bei textbasiertem RAG sind Embeddings in aller Regel der günstigste Teil der Rechnung. Das Problem entsteht an anderer Stelle: Große Dokumentbestände, häufige Aktualisierungen, mehrere parallel genutzte Embedding-Modelle oder ein Wechsel der Vektordimension können wiederholte Vollindizierungen auslösen. Der Datenlebenszyklus muss deshalb von Anfang an als Pipeline geplant werden — mit Delta-Ingestion für geänderte Dokumente, Prüfsummen zur Erkennung von Duplikaten, Versionierung und einer klaren Löschregel für veraltete Einträge. Ohne diese Mechanik wird bei jeder Änderung der gesamte Bestand neu verarbeitet, was Kosten und Wartezeit unnötig erhöht.
Vektordatenbanken haben eine Grundlast
Verwaltete Vektordatenbanken rechnen nicht ausschließlich nach Suchanfragen ab. Je nach Anbieter kommen Kapazität, Speicherplatz, Lese- und Schreibeinheiten, Replikate oder Mindestpakete hinzu. Gerade kleinere Projekte werden dadurch stärker von diesen Mindestkosten geprägt als vom tatsächlichen Suchvolumen — ein Projekt mit wenigen Nutzeranfragen zahlt unter Umständen trotzdem die volle Grundgebühr der gewählten Plattform. Bei der Auswahl lohnt sich deshalb ein Kostenrechner mit der realen Anzahl an Vektoren, der gewählten Dimension, der erwarteten Anfragerate und der Replikationsstufe — nicht die Kalkulation auf Basis der kostenlosen Teststufe, die keine belastbare Grundlage für den Produktivbetrieb ist.
Chunking und Re-Ranking beeinflussen Qualität und Rechnung gleichzeitig
Die Größe der Textabschnitte (Chunks), in die Dokumente zerlegt werden, wirkt sich doppelt aus: Kleine Chunks erhöhen die Anzahl der gespeicherten Einheiten und der zugehörigen Metadaten, große Chunks übertragen mehr womöglich irrelevanten Text in den teuren Modellkontext. Eine bewusst gewählte Überlappung zwischen benachbarten Chunks bewahrt zwar Zusammenhang, vervielfacht aber gespeicherte und eingebettete Textmenge. Die richtige Einstellung lässt sich nur anhand echter Fragen, echter Treffer und gemessener Kosten finden, nicht durch pauschale Annahmen.
Ein zusätzlicher Ranking-Schritt (Re-Ranking) kostet selbst Rechenleistung, kann aber die Anzahl der an das teure Generierungsmodell gesendeten Textpassagen deutlich reduzieren. Wirtschaftlich ist diese Kombination dann, wenn der eingesparte Modellkontext und die bessere Trefferqualität die Kosten des Re-Rankers übersteigen.
Mehr Kontext ist nicht automatisch mehr Qualität
Auch mit sehr großen Kontextfenstern moderner Modelle bleibt Retrieval relevant: Forschung zu langen Kontexten zeigt, dass relevante Information je nach Position im Text schlechter genutzt werden kann. Eine große Kontextgrenze ersetzt deshalb keine durchdachte Auswahl- und Anordnungslogik der Suchergebnisse. Ungefilterter, zu umfangreicher Kontext kann gleichzeitig Kosten und Fehlerrisiko erhöhen — mehr Daten in den Prompt zu geben ist kein Ersatz für eine gute Retrieval-Strategie.
Datenbereinigung ist eine Personalposition, keine Nebensache
Duplikate, veraltete Dateien, schlecht eingescannte Dokumente, unklare Nutzungsrechte und uneinheitliche Metadaten erhöhen die Zahl der Fehlantworten und den Nacharbeitsaufwand deutlich. Dieser Aufwand fällt außerhalb der reinen API-Rechnung an, gehört aber genauso in die Kalkulation wie Aufbau- und laufende Pflegekosten. Bei einem größeren Indexaufbau kann die Datenbereinigung durch Fachpersonal den größten einzelnen Kostenblock darstellen — deutlich vor der eigentlichen Modell- oder Embeddingrechnung.
Was das für die Planung eines RAG-Projekts bedeutet
Vor dem Aufbau eines RAG-Systems lohnt sich eine ehrliche Bestandsaufnahme: Wie viele Dokumente gibt es, wie oft ändern sie sich, wie sauber sind Rechte und Metadaten bereits heute, und wie viel Personalzeit steht für die Datenpflege zur Verfügung? Ein RAG-System mit wenigen hundert stabilen Dokumenten verursacht eine grundlegend andere Kostenstruktur als ein System, das täglich tausende neue oder geänderte Dateien verarbeiten muss.