Transcript
00:00:00Letzten Monat war es Loop Engineering, davor Context Engineering, und heute ist der neueste
00:00:05Schrei Graph Engineering. Aber ist das etwas, das man wirklich verstehen muss, oder ist das nur
00:00:11der KI-Hype-Train, der einen schicken Namen auf ein unsinniges Thema klatscht? Nun, in diesem
00:00:17Video werden wir genau diese Frage beantworten – und Spoiler-Warnung: Es ist kein Unsinn.
00:00:23Graph Engineering ist zwar nichts, das für wirklich jedes kleine Projekt relevant ist,
00:00:28aber es ist ein Konzept, das man kennen sollte – besonders, wenn man mit
00:00:33komplexen Loops arbeitet. Wenn das auf Sie zutrifft oder demnächst zutreffen wird, bleiben Sie dran.
00:00:38Graph Engineering ist im Grunde eine Erweiterung oder Weiterentwicklung von Loop Engineering.
00:00:43Wir gehen daher kurz durch, was Loop Engineering überhaupt bedeutet, damit alle auf dem gleichen Stand sind.
00:00:47Alle Loops bestehen im Wesentlichen aus drei Teilen. Erstens: der Trigger. Wie startet
00:00:54das Ganze überhaupt? Idealerweise geschieht das autonom, etwa täglich zu einer bestimmten Zeit oder ereignisbasiert.
00:01:00Schritt zwei ist die Aufgabe: Was genau wird ausgeführt? Und als Schritt drei brauchen wir ein
00:01:07Erfolgskriterium. Wir weisen es an, etwas zu tun. Woher wissen wir, ob es korrekt erledigt wurde?
00:01:13Wenn es nicht richtig war, soll der Durchlauf von vorne beginnen. Idealerweise läuft alles automatisch und die Daten
00:01:19werden gespeichert, sodass man sogar eine Art Selbstverbesserung einbauen kann. Im Grunde
00:01:25brauchen wir aber einen Trigger, eine Aufgabe und eine Möglichkeit zur Überprüfung – und zwar vollautomatisch.
00:01:30In unserem Beispiel hier haben wir einen Loop, der täglich einen Morgenbericht für uns erstellt.
00:01:35Wir haben diesen KI-Agenten. Er läuft jeden Tag um 7 Uhr morgens – das ist unser Trigger.
00:01:42Seine Aufgabe ist es, verschiedene Social-Media-Plattformen zu durchsuchen: YouTube, Twitter und Reddit,
00:01:47um KI-Trends für uns zu finden. Außerdem soll er meine E-Mails prüfen. Danach
00:01:54soll er die Informationen konsolidieren und einen Bericht erstellen. Das ist die Aufgabe. Der Erfolg
00:02:00ist in diesem Fall etwas schwer greifbar. Wie definieren wir, dass der Bericht korrekt war?
00:02:05Nun, wir haben unserem Loop vorgegeben: “Hey, der Bericht braucht solche Informationen und diese Länge.
00:02:11Er muss Links enthalten.” Wir haben ihm also Messkriterien gegeben. Das ist unser
00:02:17Loop. Ganz einfach. Er wird von einem einzelnen Agenten ausgeführt. Wie macht man daraus nun einen Graph?
00:02:25Wie wechseln wir bei genau derselben Aufgabe von Loop Engineering zu Graph Engineering?
00:02:30Ich möchte immer noch jeden Tag den Morgenbericht haben. Schauen wir es uns an. Denn hier rechts ist die
00:02:35per Graph Engineering umgesetzte Version derselben Aufgabe. Wir wollen denselben Bericht.
00:02:40Allerdings haben wir die Anzahl der arbeitenden Agenten erhöht. Genauer gesagt: Statt einem Agenten, der
00:02:46alles erledigt, haben wir mehrere Agenten für spezifische Aufgaben, die miteinander verbunden sind.
00:02:53Wir haben immer noch denselben Trigger: Jeden Morgen um 7 Uhr startet der Ablauf. Aber jetzt haben wir einen Agenten,
00:02:58der sich YouTube ansieht, einen für Twitter, einen für Reddit und einen für
00:03:04E-Mails und so weiter. Jeder dieser Agenten beschafft die erforderlichen Daten und
00:03:09fasst sie selbstständig zusammen. Anschließend schickt er seine Zusammenfassung an den Berichts-Agenten.
00:03:17Dieser sammelt alle Daten und verarbeitet sie zu unserem gewünschten Bericht. Wir könnten
00:03:23sogar noch einen Schritt weitergehen und einen Review-Agenten einsetzen, der sich den
00:03:30generierten Bericht selbstständig ansieht. Er vergleicht ihn mit unseren Vorgaben für einen guten Bericht und prüft:
00:03:36Müssen wir das Ganze nochmal durchlaufen lassen oder können wir es direkt ausgeben? Das ist
00:03:41Graph Engineering auf den Punkt gebracht. Schauen wir uns das genauer an. Sie denken jetzt vielleicht:
00:03:48“Wir haben doch nur ein paar Agenten hinzugefügt. Ich verstehe immer noch nicht, was sich geändert hat.”
00:03:51Ja, wir haben mehr Agenten hinzugefügt – und das aus gutem Grund. Dass Graph Engineering etwas
00:03:58komplexer ist, liegt nicht daran, dass wir Dinge unnötig kompliziert machen wollen. Es liegt daran, dass wir
00:04:03jede einzelne Aufgabe in einen eigenen Agenten verwandelt haben, der seine eigene Form
00:04:09von Loop Engineering ausführt. Was hatten wir vorher? Loop Engineering, richtig? Es erledigt
00:04:14all diese Dinge und prüft die Erfolgskriterien. Aber das geschah auf einer sehr abstrakten Ebene,
00:04:18wobei viele verschiedene Aufgaben auf einmal erledigt wurden. Beim Graph Engineering
00:04:22zoomen wir stattdessen auf eine spezifische Aufgabe heran. Dieser eine Agent ist nur für die YouTube-Analyse
00:04:29und -Recherche zuständig. Auch daraus haben wir ein Loop-Engineering-Konstrukt gemacht. Denn
00:04:34überlegen Sie mal: Es ist zwar auf eine Aufgabe reduziert, aber immer noch Loop Engineering. Wir haben einen Trigger,
00:04:39nämlich 7 Uhr morgens. Wir haben eine Aufgabe: Er muss KI-Infos auf YouTube finden und
00:04:46zusammenfassen. Und drittens haben wir immer noch Erfolgskriterien. Doch weil wir daraus ein
00:04:51Graph-Engineering-System gemacht haben, können wir für jeden einzelnen Schritt sehr genau festlegen,
00:04:57wie Erfolg aussieht. Das könnte zum Beispiel heißen: “Du musst mindestens fünf Quellen finden.” Und:
00:05:03“Die Zusammenfassung muss mindestens zwei Absätze lang sein.” Oder: “Für jede Quelle und jede Information
00:05:09musst du die Relevanz begründen.” Statt eines sehr groben Überprüfungsprozesses,
00:05:16der versucht, alles in ein einziges “Hat geklappt” oder “Hat nicht geklappt” zu quetschen,
00:05:22haben wir es in klare Teilbereiche zerlegt. Warum sollte Sie das interessieren?
00:05:27Erstens steigert es die Qualität. Denn statt einem Agenten, der alles macht, erledigt ein Agent
00:05:33genau eine Sache. Allein schon unter dem Aspekt des “Context Rot” – also dem Qualitätsverlust des Kontextes –
00:05:40und der Tatsache, dass sein Kontextfenster relativ übersichtlich bleibt im Vergleich zu jemandem,
00:05:44der 10 Dinge auf einmal versucht, liefert das schlicht bessere Ergebnisse. Außerdem geht es schneller.
00:05:51Statt eines Agenten für 10 Aufgaben arbeiten vier Agenten parallel an vier Aufgaben.
00:05:56Es ist also schneller, fehlerresistenter und man erkennt sofort, wo ein Fehler liegt. Ich sehe
00:06:03sehr schnell, ob es ein YouTube- oder ein Reddit-Problem ist. Im ersten Fall ist es viel schwerer,
00:06:08die Ursache herauszufiltern und zu verstehen, an welcher Stelle der Fehler lag,
00:06:15weshalb uns der Bericht nicht gefiel und er überarbeitet werden musste. Das liegt wieder daran,
00:06:20dass Erfolgskriterien für jede Teilaufgabe definiert werden können. Das ist im Wesentlichen Graph Engineering
00:06:27und der Grund, warum es wichtig ist. Wir haben nicht nur einen Agenten, sondern eine Reihe von Agenten,
00:06:33die auf unterschiedlichste Weise miteinander verbunden sind. Wir haben ihre Aufgaben auf atomare Ebene zerlegt.
00:06:38Und da es sich um atomare Aufgaben handelt, können wir für jede einzelne sehr präzise festlegen,
00:06:44was getan werden soll und wie Erfolg aussieht. Jeder dieser Agenten ist jetzt im Grunde
00:06:48ein eigenes Loop-Engineering-Konstrukt. Wir haben einfach mehrere Loops miteinander verknüpft. Die nächste Frage
00:06:54an diesem Punkt sollte sein: Wann brauche ich Graph Engineering und wann reicht Loop Engineering?
00:06:58Seien wir ehrlich: Man muss nicht jedes Mal ein superkomplexes Multi-Agenten-System aufbauen.
00:07:04Das ist schlicht nicht nötig. Oft reicht ein einfacher Loop vollkommen aus. Aber es gibt drei Fälle,
00:07:09in denen Sie eine Graph-Engineering-Lösung in Betracht ziehen sollten. Das erste Szenario dafür
00:07:15ist, wenn Kontextprobleme auftreten – insbesondere Context Rot. Wenn ich einen Agenten
00:07:20immer wieder in eine Schleife schicke und er bei jedem Durchlauf vier, fünf, sechs, sieben oder acht Aufgaben erledigt,
00:07:25sodass das Kontextfenster nach jedem Lauf im Bereich von 300.000, 400.000 oder 500.000 Tokens landet,
00:07:29macht es Sinn, die Arbeit aufzuteilen. Es gibt keinen Grund, sich wegen eines überfüllten Kontextfensters
00:07:36mit schlechterer Qualität zufriedenzugeben, wenn das gar nicht sein muss. Szenario Nummer zwei ist,
00:07:41wenn wir eine unabhängige Überprüfung benötigen. Bei echten Loops müssen wir irgendwann das Ergebnis bewerten,
00:07:48also die Sache mit den Erfolgskriterien. Sie müssen sich fragen: Kann der Agent, der das Ergebnis – in diesem Fall
00:07:55den Bericht – erstellt hat, diesen überhaupt objektiv bewerten und sagen, ob er gut war oder nicht?
00:08:01Bei einem einfachen Morgenbericht geht das wahrscheinlich. Das ist nicht so kompliziert und steht nicht viel auf dem Spiel,
00:08:07als dass er nicht sagen könnte: “Der Bericht ist gut.” Zumal es relativ subjektiv ist. Wenn es sich aber um ein
00:08:13kritischeres Thema handelt und wir ein Vier-Augen-Prinzip wollen, sollten wir eher auf
00:08:18Graph Engineering setzen. Dabei prüft ein völlig anderer Agent das, was erstellt wurde.
00:08:24Vielleicht ist das nicht einmal ein Claude-Code-Agent, sondern ein Modell wie GPT-5.6.
00:08:28So oder so ist das ein Szenario mit einer Multi-Agenten-Orchestrierung,
00:08:32bei dem Graph Engineering absolut Sinn ergibt. Der dritte Grund ist das Timing: Wie schnell muss es gehen?
00:08:37In unserem Fall ist eine Graph-Engineering-Automatisierung extrem sinnvoll. Warum sollte ein einziger
00:08:44Agent nacheinander erst YouTube, dann Twitter, dann Reddit und dann Gmail durchsuchen?
00:08:48Selbst Claude Code macht das nicht so. Wenn Sie etwa Deep Research ausführen,
00:08:52recherchiert er all diese Quellen etwa nacheinander, Schritt für Schritt?
00:08:57Nein, er startet rund hundert Sub-Agenten gleichzeitig, um das zu erledigen. Und tatsächlich sind
00:09:02nahezu alle Abläufe, die Claude Code bei der Nutzung von Ultra Code und dynamischen Workflows erstellt,
00:09:08eine Form von Graph Engineering: Mehrere Agenten sammeln Informationen,
00:09:13andere synthetisieren die Daten, und wieder andere führen eine kritische Überprüfung
00:09:17der gesammelten Informationen durch. In diesen komplexen Setups verlässt man sich an keiner Stelle
00:09:23auf einen einzelnen Loop. Es ist stattdessen ein Netzwerk aus verknüpften Loop-Agenten.
00:09:28Aber wie ich eingangs sagte: Die meisten Aufgaben fallen in keine dieser drei Kategorien.
00:09:34Und wenn das so ist, gibt es auch keinen Grund für Graph Engineering. Es ist nur ein Werkzeug
00:09:39in unserem Werkzeugkasten. Manchmal braucht man es, manchmal nicht. Aber wo es passt, bietet es klare Vorteile.
00:09:44Auf der anderen Seite stehen Nachteile, wenn man komplizierte Schritte und Infrastrukturen
00:09:48in Prozesse einbaut, die das gar nicht benötigen. Damit beende ich dieses Video
00:09:52zum Thema Graph Engineering. Ich hoffe, es hat Ihnen einen guten Einblick gegeben, was Graph Engineering
00:09:57eigentlich ist. Sie werden in Zukunft sicher noch sehr viel darüber hören.
00:10:01Wenn Sie Loop Engineering verstehen, denken Sie es einfach so: Es sind mehrere Agenten, die
00:10:07Loop Engineering nutzen. Sie arbeiten zusammen, tauschen sich aus und steigern so die Qualität.
00:10:12Das macht Prozesse schneller und erleichtert die Fehlersuche. Und wenn Sie
00:10:17unsicher sind, ob Sie es für Ihre Aufgabe brauchen, lautet die Antwort wahrscheinlich: Nein. Lassen Sie mich wie immer wissen,
00:10:24was Sie denken! Schauen Sie bei Chase AI Plus vorbei, wenn Sie meine
00:10:27Claude Code Masterclass sehen möchten. Den Link dazu finden Sie unten. Ansonsten: Bis zum nächsten Mal!