OpenAI & GitHub Copilot mit Matthias Plappert

Hallo. Und herzlich willkommen zu einer neuen Folge der Programmierbar. Wir sind heute mal wieder im Künstlichen Intelligenz Space unterwegs und werden wahrscheinlich einige Themen daraus streifen. Und als Gast haben wir heute eingeladen Matthias Plappert. Matthias, herzlich willkommen in der Programmierbar. Hallo, ich freue mich hier zu sein. Und gerade schon gescherzt Matthias Plappert eigentlich prädestiniert der Name, einen eigenen Podcast zu haben, aber den hast du noch nicht genutzt und ist noch offen für die Zukunft. Ist noch offen. Die Domain habe ich aber. Also ich sage jetzt mal konkreter, Ich bin bereit. Sehr schön. Cool. Du. Bist. Research Scientist und hast bei Firmen gearbeitet, die man im aktuellen Umfeld durchaus kennt. Einmal bei OpenAI und auch bei GitHub. Mittlerweile hast du dich selbstständig gemacht, auch vermutlich im Bereich Künstliche Intelligenz und AI und willst ein bisschen gucken, da an eigenen Produkten vielleicht was zu machen. Ich würde gerne in der Folge auch noch ein bisschen was über dich am Anfang erfahren, wie du da so reingerutscht bist und wie du das für dich selbst empfunden hast und jetzt auch so siehst, dass es ja Technologien sind, die auf einmal überall auf einmal benutzt werden. Das vielleicht vor zwei Jahren, obwohl ihr an dem gleichen schon gearbeitet habt, noch nicht so populär war, wie sich das einfach anfühlt aus der Sicht von jemandem, der sehr, sehr nah dran war. Von daher vielleicht fangen wir da mal an. Also wie bist du selbst zu diesem Thema gekommen? War das direkt schon im Studium. Hast du dich irgendwie parallel dafür interessiert? Wann hast du das erste Mal mit künstlicher Intelligenz, wenn das überhaupt für dich der richtige Begriff ist, den ich dafür nutze? Aber wann hast du dich jetzt erst mal selbst damit beschäftigt? Ja, also Künstliche Intelligenz passt auf jeden Fall. Meine Sub-Spezialität, sage ich mal, ist maschinelles Lernen, ist aber ein Teil der künstlichen Intelligenz. Und ich bin da ehrlich gesagt eher reingestolpert während des Studiums tatsächlich. Also ich hatte Informatik studiert in Karlsruhe, war damals noch im Bachelor. Das war wahrscheinlich so 2014/2015 rum und hatte das Grundstudium hinter mir und war so ein bisschen auf der Suche nach meinen Vertiefungen und hatte damals eigentlich vor allem Lust auf Kryptografie. Also nicht unbedingt Krypto als Bitcoin und Co, sondern wirklich eher zur Verschlüsselung. Und was mich daran interessiert hat, war, dass es halt, na ja, angewendete Mathematikistik ist, also dass man irgendwie nicht nur Mathe macht, Mathe zu machen, sondern irgendwie eine Anwendung dafür hat. Und das hat mich damals interessiert und dachte eine Weile, ja, das werde ich jetzt machen. Hatte schon so ein bisschen für meine Bachelorarbeit damals auch überlegt, dort ein Thema zu finden und musste aber noch ein Seminar machen. Und das war mehr oder weniger zufälligerweise, diese Anforderungen zu erfüllen im Bereich maschinelles Lernen und habe dann während dieses Seminars gemerkt, oh hoppla, das ist ja super interessant, hat auch mit Mathe zu tun, ist aber ein bisschen einfachere Mathematik. Also es kam ja auch ganz gelegen und habe dann so eine 180 Grad Wende hingelegt und meine Bachelorarbeit in dem Bereich geschrieben und dann auch im Masterstudium hauptsächlich maschinelles Lernen und als andere Vertiefung Robotik gemacht. Also das heißt, es war nie wirklich Plan, irgendwie in die App Entwicklungs zu gehen. Weil ich hatte nur gesehen, dass du auch bei PSPDF gearbeitet hast. Auch ein Produkt, was ich mal angehört habe, ich nutze nicht nur Co-Pilot, an dem du mitgearbeitet hast, sondern PSPDF. Da habe ich damals glaube ich bei der Deutschen Bank, haben wir auf jeden Fall auch iOS App PDF Erstellung, irgendwie war PSPDF geht auf jeden Fall bei uns auch durchaus mit drin. Also schon mehrere Tools von dir im Einsatz gehabt. Genau das ist mein anderes Leben gewesen. Also wir können auch noch mal da einsteigen vielleicht. Dann müssen wir ein kleines bisschen weiter zurückgehen. Und zwar habe ich relativ viel iOS Entwicklung gemacht. Ja, das stimmt. Also sowohl eigene Apps, die jetzt sag ich mal eher kleiner waren, aber so in den Anfangszeiten über den AppStore verkauft, als ich noch teilweise in der Schule war und später auch am Anfang des Studiums und hatte auch Praktikum gemacht damals in San Francisco. Das war in meinem dritten Semester im Bachelor bei Square, also dem Payment Processing Dienstleister, die ja auch damals super interessante iOS Apps hatten. Und anschließend war ich genau bei PSPDFKID als Freelancer während dem Studium unterwegs. Und das war dann auch tatsächlich etwas, was ich aufgehört hatte. Ich habe bei PSPDFKID zweieinhalb Jahre oder sowas gearbeitet und habe das dann aufgehört mit meiner Bachelorarbeit. Also es gab sozusagen mein iOS Leben. Das waren so vielleicht fünf Jahre oder so und dann gab es mein Maschinen Learning Leben und das hat sich dann so gewandelt. Das heißt aber wirklich mit Bachelorarbeit hat sich das dann bei dir gedreht, dass dann da der Fokus sich wirklich geswitcht hat, dann. Hin zu Maschinen Learning? Genau. Ich habe dann wirklich gemerkt, es interessiert mich so sehr, dass ich einfach wirklich 100% meiner Zeit darauf fokussieren möchte und habe dann ehrlich gesagt seitdem auch nicht mehr wirklich viel iOS Programmierung gemacht. Irgendwann habe ich es mal noch probiert. Also ich bin ja noch so ein bisschen Old School, also Objective C und UI-Kit anstatt SWift und SWift UI. Und ich habe dann später noch mal, weil es mich gejuckt hat, ein bisschen in SWift rumprobiert und ein bisschen SWift UI rumprobiert und so und es ist auf jeden Fall cool, hat sich viel geändert. Also ich könnte auch nicht mehr wirklich in dem Bereich arbeiten, glaube ich. Aber wie gesagt, das war auch so ein bisschen eine Stolperei. Es war nicht von langer Hand geplant, so mein Masterplan oder so, sondern es war einfach, es interessiert mich und da habe ich Lust drauf. So bin ich auch damals zur iOS-Programmierung genauso gekommen. Es war immer sehr stark so Interessen gesteuert. Und dann aber der Schritt vom Studium, also zumindest nach dem Lebenslauf, war dann ja direkt zu OpenAI in die Bay Area, oder? Also es wirkte, wenn man es erst mal so liest, jetzt nicht so nach Stolpern. Genau, es war auch immer ein bisschen... Zufällig tatsächlich. Also ich habe ja schon gesagt, ich habe dann mein Pivot, sag ich mal gemacht zu Maschinen Learning im Bachelor und bin dann dort bei Professor Asfu heißt der Professor am KIT gelandet, der Robotiker ist und hatte dann auch während meines Masterstudiums eben bei ihm relativ viel gemacht. Es gab damals an der Uni bei uns ein neues Programm, das hieß „Praxis der Forschung. Das ist die Idee, dass man für ein Jahr selbstständig ein Forschungsprojekt ausführt, wo auch das Ziel ist, dann am Ende ein Paper oder vielleicht auch zwei zu schreiben. Und das habe ich gemacht. Das war damals vor allem im Bereich der Erkennung und Generierung von menschlicher Bewegung, also diese Motion Capture Sachen. Das ist für die humanöde Robotik relativ interessant, weil die humanöden Roboter eben menschenähnliche Körper haben und man dann menschliche Bewegungen auf den Roboter mappen kann und so weiter und so fort. Und da ging es darum menschliche Bewegungen und natürliche Sprache zu verknüpfen. Also ich sage irgendwie so was wie ein Mensch läuft im Kreis und dann wird eben eine Bewegung synthetisiert, wo der Mensch oder auch der Roboter eben im Kreis läuft. Und ich hatte dann beschlossen und auch mit meinem Professor besprochen, dass ich gerne die Masterarbeit extern schreiben möchte, unter anderem weil einfach damals noch nicht so wahnsinnig viele Leute am KIT Deep Learning gemacht haben. Und Deep Learning ist einfach sehr neu, da war der große Moment 2012 und das war dann so eben eher so 2016/ 2017 rum. Also zum einen gab es nicht besonders viel Expertise, aber zum anderen gab es auch einfach nicht besonders viele CPUs und CPUs sind relativ wichtig, wenn man Deep Learning machen möchte. Und deswegen habe ich mich so ein bisschen nach Alternativen umgeschaut und hatte mich bei einigen Sachen beworben, anderen Unis, teilweise auch anderen Forschungsinstitutionen in Europa, aber eben auch OpenAI, die damals recht neu waren. Also die wurden ja Anfang 2016 in der DV gegründet und ehrlich gesagt war OpenAI so ein bisschen mein, ich kann es ja mal probieren, aber wahrscheinlich wird es eh nichts, Bewerbung. Und es war dann auch recht amüsant, weil ich mich beworben hatte für, glaube ich, zwei oder drei Monate gar nichts gehört hatte und schon kurz davor war an einer anderen Stelle zuzusagen, weil ich eben dachte, na gut, ist halt nichts. Und dann kam aber eine E-Mail, so tut uns leid, dass wir uns so spät melden. Wir hatten ein bisschen Backlog, aber wir finden nicht cool. Willst du nicht mal nach San Francisco kommen zum Bewerbungsgespräch? Was ich dann getan habe, das war dann irgendwie Ende 2016 oder so, im Oktober glaube ich. Aber es zu verstehen, das war eine Initiativbewerbung für du hast gesagt du willst dann. Masterarbeit schreiben. Ja, ja, initiativ, total aus dem Nichts. Und ich hätte quasi vorgeschlagen, hey, wärs nicht cool, wenn ich bei euch meine Masterarbeit schreibe und eben das mit so einem Praktikum verbinde. Also idealerweise ich wollte gerne für sechs Monate das machen. Hab schon ein bisschen vermutet, dass wahrscheinlich ich nicht sechs Monate lang nur die Masterarbeit dort machen muss, sondern vielleicht auch noch ein bisschen was anderes machen kann und hatte das denen einfach so ein bisschen vorgeschlagen und das hat dann auch eins zu eins so funktioniert. Ich meine, wie gesagt, mein großer Vorteil war natürlich auch so ein bisschen zur richtigen Zeit am richtigen Ort zu sein, weil die Firma einfach noch sehr jung und klein war und die einfach damals gesagt haben: Ja klar, warum nicht? Was heißtWann war dein Client zu dem Zeitpunkt? Also als ich mich beworben hatte im Oktober, als ich dort war, waren es glaube ich in etwa 30 Leute. Ich weiß noch, dass ich damals, also die waren gerade umgezogen in ihr neues Büro, was lustigerweise das alte Büro von Strype war und auch Brack Brockman, der frühe CTO von Strype und Mitgründer von Open AI sozusagen, dann wieder in seinem alten Büro saß. Das war ganz amüsant, aber es war super leer einfach. Also es ist ein relativ, nicht besonders groß, aber es hat drei Stockwerke, das Gebäude und es war einfach quasi so eine kleine Ecke im Erdgeschosswagen, quasi mit Schreibtischen voll und alles andere war einfach leer. Und als ich dann angefangen hatte, was ja ein bisschen später war, also im April 2017, waren es dann schon die 40 Leute, aber es war schon sehr klein noch. Du bist ja dann noch ein bisschen länger da geblieben. So generell, also wir hatten eben im Vorgespräch überlegt, ob wir Research Scientists irgendwie übersetzen können. Aber da wir oder ich zumindest keinen Kontakt bis jetzt viel hatte zu irgendwie diesem wissenschaftlichen Arbeiten und Paper schreiben und irgendwelche Dinge machen, das ist dann schon aber eine Rolle, in der man offiziell eingestellt wird und wo es auch dein Ziel ist praktisch Publikationen zu erstellen und Forschung, also echte Forschung einfach zu betreiben. Und das ist auch das, was OpenAI gemacht hat. Genau. Also mein Titel bei OpenAI war offiziell Member of Technical Staff. Das ist vielleicht auch ganz interessant, dass OpenAI für alle technischen Rollen diesen Titel vergibt und nicht unterscheidet zwischen einem Software-Engineer oder einem Research-Engineer oder einem Research-Scientist. Also das ist relativ flüssig und man muss sich das auch so vorstellen, dass ich jetzt nicht nur im stillen Kämmerlein saß und irgendwie mir Ideen ausgedacht habe und dann gesagt habe, hey, wär das nicht cool, sondern man macht schon alles. Also es ist eher so ein bisschen die Spezialisierung vielleicht, aber es ist schon die Erwartung, dass grundsätzlich jeder, der bei OpenAI ist, zumindest war es damals so, ob es heute noch so ist, weiß ich nicht, schon auch durchaus in der Lage dazu sein sollte, eigene Ideen auszuführen, also den Code schreiben zu können und zu tun, was auch immer notwendig ist. So ein bisschen typisch Startup auch, aber halt in einem anderen Kontext, nämlich halt einfach wirklich sehr forschungsorientiert. Und damals war bei OpenAI eben die, also von Anfang an hatte OpenAI als Ziel und hat es auch nach wie vor, generelle Künstliche Intelligenz zu erforschen. Also dieses Konzept von ADI, also Artificial General Intelligence. Und was das im Endeffekt heißt, ist so ein bisschen vielleicht fuzzi, aber man kann es sich grob so vorstellen, wie auch Menschen sehr allgemeine Intelligenz besitzen. Wir können ja viele verschiedene Sachen lernen. Wenn wir was nicht können, können wir lange drüber nachdenken und werden dann besser darin und so weiter und so fort. Und die selbe Idee eben für künstliche Intelligenz. Und in den Anfangsjahren von Open AI, als ich dazu gestoßen bin, war einfach noch überhaupt nicht klar, wie das überhaupt geht. Also es gab auch viele Leute, die gesagt haben: „Ihr spinnt ja, das geht grundsätzlich nicht. Und selbst die Leute, die gesagt haben: „Ja, vielleicht geht das irgendwie, wussten halt nicht, wie es geht und wir auch nicht. Und was dann eben Open AI Strategie war, war zu sagen: „Okay, wir haben verschiedene Betten auf mögliche Pfade dorthin. Und eine dieser Betten war eben zum Beispiel Robotik, weil eben Robotik in der physischen Welt abläuft und wir als Menschen so ein Existenzbeweis sind, dass die physische Welt ja auch relativ komplex ist und eben so was wie allgemeine Intelligenz hervorbringen kann. Es gab aber auch viele andere Sachen, also zum Beispiel so Multi-Agentensysteme. Also kann man sich so ein bisschen vorstellen, wie dieser DOTA 2 Bot in der Open AI gemacht hat, wo eben viele verschiedene Agenten in der Interaktion miteinander stehen. Es gab auch damals schon Leute, die gesagt haben, Sprachmodelle sind interessant. Es gab einfach sehr, sehr viele verschiedene Richtungen und die wurden alle so ein bisschen parallel verfolgt. Natürlich gab es auch Synergien und so weiter und so fort. Aber es war eben einfach noch sehr, sehr offen, wohin das Ganze führen kann. Und wie wart ihr aufgeteilt auf diese Wetten? Also war es so, dass sich ein Teil, also wirklich jeder so gefühlt mit einer Wette beschäftigt hat und in der Richtung dann geforscht hat und irgendwie so immer mit dem Endziel so ADI zu erzeugen? Weil ich habe mich auch ein bisschen, wie war zu diesem Zeitpunkt die Zieldefinition? Also wie findet man den? Ich habe jetzt sehr gut verstanden, dass ihr euch diese diese Wetten gesetzt habt. Das war sehr bildlich erklärt. Aber wie nähert man sich diesen Wetten? Und habt ihr euch aufgeteilt auf die Wetten, oder? Ja, genau. Also es gab auf jeden Fall eine Aufteilung, aber schon innerhalb von Teams. Es war nicht so, dass eine Person an X und eine Person an Y arbeitet. Ich würde sagen, das war auch und ist wahrscheinlich auch nach wie vor eines der Erfolgsrezepte von Open AI, dass eben schon Teams einer gewissen Größe, also zumindest für so einen Research-Kontext, so sage ich mal zwischen fünf bis teilweise sogar 15 bis 20 Leute an einer Sache gemeinsam arbeiten und gemeinsam da versuchen, Fortschritte zu machen. In akademischen Bereichen ist es oft nicht immer, aber oft so, dass es recht stark eine Person vorantreibt. Unter anderem, weil zum Beispiel jemand, der dann seinen Doktor machen möchte, ja auch nachweisen muss, ich war eben der Haupt, die Hauptperson, die diese Forschung gemacht hat. Den Constraint hatten wir ja nicht. Und letzten Endes, diese Richtungen, die wurden relativ früh von den Mitgründern definiert. Also die Person, mit der ich da hauptsächlich zusammengearbeitet habe, ist Voi Jeck, einer der Gründer, der eben einfach Lust auf Robotik hatte und gesagt hat: „Das mache ich. Und dann gab es eben andere Leute, die gesagt haben: „Ich weiß nicht, ich möchte lieber generative Modelle erforschen zur damaligen Zeit beispielsweise. Oder Leute, die gesagt haben: „Wir möchten grundsätzlich eine Forschung zu Algorithmik in diesem Bereich machen und so weiter und so fort. Und so hat sich das sozusagen, also es gab anfänglich eben Leute, die gesagt haben, das ist so ein bisschen das, worauf ich Lust habe. Und dann haben diese Personen sich herum Leute gefunden, die auch darauf Lust haben. Und bei mir war das eben dann das Robotik-Team, was ja genau das war, was ich wollte. Gibt es immer noch diese unterschiedlichen Stränge oder setzt man heute jetzt alles auf ein Pferd? Also da hat schon eine gewisse Konvergenz stattgefunden. Also was tatsächlich, springt jetzt ein bisschen vor, wir können auch noch mal ein bisschen über die Zwischenzeit reden, aber wir haben irgendwann bewusst gesagt, das war Ende 2020, also wie gesagt, April 2017 bin ich dazu gekommen und Ende 2020 haben wir dann entschieden, nicht mehr weiter Robotik zu machen. Und damals habe ich eben dann auch gewechselt, in den Bereich der Programmsynthese, also Codex und Co. Und was eben schlicht und ergreifend passiert war, ist, dass sich herausgestellt hat, dass diese Lounge Language Models, also sehr große Sprachmodelle, außergewöhnlich gut funktionieren. Und das war eben anfänglich einfach nicht klar. Es gab Leute, die gesagt haben, wir wollen es uns gerne anschauen, aber es gab ja genauso, es gab ja zig andere Ideen und es war aber von Anfang an immer ein bisschen der Plan, dann eben auch zu sagen, so, das sieht eigentlich vielversprechender aus. Wir haben endliche Ressourcen, vor allem was unsere Anzahl von Personen und deren Zeit angeht. Wir refokussieren uns, wenn notwendig. Und das ist ein paarmal passiert. Also das war eine relativ normale Vorgehensweise, also auch beispielsweise, dass das Team, das diesen DOTA 2 Bot gemacht hat, die haben auch aufgehört zu existieren, nicht weil die nicht erfolgreich waren, sondern weil schlicht und ergreifend sozusagen das Projekt sein Ziel erfüllt hatte. Und dann wird es eben zu dem nächsten weitergehen. Und ich denke, das ist auch was, was bei Open Air besonders ist, dass es letzten Endes eben sehr pragmatisch ist. Also es geht wirklich darum zu sagen Okay, was, wie kommen wir am besten weiter? Und wenn das heißt, irgendwas aufzuhören, was eigentlich gut funktioniert hat, aber vielleicht nicht mehr auf dem kritischen Pfad ist, dann wird das halt gemacht. Und weil du vorhin meintest, der eine hat gesagt, ich beschäftige mich mit generativen Modellen. Und dann hast du aber gemeint, du hast von 2020 von der Robotik zu Codex eher Programmsynthese gewechselt. So, ich hatte jetzt Codex irgendwie von... Wir haben über die generativen Modellen gesprochen, also alles, was irgendwie jetzt so, wir haben gefühlt, also unser Fokus auch von unserer oder die Aufmerksamkeit von unserem Podcast auf OpenAI kam ein bisschen durch Doorly dann wirklich am Ende, was ich jetzt auch unter dieses generative Richtung gesteckt hätte. Also ist Codex, also gehört es zu dem generativen Pfad, von dem du am Anfang gesprochen hast? Oder wie? Was genau grenzt jetzt die Programmsynthese, in der du seit 2020 warst, von jetzt anderen Produkten wie Doorly oder GPT ab? Ja, also das ist eine gute Frage. Das ist auch ein bisschen verwirrend vielleicht. Ich versuche es mal so gut ich kann zu erklären. Also was letzten Endes historisch passiert ist, ist, dass es immer Leute gab, die gesagt haben, wir möchten gerne Sachen mit Sprache machen. Es gab ja auch GPS 1 und GPT 2 und GPT 3. Und ein Vorteil generativer Modelle ist, dass sie nicht unbedingt gelabelten Datensatz brauchen. Was ich damit meine, ist, dass man, wenn man jetzt beispielsweise Bilderkennung machen möchte, muss ich ja irgendwie zum Beispiel ganz viele Bilder von einer Katze und ganz viele Bilder von einem Hund haben und bei jedem Bild manuell sagen: Das ist jetzt eine Katze, das ist jetzt ein Hund. Und bei generativen Modellen gibt es oft diese Idee von Self Supervision, also bei Text beispielsweise funktioniert das ganz einfach, indem ich sage, gegeben von Text, der bisher kam, was ist wohl das nächste Wort? Und dafür brauche ich ja keine Labels, weil Text existiert einfach in großen Mengen im Internet und den kann ich mir eben besorgen. Und es gab schon immer Leute, die gesagt haben, das wirkt so, als ob das quasi gut skalieren kann. Aber es war halt nicht offensichtlich, wie man diesen Text wirklich sinnvoll nutzen kann. Und was eben bei GDP über die Zeit sich gezeigt hat, ist, dass wenn man auf diesem extrem simplen Task trainiert, sehr viel Text. Ich sage immer quasi, woher, was kommt als nächstes, was kommt als nächstes, was kommt als nächstes, dass in dem neuronalen Netz selbst Prozesse stattfinden, die darüber hinausgehen. Also konkret gab es, ich glaube, das war zur GPS1 Zeit eventuell schon, da gibt es auch ein Paper dazu von dem entsprechenden Autor, wo diese Person festgestellt hat, wenn ich einfach nur auf Text trainiere, gibt es plötzlich in diesem neuronalen Netz ein Neuron, das auf das Sentiment reagiert, also auf die Tatsache, ist dieser Text positiv oder negativ? Es wurde aber nie spezifisch darauf trainiert. Das passiert einfach nur, weil es hilft, das nächste Wort vorherzusagen. Und was dann eben passiert ist, ist, dass Leute realisiert haben, das wirkt wie ein sehr allgemeines Rahmenwerk. Und weil eben dieses Modell immer das nächste Wort vorhersagen möchte, muss es auch ganz viele andere Dinge lernen. Also man kann sich das auch vorstellen, wenn ich jetzt im Internet zum Beispiel irgendwie Text finde, wo 5+5 ist gleich steht, muss ich plötzlich rechnen, weil vorherzusagen, was 5+5 ist gleich heißt, muss ich eben Addition ausführen. Oder ein anderes Beispiel, wenn ich ein Buch lese, in dem es darum geht, dass jemand irgendwie, weiß ich nicht, also einen fiktionalen Mord begangen hat, also so eine Detektiv-Story, dann muss ich ja quasi sehr viel darüber nachdenken, was ist eigentlich passiert, am Ende zum Beispiel vorherzusagen, wer war denn der Mörder? Und Leute haben das zusehends realisiert. Und was zeitgleich passiert ist, war, dass man festgestellt hat, wenn wir diese Modelle größer machen, also sie auf mehr Daten trainieren und aber auch ihre Parameteranzahl erhöhen, bekommen wir immer bessere Performance und das folgt sogar vorhersehbaren Trends. Also man kann das quantifizieren und sozusagen projizieren, wenn ich mein Modell Faktor fünf größer mache, wie gut ist meine erwartete Performance? Und all das hat eben dazu geführt, dass Leute festgestellt haben, so was wie GPT3 ist vielleicht eine ganz gute Idee, was damals eben niemand so richtig auf dem Schirm hatte, weil es natürlich sehr teuer ist. Also wenn ich sage, ich trainiere jetzt ein gigantisches Modell auf sehr viel Text, brauche ich ja schon eine gewisse Überzeugung, dass das auch ein sinnvolles Unterfangen ist. Und deswegen, also es hat so quasi in ganz kleinschrittig angefangen, diese Leute, die dann in Narrative Modellen gearbeitet haben, hatten gewisse Beobachtungen gemacht, wo sie gesagt haben: „Das ist interessant, mal schauen, was dann noch passiert und dann ist das so ein bisschen über die Zeit quasi eskaliert, also dass immer mehr Leute gesagt haben, das ist super interessant. Was passiert, wenn wir es größer machen? Was passiert, wenn wir es auf einer breiteren Domäne trainieren? Und so weiter und so fort. Und so hat sich das im Endeffekt entwickelt. Und zurück zu deiner ursprünglichen Frage, wie das jetzt auch mit Codex zusammenhängt, ist schlicht und ergreifend dann irgendwann die Frage aufgefallen: Was passiert eigentlich, wenn wir auf Code trainieren? Weil bisher haben wir ja hauptsächlich auf Text trainiert, der hauptsächlich englische Sprache war, also kein Code oder irgendwas dergleichen. Aber es gibt ja auch ganz viel Code, beispielsweise auf GitHub. Und da wurde eben sozusagen die Verbindung dann geknüpft. Aber das Modell, das zugrunde liegt, ist eben sehr, sehr vergleichbar, weil eben die Idee immer nur ist, ich habe irgendeinen Text, ich möchte gerne das nächste Wort vorhersagen. Und vielleicht auch zum Verständnis. Jetzt hast du ja das Beispiel mit Codex gebracht und es wurde dann auf Source Code trainiert als Textform. Und das heißt, wenn ich es richtig verstehe, wenn ich Codex und GPS 3 vergleiche, Codex ist auch ein Base Language Language Model. Es ist nicht eine gefinetütte Variante von GPS 3, sondern es ist ein komplett neu trainiertes Base-Modell auf zum Großteil Source Code. Es wird wahrscheinlich auch anderer Text reingeflossen sein. Nicht ganz. Es ist tatsächlich so, dass die erste Version von Codex zumindest GPS 3 in Anführungszeichen, gefintunt auf Code war. Aber Fintuning impliziert ja oft, dass es eine geringe Anzahl von Datenpunkten ist. Und in dem Fall war es tatsächlich einfach sehr, sehr viel. Also wie gesagt Github-Scale. Und das Base-Modell war aber schon GPD 3, aber dann wie gesagt on top eben sehr viel Code. Die Architektur ist aber identisch. Also da wurde nahezu nichts geändert. Das Detail ist vielleicht auch nicht so wichtig, aber die grundsätzliche Modellarchitektur ist komplett identisch. Und GPD. 3. Hat man dann dazu genommen, praktisch die ganze Sprache schon abzudecken, also dass man damit interagieren kann, dass Kommentare etc. Verstanden werden. Und dann ist praktisch der Code-Teil noch obendrauf gepackt worden, dass man in unterschiedlichen Programmiersprachen, also war das dann direkt schon auch irgendwie auch habt ihr euch begrenzt auf ein Set an Programmiersprachen, die ihr zum Training dann reingegeben habt? Nicht wirklich, sondern was schon passiert ist, ist, dass man versucht, das ein bisschen auszubalancieren. Es gibt ja Programmiersprachen, die sehr populär sind, also beispielsweise JavaScript, TypeScript, Python ein Stück weit auch. Und da gibt es sehr, sehr exotische Sprachen, von denen es natürlich dementsprechend auch sehr viel weniger Code gibt. Und was man schon versucht hat, ist quasi zu sagen okay, wir filtern so ein bisschen aggressiver TypeScript und JavaScript raus, einfach weil es davon unfassbar viel schon gibt. Aber grundsätzlich wurde schon einfach auf allen Programmiersprachen, soweit ich das zumindest weiß, vielleicht wurde auch unten was weggeschnitten, wo die Anzahl der Programmiersprachen einfach nicht aktiv verfügbar war, aber schon auch in der breiten Masse trainiert. Schlicht und ergreifend aus dem Grund, dass in diesem Bereich schon sehr hilfreich ist, möglichst viele Daten zu haben. Und das ist auch der Grund, warum GPS3 damalsgenommen wurde als Base Model, dann sozusagen darauf on top zu finetunen mit Code, weil es halt weit weniger Code als natürlich sprachlichen Text gibt. Also wenn man, wenn man vergleicht, auf wie viel GPS3 trainiert wurde versus auf wie viel Codex trainiert wurde, gibt es einfach schlicht und ergreifend weniger. Und deswegen war sozusagen die Idee, wir sparen, also erstens sparen wir uns ein bisschen Zeit und Rechenarbeit, weil wir ja schon dieses Base Model haben. Schaden wird es vermutlich nichts, weil wenn man ein neuronales Netz initialisiert, ist ja erst mal komplett nur randomness da drin. Und hier war eben die Idee, also Sprache zu verstehen ist wahrscheinlich schon hilfreich, auch Code zu verstehen. Deswegen nehmen wir halt das. Aber es war auch schlicht und ergreifend ein bisschen aus pragmatischen Gründen, weil wir halt nicht so viel Code hatten. Zwei Fragen, die sich mir anschließen. Das eine vielleicht, es ein bisschen in den Kontext zu setzen. Du hast gesprochen von 2017, als du dazu kamst. Was war das? 2016 oder 2017? Kannst du gleich noch mal mich korrigieren. 2017. 2017. Kurz danach, im Juni, waren es dann ungefähr 40 Mitarbeiter. Wenn wir jetzt hier schon sprechen, so GBT 3 Zeiten, so, also wie viele Personen haben jetzt in diesem generativen Bereich gearbeitet oder vielleicht auch im expliziten Codex dann, aber falls du andere Zahlen nennen kannst, auch gerne die Größe des generativen Bereichs zu verstehen. Ja, also Open AI war nie, also so lange ich zumindest dort war, nie besonders groß. Also als ich gegangen bin, das war dann Ende 2021, war es, glaube ich, nach wie vor unter 200 Personen. Und was jetzt diesen diesen generativen Bereich angeht, also anfänglich ehrlich gesagt, waren es wahrscheinlich zwei Personen, drei Personen, die wirklich viel mit Sprache experimentiert haben. Gerade dieses Sentiment Neuron und so weiter und so fort. Das waren noch sehr, sehr wenige Leute. Also E. Ist hier vor allem zu nennen als eine der Personen. Und was dann eben passiert ist, ist, dass eben Leute zum einen mit zusätzlichen Ergebnissen und eben gesehen haben, da ist Potenzial. Aber auch in dem Moment, als diese Modelle skaliert wurden, also größer wurden, kamen eben immer mehr Leute dazu, weil diese Modelle zu skalieren natürlich einfach einen gewissen Engineering Aufwand bedeutet. Die Modelle sind nicht unbedingt notwendigerweise komplexer, aber sie zu trainieren wird halt weit schwieriger, weil sie viel mehr Compute und viel mehr Speicher und so weiter brauchen. Wir reden aber hier immer noch von Teamgrößen, ich weiß nicht, die so zwischen 10 und 20 Leuten liegen. Und was eben auch viel passiert ist, ist, dass man sich das Ganze ja auch so ein bisschen als eine Pipeline vorstellen kann. Also es gibt ja grundsätzlich bei diesen Sachen die Idee, ich brauche erst mal Daten, dann trainiere ich darauf mein Base Model und dann kann ich Downstream in diesem Base Model etwas machen. Und das muss ja nicht ein Team notwendigerweise tun. Also GPS 3 hat ja existiert, das Modell war ja für alle, die bei OpenAI waren, frei verfügbar. Und es gibt viele Teams, die dann gesagt haben, wir probieren damit mal was aus. Also beispielsweise Codex oder beispielsweise diese Instruction-Followering-Sache, wo man versucht hat, wie können wir das Modell dazu bringen, besser quasi auf Instruktionen des Menschen zu antworten? Aber das findet ja alles parallel statt. Das basiert eben auf diesem geteilten Base Model. Ja, kannst. Du uns noch so ein bisschen mehr Einblick geben? Ich finde es immer noch schwer vorstellbar. Also ich meine erstens schwierig und wir versuchen uns immer dem schon näher zu nähern, generell das zu verstehen, was in diesen Modellen passiert. Teilweise, so verstehe ich zumindest, weiß auch ein OpenAI nicht hundertprozentig was, wie, warum manchmal so funktioniert. Aber wie denn so der Job aussah, also was man letztendlich gemacht hat, weil man hatte irgendwie, das hört sich erst mal simpel an, okay, wir hatten GPS3, dann haben wir einfach noch ein bisschen Code dazu getan und haben es noch mal neu trainiert und Däumchen gedreht währenddessen. Das war es wahrscheinlich nicht, sondern was sind dann für Aufgaben, also technisch, was hat man zu tun, Codex beispielsweise entstehen zu lassen? Wie iterativ ist man da? Kann man da irgendwie heute was ausprobieren? Hat morgen ein Ergebnis? Wie viel ist man am Quality Testing sozusagen? Machen das andere Leute als einfach so. Ja, was ist die echte Arbeit daran, so etwas wie Codex zu kreieren, zu erschaffen? Ja, gute Frage. Also ich würde an der Stelle auch noch mal einwerfen, dass ich diesem Team erst zu einem späteren Zeitpunkt beigetreten bin. Also dass das Team, das Codex entwickelt hat, hatte damit auch in etwa Anfang 2020 würde ich mal grob sagen angefangen und ich bin ja dann erst Ende 2020 dazu gestoßen. Was grundsätzlich sehr hilfreich ist und da war eben Voi Jack sehr, sehr gut darin, also Voi Jack hat auch neben dem Robotik Team, das Codex Team geleitet, einfach eine Vision zu haben. Also klingt erst mal trivial, ist erstaunlich schwierig in der Praxis, aber zu sagen, so das ist das, was wir wollen. Also was ist quasi, wenn wir erfolgreich sind, wie sieht das überhaupt aus? Und was er eben seine und auch wie gesagt von anderen Mitgliedern des Teams die Vision war, wir wollen quasi Programmieraufgaben lösen und die wurden dann schlicht und ergreifend gesammelt. Also es gibt diesen Datensatz von Open AI, der ist auch für Open Source worden, der heißt Human Eval, wo wirklich Leute sich hingesetzt haben und quasi kleine Programmier-Puzzles selber sich ausgedacht haben. Und das sind ganz simple Sachen, wie zum Beispiel schreibt eine Funktion, die diesen String invertiert, sind aber auch sehr viel komplexere Dinge, wo eben ein gewisseralgorithmisches Verständnis erforderlich ist. Das sind aber alles Probleme, die innerhalb von einer Funktion self-contain sind und eben dann mit der Funktionssignatur und einem dazugehörigen Doc String spezifiziert werden können. Und was dann schlicht und ergreifend passiert ist, dass man sich überlegt hat, was ist das Problem, was wir lösen wollen? Das wurde dann im wahrsten Sinne des Wortes in dem Fall kodiert, indem man gesagt hat, hier sind Probleme und zugehörige Unit Tests, die verifizieren, ob die Funktion korrekt oder indirekt ist. Also es ist es letzten Endes fast schon Test-driven Development gewesen. Und jetzt messen wir einfach jedes Mal, wenn wir eine Idee haben, wie viele von diesen Problemen können wir lösen? Können wir davon eins lösen? Können wir davon fünf lösen oder können wir alle, ich weiß nicht, ich glaube es waren ungefähr 120 Probleme lösen. Und jetzt habe ich ja eine Metrik, die ich optimieren kann. Natürlich kann ich auch betrügen, indem ich sage Okay, ich weiß ja die Antwort und schreibe sie einfach rein. Aber das hilft wahnsinnig, weil ich ja quasi sage Okay, wir wissen nicht genau, wie das geht, aber wir haben vielleicht mal zwei, drei, vier Ideen, die wir initial ausprobieren können. Dann messen wir diese Ideen auf diesem Benchmark, den wir definiert haben und verfolgen halt die vielversprechenden weiter. Und bei diesem Job generell muss man damit leben können, sehr viel Unsicherheit zu haben, weil man im Vorfeld nie weiß, wie oder ob es überhaupt lösbar ist. Und man muss so ein bisschen einfach auch dran glauben. Und wenn wir Leute haben wie Voijek, die sehr große Optimisten sind und sagen Ja, wird schon werden. Und dann eben einfach sehr, sehr iterativ Fortschritt machen. Und das fühlt sich auch in dem Moment sehr oft sehr, sehr frustrierend an, weil es eben auch oft keinen Fortschritt gibt. Also dass man irgendwie eine Weile lang rumdumpelt und halt, weiß ich nicht, ein Problem vielleicht lösen kann, wenn man Glück hat, aber keins der anderen. Und dann schlägt man mit seinem Kopf so oft gegen den Tisch und probiert so viele Sachen aus, bis man hoffentlich irgendwas findet, was besser funktioniert. Und oft ist es dann wirklich so ein Sprung, also dass man lange rumdümpelt, das ist es sehr frustrierend und dann aber so einen Heuriker Moment hat, wo man wirklich plötzlich einen messbaren Sprung hat und plötzlich es viel besser funktioniert. Ich finde, das macht so eine sehr gute Antwort, weil es mir auch direkt viele Fragen wieder aufmacht. Einerseits glaube ich, es ist so retrospektiv, wenn ich so einen Voi-Chek hatte, eine starke Vision, glaube ich. Also ich kann mir vorstellen, dass es das braucht, weil ich mir jetzt natürlich retrospektiv ist es einfach, diese Vision zu... Also retrospektiv kann man sie sich einfach erklären. Aber ich kann mir gut vorstellen, in dem Zuge, so als eben noch nichts davon irgendwie auch zu diese großen Wellen geschlagen hat, ist es noch viel schwieriger, diese Vision zu haben. Deswegen kann ich mir sehr gut vorstellen, dass das hilft. Jetzt hast du uns gerade erklärt, ihr habt eigentlich Test-driven Development gemacht und eure Unit-Tests geschrieben und habt dann sozusagen immer probiert, verändere den Input, dann einen besseren Output zu gelangen. Besseren Output heißt mehr Tests, die grün sind. Genau. Und mich hat eben viel daran interessiert, was sind denn so die Parameter, an denen ihr dann gedreht habt? Du hast uns einerseits erklärt, ihr habt DPD3 genommen und ihr feintunt das, das heißt euer Input ist auf jeden Fall der Datensatz so, aber wie viel macht Veränderung am Datensatz aus? Was sind die Schrauben, an denen ihr da in dem Fall dreht. Ja, gute Frage. Also wie gesagt, in einer ganz anfänglichen Zeit war ich selbst nicht in dem Team. Was ich aber grob sagen kann, ist, dass am Anfang schlicht und ergreifend nicht mal klar ist, wie man, also welche Methode man überhaupt verwenden soll. Also man kann sagen, man feint den Typ drei auf Code und das war ja am Ende das, was auch gut funktioniert hat. Aber das ist ja nicht notwendigerweise sofort offensichtlich. Das war eben dann eine der Ideen, die probiert wurden. Es gab aber auch Leute, die gesagt haben, wir formulieren das Ganze als ein Reinforcement Learning Problem. Also Reinforcement Learning ist die Idee, dass der Agent, also diese künstliche Intelligenz, Aktionen ausprobiert, man ihr sagt, das war gut oder das war nicht gut. Und der Agent dann lernt, diese Dinge, die eben gut waren, häufiger zu tun und die, die schlecht waren, weniger häufig. Da haben auch viele Leute mit Homo experimentiert und es hat sich herausgestellt, dass es deutlich einfacher geht, wenn man nicht versucht, diese ganzen Daten in dieser Interaktion des Agenten mit seiner Umwelt, also der Agent schreibt Code, der Unit-Test sagt mir, es war gut oder schlecht. Dieser Ansatz funktioniert weit weniger gut, wenn man halt einfach wirklich bei Null anfängt. Weil am Anfang weiß der Agent ja gar nichts. Also er weiß vielleicht ein ganz kleines bisschen, wie Programmiersprachen so taktisch funktionieren, aber darüber hinaus nicht. Und was letzten. Endes … Und aber vor allem zum Verständnis dabei, hättet ihr auch alles, diese Informationen, Agent mit seinem Umfeld. Das Umfeld wäre ja in dem Fall ihr gewesen, oder? Das heißt, mit euren in Anführungsstrichen wenigen Mitarbeitern müsstet ihr das gesamte Umfeld simulieren oder? Oder konnte man da auf Daten zurückgreifen? Weil bei dem anderen greift man ja auf GitHub und seine … Also wissen Sie, was wir am Anfang beim Base-Modell hatten. Es gibt ganz viel Text, es gibt ganz viel Source Code, aber es gibt nicht so viel Umfeld, was dem Agenten erklärt, das machst du richtig, das machst du falsch. Genau. Und das ist auch genau die Krux. Also dass du quasi in dem Moment, wo du sagst, wir nehmen den existierenden Source Code und lernen einfach nur quasi nachzumachen. Also gegeben was kam bisher, was kommt als nächstes? Lernt das Modell eben als Nebenprodukt auch gut zu programmieren. Aber das ist ja nicht notwendigerweise offensichtlich, weil es ist ja ein sehr ungesteuertes Ziel. Also ich sage nur, hier ist ganz viel Code. Tue bestmöglich so, als ob du auch diese Art von Code schreiben kannst. Aber es ist ja nicht offensichtlich, dass dabei notwendigerweise korrekter Code rauskommt. Das funktioniert wahrscheinlich auch hauptsächlich deswegen, weil eben der Hauptteil des Codes im Internet dann tendenziell doch eher korrekt als falsch ist. Aber es gibt auch ganz viel falschen Code. Und bei Reinforcement Learning ist eben der Vorteil, ich habe ein klares Signal, ich versuche etwas und mir wird klar gesagt von meiner Umgebung, sprich dem Unit Test, ist der Test grün oder rot, aber ich muss eben alle Daten selbst generieren. Und die große Einsicht in diesem Projekt war eben, es funktioniert erstaunlich gut und ich spare mir wahnsinnig viel Zeit und auch Compute, wenn ich diesen existierenden Code nehme, sozusagen zu bootstrappen. Es tut mir leid für meine ganzen Anglizismen, aber ich glaube, viele von diesen Sachen lassen sich nicht gut übersetzen. Also wenn ich sozusagen sage, okay, es ist ja schon dieses ganze Wissen irgendwie da im Internet, wie kann ich das nutzen? Und das war am Anfang nicht offensichtlich und deswegen wurden eben beide Sachen ausprobiert in den frühen Phasen. Wie gesagt, nicht von mir, sondern von den ursprünglichen Mitgliedern des Teams. Und man hat eben dann gemerkt, das funktioniert erstaunlich gut, wenn ich also der einfache Ansatz ich nehme GPS3 und trainiere bisschen off-code, funktioniert erstaunlich gut. Und dann wurde gesagt: „Okay, das scheint die Methode der Wahl zu sein. Also wenigstens die Methode, können wir mal sagen, haben wir jetzt ungefähre Klarheit. Und dann kann man ja darauf basierend optimieren, darauf eben die kleineren Stellschrauben richtig zu haben. Also wie du schon meintest, wenn ich weiß, okay, das ist jetzt meine Methode, dann kann ich sagen, ich probiere verschiedene Datensätze aus beispielsweise und schaue eben wieder, wie beeinflusst die Wahl meines Datensatzes dann diese Metrik, die ich festgelegt habe? Also wie viele von meinen Programmen konnte ich lösen und wie viele Tests sind grün? Du kannst natürlich auch, also eine Sache, ich hatte vorhin gemeint, es gibt nahezu keine Änderungen zwischen GPS 3 und Codex. Es gibt eine Änderung, die extrem trivial ist, nämlich dass Codex ursprünglich extrem viele Probleme mit White Space hatte. Also gerade bei Sprachen wie Python, wo ich ja die korrekte Anzahl von von White Space brauche, das Syntaktisch korrekte Programm zu programmieren, ist es eben so, dass oft dann ein White Space gefehlt hat, weil halt irgendwie weiß ich nicht, es war tief eingerückt und dann musst du halt Space, Space, Space, Space, Space machen. Und was dann dort gemacht wurde, war zu sagen okay, wir ändern den Tokenizer, der sozusagen den Code überführt in etwas, was das Modell versteht. Das kann man sich ungefähr so vorstellen wie ungefähr ein Wort ist ein Token und wir führen spezielle Token ein für ein White Space, zwei White Spaces, vier White Spaces, acht White Spaces, 16 White Spaces, was ich nicht quasi 16 mal Space, Base, Base, Base, Phase drücken muss, sondern einen einzigen Token habe, der dann 16 White Spaces repräsentiert. Aber das hat man noch dann in dem Feintuning von GPS3 gemacht oder musste man dann das GPS, also musste man ein adaptiertes GPS3-Base-Model erstellen? Also wo in welcher... An welcher Stelle definiert man diese Tokens? Das lässt sich ganz gut rein operieren, sag ich mal, weil du im Endeffekt nur dein Ein-und Ausgabealphabet etwas änderst. Also du fügst ja nur etwas hinzu. Du änderst jetzt alle anderen Token, machst du nicht, sondern du fügst einfach nur ein paar zusätzliche Tokens hinzu und hast jetzt natürlich ein bisschen mehr Inputs und ein bisschen mehr Outputs. Aber diese zwei Matrizen, die am Anfang und am Ende des Modells stehen, die kann man manuell einfach dann adaptieren, sodass das funktioniert. Dafür brauchst du kein neues Training des Base Modells, sondern das ist das Input, der dann noch dazu kommt. Genau das ist eine der Sachen, die sich sehr unproblematisch glücklicherweise im Nachhinein ändern lässt. Und der Grund, warum das gemacht wurde, war eben schlicht und ergreifend, dass Leute festgestellt haben: Eigentlich sehen die Programme ziemlich richtig aus, aber schade, da hat nur ein Space gefehlt. Blöd gelaufen und dann eben überlegt, was ist eine pragmatische Lösung dafür? Und dann ist es schlicht und ergreifend, dass ist die pragmatische Lösung dafür ist. Was man so hört, dauert es ja durchaus auch immer eine gute Zeit, weil es so rechenintensiv ist, so ein Modell dann zu trainieren. Das stelle ich mir so vor. Also ihr macht das wahrscheinlich in kleineren iterativen Schritten und nehmt irgendwie erst mal einen Teildatensatz oder so und guckt dann, was da die Ergebnisse sind. Gibt es dann irgendwann so ein Go und einer sagt okay, jetzt fühlen wir uns einigermaßen sicher, lass mal ein paar Wochen oder was trainieren und wir alle drücken die Daumen, dass dann was Gutes rauskommt? Ja, also es gibt grundsätzlich zum Glück die Möglichkeit, das gleiche, die gleiche Modell von, also diese Modelle werden in Familien trainiert. Also GDP3 ist das allergrößte Modell, aber in der GPS3 Familie existieren auch Modelle, die auf demselben Datensatz, die dieselbe Architektur haben, aber sehr viel kleiner sind. Also die Modellparameteranzahl ist geringer. Und was ein typisches Vorgehen ist, ist, dass man anfänglich auch schlicht und ergreifend aus dem Grund, den du gerade genannt hast, dass es eben ewig dauert, diese Modelle zu trainieren, wenn sie sehr groß sind und sehr teuer ist, mit kleineren Modellen arbeitet, die natürlich eine niedrigere Performance Seeling haben. Die werden nie so gut sein wie ein großes Modell. Aber man kann ja trotzdem darauf iterieren. Also ich muss ja nicht auf dem größtmöglichen Modell iterieren, sondern ich kann einfach sagen okay, ich nehme mir ein kleineres Modell, das sehr viel schneller trainierbar ist, das auch in der Praxis im Alltag weniger Overhead für mich hat als jemand, der daran forscht, weil eben alles ein bisschen einfacher ist und arbeite erst mal eine Weile daran. Und wenn ich dann denke, jetzt wäre es mal interessant zu sehen, wie sieht das aus, wenn ich ein größeres Modell trainiere, dann gehe ich den Schritt. Aber ich habe ja schon davor viel Arbeit gemacht, zu risken, dass es überhaupt funktioniert. Es gibt natürlich immer noch eine gewisse Restunsicherheit, weil Sachen, die bei kleineren Scales gut funktionieren, nicht notwendigerweise auch bei großer Scale funktionieren müssen. Es gibt oft den Effekt, dass Sachen bei kleinen Modellen eine Rolle gespielt haben, die dann bei größeren Modellen schlicht und ergreifend egal sind. Also das ist relativ häufig der Fall, dass man denkt, das ist irgendwie ein guter Trick, der funktioniert, aber dann stellt sich heraus, wenn ich das Modell groß mache, ist es auch egal. Also man muss da schon ein bisschen aufpassen, aber dadurch kann man das ganz gut kontrollieren und sich so herantasten. Aber klar, irgendwann muss jemand sagen, jetzt trainieren wir ein großes, aber das ist schon auch in der Regel ehrlich gesagt so, dass einfach den Leuten, die die Forschung selbst machen, sehr viel Verantwortung gegeben wird. Also wenn du dann sagst, ich glaube, das wäre eine gute Idee, dann geht das auch. Da brauchst du dann nicht besonders viele Leute zu überzeugen. Du musst dann natürlich gucken, gibt es genug Computer für das Projekt und so weiter und so fort. Aber es wird schon sehr viel Verantwortung dem Individuum gegeben, diese Entscheidungen zu treffen. Was mich ja, also der Part, der du auch meint, die Forschung und so was ja durchaus ein bisschen auch kritisiert wird an, also Open AI, aber glaube ich generell an allen Firmen, die damit ihr Geld verdienen und eben nicht Open Source sind, so dass bestimmte Dinge natürlich auch nicht geteilt werden, so was wie wir wissen ja nicht genau, wie viele Parameter hat denn jetzt, haben jetzt diese Modelle und so und das ja nicht alles Open Source ist, was natürlich aber wiederum auch sehr verständlich ist, worauf ich gar nicht so ganz eingehen will. Aber was ja durchaus offen ist, ihr publisht ja Paper als Mitarbeiter bei Open AI und da frage ich mich so ein bisschen als denjenige, der jetzt in seinem Alltag nicht so viele Paper publisht, so wie fügt sich das in euren Arbeitsalltag ein? Also einerseits habt ihr das Ziel, irgendwie diese Modelle besser zu machen, irgendwie eure Vision zu erreichen. Ihr wollt, dass Codex Code komplettiert und Code Vorschläge schreiben kann. Und Paper wäre jetzt erst mal unintuitiv für mich, der aus der App Entwicklung kommt, zu sagen okay, take a step back, ich habe ja gerade was erkannt, ich publische das als Paper, was vielleicht erst mal so wirkt wie ich komme etwas langsamer an mein Ziel. Wie fügt sich das ein, am Arbeitsalltag? Ja, also ich würde sagen, interessantes Thema, weil der große Unterschied zwischen Open AI und vielen anderen Forschungslaboren meiner Meinung nach ist, dass das Paper nicht das Hauptziel ist. Also es gibt sehr viele Forschungen, die als Endprodukt ausschließlich das Paper sind. Natürlich auch die Forschung selbst. Aber das Ziel ist am Ende ein Paper zu publizieren. Und bei Open AI ist es spezifisch nicht das Ziel, sondern es geht darum, ein anderes Ziel, wie gesagt, diese Vision oder auch ADI oder was auch immer näher zu kommen. Und es bietet sich schlicht und ergreifend an, zu gewissen Meilensteinen Sachen aufzuschreiben, weil man probiert ja wahnsinnig viele Sachen aus. Das macht man ohnehin. Also auch intern ist es sehr normal zu sagen Was haben wir probiert, was waren die Ergebnisse davon? Was hat gut funktioniert? Was hat nicht gut funktioniert? Weil man auch extrem die Übersicht sonst verliert. Das kann ein sehr verwirrender Prozess sein. Und es liegt eben Leuten bei OpenAI trotzdem sehr am Herzen, Sachen zu publizieren, weil man ja auch mit der Community interagieren möchte. Und wie gesagt, es bietet sich schlicht und ergreifend auch ab und zu mal an, wenn man was veröffentlicht. Sowohl im Sinne von, weiß ich nicht, das Modell ist es in der API oder auch einfach einen Blogpost schreibt, noch zu sagen: So, und hier ist, wie wir es gemacht haben und die Details, wie wir es gemacht haben, sind mal sehr konkret, also auch wirklich mit Code und den Modellgewichten, mal etwas weniger konkret, aber immer noch reproduzierbar und mal eben sehr wenig konkret wie bei GPD 4. Also da gibt es ja ein gewisses Spektrum. Und ja, also es passiert dann eher so als als Nebenprodukt, sage ich mal. Natürlich, wenn man das beschließt, ein Paper zu schreiben, dann investiert man da schon auch Zeit rein. Aber das ist irgendwie eher, dass man so ein Gefühl hat, jetzt haben wir irgendwie so einen Meilenstein erreicht, wo es einfach irgendwie sinnvoll wäre, auch für uns selbst das festzuhalten. Okay, das habe ich verstanden. Danke. Wie viel. Hast du dich oder hat das Kodex Team sich damit beschäftigt, was in der Mitte von diesem Prozess passiert? Also ihr habt ja irgendwie Input und habt überlegt, was sind Trainingsdaten und wir untersuchen unterschiedliche Trainingsdaten und gucken uns hinten raus an, was das Ergebnis ist und wie gut dieses Ergebnis ist. Wie tief. Steigt man dann ein in das Verständnis, was passiert in diesem Modell? Wie verändern sich irgendwie Gewichte? Guckt man da rein oder ist das irgendwie ausgelagert und man sagt okay, eigentlich interessiert uns der Part nicht, der wird vielleicht woanders weiter geforscht und entwickelt. Wie sehr ist man in diesem ganzen. Ding. Drin? Irgendwie muss man da ein Sent Neuron finden, oder? Genau. Also es interessiert einen schon. Wir würden das sehr gerne tun. Das ist aber sehr schwer. Und das liegt auch wieder an der an der Skala. Also als man das Sentiment Neuron gefunden hat, waren das noch gar nicht diese Transformer, die wir jetzt heute benutzen, also die Architektur, sondern das waren noch sogenannte LSTMs, das ist eine Art von rekurrenten neuronalen Netz. Und die haben den großen Vorteil, dass sie so eine Art Zustandsvektor haben, der relativ niedrig-dimensional ist. Also ich weiß nicht, sagen wir mal 1024 Dimensionen beispielsweise. Da gibt es noch eine ganz gute Hoffnung zu verstehen, was macht jedes von diesen einzelnen Neuronen? Das haben wir auch ein paar Mal gemacht. Also dieses Sentiment Neuron ist ein Beispiel. Ein anderes Beispiel, das ich geben kann, ist aus meinem eigenen Research, als ich noch im Robotik-Team war, haben wir jetzt gar nicht so viel drüber geredet. Aber ein Projekt, das wir damals hatten, war einen Rubics Cube, also diesen Zauberwürfel mit einem Roboter anzulösen. Und was sich herausgestellt hat dort ist, dass eben auch gewisse Attribute dieses Würfels enkodiert werden. Also wie groß ist der Würfel beispielsweise? Da gab es ein Neuron, das hat das enkodiert, weil wir die Würfelgröße stark randomisiert haben und das dann eben sehr wichtig ist für das neuronale Netz zu schätzen. Wie groß ist der Würfel, den ich gerade in der Hand halte? Und bei diesen Modellen kann man das ganz gut machen. Aber bei Modellen wie GPD3 ist einfach. Es gibt so viele Parameter, dass es halt eine extreme Suche der Nadel im Heuhaufen darstellt. Und ich glaube, jeder, der mit diesen Modellen arbeitet, würde... Da würden wir gerne mehr reingucken können, weil es einfach auch das Leben einfacher macht. Weil wir müssen ja letzten Endes, wie wir es in Ermangelung von Techniken machen müssen, ist, dass wir wirklich das Modell ausprobieren. Also dass wir sagen, gegeben diesem Input, was kommt hinten raus? Das kann systematisch sein, indem wir quasi, also ein Beispiel, das ich schon genannt habe, ist quasi wir geben dem Modell Probleme und gucken uns an, wie viele von diesen Problemen wurden gelöst. Es kann aber auch wirklich quantitativ sein. Also ich probiere einfach damit rum und schaue mir an. Es scheint immer so, als ob eben dieser White Space fehlt. Einfach, es fällt mir als Mensch auf, wenn ich quasi viel von den Inputs und Outputs anschaue. Also ich sample sozusagen von dieser Blackbox und versuche dadurch ein gewisses Verständnis zu bekommen. Aber das ist natürlich kein besonders tiefgehendes Verständnis, weil ja auch es kommt ja stark darauf an, was ich ausprobiert habe und was nicht. Und es wäre natürlich viel schöner, wenn wir einfach wirklich da reingucken könnten und sagen, das sind die Eigenschaften von diesem Modell gegeben der Gewichte, die gelernt wurden. Aber das ist leider momentan überhaupt nicht möglich. Es gibt Bestrebungen, das so möglich zu machen, aber die funktionieren nicht sehr gut und auch vor allem mit kleineren Modellen nach wie vor nur. Ich habe noch so drei Parts, die ich gerne verstehen würde, gerade auch was Codex und Kopiloten angeht. Wir hatten ja vorhin gemeint, wir haben das Base Modell GPT 3. Es gab verschiedene Bestrebungen, entweder Feintuning auf Basis von Source Code. Dann gab es aber auch die Bestrebung mit dem Reinforcement Learning und es ist dann ja das Source Code Feintuning geworden. Aber ist es denn der letzte Stage von Codex oder gibt es hintendran dann noch, also wird ja auch dann im Nachgang gibt es ja den Step des Reinforcement Learnings auch noch. Also ist Codex mit Source Code trainiert und das ist der letzte Step oder gab es gibt es danach noch weitere? Also das Modell, das ursprüngliche Codex Modell, das war der letzte Step. Gpt4 ist ja auch ein Modell, das programmieren kann, wie wir alle wissen. Und das wurde spezifisch auch noch mit Reinforcement Learning am Ende verfeinert. Aber bei Codex hat das noch nicht stattgefunden. Was aber interessant ist und was auch tatsächlich dann auch mein Research war, ist, dass man natürlich viele Optimierungen am Ende noch machen kann. Also eine Beobachtung, die relativ früh stattgefunden hat, ist, dass man, wenn man ein Modell hat und jetzt wieder misst auf diesem bereits genannten Benchmark, wie viele von meinem Problem kann ich lösen? Also wie viele Tests sind grün? Wenn man von dem Modell eine einzige Lösung zieht, also ich sage für jedes Problem darfst du eine Lösung generieren und das war's, ist die Performance, na ja, wenn ich dem Modell aber erlaube beispielsweise zehn Lösungs-Kandidaten zu generieren und probiere dann jeden aus und sage Okay, ich sehe das auch als Erfolg, wenn einer von den zehn okay war, ist die Performance weit besser. Das heißt, das Modell ist durchaus in der Lage dazu, das Problem zu lösen. Es braucht nur mehr Versuche. Das ist ja hilfreich. Also wenn ich diese Beobachtung gemacht habe, kann ich ja sagen: „Okay, ich kann also aus meinem gegebenen Modell mehr Performance herausbekommen, wenn ich quasi mehrfach probiere und eben entscheiden kann, war das ein guter oder ein schlechter Versuch. Die Annahme, dass ich immer den Code ausführen kann und Unit-Tests habe und so weiter und so fort, ist ja nicht notwendigerweise gegeben. Aber interessante Forschung kann ja beispielsweise sein zu sagen, ich versuche zu lernen, welcher Code korrekt oder indirekt ist. Weil auch da kann ich mir relativ gut Trainingsdaten generieren. Also Code hat ja die sehr angenehme Eigenschaft, dass ich ihn ausführen kann und gucke, was passiert. Und ich kann mir jetzt Probleme suchen, wo das möglich ist. Beispielsweise weiß ich auch nicht, beispielsweise wieder Open Source Projekte, die eben Unit-Tests sind und mir dann Funktionskandidaten suchen und eben gucken, ich generiere eine Funktion, lasse die Unit-Tests laufen, sind die Tests grün oder nicht grün und versuche jetzt aber zu lernen, ohne dass ich die Unit-Tests gesehen habe, ist dieser Code korrekt oder indirekt? Und sobald ich so ein Modell habe, kann ich das ja in die Sonderprozedur auch wieder einbauen. Das heißt, ich ersetze sozusagen die Unit Tests durch so eine Art gelerntes Oracle, das mir versucht vorherzusagen, stimmt dieser Code oder stimmt er nicht? Aber dann kann ich zehnmal von dem Modell ziehen und eben den vielversprechendsten Kandidaten auswählen und bekomme eben eine bessere Performance am Ende. Und das war beispielsweise Forschung, die ich dann auch noch gemacht habe, während ich bei OpenAI war. Das ist aber nicht in dem Codex Modell selbst, sondern das war in der früheren Phase sozusagen, wir probieren diese Ideen aus. Da wurde dann auch ein Paper drüber geschrieben in einer etwas anderen Domäne. Das war nicht nicht Code, sondern Mathematik. Also kann ich quasi Rechenaufgaben besser lösen mit dieser Methode? Und die Antwort war sehr eindeutig Ja. Sehr gut. Eine Frage, die ich mir jetzt gestellt habe, gefühlt, wenn wir jetzt in eurem ganzen Research sind mit Codex und so, es war ja alles eine Zeit, in der ihr jetzt Open AI dann Dinge releast habt, die auf jeden Fall auch public wurden, so, aber gefühlt, wenn man jetzt OpenAI betrachtet, hat OpenAI sehr viele Produkte, also so seid ihr ein Research Institute, aber ich frage mich jetzt so ein bisschen, wie wurde aus Codex, GitHub, Co-Pilot und wie hat das vielleicht auch OpenAI verändert, dass es so wirklich so breite Massenprodukte dann jetzt auch gibt mit dann auch der Chat-GPT und so weiter. Also vielleicht am Beispiel aber Codex, wie wurde denn aus Codex dann, also war GitHub von vornherein, seitdem ihr die Daten dann genutzt habt, so da irgendwie mit an Bord? Habt ihr irgendwann gesagt, das scheint jetzt hier gut zu funktionieren, Github, sind ja eure Daten, lass mal zusammen... Wie ist daraus Co-Field geworden? Grundsätzlich kann man sagen, dass Open AI ja als reine Forschungseinrichtung gestartet hat. Und was dann eben passiert, sind zwei Dinge. Zum einen gab es ja diese Modelle, also beispielsweise GPD 2, die interessant sind, die wir aber nicht einfach so ins Internet werfen wollten, weil wir wirklich nicht wussten, also es gibt ja auch immer Leute, die sagen, das war alles nur Marketing. Aber aus der Innenperspektive würde ich sagen, sehr eindeutig war das nicht nur Marketing. Wir wussten nicht, was passiert, wenn wir einfach GDP2 komplett offen zugänglich machen. Weil das Modell war, das eine Qualität hatte, dass es so noch nicht gab und nicht klar war, was weiß ich nicht, wir veröffentlichen es und plötzlich wird ganz Twitter mit Propaganda überflutet. Und wir wollten aber natürlich trotzdem gerne diese Modelle in irgendeiner Art und Weise teilen. Und da hat sich eben diese Idee der API angeboten, weil man eben noch eine gewisse Kontrolle behält. Also man kann das Modell zugänglich machen, also fordern, aber natürlich auch Kunden. Ich kann aber den Access auch wieder abschalten und ich habe sozusagen auch die Möglichkeit Monitoring zu betreiben, also beispielsweise problematische Muster zu erkennen. Wenn ich das Modell veröffentliche, kann ich das nicht mehr zurücknehmen. Und gleichzeitig ist natürlich schon auch so, dass kommerzielle Interessen eine Rolle spielen. Also AI Research ist teuer und wenn ich diese API habe, kann ich natürlich auch den Zugang zu dem Modell verkaufen. Also das will ich jetzt nicht in Abrede stellen. Das spielt natürlich auch eine Rolle. Wobei im Großen und Ganzen, wenn man sich anschaut, wie viel Geld Open AI bekommt, ist die Einnahme aus der API mit Sicherheit immer noch relativ gering. Die dritte Sache, die aber auch interessant ist, ist, Kontakt mit der Realität zu haben, weil diese Systeme ja letzten Endes sich, also man lernt ja sehr viel über diese Systeme, wenn sie von der breiten Nutzerbasis verwendet werden, sowohl was ihre Fähigkeiten angeht, weil wir können das ja auch nicht alles selbst testen, aber auch was ihre Probleme angeht. Und das ist eben auch sehr wichtig, das früh zu tun. Weil wenn wir jetzt sagen, okay, OpenAI ist Absicht, ist tatsächlich ADI und wir veröffentlichen zum ersten Mal irgendwie was, wenn wir ADI haben, ist die Wahrscheinlichkeit, dass das nicht so gut verläuft, relativ groß, weil man hat ja keinerlei Erfahrungen gemacht. Und die Idee ist eben zu sagen, wir veröffentlichen Modelle, wo das Risiko weit geringer ist oder vielleicht sogar gar nicht existiert, inkrementell und lernen sozusagen aus unseren Fehlern, wenn sie noch nicht besonders schlimm sind und verbessern sozusagen immer weiter durch diesen Realitätskontakt. Und deswegen dieses API-Modell kam ja dann auch mit GPS 3 auf. Zu deiner Frage, wie das bei CoPilot war, würde ich sagen, es gab relativ früh intern die Erkenntnis, dass dieses Modell halt wahrscheinlich praktisch ist als so eine Art Assistent, also in BS Code beispielsweise als Autocompleet. Da gab es eine Person bei uns, die das einfach mal ausprobiert hatte, so als quasi Nebenprojekt. Und das schien ganz interessant zu sein. Und dann war aber wie so oft eben die Sache auch, wir wollen ja auch fokussiert bleiben. Also wenn wir jetzt quasi alle nur noch ein Produkt bauen, haben wir keine Zeit mehr für die Sachen, die wir sonst so machen wollen. Das ist auch einer der Gründe für die API, dass es sozusagen die Möglichkeit ist, ein Produkt als Mittelsmann zur Verfügung zu stellen und nicht notwendigerweise das gesamte Endprodukt selber bauen zu müssen. Und dadurch kam eben dann diese KooperationKollaboration mit GitHub zustande. Und ich würde sagen, das war für alle Seiten gut, weil OpenAI wollte nicht unbedingt das alles selbst entwickeln, weil wie gesagt einfach viel Overhead den OpenAIn nicht notwendigerweise wollte. Und GitHub war natürlich super interessiert daran, weil die halt auch relativ früh verstanden haben, wie interessant das sein kann. Und ich würde sagen, das war dann eigentlich eine sehr positive Kollaboration. Der letzte Part, den mich jetzt da interessieren würde, ist, dass Codex, also das ist ja zum Zeitpunkt Github Co-Pilot, was wir genutzt haben, gab es Codex und GBT 3 jetzt, wenn ich es richtig verstehe, ist ja der Co-Pilot X auf GBT 4. Also es gibt eigentlich kein speziell gefinetuntes Modell für Source Code Generierung, sondern wir sind jetzt auf einem Modell, was sozusagen schon koden kann und wir das Base-Modell GBT 4 oder das am Ende ist es genau dasFineintuning ist ja auch ein feingetuntes Modell, das wir auch in ChatGPT haben oder was andersrum. Fragen, die sich mir stellen, ist es in GitHub Co Pilot X, so GPT4, wie wir es auch kennen von ChatGPT oder ist es doch irgendwie anders gefeint und ist der eine Teil der Frage. Und das zweite ist, wenn jetzt bei einem Beispiel wie Codex wir kein explizites Feintuning mehr für so eine Domäne brauchen, so werden wir uns dann immer mehr in die Richtung entwickeln, dass das Feintuning eigentlich ein obsoleter Schritt wird für bestimmte Domänen oder wie sieht da die allgemeine Entwicklung aus? Ja, also das ist leider alles ein bisschen verwirrend. Also zum ersten, CoPilot X sind ja verschiedene Dinge. Zum einen diese Chat-Funktionalität, zum anderen aber auch noch Sachen wie CoPilot for Docs und noch ein paar andere Dinge. Die verwende ich notwendigerweise alle dasselbe Modell. Da kann ich jetzt nicht extrem ins Detail gehen, aber manche verwenden GDP4, manche nicht unbedingt. Die andere Frage ist auch interessant, weil wie du ja schon korrekt festgestellt hast, findet da eine gewisse Konsolidierung statt. Also es gibt nicht mehr, es ist ein separates Code Modell und ein separates Sprachmodell, also GPS 3 versus Codex, sondern es ist ein gemeinsames Modell. Und der Grund, warum das so ist, ist, dass zum einen historisch bedingt einfach GPS 3 schon existiert hat und man eben dann den kürzesten Weg gegangen ist, Codex zu erzeugen. Aber wenn man quasi jetzt neue Generationen trainiert, natürlich sagen kann, vielleicht ist es sinnvoll, direkt auf Code und Sprache oder Text gleichzeitig zu trainieren. Bei Chip4 ist es sogar noch weitergehend, dass auch noch auf Bildern trainiert wurde. Das kommt ja noch dazu. Es ist ja wirklich ein sehr multimodales Modell. Da ist es natürlich naheliegend zu sagen, okay, lesen. Es gibt da keine Unterscheidung mehr zwischen Code und Text, wenn wir auch auf Bildern trainieren. Es ist aber richtig, dass du natürlich diese Spezialisierung verlierst. Es scheint aber so zu sein, und wie gesagt, das ist jetzt auch Spekulation auf meiner Seite, weil ich bin ja nicht mehr bei OpenAI und weiß über GDP4 auch nur so viel wie wir alle, dass da durchaus Synergien bestehen. Also wenn man sich bei GDP4 zum Beispiel anschaut, wie gut es im Programmieren ist, ist es signifikant viel besser als Codex. Und das mag zum einen den Grund haben, dass es ein größeres Modell ist, aber unter Umständen ist es auch einfach hilfreich, da weniger zu unterscheiden, weil eben vielleicht es auch hilfreich ist, wenn man auf natürlicher Sprache trainiert hat oder auch beispielsweise, ich weiß nicht, auf Stack Overflow, die ganzen Dokumentationen von Open Source Projekten und so, das hat ja alles Synergien. Und ich würde sagen, dass es generell ein Trend, den man so beobachten kann, ist, dass sozusagen die Spezialisierung dieser Modelle abnimmt und sie wirklich breiter werden, was ja auch Sinn macht, wenn man versucht, ADI zu bauen, weil am Ende des Tages möchte man ja ein Modell haben oder zumindest ein System, das sehr breit fähig ist. Der Nachteil ist natürlich, dass ich nicht mehr so einfach sagen kann, okay, ich feintunen dieses Modell jetzt für diesen spezifischen Use Case. Die Modelle sind natürlich auch teurer und größer und so weiter und so fort. Also es ist jetzt nichts, was es nur positiv ist, aber das ist eben der Trend, den man da sehen kann. Und die Performance von GPS4 auf diesem standardisierten Benchmark Human Eval ist extrem, extrem gut. Also ich glaube, inzwischen sind wir an einem Punkt, wo 70% dieser Probleme gelöst werden. Ich glaube, Codex am Anfang hatte in etwa 20% der Probleme gelöst. Also es ist ein sehr, sehr großer Fortschritt. Perfekt. Habe ich verstanden. Vielen Dank. Du hast mir wirklich einen sehr guten Überblick darüber gegeben, wie die Entwicklung da war und ich glaube auch einige Bausteine, gerade wenn man es auch noch mit unserer grundlegenden Einfolge davor zusammen verbindet, so irgendwie noch mal bei mir auf jeden Fall viele Lücken dann noch mal gefüllt hast. Wenn ich dann noch überige Fragen. Super spannend alles. Und klar könnte man glaube ich noch in einigen Bereichen noch mal ins Detail gehen. Eine eher so ein bisschen Metafrage, die noch in meinem Kopf rumschwirrt. Wie bewusst ist dir das oder vielleicht auch Open AI gewesen, was da für Möglichkeiten vielleicht entstehen? Also hat man relativ früh schon gemerkt, das wird ein Ding, das wird alles verändern? Kam es auch für euch überraschend letztendlich diese sehr großen Sprünge, die es jetzt am Ende gab? Also wie ist dein eigener Blick, wenn du jetzt zurückblickst darauf? Ja, also ich bin überrascht, recht häufig, was die Geschwindigkeit des Fortschritts angeht. Also ich erinnere mich noch, als ich 2017 angefangen habe, waren wirklich sehr grundlegende Sachen einfach noch komplett undösbar. Also wir haben uns damit rumgeschlagen, 2017 irgendwie wirklich sehr simple Sachen wie kleine Atari Spielchen oder so zu lösen und es war ultra schwierig und es hat ewig gedauert und ein starker Aha-Moment war damals beispielsweise schon, dass wir quasi nicht arg viel später plötzlich einen DOTA 2 Bot hatten, der sozusagen diese Technik, die bei Atari schon sehr schwer war, einfach skaliert hat und plötzlich konnteman irgendwie, ich weiß nicht, sehr gute menschliche DOTA 2 Teams besiegen. Und bei diesen Sprachmodellen würde ich sagen, ähnliche Überraschung, dass dieser sehr simple Ansatz, es ist ja wirklich simpel auf eine gewisse Art. Also ich nehme einen Text und versuche immer das nächste Wort vorherzusagen. Dass da diese ganze Komplexität nicht rein designt wird vom Menschen, sondern einfach passiert, weil es dir hilft, dich zu begreifen. Das Beispiel, das ich vorher genannt habe. Wenn du halt das gesamte Internet hast und alle Tasks darin versuchst irgendwie vorherzusagen, dann musst du halt lernen, Kopfrechnen, Resening und so weiter und so fort. Und ich würde sagen, es war alles andere als offensichtlich für die allermeisten. Ich glaube, es gab Leute, die sehr viel Weitsicht hatten bei OpenAI, also die sehr früh realisiert haben, was dort passiert. Aber ich glaube schon, dass viele Leute auch bei OpenAI von der Geschwindigkeit des Fortschritts überrascht waren. Das ist meine Wahrnehmung. Es ist aber schon auch so, dass Leute, die diese Firma gegründet haben, 2016 bereits gesagt haben, wir wollen ADI machen und das ernst gemeint haben. Und das wirkte damals, würde ich sagen, sehr, sehr verrückt. Und es wirkt bei weniger verrückt heute. Es ist vielleicht immer noch verrückt, aber es ist sehr, sehr viel weniger verrückt. Ich meine, wir sehen inzwischen, weiß ich nicht, Politiker über AGI sprechen. Das war 2016 völlig undenkbar, dass irgendwie der Präsident der Vereinigten Staaten über EDI spricht. Und es gibt bei Open AI schon Leute und ich würde sagen, viele der Gründungsmitglieder sind eben diese Leute, die schon sehr früh realisiert haben, dass es jetzt wahrscheinlich irgendwie möglich sein könnte. Es war natürlich von Anfang an unklar, ob und wann. Aber es war nicht so, dass die Leute naiv waren, sondern gesagt haben: „Wir probieren es jetzt halt mal halt. Was kann schon passieren? Sondern schon gesagt haben: „Hm, die Zeit könnte jetzt ganz gut sein. Und sie hatten ja offensichtlich recht. Ich meine, ob am Ende Hedge Alweil rauskommt oder nicht, wissen wir alle nicht. Aber zumindest hat die Firma hatte sehr viel Impact. Und das beeindruckt mich schon auch als jemand, der dort war, nach wie vor, dass dort Leute wirklich sind, die einfach sehr, sehr viel Weitsicht haben. Warum sie das haben, weiß ich nicht, ob sie wirklich so genau drüber nachgedacht haben oder ob es auch ein bisschen Glück war. Vielleicht auch eine Mischung. Aber ja. Cool. Letzte Frage: ADI. Was würdest du sagen, kommt es? Und wenn ja, wie lange dauert es noch? Also einfach zum Schluss. Ganz einfach zum Schluss. Ganz kurz beantworten. Also dass es grundsätzlich möglich ist, habe ich inzwischen keine Zweifel mehr. Hatte ich auch ehrlich gesagt noch nie, weil ich glaube, es ist auch ein bisschen vermessen. Warum sollte so etwas wie Künstliche Allgemeine Intelligenz nicht grundsätzlich möglich sein, wenn es Menschen gibt? Man kann natürlich viel über die Definition streiten und so weiter und so fort, aber wir sind ja irgendwie ein Existenzbeweis. Also grundsätzlich denke ich, es wird früher oder später passieren, außer wir entscheiden uns bewusst, es nicht zu tun. Wie lange das noch dauert, finde ich wahnsinnig schwer zu sagen. Ich glaube, das ist auch das, wo solche Vorhersagen fast immer massiv scheitern. Also entweder es geht sehr viel schneller. Also es gibt da viele Beispiele in der Vergangenheit, beispielsweise die Ride Brudders mit ihrem Flugzeug, die selber irgendwie, ich weiß es nicht mehr, es wird noch Jahrzehnte dauern und ich glaube ein paar Jahre später sind sie dann geflogen und bei der Atombombe ähnlich. Es gibt aber auch viele Beispiele in einer anderen Richtung, wo Leute, weiß ich nicht, im Space Ride gesagt haben: „Ja, in zehn Jahren wohnen wir alle auf dem Mond und dann sind wir nicht wirklich so weit gekommen. Also ich finde es sehr, sehr schwer, eine Vorhersage zu treffen, wann. Wie gesagt, meine hauptsächliche Beobachtung ist, dass es schneller voranschreitet, als ich es erwartet hätte. Das heißt, ich gehe eher davon aus, dass es schneller als später passieren kann. Finde es aber wirklich sehr, sehr schwer, da irgendwie zu sagen, in fünf Jahren oder in zehn Jahren oder in fünfzig Jahren. Ist vielleicht ein bisschen unbefriedigende. Antwort, aber... Völlig in Ordnung. Sehr gut. Selbstfahrende Autos haben wir ja auch noch nicht, obwohl die schon sehr klar vorhergesagt wurden. Obwohl sie schon. Verkauft wurden. Obwohl sie schon verkauft wurden. Vielleicht noch so ein bisschen, weil dann ist ja gerade eigentlich die letzte Frage, was mich noch interessieren würde. Jetzt haben wir viel über OpenAI geredet, was du zwischenzeitlich auch bei GitHub ist es jetzt aber nicht mehr. Aber so die Frage, was wäre auch eine natürliche Entscheidung gewesen, bei OpenAI zu bleiben, so wie es im Moment da gerade aufwärts geht? Gibt es etwas spruchreifes, was bei dir als nächstes ansteht? Irgendwas, dass man vielleicht auch Werbung machen kann oder keine Ahnung, irgendwas, von was du erzählen kannst, was bei dir als nächstes passiert, oder? Ja, also grob gesagt kann ich auf jeden Fall sagen, dass ich glaube, dass es gerade eine sehr, sehr interessante Zeit ist, weil natürlich viele Leute jetzt realisiert haben, da passiert was und auch einfach die Möglichkeiten sehr, sehr groß sind. Zum einen existieren sehr gute Modelle in den APIs, zum anderen existieren aber auch sehr gute Modelle, die Open Source sind. Es ist eine wirklich wahrhafte Explosion da in der Open Source Community, die super innovative Sachen machen, Modelle, die durchaus groß sind, also 30 Milliarden Parameter plus plötzlich auf meinem M1 Mac lauffähig sind, was vor einem Jahr noch völlig undenkbar war. Es ist einfach sehr spannend. Und mein konkretes Ziel ist im Endeffekt, diese Zeit zu nutzen und wirklich zu sagen: „Okay, was kann man wirklich jetzt bauen? Weil ich bin jemand, der forscht, aber was mich am glücklichsten macht, ist wirklich einfach Sachen zu bauen. Ich meine, ich habe iOS Apps gebaut, ich habe eine Roboterhand gebaut, die einen Rubix kubelt. Ich habe versucht, ein Modell zu bauen, das koten kann und das ist im Endeffekt das, was mir wirklich Spaß macht. Und ich habe festgestellt, dass es die interessanteste Zeit seit langem selber was zu bauen ist. Und das ist mein Plan. Was genau das sein wird, weiß ich selbst noch nicht. Also ich habe da so ein bisschen Vertrauen in den Prozess und werde einfach mal drauf los bauen und gucken, was passiert. Das hat bisher in meinem Leben gut funktioniert. Deswegen denke ich, könnte es auch wieder klappen. Was ich nebenher allerdings noch mache, unter anderem nicht zu vereinsamen, aber auch ein bisschen die Rechnungen zu bezahlen, ist Firmen zu helfen, die auch interessiert daran sind, eben mehr AI und Machine Learning in ihre Firmen zu bringen, technisch zu unterstützen. Also das ist hauptsächlich Beratungstätigkeit auf relativ hohem Level. Also dass ich jetzt nicht wahnsinnig viel für die Programmierer, sondern ihnen eher erkläre, was Trends sind, welche Tools existieren, welche Richtungen vielleicht sinnvoller sind als andere und so ein bisschen Übersicht schaffe, weil dieser Space, ihr wisst es ja wahrscheinlich selbst sehr, sehr unübersichtlich ist, sehr, sehr schnelllebig ist und dort versuche ich so ein bisschen Hilfestellung zu geben. Also auch viel für Startups beispielsweise, was mir auch einfach Spaß macht. Also das ist vielleicht am ehesten das, wo man Werbung für machen kann, dass man mich hiern kann für diese Art von Aktivität. Allerdings bin ich schon relativ stark ausgebucht, weil ich auch genug Zeit noch haben möchte, an meinem eigenen Projekt zu arbeiten. Aber wenn da jemand was Interessantes hat, dann kann er mir gerne eine E-Mail schreiben. Und Kontaktdaten kommen in die Shownotes. Und ansonsten wer weiß, wenn dein Weg des Bound weitergeht, vielleicht können wir uns ja in nicht allzu ferner Zukunft noch mal über das unterhalten, was da rauskommt. Sehr gerne. Schön. Matthias. Vielen, vielen Dank, dass du heute hier war super spannende Einblicke und mega cool, da mal mit jemandem gesprochen zu haben, der so nah dran war an all dem, was heute überall in den News ist und Nachrichten und uns irgendwie alle ja seit einigen Monaten sehr viel beschäftigt, weil es ja viel von unserer tagtäglichen Arbeit irgendwie auch ändern wird in der Zukunft und daher ja eigentlich jedem nahegelegt sein kann, sich damit auseinanderzusetzen und sich immer weiter zu informieren, was in diesem Bereich alles passiert. Wir wünschen dir auf jeden Fall ganz viel Erfolg bei deinen neuen Schritten, die du jetzt gehst. Vielen Dank, dass du heute dabei warst. Danke Fabi und an unsere Hörer*innen wie immer die Bitte, wenn ihr Feedback zu dieser Folge habt, schreibt uns gerne an podcast@programmier. Bar und das war's. Vielen Dank Matthias. Vielen Dank. Hat viel Spaß gemacht. Danke, dass ich Gast sein durfte. Sehr gerne. Bis dann. Mach's gut. Tschüss.