Dein Kontextfenster ist kein Benzintank – Sweet Spots, RAG & Workflow-Design

00:00:00: Hallo und herzlich willkommen zu einer neuen Folge deines KI-Lieblingspodcasts LAIer 8|9. Hallo Barbara!

00:00:08: Hallo Jochen!

00:00:10: Meine Güte, also wenn auf YouTube jemand diese Folge anschmeißt, erschrickt der hundertprozentig, wenn mein Gesicht in dieser Großaufnahme an der Kamera hängt. Ich muss glaube ich mal das Mikrofon anpassen.

00:00:21: Ich komm auch mal ein bisschen näher. Hallo, liebes YouTube-Publikum.

00:00:28: Wir wollen uns heute mal über Kontextfenster, also Context Windows, unterhalten und was da so herumschwirrt. Stichwort RAG. Wenn ich da sitze und die KI mit einem Prompt füttere und erwarte, dass gute Ergebnisse rauskommen, dann muss ich ja in der Regel mehr Kontext anfüttern. Ich muss ihr Kontext mitgeben, damit sie das gut abarbeiten kann. Und jetzt gibt es halt Menschen, die unglaublich viel in diesen Kontext mit reinschmeißen, weil die Kontextfenster ja auch schon unglaublich groß sind. Und die machen das eventuell auch, wenn sie KI-Chatbots bauen. Ich hatte jetzt gerade eine Freundin von mir, die versucht, ein Buch zu schreiben, und die ist jetzt bei Seite 70 oder so. Und sie schmeißt jedes Mal das komplette Buch ins Kontextfenster mit rein.

00:01:11: Das stimmt.

00:01:32: Und da sitze ich dann und frage mich: Ist das schlau? Also ja, mehr Kontext ist gut, aber …

00:01:43: Kann man machen. Sie wird dann aber hoffentlich auf dem Claude-4.6-Modell laufen. Weil ansonsten – ja, das ist das einzige Modell, bei dem sie noch eine Chance hat. Claude hat mit seinem 1-Million-Token-Window, das einigermaßen reliable ist, bis zu 600 Bilder oder ungefähr 600 Seiten PDF verarbeitet. Aber generell könnt ihr euch merken: 200.000 Token ist mal so der Richtwert. Und der Sweet Spot – falls ihr unsere andere Folge über Notion noch nicht gehört habt – der Sweet Spot in Vollproduktionsgeschichten liegt eher so zwischen 130.000 und 180.000, eher weniger sogar, was Token und Token-Window-Functions angeht. Also deswegen: 70 Seiten bereits gebautes Buch? Klingt gruselig.

00:02:36: Mal abgesehen davon, dass ich dich gleich noch kurz löchern werde und dich fragen werde, was A der Sweet Spot ist und B was eigentlich das Problem dabei ist, wenn man dieses Kontextfenster so willenlos vollstopft – ihr Problem ist natürlich, dass ihr relativ schnell auffällt, dass ihr Limit aufgebraucht ist. Das war auch der Grund, warum ich von dieser Nummer erfahren habe. Das Ding muss ja jedes Mal durch dieses Buch durchrödeln.

00:03:00: Das macht halt vor allem keinen Sinn.

00:03:02: Sie bekam dann tatsächlich die Auskunft – wo ich mich bis heute frage, wo zum Teufel steht das, ich habe es bei Claude nie gefunden: „Du hast dein Limit bis Dienstag aufgebraucht."

00:03:12: Das ist bei Claude. In den bezahlten Accounts kannst du deine Nutzungslimits angucken. Und da steht das dann drin, wann du ausgelaufen bist. Wer einen Claude Pro-, Max-, Teams- oder Business-Account hat – Enterprise-Accounts sind anders konfiguriert – der sieht seine Nutzungen. Unter „Meine Nutzung", wenn ihr das Ding auf Deutsch konfiguriert habt.

00:03:33: Muss ich mal wühlen. Alles klar. Ich hab einen Max-Account, ich laufe halt maximal in so Sachen wie „gerade ist sein Limit aufgebraucht", dann gehe ich eine Stunde später ran und dann geht's wieder. Ich bin noch nie in die Verlegenheit gekommen, dass er mir das Limit bis Dienstag gekillt hat.

00:03:51: Kleine Side-Note, Service-Post: Wir nehmen das in der gleichen Woche auf. Claude hat gerade in einem Blogartikel angekündigt, dass im gesamten März mehr Power zur Verfügung steht. Und zwar für alle, die außerhalb der Kernarbeitszeiten arbeiten. Wir linken euch das unten drunter. Das gilt für den gesamten März, funktioniert automatisch und stellt euch mehr Claude-Power zur Verfügung. Wir verlinken das in den Show Notes. Wie lange das gilt – je nachdem, wann ihr diese Folge hört – aber im Zweifelsfall im kompletten März. Usage Promotion von Claude Zebra.

00:04:29: Die versuchen die Infrastrukturen in anderen Stunden auszulasten?

00:04:37: Das ist genau der Grund. Infrastrukturauslastung. Nicht alle sollen auf den gleichen Nutzungszeiten liegen. Du musst Anreizsysteme bilden. Enterprise und so weiter konfiguriert hoffentlich mit Batch Requests. Aber für den Rest macht es Sinn, auch Anreize zu bieten, dass du dich außerhalb der Kerntrafficzeiten bewegst. Nichts ist einfacher, als dem Nutzer zu sagen: Kannst du bitte wann anders bedienen? Und genau deswegen ist das eine gute Variante. Die läuft vom 13. März an. Das heißt, ihr solltet das eventuell schon gesehen und gehört haben. Durch den gesamten März ist mein letzter Stand. Link in den Show Notes.

00:05:21: Okay, weg von Claude im Spezifischen, zurück zum Kontextfenster im Allgemeinen. Du hast vorhin den Sweet Spot erwähnt und uns irgendwas um 120.000, 130.000 Token um die Ohren gehauen. Was ist der Sweet Spot und warum ist der wichtig, wenn die Kontextfenster doch so riesengroß sind?

00:05:43: Grundsätzlich: Jedes Mal, wenn du mit einem Chatbot arbeitest, nutzt du bei jeder Eingabe – egal ob das der Prompt ist, also die Anweisungen, die du schreibst, oder die Zusatzinformationen, die wir meistens als Kontext bezeichnen – dein Gesamtbudget, das du in diesem laufenden Chat hast. Das ist die gesamte Größe der maximalen Anzahl an Token, die verarbeitet werden können, ohne dass das Ding komplett zusammenbricht oder dumm wird. Die meisten unterschätzen das, weil sie denken, dass das unendlich lang ist. Aber jetzt machen wir mal das ganz schön deutsche Beispiel – noch dazu bei den aktuellen Tankpreisen tut's extra weh: Wenn du dein Auto tankst, ob elektrisch oder per Benzin/Diesel, dann hat das eine bestimmte Reichweite. Die kannst du schlecht wegdiskutieren. Keiner kommt auf die Idee zu glauben: Mein Tank hat 800 Kilometer Reichweite, ich fahr damit mal 1000.

00:06:50: Das funktioniert so natürlich nicht. Und dieses Kontextfenster, diese Maximalanzahl an Token, die verarbeitet werden können, ist quasi dein Tank. Aber anders als wenn du an die Tankstelle fährst und nachtankst, haben wir keinen Refresher in dieser technischen Pipeline. Du musst irgendwo neu starten, damit deine Token wieder zur Verfügung stehen. Grundsätzlich ist die sogenannte Token Window Function und damit die Limitierung im verarbeitbaren Kontextfenster das, worüber dein Tank definiert ist.

00:07:30: Kleiner Reminder: Im November 2022 bis in den Februar 2023, als ChatGPT in seiner Rohversion auf dem 3.5er-Modell rausgekommen ist, hatten wir 8.000 Token. Deswegen ist übrigens vieles von dem, was euch in Schulungen oder in sonstigen Sachen erzählt wird, so veraltet wie es nur sein kann. Das Toastbrot ist nicht nur verschimmelt, sondern schon 80 Mal wiedergeboren, weil die technischen Entwicklungen so massiv vorantreiben. Was dann aber auch zu Stilblüten führt, die wir heute diskutieren: „RAG ist tot." Aber die geänderten Capabilities sowohl der LLMs als auch der technischen Verarbeitung sind extrem dynamisch. Das bringt natürlich viel Stress für Unternehmen. Wir haben mal bei 8.000 Token angefangen. Heute können Claude, Gemini und auch OpenAI in bestimmten Varianten eine Million. Achtung: Damit solltet ihr nicht rechnen. Das ist der Sweet Spot.

00:08:18: Der Sweet Spot ist, wo du sagst: Nur weil du theoretisch – bei optimalem Rückenwind, Klimaanlage ausgeschaltet – ihr kennt noch das Drama, als ihr früher die Klimaanlage ausgeschaltet habt, weil ihr kurz vor der Tankstelle wart. Unter optimalen Bedingungen, und die sind nicht immer so hart definiert, könntest du eine Million verbrennen und nutzen. Realistisch, insbesondere wenn du hoch reliable haben willst, liegt dieser Sweet Spot, besonders in Agents-Workflows, bei 130.000 bis 150.000 Token. Auch darauf gerechnet, dass die meisten jetzt stabil auf 200.000 Token laufen.

00:09:10: Das andere kann man mal nutzen und es ist auch ganz spannend, aber viele unserer Zuhörerinnen und Zuhörer sind ja eher an der Full-Prod-Seite. Da muss man ein bisschen anders denken. Könnt ihr es mal Brute-Force an die Belastungsgrenze in euren Accounts bringen? Ja, aber das ist gemeint mit dem maximalen Token-Window von einer Million. Und das ist der Großteil: Wenn euer Prompt quasi 10 bis 20 Zeilen ist und ihr auf der anderen Seite 100 Seiten Dokument hochladet, dann liegt es natürlich mehr im Kontext als am eigentlichen Prompt. Aber gerechnet wird alles zusammen. Und vergesst nicht: Der Output rechnet sich auch in euer Token-Budget rein. Input, Output und die ganzen Läufe – das ist die Rechnung, auf die diese Token laufen. Input und Output Token.

00:09:46: Sprich, wenn ich einen Prompt und ein 70-Seiten-Dokument reinlade, dann habe ich erstmal die Token für den Input. Wenn ich ihm dann zum Beispiel sage „Mach eine Rechtschreibkorrektur" und er spuckt das komplette Dokument wieder aus, dann habe ich einmal 70 Seiten Input, einmal 70 Seiten Output. Vermutlich erreiche ich dann irgendwann damit das Fenster.

00:10:12: Und jetzt ist ja die Nummer mit dem Sweet Spot und dem Ausreizen bis zum Anschlag: Es kann unzuverlässig werden. Was über diesem Sweet Spot liegt, fängt unter Umständen an, Zeug zu vergessen. Wenn ich dem 70 Seiten gebe und sage „Übersetze das bitte ins Englische", könnte es theoretisch passieren, dass nachher 36 Seiten dabei rauskommen, weil er den Rest unterwegs verloren hat. Jetzt mal sehr überspitzt ausgedrückt.

00:10:43: Es ist nicht so, dass er komplette Seiten verliert. So kann man sich das nicht vorstellen. Aber das sind zwei Probleme, die wir als Needle-in-the-Haystack-Problem und Lost-in-the-Middle-Problem definieren. Needle in the Haystack: Es kann eine hochrelevante Information in den Tiefen eines Dokumentes vergraben sein. Stellen wir uns vor, wir schreiben ein Murder Mystery. Und da gibt's den ganz dezenten Hinweis: Als Jochen ums Eck kam, stellte er die Blumenvase, die laut klackerte, auf den Kamin. Das „laut klackerte" ist quasi der Hinweis, dass Jochen in unserem Murder Mystery der Mörder ist – das Messer hat er wohl in der Vase versteckt.

00:11:30: Das ist ein minimales Detail. Als Autorin oder Autor ist natürlich klar, dass du das bewusst eingebaut hast. Der Intent ist dir klar. Aber diese Gedanken kennt dein LLM nicht. Und wenn du das jetzt übersetzen oder formatieren lässt, dann ist die Wahrscheinlichkeit sehr gering, dass das LLM kapiert, dass dieses Detail relevant ist. Wenn diese für uns Menschen oder für bestimmte Business-Kontexte extrem relevanten Details flöten gehen, dann nennen wir das ein Needle-in-the-Haystack-Problem – die Nadel im Heuhaufen, die das arme LLM vergessen hat.

00:12:20: Dazu kommt, dass wir ein generelles Problem mit diesen Riesen-Token-Functions haben. Und das kennt ihr auch schon, sowohl aus Prompting als auch aus Context Engineering. Der Anfang und das Ende sind das, was das LLM am meisten treibt. Der Mittelteil fällt gerne mal hinten runter. Das heißt nicht, dass Seiten vergessen werden, aber dass relevante Infos in der größeren Abteilung verloren gehen. Stellt euch ein Murder Mystery vor: Da muss ich erst Suspense aufbauen, eine Storyline vorne aufsetzen, alle beteiligten Personen vorstellen. Ich bin noch relativ weit weg vom Detail. Dann passiert irgendwas Dramatisches. Dann habe ich dieses einzelne Detail. Das Dramatische passiert vielleicht noch Anfang vom ersten Drittel, das kriegt das Ding noch einigermaßen hin. Aber dann passiert relativ viel Bohai mit den ganzen Details. Dann habe ich das Needle-in-the-Haystack-Problem und das Lost-in-the-Middle-Problem. Dann laufe ich ins volle Drama, dass da noch das bei rauskommt, was ich mir alles ausgedacht habe. Das sind die technischen Gründe, warum du einen Sweet Spot hast, damit du die Wahrscheinlichkeit minimierst, in diese zwei großen technischen Rahmenprobleme reinzulaufen.

00:13:08: Okay, zu diesen zwei technischen Dramen nochmal. Das eine ist Needle in the Haystack: KI hält Details für nicht so relevant, dadurch gehen sie für uns quasi verloren. Und das zweite Problem: Lost in the Middle?

00:13:22: Der Mittelteil geht einfach flöten. Stell dir vor, was dir gerade passiert ist – das war meine schöne Erklärung: Der Mensch verliert den Mittelteil auch. Du konntest dir den Anfang merken, ich habe mit spannenden Details angefangen, dann habe ich quasi … das war jetzt eine Praxisdemonstration.

00:13:41: Genau, das war eine Praxisdemonstration, liebe Zuhörer und Zuhörerinnen.

00:13:58: Da sind wir Menschen genauso anfällig wie das LLM. Wir verlieren es, dann kommt das Ende. Und dann so: Aber was war jetzt in der Mitte? Das LLM hat quasi das gleiche Problem wie wir. Das ist ein sogenanntes Lost-in-the-Middle-Problem. Aber beide zusammen sind eine Klasse von Datenverarbeitungsproblemen.

00:14:15: Das heißt dann für mich in der Praxis, wenn wir noch gedanklich beim Kontextfenster bleiben: Ich sollte, wenn ich sicherstellen möchte, dass ein möglichst großer Teil meiner Informationen im Kontext verarbeitet und im Output auch wieder ausgegeben wird, in diesem Sweet Spot arbeiten?

00:14:37: Nicht nur in diesem Sweet Spot – deswegen nennen wir das jetzt sogar Context Engineering. Zurück zu meinem kleinen Detail mit „es klappert was in der Vase": Das ist eine sehr implizite Information. Das ist etwas, was sich Jochen für sein Murder-Mystery-Buch ausgedacht hat. Das heißt, wenn du Context Engineering betreiben willst, zusammen mit deinem Prompt oder deinen zusätzlichen Kontextdaten, dann wäre das eine Information, die du dem LLM zur Verfügung stellen musst. Und zwar nicht als Verbatim-Text nur, sondern im Zweifelsfall in einer Definition: Das sind die wichtigen Details, das ist der Mörder, und so weiter. Das ist mit Context Engineering gemeint. Deswegen sind PDFs auch so aus der Hölle, oder irgendwelche Sachen, die hoch formatiert sind. Da sind Formatinformationen drin. Die „polluten" deinen Kontext, die rauchen Token. Du hast aber nichts davon. Das ist mit dem Begriff Context Engineering gemeint: Das Bearbeiten des Kontextes, sodass das, was dir als Mensch oder für den Workflow relevant ist, auch beim LLM mit der höchsten Wahrscheinlichkeit ankommt.

00:15:42: Ich nehme nochmal das Beispiel von meiner Kollegin mit dem Buch und bleiben wir bei diesem Murder Mystery. Nebenbei bemerkt: Ich muss irgendwann im Verlaufe der nächsten Minuten darauf hinweisen, dass ich tatsächlich Bücher geschrieben habe. Das war vor der Zeit, bevor ich Kinder bekommen habe. Das eine ist eine High-Fantasy-Reihe, die immer noch auf Fertigstellung wartet. Ich gucke immer, wenn ich auf der Straße bin, ob irgendwelche Fans rumrennen, die mich dann treten, weil ich ähnlich wie George R. R. Martin dieses Ding nie zu Ende gebracht habe. Der Held steht irgendwo in der Mitte und es passiert nichts mehr. Irgendwann passiert es. Das andere ist tatsächlich ein Krimi unter dem Pseudonym Jorge de la Piscina. „Die Blutfinka" heißt das Ding. Findet ihr auch in den Show Notes unten. Sorgt mal wieder für einen Algorithmus-Push bei Amazon. Spaß beiseite. Wenn ich als Autor jetzt diese Seiten nehme und Context Engineering betreiben will und ich habe dieses wichtige Detail – da muss ich ja eigentlich schon so vorgehen, wie ich das normalerweise als Autor machen würde. Man fängt meistens mit einem Plot an, den baut man dann aus, man hält das Wichtigste im Geschehen fest, man baut Personas für die Hauptfiguren. Und das wären alles Informationen, die ich im Kontext mit übermitteln müsste, damit ich sicherstelle: Wenn ich per KI an diesem Buch arbeite, fängt das Beast nicht à la Needle in the Haystack an, wichtige rote Heringe, Mordwaffenhinweise und Sonstiges unterwegs zu verlieren.

00:17:16: Genau das. Du musst immer wieder dran denken, dass du zum Beispiel die Entities definierst, die Personas definierst, die Plotline definierst. Und eben, jetzt kommt's drauf an: Muss es jetzt unbedingt dein komisches Detail mit der Vase sein?

00:18:18: Grundsätzlich: Ob jetzt so ein Detail wie meine Vase-Messer-Aktion wirklich relevant für das LLM ist, das musst du dann auch noch testen. Nicht einfach drauf geben – das ist halt genau das, was mit LLMs immer so ein bisschen das Riesendrama ist. Klar, ich kann euch sagen: Ihr müsst Entities hinterlegen, Personas hinterlegen, Plotline hinterlegen und eventuell diese Details. Aber da ist ein bestimmtes „eventuell" immer mit dran. Das ist, warum wir von Context Engineering sprechen. Und zum Context Engineering gehört, dass das im bestmöglichen Format passiert. Unsere lange Leier von: Benutzt doch Markdown-Formate und nicht irgendein PDF aus der Hölle oder sonst irgendwas. Das ist genau dieser ganze Hintergrund, der zum Themengebiet Context Engineering gehört, und damit indirekt auch zu Prompt Engineering, weil das im Prinzip zusammenarbeiten muss. Und das spielt dann das Ganze in das Finale, das Fass einmal komplett aufzumachen: Wie sieht denn eigentlich euer Workflow aus? In welchen Tools wird dieser Workflow umgesetzt? Weil das ist die eigentliche Limitierung, die wir aktuell haben.

00:19:20: Um das nochmal auf den Punkt zu bringen: Auch wenn ich quasi im Context Engineering alle Strippen gezogen habe, ist noch lange nicht gewährleistet, dass dieses klappernde Messer tatsächlich nachher in der Vase drin ist. Der Zufall spielt immer noch eine Rolle bei diesem Thema und ich muss hinterher einfach prüfen.

00:19:46: Nicht Zufall. Bitte um Gottes Willen LLMs nicht mit Zufall in Verbindung bringen – sonst erscheine ich nachts in euren Träumen oder stehe ungefragt in euren Büros. Es ist die Wahrscheinlichkeitsrechnung. Und nein, das kann man schon. Jetzt wird es aber dramatisch: Das kann man schon alles irgendwie tun, nur nicht so trivial, wie die meisten Leute sich das denken. Du musst es halt testen. Wer einen normalen Claude-Account hat, ist ja nicht in der Lage – gut, mit Co-Work geht es schon mal besser. Aber das kann man schon. Und das ist der große Unterschied: Wir bauen und basteln irgendwas rum und Vibe-Coden versus wir sind in vollproduktiven Systemen. Natürlich können wir einen Chatbot oder ein RAG oder sonst was bauen, wo wir eine extrem hohe Reliability im Retrieval haben. Also auch sicherzustellen, dass so ein Detail wirklich nachher da ist, wo es sein soll – klar geht das. Die Frage ist dann immer: Wie viel Aufwand, ja oder nein.

00:20:44: Und die Frage ist auch: Sitze ich in einem Consumer-Tool, wo ich im Prinzip nur die Möglichkeiten habe, die mir die Oberfläche zur Verfügung stellt? Das, was ich prompten kann, was ich im Context Engineering noch machen kann …

00:20:57: Genau, mit Projekten und sonst irgendwas. Aber ansonsten, deswegen muss man halt auch immer sagen: Achtung. Ich habe gehört, ich werde ein bisschen tiefer mit der Stimme. Wir haben hier angeblich sehr viel Corporate-Zuhörer. Das ist übrigens euer kleines Problem mit Microsoft Copilot und allen selbstgebauten Tools. Denn diese Tools können noch nicht mal das, worüber wir gerade schon bei Claude lästern. Ja, jetzt hat sie es gesagt. Eure Tools, die meisten Corporate Tools, können noch nicht mal das, was heute Consumer-Tools leisten. Und die Consumer-Tools laufen schon massiv in ihre Problematiken hinein. Lasst es sacken. Wenn ihr dazu vertiefen wollt, schreibt uns gerne an. Das ist eine der größten Herausforderungen auf Enterprise-Level gerade.

00:21:38: Das ist tatsächlich im kleineren Corporate-Umfeld auch für mich von Anfang an eine Beobachtung gewesen. Der Versuch, eigene Oberflächen, eigene KI-Tools zu machen, hinkte immer so brutal den Consumer-Tools hinterher. Was dann dazu führte, dass die Power-User im Unternehmen das Zeug gemieden haben wie der Teufel das Weihwasser, weil du nicht dieselben Möglichkeiten hattest wie im Prosumer-Bereich.

00:22:10: Genau. Und heute siehst du diese Diskrepanz immer stärker. Du hast häufig so eine Basic-Funktionalität wie einen Projektordner – die du wirklich brauchst, um irgendwie clever und professionell damit zu arbeiten – einfach nicht. Das ist sehr dramatisch, ist aber auch nur ein Symptom eines größeren Problems.

00:22:30: Das Thema mit den Projekten. Bevor wir – du hast das Wort RAG ja schon gedroppt – diese Spur etwas weiter verfolgen: Es ist kein roter Hering, es war tatsächlich ein Hinweis auf den Täter, um in der Analogie zu bleiben. Projekte. Ich habe dann überlegt. Da, wo es bei mir zuverlässiger wird im Arbeiten, ist, wenn ich mein Wissen in Chunks aufgeteilt in einem Projekt verteile. Das war auch der erste Rat, den ich meiner Kollegin gegeben habe. Dann bin ich aber – muss ich ehrlich sagen – ein bisschen an den Rand meines Wissens gestoßen. Ich habe mich zum Beispiel gefragt: Was tut Claude eigentlich, wenn ich das Projekt füttere? In irgendeiner Form ist es wahrscheinlich Context Engineering, aber …

00:23:19: Es ist eine saubere, gechunkte RAG-Pipeline. Deine Kontextdaten, also du hast Anweisungen und deine Projektdaten. In deinen Projektdaten wird vorgechunkt in einer bestimmten Art und Weise, sodass sie dann – das ist weniger Context Engineering, viel mehr klassisches Retrieval Optimization. Daher kommt der Begriff RAG übrigens eigentlich: dass das quasi vorbereitet und aufbereitet wird.

00:23:44: Das heißt, wenn sie jetzt – bleiben wir bei dem Buch – ihre 70 Seiten als ein Buch hochlädt. Da war ich schon am Überlegen: Ist es sinnvoller, das kapitelweise oder am Stück da reinzufüttern? Wenn man dann zum Beispiel sagt: Pass auf, ich will die Mordszene nochmal überarbeiten …

00:24:03: Jetzt kommen wir dahin, wo wir ehrlich sein müssen. Liebe Corporates, heute bash ich euch wieder. Erst zähle ich euch den Microsoft Copilot an, dann eure eigenen Tools, und jetzt wird's noch dramatischer. Dein Beispiel ist genau das, warum ich auf diese Fragen – die mir täglich gestellt werden, nicht nur von dir, das ist kein Vorwurf, sondern es wird mir konstant in jedem Meeting gestellt – „Aber wie soll ich das machen?" sage: Freunde und liebe Freundinnen, ihr fangt an der falschen Stelle an. Du kannst die schönste Kontextoptimierung bauen. Du kannst das schönste Prompt-Design veranstalten. Wenn du kein Verständnis hast, wie ein Workflow AI-driven aussehen muss – und nein, das ist nicht eine Tool-Frage, ob wir jetzt N8N einführen – dann beinhaltet das: Wenn wir unsere Workflows nicht redesignen, und zwar nicht nur optimieren, nicht unsere Human Workflows, sondern wirklich AI-driven Workflow Design betreiben, dann kommt da hinten raus immer nur Crap. Und wenn ich wieder höre „Die AI kann das nicht" und „Eigentlich hat die AI nur Schuld" – nee, Freunde der Nacht: Das ganze Ding heißt hier Layer 8, weil das Problem vor dem Rechner sitzt. Layer 9, weil die Organisation nicht bereit ist, ihre Workflows zu redesignen. Und wenn ihr euch jede einzelne Studie anguckt, die den ROI von AI in Frage stellt, kommt man immer zum gleichen Fazit: Hat jemand angefangen, an der richtigen Stelle Workflow-Design zu betreiben? Dann hast du – Spoiler – Return on Investment für jede einzelne AI-Initiative. Tust du das nicht, dann schmeißt du die Kohle zum Fenster raus. Deswegen kann ich diese Frage – „Was soll sie machen?" – nicht pauschal beantworten. Vielleicht zwei, vielleicht acht verschiedene Projekte anstellen. Eins, wo sie die Persona-Entities aufrechterhalten, eins, das sie zum Plot-Checking verwendet. Die Anzahl an Murder Mysteries, die ich in meinem Leben geschrieben habe, ist null. Also muss ich da sehr theoretisch rangehen. Das ist das eigentliche Bottleneck. Und du siehst: Wir haben März 2026 und die Leute haben immer noch nicht verstanden, dass sie sich an die Maschine anpassen müssen, um den vollen Hebel zu nutzen. Das will der Mensch im Enterprise und Corporate nicht hören, weil das Ding soll ja das menschengemachte Problem lösen. Und damit beißt sich die Katze dummerweise echt böse in den Schwanz.

00:26:25: Ein menschliches Problem bei dieser Erkenntnis, zu sagen „Ich muss meinen Workflow anpassen, ich brauche vielleicht ein eigenes Projekt, das sich nur mit den Personas beschäftigt, und eins mit dem Plot" – das ist ja schon so ein bisschen Bequemlichkeit. Weil wenn man dieses Projekt mal aufgesetzt hat – ich merke das bei mir selber – ich habe Projekte, bei denen ich ganz genau weiß, ich müsste das eigentlich aufsplitten. In denen ein einzelner Content-Workflow komplett abgenudelt wird und das Ding verliert gelegentlich die Spur. Ich muss es wieder zurückführen und ich weiß genau: Ich müsste das neu aufbauen. Aber es ist halt Arbeit.

00:27:06: Es ist halt Arbeit. Und ihr vergesst scheinbar alle, dass ihr jetzt alle zu kleinen Mathematikern geworden seid, wo die Grundarbeit und die Vorarbeit der entscheidende Punkt ist. Das ist Bequemlichkeit. Und im Corporate-Kontext: Warum kann das denn das LLM nicht einfach? Also die Diskussion führe ich täglich. Ich kann euch nicht vor der eigenen Faulheit retten. Shoutout an meine ukrainische Verwandtschaft. Gott hab sie selig. Aber wenn du mit einer ukrainischen Mama und Großmutter aufgewachsen bist, ist Disziplin wohl tiefer drin. Die Faulheit ist an der Stelle das Problem. Und diese Tools – das haben wir in diversen Folgen ja auch schon immer wieder gesagt – sind Faulheitsfütterer. Ja, natürlich: Wenn du in der Theorie mit einem durchschnittlichen oder unterdurchschnittlichen Ergebnis zufrieden bist, dann hört nicht diesen Podcast – der sorgt für Stress und schlaflose Nächte. Willst du aber der Realität ins Auge blicken, wo wir 2026 stehen – in der größten Disruption, die gleichzeitig, richtig gemacht, das größte Enablement sein kann und dein größter Hebel für deine persönliche und Unternehmenszukunft – dann muss man drei Schritte zurückgehen und sagen: Okay, Butter bei die Fische, wie sieht es jetzt wirklich aus? Und ganz ehrlich: Wir zwei dürfen uns ja privat und geschäftlich erlauben, in unseren Unternehmen faul zu sein. Fair Deal. Aber die Faulheit der Unternehmen, weil sie es nicht kapieren, kostet in der Zukunft Arbeitsplätze. Das hat nichts mit AI zu tun. Sondern einfach nur die Kosten der Faulheit, die dich irgendwann in den Hintern beißen. Da hat keine AI den Job abgeschafft, sondern schlicht und nur die Faulheit.

00:28:42: Wir marschieren schon in Richtung RAG, du hast schon einiges erwähnt. Ich greife das nochmal auf, weil ich habe es verstanden, aber ich will sicherstellen, dass jeder Zuhörer und jede Zuhörerin auch mitkommt. Was in einem Claude-Projekt – und nebenbei: Auch wenn Claude uns keine Kohle bezahlt, die Projekte funktionieren für mich dort einfach am besten, deswegen werdet ihr das relativ oft hören. Du hast schon ein bisschen erklärt: Die Informationen in den Projektdateien, dann gibt es die Anweisungen, und es teilt das in Chunks auf. So sortiere ich das für mich ein: Claude schneidet sich genau den Teil raus, den er braucht, um meinen Prompt und meine Aufgabe zu bearbeiten. Und der Chunk liegt dann möglichst im Sweet Spot, würde ich mutmaßen.

00:29:44: Mehrere Chunks. Das ist nicht einer, das sind ganz viele Chunks.

00:29:47: Okay, und da sind wir dann in diesem Bereich. Meine erste Befürchtung war, dass alles, was in der Datei ist, einfach komplett in den Kontext gekippt wird. Ich weiß aber aus der Praxis, dass das definitiv nicht sein kann. Deswegen freut mich die Erklärung, dass das in Richtung RAG geht und Claude das in Chunks aufteilt. Lass uns mal kurz erzählen, was da im Groben passiert.

00:30:09: Damit wir jetzt endlich auch mal ein anderes Tool reinschmeißen – wobei, ehrlicherweise muss man sagen: Die einzigen beiden Competitors im Enterprise-Bereich sind Google mit Gemini und Anthropic mit Claude. OpenAI liefert immer noch gute, interessante Modelle. Die LLMs, die in letzter Zeit von OpenAI rausgekommen sind, sind gut, aber die Arbeitsoberfläche, die OpenAI zur Verfügung stellt, und alles, was Workflows und Sonstiges angeht, ist gerade nicht up to date. Aber in der aktuellen Diskussion haben wir drei Player: OpenAI, Anthropic und Google. Alle anderen sind quasi schon non-existent. Deswegen reden wir über nicht wahnsinnig viele andere Foundational Labs. Eins unserer Lieblingstools, sowohl in kleineren als auch in größeren Projekten, ist NotebookLM. Und in NotebookLM könnt ihr extrem viel Daten reinschmeißen – das hat eine saubere Retrieval-Argumentation im Hintergrund laufen.

00:31:30: Jetzt kommen wir zum ganzen Drama. Wenn ihr in einem Projekt oder so in dem Kontext arbeitet: Wenn die Daten nicht gleich im Chatfenster drin sind, dann ist es die Ingestion und der sogenannte Retrieval-Mechanismus. Der Retrieval-Mechanismus versucht genau das: Du hast einen Prompt, eine Anweisung. Und anstatt jetzt das Kontextfenster blank mit einer Million Token vollzuballern, versucht der Retrieval-Mechanismus, genau das Relevante für die Anfrage zu finden. Dafür gibt es verschiedenste Mechanismen. Dieses Retrieval, wenn es in einem RAG läuft – in so einer Retrieval Augmented Generation, das heißt, dass innerhalb des Mechanismus weitere LLMs zur Verfügung gestellt werden – dann haben die meisten diese Idee: Vektordatenbanken, Embeddings und so weiter. Aber grundsätzlich steht RAG, oder das R, in erster Linie für den Retrieval-Mechanismus.

00:33:00: Der Retrieval-Mechanismus basiert eben auch auf verschiedenen Arten, die wir Chunking nennen. Chunking ist nichts anderes, als dass wir Text und Daten in Happen verfügbar machen. Der Elefant wird in kleinen Happen gegessen. Das ist Chunking. Für Chunking haben wir verschiedene Techniken. Klassischerweise gibt es so was wie Semantic Chunking. Es gibt Section-Aware Chunking. Es gibt ganz viele Chunking-Technologien. Jetzt merkt ihr auch: Wenn ihr einfach irgendwas – sei es in NotebookLM, in andere Tools, in Claude Projects oder auch einen Folder durchsuchen lasst mit einer Google-Drive-Connection – dann habt ihr keine Möglichkeit, das zu beeinflussen. Das heißt, ihr müsst auf das zurückgreifen, was euch der Tool-Anbieter zur Verfügung stellt. Die geben sich da sehr viel Mühe, weil sie wissen, dass ihre Tools sonst nicht gut genug funktionieren. Das ist aber auch genau der Unterschied, warum Claude-Projekte besser funktionieren als OpenAI-Projekte aktuell: Ihr hängt an der technischen Leistungsfähigkeit eures Tool-Anbieters. Und warum Copilot so schlecht ist – Microsoft, das ist völlig danebengegangen und wird auch scheinbar nicht gefixt – daran hängt ihr quasi an dieser Stelle. Und wenn du natürlich sagst: Moment mal, ich hab als Unternehmen oder auch als halber Nerd, ganzer Nerd oder Vollprofi natürlich viel mehr Möglichkeiten, dann kannst du das selber strukturieren. Dann kannst du viel mehr Context Engineering machen, arbeitest mit verschiedenen Retrieval- und Search-Algorithmen oder Verbindungen, um ein optimales Ergebnis zu bekommen, das auf deinen Workflow, deinen Prompt, deinen Krimskrams optimiert ist. Und deswegen ist RAG nicht tot. RAG hat insbesondere in Unternehmen eine hohe Relevanz. Da muss man im Zweifelsfall ein paar tausend PDF-Dokumente verfügbar machen. Das wird sicher nicht mit einem Kontextfenster funktionieren.

00:33:55: Das R – Retrieval – von RAG habe ich jetzt sehr explizit erklärt gehört. Wie geht es denn mit A und G weiter, wenn ich mal blöd fragen darf?

00:34:01: Augmented Generation. Retrieval Augmented Generation ist – jetzt sehr vereinfacht dargestellt – nichts anderes, als dass innerhalb des Retrievals nicht ein super statischer, deterministischer Algorithmus rüberläuft, sondern auch nach dem direkten Retrieval LLM- oder LLM-ähnliche Algorithmen zur Verfügung kommen können. Quasi bevor es final im auszuführenden LLM landet. Das heißt, du hast so eine große Borg, wo dein RAG lebt, in allen Varianten, die man da so benutzen kann. Und dort kann und wird in Teilen schon quasi ein LLM verwendet, um klar vorzudeterminieren, was danach in die nächste Nummer reinkommt. Und dann hast du dein LLM-Modell dahinter. Das ist die grobe Architektur, nachdem wir hier keine Slides an die Wand schmeißen können. Deswegen nennt sich das Augmented Generation: Du augmentierst das Retrieval, machst es also weiter und arbeitest im Zweifelsfall generativ. Alles kann, nichts muss. Das kommt sehr auf den Case drauf an, was du baust. RAG ist quasi ein Überbegriff ohne eine spezifische technische Definition. Du hast einen hohen Grad der Flexibilität. Einfache Vektordatenbanken genauso wie Knowledge Graphs sind beides Kategorien eines RAG. Kann aber auch ganz anders aussehen. RAG ist wie ein Metabegriff und die Retrieval Augmentation beschreibt ein größeres Konzept, das dann nicht definiert ist, wie es im Einzelfall runtergebrochen wird.

00:35:35: Du hast zum zweiten Mal einen Begriff verwendet, nämlich die Vektordatenbank. Und jetzt kam noch der Knowledge Graph dazu. Wollen wir die zwei vielleicht auch noch erklären?

00:35:42: Vektoren und Graphen sind im Prinzip nur zwei Repräsentanten, wie Daten, wie Wissen in maschinenlesbarer Form repräsentiert werden kann. Das kann man in Form von Vektoren tun – genau, Mathe, Flashback – genau wie ihr euch Vektoren vorstellt. Bisschen länger, bisschen größer, aber das sind Vektoren. Und Graphen können ausgleichen, was Vektoren nicht können. In einem Graphen kann ich quasi Sachen miteinander verknüpfen, sodass ich nicht ins Vollchaos komme. Stellt euch vor: Ihr produziert Computermäuse. Ihr seid jetzt eine Company, die Computermäuse produziert. Jetzt habt ihr natürlich auch – also das ist euer Produkt, diese Daten rund um die Computermäuse müssen irgendwo abgelegt werden. Aber eure Mitarbeitenden benutzen auch Computermäuse. Und jetzt: Wie soll der Vektor sauber unterscheiden, ob das die Computermaus auf meinem Schreibtisch ist oder die, die ich dem Jochen verkauft habe?

00:36:42: In Graphen kann ich dieses Problem ausgleichen, sodass ich, wenn ich das Gleiche mit mehrfacher Bedeutung habe, besser unterscheiden kann. Deswegen sind Graphen grundsätzlich in der Theorie immer besser. Das heißt aber nicht, dass es in der Praxis so ist und dass sich der Aufwand, der betrieben werden muss, damit die Graphen gut und solide sind, wirklich rentiert. Und deswegen – um unseren Dreiklang nochmal klarzumachen, warum Google so ein Enterprise-Case ist: Die haben ihre ganzen Knowledge Graphs, insbesondere auf den im Netz verfügbaren Daten, seit Jahren im Aufbau. Deswegen sind die, was Suche oder eine bestimmte Knowledge-Verfügbarkeit angeht, am meisten voraus, weil sie so viel Vorsprung haben, unter anderem im öffentlich Zugänglichen, aber auch aus internem Graphenbauen. Das ist der Unterschied.

00:37:34: Jetzt frage ich mich gerade eins, weil meine Kollegin hat ja ein Word-Dokument mit 70 Seiten. Und wenn ich jetzt in so ein Unternehmen reingehe und mir überlege, in welcher Form Daten dort vorliegen, dann wären Datenbanken in Anführungszeichen schon eigentlich so eher …

00:37:57: Datenbanken sind ein Teil des Retrieval, das du verwendest für deinen ganzen Krimskrams. Datenbanken sind ein Teil deiner Retrieval-Strategien. Je nachdem, wie du die Datenbanken verwendest und anbindest, sind sie quasi ein echtes – bitte in Anführungszeichen denken – RAG. Aber Datenbanken sind Teil deiner Verarbeitungsstrategie, der Ingestion.

00:38:15: Aber was mache ich mit dem ganzen anderen Kram? In so einem Unternehmen sammeln sich ja unglaubliche Millionen von Word-Dokumenten an. Irgendwer hat irgendwo was dokumentiert, eine Guideline dafür erstellt.

00:38:28: Da kommen wir jetzt dahin, warum Microsoft Copilot und die SharePoint-Anbindungen so ein Riesendrama ist. Grundsätzlich – und da kommt eigentlich auch die häufigste Verwendung für RAG her: Du hast für deinen Fachbereich Marketing deine ganzen Daten, die eigentlich allen Mitarbeitern zur Verfügung stehen sollten. Die werden dann RAG-pipelined. Achtung: Das heißt nicht, dass ich euch jetzt genau sagen kann, wie das bei euch aussieht. Aber diese sogenannten RAGs sind für die unstrukturierten Daten im Unternehmen zuständig. Wenn die Datenbank strukturierte und maximal semi-strukturierte Daten verarbeiten kann und sollte, sind die RAGs für die Rohdaten zuständig – die unstrukturierten Daten verfügbar zu machen. Das betrifft natürlich insbesondere die ganz klassische Suche – der Mitarbeiter sucht was – aber auch die Verfügbarkeit in der Data-AI-Readiness. RAGs sind für die unstrukturierten Daten zuständig. Also deine PDFs und die Führungsleitlinie aus 1997.

00:39:31: Und den Zusammenhang auch noch kurz zu erklären: SharePoint und diese Sammlung an PDFs und Word-Dokumenten, die sich aus Nutzersicht über x Dutzend Arbeitsgruppen, Ordner und weiß der Teufel welche Strukturen verteilt – ist dann SharePoint der Data Lake?

00:39:56: Um Gottes Willen. Der Punkt ist, dass es teilweise so benutzt wird. SharePoint wird bestimmt auch irgendwo als Data Lake benutzt. Nein, das wäre technisch noch ein bisschen mehr. SharePoint sollte eigentlich die vorstrukturierte Variante sein, damit Retrieval und Data AI eine Chance hat. Wir wissen alle, dass es so nicht aussieht. „Final_37b_Draft_18b_versendet_zur_letzten_PowerPoint." Viel Spaß, dass das LLM rausfindet, was das jetzt sein soll.

00:40:18: Final_letzte_Version.

00:40:26: Das heißt nicht, dass SharePoint als Data Lake missbraucht wird. Aber das sollte eigentlich nicht sein. Am Ende des Tages gibt es diese lustige Aussage: Wenn ihr in einer Microsoft-Company seid, wird immer diskutiert, was speichere ich in Teams, was in SharePoint und was im OneDrive. Am Ende des Tages ist das rein architektonisch genau das Gleiche. Das sind nur unterschiedliche Prozesse. OneDrive ist quasi dein Speicher. SharePoint ist eigentlich das, was allen zur Verfügung steht. Und Teams ist quasi dein Chat-Gedöns. Ich bin keine Microsoft-Expertin. Ich muss mich mit genug Microsoft rumärgern, aber wir selber sind keine Microsoft-Company. Wer SharePoint als Data Lake missbraucht, hat seine Hausaufgaben nicht gemacht. Sieht das in vielen Fällen so aus? Ja. Aber genau deswegen ist dieses SharePoint-Drama so groß. Wenn das Ganze gut organisiert und strukturiert wäre, wäre es nicht so dramatisch.

00:41:19: Ich gehe mal zurück aufs einfache Beispiel. Wenn ich jetzt wirklich eine überschaubare Menge an Daten habe – ich nehme wieder die Krücke mit meiner Kollegin und ihrem Buch –, die wird sich wahrscheinlich hinsetzen und Dokumente erstellen können, die strukturierte Daten für das Projekt zur Verfügung stellen, damit der Kontext besser strukturierte Daten zum Arbeiten hat. Bei einem Unternehmen, das 40.000 Word-Dokumente, 20.000 PDFs in Strukturen und Ordnern hat, die man schon mit der Oberfläche von Microsoft nicht mehr versteht: Was mache ich mit dem ganzen Krimskrams? Nur mal die Frage.

00:42:04: Anrufen. Anrufen. Anrufen. Bitte anrufen und keinen Unsinn veranstalten. Anrufen, ruft doch einfach an, dann können wir euch helfen. Ansonsten muss ich es wieder fixen und dann ist eure Data-AI-Readiness mindestens drei Jahre verschoben. Der Punkt ist: Das ist ein Job für ein paar Vollprofis und nicht nur für einen.

00:42:20: Das ist ein Job für den Data Scientist dieses Problem?

00:42:29: Vibe-Coded. Also: Wäre ich ein LinkedIn-AI-Influencer-Guru, der sich Experte nennt, dann würde ich euch jetzt empfehlen: Wir haben da einen N8N-Workflow und außerdem können wir mit Co-Worker-Agents drüber – Sachen, die räumen eure Daten auf. Falls euch irgendjemand das …

00:42:45: Kommentiert mit „Apfelbaum" unten in den Kommentaren und dann schicken wir euch ein unverständliches Diagramm.

00:42:50: Genau. Der Punkt ist: Wenn du 40.000 Dokumente hast, wenn du ein Unternehmen bist, das nicht morgen in der Zeitung stehen will, weil es sich die ganzen Daten gelöscht hat, dann habt ihr hoffentlich irgendwelche Profis. Wir haben auch Kollegen, die wir empfehlen können. Oder ihr habt Leute intern. Aber hört auf eure Profis, die euch sagen, dass das ein nicht triviales Problem ist, das man technisch gut erschlagen kann. So kommt auch die Aussage zustande: Diese ganz naiven „wir schmeißen da 10.000 Dokumente in ein RAG rein" – das war noch nie eine gute Empfehlung. Man wollte uns ja nicht zuhören. Es gibt angeblich Leute, die machen das schon ein bisschen länger. Da schwingt bei mir immer Frust mit, weil ich dann Sachen fixen muss, die wirklich hart vermeidbar gewesen wären. Das ist halt einfach das Problem.

00:43:28: Das fängt ja schon einfach an. Wenn ich zum Beispiel in einem meiner Claude-Projekte eine Markdown-Datei erstellt habe mit irgendwelchen Hintergrundrichtlinien, wie ein Artikel zu erstellen ist oder sonst irgendwas, und ich vergesse, dass ich das getan habe, und lade diese Richtlinien nochmal in den Projektkontext hoch – dann habe ich zwei Richtlinien, die sich unter Umständen widersprechen. Dann brauche ich mich nicht wundern, wenn Claude mir Murks produziert, weil im Kontext liegen zwar richtig … Warum erzähle ich das? Wenn du so ein riesengroßes Konvolut auf SharePoint liegen hast, ist die Wahrscheinlichkeit extrem hoch, dass deine Brand Guidelines aus 1997 und 2026 sich eventuell widersprechen könnten. Und wenn man jetzt das ganze Konvolut da reinschüttet und sich hinterher wundert, warum auf einmal Brand Guidelines von 1997 auf der aktuellen Webseite angewendet werden, weil der Adobe Brand Agent auf diese Guidelines zurückgegriffen hat, die ihm über SharePoint reingeflutscht wurden – dann muss man sich nicht wundern.

00:44:45: Und das ist halt auch genau das. Das große Budget liegt jetzt übrigens – je nach Größe des Unternehmens – weniger im Bauen dieser ganzen Geschichten als im Whiteboarding der Architektur. Und das ist das, was gerade so schiefgeht. Die Technik: Wenn das Scribble mal steht, wenn die Architektur aufgesetzt ist, dann kann das fast jedes Unternehmen mit In-House-Ressourcen stemmen, bin ich mir fast sicher. Die große Herausforderung ist: Wie bauen wir das überhaupt? Und wie ist es gebaut, dass es zukunftssicher wird? Ruft doch bitte an und ruft ein paar Kollegen an. Weil da passiert momentan das große Problem. Du siehst erst, dass es nicht funktioniert, wenn genau das passiert, was du gerade geschildert hast. Dann ist es zu spät. Lass es mal nicht die Brand Guidelines sein. Fehlbranding hat den Aktienkurs noch nie gekillt. Aber lass das mal andere Sachen sein. Und das ist das große Missverständnis: Die eigentliche Arbeit, das umzusetzen, ist – insbesondere wo wir heute stehen, mit den ganzen großartigen Coding-Assistants – nicht mehr das Schwierigste. Aber davor braucht es Deep Knowledge aus der Firma und echte Expertise, um die Whiteboarding-Session on point hinzubekommen und die Steps, die daraus folgen. Den Rest kann man in Full-Speed machen. Aber dieser Moment muss sitzen. Wenn der sitzt: alles mega. Das ist aber das, was momentan so massiv schiefgeht. Dass du denkst, ich habe noch einen SharePoint. Nein, ihr habt Chaos. Ihr habt so ein Chaos – wie soll das LLM das morgens auffassen?

00:46:26: Man schafft ja bei einem Zugriff auf SharePoint noch nicht mal ein konsistentes Verhalten über die verschiedenen Oberflächen. Wenn ich ein Dokument in Teams suche, bekomme ich andere Ergebnisse als wenn ich in Word suche, in OneDrive suche oder über die SharePoint-Maske. Manchmal finde ich es an der einen Stelle, manchmal an der anderen. Ich habe mittlerweile keine Microsoft-Tools mehr, weil ich mein eigenes Unternehmen habe und mich nicht mehr mit irgendwelchen Leuten rumärgern muss, die Microsoft-verliebt sind. Freundliche Grüße nach München. Mein Leben ist deutlich leichter.

00:47:03: Ich hab das schon, aber ich muss auch sagen: Bitte, da müsst ihr auch klar drüber nachdenken. Aber das ist ein schönes Wort zum Samstag. Wann auch immer ihr diese Folge hört – wir kommen ja immer freitags raus.

00:47:14: Genau, dann würden wir in diesem Sinne sagen: Ein schönes Wochenende und bis zum nächsten Mal.

00:47:22: Tschüüüs!