Der Kerngedanke ist einfach zu beschreiben: Ein LLM allein ist ein Textgenerator. Es nimmt eine Eingabe entgegen und produziert eine Ausgabe. Für eine nützliche Anwendung braucht man aber mehr – man muss Eingaben strukturieren, Wissen aus eigenen Dokumenten einspeisen, mehrere Modellaufrufe verketten, externe Werkzeuge aufrufen, Zwischenergebnisse zwischenspeichern und das Ganze beobachtbar und testbar machen. Genau diese Klammer liefert LangChain als Orchestrierungs- und Integrationsschicht zwischen dem Modell, Ihren Daten und der restlichen Software.
LangChain ist dabei bewusst herstellerneutral aufgebaut. Es legt sich nicht auf einen einzelnen LLM-Anbieter fest, sondern bietet einheitliche Schnittstellen für viele Modelle – kommerzielle wie selbst gehostete Open-Weight-Modelle. Dieselbe Eigenschaft gilt für Vektordatenbanken, Dokumenten-Quellen und Werkzeuge. Das Versprechen lautet: Sie schreiben Ihre Anwendungslogik einmal und können den darunterliegenden Anbieter mit überschaubarem Aufwand austauschen.
Ein wichtiger Unterschied zu Tools wie Microsoft Copilot oder einem fertigen Chatbot: LangChain ist kein einsatzbereites Endprodukt, das man lizenziert und einschaltet. Es ist eine Bibliothek für Entwicklerinnen und Entwickler. Wer LangChain nutzt, schreibt Code – in Python oder JavaScript/TypeScript – und baut daraus seine eigene Anwendung. Das bedeutet maximale Flexibilität, aber auch Verantwortung: Architektur, Hosting, Datenschutz und Betrieb liegen bei Ihnen beziehungsweise bei Ihrem Umsetzungspartner.
Aus diesem Grund taucht LangChain in der Praxis fast immer dort auf, wo eine maßgeschneiderte KI-Anwendung entstehen soll, die sich mit Standardprodukten nicht abbilden lässt – etwa ein Assistent, der auf die eigene, sensible Dokumentenbasis zugreift, ein Agent, der mehrere interne Systeme orchestriert, oder ein domänenspezifischer Chatbot mit eigenem Verhalten und eigener Datenhoheit.
Drei Eigenschaften definieren LangChain im Kern:
In der INAGRO-Wissensdatenbank steht LangChain in der Kategorie Vektordatenbanken & RAG – und das aus gutem Grund. Die beiden häufigsten Anwendungsfälle für LangChain sind Retrieval-Augmented Generation (also das Anreichern von Modellantworten mit eigenem Wissen) und Agenten (also Systeme, die selbstständig Werkzeuge auswählen und mehrstufige Aufgaben lösen). Für beides liefert LangChain die Bausteine. Die eigentliche Wissensspeicherung übernehmen weiterhin spezialisierte Komponenten wie Vektordatenbanken; LangChain ist die Schicht, die diese Komponenten zu einer funktionierenden Anwendung verbindet.
Der praktische Wert dieser Bausteine zeigt sich im Zusammenspiel. Eine typische, einfache LangChain-Kette sieht konzeptionell so aus: Ein Prompt-Template nimmt eine Nutzerfrage entgegen und füllt sie in eine vorbereitete Vorlage ein. Das Ergebnis geht an ein Chat-Modell. Dessen Antwort läuft durch einen Output-Parser, der reinen Text oder ein strukturiertes Objekt zurückgibt. Mit LCEL wird diese Kette deklarativ zusammengesteckt – Prompt, Modell und Parser werden mit einem Pipe-Operator verbunden. Der große Gewinn: Die Kette ist von Haus aus streaming-fähig, kann parallel ausgeführt werden und lässt sich einzeln testen.
Diese Komponierbarkeit ist die eigentliche Stärke von LangChain. Statt für jede Anwendung das Rad neu zu erfinden, kombinieren Entwicklerinnen und Entwickler bewährte Bausteine. Ein Retrieval-Schritt, ein Reranking-Schritt, ein Modellaufruf, ein Parser – jeder Baustein ist isoliert, austauschbar und wiederverwendbar.
Ein Sprachmodell ist von Natur aus zustandslos: Jeder Aufruf kennt nur, was im aktuellen Prompt steht. Für einen einmaligen Übersetzungs-Task ist das egal. Für einen Chatbot, der sich an die letzten zehn Nachrichten erinnern soll, ist es entscheidend. LangChain liefert dafür Memory-Mechanismen, die den Gesprächsverlauf vorhalten und bei jedem neuen Aufruf in den Kontext einspeisen. In der modernen LangChain-Welt wird Zustandshaltung zunehmend über LangGraph abgebildet – das Thema von Kapitel 05 –, weil dort Zustand, Persistenz und Wiederaufnahme sauberer modelliert sind als in den klassischen Memory-Klassen.
Das Grundproblem von RAG ist schnell erklärt: Ein Sprachmodell kennt nur, was in seinen Trainingsdaten stand. Ihre internen Verträge, Ihr Produktwissen, Ihre Prozessdokumentation – all das kennt es nicht. Stellt man dem Modell trotzdem eine Frage dazu, antwortet es entweder „weiß ich nicht“ oder, schlimmer, es erfindet plausibel klingende, aber falsche Inhalte. RAG löst das, indem vor dem Modellaufruf die passenden Wissensbausteine aus Ihren Dokumenten gesucht und in den Prompt eingefügt werden. Das Modell antwortet dann auf Basis dieser bereitgestellten Quellen.
LangChain bildet eine RAG-Pipeline durch eine Kette spezialisierter Komponenten ab. Diese vier Schritte tauchen in jeder LangChain-RAG-Anwendung auf:
Der praktische Mehrwert von LangChain bei RAG liegt weniger in einzelnen Algorithmen als in der Vereinheitlichung. Ob Sie Ihre Embeddings bei einem kommerziellen Anbieter erzeugen oder ein selbst gehostetes Open-Weight-Modell nutzen, ob Sie als Vektor-Store eine eingebettete Bibliothek, eine Postgres-Erweiterung oder eine dedizierte Vektordatenbank verwenden – die LangChain-Schnittstelle bleibt gleich. Das senkt die Wechselkosten erheblich und erlaubt es, zunächst mit einer einfachen lokalen Lösung zu starten und später auf eine produktionsreife Datenbank zu migrieren, ohne die Pipeline neu zu schreiben.
In unseren Projekten ist genau das oft der entscheidende Vorteil: Ein erster RAG-Prototyp entsteht mit einem eingebetteten Vektor-Store in wenigen Tagen. Bewährt sich der Ansatz, tauschen wir Embedding-Modell und Vektor-Store gegen produktionsreife, DSGVO-konforme Komponenten aus – die Anwendungslogik bleibt weitgehend unverändert.
LangChain orchestriert RAG, speichert die Daten aber nicht selbst. Die eigentliche Wissensbasis liegt in einer Vektordatenbank, das Chunking folgt einer bewussten Strategie, die Embeddings stammen von einem dedizierten Modell. Für all diese Bausteine finden Sie in dieser Kategorie eigene Fachartikel – etwa zu Vektor-Stores, zu Embeddings, zu Chunking-Strategien, zu Hybrid-Suche und Reranking. LangChain ist die Klammer, die diese Bausteine zusammenführt; die einzelnen Komponenten wählen Sie nach Ihren Anforderungen an Datenschutz, Skalierung und Kosten.
Das Grundprinzip eines Agenten ist die Schleife aus Denken und Handeln. Das Modell bekommt eine Aufgabe und eine Liste verfügbarer Werkzeuge. Es überlegt, welches Werkzeug es als Nächstes braucht, ruft es auf, betrachtet das Ergebnis und entscheidet erneut: weiteres Werkzeug nutzen oder die Aufgabe ist gelöst. Diese Schleife wiederholt sich, bis eine Antwort feststeht. Technisch basiert das heute meist auf dem Function-Calling moderner Chat-Modelle: Das Modell gibt nicht nur Text aus, sondern signalisiert strukturiert, welche Funktion mit welchen Parametern aufgerufen werden soll.
Werkzeuge (Tools) sind das, was einen Agenten handlungsfähig macht. Praktisch alles, was sich als Funktion kapseln lässt, kann ein Werkzeug sein:
Eigene Werkzeuge zu definieren ist in LangChain bewusst einfach gehalten: Eine Funktion wird mit einer klaren Beschreibung und einem Eingabe-Schema versehen, und schon kann das Modell sie aufrufen. Die Beschreibung ist dabei kein Beiwerk – sie ist die Anleitung, anhand derer das Modell entscheidet, wann das Werkzeug passt. Schlecht beschriebene Werkzeuge führen zu schlecht entscheidenden Agenten.
So mächtig Agenten klingen, so heikel sind sie im Betrieb. Ein Agent, der selbst entscheidet, ist naturgemäß weniger vorhersehbar als eine feste Chain. Er kann in Endlosschleifen geraten, Werkzeuge falsch wählen, unnötig viele teure Modellaufrufe produzieren oder bei mangelhafter Absicherung Aktionen auslösen, die er nicht hätte auslösen dürfen. Aus diesem Grund hat sich der Schwerpunkt in der LangChain-Welt verschoben: Für ernsthafte, produktive Agenten wird heute meist nicht der klassische Agent-Mechanismus genutzt, sondern LangGraph – weil es deutlich mehr Kontrolle über den Ablauf erlaubt. Mehr dazu im nächsten Kapitel.
Der gedankliche Sprung von Chains zu LangGraph ist bedeutsam. Eine Chain ist linear: A, dann B, dann C. Ein klassischer Agent ist das Gegenteil – er entscheidet alles selbst, ist aber kaum zu bändigen. LangGraph liegt genau dazwischen: Sie definieren einen Graphen aus Knoten und Kanten. Jeder Knoten ist ein Arbeitsschritt – ein Modellaufruf, ein Werkzeug, eine Prüfung. Die Kanten legen fest, welcher Schritt als Nächstes folgt, und das darf von Bedingungen abhängen. So entstehen Verzweigungen, Schleifen und Wiederholungen, ohne dass die Kontrolle an das Modell abgegeben wird.
Der Name verrät es: In LangGraph ist der Zustand (State) erstklassiger Bürger. Durch den gesamten Graphen wird ein gemeinsames Zustandsobjekt gereicht, das jeder Knoten lesen und verändern kann. Darin liegt der Gesprächsverlauf, liegen Zwischenergebnisse, liegt der Fortschritt der Aufgabe. Dieses Modell macht mehrere Dinge möglich, die mit einfachen Chains schwierig waren:
In unseren Projekten gilt heute eine klare Linie: Sobald ein Ablauf mehr ist als eine simple Frage-Antwort-Kette – sobald es Verzweigungen, Wiederholungen, menschliche Freigaben oder langlaufende Zustände gibt – fällt die Wahl auf LangGraph statt auf klassische Chains oder den alten Agent-Mechanismus. Der Grund ist nicht Mode, sondern Wartbarkeit und Beobachtbarkeit. Ein als Graph modellierter Ablauf ist sichtbar, nachvollziehbar und testbar. Man kann jeden Knoten einzeln prüfen, den Zustand an jedem Punkt inspizieren und das Verhalten gezielt steuern. Diese Eigenschaften sind für einen verlässlichen Produktivbetrieb wichtiger als jede zusätzliche Autonomie.
Wer eine RAG-Pipeline oder einen Agenten betreibt, kennt die Kernfrage: Warum hat das System genau diese Antwort gegeben? Lag es am Retrieval, das die falschen Dokumente fand? Am Prompt? Am Modell? An einem Werkzeug, das ein unerwartetes Ergebnis lieferte? Ohne Einblick in die einzelnen Schritte tappt man im Dunkeln. LangSmith liefert diesen Einblick über drei Säulen.
Aus unserer Erfahrung ist die Evaluierung die wertvollste, aber am häufigsten übersprungene Disziplin. Viele KI-Projekte funktionieren im Demo-Modus gut und scheitern dann im Alltag, weil niemand systematisch misst, ob Änderungen die Qualität verbessern oder verschlechtern. Ein neuer Prompt, ein anderes Embedding-Modell, ein Modell-Update beim Anbieter – jede dieser Änderungen kann die Antwortqualität kippen, ohne dass es jemand bemerkt. Mit einem Eval-Datensatz und automatisierten Bewertungen wird Qualität messbar: Man kann Versionen vergleichen, Regressionen erkennen und Verbesserungen belegen statt behaupten. Genau das hebt eine KI-Anwendung von der Spielerei zur verlässlichen Software.
LangChain spielt seine Stärken aus, wenn eine Anwendung über reines RAG hinausgeht: wenn mehrere Werkzeuge orchestriert werden, wenn Agenten oder zustandsbehaftete Workflows nötig sind, wenn viele unterschiedliche Systeme angebunden werden müssen und wenn Beobachtbarkeit über LangSmith gewünscht ist. Auch für schnelle Prototypen ist LangChain hervorragend – die breite Integrationsbasis bringt in Tagen zum Laufen, was sonst Wochen kostet.
LlamaIndex ist von Beginn an auf das Indizieren und Abfragen von Dokumenten spezialisiert. Wenn der Kern Ihres Vorhabens hochwertiges Dokument-RAG ist – also eine durchdachte Wissens-Suche über große, heterogene Dokumentbestände – dann ist LlamaIndex oft die fokussiertere, elegantere Lösung. Die beiden Frameworks schließen sich nicht aus; sie überschneiden sich, setzen aber unterschiedliche Schwerpunkte. LlamaIndex wird daher zu Recht als verwandtes Werkzeug geführt.
Die Direktintegration – also der direkte Aufruf einer Modell-API ohne Framework – ist die unterschätzte Option. Für klar umrissene Aufgaben mit einem einzigen Modellaufruf und wenig Logik ist ein Framework oft Overkill. Weniger Abstraktion bedeutet weniger Abhängigkeiten, weniger Versions-Reibung und besser verständlichen Code. In unseren Projekten beginnen wir die Architektur-Diskussion deshalb häufig mit der Frage: Brauchen wir das Framework überhaupt – oder löst ein direkter, gut getesteter Aufruf das Problem schlanker?
Der zentrale Punkt zuerst: LangChain selbst verarbeitet keine Daten auf fremden Servern. Die Bibliothek läuft dort, wo Sie sie ausführen – auf Ihrem Server, in Ihrer Cloud, in Ihrem Rechenzentrum. Damit liegt die Datenhoheit grundsätzlich bei Ihnen. Die datenschutzrelevanten Datenflüsse entstehen erst durch die Komponenten, die Sie anbinden – und genau hier muss man genau hinschauen.
Bei einer typischen LangChain-Anwendung gibt es mehrere potenzielle Abflusspunkte, die jeweils einzeln zu bewerten sind:
Dass LangChain quelloffen ist, hat handfeste Vorteile: keine Lizenzkosten für das Framework selbst, volle Transparenz über den Code, keine Bindung an einen einzelnen Hersteller und die Freiheit, alles selbst zu betreiben. Diese Freiheit hat aber eine Kehrseite: Die Verantwortung für Sicherheit, Updates und Betrieb liegt bei Ihnen. LangChain entwickelt sich schnell, Schnittstellen ändern sich, Abhängigkeiten müssen gepflegt werden. Ein produktives System braucht jemanden, der diese Pflege übernimmt – sei es ein internes Team oder ein Umsetzungspartner.
Aus Betriebssicht empfehlen wir grundsätzlich, die LangChain-Versionen zu fixieren und Updates kontrolliert einzuspielen statt automatisch. Die Geschwindigkeit der Weiterentwicklung ist großartig für Innovation, aber riskant für Stabilität, wenn man sie nicht aktiv steuert.
Standardprodukte wie Microsoft Copilot, fertige Chatbot-Plattformen oder spezialisierte SaaS-Lösungen decken viele Bedürfnisse ab, ohne dass eine Zeile Code geschrieben werden muss. Sie sind schnell eingeführt, gewartet vom Anbieter und in der Regel günstiger im Einstieg. Der Punkt, an dem LangChain ins Spiel kommt, ist genau dort, wo diese Produkte an Grenzen stoßen.
Die ehrliche Botschaft an mittelständische Entscheider lautet: Eine Custom-KI-Anwendung mit LangChain ist ein Software-Projekt, kein Lizenzkauf. Ein erster funktionierender Prototyp – etwa ein RAG-Assistent auf einer abgegrenzten Dokumentenmenge – entsteht oft erstaunlich schnell, in Tagen bis wenigen Wochen. Der Weg von diesem Prototyp zu einer produktiv betriebenen, verlässlichen Anwendung ist aber der eigentliche Aufwand: Datenqualität, Berechtigungen, Evaluierung, Absicherung, Monitoring und laufende Pflege. Diese „letzten zwanzig Prozent“ machen erfahrungsgemäß den Großteil der Arbeit aus.
Genauso wichtig wie die Entwicklung ist der Betrieb über die Zeit. Eine LangChain-Anwendung muss gepflegt werden: Framework-Updates, Modell-Wechsel beim Anbieter, neue Datenquellen, sich änderndes Nutzerverhalten. Wer ein Custom-System baut, braucht entweder internes Know-how oder einen verlässlichen Partner, der diese Verantwortung trägt. Diese Folgekosten gehören von Anfang an in die Build-vs-Buy-Rechnung – sonst entsteht ein gut gemeintes Projekt, das nach dem ersten Modell-Update verwaist.
