Maggie: Die Saga eines Startups für KI-Babyübersetzer

TL;DR Zusammenfassung Ich traf einen Klassenkameraden auf einem Parkplatz und wir kamen uns über einen verlorenen 10-Dollar-Schein näher. Was ich nicht wusste, war, dass mein Klassenkamerad ein Modell gebaut hatte, das Babyschreie übersetzte, und auf der Suche nach einem Mitgründer war. Dank konnten wir uns als Geschäftspartner treffen, einen Arbeitsplatz finden und unser Unternehmen gründen. Dr. Peter Scheurmans Venture Lab Innerhalb weniger Wochen baute ich einen Server rund um das Modell und eine Android- , mit der Eltern das Weinen ihres Babys übersetzen konnten. Die Latenz war jedoch schrecklich – niemand möchte warten, bis ein Server hochfährt oder Audiodateien hochlädt, während er ein weinendes Kind im Arm hält. App Also beschlossen wir, das Modell in die App zu integrieren, aber es war zu groß. Das bedeutete, dass wir seine Größe durch Quantisierung verringern mussten, ohne die Genauigkeit merklich zu reduzieren, und herausfinden mussten, wie wir die vom Modell benötigten Eingaben auf dem Gerät generieren konnten, ohne dass die App abstürzte. Ohne , der uns wertvolle Ratschläge zu TensorFlow, Android und Start-ups gab, hätten wir das nicht geschafft. Pete Warden Aber jetzt, da das Modell auf dem Gerät war, war es außerhalb unserer Reichweite. Wie messen wir seine Leistung? Wie sieht Erfolg aus? Ich baute eine Schicht aus Protokollierung, Überwachung und Benutzerfeedback um das Modell herum auf, um alle Informationen zu erfassen, die zur Beurteilung der Leistung erforderlich sind. Diese Daten erzeugten ein Schwungrad; jede Übersetzung erzeugte neue gekennzeichnete Trainingsdaten – wir erweiterten unseren Datensatz jetzt mit minimalem Aufwand. Als die App dann funktionierte und überwacht wurde, standen wir vor einem Dilemma: eine oder mehrere Übersetzungen anzeigen? Unser Instinkt sagt uns, wir sollten die genaueste Übersetzung anzeigen – schließlich ist das die, die am wahrscheinlichsten richtig ist. Aber was, wenn die Übersetzung nur zu 70 % zuverlässig ist? Und was ist mit 60 % oder 50 %? Dies war ein subtiles Problem, das uns dabei half, zu sehen, wie die Leute die App tatsächlich nutzten, und wir entdeckten ein Killer-Feature. Es stellt sich heraus, dass es sehr schwierig ist, das Telefon zu finden und die App zu öffnen, während das Kind in den Armen weint. Deshalb haben wir mithilfe eines intelligenten Lautsprechers von Google Home ein Babyphone namens entwickelt – freihändige Übersetzungen. Homer Der intelligente Lautsprecher war jedoch keine Rettung. Uns gingen das Geld und die Energie aus, die Lebensumstände zwangen uns, wieder nach Hause zurückzukehren, und unser Baby-Übersetzer landete auf dem Abstellgleis. Vorwort Ich begann, für die Arbeit an einer KI-Funktion zu arbeiten, weil ich eine Möglichkeit sah, ein klobiges, altes Expertentool zu umgehen, und natürlich muss jedes Start-up ein Start-up sein. Während ich den Prototyp dieser Funktion entwickelte, stieß ich auf einige seltsam vertraute Probleme. Also durchsuchte ich meine Tagebücher und fand Maggie, den Baby-Übersetzer, den ich und ein Freund vor der Pandemie gebaut hatten. Es ist fast sieben Jahre her, und die gleichen Probleme, die KI-Tests und die Produktionsbereitstellung plagten, sind immer noch eine ungemilderte Plage, obwohl der Stand der Technik erhebliche Fortschritte gemacht hat. Hier ist eine Reflexion meiner Notizen, Gedanken und des Codes von Maggie, um die üblichen Probleme auf dem Weg zur Produktionsreife von KI aufzuzeigen. Ich hoffe, Sie finden es hilfreich. KI- Was ist Maggie? Maggie ist der Name des jüngsten Kindes der Simpsons aus der gleichnamigen Serie. Maggie ist ein Baby, das noch nicht sprechen gelernt hat. Maggies Onkel Herb ist nach einer schlechten Geschäftsentscheidung am Boden zerstört und zieht bei den Simpsons ein. Auf wundersame Weise baut er einen funktionierenden Baby-Übersetzer, nachdem er sich von seiner Nichte und der Frustration der Familie über ihre Sprachlosigkeit inspirieren ließ. Auf ähnliche Weise kam mein Freund Chris durch seine Beziehung zu seiner kleinen Schwester, die Probleme mit dem Sprechen hatte, auf die Idee, einen Baby-Übersetzer zu bauen. Daher haben wir unsere App Maggie genannt. arbeitete damals in einem Babylabor und fand heraus, dass es physiologische Grenzen für das Spektrum der Geräusche gibt, die Kinder innerhalb einer bestimmten Altersgruppe machen können. Auf der Grundlage dieser Erkenntnisse sammelte er Trainingsdaten und erstellte ein Klassifizierungsmodell für Babyschreie – eine beeindruckende Leistung, da er Physik studierte und keinerlei Informatikerfahrung hatte. Chris Wir hatten einen gemeinsamen Kurs – Engineer Service Learning –, in dem die gesamte Klasse an der LEED-Zertifizierung für eines der Gebäude auf dem Campus arbeitete. Ich erinnere mich an ihn als den unbekümmerten Typen, der mit einem Longboard in den Unterricht kam. Unsere erste Begegnung fand außerhalb des Klassenzimmers auf dem dunklen Parkplatz eines Lebensmittelladens statt, wo ich ihn sah, wie er sich für eine Fahrt mit seinem Dirtbike bereitmachte. Er hatte neben meinem Auto geparkt, und wir unterhielten uns. Dann bemerkte ich ein zerknülltes Papier neben ihm, hob es auf, sah, dass es Geld war, und sagte ihm, dass er sein Geld fallen gelassen hatte. Er sagte, es sei nicht seins, aber ich sagte ihm, er solle es behalten. Wir wussten nicht, wie viel es war; der Parkplatz war zu dunkel. 1 Dollar, 10 Dollar oder 100 Dollar. Ich sagte ihm, ich hoffe, es wären 100 Dollar. Es waren 10 Dollar. Aber diese erste Begegnung baute genug Vertrauen zwischen uns auf, dass er mich ein paar Wochen später, als wir beide im Venture Lab – dem Startup-Inkubator an der UC Merced – arbeiteten, bat, eine App zu entwickeln, um seinen Baby-Übersetzer einzusetzen. Ohne das Venture Lab hätten wir nie an eine Zusammenarbeit gedacht. Ich habe bestimmt nicht irgendwelchen Klassenkameraden erzählt, dass ich Android-Apps entwickle, und er hat auch nicht mit seinem kleinen Übersetzungsmodell geprahlt. Persönliche dritte Räume haben eine magnetische Magie, die man nicht unterschätzen sollte. Ich habe ein Modell und es funktioniert. Was nun? Obwohl Chris ein funktionierendes Modell erstellt hatte, konnte er nicht herausfinden, wie er es bereitstellen sollte. Das war Anfang 2017 und es gab nicht viele Kurse oder Anleitungen, die dies demonstrierten. Sein Mentor bei TensorFlow empfahl die Bereitstellung auf Android, aber die mobile Entwicklung zu lernen, war zu viel verlangt. Ich kannte Android und hatte mehrere Apps im Play Store bereitgestellt, aber selbst für mich war das eine Herausforderung. Also wählte ich den einfachen Weg. Ich habe das Modell auf einen Server gestellt und API-Aufrufe an es gesendet. Die Ausführung des Modells auf einem Flask-Server war überraschend einfach: TensorFlow importieren, das Modell von der lokalen Festplatte laden (ich habe erst später daran gedacht, das Modell so bereitzustellen, dass es leicht versioniert werden kann) und die Anfragen darauf richten. Aber es gab ein paar Fallstricke: Die Anfrage musste in die Eingabe umgewandelt werden, die das Modell erwartete, und wir haben kein gemeinsames Paket erstellt, um diese Arbeit zu erledigen. Da Chris das Modell trainierte und ich den Server erstellte, wurde dies zu einer Fehlerquelle. Die erste Anfrage war immer langsam; wir hosteten auf AppEngine und ich hatte die Anzahl der inaktiven Server auf Null (Standard) gelassen, weil ich noch nie mit einem Server gearbeitet hatte, der eine so lange Einrichtung erforderte. Warum sollte man Geld für inaktive Server ausgeben, wenn es nur eine Sekunde dauerte, neue Server zu starten? Das Laden und Ausführen des Modells dauerte lange, also mussten wir unsere Server rund um die Uhr inaktiv lassen. Man weiß nie, wann ein Baby anfängt zu weinen, was eine höhere Hosting-Rechnung bedeutet. Dieser langsame Start machte das Integrationstesten zu einem großen Problem, so dass ich auf manuelle Tests zurückgreifen musste. Es war unerträglich, minutenlang auf das Bestehen der Tests zu warten. Es war schneller, den Server mit Hot-Reload hochzufahren und vor jedem Commit manuell zu testen. Die Bereitstellung und Versionskontrolle war schwierig. Ursprünglich hatte ich das Modell mit dem Repository bereitgestellt, weil ich eine Art Versionskontrolle wollte, aber ich erkannte schnell, dass dies auf Kosten der Bereitstellungsfreundlichkeit ging. Für jedes Modellupdate musste der Server bereitgestellt und der gesamte Cluster neu gestartet werden, was einige Zeit in Anspruch nahm, da die Server das neue Modell laden mussten. Trotz dieser Probleme hat es funktioniert. Durch die gemeinsame Nutzung des Modelleingabeparsers und des Transformatorcodes wurde das erste Problem gelöst. Das Modell als Blackbox zu behandeln und es zu simulieren, erleichterte die Erstellung von Integrationstests darum herum. Diese Tests stellten sicher, dass es keine unerwarteten Fehlausrichtungen zwischen Server und Modell gab – solange die Mocks genau waren. Jetzt gibt es Modellschnittstellen, die die Mock-Korrektheit während der Entwicklung sicherstellen können. Bereitstellung und Versionskontrolle für Modelle sind heutzutage kein Problem mehr und erfordern für die meisten Anwendungsfälle neuartige Lösungen. Andererseits haben uns die Latenz- und Verfügbarkeitsprobleme letztendlich dazu gezwungen, das Modell auf der App am Rand bereitzustellen. Dies hatte den Vorteil, dass die Netzwerklatenz beseitigt wurde, die viel schnellere CPU des Telefons genutzt wurde und die App im Hintergrund ausgeführt werden konnte, was unser Startlatenzproblem löste und unsere Hostingkosten senkte. Aber natürlich gab es neue Probleme. Wo soll das Modell hin? Wir haben viel Zeit damit verbracht, zu überlegen, wo wir das Modell platzieren sollten. Wir wollten die Geschwindigkeit und Zuverlässigkeit des Telefons, sehnten uns aber nach der Sicherheit und einfachen Bereitstellung des Servers. Anfangs war es attraktiv, das Modell auf dem Server zu platzieren: Die Aktualisierung und Bereitstellung war problemlos. Die Anzahl der Benutzer wurde dadurch nicht begrenzt – zu diesem Zeitpunkt unterstützten nur bestimmte Android-Versionen die TensorFlow-Inferenzbibliotheken, sodass die Installation des Modells auf dem Telefon weniger Benutzer bedeutete. Es bot mehr Optionalität – die API des Servers konnte von intelligenten Lautsprechern, Websites und Babyphones verwendet werden. Ich musste mir keine Sorgen machen, dass jemand das Modell stiehlt. Doch die Nachteile häuften sich: Es war langsam; das Hochladen der Aufnahmen, ihre Transkription und das anschließende Ausführen des Modells dauerte lange. Das Ausfallrisiko machte die App weniger attraktiv – unsere Benutzer brauchten eine Verfügbarkeit von 100 %; das Attraktivste an der App war, dass sie für Sie da war, wenn Ihr Ehepartner, Ihre Eltern usw. nicht da waren – sie war für Sie da, wenn Sie mit einem unergründlichen, weinenden Kind allein waren. Es war teuer. Die für diese Arbeit erforderlichen Maschinen waren für ein Startup, das alles mit Google Cloud-Guthaben bezahlen musste, zu teuer. Letztendlich haben wir uns aufgrund der ersten beiden Punkte dazu entschieden, das Modell in die App zu integrieren – die App war nicht überzeugend, wenn man auf die Übersetzung warten musste oder wenn sie gelegentlich ausfiel. Ein paar Sekunden Latenz erscheinen wie eine Ewigkeit, wenn man ein schreiendes Neugeborenes im Arm hält. Aber das Modell auf das Telefon zu bringen, hatte seine Probleme, wie ich im nächsten Abschnitt beschreiben werde. Die Lektion, die ich daraus gelernt habe, ist, dass Sie die Benutzererfahrung optimieren sollten – selbst wenn die Lösung nicht skalierbar ist, Ihnen kein zukünftiges Wachstum bringt oder Ihr geistiges Eigentum gefährdet. Unternehmen leben und sterben von ihrer Benutzererfahrung, insbesondere wenn es sich um neue Unternehmen handelt, die Vertrauen gewinnen und eine Marke aufbauen müssen. Geschichten vom Rand Das Modell auf das Telefon zu bringen, war mit einer Menge technischer Schwierigkeiten verbunden. Einige davon gibt es heute nicht mehr, die meisten aber schon. Wir waren auf dem neuesten Stand. TensorFlow für Android war gerade erst erschienen – die öffentliche Veröffentlichung war im Februar 2017 und ich habe die App im März entwickelt. Aber mit Ausdauer und viel Hilfe von von TensorFlow haben wir es geschafft, das Modell in der App zum Laufen zu bringen. Pete Warden Das erste Problem bestand darin, das Modell in das APK-Paket zu bekommen. Damals hatte Android ein APK-Limit von 50 MB und eine Erweiterungsfunktion, mit der Apps größer werden konnten, indem Komponenten nach der Installation heruntergeladen wurden. Ich hielt die Erweiterungsfunktion jedoch für unsicher, da sie bedeutete, dass das Modell auf einem Server verfügbar gemacht werden musste. Also entschieden wir uns, die App zu quantisieren – eine Technik, bei der die Genauigkeit aller Ein- und Ausgaben jeder Ebene reduziert wird. In unserem Fall haben wir alle Gleitkommazahlen in Ganzzahlen umgewandelt, was die Größe des Modells erheblich reduzierte und es schneller machte, aber auch die Genauigkeit verringerte. Chris ging mehrere Iterationen des Modells mit unterschiedlichen Quantisierungsschemata durch und entschied sich schließlich trotz der Genauigkeitsreduzierung für die Ganzzahlquantisierung. Dies war nützlich, solange das Modell besser abschnitt als die neuen Eltern. Bonus: Es löste das Update-Problem – das Herunterladen von Hunderten von MB Daten bei jedem Modell-Update war bei getakteten Internetverbindungen eine hohe Anforderung, aber ein paar MB waren zu bewältigen (das erscheint mir jetzt albern, da die Leute heutzutage regelmäßig GBs an Videoinhalten auf ihre Telefone herunterladen). Dann folgte eine lange Reihe kleinerer Probleme. Das größte war, dass die FFT-Bibliotheken, die von den verschiedenen Java-Versionen unterstützt wurden, die mit Android ausgeliefert wurden, nicht dasselbe Spektrogramm erzeugten, mit dem das Modell trainiert wurde. Wir trainierten das Modell mit einer C++-FFT-Bibliothek und es erzeugte Spektrogramme mit unterschiedlichen Farben und Dimensionen. Da es sich um geheime Tools handelte, waren sowohl die C++- als auch die Java-Versionen undurchsichtig geschrieben und schwer zu ändern. Eine weitere schnelle Entscheidung: Wir beschlossen, das Modell mit den Java-FFT-Spektrogrammen neu zu trainieren. Das bedeutete, alle Audiodateien in Spektrogramme umzuwandeln und dann den Trainingsprozess auszuführen, was auf dem alten Macbook meines Freundes Tage dauerte. Aber das Problem war gelöst und ich konnte mich in dieser Zeit auf etwas anderes konzentrieren. Aber die App fror ständig ein und stürzte ab. Es stellte sich heraus, dass es keine gute Idee war, die Aufnahme in den Speicher zu laden und dann das Spektrogramm im Speicher zu erstellen. Die App beanspruchte einen Großteil der Ressourcen des Telefons. Die Lösung bestand darin, auf Festplatte zu speichern und zu streamen. Das Speichern auf Festplatte war einfach; das Streamen war schwierig, denn sobald das Audio den Speicher verlassen hat, kann auf der Festplatte alles Mögliche damit passieren. Ein anderes Programm kann es lesen und ändern; es kann gelöscht werden, das Speichern kann fehlschlagen usw. … Diese Sonderfälle gibt es im Internet normalerweise nicht – Sie haben einen isolierten Kanal mit Ihrem Benutzer, aber nicht auf den Geräten. Sicherzustellen, dass von vornherein genügend Speicherplatz dafür vorhanden war, und nach der App aufzuräumen, war eine unerwartete Herausforderung. Wie ich später herausfand, ist es eine unbegründete Annahme, zu glauben, wenn das Telefon genug Speicher hat, um Ihre App zu installieren, dann hat es auch genug Speicher, um sie auszuführen. Und schließlich war das Gerät selbst ein Gegner – Android-Telefone sind mit einer Vielzahl von CPUs, Speicherkapazitäten und – am wichtigsten – Mikrofonen ausgestattet. Das CPU- und Speicherproblem ließ sich lösen, indem man die erforderliche Android-Version auf die neueste Version einstellte und auf das Beste hoffte; im schlimmsten Fall war die App langsam – es gibt keine Möglichkeit, den Ressourcenbedarf in Android direkt einzustellen. Das eigentliche Problem bestand darin, die unterschiedlichen Eigenschaften von Mikrofonen zu berücksichtigen – Android erlaubt es Ihnen zwar, Mikrofone auf den Geräten, auf denen Ihre App installiert ist, vorzuschreiben, aber nicht den Mikrofontyp. Ich habe nicht versucht, dieses Problem zu lösen. Ich hatte damals viele Testtelefone und bemerkte, wie viel schlechter die Vorhersagen für die billigen Telefone waren. Ich entschied, dass jetzt keine Zeit war, eine Lösung zu finden – wir versuchten, so schnell wie möglich auf den Markt zu kommen. Manchmal besteht die beste Lösung für ein Problem darin, es zu notieren und weiterzumachen. Jetzt ist mir klar, dass dieses Problem uns in die Richtung des Endprodukts gelenkt hat – Homer, ein intelligenter Lautsprecher. Nachdem die technischen Schwierigkeiten überwunden (oder vermieden) waren, wandten wir uns dem schwierigeren Problem der Vorhersagequalität zu. Da das Modell auf der App lief, waren wir blind für seine Leistung. Wenn es schlecht funktionierte, konnten wir das nur anhand von Kommentaren auf der App-Seite oder Deinstallationen feststellen; dann war es aber zu spät. Daher war es von entscheidender Bedeutung, einen Wrapper aus Protokollen, Überwachung, Datenerfassung und Feedback rund um das Modell zu erstellen. Einer oder viele? Das Modell verwendete Spektrogramme und einige andere Informationen, um die Geräusche des Babys zu kategorisieren – hungrig, unwohl, Schmerzen, schläfrig und Blähungen waren die Übersetzungen. Es gab eine Liste aller möglichen Kategorien zurück, wobei jede Kategorie einen Prozentsatz hatte, der angab, wie sicher sich das Modell bei dieser bestimmten Übersetzung war. Alle Prozentsätze ergeben zusammen 100 – wenn die genaueste Übersetzung mit 90 % „hungrig“ wäre, dann hätten die anderen fünf Kategorien Genauigkeiten, die sich auf 10 % summieren. Die Frage, die wir uns schon früh stellten, war, ob wir alle Übersetzungen anzeigen sollten (geordnet von der genauesten bis zur ungenauesten) oder nur eine. Ich entschied mich dafür, nur eine anzuzeigen, weil ich die Leute nicht mit noch mehr Übersetzungen verwirren wollte und weil es einfacher war, dies zu erstellen (Faulheit ist ein Eckpfeiler von Agile). Bei unserer ersten Gruppe von Benutzern traten jedoch Probleme auf. Wenn das Modell sicher war (über 80 %), funktionierte der Vorschlag – wir bekamen keine Beschwerden von Eltern. Aber es war nicht immer so zuverlässig. Wenn die Übersetzungsgenauigkeit unter 80 % lag, war sie so gut wie die Eltern oder ihre Vermutung. Das verfehlt den Zweck der App; sie sollte genauere Übersetzungen bieten als die panischen Versuche frischgebackener Eltern, ihr Kind zu beruhigen. Und das tat sie auch, und nicht überraschend waren die 2. oder 3. Übersetzungen genau richtig. Wir fanden das durch persönliche Interviews heraus – persönliche Interviews sind nicht skalierbar und zeitaufwändig, aber extrem informationsreich; wenn Sie täglich eines machen können, tun Sie es. Das Baby würde weinen und die App würde die falsche Übersetzung mit geringer Sicherheit anzeigen, aber wir würden die anderen Übersetzungen ausprobieren (wir sahen sie in den Protokollen) und sie würden funktionieren. Das kam mir nicht intuitiv vor, weil ich die App als Übersetzer betrachtete. Es sollte doch nur eine Möglichkeit geben, etwas zu übersetzen, oder? Falsch. Die App war ein Erkundungstool für junge Eltern und Betreuer, um herauszufinden, was sie zuerst versuchen sollten. Soll ich versuchen, mein Baby aufstoßen zu lassen? Hat es Hunger? Wann hat es das letzte Mal ein Nickerchen gemacht? Alle Eltern gehen diese Checkliste durch, wenn ihr Baby anfängt zu weinen. Unsere App hat diese Erkundung beschleunigt. So haben die Eltern sie verwendet, und das ist das Feedback, das wir bekamen, nachdem wir mehrere Übersetzungen eingeführt hatten. Das war nicht das Killer-Feature, aber es hat die App definitiv von einer Spielerei in ein Tool für den täglichen Gebrauch verwandelt, einen zuverlässigen Begleiter, wenn der Ehepartner weg ist oder die Großeltern schlafen. Basierend auf diesen Daten entschieden wir uns schnell, mehr Übersetzungen anzuzeigen. Der Trick bestand darin, herauszufinden, wie viele. Die Anzeige aller Übersetzungen – aller fünf Kategorien – ließ die App aussehen, als würde sie jedes Mal dieselben Übersetzungen wiederholen. Was würden Sie denken, wenn Google Ihnen jedes Mal, wenn Sie nach Essen suchen, dieselben vier Restaurants anzeigen würde? Wir entschieden uns für die drei besten Übersetzungen – dies sind teils Kunst und teils Daten. Aus irgendeinem Grund neigen die Leute eher zur Zahl drei. Die Daten zeigten, dass das Vertrauen des Modells in andere Übersetzungen nach der dritten Übersetzung deutlich abnahm. Wenn die erste Übersetzung ein Vertrauen von 70 % hatte, hatte die zweite 20 %, die dritte 9 % und der Rest unter 1 %. Also haben wir diese Übersetzungen weggelassen. Es bestand eine kleine Chance, dass diese weggelassenen Übersetzungen richtig waren, aber ihre Einbeziehung lief Gefahr, dass die App repetitiv wirkte. Die Wahl war, dass 1 von 100 Benutzern Übersetzungen erhalten würde, die alle falsch waren, oder dass alle Benutzer nutzlose Übersetzungen sehen und denken würden, dass die App geraten hätte. Es war eine einfache Entscheidung. Natürlich hätte ich das im Nachhinein mit einem mehrarmigen Banditen testen sollen – fünf verschiedene Versionen der App veröffentlichen, eine für jede Auswahl, z. B. eine Übersetzung anzeigen, zwei anzeigen, drei anzeigen usw., und die Leute langsam auf die Version der App migrieren, die die besten Ergebnisse erzielt hat. Der wichtigste Erfolgsindikator wäre, wie viele Leute das grüne Häkchen angeklickt haben (mit der Übersetzung zufrieden). Aber ich glaube, dass wir in einem so frühen Stadium die richtige Entscheidung getroffen haben, und, was noch wichtiger ist, wir haben die Entscheidung auf die richtige Weise getroffen. Wir waren aufgeschlossen, wir haben keine Entscheidung als konkret betrachtet (kein Ego hier), wir haben uns ständig bei unseren Benutzern erkundigt und ihnen zugehört, auch wenn es sich nicht richtig anfühlte. Lernen am Arbeitsplatz Jede Interaktion ist eine Gelegenheit, sich zu verbessern und Eindruck zu machen. Meine Sorge war von Anfang an, dass das Modell einfach Glück hatte und dass es einen alleinstehenden Vater oder eine alleinstehende Mutter geben würde, denen gesagt wird, ihr Baby weine, weil es Blähungen hat, und die ihr Baby zu Tode rülpsen. Das ist unwahrscheinlich, aber wir fühlten uns für das Wohlergehen des Babys jedes Benutzers verantwortlich. Also verzögerten wir den Start, indem wir der App eine Feedback-Funktion hinzufügten. Nach jeder Übersetzung wurde man gefragt, wie hilfreich sie war – eine nicht überspringbare Seite. Dann lud die App das Benutzerfeedback, die Ausgabe des Modells, den Gerätetyp und das Spektrogramm hoch. Anfangs lud ich die Audiodatei hoch, merkte aber schnell, dass das Mikrofon viele Hintergrundgeräusche aufnahm. Aus Datenschutzgründen haben wir uns entschieden, nur das Spektrogramm hochzuladen. Was ich damals nicht wusste, war, dass man ein Spektrogramm umkehren und das Audio rekonstruieren kann, wenn auch mit schlechterer Qualität und mit einigen Schwierigkeiten. Das war unser Schwungrad. Ich überspringe jedoch die Debatten und zahlreichen Entwürfe, die zu dieser endgültigen Version geführt haben. Es ist schwierig zu entscheiden, welche Daten erhoben werden sollen, wie der Erfolg gemessen und wie Erfolg definiert werden soll, aber es handelt sich um einen iterativen Prozess, den Sie in kleinen Schritten durchführen und verbessern können. Der beste Rat, den ich bekommen habe, war, zu definieren, wie Erfolg aussieht oder, wenn das zu schwierig ist, wie Misserfolg aussieht (für mich ist es viel einfacher, Misserfolg als Erfolg zu definieren – ich weiß nie, was ich will, aber ich bin mir sicher, was ich vermeiden möchte) und konkret zu sein. Leiten Sie aus dieser Antwort die Kennzahlen ab, anhand derer Sie Ihre Bemühungen beurteilen können – wenn Misserfolg darin besteht, Benutzer zu verlieren, bevor ihr Baby zu alt ist, um die App zu verwenden, dann messen Sie die durchschnittliche Lebensdauer der App auf dem Telefon des Benutzers. Aber bedenken Sie, dass diese Definitionen und Kennzahlen nicht statisch sind – sie werden sich ändern. Sie müssen sich nur entscheiden und an ihnen festhalten, bis sie nicht mehr funktionieren. Sie werden nicht mehr funktionieren, wenn Sie aufhören, aus ihnen zu lernen oder zumindest, wenn es schwieriger wird, aus ihnen zu lernen. Das ist das Ziel, zu lernen und sich zu verbessern, der Rest sind Details. Im Zeitalter von KI/ML sind die Daten, die einem Unternehmen anvertraut werden, das wertvollste digitale Gut, nicht das Modell. Die Erweiterung dieser Daten – vorzugsweise auf transparente und ethische Weise – ist für anhaltenden Erfolg von entscheidender Bedeutung. Daher sollte jede Benutzerinteraktion als wertschöpfender Moment betrachtet werden, unabhängig von den Konversionsraten. Daraus folgt, dass jede Interaktion den Benutzer beeindrucken und ihn dazu bringen sollte, wiederzukommen. Wir haben etwas gebaut, das wirklich beeindruckt und inspiriert hat; wir hatten eine großartige Designerin, , die meinen Rohentwurf nahm und ihn zu einer App verfeinerte, die angenehm und angenehm zu verwenden war. Und jede Übersetzung machte die nächste besser. Teresa Ibarra Das Ende Das letzte, was wir gebaut haben, war Homer. Nachdem wir Dutzende von persönlichen Interviews mit App-Benutzern geführt und noch mehr Leute angerufen hatten, wurde uns klar, dass es schwierig und umständlich ist, nach dem Telefon zu suchen, den Bildschirm zu entsperren, unsere App zu finden, sie zu öffnen und auf „Übersetzen“ zu klicken, während man sein weinendes Kind im Arm hält. Warum haben wir so lange gebraucht, um das zu erkennen? Wir waren zwei alleinstehende, kinderlose Jungs in ihren Zwanzigern – ich kann mich nicht erinnern, wann ich das letzte Mal ein Baby im Arm gehalten, geschweige denn sein Weinen beruhigt habe. Also beschlossen wir, ein Babyphone mit einem intelligenten Lautsprecher zu bauen. Ich bestellte ein Kit von Raspberry Pi und baute einen benutzerdefinierten Google Home-Lautsprecher mit einem großen blauen Knopf oben drauf. Chris hatte die großartige Vision, das Modell an Babyphone-Hersteller zu verkaufen, aber wir kamen bei diesen Firmen nicht gut an. Warum also nicht unser eigenes Babyphone mit einem intelligenten Lautsprecher bauen? Nachdem ich Google Home gebaut hatte, erstellte ich ein Bash-Skript, um den Übersetzer beim Start auszuführen. Der Übersetzer verwendete das SDK von Google Home, um auf die Auslösephrase „Okay, Google, übersetze“ zu übersetzen. Der Übersetzer war ein Python-Skript, das Audio von den Mikrofonen las, es in ein Spektrogramm umwandelte und es dann zur Übersetzung an einen Server schickte. Ich hielt die Dinge flexibel und es ! Endlich hatten wir unsere Killer-App, aber sie rettete das Unternehmen nicht. funktionierte Uns ging das Geld aus – das Preisgeld, das wir bei einem Wettbewerb gewonnen hatten. Das Leben ging uns beiden schnell aus dem Kopf. Wir schlossen das College ab und gingen beide nach Hause – ich nahm einen Job in der Bay Area an und Chris ging, um sich um seine kranke Mutter in Texas zu kümmern. Das Startup scheiterte. Startups sind hart und herzzerreißend. Sie können sie nicht in Teilzeit betreiben. Jeder, der einen Anteil hat, muss Vollzeit arbeiten oder gehen, um Platz für jemand anderen zu machen. Oder Sie müssen Ihre Ambitionen zurückschrauben, sie vielleicht sogar ganz aufgeben. Nun, es gibt Probleme da draußen, die man in Teilzeit gewinnbringend lösen kann – aber sind sie lohnenswert? Begeistern sie Sie? Wenn ich etwas gelernt habe – abgesehen davon, wie mühsam es ist, ML-Modelle auf Android bereitzustellen –, dann, dass man sich wirklich für das Problem interessieren muss, das man löst. Man muss den Mut finden, sich trotz der finanziellen Risiken und der enormen Opportunitätskosten vollzeitlich damit zu beschäftigen. Ich würde auf keinen Fall meinen Tech-Job aufgeben, um daran zu arbeiten. Ich liebte es, jungen Eltern und verzweifelten Vätern zu helfen; die Technologie zu lernen und zu entwickeln war aufregend, aber wie sollte ich meinem Vater erklären, warum ich nach meinem Abschluss wieder in unsere beengte Sozialwohnung zog? Wie konnte ich ein sechsstelliges Gehalt ablehnen, nachdem ich so lange von Sozialhilfe gelebt hatte? Und was ist mit Risikokapital? Warum haben Sie nicht versucht, Geld aufzutreiben? Die Realität ist, dass Risikokapitalgeber nur dann zum Telefon greifen, wenn sie Sie, die Schule, die Sie besucht haben, oder das Unternehmen, bei dem Sie gearbeitet haben, kennen. Es ist ihnen egal, was Sie aufgebaut haben – wenn es nicht profitabel ist, ist Ihre Innovation ein nebensächliches Detail – Risikokapitalgeber investieren zuerst in Gründer und Teams und zuletzt in Produkte. Aber die meisten von ihnen wissen nicht, wie man gute Gründer oder Teams auswählt, also überlassen sie das den Zulassungsbeamten an Eliteschulen oder FAANG.