Die 7 Stufen von Claude Code & RAG

CChase AI
Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00Lassen Sie uns das Problem von Claud Code und dem Gedächtnis lösen – wir wollen KI-Systeme dazu bringen, zuverlässig und genau
00:00:06Fragen zu vergangenen Gesprächen oder riesigen Dokumentensammlungen zu beantworten. Das ist ein Problem, das wir
00:00:13seit Jahren zu lösen versuchen, und die typische Antwort darauf war RAG: Retrieval Augmented Generation.
00:00:20Obwohl dieses Video den Titel "Die sieben Stufen von Claud Code und RAG" trägt, geht es in Wirklichkeit darum,
00:00:26das Problem von Claud Code, KI-Systemen im Allgemeinen und deren Gedächtnis zu dekonstruieren, und noch
00:00:33wichtiger: Dieses Video soll Ihnen einen Fahrplan geben, der Ihnen zeigt, wo Sie in diesem
00:00:37Kampf zwischen KI-Systemen und dem Gedächtnis stehen und was Sie tun können, um das nächste Level zu erreichen. Während wir also
00:00:43durch diese sieben Stufen von Claud Code und RAG reisen, werden wir eine Reihe von Themen ansprechen, aber
00:00:48wir werden nicht bei GraphRAG oder anderen komplizierten Dingen anfangen. Wir beginnen ganz am Anfang,
00:00:53nämlich bei den grundlegenden Gedächtnissystemen, die nativ in Claud Code integriert sind. Denn so traurig es auch ist,
00:00:59dies ist der Punkt, an dem die meisten Menschen nicht nur beginnen, sondern auch stehen bleiben. Von Auto-Memory und Dingen wie
00:01:04claud.md bewegen wir uns zu externen Tools wie Obsidian, bevor wir schließlich
00:01:10bei den Profis mit den echten RAG-Systemen landen. Auf diesen Stufen werden wir darüber sprechen, was RAG eigentlich ist,
00:01:16wie es funktioniert und welche verschiedenen Arten es gibt: Naive RAG versus GraphRAG versus Agentic RAG, Themen wie
00:01:21Re-Ranker und alles dazwischen. Auf jeder Stufe werden wir das Ganze nach demselben Schema aufschlüsseln:
00:01:25Wir sprechen darüber, was Sie auf dieser Stufe erwartet, welche Fähigkeiten Sie beherrschen müssen, welche
00:01:29Fallen Sie vermeiden sollten und was Sie tun müssen, um auf die nächste Stufe zu gelangen. Was dieses Video
00:01:34nicht sein wird, ist eine extrem tiefgehende technische Erklärung, wie man diese spezifischen Systeme
00:01:40unbedingt einrichtet, denn das habe ich in vielen Fällen bereits getan. Wenn wir über GraphRAG und
00:01:45LightRAG sprechen oder sogar über fortgeschrittenere Themen wie RAG-Anything in diesen verschiedenen
00:01:50Embedding-Systemen – dazu habe ich Videos gemacht, in denen ich von Anfang bis Ende erkläre, wie
00:01:55man das selbst einrichtet. Wenn wir zu diesen Abschnitten kommen, werde ich diese Videos verlinken. Das ist
00:02:00in unser beider Interesse, damit dieses Video nicht fünf Stunden lang wird. Dennoch werden wir für diese Stufen darüber sprechen,
00:02:04was das eigentlich bedeutet, was jedes System bringt und wann man es einsetzen sollte. Aber
00:02:09bevor wir mit Stufe eins beginnen, ein kurzes Wort von unserem heutigen Sponsor: mir selbst. Erst letzten Monat habe ich die
00:02:15Claud Code Masterclass veröffentlicht. Das ist der beste Weg, um von Null zum KI-Entwickler zu werden, besonders wenn man
00:02:21keinen technischen Hintergrund hat. Diese Masterclass ist etwas anders, weil wir uns auf eine
00:02:25Reihe verschiedener Anwendungsfälle konzentrieren, um den Umgang mit Claud Code zu lernen. Einer davon ist zum Beispiel
00:02:31RAG auf Produktionsniveau – wie man die RAG-Systeme, die man in diesem Video sieht, in einem echten Szenario aufbaut und
00:02:37tatsächlich als Teammitglied einsetzt oder an einen Kunden verkauft. Darauf konzentrieren wir uns. Wenn
00:02:42Sie Zugang haben möchten, finden Sie ihn in Chase AI Plus. Einen Link dazu gibt es im angepinnten Kommentar,
00:02:47und wir würden uns freuen, Sie dabei zu haben. Beginnen wir nun mit Stufe eins: Auto-Memory.
00:02:51Dies sind die Systeme, die Claud Code automatisch nutzt, um eine Art Gedächtnisapparat zu erstellen, um
00:02:58sich tatsächlich an Dinge zu erinnern, über die Sie gesprochen haben. Sie wissen, dass Sie hier sind, wenn Sie
00:03:02nie absichtlich etwas eingerichtet haben, um Claud Code zu helfen, sich an den Kontext früherer Gespräche
00:03:09oder an Dinge in Ihrer Codebasis zu erinnern. Und wenn wir von Auto-Memory sprechen, dann ist das
00:03:13buchstäblich der Name des Systems: Auto-Memory. Es ist automatisch aktiviert, wenn Sie Claud Code nutzen,
00:03:18und ermöglicht es Claud Code im Grunde, selbstständig Markdown-Dateien zu erstellen, die
00:03:26Dinge auflisten, die es in diesem speziellen Projekt für wichtig über Sie hält. Dies geschieht rein auf
00:03:32Basis seiner eigenen Intuition aus Ihren Gesprächen. Ich kann diese erstellten Gedächtnisdateien sehen – wie gesagt,
00:03:37das passiert von selbst. Wenn Sie in Ihren .claud-Ordner gehen und dann in "projects", sehen Sie dort einen
00:03:42Ordner namens "memory". In diesem Ordner finden Sie eine Reihe von Markdown-Dateien.
00:03:47Hier sind es vier, und sie sind wie Claud Codes Version von Post-it-Notizen, die besagen: "Oh ja, er hat
00:03:51einmal seine YouTube-Projekt-Wachstumsziele erwähnt, schreiben wir das mal auf." In jedem
00:03:59Memory-Ordner wird es eine memory.md-Datei geben. Wie Sie sehen, enthält diese Datei eine kleine Notiz über
00:04:04eine meiner Fähigkeiten und dann im Grunde ein Inhaltsverzeichnis all dieser Unter-Gedächtnisdateien, das besagt:
00:04:09"Hier gibt es eine zu YouTube-Wachstum, eine zum Umsatz oder zu Referenzen und das ist der Inhalt."
00:04:13Wenn ich also einfach mit Claud Code in meiner Vault-Datei spreche und etwas über YouTube und meine
00:04:19Wachstumsziele erwähne, wird es darauf Bezug nehmen und sagen: "Oh ja, Chase versucht,
00:04:23bis Ende 2026 x Abonnenten zu erreichen." Das ist nett, aber letztendlich nicht wirklich nützlich.
00:04:30Es ist ein bisschen wie bei ChatGPT, wenn es plötzlich zufällige Dinge aus
00:04:35früheren Gesprächen einstreut und man denkt: "Okay, ich hab's verstanden, du hast dir das gemerkt,
00:04:40aber es interessiert mich gerade nicht wirklich." Und ehrlich gesagt ist es etwas seltsam, das ständig wieder aufzubringen.
00:04:44Mir wäre es lieber, es ließe es bleiben. Leider verharren die meisten Menschen auf ihrer Gedächtnis-Reise hier,
00:04:49und das basiert auf einer gewissen, fast schon missbräuchlichen Vergangenheit, die wir alle mit
00:04:54diesen Chatbots haben. Diese Chatbots haben nämlich kein echtes Gedächtnis von Gespräch zu Gespräch, und so
00:05:00haben wir eine Heidenangst davor, ein Chat-Fenster oder eine Terminal-Sitzung zu schließen,
00:05:06weil man denkt: "Oh mein Gott, es wird sich nicht mehr an unser Gespräch erinnern." Das ist
00:05:10tatsächlich ein echtes Problem. Denn was ist die Antwort aller darauf, dass das Chat-Fenster sich
00:05:17an nichts erinnern kann? Nun, die Antwort ist, dass man dieses Gespräch einfach ewig am Laufen hält,
00:05:22weil man nicht riskieren will, dass es alles vergisst, sobald man das Fenster schließt. Diese Angst wurde hier
00:05:26in diesen Chat-Fenstern geboren, angefangen bei ChatGPT und genauso bei Clauds Web-App. Ehrlich gesagt
00:05:31war es früher mit Clauds Web-App noch viel schlimmer. Ich glaube, wir alle erinnern uns noch an die Zeit vor
00:05:35dem 1-Million-Kontextfenster, wo man 30 Minuten lang mit Claud sprechen konnte und er dann sagte: "Bis
00:05:39in vier Stunden." Das Problem ist, dass die Leute dieses fast schon psychotisch-neurotische Verhalten mit ins
00:05:45Terminal genommen haben. Da man es sich dank der 1 Million Kontextfenster jetzt leisten kann,
00:05:50löschen sie die Sitzung nie. Sie reden und reden und reden einfach weiter mit Claud Code,
00:05:55weil sie nicht wollen, dass er vergisst, worüber sie gerade sprechen. Das Problem dabei ist,
00:06:00dass Ihre Effizienz mit der Zeit massiv sinkt, je länger Sie innerhalb derselben Sitzung mit Claud Code
00:06:05sprechen. Das ist die fundamentale Idee der Kontext-Fäulnis (Context Rot). Falls Sie nicht wissen, was das
00:06:10ist: Es ist das Phänomen, dass ein KI-System schlechter wird, je länger ich es in derselben Sitzung,
00:06:16im selben Chat benutze und dabei das Kontextfenster fülle. Das sieht man hier: Claud Code,
00:06:231 Million Kontextfenster. Bei 256.000 Token – also wenn ich erst ein Viertel des Fensters gefüllt habe –
00:06:30liegen wir bei 92 %. Am Ende sind es nur noch 78 %. Je mehr man es also im selben Chat nutzt, desto schlechter wird es.
00:06:36Und das ist eines der Hauptprobleme, das Leute mit KI-Systemen und dem Gedächtnis haben. Ich habe Claud Code,
00:06:42es hat jetzt eine Million Kontext, und doch will ich nicht, dass es das aktuelle Gespräch vergisst. Also schließe ich
00:06:47das Fenster nie, sondern fülle es immer weiter auf. Dann passieren zwei Dinge: Erstens sinkt die Effektivität,
00:06:51wie wir gerade gesehen haben. Zweitens explodiert Ihr Verbrauch, denn die Menge an Token, die bei
00:06:59einer Million oder 800.000 Kontext verbraucht werden, ist wesentlich höher als bei 80.000 Kontext. Das ist
00:07:08nicht das einzige Problem, aber – kurz weg vom Thema – wir sind in einem Ökosystem, in dem sich jeder darüber beschwert,
00:07:12dass Claud Code schlechter geworden sei und der Token-Verbrauch automatisch in die Höhe schießt. Dafür gibt es
00:07:18viele Gründe, aber einer davon ist zweifellos die Tatsache, dass die Leute seit der Einführung der 1 Million Kontext
00:07:24keine Ahnung haben, wie sie ihr eigenes Kontextfenster verwalten sollen. Sie sind bei weitem nicht
00:07:29aggressiv genug damit, die Konversation zu löschen und zurückzusetzen – aber das führt jetzt zu weit.
00:07:34Der Punkt dieser ganzen Diskussion ist: Wenn es um das Gedächtnis in Bezug auf RAG und
00:07:39Claud Code geht, müssen wir die Kontext-Fäulnis immer im Hinterkopf behalten. Wir versuchen ständig,
00:07:44dieses Spannungsfeld zu bewältigen: Einerseits will ich Kontext einspeisen, damit Claud Code Fragen zu vielen
00:07:50Dingen beantworten kann; andererseits will ich nicht, dass der Kontext zu groß wird, weil die Leistung dann abnimmt.
00:07:55Darüber müssen wir in dieser Debatte über das Gedächtnis immer nachdenken.
00:08:02Aber zurück zum eigentlichen Video und Stufe eins: Was machen die Leute auf Stufe eins? Die
00:08:06Antwort ist: Sie machen eigentlich gar nichts. Und weil sie nichts tun, verlassen sie sich einfach
00:08:10auf ein aufgeblähtes Kontextfenster, um sich an Dinge zu erinnern. Sie wissen, dass Sie hier sind, wenn Sie
00:08:15noch nie eine claud.md-Datei bearbeitet haben und wenn Sie nie irgendein Artefakt oder eine
00:08:23Datei erstellt haben, die Claud Code verstehen lässt, was eigentlich los ist, was in der Vergangenheit getan wurde
00:08:27und was in Zukunft zu tun ist. Was müssen wir auf dieser Stufe meistern? Nun, im Grunde,
00:08:31trotz allem, was ich hier geschrieben habe, müssen Sie einfach nur verstehen, dass Auto-Memory nicht ausreicht.
00:08:35Wir müssen eine aktive Rolle einnehmen, wenn es um Claud Code und das Gedächtnis geht. Denn eine Falle auf dieser Stufe
00:08:40ist: Wenn man keine aktive Rolle übernimmt, hat man keine Kontrolle. Und wir müssen kontrollieren, was Claud Code
00:08:44berücksichtigt, wenn es unsere Fragen beantwortet. Um also Stufe eins freizuschalten und zu Stufe zwei zu gelangen,
00:08:50brauchen wir ein explizites Gedächtnis. Wir müssen herausfinden, wie wir das tatsächlich umsetzen können. Welche Dateien
00:08:57muss man bearbeiten und überhaupt kennen, um eine aktive Rolle in dieser Beziehung einzunehmen?
00:09:01Auf Stufe zwei dreht sich alles um eine ganz bestimmte Datei: die claud.md-Datei. Wenn man
00:09:06zum ersten Mal davon erfährt, fühlt es sich wie ein Segen an. Endlich gibt es einen zentralen Ort, an dem ich Claud
00:09:12Code bestimmte Regeln und Konventionen mitteilen kann, denen es immer folgen soll – und es wird es tun.
00:09:16Tatsächlich kann ich Dinge einfügen, an die es sich erinnern soll, und es wird sie nie vergessen. Zuerst fühlt sich das definitiv
00:09:20nach Fortschritt an. Hier ist eine Vorlage einer standardmäßigen claud.md-Datei für ein persönliches Assistenten-Projekt.
00:09:29Claud Code wird automatisch eine claud.md-Datei erstellen, aber Sie haben die Möglichkeit,
00:09:33diese zu bearbeiten oder sie sogar bei Bedarf mit einem Befehl wie /init zu aktualisieren. Die Idee
00:09:38hinter diesem Ding ist, dass es – wieder einmal – wie der heilige Gral der Anweisungen für Claud Code für dieses
00:09:43spezielle Projekt ist. Im Grunde wird Claud Code diese Datei vor jeder Aufgabe, die es
00:09:50ausführt, konsultieren. Wenn Sie also wollen, dass es sich an bestimmte Dinge erinnert, was werden Sie tun? Sie werden
00:09:54es in die claud.md schreiben. Theoretisch ist es ein kleinerer Maßstab als bei etwas wie RAG – wir
00:10:00packen hier keine kompletten Dokumente rein, aber es sind Dinge, an die sich Claud Code
00:10:05immer erinnern soll, und Konventionen, die es befolgen muss. In diesem Beispiel haben wir einen "Über mich"-Bereich,
00:10:09eine Aufschlüsselung der Dateisystemstruktur und wie es eigentlich vorgehen soll,
00:10:14wenn wir Befehle geben. Da dies, wie gesagt, bei fast jedem Prompt referenziert wird, ist Claud Code
00:10:18wirklich gut darin, das zu befolgen. Der Gedanke, sich bestimmte Dinge zu merken – dafür scheint dies ein
00:10:22großartiger Ort zu sein. Aber wir müssen vorsichtig sein, denn wir können es auch übertreiben. Wenn wir uns
00:10:28Studien wie diese ansehen, in denen agents.md evaluiert wurde – und man kann agents.md durch claud.md ersetzen –
00:10:33stellten sie in der Studie fest, dass solche Dateien tatsächlich die Effektivität von großen
00:10:40Sprachmodellen im Allgemeinen verringern können. Und warum ist das so? Nun, genau das, was es so gut macht –
00:10:45die Tatsache, dass es in praktisch jeden Prompt injiziert wird –, ist auch das, was es so schlecht machen kann. Injizieren wir
00:10:51tatsächlich den richtigen Kontext? Haben wir das Rauschen durchdrungen und geben wir wirklich ein sauberes
00:10:57Signal, oder werfen wir einfach nur Dinge hinein, die wir für gut halten? Denn wenn es nicht für
00:11:02praktisch jeden einzelnen Prompt in Ihrem Projekt relevant ist, sollte es dann wirklich hier in der claud.md stehen?
00:11:08Ist das ein guter Weg, um Claud Code sich an Dinge erinnern zu lassen? Ich würde sagen: Nein, nicht wirklich. Und das
00:11:15steht im Gegensatz zu dem, was viele Leute über claud.md sagen und wie man sie strukturieren sollte. Basierend auf solchen
00:11:20Studien und persönlicher Erfahrung gilt: Weniger ist mehr. Kontext-Verschmutzung ist real, Kontext-Fäulnis ist real.
00:11:26Wenn also etwas in der claud.md steht und es nicht für – wie gesagt – praktisch
00:11:32jeden einzelnen Prompt Sinn ergibt, sollte es dann dort sein? Die Antwort lautet nein. Aber die meisten Leute merken das nicht
00:11:37und tappen stattdessen in die Falle eines aufgeblähten Regelwerks. Die Fähigkeiten, die wir stattdessen meistern sollten,
00:11:42sind: Wie erstelle ich Projektkontext mit hohem Signalwert? Wie stelle ich sicher, dass das, was ich tatsächlich
00:11:48hier reinschreibe, Sinn ergibt? Damit einher geht die Erkenntnis über die Kontext-Fäulnis, wie wir
00:11:53schon auf der letzten Stufe besprochen haben. Wenn man das alles zusammennimmt, fühlt sich Stufe zwei so an,
00:11:57als käme man voran – so nach dem Motto: "Hey, ich nehme eine aktive Rolle beim Gedächtnis ein, ich habe diese claud.md-Datei."
00:12:02Aber dann merkt man, dass es nicht wirklich ausreicht. Wenn wir über Stufe drei sprechen und was wir tun können,
00:12:08um dort voranzukommen, dann wollen wir nicht an ein statisches Regelwerk denken, sondern an
00:12:14etwas, das sich weiterentwickeln kann. Es ist etwas, das claud.md mit einbeziehen kann. Anstatt sich darauf zu verlassen,
00:12:18dass claud.md alles erledigt – was wäre, wenn wir claud.md stattdessen als eine Art Indexdatei nutzen,
00:12:24die Claud Code in die richtige Richtung weist? Was meine ich damit,
00:12:30dass claud.md als eine Art Index fungiert und auf andere Dateien verweist? Nun, ich spreche von einer
00:12:37Architektur innerhalb Ihrer Codebasis, die nicht nur eine einzige Markdown-Datei hat,
00:12:41um alle Gedächtnisprobleme in Form von claud.md zu lösen. Ich spreche von mehreren
00:12:47Dateien für spezifische Aufgaben. Ein tolles Beispiel dafür ist das Orchestrierungstool "gsd" (Get Shit Done).
00:12:53Es erstellt nicht nur eine Datei, die sagt: "Das werden wir bauen, das sind die Anforderungen, das haben wir getan und da wollen wir hin."
00:12:56Stattdessen erstellt es mehrere. Sie können hier links sehen: Wir haben eine project.md, eine requirements.md,
00:13:02eine Roadmap und eine State-Datei. Die Anforderungen existieren, damit Claud Code immer weiß und im Gedächtnis behält,
00:13:08was es eigentlich bauen soll. Die Roadmap schlüsselt genau auf, was wir als Nächstes
00:13:12erstellen werden, was wir in der Vergangenheit getan haben und was in der Zukunft ansteht. Das Projekt gibt ihm das
00:13:16Gedächtnis, den Kontext, was wir auf hoher Ebene tun – was ist unser Nordstern? Indem wir
00:13:22Gedächtnis, Kontext und Konventionen in einem solchen System aufteilen, bekämpfen wir die Kontext-Fäulnis
00:13:29und das Problem aus der erwähnten Studie. Denn diese Dateien ständig in jeden
00:13:34Prompt zu injizieren, wie wir es bei claud.md tun, ist eigentlich kontraproduktiv. Es hilft uns nicht, bessere Ergebnisse
00:13:39zu erzielen. Darüber hinaus ist die Aufteilung in Chunks und ein klarer Pfad für Claud Code,” dem es folgen kann,
00:13:44viel effektiver. Es denkt dann: "Ich will herausfinden, wo diese Information ist. Oh, ich gehe zur claud.md.
00:13:49In der claud.md steht: Das sind meine fünf Optionen. Okay, das ist die richtige, die suche ich jetzt raus."
00:13:54Diese Art von Struktur werden Sie zu 100 % auf der nächsten Stufe sehen, wenn wir über
00:13:58Obsidian sprechen. Es ist im Grunde eine einfache Neuinterpretation des Chunking-Systems und der
00:14:04Vektorsimilaritätssuche, die wir in echten RAG-Systemen sehen. Aber natürlich ist das auf dieser Stufe noch
00:14:10eher kleinteilig. Wir sprechen hier über vier Markdown-Dateien, nicht über ein System,
00:14:14das Tausende und Abertausende von Dokumenten verwalten kann. Aber wie Sie mich schon oft
00:14:20sagen gehört haben: Was bedeutet das für Sie? Brauchen Sie ein System, wie wir es auf den Stufen vier,
00:14:26fünf, sechs und sieben besprechen, das so viele Dokumente bewältigen kann? Die Antwort lautet: Vielleicht nicht.
00:14:32Ein Teil dieser RAG-Reise besteht darin, nicht nur zu verstehen, wo man steht, sondern auch: Wo muss man eigentlich hin?
00:14:36Müssen Sie immer auf Stufe sieben sein und wissen, wie man ein agentisches RAG-System innerhalb von Claud Code aufsetzt?
00:14:41Es ist wahrscheinlich gut zu wissen, wie es geht, aber es ist genauso gut zu wissen, wann man es nicht
00:14:46implementieren muss. Manchmal reicht das, was wir in Systemen wie diesem sehen, für viele Leute völlig aus.
00:14:52Es ist also ebenso wichtig zu wissen, wie man es macht, als auch zu wissen: Brauche ich das? Sollte ich das tun?
00:14:58Wenn wir über Stufe drei und State-Dateien sprechen – woher wissen wir, dass wir hier angekommen sind?
00:15:00Nun, wir wissen es, wenn wir uns noch strikt innerhalb des Claud-Code-Ökosystems bewegen. Wir haben noch keine
00:15:04externen Tools oder Anwendungen integriert. Wir sind an dem Punkt, an dem wir einfach
00:15:09mehrere Markdown-Dateien erstellen, um unser eigenes hausgemachtes Gedächtnis-Chunking-System zu bauen.
00:15:14Aber das ist trotzdem sehr wichtig. Wir meistern hier echte Fähigkeiten. Die Idee,
00:15:18Dokumente wirklich zu strukturieren und ein System zu haben, das den Status bei jeder
00:15:23Sitzung aktualisiert. Denn das kann auch bei RAG ein Problem sein: Wie stellt man sicher, dass alles aktuell
00:15:28ist? Wahrscheinlich fangen Sie an diesem Punkt auch an, Orchestrierungsschichten zu nutzen, wie
00:15:33gsd oder Superpowers, die solche Multi-Markdown-Architekturen von selbst erstellen.
00:15:40Aber es gibt hier eine echte Falle: Was wir in diesem Projekt erstellen, ist sehr stark auf genau dieses Projekt zugeschnitten.
00:15:46Es ist etwas umständlich, diese Markdown-Dateien zu nehmen und in ein anderes Projekt zu übertragen. Auf
00:15:51Stufe vier bringen wir daher Obsidian ins Spiel. Das ist ein Tool, um das gerade ein riesiger Hype gemacht wird,
00:15:56und das aus gutem Grund. Wenn Leute wie Andre Karpathy über diese
00:16:00LLM-Wissensdatenbanken sprechen, die sie erstellt haben und die im Grunde auf einem Obsidian-Fundament
00:16:06basieren, und das fast 20 Millionen Aufrufe bekommt, dann sollten wir wahrscheinlich zuhören und sehen, wie das eigentlich funktioniert.
00:16:11Nur als Kontext: Ich habe einen kompletten Deep Dive zu dieser LLM-Wissensdatenbank von Andre Karpathy in Obsidian gemacht.
00:16:18Ich verlinke das oben. Wenn Sie sich also darauf konzentrieren wollen, wie man das aufbaut, schauen Sie sich das oben an.
00:16:22Was ich den meisten Leuten auch sagen möchte, ist: Diese Obsidian-Sache, über die wir hier in
00:16:27Stufe vier sprechen, ist ehrlich gesagt die Stufe, die die meisten Leute anstreben
00:16:32sollten. Denn das reicht für die meisten Menschen und Anwendungsfälle völlig aus. Wenn wir über die Stufen fünf, sechs und
00:16:37sieben sprechen, geht es um echte RAG-Strukturen, und um ehrlich zu sein, ist das für die meisten Leute Overkill.
00:16:43Das ist für die meisten Leute Overkill. Wir reden zwar alle gerne über RAG, als wäre es das Größte – ich verstehe das schon –, aber
00:16:50Obsidian ist diese 80-Prozent-Lösung, die in der Realität für die meisten eher eine 99-Prozent-Lösung ist. Es ist kostenlos,
00:16:56es gibt praktisch keinen Verwaltungsaufwand und für den Einzelanwender erledigt es den Job. Und wenn ich sage, es erledigt den Job
00:17:02für den Einzelanwender, dann meine ich: Es löst das Problem, Claud Code mit einem Haufen
00:17:07verschiedener Dokumente und Markdown-Dateien zu verbinden und daraus genaue, zeitnahe
00:17:13Informationen zu erhalten – und dabei als Mensch den Überblick über diese Dokumente zu behalten. Denn wenn ich
00:17:19diese Dokumente anklicke, ist sofort klar, was darin passiert und welche Dokumente
00:17:24damit verknüpft sind. Klicke ich auf diese Links, gelange ich zu weiteren Dokumenten. Klicke ich dort wieder,
00:17:30kommen noch mehr Dokumente. Für mich als Mensch ist dieser Einblick extrem wichtig.
00:17:36Denn um ganz ehrlich zu sein: Den Einblick, den man durch Obsidian in die Dokumente erhält, halte ich für
00:17:42wertvoller als vieles von dem, was man in RAG-Systemen bekommt, wenn wir von Tausenden und Abertausenden von
00:17:47Tausende von Dokumenten, die in ein Graph-RAG-System eingebettet sind – das sieht visuell toll aus,
00:17:52sieht wirklich beeindruckend aus. Wissen Sie tatsächlich, was darin vor sich geht? Vielleicht schon,
00:17:58aber ehrlich gesagt verlässt man sich irgendwie nur auf die Antworten, die angezeigt werden, und die Links,
00:18:03aber es ist schwer, die Embeddings wirklich zu durchschauen. Man sollte Obsidian
00:18:08und Claude Code besondere Aufmerksamkeit schenken, denn wenn wir über den Weg weg von RAG sprechen,
00:18:13schlage ich jedem – auch Kunden – vor: Lassen Sie uns mit Obsidian anfangen und sehen, wie weit wir das skalieren können,
00:18:20und wenn wir an eine Grenze stoßen, können wir immer noch zu robusteren RAG-Systemen übergehen.
00:18:26Warum nicht die einfache Option versuchen? Wenn es funktioniert, super; es ist kostenlos und kostet kein Geld,
00:18:31im Vergleich dazu, gleich ein RAG-System aufzubauen, was je nach Ziel ziemlich schwierig in der Produktion sein kann.
00:18:35Fangen Sie immer mit den einfachen Dingen an; es ist nie zu schwer, später zu etwas Komplizierterem zu wechseln.
00:18:40Worüber reden wir hier also in Level 4? Wir sprechen davon, die Struktur zu nehmen,
00:18:45die wir in Level 3 aufgebaut haben, also eine Index-Datei, die auf verschiedene Markdown-Dateien verweist,
00:18:50und das einfach hochzuskalieren und dann das externe Tool Obsidian hinzuzufügen, damit es für Sie,
00:18:56den Menschen, einfach wird, diese Verbindungen zu sehen. Das Idealbild dieser Version
00:19:00ist im Grunde das, was Andre Karpathy entworfen hat: der Aufbau einer LLM-Wissensdatenbank auf Obsidian,
00:19:05betrieben durch Claude Code. Und das sieht strukturell so aus: Wenn Sie Obsidian nutzen
00:19:11und es herunterladen – es ist wie gesagt völlig kostenlos, siehe das Video, das ich vorhin gepostet habe –,
00:19:16legen Sie einen bestimmten Ordner als "Vault" fest. Betrachten Sie den Vault als eine Art RAG-System,
00:19:23dieses quasi RAG-System, das Sie erstellt haben. Innerhalb des Vaults architektonieren wir das Ganze,
00:19:30wir strukturieren es einfach mit Dateien. Wir haben den Hauptordner namens Vault
00:19:36und darin erstellen wir mehrere Unterordner. Im Fall von Andre Karpathy spricht er von drei verschiedenen Unterordnern.
00:19:41In der Realität könnten es beliebige Unterordner sein; es muss nur zu dem Thema passen, das wir besprechen.
00:19:47In einem Ordner haben wir die Rohdaten. Das ist alles, was wir einlesen und später strukturieren wollen,
00:19:52damit Claude Code später darauf verweisen kann. Stellen Sie sich vor, Claude Code soll eine Wettbewerbsanalyse
00:19:58von 50 Konkurrenten machen und zieht jeweils 50 Seiten pro Website. Das ist eine große Menge
00:20:03an Informationen – wahrscheinlich 2500 verschiedene Dinge. All das landet in einem Rohdaten-Ordner,
00:20:08das ist sozusagen der Bereitstellungsraum für die Daten. Dann haben wir den Wiki-Ordner.
00:20:14Dort kommen die strukturierten Daten hinein. Wir lassen Claude Code diese Rohdaten nehmen und sie im Grunde
00:20:20in verschiedene Wikipedia-ähnliche Artikel im Wiki-Ordner strukturieren. Jeder Artikel erhält seinen eigenen Ordner.
00:20:28Die Idee ist: Wenn Sie Claude Code nach Informationen fragen, zum Beispiel wenn wir es
00:20:33nach Dingen über KI-Agenten suchen lassen und ich sage: "Claude Code, erzähl mir was über KI-Agenten",
00:20:38genauso wie man ein RAG-System abfragen würde – nun, Claude Code geht in den Vault, vom Vault
00:20:45geht es ins Wiki. Das Wiki hat eine Master-Index-Markdown-Datei. Denken Sie daran,
00:20:50was wir vorhin über die claud.md-Datei besprochen haben, richtig? Sie sehen, wie sich diese Themen
00:20:56durch die verschiedenen Level ziehen. Es schaut in den Master-Index, und dieser sagt ihm,
00:21:00was in diesem Obsidian-RAG-System existiert. Ah, KI-Agenten existieren. Cool. Und wissen Sie, was hier unten passiert?
00:21:08Es gibt dort auch eine Index-Datei, die die einzelnen vorhandenen Artikel beschreibt. Was ich damit sage:
00:21:14Es gibt eine klare Hierarchie, auf die Claude Code zugreifen kann, wenn es Informationen finden will,
00:21:21also Vault, Wiki, Index, Artikel usw. Weil es so klar ist, wie man Informationen findet,
00:21:31und weil es so klar ist, Informationen erst zu finden und in ein Wiki zu verwandeln, können wir ein System
00:21:37mit vielen Dokumenten ohne RAG erstellen – Hunderte, Tausende, wenn man es richtig macht. Denn wenn das System klar sagt:
00:21:44"Ich prüfe den Vault und den Index", und das eine klare Abgrenzung hat, wo alles liegt, nun,
00:21:50dann ist es für Claude Code nicht schwer herauszufinden, wo etwas zu finden ist. So kommt man
00:21:54bei Tausenden von Dokumenten ohne RAG-Struktur aus. Das war in der Vergangenheit sehr schwer,
00:21:58weil die meisten Leute überhaupt nichts strukturieren. Sie haben einfach eine Milliarde Dokumente in einem Ordner.
00:22:02Das ist so, als ob 10 Millionen Dateien auf dem Fabrikboden verstreut lägen. Findet Claude Code das? Nein.
00:22:08Man braucht einfach einen Aktenschrank. Claude Code ist eigentlich ziemlich schlau,
00:22:13und man kann diese Architektur hier in Aktion sehen. Wir schauen uns gerade eine claud.md-Datei an,
00:22:17die sich in einem Obsidian-Vault befindet. Und was steht dort? Nun, sie schlüsselt die Vault-Struktur auf,
00:22:24das Wiki-System, die gesamte Struktur der Unterordner und wie man im Grunde
00:22:30damit arbeitet. Wir nutzen claud.md hier also wieder als eine Art Konventionsdatei. Hier links
00:22:36sehen Sie den Wiki-Ordner. Im Wiki-Ordner ist ein Master-Index, und der listet auf, was darin enthalten ist.” In diesem Fall gibt es nur einen Artikel, über von Claude verwaltete Agenten.
00:22:43In diesem Ordner sehen wir "Claude Managed Agents". Dieser hat seinen eigenen Wiki-Ordner,
00:22:49der die Artikel darin aufschlüsselt, bis man zum eigentlichen Artikel gelangt. Die Schritte sind also sehr klar.
00:22:55Wenn ich Claude Code sage: "Erzähl mir was über die verwalteten Agenten", und wir haben ein Wiki dazu,
00:23:01ist es für Claude sehr einfach, über sein integriertes Grep-Tool danach zu suchen. Es verlinkt mir
00:23:06die eigentliche Markdown-Datei und schlüsselt dann alles auf, was dort passiert. Die Frage in Level 4
00:23:12wird nun wirklich eine Frage der Skalierung: Bei wie vielen Dokumenten funktioniert ein solches System noch?
00:23:16Gibt es einen Punkt, an dem Andre Karpathys System auseinanderfällt? Ich verstehe, dass es ein klarer Pfad ist,
00:23:22dem Claude Code folgen muss – es geht zu den Indizes usw. Hält das auch bei
00:23:262.000 Dokumenten stand? 2.500? 3.000? Gibt es eine genaue Zahl? Die Antwort ist: Wir wissen es nicht wirklich.
00:23:31Es gibt eine frühere Zahl, weil alle Dokumente unterschiedlich sind. Wenn man an eine Grenze stößt,
00:23:37ist es nicht so einfach wie: "Claude Code gibt uns falsche Antworten, weil zu viele Dateien im
00:23:43Obsidian-System sind". Wie viel kostet es Sie an Token, jetzt, wo wir so viele Dateien hinzugefügt haben,
00:23:47und wie schnell geht es? Denn RAG kann in bestimmten Situationen tatsächlich unendlich viel schneller
00:23:52und billiger sein. Wir sehen hier einen Vergleich zwischen rein textbasierten LLMs – das sind die großen Balken –
00:23:59und textbasiertem RAG in Bezug auf die Anzahl der Token, die für die korrekte Antwort benötigt wurden,
00:24:06und die Zeit, die es dauerte. Was sehen wir hier? Wir sehen, dass es zwischen textbasiertem RAG
00:24:11und textbasierten LLMs einen massiven Unterschied gibt, in der Größenordnung von etwa dem 1200-fachen.
00:24:18Ich sage also, dass RAG in diesen Studien 1200-mal billiger und 1200-mal schneller ist als ein reines LLM.
00:24:25Als Kontext: Das wurde 2025 gemacht, nicht mit Claude Code. Diese Modelle haben sich seitdem signifikant verändert.
00:24:33Das sind einfach nur reine LLMs, kein Tool für Programmierer usw. Aber wir sprechen hier
00:24:37von einem 1200-fachen Unterschied. Wenn wir also bewerten: "Sollte ich Obsidian nutzen oder
00:24:48ein RAG-System?", dann ist es nicht so einfach wie: "Bekomme ich die richtige Antwort oder nicht?".
00:24:54Es könnte ein Szenario geben, in dem man mit Obsidian zwar die richtige Antwort bekommt,
00:24:59aber mit RAG wäre es tausendmal billiger und schneller, richtig? Es ist also eine sehr unscharfe Linie
00:25:04zwischen dem Punkt, an dem Obsidian und diese Markdown-Architektur gut genug sind, und dem,
00:25:10an dem wir RAG brauchen. Es gibt keine perfekte Antwort. Ich habe keine perfekte Antwort für Sie.
00:25:15Man muss experimentieren, beides ausprobieren und sehen, was funktioniert, denn das hier ist ehrlich gesagt veraltet.
00:25:18Bei 2025er-Modellen ist der Unterschied zwischen RAG und reinen LLMs vielleicht nicht mehr das 1200-fache,
00:25:25aber wie stark ist diese Lücke geschrumpft? Das ist ein wahnsinniger Unterschied, nicht nur 10-fach,
00:25:32sondern 1200-fach. Es gibt also viel zu wissen, und wie gesagt, man kennt die Antwort nicht im Voraus.
00:25:39Egal wie viele Videos man schaut, niemand wird einem sagen, wo genau die Grenze im Sand verläuft.
00:25:45Man muss es buchstäblich einfach selbst ausprobieren und sehen, was funktioniert, während man die Anzahl
00:25:49der Dokumente erhöht, über die Claude Code Fragen beantworten soll. In diesem Sinne gehen wir über zu Level 5,
00:25:54wo wir endlich über echte RAG-Systeme sprechen und über einige RAG-Grundlagen wie Embeddings,
00:25:59Vektordatenbanken und wie Daten eigentlich durch ein System fließen, wenn sie Teil unserer
00:26:04RAG-Wissensdatenbank werden. Beginnen wir mit dem "Naive RAG", dem einfachsten RAG-Typ,
00:26:10der aber die Grundlage für alles andere bildet. Man kann sich RAG-Systeme grob in drei Teile unterteilt vorstellen.
00:26:16Auf der linken Seite haben wir die Embedding-Phase, dann kommt die Vektordatenbank
00:26:21und schließlich das eigentliche Retrieval mit dem Large Language Model – also eins, zwei und drei.
00:26:27Um dieses Modell am besten zu illustrieren, schauen wir uns den Weg eines Dokuments an,
00:26:33das Teil unserer Wissensdatenbank werden soll. In einem großen RAG-System könnten es Tausende von Dokumenten sein,
00:26:40und jedes Dokument könnte Tausende von Seiten haben. Aber in diesem Beispiel haben wir ein einseitiges Dokument.
00:26:45Wenn wir dieses Dokument zu unserer Datenbank hinzufügen wollen, wird es nicht als ganze Einheit
00:26:50eingelesen. Stattdessen nehmen wir dieses Dokument und zerteilen es in Stücke, sogenannte "Chunks".
00:26:56Diese eine Seite wird also im Grunde zu drei verschiedenen Chunks. Diese drei Chunks werden dann
00:27:03an ein Embedding-Modell gesendet, und dessen Aufgabe ist es, diese drei Chunks in einen Vektor
00:27:08in einer Vektordatenbank umzuwandeln. Eine Vektordatenbank ist einfach eine Variante einer Standarddatenbank.
00:27:15Bei einer Standarddatenbank denkt man an etwas wie eine Excel-Tabelle, richtig? Man hat Spalten
00:27:21und Zeilen. In einer Vektordatenbank sind es keine zweidimensionalen Spalten und Zeilen,
00:27:27sondern hunderte, wenn nicht tausende Dimensionen. Aber für heute stellen Sie sich einfach
00:27:32einen dreidimensionalen Graphen vor, wie Sie ihn hier sehen, und die Vektoren sind Punkte darin.
00:27:37Jeder Punkt wird durch eine Reihe von Zahlen dargestellt. Hier sehen wir zum Beispiel "Bananen",
00:27:43und das wird durch 0,52, 5,12 und 9,31 dargestellt. Das sehen Sie hier oben. Und das geht über hunderte von Zahlen so weiter.
00:27:50Wo jeder Vektor in diesem riesigen mehrdimensionalen Graphen platziert wird, hängt von seiner semantischen Bedeutung ab,
00:27:57also davon, was die Wörter eigentlich bedeuten. Sie sehen hier: Das ist der Bereich für Obst,
00:28:06da haben wir Bananen, Äpfel und Birnen. Dort drüben haben wir Schiffe und Boote.
00:28:13Gehen wir zurück zu unserem Dokument. Nehmen wir an, dieses Dokument handelt von Schiffen aus dem Zweiten Weltkrieg.
00:28:19Jeder dieser Chunks wird in eine Reihe von Zahlen umgewandelt, und diese Zahlenreihen
00:28:24werden als Punkt im Graphen dargestellt. Wo werden sie wohl landen? Wahrscheinlich in diesem Bereich hier,
00:28:31also eins, zwei und drei. So werden Dokumente platziert. Jedes Dokument wird gechunkt,
00:28:37jeder Chunk geht durch das Embedding-Modell, und das Modell fügt sie in die Vektordatenbank ein.
00:28:42Wiederholen Sie das für jedes Dokument. Am Ende, nach ein paar tausend Malen,
00:28:49erhalten wir eine Vektordatenbank, die sozusagen unseren Wissensgraphen darstellt, unsere Wissensbasis.
00:28:54Das bringt uns zu Schritt drei, dem Retrieval-Teil. Wo kommen Sie dabei ins Spiel?
00:28:58Normalerweise – stellen wir Sie mal dar, wir geben Ihnen eine andere Farbe, Sie dürfen rosa sein.
00:29:04Das sind also Sie. Normalerweise sprechen Sie einfach mit Claude Code und stellen Claude Code Fragen
00:29:09über Schlachtschiffe aus dem Zweiten Weltkrieg. In einem normalen Setup ohne RAG passiert folgendes:
00:29:16Das Large Language Model Opus 4.6 schaut in seine Trainingsdaten und gibt Ihnen eine Antwort,
00:29:23die auf diesen Trainingsdaten basiert, also Informationen über Schlachtschiffe aus dem Zweiten Weltkrieg.
00:29:29Aber mit einem RAG-System macht es mehr: Es ruft die entsprechenden Vektoren ab.
00:29:34Es nutzt diese Vektoren, um die Antwort, die es für Sie generiert, zu erweitern – daher
00:29:39Retrieval Augmented Generation (RAG). Das ist die Stärke von RAG: Es erlaubt unseren Modellen,
00:29:44Informationen heranzuziehen, die nicht Teil ihrer Trainingsdaten sind, um die Antwort zu ergänzen.
00:29:51In diesem Beispiel sind es Schlachtschiffe. Ich weiß, das Modell kennt die schon, aber stellen Sie sich vor,
00:29:56es wären interne Firmendaten, die nicht im Web verfügbar sind, und das in großem Stil. Das ist das Argument für RAG.
00:30:02In unserem Beispiel: Wenn wir Claude Code nach Schlachtschiffen aus dem Zweiten Weltkrieg fragen
00:30:06und es ein RAG-Setup ist, passiert Folgendes: Es nimmt unsere Frage und wandelt sie in eine Zahlenreihe um,
00:30:15ähnlich wie die Vektoren hier. Es schaut sich dann an, welche Zahl unsere Frage hat und welche Zahlen
00:30:21die Vektoren haben, und prüft, welche dieser Vektoren dem Vektor der Frage am nächsten kommen.
00:30:25Wie ähnlich sind die Vektoren der Frage? Und dann zieht es eine bestimmte Anzahl von Vektoren,
00:30:32ob nun einen, drei, fünf, zehn oder zwanzig, und lädt diese Vektoren und deren Informationen
00:30:39in das Large Language Model. Jetzt hat das Modell seine Antwort aus den Trainingsdaten plus Informationen
00:30:46aus etwa 10 Vektoren. Das war der Retrieval-Teil. Dann ergänzt und generiert es eine Antwort
00:30:51mit diesen zusätzlichen Informationen. So funktioniert RAG, so funktioniert Naive RAG.
00:30:56Das ist aus mehreren Gründen nicht besonders effektiv. Diese sehr einfache Struktur fällt auseinander,
00:31:02sobald wir darüber nachdenken: Wie zerteilen (chuncken) wir diese Dokumente eigentlich? Ist es zufällig?
00:31:09Nur nach einer bestimmten Token-Anzahl? Gibt es Überlappungen? Sind die Dokumente selbst
00:31:13überhaupt so aufgebaut, dass ein Zerteilen Sinn ergibt? Was ist, wenn Chunk Nr. 3 auf etwas in
00:31:19Chunk Nr. 1 verweist? Wenn wir dann die Chunks abrufen, was, wenn wir nicht den richtigen bekommen?
00:31:25Was, wenn der andere Chunk fehlt, der als Kontext nötig ist, damit das, was Nr. 3 sagt, überhaupt Sinn ergibt?
00:31:31Oft wird das gesamte Dokument benötigt, um Fragen dazu zu beantworten.
00:31:36Diese Idee von stückchenweisen Antworten funktioniert in der Praxis also nicht wirklich.
00:31:42Dennoch war RAG lange Zeit so aufgebaut. Weitere Probleme sind Dinge wie: Was ist,
00:31:47wenn ich Fragen zu den Beziehungen zwischen verschiedenen Vektoren habe? Denn im Moment
00:31:53rufe ich Vektoren isoliert ab. Aber was, wenn ich wissen will, wie Boote mit Bananen zusammenhängen?
00:31:59Klingt wahllos, aber wenn ich es wollte – bei diesem Standard-Vektordatenbank-Ansatz (Naive RAG)
00:32:05ist alles isoliert. Es ist schwer, Informationen zu verknüpfen, und vieles hängt davon ab,
00:32:10wie gut die Originaldokumente strukturiert sind. Sind sie so aufgebaut, dass RAG Sinn ergibt?
00:32:17Über die Jahre haben wir Wege gefunden, diese Probleme zu mildern, zum Beispiel durch Re-Ranker
00:32:22oder Ranking-Systeme, die alle gefundenen Vektoren prüfen und sie mit einem LLM noch einmal
00:32:31hinsichtlich ihrer Relevanz bewerten. Aber im Großen und Ganzen ist dieses Naive-RAG-System
00:32:36aus der Mode gekommen. Dennoch ist es wichtig zu verstehen, wie das auf einer grundlegenden Ebene funktioniert,
00:32:41um fundierte Entscheidungen treffen zu können, wenn man sich für einen robusteren RAG-Ansatz entscheidet.
00:32:46Denn wenn man nicht versteht, wie Chunking oder Embeddings funktionieren, wie soll man dann
00:32:51entscheiden, wie man seine Dokumente strukturiert? Wenn wir über Dinge wie GraphRAG sprechen
00:32:56oder über komplexere Embedding-Systeme wie das brandneue von Google, das nicht nur Text,
00:33:03sondern auch Videos verarbeiten kann – wenn man dieses Fundament nicht versteht, erkennt man die Falle nicht.
00:33:07Und die Falle ist, dass wir im Grunde nur eine schlechte Suchmaschine gebaut haben. Denn bei diesen
00:33:13Naive-RAG-Systemen, wo wir nur Chunks abrufen und die Beziehungen dazwischen nicht verstehen,
00:33:17was ist da der Unterschied zu einem überkomplizierten Strg+F-System? Die Antwort lautet:
00:33:22Es gibt kaum einen Unterschied. Deshalb führen diese simplen, veralteten RAG-Strukturen,
00:33:27die man immer noch überall sieht – wenn jemand sagt: "Hier ist mein Pinecone-RAG-System" oder
00:33:31"Hier ist mein Supabase-RAG" und sie erwähnen nichts über GraphRAG oder anspruchsvolle Re-Ranker –
00:33:36dazu, dass es schlecht sein wird. Die tatsächliche Effektivität liegt dann vielleicht bei 25 %,
00:33:42dass man etwas Richtiges bekommt. Da könnte man fast schon raten. Wenn man das nicht vorher weiß,
00:33:48kann man hinters Licht geführt, verwirrt oder in manchen Fällen sogar regelrecht betrogen werden,
00:33:54indem einem RAG-Systeme verkauft werden, die keinen Sinn ergeben. In Level 5 geht es also nicht darum,
00:33:58diese Naive-RAG-Systeme zu implementieren, sondern zu verstehen, wie sie funktionieren, damit Sie,
00:34:03wenn es Zeit für etwas Anspruchsvolleres ist, wirklich verstehen, was passiert. Denn diese
00:34:07fünfminütige Erklärung von RAG ist leider etwas, das die meisten nicht verstehen, wenn sie sagen:
00:34:12"Ich brauche ein RAG-System". Brauchen Sie das wirklich? Man muss sich auch fragen, welche Art von Fragen
00:34:18man eigentlich an sein System stellt. Wenn man seine Wissensdatenbank nur wie ein riesiges Regelwerk
00:34:23behandelt und nur ganz spezifische Dinge aus diesem System benötigt, dann ist Obsidian
00:34:28wahrscheinlich genug, oder man kommt sogar mit einem Naive-RAG-System aus. Aber wenn wir etwas
00:34:34über Beziehungen wissen müssen, wie X mit Y interagiert, und es zwei separate Dokumente sind,
00:34:38die sich nie gegenseitig erwähnen, und ich das nicht einfach direkt in den Kontext packen kann,
00:34:43weil ich tausende solcher Dokumente habe – genau dann braucht man RAG, und zwar etwas
00:34:48Anspruchsvolleres als einfaches Vektor-RAG. Dann müssen wir über GraphRAG sprechen.
00:34:54Wenn wir über Level 6 von Claude Code und RAG sprechen, reden wir über GraphRAG.
00:34:59Meiner Meinung nach ist dies die unterste Ebene der Infrastruktur, die man schaffen sollte, wenn man RAG nutzt.
00:35:02Hier verwenden wir LightRAG, ein komplett quelloffenes Tool. Ich verlinke oben ein Video,
00:35:09in dem ich genau erkläre, wie man es benutzt und aufbaut. Die Idee von GraphRAG ist offensichtlich:
00:35:13Alles ist miteinander verbunden. Das ist keine Vektordatenbank mit isolierten Vektoren.
00:35:19Das sind viele Dinge, die miteinander verknüpft sind. Wenn ich auf dieses Dokument klicke, sehe ich hier
00:35:23auf der rechten Seite – ich schiebe das mal rüber – die Beschreibung des Vektors, den Namen, Typ,
00:35:29die Datei, den Chunk und, noch wichtiger, die verschiedenen Beziehungen. Und dieser
00:35:34beziehungsbasierte Ansatz führt zu effektiveren Ergebnissen. Hier ist eine Grafik von LightRAGs GitHub,
00:35:39die etwa sechs bis acht Monate alt ist. Anmerkung: LightRAG ist das leichtgewichtigste GraphRAG-System,
00:35:44das ich kenne. Es gibt sehr robuste Versionen, darunter GraphRAG selbst von Microsoft –
00:35:50es heißt buchstäblich GraphRAG. Wenn wir Naive RAG mit LightRAG vergleichen,
00:35:55sehen wir durchweg Sprünge von oft mehr als 100 Prozent, richtig? 31,6 gegen 68,4,
00:36:0024 gegen 76, 24 gegen 75 und so weiter. Laut LightRAG kann es sogar
00:36:05mithalten und schlägt GraphRAG selbst – aber das sind LightRAGs eigene Zahlen,
00:36:10also mit Vorsicht zu genießen. Wenn man sich dieses Wissensgraph-System ansieht, denkt man sofort
00:36:15an Obsidian, weil es sehr ähnlich aussieht. Was wir hier in Obsidian sehen,
00:36:23ist jedoch viel rudimentärer als das, was in LightRAG oder einem anderen GraphRAG-System passiert.
00:36:30Denn diese Verbindungen hier sind alle manuell und teilweise willkürlich. Sie sind nur verbunden,
00:36:35Obsidian viel rudimentärer als das, was in LightRAG oder einem GraphRAG-System passiert.
00:36:4324 zu 76, 24 zu 75 und so weiter. Und laut Light RAG
00:36:49behauptet es sogar, GraphRAG selbst zu schlagen. Aber hey, das sind Light RAGs Zahlen,
00:36:54also mit Vorsicht zu genießen. Wenn wir uns dieses Wissensgraph-System ansehen,
00:36:58denken Sie wahrscheinlich sofort an Obsidian, weil es sehr ähnlich aussieht. Aber
00:37:04was wir hier in Obsidian sehen, ist viel rudimentärer als das, was in Light RAG
00:37:10oder einem anderen GraphRAG-System passiert. Denn diese Verbindungen hier
00:37:16sind alle manuell und etwas willkürlich. Es ist nur verbunden, weil wir
00:37:22verwandte Dokumente gesetzt haben, oder Claude Code dies beim Generieren tat.
00:37:27Theoretisch könnte ich also eine Menge zufälliger Dokumente verbinden, die in Wahrheit
00:37:30nichts miteinander zu tun haben. Da Claude Code nicht dumm ist, macht es das nicht,
00:37:35aber das ist etwas ganz anderes als hier. Dies durchlief ein echtes Embedding-System,
00:37:41analysierte den Inhalt, definierte eine Beziehung und eine Entität. Da passiert
00:37:46in Light RAG viel mehr Arbeit bei der Beziehungsdefinition als in Obsidian. Führt
00:37:52dieser Unterschied tatsächlich zu einer gewaltigen Leistungslücke auf niedriger Ebene?
00:38:02Vielleicht bei riesigen Datenmengen. Auch hier befinden wir uns in einer Grauzone,
00:38:07es hängt von Ihrer Skalierung ab. Niemand kann das beantworten außer Ihnen
00:38:13durch persönliche Erfahrung. Aber verstehen Sie: Diese beiden Dinge sind nicht gleich.
00:38:20Das sind zwei völlig verschiedene Systeme. Eines ist sehr anspruchsvoll, eines eher rudimentär.
00:38:26Um Level 6 abzuschließen: Wir sind bei GraphRAG, wenn wir entschieden haben,
00:38:31dass Obsidian nicht reicht und wir kein "Naive RAG" nutzen können, weil es nicht funktioniert.
00:38:36Wir brauchen etwas, das Entitäten und Beziehungen extrahiert und ein Hybrid-System nutzt.
00:38:43Aber es gibt Fallen und ernsthafte Hindernisse, selbst hier auf Level 6 bei Light RAG.
00:38:48Das hier ist nur Text. Was ist mit scannbaren PDFs? Was ist mit Videos oder Bildern?
00:38:55Wir leben nicht in einer Welt, in der alle Dokumente nur Google Docs sind.
00:39:01Was machen wir also in diesen Fällen? Multimodales Retrieval ist ein großes Thema.
00:39:06Und was wäre, wenn wir diesen Systemen mehr agentische Qualitäten verleihen würden?
00:39:11Ein bisschen mehr KI-Power als Boost? Wenn wir über multimodale Dinge sprechen,
00:39:17bewegen wir uns an die absolute Spitze von RAG im April 2026. Das ist Level 7.
00:39:24Bei Level 7 und "Agentic RAG" wollen wir uns vor allem auf eines konzentrieren:
00:39:31Dinge, die mit multimodalem Ingestion zu tun haben. Wir haben Videos dazu gemacht,
00:39:36wie "RAG Anything", das es erlaubt, Bilder und Nicht-Text-Dokumente zu importieren –
00:39:44denken Sie an PDFs – in Strukturen wie den Light RAG Wissensgraphen hier.
00:39:49Wir haben auch neue Releases wie Gemini Embedding 2, das gerade im März erschien.
00:39:56Es erlaubt uns, Videos direkt in unsere Vektordatenbank einzubetten. Genau dahin
00:40:01geht die Reise. Reine Textdokumente reichen nicht mehr. Wie viel Wissen ist im
00:40:06Internet gefangen, besonders auf YouTube? Wir wollen mehr als nur ein Transkript.
00:40:10Ein Transkript allein reicht nicht aus. Dieses multimodale Problem ist real.
00:40:16Und das sind Dinge, die erst vor wenigen Wochen herausgekommen sind. Level 7 ist auch,
00:40:20wo wir anfangen müssen, auf unsere Architektur und Pipelines zu achten.
00:40:25Es reicht nicht, nur Daten reinzubekommen. Das ist toll, wir haben all diese Verbindungen.
00:40:30Aber wie kommen die Daten dahin? Wie funktioniert das im Kontext eines Teams?
00:40:35Wie kommen die Daten wieder raus? Was, wenn sich Informationen in einem Dokument ändern?
00:40:40Was, wenn jemand es editiert? Wie wird es aktualisiert? Was ist mit Dubletten?
00:40:46Wer darf diese Dinge einpflegen? Bei produktionsreifen Systemen sind das
00:40:50Fragen, die man sich stellen muss. Wenn wir ein agentisches RAG-System wie dieses
00:40:54von n8n betrachten, sieht man, dass der Großteil der Infrastruktur hier
00:41:01nur um Daten-Ingestion und Synchronisierung geht. Nur ein kleiner Teil ist RAG,
00:41:06nämlich genau dort. Wir brauchen Systeme, die Daten bereinigen und prüfen können:
00:41:11Wir haben das hier gerade eingelesen, das war Version 2. Können wir Version 1 löschen?
00:41:17Hier ist eine Ingestion-Pipeline, bei der Dokumente nicht direkt in das System
00:41:21oder Light RAG kommen. Stattdessen landen sie in Google Drive und werden von dort
00:41:27ins GraphRAG-System übertragen und protokolliert. Das sind die Dinge,
00:41:31die über Erfolg oder Scheitern Ihres RAG-Systems entscheiden. Bei Agentic RAG,
00:41:37auch wenn das hier unscharf ist: Wenn ein KI-Agent das ganze Programm steuert –
00:41:42stellen Sie sich einen Chatbot für Ihr Team vor – muss er dann immer die Datenbank abfragen?
00:41:49Wahrscheinlich nicht. In einem Team oder Unternehmen werden Sie Informationen haben,
00:41:54die in einer Datenbank wie dieser als Text liegen. Aber Sie haben wahrscheinlich
00:41:58auch Standard-Postgres-Datenbanken, die man mit SQL abfragen möchte.
00:42:03Bei einem agentischen RAG-System brauchen wir also genau das: Die Fähigkeit,
00:42:08intelligent zu entscheiden: Nutze ich die GraphRAG-Datenbank hier
00:42:15oder mache ich einfach ein paar SQL-Abfragen in Postgres? Das kann komplex werden.
00:42:20Und all das ist vom Anwendungsfall abhängig, weshalb es manchmal schwer ist,
00:42:23diese Videos zu machen und jeden Grenzfall zu treffen. Der Punkt bei Level 7 ist nicht,
00:42:30dass es ein supergeheimes RAG-System gibt. Es geht darum, dass der Teufel
00:42:34im Detail steckt – meist bei der Daten-Ingestion und der Aktualisierung.
00:42:39Aber auch: Wie greift man darauf zu? In einer Demo ist das einfach: Ich gehe
00:42:46zu Light RAG, gehe auf Retrieval und stelle Fragen. Etwas ganz anderes ist es,
00:42:50wenn ein ganzes Team aus verschiedenen Winkeln darauf zugreift. Und Sie
00:42:55wollen sicher nicht, dass jeder einfach Dinge direkt in Light RAG hochladen kann.
00:43:01Für Einzelunternehmer, die ein anspruchsvolles, multimodales RAG-System bauen wollen,
00:43:07empfehle ich die Kombination aus "RAG Anything" und Light RAG.
00:43:14Ich habe dazu ein Video gemacht, das ich oben verlinke. Ich empfehle das aus
00:43:19einigen Gründen: Es ist Open Source und leichtgewichtig. Man verschwendet also
00:43:26nicht Unmengen an Geld oder Zeit, um zu prüfen, ob es für den Anwendungsfall passt.
00:43:31Wir wollen nicht in Systemen feststecken, aus denen es keinen Ausweg gibt,
00:43:37nachdem wir viel Geld investiert haben. Deshalb liebe ich Obsidian und empfehle
00:43:42Dinge wie Light RAG und RAG Anything. Wenn es für Sie nicht funktioniert,
00:43:45haben Sie nur ein paar Stunden verloren. Es ist nicht so, als hätten Sie
00:43:50viel Geld für Microsofts GraphRAG ausgegeben, das keineswegs billig ist.
00:43:56Wann wissen Sie, dass Sie in Level 7 sind? Wenn Sie Bilder, Tabellen und Videos
00:44:02indexieren müssen und ein Agent-System nutzen, das den Pfad zur Antwort wählt.
00:44:06Auf Level 7 integrieren Sie wahrscheinlich all das. Sie haben vielleicht eine
00:44:12Claude-MD-Datei, eine Codebasis mit Markdown-Dateien für schnelles Retrieval,
00:44:16vielleicht nutzen Sie zusätzlich Obsidian in einem Vault, plus Dokumente
00:44:20in einer GraphRAG-Datenbank. Und oben drüber steht ein KI-System, das entscheidet,
00:44:25welche Route bei einer Frage genommen wird. Das ist eine reife Speicher-Architektur.
00:44:33Aber was ist die Falle dabei? Die Falle ist ehrlich gesagt der Versuch, sich in
00:44:40dieses Level und diese Komplexität zu zwingen, wenn es gar nicht nötig ist.
00:44:47Den meisten von Ihnen reicht Obsidian völlig aus. Das ist mehr als genug.
00:44:52Sie brauchen kein GraphRAG und generell oft gar kein RAG. Wenn es nicht offensichtlich ist,
00:44:57dass Sie Level 7 brauchen, und Sie Obsidian noch nicht probiert haben: Lassen Sie es.
00:45:01Es ist wahrscheinlich Zeitverschwendung. Der Punkt dieses Videos war es,
00:45:07Ihnen die verschiedenen Level von RAG, Speicher und Claude Code zu zeigen,
00:45:12was die Probleme, Spannungen und Kompromisse sind und wo Sie stehen sollten.
00:45:18Das Wichtigste ist: Experimentieren Sie einfach. Sie müssen nicht alles wissen,
00:45:24bevor Sie anfangen. Probieren Sie es in aufsteigender Reihenfolge aus.
00:45:28Wenn Markdown-Dateien in einem Claude-System reichen – quasi claude.md auf Steroiden – super.
00:45:34Dann probieren Sie Obsidian. Wenn das nicht reicht, versuchen Sie Light RAG und so weiter.
00:45:39Damit belasse ich es für heute. Wenn Sie mehr über die Produktion
00:45:43von RAG lernen wollen – wie man es für Teams aufsetzt oder für Kunden verpackt –
00:45:47wir haben ein Modul dazu in Chase AI Plus. Schauen Sie mal rein. Ansonsten
00:45:52lassen Sie mich wissen, wie es Ihnen gefallen hat. Wir sehen uns!

Key Takeaway

Die Optimierung des KI-Gedächtnisses erfolgt über sieben Stufen, wobei die Skalierung von einfachen Markdown-Strukturen über Obsidian-Wikis bis hin zu agentischen GraphRAG-Systemen reicht, um die Leistungsdegradation durch Context Rot zu verhindern.

Highlights

Das Kontextfenster von Claude Code verliert bei einer Füllung von 256.000 Token etwa 8 % seiner Genauigkeit und sinkt am Ende auf 78 %.

RAG-Systeme können im Vergleich zu reinen LLM-Abfragen bei großen Datenmengen eine bis zu 1200-fache Kosten- und Zeitersparnis erzielen.

Die Nutzung von Obsidian als strukturiertes Wiki dient für 99 % der Einzelanwender als kostenlose und wartungsfreie Alternative zu komplexen RAG-Datenbanken.

GraphRAG-Systeme wie LightRAG steigern die Antwortqualität gegenüber naivem RAG in Tests um über 100 % durch die Extraktion von Entitäten und Beziehungen.

Moderne Embedding-Modelle wie Gemini Embedding 2 ermöglichen seit März 2026 die direkte Einbettung von Videoinhalten in Vektordatenbanken.

Effektive Gedächtnis-Architekturen nutzen die claud.md-Datei lediglich als Index, der auf spezialisierte Dateien wie project.md oder roadmap.md verweist.

Timeline

Das Problem der Kontext-Fäulnis und Auto-Memory

  • KI-Modelle verlieren drastisch an Effektivität, je voller das Kontextfenster durch lange Sitzungen wird.
  • Das native Auto-Memory-System von Claude Code erstellt eigenständig Markdown-Notizen im .claud-Ordner.
  • Die Angst vor Informationsverlust führt zu neurotischem Chat-Verhalten und explodierenden Token-Kosten.

Das Phänomen der Context Rot beschreibt den Leistungsabfall von 92 % auf 78 % bei Claude Code innerhalb eines 1-Million-Token-Fensters. Viele Nutzer löschen ihre Sitzungen nicht aggressiv genug, was zu unpräzisen Antworten und hohen Kosten führt. Auto-Memory fungiert dabei lediglich als digitale Post-it-Notiz ohne echte strategische Steuerung.

Strukturierung durch claud.md und spezialisierte Markdown-Dateien

  • Überladene claud.md-Dateien verschlechtern die Modellleistung durch unnötiges Rauschen bei jedem Prompt.
  • Spezialisierte Dateien wie project.md oder requirements.md trennen Kontext und Konventionen sauber voneinander.
  • Zentralisierte Index-Dateien weisen der KI den Weg zu relevanten Informationen, anstatt alles gleichzeitig zu laden.

Studien zu agents.md belegen, dass zu umfangreiche Anweisungsdateien die Effektivität mindern, da sie in jeden Prompt injiziert werden. Ein besserer Ansatz ist die Aufteilung in Chunks innerhalb der Codebasis. Tools wie das GSD-Framework nutzen diese Architektur, um der KI einen klaren Pfad durch Roadmap- und State-Dateien zu geben.

Obsidian als skalierbare Wissensdatenbank

  • Obsidian bildet eine 99-Prozent-Lösung für Einzelanwender ohne den Verwaltungsaufwand komplexer Server-Infrastrukturen.
  • Eine klare Hierarchie aus Vault, Wiki und Master-Index ermöglicht die Verwaltung von tausenden Dokumenten ohne formales RAG.
  • Menschliche Einsicht in die Dokumentverknüpfungen ist oft wertvoller als schwer durchschaubare Vektor-Embeddings.

Das von Andre Karpathy inspirierte System nutzt Obsidian als strukturiertes Datei-Archiv, in dem Rohdaten zu Wikipedia-ähnlichen Artikeln verarbeitet werden. Claude Code greift über Grep-Tools auf diesen Vault zu. Dies schließt die Lücke zwischen manuellem Gedächtnis und technischem RAG, solange die Anzahl der Dokumente die Token-Effizienz nicht negativ beeinflusst.

Technisches Fundament: Naive RAG und Vektordatenbanken

  • Naive RAG zerlegt Dokumente in Chunks, wandelt sie in mathematische Vektoren um und speichert sie in multidimensionalen Graphen.
  • Isolierte Vektorabfragen gleichen oft nur einer komplizierten Strg+F-Suche ohne Verständnis für Zusammenhänge.
  • Die Qualität eines RAG-Systems hängt primär von der Chunking-Strategie und der semantischen Bedeutung der Embeddings ab.

Beim Naive RAG werden Textstücke durch Embedding-Modelle in Zahlenreihen transformiert. Diese Punkte werden basierend auf ihrer Bedeutung in Clustern angeordnet, etwa Obst oder Schiffe. Das Hauptproblem liegt in der Isolation der Chunks; fehlt der Kontext benachbarter Textstellen, liefert das System oft nur zu 25 % korrekte oder relevante Ergebnisse.

Fortgeschrittene Vernetzung mit GraphRAG

  • GraphRAG extrahiert Entitäten und definiert explizite Beziehungen zwischen Datensätzen.
  • Open-Source-Lösungen wie LightRAG bieten signifikante Leistungssprünge gegenüber herkömmlichen Vektordatenbanken.
  • Die automatisierte Analyse von Inhalten durch Embedding-Systeme übertrifft die manuelle Verlinkung in Obsidian an Präzision.

Im Gegensatz zu isolierten Vektoren sind in einem Wissensgraphen Informationen wie Dateityp, Name und Beziehungen fest verknüpft. LightRAG demonstriert durchweg Verbesserungen von über 100 % in Benchmarks. Während Obsidian auf willkürlichen menschlichen Links basiert, nutzt GraphRAG KI-Power, um die Architektur der Wissensbasis dynamisch zu definieren.

Agentic RAG und multimodale Pipelines

  • Agentic RAG entscheidet autonom, ob Informationen aus Graph-Datenbanken, SQL-Abfragen oder internem Wissen bezogen werden.
  • Moderne Systeme müssen multimodale Daten wie Bilder, Tabellen und Videos nativ verarbeiten können.
  • Der Fokus produktionsreifer Systeme liegt auf der Daten-Ingestion, Synchronisierung und Zugriffskontrolle für Teams.

Auf der höchsten Stufe steht die Integration verschiedener Datenquellen. Agenten nutzen Tools wie n8n, um Daten aus Google Drive zu synchronisieren und zu bereinigen. Für Einzelunternehmer empfiehlt sich die Kombination aus RAG Anything und LightRAG, da sie kostengünstig und flexibel bleibt. Komplexität sollte erst dann eingeführt werden, wenn einfachere Methoden wie Obsidian versagen.

Community Posts

View all posts