RAGHub: ein kuratiertes Verzeichnis für das RAG-Ökosystem

Das Problem: Auswahl ohne Vergleichsmaßstab

RAGHub adressiert ein Auswahlproblem, kein technisches. Die README beschreibt die Lage selbst so: Jeden Tag scheint ein neues Werkzeug oder Framework zu erscheinen, und die Wahl werde "more of an art than a science". Die Frage, die das Projekt aufwirft, ist ungewöhnlich ehrlich formuliert: Ist das Framework von vor drei Monaten noch relevant, oder war es nur Hype, der alte Konzepte neu verpackt? Genau diese Frage lässt sich mit einer Suchmaschine schlecht beantworten, weil Suchergebnisse keine zeitliche Einordnung liefern. RAGHub versucht, sie in einer Tabelle zu beantworten. Die Zielgruppe sind Entwicklerinnen und Entwickler, die eine RAG-Pipeline planen und noch nicht wissen, ob sie eine Bibliothek einbinden oder eine fertige Plattform betreiben wollen. Das Verzeichnis richtet sich ausdrücklich an die Community von r/RAG und ist als lebende Sammlung angelegt, nicht als einmalig veröffentlichter Katalog.

Die Struktur: Tabellen statt Code

Das Repository enthält nach der README-Gliederung mehrere Kategorien: RAG Frameworks, RAG Evaluation and Optimization Frameworks, RAG Engines sowie RAG Resources and Sites und Model LeaderBoards. Die Trennung zwischen Frameworks und Engines ist die inhaltlich wichtigste Entscheidung des Verzeichnisses. Die FAQ definiert sie so: Frameworks wie LangChain oder LlamaIndex sind Bibliotheken, die in eigenen Code eingebunden werden, um eigene Pipelines zu bauen. Engines wie RAGFlow oder Dify sind eigenständige Plattformen mit gebrauchsfertiger RAG-Funktionalität. Wer diese Unterscheidung beim Lesen der Tabellen nicht im Kopf behält, vergleicht Projekte miteinander, die unterschiedliche Dinge leisten. Jeder Eintrag folgt einem festen Spaltenschema: Name, Beschreibung, Website, Github und Aktivität. Die Aktivitätsspalte enthält relative Zeitangaben wie "1h ago" oder "1d ago", die Stars-Spalte bindet Shields.io-Badges ein. Beide Angaben ändern sich laufend, ohne dass sich der Text der Tabelle ändert.

Beitragen: Fork, Tabelle, Pull Request

RAGHub hat keine Installationsroutine, weil es nichts ausführt. Der Beitragsweg ist in der README in vier Schritten beschrieben: Repository forken, den Eintrag in den passenden Abschnitt setzen, das bestehende Tabellenformat einhalten, Pull Request stellen. Für Details verweist die README auf CONTRIBUTING.md. Das ist der gesamte Betriebsablauf. Wer nach einem Befehl sucht, um das Verzeichnis zu starten, findet keinen, und das ist keine Lücke, sondern die Konsequenz daraus, dass das Projekt aus Markdown-Dateien besteht. Die eigentliche Arbeit liegt im Einhalten des Formats: Eine neue Zeile muss dieselben fünf Spalten füllen, und die Aktivitätsspalte verlangt eine relative Zeitangabe, die zum Zeitpunkt des Pull Requests stimmt und danach veraltet. Das ist ein struktureller Wartungspunkt, der bei jedem Beitrag neu anfällt.

Die FAQ als eigentlicher Inhalt

Der substanziellste Teil von RAGHub ist nicht die Liste, sondern die FAQ. Sie beantwortet Fragen, die vor der Werkzeugwahl stehen. Zur Frage, ob eine Vektordatenbank nötig ist, nennt die README vier Optionen mit jeweiligem Einsatzzweck: ChromaDB für Prototyping und einfaches Setup, Qdrant für Produktion und hohe Leistung, Pinecone als verwalteter Enterprise-Dienst, Weaviate für Hybridsuche und GraphQL. Zur Evaluation verweist sie auf ragas für Faithfulness, Answer Relevancy und Context Precision, auf Trulens für Feedback-Funktionen, auf Phoenix für Observability und auf Deepchecks für kontinuierliche Validierung und Drift-Erkennung. Für lokale Modelle nennt sie Ollama, vLLM, LM Studio und LocalAI. Diese Zuordnungen sind kurz, aber sie geben eine Richtung vor, die eine reine Linkliste nicht liefert. Eine Tabelle zu häufigen RAG-Problemen ordnet schlechte Retrieval-Qualität dem Chunking und den Embeddings zu, Kontextfenstergrenzen dem Reranking und Halluzinationen der Frage, ob der abgerufene Kontext vom Modell tatsächlich verwendet wird.

Grenzen: keine Kriterien, keine Versionen, keine Prüfung

RAGHub bewertet nicht. Die README nennt fünf Auswahlfaktoren (Use Case, Scale, Complexity, Integration, Language), aber sie liefert keine Bewertung der gelisteten Projekte entlang dieser Faktoren. Die Beschreibungen in der Tabelle sind knapp, oft ein Halbsatz, und stammen aus der jeweiligen Projektselbstdarstellung. Wer zwischen zwei Frameworks entscheiden muss, bekommt hier keine Entscheidungshilfe, sondern zwei Zeilen mit Werbetext. Auch Versionsnummern fehlen. Es gibt keine Angabe, welche Version eines Frameworks gelistet ist, und die relative Aktivitätsspalte sagt nichts über Release-Kadenz oder Wartungszustand. Das Verzeichnis ist damit nicht als Due-Diligence-Werkzeug geeignet. Ein weiterer Punkt: Die README beschreibt RAG als Technik, die Halluzinationen reduziert, und nennt Halluzinationen gleichzeitig als offenes Problem mit der Lösung, sicherzustellen, dass der abgerufene Kontext vom LLM korrekt genutzt wird. Das ist eine Beschreibung des Problems, keine Lösung. Wer erwartet, dass ein Verzeichnis diese Frage beantwortet, sucht am falschen Ort.

Alternative: awesome-Listen und Kuratierung durch Einzelpersonen

Die naheliegende Alternative sind die sogenannten awesome-Listen auf GitHub, die nach demselben Muster funktionieren: eine README mit thematisch gruppierten Links und einem Beitragsweg per Pull Request. Der Unterschied liegt in der Kuratierung. RAGHub ist an ein Subreddit gebunden und positioniert sich als dessen Sammlung, während awesome-Listen häufig von einer einzelnen Person gepflegt werden und deren Auswahlkriterien widerspiegeln. RAGHub gewinnt dadurch potenziell an Breite, verliert aber an Konsistenz: Was aufgenommen wird, hängt davon ab, wer einen Pull Request stellt. Ein zweiter Unterschied ist die Struktur. RAGHub trennt Frameworks, Engines und Evaluationswerkzeuge und ergänzt eine FAQ mit konkreten Zuordnungen zwischen Problem und Werkzeug. Eine reine awesome-Liste bietet diese Einordnung meist nicht. Dafür fehlt RAGHub die Vergleichstiefe, die eine auf ein einzelnes Werkzeug spezialisierte Dokumentation hat. Wer LangChain, LlamaIndex oder Haystack ernsthaft einsetzen will, liest deren eigene Dokumentation und nicht die Zeile in RAGHub.

Lizenz und Pflegeaufwand

RAGHub steht unter der MIT-Lizenz. Für Nutzer bedeutet das, dass die Inhalte des Verzeichnisses weiterverwendet, kopiert und angepasst werden dürfen, solange der Urheberrechtshinweis und die Lizenzangabe erhalten bleiben. Das betrifft die Sammlung selbst, nicht die verlinkten Projekte: Jedes gelistete Framework hat seine eigene Lizenz, und die README macht dazu keine Angabe. Wer ein gelistetes Werkzeug einsetzen will, muss dessen Lizenz separat prüfen. Der Pflegeaufwand liegt bei den Beitragenden und den Maintainern des Repositories. Die Aktivitätsspalte mit relativen Zeitangaben veraltet fortlaufend, und die Stars-Badges werden extern von Shields.io geladen, sodass die README ohne eigenes Zutun veraltete Zahlen anzeigen kann. Ein Upgrade im Sinne einer neuen Version gibt es nicht, weil es keinen veröffentlichten Release gibt. Änderungen kommen als Commits und Pull Requests auf dem main-Branch an. Wer das Verzeichnis forkt und lokal anpasst, muss selbst entscheiden, wie er mit Aktualisierungen des Originals umgeht, da kein Versionsschema die Zusammenführung steuert.

Redaktionelles Fazit

Wer einen schnellen, redaktionell sortierten Einstieg in RAG-Werkzeuge sucht und die Angaben anschließend selbst prüft, findet in RAGHub eine brauchbare Ausgangsbasis. Wer reproduzierbare Empfehlungen, Versionsangaben oder Kriterien für die Auswahl braucht, sollte zuerst die jeweilige Projekt-README lesen und RAGHub nur als Startpunkt behandeln. Vor jedem Einsatz ist zu prüfen, ob die Tabelle im Repository noch die aktuelle Aktivitätsspalte enthält und ob die verlinkten Repositories erreichbar sind.

Offizielle Quellen

1. Andrew-Jang/RAGHub on GitHub
2. Issues
3. License: MIT
4. README