LangChain oder LlamaIndex: Der Engpass entscheidet

Wenn Dokumente aufbereitet, indiziert und gezielt wiedergefunden werden müssen, ist LlamaIndex meist der passendere Ausgangspunkt. Die LlamaIndex-Dokumentation beschreibt dafür Datenaufnahme, Indizes, Retriever und Query Engines. Wo ein Agent dagegen zwischen Werkzeugen wählen und längere Abläufe steuern soll, spricht mehr für LangChain. Entscheidend ist der Engpass der konkreten Anwendung, nicht eine allgemeine Rangfolge der Frameworks.

Beide Produkte beherrschen RAG und Agenten. LangChains Agentendokumentation zeigt mit create_agent die Verbindung von Modell, Werkzeugen, Zustand und Middleware. Für eine Dokumentenfrage kann eine feste Such- und Antwortstrecke genügen; ein Ablauf mit mehreren externen Diensten braucht eher Regeln für Werkzeugwahl, Fehler und Zustand. Treten beide Anforderungen auf, lässt sich die Dokumentensuche von LlamaIndex als Werkzeug in einen LangChain-Agenten einbinden.

Dokumentenaufnahme: Der Engpass liegt oft vor der Suche

Bei RAG beginnt die Qualität mit dem eingelesenen Material. Ein Retriever kann eine Passage nur finden, wenn Tabellen, Überschriften und zusammengehörige Abschnitte bei der Verarbeitung brauchbar erhalten bleiben. Ebenso wichtig ist, ob Metadaten eine Fundstelle ihrer Quelle zuordnen und ob geänderte Dokumente im Index ankommen. Eine schnelle Antwort hilft wenig, wenn sie auf einer alten Fassung oder einem schlecht getrennten Textabschnitt beruht.

Die IngestionPipeline von LlamaIndex wendet Transformationen auf Eingabedaten an, kann Ergebnisse zwischenspeichern und erzeugte Knoten an einen Vektorspeicher übergeben. Mit angeschlossenem Dokumentenspeicher erkennt sie Dokumente anhand ihrer Kennung und ihres Hashs wieder; bei geändertem Inhalt kann sie diese erneut verarbeiten. Das macht die Aktualisierung des Bestands zu einer eigenen, gestaltbaren Strecke statt zu einem Nebeneffekt der Abfrage.

Bei unterschiedlich aufgebauten oder häufig wechselnden Dokumenten ist diese Kontrolle ein guter Grund, LlamaIndex näher anzusehen. Für einen kleinen Bestand einfacher Texte kann eine bestehende LangChain-Retrievalstrecke ausreichen. Der relevante Vergleich lautet dann: Welche Verarbeitung liefert für die tatsächlichen Fragen passende, aktuelle Passagen? Die Antwort hängt auch vom Parser, der Segmentierung und dem Speicher ab; das Framework allein legt die Trefferqualität nicht fest.

Agentensteuerung: Wann LangChain den schwierigeren Teil übernimmt

Ein Agent muss mehr leisten als eine Passage nachzuschlagen, wenn er etwa zwischen Dokumentensuche und externen APIs entscheidet, Ergebnisse aufeinander bezieht oder einen unterbrochenen Ablauf fortsetzt. LangChain stellt dafür einen Agenteneinstieg bereit, dessen Werkzeuge und Middleware konfiguriert werden können. Ein Checkpointer kann Gesprächszustand über Aufrufe hinweg erhalten. Diese Bausteine passen zu Anwendungen, bei denen die Reihenfolge und Kontrolle der Aktionen die eigentliche Entwicklungsarbeit ausmachen.

Die Entscheidung für LangChain folgt daraus nicht automatisch bei jedem RAG-Projekt. Jeder zusätzliche Modell- oder Werkzeugaufruf kann Zeit und Kosten verursachen; eine feste Abfolge ist für eine reine Dokumentenfrage oft leichter vorhersehbar. Umgekehrt hat auch LlamaIndex Agenten und ereignisbasierte Workflows. Wer bereits einen überschaubaren Ablauf damit betreibt, braucht für bloße Werkzeugaufrufe keinen zweiten Agentenrahmen. Der Vorteil von LangChain wird vor allem dort plausibel, wo flexible Werkzeugwahl, längerer Zustand und Eingriffe in den Ablauf zusammenkommen.

Was eine Messung zur Laufzeit aussagen kann

Der korrigierte lokale Versuch von Markaicode zieht frühere unbelegte Kaltstart- und Speicherwerte zurück und misst stattdessen die Segmentierung von 200 synthetischen Dokumenten über fünf Läufe auf einem Container mit einer virtuellen CPU: LangChains RecursiveCharacterTextSplitter benötigte im Median 0,111 Sekunden und erzeugte 6.459 Abschnitte, LlamaIndex’ SentenceSplitter 0,669 Sekunden und 704 Abschnitte. Für beide waren die Einstellungen chunk_size=500 und chunk_overlap=50 gesetzt.

Das Ergebnis betrifft ausschließlich diesen Verarbeitungsschritt. Die Splitter schneiden Text nach unterschiedlichen Regeln und erzeugten entsprechend verschieden viele Abschnitte. Aus dem Zeitunterschied lässt sich weder die Qualität der später gefundenen Passagen noch die Latenz einer vollständigen Antwort ableiten. Auch Speicherverbrauch und Werkzeugaufrufe wurden in diesem Versuch nicht verglichen. Ein schnellerer Splitter kann für die eigene Anwendung wertvoll sein; er beantwortet aber keine Frage zur Agentensteuerung.

Für eine Architekturentscheidung sollten deshalb getrennte Größen betrachtet werden: Dauer und Zuverlässigkeit der Aufnahme, Qualität der gefundenen Passagen, Zeit bis zur fertigen Antwort sowie Speicherbedarf unter der erwarteten Last. Bei Agenten kommen die Zahl, Dauer und Fehler der Werkzeugaufrufe hinzu. Erst die Trennung zeigt, ob ein Wechsel der Datenstrecke, der Steuerung oder beider Teile einen beobachteten Engpass trifft.

Beobachtbarkeit und die Grenze zwischen beiden Frameworks

Eine langsame oder falsche Antwort hat mehrere mögliche Ursachen: ein Dokument fehlt im Index, der Retriever wählt eine unpassende Passage, das Modell verarbeitet den Kontext schlecht oder ein Agent ruft das falsche Werkzeug auf. Im Betrieb müssen diese Schritte unterscheidbar bleiben. Sonst wird eine Änderung am Agenten vorgenommen, obwohl die Ursache in der Dokumentaufnahme liegt, oder die Suche wird umgebaut, obwohl zusätzliche Werkzeugschleifen die Wartezeit erzeugen.

LangChains Frameworkvergleich beschreibt die Kombination aus LlamaIndex-Query-Engine als Werkzeug und LangChain beziehungsweise LangGraph für den Agentenablauf; LangSmith wird dort als frameworkübergreifende Plattform für Traces und Auswertung eingeordnet. Für eine solche Kombination ist eine gemeinsame Anfragekennung sinnvoll, die den gefundenen Abschnitt mit dem auslösenden Werkzeugaufruf verbindet. Das ist eine Architekturentscheidung: Sie macht sichtbar, auf welcher Seite der Schnittstelle Qualität oder Zeit verloren geht.

Migrations- und Integrationsmatrix

Die Zuordnung richtet sich nach dem beobachteten Problem und der bereits funktionierenden Strecke:

LangChain-RAG, aber schwierige Dokumentenaufnahme: LlamaIndex für Einlesen, Segmentierung und Indexierung prüfen. Der vorhandene Antwortpfad kann bestehen bleiben, während Quellenkennungen und Metadaten beim Übergang erhalten werden.
LlamaIndex-RAG, aber komplexe Werkzeugwahl: Die bestehende Query Engine als klar definiertes Suchwerkzeug an einen LangChain-Agenten geben. LlamaIndex verantwortet den Dokumentbestand; der Agent entscheidet, wann er die Suche aufruft und wie er das Ergebnis weiterverarbeitet.
LangChain-Agent mit ausreichender Suche: Die bestehende Architektur beibehalten, solange die Dokumentseite die nötigen Passagen liefert. Ein zusätzlicher Indexierungsrahmen bringt auch eine neue Schnittstelle und Betriebsarbeit mit sich.
LlamaIndex-Workflow mit gut kontrollierbarem Ablauf: Die vorhandene Steuerung nutzen, solange Zustand, Fehlerbehandlung und Beobachtbarkeit für die Aufgabe genügen. LangChain wird erst interessant, wenn die Anforderungen an die Agentensteuerung über diesen Ablauf hinausgehen.

Wo beide Seiten schwierig sind, braucht die Kombination eine eindeutige Grenze: Die Suche liefert Passagen mit Quelle und Metadaten; der Agent entscheidet über Werkzeugaufrufe und weitere Schritte. So kann jede Seite für ihren eigenen Engpass beurteilt werden, ohne eine Segmentierungsmessung mit der Leistung eines vollständigen Agenten zu verwechseln.

Lesen Sie auch: