Regeln des maschinellen Lernens:

Best Practices für ML-Engineering

Martin Zinkevich

Dieses Dokument soll Nutzern mit Grundkenntnissen im Bereich maschinelles Lernen dabei helfen, die Vorteile der Best Practices von Google für maschinelles Lernen zu nutzen. Sie stellt einen Stil für maschinelles Lernen dar, ähnlich dem Google C++ Style Guide und anderen beliebten Leitfäden zum praktischen Programmieren. Wenn Sie einen Kurs in maschinellem Lernen absolviert oder ein maschinell erlerntes Modell erstellt oder daran gearbeitet haben, haben Sie die erforderlichen Kenntnisse, um dieses Dokument zu lesen.

Martin Zinkevich stellt 10 seiner Lieblingsregeln des maschinellen Lernens vor. Dann lies weiter und sieh dir alle 43 Regeln an.

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 „Über Katzen“ oder „Nicht über Katzen“ klassifizieren möchten.
  • Label: Eine Antwort auf eine Vorhersageaufgabe, entweder die von einem System für maschinelles Lernen erzeugte Antwort oder die richtige Antwort aus Trainingsdaten. Das Label für eine Webseite kann beispielsweise „über Katzen“ sein.
  • Funktion: Eine Eigenschaft einer Instanz, die in einer Vorhersageaufgabe verwendet wird. Beispielsweise kann eine Webseite die Funktion „enthält das Wort ‚Katze‘“ haben.
  • Funktionsspalte: Eine Reihe verwandter Funktionen, z. B. alle möglichen Länder, in denen Nutzer leben können. Ein Beispiel kann ein oder mehrere Merkmale in einer Feature-Spalte haben. „Funktionsspalte“ ist die Google-spezifische Terminologie. Eine Featurespalte wird im VW-System (bei Yahoo/Microsoft) als „Namespace“ oder als Feld 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 das Modell dann, um Vorhersagen zu treffen.
  • Messwert: Eine Zahl, die für Sie wichtig ist. Kann direkt optimiert werden oder nicht.
  • Ziel: Ein Messwert, den Ihr Algorithmus zu optimieren versucht.
  • Pipeline: Die Infrastruktur, die einen Algorithmus für maschinelles Lernen umgibt. Umfasst das Erfassen der Daten vom Front-End, das Einfügen in Trainingsdatendateien, das Trainieren eines oder mehrerer Modelle und das Exportieren der Modelle in die Produktion.
  • Klickrate (Click-through-Rate, CTR) – Prozentsatz der Besucher einer Webseite, die auf einen Link in einer Anzeige klicken.

Überblick

Um tolle Produkte herzustellen:

Ist maschinelles Lernen ein guter Entwickler und nicht ein großartiger Experte für maschinelles Lernen, den Sie nicht sind?

Die meisten Probleme, mit denen Sie konfrontiert werden werden, sind technische Probleme. Trotz aller Ressourcen eines kompetenten ML-Experten werden die meisten Gewinne durch hervorragende Funktionen und nicht durch exzellente Algorithmen für maschinelles Lernen erzielt. Der grundlegende Ansatz lautet also:

  1. Achten Sie darauf, dass Ihre Pipeline durchgängig einwandfrei funktioniert.
  2. Beginnen Sie mit einem vernünftigen Ziel.
  3. Vernünftige Funktionen hinzufügen
  4. Stellen Sie sicher, dass Ihre Pipeline stabil bleibt.

Dieser Ansatz funktioniert über einen langen Zeitraum gut. Weichen Sie von diesem Ansatz nur dann ab, wenn es keine einfacheren Tricks gibt, um weiterzukommen. Mehr Komplexität verlangsamt zukünftige Releases.

Sobald Sie mit den einfachen Tricks vertraut sind, wird modernstes maschinelles Lernen möglicherweise in Zukunft für Sie infrage kommen. Weitere Informationen finden Sie in Phase III der ML-Projekte.

Dieses Dokument ist wie folgt aufgebaut:

  1. Der erste Teil soll Ihnen dabei 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. Im dritten Teil geht es um das Starten und Iterieren, während Sie Ihrer Pipeline neue Features hinzufügen, wie Sie Modelle bewerten und Abweichungen zwischen Training und Bereitstellung bewerten.
  4. Im letzten Teil geht es darum, was zu tun ist, wenn Sie ein Plateau erreichen.
  5. Anschließend gibt es eine Liste ähnlicher Arbeiten und einen Anhang mit einigen Hintergrundinformationen zu den Systemen, die in diesem Dokument häufig als Beispiele verwendet werden.

Ohne maschinelles Lernen

Regel 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 nehmen und dann das Modell für ein neues Produkt optimieren. Dies wird jedoch wahrscheinlich die grundlegende heuristics unterdurchschnittlichen. Wenn Sie glauben, dass Sie durch maschinelles Lernen einen 100 % Boost erhalten, dann wird Ihnen eine Heuristik die Hälfte der Strecke dorthin gelingen.

Wenn Sie beispielsweise das Ranking von Apps in einem App-Marktplatz festlegen, können Sie die Installationsrate oder die Anzahl der Installationen als Heuristik verwenden. Wenn Sie Spam erkennen, filtern Sie Publisher heraus, die bereits Spam versendet haben. Scheuen Sie sich auch nicht, menschliche Änderungen vorzunehmen. Wenn Sie Kontakte ordnen müssen, ordnen Sie die zuletzt verwendeten Kontakte am höchsten (oder sogar in alphabetischer Reihenfolge). Wenn maschinelles Lernen für Ihr Produkt nicht unbedingt erforderlich ist, sollten Sie es erst einsetzen, wenn Sie Daten haben.

Regel 2: Entwerfen und implementieren Sie zunächst Metriken.

Bevor Sie die Funktionen Ihres ML-Systems formalisieren, sollten Sie so viel wie möglich in Ihrem aktuellen System verfolgen. Tun Sie dies aus folgenden Gründen:

  1. Es ist einfacher, früher die Zustimmung der Systemnutzer zu erhalten.
  2. Wenn Sie der Meinung sind, dass dies in Zukunft ein Problem darstellen könnte, ist es besser, jetzt Verlaufsdaten zu erhalten.
  3. Wenn Sie bei der Entwicklung Ihres Systems die Messwertinstrumentierung berücksichtigen, werden Sie in Zukunft besser vorgehen. Insbesondere möchten Sie nicht, dass Sie in Logs nach Strings suchen müssen, um Ihre Messwerte zu instrumentieren.
  4. Sie werden feststellen, was sich ändert und was unverändert bleibt. Angenommen, Sie möchten die an einem Tag aktiven Nutzer direkt optimieren. Während der frühen Änderungen des Systems werden Sie jedoch möglicherweise feststellen, dass sich dieser Messwert nicht spürbar durch drastische Änderungen der Nutzererfahrung merklich verändert.

Das Google Plus-Team misst die Anzahl der Seitenaufrufe pro Lesevorgang, erneutes Teilen pro Lesevorgang, plus eins pro Lesevorgang, Kommentare/gelesen, Kommentare pro Nutzer, erneut geteilte Inhalte pro Nutzer usw., um zu ermitteln, ob ein Beitrag zum Zeitpunkt der Bereitstellung geeignet ist. Wichtig ist auch ein Test-Framework, in dem Sie Nutzer in Buckets gruppieren und Statistiken nach Tests aggregieren können. Siehe Regel 12.

Indem Sie sich freier beim Erfassen von Messwerten umsehen, erhalten Sie ein umfassenderes Bild Ihres Systems. Haben Sie ein Problem festgestellt? Fügen Sie einen Messwert hinzu, um ihn zu verfolgen. Haben Sie sich über eine quantitative Änderung beim letzten Release gefreut? Fügen Sie einen Messwert hinzu, um ihn zu verfolgen.

Regel 3: Maschinelles Lernen hat Vorrang vor komplexen Heuristiken

Eine einfache Heuristik kann Ihr Produkt zum Verkauf bringen. Eine komplexe Heuristik ist uninteressant. Sobald Sie Daten haben und eine grundlegende Vorstellung davon haben, was Sie erreichen möchten, können Sie mit maschinellem Lernen fortfahren. Wie bei den meisten Aufgaben der Softwareentwicklung möchten Sie sicher sein, dass Sie Ihren Ansatz kontinuierlich aktualisieren, unabhängig davon, ob es sich um ein Heuristik- oder ein maschinell erlerntes Modell handelt. Sie werden feststellen, dass das maschinell erlernte Modell einfacher zu aktualisieren und zu pflegen ist (siehe Regel Nr. 16).

ML-Phase I: Ihre erste Pipeline

Bei Ihrer ersten Pipeline können Sie sich auf die Systeminfrastruktur konzentrieren. Es macht zwar Spaß, über all die fantasievollen Funktionen des maschinellen Lernens nachzudenken, aber es wird schwierig sein, herauszufinden, was passiert, wenn Sie nicht zuerst auf Ihre Pipeline vertrauen.

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

Das erste Modell bietet Ihrem Produkt den größten Boost. Es muss also nicht besonders schick sein. Es werden jedoch viel mehr Infrastrukturprobleme auftreten, als Sie erwarten. Bevor Sie Ihr leistungsfähiges neues ML-System verwenden können, müssen Sie Folgendes bestimmen:

  • Beispiele für Ihren Lernalgorithmus
  • Ein erster Schnitt zur Bedeutung von „gut“ und „schlecht“ für Ihr System.
  • So integrieren Sie Ihr Modell in Ihre Anwendung. Sie können das Modell entweder live anwenden oder es offline anhand von Beispielen vorab berechnen und die Ergebnisse in einer Tabelle speichern. Sie haben beispielsweise die Möglichkeit, Webseiten vorzuklassifizieren und die Ergebnisse in einer Tabelle zu speichern, aber Sie möchten Chatnachrichten live klassifizieren.

Durch die Auswahl einfacher Funktionen können Sie einfacher sicherstellen, dass:

  • Die Funktionen erreichen deinen Lernalgorithmus ordnungsgemäß.
  • Das Modell lernt angemessene Gewichtungen.
  • Die Features erreichen Ihr Modell korrekt auf dem Server.

Sobald Sie ein System haben, das diese drei Dinge zuverlässig erledigt, haben Sie den Großteil der Arbeit erledigt. Ihr einfaches Modell bietet Ihnen Basismesswerte und ein Basisverhalten, mit dem Sie komplexere Modelle testen können. Einige Teams streben eine „neutrale“ erste Einführung an: eine erste, bei der die Vorteile des maschinellen Lernens ausdrücklich herabgestuft werden, 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 es herum testen können. Insbesondere:

  1. Testen Sie, wie Sie Daten in den Algorithmus einarbeiten. Prüfen Sie, ob die zu füllenden Featurespalten gefüllt sind. Sofern die Privatsphäre dies zulässt, prüfen Sie die Eingabe in den Trainingsalgorithmus manuell. Vergleichen Sie nach Möglichkeit Statistiken in Ihrer Pipeline mit Statistiken für dieselben Daten, die an anderer Stelle verarbeitet wurden.
  2. Testen Sie das Abrufen von Modellen aus dem Trainingsalgorithmus. Achten Sie darauf, dass das Modell in Ihrer Trainingsumgebung die gleiche Punktzahl wie das Modell in Ihrer Bereitstellungsumgebung gibt (siehe Regel 37).

Maschinelles Lernen hat ein Element der Unvorhersehbarkeit. Daher sollten Sie Tests für den Code zum Erstellen von Beispielen für Training und Bereitstellung haben 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: Seien Sie beim Kopieren von Pipelines vorsichtig im Hinblick auf gelöschte Daten.

Häufig erstellen wir eine Pipeline, indem wir eine vorhandene Pipeline kopieren (z.B. Cargo Cult Programming) und die alte Pipeline löscht Daten, die wir für die neue Pipeline benötigen. Beispielsweise werden ältere Beiträge der Google Plus-Pipeline für angesagte Beiträge verwendet, da versucht wird, das Ranking neuer Beiträge zu ermitteln. Diese Pipeline wurde kopiert und für den Google Plus-Stream verwendet. Dort sind ältere Beiträge noch aussagekräftig, alte Beiträge wurden jedoch noch verworfen. Ein weiteres gängiges Muster besteht darin, nur Daten zu protokollieren, die der Nutzer gesehen hat. Daher sind diese Daten nutzlos, wenn wir modellieren möchten, warum ein bestimmter Beitrag von dem Nutzer nicht gesehen wurde, da alle negativen Beispiele verworfen wurden. Ein ähnliches Problem ist bei Google Play aufgetreten. Während der Arbeit an der Play Apps-Startseite wurde eine neue Pipeline erstellt, die auch Beispiele von der Landingpage für Play Spiele ohne eine Funktion enthielt, um zu unterscheiden, woher die einzelnen Beispiele stammen.

Regel 7: Heuristiken in Features umwandeln oder extern verarbeiten

Normalerweise sind die Probleme, die durch maschinelles Lernen zu lösen versucht, nicht ganz neu. Es gibt bereits ein System für das Ranking, die Klassifizierung oder das Problem, das Sie lösen möchten. Das bedeutet, dass es eine Reihe von Regeln und Heuristiken gibt. Dieselben Heuristiken können Sie nutzen, wenn Sie sie mit maschinellem Lernen optimieren. Ihre Heuristiken sollten aus zwei Gründen auf die vorhandenen Informationen zurückgreifen. Erstens verläuft der Übergang zu einem maschinell gelernten System reibungsloser. Zweitens enthalten diese Regeln eine gewisse Intuition in Bezug auf das System, die Sie nicht verwerfen möchten. Es gibt vier Möglichkeiten, eine vorhandene Heuristik zu verwenden:

  • Vorverarbeiten mit der Heuristik. Wenn die Funktion unglaublich toll ist, ist dies eine Option. Wenn beispielsweise der Absender in einem Spamfilter bereits auf die schwarze Liste gesetzt wurde, versuchen Sie nicht neu zu erfahren, was "auf schwarzer Liste" bedeutet. Blockieren Sie die Nachricht. Dieser Ansatz eignet sich am besten für binäre Klassifizierungsaufgaben.
  • Erstellen Sie eine Funktion. Es ist toll, ein Feature direkt aus der Heuristik zu erstellen. Wenn Sie beispielsweise eine Heuristik zum Berechnen eines Relevanzwerts für ein Abfrageergebnis verwenden, können Sie den Wert als Wert eines Features einbeziehen. Später können Sie den Wert mithilfe von Techniken des maschinellen Lernens massieren (z. B. in einen endlichen Satz diskreter Werte umwandeln oder mit anderen Merkmalen kombinieren), aber zuerst den von der Heuristik erzeugten Rohwert verwenden.
  • Die Roheingaben der Heuristik minen Wenn es für Apps eine Heuristik gibt, die die Anzahl der Installationen, die Anzahl der Zeichen im Text und den Wochentag kombiniert, sollten Sie diese Teile auseinanderziehen und diese Eingaben separat in den Lernprozess einspeisen. Hier finden Sie einige Techniken, die für Gruppen gelten (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 versuchen, die Anzahl der Downloads zu maximieren, aber auch hochwertige Inhalte benötigen, könnten 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.

Berücksichtigen Sie die zusätzliche Komplexität, wenn Sie Heuristiken in einem ML-System verwenden. Die Verwendung alter Heuristiken in Ihrem neuen Algorithmus für maschinelles Lernen kann dabei helfen, einen reibungslosen Übergang zu erreichen. Überlegen Sie sich jedoch, ob es einen einfacheren Weg gibt, diesen Effekt zu erzielen.

Monitoring

Achten Sie im Allgemeinen auf eine gute Hygiene bei Benachrichtigungen, z. B. indem Sie Benachrichtigungen umsetzbar machen und eine Dashboard-Seite haben.

Regel 8: Informieren Sie sich über die Aktualitätsanforderungen Ihres Systems.

Wie stark beeinträchtigt die Leistung, wenn Sie ein Modell haben, 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 das Modell einen Tag lang nicht aktualisiert wird und die Qualität Ihres Produkts erheblich beeinträchtigt, ist es sinnvoll, dass ein Entwickler es kontinuierlich beobachten kann. Die meisten Ad Serving-Systeme haben jeden Tag neue Anzeigen, die täglich aktualisiert werden müssen. Wenn beispielsweise das ML-Modell für die Google Play-Suche nicht aktualisiert wird, kann sich dies in weniger als einem Monat negativ auswirken. Einige Modelle für angesagte Beiträge in Google Plus haben keine Post-ID im Modell, sodass sie diese Modelle nur selten exportieren können. 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 Featurespalten zu Ihrem Modell hinzugefügt oder daraus entfernt werden.

Regel 9: Probleme vor dem Export von Modellen ermitteln.

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

Führen Sie vor dem Export des Modells Plausibilitätsprüfungen durch. Achten Sie insbesondere darauf, dass die Leistung des Modells im Hinblick auf ausgesetzte Daten angemessen ist. Wenn Sie Bedenken bezüglich der Daten haben, exportieren Sie kein Modell. Viele Teams, die kontinuierlich Modelle bereitstellen, prüfen vor dem Exportieren den Bereich unter der ROC-Kurve (oder AUC). Bei Problemen mit nicht exportierten Modellen ist eine E-Mail-Benachrichtigung erforderlich. Bei Problemen mit einem nutzerseitigen Modell hingegen ist möglicherweise eine Seite erforderlich. Daher ist es besser, abzuwarten, bevor sie sich auf die Nutzenden auswirken.

Regel 10: Achten Sie auf Fehler, bei denen lautlos Fehler aufgetreten sind.

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 passt sich entsprechend an, das Verhalten bleibt relativ gut und nimmt schrittweise ab. Manchmal stoßen Sie auf Tabellen, die schon Monate veraltet sind. Eine einfache Aktualisierung verbessert die Leistung mehr als jede andere Veröffentlichung in diesem Quartal. Die Abdeckung eines Features kann sich aufgrund von Implementierungsänderungen ändern: Eine Featurespalte könnte beispielsweise in 90% der Beispiele ausgefüllt und plötzlich auf 60% der Beispiele abfallen. Google Play hatte einmal einen Tisch, der 6 Monate lang veraltet war. Allein die Aktualisierung der Tabelle führte zu einem Anstieg der Installationsrate um 2 %. Wenn Sie Statistiken der Daten verfolgen und die Daten gelegentlich manuell überprüfen, können Sie diese Art von Fehlern reduzieren.

Regel 11: Weisen Sie Featurespalten Inhaber und Dokumentation zu.

Wenn das System groß ist und viele Featurespalten vorhanden sind, sollten Sie wissen, wer die einzelnen Featurespalten erstellt oder verwaltet. Wenn Sie feststellen, dass die Person, die eine Feature-Spalte versteht, den Raum verlässt, sorgen Sie dafür, dass jemand über die Informationen verfügt. Obwohl viele Merkmalspalten beschreibende Namen haben, ist eine detailliertere Beschreibung des Merkmals, seiner Herkunft und der erwarteten Hilfe hilfreich.

Ihr erstes Ziel

Sie haben viele Messwerte oder Messwerte in Bezug auf das System, das Sie interessiert, aber Ihr Algorithmus für maschinelles Lernen benötigt oft ein einziges Ziel, also eine Zahl, die der Algorithmus versucht, zu optimieren. Ich unterscheide hier zwischen Zielen und Messwerten: Ein Messwert ist eine Zahl, die Ihr System meldet, die wichtig sein kann oder nicht. Siehe auch Regel 2.

Regel 12: Denken Sie nicht zu viel darüber nach, 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 viele Messwerte, die für Sie wichtig sind und die Sie alle messen sollten (siehe Regel 2). Zu Beginn des maschinellen Lernprozesses werden Sie jedoch feststellen, dass sie immer weiter steigen, selbst diejenigen, die Sie nicht direkt optimieren. Angenommen, Ihnen geht es um die Anzahl der Klicks und die Verweildauer auf der Website. Wenn Sie die Anzahl der Klicks optimieren, steigt die aufgewendete Zeit wahrscheinlich länger.

Halten Sie es also einfach und überdenken Sie nicht zu viel darüber, verschiedene Messwerte in Einklang zu bringen, wenn Sie noch alle Messwerte problemlos erhöhen können. Ziehen Sie diese Regel jedoch nicht zu weit: 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 aber gegen die Einführung entscheiden, ist möglicherweise eine objektive Überarbeitung erforderlich.

Regel 13: Wählen Sie einen einfachen, beobachtbaren und zuordenbaren Messwert für Ihr erstes Ziel.

Oft wissen Sie nicht, was das eigentliche Ziel ist, aber wenn Sie sich die Daten und die Gegenüberstellung des alten und des neuen ML-Systems ansehen, stellen Sie fest, dass Sie das Ziel optimieren möchten. Außerdem können sich verschiedene Teammitglieder oft nicht auf die tatsächliche Zielsetzung einigen. Das ML-Ziel sollte leicht zu messen sein und ein Stellvertreter für das „wahre“ Ziel sein. Tatsächlich gibt es oft kein „wahres“ Ziel (siehe Regel 39). Trainieren Sie also mit dem einfachen ML-Ziel und erwägen Sie, eine Richtlinienebene hinzuzufügen, mit der Sie zusätzliche Logik (hoffentlich sehr einfache Logik) für das endgültige Ranking hinzufügen können.

Das einfachste Modell ist ein Nutzerverhalten, das direkt beobachtet und einer Aktion des Systems zugeordnet werden kann:

  • Wurde auf diesen eingestuften Link geklickt?
  • Wurde dieses bewertete Objekt heruntergeladen?
  • Wurde dieses mit einem Rang versehene Objekt weitergeleitet/beantwortet/per E-Mail gesendet?
  • Wurde dieses bewertete Objekt bewertet?
  • Wurde das gezeigte Objekt als Spam/Pornografie/anstößig gekennzeichnet?

Vermeiden Sie zunächst die Modellierung indirekter Effekte:

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

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

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

  • Sind die Nutzenden zufrieden mit dem Produkt?
  • Ist der Nutzer damit zufrieden?
  • Verbessert das Produkt das allgemeine Wohlbefinden der Nutzenden?
  • Wie wird sich dies auf den allgemeinen Gesundheitszustand des Unternehmens auswirken?

Das alles ist wichtig, aber auch unglaublich schwer zu messen. Verwenden Sie stattdessen Proxys: Wenn der Nutzer zufrieden ist, bleibt er länger auf der Website. Wenn die Nutzenden zufrieden sind, besucht sie die Website morgen noch einmal. Im Hinblick auf das Wohlergehen und die Gesundheit des Unternehmens ist menschliches Urteilsvermögen erforderlich, um ein maschinell erlerntes Ziel mit der Art des Produkts, das Sie verkaufen, und Ihrem Businessplan in Verbindung zu bringen.

Regel 14: Wenn Sie mit einem interpretierbaren Modell beginnen, wird das Debugging einfacher.

Lineare und logistische Regressionen sowie Poisson-Regression werden direkt durch ein probabilistisches Modell gestützt. Jede Vorhersage kann als Wahrscheinlichkeit oder als erwarteter Wert interpretiert werden. Dies vereinfacht die Fehlerbehebung als Modelle, die Ziele (Null-1-Verlust, verschiedene Scharnier-Verluste usw.) verwenden, die versuchen, die Klassifizierungsgenauigkeit oder Ranking-Leistung direkt zu optimieren. Wenn beispielsweise die Wahrscheinlichkeiten beim Training von den Wahrscheinlichkeiten abweichen, die direkt oder durch Untersuchung des Produktionssystems vorhergesagt wurden, könnte diese Abweichung auf ein Problem hinweisen.

Bei der linearen, logistischen oder Poisson-Regression gibt es Teilmengen der Daten, bei denen die durchschnittliche vorhergesagte Erwartung dem durchschnittlichen Label entspricht (1-Moment kalibriert oder nur kalibriert). Dies trifft auf die Annahme zu, dass Sie keine Regularisierung haben und Ihr Algorithmus konvergiert ist. Es gilt dann im Allgemeinen annähernd richtig. Wenn Sie ein Merkmal haben, das für jedes Beispiel entweder 1 oder 0 ist, wird der Satz von 3 Beispielen, bei denen dieses Merkmal 1 ist, kalibriert. Wenn Sie ein Feature für jedes Beispiel auf „1“ haben, wird der Satz aller Beispiele kalibriert.

Bei einfachen Modellen ist es einfacher, mit Feedbackschleifen umzugehen (siehe Regel 36). Häufig stützen wir uns auf diese probabilistischen Vorhersagen, um eine Entscheidung zu treffen. So werden z. B. Beiträge in absteigender Reihenfolge des erwarteten Werts (d. h. Wahrscheinlichkeit eines Klicks/Download usw.) eingeordnet. Denken Sie jedoch daran, dass bei der Auswahl des zu verwendenden Modells die Entscheidung wichtiger ist als die Wahrscheinlichkeit, dass die Daten aus dem Modell stammen (siehe Regel 27).

Regel 15: Trennen Sie Spam-Filterung und Qualitätsrang in einer Richtlinienebene.

Das Qualitätsranking ist eine Kunst, aber die Spamfilterung ist ein Krieg. Die Signale, anhand derer Sie qualitativ hochwertige Beiträge bestimmen, werden für diejenigen, die Ihr System verwenden, offensichtlich und sie werden ihre Beiträge so optimieren, dass sie diese Eigenschaften haben. Daher sollte sich Ihr Qualitätsranking auf das Ranking von Inhalten konzentrieren, die nach Treu und Glauben gepostet wurden. Sie sollten den „Qualitätsranking Learner“ für ein hohes Spam-Ranking nicht unterlegen. Ebenso sollten nicht jugendfreie Inhalte getrennt vom Qualitätsranking behandelt werden. Spamfilter ist etwas anderes. Sie müssen davon ausgehen, dass sich die Features, die Sie generieren müssen, ständig ändern werden. Oftmals gibt es offensichtliche Regeln, die du in das System einfügst. (Wenn ein Beitrag mehr als drei Spam-Stimmen hat, soll er nicht abgerufen werden usw.). Jedes erlernte Modell muss täglich aktualisiert werden, wenn nicht sogar schneller. Der Ruf des Erstellers der Inhalte wird eine große Rolle spielen.

Zu einem gewissen Grad muss die Ausgabe dieser beiden Systeme integriert werden. Beachten Sie, dass das Filtern von Spam in Suchergebnissen wahrscheinlich strenger sein sollte als das Filtern von Spam in E-Mails. Außerdem ist es eine übliche Praxis, Spam aus den Trainingsdaten für den Qualitätsklassifikator zu entfernen.

ML-Phase II: Feature Engineering

In der ersten Phase des Lebenszyklus eines Systems für maschinelles Lernen müssen die Trainingsdaten in das Lernsystem geladen, alle relevanten Messwerte instrumentiert werden und eine Bereitstellungsinfrastruktur erstellt werden. Nachdem Sie ein funktionierendes End-to-End-System mit instrumentierten Einheiten- und Systemtests haben, beginnt Phase II.

In der zweiten Phase gibt es eine Menge leicht hängender Früchte. Es gibt eine Vielzahl offensichtlicher Funktionen, die in das System übernommen werden können. Daher werden in der zweiten Phase des maschinellen Lernens so viele Features wie möglich einbezogen und auf intuitive Weise kombiniert. Während dieser Phase sollten alle Messwerte steigen. Es wird viele Markteinführungen geben und es ist ein guter Zeitpunkt, viele Entwickler zu gewinnen, die all die Daten zusammenführen können, die Sie zum Erstellen eines wirklich großartigen Lernsystems benötigen.

Regel 16: Einführung und Iteration einplanen

Erwarten Sie nicht, dass das Modell, an dem Sie gerade arbeiten, das letzte ist, das Sie einführen, oder dass Sie auch gar keine Modelle mehr einführen werden. Überlegen Sie daher, ob die Komplexität, die Sie mit dieser Einführung erhöhen, zukünftige Markteinführungen verlangsamen wird. Viele Teams haben seit Jahren ein Modell pro Quartal oder häufiger eingeführt. Es gibt drei grundlegende Gründe für die Einführung neuer Modelle:

  • Du entwickelst neue Funktionen.
  • Sie optimieren die Regularisierung und kombinieren alte Features auf neue Weise.
  • Sie stimmen das Ziel ab.

Unabhängig davon kann es gut sein, einem Modell etwas Liebe zu geben: Ein Blick auf die Dateneingabe in das Beispiel kann dabei helfen, sowohl neue als auch alte, defekte Signale zu finden. Überlegen Sie beim Erstellen Ihres Modells, wie einfach es ist, Features hinzuzufügen, 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 es möglich ist, zwei oder drei Kopien parallel laufen zu lassen. Und schließlich müssen Sie sich keine Gedanken darüber machen, ob Feature 16 von 35 in diese Version der Pipeline aufgenommen werden. Nächstes Quartal.

Regel 17: Beginnen Sie mit direkt beobachteten und gemeldeten Features und nicht mit erlernten Features.

Dieser Punkt mag kontrovers sein, vermeidet aber viele Fallstricke. Zuerst wird beschrieben, was ein erlerntes Feature ist. Ein erlerntes Feature ist ein Feature, das entweder von einem externen System (z. B. einem unbeaufsichtigten Clustering-System) oder vom Lernenden selbst (z. B. über ein faktorisiertes Modell oder Deep Learning) generiert wird. Beides kann nützlich sein, kann aber viele Probleme haben, sodass sie nicht im ersten Modell enthalten sein sollten.

Wenn Sie zum Erstellen eines Features ein externes System verwenden, denken Sie daran, dass das externe 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, ist es möglicherweise veraltet. Wenn Sie die Funktionen über das externe System aktualisieren, kann sich die Bedeutung ändern. Wenn Sie ein Feature über ein externes System bereitstellen, sollten Sie bedenken, dass dieser Ansatz sehr viel Sorgfalt erfordert.

Das Hauptproblem bei faktorisierten und tiefen Modellen besteht darin, dass sie nicht konvex sind. Daher gibt es keine Garantie dafür, dass eine optimale Lösung näherungsweise ermittelt oder gefunden werden kann. Außerdem können die lokalen Minima, die bei jeder Iteration gefunden werden, unterschiedlich sein. Durch diese Variation lässt sich nur schwer beurteilen, ob die Auswirkungen einer Änderung an Ihrem System aussagekräftig oder zufällig sind. Wenn Sie ein Modell ohne tiefe Features erstellen, können Sie eine hervorragende Basisleistung erzielen. Nachdem dieser Mindestwert erreicht ist, können Sie esoterische Ansätze ausprobieren.

Regel 18: Entdecke Inhalte mit Funktionen, 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 unter "Angesagte Beiträge" verwendet werden könnte, geben viele Nutzer +1, teilen ihn erneut oder kommentieren ihn, bevor er überhaupt unter "Angesagte Beiträge" erscheint. Wenn Sie dem Lernenden diese Statistiken zur Verfügung stellen, kann er neue Beiträge bewerben, für die er keine Daten im zu optimierenden Kontext hat. In den Videoempfehlungen von YouTube können die Anzahl der Aufrufe oder mehrere Aufrufe in der YouTube-Suche berücksichtigt werden. Dabei wird erfasst, wie oft ein Video nach einem anderen angesehen wurde. Sie können auch explizite Nutzerbewertungen verwenden. Wenn Sie schließlich eine Nutzeraktion als Label verwenden, kann es hilfreich sein, diese Aktion im Dokument in einem anderen Kontext zu sehen. All diese Funktionen ermöglichen es dir, neue Inhalte in einen Kontext zu bringen. Dabei geht es nicht um Personalisierung: Finden Sie zuerst heraus, ob jemand die Inhalte in diesem Kontext mag, und überlegen Sie sich dann, wem sie mehr oder weniger gefallen.

Regel 19: Verwenden Sie möglichst spezifische Funktionen.

Bei unzähligen Daten ist es einfacher, Millionen einfacher Funktionen zu erlernen als ein paar komplexe Funktionen. IDs der abgerufenen Dokumente und kanonische Abfragen bieten keine große Verallgemeinerung, stimmen jedoch das Ranking mit den Labels in Head-Abfragen überein. Scheuen Sie sich daher nicht vor Gruppen von Features, in denen jedes Feature für einen sehr kleinen Teil Ihrer Daten gilt. Die Gesamtabdeckung liegt jedoch bei über 90%. Mit der Regularisierung können Sie die Features entfernen, die auf zu wenige Beispiele zutreffen.

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

Es gibt verschiedene Möglichkeiten, Funktionen 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“.

Bei der Diskretisierung wird ein kontinuierliches Merkmal genommen und daraus viele diskrete Merkmale erstellt. Ziehen Sie ein fortlaufendes Feature wie das Alter in Betracht. Sie können ein Merkmal erstellen, das 1 ist, wenn das Alter unter 18 ist, ein anderes, 1, wenn das Alter zwischen 18 und 35 Jahre liegt, und so weiter. Denken Sie nicht zu viel über die Grenzen dieser Histogramme nach: Einfache Quantile haben die meiste Wirkung.

Kreuze kombinieren zwei oder mehr Featurespalten. Eine Featurespalte ist in der Terminologie von TensorFlow eine Reihe homogener Merkmale (z. B. {male, female}, {US, Canada, Mexico} usw.). Ein Kreuz ist eine neue Featurespalte mit Features, z. B. {male, female} × {US,Canada, Mexico}. Diese neue Featurespalte enthält das Element (männlich, Kanada). Wenn Sie TensorFlow verwenden und TensorFlow anweisen, diese Verknüpfung für Sie zu erstellen, wird dieses Feature (männlich, Kanada) in Beispielen für männliche Kanadier vorhanden sein. Beachten Sie, dass für das Lernen von Modellen mit drei, vier oder mehr grundlegenden Merkmalspalten riesige Datenmengen benötigt werden.

Kreuze, die sehr große Merkmalspalten erzeugen, können zu Überanpassung führen. Stellen Sie sich beispielsweise vor, dass Sie eine Art von Suche durchführen und eine Feature-Spalte mit Wörtern in der Abfrage und eine Feature-Spalte mit Wörtern im Dokument haben. Sie können diese mit einem Kreuz kombinieren, haben dann aber viele Funktionen (siehe Regel 21).

Für die Arbeit mit Text gibt es zwei Alternativen. Am drakonischsten ist das Punktprodukt. Ein Punktprodukt in seiner einfachsten Form zählt einfach die Anzahl der Wörter, die die Abfrage und das Dokument gemeinsam haben. Diese Funktion kann dann diskretisiert werden. Ein anderer Ansatz ist eine Schnittmenge: Daher haben wir ein Merkmal, das genau dann vorhanden ist, wenn das Wort "Pony" sowohl im Dokument als auch in der Abfrage vorhanden ist, und eine weitere Funktion, die genau dann vorhanden ist, wenn das Wort "the" sowohl im Dokument als auch in der Abfrage vorhanden ist.

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

Es gibt faszinierende Ergebnisse aus der statistischen Lerntheorie über den geeigneten Komplexitätsgrad eines Modells, aber diese Regel ist im Grunde alles, was Sie wissen müssen. Ich hatte Gespräche, in denen die Leute nicht gezweifelt haben, dass man aus tausend Beispielen etwas lernen kann oder dass man jemals mehr als eine Million Beispiele brauchen würde, weil sie in einer bestimmten Lernmethode stecken bleiben. Das Entscheidende ist, das Gelernte an die Größe Ihrer Daten anzupassen:

  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 beschriftete Beispiele haben, sollten Sie ein Punktprodukt zwischen Dokument- und Abfragefeatures, TF-IDF, und ein halbes Dutzend andere hochgradig von Menschen entwickelte Funktionen verwenden. 1.000 Beispiele, ein Dutzend Funktionen.
  2. Wenn Sie eine Million Beispiele haben, überschneiden Sie die Dokument- und Abfragefeaturespalten mithilfe der Regularisierung und möglicherweise der Featureauswahl. Dadurch erhalten Sie Millionen von Features, aber mit der Regularisierung werden Sie weniger haben. Zehn Millionen Beispiele, vielleicht hunderttausend Funktionen.
  3. Wenn Sie Milliarden oder Hunderte Milliarden Beispiele haben, können Sie die Featurespalten mit Dokument- und Abfragetokens verknüpfen, indem Sie Featureauswahl und Regularisierung verwenden. Sie haben eine Milliarde Beispiele und 10 Millionen Features. Die statistische Lerntheorie bietet selten enge Grenzen, bietet jedoch eine gute Orientierungshilfe für den Einstieg.

Verwenden Sie am Ende Regel 28, um zu entscheiden, welche Features verwendet werden sollen.

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

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

Berücksichtige die Abdeckung, wenn du überlegst, welche Funktionen du hinzufügen oder behalten möchtest. Wie viele Beispiele werden von der Funktion abgedeckt? Wenn Sie beispielsweise einige Personalisierungsfunktionen haben, aber nur 8% Ihrer Nutzer Personalisierungsfunktionen haben, ist diese nicht sehr effektiv.

Gleichzeitig können einige Funktionen ihr Gewicht übersteigen. Wenn Sie beispielsweise ein Feature haben, das nur 1% der Daten abdeckt, aber 90% der Beispiele mit dem Feature positiv sind, ist es eine großartige Funktion, die Sie hinzuzufügen.

Menschliche Analyse des Systems

Bevor Sie zur dritten Phase des maschinellen Lernens übergehen, sollten Sie sich auf etwas konzentrieren, das in keinem ML-Kurs behandelt wird: wie Sie ein vorhandenes Modell betrachten und verbessern können. Dies ist eher eine Kunst als eine Wissenschaft, aber es gibt einige Anti-Patterns, die Sie vermeiden sollten.

Regel 23: Sie sind kein typischer Endnutzer.

Dies ist wahrscheinlich der einfachste Weg für ein Team, sich ins Stocken zu bringen. Fishfooding (Verwendung eines Prototyps in Ihrem Team) und Dogfooding (Verwendung eines Prototyps innerhalb Ihres Unternehmens) hat zwar viele Vorteile, aber die Mitarbeiter sollten prüfen, ob die Leistung korrekt ist. Auch wenn eine Änderung, die offensichtlich schlecht ist, nicht angewendet werden sollte, sollte alles, was fast schon produktionsreif zu sein scheint, weiter getestet werden, entweder durch Bezahlung von Laien für die Beantwortung von Fragen auf einer Crowdsourcing-Plattform oder durch ein Live-Experiment mit echten Nutzern.

Dafür gibt es zwei Gründe. Zum einen sind Sie zu nah am Code. Möglicherweise suchen Sie nach einem bestimmten Aspekt der Beiträge oder Sie sind einfach zu emotional involviert (z.B. Bestätigungsverzerrung). Zweitens: Ihre Zeit ist zu wertvoll. Denken Sie an die Kosten für neun Entwickler, die in einem einstündigen Meeting sitzen, und überlegen Sie, wie viele beauftragte menschliche Labels, die auf einer Crowdsourcing-Plattform einkaufen, nach.

Wenn Sie Nutzerfeedback haben möchten, verwenden Sie UX-Methodiken. Erstellen Sie Nutzer Personas zu Beginn eines Prozesses (eine Beschreibung ist in Bill Buxtons Sketching User Experiences) und führen Sie später Usability-Tests durch (eine Beschreibung ist in Don’t Make Me Think von Steve Krug). Mit User Personas werden hypothetische Nutzende erstellt. Wenn Ihr Team beispielsweise ausschließlich männlich ist, kann es hilfreich sein, eine 35-jährige weibliche User Persona (mit entsprechenden Nutzerfunktionen) zu entwerfen und sich dann die Ergebnisse anzusehen, die damit erzielt werden, anstatt 10 Ergebnisse für männliche 25- bis 40-Jährige. Wenn Sie reale Personen dazu bringen, ihre Reaktionen auf Ihre Website (lokal oder remote) für Usability-Tests zu beobachten, erhalten Sie möglicherweise eine neue Perspektive.

Regel 24: Die 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 der Unterschiede zwischen den neuen Ergebnissen und der Produktion. Wenn Sie beispielsweise ein Ranking-Problem haben, führen Sie beide Modelle für eine Stichprobe von Abfragen im gesamten System aus und betrachten Sie die Größe der symmetrischen Differenz der Ergebnisse (gewichtet nach Ranking-Position). Wenn der Unterschied sehr gering ist, können Sie ohne Ausführen eines Tests feststellen, dass es nur wenige Ä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 qualitativ die Änderung qualitativ nachvollziehen. Achten Sie jedoch darauf, dass das System stabil ist. Achten Sie darauf, dass ein Modell beim Vergleich mit sich selbst eine geringe symmetrische Differenz (idealerweise null) aufweist.

Regel 25: Bei der Auswahl von Modellen hat praktikable Leistung Vorrang vor der Vorhersagekraft.

Ihr Modell versucht möglicherweise, die Klickrate vorherzusagen. Letztendlich ist jedoch die entscheidende Frage, was Sie mit dieser Vorhersage machen. Wenn Sie es für das Ranking von Dokumenten verwenden, ist die Qualität des endgültigen Rankings wichtiger als die Vorhersage selbst. Wenn Sie die Wahrscheinlichkeit vorhersagen, dass es sich bei einem Dokument um Spam handelt, und die Anzahl der blockierten Elemente dann unterschritten wird, ist die Genauigkeit der zulässigen Elemente wichtiger. In den meisten Fällen sollten sich die beiden Punkte einigen: Wenn sie sich nicht einig sind, bringt sie wahrscheinlich nur wenig Vorteile. Wenn es also eine Änderung gibt, die den Logverlust verbessert, aber die Leistung des Systems verschlechtert, sollten Sie nach einem anderen Feature suchen. Wenn dies häufiger auftritt, ist es an der Zeit, das Ziel Ihres Modells noch einmal zu überdenken.

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

Angenommen, Sie sehen ein Trainingsbeispiel, bei dem das Modell falsch ist. Bei einer Klassifizierungsaufgabe kann dieser Fehler falsch-positiv oder falsch-negativ sein. Bei einer Ranking-Aufgabe kann der Fehler ein Paar sein, bei dem eine positive Bewertung niedriger als eine negative eingestuft wurde. Der wichtigste Punkt ist, dass dies ein Beispiel ist, das das System für maschinelles Lernen weiß, dass es fehlerhaft ist, und das es gegebenenfalls beheben möchte. Wenn Sie dem Modell ein Feature zuweisen, mit dem der Fehler behoben werden kann, versucht das Modell, es zu verwenden.

Wenn Sie andererseits versuchen, ein Feature anhand von Beispielen zu erstellen, die das System nicht als Fehler einstuft, wird das Feature ignoriert. Angenommen, ein Nutzer sucht in der Play Apps-Suche nach "kostenlose Spiele". Angenommen, eines der besten Ergebnisse ist eine weniger relevante GAG-App. Sie erstellen also eine Funktion für „Gag Apps“. Wenn du jedoch die Anzahl der Installationen maximiert und Nutzer bei der Suche nach kostenlosen Spielen eine GAG-App installieren, hat diese Funktion nicht den gewünschten Effekt.

Wenn Sie Beispiele für Fehler haben, die das Modell falsch zugeordnet haben, suchen Sie nach Trends, die außerhalb Ihres aktuellen Feature-Sets liegen. Wenn das System beispielsweise längere Beiträge zurückgestuft hat, fügen Sie die Länge der Beiträge hinzu. Seien Sie nicht zu spezifisch. Wenn Sie die Länge des Beitrags hinzufügen möchten, versuchen Sie nicht zu erraten, was „lang“ bedeutet. Fügen Sie einfach ein Dutzend Features hinzu und das Modell entscheidet, was mit ihnen zu tun ist (siehe Regel 21). Dies ist der einfachste Weg, das gewünschte Ergebnis zu erhalten.

Regel 27: Versuchen Sie, das beobachtete unerwünschte Verhalten zu quantifizieren.

Einige Mitglieder Ihres Teams werden zunehmend frustriert mit Eigenschaften des Systems, die ihnen nicht gefallen und die nicht von der vorhandenen Verlustfunktion erfasst werden. An dieser Stelle sollten sie alles tun, um ihre Griffe in feste Zahlen umzuwandeln. Wenn sie beispielsweise der Meinung sind, dass zu viele „gag-Apps“ in der Play-Suche angezeigt werden, können Prüfer diese Apps von Prüfern identifizieren. Sie können in diesem Fall auch von Menschen gekennzeichnete Daten verwenden, da nur ein relativ kleiner Teil der Abfragen einen großen Teil des Traffics ausmacht. Wenn Ihre Probleme messbar sind, können Sie sie als Funktionen, Ziele oder Messwerte verwenden. Als Faustregel gilt: Zuerst messen, dann optimieren.

Regel 28: Identisches kurzfristiges Verhalten bedeutet nicht dasselbe langfristige Verhalten.

Angenommen, Sie haben ein neues System, das jede doc_id und exact_query prüft und dann die Klickwahrscheinlichkeit für jedes Dokument für jede Abfrage berechnet. Sie werden feststellen, dass sein Verhalten sowohl bei der Seite als auch bei den A/B-Tests fast identisch mit Ihrem aktuellen System ist. Da es so einfach ist, starten Sie es. Sie stellen jedoch fest, dass keine neuen Apps angezeigt werden. Woran liegt das? Da Ihr System nur ein Dokument basierend auf seinem eigenen Verlauf mit dieser Abfrage anzeigt, gibt es keine Möglichkeit zu erfahren, dass ein neues Dokument angezeigt werden sollte.

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

Abweichungen zwischen Training und Bereitstellung

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

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

Wir haben bei Google-Systemen für das maschinelle Lernen in der Produktion beobachtet, dass es Abweichungen zwischen Training und Bereitstellung gibt, die sich negativ auf die Leistung auswirken. Die beste Lösung besteht darin, sie explizit zu überwachen, damit System- und Datenänderungen nicht unbemerkt zu Verzerrungen führen.

Regel 29: Um sicherzustellen, dass Sie wie gewohnt trainieren, sollten Sie die bei der Bereitstellung verwendeten Funktionen speichern und diese Funktionen dann an ein Protokoll übertragen, um sie während des Trainings zu verwenden.

Selbst wenn Sie dies nicht für jedes Beispiel tun können, sollten Sie es nur für einen kleinen Bruchteil 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 überrascht von den Ergebnissen. Die YouTube-Startseite wurde bei der Bereitstellung auf Protokollierungsfunktionen umgestellt. Dies führte zu erheblichen Qualitätsverbesserungen und einer geringeren Codekomplexität. Viele Teams wechseln daher ihre Infrastruktur, während wir sprechen.

Regel 30: Lassen Sie die Stichprobendaten mit Gewichtung nicht willkürlich fallen!

Wenn Sie zu viele Daten haben, besteht die Versuchung, die Dateien 1 bis 12 zu nehmen und die Dateien 13 bis 99 zu ignorieren. Und genau das ist das Problem. Obwohl Daten, die dem Nutzer nie angezeigt wurden, gelöscht werden können, ist die Gewichtung nach Wichtigkeit für den Rest am besten. Bei der Wichtigkeitsgewichtung bedeutet das, dass Sie, wenn Sie Beispiel X mit einer Wahrscheinlichkeit von 30% untersuchen, eine Gewichtung von 10/3 zuweisen. Bei der Wichtigkeitsgewichtung bleiben alle in Regel 14 beschriebenen Kalibrierungseigenschaften erhalten.

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

Angenommen, Sie verknüpfen Dokument-IDs mit einer Tabelle, die Funktionen für diese Dokumente enthält (z. B. die Anzahl der Kommentare oder Klicks). Zwischen Trainings- und Bereitstellungszeit 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. Diese Art von Problem lässt sich am einfachsten vermeiden, indem Sie Features zum Zeitpunkt der Bereitstellung protokollieren (siehe Regel 32). Wenn sich die Tabelle nur langsam ändert, können Sie auch einen stündlichen oder täglichen Snapshot der Tabelle erstellen, um angemessene Daten zu erhalten. Beachten Sie, dass das Problem dadurch immer noch nicht vollständig behoben wird.

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

Die Batchverarbeitung unterscheidet sich von der Onlineverarbeitung. Bei der Onlineverarbeitung müssen Sie jede Anfrage bearbeiten, sobald sie eingeht.Sie müssen also für jede Abfrage eine separate Suche durchführen. Bei der Batchverarbeitung hingegen können Sie Aufgaben kombinieren (z.B. einen Join durchführen). Zum Zeitpunkt der Bereitstellung führen Sie eine Onlineverarbeitung durch, während das Training eine Batchverarbeitungsaufgabe ist. Es gibt jedoch einige Dinge, die Sie tun können, um Code wiederzuverwenden. Beispielsweise können Sie ein Objekt speziell für Ihr System erstellen, in dem das Ergebnis von Abfragen oder Joins sehr menschenlesbar gespeichert und Fehler leicht getestet werden kann. Sobald Sie alle Informationen erfasst haben, führen Sie während der Bereitstellung oder des Trainings eine gemeinsame Methode aus, um eine Brücke zwischen dem visuell lesbaren Objekt, das für Ihr System spezifisch ist, und dem Format zu schließen, das das System für maschinelles Lernen erwartet. Dadurch werden Abweichungen zwischen Training und Bereitstellung vermieden. Daher sollten Sie versuchen, zwischen Training und Bereitstellung nicht zwei verschiedene Programmiersprachen zu verwenden. Diese Entscheidung wird es Ihnen fast unmöglich machen, Code zu teilen.

Regel 33: Wenn Sie bis zum 5. Januar ein Modell erstellen, das auf den Daten basiert, testen Sie das Modell mit den Daten ab dem 6. Januar.

Im Allgemeinen sollten Sie die Leistung eines Modells mit den Daten messen, die nach den Daten erfasst wurden, mit denen Sie das Modell trainiert haben, da dies besser widerspiegelt, was Ihr System in der Produktion tun wird. Wenn Sie bis zum 5. Januar ein Modell erstellen, das auf diesen Daten basiert, testen Sie es mit den Daten vom 6. Januar. Sie werden davon ausgehen, dass die Leistung mit den neuen Daten nicht so gut sein wird, aber nicht wesentlich schlechter. Da es tägliche Auswirkungen geben kann, kann es sein, dass Sie die durchschnittliche Klickrate oder Conversion-Rate nicht vorhersagen. Der Bereich unter der Kurve, der die Wahrscheinlichkeit darstellt, dass dem positiven Beispiel eine höhere Punktzahl als ein negatives Beispiel gegeben wird, sollte angemessen nahe kommen.

Regel 34: Nehmen Sie bei der binären Klassifizierung für die Filterung (z. B. bei der Spamerkennung oder beim Erkennen interessanter E-Mails) kurzfristig kleine Abstriche bei der Leistung, um sehr saubere Daten zu erhalten.

Beim Filtern werden als negativ markierte Beispiele 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 beziehen, die den Nutzern gezeigt werden. Wenn ein Nutzer beispielsweise eine E-Mail als Spam markiert, die Ihr Filter durchlässt, können Sie daraus lernen.

Dieser Ansatz führt jedoch zu Stichprobenverzerrungen. Sie können sauberere Daten erfassen, wenn Sie stattdessen während der Bereitstellung 1% des gesamten Traffics als „Hold out“ kennzeichnen und alle betroffenen Beispiele an den Nutzer senden. Jetzt blockiert Ihr Filter mindestens 74% der negativen Beispiele. Diese Beispiele können zu Trainingsdaten werden.

Wenn Ihr Filter mindestens 95% der negativen Beispiele blockiert, ist dieser Ansatz weniger praktikabel. Wenn Sie jedoch die Bereitstellungsleistung messen möchten, können Sie eine noch kleinere Stichprobe erstellen (z.B.0,1% oder 0,001%). Mit 10.000 Beispielen lässt sich die Leistung recht genau schätzen.

Regel 35: Hüten Sie sich vor der inhärenten Verzerrung bei Ranking-Problemen.

Wenn Sie Ihren Rangfolgenalgorithmus so stark ändern, dass unterschiedliche Ergebnisse angezeigt werden, haben Sie die Daten, die der Algorithmus in Zukunft sehen soll, effektiv geändert. Diese Art von Verzerrung tritt auf und Sie sollten Ihr Modell darauf aufbauen. Es gibt mehrere unterschiedliche Ansätze. Diese Ansätze sind alles Möglichkeiten, Daten zu bevorzugen, die Ihr Modell bereits gesehen hat.

  1. haben eine höhere Regularisierung für Features, die mehr Abfragen abdecken, im Gegensatz zu Features, die nur für eine Abfrage aktiviert sind. Auf diese Weise bevorzugt das Modell Features, die für eine oder einige Abfragen spezifisch sind, gegenüber Features, die auf alle Abfragen verallgemeinern. So kann verhindert werden, dass sehr beliebte Ergebnisse in irrelevante Abfragen übergehen. Dies steht im Gegensatz zur konventionellen Empfehlung, eine stärkere Regularisierung für Featurespalten mit eindeutigeren Werten zu verwenden.
  2. Lassen Sie nur zu, dass Features eine positive Gewichtung haben. Daher ist jedes gute Merkmal besser als ein Merkmal, das "unbekannt" ist.
  3. Funktionen, die nur Dokumente enthalten, sind nicht verfügbar. Dies ist eine extreme Version von Punkt 1. Beispiel: Auch wenn eine bestimmte App unabhängig von der Abfrage ein beliebter Download ist, möchten Sie sie nicht überall anzeigen. Es ist einfach, keine reinen Dokumentfunktionen zu haben. Sie sollten eine bestimmte beliebte App nicht überall präsentieren, da sie so wichtig ist, dass alle gewünschten Apps erreichbar sind. Wenn ein Nutzer beispielsweise nach „Vogelbeobachtungs-App“ sucht, lädt er möglicherweise „wütende Vögel“ herunter, aber das war sicher nicht die Absicht. Wenn eine solche App präsentiert wird, kann sich die Downloadrate verbessern, aber die Anforderungen des Nutzers sind letztendlich nicht erfüllt.

Regel 36: Feedbackschleifen mit Positionsmerkmalen vermeiden

Die Position von Inhalten beeinflusst dramatisch, wie wahrscheinlich es ist, dass der Nutzer mit ihm interagiert. Wenn Sie eine App an erster Position platzieren, wird sie häufiger angeklickt, wodurch Sie überzeugt sind, dass dies eher unwahrscheinlich ist. Eine Möglichkeit, dies zu umgehen, besteht darin, Positionsmerkmale hinzuzufügen, d.h. Funktionen über die Position des Inhalts auf der Seite. Sie trainieren Ihr Modell mit Positionsfeatures und es lernt, beispielsweise das Feature „1stposition“ stark zu gewichten. Ihr Modell weist daher anderen Faktoren, beispielsweise mit „1stposition=true“, weniger Gewicht zu. Bei der Bereitstellung geben Sie dann keinen Instanzen das Positionsfeature an oder geben allen das gleiche Standardfeature, da Sie Kandidaten bewerten, bevor Sie die Reihenfolge festgelegt haben, in der sie angezeigt werden sollen.

Beachten Sie, dass es aufgrund dieser Asymmetrie zwischen Training und Tests wichtig ist, Positionsmerkmale etwas vom Rest des Modells zu trennen. Ideal ist, wenn das Modell die Summe einer Funktion der Positionsmerkmale und einer Funktion der übrigen Merkmale ist. Zum Beispiel dürfen die Positionsmerkmale nicht mit einer Dokumentfunktion verknüpft werden.

Regel 37: Messen Sie die Trainings-/Auslieferungsabweichung.

Es gibt mehrere Dinge, die im Allgemeinen eine Verzerrung verursachen können. Darüber hinaus können Sie ihn in mehrere Teile aufteilen:

  • Der Unterschied zwischen der Leistung der Trainingsdaten und den Holdout-Daten. Das wird im Allgemeinen immer existieren und ist nicht immer schlecht.
  • Die Differenz zwischen der Leistung für Holdout-Daten und den „nextday“-Daten. Auch dies wird immer existieren. Sie sollten Ihre Regularisierung optimieren, um die Leistung am nächsten Tag zu maximieren. Große Leistungsabfälle zwischen dem Holdout und den Daten für den nächsten Tag können jedoch darauf hinweisen, dass einige Features zeitkritisch sind und die Modellleistung beeinträchtigen können.
  • Der Unterschied zwischen der Leistung der Daten für den nächsten Tag und den Livedaten. Wenn Sie ein Modell auf ein Beispiel in den Trainingsdaten und dasselbe Beispiel bei der Bereitstellung anwenden, sollten Sie genau dasselbe Ergebnis erhalten (siehe Regel 5). Daher weist eine hier abweichende Abweichung wahrscheinlich auf einen technischen Fehler hin.

ML-Phase III: Langsames Wachstum, Optimierung der Optimierung und komplexe Modelle

Es gibt bestimmte Anzeichen dafür, dass die zweite Phase ihren Abschluss erreicht. Zunächst einmal wird dein monatlicher Gewinn sinken. Zwischen den Messwerten gibt es bereits gewisse Kompromisse: Bei einigen Tests werden Sie einen Anstieg und einen Rückgang der Werte feststellen. Jetzt wird es interessant. Da die Vorteile schwerer zu erzielen sind, muss das maschinelle Lernen ausgefeilter werden. Achtung: Dieser Abschnitt hat mehr Blue-Sky-Regeln als frühere Abschnitte. Wir haben erlebt, dass viele Teams die glücklichen Zeiten des maschinellen Lernens in Phase I und Phase II durchlaufen haben. Sobald Phase III erreicht ist, müssen die Teams ihren eigenen Weg finden.

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

Auf dem Höhepunkt der Messungen wird Ihr Team damit beginnen, Probleme zu untersuchen, die von den Zielen Ihres aktuellen Systems für maschinelles Lernen nicht abgedeckt werden. Wenn die Produktziele nicht durch das vorhandene algorithmische Ziel abgedeckt sind, müssen Sie entweder Ihr Ziel oder Ihre Produktziele ändern. Sie können beispielsweise Klicks, Plus-eins oder Downloads optimieren, aber Entscheidungen zur Einführung zum Teil auf der Grundlage von Prüfern treffen.

Regel 39: Entscheidungen bei der Markteinführung sind Stellvertreter für langfristige Produktziele.

Alice hat eine Idee, wie der logistische Verlust bei der Vorhersage von Installationen reduziert werden kann. Sie fügt eine Funktion hinzu. Der logistische Verlust sinkt. Bei einem Live-Test sieht sie, dass die Installationsrate steigt. Wenn sie jedoch zu einem Überprüfungsmeeting zur Einführung besucht, weist sie darauf hin, dass die Anzahl der aktiven Nutzer pro Tag um 5 % sinkt. Das Team beschließt, das Modell nicht auf den Markt zu bringen. Alice ist enttäuscht, merkt aber jetzt, dass die Einführungsentscheidungen von mehreren Kriterien abhängen, von denen nur einige direkt mit ML optimiert werden können.

Die Wahrheit ist, dass es in der realen Welt keine Verliese oder Drachen gibt: Es gibt keine „Trefferpunkte“, die den Zustand deines Produkts identifizieren. Das Team muss die gesammelten Statistiken verwenden, um effektiv vorherzusagen, wie gut das System in Zukunft sein wird. Wichtig sind Interaktionen, die Nutzer, die an 1 Tag aktiv sind, 30 Tage pro Tag, den Umsatz und den Return on Investment der Werbetreibenden. Diese Messwerte, die in A/B-Tests gemessen werden können, sind nur ein Indikator für langfristigere Ziele: Nutzerzufriedenheit, Vergrößerung der Nutzerzahl, zufriedene Partner und Gewinn. Selbst dann könnten Sie als Indikatoren für ein nützliches, hochwertiges Produkt und ein erfolgreiches Unternehmen in fünf Jahren dienen.

Die einzigen einfachen Entscheidungen beim Start sind, wenn alle Messwerte besser werden (oder zumindest nicht schlechter werden). Wenn das Team die Wahl zwischen einem ausgefeilten Algorithmus für maschinelles Lernen und einer einfachen Heuristik hat und die einfache Heuristik auf alle diese Messwerte besser funktioniert, sollte es die Heuristik wählen. Außerdem gibt es keine explizite Rangfolge aller möglichen Messwerte. Berücksichtigen Sie insbesondere die folgenden zwei Szenarien:

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

Wenn das aktuelle System A ist, ist es unwahrscheinlich, dass das Team zu B wechselt. Wenn das aktuelle System B ist, ist es unwahrscheinlich, dass das Team zu A wechselt. Dies scheint im Widerspruch zum rationalen Verhalten zu stehen. Vorhersagen zu sich ändernden Messwerten können jedoch auftreten oder nicht, sodass mit jeder Änderung ein großes Risiko besteht. Jede Metrik deckt ein gewisses Risiko ab, mit dem das Team Bedenken hat.

Darüber hinaus deckt keine Metrik die größte Frage des Teams ab: „Wo wird mein Produkt in fünf Jahren sein“?

Einzelne Ziele tendieren hingegen dazu, ein Ziel zu bevorzugen, das sie direkt optimieren können. Bei den meisten Tools für maschinelles Lernen wird eine solche Umgebung bevorzugt. In einer solchen Umgebung kann es vorkommen, dass ein Entwickler regelmäßig neue Funktionen einsetzt. Es gibt eine Art von maschinellem Lernen, das zielgruppenorientierte Lernen, das sich diesem Problem widmet. Beispielsweise kann ein Problem mit der Zufriedenheit mit Einschränkungen formuliert werden, das für jeden Messwert niedrigere Grenzen hat und eine lineare Kombination von Messwerten optimiert. Aber selbst dann sind nicht alle Messwerte einfach als ML-Ziel zu verstehen: Wenn auf ein Dokument geklickt oder eine App installiert wird, liegt das daran, dass der Inhalt angezeigt wurde. Es ist jedoch weitaus schwieriger herauszufinden, warum ein Nutzer Ihre Website besucht. Die Vorhersage des zukünftigen Erfolgs einer Website als Ganzes ist KI-vollständig: so schwierig wie maschinelles Sehen oder Natural Language Processing.

Regel 40: Halten Sie Ensembles einfach.

Einheitliche Modelle, die Rohmerkmale aufnehmen und Inhalte direkt einstufen, sind die Modelle, die am einfachsten zu debuggen und zu verstehen sind. Ein Ensemble von Modellen (ein „Modell“, das die Punktzahlen anderer Modelle kombiniert) kann jedoch besser funktionieren. Der Einfachheit halber sollte jedes Modell entweder ein Ensemble sein, das nur die Eingabe anderer Modelle übernimmt, oder ein Basismodell, das viele Merkmale übernimmt, aber nicht beides. Wenn Sie Modelle zusätzlich zu anderen Modellen haben, die separat trainiert werden, kann die Kombination dieser Modelle zu unerwünschtem Verhalten führen.

Verwenden Sie ein einfaches Gruppenmodell, das nur die Ausgabe Ihrer „Basismodelle“ als Eingaben annimmt. Sie möchten auch Attribute für diese Ensemble-Modelle erzwingen. Beispielsweise sollte ein Anstieg der von einem Basismodell erzeugten Punktzahl die Punktzahl des Ensembles nicht verringern. Außerdem ist es am besten, wenn die eingehenden Modelle semantisch interpretierbar sind (z. B. kalibriert sind), damit Änderungen der zugrunde liegenden Modelle das Ensemble-Modell nicht verwirren. Sie sollten außerdem erzwingen, dass eine Erhöhung der vorhergesagten Wahrscheinlichkeit eines zugrunde liegenden Klassifikators die vorhergesagte Wahrscheinlichkeit der Gruppe nicht verringert.

Regel 41: Suchen Sie bei Leistungsplateaus nach qualitativ neuen Informationsquellen, die Sie hinzufügen können, anstatt vorhandene Signale zu verfeinern.

Sie haben einige demografische Informationen über den Nutzer hinzugefügt. Sie haben Informationen zu den Wörtern im Dokument hinzugefügt. Sie haben die Vorlagenuntersuchung durchlaufen und die Regularisierung angepasst. In nur wenigen Quartalen gab es keine Einführung mit einer Verbesserung der wichtigsten Messwerte um mehr als 1 %. Was heißt das für die Zukunft?

Es ist an der Zeit, mit dem Aufbau der Infrastruktur für stark unterschiedliche Funktionen zu beginnen, z. B. für den Verlauf von Dokumenten, auf die dieser Nutzer im letzten Tag, in der letzten Woche oder im letzten Jahr zugegriffen hat, oder für Daten aus einer anderen Property. Verwenden Sie wikidata oder unternehmensinterne Elemente wie den Knowledge Graph von Google. Deep Learning einsetzen Passen Sie Ihre Erwartungen in Bezug auf den erwarteten Return on Investment an und erweitern Sie Ihre Anstrengungen entsprechend. Wie bei jedem Engineering-Projekt müssen Sie die Vorteile des Hinzufügens neuer Features gegen die Kosten der erhöhten Komplexität abwägen.

Regel 42: Erwarte nicht, dass Vielfalt, Personalisierung oder Relevanz so stark mit der Beliebtheit zusammenhängen, wie du denkst.

Vielfalt in einer Inhaltsgruppe kann viele Dinge bedeuten, wobei die Diversität der Quelle des Inhalts eine der häufigsten ist. Personalisierung bedeutet, dass jeder Nutzende seine eigenen Ergebnisse erhält. Relevanz bedeutet, dass die Ergebnisse für eine bestimmte Abfrage besser für diese Abfrage als jede andere Abfrage geeignet sind. Daher werden alle drei Eigenschaften als vom gewöhnlichen abweichend definiert.

Das Problem ist, dass das Gewöhnliche oft schwer zu übertreffen ist.

Wenn dein System beispielsweise Klicks, Verweildauer, Wiedergaben, +1-Empfehlungen, erneute geteilte Inhalte usw. misst, misst du die Beliebtheit des Inhalts. Teams versuchen manchmal, ein persönliches Modell mit Diversität zu erlernen. Zur Personalisierung fügt sie Funktionen hinzu, die es dem System ermöglichen, zu personalisieren (einige Funktionen, die das Interesse des Nutzers darstellen) oder zu diversifizieren (Funktionen, die angeben, ob dieses Dokument Merkmale mit anderen zurückgegebenen Dokumenten gemeinsam hat, z. B. Autor oder Inhalt), und stellen fest, dass diese Merkmale weniger Gewicht (oder manchmal ein anderes Zeichen) erhalten, als sie erwartet haben.

Das bedeutet nicht, dass Vielfalt, Personalisierung oder Relevanz keinen Wert haben. Wie in der vorherigen Regel erwähnt, können Sie eine Nachverarbeitung vornehmen, um die Vielfalt oder Relevanz zu erhöhen. Wenn Sie feststellen, dass die längerfristigen Ziele zunehmen, können Sie erklären, dass Diversität/Relevanz – abgesehen von Beliebtheit – wertvoll ist. Sie können dann entweder weiterhin die Nachverarbeitung verwenden oder das Ziel direkt basierend auf Vielfalt oder Relevanz ändern.

Regel 43: Ihre Freunde sind in der Regel bei verschiedenen Produkten gleich. Eher nicht.

Teams bei Google haben viel Arbeit geleistet, weil sie ein Modell nutzen, das die Nähe einer Verbindung in einem Produkt vorhersagt, und es in einem anderen gut funktioniert. Eure Freunde sind, wer sie sind. Andererseits habe ich beobachtet, dass sich mehrere Teams mit Personalisierungsfunktionen über Produktaufteilungen hinweg kämpfen. Ja, es scheint, es sollte funktionieren. Im Moment scheint dies nicht der Fall zu sein. Manchmal hat sich bewährt, Rohdaten aus einem Attribut zu verwenden, um das Verhalten einer anderen Eigenschaft vorherzusagen. Beachten Sie auch, dass es hilfreich sein kann, bereits zu wissen, dass ein Nutzer einen Verlauf für eine andere Property hat. Beispielsweise kann das Vorhandensein einer Nutzeraktivität bei zwei Produkten an sich ein Hinweis darauf sein.

Sowohl bei Google als auch extern gibt es zahlreiche 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, Danafa Ispir, Jeremiah Harmsen, Konstantinos Katsiah Harmsen, Konstantinos Korrektions für Katsiah Harmsen, Konstantinos, Katsi Vielen Dank auch an Kristen Lefevre, Suddha Basu und Chris Berg, die bei einer früheren Version geholfen haben. Alle Fehler, Auslassungen oder (schnauben!) unbeliebten Meinungen sind meine eigene.

Anhang

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

YouTube im Überblick

YouTube ist ein Streaming-Videodienst. Sowohl die Teams für die YouTube-Videoempfehlungen als auch die YouTube-Startseite verwenden ML-Modelle, um das Ranking von Videoempfehlungen zu ermitteln. Im Abschnitt „Nächstes Video“ werden Videos empfohlen, die nach dem aktuell abgespielten Video angesehen werden können. Auf der Startseite werden Nutzern, die auf der Startseite surfen, Videos empfohlen.

Google Play – Übersicht

Bei Google Play gibt es viele Modelle, mit denen sich eine Vielzahl von Problemen lösen lässt. Die Apps für die Google Play-Suche, Google Play und personalisierte Empfehlungen auf der Google Play-Startseite sowie Apps vom Typ „Ebenfalls installiert“ nutzen maschinelles Lernen.

Übersicht über Google+

Google Plus nutzte maschinelles Lernen in einer Vielzahl von Situationen, z. B. beim Ranking der Beiträge im Stream der vom Nutzer gesehenen Beiträge, der angesagten Beiträge (die aktuell sehr beliebt sind) oder von Personen, die Sie kennen. Google Plus hat 2019 alle privaten Konten geschlossen und am 6. Juli 2020 durch Google Currents für Geschäftskonten ersetzt.