Regeln des maschinellen Lernens:

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Best Practices für Machine Learning

Martin Zinkevich

Dieses Dokument richtet sich an Nutzer mit Grundkenntnissen des maschinellen Lernens, damit diese von den Best Practices von Google für maschinelles Lernen profitieren. Sie bietet einen Stil für maschinelles Lernen, der dem Google C++ Style Guide und anderen beliebten Leitfäden für die praktische Programmierung ähnelt. Wenn Sie einen Kurs im Bereich des maschinellen Lernens absolviert oder ein maschinell erlerntes Modell erstellt oder bearbeitet haben, verfügen Sie über die erforderlichen Informationen zum Lesen dieses Dokuments.

Martin Zinkevich stellt 10 Lieblingsregeln des maschinellen Lernens vor. Lesen Sie weiter, um alle 43 Regeln kennenzulernen.

Terminologie

In unserer Diskussion über effektives maschinelles Lernen werden die folgenden Begriffe wiederholt verwendet:

  • Instanz: Die Sache, für die Sie eine Vorhersage treffen möchten. Die Instanz kann beispielsweise eine Webseite sein, die Sie entweder als „über Katzen“ oder „nicht über Katzen“ klassifizieren möchten.
  • Label: Eine Antwort auf eine Vorhersageaufgabe, die entweder von einem ML-System oder die in den Trainingsdaten bereitgestellte richtige Antwort ist. Das Label für eine Webseite könnte beispielsweise „über Katzen“ lauten.
  • Feature: Ein Attribut einer Instanz, das in einer Vorhersageaufgabe verwendet wird. Eine Webseite könnte beispielsweise das Feature „enthält das Wort „Katze““ haben.
  • Featurespalte: Eine Reihe von zugehörigen Merkmalen, z. B. alle Länder, in denen Nutzer leben dürfen. Ein Beispiel kann eine oder mehrere Features in einer Featurespalte enthalten. Die „Funktionsspalte“ ist eine Google-spezifische Terminologie. Eine Featurespalte wird im VW-System (bei Yahoo/Microsoft) oder ein Feld als „Namespace“ bezeichnet.
  • Beispiel: Eine Instanz (mit ihren Funktionen) und ein Label.
  • Modell: Eine statistische Darstellung einer Vorhersageaufgabe. Sie trainieren ein Modell anhand von Beispielen und verwenden es dann für Vorhersagen.
  • Messwert: Eine Zahl, die Ihnen wichtig ist. Möglicherweise direkt optimiert.
  • Ziel: Ein Messwert, den der Algorithmus optimieren möchte.
  • Pipeline: Die Infrastruktur, die einen Algorithmus für maschinelles Lernen umgibt. Umfasst das Erfassen der Daten vom Front-End, das Speichern in Trainingsdatendateien, das Trainieren eines oder mehrerer Modelle und das Exportieren der Modelle in die Produktion.
  • Klickrate: Prozentsatz der Besucher einer Webseite, die auf einen Link in einer Anzeige geklickt haben

Übersicht

So kreierst du tolle Produkte:

Machen Sie maschinelles Lernen wie ein Ingenieur, der nicht so fähig ist.

Die meisten Probleme sind technische Probleme. Trotz aller Ressourcen eines erstklassigen Experten für maschinelles Lernen kommen die meisten Vorteile durch großartige Funktionen und nicht durch gute Algorithmen für maschinelles Lernen. Der grundlegende Ansatz lautet also:

  1. Achten Sie darauf, dass Ihre Pipeline durchgängig ausgeführt wird.
  2. Beginnen Sie mit einem vernünftigen Ziel.
  3. Fügen Sie auf einfache Weise gängige Funktionen hinzu.
  4. Achten Sie darauf, dass Ihre Pipeline stabil bleibt.

Dieser Ansatz funktioniert über einen längeren Zeitraum gut. Verwenden Sie diesen Ansatz nur, wenn es keine einfachen Tricks mehr gibt, die Sie voranbringen. Wenn die Komplexität zunimmt, werden zukünftige Releases langsamer.

Wenn Sie alle einfachen Tricks ausgeschöpft haben, kann es sein, dass Sie in Zukunft echtes maschinelles Lernen betreiben. Weitere Informationen finden Sie im Abschnitt zu ML-Projekten in Phase III.

Dieses Dokument ist wie folgt angeordnet:

  1. Der erste Teil sollte Ihnen helfen zu verstehen, ob der richtige Zeitpunkt für den Aufbau eines Systems für maschinelles Lernen ist.
  2. Im zweiten Teil geht es um die Bereitstellung der ersten Pipeline.
  3. Der dritte Teil befasst sich mit der Einführung und Iteration beim Hinzufügen neuer Features zu Ihrer Pipeline, der Bewertung von Modellen und der Abweichungen zwischen Training und Bereitstellung.
  4. Im letzten Teil geht es darum, was du tun musst, wenn du ein Plateau erreichst.
  5. Anschließend finden Sie eine Liste mit zugehörigen Aufgaben und einen Anhang mit einigen Hintergrundinformationen zu den Systemen, die in diesem Dokument häufig als Beispiele dienen.

Vor dem maschinellen Lernen

Regel Nr. 1: Scheuen Sie sich nicht, ein Produkt ohne maschinelles Lernen auf den Markt zu bringen.

Maschinelles Lernen ist cool, erfordert aber Daten. Theoretisch können Sie Daten aus einem anderen Problem übernehmen und dann das Modell für ein neues Produkt optimieren. Dies wird jedoch wahrscheinlich die grundlegende Heuristik nicht erfüllen. Wenn Sie glauben, dass Sie mit maschinellem Lernen einen Anstieg von 100% erzielen können, dann kommt eine Heuristik 50 % näher.

Wenn Sie beispielsweise ein Ranking für Apps auf einem App-Marktplatz erstellen, können Sie die Installationsrate oder die Anzahl der Installationen als Heuristik verwenden. Wenn Sie Spam erkennen, filtern Sie Publisher heraus, die bereits Spam gesendet haben. Scheuen Sie sich auch nicht, die manuelle Bearbeitung zu verwenden. Wenn Sie Kontakte nach Rang sortieren möchten, verwenden Sie jeweils die aktuellste oder sogar die alphabetischste. Wenn maschinelles Lernen für Ihr Produkt nicht unbedingt erforderlich ist, sollten Sie es erst verwenden, wenn Sie Daten haben.

Regel 2: Messwerte entwickeln und implementieren

Bevor Sie die Funktionsweise Ihres Systems für maschinelles Lernen formulieren, sollten Sie so viel wie möglich in Ihrem aktuellen System verfolgen. Das hat folgende Gründe:

  1. Es ist einfacher, die Zustimmung der Nutzer des Systems einzuholen.
  2. Wenn Sie glauben, dass etwas in der Zukunft ein Problem sein könnte, ist es besser, jetzt aktuelle Daten abzurufen.
  3. Wenn Sie Ihr System unter Berücksichtigung der Messwertinstrumentierung entwerfen, werden Sie in Zukunft bessere Ergebnisse erzielen. Insbesondere müssen Sie nicht dafür sorgen, dass Sie Logs in Strings durchsuchen, um Ihre Messwerte zu instrumentieren.
  4. Sie werden feststellen, was sich ändert und was sich ändert. Angenommen, Sie möchten die aktiven Nutzer eines Tages direkt optimieren. Bei der frühen Bearbeitung des Systems werden Sie jedoch bemerken, dass dramatische Änderungen der Nutzererfahrung diesen Messwert nicht merklich ändern.

Das Google Plus-Team misst die Ausweitung pro Lesevorgang, die erneute Freigabe pro Lesevorgang sowie die Plus-pro-Lese-Funktion, Kommentare/Lesen, Kommentare pro Nutzer, das erneute Teilen pro Nutzer usw., die zum Berechnen des Beitrags zum Zeitpunkt der Bereitstellung verwendet werden. Außerdem ist ein Test-Framework wichtig, in dem Sie Nutzer in Buckets gruppieren und Statistiken nach Test zusammenfassen können. Siehe Regel 12.

Wenn Sie Messwerte liberaler definieren, erhalten Sie ein umfassenderes Bild Ihres Systems. Haben Sie ein Problem festgestellt? Fügen Sie einen Messwert hinzu, um ihn zu erfassen! Sind Sie aufgeregt über quantitative Veränderungen bei der letzten Veröffentlichung? Fügen Sie einen Messwert hinzu, um ihn zu erfassen!

Regel 3: Maschinelles Lernen gegenüber komplexer Heuristik verwenden

Eine einfache Heuristik kann Ihr Produkt an die Tür bringen. Eine komplexe Heuristik ist unvorhersehbar. Sobald Sie die Daten und eine grundlegende Vorstellung davon haben, was Sie erreichen möchten, können Sie mit dem maschinellen Lernen fortfahren. Wie in den meisten Software-Entwicklungsaufgaben möchten Sie vermutlich Ihren Ansatz kontinuierlich aktualisieren, unabhängig davon, ob es sich um ein heuristisches oder ein maschinell erlerntes Modell handelt. Außerdem werden Sie feststellen, dass das maschinell erlernte Modell einfacher zu aktualisieren und zu warten ist (siehe Regel 16).

ML-Phase I: Ihre erste Pipeline

Konzentrieren Sie sich auf Ihre Systeminfrastruktur für die erste Pipeline. Es macht zwar Spaß, über all das fantasievolle maschinelle Lernen nachzudenken, was Sie tun werden, aber es wird schwierig sein herauszufinden, was passiert, wenn Sie Ihrer Pipeline nicht vertrauen.

Regel Nr. 4: Das erste Modell einfach halten und die Infrastruktur optimieren.

Das erste Modell bietet den größten Boost für Ihr Produkt, sodass es nicht besonders schick ist. Es werden jedoch viel mehr Infrastrukturprobleme als erwartet auftreten. Bevor ein Nutzer das neue ML-System verwenden kann, müssen Sie Folgendes ermitteln:

  • So erhalten Sie Beispiele für Ihren Lernalgorithmus.
  • Erstens, was „gut“ und „schlecht“ für dein System bedeuten.
  • So binden Sie Ihr Modell in Ihre Anwendung ein. Sie können das Modell entweder live anwenden oder das Modell für Beispiele offline vorab berechnen und die Ergebnisse in einer Tabelle speichern. Beispiel: Sie möchten Webseiten vorab klassifizieren und die Ergebnisse in einer Tabelle speichern, Chatnachrichten jedoch live klassifizieren.

Mit einfachen Funktionen sorgen Sie dafür, dass:

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

Sobald Sie ein System haben, das diese drei Dinge zuverlässig ausführt, haben Sie den Großteil der Arbeit erledigt. Ihr einfaches Modell bietet Ihnen Referenzmesswerte und ein Basisverhalten, mit dem Sie komplexere Modelle testen können. Einige Teams streben einen „neutralen“ ersten Start an: Ein erster Start, bei dem maschinelles Lernen ausdrücklich priorisiert wird, um nicht abgelenkt zu werden.

Regel 5: Infrastruktur unabhängig vom maschinellen Lernen testen

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

  1. Testen Sie Daten in den Algorithmus. Prüfen Sie, ob Merkmalspalten, die ausgefüllt werden sollen, ausgefüllt werden. Wenn der Datenschutz dies zulässt, prüfen Sie die Eingabe für Ihren Trainingsalgorithmus manuell. Überprüfen Sie nach Möglichkeit die Statistiken in Ihrer Pipeline im Vergleich zu den Statistiken für dieselben Daten, die an anderer Stelle verarbeitet werden.
  2. Testen Sie Modelle aus dem Trainingsalgorithmus heraus. Achten Sie darauf, dass das Modell in Ihrer Trainingsumgebung denselben Wert wie das Modell in Ihrer Bereitstellungsumgebung erhält (siehe Regel 37).

Maschinelles Lernen hat ein unvorhersehbares Element. Achten Sie daher darauf, dass Sie Tests für den Code zum Erstellen von Beispielen für Training und Bereitstellung ausführen und dass Sie während der Bereitstellung ein festes Modell laden und verwenden können. Es ist außerdem wichtig, dass Sie Ihre Daten verstehen: Tipps zur Analyse großer, komplexer Datasets.

Regel 6: Beim Kopieren von Pipelines vorsichtig sein, wenn Daten gelöscht werden.

Häufig erstellen wir eine Pipeline, indem wir eine vorhandene Pipeline kopieren (z. B. Cargo-Kult-Programmierung). Die alte Pipeline löscht dann die Daten, die wir für die neue Pipeline benötigen. Zum Beispiel werden in der Pipeline für Google+ Angesagte Beiträge ältere Beiträge gelöscht, da versucht wird, das Ranking neuer Beiträge zu erhöhen. Diese Pipeline wurde für die Verwendung in Google Plus Stream kopiert, wo ältere Beiträge weiterhin aussagekräftig sind, aber alte Beiträge weiterhin verworfen werden. Ein weiteres gängiges Muster besteht darin, nur Daten zu protokollieren, die der Nutzer gesehen hat. Diese Daten sind also nutzlos, wenn wir modellieren möchten, warum ein bestimmter Beitrag vom Nutzer nicht gesehen wurde, da alle negativen Beispiele ausgelassen wurden. Ein ähnliches Problem ist bei Play aufgetreten. Bei der Arbeit auf der Startseite von Play Apps wurde eine neue Pipeline erstellt, die auch Beispiele von der Landingpage für Play Spiele enthielt, ohne dass klar ersichtlich war, woher die einzelnen Beispiele stammen.

Regel 7: Heuristik in Merkmale umwandeln oder extern verarbeiten

Normalerweise sind die Probleme, die durch maschinelles Lernen gelöst werden sollen, nicht völlig neu. Es gibt ein bestehendes System für das Ranking, die Klassifizierung oder das andere Problem, das Sie lösen möchten. Das bedeutet, dass es eine Reihe von Regeln und Heuristiken gibt. Dieselbe Heuristik kann Ihnen bei der Optimierung durch maschinelles Lernen helfen. Ihre Heuristik sollte aus zwei Gründen so eingerichtet werden, dass sie allen Informationen zur Verfügung steht, die sie haben. Zuerst wird der Übergang zu einem maschinellen Lernsystem reibungsloser. Zweitens enthalten diese Regeln in der Regel viel Wissen über das System, das Sie nicht entsorgen möchten. Es gibt vier Möglichkeiten, eine vorhandene Heuristik zu verwenden:

  • Vorverarbeiten mit der Heuristik Wenn die Funktion fantastisch ist, ist dies eine Option. Wenn beispielsweise der Absender in einem Spamfilter bereits auf die schwarze Liste gesetzt wurde, versuchen Sie nicht, den Begriff „schwarze Liste“ neu zu definieren. Blockiere die Nachricht. Dieser Ansatz ist bei binären Klassifizierungsaufgaben am sinnvollsten.
  • Erstellen Sie ein Element. Das Erstellen einer Funktion aus der Heuristik ist großartig. Wenn Sie beispielsweise eine Relevanz für ein Abfrageergebnis anhand einer Heuristik berechnen, können Sie den Wert als Featurewert einbeziehen. Später möchten Sie möglicherweise Techniken des maschinellen Lernens verwenden, um den Wert zumassieren (z. B. den Wert in einen endlichen Satz diskreter Werte zu konvertieren oder ihn mit anderen Merkmalen zu kombinieren), aber zuerst den durch die Heuristik erzeugten Rohwert verwenden.
  • Rohdaten der Heuristik abbauen 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 separat ziehen und diese Eingaben separat in das Lernen einfließen lassen. Hier gelten einige Techniken für Ensembles (siehe Regel 40).
  • Ändern Sie das Label. Dies ist eine Option, 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 möchten, aber auch an hochwertigem Content interessiert sind, können Sie das Label vielleicht mit der durchschnittlichen Anzahl der Sterne der App multiplizieren. Hier gibt es viel Spielraum. Siehe Ihr erstes Ziel.

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

Monitoring

Grundsätzlich solltest du eine gute Benachrichtigungshygiene üben, z. B. Benachrichtigungen umsetzbar machen und eine Dashboard-Seite haben.

Regel 8: Anforderungen an die Aktualität deines Systems

Wie stark ist die Leistung bei einem Tag, das einen Tag alt ist? Eine Woche alt? Ein Viertel alt? Diese Informationen können Ihnen helfen, die Prioritäten Ihres Monitorings zu verstehen. Wenn Sie eine erhebliche Produktqualität verlieren, wenn das Modell einen Tag lang nicht aktualisiert wurde, kann es von Vorteil sein, wenn ein Entwickler sie ständig beobachtet. Die meisten Ad Serving-Systeme haben neue Werbung, die jeden Tag verarbeitet werden muss und täglich aktualisiert werden muss. Wenn beispielsweise das ML-Modell für die Google Play-Suche nicht aktualisiert wird, kann sich das in weniger als einem Monat negativ auswirken. Einige Modelle von „Angesagte Beiträge“ in Google Plus haben keine Beitrags-ID im Modell, sodass diese Modelle nur selten exportiert werden können. Andere Modelle mit Post-IDs werden viel häufiger aktualisiert. Beachten Sie auch, dass sich die Aktualität im Laufe der Zeit ändern kann, insbesondere wenn Featurespalten Spalten hinzugefügt oder entfernt werden.

Regel 9: Probleme vor dem Exportieren von Modellen erkennen.

Viele Systeme für maschinelles Lernen haben eine Phase, in der Sie das Modell in die Bereitstellung exportieren. Wenn ein Problem mit einem exportierten Modell auftritt, handelt es sich um ein an Nutzer gerichtetes Problem.

Führen Sie eine Plausibilitätsprüfung direkt vor dem Export des Modells durch. Achten Sie insbesondere darauf, dass die Leistung des Modells für aufbewahrte Daten angemessen ist. Wenn Sie Bedenken bezüglich der Daten haben, sollten Sie kein Modell exportieren. Viele Teams, die Modelle bereitstellen, prüfen vor dem Export den Bereich unterhalb der ROC-Kurve (oder AUC). Bei Problemen mit Modellen, die nicht exportiert wurden, ist eine E-Mail-Benachrichtigung erforderlich. Bei Problemen mit einem nutzerseitigen Modell ist jedoch möglicherweise eine Seite erforderlich. Es ist also besser, zu warten und sich zu vergewissern, dass es keine Auswirkungen auf die Nutzer gibt.

Regel 10: Achte auf lautlose Fehler.

Dieses Problem tritt häufiger bei Systemen für maschinelles Lernen auf als bei anderen Arten von Systemen. Angenommen, eine bestimmte Tabelle, die verknüpft wird, wird nicht mehr aktualisiert. Das System für maschinelles Lernen wird sich noch anpassen und das Verhalten bleibt weiterhin gut, rückläufig. Manchmal finden Sie Tabellen, die monatelang veraltet sind, und eine einfache Aktualisierung verbessert die Leistung mehr als bei jeder anderen Markteinführung in diesem Quartal. Die Abdeckung einer Funktion kann sich aufgrund von Implementierungsänderungen ändern. Beispielsweise kann eine Featurespalte in 90% der Beispiele ausgefüllt werden und dann plötzlich auf 60% der Beispiele fallen. Bei Google Play gab es einmal eine Tabelle, die 6 Monate lang veraltet war, und durch das Aktualisieren der Tabelle allein konnte die Installationsrate um 2% gesteigert werden. Wenn Sie Statistiken der Daten verfolgen und die Daten bei Bedarf manuell überprüfen, können Sie diese Art von Fehlern reduzieren.

Regel 11: Funktionsinhabern Eigentümer und Dokumentation zur Verfügung stellen.

Wenn das System groß ist und viele Featurespalten hat, sollten Sie wissen, wer jede Featurespalte erstellt hat oder verwaltet. Wenn Sie feststellen, dass die Person, die eine Featurespalte versteht, diese verlässt, stellen Sie sicher, dass jemand die Informationen hat. Obwohl viele Merkmalsspalten beschreibende Namen haben, empfiehlt es sich, eine detailliertere Beschreibung des Features, der Herkunft und der voraussichtlichen Hilfe zu geben.

Ihr erstes Ziel

Sie haben zwar viele Messwerte oder Messwerte zu dem System, das Ihnen wichtig ist, aber für den Algorithmus für maschinelles Lernen ist häufig ein einzelnes Ziel erforderlich, das der Algorithmus versuchen würde, zu optimieren. Ich unterscheidet hier zwischen Zielen und Messwerten: Ein Messwert ist eine beliebige Zahl, die Ihr System meldet. Weitere Informationen finden Sie unter Regel 2.

Regel 12: Überlegen Sie nicht, welches Ziel Sie direkt optimieren möchten.

Sie möchten Geld verdienen, Ihre Nutzer zufriedenstellen und die Welt zu einem besseren Ort machen. Es gibt unzählige Messwerte, die Sie interessieren sollten, und Sie sollten sie alle messen (siehe Regel 2). Zu Beginn des Prozesses für maschinelles Lernen werden jedoch alle zunehmen, auch solche, die Sie nicht direkt optimieren. Angenommen, Sie interessieren sich für die Anzahl der Klicks und die Zeit, die auf der Website verbracht wird. Wenn Sie die Anzahl der Klicks optimieren, ist die Zeit vermutlich höher.

Fassen Sie sich also einfach und machen Sie sich keine Gedanken darüber, verschiedene Messwerte auszubalancieren, wenn Sie alle Messwerte problemlos erhöhen können. Sie sollten diese Regel nicht zu weit fassen: Verwechseln Sie Ihr Ziel nicht mit dem endgültigen Systemzustand (siehe Regel 39). Wenn Sie feststellen, dass Sie den direkt optimierten Messwert erhöhen, sich dann aber entscheiden, nicht zu starten, ist möglicherweise eine objektive Überarbeitung erforderlich.

Regel 13: Wähle einen einfachen, beobachtbaren und zuweisbaren Messwert für dein erstes Ziel aus.

Oft ist nicht klar, was das wahre Ziel ist. Sie denken aber, aber wenn Sie dann die Daten und die parallele Analyse Ihres alten Systems und des neuen ML-Systems betrachten, erkennen Sie, dass Sie das Ziel optimieren müssen. Darüber hinaus können sich verschiedene Teammitglieder oft nicht auf das wahre Ziel einigen. Das ML-Ziel sollte leicht messbar sein und dient als Proxy für das „wahre“ Ziel. Tatsächlich gibt es oft kein „true“-Ziel (siehe Regel#39). Trainieren Sie daher mit dem einfachen ML-Ziel und erwägen Sie eine „Richtlinienebene“, mit der Sie eine zusätzliche Logik (hoffentlich sehr einfache Logik) für das endgültige Ranking 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 bewertete Objekt heruntergeladen?
  • Wurde dieses Rangobjekt weitergeleitet/beantwortet/per E-Mail gesendet?
  • Wurde dieses bewertete Objekt bewertet?
  • War dieses gezeigte Objekt als Spam/Pornografie/anstößig?

Vermeiden Sie zuerst die Modellierung indirekter Effekte:

  • War der Nutzer am nächsten Tag da?
  • Wie lange hat der Nutzer die Website besucht?
  • Wie hoch waren die täglich aktiven Nutzer?

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

Schließlich sollten Sie nicht versuchen, das maschinelle Lernen zu ermitteln:

  • Ist der Nutzer zufrieden mit dem Produkt?
  • Ist der Nutzer zufrieden?
  • Verbessert das Produkt das allgemeine Wohlbefinden der Nutzer?
  • Wie wirkt sich das auf den allgemeinen Gesundheitszustand des Unternehmens aus?

Diese sind zwar wichtig, aber auch äußerst schwer zu messen. Verwende stattdessen Proxys: Wenn der Nutzer zufrieden ist, bleibt er länger auf der Website. Wenn der Nutzer zufrieden ist, besucht er morgen noch einmal. Zum Wohlergehen und zur Gesundheit des Unternehmens sind manuelle Überprüfungen erforderlich, um alle maschinellen Lernziele mit der Art des angebotenen Produkts und Ihres Geschäftsplans in Verbindung zu bringen.

Regel 14: Der Einstieg in ein interpretierbares Modell erleichtert das Debugging.

Lineare Regression, logistische Regression und Poisson-Risiko sind direkt von einem probabilistischen Modell motiviert. Jede Vorhersage kann als Wahrscheinlichkeit oder erwarteter Wert interpretiert werden. Dadurch lassen sich Fehler leichter beheben als bei Modellen, die Ziele wie Nullverlust und verschiedene Scharnierverluste verwenden, die versuchen, die Klassifizierungsgenauigkeit oder die Rankingleistung direkt zu optimieren. Wenn z. B. Wahrscheinlichkeiten im Training von Wahrscheinlichkeiten abweichen, die nebeneinander oder durch Prüfung des Produktionssystems angegeben werden, kann diese Abweichung ein Problem darstellen.

In linearen, logistischen oder Poisson-Rängen gibt es beispielsweise Teilmengen der Daten, bei denen die durchschnittliche vorhergesagte Erwartung mit dem durchschnittlichen Label übereinstimmt (1-Moment-Kalibrierung oder nur kalibriert). Dies setzt voraus, dass Sie keine Regularisierung haben und Ihr Algorithmus konvergent ist. Allgemein gilt das. Wenn Sie ein Feature haben, das entweder 1 oder 0 für jedes Beispiel ist, werden die drei Beispiele mit 1 kalibriert. Wenn Sie ein Feature haben, das für jedes Beispiel 1 ist, wird die Gruppe aller Beispiele kalibriert.

Bei einfachen Modellen ist es einfacher, mit Feedbackschleifen umzugehen (siehe Regel 36). Häufig verwenden wir diese probabilistischen Vorhersagen, um eine Entscheidung zu treffen, z.B. Ranking von abnehmenden erwarteten Werten (d.h. Wahrscheinlichkeit eines Klicks/Downloads usw.). Denken Sie jedoch daran, bei der Auswahl des zu verwendenden Modells die Wahrscheinlichkeit größer ist als die Wahrscheinlichkeit der Daten für das Modell (siehe Regel 27).

Regel Nr. 15: Spam-Filterung und Qualitäts-Ranking in einer Richtlinienebene trennen.

Qualitäts-Ranking ist eine gute Kunst, aber Spam-Filterung ist ein Krieg. Die Signale, die du zur Bestimmung hochwertiger Beiträge verwendest, werden für die Nutzer deines Systems offensichtlich. Sie werden ihre Beiträge dann entsprechend anpassen. Daher sollte sich dein Qualitäts-Ranking auf das Ranking von Inhalten konzentrieren, die in Treu und Glauben gepostet werden. Sie sollten den Qualitätslerner nicht auf das Ranking von Spam achten. Ebenso sollten Inhalte mit dem Status „Nicht jugendfrei“ getrennt vom Qualitäts-Ranking gehandhabt werden. Die Spam-Filterung ist etwas anderes. Sie müssen davon ausgehen, dass sich die Features, die Sie generieren müssen, ständig ändern. Häufig gibt es offensichtliche Regeln, die man in das System einfügt (wenn ein Beitrag mehr als drei Spam-Stimmen hat, z. B. keine Beiträge abrufen). Jedes erlernte Modell muss täglich aktualisiert werden, wenn nicht schneller. Der Ruf des Erstellers der Inhalte spielt eine große Rolle.

Auf irgendeiner Ebene muss die Ausgabe dieser beiden Systeme integriert werden. Beachten Sie, dass das Filtern von Spam in den Suchergebnissen wahrscheinlich strenger sein sollte als das Filtern von Spam in E-Mails. Dies setzt voraus, dass Sie keine Regularisierung haben und Ihr Algorithmus konvergiert ist. Das gilt im Allgemeinen. Es ist außerdem üblich, Spam aus den Trainingsdaten für den Qualitätsklassifikator zu entfernen.

ML-Phase II: Feature Engineering

In der ersten Phase des Lebenszyklus eines ML-Systems besteht das Hauptproblem darin, die Trainingsdaten in das Lernsystem zu bringen, alle relevanten Messwerte zu analysieren und eine Bereitstellungsinfrastruktur zu erstellen. Nachdem Sie ein funktionsfähiges End-to-End-System mit instrumentierten Einheiten- und Systemtests haben, beginnt Phase II.

In der zweiten Phase gibt es viele tief hängende Früchte. Es gibt eine Vielzahl offensichtlicher Merkmale, die in das System geladen werden können. In der zweiten Phase des maschinellen Lernens werden daher möglichst viele Features abgerufen und auf intuitive Weise kombiniert. In dieser Phase sollten alle Messwerte weiter ansteigen. Es wird zahlreiche Markteinführungen geben und die besten Leute, die alle für ein wirklich tolles Lernsystem erforderlichen Daten zusammentragen können, sollten jetzt viele Entwickler einbeziehen.

Regel 16: Einführung und Iteration planen

Erwarten Sie nicht, dass das Modell, an dem Sie gerade arbeiten, das letzte ist, das Sie starten, oder dass Sie jemals die Einführung von Modellen einstellen werden. Überlegen Sie daher, ob die Komplexität, die Sie mit dieser Einführung hinzufügen, zukünftige Starts verlangsamt. Viele Teams haben über Jahre hinweg ein Modell pro Quartal oder mehr eingeführt. Es gibt drei grundlegende Gründe für die Einführung neuer Modelle:

  • Es gibt neue Funktionen.
  • Du passt die Regularisierung an und kombinierst alte Funktionen auf neue Art und Weise.
  • Sie passen das Ziel an.

Egal, ein wenig Liebe zum Modell zu haben, kann gut sein: Wenn Sie die Daten in das Beispiel einfließen lassen, können Sie sowohl neue als auch alte, fehlerhafte Signale finden. Überlegen Sie beim Erstellen Ihres Modells, wie einfach Features hinzugefügt oder entfernt werden können. Überlegen Sie sich, wie einfach es ist, eine neue Kopie der Pipeline zu erstellen und ihre Richtigkeit zu überprüfen. Überlegen Sie, ob es möglich ist, zwei oder drei Kopien parallel auszuführen. Machen Sie sich auch keine Gedanken darüber, ob Feature 16 von 35 diese Version der Pipeline erreicht. Du bekommst es im nächsten Quartal.

Regel 17: Beginnen Sie mit direkt beobachteten und gemeldeten Funktionen, nicht mit den erlernten.

Dies kann ein kontroverser Punkt sein, aber viele Fehler lassen sich vermeiden. Beschreiben wir zuerst, was ein erlerntes Merkmal ist. Ein erlerntes Feature wird entweder von einem externen System (z. B. einem nicht überwachten Clustersystem) oder vom Lernenden selbst erstellt (z. B. durch ein faktorisiertes Modell oder Deep Learning). Beide können nützlich sein, können jedoch viele Probleme verursachen, sodass sie nicht im ersten Modell enthalten sein sollten.

Wenn Sie ein externes System zum Erstellen eines Merkmals verwenden, beachten Sie, dass das externe System ein eigenes Ziel hat. Das Ziel des externen Systems ist möglicherweise nur schwach korreliert mit Ihrem aktuellen Ziel. Wenn Sie einen Snapshot des externen Systems erstellen, kann dieser veraltet sein. Wenn Sie die Features des externen Systems aktualisieren, kann sich die Bedeutung ändern. Wenn Sie ein externes System verwenden, um ein Feature bereitzustellen, beachten Sie, dass dieser Ansatz mit viel Sorgfalt verbunden ist.

Das Hauptproblem bei faktorisierten Modellen und tiefen Modellen ist, dass sie nicht konvex sind. Daher kann nicht garantiert werden, dass eine optimale Lösung ermittelt oder ermittelt werden kann. Außerdem können die bei jedem Durchlauf gefundenen lokalen Minima variieren. Mit dieser Variante lässt sich nur schwer beurteilen, ob die Auswirkungen einer Änderung auf Ihr System sinnvoll oder zufällig sind. Durch das Erstellen eines Modells ohne tief greifende Features können Sie eine hervorragende Referenzleistung erzielen. Nachdem dieser Ausgangswert erreicht wurde, können Sie mehr esoterische Ansätze ausprobieren.

Regel 18: Mit Inhaltsfunktionen experimentieren, die kontextübergreifend verallgemeinert werden

Machine Learning-Systeme sind oft nur ein kleiner Teil eines großen Ganzen. Wenn Sie sich beispielsweise einen Beitrag vorstellen, der in „Angesagte Beiträge“ verwendet werden könnte, werden viele Beiträge mit einem +1 versehen, erneut geteilt oder kommentiert, bevor sie in den angesagten Beiträgen angezeigt werden. Wenn Sie dem Lernenden diese Statistiken zur Verfügung stellen, können damit neue Beiträge beworben werden, für die es im Kontext der Optimierung keine Daten gibt. YouTube Watch Next kann die Anzahl der Wiedergaben oder Co-Watches über die YouTube-Suche Du kannst auch explizite Nutzerbewertungen verwenden. Wenn Sie eine Nutzeraktion haben, die Sie als Label verwenden, kann es hilfreich sein, diese Aktion im Dokument in einem anderen Kontext zu sehen. Mit all diesen Funktionen können Sie neue Inhalte in den Kontext bringen. Dabei geht es nicht um Personalisierung: Finde zuerst heraus, ob die Inhalte in diesem Kontext gefallen. Finde dann heraus, wem sie mehr oder weniger gefallen.

Regel 19: Verwende nach Möglichkeit sehr spezifische Funktionen.

Aufgrund der großen Datenmenge ist es einfacher, Millionen von einfachen Features als nur wenige komplexe Features zu erlernen. Kennungen von Dokumenten, die abgerufen und kanonisiert werden, bieten nicht viel Generalisierung, passen Ihr Ranking jedoch mit Ihren Labels bei Kopfabfragen an. Sie haben also keine Angst vor Gruppen von Merkmalen, bei denen jedes Merkmal auf einen kleinen Bruchteil Ihrer Daten zutrifft, die Abdeckung aber insgesamt über 90 % liegt. Mit der Regularisierung können Sie die Features entfernen, die für zu wenige Beispiele gelten.

Regel 20: Vorhandene Funktionen kombinieren und ändern, um neue Funktionen auf verständliche Weise zu erstellen.

Es gibt verschiedene Möglichkeiten, Features zu kombinieren und zu ändern. Mit Systemen für maschinelles Lernen wie TensorFlow können Sie Ihre Daten durch Transformationen vorverarbeiten. Die beiden gängigsten Ansätze sind „Diskretisierungen“ und „Kreuze“.

Die Diskretisierung besteht darin, ein kontinuierliches Feature zu verwenden und daraus viele diskrete Features zu erstellen. Verwenden Sie ein kontinuierliches Feature wie das Alter. Sie können ein Merkmal erstellen, das 1 ist, wenn das Alter unter 18 ist, und ein anderes, das 1 ist, wenn das Alter zwischen 18 und 35 liegt. Denken Sie nicht über die Grenzen dieser Histogramme nach: Einfache Quantile haben den größten Einfluss.

Kreuze kombinieren zwei oder mehr Featurespalten. Eine Featurespalte in der Terminologie von TensorFlow besteht aus einer Reihe von homogenen Features (z. B. {male, female}, {US, Canada, Mexico} usw.). Ein Kreuz ist eine neue Merkmalspalte mit Features in, z. B. {male, female} × {US,Canada, Mexico}. Diese neue Merkmalsspalte enthält das Merkmal (männlich, Kanada). Wenn Sie TensorFlow verwenden und TensorFlow anweisen, dieses Kreuz für Sie zu erstellen, wird dieses (männliche, kanadische) Feature in Beispielen für männliche Kanadier vorhanden sein. Beachten Sie, dass es enorme Mengen an Daten benötigt, um Modelle mit Kreuzen von drei, vier oder mehr Grundmerkmalspalten zu erlernen.

Kreuze, die sehr große Merkmalsspalten erzeugen, können überdimensioniert sein. Beispiel: Sie führen eine Suche durch und haben eine Featurespalte mit Wörtern in der Abfrage sowie eine Featurespalte mit Wörtern im Dokument. Sie können sie mit einem Kreuz kombinieren, erhalten dann aber viele Funktionen (siehe Regel 21).

Beim Arbeiten mit Text gibt es zwei Alternativen. Der drakonischste Punkt ist ein Punktprodukt. Ein Punktprodukt in seiner einfachsten Form zählt einfach die Anzahl der Wörter, die die Abfrage und das Dokument gemeinsam haben. Dieses Feature kann dann diskretisiert werden. Ein anderer Ansatz ist eine Kreuzung: Wir haben also eine Funktion, die nur vorhanden ist, wenn das Wort „Pony“ sowohl im Dokument als auch in der Abfrage vorhanden ist, und eine weitere Funktion, die nur vorhanden ist, wenn das Wort „the“ im Dokument und in der Abfrage enthalten ist.

Regel 21: Die Anzahl der Feature-Gewichtungen, die Sie in einem linearen Modell lernen können, ist ungefähr proportional zur Menge der vorhandenen Daten.

Es gibt faszinierende Ergebnisse des statistischen Lernens zur richtigen Komplexität eines Modells. Diese Regel ist jedoch alles, was Sie wissen müssen. Ich habe mich mit Gesprächen unterhalten, bei denen die Menschen sich nicht sicher waren, ob man aus tausendtausend Beispielen etwas lernen kann, oder dass man jemals mehr als eine Million Beispiele brauchen würde, weil sie bei einer bestimmten Lernmethode hängen bleiben. Entscheidend ist, das Lernen auf die Größe der Daten zu skalieren:

  1. Wenn Sie an einem Rankingsystem für die Suche arbeiten und die Dokumente und die Abfrage Millionen verschiedener Wörter enthalten und Sie 1.000 Labelbeispiele haben, sollten Sie ein Punktprodukt zwischen Dokument- und Abfragefunktionen, TF-IDF und ein halbes Dutzend weiterer hoch entwickelter Features verwenden. 1.000 Beispiele, ein Dutzend Funktionen.
  2. Wenn Sie eine Million Beispiele haben, schneiden Sie die Dokument- und Abfragefeature-Spalten über Regularisierung und ggf. Featureauswahl. Dadurch erhalten Sie Millionen von Features, aber bei der Regularisierung stehen Ihnen weniger zur Verfügung. 10 Millionen Beispiele, vielleicht 100.000 Features.
  3. Wenn Sie Milliarden oder Hunderte Milliarden von Beispielen haben, können Sie die Featurespalten mithilfe von Feature-Auswahl und Regularisierung mit Dokument- und Abfragetokens verknüpfen. Sie haben eine Milliarde Beispiele und 10 Millionen Features. Statistische Theorietheorien bringen selten enge Grenzen, bieten aber gute Anhaltspunkte für die Ausgangslage.

Am Ende verwenden Sie Regel 28, um zu entscheiden, welche Features verwendet werden sollen.

Regel 22: Funktionen bereinigen, die Sie nicht mehr verwenden

Nicht verwendete Funktionen führen zu technischen Schulden. Wenn Sie feststellen, dass Sie ein Feature nicht verwenden und die Kombination mit anderen Features nicht funktioniert, löschen Sie es aus Ihrer Infrastruktur. Sie sollten Ihre Infrastruktur sauber halten, damit die vielversprechendsten Funktionen so schnell wie möglich getestet werden können. Bei Bedarf kann jemand Ihr Feature jederzeit wieder hinzufügen.

Bedenken Sie, welche Funktionen Sie hinzufügen oder beibehalten sollten. Wie viele Beispiele werden vom Feature abgedeckt? Wenn Sie beispielsweise einige Personalisierungsfunktionen haben, aber nur 8% Ihrer Nutzer Personalisierungsfunktionen haben, ist diese nicht sehr effektiv.

Gleichzeitig können einige Funktionen übertreffen. Wenn Sie beispielsweise ein Feature haben, das nur 1% der Daten abdeckt, aber 90% der Beispiele, die das Feature enthalten, positiv sind, dann ist es eine gute Funktion, dieses Feature hinzuzufügen.

Menschliche Analyse des Systems

Bevor Sie mit der dritten Phase des maschinellen Lernens beginnen, sollten Sie sich auf etwas konzentrieren, das in keiner der Kurse des maschinellen Lernens unterrichtet wird: wie Sie ein vorhandenes Modell betrachten und verbessern können. Dies ist eher eine Kunst als eine Wissenschaft, aber dennoch gibt es mehrere Anti-Muster, die vermieden werden können.

Regel 23: Sie sind kein typischer Endnutzer.

Das ist vielleicht der einfachste Weg für ein Team. Obwohl Fishfood (mit einem Prototyp in Ihrem Team) und Dogfooding (mit einem Prototyp in Ihrem Unternehmen) viele Vorteile bietet, sollten die Mitarbeiter prüfen, ob die Leistung korrekt ist. Eine Änderung, die offensichtlich nicht sinnvoll ist, sollte zwar nicht verwendet werden, aber alles, was in der Produktion vernünftig aussieht, sollte weiter getestet werden. Dazu werden entweder Laien zur Beantwortung von Fragen auf einer Crowdsourcing-Plattform oder im Rahmen eines Live-Experiments mit echten Nutzern getestet.

Dafür gibt es zwei Gründe. Die erste besteht darin, dass Sie zu nahe am Code sind. Vielleicht suchst du nach einem bestimmten Aspekt der Beiträge oder bist einfach nur zu emotional involviert (z.B. Bestätigungsfehler). Zweitens ist deine Zeit zu kostbar. Berücksichtigen Sie die Kosten von neun Entwicklern, die in einer einstündigen Besprechung sitzen, und überlegen Sie, wie viele vertraglich beauftragte Labels auf einer Crowdsourcing-Plattform gekauft werden.

Wenn Sie Feedback der Nutzer einholen möchten, verwenden Sie die entsprechenden Methoden. Erstellen Sie zu Beginn eines Prozesses Nutzeridentitäten (eine Beschreibung in Bill Buxtons Sketching User Experiences) und führen Sie später Tests zur Nutzerfreundlichkeit durch (eine Beschreibung befindet sich in Steve Krugs Don't Make Me Think-Beitrag). Nutzeridentitäten umfassen das Erstellen eines hypothetischen Nutzers. Wenn Ihr Team beispielsweise männlich ist, kann es hilfreich sein, eine 35-jährige weibliche Nutzeridentität zu entwickeln (mit Nutzerfunktionen) und sich die Ergebnisse anzusehen, die statt der 10- bis 45-jährigen männlichen Nutzer vorliegen. Wenn Sie es Ihren Nutzern ermöglichen, die Reaktionen Ihrer Website (lokal oder remote) beim Nutzerfreundlichkeitstest live zu verfolgen, können Sie eine ganz neue Perspektive erhalten.

Regel 24: Delta zwischen Modellen messen.

Eine der einfachsten und manchmal nützlichsten Messungen, die Sie vornehmen können, bevor Nutzer Ihr neues Modell betrachten, besteht darin, zu berechnen, wie sich die neuen Ergebnisse von der Produktion unterscheiden. Wenn Sie beispielsweise ein Rankingproblem haben, führen Sie beide Modelle für eine Stichprobe von Abfragen im gesamten System aus und sehen Sie sich die Größe der symmetrischen Differenz der Ergebnisse (gewichtet nach Rankingposition) an. Wenn der Unterschied sehr gering ist, können Sie ohne einen Test feststellen, dass es nur kleine Änderungen gibt. Wenn der Unterschied sehr groß ist, sollten Sie darauf achten, dass die Änderung gut ist. Wenn Sie sich Abfragen mit hohem symmetrischen Unterschied ansehen, können Sie die Änderung besser nachvollziehen. Achten Sie jedoch darauf, dass das System stabil ist. Achten Sie darauf, dass ein Modell im Vergleich zu sich selbst einen geringen (idealerweise null) symmetrischen Unterschied aufweist.

Regel Nr. 25: Bei der Auswahl der Modelle hat die Leistungsfähigkeit eine bessere Leistung als Vorhersageleistung.

Ihr Modell versucht möglicherweise, die Klickrate vorherzusagen. Letztendlich geht es darum, was Sie mit dieser Vorhersage tun. Wenn Sie es zum Ranking von Dokumenten verwenden, ist die Qualität des endgültigen Rankings wichtiger als die Vorhersage selbst. Wenn Sie die Wahrscheinlichkeit vorhersagen, dass ein Dokument Spam ist, und dann entscheiden, was blockiert werden soll, ist die Genauigkeit der zulässigen Vorgänge wichtiger. In den meisten Fällen sollten diese beiden Dinge einvernehmlich sein: Wenn sie nicht zustimmen, werden sie wahrscheinlich einen kleinen Nutzen bringen. Wenn es also eine Änderung gibt, die den Logverlust verbessert, aber die Leistung des Systems beeinträchtigt, suchen Sie nach einer anderen Funktion. Wenn dies häufiger vorkommt, ist es an der Zeit, das Ziel Ihres Modells zu überdenken.

Regel 26: Muster in den gemessenen Fehlern suchen und neue Features erstellen

Angenommen, Sie sehen ein Trainingsbeispiel, dass das Modell „falsch“ ist. In einer Klassifizierungsaufgabe kann dieser Fehler falsch positive oder falsch negative Ergebnisse sein. In einer Rankingaufgabe könnte der Fehler ein Paar sein, bei dem ein positives Ranking niedriger als ein negatives Ranking war. Der wichtigste Punkt ist, dass dies ein Beispiel ist, dass das ML-System weiß, dass es falsch liegt, und es beheben möchte, falls es die Möglichkeit gibt. Wenn Sie dem Modell eine Funktion geben, mit der sich der Fehler beheben lässt, versucht das Modell, diese zu verwenden.

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

Sobald Sie Beispiele haben, dass das Modell falsch ist, suchen Sie nach Trends, die sich außerhalb Ihres aktuellen Feature-Sets befinden. Wenn das System beispielsweise längere Beiträge abwertet, fügen Sie die Beitragslänge hinzu. Seien Sie nicht zu spezifisch für die Features, die Sie hinzufügen. Wenn Sie Post-Längen hinzufügen möchten, versuchen Sie nicht zu erraten, was "lang" bedeutet, sondern nur ein Dutzend Funktionen und lassen Sie das Modell dann entscheiden, was damit zu tun ist (siehe Regel Nr. 21). So gelangen Sie am einfachsten zum gewünschten Ergebnis.

Regel 27: Beobachten Sie das beobachtete unerwünschte Verhalten.

Einige Mitglieder Ihres Teams sind frustriert über Eigenschaften des Systems, die sie nicht mögen und die nicht von der vorhandenen Verlustfunktion erfasst werden. An dieser Stelle sollten sie alles tun, was nötig ist, um ihre Griffe in solide Zahlen zu verwandeln. Wenn sie z. B. glauben, dass zu viele „Gag-Apps“ in Play Search angezeigt werden, können sie von Prüfern identifiziert werden. In diesem Fall können Sie mit Menschen versehene Daten verwenden, da ein relativ kleiner Teil der Abfragen einen großen Teil des Traffics ausmacht. Wenn Ihre Probleme messbar sind, können Sie sie als Features, Ziele oder Messwerte verwenden. Die allgemeine Regel lautet Zuerst messen, zweiter optimieren.

Regel Nr. 28: Identisches kurzfristiges Verhalten bedeutet nicht, dass langfristiges Verhalten identisch ist.

Stellen Sie sich vor, Sie haben ein neues System, das sich jede doc_id und genau_Suchanfrage ansieht und dann die Wahrscheinlichkeit von Klicks für jedes Dokument und jede Abfrage berechnet. Sie stellen fest, dass sich dieses Verhalten sowohl mit Ihrem aktuellen System als auch mit A/B-Tests fast identisch ist. Daher starten Sie es. Sie stellen jedoch fest, dass keine neuen Apps angezeigt werden. Was steckt dahinter? Da Ihr System nur ein Dokument anzeigt, das auf seinem eigenen Verlauf mit dieser Abfrage basiert, kann nicht festgestellt werden, ob ein neues Dokument angezeigt werden sollte.

Die einzige Möglichkeit zu verstehen, wie ein solches System auf lange Sicht funktionieren würde, besteht darin, es nur mit Daten zu trainieren, die während der Liveausführung des Modells erfasst wurden. Das ist sehr schwierig.

Verschiebungs-Skew

Abweichungen zwischen Training und Bereitstellung sind ein Unterschied zwischen der Leistung während des Trainings und der Leistung während der Bereitstellung. Diese Abweichung kann folgende Ursachen haben:

  • Eine Diskrepanz zwischen dem Umgang mit Daten in den Trainings- und Bereitstellungspipelines.
  • Eine Änderung der Daten zwischen dem Training und der Bereitstellung.
  • Eine Feedbackschleife zwischen Ihrem Modell und Ihrem Algorithmus.

Wir haben bei Google Produktionssysteme für maschinelles Lernen mit Trainings-Bereitstellungs-Verzerrungen beobachtet, die sich negativ auf die Leistung auswirken. Die beste Lösung besteht darin, sie explizit zu überwachen, damit System- und Datenänderungen keine Verzerrungen verursachen.

Regel 29: Die beste Möglichkeit, sicherzustellen, dass das Training wie Ihr Training funktioniert, besteht darin, die bei der Bereitstellung verwendeten Features zu speichern und diese Features dann in ein Protokoll zu schreiben, um sie während des Trainings zu verwenden.

Auch wenn Sie dies nicht für jedes Beispiel durchführen können, sollten Sie dies für einen kleinen Teil tun, damit Sie die Konsistenz zwischen Bereitstellung und Training prüfen können (siehe Regel 37). Teams, die diese Messung bei Google durchgeführt haben, waren manchmal von den Ergebnissen überrascht. Die Startseite von YouTube wechselte bei der Bereitstellung zu Logging-Funktionen mit deutlichen Qualitätsverbesserungen und einer geringeren Komplexität des Codes. Viele Teams wechseln daher ihre Infrastruktur während des Gesprächs.

Regel Nr. 30: Stichprobengewichtung nach Wichtigkeit – nicht willkürlich verwerfen

Wenn zu viele Daten vorhanden sind, besteht die Versuchung, die Dateien 1–12 zu übernehmen und die Dateien 13–99 zu ignorieren. Und genau das ist das Problem. Obwohl Daten, die dem Nutzer nie angezeigt wurden, verworfen werden können, ist die Wichtigkeitsgewichtung für den Rest am besten geeignet. Die Wichtigkeit einer Gewichtung bedeutet, dass Sie, wenn Sie Beispiel X mit einer Wahrscheinlichkeit von 30% verwenden, eine Gewichtung von 10/3 verwenden. Mit der Wichtigkeitsgewichtung werden alle in Regel 14 erläuterten Kalibrierungseigenschaften noch beibehalten.

Regel 31: Vorsicht: Wenn Sie Daten aus einer Tabelle während der Trainings- und Bereitstellungszeit zusammenführen, können sich die Daten in der Tabelle ändern.

Angenommen, Sie führen Dokument-IDs mit einer Tabelle zusammen, die Funktionen für diese Dokumente enthält, z. B. die Anzahl der Kommentare oder Klicks. Zwischen Training und Bereitstellung können sich Features in der Tabelle ändern. Die Vorhersage Ihres Modells für dasselbe Dokument kann dann zwischen Training und Bereitstellung abweichen. Die einfachste Möglichkeit, dieses Problem zu vermeiden, besteht darin, Features bei der Bereitstellung zu protokollieren (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 sinnvolle Daten zu erhalten. Beachten Sie, dass das Problem dadurch nicht vollständig behoben wird.

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

Die Batchverarbeitung unterscheidet sich von der Onlineverarbeitung. Bei der Onlineverarbeitung müssen Sie jede Anfrage bei Eingang verarbeiten (z.B. müssen Sie für jede Abfrage eine separate Suche durchführen), während Sie bei der Batchverarbeitung Aufgaben kombinieren (z.B. einen Join). Zum Zeitpunkt der Bereitstellung führen Sie eine Onlineverarbeitung durch, während das Training eine Batchverarbeitungsaufgabe ist. Es gibt jedoch einige Dinge, die Sie unternehmen können, um Code noch einmal zu verwenden. Sie können beispielsweise ein Objekt erstellen, das für Ihr System spezifisch ist, wobei das Ergebnis von Abfragen oder Joins auf sehr menschenlesbare Weise gespeichert und Fehler problemlos getestet werden können. Sobald Sie alle Informationen erfasst haben, führen Sie während der Bereitstellung oder des Trainings eine gemeinsame Methode für das Brückenn des für Menschen lesbaren Objekts aus, das für Ihr System spezifisch ist und in welchem Format das Machine Learning-System erwartet. Dadurch werden Abweichungen zwischen Training und Bereitstellung vermieden. Vermeiden Sie es, zwei verschiedene Programmiersprachen zwischen Training und Bereitstellung zu verwenden. Diese Entscheidung macht es fast unmöglich, Code freizugeben.

Regel 33: Wenn Sie ein Modell auf Basis der Daten bis zum 5. Januar erstellen, testen Sie das Modell anhand der Daten ab dem 6. Januar.

Generell sollten Sie die Leistung eines Modells anhand der Daten messen, die Sie nach dem Trainieren des Modells gesammelt haben. Dies spiegelt die Vorgehensweise Ihres Systems in der Produktion besser wider. Wenn Sie ein Modell auf Basis der Daten bis zum 5. Januar erstellen, testen Sie es an den Daten vom 6. Januar. Sie erwarten, dass die Leistung der neuen Daten nicht so gut sein wird. Sie sollte aber nicht wesentlich schlechter sein. Da es zu täglichen Auswirkungen kommen kann, können Sie die durchschnittliche Klickrate oder Conversion-Rate nicht vorhersagen. Der Bereich unter der Kurve, der die Wahrscheinlichkeit darstellt, dass dem positiven Beispiel ein höherer Wert als ein negatives Beispiel gegeben wird, sollte naheliegend sein.

Regel Nr. 34: Bei der binären Klassifizierung für das Filtern, z. B. bei der Spamerkennung oder der Ermittlung interessanter E-Mails, werden kurzfristig kurzfristige Leistungsabstriche bei sehr sauberen Daten vorgenommen.

In einer Filteraufgabe werden Beispiele, die als negativ gekennzeichnet sind, dem Nutzer nicht angezeigt. Angenommen, Sie haben einen Filter, der 75% der negativen Beispiele bei der Auslieferung blockiert. Sie könnten versucht sein, zusätzliche Trainingsdaten aus den Instanzen zu ziehen, die Nutzern angezeigt werden. Wenn ein Nutzer beispielsweise eine E-Mail als Spam markiert, die Ihr Filter durchläuft, möchten Sie möglicherweise daraus lernen.

Dieser Ansatz führt jedoch zu Stichprobenverzerrungen. Sie können dann bereinigte Daten erfassen, wenn Sie stattdessen 1% des gesamten Traffics als „ausgehalten“ kennzeichnen und dann alle Beispiele an den Nutzer senden. Jetzt blockiert Ihr Filter mindestens 74% der negativen Beispiele. Diese Beispiele können Ihre Trainingsdaten werden.

Wenn Ihr Filter 95% der negativen Beispiele oder mehr blockiert, wird dieser Ansatz weniger realisierbar. Auch wenn Sie die Bereitstellungsleistung messen möchten, können Sie eine noch kleinere Stichprobe (z.B.0,1% oder 0,001%) erstellen. Zehntausend Beispiele reichen aus, um die Leistung genau zu schätzen.

Regel Nr. 35: Vorsicht vor Ranking-Problemen

Wenn Sie Ihren Rankingalgorithmus so stark anpassen, dass unterschiedliche Ergebnisse angezeigt werden, haben Sie die Daten, die Ihr Algorithmus in Zukunft sehen wird, effektiv geändert. Diese Art von Verzerrung wird angezeigt und Sie sollten das Modell entsprechend gestalten. Es gibt verschiedene Ansätze. Diese Ansätze sind alle Möglichkeiten, Daten zu bevorzugen, die Ihr Modell bereits gesehen hat.

  1. Sie haben eine höhere Regularisierung für Features, die mehr Abfragen abdecken, als für Features, die nur für eine Abfrage aktiviert sind. Auf diese Weise bevorzugt das Modell Merkmale, die für eine oder einige wenige Abfragen spezifisch sind, und Features, die sich auf alle Abfragen beziehen. Dieser Ansatz kann verhindern, dass sehr beliebte Ergebnisse in irrelevante Abfragen gelangen. Beachten Sie, dass dies gegen die konventionelleren Empfehlungen einer Regularisierung von Featurespalten mit eindeutigeren Werten verstößt.
  2. Nur Funktionen mit einer positiven Gewichtung zulassen. Daher ist ein gutes Feature besser als ein Feature, das „unbekannt“ ist.
  3. Sie haben keine Funktionen, für die nur Dokumente verfügbar sind. Das ist eine Extremversion von Nummer 1. Auch wenn eine bestimmte Anwendung beispielsweise ein beliebter Download ist, unabhängig von der Abfrage, soll sie nicht überall angezeigt werden. Wenn Sie keine reinen Dokumentfunktionen nutzen, ist das ganz einfach. Warum eine bestimmte beliebte App nicht überall angezeigt werden soll, ist wichtig, damit alle gewünschten Apps erreichbar sind. Wenn ein Nutzer beispielsweise nach „Vogelbeobachtungs-App“ sucht, könnte er „wütende Vögel“ herunterladen – aber das war natürlich nicht seine Absicht. Eine solche App kann die Downloadrate verbessern, aber die Anforderungen des Nutzers bleiben letztlich unbefriedigt.

Regel 36: Feedbackpositionen mit Positionsfunktionen vermeiden

Die Position der Inhalte wirkt sich erheblich darauf aus, wie wahrscheinlich es ist, dass der Nutzer damit interagiert. Wenn Sie eine App an der ersten Position platzieren, wird sie häufiger angeklickt und Sie können sich also davon überzeugen, dass sie wahrscheinlicher angeklickt wird. Eine Möglichkeit ist, Positionsmerkmale, d.h. Elemente zur Position des Inhalts auf der Seite, hinzuzufügen. Sie trainieren Ihr Modell mit Positionsmerkmalen, die dann lernen, zum Beispiel das Element "1stposition" zu gewichten. Ihr Modell bewertet andere Faktoren für Beispiele mit „1stposition=true“ also weniger. Bei der Bereitstellung weisen Sie dann keine Instanzen dem Positionsfeature zu oder Sie weisen allen das gleiche Standardfeature zu, da Sie Kandidaten bewerten, bevor Sie die Reihenfolge festgelegt haben, in der sie angezeigt werden sollen.

Beachten Sie, dass es wichtig ist, alle Positionsmerkmale aufgrund dieser Asymmetrie zwischen Training und Tests etwas vom Rest des Modells zu trennen. Idealerweise ist das Modell die Summe einer Funktion der Positionsmerkmale und einer Funktion der übrigen Features. Beispielsweise sollten Sie die Positionsmerkmale nicht mit Dokumentmerkmalen verknüpfen.

Regel Nr. 37: Verschiebungs-/Bereitstellungsverzerrung messen.

Im Allgemeinen können mehrere Ursachen für Abweichungen auftreten. Darüber hinaus können Sie es in mehrere Teile unterteilen:

  • Der Unterschied zwischen der Leistung der Trainingsdaten und der Holdout-Daten. Im Allgemeinen ist dieser Fehler immer vorhanden und nicht immer schlecht.
  • Der Unterschied zwischen der Leistung der Holdout-Daten und der Daten vom nächsten Tag. Auch dies wird immer vorhanden sein. Sie sollten Ihre Regularisierung optimieren, um die Leistung am nächsten Tag zu maximieren. Große Leistungsabfälle zwischen Holdout- und Daten für den nächsten Tag können jedoch darauf hinweisen, dass einige Features zeitabhängig sind und die Modellleistung beeinträchtigen können.
  • Der Unterschied zwischen der Leistung der Daten des nächsten Tages und der Live-Daten. Wenn Sie ein Modell auf ein Beispiel in den Trainingsdaten und dasselbe Beispiel bei der Bereitstellung anwenden, sollten Sie genau das gleiche Ergebnis erhalten (siehe Regel Nr. 5). Eine Diskrepanz deutet hier auf einen technischen Fehler hin.

ML-Phase III: Verlangsamtes Wachstum, Optimierung: optimierte Modelle und komplexe Modelle

Es gibt bestimmte Anzeichen dafür, dass die zweite Phase fast abgeschlossen ist. Zunächst sinkt der monatliche Gewinn. Zwischen den Messwerten werden Sie Kompromisse eingehen: Sie werden einen Anstieg sehen und andere bei einigen Tests. Hier wird es interessant. Da die Ergebnisse nicht so einfach zu erreichen sind, muss das maschinelle Lernen ausgefeilter werden. Hinweis: Dieser Abschnitt enthält mehr Regeln für den blauen Himmel als die vorherigen Abschnitte. Wir haben festgestellt, dass viele Teams die fröhlichen Zeiten des maschinellen Lernens von Phase I und Phase II durchlaufen. Sobald Phase III erreicht ist, müssen die Teams ihren eigenen Pfad finden.

Regel 38: Verschwenden Sie keine Zeit mit neuen Funktionen, wenn nicht ausgerichtete Ziele zum Problem geworden sind.

Ihr Analyseniveau wird sich mit den Problemen befassen, die außerhalb der Ziele Ihres aktuellen Systems für maschinelles Lernen liegen. Wie bereits erwähnt, müssen Sie entweder Ihr Ziel oder Ihre Produktziele ändern, falls die Produktziele nicht durch das vorhandene algorithmische Ziel abgedeckt werden. Sie können beispielsweise Klicks, +1 und Downloads optimieren, aber Entscheidungen zur Einführung teilweise auf menschliche Prüfer anwenden.

Regel 39: Einführungsentscheidungen sind ein Anhaltspunkt für langfristige Produktziele.

Alice hat eine Idee, den logistischen Verlust der Vorhersage von Installationen zu reduzieren. Sie fügt eine Funktion hinzu. Der logistische Verlust geht zurück. Bei einem Live-Test sieht sie, Beim Start einer Besprechung zur Produkteinführung besteht jedoch ein Rückgang um 5%. Das Team möchte das Modell nicht einführen. Alice ist enttäuscht, weiß aber jetzt, dass Entscheidungen über die Einführung von mehreren Kriterien abhängen, von denen nur einige direkt mit ML optimiert werden können.

Tatsache ist, dass die reale Welt keine Kerker und Drachen ist. Es gibt keine „Trefferpunkte“, die den Zustand deines Produkts angeben. Das Team muss die gesammelten Statistiken nutzen, um zu prognostizieren, wie gut das System in der Zukunft sein wird. Sie müssen sich um Interaktionen, aktive Nutzer pro Tag, 30 aktive Nutzer pro Tag, Umsatz und Return on Investment des Werbetreibenden kümmern. Diese Messwerte, die auch in A/B-Tests selbst messbar sind, sind nur ein Indikator für langfristige Ziele: Nutzer zufriedenstellen, mehr Nutzer gewinnen, Partner und Gewinn erreichen. Selbst dann könnten Sie Proxys für ein nützliches, hochwertiges Produkt und ein florierendes Unternehmen in fünf Jahren in Betracht ziehen.

Die einzigen einfachen Entscheidungen über den Start sind, wenn alle Messwerte besser werden oder zumindest nicht schlechter werden. Wenn das Team zwischen einem ausgefeilten Algorithmus für maschinelles Lernen und einer einfachen Heuristik wählen kann und die einfache Heuristik bei allen diesen Messwerten bessere Ergebnisse liefert, sollte sie die Heuristik wählen. Außerdem gibt es kein explizites Ranking aller möglichen Messwerte. Betrachten Sie insbesondere die folgenden zwei Szenarien:

Testen Täglich aktive Nutzer Umsatz/Tag
A 1 Million 4 Mio. $
B 2 Millionen 2 Mio. $

Wenn das aktuelle System A ist, ist es unwahrscheinlich, dass das Team zu B wechselt. Wenn das aktuelle System B ist, würde das Team wahrscheinlich nicht zu A wechseln. Dies scheint mit dem rationalen Verhalten in Konflikt zu stehen. Vorhersagen von sich ändernden Messwerten können jedoch schwankt oder auch nicht, sodass mit jeder Änderung ein großes Risiko verbunden ist. Jeder Messwert deckt ein gewisses Risiko ab, mit dem sich das Team befasst.

Darüber hinaus deckt kein Messwert das oberste Anliegen des Teams ab: „Wo wird mein Produkt in fünf Jahren sein?“

Im Gegensatz dazu bevorzugen Einzelpersonen eher ein Ziel, das sie direkt optimieren können. Die meisten Tools für maschinelles Lernen bevorzugen eine solche Umgebung. Ein Entwickler, der neue Features ausstellt, kann in einer solchen Umgebung einen kontinuierlichen Strom von Einführungen erhalten. Es gibt eine Art von maschinellem Lernen, die mit mehreren Zielen verbunden ist und dieses Problem angeht. Beispielsweise können Sie ein Problem mit der Einschränkungszufriedenheit formulieren, das für jeden Messwert eine Untergrenze hat und eine lineare Kombination von Messwerten optimiert. Aber selbst dann sind nicht alle Messwerte einfach als Machine-Learning-Ziele geeignet. Wenn ein Dokument angeklickt oder eine App installiert wird, liegt das daran, dass der Inhalt angezeigt wurde. Aber es ist viel schwieriger herauszufinden, warum ein Nutzer deine Website besucht. Wie der Erfolg einer Website als Ganzes vorhergesagt werden kann, hängt von der KI-Komplettlösung ab. Dies gilt ebenso für das maschinelle Sehen oder die Verarbeitung natürlicher Sprache.

Regel Nr. 40: Ensembles einfach halten

Einheitliche Modelle, die unbearbeitete Merkmale annehmen und den Inhalt direkt in eine Rangfolge bringen, sind die einfachste Modelle zur Fehlerbehebung und zu verstehen. Ein Ensemble von Modellen (ein „Modell“, das die Punktzahlen anderer Modelle kombiniert) kann jedoch besser funktionieren. Zur Vereinfachung sollte jedes Modell entweder ein Ensemble sein, das nur die Eingabe anderer Modelle verwendet, oder ein Basismodell, das viele Merkmale enthält, aber nicht beides. Wenn Sie Modelle zusätzlich zu anderen Modellen trainieren, die separat trainiert werden, kann das Kombinieren ein schlechtes Verhalten zur Folge haben.

Verwenden Sie ein einfaches Modell für Ensemble, das nur die Ausgabe Ihrer Basismodelle als Eingaben verwendet. Außerdem möchten Sie Attribute für diese Ensemble-Modelle erzwingen. Beispielsweise sollte eine Erhöhung des Werts, der von einem Basismodell erzeugt wurde, den Wert des Ensembles nicht verringern. Außerdem ist es am besten, wenn die eingehenden Modelle semantisch interpretierbar sind (z. B. kalibriert), damit Änderungen der zugrunde liegenden Modelle das Ensemble-Modell nicht verwechseln. Erzwingen Sie außerdem, dass eine Erhöhung der vorhergesagten Wahrscheinlichkeit für einen zugrunde liegenden Klassifikator die vorhergesagte Wahrscheinlichkeit des Ensembles nicht verringert.

Regel Nr. 41: Suchen Sie bei Leistungspraktiken nach qualitativ neuen Informationsquellen, die vorhandene Signale ergänzen, anstatt sie zu verfeinern.

Sie haben einige demografische Informationen über den Nutzer hinzugefügt. Sie haben einige Informationen zu den Wörtern im Dokument hinzugefügt. Sie haben die Vorlagenanalyse durchlaufen und die Regularisierung abgestimmt. In den letzten Quartalen haben Sie Ihre wichtigsten Messwerte um nicht mehr als 1% verbessert. Wie geht es jetzt weiter?

Es ist an der Zeit, mit dem Aufbau der Infrastruktur für radikale unterschiedliche Features zu beginnen, z. B. den Verlauf von Dokumenten, auf die dieser Nutzer im letzten Tag, in der letzten Woche oder im letzten Jahr zugegriffen hat, oder Daten aus einer anderen Property. Verwenden Sie stattdessen Wikidata-Entitäten oder interne Daten Ihres Unternehmens (z. B. den Knowledge Graph von Google). Verwenden Sie Deep Learning. Passen Sie die Erwartungen im Hinblick auf den Return on Investment an. Wie bei jedem Entwicklerprojekt müssen Sie die Vorteile, die mit dem Hinzufügen neuer Features erzielt werden, und den Kosten der höheren Komplexität abwägen.

Regel Nr. 42: Diversität, Personalisierung oder Relevanz dürften nicht mit der Beliebtheit korrelieren, wie Sie denken.

Die Vielfalt der Inhalte kann viele Bedeutungen haben, wobei die Vielfalt der Quellen eine der häufigsten ist. Die Personalisierung impliziert, dass jeder Nutzer seine eigenen Ergebnisse erhält. Die Relevanz impliziert, dass die Ergebnisse für eine bestimmte Abfrage für diese Abfrage besser geeignet sind als andere Abfragen. Daher werden alle drei Attribute als unterschiedlich definiert.

Das Problem ist, dass der gewöhnliche Weg schwer zu übertreffen ist.

Wenn mit Ihrem System Klicks, die Zeitdauer, angesehene Videos, +1-Empfehlungen, erneutes Teilen usw. gemessen werden, messen Sie die Beliebtheit der Inhalte. Teams versuchen manchmal, ein persönliches Modell mit Vielfalt zu erlernen. Zur Personalisierung werden Funktionen hinzugefügt, mit denen das System personalisiert werden kann (einige Merkmale, die das Interesse des Nutzers repräsentieren) oder diversifiziert ist (Merkmale, die angeben, ob dieses Dokument Gemeinsamkeiten mit anderen Dokumenten aufweist, z. B. Autor oder Inhalt). Dabei wird festgestellt, dass diese Features weniger Gewicht (oder manchmal ein anderes Zeichen) erhalten als erwartet.

Diversität, Personalisierung oder Relevanz sind hiervon ausgenommen. Wie in der vorherigen Regel erwähnt, können Sie die Nachbearbeitung nutzen, um die Vielfalt oder Relevanz zu erhöhen. Wenn Sie eine Steigerung der langfristigen Ziele feststellen, können Sie angeben, dass Vielfalt/Relevanz abgesehen von der Beliebtheit wertvoll ist. Sie können dann entweder die Weiterverarbeitung fortsetzen oder das Ziel je nach Vielfalt oder Relevanz direkt ändern.

Regel Nr. 43: Deine Freunde haben in der Regel verschiedene Produkte. Ihre Interessen sind meist nicht darauf zugeschnitten.

Die Teams bei Google sind stark auf die Idee gekommen, ein Modell vorherzusehen, das die Verbindung in einem Produkt vorhersagt und darauf einwandfrei funktioniert. Deine Freunde sind, wer sie sind. Andererseits habe ich beobachtet, dass einige Teams Probleme mit Personalisierungsfunktionen über Produktbereiche hinweg haben. Ja, das sollte funktionieren. Derzeit scheint das nicht der Fall zu sein. Manchmal funktionierte es, indem Rohdaten aus einer Property verwendet wurden, um das Verhalten für eine andere vorherzusagen. Es kann auch hilfreich sein zu wissen, dass ein Nutzer einen Verlauf in einer anderen Property hat. Beispielsweise kann die Präsenz von Nutzeraktivitäten auf zwei Produkten an sich schon ein Anzeichen dafür sein.

Es gibt sowohl bei Google als auch extern viele Dokumente zum maschinellen Lernen.

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, Lia Yani Vielen Dank an Kristen Lefevre, Suddha Basu und Chris Berg, die bei einer früheren Version geholfen haben. Alle Fehler, Auslassungen oder (gerade!) unpopuläre Meinungen gehören mir.

Anhang

In diesem Dokument finden Sie zahlreiche Verweise auf Google-Produkte. Im Folgenden finden Sie eine kurze Beschreibung der häufigsten Beispiele.

YouTube im Überblick

YouTube ist ein Streaming-Videodienst. Sowohl die YouTube Video Next- als auch die YouTube-Startseite nutzen ML-Modelle, um Videoempfehlungen zu ordnen. Unter „Nächstes Video“ werden Videos empfohlen, die sich nach dem aktuellen Video ansehen können. Auf der Startseite werden Nutzern Videos empfohlen, die die Startseite aufrufen.

Google Play

Google Play hat viele Modelle, die eine Vielzahl von Problemen lösen. Bei Google Play, der Google Play-Startseite sowie personalisierten Empfehlungen und Apps, die auch selbst installiert wurden, kommt maschinelles Lernen zum Einsatz.

Google+ Übersicht

Google Plus nutzte maschinelles Lernen in einer Vielzahl von Situationen: Ranking von Beiträgen im "Stream" von Beiträgen, die von Nutzern gesehen wurden, Rankings von "Angesagte Beiträge" (Beiträge, die derzeit sehr beliebt sind), Rankings von bekannten Personen usw. Google+ hat 2019 alle privaten Konten geschlossen und am 6. Juli 2020 durch Google Currents für Geschäftskonten ersetzt.