Erste KI-Firma 2014 an Deepmind verkauft und jetzt baut er seine dritte KI-Firma: Was brauchen die KI-Firmen der Zukunft?

[0:00] Hatte auch mal mit ein paar von den OpenAI-Gründern gesprochen, dann aber relativ bald für mich erkannt, ich will nicht zurück in die reine Forschung. Wenn wir irgendwann von diesem 20-25%-Ding auf ein 20x-Ding kommen, dass du dann auch eine positive Value Proposition dahinter hast. Weil es sagen können, guck mal, hiermit könnt ihr plötzlich besser M&A machen. Und dann gibt es hier Beispiele für die drei Biotechs, die ihr hättet kaufen sollen, die ihr kaufen wolltet, aber als ihr mit der Analyse fertig wart, waren die schon verkauft. Klar, wir haben eine abstrakte Roadmap, das ist so ein bisschen die von hier zum dicker Korn. Wenn ich jetzt jemanden habe, der irgendwo im mittleren Management sitzt, der hat ein Budget von 100.000 Dollar, die er ausgeben kann für Piloten, aber der hat noch die Software gekauft und der wüsste nicht mal, wie das geht in der Firma, dann bringt das nichts. Wenn ich mit 85% Sicherheit auf Pferde wetten kann, werde ich reich. Wenn ich ein Modell habe, das mit 85% Sicherheit ein Atomkraftwerk kühlen soll, dann ist das richtig schlecht. Das wäre jetzt auch albern zu sagen, jeder muss jetzt KI-Modelle entwickeln, weil das irgendwie sexier klingt. Wenn du das auf der Shelf nutzen kannst, ist doch mega, dann mach das doch einfach. KI-Firma oder KI-Firma, das wird sich noch herauskristallisieren über die nächsten Jahre.

[0:59] Was ist der Unterschied zwischen KI-Firma und KI-Firma? Also zwischen, ja, ich baue mal hier ein bisschen was und nehme ChatGPT und packe da was drauf und das ist jetzt mein Produkt und ich baue wirklich eine Firma, wo KI der zugrunde liegende Baustein ist. Und darüber habe ich heute mit Karl-Moritz Herrmann gesprochen.

[1:16] Karl-Moritz hat vorher seine erste Firma an DeepMind verkauft, also quasi Google war dann jahrelang Forscher bei DeepMind, ist dann wieder Unternehmer geworden, hat Saiga gegründet. Saiga ist dann tatsächlich insolvent gegangen, sprechen wir in dem Podcast auch drüber und ist jetzt der Gründer von Reliant AI. Die haben gerade mehr als 11 Millionen Seed-Finanzierung geraced von kanadischen Investoren, haben eine KI gebaut, mit der du Pharma-Prozesse besser abbilden kannst. Das heißt sowohl zur Entscheidung, welche Studien führen wir durch mit wem, aber auch zu, welche Firmen wollen wir kaufen, also wirklich das M&A-Geschäft in der Pharma-Industrie. Und dadurch, dass er natürlich alles gesehen hat, von KI-Firma selber gründen bis hin zu wie funktionieren die großen Forschungsteams dieser Welt, wie bei einem Deepmind, habe ich mit Kai Moritz viel darüber gesprochen.

[2:02] Was sind die Unterschiede? Also wenn ich jetzt heute losrennen würde, eine KI-Firma bauen, sieht es sicherlich ganz anders aus, als wenn Kai Moritz eine baut. Und da sind wir tiefer eingestiegen, haben versucht viel hinter seinen Ansatz Reliant AI aufzubauen, nachzudenken, wie sieht das aus technischer Natur aus, aus Produktnatur, wie geht man damit um, wenn sich dauernd die Modelle verändern, also wie ein GPT oder andere Large Language Models, wo ich dann ja als Firma auch anpassen muss, wie mein Produkt funktioniert. Deswegen sehr tiefer Einblick in wohl eine der spannendsten KI-Firmen, die wir hier gerade im Dachraum haben und ich glaube das erste lange Interview, das Kai Moritz überhaupt gegeben hat und dementsprechend ganz viel Spaß in die Einblicke in den Kopf, dass wohl einen der spannendsten Forscher zum Thema KI und Unternehmer zum Thema KI in Deutschland vor allem und wahrscheinlich auch Europa und deswegen starten wir direkt los. Du hörst Unicorn Bakery, mein Name ist Fabian Tausch und jetzt viel Spaß mit Kai Moritz von Reliant AI.

[3:00] Karl Moritz, herzlich willkommen bei Unicorn Bakery. Hi, vielen Dank für die Einladung, Fabian. Wir haben das erste Mal gesprochen vor einigen Jahren. Seitdem hast du eine neue Firma gegründet und hast jetzt gerade 11 Millionen von Investoren bekommen. Und wenn ich mir das auf dem Papier angucke und mir den Werdegang der Firma aktuell anschaue, KI-Firma, klar, gerade eine positive Zeit für KI generell.

[3:22] Starkes Research-Team, also Ex-Deep-Mind-Leute, die dann irgendwie eine Firma gründen in dem Bereich, wo man einfach sagen würde, okay, das sieht erstmal vom Setup her gut aus, wenn ich mir das angucke, noch nicht so lange live oder auch überhaupt gegründet und irgendwie 11 Millionen Seed, was jetzt auch nicht, kann man darüber streiten, ich glaube, es gibt manche, die sagen, es ist ein kleines Seed für KI, wenn man es mit UF vergleicht, da sage ich, es ist ja generell erstmal eine große Seed-Runde, aber grundsätzlich sage ich, auf dem Diagramm von links unten nach rechts oben, scheint es mir eine erstmal recht gerade Linie zu sein und es scheint sich eigentlich ganz gut zu entwickeln. Gibt es Dinge, wo du sagst, hey, um mal ganz ehrlich zu sein, da gibt es auch ein paar Momente, die vielleicht nicht ganz so rosig waren und die sollte man da vielleicht auch noch mit in Betracht ziehen? Du, sicher. Ich glaube, Seed Announcement ist immer so ein Punkt, immer sehr punktuell und vielleicht, wenn man so im Maß die Punkte anschaut, im Mittel, dann geht das schon irgendwie in die richtige Richtung. Natürlich ist es ein ständiges Auf und Ab. Ich habe mich vor zwei Wochen mit einem anderen Gründer darüber gesprochen, der eine deutlich größere Firma hat, die sind deutlich weiter. Der meinte auch einfach ein Pre-Project-Market-Fit-Startup, das ist brutal schwierig, das ist brutal hoch und runter die ganze Zeit, bis du dann irgendwann an dem Punkt kommst, an dem Punkt weiter bist. Dann ist es immer noch schwierig auf eine andere Art und Weise schwierig. Insofern ja, absolut. Das würdest du sagen, ich meine am Ende, wenn man da nochmal reinguckt, du hast ja vor, also du hast eine Firma an Google verkauft, beziehungsweise DeepMind, an DeepMind verkauft, muss man sagen.

[4:44] Google hat sie bezahlt, aber DeepMind hat sie geschluckt. Genau, so rum bist du dann bei DeepMind gewesen, hast dann Saiga gemacht. Saiga war eigentlich das, was du heute mit Reliant machst, nur auf der Horizontalen, das heißt eigentlich mir Sachen zu erleichtern, dass ich meine Steuererklärung oder meine Anmeldung beim Amt oder ähnliches damit vereinfachen kann. Saiga gibt es heute nicht mehr. Jetzt gibt es Reliant, wo ihr das quasi euch überlegt, welche Prozesse gibt es in der Pharmaindustrie, die ich am Ende simplifizieren kann, dadurch, dass eben KI mir helfen kann, wenn ich irgendwie Mitarbeiter in dem Konzern bin und Sachen vorbereiten muss und mir Gedanken machen muss, aber sehr viel Zeit mit Research zum Beispiel verbringe. Schön gesagt, Saiga gibt es heute nicht mehr. Lass uns da mal vielleicht einen Schritt zurücknehmen und bevor wir über Reliant sprechen, auch erst mal kurz über Saiga sprechen. Was ist da passiert, dass am Ende aus einer Firma, die die, ich hab mit vielen gesprochen, die meinten, also ich glaub, wer damals gesagt hat, wir sollten mal sprechen und uns connected hat, war Michael Brehm, der ja I2X gemacht hat und Michael meinte, ey, mit Karl Moritz musst du unbedingt mal sprechen und ich meine, er war damals trotzdem, ich würd sagen, nicht gehypt. Also, und es gab schon irgendwie viele, die gesagt haben, hey, das muss man sich genauer angucken, was passiert. Du, ähm.

[5:55] Was passiert ist ganz klassisch, wir hatten irgendwann kein Geld mehr, dann mussten wir in die Insolvenz. Es ist immer schwierig zu sagen, woran das genau gescheitert ist. Es ist gescheitert, wir hatten kein Geld mehr und das war, weil wir keine Investoren gefunden haben für die nächste Runde. Am Ende der große Unterschied zwischen dem, was wir bei Saiga versucht haben und jetzt bei Reliant ist natürlich, wie du gesagt hast, Saiga, das war ein B2C-Setup, das ging darum, Arbeit im Privatleben zu verleichtern, Prozesse, Admin-Themen, Mental Load im Privatleben zu automatisieren.

[6:22] Und wenn du dein Privatleben anschaust, das ist ja nicht so, dass du irgendwie ein Thema hast, das jeden Tag nervt. Das Problem ist, dass diese Wäscheliste im Kopf, Mental Load, und wenn ich da wirklich was helfen will, dann geht das darum, diese Wäscheliste abzuarbeiten. Das heißt, ich muss eine ganze Bandbreite an Themen von Anfang an bedienen, damit das funktioniert. Und das zu automatisieren ist natürlich brutal schwierig, weil wenn ich eine perfekte Software habe, die Strafzettel für dich bezahlt, dann ist das eine App, die benutzt du zweimal im Jahr oder wenn du so fährst wie ich vielleicht auch fünfmal im Jahr, aber nicht jede Woche, wenn ich eine App habe, die Kindergeld für dich beantragt. Das ist ein Prozess ein paar Mal im Leben. Und da sozusagen auf dieses Engagement zu kommen, dass du wirklich alles abdeckst, ist einfach eine andere Herausforderung nochmal. Was wir jetzt bei Reliant machen, ist ja die gleiche Idee. Das geht darum, wie können wir KI nutzen, um ein bisschen Mental Media Labor zu automatisieren. Wie können wir Sachen wegautomatisieren, die eigentlich kein guter Einsatz unserer Zeit sind. Sachen, wo es darum geht, die Vorarbeit zu leisten für die eigentliche Arbeit. Wir wollen nicht Menschen, die Arbeit abnehmen, wir wollen Menschen, die Vorarbeit abnehmen. Der Vorteil jetzt natürlich in einem B2B-Setup ist, da finde ich Prozesse, die Menschen ständig machen. Da finde ich Sachen, da lohnt es sich, ein einziges Thema wirklich durchzuautomatisieren. Dann gibt es genug Menschen, da gibt es genug dann auch Markt dahinter, dass so eine Lösung funktioniert. So, bei Saiga war das nicht der Fall. Bei Saiga, das war immer, du musst die Breite abdecken.

[7:38] Wir waren jetzt auch nicht die erste Firma, die versucht hat, einen digitalen Assistenten fürs Privatleben zu entwickeln. Davor gab es Ansätze in Deutschland, wahrscheinlich ist GoButler das bekannteste Beispiel. In Amerika war Magic unter anderem. Was die gemacht hatten, war immer zu sagen, wir skalieren das ganz schnell hoch mit Humans in the Loop.

[7:55] Sprich, wir haben dann einfach Hallen voller Mitarbeiter, die manuell die Sachen machen, die noch nicht automatisiert sind und kommen dann irgendwann über die Scale an den Punkt, dass wir die Themen auch einzeln automatisieren können. GoButler etc. sind dann immer daran gescheitert, dass denen in den Folgerunden niemand geglaubt hat, dass sie dieses Automatisierungsproblem gelöst bekommen. Bei Saiga haben wir deshalb den umgekehrten Ansatz gefahren. Ich habe gesagt, wir versuchen das so klein wie möglich zu halten. Wir hatten am Ende um die 100 Kunden drauf, wirklich wenig. Weil ihr noch nicht mehr Kunden drauf haben wolltet oder weil ihr noch nicht mehr Kunden überzeugt habt? weil wir nicht mehr drauf haben wollten. Wir hatten eine riesige Warteliste und die Kunden, die drauf waren, die waren auch sehr glücklich damit. Ich kriege jetzt auch noch ab und zu in Gesprächen oder E-Mails von Menschen, die traurig sind, dass das Ding nicht mehr gibt. Also die Software hat funktioniert. Was waren die Cases, die ihr bis nachhin irgendwie automatisiert oder systematisiert habt? Es war eine Kombination von Sachen.

[8:41] Also auf der KI-Seite das wichtigste Modell bei uns, das war gar nicht eine Case-Automatisierung, sondern das war ein Recommender-Modell. Das ging darum, wir haben mit allen Kunden am Anfang ein Interview geführt, die mussten auch so einen kleinen Fragebogen ausfüllen Und so individuell wir auch sind, sind wir doch dann einigermaßen vorhersehbar. Und das Gute an dem Recommender-Modell war, das ging darum, basierend auf deinem Profil, basierend auch auf den anderen Tasks, die du einstellst, konnte Saiger Vorschläge ausspucken. Und da konnten wir natürlich dann auch den Hebel nutzen, dass dieses Recommender-System darauf gebiased wurde, hauptsächlich Sachen vorzuschlagen, die wir durchautomatisiert haben. Das ist ja auch viel einfacher vom Setup her, wenn ich zu dir gehe und sage, guck mal hier, Vorschlag, ein Restaurant buchen für eine Date Night oder Vorschlag, du bist jetzt 35 geworden, da gibt es von den Krankenkassen eine Vorsorgeuntersuchung, die man arrangieren sollte. Wenn ich das Thema weiß, wenn ich das selber anstoße, dann ist das für die KI viel einfacher, das durchzuautomatisieren. Wenn du das einspielst von der anderen Seite, ist das deutlich schwieriger als Problem. Insofern, das hat funktioniert.

[9:37] Wir waren da auch eigentlich ganz happy mit unserem Automatisierungsgrad. Ich glaube, wo wir uns schwierig getan hatten, und das war dann der Fehler in meiner Strategie, war, dass wir gesagt haben, wir wachsen bewusst langsam, um dann sozusagen peu à peu gleichzeitig die Automatisierung hochzutreiben und zu vermeiden, dass wir so eine Situation haben, wo wir ganz stark wachsen, hunderte von Mitarbeitern haben, die manuelle Arbeit machen, mit dem Ziel, die über die Zeit redundant zu machen. Dadurch hatten wir eine Firma mit relativ cooler Technik drin, aber nichts, was irgendwie jetzt für VCs sie es ausgereicht hatte von der Fantasie her, um dann sozusagen dieses Skalierungspotenzial dahinter zu sehen. Kann ich im Nachhinein komplett nachvollziehen, der geht auf mich, aber ja, das ist schwierig im Vornherein, wahrscheinlich haben wir so ein Stück weit übersteuert, basierend auf dem, woran die vor uns gescheitert sind. Wie war das für dich persönlich? Du hast, ich meine, trotzdem ein paar Jahre an Saiger gearbeitet und dann auf einmal gesehen, okay, wir kriegen kein Geld mehr dafür und dann muss man sich ja so langsam irgendwie doch der Wahrheit stellen und sagen, okay, das, Kann sein, dass wir diese Insolvenz anmelden müssen, so wie war dieser Prozess für dich von, hey, ich glaube, wir machen genau das Richtige, hin zu, oh shit, das, was ich glaube, was richtig war, funktioniert doch nicht.

[10:44] Die beiden Sachen greifen ineinander über. Also die Insolvenz kommt, wenn du am Ende von den Fundraising-Gesprächen die letzte Absage bekommen hast. Wir hatten das ja mit genug Runway geplant. Wir waren jetzt auch nicht insolvent, es ist kein Geld mehr in der Bank, wir haben das alles rechtzeitig angemeldet. Es ist einfach absehbar, aber wir kriegen keine Folgefinanzierung mehr. Ja, das ist zum Kotzen natürlich. Das war nicht der Plan für die Firma. Ich mag die Idee weiterhin. Ich habe seit Saiga auch in mindestens drei Startups als Angel investiert, die was ähnliches planen. Ich weiß nicht, ob die bessere Chancen haben, aber ich mag die Idee sehr. Ich hoffe, dass das irgendjemand anders hinbekommt. Die Insolvenz, das ist das erstmal für Admin. Ich habe das mal gelesen. Es gibt ja so ein bisschen das Konzept, wenn jemand stirbt in der Familie, dann kriegst du erstmal absichtlich ganz viel Admin-Arbeit, damit du so ein bisschen einen Prozess hast, den du durchlaufen musst, um das zu verarbeiten. Ich glaube, bei der Insolvenz auf eine gewisse Art und Weise ist das ähnlich.

[11:31] Da kommt dann erstmal richtig viel Arbeit nochmal. Da geht es ja darum, auf der einen Seite intern, was machen wir jetzt mit den 40 Mitarbeitern? Wie kann ich da noch versuchen, das irgendwie besser zu gestalten, denen zu helfen, woanders unterzukommen, denen dann auch helfen, wenn sie nicht sofort woanders unterkommen, wie gehen sie jetzt mit dem Arbeitsamt um und den ganzen Sachen. Ein großer Teil vom Team kam nicht aus Deutschland. Dem muss ja auch erstmal helfen, hier mit der Bürokratie klar zu kommen. Auf der anderen Seite hast du dann natürlich die Insolvenz in Richtung Insolvenzverwaltung. Deshalb sich einen Akten zusammentragen und schauen, dass die alles haben, damit die ihre Arbeit machen können. Und als drittes natürlich noch in der Investorenseite. Da muss man ja auch gucken, dass man den Prozess da irgendwie transparent gestaltet und die alle mitnimmt, soweit das eben geht. Das ist mein Schritt weitergehen. Ich will gar nicht so lange drauf rumreiten, dass die eine Firma jetzt vielleicht nicht funktioniert hat. Aber die Frage, die ich mir stelle, ist natürlich so, was lernst du daraus für die nächste Firma?

[12:22] Ohne zu wissen, was das nächste Projekt wurde. Also es gab diesen Moment, sagen wir mal abgeschlossen, trotz Adminarbeit.

[12:30] Du hast weiter darüber nachgedacht, was mache ich als nächstes? Wie war der Prozess? Was war dir wichtig für das nächste Ding, was du angehen wolltest? Ja, ich glaube, am Ende nimmst du drei Sachen raus aus so einer Geschichte. Wenn du dir das Scheitern anschaust oder zumindest in meinem Fall, dann gibt das, welche Aspekte in dem Scheitern sind speziell Saiger geschuldet, dem Geschäftsmodell, daraus kann ich was lernen für den nächsten Versuch. Welche Sachen sind gescheitert durch Pech, durch Zustände, Umstände, daraus kann ich relativ wenig lernen, aber ich glaube, das sozusagen zu separieren ist wichtig. Und dann vielleicht für mich persönlich auch noch, ne, Saiga war länger als mein erstes Startup, da habe ich deutlich mehr gelernt, da habe ich auch deutlich mehr machen müssen und dadurch dann auch nochmal ein klares Bild bekommen von, was sind die Sachen, die ich gut gemacht habe, was sind die Sachen, die ich schlecht gemacht habe, aber jetzt gelernt habe, die beim nächsten Mal gut laufen und was sind die Themen, die mir einfach nicht liegen, wo ich beim nächsten Mal von allem schauen muss, dass ich dafür andere Menschen auch mit an Bord habe. Ich glaube, das ist einfach super hilfreich. Also es ist wohl relativ klar, ich bin wahrscheinlich nicht der Mensch, der, B2C-Firmen aufbaut und Und riesige Kampagnen drumherum fährt, riesige Messaging-Sachen aufsetzt, sich selber irgendwie im Internet präsentiert, ganz groß und darüber sein Following baut. Das habe ich bei Saiger nicht gemacht, habe ich da auch nicht geschafft. Das würde ich jetzt auch nicht versuchen in der nächsten Firma. Andere Seiten auf der operativen Geschichte mit dem Management von den Investoren, auch so ein bisschen Planung going forward, die nächsten Finanzierungsrunden rein. Da sind sicher Fehler drin, aber ich glaube, das sind Fehler, die macht man nur einmal, da lernt man viel draus.

[13:57] Man sagt immer so blöd, ja, wenigstens hast du was gelernt. Ich wünsche mir natürlich, die Firma hätte einfach geklappt und ich hätte nichts gelernt. Jetzt hat die Firma nicht geklappt und ich habe viel gelernt. Das ist ein ordentlicher Trostpreis. Als du, ich meine klar, du hast gerade gesagt, okay, vielleicht bin ich nicht der Typ, der B2C-Firmen skandiert, daraus ergibt sich das Learning, okay, die nächste Firma könnte B2B werden. Was hast du dir noch dann vorgenommen, als du das Geschäftsmodell bzw. Den Use Case, das Problem, was ihr lösen wollt, versucht hast zu identifizieren? Was waren die großen Punkte, wo du gesagt hast, okay, da kommt alles zusammen? Ja, nun ein paar Sachen. Also ich meine, ganz transparent, ich habe mir erstmal vorgenommen, ein halbes Jahr keine Entscheidung zu treffen, in Ruhe zu schauen, was will ich als nächstes machen? Ist das nochmal gründen? Ist das auch was ganz anderes machen? Ich komme aus der KI-Forschung, ich habe dann auch mit den großen KI-Labs gesprochen, hatte auch mal mit ein paar von den Open-AI-Gründern gesprochen, dann aber relativ bald für mich erkannt, ich will nicht zurück in die reine Forschung. Was mir so viel Spaß macht am Gründen, und das ist schwierig, das woanders zu finden als Job, ist einfach diese breite Verantwortung, die breiten Themen, die man da bearbeiten kann. Und als mir dann eigentlich wieder klar wurde, das wird wieder auf eine Firma hinauslaufen, da war auch relativ klar dieses Thema Mental Media Labor automatisieren. Das war immer so ein bisschen mein Thema. Da komme ich auch nicht mehr weg von. Für mich, das ist immer das große Versprechen von KI. Wie können wir KI nutzen.

[15:10] Um erstmal die Sachen im Leben zu automatisieren, die Sachen loszuwerden, die sozusagen zwischen uns und dem Glück stehen. Und das ist in der Regel ja nicht die ganze Arbeit, sondern es ist der Teil sozusagen Vorarbeit, die ich leiste, um dann den Teil zu machen, der mich eigentlich interessiert. Sei das die großen strategischen Entscheidungen zu treffen, sei das irgendwelche Sachen ganz detailliert durchzuspielen, taktisch zu überlegen oder sei das auch nur vielleicht Verkaufsgespräche zu führen. Vielleicht ist das mein Ding. Dann brauche ich aber trotzdem nicht der Typ sein, der die ganzen Slides davor malt und die Briefings unterschreibt mit, was ist das jetzt für ein Kunde, mit dem ich rede. So, ich glaube, das war relativ gesetzt dann als Thema. Die B2B-Sache war auch gesetzt. Ein bisschen zum einen Saiger geschuldet, der Erfahrung dort und zum anderen auch so ein bisschen aus der Perspektive heraus. Es ist leichter, eine Firma zu gründen, wo du an das Produkt einen sehr starken RRI koppeln kannst. Bei diesem Assistenten fürs Privatleben, die meisten Menschen haben da keinen RRI für. Ich berechne jetzt nicht irgendwie meine Stunde am Samstag ist mir 50 Euro wert und die Stunde am Freitagabend sogar 75 Euro. Und darum macht das Sinn, wenn ich hier Geld für so ein Ding ausgebe. In einem B2B-Kontext und da, wo wir jetzt gelandet sind mit Reliant und Pharma, da ist das natürlich viel einfacher, wenn ich sage...

[16:21] Hier ist eine Analyse, die können wir für euch automatisieren. Da geht das jetzt zum Beispiel um so eine klinische Landschaftsanalyse. Was gibt es gerade für Medikamente? Was passiert in der Forschung um eine bestimmte Krankheit herum, um eine bestimmte Form von Krebs herum? Dann kann ich ja ganz genau berechnen, was kostet mich das gerade intern, das zu machen? Was kostet mich das, wenn ich da mit einer externen Firma zusammenarbeite? Und auch im zweiten Schritt so ein bisschen, was kostet mich das eigentlich, wenn wir da einen Fehler machen?

[16:45] Was verliere ich hier an Geld, wenn mich das sieben Wochen Zeit kostet und nicht nur vier Tage, bis ich diese Analyse habe? Aber das ist ein einfacheres Produkt zu verkaufen. Ich glaube, das ist eine Sache hinter Reliant, die uns sehr wichtig war. Von Anfang an da ein Must-Have und nicht ein Nice-to-have zu bauen. Ich würde gerne, also ich meine, du hast gesagt, du kommst aus, du hast bei DeepMind auch jahrelang Research-Teams gesehen. Du warst in der Forschung. Du weißt, wie, sagen wir erstmal, so eine Research-Organisation funktioniert. Du weißt, wie man eine Firma baut. Und ein Theme, was ich gerne über diese Folge ein bisschen drüberstülpen würde, ist der Unterschied zwischen einer KI-Firma und einer KI-Firma, also einem KI-Startup und einem KI-Startup, weil.

[17:26] So wie ich das wahrnehme als jemand, der keine Ahnung hat, wenn ich heute losrennen würde und ich würde mir irgendwen suchen, der jetzt aus der Uni kommt und sage, ich baue mit dem irgendwie eine KI-Firma, dann würden wir vielleicht losrennen und würden sagen, was ist gerade das beste Modell und vielleicht das noch so programmieren, dass man die Modelle tauschen kann, falls ein anderes besser wird und so dieses Plug-in-Hybrid mäßig zu bauen und überlegen uns, okay, wofür bauen wir eine Lösung? Und ich würde Ich würde gerne verstehen, wenn du selber gerade darüber nachdenkst, das Fundament für Reliant zu bauen, worauf achtet ihr? Anhand dessen, dass ihr einfach jahrelang schon da tiefer drin seid, was ist euch wichtig? Das heißt, die erste Frage, worauf hast du bei, am Ende baut ein sehr technisches Produkt logischerweise, worauf hast du beim Zusammenstellen erst mal des Gründerteams geachtet? Also ihr seid drei Co-Founder, wenn ich es richtig weiß. Ein weiterer technischer und ein Commercial Co-Founder zusätzlich zu dir. dementsprechend, Und warum, wieso, warum genau diese Zusammensetzung?

[18:23] Ja, du super gerne. Also ich glaube, wie gesagt, wir sind drei Mitgründer. Ich habe mich zusammen mit Marc Belmar hingesetzt, schon ein gutes halbes Jahr, bevor wir angefangen haben. Das ist ein alter Kollege von DeepMind. Der ist länger in der reinen Forschung geblieben als ich. Wir sind etwa zeitgleich von DeepMind weg. Er ist dann nach Montreal, hat da bei Google Brain das Reinforcement Learning Team geleitet. Ich glaube, die eine Sache, die uns zusammengebracht hat, war so ein bisschen diese Tiefüberzeugung, dass Forschung am besten funktioniert, wenn sie an echte Probleme gekoppelt ist. Für mich, ich komme aus der Sprachforschung, da war das immer klar. Bei Sprachforschung, das Schöne ist, die Themen, die du hast, sind relativ konkret. Da geht es um Machine Translation, wie kriege ich Text von einer Sprache in die andere übersetzt. Oder viel von meiner Arbeit war über Question-Answering-Themen, also wie kriege ich einen Computer dazu, Fragen zu beantworten. Also viel von dem, was jetzt in diesen großen Large-Language-Modus drin steht, sind die Themen, an denen ich auch gearbeitet habe. Bei Mark, der kommt aus dem Reinforcement Learning. Reinforcement Learning, das ist eine andere Form von KI. Da geht das darum, Systeme zu trainieren, indem du die erstmal losschickst, wild Sachen machen lässt und ihnen dann Feedback gibst.

[19:24] Das war gut, das war gut, das war schlecht, das war richtig schlecht. Jetzt probier es nochmal. Das Problem mit RL ist, das ist super ineffizient in der Regel. Das heißt, du brauchst da viele zehntausende, hunderttausende Versuche, bis so ein System anfängt zu verstehen, okay, so muss ich hier interagieren in dieser Welt, in dieser Simulation. Und weil das so ineffizient ist, wurde das lange Zeit sehr viel über Spiele gemacht. Also, was du vielleicht kennst, bei DeepMind, so das erste große Projekt war ja, Modelle zu entwickeln, die Atari gespielt haben. Das war tatsächlich Marks Doktorarbeit, über die er dann zu DeepMind geholt wurde und das Ding wurde dann aufgeblasen intern. Und die Atari-Spiele sind wunderbar, weil die kannst du hunderttausendmal parallel laufen lassen, da brauchst du keine Interaktion, da brauchst du keinen Menschen, der da irgendwie zwischensteckt. Das war genau das Gleiche später mit dieser Go-Geschichte. Wir können Go komplett durchsimulieren. Das Regelwerk ist sehr einfach. Am Ende hat einer gewonnen, der andere nicht. Das heißt, so ein Reward-Model kann da sehr gut trainiert werden. Wenn du jetzt diese Sachen anguckst.

[20:20] Das kann man im Abstrakten machen und wenn du dann anfängst, das in die echte Welt zu übertragen, dann kommt nochmal eine ganz andere Schärfe, eine ganz andere Tiefe an Problematik hinzu. Beim Reinforcement Learning zum Beispiel, was Marc gemacht hatte nach Diebmann war bei Google X, hat der RL für Project Loon geleitet. Project Loon, das war sein Projekt, da haben sie Heliumballons in die Stratosphäre geschickt, um über Afrika besser Internetabdeckung zu ermöglichen. Da wird das dann schwieriger, weil wenn du das simulieren musst, dann hast du natürlich ein Szenario, das du jetzt nicht mehr komplett im Computer abgedeckt bekommst. Dadurch aber, wenn es dann funktioniert, am Ende deutlich robustere Algorithmen. Und insofern, ich glaube, was uns beiden immer wichtig war, ist, wenn wir das auf der Forschungsseite vorantreiben wollen, brauchen wir echte Probleme. Und dafür war uns auch immer klar bei Reliant, wir wollen ein echtes Problem haben. Wir wollen jetzt nicht eine KI-Plattform-Firma sein, die sagt, guck mal, hier ist noch ein Twist, eine andere Variante von einem Large-Language-Model, hallo, spielt jemand da mit, das ist ganz cool und die echten Probleme soll dann jemand anderes lösen. Darum war es uns auch wichtig, von Anfang an eine Domain auszusuchen, ein Thema und dann Expertise in dem Bereich. Darum haben wir dann auch Richard von Anfang an mit ans Boot geholt als dritten Gründer, der aus der Pharma-Branche kommt, der mit KI jetzt erstmal relativ wenig am Hut hatte, aber der diese Branche wirklich gut verstand, der uns genau erklären konnte, was sind die Probleme da drin, wie löse ich die und dann auch die entscheidende Frage, wie gut muss die Lösung sein, damit sie eine Lösung ist.

[21:43] Weil ich meine, ich kann dir ein KI-Modell geben und sagen, das ist 85 Prozent akkurat. Und das ist erstmal keine Aussage für die echte Welt. Es gibt Situationen, da ist 85 Prozent richtig geil. Es gibt andere Situationen, da ist 85 Prozent eine Katastrophe.

[21:55] Wenn ich mit 85 Prozent Sicherheit auf Pferde wetten kann, werde ich reich. Wenn ich ein Modell habe, das mit 85 Prozent Sicherheit ein Atomkraftwerk kühlen soll, dann ist das richtig schlecht. Und ich glaube, das ist insgesamt einfach wichtig, sozusagen das zu verstehen. Das heißt, das Erste, was wir bei Reliant auch gemacht haben, noch bevor wir den ersten Engineer eingestellt haben, bevor wir das erste Produkt gebaut haben, war, wir haben intern Benchmarks gebaut. Wir haben für die ersten Benchmarks. Themen, die wir uns ausgesucht hatten in Pharma, haben wir uns hingesetzt, haben Experten reingeholt, haben Benchmarks gebaut, um ein Gefühl dafür zu entwickeln, wie gut funktioniert das mit der Technik heute.

[22:31] Also wenn ich jetzt ein GPT-4 draufschmeiße, damals ein GPT-3,5 und wie gut muss das sein, damit da wirklich ein Mehrwert drin ist. So, genau, das ist so ein bisschen die Grundidee dahinter und sowohl dem, wieso wir bei Pharma als auch bei dem Team dann gelandet sind. Wie weit waren die Benchmarks und die Technologie zu dem Zeitpunkt mit einem GPT 3,5 zu dem, wo ihr sagt, hey, da muss man eigentlich hinkommen, um es wirklich akkurat zu machen und wirklich Mehrwert zu stiften? Wie weit lag das auseinander? Es hängt immer vom Thema ab. Also bei uns jetzt als ein Beispiel, wir haben ein Benchmark gebaut, da ging das darum, Biomarker aus klinischer Literatur rauszuziehen. Da haben wir mit GPT 3,5 47% Accuracy bekommen, mit GPT 4 52% Accuracy. Damit das wirklich hilft, musst du da in den hohen 90ern sein. Also da ist dann ein großer, großer Lift, den es noch braucht. Es gibt andere Sachen, da funktioniert das schon sehr gut. Wenn das darum geht, Sachen aus speziell formatierten klinischen Studien rauszuziehen, Fragen zu beantworten zu ein bisschen abstrakteren Geschichten.

[23:35] Aber es hängt ganz stark vom Thema ab. Ich glaube, das Entscheidende für uns war, einfach für die Use Cases, die wir lösen wollen, reicht das noch nicht. Und das Gap ist auch so groß, dass wir jetzt nicht sehen, wie das mit der nächsten Generation von allgemeinen Modellen gelöst wird, sondern es ist ja klar, da brauchst du mehr Arbeit reinstecken, also mehr KI auch entwickeln, mehr Modelle miteinander kombinieren, um da wirklich was zu erreichen. Das heißt, ihr habt euch angeguckt, sagen wir mal, es gibt 50 Use Cases, das ist einfach nur meine Prothese, und ihr habt euch angeguckt, okay, also die aktuellen Modelle funktionieren für jeden dieser 50 Use Cases x gut und x gut kann von, sagen wir mal, wahrscheinlich 25% bis irgendwie 75% reichen oder best case natürlich bis 100% und habt dann gesagt, okay, das sind die, wo zum Beispiel in der GPT-4 schon am besten funktioniert.

[24:20] Habt ihr dann gesagt, okay, da sind wir bei 57% und es ist leichter, 57% mit der Addition anderer Modelle, also zum Beispiel einem Club oder einem, ja, es gibt ja einige, wir müssen jetzt nicht alle davon durchsprechen, aber, oder Lama oder andere. Dann irgendwie zu sagen, okay, 57% auf 80% zu bekommen, ist einfacher als 40% auf 80% zu bekommen und habt das dann genutzt, um zu priorisieren, welche Cases ihr als erstes bespielt? Das hätten wir vielleicht machen sollen, das klingt sehr schlau. Ich weiß nicht, ob das schlau ist. Kann ja sein, dass man sagt, es ist gar nicht so schlau, weil am Ende muss ich es mit anderen Modellen trainieren, das ist gleich kompliziert. Nee, also in der Praxis, wir haben uns auf Use Cases konzentriert, die für uns gewisse Kriterien erfüllen. Das kommt erstmal ganz stark über die Marktseite, also Sachen, wo es genug Demand gibt, bei denen wir sehen, wie wir das plausibel verkauft bekommen, plausibel auch in den Punkt bekommen, wo das nützlich wird, wo das genutzt werden kann und.

[25:08] Dann haben wir eine spezielle Kategorie von Themen, auf die wir jetzt unsere Modelle, unsere Algorithmen anwenden. Da geht es speziell um die Situation, wo du mit vielen Daten arbeiten musst, die teils unstrukturiert sind, dafür sind LLMs gut, die teils auch Struktur haben, dafür sind LLMs weniger gut. Da gibt es dann mehr klassische Methoden aus der Datenanalyse. Und wir entwickeln Modelle, die so ein bisschen diese Brücke schlagen zwischen einem unstructured Gen-AI-Ansatz und diesem viel strukturierteren Ansatz. Was für uns entscheidend ist auf der technischen Seite ist, dass wir mit unseren Modellen dann Garantien über Recall abgeben können. Sprich, ich kann dir nicht garantieren, dass alles 100% richtig ist. Aber ich kann dir garantieren, wenn es hier 100 Antworten gibt, dann findest du auch die 100 Antworten und vielleicht noch 20 extra, die du dann raussortieren musst. Aber das macht natürlich einen Riesenunterschied. Wenn es wichtig ist, dass ich alle Sachen sehe, aus 120 Sachen die 20 falschen rausfischen, das kostet mich ein bisschen Zeit. Aus 100.000 Sachen, die 100 richtigen rausziehen, kostet mich deutlich mehr Zeit. Und wenn ich jetzt ein Modell habe, das vielleicht nur richtige Sachen rauszieht, aber von denen nur 80%, dann muss ich, um diese 24% zu finden, dann doch wieder durch das Originalmaterial durch. Das ist so ein bisschen die Hauptkomponente von unserem Modellansatz.

[26:18] Dass wir Sachen entwickeln, die da Garantien abgeben können. Da schränkt diese Probleme die Themen bei uns ein bisschen ein. Das andere, was bei uns wichtig war, war dann mehr von der Marktseite, von der Implementierungsseite Sachen zu finden, die oft genug gemacht werden, dass wir die auch testen können, dass wir die auch in der Breite relativ schnell testen können und gleichzeitig Sachen, bei denen das Change-Management überschaubar ist. Also als allererstes Single-Player-Use-Cases. Es gibt zig Sachen, da könnte man auch ein bisschen Lift reinholen, wo dann aber fünf Menschen plötzlich ihre Arbeit anpassen müssen. Das ist natürlich super schwierig einzubauen. Dann gibt es diese ganzen Themen so ein bisschen mehr in dieser Robotic-Process-Automation-Ecke. Da gibt es dann immer auch noch einen Lift drin, aber wenn das Thema groß genug ist, dann war da vor 15 Jahren Accenture, hat versucht, das irgendwie durchzuorganisieren, hat da rausgeholt, was rauszuholen war.

[27:08] Dann war da vor acht Jahren UiPath, hat da nochmal irgendwie alles weiter runtergedrückt. Und dann ist am Ende nicht mehr so viel übrig, was man da noch machen könnte. Da gab es spannendere Modelle für uns. Das heißt, ihr habt den Sale im Vertrieb gleich mitgedacht und gesagt, okay, warte mal, wenn wir das Problem lösen würden, dann wäre das aber echt komplex. Weil selbst wenn das einen extremen Mehrwert haben kann für die Organisation, müssten zu viele Leute ihre Arbeit anpassen. Dementsprechend brauchen wir viel mehr Stakeholder im Vertriebsprozess und sagen dann, ja, wahrscheinlich gibt es andere Cases, die wir priorisieren sollten, weil wir weniger komplexe Entscheidungsprozesse im Verkauf haben. Ja, genau. Also weniger Change Management, einfache Prozesse und auch, und ich glaube, das ist wichtig, eine.

[27:50] Eine interessantere RRI-Bewertung, Berechnung. Ich meine, ich habe all diese Sachen, ich sage, hier ist ein ganz effizienter Prozess, ich kann jetzt noch voll automatisieren. Dann ist das am Ende eine Kosteneinsparungsgeschichte. Ich kann gucken, mache ich jetzt dieses Team nochmal 20% effizienter oder vielleicht auch 100% effizienter. Wo wir uns darauf konzentrieren, sind eigentlich Cases, wo du klar so ein Effizient hast. Also am Anfang, wenn wir das 25% schneller machen, das ist schön, dann ist das günstiger für euch. Aber entscheidender, wenn das wirklich gut wird, Wenn wir irgendwann von diesem 20-25%-Ding auf ein 20x-Ding kommen, dass du dann auch eine positive Value Proposition dahinter hast. Weil es sagen können, guck mal, hiermit könnt ihr plötzlich besser M&A machen. Und dann gibt es hier Beispiele für die drei Biotechs, die ihr hättet kaufen sollen, die ihr kaufen wolltet, aber als ihr mit der Analyse fertig wart, waren die schon verkauft.

[28:37] Oder hier ist ein Ding, das hilft euch besser, Trial Sites auszusuchen für klinische Studien. Damit bekommt ihr die Verzögerung in euren klinischen Studien runter. Da müsst ihr weniger nachrekrutieren, weil wir eben Sites aussuchen, die dann auch genug Patienten mit der entsprechenden Krankheit haben. Was sind Sites? Bei klinischen Studien, also den späterphasigen Studien, wo dann wirklich an Menschen getestet wird, da musst duseits Krankenhäuser oder Ärzte aussuchen, bei denen du die Studien durchführst und das klingt so trivial, aber ist eigentlich eine hohe Kunst. Wenn das jetzt nicht um sozusagen Standardkrankheiten geht, die du überall findest, musst du einfach gucken, wo finde ich jetzt Krankenhäuser, die dann auch Patienten in der ausreichenden Anzahl haben, dass ich hier eine Studie durchführen kann und dass die Zahlen dann auch irgendwie deutbar und belegbar sind. Und das ist einfach ein super wichtiges Thema, weil.

[29:30] Ein Großteil von Studien scheitern nicht unbedingt daran, dass das Medikament nicht funktioniert. Die scheitern daran, dass man das nicht beweisen konnte, weil du nicht genug Patienten gefunden hast, die du durchschieben kannst durch die Studie. Ja, okay, fair. Und jetzt natürlich einfach zu der Fragestellung, ich formuliere sie so platt, wie ich sie vorhin einmal ausgedrückt habe, aber was ist der Unterschied zwischen einer KI-Firma und einer KI-Firma? Also du sprichst ja mit vielen, du hast einiges gesehen über die letzten Jahre, du bist in dieser Welt bestens vernetzt und dementsprechend kommen bestimmt auch Gründer verschiedenster Arten zu dir. Was würdest du sagen, ist der größte Unterschied zwischen KI-Firma und KI-Firma? Ja, ich glaube so ein bisschen, was ich vorhin gesagt hatte. Eine KI-Firma, die wirklich KI entwickelt, ist eine, die anfängt mit den Benchmarks, die anfängt mit internen Metriken und die dann schaut, wie kriege ich ein System entwickelt, das dieses Problem löst, das da die Zahlen erreicht, die wir brauchen. Und das ist dann nicht ein, wir benutzen ein GPT-4 und machen da Prompt Engineering drauf.

[30:27] Das ist ein guter Start, das reicht für manche Themen und das ist dann eine wunderbare Firma. Aber in vielen Situationen ist das eben nur der Anfang und dann merkst du, okay, jetzt brauche ich hier noch andere Systeme. Bei uns zum Beispiel das LLM ist eines von acht größeren KI-Modellen, die wir am Start haben. Da passiert ganz viel sozusagen bevor Sachen überhaupt zu dem LLM geschickt werden. Da passiert danach ganz viel im Post-Processing, wo nochmal geschaut wird, ist das eigentlich plausibel basierend auf den Daten, die wir da reingespielt haben? Können wir da den Link herstellen zwischen dem Output von dem LLM und der Datenbasis darunter? Und da kann ich mit einem anderen Modell nochmal eine Sicherheit berechnen. Also kann ich berechnen, wie überzeugt sind wir eigentlich davon, dass die Antwort richtig ist? Und kann ich das dann nutzen, um sozusagen das dem Endnutzer anders zu präsentieren, damit das für den leichter ist zu überprüfen, was da rausgekommen ist? So, insofern, ich glaube, du hast also die Art von Firma, die wir bauen. Das eine, wo du mit der Technologie, die du jetzt auf der Shelf bekommst, noch nicht ankommst, wo du selber Sachen entwickeln musst und wo dann auch grundsätzlich erstmal, Erstmal, wir bauen natürlich an einem Produkt für Pharma gerade. Die Technologie, die wir bauen, funktioniert unabhängig davon.

[31:33] Das heißt, was wir da entwickeln, diese Brücke schlagen zwischen unstrukturierten und strukturierten Daten. Ein großes Investment, das wir bei uns ins Reinforcement Learning machen, um diese Verifier-Modelle zu bauen, die überprüfen, wie gut Antworten sind, die dann helfen, da auch nochmal Rücksprache mit anderen Modellen zu haben. Das ist ein Forschungsthema. Dafür brauchst du Menschen, die auch aus der Forschung kommen, die sowas entwickeln können, die solche Sachen berechnen können. Das ist die Art von KI-Firma. Ich glaube, dann die zweite Art von KI-Firma, die du hast, das sind die, platt gesagt, so ein bisschen die Jasper-AIs dieser Welt, die ein Produkt bauen, bei dem die Präzision oder die Genauigkeit, die du aus einem GPT bekommst, ausreichend ist. Das ist dann da eine Kombination aus Prompt Engineering auf der einen Seite, das ist wichtig, UX auf der anderen Seite, das ist extrem wichtig natürlich für uns alle, aber da dann besonders. Und dann ist das mehr eine Firma, die die KI benutzt, aber eigentlich eine Produktfirma ist.

[32:23] Ist auch völlig in Ordnung, aber ist halt eine andere Art von KI-Firma. Und dann die dritte Art von KI-Firma, die du hast, das sind dann vielleicht eher die Mistralz und Coherence dieser Welt. Das sind Firmen, die vielleicht wie wir auch Technologie entwickeln erstmal, aber die Technologie nicht unbedingt an konkreten Use-Case koppeln, sondern eher sagen, wir bauen Large-Language-Models, wir bauen eine andere Art von Constitutional Models, wie auch immer du das dann nennen willst und versuchen da sozusagen allgemein die Technologie voranzutreiben, sodass dann die Jasper-AIs dieser Welt da einen höheren Absprung kriegen. Ort haben. Was würdest du sagen, ich bin mir relativ sicher und das ist ja auch nicht wertend, sondern dass hier einige zuhören, die sagen, hey, ich kategorisiere mich eher in, wir nutzen bestehende Modelle und gucken dann, dass wir darauf eine Produktfirma bauen. Was würdest du sagen, sind so die größten Wege, wie ich dann so diese vielgesagte Defensibility bauen kann? Also dafür zu sorgen, dass nicht das morgen einfach kopiert wird. Was sind, wenn die Technologie mich erstmal nicht unterscheidet? Also ich sagen kann, jeder kann morgen GPT nutzen, egal welche Form und Farbe das jetzt gerade gibt und wann dann das neueste Modell kommt. Aber wie, würdest du sagen, bauen diese Firmen wirklich Defensibility? Wenn die Technologie sich gar nicht unterscheidet, ist es natürlich schwierig. Also das ist ja so ein bisschen, da haben wir Jasper als Beispiel.

[33:36] Die haben ja am Anfang wirklich das erste große, erfolgreiche KI-basierte Startup gebaut, wenn du so willst. Also ein relativ dünner Layer oben auf ChatGP drauf. Für alle, die es nicht mehr wissen, Jasper war einfach was, wo du dich anmelden konntest. Dann konntest du alle möglichen Formen von, Du kannst einen LinkedIn-Post, einen Facebook-Post oder was auch immer einfach Texte generieren lassen, kann auch eine E-Mail sein. Du hast dann quasi einfach nur einen Button geklickt und kurz so zwei, drei Nuancen reingeschrieben und das hat dann eigentlich das, was du heute vielleicht einfacher machen kannst, aber damals gab es das zwar noch bevor dieser große Chat-GPT-Hype kam, also vor dem Chat-GPT-Moment und da haben die das schon als Interface verfügbar gemacht.

[34:18] Ja, genau. Und ich glaube, das ist ja so ein bisschen das Beispiel für eine Firma, die dann am Ende keine Defensibility hatte. Aber das war relativ schnell klar. Okay, das habe ich bisher hier gemacht. Das kann ich jetzt auch einfach in ChatGPT machen. ChatGPT kam später raus. Die haben das auf GPT-3 gebaut ursprünglich. Und denen ist dann auch entsprechend der Umsatz weggekracht. Und in ihrem ersten Jahr hatten die mehr Umsatz als OpenAI. Das muss man sich mal vorstellen.

[34:41] Jetzt hat OpenAI dann ein paar Größenordnungen mehr. So, wenn du jetzt aber einen Schritt weiter gehst und noch bevor du die KI anfasst und ernsthafte Probleme löst, die relativ tief drinnen stecken in der Industrie, dann kommen ja andere Sachen, die du machen musst. Da musst du anfangen, dich mit den Datensätzen auseinanderzusetzen, die du in dem Bereich hast, in der Industrie hast. Da musst du dich damit auseinandersetzen, wie passe ich da jetzt überhaupt rein. Nein, also habe ich hier ein System, das braucht eine Sharepoint-Integration oder muss ich hier irgendwelche SAP S2-HANA, S4-HANA, ich bringe das mal durcheinander, Integration bauen, dass ich da die Daten rausgezogen bekomme. Aber damit kannst du natürlich eine sehr wertvolle Firma aufbauen und hast dann die Sensibility so ein bisschen über diese Tiefintegration in der Industrie rein. Also ich glaube, da kann man sehr sinnvolle Firmen bauen. Das wäre jetzt auch albern zu sagen, jeder muss jetzt KI-Modelle entwickeln, weil das irgendwie sexier klingt. Wenn du das auf der Shelf nutzen kannst, ist doch mega, dann mach das doch einfach. Was wir gemacht haben und ich glaube, das ist auch einfach dem Background geschuldet, wir haben uns Themen ausgesucht, bei denen diese KI-Modelle halt nicht ausreichen, wo dann die Defensibility eben auch über den nächsten Schritt kommt, dass wir sagen, wir bauen selber Modelle, die kann erstmal keiner kopieren und bauen gleichzeitig aber dieses tiefe Verständnis für eine Industrie auf und gucken da auch, wie kriegen wir jetzt nicht nur den Head gelöst, sondern auch so ein bisschen die Long Tail an Problemen, an Thematiken da drin gelöst, dass wir was bauen, was dann wirklich funktioniert.

[35:58] Eine Fragestellung, die mich betrifft, die aber auch jede Product Company basierend auf den aktuellen LLMs ist, ist, OpenAI sagt, wir bringen ein neues GPT raus, eine neue Version. Dann kann ich ja nicht einfach sagen, ach ja, ich switch jetzt einfach irgendwo im Background GPT-4 durch GPT-4.5, sagen wir jetzt einfach mal. Und weil ich am Ende ja nicht weiß, wie verhält sich das mit dem, was ich ihm an Rahmenbedingungen gegeben habe, an. anderen. Jetzt gibt es aber trotzdem Firmen, die das relativ zügig natürlich integrieren. Wie ist der Prozess von, hey, ich nutze jetzt die aktuelle Version, aber morgen kommt eine neue raus. Wie bereite ich das vor, dass ich dann auch wirklich sicherstellen kann, dass mein Kunde mindestens das Gleiche, wenn nicht ein besseres Ergebnis hat. Weil die Fragestellung habt ihr, egal ob ihr 1 oder 8 LLMs kombiniert. Du, absolut. Ich glaube, die Frage hängt dann ganz stark von dem Produkt ab. Wenn mein Produkt ein Interface ist, bei dem der Kunde der Prompt-Engineer ist, dann kann ich das einfach austauschen. Also wenn wir jetzt geschaut haben mit den nächsten GPT-Modellen, die da raus kamen, eine Firma wie u.com, die haben da irgendwie sechs, sieben Stunden später... Vielen Dank nochmal.

[37:07] Die schaffen das in sechs, sieben Stunden, weil natürlich da der Großteil von Prompt-Engineering erstmal kundenseitig passiert. Und dann gebe ich das Experimentieren an den Kunden weiter, das ist natürlich mega. Wenn ich eine Firma habe, bei denen ich entweder selber sehr viel in Prompts investiert habe und andere Sachen oder bei denen ich ein GPT-Modell genutzt habe, um mir einen Agenten zu bauen, der dann auch intern Sachen ausführen soll, da muss ich natürlich sicherstellen, dass dann die Agenten, da die Syntax erhalten bleibt. Ich glaube, am Ende jede Firma, die sich da einigermaßen darauf vorbereitet, sollte intern genug Daten haben, genug Unit-Tests haben, dass man das einfach durchlaufen lassen kann. Und dass ich dann weiß, okay, hier sind irgendwie meine 500 Test-Cases und wenn ich da jetzt ein anderes Modell ankoppe, sei das von GPT-4 auf GPT-4.0 oder sei das von, GPT auf ein LAMA, auf ein Cloud, auf ein Command-R-Modell, dass ich einfach diese Tests durchlaufen lassen kann und dann sehe, okay, hier, die 450 Sachen funktionieren noch, die 50 nicht, dann muss ich da jetzt halt dran rumfallen, sei das über Prompts, sei das über irgendwelche anderen Änderungen im Code. Das geht relativ gut, meine ich. Das heißt, am Ende brauche ich trotzdem erstmal das gewisse Benchmarking, was du anfangs besprochen hast und dann auf mein Modell, egal was für eine Art von Company ich quasi gerade baue, angepasst, um zu sagen, hey, das sind die wichtigsten Cases, die funktionieren müssen.

[38:19] Außer ich bin ein new.com-Fahrer, die es nicht wissen, dass am Ende kannst du da auswählen, ob du jetzt mit GPT, Cloud, Lama oder wem auch immer quasi chatten möchtest, da mit deinen Agents und so bauen. Und auch da muss ich mir dann natürlich angucken, wenn mein Agent bisher auf der letzten Version GPT läuft, ob der mit der neuen Version besser läuft oder nicht. Das kommt natürlich darauf an, was ich dem alles gesagt habe. Ich würde sagen, in meinem Fall, der irgendwie generische Agents vielleicht baut, ist das wahrscheinlich leichter, das einfach zu switchen versus da, die man sich wirklich, wirklich, wirklich tief mit beschäftigt und sehr komplexe Sachen drauf gebaut, muss man dann vielleicht nochmal gegentesten.

[38:54] Ja, aber ich glaube, so ein bisschen zusammenfassend auch. Also ob KI-Firma, KI-Firma oder KI-Firma, Modelle bauen, das ist nicht unbedingt notwendig. Benchmarks bauen muss sein. Da hat auch die, ich habe ein UI on top of Cloud gebaut Firma, kein Recht zu sagen, wir machen keine Benchmarks. Also ich glaube, das muss einfach da sein als Firma, damit man intern gucken kann, wo geht das hin? Verändert sich da irgendwas in meinem Modell? Funktionieren die ganzen Sachen noch oder nicht? Das ist jetzt auch kein Hexenwerk. Da gibt es ja auch mehr und mehr Startups dann wieder, die dafür für Tooling bauen, die das leichter machen. Ich glaube, das... Das muss eigentlich jede KI-Firma, egal welcher Fasson, in ihrem Stack haben. Jetzt wird es interessant, weil ich bin ja ein absoluter Noob, was das Thema betrifft. Was macht gute Benchmarks aus? Also dass du sagst, okay, die sind auch wirklich battle-tested und das macht auch wirklich Sinn, diese Benchmarks zu wählen.

[39:46] Es gibt ja zwei Arten von Benchmarks. Wir haben ja viel gesehen, so externe Benchmarks. Ganz ehrlich, ich glaube, bei den externen Benchmarks einmal, wenn du Zugriff auf die Testdaten hast, dann kannst du dein Modell so hinbiegen, dass es das beste Modell überhaupt ist. Und das haben wir auch gesehen. Ich glaube, jede Large-Language-Model-Firma war die beste Large-Language-Model-Firma der Welt auf einem eigenen Benchmark. Und ob das jetzt Aleph Alpha in Heidelberg war oder Cohere in Toronto oder die Leute von Mistral, ist ja unwahrscheinlich, dass alle Firmen gleichzeitig die beste Firma der Welt sind. Dann darf man mal weggehen und zu Application Layer Firmen gehen. Gute Benchmarks sind interne Benchmarks, die das messen, was auch deine Kunden dann machen. Bei denen sowohl auf die Edge Cases geschaut wird, als auch auf die zentralen Sachen und wo du ein klares Verständnis davon hast, nicht nur wie du das evaluierst, sondern auch wo der Cutoff ist. Ja, ab welchem Prozentsatz fängt das an zu funktionieren? Wie gut muss das sein, damit ich das nutzen kann? Das lernen wir auch alle zusammen gerade ein bisschen mehr. Also wir sehen, okay, für die Situation, da brauche ich was, das gut genug ist. Dann kann ich das komplett automatisieren. Und wenn es schief geht, dann weiß ich, bei wem ich mich entschuldigen muss. Aber der Trade-Off ist es wert. Bei der Situation...

[40:52] Da muss das 100% perfekt sein am Ende, aber das Thema ist groß genug, dass da eh ein Mensch dahinter hängt und solange ich das auf eine gewisse Art und Weise aufbereite, kann ich der Person immer noch sehr viel Zeit sparen. Und ich glaube, dass das wichtig ist, dieses Grundverständnis dafür zu haben, nicht nur was messe ich auch, sondern welche Zahl brauche ich da am Ende dahinter stehen haben. Ich kann mir vorstellen, dass viele sich das schönreden und sagen, also ja, ab dem Moment wäre es gut, aber kommt die 3% oder 4% Unterschied machen jetzt auch nicht mehr so viel aus. Wenn du sagst, man spricht ja gerne doch von MVP und man muss irgendwann mal rausgehen und Prototypen und testen. Wie genau habt ihr es bei euch genommen zwischen, okay, das sind die Benchmarks, da wollen wir hinkommen und wir sind aber auf dem guten Weg dahin und müssen aber einfach trotzdem auch mal Feedback sammeln.

[41:36] Weil, ich meine, du könntest natürlich noch länger im Forschungslabor bleiben und noch ein Jahr weiterentwickeln oder du sprichst mal mit jemandem und sagst, ist das generell schon mal irgendwie hilfreich?

[41:45] Ich glaube, das kannst du gar nicht von außen beurteilen. Also dieses Benchmark und wie gut muss das sein, das lernen wir von unseren Kunden. Also bei Reliant, wir hatten Pilotkunden, bevor wir Code geschrieben hatten, einfach um sicherzustellen, dass wir eben nicht im Labor bauen, dass wir gegen echte Probleme bauen und dann auch sozusagen dieses wirkliche Feedback bekommen. Und wir waren da am Anfang auch nicht bei den Werten, wo wir sein müssen. Ich glaube, Ich glaube, inzwischen haben wir ein relativ gutes Verständnis dafür, wie gut die Modelle sein müssen im Abstrakten, aber dann auch im Konkreten, an welchen Punkten darf es nicht scheitern, was muss perfekt sein und wo sind die Sachen, wo es okay ist, wenn das überprüft werden muss. Weil da sind ja immer mehrere Sachen drin. Das ist sozusagen die Modellqualität an sich. Dann ist da so ein bisschen die Frage nach dem Vertrauen, nach der Confidence, die die Kunden haben in das Produkt. Du kannst ja ein Modell haben, egal wie gut das ist, wenn die Leute der Sache nicht trauen und danach dann doch wieder auf irgendeine alte Datenbank zurückgreifen oder zwei Stunden die Arbeit nochmal selber machen, dann ist das ja hinfällig. Und das dritte ist dann so ein bisschen damit mit dem Vertrauen auch verlinkt, dann die Change-Management-Frage. Also wie schwierig ist der Sprung von dem aktuellen Prozess auf den neuen, den wir unterstützen können? Wie painful ist das alte Ding? Also das informiert ja dann auch so ein bisschen, wie gut muss die neue Lösung sein? Wenn ich was habe, das funktioniert eigentlich ganz gut, ich kann das ein bisschen besser machen, dann muss die schon richtig geil sein, die neue Lösung. Wenn ich was habe und das ist eine Mega-Pain und das sind vier Stunden am Tag super anstrengende Stunden.

[43:08] Langweilige Arbeit, dann habe ich hier eine andere Landungsfläche, eine größere Spanne an Modellen, an Systemen, die gut genug sind. Wie seid ihr mit Pilotkunden vorgegangen? Also ich meine, das eine ist irgendwie, also wie habt ihr überhaupt ausgewählt, wer ist der passende Pilotkunde? Ja, am Ende haben wir erstmal viele gefragt, ob sie wollen. Es gibt ein paar Sachen, die natürlich helfen beim Piloten. Es hilft, jemanden zu haben, der sich das Problem bewusst ist. Menschen, die im Idealfall auch schon mit anderen KU-Lösungen gespielt haben, schon ein Gefühl dafür haben, was geht da eigentlich, was geht da nicht, wo sind die Grenzen von den Sachen. Wenn ich jetzt versuche, unser Produkt an jemanden zu verkaufen, der ein riesiges Problem hat, aber noch nicht einmal versucht hat, mit ChatGPT oder Perplexity oder so jemanden zu spielen damit, ist das natürlich ein anderer Punkt, an dem ich den abholen muss, als eine andere Person, die das schon alles durchprobiert hat und die ganz genau weiß, oh, das ist eigentlich ganz cool, ich würde das super gerne mit ChatGPT machen. Hier sind die Knackpunkte, an denen das scheitert. Wenn ich dann sagen kann, ja, mega, Das sind genau die Punkte, an denen wir arbeiten. Das ist, wo unser System funktioniert, habe ich eine ganz andere Basis, auf der ich anfangen kann. Gleichzeitig bist du ja an einem Punkt, wo du eigentlich noch keine Basis hast, wo du sagst, das sind die Use Cases, die wir uns grob überlegen können im Pharma Ding. Das heißt, du bist ja irgendwo so, das ist die Basis, wo wir eigentlich hinkommen wollen. Das heißt, du musst ja in der Kommunikation, wie offen bist du, hey, wir laufen heute los und würden gerne mit euch da hinkommen, dass eben genau das, was euch bei ChatGPT gerade stört, euch nicht mehr stört mit unserem Modell.

[44:36] Du, sehr offen. Ich meine, das sind ja alles auch Pilotverträge am Anfang. Wenn ich denen jetzt Gott und die Welt verkaufe und dann am ersten Tag machen sie die App auf und sehen, das ist ja noch gar nichts, dann habe ich sozusagen ab Tag zwei keine Vertrauensbasis mehr. Also wir haben das schon sehr klar kommuniziert immer, das sind Piloten. Wir entwickeln da zusammen was. Hier sind die Sachen, die wir technisch schon können. Da hatten wir schon ein bisschen Vorsprung schon. Aber das ist ein Pilot, also wirklich eine Co-Development-Geschichte. Wir müssen das zusammen vorantreiben. An Tag 1 wird das noch keine Lösung sein für euch. Das Ziel ist, dass das ein paar Monate später an den Punkt dann gekommen ist. Ich glaube, das funktioniert auch sehr gut. Was dafür natürlich dann wichtig ist, ich brauche Kunden, bei denen das Problem groß genug ist und häufig genug vorkommt, dass sie dann in so einer Pilotphase auch mithelfen können. Wir hatten auch schon mal einen Piloten, die... Die hatten ein riesiges Problem und dachten, mega, dafür passt die Lösung. Wir haben dann mit den Piloten angefangen und dann kam raus, ja, das ist ein Thema, da sind wir jetzt gerade fertig mit, das kommt in sieben Monaten wieder.

[45:31] Und dann kannst du da erstmal relativ wenig machen. Dann haben wir den Piloten auch auf Eis gelegt, wir werden das jetzt wieder starten nächstes Jahr, wenn das bei denen wieder präsenter ist. Aber für so eine gemeinsame Entwicklung arbeiten wir dann lieber zusammen mit Firmen, die das Problem auch ein bisschen mehr regelmäßiger haben. Wie aktiv definiert ihr die Rolle des Pilotkunden? Also was sind, was das Commitment, was ich mitbringen muss, um bei euch Pilotkunde sein zu dürfen? Das machen wir inzwischen relativ, relativ konkret. Am Anfang haben wir das wahrscheinlich ein bisschen relaxter getan. Darum ist das dann auch teilweise, teilweise schief gegangen. Das ist sehr klar. Also bei den Piloten, da ist eine Erwartungshaltung dran mit, ihr nehmt ein großes Team drauf auf die Software. Das ist auch ein Invest bei euch während dieser ersten Pilotphase, weil es noch nicht funktionieren wird. Wir haben das Recht, mit allen Mitarbeitern zu sprechen, die das zu nutzen, auch sehr regelmäßig. Was ist für dich sehr regelmäßig? Mindestens einmal die Woche. Okay. Und großes Team sind, sind da schon fünf Leute oder sind das 50 Leute? Nein, 50 Leute nicht. Das ist so, man kann sagen, zwischen fünf und 15 Menschen. Das sind jetzt, wir arbeiten ja viel mit Business Development Teams, Early Commercial Pipeline Teams in Pharmafirmen, in Life Sciences Beratung. Das sind keine 50-Menschen-Teams jetzt für diese einzelnen Workflows. Aber nee, die Piloten sind relativ stark strukturiert auch, ein bisschen was die Zielsetzung angeht, was Meilensteine angeht, was dann auch Check-ins mit dem Bayer, mit dem Champion angeht. Ich glaube, da sind wir inzwischen in ein ganz gutes Setup gekommen.

[46:58] Und was sind Sachen, wo, also du hast gesagt, da gibt es eine, was nicht funktioniert beim Piloten, war irgendwie zu laissez-faire und nicht zu klar definieren, was das Commitment der anderen Seite ist. Was sind noch Sachen, wo du sagst, ey, die haben wir über die Zeit gelernt, da müssen wir bei Piloten echt ein bisschen mehr aufpassen, dass das auch wirklich funktioniert? Ich glaube, eine Sache ist einfach, wir müssen, es ist wichtig, am Anfang diese Zeit zu investieren, um ein Problem ganz klar zu umreißen und ganz sicherzustellen, dass jetzt, das ist ein Pilot, um ein Problem zu lösen und das ist nicht ein Pilot, weil die Firma meint, sie braucht jetzt was mit KI machen. Ich glaube, das passiert natürlich jetzt gerade auch viel. Jede Firma meint, sie muss was mit KI machen. Wenn du aber kein Business-Problem dahinter hast und dann auch keine Business-KPIs dahinter hast, dann ist das sehr schwierig für uns, eine Lösung zu bauen, bei der du dann auch den Bayern bekommst, bei der du dann auch die Nutzer bekommst. Insofern, wir achten da sehr stark drauf, inzwischen bei Pilotkunden nur mit Firmen zu arbeiten, die so ein Problem haben. Wo dann auch ganz klar ist, wenn wir das hier erreichen, dann habt ihr hier die Leute, die brauchen das ständig. Die brauchen das in der Vorhersehbahnfrequenz. Da können wir dann auch den ROI dahinter berechnen. Dadurch finden wir dann auch einen Preispunkt, der für beide Seiten akzeptabel ist. Ich glaube, da waren wir vielleicht, ganz am Anfang freust du dich ja über jeden Piloten. Da waren wir vielleicht ein bisschen zu entspannt, was das angeht. Und ja, machen das jetzt ordentlicher. Ja. Wann machst du aus einem Piloten einen.

[48:14] Kunden, also wann ist der Switch, dass du sagst, hey, jetzt sind wir weit genug, das wäre jetzt unser Approach-Produkt, wollt ihr ab morgen in Anführungszeichen Kunde sein? Im Idealfall ist es ein fließender Übergang. Also in der Pilotphase, da ist ja auch diese Co-Development-Geschichte, da ist die Erwartung, das funktioniert noch nicht, da investieren beide Zeit rein, dann wechselt das irgendwann rüber in eine Evaluierungsphase. Ehrlicherweise, wir machen genau das Gleiche, wir arbeiten sehr schnell dran, das Produkt besser zu machen für das, was die Kunden brauchen. Aber so ein bisschen die Anspruchshaltung auf Kundenseite ändert sich dann langsam aus. Ich helfe hier mit zu, ich gucke, ob das jetzt funktioniert. Und da findet man ja dann in der Regel einen natürlichen Absprungspunkt, wo man sagt, okay, jetzt haben wir das evaluiert, jetzt wissen wir, dass das funktioniert. Lass uns jetzt den nächsten Schritt machen und aus dem Pilotvertrag einen längerfristigen Mehrjahresvertrag zu machen. Wie seid ihr an Pricing rangegangen? Also wie habt ihr euch da dem, also wahrscheinlich experimentiert ihr da immer noch, würde ich jetzt mal auf was denken. Jetzt seid ihr ja noch nicht irgendwie seit fünf Jahren live und wisst ganz genau, was ihr da macht. Aber was sind so die ersten Gedanken gewesen zu Pricing? Wie seid ihr da reingestartet? Ja, das ist relativ experimentell. Ich habe da auch viel mit unseren Angel-Investoren am Anfang drüber gesprochen. Wir haben zum Beispiel von Datadog, Amit Agarwal, der Präsident ist ein Angel bei uns. Die haben ja ein super Pricing. Also ich glaube, das ist so ein bisschen ein Beispiel für Firmen, die Pricing einfach gut gelöst haben. Der hatte dann auch 20 Vorschläge, die alle sehr sinnvoll sind und als letzten Vorschlag meinte er, jetzt vergesst das alles wieder, guckt erstmal, dass ihr das Produkt an den Markt bekommt.

[49:43] Sobald wir hier was haben, was nach Product Market für da aussieht, dann können wir uns um so ein komplexeres Pricing kümmern. Insofern pricing bei uns das darauf optimiert. Da muss eine Marge drin sein. Wir müssen da sozusagen auf der Unit profitabel sein. Wir müssen eine Flexibilität drin haben im Pricing, dass wenn das Usage explodiert und dadurch hinten raus unsere GPU-Kosten explodieren, dass wir das auch anpassen können. Aber das sind alles Lagging Indicators. Im ersten Schritt geht es mir darum, das Produkt zur Marktreife zu bringen, das Produkt weiterzuentwickeln, mit Menschen, die das viel benutzen. Und wenn die das genug benutzen, dann können wir mittelfristig im Pricing schauen, und dass das auch da landet, wo wir hinwollen. Und wir müssen nochmal einen Tick zurück. Wir haben vorhin mal über das Gründerteam gesprochen. Die Frage ist natürlich dann, okay, wissend, dass man ein komplexes Produkt baut und dass man eine KI-Firma bauen möchte, die irgendwie bestehen kann, muss man sich natürlich Gedanken machen, wie kriegen wir es hin, dass es nicht nur von uns dreien abhängt als Mitgründern. Wer waren die ersten Highers?

[50:39] Genau. Wir versuchen, die Firma so klein wie möglich zu halten. Ich fand das ganz lustig, bis vor ein paar Jahren, alle Befreundinnen und VCs haben mir immer gesagt, du musst gucken, dass das Startup so klein wie möglich ist. Guck dir FTX an, die machen das richtig gut. Jetzt haben wir gelernt, vielleicht war es nicht so gut, dass die das so klein hatten, weil es gibt da Funktionen, die brauchst du in der Firma auch früh. Bei uns am Ende, wir brauchen drei Arten von Menschen. Das hat sich auch in den ersten Hires reflektiert. Wir brauchen auf der Machine Learning Seite gute Menschen, die uns helfen können, da unsere Modelle zu entwickeln. Wie gesagt, wir benutzen das Large Language Model off the shelf und dann weiter trainiert. Die anderen Sachen drumherum trainieren wir von Grund auf. Da haben wir auch viele Sachen selber entwickelt.

[51:15] Sind gerade so ein bisschen am Schauen, wollen wir es veröffentlichen, wollen wir es patentieren, wollen wir nichts davon preisgeben, weil manchmal ist es auch gut, leise zu sein. Das ist das eine Team. Da haben wir natürlich so ein bisschen auch durch Marks Hintergrund, durch meinen Hintergrund, richtig gute Leute gefunden, die von Meta zu uns gekommen sind, in Kanada von Mila gekommen sind, von Google gekommen sind. Wie viele Leute seid ihr gerade im Team? 20 in etwa. Und das Machine Learning Team als sich ist wahrscheinlich das größte Team da drin. Das zweite ist dann Engineering, also klassisches Engineering, Backend, Dateninfrastruktur auf der einen Seite und Frontend auf der anderen. Ich glaube, da besonders das Frontend ist natürlich auch super wichtig, weil wieder wegen dieser Change-Management-Geschichte. Ich habe keine Software, die ich jetzt verkaufe, die einfach 100 Prozent wunderbar funktioniert. Das heißt, ich habe eine Software, mit der du dich als Nutzer rumschlagen musst. Und je mehr ich da auf der UX-Seite gut mache, je mehr ich das zu einem System bekomme, wo du einfach Lust drauf hast, damit zu arbeiten, desto besser sind meine Chancen. Ich glaube, viele unterschätzen das so ein bisschen, wie wichtig UX ist in KI-Produkten heute, besonders weil sie eben noch nicht perfekt sind. Und dann das dritte Team ist dann auf der kommerziellen Seite. Da haben wir zum ersten Schritt noch mehr Leute reingeholt, die sich mit Pharma auskennen.

[52:22] Die da helfen können, mit den Kunden zu sprechen, in der einen Richtung, aber in der anderen Richtung auch einfach das Wissen ins Team reinzubringen. Also Richard, unser Mitgründer, der verbringt inzwischen die Hälfte seiner Zeit mit dem Machine Learning Team, um dem zu helfen, Sachen richtig zu annotieren, um dem zu helfen, Benchmarks richtig zu verstehen. Wenn es darum geht, wir bauen Epidemiologien für Firmen, da hilft es jemand zu haben, der es sein Leben lang gemacht hat, der ein PhD in dem Thema hat und da einfach nochmal eine Detailschärfe reinbringt, die du jetzt nicht bekommen würdest, wenn das ein Thema basierend auf Wikipedia wäre bei dir in der Firma. Das heißt, um da trotzdem einmal dran zu bleiben, eure ersten Hires waren nicht, hey, wie können wir einfach das Produkt an mehr Leute irgendwie so früh wie möglich versuchen, einfach maximal viele Pilotkunden zu closen, sondern die Aufgabe hast wahrscheinlich größtenteils du übernommen und hast gesagt, okay, mit Richard zusammen, der natürlich in der Pharma-Branche gut vernetzt ist, wenn er da diverse Jahre war, sondern die Frage war, okay, wie können wir parallel wirklich dieses Fundament schaffen, dass wir nicht an den Punkt kommen, dass Pharma sich da rumspricht, die Industrie ist ja jetzt, also es ist eine riesen Industrie, Aber es sind jetzt ja auch nicht Milliarden von Unternehmen, wo du sagst, okay, du musst halt gucken, wenn da sich rumspricht, dass wir bei irgendwem was komplett vergeigt haben. Das heißt, du musst sehr darauf bauen, dass dieser Kern des Produkts passt und deswegen Engineering und Machine Learning, um all das zusammenzuführen, ein wirklich valides Produkt zu bauen. Ja, absolut.

[53:40] Wie du gesagt hast, also Top-20-Farmer gibt es nur 20 Firmen von. Die sind natürlich enorm wichtig, dass wir die alle als Kunden gewinnen mittelfristig. Und da willst du jetzt nicht hinkommen, dir da bei der Hälfte irgendwie die Finger verbrennen mit einer Sache, die nicht ausgereift ist, die nicht ordentlich durchdacht ist. Also die Sales-Seite ist dann auch wichtig. Das machen wir zurzeit komplett Founder-led. Das mache ich, das macht Richard. Wir haben jetzt eine Kollegin auch in Amerika, die sozusagen da auch sich um den Markt mit kümmert, die dann auch das Account-Management für Pilotkunden übernommen hat. Die USA sind unser wichtigster Markt. Aber das ist jetzt keine Sache, wo wir gesagt haben, wir wollen das so wie andere Firmen machen, dass wir einfach jetzt komplett auf Sales gehen, wohl wissend, dass das Produkt noch nicht ausgereift ist und ein bisschen dann in der Hoffnung, dass das Produkt gut genug wird, während wir die ganzen Leute irgendwo in der Pipeline haben. Ist immer so ein bisschen Trade-off. Ich glaube, bei Pharma macht das, was wir machen, viel Sinn. Ich weiß von anderen Firmen, die das umgekehrt machen, in anderen Industrien. Wenn ich jetzt Software an kleine Anwaltskanzleien verkaufe, da kann ich auch einfach erst mal mit dem Verkaufen anfangen und dann mit der Qualität nachher kommen, weil von denen gibt es genug, wo ich das ein bisschen durchspülen kann. Ja, und das heißt jetzt going forward, wenn wir mal weitergucken, seid ihr gerade wahrscheinlich dabei, ihr habt wahrscheinlich immer noch Piloten gelaufen. Ich würde denken, erste Kunden, wo es gewandelt wurde vom Pilot in Kunden und werdet euch jetzt wahrscheinlich nach und nach konzentrieren, Produkt weiterzuentwickeln. Keine Frage, das wird ja nicht von heute auf morgen aufhören, das wird ja ein konstanter Prozess.

[55:01] Aber jetzt kommt für euch wahrscheinlich trotzdem zu überlegen, wie kommt ihr an den Punkt, dass nicht zum Beispiel Sales nur von dir in Anführungszeichen abhängt, also Founder Let Sales hinzu. Wie bauen wir dann zusätzlich dazu auch eine Go-To-Market-Motion?

[55:14] Wäre jetzt mein Gedanke, ohne dass wir uns davor unterhalten haben. Ja, genau. Denn das kommt, ich glaube jetzt, wie du gesagt hast, wir sind... Wir haben jetzt auch erfolgreiche Piloten gehabt, wir sind aber noch sehr stark in dieser Phase, dass wir das Produkt weiterentwickeln. So ein bisschen für mich intern die Metrik ist natürlich, wir sind eine Softwarefirma, wir wollen Software verkaufen und da gilt es für mich so ein bisschen den Anteil von Customization, den Anteil von Extraarbeit, die wir für einen neuen Kunden machen, per pre runterzufahren. Und ich weiß nicht, was da sozusagen die Prozentzahl ist. Ist das 10% Customization, ist das 20% Customization? Ab welchem Punkt man dann das Modell wechselt und sagt, okay, jetzt wissen wir, wie wir das verkaufen. Jetzt haben wir auch intern die Kapazitäten in Forward Deployed Engineering, in Account Management, die sozusagen diese Customization hinbekommen. Ich glaube, sobald ich da erstmal ein Rezept habe, dann ist auch der Punkt, externe Sales mit reinzuholen. Wir haben jetzt tatsächlich angefangen, nach einem externen Head of Commercial zu suchen, wohl wissend, dass das eine schwierige Rolle ist, zu füllen. Also ich erwarte nicht, dass die Person im November bei uns ist. Das ist wahrscheinlich eher Anfang 25 ein Plan und sollte dann auch vom Timing her gut hinhauen mit dem Punkt, wo wir einfach, wir haben das gelöst für ein, zwei Use Cases, die können wir jetzt verkaufen, da können wir die Firma hochskalieren. Während wir uns dann, und das wird weiterhin bei mir liegen bleiben.

[56:26] Sozusagen Ausschau halten nach den nächsten großen Workflows in Pharma, die wir dann sukzessive auch lösen wollen.

[56:31] Ist es dann, jetzt mal um das in Produktseite zu sprechen, ist das dann Multi-Product, weil ihr mehrere Use Cases habt und ich kaufe einen Use Case bei euch oder kaufe ich Reliant AI und habe dann mehrere Use Cases da drin? Ist eine gute Frage. Also zurzeit alles, was wir entwickeln für einen Piloten, das kommt auch allen anderen zugute. Das ist eine App, Reliant Tabular heißt das heute. Das kann sein, dass sich das weiterentwickelt in der Situation, wo wir verschiedene Sachen für verschiedene Kunden freischalten. Also konkret, was wir jetzt gerade machen, das ist viel Epidemiologies oder Analog Identification. Da geht das darum, rauszufinden, wenn ich ein Produkt habe, das ich an den Markt bringen will oder das ich jetzt einreichen will beim Regulator. Was sind vergleichbare Assets in den letzten Jahren, die zugelassen wurden, von denen ich was lernen kann? Also Assets mit vielleicht einer ähnlich seltenen oder häufigen Krankheit, mit einem ähnlichen Preispunkt, mit einem ähnlichen medizinischen Vorsprung gegenüber dem Status Quo in der Indikation. Die Art von Themen, das sind in der Regel in Pharmafirmen die gleichen Teams, die das machen. Jetzt gibt es aber auch andere Sachen, die wir machen können, an denen wir dran sind, wo das um systematische Literature-Views geht oder wo das darum geht, Key-Opinion-Leaders in der Healthcare-Welt zu identifizieren. Also wer sind die großen Uniklinik-Profs, wer sind die wichtigen Ärzte zu dieser speziellen Krankheit, mit denen ich reden muss, mit denen ich als Pharmafirma ins Gespräch kommen muss, wenn ich da ein neues Asset habe, wenn ich da meine Themen anschaue.

[57:59] Das sind dann andere Themen und ich glaube, da kommst du dann auch an den Punkt, wo das irgendwann unterschiedliche Produkte sind, die auch einfach anders aussehen müssen. Was wir gelernt haben, das war jetzt auch der Prozess übers letzte Jahr, ist relativ leicht, eine Workbench zu bauen. Es ist relativ leicht zu sagen, ich baue hier einen.

[58:15] Ein Excel mit ganz viel KI dahinter, speziell für Pharma und da kannst du dann alles drin lösen. Da ist natürlich aber dann auf der anderen Seite dieser Anspruch ans Change Management, also wie arg sich die Menschen dafür nochmal im Kopf neu sortieren müssen, höher und zum anderen habe ich da auch dann wieder mehr so ein bisschen diese Saiger-Problematik, wenn ich jemandem ein Spreadsheet gebe, dann erwartet der erstmal, dass das alles machen kann. Wo wir uns jetzt so ein bisschen hingewandelt haben, ist vielmehr in so ein Workflow-basiertes Denken, dass wir sagen, wir machen jetzt nicht hier den Chat-Assistenten, den Chat-Agenten, der alles für dich macht, sondern wenn du ein Problem hast, dann geben wir dem Problem einen Namen, dann gibt es einen Knopf mit dem Namen drauf, dann drückst du da drauf und dann hast du die Lösung. Das erfordert vom Nutzer weniger, weil der muss jetzt nicht lernen, wie gehe ich hier mit einem neuen System um, sondern der muss nur auf einen Knopf drücken. Und das macht das für uns auf der KI-Seite leichter, weil wir weniger Edge-Cases abbilden müssen. Wir müssen einfach wissen, das ist das Problem. Das müssen wir lösen auf 99,5 Prozent, damit das funktioniert.

[59:11] Aber wir können das ganz sauber runterdefinieren, ganz sauber runterbrechen auf eben dieses einzelne Problem. Das spiegelt sich dann auch so ein bisschen in dem Produkt wieder, wie das aussieht und wie man das dann auch in einzelnen Workflows, in einer Multiproduktstrategie ummünzen kann. Okay. Ich habe nur versucht zu verstehen auch, wie die Gespräche mit den Kunden laufen. Oder Piloten, hey, wir haben ja jetzt gerade das hier und wir arbeiten gerade parallel daran und es kann sein, dass da noch irgendwas hinzukommt. Wir lösen diesen einen speziellen Case, also dieses Landed Expand. So, ich komme da rein und die wissen, ich löse genau diesen einen Case und merken dann, warte mal, die haben diese Lösung auch noch, das könnte für uns ja auch super relevant sein, versus ich mache quasi einmal das Gesamtding. Und das ist ja schon eine Entscheidung, ist erstmal, wie gehe ich in die Kommunikation.

[59:54] Das Erste, was ihr gebaut habt, war natürlich erstmal ein Use Case und dann kommen andere Use Cases hinzu. Es ist ja so eine strategische Entscheidung, wo man sich überlegt, wie spreche ich mit meinen Kunden, wie frame ich die, wie bereite ich die darauf vor und dann ist der Mix aus, wie überfordere ich die nicht mit all dem, was wir jetzt gerade vielleicht können und gebe denen erstmal eine ganz klare Anleitung auch, was geht und was nicht geht. Ja, absolut. Also, du als Beispiel, ich fliege nächste Woche nach Boston für Gespräche mit zwei Pilotkunden da und bei einem sind wir gerade an dem Punkt, wo es darum geht, sozusagen in die letzte Pilotphase rüber zu wechseln. Der Großteil von dem Gespräch geht dann um den einen Workflow, den wir mit denen ganz konkret definiert hatten. Dann guck mal, das ist, was wir vor drei Monaten besprochen haben, da sind wir jetzt jetzt, was das Produkt angeht, da sind wir jetzt, was die Qualität angeht, da sind wir, was auch die Engagement-Metrics auf eurer Seite angeht. Aber dann gleichzeitig ein Teil von dem Gespräch ist aber auch.

[1:00:47] Und weil wir jetzt so viel Zeit mit euch verbracht haben, wir haben ein Forward-Deploy-Team, das auch wirklich viel Zeit bei Kunden verbringt, ist hier auch noch so ein bisschen Ausblick auf die Product-Roadmap über die nächsten sechs Monate. Hier sind ein paar andere Sachen, an denen wir dran sind in der Entwicklung. Da haben wir euch jetzt rausgehalten bisher, das war nicht Teil von den Piloten, aber die werdet ihr auch bekommen und verfolgen. Wenn wir hier jetzt weitermachen, dann sind das auch Sachen, wo es vielleicht Sinn machen würde, parallel einen nächsten Piloten aufzusetzen. Das ist dann die gleiche Lösung, aber mit dem gleichen Ansatz. Wir entwickeln das sowieso, aber wenn ihr dann nochmal so ein bisschen euren Dreh, euren Twist drauf bekommen wollt, dann lasst uns da einfach auch nochmal sozusagen diese extra Arbeit aufnehmen gemeinsam. Du hast gesagt, letzte Phase. In wie viele Phasen unterteilt ihr eure Pilotstrategie? Das hängt vom Piloten ab.

[1:01:31] Das hängt so ein bisschen von der Firma ab. Wir verhandeln gerade einen Pilot mit einer großen Pharmafirma. Das ist eine Phase, auch für sehr viel mehr Geld als viele andere Piloten, bei denen das dann irgendwie drei kleine Phasen sind für relativ kleines Geld. Da wollen die Leute einfach viele Gates drin haben, viele Möglichkeiten haben, nochmal nachzujustieren oder auch auszusteigen, wenn das nicht in die Richtung geht. Ich meine, was wir jetzt auch viel sehen ist natürlich, wir sind jetzt nicht die erste AI-Firma der Welt und ganz viele von unseren Kunden haben dann schon mit Chat-GPT gespielt, haben schon mit anderen Systemen gespielt, haben da dann auch schon eine entsprechende Enttäuschung gesammelt und eine Idee davon, woran das immer scheitern könnte und sind dann ein bisschen vorsichtiger geworden. Und darum versuchen wir das einfach so flexibel wie möglich zu gestalten. Wir sind überzeugt davon, dass unser Produkt funktioniert und dass wir mit entsprechendem Input von Kunden das auch an den Punkt bekommen, wo das für die funktioniert. Aber machen das den Leuten einfach. Also das kann dann auch gerne in drei Phasen sein, dass man erstmal genau zusammen den Workflow definiert, nochmal Parameter festzieht, dann vielleicht auch definiert, was wollen wir jetzt erreichen über die nächste Phase, dann diese Co-Development-Phase und als letztes so ein bisschen diese Evaluierungsphase. Ich glaube, da auch spannend, wenn man das nochmal zusammenfasst.

[1:02:41] Ihr habt nicht ein Schema für euch, wo ihr sagt, das ist unser Prozess für einen Piloten, sondern der Pilot passt sich dem Kunden an, weil am Ende, oder dem potenziellen Kunden, weil das sind gerade erstmal diejenigen, mit denen wir überhaupt ins Gespräch kommen wollen, überhaupt mit denen arbeiten wollen. Da dürfen wir als Firma nicht zu starr sein und sagen, es geht nur so, sonst machen wir das nicht. Aber das muss man einfach festhalten für alle, die hier zuhören. Genau, ich meine, das ist ja, wahrscheinlich ist das das Schöne an Founder-Led-Sales. Wir können das noch so machen, wie wir das für sinnvoll halten. Wir machen jetzt auch nicht alles mit. Das ist schon klar, wir haben in Piloten ein paar Sachen, da wissen wir, die brauchen wir, damit der Pilot Erfolg haben kann. Wenn das nicht gegeben ist, dann lehnen wir Piloten auch ab. Hast du Beispiele? Also das Commitment zum Beispiel, was du vorgesprochen hast? Das Commitment, der klare Bein auf der Kundenseite und sagen, ich finde das immer schwierig, in Piloten KPIs reinzuschreiben und sagen, wenn wir hier die Zahl erfüllen und hier die Zahl erfüllen, dann müsst ihr konvertieren. Am Ende entweder das Ding ist gut, dann konvertieren die Leute, oder das Ding ist nicht gut, dann finden sie auch Gründe, egal welche Zahlen du erreichst, da nicht zu konvertieren. Aber das Wichtige ist, das Gespräch zu haben und sicherzustellen, das ist jetzt der Buyer, ist jemand, der auch das Budget hat, danach weiter zu machen.

[1:03:50] Wenn ich jetzt jemanden habe, der irgendwo im mittleren Management sitzt, der hat ein Budget von 100.000 Dollar, die er ausgeben kann für Piloten, aber der hat noch die Software gekauft und der wüsste nicht mal, wie das geht in der Firma, dann bringt das nichts. Bei großen Pharmafirmen als Beispiel, wir schauen da sehr stark, dass wir erst ein MSA, also ein Master Service Agreement abschließen, um sicherzustellen, dass wir auch bei der IT und bei der Datensicherheit über alle Hürden gesprungen sind, dass die dann konvertieren könnten. Vielleicht sind für den Piloten die Ansprüche kleiner, aber mir hilft jetzt ein Pilot nichts, wenn die am Ende sagen, okay, das ist alles mega und jetzt machen wir ein Jahr Compliance mit euch und gucken, dass ihr hier die verschiedenen Zertifikate habt und oh, das muss ja alles irgendwie on-prem sein und bei uns in der Metallbox im Keller sein, was wir nicht unterstützen. Da ist es zum Beispiel wichtig, solche Gespräche immer nach vorne zu ziehen. Okay, das heißt, brauche ich jetzt weiterhin weitere Use Cases validieren mit neuen Kunden, die aktuellen Piloten zumindest für die einzelnen Use Cases in Kunden wandeln und gucken, ob man mit denen nicht parallel neue Pilot Relationships bauen kann für die weiteren Use Cases und dann nach und nach Richtung, okay, das sind die Use Cases, die wir schon haben, also klare Go-To-Market-Strategie dafür entwickeln, währenddessen ein weiteres Produkt stabilisiert und weiterentwickelt wird.

[1:05:02] Das klingt nach einer guten Zusammenfassung. Ihr seid, letzter Punkt, der mich noch interessiert, ihr seid ja in, ihr habt ja mehrere Hubs quasi, ihr seid jetzt nicht irgendwie rein Berlin oder rein Kanada oder rein US, sondern ihr seid irgendwie alles drei davon. Ich glaube, das eine Mal muss man fragen, warum? Und das zweite ist, wie funktioniert das für euch?

[1:05:20] Weil klingt ja erstmal nach einer komplexen Struktur. Ja, du mit dem Warum, also ganz pragmatisch. Marc und ich haben irgendwann gemerkt, wir wollen die Firma zusammen gründen. Wir denken über KI gleich nach. Wir denken gleich darüber nach, wie man Produkte für KI bauen sollte. Wussten aber auch, dass weder der eine noch der andere bereit ist, umzuziehen. Das ist ein bisschen eine ganz pragmatische Sache. Ich entscheide noch aus meiner Sicht, wir haben ein Büro hier in Berlin, das andere ist in Montreal. Ich habe in Montreal eine ganz andere Dichte an KI-Talenten als hier. Da können wir besser Leute einstellen. Wir haben auch in Berlin jetzt unseren ersten Mitarbeiter auf der Machine Learning Seite. Das war ein Principal Scientist bei Zalando, bis er jetzt letzte Woche zu uns gekommen ist. Aber abgesehen davon sind alle Machine Learning Forscher, Machine Learning Engineers bei uns in Montreal. Da hast du natürlich von Google ein großes Lab, da hat Meta ein großes Lab. Mit Mila hast du eine der weltbesten Universitäten in dem Bereich. Da gibt es dann auch ein größeres Startup-Ökosystem, in dem Leute wirklich KI gemacht haben. In Berlin finde ich ganz viele Menschen, die können E-Commerce bauen, aber richtig Hardcore-KI-Firmen haben wir hier deutlich weniger, was das vom Setup her schwieriger macht. Umgekehrt natürlich habe ich in Deutschland, ich habe Engineering-Talent. Der Großteil von unserem Engineering sitzt auch hier. Produktseitig auch.

[1:06:32] Zum 1. Oktober fängt bei uns der ehemalige VP-Product von Dr. Lieb an, um so ein bisschen das Produktthema bei uns zu übernehmen.

[1:06:40] Da haben wir gute Leute hier. Es gibt viele gute Argumente für den Standort Berlin. Für eine KI-Firma brauchst du aber noch diesen zweiten Standort. Aktuell, den haben wir jetzt in Montreal. Das hätte auch in London sein können. Gleichzeitig, das geht ganz gut für uns. Bei Pharma, dein Markt ist von Anfang an global. Einmal, die USA sind super wichtig. Das ist nicht das größte Land der Welt, aber das macht den meisten Pharma-Umsatz mehr als den besten der Welt zusammen. Das war klar, wir müssen da von Anfang an hin. Da sind wir mit Montreal natürlich von der Zeitzone her super aufgestellt. Das ist ein 45-Minuten-Flug nach Boston. Du bist auch in ein paar Stunden in New Jersey, was auf der Ostküste zumindest die beiden wichtigsten Hubs sind für Pharma und Biotech. Insofern, genau, das war so ein bisschen verschiedene Gründe, wie das dazu kam. Wir haben auch lange drüber nachgedacht. Wir haben sicher drei Monate lang nur geschaut, kriegt man das aufgestellt? Macht das Sinn? Macht das keinen Sinn? Wir hatten auch einen dritten technischen potenziellen Mitgründer an der Westküste. Da haben wir dann eben gemerkt, das funktioniert nicht. Dafür ist der Zeitzonenunterschied dann doch zu groß. Montreal, Berlin funktioniert ganz gut. So ab 13 Uhr deutscher Zeit ist Mark wach. Ab 15 Uhr ist dann 9 Uhr bei denen, auch alle anderen im Büro. Und umgekehrt ich gehe spät ins Bett. Das kriegen wir irgendwie hin.

[1:07:51] Standorte in USA, da haben wir kein Hub. Da haben wir einzelne Mitarbeiter auf der kommerziellen Seite. Die brauchst du da. Also ich meine einmal, wir merken das selber. Amerikaner reden lieber mit Amerikanern. Wir haben auch eine amerikanische ENG, weil es auch vertraglich manchmal einfacher ist, für die mit amerikanischen Firmen zusammenzuarbeiten. Aber auf der kommerziellen Seite, da ist das weniger bürobasiert. Da ist es entscheidend, dass wir dann auch bei den Kunden vor Ort sind, dass wir mit denen Zeit verbringen. Die anderen beiden Standorte Berlin und Montreal haben ja ganz klassische Büros. Da ist auch die Erwartung, dass die Mitarbeiter eine große Zeit über im Büro sind. Ich glaube, das ist enorm wichtig, was diese schnelle Abstimmung angeht. Wir haben jetzt, klar, wir haben eine abstrakte Roadmap, das ist so ein bisschen die von hier zum Dekakorn, aber die sozusagen wochenbasierte Roadmap ist natürlich viel, viel dynamischer, viel fassier. Und da sehen wir selber, wie wichtig das ist, dass die Menschen nebeneinander sitzen können. Und wenn sich Montagabend der Plan ändert, dass man dann auch Dienstagfrüh sozusagen koordiniert am neuen Plan arbeiten kann und nicht...

[1:08:49] Sich erstmal stundenlang in irgendwelchen Konferenzen verliert. Klingt auf jeden Fall trotzdem irgendwie anspruchsvoll, wenn du, glaube ich, einen ganz anderen Kommunikationsaufwand hast, als wenn du jetzt alle in einem Büro hättest, was bei 20 Leuten noch ganz gut funktionieren könnte. Das wird dann irgendwann ähnlich, also auch viel Kommunikationsaufwand. Klingt aber natürlich erstmal in sich schlüssig und ist, glaube ich, einfach spannend zu verstehen für Leute, die denken, ah, okay, warum, wieso, weshalb, was sind die Gedanken, die sie sich gemacht haben? Nicht, dass jetzt jeder darüber nachdenkt, aber manchmal, selbst wenn das nur ist, ein zweites Office aufzumachen, muss ich ja über ähnliche Fragestellungen nachdenken. Deswegen glaube ich, können wir hier einen Punkt machen. Kamots hat mir sehr viel Spaß gemacht, auch einfach um so einen Einblick zu bekommen, was sind die Unterschiede zwischen KI-Firma und KI-Firma und wie fange ich das an von technischer und Produktseite zu denken, um dann wirklich eine Basis zu schaffen. Und deswegen vielen lieben Dank, dass du dir die Zeit genommen hast. Ich bin mir sicher, von euch hört man noch einiges und wir hören uns vielleicht auch nochmal hier. Bis dahin, großes Dankeschön. Ich würde dir die letzten Worte des Podcasts nochmal übergeben quasi als Verabschiedung und freue mich auf alles, was kommt. Achso, ich verlinke natürlich sowohl dein LinkedIn als auch Reliant in den Show Notes, dass man da nochmal nachgucken kann und up-to-date bleiben kann.

[1:09:58] Ja, du Fabian, vielen Dank dir. Hat sehr viel Spaß gemacht. Genau, KI-Firma oder KI-Firma, das wird sich noch herauskristallisieren über die nächsten Jahre. Ich glaube, das ist unheimlich spannend und das ist einfach eine, vielleicht eine der großen Basistechnologien der nächsten Jahre, dass da muss nicht jeder die Technologie weiterentwickeln, um dann eine sinnvolle Firma immer obendrauf zu bauen. Gleichzeitig ist die Technologie noch nicht an dem Punkt, dass das ausreicht für die meisten Ansätze darum. Ich glaube, diese Abstufung von verschiedenen Arten von KI-Firmen wird es weiterhin geben. Ich bin froh, dass ich da mitmachen darf und dir vielen Dank für die Einladung.