LightRAG: Graphbasiertes RAG-Framework mit zweistufigem Retrieval

LightRAG und sein Graph-Ansatz

Die README beschreibt LightRAG als leichtgewichtiges Knowledge-Graph-RAG-Framework und effiziente Alternative zu Microsoft GraphRAG. Es nutzt eine zweischichtige Architektur, die sowohl Knowledge-Graphen als auch Vektor-Einbettungen verwaltet, und will die Lücke zwischen herkömmlichem vektorbasiertem RAG und graphbasiertem RAG schließen. Das Projekt ist in Python geschrieben, und die Repository-Metadaten verweisen auf ein EMNLP2025-Papier mit der arXiv-Kennung 2410.05779. Laut README zielt das Framework auf hohe Skalierbarkeit ab und soll Rechenaufwand, langsame Antwortzeiten und Kosten inkrementeller Updates reduzieren; es soll auch mit einem 30B-Open-Source-LLM hohe RAG-Qualität liefern.

Retrieval: local, global und die übrigen Modi

LightRAG bietet fünf Abfragemodi. local ruft Kandidaten-Entitäten und deren direkt zugeordnete Attribute aus dem Knowledge-Graph ab und eignet sich für Fragen zu bestimmten Objekten oder konkreten Fakten. global ruft Beziehungsketten ab, die breite Themen abdecken, für dokumentübergreifendes Schließen und Zusammenfassen. hybrid kombiniert die Ergebnisse von local und global. naive verwendet ohne Knowledge-Graph die Vektorähnlichkeit auf den ursprünglichen Textabschnitten. mix kombiniert local, global und naive; laut README ist mix der Standardmodus und liefert in der Regel die idealsten Abfrageergebnisse, braucht aber etwas länger als naive.

Dokumentanalyse und multimodale Eingaben

Die Dokument-Pipeline unterstützt MinerU, Docling und einen nativen Parser und kann um Drittanbieter-Parser erweitert werden. Die native Engine analysiert Bilder, Tabellen und Formeln in Word- und Markdown-Dokumenten und erkennt Abschnittsüberschriften in Word-Dokumenten. Laut README werden multimodale Inhalte seit v1.5 über den Knowledge-Graph mit dem Fließtext verbunden und bei Abfragen verwendet. Es gibt vier Text-Chunking-Strategien: feste Länge, rekursive Zeichen, Vektor-Semantik und Absatz-Semantik. Die Absatz-Semantik-Strategie richtet die Chunk-Grenzen so weit wie möglich an Überschriften, Absätzen und Tabellen aus.

Speicher-Backends und Aktualisierungsmechanik

LightRAG benötigt vier Speichertypen: KV, Vektor, Graph und Dokumentstatus. Die Standardeinstellungen sind In-Memory-Datenbanken mit lokaler Dateipersistenz, die nur für Entwicklung und Debugging gedacht sind. Für die Produktion können PostgreSQL, MongoDB oder OpenSearch alle vier Speichertypen übernehmen; Milvus, Qdrant, Neo4j und Memgraph sind für spezialisierte Vektor- oder Graph-Speicher aufgeführt. Die README beschreibt inkrementelle Updates und selektives Löschen: Wenn ein Dokument gelöscht wird, kann das System den LLM-Cache aus der Indexierung nutzen, um die betroffenen Entitäten und Beziehungen wiederherzustellen. Sie weist auch darauf hin, dass LightRAG derzeit kein Re-Embedding-Werkzeug bereitstellt.

Server, API und Bereitstellungswege

Das Repository enthält einen LightRAG-Server mit Weboberfläche und REST-API. Die Installation ist über PyPI mit dem api-Extra oder aus dem Quellcode möglich; die README empfiehlt uv für die Paketverwaltung. Es gibt außerdem ein Docker-Compose-Setup und einen interaktiven Einrichtungsassistenten, der eine .env-Datei erzeugt. Die README enthält eine Sicherheitswarnung: Bevor der Server im Netzwerk freigegeben wird, sollte man eine Authentifizierung mit LIGHTRAG_API_KEY oder AUTH_ACCOUNTS plus TOKEN_SECRET konfigurieren oder an 127.0.0.1 binden. Ohne Authentifizierung sind alle Endpunkte öffentlich, und die Ollama-kompatiblen /api/*-Routen bleiben standardmäßig offen.

Modellrollen, Einbettungen und Reranking

LightRAG benötigt LLMs in vier Rollen: EXTRACT für die Entitäts-Relations-Extraktion, QUERY für die Erstellung der finalen Antwort, KEYWORD für die latenzempfindliche Schlüsselwortgenerierung und VLM für Bildeingaben. Die README empfiehlt für Extraktion und Schlüsselwörter ein nicht denkendes Modell und für die Abfrage ein stärkeres Modell. Das Einbettungsmodell muss vor der Dokumentindexierung festgelegt und bei der Abfrage verwendet werden; ein Wechsel erfordert das erneute Einbetten aller Textabschnitte, Entitäten und Beziehungen, und LightRAG bietet dafür kein Werkzeug. Reranking ist optional, fügt etwa ein bis zwei Sekunden Verzögerung hinzu und kann während der Abfrage jederzeit geändert werden.

Evaluationsergebnisse, SDK-Nutzung und Lizenz

Die README enthält eine Leistungstabelle, die LightRAG mit NaiveRAG, RQ-RAG, HyDE und GraphRAG in den Bereichen Landwirtschaft, Informatik, Recht und gemischt vergleicht. LightRAG gewinnt die meisten Vergleiche, aber die Tabelle zeigt, dass GraphRAG bei einigen gemischten Metriken vorn liegt, etwa beim Gesamtwert 50,4% gegenüber 49,6%. Die README empfiehlt für die Integration in ein Projekt die REST-API; das SDK ist für eingebettete Anwendungen oder akademische Forschung gedacht, und einige Funktionen sind nur über das SDK zugänglich. Das Projekt ist unter MIT lizenziert, was Rechte zur Nutzung, Vervielfältigung, Änderung, Zusammenführung, Veröffentlichung, Verbreitung, Unterlizenzierung und zum Verkauf gewährt und die Software ohne Gewährleistung bereitstellt. Die Lizenz macht keine Aussagen zu Sicherheitslage, Support oder Produktionsgarantien.

Bei HKUDS/LightRAG muss die praktische Einordnung an der veröffentlichten README bleiben. Der dokumentierte Stand nennt konkrete Dateien, Befehle oder Konfigurationswerte, die für einen Test wichtiger sind als allgemeine Produktversprechen. Diese Angaben beschreiben den vorgesehenen Weg, sie ersetzen keine Aussage über jede Plattform oder jede Betriebsumgebung. Für die Prüfung von LightRAG sollte dieser Punkt mit einer kleinen, kontrollierten Eingabe nachvollzogen werden. Beobachten Sie die Ausgabe, Fehlermeldungen und erzeugten Dateien und halten Sie fest, welche Teile aus LightRAG stammen und welche Abhängigkeiten von der lokalen Umgebung kommen.

Redaktionelles Fazit

LightRAG steht unter der MIT-Lizenz; die README enthält Bewertungstabellen sowie umfangreiche Konfigurations- und Bereitstellungsdokumentation. Die README trifft keine Aussagen zu Produktionsleistung, Sicherheitsgarantien oder versionsspezifischem Verhalten; diese müssen separat geprüft werden.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes