LangChain RAG im Vergleich: Wann LlamaIndex besser passt

LangChain RAG oder LlamaIndex: Was passt zum Projekt?

LlamaIndex ist die erste Wahl für Anwendungen, deren Kern die Arbeit mit Dokumenten ist. LangChain bietet den passenderen Einstieg für Agenten, die mehrere Tools koordinieren. Beide eignen sich für Retrieval-Augmented Generation, kurz RAG: Dabei werden relevante Quellen abgerufen, bevor das Modell daraus eine Antwort erzeugt.

Für ein Gründungsteam, das einen Supportassistenten auf Basis von Produkthandbüchern entwickelt, ist LlamaIndex der bessere Ausgangspunkt. Seine Abstraktionen für Dokumente, Indizes und Query Engines stellen den Weg vom Einlesen bis zur Antwort in den Mittelpunkt des Codes. Das passt, wenn sich die nächsten Entwicklungsfragen um fehlende Textstellen, die Dokumentstruktur oder die Belege drehen, die das Modell tatsächlich erhält.

Für einen Assistenten, der eine Richtlinie liest, eine Bestellung prüft und vor einer Erstattung eine Freigabe einholt, ist LangChain der bessere Ausgangspunkt. In seiner aktuellen Agenten-API stehen Tools und die Verarbeitungsschleife des Modells im Zentrum; LangGraph bildet das darunterliegende Ausführungsframework. Das passt, wenn Zustand, Freigaben oder die Reihenfolge von Aktionen die entscheidenden Fragen sind.

Erfüllt eine bestehende Anwendung bereits ihre Anforderungen an Retrieval und Workflows, sollte sie bestehen bleiben. Ein anderer Framework-Name repariert weder eine fehlerhaft eingelesene Tabelle noch einen unsicheren Zahlungsvorgang. Eine zusätzliche Komponente lohnt sich erst, wenn klar ist, welchen konkreten Fehler sie beheben soll.

Dieser Vergleich bewertet den Umgang mit Dokumenten, die Kontrolle über die Agentenausführung, die Schnittstellen zwischen Komponenten und die laufenden Kosten. Die Einschätzungen beruhen auf der Dokumentation; sie sind keine gemessenen Ranglisten für Geschwindigkeit oder Genauigkeit.

Quellen: die LlamaIndex-Dokumentation, die LangChain-Dokumentation, das LlamaIndex-Paket und das LangChain-Paket sowie die Preisangaben der Anbieter zu LlamaParse und LangSmith. Die gehosteten Dienste in der Preiszeile erfüllen unterschiedliche Aufgaben; ihre Abonnements sind daher nicht gleichwertig.

Wofür eignen sich die Frameworks heute?

LlamaIndex ist mehr als ein Index, LangChain mehr als eine Sammlung von Chains. Die aktuelle Dokumentation beider Ökosysteme stellt auch Agenten in den Mittelpunkt. Der Unterschied liegt darin, für welche Aufgabe das jeweilige Framework die nützlichere Ausgangsstruktur liefert.

LlamaIndex: Datenpipelines und Dokumentenagenten

LlamaIndex ist ein Open-Source-Framework für Agenten, die mit eigenen Daten arbeiten. Seine Bausteine decken das Laden von Dokumenten, das Erstellen durchsuchbarer Repräsentationen, das Abrufen von Belegen und das Erzeugen von Antworten ab. Mit Workflows unterstützt es außerdem ereignisgesteuerte Abläufe mit Verzweigungen, Wiederholungsversuchen und menschlicher Prüfung. Die Framework-Übersicht des Anbieters beschreibt diesen erweiterten Umfang ausdrücklich.

Bei einem Assistenten für Vertragsfragen ist häufig die einzelne Textstelle die entscheidende Einheit: Woher stammt sie, zu welcher Version gehört sie, und verändert der umgebende Abschnitt ihre Bedeutung? Ein Node in LlamaIndex bündelt einen Ausschnitt des Quellinhalts mit Metadaten und Beziehungen. So lassen sich diese Belege gezielt verwalten. Eine Query Engine verbindet anschließend das Retrieval mit der Antwortgenerierung. Näheres erläutert die Anleitung zu VectorStoreIndex.

Die Grenze setzt die Qualität des eingelesenen Materials. Macht ein Loader aus einer Tabelle einen durchgehenden Text, kann ein Preis seine Zuordnung zur Spaltenüberschrift verlieren. Die Indexierung übernimmt diesen Fehler dann unverändert. Auch die LlamaIndex-Dokumentation unterscheidet zwischen integrierten Readern für sauberen Text und dem kommerziellen Dienst LlamaParse für anspruchsvollere Dokumente. Die Datenabstraktionen sind ein Grund für die Framework-Wahl; die Qualität des Parsings muss gesondert geprüft werden.

Auch die langfristige Pflege spielt eine Rolle: Laut aktueller Paketbeschreibung des Anbieters hat sich der Schwerpunkt auf LlamaParse und verwandte Dokumentenwerkzeuge verlagert. Das Framework bleibt als offener Werkzeugkasten verfügbar. Bevor eine langfristige Abhängigkeit entsteht, sollte deshalb geprüft werden, wie gut die konkret benötigten Integrationen gepflegt werden.

LangChain: Agenten mit LangGraph als Grundlage

LangChain ist ein Open-Source-Framework, dessen aktuelle API create_agent eine konfigurierbare Ausführungsumgebung für Agenten bereitstellt. Dazu gehören Tools, Anweisungen und die umgebende Ausführungslogik, mit der ein Modell Aufgaben erledigen kann. Middleware erlaubt es, das Verhalten rund um diese Schleife anzupassen. Die Übersicht beschreibt LangGraph als Grundlage dieser Agenten.

Für einen Agenten im Bestellsupport kann Retrieval eines von mehreren Tools sein. Die Anwendung fragt möglicherweise auch den Versandstatus ab und bereitet einen Erstattungsvorschlag vor. Wenn das Zusammenspiel solcher Tools das Produkt prägt, ist LangChain der naheliegende Einstieg.

Die Grenze liegt bei den verbindlichen Geschäftsregeln: Eine Agentenabstraktion kann sie nicht selbst festlegen. Die Anwendung muss weiterhin bestimmen, wer eine Erstattung erhalten darf, welche Freigabe nötig ist und wie verhindert wird, dass eine wiederholte Ausführung doppelt erstattet. Das Framework liefert die Ausführungsmechanismen; die Regeln verantwortet die Anwendung.

LangChain oder direkt LangGraph?

Die Agentenabstraktion von LangChain passt, wenn ein Modell die benötigten Tools auswählen soll. LangGraph direkt einzusetzen ist sinnvoll, wenn Zustand und Zustandsübergänge des Workflows expliziter definiert werden müssen. LangGraph gehört bereits zur Grundlage aktueller LangChain-Agenten. Gedächtnisfunktionen oder menschliche Prüfung hinzuzufügen erfordert daher nicht automatisch eine Neuentwicklung. Diese Entscheidung behandelt der separate Vergleich von LangChain und LangGraph.

Aktuelle Python-Versionen und Lizenzen

Geprüft am 13. Oktober 2026: Veröffentlicht waren die Python-Pakete llama-index 0.14.25, llama-index-core 0.14.25, langchain 1.4.5 und langgraph 1.2.15. Diese Angaben sind Momentaufnahmen einzelner Pakete, keine einheitliche Versionsnummer für sämtliche Integrationen eines Ökosystems.

Beide Framework-Repositories stehen unter der MIT-Lizenz: siehe die Lizenz von LlamaIndex und die Lizenz von LangChain. Für die gehosteten Produkte gelten gesonderte kommerzielle Bedingungen. Eine kostenlose Framework-Lizenz deckt weder Modellinferenz noch eine gehostete Vektordatenbank oder den Anwendungsserver ab.

LangChain RAG und LlamaIndex RAG: Dieselbe Aufgabe in Python

Beide Beispiele laden lokale Textdateien, erstellen einen Index im Arbeitsspeicher und beantworten dieselbe Frage anhand abgerufener Inhalte. Sie veranschaulichen den Aufbau der APIs. Für diesen Vergleich wurden sie mit der Dokumentation abgeglichen, aber nicht gegen eine kostenpflichtige Modell-API ausgeführt.

Als Grundlage dient ein Verzeichnis data mit eigenen Richtlinientexten als UTF-8-Dateien mit der Endung .txt. Die Umgebungsvariable OPENAI_API_KEY muss gesetzt sein; RAG_MODEL muss in beiden Skripten dasselbe, im eigenen Konto verfügbare OpenAI-Chatmodell bezeichnen. Beide Beispiele wählen ausdrücklich text-embedding-3-small für die Embeddings aus, also die numerischen Repräsentationen, mit denen nach ähnlichen Inhalten gesucht wird. Auch das LlamaIndex-Einstiegstutorial empfiehlt, das Embedding-Modell explizit festzulegen.

Das LlamaIndex-Beispiel

Benötigt werden llama-index-core, llama-index-readers-file, llama-index-llms-openai und llama-index-embeddings-openai. Alternativ enthält das Einstiegspaket llama-index diese Komponenten bereits; Details stehen in der Installationsanleitung.

import os
from llama_index.core import SimpleDirectoryReader, VectorStoreIndex
from llama_index.embeddings.openai import OpenAIEmbedding
from llama_index.llms.openai import OpenAI

docs = SimpleDirectoryReader("data", required_exts=[".txt"]).load_data()
embed = OpenAIEmbedding(model="text-embedding-3-small")
index = VectorStoreIndex.from_documents(docs, embed_model=embed)
llm = OpenAI(model=os.environ["RAG_MODEL"])
engine = index.as_query_engine(llm=llm, similarity_top_k=3)
print(engine.query("What is the refund window?"))

Hier übernimmt from_documents die Umwandlung der Dokumente in Nodes und ihre Indexierung. Die Query Engine kümmert sich um Retrieval und Antwortsynthese. Für einen kleinen Wissensassistenten ist das der Vorteil: Der Code bildet die Arbeit mit Dokumenten unmittelbar ab. Bei Änderungsbedarf bleiben zugleich die tieferliegenden Komponenten zugänglich.

Das LangChain-Beispiel

Benötigt werden langchain-core, langchain-openai und langchain-text-splitters. Dieser fest vorgegebene Retrieval-Ablauf verwendet die Komponentenpakete von LangChain. Das übergeordnete Agentenpaket langchain wird erst benötigt, wenn ein Agent hinzukommt. Die APIs sind in der RAG-Anleitung, der Referenz zum In-Memory-Speicher und der OpenAI-Integration dokumentiert.

import os
from pathlib import Path
from langchain_core.documents import Document
from langchain_core.vectorstores import InMemoryVectorStore
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_text_splitters import RecursiveCharacterTextSplitter
files = Path("data").glob("*.txt")
docs = [Document(page_content=p.read_text(encoding="utf-8"), metadata={"source": str(p)}) for p in files]
chunks = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=100).split_documents(docs)
index = InMemoryVectorStore.from_documents(chunks, OpenAIEmbeddings(model="text-embedding-3-small"))
question = "What is the refund window?"
context = "\n\n".join(d.page_content for d in index.similarity_search(question, k=3))
llm = ChatOpenAI(model=os.environ["RAG_MODEL"])
print(llm.invoke(f"Answer only from this context; if absent, say unknown.\n{context}\nQuestion: {question}").content)

In dieser Variante sind die einzelnen Schritte sichtbar: Text laden, aufteilen, einbetten und speichern, Textstellen abrufen und schließlich das Chatmodell aufrufen. Die zusätzliche Verknüpfung der Komponenten wird dann nützlich, wenn Retrieval nur ein Teil einer größeren Anwendung ist.

LlamaIndex vs LangChain: Wer überzeugt bei Retrieval und Agenten?

LlamaIndex bietet die passendere Ausgangsabstraktion für die Dokumentensuche. LangChain bietet sie für Agenten, die Aktionen koordinieren. Diese Urteile betreffen die Eignung für eine Entwicklungsaufgabe. Sie bedeuten nicht, dass eines der Frameworks die Aufgaben des anderen grundsätzlich nicht bewältigen könnte.

Dokumente einlesen und abrufen: Vorteil LlamaIndex

LlamaIndex empfiehlt sich, wenn die meisten Änderungen auf dem Weg vom Rohdokument zu den Belegen für das Modell anfallen. Seine Struktur aus Indexierung und Query Engines hält diese Arbeit zusammen. Ein Einkaufsassistent, der Fragen zu Vertragsnachträgen beantwortet, muss beispielsweise zunächst die Beziehungen zwischen Quellen erhalten. Eine weitere Schleife für Tool-Aufrufe ist dann nachrangig.

LangChain kann denselben Retrieval-Ablauf abbilden. Seine RAG-Dokumentation trennt die Indexierung vom Abruf und der Antwortgenerierung; das obige Beispiel zeigt den einfachen Fall. Gibt es bereits einen guten Suchdienst, kann dessen Aufruf aus LangChain weniger Aufwand bedeuten als die Einführung eines weiteren Frameworks.

Die Entscheidung kippt, sobald Retrieval nicht mehr das schwierige Teilsystem ist. Bei einer sauberen Wissensbasis und mehreren Tools für Geschäftsprozesse lohnt sich die Investition eher in den Agenten-Workflow.

Agenten mit Tools und Workflow-Steuerung: Vorteil LangChain

LangChain empfiehlt sich, wenn die Anwendung zwischen Belegen und Aktionen wechselt: eine Richtlinie lesen, einen Kundendatensatz abrufen, fehlende Angaben erfragen und dann eine Aktion zur Freigabe vorbereiten. Die konfigurierbare Agentenschleife und die Grundlage LangGraph passen zu diesem Aufbau.

Auch LlamaIndex unterstützt Agenten. Die Agentenanleitung des Anbieters dokumentiert Agenten mit Tool-Nutzung; das Einstiegstutorial bindet Retrieval als aufrufbares Tool ein. Ein Dokumentenassistent, der sucht, rechnet und eine Antwort liefert, kann vollständig innerhalb von LlamaIndex bleiben.

Ein bereits dort umgesetzter dokumentenbezogener Workflow muss deshalb nicht migriert werden, nur weil das Produkt inzwischen einen „Agenten“ hat. Ein Wechsel ist erst sinnvoll, wenn die neu benötigte Workflow-Steuerung den Austausch der Ausführungsschicht rechtfertigt.

LlamaIndex und LangGraph im Vergleich

LlamaIndex und LangGraph erfüllen häufig Aufgaben auf unterschiedlichen Ebenen. LlamaIndex kann Belege aufbereiten und abrufen; LangGraph kann steuern, wie ein zustandsbehafteter Workflow danach weiterläuft. Für diese Ausführungsschicht kommen auch die eigenen Workflows von LlamaIndex infrage. Beide zusammen einzusetzen ist somit eine Architekturentscheidung und kein Behelf für ein fehlendes Feature.

Entscheidend sind klare Zuständigkeiten: Eine Komponente sollte das Dokumenten-Retrieval verantworten, eine andere den Ausführungszustand der Anwendung. Wenn beide unabhängig voneinander Wiederholungsversuche und Gesprächszustand steuern, wird die Ursachenanalyse bei einer wiederholten Aktion schwieriger.

Retrieval-Qualität: Fehler prüfen statt Marken vergleichen

Eine Feature-Liste belegt für keines der Frameworks einen Genauigkeitsvorsprung. Sinnvoller ist ein Vergleich mit derselben Quellensammlung und denselben Fragen. Bevor die Formulierung der Antwort bewertet wird, sollte feststehen, ob die richtigen Belege überhaupt abgerufen wurden.

Für einen Richtlinienassistenten gehören dazu eine gewöhnliche Frage zur Erstattung, eine nur durch einen Nachtrag beantwortbare Frage, eine Frage ohne Antwort in den Quellen und eine Frage zu einem Dokument, auf das die anfragende Person keinen Zugriff hat. Eine flüssige Antwort genügt nicht. Zu prüfen sind die Quellenversion, die Berechtigungsgrenzen und die tatsächlichen Belege für die Antwort.

Am Anfang sollte ein fest vorgegebener Retrieval-Ablauf stehen. Eine adaptive Suche lohnt sich dort, wo ein weiterer Schritt zur Beschaffung von Belegen eine misslungene Antwort korrigieren könnte. Der Erklärartikel zu agentischem RAG zeigt, wann diese zusätzliche Entscheidungsschleife ihren Aufwand rechtfertigt.

Was ist kostenlos, wofür fallen Kosten an?

Die Frameworks sind kostenlos. Gehostete Dokumentenverarbeitung, Observability und Bereitstellung werden separat bezahlt. Die folgenden Preise wurden am 13. Oktober 2026 anhand der aktuellen US-Preisseiten der Anbieter geprüft.

LlamaCloud und LlamaParse

LlamaParse ist der Name, unter dem LlamaIndex seine gehostete Dokumentenplattform inzwischen auf der öffentlichen Preisseite führt. Der Zugriff erfolgt über das LlamaCloud-Dashboard. Die Plattform umfasst Parsing, Extraktion und Indexierung. Sie ist ein kommerzieller Dienst neben dem Open-Source-Framework; für den Import von llama_index ist kein Abonnement erforderlich.

Die öffentlich angebotenen Tarife sind Free für $0/Monat mit 10,000 Credits, Starter für $50/Monat mit 40,000 Credits und Pro für $500/Monat mit 400,000 Credits. Enterprise wird individuell kalkuliert. Der Standardpreis für die Nutzung beträgt $1.25 je 1,000 Credits.

Wie viele Credits eine PDF-Seite verbraucht, hängt von der Parsing-Stufe ab: Fast benötigt 1 Credit, Cost-effective 3, Agentic 10 und Agentic Plus 45. Die folgende Grafik rechnet diese veröffentlichten Sätze in den Credit-Gegenwert für dieselbe Menge an Seiten um. Freikontingente, Mindestkosten für Abonnements und Zusatzleistungen sind nicht enthalten; die Grafik stellt deshalb keine Monatsrechnung dar.

Fast liefert Text mit räumlichen Positionsinformationen statt Markdown und eignet sich daher nur, wenn dieses Ausgabeformat zur eigenen Verarbeitung passt. Credits heben auch keine Tarifgrenzen auf: Free und Starter erlauben 5 gleichzeitige Parsing-Aufträge, Pro dagegen 20. Ein Upgrade sollte wegen der benötigten Kapazität oder Features erfolgen. Ein größeres Credit-Paket macht den einzelnen Credit nicht automatisch günstiger. Quellen: Nutzungspreise und Tarifvergleich.

LangSmith

LangSmith ist die kommerzielle Plattform für Observability, Evaluation und Bereitstellung im LangChain-Ökosystem. Sie kann auch Anwendungen anderer Frameworks nachverfolgen, darunter LlamaIndex. Ihre Wahl ist daher unabhängig von der Framework-Entscheidung möglich. Der Anbieter erläutert diese frameworkübergreifende Unterstützung.

Die LangSmith-Preisseite nennt für Developer $0/Monat für einen Nutzerplatz, einschließlich 5,000 Basis-Traces, und für Plus $39 pro Nutzerplatz und Monat, einschließlich insgesamt 10,000 Basis-Traces. Zusätzliche Nutzung wird berechnet. Enterprise-Preise werden individuell vereinbart.

Ein Trace zeichnet die Ausführung einer Anwendung auf und kann mehrere Modellaufrufe und Tool-Ereignisse enthalten. Er ist weder ein Token noch eine einzelne abgerufene Textstelle. Plus enthält eine kleine serverlose Bereitstellung. Zusätzliche Nutzung für die Bereitstellung sollte jedoch separat eingeplant werden; für Agenten im direkten Kundenkontakt empfiehlt der Anbieter eine dedizierte Bereitstellung.

Dieselbe Monatslast mit beiden Frameworks durchgerechnet

Bei gleicher Nutzung derselben Dienste spart ein Framework-Wechsel keine Abonnementkosten. Das folgende Monatsszenario ist bewusst eng gefasst; Anwendung und Index werden separat gehostet:

• Drei Entwickler benötigen Nutzerplätze in LangSmith Plus.
• Die Anwendung erzeugt 20,000 Basis-Traces.
• 1,000 neue PDF-Seiten werden mit der Parsing-Stufe Agentic von LlamaParse verarbeitet.
• Beide Implementierungen verwenden dasselbe Chatmodell, dasselbe Embedding-Modell und dieselbe Token-Menge.
• Der gehostete Index, die Speicherung aufbewahrter Dateien und andere Dokumentenoperationen mit Credit-Verbrauch werden in diesem Szenario nicht genutzt.

Das Parsing verbraucht 1,000 × 10 = 10,000 Credits und passt damit in das monatliche Free-Kontingent, sofern es ansonsten ungenutzt ist. Der tatsächlich zu zahlende Betrag liegt bei $0, obwohl die verbrauchten Credits zum Listenpreis einen Gegenwert von $12.50 haben. Das sind unterschiedliche Größen: Der Credit-Gegenwert erzeugt im Free-Tarif keine Rechnung. Berechnungsgrundlagen: LlamaParse-Tarife und Nutzungssätze.

Der aktuelle LangSmith-Preisrechner weist 0.005 LSU pro zusätzlichem Trace bei $1 pro LSU aus. Drei Nutzerplätze kosten 3 × $39 = $117. Die Trace-Nutzung oberhalb des gemeinsamen Kontingents kostet (20,000 − 10,000) × $0.005 = $50. Die Zwischensumme für die ausgewählten Dienste beträgt $167/Monat mit LlamaIndex und $167/Monat mit LangChain.

Modellinferenz, Embeddings und eigenes Hosting sind in dieser Zwischensumme nicht enthalten. Das vollständige Anwendungsbudget ergibt sich aus den ausgewählten Diensten zuzüglich dieser Kosten. Bei gleicher Modelllast bleiben diese Eingangsgrößen gleich. Verursacht ein Framework zusätzliche Retrieval- oder Modellaufrufe, ändert sich die Last; das muss separat gemessen werden.

Hier gibt es keinen Punkt, an dem eines der Frameworks preislich günstiger wird: Beide bleiben ohne Lizenzgebühren, und beide können dieselben kostenpflichtigen Dienste nutzen. Wer $50 für Dokumentenverarbeitung mit $39 für Observability vergleicht, vergleicht unterschiedliche Leistungen. Für die Kostenentscheidung zählt, welchen Dienst die Anwendung benötigt und wie viel sie davon verbraucht.

Unterschiedliche Abrechnung: Retrieval-Abfragen sind keine Chat-Runden

Beim gehosteten Index v2 von LlamaParse kostet eine Retrieval-Abfrage 1 Credit, eine Chat-Runde dagegen 100 Credits. Hinzu kommen gegebenenfalls Parsing- und Speicherkosten. Zum Standardpreis haben 1,000 Vorgänge vor Berücksichtigung von Kontingenten einen Credit-Gegenwert von $1.25 für Retrieval oder $125 für gehosteten Chat. Das sind verschiedene Vorgänge, keine zwei Preise für dieselbe Antwort. Quelle: Index-Preise.

Für einen kombinierten Stack ist dieser Unterschied relevant. Erzeugt der übergeordnete Agent bereits die endgültige Antwort, muss geklärt werden, ob sein Retrieval-Tool Belege oder eine bereits formulierte Antwort eines anderen Dienstes liefern soll. Diese Wahl beeinflusst sowohl die Schnittstelle als auch die Abrechnung. Ein lokaler Aufruf von query_engine.query() löst nicht automatisch die Gebühr für eine Chat-Runde im gehosteten Index aus. Dafür muss der verwaltete Dienst tatsächlich an der Verarbeitung der Anfrage beteiligt sein.

Wann lohnt sich die Kombination aus LlamaIndex und LangChain?

Beide Frameworks lohnen sich zusammen, wenn sowohl die Dokumentensuche als auch die Koordination von Aktionen eigenständig anspruchsvoll sind. Ein Supportagent, der Richtliniennachträge auslegen und einen Freigabeprozess koordinieren muss, ist dafür ein guter Kandidat. Eine Frage-Antwort-Oberfläche über sauberem Text ist es meist nicht.

LlamaIndex übernimmt dann das Einlesen und Abrufen der Dokumente. Eine eng umrissene Funktion oder ein Dienst liefert relevante Textstellen mit Quellenkennungen und Metadaten zurück. Der LangChain-Agent ruft diese Funktion als Tool auf; LangGraph bildet die Grundlage seiner Ausführung. Die Hinweise des Anbieters zur Kombination der Frameworks beschreiben diese Aufteilung.

Im Supportbeispiel werden die einschlägige Richtlinienpassage, ihre Dokument-ID und die Metadaten zur Revision zurückgegeben. Der Agent kann sie mit dem Bestelldatensatz abgleichen und daraus eine Aktion vorschlagen. Diese Quellenverweise sollten bis in die endgültige Antwort erhalten bleiben, damit die Anwendung prüfen kann, worauf sie beruht.

Eine bereits vollständig formulierte Antwort sollte nicht versehentlich in einer weiteren Schleife zur Antwortgenerierung landen. Eine Zeichenkette aus einer Query Engine ist zwar bequem, kann dem übergeordneten Agenten aber die zugrunde liegenden Textstellen verbergen. Wenn die Prüfung der Quellen zählt, ist ein Retrieval-Ergebnis mit expliziten Belegen vorzuziehen. Formulierte Teilantworten eignen sich dann, wenn diese Aufgabengrenze bewusst gewählt wurde.

Der zusätzliche Aufwand zweier Frameworks liegt in der Wartung: Integrationen für beide Frameworks müssen gepflegt, mehr Abhängigkeiten aktualisiert und eine weitere Schnittstelle überwacht werden. Beide Frameworks sind nur dann gerechtfertigt, wenn sich die Zuständigkeit jedes einzelnen klar benennen lässt, ohne dass beide pauschal „den Agenten übernehmen“.

Framework-Wechsel: Was lässt sich übernehmen, wo drohen Brüche?

Der Migrationsaufwand steckt in Datenkonventionen und Workflow-Zuständen, nicht im Austausch von Importanweisungen. Ein Wechsel von LlamaIndex zu LangChain oder der Einsatz von LlamaIndex als Alternative zu den Retrieval-Komponenten von LangChain sollte bei den Schnittstellenverträgen der bestehenden Anwendung beginnen.

Die ursprünglichen Quelldokumente und exportierbare Metadaten müssen erhalten bleiben. Das gilt ebenso für Dokument-IDs, Zugriffskennzeichnungen, Quellenrevisionen und Zitationsverweise. Sie gehören zur Anwendung. Framework-spezifische Dokument- und Node-Objekte sind lediglich Adapter darum herum.

Vorhandene Embeddings können weiter nutzbar sein, wenn Embedding-Modell, Dimensionen, gespeicherter Text und Datenbankschema kompatibel bleiben. Dass ein neuer Adapter jedes Feld unverändert lesen kann, darf nicht vorausgesetzt werden. Ändern sich die Chunk-Grenzen oder das Embedding-Modell, müssen der betroffene Index neu aufgebaut und die Retrieval-Ergebnisse erneut bewertet werden. Die Anleitung zu Vektorspeichern von LlamaIndex unterscheidet zwischen dem standardmäßigen Speicher im Arbeitsspeicher und dauerhaften Integrationen.

Bei Workflows sollten Gesprächszustand, ausstehende Freigaben und unerledigte Aktionen als eigene Migration behandelt werden. Historische Tool-Aufrufe dürfen nicht allein zur Rekonstruktion des Zustands erneut abgespielt werden: Eine wiederholte externe Aktion kann Folgen haben, selbst wenn das Gespräch korrekt aussieht. Vor der Umstellung des Datenverkehrs muss feststehen, wie alte Sitzungen enden und neue beginnen.

Ein stabiler Dokumentenagent auf LlamaIndex sollte nicht allein wegen des Agentenetiketts ersetzt werden. Ebenso wenig rechtfertigen weniger Codezeilen in einem anderen Beispiel den Austausch eines funktionierenden LangChain-Retrievals. Ein Wechsel lohnt sich, wenn die aktuelle Abstraktion eine konkrete, wiederkehrende Anforderung unnötig schwer ausdrückbar oder wartbar macht.

Häufige Fragen

Der nächste Entwicklungsschritt

Am Anfang steht der Fehler, den der Prototyp beheben muss. Fehlt die richtige Textstelle in den Quellen, empfiehlt sich zunächst ein kleiner Retrieval-Ablauf mit LlamaIndex. Geht es um die Koordination von Tools und freigegebenen Aktionen, bietet sich LangChain an. Dabei muss festgelegt werden, welcher Zustand zwischen den Schritten erhalten bleiben soll. Die erste funktionierende Version sollte so überschaubar sein, dass jede abgerufene Quelle und jede vorgeschlagene Aktion überprüfbar bleibt.

Die Checkliste zur Prüfung von KI-Geschäftsprozessen hilft dabei, vor der Framework-Wahl die Aufgabe und die Anforderungen an Belege festzulegen und zu klären, wo eine Freigabe nötig ist.