NirDiamant/RAG_Techniques: 42+ Notebooks als Nachschlagewerk für Retrieval-Pipelines

Was das Repository liefert und was es bewusst nicht liefert

Das Repository beschreibt sich selbst als gemeinschaftlich gepflegter Ort mit über 42 ausführbaren Notebooks, die RAG-Techniken von den Grundlagen bis zum aktuellen Stand abdecken, jeweils mit Intuition, Code und Referenzen. Der entscheidende Punkt steckt im Wort Notebook. Es gibt kein Paket, das man per pip installiert und dann in eine Anwendung importiert. Es gibt keine stabile API, keine Versionszusagen, keine Klassen, die man in eine bestehende Pipeline einhängt. Wer hier landet, bekommt lesbaren und ausführbaren Code, den man kopiert, anpasst und weiterentwickelt. Das ist ein bewusster Zuschnitt. Die Zielgruppe sind Ingenieure und Data Scientists, die verstehen wollen, wie ein Verfahren funktioniert, bevor sie es in eine Bibliothek gießen. Für Teams, die eine fertige Retrieval-Schicht brauchen, ist das der falsche Einstiegspunkt. Die Sprache ist Jupyter Notebook, das Repository ist nicht archiviert, der letzte Push stammt vom 4. September 2026.

Aufbau der Sammlung: Notebooks als Bausteine, nicht als Pipeline

Aus der Struktur des Repositories wird ein Muster erkennbar. Jede Technik bekommt ein eigenes Notebook mit Tutorial-Charakter. Es gibt keine durchgehende Demo-Anwendung, die alle Verfahren zu einer Gesamtarchitektur verbindet. Die Themenliste im Repository nennt unter anderem agentic-rag, embeddings, langchain, llama-index, semantic-search und vector-database. Daraus lässt sich ablesen, dass die Notebooks unterschiedliche Ökosysteme berühren, statt auf einen einzigen Stack festgelegt zu sein. Für den Leser heißt das: Man kann ein Verfahren isoliert nachvollziehen, muss aber selbst entscheiden, welche Bausteine zusammenpassen. Die Verantwortung für die Integration liegt beim Anwender, nicht beim Repository. Das ist bei einer Lernressource folgerichtig, bei einer Produktionsabhängigkeit wäre es ein Problem. Wer die Sammlung als Steinbruch begreift, wird gut bedient. Wer sie als Gerüst für ein System begreift, muss die Architektur selbst entwerfen.

Betrieb: Notebooks starten statt Pakete installieren

Der Einstieg läuft über die Notebooks selbst, nicht über ein Installationskommando des Projekts. Die README gibt dazu ein konkretes Beispiel aus dem Kursumfeld: Ein npm install fügt den KI-Assistenten eines Moduls in Claude Code ein und führt durch das Tutorial. Dieses Kommando gehört zum Kursangebot des Autors, nicht zum Repository als Bibliothek. Für die Notebooks selbst nennt die README keine zentrale Installationsanweisung, keine requirements-Datei und keine Umgebungsvariable. Das bedeutet praktisch: Abhängigkeiten wie langchain, llama-index oder OpenAI-Clients sind pro Notebook zu ermitteln und selbst zu installieren. Wer das unterschätzt, verbringt mehr Zeit mit Umgebungsarbeit als mit dem eigentlichen Verfahren. Der Vorteil dieser Offenheit ist, dass kein Framework den Blick verstellt. Der Nachteil ist, dass es keinen reproduzierbaren Einstiegspunkt gibt, an dem man sich entlanghangeln kann.

Die Lizenzangabe NOASSERTION ist kein Freibrief

GitHub weist für dieses Repository NOASSERTION aus. Das ist keine Lizenz, sondern die Aussage, dass die automatische Erkennung keine eindeutige Lizenz identifizieren konnte. Für Ingenieure, die Code übernehmen wollen, ist das relevant. Ohne klare Lizenzdatei lässt sich nicht ohne Weiteres sagen, unter welchen Bedingungen Code in ein eigenes Produkt einfließen darf. Das ist kein Grund, das Repository zu meiden, aber ein Grund, vor der Übernahme von Code in ein kommerzielles Projekt die Lizenzfrage zu klären. Das gilt besonders, weil die Notebooks teils auf Bibliotheken mit eigenen Lizenzen aufbauen und teils auf Modell-APIs verweisen, deren Nutzungsbedingungen separat gelten. Wer nur liest und lernt, hat dieses Problem nicht. Wer kopiert und ausliefert, schon.

Wartungskosten entstehen beim Leser, nicht beim Projekt

Die Sammlung wird aktiv gepflegt, der letzte Push liegt nur wenige Tage zurück, und im April 2026 erschien mit book-v1.0 ein Begleitbuch mit dem Titel RAG Made Simple: Visual Companion Book. Das spricht für Kontinuität. Es ändert aber nichts daran, wo die Wartungslast liegt. Ein Notebook, das heute gegen eine bestimmte Version einer Vektor- oder LLM-Bibliothek läuft, kann nach deren nächstem Breaking Change nicht mehr ohne Anpassung funktionieren. Das Repository hat keine Testsuite, die solche Brüche automatisch meldet, und keine Versionsmatrix, aus der man ablesen könnte, welche Kombination zuletzt funktioniert hat. Wer ein Notebook übernimmt, übernimmt damit auch die Verantwortung, es bei jeder Änderung der Abhängigkeiten erneut zu prüfen. Bei 42 Notebooks ist das ein laufender Posten, der in keiner Aufwandsschätzung fehlen sollte. Der Nutzen liegt im Verständnis, die Rechnung kommt später.

Wo die Sammlung an ihre Grenzen stößt

Der offensichtlichste Fall, in dem dieses Repository das falsche Werkzeug ist: ein Team braucht eine Retrieval-Schicht, die morgen in Produktion geht und ein Jahr lang ohne Betreuung läuft. Dafür gibt es keine Garantie. Ein zweiter Fall ist die Bewertung von Qualität. Die Notebooks zeigen, wie ein Verfahren implementiert wird, aber aus dem vorliegenden Material geht nicht hervor, dass sie Retrieval-Qualität messen, mit Baseline-Vergleichen arbeiten oder Fehlerraten berichten. Wer wissen will, ob ein Verfahren auf dem eigenen Korpus besser abschneidet als ein anderes, muss diese Messung selbst bauen. Ein dritter Punkt betrifft die Abhängigkeit von externen Modell-APIs. Viele RAG-Verfahren beruhen auf Embedding- oder Generierungsmodellen, und deren Verhalten ändert sich mit jedem Modellwechsel. Ein Notebook, das vor einem Jahr plausibel war, kann mit demselben Code heute andere Ergebnisse liefern. Das ist kein Fehler des Repositories, aber ein Grund, Ergebnisse nicht ungeprüft zu übernehmen.

Abgrenzung zu LangChain und LlamaIndex

Die naheliegende Alternative ist eine der Bibliotheken, die in den Themen des Repositories selbst auftauchen: LangChain oder LlamaIndex. Der Unterschied liegt nicht im Funktionsumfang, sondern in der Rolle. LangChain und LlamaIndex sind Bibliotheken mit versionierten APIs, die man in eine Anwendung importiert und deren Verhalten über Releases hinweg nachvollziehbar ist. Das RAG-Techniques-Repository ist eine Sammlung von Beispielen, die diese Bibliotheken benutzt, um Verfahren zu zeigen. Wer eine Chain mit Retriever, Prompt-Template und Ausgabeparser braucht, wird bei LangChain schneller zu lauffähigem Code kommen. Wer verstehen will, warum ein bestimmter Retriever einem anderen vorzuziehen ist und welche Zwischenschritte dabei entstehen, findet hier die anschaulichere Darstellung. Die beiden Ansätze schließen sich nicht aus. Man liest hier, um zu verstehen, und implementiert dann in der Bibliothek. Wer das Repository als Ersatz für eine Bibliothek einsetzt, verwechselt Referenzmaterial mit Infrastruktur.

Begleitangebot und Interessenlage

Um das Repository herum existiert ein kommerzielles Angebot. Die README bewirbt einen Kurs mit 20 Modulen, jeweils eine Videovorlesung plus ein Praktikum, sowie ein kostenloses Modul zum Ausprobieren. Dazu kommen ein Newsletter und ein Begleitbuch. Das ist kein Widerspruch zur offenen Sammlung, aber es erklärt, warum die README stark auf das Kursangebot zuläuft und warum Sponsoren und Tracking-Links im Dokument auftauchen. Wer das Repository nur als technische Referenz nutzen will, kann diese Teile ignorieren. Wer wissen will, ob der Autor die Verfahren selbst im Produktivbetrieb einsetzt, findet im vorliegenden Material keine Aussage dazu. Die Notebooks zeigen Implementierungen, nicht Betriebserfahrung. Diese Unterscheidung sollte man beim Lesen mitführen, gerade weil die README den Bogen von Prototypen zur Produktion ausdrücklich zieht.

Redaktionelles Fazit

Wer RAG-Verfahren vergleichen und einzelne Bausteine verstehen will, findet hier eine der breitesten Notebooksammlungen überhaupt. Wer eine betriebsfertige Bibliothek mit versionierten APIs sucht, ist hier falsch. Vor dem Einsatz im eigenen Projekt: prüfen, welche Notebooks auf welche Bibliotheksversionen und Modell-APIs verweisen, und ob die Lizenzangabe NOASSERTION für die geplante Verwendung geklärt ist.

Offizielle Quellen

1. Issues
2. NirDiamant/RAG_Techniques on GitHub
3. Project website
4. README
5. Releases