Regeln des maschinellen Lernens:

Best Practices für die ML-Entwicklung

Martin Zinkevich

Dieses Dokument soll Personen mit grundlegenden Kenntnissen im Bereich maschinelles Lernen dabei helfen, die Best Practices von Google für maschinelles Lernen zu nutzen. Er stellt einen Stil für maschinelles Lernen vor, ähnlich dem Google C++ Style Guide und anderen beliebten Leitfäden zur praktischen Programmierung. Wenn Sie einen Kurs zum Thema maschinelles Lernen besucht oder ein Modell für maschinelles Lernen erstellt oder daran gearbeitet haben, haben Sie die notwendigen Grundlagen, um dieses Dokument zu lesen.

Martin Zinkevich stellt 10 seiner Lieblingsregeln für maschinelles Lernen vor. Lies weiter, um alle 43 Regeln zu erfahren.

Terminologie

Die folgenden Begriffe werden in unserer Diskussion über effektives maschinelles Lernen immer wieder auftauchen:

  • Instanz: Das Element, für das Sie eine Vorhersage treffen möchten. Die Instanz kann beispielsweise eine Webseite sein, die Sie als „bezieht sich auf Katzen“ oder „bezieht sich nicht auf Katzen“ klassifizieren möchten.
  • Label: Eine Antwort für eine Vorhersageaufgabe – entweder die Antwort, die von einem System für maschinelles Lernen generiert wurde, oder die richtige Antwort, die in den Trainingsdaten angegeben ist. Das Label für eine Webseite könnte beispielsweise „Informationen zu Katzen“ lauten.
  • Attribut: Ein Attribut einer Instanz, das in einer Vorhersageaufgabe verwendet wird. Eine Webseite könnte beispielsweise die Funktion „enthält das Wort ‚Katze‘“ haben.
  • Feature-Spalte: Eine Reihe ähnlicher Funktionen, z. B. alle Länder, in denen Nutzer leben könnten. Ein Beispiel kann eine oder mehrere Features in einer Featurespalte enthalten. „Attributspalte“ ist eine Google-spezifische Terminologie. Eine Feature-Spalte wird im VW-System (bei Yahoo/Microsoft) als „Namespace“ oder als Feld bezeichnet.
  • Beispiel: Eine Instanz (mit ihren Features) und ein Label.
  • Modell: Eine statistische Darstellung einer Vorhersageaufgabe. Sie trainieren ein Modell anhand von Beispielen und verwenden es dann, um Vorhersagen zu treffen.
  • Messwert: Eine Zahl, die für Sie wichtig ist. Sie werden möglicherweise nicht direkt optimiert.
  • Ziel: Ein Messwert, der mit dem Algorithmus optimiert werden soll.
  • Pipeline: Die Infrastruktur, die einen Algorithmus für maschinelles Lernen umgibt. Dazu gehören das Erfassen der Daten aus dem Front-End, das Einfügen in Trainingsdatendateien, das Trainieren eines oder mehrerer Modelle und das Exportieren der Modelle in die Produktion.
  • Klickrate: Der Prozentsatz der Besucher einer Webseite, die auf einen Link in einer Anzeige klicken.

Übersicht

So entwickeln Sie großartige Produkte:

Machen Sie maschinelles Lernen wie der großartige Entwickler, der Sie sind, und nicht wie der großartige Experte für maschinelles Lernen, der Sie nicht sind.

Die meisten Probleme, mit denen Sie konfrontiert werden, sind in der Tat technische Probleme. Selbst mit allen Ressourcen eines Experten für maschinelles Lernen stammen die meisten Verbesserungen von guten Funktionen, nicht von guten Algorithmen für maschinelles Lernen. Der grundlegende Ansatz ist also:

  1. Achten Sie darauf, dass Ihre Pipeline von Anfang bis Ende solide ist.
  2. Beginnen Sie mit einem vernünftigen Ziel.
  3. Fügen Sie auf einfache Weise sinnvolle Funktionen hinzu.
  4. Sorgen Sie dafür, dass Ihre Pipeline stabil bleibt.

Dieser Ansatz funktioniert über einen langen Zeitraum hinweg gut. Abweichungen von diesem Ansatz sollten Sie nur vornehmen, wenn es keine einfachen Tricks mehr gibt, mit denen Sie weiterkommen. Eine höhere Komplexität verzögert zukünftige Releases.

Wenn Sie die einfachen Tricks ausgeschöpft haben, könnte es sein, dass Sie sich mit moderner KI beschäftigen. Weitere Informationen finden Sie im Abschnitt zu Projekten für maschinelles Lernen in Phase III.

Dieses Dokument ist so aufgebaut:

  1. Der erste Teil sollte Ihnen helfen zu verstehen, ob die Zeit reif ist, ein System für maschinelles Lernen zu entwickeln.
  2. Im zweiten Teil geht es um die Bereitstellung Ihrer ersten Pipeline.
  3. Im dritten Teil geht es um die Einführung und Iteration, während Sie Ihrer Pipeline neue Funktionen hinzufügen, sowie um die Bewertung von Modellen und Abweichungen zwischen Training und Bereitstellung.
  4. Im letzten Teil geht es darum, was du tun kannst, wenn du einen Plateaueffekt erreichst.
  5. Danach folgt eine Liste verwandter Arbeiten und ein Anhang mit einigen Hintergrundinformationen zu den Systemen, die in diesem Dokument häufig als Beispiele verwendet werden.

Vor dem Machine Learning

Regel 1: Haben Sie keine Angst, ein Produkt ohne maschinelles Lernen auf den Markt zu bringen.

Maschinelles Lernen ist toll, erfordert aber Daten. Theoretisch können Sie Daten aus einem anderen Problem verwenden und das Modell dann für ein neues Produkt optimieren. Dies führt jedoch wahrscheinlich zu einer schlechteren Leistung als bei grundlegenden Heuristiken. Wenn Sie glauben, dass Sie mithilfe von Machine Learning eine Steigerung von 100% erzielen können, können Sie mit einer Heuristik 50 % dieses Ziels erreichen.

Wenn Sie beispielsweise Apps in einem App-Shop bewerten, können Sie die Installationsrate oder die Anzahl der Installationen als Heuristik verwenden. Wenn du Spam feststellst, solltest du Publisher herausfiltern, die bereits in der Vergangenheit Spam gesendet haben. Scheuen Sie sich auch nicht, die Bearbeitung durch Menschen in Anspruch zu nehmen. Wenn Sie Kontakte sortieren möchten, ordnen Sie die am häufigsten verwendeten Kontakte an die erste Stelle (oder sortieren Sie sie alphabetisch). Wenn maschinelles Lernen für Ihr Produkt nicht unbedingt erforderlich ist, sollten Sie es erst verwenden, wenn Sie Daten haben.

Regel 2: Messwerte zuerst entwerfen und implementieren

Bevor Sie festlegen, was Ihr System für maschinelles Lernen tun soll, sollten Sie so viele Daten wie möglich in Ihrem aktuellen System erfassen. Das hat folgende Gründe:

  1. Es ist einfacher, die Berechtigung der Nutzer des Systems früher einzuholen.
  2. Wenn Sie glauben, dass es in Zukunft Probleme geben könnte, sollten Sie jetzt Verlaufsdaten abrufen.
  3. Wenn Sie Ihr System mit Blick auf die Messwerte ausstatten, können Sie in Zukunft noch bessere Ergebnisse erzielen. Sie sollten nicht ständig nach Strings in Protokollen suchen müssen, um Ihre Messwerte zu instrumentieren.
  4. Sie werden feststellen, was sich ändert und was gleich bleibt. Angenommen, Sie möchten die Anzahl der Nutzer, die an einem Tag aktiv waren, direkt optimieren. Bei den ersten Manipulationen des Systems stellen Sie jedoch möglicherweise fest, dass sich diese Messwerte auch bei drastischen Änderungen der Nutzerfreundlichkeit kaum ändern.

Das Google Plus-Team misst unter anderem die Anzahl der Aufrufe, der geteilten Beiträge, der „Mag ich“-Bewertungen, der Kommentare, der Kommentare pro Nutzer und der geteilten Beiträge pro Nutzer. Diese Werte werden verwendet, um die Qualität eines Beitrags bei der Auslieferung zu berechnen. Außerdem ist ein Test-Framework wichtig, mit dem Sie Nutzer in Gruppen einteilen und Statistiken nach Test zusammenfassen können. Siehe Regel 12.

Wenn Sie Messwerte großzügiger erheben, erhalten Sie ein umfassenderes Bild Ihres Systems. Haben Sie ein Problem festgestellt? Fügen Sie einen Messwert hinzu, um ihn zu erfassen. Sind Sie von einer quantitativen Änderung in der letzten Version begeistert? Fügen Sie einen Messwert hinzu, um ihn zu erfassen.

Regel 3: Wählen Sie maschinelles Lernen anstelle einer komplexen Heuristik.

Mit einer einfachen Heuristik können Sie Ihr Produkt auf den Markt bringen. Eine komplexe Heuristik ist nicht wartbar. Sobald Sie Daten und eine grundlegende Vorstellung davon haben, was Sie erreichen möchten, können Sie mit dem maschinellen Lernen fortfahren. Wie bei den meisten Aufgaben im Softwareentwicklungsprozess sollten Sie Ihren Ansatz ständig aktualisieren, unabhängig davon, ob es sich um ein heuristisches oder ein maschinell erstelltes Modell handelt. Sie werden feststellen, dass das maschinell erstellte Modell einfacher zu aktualisieren und zu pflegen ist (siehe Regel 16).

ML Phase I: Ihre erste Pipeline

Konzentrieren Sie sich bei Ihrer ersten Pipeline auf Ihre Systeminfrastruktur. Es macht zwar Spaß, über all die kreativen Möglichkeiten des maschinellen Lernens nachzudenken, aber es wird schwierig, herauszufinden, was passiert, wenn Sie Ihrer Pipeline nicht vertrauen.

Regel 4: Halten Sie das erste Modell einfach und achten Sie auf die richtige Infrastruktur.

Das erste Modell bietet den größten Mehrwert für Ihr Produkt. Es muss also nicht besonders schick sein. Sie werden jedoch mit vielen mehr Infrastrukturproblemen konfrontiert sein, als Sie erwarten. Bevor andere Ihr neues, ausgeklügeltes System für maschinelles Lernen verwenden können, müssen Sie Folgendes festlegen:

  • So erhalten Sie Beispiele für Ihren Lernalgorithmus.
  • Eine erste Definition dessen, was „gut“ und „schlecht“ für Ihr System bedeutet.
  • Wie Sie Ihr Modell in Ihre Anwendung einbinden. Sie können das Modell entweder live anwenden oder es offline an Beispielen vorab berechnen und die Ergebnisse in einer Tabelle speichern. So können Sie beispielsweise Webseiten vorab klassifizieren und die Ergebnisse in einer Tabelle speichern, Chatnachrichten aber in Echtzeit klassifizieren.

Wenn Sie einfache Funktionen auswählen, können Sie Folgendes leichter erreichen:

  • Die Funktionen erreichen Ihren Lernalgorithmus korrekt.
  • Das Modell lernt angemessene Gewichte.
  • Die Funktionen erreichen Ihr Modell auf dem Server korrekt.

Sobald Sie ein System haben, das diese drei Dinge zuverlässig erledigt, haben Sie den Großteil der Arbeit erledigt. Ihr einfaches Modell liefert Ihnen Referenzmesswerte und ein Referenzverhalten, mit denen Sie komplexere Modelle testen können. Einige Teams streben einen „neutralen“ ersten Start an: Bei diesem ersten Start werden die Vorteile des maschinellen Lernens ausdrücklich depriorisiert, um Ablenkungen zu vermeiden.

Regel 5: Testen Sie die Infrastruktur unabhängig vom Machine Learning.

Achten Sie darauf, dass die Infrastruktur testbar ist und dass die Lernteile des Systems gekapselt sind, damit Sie alles um sie herum testen können. Im Detail:

  1. Testen Sie, ob Daten in den Algorithmus gelangen. Prüfen Sie, ob die zu füllenden Attributspalten ausgefüllt sind. Prüfen Sie die Eingabe für Ihren Trainingsalgorithmus manuell, sofern dies datenschutzrechtlich zulässig ist. Vergleichen Sie nach Möglichkeit die Statistiken in Ihrer Pipeline mit den Statistiken für dieselben Daten, die an anderer Stelle verarbeitet werden.
  2. Testen Sie, ob Sie Modelle aus dem Trainingsalgorithmus abrufen können. Das Modell in Ihrer Trainingsumgebung muss dieselbe Bewertung wie das Modell in Ihrer Bereitstellungsumgebung liefern (siehe Regel 37).

Da maschinelles Lernen nicht immer vorhersehbar ist, sollten Sie Tests für den Code zum Erstellen von Beispielen beim Training und Bereitstellen durchführen und ein festes Modell während der Bereitstellung laden und verwenden können. Außerdem ist es wichtig, Ihre Daten zu verstehen. Weitere Informationen finden Sie unter Praktische Tipps zur Analyse großer, komplexer Datensätze.

Regel 6: Achten Sie beim Kopieren von Pipelines auf verlorene Daten.

Oft erstellen wir eine Pipeline, indem wir eine vorhandene Pipeline kopieren (Cargo-Cult-Programmierung). Die alte Pipeline verwirft dann Daten, die wir für die neue Pipeline benötigen. In der Pipeline für „Angesagt“ von Google Plus werden beispielsweise ältere Beiträge entfernt, da neue Beiträge besser bewertet werden sollen. Diese Pipeline wurde kopiert, um sie für den Google Plus-Stream zu verwenden, in dem ältere Beiträge noch relevant sind. Die Pipeline ließ jedoch weiterhin alte Beiträge aus. Ein weiteres häufig verwendetes Muster besteht darin, nur Daten zu erfassen, die der Nutzer gesehen hat. Diese Daten sind also nutzlos, wenn wir modellieren möchten, warum ein bestimmter Beitrag nicht vom Nutzer gesehen wurde, da alle negativen Beispiele entfernt wurden. Ein ähnliches Problem trat bei Google Play auf. Bei der Arbeit an der Startseite von Google Play Apps wurde eine neue Pipeline erstellt, die auch Beispiele von der Landingpage von Google Play Spiele enthielt, ohne dass es eine Funktion gab, die Aufschluss darüber gab, woher die einzelnen Beispiele stammten.

Regel 7: Heuristiken in Funktionen umwandeln oder extern verarbeiten

Normalerweise sind die Probleme, die mithilfe von maschinellem Lernen gelöst werden sollen, nicht völlig neu. Es gibt ein bestehendes System zum Bewerten, Klassifizieren oder Lösen des Problems, das Sie lösen möchten. Das bedeutet, dass es eine Reihe von Regeln und Heuristiken gibt. Diese Heuristiken können Ihnen einen Schub geben, wenn sie mithilfe von maschinellem Lernen optimiert werden. Aus zwei Gründen sollten Sie Ihre Heuristiken nach allen verfügbaren Informationen durchsuchen. Erstens: Die Umstellung auf ein KI-gestütztes System verläuft reibungsloser. Zweitens enthalten diese Regeln in der Regel viel Intuition über das System, die Sie nicht wegwerfen möchten. Es gibt vier Möglichkeiten, eine vorhandene Heuristik zu verwenden:

  • Vorverarbeitung mit der Heuristik Wenn die Funktion unglaublich cool ist, ist das eine Option. Wenn der Absender beispielsweise in einem Spamfilter bereits auf die schwarze Liste gesetzt wurde, sollten Sie nicht versuchen, herauszufinden, was „auf die schwarze Liste setzen“ bedeutet. Blockieren Sie die Nachricht. Dieser Ansatz macht am meisten Sinn bei binären Klassifizierungsaufgaben.
  • Erstellen Sie ein Element. Es ist großartig, direkt ein Feature aus der Heuristik zu erstellen. Wenn Sie beispielsweise mithilfe einer Heuristik einen Relevanzwert für ein Suchergebnis berechnen, können Sie diesen Wert als Wert eines Features angeben. Später können Sie den Wert mithilfe von Verfahren des maschinellen Lernens bearbeiten, z. B. in einen von einer endlichen Reihe diskreter Werte umwandeln oder mit anderen Funktionen kombinieren. Verwenden Sie aber zuerst den Rohwert, der von der Heuristik generiert wurde.
  • Die Roheingaben der Heuristik auswerten. Wenn es eine Heuristik für Apps gibt, die die Anzahl der Installationen, die Anzahl der Zeichen im Text und den Wochentag kombiniert, sollten Sie diese Teile voneinander trennen und diese Eingaben separat in das Lernen einfließen lassen. Einige Techniken, die für Ensembles gelten, können auch hier angewendet werden (siehe Regel 40).
  • Bearbeiten Sie das Label. Diese Option ist sinnvoll, wenn Sie der Meinung sind, dass die Heuristik Informationen erfasst, die derzeit nicht im Label enthalten sind. Wenn Sie beispielsweise die Anzahl der Downloads maximieren, aber auch hochwertige Inhalte anbieten möchten, können Sie das Label mit der durchschnittlichen Anzahl der Sterne multiplizieren, die die App erhalten hat. Hier gibt es viel Spielraum. Weitere Informationen finden Sie unter „Ihr erstes Ziel“.

Beachten Sie jedoch die zusätzliche Komplexität, die durch die Verwendung von Heuristiken in einem ML-System entsteht. Die Verwendung alter Heuristiken in Ihrem neuen Algorithmus für maschinelles Lernen kann zu einer reibungslosen Umstellung beitragen. Überlegen Sie jedoch, ob es eine einfachere Möglichkeit gibt, denselben Effekt zu erzielen.

Monitoring

Achten Sie im Allgemeinen auf eine gute Benachrichtigungshygiene, z. B. indem Sie Benachrichtigungen umsetzbare Aktionen enthalten und eine Dashboardseite haben.

Regel 8: Die Aktualitätsanforderungen Ihres Systems kennen

Wie stark verschlechtert sich die Leistung, wenn ein Modell einen Tag alt ist? Eine Woche alt? Ein Vierteljahr alt? Anhand dieser Informationen können Sie die Prioritäten Ihrer Überwachung besser nachvollziehen. Wenn die Produktqualität erheblich sinkt, wenn das Modell einen Tag lang nicht aktualisiert wird, ist es sinnvoll, einen Entwickler zu beauftragen, das Modell kontinuierlich zu beobachten. Die meisten Anzeigenbereitstellungssysteme müssen täglich neue Anzeigen verarbeiten und daher täglich aktualisiert werden. Wenn das ML-Modell für die Google Play-Suche beispielsweise nicht aktualisiert wird, kann sich das innerhalb weniger Wochen negativ auswirken. Einige Modelle für „Angesagt“ in Google Plus haben keine Beitrags-ID im Modell. Daher können diese Modelle nur selten exportiert werden. Andere Modelle mit Beitrags-IDs werden viel häufiger aktualisiert. Beachten Sie auch, dass sich die Aktualität im Laufe der Zeit ändern kann, insbesondere wenn Ihrem Modell Featurespalten hinzugefügt oder daraus entfernt werden.

Regel 9: Probleme vor dem Exportieren von Modellen erkennen

Viele Systeme für maschinelles Lernen haben eine Phase, in der das Modell für die Bereitstellung exportiert wird. Wenn ein Problem mit einem exportierten Modell auftritt, ist es ein Problem für die Nutzer.

Führen Sie kurz vor dem Export des Modells Plausibilitätstests durch. Achten Sie insbesondere darauf, dass die Leistung des Modells bei den nicht verwendeten Daten akzeptabel ist. Wenn Sie Bedenken bezüglich der Daten haben, exportieren Sie kein Modell. Viele Teams, die Modelle kontinuierlich bereitstellen, prüfen vor dem Exportieren den Bereich unter der ROC-Kurve (AUC). Probleme mit Modellen, die nicht exportiert wurden, erfordern eine E-Mail-Benachrichtigung. Probleme mit einem nutzerorientierten Modell erfordern möglicherweise eine Seite. Daher ist es besser, zu warten und sich zu vergewissern, bevor Sie Änderungen für Nutzer vornehmen.

Regel 10: Achten Sie auf stumme Fehler.

Dieses Problem tritt häufiger bei Systemen für maschinelles Lernen als bei anderen Systemen auf. Angenommen, eine bestimmte Tabelle, die zusammengeführt wird, wird nicht mehr aktualisiert. Das maschinelle Lernsystem passt sich an und das Verhalten bleibt weiterhin relativ gut, wobei es nach und nach abnimmt. Manchmal finden Sie Tabellen, die seit Monaten nicht aktualisiert wurden. Eine einfache Aktualisierung verbessert die Leistung mehr als jede andere Einführung im Quartal. Die Abdeckung eines Features kann sich aufgrund von Implementierungsänderungen ändern: Beispielsweise könnte eine Feature-Spalte in 90% der Beispiele ausgefüllt sein und plötzlich auf 60% der Beispiele sinken. Bei Google Play gab es einmal eine Tabelle, die sechs Monate lang nicht aktualisiert wurde. Allein durch die Aktualisierung der Tabelle konnte die Installationsrate um 2% gesteigert werden. Wenn Sie Statistiken zu den Daten erfassen und die Daten gelegentlich manuell prüfen, können Sie diese Art von Fehlern reduzieren.

Regel 11: Weisen Sie Feature-Spalten Eigentümer und Dokumentation zu.

Wenn das System groß ist und viele Feature-Spalten vorhanden sind, sollten Sie wissen, wer jede Feature-Spalte erstellt oder verwaltet. Wenn die Person, die sich mit einer Feature-Spalte auskennt, das Unternehmen verlässt, sollten Sie dafür sorgen, dass jemand anderes die Informationen hat. Viele Feature-Spalten haben zwar beschreibende Namen, es ist aber hilfreich, eine detailliertere Beschreibung zu haben, was das Feature ist, woher es stammt und wie es voraussichtlich helfen wird.

Ihr erstes Ziel

Sie haben viele Messwerte oder Messungen zum System, die für Sie wichtig sind, aber Ihr Algorithmus für maschinelles Lernen benötigt oft ein einzelnes Ziel, eine Zahl, die der Algorithmus zu optimieren versucht. Ich unterscheide hier zwischen Zielen und Messwerten: Ein Messwert ist eine Zahl, die von Ihrem System erfasst wird und die wichtig sein kann oder auch nicht. Siehe auch Regel 2.

Regel 12: Überlegen Sie nicht zu lange, welches Zielvorhaben Sie direkt optimieren möchten.

Sie möchten Geld verdienen, Ihre Nutzer glücklich machen und die Welt zu einem besseren Ort machen. Es gibt viele Messwerte, die für Sie wichtig sind, und Sie sollten sie alle erfassen (siehe Regel 2). Zu Beginn des Machine-Learning-Prozesses steigen jedoch alle, auch diejenigen, die Sie nicht direkt optimieren. Angenommen, Sie möchten die Anzahl der Klicks und die auf der Website verbrachte Zeit erfassen. Wenn Sie die Anzahl der Klicks optimieren, steigt die Verweildauer wahrscheinlich.

Halten Sie es also einfach und machen Sie sich nicht zu viele Gedanken über das Gleichgewicht verschiedener Messwerte, wenn Sie alle Messwerte ganz einfach steigern können. Gehen Sie mit dieser Regel jedoch nicht zu weit: Verwechseln Sie Ihr Ziel nicht mit der endgültigen Gesundheit des Systems (siehe Regel 39). Wenn Sie den direkt optimierten Messwert steigern, die Einführung aber nicht starten möchten, ist möglicherweise eine objektive Überarbeitung erforderlich.

Regel 13: Wählen Sie für Ihr erstes Zielvorhaben einen einfachen, beobachtbaren und zurechenbaren Messwert aus.

Oft wissen Sie nicht, was das eigentliche Ziel ist. Sie denken, dass Sie es wissen, aber wenn Sie sich die Daten ansehen und Ihr altes System mit dem neuen ML-System vergleichen, stellen Sie fest, dass Sie das Ziel anpassen möchten. Außerdem können sich die einzelnen Teammitglieder oft nicht auf das eigentliche Ziel einigen. Das ML-Zielvorhaben sollte leicht messbar sein und als Proxy für das „wahre“ Zielvorhaben dienen. Tatsächlich gibt es oft kein „echtes“ Ziel (siehe Regel 39). Trainieren Sie also mit dem einfachen ML-Ziel und überlegen Sie, ob Sie eine „Richtlinienebene“ hinzufügen möchten, mit der Sie zusätzliche Logik (hoffentlich sehr einfache Logik) für die endgültige Sortierung hinzufügen können.

Am einfachsten lässt sich ein Nutzerverhalten modellieren, das direkt beobachtet und einer Aktion des Systems zugeordnet werden kann:

  • Wurde auf diesen Link geklickt?
  • Wurde dieses Objekt heruntergeladen?
  • Wurde dieses Objekt weitergeleitet, wurde darauf geantwortet oder wurde es per E-Mail gesendet?
  • Wurde dieses Objekt bewertet?
  • Wurde das angezeigte Objekt als Spam/Pornografie/anstößig markiert?

Vermeiden Sie es, indirekte Effekte zu modellieren:

  • Hat der Nutzer die Website am nächsten Tag besucht?
  • Wie lange hat der Nutzer die Website besucht?
  • Wie viele aktive Nutzer pro Tag waren es?

Indirekte Effekte sind gute Messwerte und können bei A/B-Tests und bei der Einführung von Produkten verwendet werden.

Versuchen Sie außerdem nicht, mithilfe von maschinellem Lernen Folgendes zu ermitteln:

  • Sind die Nutzer mit der Nutzung des Produkts zufrieden?
  • Ist der Nutzer mit der Erfahrung zufrieden?
  • Verbessert das Produkt das allgemeine Wohlbefinden der Nutzer?
  • Welche Auswirkungen hat das auf die Gesamtgesundheit des Unternehmens?

All diese Faktoren sind wichtig, aber auch unglaublich schwer zu messen. Verwenden Sie stattdessen Proxys: Wenn der Nutzer zufrieden ist, bleibt er länger auf der Website. Wenn der Nutzer zufrieden ist, wird er morgen wiederkommen. Was das Wohlbefinden und die Gesundheit des Unternehmens angeht, ist menschliches Urteilsvermögen erforderlich, um jedes mithilfe von maschinellem Lernen ermittelte Ziel mit der Art des von Ihnen verkauften Produkts und Ihrem Geschäftsplan in Verbindung zu bringen.

Regel 14: Mit einem interpretierbaren Modell zu beginnen, erleichtert das Debuggen.

Lineare Regression, logistische Regression und Poisson-Regression basieren direkt auf einem probabilistischen Modell. Jede Vorhersage kann als Wahrscheinlichkeit oder als Erwartungswert interpretiert werden. Dies macht sie einfacher zu debuggen als Modelle, die Zielvorhaben (Null-Eins-Verlust, verschiedene Scharnierverluste usw.) verwenden, mit denen die Klassifizierungsgenauigkeit oder die Rankingleistung direkt optimiert werden soll. Wenn sich die Wahrscheinlichkeiten beim Training beispielsweise von den Wahrscheinlichkeiten unterscheiden, die in direkten Vergleichen oder bei der Prüfung des Produktionssystems vorhergesagt wurden, könnte diese Abweichung ein Problem aufzeigen.

Bei der linearen, logistischen oder Poisson-Regression gibt es Teilmengen der Daten, bei denen die durchschnittliche prognostizierte Erwartung dem durchschnittlichen Label entspricht (1-Moment-Kalibrierung oder nur Kalibrierung). Das gilt unter der Annahme, dass Sie keine Regularisierung verwenden und Ihr Algorithmus konvergiert ist. Im Allgemeinen ist es ungefähr richtig. Wenn ein Feature für jedes Beispiel entweder „1“ oder „0“ ist, wird die Gruppe von drei Beispielen, bei denen dieses Feature „1“ ist, kalibriert. Wenn ein Feature für jedes Beispiel den Wert 1 hat, wird auch der gesamte Satz der Beispiele kalibriert.

Bei einfachen Modellen ist es einfacher, mit Feedbackschleifen umzugehen (siehe Regel 36). Oft nutzen wir diese probabilistischen Vorhersagen, um eine Entscheidung zu treffen, z.B. Beiträge nach abnehmendem erwartetem Wert zu sortieren (d.h. Wahrscheinlichkeit für Klicks/Downloads usw.). Denken Sie jedoch daran, dass bei der Auswahl des Modells die Entscheidung wichtiger ist als die Wahrscheinlichkeit der Daten unter Berücksichtigung des Modells (siehe Regel 27).

Regel 15: Spamfilterung und Qualitätsrangfolge in einer Richtlinienebene trennen.

Die Qualität zu bewerten ist eine Kunst, aber Spam zu filtern ist ein Krieg. Die Signale, die Sie zur Bestimmung hochwertiger Beiträge verwenden, werden für die Nutzer Ihres Systems offensichtlich und sie passen ihre Beiträge entsprechend an. Daher sollten Sie sich beim Qualitätsranking darauf konzentrieren, Inhalte zu bewerten, die in gutem Glauben gepostet wurden. Sie sollten den Qualitätsrang-Lernalgorithmus nicht als unzuverlässig einstufen, wenn er Spam hoch einordnet. Ähnlich sollten „anstößige“ Inhalte getrennt vom Qualitätsranking behandelt werden. Beim Spamfiltern sieht es anders aus. Sie müssen damit rechnen, dass sich die Funktionen, die Sie generieren müssen, ständig ändern. Oft gibt es offensichtliche Regeln, die Sie in das System einbinden (z. B. „Wenn ein Beitrag mehr als drei Spam-Abstimmungen hat, darf er nicht abgerufen werden“). Jedes gelernte Modell muss täglich, wenn nicht sogar schneller, aktualisiert werden. Der Ruf des Erstellers der Inhalte spielt eine große Rolle.

Die Ausgabe dieser beiden Systeme muss auf einer bestimmten Ebene integriert werden. Denken Sie daran, dass Spam in den Suchergebnissen wahrscheinlich strenger gefiltert werden sollte als Spam in E-Mails. Außerdem wird in der Regel Spam aus den Trainingsdaten für den Qualitätsklassifizierer entfernt.

ML-Phase II: Feature Engineering

In der ersten Phase des Lebenszyklus eines Systems für maschinelles Lernen geht es darum, die Trainingsdaten in das Lernsystem einzufügen, alle relevanten Messwerte zu erfassen und eine Bereitstellungsinfrastruktur zu erstellen. Nachdem Sie ein funktionierendes End-to-End-System mit Einheiten- und Systemtests haben, beginnt Phase II.

In der zweiten Phase gibt es viele einfache Lösungen. Es gibt eine Vielzahl von offensichtlichen Funktionen, die in das System einfließen könnten. In der zweiten Phase des maschinellen Lernens werden also so viele Funktionen wie möglich herangezogen und auf intuitive Weise kombiniert. In dieser Phase sollten alle Messwerte weiter steigen. Es wird viele Einführungen geben und es ist eine gute Zeit, viele Entwickler hinzuzuziehen, die alle Daten zusammenführen können, die Sie für ein wirklich hervorragendes Lernsystem benötigen.

Regel 16: Planen Sie die Einführung und Iteration.

Es ist nicht wahrscheinlich, dass das Modell, an dem Sie gerade arbeiten, das letzte ist, das Sie veröffentlichen, oder dass Sie irgendwann keine Modelle mehr veröffentlichen werden. Überlegen Sie daher, ob die Komplexität, die Sie mit dieser Einführung hinzufügen, zukünftige Einführungen verlangsamt. Viele Teams haben seit Jahren mindestens ein Modell pro Quartal eingeführt. Es gibt drei grundlegende Gründe, neue Modelle einzuführen:

  • Sie entwickeln neue Funktionen.
  • Sie optimieren die Regularisierung und kombinieren alte Funktionen auf neue Weise.
  • Sie optimieren das Zielvorhaben.

Trotzdem kann es sinnvoll sein, sich ein wenig Zeit für ein Modell zu nehmen: Wenn Sie sich die Daten ansehen, die in das Beispiel einfließen, können Sie neue Signale sowie alte, fehlerhafte Signale finden. Überlegen Sie beim Erstellen Ihres Modells also, wie einfach es ist, Funktionen hinzuzufügen oder zu entfernen oder neu zu kombinieren. Überlegen Sie, wie einfach es ist, eine neue Kopie der Pipeline zu erstellen und ihre Richtigkeit zu überprüfen. Überlegen Sie, ob zwei oder drei Kopien parallel ausgeführt werden können. Und machen Sie sich keine Sorgen, ob Feature 16 von 35 in diese Version der Pipeline aufgenommen wird. Sie erhalten sie im nächsten Quartal.

Regel 17: Beginnen Sie mit direkt beobachteten und gemeldeten Funktionen, anstatt mit gelernten Funktionen.

Das mag zwar ein kontroverser Punkt sein, aber so lassen sich viele Fallstricke vermeiden. Zuerst wollen wir beschreiben, was ein gelerntes Merkmal ist. Ein gelerntes Merkmal ist ein Merkmal, das entweder von einem externen System (z. B. einem nicht überwachten Clustering-System) oder vom Lernenden selbst (z. B. über ein faktorielles Modell oder Deep Learning) generiert wird. Beides kann nützlich sein, kann aber auch viele Probleme verursachen. Daher sollten sie nicht im ersten Modell enthalten sein.

Wenn Sie ein externes System zum Erstellen einer Funktion verwenden, denken Sie daran, dass dieses System ein eigenes Ziel hat. Das Ziel des externen Systems ist möglicherweise nur schwach mit Ihrem aktuellen Ziel korreliert. Wenn Sie einen Snapshot des externen Systems erstellen, kann er schnell veraltet sein. Wenn Sie die Funktionen aus dem externen System aktualisieren, können sich die Bedeutungen ändern. Wenn Sie ein externes System zur Bereitstellung einer Funktion verwenden, ist Vorsicht geboten.

Das Hauptproblem bei faktorisierten Modellen und Deep-Learning-Modellen ist, dass sie nicht konvex sind. Es gibt also keine Garantie dafür, dass eine optimale Lösung angenähert oder gefunden werden kann, und die in jeder Iteration gefundenen lokalen Minima können unterschiedlich sein. Diese Schwankungen erschweren es, zu beurteilen, ob die Auswirkungen einer Änderung an Ihrem System signifikant oder zufällig sind. Wenn Sie ein Modell ohne Deep-Learning-Features erstellen, können Sie eine hervorragende Ausgangsleistung erzielen. Nachdem Sie diese Baseline erreicht haben, können Sie esoterischere Ansätze ausprobieren.

Regel 18: Experimentieren Sie mit Inhaltselementen, die sich über verschiedene Kontexte hinweg verallgemeinern lassen.

Oft ist ein Machine-Learning-System nur ein kleiner Teil eines viel größeren Ganzen. Wenn du dir beispielsweise einen Beitrag vorstellst, der in „Angesagt“ verwendet werden könnte, werden viele Nutzer dem Beitrag „Mag ich“ geben, ihn noch einmal teilen oder kommentieren, bevor er in „Angesagt“ angezeigt wird. Wenn Sie diese Statistiken dem Lernenden zur Verfügung stellen, kann er neue Beiträge bewerben, für die es im optimierten Kontext keine Daten gibt. Für die Funktion „Empfohlene Videos“ auf YouTube können die Anzahl der Aufrufe oder die Anzahl der gemeinsamen Wiedergaben (Anzahl der Aufrufe eines Videos nach dem Aufruf eines anderen Videos) aus der YouTube-Suche verwendet werden. Sie können auch explizite Nutzerbewertungen verwenden. Wenn Sie eine Nutzeraktion als Label verwenden, kann es sehr hilfreich sein, diese Aktion im Dokument in einem anderen Kontext zu sehen. Mit all diesen Funktionen können Sie neue Inhalte in einen Kontext stellen. Dabei geht es nicht um Personalisierung: Finde zuerst heraus, ob einem Nutzer die Inhalte in diesem Kontext gefallen, und dann, wem sie mehr oder weniger gefallen.

Regel 19: Verwenden Sie nach Möglichkeit sehr spezifische Funktionen.

Bei einer großen Menge an Daten ist es einfacher, Millionen einfacher Funktionen zu lernen als nur wenige komplexe Funktionen. IDs der abgerufenen Dokumente und kanonische Abfragen bieten nicht viel Generalisierung, aber Sie können das Ranking mit Ihren Labels für Hauptabfragen abgleichen. Haben Sie also keine Angst vor Gruppen von Funktionen, bei denen jede Funktion auf einen sehr kleinen Teil Ihrer Daten zutrifft, die Gesamtabdeckung aber über 90 % liegt. Mithilfe der Regularisierung können Sie Merkmale entfernen, die auf zu wenige Beispiele zutreffen.

Regel 20: Kombinieren und ändern Sie vorhandene Funktionen, um neue Funktionen auf verständliche Weise zu erstellen.

Es gibt verschiedene Möglichkeiten, Funktionen zu kombinieren und zu ändern. Mithilfe von Systemen für maschinelles Lernen wie TensorFlow können Sie Ihre Daten durch Transformationen vorverarbeiten. Die beiden gängigsten Ansätze sind „Discretizations“ (Diskretisierungen) und „Crosses“ (Kreuzungen).

Bei der Diskretisierung wird ein kontinuierliches Merkmal in viele diskrete Merkmale unterteilt. Denken Sie an eine kontinuierliche Funktion wie das Alter. Sie können eine Funktion erstellen, die den Wert „1“ hat, wenn das Alter unter 18 Jahren liegt, eine andere Funktion, die den Wert „1“ hat, wenn das Alter zwischen 18 und 35 Jahren liegt, usw. Überlegen Sie sich nicht zu viel über die Grenzen dieser Histogramme: Mit einfachen Quantilen erzielen Sie die besten Ergebnisse.

In Kreuzen werden zwei oder mehr Featurespalten kombiniert. Eine Merkmalspalte ist in der TensorFlow-Terminologie eine Gruppe homogener Merkmale (z. B. {male, female}, {US, Canada, Mexico} usw.). Eine Kreuzung ist eine neue Merkmalspalte mit Merkmalen wie {männlich, weiblich} × {USA, Kanada, Mexiko}. Diese neue Feature-Spalte enthält das Feature (männlich, Kanada). Wenn Sie TensorFlow verwenden und TensorFlow auffordern, diese Kreuzung für Sie zu erstellen, ist diese Funktion (männlich, Kanada) in Beispielen für männliche Kanadier enthalten. Für das Training von Modellen mit Kreuzen aus drei, vier oder mehr Basismesswerten sind enorme Datenmengen erforderlich.

Kreuzungen, die sehr große Feature-Spalten erzeugen, können zu einer Überanpassung führen. Angenommen, Sie führen eine Suche durch und haben eine Featurespalte mit Wörtern in der Abfrage und eine Featurespalte mit Wörtern im Dokument. Sie können diese mit einem Kreuz kombinieren, aber das führt zu vielen Elementen (siehe Regel 21).

Bei der Arbeit mit Text gibt es zwei Möglichkeiten. Die drakonischste ist die Punktproduktmethode. Bei einer Skalarprodukt-Berechnung in ihrer einfachsten Form wird einfach die Anzahl der Wörter gezählt, die der Suchanfrage und dem Dokument gemeinsam sind. Diese Funktion kann dann diskretisiert werden. Ein weiterer Ansatz ist die Schnittmenge: So haben wir eine Funktion, die nur dann vorhanden ist, wenn das Wort „Pferd“ sowohl im Dokument als auch in der Suchanfrage enthalten ist, und eine weitere Funktion, die nur dann vorhanden ist, wenn das Wort „das“ sowohl im Dokument als auch in der Suchanfrage enthalten ist.

Regel 21: Die Anzahl der Merkmalsgewichte, die Sie in einem linearen Modell lernen können, ist ungefähr proportional zur Datenmenge, die Sie haben.

Es gibt faszinierende Ergebnisse aus der statistischen Lerntheorie zur angemessenen Komplexität eines Modells, aber diese Regel ist im Grunde alles, was Sie wissen müssen. Ich habe Gespräche geführt, in denen Menschen bezweifelten, dass man aus tausend Beispielen etwas lernen kann oder dass man jemals mehr als eine Million Beispiele benötigen würde, weil sie an einer bestimmten Lernmethode festhängen. Der Schlüssel besteht darin, die Lerninhalte an die Größe Ihrer Daten anzupassen:

  1. Wenn Sie an einem Suchranking-System arbeiten und es in den Dokumenten und der Suchanfrage Millionen verschiedener Wörter gibt und Sie 1.000 beschriftete Beispiele haben, sollten Sie eine Punktprodukt-Berechnung zwischen Dokument- und Suchanfragemerkmalen, TF-IDF und ein halbes Dutzend anderer stark von Menschen entwickelter Merkmale verwenden. 1.000 Beispiele, ein Dutzend Funktionen.
  2. Wenn Sie eine Million Beispiele haben, schneiden Sie die Dokument- und Abfragespalte mithilfe von Regularisierung und gegebenenfalls Feature-Auswahl übereinander. So erhalten Sie Millionen von Funktionen, bei der Regularisierung sind es jedoch weniger. Zehn Millionen Beispiele, vielleicht hunderttausend Funktionen.
  3. Wenn Sie Milliarden oder Hunderte von Milliarden von Beispielen haben, können Sie die Feature-Spalten mit Dokument- und Abfragetokens kreuzen, indem Sie die Feature-Auswahl und die Regularisierung verwenden. Sie haben eine Milliarde Beispiele und 10 Millionen Merkmale. Die statistische Lerntheorie liefert selten enge Grenzen, ist aber ein guter Ausgangspunkt.

Am Ende entscheiden Sie anhand von Regel 28, welche Funktionen Sie verwenden möchten.

Regel 22: Bereinigen Sie Funktionen, die Sie nicht mehr verwenden.

Nicht verwendete Funktionen führen zu technischen Altlasten. Wenn Sie feststellen, dass Sie eine Funktion nicht verwenden und die Kombination mit anderen Funktionen nicht funktioniert, entfernen Sie sie aus Ihrer Infrastruktur. Sie sollten Ihre Infrastruktur möglichst schlank halten, damit die vielversprechendsten Funktionen so schnell wie möglich getestet werden können. Bei Bedarf kann die Funktion jederzeit wieder hinzugefügt werden.

Berücksichtigen Sie die Abdeckung, wenn Sie überlegen, welche Funktionen Sie hinzufügen oder beibehalten möchten. Wie viele Beispiele werden durch die Funktion abgedeckt? Wenn Sie beispielsweise einige Personalisierungsfunktionen haben, diese aber nur für 8% Ihrer Nutzer verfügbar sind, ist das nicht sehr effektiv.

Gleichzeitig können einige Funktionen mehr leisten, als sie auf den ersten Blick erscheinen. Wenn ein Feature beispielsweise nur 1% der Daten abdeckt, aber 90% der Beispiele mit dem Feature positiv sind, ist es eine gute Idee, es hinzuzufügen.

Menschliche Analyse des Systems

Bevor wir mit der dritten Phase des maschinellen Lernens fortfahren, ist es wichtig, sich auf etwas zu konzentrieren, das in keinem Kurs zum maschinellen Lernen gelehrt wird: wie man sich ein vorhandenes Modell ansieht und es verbessert. Dies ist mehr eine Kunst als eine Wissenschaft. Dennoch gibt es mehrere Antimuster, die Sie damit vermeiden können.

Regel 23: Sie sind kein typischer Endnutzer.

Das ist vielleicht die einfachste Art, wie ein Team ins Stocken geraten kann. Fishfooding (Verwendung eines Prototyps innerhalb des Teams) und Dogfooding (Verwendung eines Prototyps innerhalb des Unternehmens) bieten zwar viele Vorteile, aber die Mitarbeiter sollten prüfen, ob die Leistung stimmt. Eine offensichtlich schlechte Änderung sollte nicht verwendet werden. Alles, was in etwa der Produktion entspricht, sollte weiter getestet werden, entweder indem Laien bezahlt werden, um Fragen auf einer Crowdsourcing-Plattform zu beantworten, oder durch einen Live-Test mit echten Nutzern.

Dafür gibt es zwei Gründe. Erstens: Sie sind zu nah am Code. Vielleicht suchen Sie nach einem bestimmten Aspekt der Beiträge oder Sie sind einfach zu emotional involviert (z.B. Bestätigungsfehler). Zweitens: Ihre Zeit ist zu wertvoll. Denken Sie an die Kosten für neun Entwickler, die an einem einstündigen Meeting teilnehmen, und an die Anzahl der beauftragten menschlichen Labels, die Sie auf einer Crowdsourcing-Plattform kaufen.

Wenn Sie wirklich Feedback von Nutzern erhalten möchten, verwenden Sie Methoden zur Nutzererfahrung. Erstellen Sie früh im Prozess User Personas (eine Beschreibung finden Sie in Bill Buxtons Buch Sketching User Experiences) und führen Sie später Usability-Tests durch (eine Beschreibung finden Sie in Steve Krugs Buch Don’t Make Me Think). Bei User Personas wird ein hypothetischer Nutzer erstellt. Wenn Ihr Team beispielsweise nur aus Männern besteht, kann es hilfreich sein, eine 35-jährige weibliche User Persona (komplett mit Nutzermerkmalen) zu entwerfen und sich die Ergebnisse anzusehen, die sie generiert, anstatt 10 Ergebnisse für 25- bis 40-jährige Männer. Wenn Sie echte Nutzer in Usability-Tests einbeziehen und ihre Reaktion auf Ihre Website beobachten (lokal oder aus der Ferne), können Sie auch eine neue Perspektive gewinnen.

Regel 24: Delta zwischen den Modellen messen

Eine der einfachsten und manchmal nützlichsten Messungen, die Sie vornehmen können, bevor sich Nutzer Ihr neues Modell angesehen haben, ist die Berechnung, wie stark sich die neuen Ergebnisse von denen in der Produktion unterscheiden. Wenn Sie beispielsweise ein Rankingproblem haben, führen Sie beide Modelle für eine Stichprobe von Suchanfragen im gesamten System aus und sehen Sie sich die Größe der symmetrischen Differenz der Ergebnisse an (gewichtet nach der Rankingposition). Wenn der Unterschied sehr gering ist, können Sie ohne Test feststellen, dass es kaum eine Änderung geben wird. Wenn der Unterschied sehr groß ist, sollten Sie sich vergewissern, dass die Änderung sinnvoll ist. Wenn Sie sich Suchanfragen ansehen, bei denen der symmetrische Unterschied hoch ist, können Sie qualitativ nachvollziehen, wie die Änderung ausgefallen ist. Achten Sie jedoch darauf, dass das System stabil ist. Achten Sie darauf, dass ein Modell im Vergleich zu sich selbst einen niedrigen (idealerweise null) symmetrischen Unterschied aufweist.

Regel 25: Bei der Auswahl von Modellen ist die utilitaristische Leistung wichtiger als die Vorhersagekraft.

Ihr Modell kann versuchen, die Klickrate vorherzusagen. Die entscheidende Frage ist jedoch, was Sie mit dieser Vorhersage tun. Wenn Sie sie zum Sortieren von Dokumenten verwenden, ist die Qualität des Endergebnisses wichtiger als die Vorhersage selbst. Wenn Sie die Wahrscheinlichkeit vorhersagen, dass ein Dokument Spam ist, und dann einen Grenzwert für das Blockieren festlegen, ist die Genauigkeit der zugelassenen Elemente wichtiger. In den meisten Fällen sollten diese beiden Dinge übereinstimmen. Wenn das nicht der Fall ist, ist der Gewinn wahrscheinlich gering. Wenn also eine Änderung den Log-Verlust verringert, aber die Leistung des Systems beeinträchtigt, sollten Sie nach einer anderen Funktion suchen. Wenn das häufiger vorkommt, sollten Sie das Ziel Ihres Modells noch einmal überdenken.

Regel 26: Suchen Sie nach Mustern in den gemessenen Fehlern und erstellen Sie neue Funktionen.

Angenommen, Sie sehen ein Trainingsbeispiel, das das Modell als „falsch“ eingestuft hat. Bei einer Klassifizierungsaufgabe kann dieser Fehler ein falsch positives oder ein falsch negatives Ergebnis sein. Bei einer Rangierungsaufgabe könnte der Fehler ein Paar sein, bei dem ein positives Beispiel niedriger als ein negatives Beispiel eingestuft wurde. Der wichtigste Punkt ist, dass dies ein Beispiel dafür ist, dass das System für maschinelles Lernen weiß, dass es einen Fehler gemacht hat, und diesen bei Gelegenheit korrigieren möchte. Wenn Sie dem Modell eine Funktion geben, mit der es den Fehler beheben kann, versucht es, diese zu verwenden.

Wenn Sie hingegen versuchen, eine Funktion anhand von Beispielen zu erstellen, die das System nicht als Fehler erkennt, wird die Funktion ignoriert. Angenommen, ein Nutzer sucht in der Play Store App-Suche nach „kostenlose Spiele“. Angenommen, eines der Top-Ergebnisse ist eine weniger relevante App mit einem Scherzartikel. Sie erstellen also eine Funktion für „Apps mit Scherzartikeln“. Wenn Sie jedoch die Anzahl der Installationen maximieren und Nutzer eine Scherz-App installieren, wenn sie nach kostenlosen Spielen suchen, hat die Funktion „Scherz-Apps“ nicht die gewünschte Wirkung.

Sobald Sie Beispiele haben, die das Modell falsch erkannt hat, suchen Sie nach Trends, die nicht zu Ihrem aktuellen Funktionsumfang gehören. Wenn das System beispielsweise längere Beiträge zu unterdrücken scheint, fügen Sie die Beitragslänge hinzu. Seien Sie nicht zu spezifisch bei den hinzugefügten Funktionen. Wenn Sie die Länge von Beiträgen hinzufügen möchten, versuchen Sie nicht, zu erraten, was „lang“ bedeutet. Fügen Sie einfach ein Dutzend Funktionen hinzu und lassen Sie das Modell herausfinden, was es damit tun soll (siehe Regel 21). Das ist der einfachste Weg, um das gewünschte Ergebnis zu erzielen.

Regel 27: Versuchen Sie, beobachtetes unerwünschtes Verhalten zu quantifizieren.

Einige Mitglieder Ihres Teams werden mit Eigenschaften des Systems unzufrieden, die ihnen nicht gefallen und die von der vorhandenen Verlustfunktion nicht erfasst werden. An diesem Punkt sollte er alles tun, um seine Kritik in harte Zahlen umzuwandeln. Wenn sie beispielsweise der Meinung sind, dass in der Play Suche zu viele „Scherz-Apps“ angezeigt werden, können sie menschliche Prüfer damit beauftragen, diese zu identifizieren. In diesem Fall können Sie problemlos von Menschen beschriftete Daten verwenden, da ein relativ kleiner Teil der Suchanfragen einen großen Teil des Traffics ausmacht. Wenn Ihre Probleme messbar sind, können Sie sie als Funktionen, Ziele oder Messwerte verwenden. Die allgemeine Regel lautet: Zuerst messen, dann optimieren.

Regel 28: Identisches kurzfristiges Verhalten bedeutet nicht, dass das Verhalten auch langfristig identisch ist.

Angenommen, Sie haben ein neues System, das sich jede doc_id und exact_query ansieht und dann die Klickwahrscheinlichkeit für jedes Dokument für jede Suchanfrage berechnet. Sie stellen fest, dass das Verhalten sowohl in direkten Vergleichen als auch in A/B-Tests nahezu identisch mit dem Ihres aktuellen Systems ist. Aufgrund der Einfachheit führen Sie es ein. Sie stellen jedoch fest, dass keine neuen Apps angezeigt werden. Warum? Da Ihr System nur ein Dokument basierend auf seinem eigenen Verlauf mit dieser Suchanfrage anzeigt, gibt es keine Möglichkeit zu erfahren, dass ein neues Dokument angezeigt werden sollte.

Die einzige Möglichkeit, die langfristige Funktionsweise eines solchen Systems zu verstehen, besteht darin, es nur mit Daten zu trainieren, die erfasst wurden, als das Modell live war. Das ist sehr schwierig.

Abweichungen zwischen Training und Bereitstellung

Abweichungen zwischen Training und Bereitstellung sind Unterschiede zwischen der Leistung während des Trainings und der Leistung während der Bereitstellung. Mögliche Ursachen:

  • Eine Abweichung zwischen der Verarbeitung von Daten in der Trainings- und der Bereitstellungspipeline.
  • Eine Änderung der Daten zwischen dem Training und der Bereitstellung.
  • Eine Feedbackschleife zwischen Ihrem Modell und Ihrem Algorithmus.

Wir haben bei Produktionssystemen für maschinelles Lernen bei Google Abweichungen bei der Bereitstellung von Trainingsdaten festgestellt, die sich negativ auf die Leistung auswirken. Die beste Lösung besteht darin, die Daten explizit zu überwachen, damit System- und Datenänderungen nicht unbemerkt zu Abweichungen führen.

Regel 29: Am besten sorgen Sie dafür, dass Sie so trainieren, wie Sie bereitstellen. Speichern Sie dazu die bei der Bereitstellung verwendeten Features und leiten Sie sie dann an ein Protokoll weiter, um sie beim Training zu verwenden.

Auch wenn Sie dies nicht für jedes Beispiel tun können, sollten Sie es für einen kleinen Teil tun, damit Sie die Konsistenz zwischen Auslieferung und Training überprüfen können (siehe Regel 37). Teams, die diese Messung bei Google durchgeführt haben, waren manchmal von den Ergebnissen überrascht. Auf der Startseite von YouTube wurden Logging-Funktionen zur Auslieferungszeit eingeführt, was zu erheblichen Qualitätsverbesserungen und einer Verringerung der Codekomplexität geführt hat. Viele Teams sind gerade dabei, ihre Infrastruktur umzustellen.

Regel 30: Stichprobendaten nach Wichtigkeit gewichten, nicht willkürlich ausschließen

Wenn Sie zu viele Daten haben, besteht die Versuchung, die Dateien 1–12 zu verwenden und die Dateien 13–99 zu ignorieren. Und genau das ist das Problem. Daten, die dem Nutzer nie angezeigt wurden, können entfernt werden. Für den Rest ist die Gewichtung nach Wichtigkeit am besten. Wenn Sie beispielsweise Beispiel X mit einer Wahrscheinlichkeit von 30% auswählen möchten, geben Sie ihm eine Gewichtung von 10/3. Bei der Gewichtung der Wichtigkeit gelten weiterhin alle in Regel 14 beschriebenen Eigenschaften der Kalibrierung.

Regel 31: Wenn Sie Daten aus einer Tabelle beim Training und bei der Bereitstellung zusammenführen, können sich die Daten in der Tabelle ändern.

Angenommen, Sie möchten Dokument-IDs mit einer Tabelle mit Funktionen für diese Dokumente zusammenführen, z. B. die Anzahl der Kommentare oder Klicks. Zwischen Training und Bereitstellung können sich die Features in der Tabelle ändern. Die Vorhersage Ihres Modells für dasselbe Dokument kann sich dann zwischen Training und Bereitstellung unterscheiden. Am einfachsten lässt sich dieses Problem vermeiden, indem Sie Funktionen zum Zeitpunkt der Auslieferung erfassen (siehe Regel 32). Wenn sich die Tabelle nur langsam ändert, können Sie auch stündlich oder täglich einen Snapshot der Tabelle erstellen, um relativ genaue Daten zu erhalten. Das Problem wird dadurch aber nicht vollständig behoben.

Regel 32: Verwenden Sie nach Möglichkeit Code zwischen Ihrer Trainingspipeline und Ihrer Bereitstellungspipeline wieder.

Die Batchverarbeitung unterscheidet sich von der Onlineverarbeitung. Bei der Onlineverarbeitung müssen Sie jede Anfrage bearbeiten, sobald sie eingeht (z. B. für jede Abfrage eine separate Suche durchführen). Bei der Batchverarbeitung können Sie Aufgaben kombinieren (z. B. eine Zusammenführung vornehmen). Bei der Bereitstellung erfolgt eine Onlineverarbeitung, während das Training eine Batchverarbeitung ist. Es gibt jedoch einige Möglichkeiten, Code wiederzuverwenden. Sie können beispielsweise ein Objekt erstellen, das speziell für Ihr System bestimmt ist, in dem das Ergebnis von Abfragen oder Zusammenführungen auf eine sehr visuell lesbare Weise gespeichert werden kann und Fehler leicht getestet werden können. Sobald Sie alle Informationen erfasst haben, führen Sie beim Bereitstellen oder Trainieren eine gängige Methode aus, um eine Brücke zwischen dem für Ihr System spezifischen visuell lesbaren Objekt und dem Format zu schlagen, das das System für maschinelles Lernen erwartet. So wird eine Quelle für Abweichungen zwischen Training und Bereitstellung eliminiert. Verwenden Sie daher für Training und Bereitstellung möglichst dieselbe Programmiersprache. Diese Entscheidung macht es Ihnen nahezu unmöglich, Code zu teilen.

Regel 33: Wenn Sie ein Modell auf der Grundlage der Daten bis zum 5. Januar erstellen, testen Sie es anhand der Daten vom 6. Januar und danach.

Im Allgemeinen sollten Sie die Leistung eines Modells anhand der Daten messen, die nach den Daten erfasst wurden, mit denen Sie das Modell trainiert haben. So lässt sich besser nachvollziehen, wie Ihr System in der Produktion abschneidet. Wenn Sie ein Modell auf der Grundlage der Daten bis zum 5. Januar erstellen, testen Sie es anhand der Daten vom 6. Januar. Die Leistung sollte mit den neuen Daten zwar nicht so gut sein, aber nicht wesentlich schlechter. Da es tägliche Auswirkungen geben kann, können Sie die durchschnittliche Klick- oder Conversion-Rate möglicherweise nicht vorhersagen. Der Bereich unter der Kurve, der die Wahrscheinlichkeit darstellt, dass dem positiven Beispiel eine höhere Bewertung als dem negativen Beispiel gegeben wird, sollte jedoch in etwa übereinstimmen.

Regel 34: Bei der binären Klassifizierung für das Filtern (z. B. Spamerkennung oder Identifizierung interessanter E-Mails) sollten Sie kurzfristige Leistungseinbußen in Kauf nehmen, um sehr saubere Daten zu erhalten.

Bei einer Filteraufgabe werden dem Nutzer keine Beispiele angezeigt, die als negativ gekennzeichnet sind. Angenommen, Sie haben einen Filter, der beim Bereitstellen 75% der negativen Beispiele blockiert. Sie könnten versucht sein, zusätzliche Trainingsdaten aus den Nutzern angezeigten Instanzen zu ziehen. Wenn ein Nutzer beispielsweise eine E-Mail als Spam markiert, die Ihr Filter durchgelassen hat, sollten Sie das berücksichtigen.

Dieser Ansatz führt jedoch zu Stichprobenverzerrungen. Sie können sauberere Daten erheben, wenn Sie stattdessen beim Ausliefern 1% des gesamten Traffics als „ausgeblendet“ kennzeichnen und alle ausgeblendeten Beispiele an den Nutzer senden. Jetzt werden mit Ihrem Filter mindestens 74% der negativen Beispiele blockiert. Diese zurückgehaltenen Beispiele können Ihre Trainingsdaten werden.

Wenn Ihr Filter mindestens 95% der negativen Beispiele blockiert, ist dieser Ansatz weniger geeignet. Wenn Sie die Auslieferungsleistung dennoch messen möchten, können Sie eine noch kleinere Stichprobe verwenden (z.B.0,1% oder 0,001%). Zehntausend Beispiele reichen aus, um die Leistung ziemlich genau zu schätzen.

Regel 35: Achten Sie auf die inhärente Verzerrung bei Ranking-Problemen.

Wenn Sie Ihren Ranking-Algorithmus so radikal ändern, dass andere Ergebnisse angezeigt werden, haben Sie effektiv die Daten geändert, die Ihr Algorithmus in Zukunft sehen wird. Diese Art von Abweichung wird auftreten und Sie sollten Ihr Modell entsprechend gestalten. Es gibt mehrere Ansätze. Mit diesen Ansätzen können Sie Daten bevorzugen, die Ihrem Modell bereits bekannt sind.

  1. Die Funktion „Regelmäßigkeit“ wird bei Funktionen, die mehr Abfragen abdecken, stärker angewendet als bei Funktionen, die nur für eine Abfrage aktiviert sind. So werden im Modell eher Merkmale bevorzugt, die für eine oder wenige Suchanfragen spezifisch sind, als Merkmale, die auf alle Suchanfragen generalisiert werden. So lässt sich verhindern, dass sehr beliebte Ergebnisse in irrelevante Suchanfragen einfließen. Dies steht im Gegensatz zum gängigen Ratschlag, Merkmalsspalten mit mehr eindeutigen Werten stärker zu regulieren.
  2. Nur positive Gewichte für Elemente zulassen Daher ist jedes gute Merkmal besser als ein Merkmal, das als „unbekannt“ eingestuft wird.
  3. Sie haben keine Funktionen, die nur für Dokumente verfügbar sind. Dies ist eine extreme Version von Punkt 1. Auch wenn eine bestimmte App unabhängig von der Suchanfrage ein beliebter Download ist, sollten Sie sie nicht überall präsentieren. Da es keine Funktionen gibt, die nur für Dokumente gelten, ist das ganz einfach. Der Grund, warum Sie eine bestimmte beliebte App nicht überall schalten möchten, hat damit zu tun, dass alle gewünschten Apps erreichbar sein müssen. Wenn ein Nutzer beispielsweise nach „App für Vogelbeobachtung“ sucht, lädt er möglicherweise „Angry Birds“ herunter, obwohl das nicht seine Absicht war. Die Präsentation einer solchen App kann die Downloadrate verbessern, die Anforderungen der Nutzer werden jedoch letztendlich nicht erfüllt.

Regel 36: Vermeiden Sie Feedbackschleifen mit Positionselementen.

Die Position von Inhalten wirkt sich stark darauf aus, wie wahrscheinlich es ist, dass Nutzer damit interagieren. Wenn Sie eine App an die erste Position setzen, wird sie häufiger angeklickt. Sie sind dann davon überzeugt, dass sie mit größerer Wahrscheinlichkeit angeklickt wird. Eine Möglichkeit, dies zu beheben, besteht darin, Positionsmerkmale hinzuzufügen, d.h. Merkmale zur Position der Inhalte auf der Seite. Sie trainieren Ihr Modell mit Positionsmerkmalen und es lernt, beispielsweise das Merkmal „1. Position“ stark zu gewichten. Daher werden anderen Faktoren für Beispiele mit „1st_position=true“ im Modell weniger Gewicht beigemessen. Bei der Auslieferung weisen Sie dann keiner Instanz das Positionsfeature zu oder Sie weisen ihnen alle dieselbe Standardfunktion zu, da Sie Kandidaten bewerten, bevor Sie sich für die Reihenfolge ihrer Präsentation entschieden haben.

Aufgrund dieser Asymmetrie zwischen Training und Testen ist es wichtig, alle Positionsmerkmale etwas vom Rest des Modells zu trennen. Idealerweise ist das Modell die Summe einer Funktion der Positionsmerkmale und einer Funktion der übrigen Merkmale. Überschneiden Sie beispielsweise die Positionierungselemente nicht mit Dokumentelementen.

Regel 37: Abweichungen zwischen Training und Bereitstellung messen

Es gibt mehrere Dinge, die im weitesten Sinne zu einer Verzerrung führen können. Außerdem können Sie sie in mehrere Teile unterteilen:

  • Der Unterschied zwischen der Leistung auf den Trainingsdaten und den Hold-out-Daten. Im Allgemeinen wird es immer Unstimmigkeiten geben und das ist nicht immer schlecht.
  • Der Unterschied zwischen der Leistung der Kontrolldaten und der Leistung der Daten vom nächsten Tag. Das wird immer der Fall sein. Sie sollten die Regularisierung so anpassen, dass die Leistung am nächsten Tag maximiert wird. Große Leistungseinbrüche zwischen den Daten des Hold-out-Prozentsatzes und den Daten des nächsten Tages können jedoch darauf hinweisen, dass einige Funktionen zeitkritisch sind und die Modellleistung möglicherweise beeinträchtigen.
  • Die Differenz zwischen der Leistung der Daten vom „nächsten Tag“ und der Leistung der Live-Daten. Wenn Sie ein Modell auf ein Beispiel in den Trainingsdaten und dasselbe Beispiel bei der Bereitstellung anwenden, sollte das genau dasselbe Ergebnis liefern (siehe Regel 5). Eine Abweichung hier ist daher wahrscheinlich ein technischer Fehler.

ML-Phase III: Verlangsamtes Wachstum, Optimierungsverbesserung und komplexe Modelle

Es gibt bestimmte Anzeichen dafür, dass die zweite Phase zu Ende geht. Zuerst werden Ihre monatlichen Einnahmen sinken. Sie werden feststellen, dass sich die Messwerte gegenseitig beeinflussen: In einigen Tests steigen einige Messwerte, andere sinken. Jetzt wird es interessant. Da die Verbesserungen schwieriger zu erzielen sind, muss das maschinelle Lernen immer ausgefeilter werden. Ein wichtiger Hinweis: Dieser Abschnitt enthält mehr Regeln für Visionen als die vorherigen Abschnitte. Wir haben viele Teams durch die glücklichen Phasen I und II des maschinellen Lernens begleitet. Sobald Phase III erreicht ist, müssen die Teams ihren eigenen Weg finden.

Regel 38: Verschwenden Sie keine Zeit mit neuen Funktionen, wenn nicht übereinstimmende Zielvorhaben das Problem sind.

Wenn die Messwerte stagnieren, wird sich Ihr Team mit Problemen befassen, die nicht in den Zuständigkeitsbereich Ihres aktuellen Systems für maschinelles Lernen fallen. Wie bereits erwähnt, müssen Sie entweder Ihr Ziel oder Ihre Produktziele ändern, wenn die Produktziele nicht durch das vorhandene algorithmische Ziel abgedeckt werden. Sie können beispielsweise Klicks, „Mag ich“-Bewertungen oder Downloads optimieren, aber Entscheidungen zur Einführung teilweise auf Grundlage von Bewertungen durch Menschen treffen.

Regel 39: Entscheidungen zur Markteinführung sind ein Maßstab für langfristige Produktziele.

Alice hat eine Idee, wie sich die logistischen Verluste bei der Vorhersage von Installationen reduzieren lassen. Sie fügt eine Funktion hinzu. Der logistische Verlust sinkt. Bei einem Livetest stellt sie fest, dass sich die Installationsrate erhöht. Bei einer Besprechung zur Produktveröffentlichung wird jedoch darauf hingewiesen, dass die Anzahl der aktiven Nutzer pro Tag um 5 % gesunken ist. Das Team entscheidet, das Modell nicht einzuführen. Alice ist enttäuscht, erkennt aber jetzt, dass Einführungsentscheidungen von mehreren Kriterien abhängen, von denen nur einige direkt mithilfe von ML optimiert werden können.

Die Realität ist, dass die reale Welt kein Computerspiel ist: Es gibt keine „Höhepunkte“, anhand derer sich der Zustand Ihres Produkts bestimmen lässt. Das Team muss anhand der erfassten Statistiken versuchen, effektiv vorherzusagen, wie gut das System in Zukunft sein wird. Sie müssen sich um das Engagement, aktive Nutzer pro Tag (DAU), aktive Nutzer in den letzten 30 Tagen, den Umsatz und den Return on Investment des Werbetreibenden kümmern. Diese in A/B-Tests messbaren Messwerte sind nur ein Indikator für langfristigere Ziele: zufriedene Nutzer, mehr Nutzer, zufriedene Partner und Gewinn. Diese können auch als Indikatoren für ein nützliches, hochwertiges Produkt und ein erfolgreiches Unternehmen in fünf Jahren betrachtet werden.

Einfache Entscheidungen zur Einführung sind nur dann möglich, wenn sich alle Messwerte verbessern (oder zumindest nicht verschlechtern). Wenn das Team die Wahl zwischen einem ausgefeilten Algorithmus für maschinelles Lernen und einer einfachen Heuristik hat und die einfache Heuristik bei allen diesen Messwerten besser abschneidet, sollte es sich für die Heuristik entscheiden. Außerdem gibt es keine explizite Rangfolge aller möglichen Messwertwerte. Betrachten Sie insbesondere die folgenden beiden Szenarien:

Test Täglich aktive Nutzer Umsatz pro Tag
A 1 Million 4 Millionen $
B 2 Millionen 2 Millionen $

Wenn das aktuelle System A ist, wird das Team wahrscheinlich nicht zu B wechseln. Wenn das aktuelle System B ist, wird das Team wahrscheinlich nicht zu A wechseln. Das scheint im Widerspruch zu rationalem Verhalten zu stehen. Allerdings können sich Prognosen zu sich ändernden Messwerten bewahrheiten oder nicht. Daher ist mit jeder Änderung ein großes Risiko verbunden. Jeder Messwert deckt ein Risiko ab, das das Team beunruhigt.

Außerdem deckt kein Messwert die letztendliche Frage des Teams ab: „Wo steht mein Produkt in fünf Jahren?“

Einzelpersonen bevorzugen dagegen in der Regel ein Ziel, das sie direkt optimieren können. Die meisten Tools für maschinelles Lernen bevorzugen eine solche Umgebung. Ein Entwickler, der neue Funktionen entwickelt, kann in einer solchen Umgebung einen stetigen Strom von Einführungen erzielen. Es gibt eine Art des maschinellen Lernens, das sogenannte mehrstufige Lernen, mit dem dieses Problem angegangen wird. So kann beispielsweise ein Problem zur Erfüllung von Einschränkungen formuliert werden, das untere Grenzwerte für jeden Messwert hat und eine lineare Kombination von Messwerten optimiert. Aber selbst dann lassen sich nicht alle Messwerte leicht als Ziele für die maschinelle Lerntechnologie formulieren: Wenn auf ein Dokument geklickt oder eine App installiert wird, liegt das daran, dass die Inhalte präsentiert wurden. Es ist jedoch viel schwieriger herauszufinden, warum ein Nutzer Ihre Website besucht. Der zukünftige Erfolg einer Website als Ganzes ist KI-komplett: so schwierig wie maschinelles Sehen oder die Verarbeitung natürlicher Sprache.

Regel 40: Halten Sie Ensembles einfach.

Unified-Modelle, die Rohmerkmale aufnehmen und Inhalte direkt bewerten, sind die Modelle, die sich am einfachsten debuggen und nachvollziehen lassen. Ein Ensemble von Modellen (ein „Modell“, das die Bewertungen anderer Modelle kombiniert) kann jedoch besser funktionieren. Für eine einfache Handhabung sollte jedes Modell entweder ein Ensemble sein, das nur die Eingabe anderer Modelle berücksichtigt, oder ein Basismodell, das viele Funktionen berücksichtigt. Beides ist nicht möglich. Wenn Sie Modelle auf anderen Modellen haben, die separat trainiert werden, kann die Kombination zu Fehlverhalten führen.

Verwenden Sie für das Ensemble ein einfaches Modell, das nur die Ausgabe Ihrer „Basismodelle“ als Eingaben verwendet. Außerdem möchten Sie für diese Ensemblemodelle Eigenschaften erzwingen. Eine Erhöhung der Bewertung durch ein Basismodell sollte beispielsweise nicht zu einer niedrigeren Bewertung des Ensembles führen. Außerdem sollten die eingehenden Modelle semantisch interpretierbar (z. B. kalibriert) sein, damit Änderungen an den zugrunde liegenden Modellen das Ensemblemodell nicht verfälschen. Außerdem sollte eine Erhöhung der prognostizierten Wahrscheinlichkeit eines zugrunde liegenden Klassifikators nicht zu einer Verringerung der prognostizierten Wahrscheinlichkeit des Ensembles führen.

Regel 41: Wenn die Leistung stagniert, sollten Sie nach qualitativ neuen Informationsquellen suchen, anstatt vorhandene Signale zu optimieren.

Sie haben demografische Informationen zum Nutzer hinzugefügt. Sie haben einige Informationen zu den Wörtern im Dokument hinzugefügt. Sie haben die explorative Datenanalyse mit der Vorlage durchgeführt und die Regularisierung angepasst. In den letzten Quartalen gab es keine Einführung, bei der die wichtigsten Messwerte um mehr als 1% gestiegen sind. Was heißt das für die Zukunft?

Es ist an der Zeit, die Infrastruktur für radikal andere Funktionen zu erstellen, z. B. den Verlauf der Dokumente, auf die dieser Nutzer in den letzten 24 Stunden, der letzten Woche oder dem letzten Jahr zugegriffen hat, oder Daten aus einer anderen Property. Verwenden Sie wikidata-Entitäten oder etwas Internes für Ihr Unternehmen, z. B. die Knowledge Graph von Google. Deep Learning verwenden Passen Sie Ihre Erwartungen an den erwarteten Return on Investment an und steigern Sie Ihre Bemühungen entsprechend. Wie bei jedem Engineering-Projekt müssen Sie den Nutzen neuer Funktionen gegen die Kosten der erhöhten Komplexität abwägen.

Regel 42: Vielfalt, Personalisierung oder Relevanz sind nicht so eng mit der Beliebtheit von Inhalten verknüpft, wie Sie vielleicht denken.

Vielfalt in einer Reihe von Inhalten kann viele Dinge bedeuten. Die Vielfalt der Quelle der Inhalte ist eine der häufigsten. Bei der Personalisierung erhält jeder Nutzer eigene Ergebnisse. Die Relevanz bedeutet, dass die Ergebnisse für eine bestimmte Suchanfrage besser geeignet sind als alle anderen. Alle drei Eigenschaften werden also als anders als gewöhnlich definiert.

Das Problem ist, dass das Gewöhnliche in der Regel schwer zu schlagen ist.

Wenn Ihr System Klicks, verbrachte Zeit, Aufrufe, „Mag ich“-Bewertungen, geteilte Inhalte usw. misst, wird die Beliebtheit der Inhalte gemessen. Manchmal versuchen Teams, ein persönliches Modell mit Vielfalt zu lernen. Zur Personalisierung fügt er Funktionen hinzu, die es dem System ermöglichen würden, die Ergebnisse zu personalisieren (einige Funktionen, die das Interesse des Nutzers widerspiegeln) oder zu diversifizieren (Funktionen, die angeben, ob dieses Dokument gemeinsame Merkmale mit anderen zurückgegebenen Dokumenten hat, z. B. Autor oder Inhalt). Er stellt fest, dass diese Funktionen weniger Gewicht (oder manchmal ein anderes Vorzeichen) erhalten, als er erwartet.

Das bedeutet nicht, dass Vielfalt, Personalisierung oder Relevanz nicht wertvoll sind. Wie bereits in der vorherigen Regel erwähnt, können Sie mithilfe der Nachbearbeitung die Vielfalt oder Relevanz erhöhen. Wenn Sie feststellen, dass sich die langfristigen Ziele verbessern, können Sie festhalten, dass Vielfalt und Relevanz neben der Beliebtheit ebenfalls wichtig sind. Sie können die Nachbearbeitung dann entweder weiter verwenden oder das Zielvorhaben direkt anhand von Vielfalt oder Relevanz ändern.

Regel 43: Ihre Freunde sind in der Regel bei verschiedenen Produkten dieselben. Ihre Interessen sind es in der Regel nicht.

Teams bei Google haben große Erfolge erzielt, indem sie ein Modell zur Vorhersage der Nähe einer Verbindung in einem Produkt verwendet haben, das auch in einem anderen gut funktioniert hat. Deine Freunde sind, wer sie sind. Andererseits habe ich beobachtet, wie mehrere Teams mit Personalisierungsfunktionen in verschiedenen Produktbereichen zu kämpfen hatten. Ja, es sollte funktionieren. Im Moment sieht es nicht so aus. Manchmal hat es sich bewährt, Rohdaten aus einer Property zu verwenden, um das Verhalten in einer anderen Property vorherzusagen. Denken Sie auch daran, dass es hilfreich sein kann, zu wissen, dass ein Nutzer bereits in einer anderen Property aktiv war. So kann beispielsweise die Nutzeraktivität bei zwei Produkten ein Indiz für eine mögliche Verbindung sein.

Es gibt viele Dokumente zu maschinellem Lernen, sowohl bei Google als auch extern.

Danksagungen

Vielen Dank an David Westbrook, Peter Brandt, Samuel Ieong, Chenyu Zhao, Li Wei, Michalis Potamias, Evan Rosen, Barry Rosenberg, Christine Robson, James Pine, Tal Shaked, Tushar Chandra, Mustafa Ispir, Jeremiah Harmsen, Konstantinos Katsiapis, Glen Anderson, Dan Duckworth, Shishir Birmiwal, Gal Elidan, Su Lin Wu, Jaihui Liu, Fernando Pereira und Hrishikesh Aradhye für viele Korrekturen, Vorschläge und hilfreiche Beispiele für dieses Dokument. Außerdem möchte ich mich bei Kristen Lefevre, Suddha Basu und Chris Berg bedanken, die an einer früheren Version mitgewirkt haben. Für Fehler, Auslassungen oder (oh Schreck!) unpopuläre Meinungen bin ich selbst verantwortlich.

Anhang

In diesem Dokument werden verschiedene Google-Produkte erwähnt. Im Folgenden finden Sie eine kurze Beschreibung der häufigsten Beispiele.

YouTube im Überblick

YouTube ist ein Streamingdienst für Videos. Sowohl die YouTube-Teams für „Nächstes Video“ als auch für die YouTube-Startseite nutzen ML-Modelle, um Videoempfehlungen zu bewerten. Unter „Als Nächstes ansehen“ werden Videos empfohlen, die du dir nach dem aktuell wiedergegebenen ansehen kannst. Auf der Startseite werden Nutzern Videos empfohlen, die sie sich ansehen können.

Google Play – Übersicht

Google Play bietet viele Modelle, mit denen eine Vielzahl von Problemen gelöst werden kann. Für die Play-Suche, die personalisierten Empfehlungen auf der Play-Startseite und die Apps unter „Von Nutzern auch installiert“ wird maschinelles Lernen eingesetzt.

Google Plus – Übersicht

Bei Google Plus wurde maschinelles Lernen in einer Vielzahl von Situationen eingesetzt: zum Sortieren von Beiträgen im „Stream“ der Beiträge, die Nutzer sehen, zum Sortieren von Beiträgen in „Angesagt“ (aktuell sehr beliebte Beiträge) und zum Sortieren von Personen, die Sie kennen. Google+ hat 2019 alle privaten Konten geschlossen und wurde am 6. Juli 2020 durch Google Currents für Unternehmenskonten ersetzt.