Context is King

Der Newsletter für technische Entscheider, Business-Strategen und KI-Interessierte.

Heute auf der Setlist: Warum „Context is King" keine einfache Phrase ist, sondern eine der teuersten Lektionen, die Unternehmen 2026 gerade lernen müssen.

🎚️ Soundcheck

Die meisten KI-Projekte scheitern nicht am Modell. Sie scheitern an dem, was das Modell nicht weiß.

Ein Sprachmodell ist brillant darin, Sprache zu erzeugen, aber es kennt weder den letzten Quartalsbericht noch die interne, kaum auffindbare Richtlinie von vorgestern noch den Vertrag, der gestern unterschrieben wurde. Sein Wissen ist eingefroren auf den Tag, an dem das Training endete. Fragt man es trotzdem, erfindet es eine plausibel klingende Antwort. Das nennt man Halluzination, und gerade im Unternehmenskontext ist sie nicht sonderlich charmant, sondern durchaus haftungsrelevant.

Die Lösung dafür hat einen sperrigen Namen und eine einfache Idee: Retrieval Augmented Generation, kurz RAG. Genau darum geht es hier & heute im ersten Rag'n'Roll Newsletter!🤘

🎤 Main Set: RAG in drei Sätzen & in drei Ebenen

Was ist RAG?

RAG koppelt ein Sprachmodell an eine externe Wissensquelle. Bevor das Modell antwortet, sucht ein Retrieval-System die relevanten Stellen aus Dokumenten, Datenbanken oder Wissensbeständen heraus und legt sie dem Modell als Kontext vor. Das Modell antwortet dann auf Basis dieser Belege, also nicht aus dem Gedächtnis, sondern aus den relevanten Quellen.

Der Effekt: aktuelle, nachprüfbare, zitierbare Antworten statt selbstbewusster Erfindungen. Und das Beste: Das Modell muss nicht extra trainiert werden, wenn sich das zugrundeliegende Wissen ändert. Neues Dokument rein & fertig.

Wofür braucht man das im Unternehmen?

Überall dort, wo die Antwort in internen Daten steckt (und nicht im allgemeinen Internet):

• Der Support-Mitarbeiter, der in Sekunden die richtige Klausel aus 400 Seiten Handbuch braucht.
• Die Fachabteilung, die „Was steht in unserer aktuellen Reiserichtlinie?" fragt und die aktuelle meint, nicht die von vor ein paar Jahren.
• Der Analyst, der quer über mehrere Quartalsberichte fragt: „Welche Themen tauchen im Kundenfeedback dieses Quartals immer wieder auf?"

Der gemeinsame Nenner: präzise, berechtigungsbewusste, belegbare Antworten aus internem Wissen. Genau das, was ein reines Sprachmodell nicht leisten kann.

Und was ist State of the Art?

Hier wird es interessant, denn RAG-Methoden von 2024 und von 2026 sind kaum noch dasselbe.

Das Ende von „Naive RAG." Die erste Generation war simpel:

• Dokumente in eine Vektor-Datenbank kippen (Wörter werden mathematisch vergleichbar gemacht)
• per Ähnlichkeitssuche (mathematisch gesehen & auf Basis des Embedding-Modell-Trainings) die passendsten Schnipsel ziehen
• ins Modell geben (hier dann die tatsächlichen Textschnipsel aus den Dokumenten, nicht die mathematischen Repräsentationen aus der Vektordatenbank)
• fertig

Das funktionierte halbwegs. Der typische Fehler: Der Retriever (also das, was die Vektordatenbank durchsucht & danach die echten Textschnipsel an die KI übergibt) zieht drei irrelevante Absätze heran und übersieht genau den einen entscheidenden Satz, der in einer Tabelle versteckt war. 2026 gilt dieser Ansatz als Prototyp, nicht als Produktionssystem.

Der Engpass hat sich verschoben. Die Modelle sind inzwischen hochintelligent, also ist die „Generation" selten das Problem. Das Problem ist fast immer das Retrieval. Wer schlechtes Naive RAG implementiert hat, hat in 90 % der Fälle kein Generierungs-, sondern ein Retrieval-Problem. Deshalb dreht sich der State of the Art heute fast vollständig um die Frage: Wie holen wir den richtigen Kontext zur richtigen Zeit?

Die Antworten der aktuellen Generation:

• Hybride Suche + Reranking: Lexikalische und semantische Suche kombiniert, danach ein Modell, das die Treffer noch einmal nach Relevanz sortiert.
• Query-Strategien: Die ursprüngliche Frage wird umformuliert, in Teilfragen zerlegt oder in eine hypothetische Musterantwort übersetzt, bevor überhaupt gesucht wird. Denn eine einzelne Nutzerfrage ist oft mehrdeutig.
• GraphRAG: Statt nur lose Textschnipsel zu suchen, wird ein Wissensgraph aufgebaut. Das beantwortet die „großen" Fragen, die Verbindungen verschiedener Dokumente & Paragraphen zugrunde legen. Das kann reine Ähnlichkeitssuche nicht, es gilt also: Vektorsuche für Präzision, GraphRAG für den Überblick. Zusammen decken sie den Großteil betrieblicher Wissensfragen ab.
• Self-RAG & Corrective RAG: Das System bewertet seine eigenen Treffer. Ist die Beleglage dünn, fragt es erneut nach, statt zu raten. In regulierten Bereichen senkt das Halluzinationen oft drastisch.

Und über all dem steht der Begriff, der gerade die ganze Branche prägt: Agentic RAG.

🥁 Track 2: Warum RAG das Herz agentischer Systeme ist

Bisher war RAG eine starre Pipeline: Frage rein → Suche → Kontext einfügen → Antwort. Es gibt also nur einen Such-Versuch & das Ergebnis steht.

Agentic RAG dreht das um. Hier steuert ein Agent das Retrieval selbst: Er zerlegt die Aufgabe, wählt Suchstrategien, formuliert um, wenn die Treffer schwach sind, und iteriert so lange, bis er sich sicher ist, dass die Ergebnisse stimmen beziehungsweise plausibel sind. Aus „einmal suchen" wird „recherchieren, prüfen, nachhaken". Dieses Muster ist 2026 zum dominanten Ansatz für RAG in Unternehmens-KI Projekten geworden.

Der Grund, warum das so entscheidend ist: Ein Agent trifft nicht nur eine, sondern eine ganze Kette an Entscheidungen. In typischen Workflows kommen oft rund 20 autonome Schritte zum Einsatz, bevor ein Mensch eingreift. Und Fehler in solchen Ketten potenzieren sich. Wenn Schritt 3 auf falschem Kontext aufsetzt, ist alles danach kontaminiert. Der Agent ist also nur so gut wie der Kontext, den er bei jedem einzelnen Schritt bekommt.

Das ist also mit „Context is King" gemeint: Die Modelle sind längst kein Problem mehr. Der Wettbewerbsvorteil liegt nicht mehr darin, das schlauste Modell im Einsatz zu haben (und damit nebenbei gemerkt Unsummen an KI-Kosten zu häufen), sondern darin, ihm zur richtigen Zeit das richtige Wissen vorzulegen. Genau diese Disziplin hat inzwischen einen eigenen Namen bekommen: Context Engineering. RAG ist ihr Maschinenraum.

🎯 Encore: Der eine Gedanke für Entscheider

Es gibt ein verlockendes Gegenargument, das das nächste KI-Projekt doch sehr einfach machen sollte: „Die Kontextfenster der Modelle werden riesig! Kippen wir doch einfach alles rein, dann brauchen wir kein RAG mehr." Klingt bequem, ist es aber nicht. Riesige Kontextfenster treiben Kosten und Governance-Risiko extrem nach oben und sie lösen das eigentliche Problem nicht: Welche Information darf dieser Nutzer überhaupt sehen, ist sie aktuell, und woher stammt sie?

Genau deshalb bleibt RAG das Fundament für präzise, berechtigungsbewusste und kostenkontrollierte Unternehmens-KI. Es ist keine Funktion mehr, die man „dazuschaltet", es ist grundlegendste Infrastruktur. Die Wahl der richtigen RAG-Architektur ist damit eine strategische Entscheidung, kein Implementierungsdetail.

Die Frage, die man sich stellen sollte, ist nicht „Brauchen wir RAG?", sondern: „Ist unser Wissen so strukturiert, dass eine KI ihm vertrauen kann & generell Zugriff drauf hat?"

💿 B-Side

Anti-Pattern der Woche: „Wir laden einfach alle PDFs hoch." Wenn Dokumente keine sauberen Überschriften, keine Metadaten (Eigentümer, Zugriffsregelungen, Gültigkeitsdatum) und keine durchdachte Zerlegung in sinnvolle Abschnitte haben, hilft auch das beste Modell nichts. Schlechtes Retrieval beginnt fast immer bei schlecht aufbereiteten Dokumenten. Governance kommt vor Retrieval, nicht danach.

---

Das war Rag'n'Roll #001. Nächste Ausgabe: Wie man eine RAG-Architektur bewertet und woran man erkennt, dass man eigentlich GraphRAG braucht.

Weiterleiten ausdrücklich erwünscht🤘