Eine Frage, die mir häufig gestellt wird, ist, wie ich um Himmels willen von der Sprachtechnologie und KI zum Banking gekommen bin. Nun, hier ist die Antwort.
Text-to-Speech
Der Höhepunkt meiner bisherigen Karriere war die Einführung und der anschließende Erfolg des Google Text-to-Speech-Systems. Es ging im Juni 2012 als Teil des neuen Google Now-Dienstes live, der es Nutzern ermöglichte, komplexe Sprachsuchanfragen zu stellen und einfache Fragen an den Dienst zu richten. Die Einführung war ein Erfolg, und der Dienst wird heute für die gesamte Sprachausgabe von Google verwendet, einschließlich Navigationsanweisungen, interaktiver Sprachsuche und sprachgestützter Technologien. Das Text-to-Speech-System funktioniert über das Internet sowie direkt auf dem Gerät und war bis 2015 auf über 1 Milliarde Android-Geräten installiert.
Der Hauptbeitrag unseres Teams bestand darin, eine äußerst natürliche und angenehm klingende Stimme bereitzustellen. Nutzer akzeptieren keine schlechte Sprachsynthese: Sie klingt unangenehm im Ohr, und die meisten schalten sie ab, sobald sie können. Nur durch die Entwicklung von etwas qualitativ Hochwertigem konnte der Dienst als brauchbar angesehen werden.
Wie wurde das also erreicht? Das Text-to-Speech-System nutzte das Unit-Selection-Framework, eine Technologie mit langer Tradition, die über Jahre hinweg von erstklassigen Laboren und Forschern entwickelt wurde. Im Wesentlichen nimmt man eine Sprachdatenbank eines einzelnen Sprechers auf. Jeder Satz wird in Phoneme zerlegt, die die „Einheiten“ (Units) bilden, von denen der Algorithmus seinen Namen hat. Die Klangmuster einer bestimmten Spracheinheit sind stark kontextabhängig. Zum Beispiel hat der /t/-Laut in „top“ viel Aspiration, während das /t/ in „stop“ von Natur aus ganz anders ist und eher einem kurzen (50 ms) Moment der Stille entspricht. Aufgrund dieser Kontexteffekte würde es holprig und unnatürlich klingen, ein einziges /t/ aufzunehmen und überall zu verwenden. Tatsächlich muss man Tausende, manchmal sogar Zehntausende von jedem Phonem aufnehmen, um genügend Einheiten zu erhalten, die das Spektrum der benötigten Klänge angemessen abdecken.
Sobald eine Datenbank gesammelt und analysiert wurde, wird sie in ein effizientes Laufzeitformat kompiliert. Wenn ein Satz eingeht, wird er in Phoneme umgewandelt, und dann durchsucht die Datenbank das System nach der „besten“ Sequenz – also der Sequenz mit den passendsten Einheiten, die zudem am wenigsten holprig zusammenpassen. Würde man dies auf die einfache Art tun, bräuchte man für einen einzigen Satz stundenlange Rechenzeit. Doch durch eine Kombination aus dynamischer Programmierung, intelligenter Indizierung, maßgeschneiderten Datenmodellen, Caching, Pruning und Suchoptimierung kann ein Satz etwa hundertmal schneller generiert werden, als es dauert, das Audio abzuspielen.
Nichts davon entstand über Nacht. Tatsächlich arbeitete ich bereits seit 1989 an diesem Problem, als wir 2012 das Google-System einführten. Ich scherzte einmal (und bereute es später) in einem Interview, dass „Michelangelo nur sieben Jahre brauchte, um die Sixtinische Kapelle zu bemalen“. Meine prägenden Jahre verbrachte ich an der Universität Edinburgh, wo ich 1992 meinen Doktortitel abschloss. Ich blieb dort weitere acht Jahre und wurde 1999 schließlich Direktor des universitätseigenen Centre for Speech Technology Research. Den Großteil dieser Zeit arbeitete ich an Text-to-Speech, und das Festival System , das ich gemeinsam mit Alan Black und Richard Caley entwickelt habe, wird noch immer als Lehr- und Forschungsinstrument genutzt. (Und falls Sie einen Beweis dafür brauchen, dass ich einmal programmieren konnte, werfen Sie einen Blick auf das github-Archiv).
Die 1990er Jahre an der Universität Edinburgh waren eine großartige Zeit. Die Universität verfügte über eine lebendige Gemeinschaft in den Bereichen KI, maschinelles Lernen, Sprachtechnologie, Linguistik, Kognitionswissenschaft und Informatik – ein wunderbares Lernumfeld. Wenn ich sehe, wie viel Aufmerksamkeit die KI heute erhält, weiß ich ehrlich gesagt nicht so recht, wie ich reagieren soll. In den 1990er Jahren waren wir vielleicht ein paar Hundert in Großbritannien, wir kannten uns größtenteils untereinander und blieben unter uns, vor allem, weil aus kommerzieller Sicht kaum etwas wirklich funktionierte. Es hat jedoch enormen Spaß gemacht. Die konzeptionellen Probleme, über die wir damals debattierten, waren dieselben wie heute: Sollten Maschinen einen Moralkodex haben? Könnten sie gefährlich sein? Was ist mit den Arbeitsplätzen der Menschen? Und so weiter. Aber das waren Debatten innerhalb einer introvertierten Gemeinschaft. Ich bin immer noch verblüfft, dass ich jeden Tag einen Artikel über KI in der Presse sehe, zu dem sich sogar Premierminister und Präsidenten äußern.
Startup-Leben
Ich habe mein erstes Technologieunternehmen, Rhetorical Systems, im Jahr 2000 mitgegründet, und vom ersten Moment an wusste ich, dass das mein Leben ist. Abgesehen von einem Zwischenspiel in Cambridge von 2004 bis 2006 habe ich das akademische Leben hinter mir gelassen.
Das Leben bei Rhetorical war die übliche Achterbahnfahrt eines Tech-Startups, wie sie schon oft dokumentiert wurde, daher erspare ich mir das hier – außer der Anmerkung, dass es damals kaum Anleitung gab, wie man so etwas angeht. Wirtschaftsbücher waren auf große Konzerne ausgerichtet, und die wenigen Startup-Bücher, die es gab, handelten von der Eröffnung von Läden, Restaurants oder „normalen“ Unternehmen. Wer heute ein Unternehmen gründet, kann zumindest auf eine großartige Community und eine Fülle an Lektüre zurückgreifen.
Rhetorical entwickelte die Text-to-Speech-Technologie, die ich zuvor an der Universität erfunden hatte. Qualitativ war sie ein großer Erfolg, kommerziell jedoch weniger. Der Grund dafür war, dass es selbst bei wachsender Akzeptanz schwierig ist, diese Technologie auf dem breiteren Markt zu verkaufen. Die Leute wollten sie zwar nutzen, waren aber nur ungern bereit, dafür zu bezahlen. Dieses Problem ist im KI-Markt nach wie vor weit verbreitet: Alexa, Siri und Google Home nutzen zwar intensiv KI- und Sprachtechnologien, diese werden jedoch von großen Technologieunternehmen bereitgestellt und nicht von eigenständigen Startups. Oft wurden die von den großen Tech-Konzernen eingesetzten Technologien in Startups erfunden und durch Übernahmen eingegliedert – es ist also klar, dass beide Unternehmenstypen aufeinander angewiesen sind. Rhetorical wurde 2004 zwangsläufig übernommen, woraufhin ich zwei Jahre am Fachbereich Ingenieurwesen der Universität Cambridge verbrachte.
2006 war ich Mitgründer von Phonetic Arts, diesmal als CEO. Wir machten im Grunde das Gleiche, aber der Zielmarkt war nun die Unterhaltungsindustrie. Wieder war die Technologie exzellent, aber zahlende Kunden zu finden, blieb schwierig. 2010 wiederholte sich die Geschichte: Google rief eines Tages an und fragte, ob wir an einem Deal interessiert seien. Die fünf Monate der zermürbenden Verhandlungen, die folgten, könnten ein ganzes Buch füllen, aber das Ende war glücklich: Ende 2010 wurde Phonetic Arts übernommen, das Team schloss sich Google an und wurde zum Google Text-to-Speech-Team.
Die Zeit bei Google hat viel Spaß gemacht, und es war eine Erleichterung, sich nicht jeden Monat Gedanken über die Gehaltsabrechnungen machen zu müssen. Die Unternehmenskultur bei Google war großartig, aber was mich wirklich faszinierte, waren nicht die kostenlosen Mittagessen oder Massagen, sondern wie Google ein derart skalierbares Unternehmen aufgebaut hatte. Auch wenn Google heute riesig ist, war das nicht immer so. Doch schon in der Anfangszeit konnten ein paar hundert Ingenieure Produkte entwickeln, die von zig Millionen Menschen genutzt wurden. Als ich zum Android-Team stieß, bestand es aus nur 300 Ingenieuren, hatte aber bereits 500 Millionen Telefone ausgestattet.
Dafür gibt es viele Geheimnisse. Erstens: Stellen Sie nur exzellente Ingenieure ein und lassen Sie sie zum Herzstück des Technologieunternehmens werden. Viele Firmen streben das zwar an, aber nur sehr wenige setzen es wirklich um. Im besten Fall stellen sie ein paar Stars ein, glauben aber, dass diese für die „langweiligeren“ oder „normalen“ Ingenieursaufgaben nicht nötig seien. Der Google-Ansatz bestand darin, auf allen Ebenen Stars einzustellen und langweilige Aufgaben zu eliminieren, indem man Code schrieb, der die Arbeit automatisch erledigt. Manuelle Prozesse gibt es bei Google so gut wie gar nicht.
Zweitens: das System aus Continuous Integration, Deployment und Monorepo. Es war beeindruckend zu sehen, wie Google Milliarden von Codezeilen in einem einzigen Repository verwaltete, die alle kontinuierlich und automatisch erstellt und getestet wurden. Das bedeutet, dass jeder Ingenieur den Code eines anderen wiederverwenden kann, ohne um Erlaubnis fragen oder etwas Besonderes tun zu müssen – man richtet einfach die Abhängigkeit ein, und alles wird kompiliert und ausgeführt. Google hat keinen „Ballast“ in seiner Codebasis – alles wird kompiliert, ausgeführt, dokumentiert und getestet. Der Code wird nach einem außergewöhnlich hohen Standard geschrieben und ist einfach zu lesen und zu verstehen. (Im Gegensatz dazu steht die Bankenwelt, in der man häufig Systeme findet, bei denen niemand mehr wirklich versteht, wie die vor Jahren geschriebenen Komponenten funktionieren, geschweige denn, wie man sie entfernen oder ersetzen könnte.)
Abschließend sollte man erwähnen, dass die bei Google eingesetzte Technologie oft gar nicht so originell ist; sie wird lediglich außergewöhnlich gut umgesetzt, was Geschwindigkeit, Stabilität und Verfügbarkeit angeht (denken Sie an Gmail). Aber einfache Dinge gut zu machen, ist nicht unbedingt leicht – ein System wie Gmail bewältigt weltweit riesige Mengen an E-Mails und muss dabei stets schnell und effektiv funktionieren. Wenn man Gmail als Transaktionssystem betrachtet, bei dem jede E-Mail eine Transaktion darstellt, erkennt man die Überschneidungen zum Bankwesen.
Obwohl die Zeit bei Google großartig war, bleibt man als Unternehmer immer einer. Als meine „Zeit“ abgelaufen war, verließ ich das Unternehmen Ende 2013. Wie ein Sous-Chef, der in einem Spitzenrestaurant gelernt hat, hatte ich das Gefühl, mit dem Rezept für den Aufbau eines großartigen Technologieunternehmens im Gepäck zu gehen. Mit diesem Gedanken im Hinterkopf gründete ich Thought Machine.
Das Team aufbauen
Meine oberste Priorität war es, ein echtes Weltklasse-Team zu schaffen und es mit dem Geist technischer Exzellenz zu durchdringen. Der Schlüssel dazu ist eine Vision von einem Unternehmen, der sich die Leute anschließen wollen. Dies ist eine Kombination aus einem großartigen Arbeitsumfeld, einem interessanten Fachbereich, einem riesigen Markt und dem Potenzial für einen Börsengang. Ich wollte nicht noch einmal ein Unternehmen für eine schnelle Übernahme aufbauen. Zuerst wandte ich mich an ehemalige Kollegen, von denen ich wusste, dass sie technisch exzellent waren und dieselben Unternehmensziele verfolgten wie ich. Auf diese Weise stellte ich Fabian, Pebers und Will ein – alle von Google.
Irgendwann gehen einem die bekannten Kandidaten aus, also stellte ich einen internen Recruiter ein, Hung Lee, der sich in Vollzeit um den Aufbau des Teams kümmerte. Er hatte die Idee, eine Veranstaltung abzuhalten, bei der Kandidaten vorbeikommen, sich mit dem Team austauschen und ich einen Vortrag über das Unternehmen halten konnte. Das war ein sofortiger Erfolg, und wir haben seitdem immer auf diese Weise rekrutiert – in den letzten vier Jahren kamen mehr als 1.000 Kandidaten zu den Recruiting-Events von Thought Machine.
Ich hielt es für wichtiger, erst das großartige Team aufzubauen, bevor ich mich für das genaue Problem entschied…
Das Problem wählen
Der allgemeine Bereich war schnell gefunden: Da London sich rasant zum Fintech-Zentrum der Welt entwickelte, war dies die offensichtliche Wahl. Im ersten Jahr von Thought Machine arbeiteten wir mit Banken in verschiedenen Bereichen der Konsumentenfinanzierung zusammen. Der Appetit der Banken auf Neues war deutlich, und an Auswahl mangelte es uns nicht. Doch es wurde klar, dass die meisten Fintechs nur an der Oberfläche arbeiteten, weil man sich an den Kern – die mythische Kernbankenplattform – nicht herantraute. Die Anbindung an Kernbankensysteme war schwierig, da diese oft vor Jahrzehnten in Cobol geschrieben wurden und auf Mainframes liefen. Sie waren weit entfernt von einer in der Cloud gehosteten API-Microservice-Architektur.
Den Business Case erkannte ich deutlich, als ich mit Challenger-Banken sprach. Es würde Jahre dauern, bis sie ihre eigenen Bankensysteme aufgebaut hätten, und der Zukauf von bestehenden Drittanbietern war schwierig und teuer, da keiner von ihnen moderne Architekturen nutzte. Es gab einen klaren Bedarf, eine Marktlücke.
Fast jeder riet uns davon ab: Mainframe-Kernbankensysteme seien eine Konstante; Banken würden sich niemals ändern, das Problem sei zu schwierig und unlösbar. Was den letzten Punkt angeht (ist Kernbanking schwierig?), weigerte ich mich, klein beizugeben. Warum sollte es so schwer sein, Zahlungen und Zinsen zu berechnen und die Ergebnisse zu erfassen? Und natürlich spornt es einen ehrgeizigen Ingenieur nur noch mehr an, wenn einem so viele Leute sagen, wie schwierig etwas sei!
Also führten Will Montgomery und ich eine Reihe langer Gespräche, und Will begann mit der Entwicklung dessen, was später Vault Corewurde. Nach ein paar Monaten hatten wir etwas vorzeigbares und präsentierten es einigen Banken. Das Feedback war sofort ermutigend, was dazu führte, dass wir im Laufe des Jahres 2016 das gesamte Unternehmen nach und nach auf dieses Produkt ausrichteten. Während wir immer weiter bauten, wuchs das kommerzielle Interesse rapide, und wir erkannten, dass die Chance viel größer war als ursprünglich angenommen: Wir würden nicht nur eine Kernbanken-Engine in der Cloud bauen, sondern tatsächlich eine vollständige Privatkundenbank – mit Treasury-Systemen, Finanzberichterstattung, CRM, Kreditrisikoentscheidungen und Dutzenden weiteren Komponenten.
Wenn man kritisch sein wollte, könnte man sagen, dass an unserem Vorgehen nichts besonders Magisches oder Originelles ist; wir wenden lediglich die Best Practices des agilen Cloud-Computings auf das Problem des Privatkundengeschäfts an. Aber genau das ist der Punkt: Man muss mit der Denkweise des Cloud-Computings beginnen und das spezifische System von Grund auf neu aufbauen, wobei man dieser Methodik treu bleibt. Man kann sich nicht von der Art und Weise weiterentwickeln, wie die Bankenbranche seit Jahrzehnten gearbeitet hat.
Und so kam ich von Text-zu-Sprache-Systemen zu cloudbasierten Bankenplattformen.
