PROBLEMSTELLUNG ERKLÄRT AM BEISPIEL KI-GESTÜTZTER ANZEIGEN
Die Grundidee: ein Werbekunde bekommt einen Chatbot, der Besucherfragen direkt auf Basis der eigenen Webseite beantwortet – als interaktive Anzeige statt als statisches Banner. Die technische Kernfrage dahinter: Wie bringt man einer KI das Wissen einer ganzen Webseite bei, wenn diese Webseite hunderte Seiten groß ist? Zwei völlig verschiedene Wege sind möglich, mit sehr unterschiedlichen Konsequenzen bei Kosten und Zuverlässigkeit. Am Beispiel einer fiktiven, aber realistisch großen Klinik-Website erklärt und zum Selbst-Ausprobieren weiter unten.
Der Film zeigt beide Wege und erklärt, warum der einfachere von beiden ab einer bestimmten Datenmenge nicht langsam schlechter wird, sondern aufhört. Alles Weitere auf dieser Seite steht ausführlicher darunter.
TESTDATEN
Alle Inhalte in dieser Demo sind komplett fiktiv – Namen, Ärzt:innen, Adressen, Telefonnummern. Nichts davon ist real. Der Umfang dagegen ist bewusst realistisch gewählt, orientiert an der tatsächlichen Größenordnung eines großen Klinikums: 416 Einzelseiten – Fachbereiche, Ambulanzen, Kontaktdaten, Forschungsartikel.
Das ist wichtig, denn genau diese Größenordnung ist der Punkt der ganzen Demo: Eine kleine Firmenwebseite mit 20 Unterseiten passt locker komplett in eine einzelne KI-Anfrage – da braucht es kein RAG. Eine Klinik mit hunderten Fachbereichen, Ambulanzen und Forschungsseiten dagegen nicht. Ab einer bestimmten Größe wird der „einfache" Weg (alles auf einmal an die KI übergeben) technisch unmöglich – nicht nur teuer, sondern buchstäblich zu groß für das Zeitfenster, das ein KI-Modell auf einmal lesen kann. Das lässt sich weiter unten live nachvollziehen.
GRUNDIDEE
Man gibt der KI bei jeder einzelnen Frage einfach den kompletten Text aller Seiten mit – wie ein Prüfling, dem man vor jeder Prüfungsfrage das gesamte Lehrbuch nochmal komplett vorliest, bevor er antworten darf.
Einfach zu bauen, aber wird bei viel Text langsam, teuer – und irgendwann schlicht unmöglich, weil jedes KI-Modell nur eine begrenzte Textmenge auf einmal lesen kann.
Man baut vorab, einmalig eine durchsuchbare Bibliothek aus allen Seiteninhalten. Bei jeder Frage holt sich die KI dann nur die paar wirklich passenden Abschnitte aus dieser Bibliothek – wie ein Prüfling, der im Buch-Register nachschlägt und gezielt nur die richtige Seite aufschlägt.
Mehr Aufwand beim Aufbau, dafür bleibt es auch bei riesigen Datenmengen schnell und günstig – skaliert praktisch unbegrenzt.
TECHNISCHER WORKFLOW
Das ist der wichtigste Punkt, um RAG zu verstehen: Es sind zwei komplett getrennte Vorgänge, die zu unterschiedlichen Zeitpunkten laufen.
Oben: die Bibliothek wird selten und geplant neu gebaut. Unten: bei jeder Frage läuft nur noch die schnelle, günstige Suche bzw. beim Full-Context-Weg die komplette Text-Übergabe.
WARUM NICHT LIVE, JEDE MINUTE?
Naheliegender Gedanke: Warum nicht die Bibliothek bei jeder Frage direkt neu bauen, damit sie garantiert aktuell ist? Weil das unnötig teuer und langsam wäre. Der Bibliotheksbau (oben im Diagramm) bedeutet: alle 416 Seiten lesen, bereinigen, in Abschnitte teilen und in Zahlen übersetzen – das dauert mehrere Minuten Rechenzeit. Eine Klinik-Webseite ändert sich aber nicht minütlich, meist nicht mal täglich. Ein Rhythmus von einmal täglich oder sogar nur einmal pro Woche reicht in der Praxis völlig aus, um die Bibliothek aktuell zu halten.
Die eigentliche Anfrage eines Besuchers (unten im Diagramm) ist davon komplett getrennt und läuft in Sekunden – sie schlägt nur in der bereits fertigen Bibliothek nach, statt jedes Mal alles neu zu berechnen. Genau diese Trennung – selten und aufwändig bauen, aber oft und günstig benutzen – ist der eigentliche Kostenvorteil von RAG gegenüber Full-Context.
VOR- UND NACHTEILE
| Kriterium | Full-Context | RAG |
|---|---|---|
| Aufbau-Aufwand | Sehr gering — Text einfach mitschicken | Höher — Vektor-Datenbank, Chunking, Embedding-Pipeline nötig |
| Läuft bei kleiner Datenmenge | Problemlos, sehr einfach | Funktioniert, ist aber unnötiger Mehraufwand |
| Läuft bei großer Datenmenge | Wird langsam & teuer, irgendwann technisch unmöglich | Bleibt schnell & günstig, praktisch unbegrenzt skalierbar |
| Kosten pro Anfrage | Wächst mit der Gesamt-Datenmenge | Bleibt konstant niedrig, unabhängig von der Gesamtgröße |
| Aktualität | Sofort aktuell, sobald der Text sich ändert | Nur so aktuell wie der letzte Bibliotheksbau (z. B. gestern) |
| Typische Schwachstelle | Harter Abbruch bei Überschreiten des Kontextlimits | Kann bei ungünstiger Frage-Formulierung die richtige Antwort verfehlen |
| Fazit | Gut für kleine, selten wechselnde Datenmengen | Nötig, sobald die Datenmenge wächst |
KOSTEN, KONKRET
Zahlen aus dieser Demo (Claude Haiku 4.5, 1 Mio. Ein-/Ausgabe-Tokens kosten 1 $ bzw. 5 $). Grobe Faustregel: 1.000 Zeichen deutscher Text ≈ 250–300 „Tokens" (die Recheneinheit, in der KI-Anfragen abgerechnet werden).
| Ansatz & Datenmenge | Kontext pro Anfrage | Geschätzte Kosten pro Anfrage |
|---|---|---|
| RAG (jede Datenmenge) | ~2.000–3.000 Tokens | < 0,5 Cent |
| Full-Context, kleine Seite (22 Seiten) | ~11.000 Tokens | ca. 1,3 Cent |
| Full-Context, mittlere Seite (220 Seiten) | ~70.000 Tokens | ca. 7 Cent |
| Full-Context, große Klinik-Seite (416 Seiten) | ~408.000 Tokens | nicht möglich — über dem Limit |
Der Bibliotheksbau selbst (Embedding aller 416 Seiten) läuft in dieser Demo über ein selbst gehostetes Modell auf dem ohnehin vorhandenen Server — dafür fallen keine zusätzlichen API-Kosten an, nur ein paar Minuten Rechenzeit, ein- bis wenige Male pro Woche. Bei einem bezahlten Embedding-Dienst kämen hier zusätzlich geringe, aber planbare Kosten pro Bibliotheksbau dazu (nicht pro Anfrage).
Kurz gesagt: Bei kleinen Webseiten ist der Unterschied kaum spürbar. Bei einer Datenmenge wie einer großen Klinik-Website wird Full-Context nicht nur teurer, sondern ab einem bestimmten Punkt schlicht unbenutzbar — RAG bleibt dagegen durchgehend günstig und funktioniert unabhängig von der Datenmenge.
JETZT SELBST AUSPROBIEREN
Echte Anfragen gegen die echte Musterklinik-Wissensbasis, in Echtzeit, beide Wege gleichzeitig. Jede Anfrage verursacht echte Kosten – deshalb ist der Live-Test nur mit einem persönlichen Zugangscode nutzbar.
Hinweis zu eigenen Fragen: Die fünf Beispiele unten sind bewusst ausgewählt, weil sie einen bestimmten Effekt sichtbar machen. Frei gestellte Fragen scheitern dagegen häufig – eine eigene Messung mit 103 Fragen ergab, dass rund zwei Drittel mit „kann ich nicht beantworten“ endeten. Zwei Gründe: Der Beispieldatensatz enthält nur einen Teil der ursprünglichen Website, und die enthaltenen Nachrichtenmeldungen verdrängen bei der Suche die eigentlichen Sachinformationen. Beides ist typisch für RAG in der Praxis und gehört zu dem, was diese Demo zeigen soll.
Zugangscode
Kein Selbst-Service: Der Zugang zu diesem Live-Test wird nur auf Anfrage und nach persönlicher Freigabe vergeben.
Unten stehen fünf geprüfte Testfragen, die jeweils gezielt eine typische Schwachstelle zeigen – oder einfach eine eigene Frage eintippen.
Eigene Frage