Read or Act

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

Heute auf der Setlist: Wann ein Sprachmodell nachschlagen (RAG) und wann es handeln soll (MCP), & warum die besten Systeme beides können.

🎚️ Soundcheck

„RAG oder MCP?“ klingt nach einer nötigen Entscheidung, wenn man vor diesen Akronymen steht, sie ist aber meistens sowieso die falsche Frage. Die beiden lösen unterschiedliche Aufgaben: RAG beantwortet „Was steht dazu in unseren Unterlagen?“, MCP beantwortet „Tu etwas in unseren Systemen“. Das eine ruft Wissen ab, das andere führt Aktionen aus.

Eine Faustregel bringt es auf den Punkt: Würde ein Mensch die Antwort in einem Dokument nachschlagen, ist es RAG. Würde ein Mensch einen Knopf drücken oder eine Datenbank abfragen, ist es MCP.

🎤 Main Set: Zwei Werkzeuge, zwei Jobs

RAG: Wissen abrufen

RAG erweitert das Modell um einen Abrufmechanismus: Dokumente werden in Chunks zerlegt, als Embeddings indexiert, & bei einer Frage werden die relevantesten Passagen geholt & dem Modell als Kontext beigelegt. Die Stärke von RAG-Systemen ist Nachvollziehbarkeit: belegbare Antworten mit Quellenangaben. Ideal für „Stable Knowledge“, also stabiles Wissen wie Handbücher, Richtlinien & Spezifikationen. Eben Dinge, die sich optimalerweise nicht zu häufig oder zu grundlegend ändern, auch wenn gute RAG-Systeme auch damit umgehen können.

MCP: Aktionen ausführen

Das Model Context Protocol bindet externe Tools & Datenquellen an das Modell. Tools werden mit strukturierten Schemas registriert (Name, Parameter, JSON-Definition); das Modell erzeugt gezielt Tool-Aufrufe, ein Backend führt sie aus & liefert das Ergebnis zurück. Die Stärke ist Echtzeit & direkte Systeminteraktion: Bestand abfragen, ein Ticket anlegen, eine Bestellung auslösen.

Der Kernunterschied in einem Satz: RAG liefert eine Erklärung aus Dokumenten, MCP liefert eine Aktion über Tools.

Wichtig im Kopf zu behalten: Natürlich kann ein RAG-System Teil eines MCP-Servers sein. Das eine schließt das andere keinesfalls aus.

🥁 Track 2: Wann was, und warum oft beides

RAG passt, wenn die Antwort bereits in Doku, Policy oder Spezifikation steht, wenn Quellenangaben nötig sind & die Inhalte relativ stabil bleiben. MCP passt, wenn Live-Daten gebraucht werden, wenn das System eine Aktion ausführen soll oder mehrstufige Workflows mit Tool-Sequenzen nötig sind.

In der Praxis ist es aber selten entweder/oder. Viele Produktionssysteme fahren ein RAG → MCP → RAG-Muster: erst per RAG die Policy oder Begründung abrufen, dann per MCP die Aktion ausführen, dann per RAG das Ergebnis erklären. Beispiel Support-Bot: „Habt ihr 'Dune: Teil 2' auf Lager, & wie ist eure Rückgaberichtlinie?“ trifft beide Systeme zugleich, den Bestand per MCP(-Tool) & die Richtlinie per RAG.

Beide liefern am Ende Kontext, der nur unterschiedlicher Natur ist: RAG den Wissenskontext, MCP den Aktionskontext. Context is King, auch hier.

🎯 Encore: Der eine Gedanke für Entscheider

RAG vs MCP ist kein Entweder-oder, sondern eine Frage der Aufgabe: Information oder Aktion. Und die meisten echten Use Cases brauchen beides.

Die richtige Frage ist deshalb nicht „Setzen wir auf RAG oder MCP?“, sondern: „An welcher Stelle in unserem Workflow braucht das System Wissen, & an welcher eine Aktion?“

Wer das sauber trennt, baut Systeme, die belegen & handeln können.

💿 B-Side

Das Anti-Pattern der Woche: MCP-Tools, die anlegende, aktualisierende oder löschende Operationen auslösen (Bestellung, Preisänderung), ohne Berechtigungsprüfung, klare Schemas & Schutz vor Endlosschleifen. Das zerschießt auf kurz oder lang das ganze System & birgt schwerwiegende Risiken. Auf RAG-Seite gilt das Bekannte: eine veraltete Knowledge Base, schlechtes Chunking & Kontextüberlastung kippen die Qualität der Antworten eines Sprachmodells.

---

Das war Rag'n'Roll #005. Nächste Ausgabe: Warum Knowledge Graphs an Ausnahmen scheitern, & was einen echten Wissens-Graph vom bloßen Entitäten-Graph unterscheidet.

Weiterleiten erwünscht🤘