Reguły systemów uczących się:

Sprawdzone metody dotyczące inżynierii uczenia maszynowego

Martin Zinkevich

Ten dokument ma pomóc osobom, które mają podstawową wiedzę o uczeniu maszynowym, w korzystaniu ze sprawdzonych metod Google dotyczących uczenia maszynowego. Przewodnik ten przedstawia styl uczenia maszynowego podobny do przewodnika Google C++ Style Guide i innych popularnych przewodników dotyczących praktycznego programowania. Jeśli bierzesz udział w kursie dotyczącym systemów uczących się lub pracowałeś/pracowałaś nad takim systemem lub tworzysz go, masz odpowiednie przygotowanie do przeczytania tego dokumentu.

Martin Zinkevich przedstawia 10 swoich ulubionych zasad dotyczących systemów uczących się. Czytaj dalej, aby poznać wszystkie 43 zasady!

Terminologia

W trakcie omawiania skutecznego uczenia maszynowego będziemy często używać tych terminów:

  • Instancja: element, którego dotyczy prognoza. Może to być na przykład strona internetowa, którą chcesz zaklasyfikować jako „o kotach” lub „nie o kotach”.
  • Etykieta: odpowiedź na zadanie przewidywania – albo odpowiedź wygenerowana przez system uczenia maszynowego, albo prawidłowa odpowiedź podana w danych treningowych. Na przykład etykieta strony internetowej może brzmieć „o kotach”.
  • Cecha: właściwość instancji używana w zadaniu przewidywania. Na przykład strona internetowa może mieć funkcję „zawiera słowo „kot””.
  • Kolumna funkcji: zbiór powiązanych funkcji, np. zbiór wszystkich możliwych krajów, w których mogą mieszkać użytkownicy. Przykład może zawierać co najmniej 1 cechę w kolumnie cech. Termin „kolumna z cechami” jest terminem używanym przez Google. W systemie VW (Yahoo/Microsoft) kolumna funkcji jest nazywana „przestrzenią nazw”, a w systemie Microsoft – polem.
  • Przykład: instancja (z jej właściwościami) i etykieta.
  • Model: statystyczna reprezentacja zadania prognozowania. Trenujesz model na przykładach, a potem używasz go do tworzenia prognoz.
  • Dane: liczba, która Cię interesuje. Może być bezpośrednio optymalizowany.
  • Cel: dane, które algorytm próbuje zoptymalizować.
  • Potok: infrastruktura związana z algorytmem systemów uczących się. Obejmuje zbieranie danych z front-endu, umieszczanie ich w plikach danych treningowych, trenowanie co najmniej jednego modelu i eksportowanie modeli do wersji produkcyjnej.
  • Współczynnik klikalności Odsetek użytkowników, którzy kliknęli link w reklamie.

Omówienie

Aby tworzyć świetne produkty:

wykorzystywać systemy uczące się jak świetny inżynier, a nie jak ekspert w tej dziedzinie.

Większość problemów, z którymi się zetkniesz, to tak naprawdę problemy inżynierskie. Nawet przy wykorzystaniu wszystkich zasobów eksperta w dziedzinie uczenia maszynowego większość korzyści wynika z dobrych funkcji, a nie z dobrych algorytmów systemów uczących się. Podstawowe podejście:

  1. Upewnij się, że potok jest solidny od początku do końca.
  2. Zacznij od określenia rozsądnego celu.
  3. Dodawanie funkcji typu common-sense w prosty sposób.
  4. Zadbaj o to, aby potok był stabilny.

Takie podejście będzie skuteczne przez długi czas. Odstępstwo od tego podejścia jest możliwe tylko wtedy, gdy nie ma już prostych sposobów na dalsze zwiększanie skuteczności. Zwiększanie złożoności opóźnia kolejne wersje.

Gdy wyczerpiesz możliwości prostych sztuczek, możesz sięgnąć po zaawansowane metody uczenia maszynowego. Zobacz sekcję dotyczącą projektów systemów uczących się w fazie III.

Ten dokument jest uporządkowany w ten sposób:

  1. Pierwsza część pomoże Ci ustalić, czy nadszedł odpowiedni czas na stworzenie systemu uczącego się.
  2. Druga część dotyczy wdrażania pierwszego potoku.
  3. Trzecia część dotyczy uruchamiania i iterowania podczas dodawania nowych funkcji do procesu, oceny modeli oraz zniekształceń w usługach generujących reklamy.
  4. W ostatniej części dowiesz się, co robić, gdy osiągniesz plateau.
  5. Następnie znajdziesz listę powiązanych prac oraz dodatek z informacjami o systemach, które są często używane jako przykłady w tym dokumencie.

Przed systemami uczącymi się

Zasada 1: nie bój się uruchomić produktu bez uczenia maszynowego.

Systemy uczące się są świetne, ale wymagają danych. Teoretycznie możesz pobrać dane dotyczące innego problemu, a potem dostosować model do nowego produktu, ale prawdopodobnie będzie on mniej skuteczny niż podstawowe heurystyki. Jeśli uważasz, że systemy uczące się maszynowo przyniosą 100% wzrost, to heurystyka zapewni Ci 50% tego wzrostu.

Jeśli na przykład ustalasz pozycję aplikacji na platformie, możesz użyć jako heurystyki współczynnika instalacji lub liczby instalacji. Jeśli wykryjesz spam, odfiltruj wydawców, którzy wcześniej wysyłali spam. Nie bój się też korzystać z usług korektora. Jeśli chcesz ustawić kolejność kontaktów, najwyżej umieść te, których używasz najczęściej (lub posortuj je alfabetycznie). Jeśli systemy uczące się nie są absolutnie niezbędne dla Twojego produktu, nie używaj ich, dopóki nie będziesz mieć danych.

Reguła 2. Najpierw zaprojektuj i wdróż dane.

Zanim sformalizujesz, co będzie robić Twój system uczenia maszynowego, śledź w jak największym stopniu to, co dzieje się w Twoim obecnym systemie. Zrób to z tych powodów:

  1. Wcześniejsze uzyskanie zgody użytkowników systemu jest łatwiejsze.
  2. Jeśli uważasz, że coś może być problemem w przyszłości, lepiej jest już teraz pobrać dane historyczne.
  3. Jeśli zaprojektujesz swój system z myślą o instrumentacji danych, w przyszłości będzie Ci łatwiej. Nie chcesz przecież wyszukiwać w dziennikach ciągu znaków, aby stworzyć dane.
  4. Zobaczysz, co się zmieniło, a co nie uległo zmianie. Załóżmy, że chcesz bezpośrednio optymalizować kampanię pod kątem użytkowników aktywnych w ciągu 1 dnia. Jednak podczas wczesnych manipulacji systemem możesz zauważyć, że znaczne zmiany w doświadczeniu użytkownika nie zmieniają znacząco tej metryki.

Zespół Google Plus mierzy liczbę wyświetleń na osobę, udostępnień na osobę, polubień na osobę, komentarzy/wyświetleń, komentarzy na użytkownika, udostępnień na użytkownika itp., aby obliczyć wartość posta w momencie wyświetlania. Pamiętaj też, że ważne jest framework eksperymentalny, w którym możesz grupować użytkowników w grupy i zbierać statystyki według eksperymentu. Patrz reguła 12.

Dzięki bardziej liberalnemu podejściu do zbierania danych możesz uzyskać szerszy obraz swojego systemu. Wystąpił problem? Dodaj dane, aby je śledzić. Czy jesteś podekscytowany(-a) niektórymi zmianami ilościowymi w ostatniej wersji? Dodaj dane, aby je śledzić.

Zasada 3. Zamiast złożonej heurystyki wybierz uczenie maszynowe.

Prosta heurystyka może pomóc w wprowadzeniu produktu na rynek. Złożona heurystyka jest trudna do utrzymania. Gdy już masz dane i ogólny zarys tego, co chcesz osiągnąć, przejdź do uczenia maszynowego. Podobnie jak w przypadku większości zadań związanych z inżynierią oprogramowania, będziesz musiał(-a) stale aktualizować swoje podejście, niezależnie od tego, czy jest to model heurystyczny, czy model uczenia maszynowego. Wkrótce się przekonasz, że model uczenia maszynowego jest łatwiejszy do aktualizowania i utrzymywania (patrz reguła nr 16).

Faza I: Twój pierwszy potok

W przypadku pierwszego potoku skup się na infrastrukturze systemu. Chociaż myślenie o wszystkich pomysłowych zastosowaniach uczenia maszynowego może być ekscytujące, trudno będzie Ci się zorientować, co się dzieje, jeśli nie ufasz swojemu procesowi.

Zasada 4. Pierwszy model powinien być prosty, a jego infrastruktura dobrze zaprojektowana.

Pierwszy model zapewnia największy wzrost sprzedaży produktu, więc nie musi być wyszukany. Jednak napotkasz znacznie więcej problemów z infrastrukturą, niż się spodziewasz. Zanim ktokolwiek będzie mógł korzystać z Twojego nowego systemu uczącego się, musisz określić:

  • Jak uzyskać przykłady dla algorytmu uczenia się.
  • Pierwsze zawężenie zakresu definiowania tego, co w Twoim systemie oznacza „dobry” i „zły”.
  • Jak zintegrować model z aplikacją. Możesz zastosować model na żywo lub wstępnie obliczyć go na przykładach offline i zapisać wyniki w tabeli. Możesz na przykład wstępnie skategoryzować strony internetowe i przechowywać wyniki w tabeli, ale możesz też sklasyfikować wiadomości z czatu na żywo.

Wybór prostych funkcji ułatwia:

  • Funkcje docierają do algorytmu uczenia się.
  • Model uczy się rozsądnych wag.
  • Cechy prawidłowo docierają do modelu na serwerze.

Gdy masz system, który niezawodnie wykonuje te 3 czynności, wykonałeś większość pracy. Prosty model zapewnia podstawowe dane i zachowanie, których możesz używać do testowania bardziej złożonych modeli. Niektóre zespoły dążą do „neutralnego” pierwszego uruchomienia: pierwszego uruchomienia, które wyraźnie nie stawia na pierwszym miejscu korzyści płynących z wykorzystywania uczenia maszynowego, aby uniknąć rozpraszania uwagi.

Zasada 5. Testuj infrastrukturę niezależnie od systemów uczących się.

Upewnij się, że infrastruktura jest testowalna, a elementy systemu związane z uczenie się są opakowane, aby można było przetestować wszystko wokół nich. Oto najważniejsze kwestie:

  1. Przetestuj przesyłanie danych do algorytmu. Sprawdź, czy kolumny funkcji, które powinny być wypełnione, są wypełnione. W miarę możliwości sprawdzaj ręcznie dane wejściowe do algorytmu trenowania. Jeśli to możliwe, porównaj statystyki w swoim strumieniu z statystykami dotyczącymi tych samych danych przetworzonych w innym miejscu.
  2. Testowanie pobierania modeli z algorytmu trenowania. Upewnij się, że model w Twoim środowisku trenowania ma taki sam wynik jak model w Twoim środowisku obsługi (patrz reguła #37).

Uczenie maszynowe ma element nieprzewidywalności, dlatego pamiętaj, aby przetestować kod służący do tworzenia przykładów podczas trenowania i wyświetlania oraz upewnij się, że możesz wczytywać i używać stałego modelu podczas wyświetlania. Ważne jest też, aby dobrze rozumieć swoje dane. W tym celu zapoznaj się z artykułem Praktyczne porady dotyczące analizy dużych, złożonych zbiorów danych.

Reguła 6. Podczas kopiowania ścieżek danych uważaj na utracone dane.

Często tworzymy potok danych, kopiując istniejący potok (czyli stosujemy programowanie cargo cult), a stary potok danych odrzuca dane, których potrzebujemy w nowym potoku danych. Na przykład potok dla sekcji Co jest popularne w Google Plus pomija starsze posty (ponieważ stara się nadać wyższą pozycję nowym postom). Ten potok został skopiowany do użycia w strumieniu Google Plus, w którym starsze posty są nadal istotne, ale potok nadal pomijał stare posty. Innym częstym wzorcem jest rejestrowanie tylko danych, które użytkownik zobaczył. Dlatego te dane są bezużyteczne, jeśli chcemy modelować, dlaczego użytkownik nie widział konkretnego posta, ponieważ wszystkie negatywne przykłady zostały odrzucone. Podobny problem wystąpił w Google Play. Podczas pracy nad stroną główną aplikacji w Google Play utworzono nowy kanał, który zawierał przykłady z strony docelowej Gier w Google Play bez żadnych funkcji umożliwiających określenie, skąd pochodzą.

Reguła 7. Przekształcaj heurystyki w funkcje lub zarządzaj nimi w sposób zewnętrzny.

Zwykle problemy, które próbuje rozwiązać system uczący się, nie są zupełnie nowe. Istnieje już system rankingowy lub klasyfikacyjny, który rozwiązuje Twój problem. Oznacza to, że istnieje wiele reguł i heurystyk. Te same heurystyki mogą przynieść Ci korzyści, jeśli zostaną dostosowane za pomocą uczenia maszynowego. Heurystyka powinna wydobywać z dostępnych informacji wszystko, co jest możliwe, z dwóch powodów. Po pierwsze, przejście na system oparty na uczeniu maszynowym będzie płynniejsze. Po drugie, te reguły zawierają wiele intuicji na temat systemu, której nie chcesz się pozbyć. Istnieją 4 sposoby użycia istniejącej heurystyki:

  • Przeprowadź wstępne przetwarzanie za pomocą heurystyki. Jeśli funkcja jest niesamowicie przydatna, możesz z niej skorzystać. Jeśli na przykład w filtrze spamu nadawca został już umieszczony na liście zablokowanych, nie próbuj ponownie uczyć się, co oznacza „znajduje się na liście zablokowanych”. Zablokuj wiadomość. Takie podejście sprawdza się najlepiej w przypadku zadań polegających na binarnej klasyfikacji.
  • Utwórz funkcję. Bezpośrednie tworzenie funkcji na podstawie heurystyki jest świetne. Jeśli np. używasz heurystyki do obliczania wyniku trafności dla wyniku zapytania, możesz uwzględnić ten wynik jako wartość atrybutu. Później możesz użyć technik uczenia maszynowego, aby zmodyfikować wartość (np. zamienić ją na jedną z ograniczonego zbioru wartości dyskretnych lub połączyć z innymi cechami), ale na początek użyj wartości surowej wygenerowanej przez heurystyczny algorytm.
  • wydobywać z nieprzetworzonych danych wejściowych heurystyki; Jeśli w przypadku aplikacji istnieje heurystyka, która uwzględnia liczbę instalacji, liczbę znaków w tekście i dzień tygodnia, rozważ oddzielne podawanie tych danych do uczenia się. Tutaj stosuje się niektóre techniki stosowane w przypadku zbiorów (patrz reguła nr 40).
  • Zmodyfikuj etykietę. Ta opcja jest dostępna, gdy uważasz, że heurystyka przechwytuje informacje, których obecnie nie ma na etykiecie. Jeśli na przykład chcesz zmaksymalizować liczbę pobrań, ale jednocześnie zapewnić jakość treści, możesz pomnożyć etykietę przez średnią liczbę gwiazdek przyznanych aplikacji. Tutaj jest dużo swobody. Zobacz "Pierwotny cel".

Pamiętaj, że użycie heurystyki w systemie uczenia maszynowego może zwiększyć złożoność. Użycie starych heurystyk w nowym algorytmie systemów uczących się może ułatwić płynne przejście, ale zastanów się, czy nie ma prostszego sposobu na osiągnięcie tego samego efektu.

Monitorowanie

Stosuj ogólne zasady dotyczące alertów, np. twórz alerty, które można wykorzystać, i umieszczaj je na stronie panelu.

Zasada 8. Dowiedz się, jakie wymagania dotyczące aktualności musi spełniać Twój system.

O ile spada skuteczność, jeśli model ma 1 dzień? Tydzień? Kwartał? Te informacje pomogą Ci zrozumieć priorytety monitorowania. Jeśli jakość usługi znacznie się pogarsza, gdy model nie jest aktualizowany przez 1 dzień, warto, aby inżynier stale go monitorował. Większość systemów do obsługi reklam ma do obsługi nowe reklamy każdego dnia i musi być aktualizowana codziennie. Jeśli na przykład model ML do wyszukiwania w Google Play nie zostanie zaktualizowany, może to mieć negatywny wpływ na wyniki w ciągu miesiąca. Niektóre modele funkcji Co jest popularne w Google Plus nie zawierają identyfikatora posta, więc mogą eksportować te modele rzadko. Inne modele, które mają identyfikatory postów, są aktualizowane znacznie częściej. Zwróć też uwagę, że świeżość może się zmieniać z czasem, zwłaszcza gdy dodasz do modelu lub usuniesz z niego kolumny z cechami.

Zasada 9. Wykrywanie problemów przed eksportowaniem modeli.

Wiele systemów uczenia maszynowego ma etap, na którym model jest eksportowany do udostępniania. Jeśli wystąpi problem z wyeksportowanym modelem, jest to problem dotyczący użytkownika.

Zanim wyeksportujesz model, wykonaj testy poprawności. W szczególności upewnij się, że skuteczność modelu na danych testowych jest zadowalająca. Jeśli nadal masz wątpliwości co do danych, nie eksportuj modelu. Wiele zespołów, które stale wdrażają modele, przed eksportem sprawdza obszar pod krzywą ROC (lub AUC). Problemy dotyczące modeli, które nie zostały wyeksportowane, wymagają alertu e-mail, ale problemy dotyczące modelu przeznaczonego dla użytkowników mogą wymagać strony. Dlatego lepiej poczekać i upewnić się, że zmiany nie wpłyną na użytkowników.

Zasada 10. Uważaj na bezgłośne błędy.

Ten problem występuje częściej w przypadku systemów uczenia maszynowego niż innych rodzajów systemów. Załóżmy, że dana tabela, która jest złączana, nie jest już aktualizowana. System uczenia maszynowego dostosuje się do sytuacji, a zachowanie będzie nadal w miarę dobre, stopniowo słabnące. Czasami trafiasz na tabele, które nie były aktualizowane od miesięcy, a ich odświeżenie poprawia skuteczność bardziej niż jakiekolwiek inne uruchomienie w tym kwartale. Zakres zastosowania danej funkcji może się zmieniać z powodu zmian w implementacji. Na przykład kolumna z cechami może być wypełniona w 90% przypadków, a nagle w tylko 60% z nich. W przypadku aplikacji Play Once tabela była nieaktualna przez 6 miesięcy, a jej odświeżenie samo w sobie zwiększyło współczynnik instalacji o 2%. Jeśli będziesz śledzić statystyki danych, a także od czasu do czasu sprawdzać je ręcznie, możesz zmniejszyć liczbę tego typu awarii.

Reguła 11. Przypisz właścicieli i dokumentację do kolumn funkcji.

Jeśli system jest duży i zawiera wiele kolumn cech, musisz wiedzieć, kto utworzył lub aktualizuje poszczególne kolumny cech. Jeśli zauważysz, że osoba, która rozumie kolumnę funkcji, opuszcza zespół, upewnij się, że ktoś inny ma te informacje. Chociaż wiele kolumn funkcji ma nazwy opisowe, warto mieć bardziej szczegółowy opis tego, czym jest dana funkcja, skąd się wzięła i jak ma pomagać.

Pierwszy cel

Masz wiele danych i wyników dotyczących systemu, który Cię interesuje, ale algorytm systemów uczących się często wymaga tylko jednego celu, czyli liczby, którą algorytm „próbuje” zoptymalizować”. Tutaj rozróżniam cele od danych: dane to dowolna liczba, którą raportuje Twój system, która może być ważna lub nie. Zobacz też Reguła 2.

Reguła 12. Nie zastanawiaj się zbytnio nad tym, który cel wybrać do bezpośredniej optymalizacji.

Chcesz zarabiać, zadowolać użytkowników i uczynić świat lepszym miejscem. Istnieje mnóstwo danych, które są dla Ciebie ważne, i powinieneś je mierzyć (patrz reguła 2). Jednak na początku procesu uczenia maszynowego zauważysz, że wszystkie one rosną, nawet te, których nie optymalizujesz bezpośrednio. Załóżmy np., że interesuje Cię liczba kliknięć i czas spędzony w witrynie. Jeśli zoptymalizujesz kampanię pod kątem liczby kliknięć, prawdopodobnie zauważysz wzrost czasu spędzanego na stronie.

Dlatego nie komplikuj sprawy i nie zastanawiaj się zbytnio nad zrównoważeniem różnych wskaźników, skoro możesz łatwo zwiększyć wszystkie dane. Nie traktuj tej reguły zbyt dosłownie: nie myl swojego celu z ostatecznym stanem systemu (patrz Reguła 39). Jeśli zwiększysz wartość wskaźnika optymalizowanego bezpośrednio, ale zdecydujesz się nie uruchamiać kampanii, może być konieczna zmiana celu.

Reguła 13. Wybierz dla pierwszego celu prostą, możliwą do zaobserwowania i przypisaną do niego miarę.

Często nie wiesz, jaki jest prawdziwy cel. Myślisz, że wiesz, ale gdy analizujesz dane i porównujesz stary system z nowym systemem opartym na AI, zdajesz sobie sprawę, że musisz dostosować cel. Co więcej, różni członkowie zespołu często nie mogą się zgodzić co do prawdziwego celu. Cel związany z AI powinien być czymś, co jest łatwe do zmierzenia i reprezentuje „prawdziwy” cel. W rzeczywistości często nie ma „prawdziwego” celu (patrz reguła 39). Dlatego trenuj na podstawie prostego celu ML i rozważ użycie „warstwy zasad” na górze, która pozwoli Ci dodać dodatkową logikę (miejmy nadzieję, że bardzo prostą) do końcowego rankingu.

Najłatwiej jest modelować zachowanie użytkownika, które jest bezpośrednio obserwowane i można je przypisać do działania systemu:

  • Czy ten link z rankingu został kliknięty?
  • Czy ten obiekt z rankingiem został pobrany?
  • Czy obiekt z rankingiem został przekierowany, na niego odpowiedziano lub wysłano e-maila?
  • Czy oceniany obiekt był oceniany?
  • Czy wyświetlony obiekt został oznaczony jako spam, treści pornograficzne lub obraźliwe?

Na początku unikaj modelowania efektów pośrednich:

  • Czy użytkownik odwiedził witrynę następnego dnia?
  • Jak długo użytkownik przebywał w witrynie?
  • Ile było aktywnych użytkowników dziennie?

Efekty pośrednie dają dobre dane i można ich używać podczas testów A/B oraz podejmowania decyzji dotyczących wprowadzania zmian.

Na koniec: nie próbuj wykorzystywać systemów uczących się do określania:

  • Czy użytkownik jest zadowolony z korzystania z usługi?
  • Czy użytkownik jest zadowolony z wyników?
  • Czy produkt poprawia ogólne samopoczucie użytkownika?
  • Jak to wpłynie na ogólną kondycję firmy?

Wszystkie one są ważne, ale też bardzo trudne do zmierzenia. Zamiast tego użyj serwerów proxy: jeśli użytkownik jest zadowolony, dłużej będzie przebywać na stronie. Jeśli użytkownik będzie zadowolony, wróci jutro. W zakresie dobrostanu i zdrowia firmy wymagana jest ocena ludzka, aby powiązać cel uczenia maszynowego z charakterem produktu, który sprzedajesz, i planem biznesowym.

Zasada 14. Zacznij od interpretowalnego modelu, aby ułatwić debugowanie.

Regresja liniowa, logistyczna i Poissona są bezpośrednio oparte na modelu probabilistycznym. Każda prognoza może być interpretowana jako prawdopodobieństwo lub wartość oczekiwana. Dzięki temu łatwiej je debugować niż modele, które korzystają z celów (strata zero-jeden, różne straty zawiasowe itp.), które próbują bezpośrednio optymalizować dokładność klasyfikacji lub skuteczność rankingu. Jeśli na przykład prawdopodobieństwa podczas trenowania różnią się od prawdopodobieństw przewidywanych w ramach side-by-side lub podczas sprawdzania systemu produkcyjnego, to odchylenie może wskazywać na problem.

Na przykład w regresji liniowej, logistycznej lub Poissona są podzbiory danych, w których średnia prognozowana wartość oczekiwana jest równa średniej etykiety (skalibrowana w 1 momencie lub po prostu skalibrowana). Jest to prawda, jeśli nie stosujesz regularyzacji i jeśli algorytm osiągnął zbieżność. Jest to też w ogóle prawda w przybliżeniu. Jeśli w przypadku każdego przykładu dana cecha ma wartość 1 lub 0, zestaw 3 przykładów, w których ta cecha ma wartość 1, jest kalibrowany. Jeśli masz funkcję, która ma wartość 1 w przypadku każdego przykładu, zbiór wszystkich przykładów jest skalibrowany.

W przypadku prostych modeli łatwiej jest sobie radzić z pętlami sprzężenia zwrotnego (patrz reguła nr 36). Często używamy tych prognoz probabilistycznych do podejmowania decyzji, np. do ustalania pozycji postów w zależności od malejącej wartości oczekiwanej (czyli prawdopodobieństwa kliknięcia, pobrania itp.). Pamiętaj jednak, że przy wyborze modelu ważniejsze są decyzje niż prawdopodobieństwo danych w danym modelu (patrz reguła 27).

Zasada 15. Oddziel filtrowanie spamu i ranking jakości w warstwie zasad.

Ranking jakości to sztuka, ale filtrowanie spamu to wojna. Sygnały, których używasz do określania jakości postów, staną się oczywiste dla osób korzystających z Twojego systemu, które będą mogły dostosować swoje posty, aby spełniały te wymagania. Dlatego ranking jakości powinien dotyczyć treści publikowanych w dobrej wierze. Nie należy pomijać jakościowego modułu rankingowego, który wysoko ceni spam. Podobnie treści „o wysokiej jakości” powinny być traktowane oddzielnie od rankingu jakości. Filtrowanie spamu to zupełnie inna historia. Należy się spodziewać, że cechy, które trzeba wygenerować, będą się stale zmieniać. Często w systemie są oczywiste reguły (np. jeśli post ma więcej niż 3 głosy na spam, nie pobieraj go). Każdy model wyuczony będzie musiał być aktualizowany codziennie, a częściej. Dużą rolę odgrywa reputacja twórcy treści.

Na pewnym poziomie dane z tych 2 systemów będą musiały być zintegrowane. Pamiętaj, że filtrowanie spamu w wynikach wyszukiwania powinno być bardziej agresywne niż filtrowanie spamu w wiadomościach e-mail. Standardową praktyką jest też usuwanie spamu z danych treningowych klasyfikatora jakości.

Etap II: ekstrakcja wyróżników

W pierwszym etapie cyklu życia systemu uczenia maszynowego ważne jest, aby przekazać dane szkoleniowe do systemu uczenia, skonfigurować wskaźniki, które nas interesują, i utworzyć infrastrukturę do obsługi. Gdy masz działający system z testami jednostkowymi i systemowymi, rozpoczyna się faza II.

W drugiej fazie jest dużo nisko wiszących owoców. Istnieje wiele oczywistych funkcji, które można wdrożyć w systemie. Drugi etap uczenia maszynowego polega na uwzględnieniu jak największej liczby cech i ich intuicyjnym łączeniu. Na tym etapie wszystkie dane powinny nadal rosnąć. Będzie wiele premier, więc to świetny czas na zaangażowanie wielu inżynierów, którzy mogą połączyć wszystkie dane potrzebne do stworzenia naprawdę niesamowitego systemu nauczania.

Zasada 16. Planuj uruchomienie i powtarzanie.

Nie oczekuj, że model, nad którym obecnie pracujesz, będzie ostatnim, który uruchomisz, ani że przestaniesz tworzyć nowe modele. Dlatego zastanów się, czy złożoność, którą dodajesz w ramach tego uruchomienia, nie spowolni przyszłych uruchomień. Wiele zespołów od lat co kwartał lub częściej publikuje nowe modele. Nowe modele warto wdrażać z 3 podstawowych powodów:

  • Tworzysz nowe funkcje.
  • Regulujesz regularyzację i łączysz stare cechy w nowy sposób.
  • Dostosowywanie celu.

W każdym razie warto poświęcić modelowi trochę uwagi: przeglądanie danych, które są podawane do przykładu, może pomóc w znalezieniu nowych sygnałów, a także starych, niedziałających. Podczas tworzenia modelu zastanów się, jak łatwo można dodawać i usuwać cechy oraz je łączyć. Zastanów się, jak łatwo jest utworzyć nową kopię potoku i sprawdzić jej poprawność. Zastanów się, czy można uruchomić 2 lub 3 kopii równolegle. Nie musisz się też martwić, czy funkcja 16 z 35 trafi do tej wersji potoku. Otrzymasz je w następnym kwartale.

Zasada 17. Zacznij od obserwowanych i zgłaszanych cech, a nie od cech wyuczonych.

Może to być kontrowersyjna kwestia, ale pozwala uniknąć wielu pułapek. Na początek wyjaśnijmy, czym jest wyuczona cecha. Wyuczona cecha to cecha wygenerowana przez zewnętrzny system (np.system klasteryzacji bez nadzoru) lub przez sam system uczący się (np. za pomocą modelu czynnikowego lub uczenia głębokiego). Oba te rozwiązania mogą być przydatne, ale mogą też powodować wiele problemów, dlatego nie powinny być stosowane w pierwszym modelu.

Jeśli do tworzenia funkcji używasz zewnętrznego systemu, pamiętaj, że ma on swój własny cel. Cel zewnętrznego systemu może być słabo skorelowany z Twoim bieżącym celem. Jeśli zrobisz zrzut ekranu zewnętrznego systemu, może on się zdezaktualizować. Jeśli zaktualizujesz funkcje z zewnętrznego systemu, ich znaczenie może się zmienić. Jeśli korzystasz z zewnętrznego systemu do udostępniania funkcji, pamiętaj, że takie podejście wymaga dużej ostrożności.

Głównym problemem z modelami czynnikowymi i modelami głębokimi jest to, że nie są one wypukłe. Nie ma więc gwarancji, że optymalne rozwiązanie zostanie zbliżone lub znalezione, a minimalne wartości lokalne znalezione w każdej iteracji mogą się różnić. Z tego powodu trudno jest ocenić, czy wpływ zmiany w systemie jest istotny, czy przypadkowy. Tworząc model bez funkcji głębokich, możesz uzyskać doskonałą wydajność podstawową. Po osiągnięciu tego poziomu możesz spróbować bardziej zaawansowanych metod.

Reguła 18.: Eksploruj funkcje treści, które są uniwersalne w różnych kontekstach.

System uczenia maszynowego często stanowi tylko niewielką część znacznie większej całości. Na przykład, jeśli wyobrażasz sobie post, który mógłby zostać wykorzystany w sekcji Na czasie, wiele osób będzie go plusować, udostępniać dalej lub komentować, zanim w ogóle pojawi się w tej sekcji. Jeśli udostępnisz te statystyki użytkownikowi, może on promować nowe posty, dla których nie ma danych w kontekście, w którym optymalizuje. YouTube „Obejrzyj dalej” może używać liczby obejrzeń lub współoglądów (liczby, ile razy jeden film został obejrzany po obejrzeniu innego) z wyszukiwarki YouTube. Możesz też użyć ocen użytkowników. Jeśli masz działanie użytkownika, które używasz jako etykiety, wyświetlanie tego działania w dokumencie w innym kontekście może być przydatną funkcją. Wszystkie te funkcje umożliwiają dodawanie nowych treści do kontekstu. Pamiętaj, że nie chodzi tu o personalizację: najpierw sprawdź, czy ktoś lubi treści w tym kontekście, a potem ustal, kto je lubi bardziej lub mniej.

Reguła 19. Korzystaj z funkcji, które są Ci potrzebne.

Przy dużej ilości danych łatwiej jest się uczyć milionów prostych cech niż kilku złożonych cech. Identyfikatory dokumentów, które są pobierane, oraz zapytania kanoniczne nie dają zbyt wiele informacji ogólnych, ale dopasowują ranking do etykiet zapytań głównych. Nie obawiaj się więc grup funkcji, w których każda funkcja dotyczy bardzo małej części danych, ale ogólne pokrycie wynosi ponad 90%. Możesz użyć regularyzacji, aby wyeliminować cechy, które mają zastosowanie do zbyt małej liczby przykładów.

Reguła 20. Łącz i modyfikuj istniejące funkcje, aby tworzyć nowe w zrozumiały sposób.

Funkcje można łączyć i modyfikować na wiele sposobów. Systemy uczenia maszynowego, takie jak TensorFlow, umożliwiają wstępną obróbkę danych za pomocą przekształceń. Dwa najpopularniejsze podejścia to „discretizations” i „crosses”.

Dyskretyzacja polega na przekształceniu ciągłej cechy w wiele cech dyskretnych. Weź pod uwagę zmienną ciągłą, np. wiek. Możesz utworzyć funkcję, która ma wartość 1, gdy wiek jest mniejszy niż 18 lat, inną funkcję, która ma wartość 1, gdy wiek jest w przedziale 18–35 lat, itd. Nie przejmuj się zbytnio granicami tych histogramów: podstawowe kwantyle będą miały największy wpływ.

Krzyżówki łączą co najmniej 2 kolumny cech. Według terminologii TensorFlow kolumna cech to zbiór cech jednorodnych (np. {male, female}, {US, Canada, Mexico} itd.). Krzyżowanie to nowa kolumna cech z cechami, np. {mężczyzna, kobieta} × {Stany Zjednoczone, Kanada, Meksyk}. Ta nowa kolumna funkcji będzie zawierać funkcję (osoba płci męskiej, Kanada). Jeśli używasz TensorFlow i powiesz mu, aby utworzył tę krzyżówkę za Ciebie, ta cecha (mężczyzna, Kanada) będzie obecna w przykladach reprezentujących Kanadyjczyków płci męskiej. Pamiętaj, że do uczenia modeli z krzyżowaniem 3, 4 lub więcej kolumn cech podstawowych potrzeba ogromnych ilości danych.

Krzyżówki, które generują bardzo duże kolumny cech, mogą być nadmiernie dopasowane. Wyobraź sobie na przykład, że wykonujesz wyszukiwanie, w którym występuje kolumna z funkcjami zawierającymi słowa w zapytaniu oraz kolumna z funkcjami zawierającymi słowa w dokumencie. Możesz je połączyć za pomocą funkcji krzyżowej, ale w efekcie uzyskasz wiele cech (patrz reguła 21).

Podczas pracy z tekstem masz 2 możliwości. Najbardziej restrykcyjne są produkty typu dot. W najprostszej postaci iloczyn punktowy zlicza liczbę wspólnych słów w zapytaniu i dokumencie. Ta funkcja może być następnie podzielona na dyskretne elementy. Innym podejściem jest przecięcie: w ten sposób będziemy mieć funkcję, która jest obecna tylko wtedy, gdy słowo „pony” występuje zarówno w dokumencie, jak i w zapytaniu, oraz inną funkcję, która jest obecna tylko wtedy, gdy słowo „the” występuje zarówno w dokumencie, jak i w zapytaniu.

Zasada 21: liczba wag cech, które można nauczyć w przypadku modelu liniowego, jest w przybliżeniu proporcjonalna do ilości dostępnych danych.

Istnieją fascynujące wyniki teorii uczenia się statystycznego dotyczące odpowiedniego poziomu złożoności modelu, ale to reguła, o której musisz wiedzieć. W trakcie rozmów z użytkownikami zauważyłem, że mają oni wątpliwości, czy można nauczyć się czegoś na podstawie 1000 przykładów lub czy kiedykolwiek będziesz potrzebować więcej niż miliona przykładów, ponieważ utknęli w określonej metodzie nauki. Kluczem jest dostosowanie uczenia się do wielkości danych:

  1. Jeśli pracujesz nad systemem rankingowym wyszukiwarki, a w dokumentach i zapytaniu występują miliony różnych słów i masz 1000 oznaczonych przykładów, użyj produktu punktowego między funkcjami dokumentu i zapytania, TF-IDF oraz kilkoma innymi funkcjami opracowanymi przez człowieka. 1000 przykładów, kilkanaście funkcji.
  2. Jeśli masz milion przykładów, przetnij kolumny cech dokumentu i zapytania, stosując regularyzację i ewentualnie wybór cech. Dzięki temu uzyskasz miliony cech, ale z regularyzacją będzie ich mniej. 10 milionów przykładów, może 100 tysięcy cech.
  3. Jeśli masz miliardy lub setki miliardów przykładów, możesz krzyżowo porównywać kolumny cech z tokenami dokumentu i zapytań, korzystając z funkcji wyboru cech i regularyzacji. Masz miliard przykładów i 10 milionów cech. Teoria uczenia się statystycznego rzadko dostarcza ścisłych granic, ale stanowi świetny punkt wyjścia.

Na koniec zastosuj regułę #28, aby zdecydować, których funkcji użyć.

Zasada 22: Usuń funkcje, których już nie używasz.

Niewykorzystane funkcje generują zadłużenie techniczne. Jeśli okaże się, że nie używasz danej funkcji i nie sprawdza się ona w połączeniu z innymi funkcjami, usuń ją z swojej infrastruktury. Chcesz, aby infrastruktura była czysta, aby jak najszybciej można było wypróbować najbardziej obiecujące funkcje. W razie potrzeby zawsze można przywrócić funkcję.

Pamiętaj o zasięgu, gdy rozważasz, które funkcje dodać lub zachować. Ile przykładów obejmuje ta funkcja? Jeśli na przykład masz funkcje personalizacji, ale tylko 8% użytkowników korzysta z tych funkcji, nie będą one zbyt skuteczne.

Jednocześnie niektóre funkcje mogą być bardziej przydatne, niż się wydaje. Jeśli na przykład dana cecha obejmuje tylko 1% danych, ale 90% przykładów, które ją mają, jest pozytywnych, warto ją dodać.

Analiza systemu przez człowieka

Zanim przejdziesz do trzeciej fazy uczenia maszynowego, skup się na czymś, czego nie uczy się na żadnym kursie uczenia maszynowego: jak analizować istniejący model oraz jak go ulepszać. Jest to bardziej sztuka niż nauka, ale mimo to pomaga uniknąć kilku wzorców nieprawidłowych zachowań.

Zasada 23: nie jesteś typowym użytkownikiem końcowym.

Jest to prawdopodobnie najprostszy sposób na zablokowanie zespołu. Chociaż stosowanie metody „żywej ryby” (czyli używanie prototypu w ramach zespołu) i „żywej krowy” (czyli używanie prototypu w ramach firmy) przynosi wiele korzyści, pracownicy powinni sprawdzić, czy działanie jest prawidłowe. Zmiany, które są wyraźnie złe, nie należy stosować, ale wszystko, co wygląda na dość zbliżone do wersji produkcyjnej, powinno być dalej testowane. Można do tego wykorzystać płatnych laików, którzy będą odpowiadać na pytania na platformie crowdsourcingowej, lub przeprowadzić eksperyment na żywo z udziałem prawdziwych użytkowników.

Jest to spowodowane 2 powodami. Po pierwsze, jesteś zbyt blisko kodu. Możesz szukać konkretnego aspektu postów lub po prostu zbyt emocjonalnie angażujesz się w te kwestie (np. poprzez potwierdzenie uprzedzeń). Po drugie, Twój czas jest zbyt cenny. Weź pod uwagę koszt 9 inżynierów biorących udział w jednogodzinnym spotkaniu i pomyśl, ile kosztuje zatrudnienie zewnętrznych ekspertów na platformie crowdsourcingowej.

Jeśli naprawdę chcesz uzyskać opinie użytkowników, użyj metod badań wrażeń użytkowników. Na początku procesu twórz persony użytkownika (jeden opis znajdziesz w książce Billa Buxtona Sketching User Experiences), a później przeprowadź testy użyteczności (jeden opis znajdziesz w książce Steve’a Kruga Don’t Make Me Think). Profil użytkownika to hipotetyczny użytkownik. Jeśli np. Twój zespół składa się wyłącznie z mężczyzn, warto zaprojektować personę użytkownika w postaci 35-letniej kobiety (wraz z jej cechami) i sprawdzić uzyskane wyniki zamiast 10 wyników dla mężczyzn w wieku 25–40 lat. Możesz też poprosić o testowanie witryny prawdziwych użytkowników (lokalnie lub zdalnie) i obserwować ich reakcje.

Reguła 24: zmierz różnicę między modelami.

Jednym z najprostszych i czasem najprzydatniejszych pomiarów, które możesz wykonać, zanim jakikolwiek użytkownik skorzysta z nowego modelu, jest obliczenie, jak bardzo różnią się nowe wyniki od wyników produkcyjnych. Jeśli np. masz problem z rankingiem, uruchom oba modele na próbce zapytań w całym systemie i sprawdź wielkość różnicy symetrycznej wyników (ważoną według pozycji w rankingu). Jeśli różnica jest bardzo mała, możesz stwierdzić bez przeprowadzania eksperymentu, że zmiana będzie niewielka. Jeśli różnica jest bardzo duża, musisz się upewnić, że zmiana jest odpowiednia. Przeglądanie zapytań, w których różnica symetryczna jest wysoka, może pomóc w poznaniu jakościowej charakterystyki zmiany. Upewnij się jednak, że system jest stabilny. Upewnij się, że model porównany sam ze sobą ma niską (najlepiej zerową) różnicę symetryczną.

Zasada 25: przy wyborze modeli liczy się użyteczność, a nie trafność prognoz.

Model może próbować prognozować współczynnik klikalności. Jednak kluczowe znaczenie ma to, co zrobisz z tą prognozą. Jeśli używasz go do rankingowania dokumentów, jakość końcowego rankingu ma większe znaczenie niż sama prognoza. Jeśli przewidujesz, że dokument jest spamem, a następnie ustawiasz limit tego, co jest blokowane, większa znaczenie ma dokładność tego, co jest dozwolone. W większości przypadków te 2 wartości powinny się zgadzać: jeśli się różnią, różnica będzie niewielka. Jeśli więc jakaś zmiana poprawia straty danych w logu, ale pogarsza wydajność systemu, poszukaj innej funkcji. Jeśli zdarza się to częściej, warto ponownie sprawdzić cel modelu.

Reguła 26. Szukaj w zmierzonych błędach wzorców i twórz nowe cechy.

Załóżmy, że widzisz przykład treningowy, który model „źle” zinterpretował. W zadaniu polegającym na klasyfikowaniu może to być błąd fałszywie pozytywny lub fałszywie negatywny. W zadaniu polegającym na ustalaniu kolejności błędem może być para, w której pozytywny wynik ma niższą pozycję niż negatywny. Najważniejsze jest to, że jest to przykład, w którym system uczenia maszynowego wie, że popełnił błąd i chce go naprawić, jeśli tylko będzie miał taką możliwość. Jeśli modelowi przypiszesz funkcję, która pozwala naprawić błąd, spróbuje jej użyć.

Jeśli jednak spróbujesz utworzyć funkcję na podstawie przykładów, które system nie uzna za błędy, funkcja zostanie zignorowana. Załóżmy, że ktoś w wyszukiwarce aplikacji w Google Play wyszukuje „bezpłatne gry”. Załóżmy, że jeden z najpopularniejszych wyników to mniej trafna aplikacja żartująca. W takim przypadku utwórz funkcję „aplikacje żartująca”. Jeśli jednak chcesz zmaksymalizować liczbę instalacji, a użytkownicy instalują aplikację żartu, gdy szukają bezpłatnych gier, funkcja „Aplikacje żartu” nie przyniesie oczekiwanego efektu.

Gdy masz już przykłady, w których model się pomylił, poszukaj trendów spoza bieżącego zbioru funkcji. Jeśli na przykład system wydaje się obniżać pozycję dłuższych postów, dodaj długość postu. Nie używaj określeń zbyt szczegółowych w przypadku funkcji, które dodajesz. Jeśli chcesz dodać długość postu, nie próbuj zgadnąć, co oznacza „długi”, tylko dodaj kilkanaście cech i pozwól modelowi określić, co z nimi zrobić (patrz Reguła nr 21). To najprostszy sposób na uzyskanie pożądanego wyniku.

Zasada 27: Postaraj się oszacować zaobserwowane niepożądane zachowanie.

Niektórzy członkowie zespołu zaczną być zniechęceni właściwościami systemu, które im się nie podobają i nie są uwzględniane przez obecną funkcję utraty. W tej chwili powinni zrobić wszystko, co możliwe, aby ich skargi przekształcić w konkretne liczby. Jeśli na przykład zespół uzna, że w wyszukiwarce w Sklepie Play wyświetla się zbyt wiele „żartobliwych aplikacji”, może poprosić o ich zidentyfikowanie osoby weryfikujące. (w tym przypadku możesz używać danych z oznaczonymi ręcznie etykietami, ponieważ stosunkowo mała część zapytań odpowiada za dużą część ruchu). Jeśli masz problemy, które można zmierzyć, możesz zacząć używać ich jako funkcji, celów lub danych. Ogólna zasada brzmi: „najpierw zmierz, a potem zoptymalizuj”.

Reguła 28: pamiętaj, że identyczne zachowanie w krótkim okresie nie oznacza identycznego zachowania w długim okresie.

Załóżmy, że masz nowy system, który sprawdza każdy identyfikator dokumentu (doc_id) i dokładne zapytanie (exact_query), a następnie oblicza prawdopodobieństwo kliknięcia każdego dokumentu dla każdego zapytania. Okazuje się, że jego działanie jest prawie identyczne z obecnym systemem w ramach testów porównawczych i A/B, więc ze względu na jego prostotę decydujesz się go wdrożyć. Zauważysz jednak, że nie wyświetlają się żadne nowe aplikacje. Dlaczego? Ponieważ Twój system wyświetla tylko dokument na podstawie własnej historii dotyczącej tego zapytania, nie ma możliwości określenia, że powinien wyświetlić nowy dokument.

Jedynym sposobem na zrozumienie, jak taki system będzie działać długofalowo, jest trenowanie go tylko na danych uzyskanych, gdy model był aktywny. To bardzo trudne.

Zniekształcenie między trenowaniem a zastosowaniem praktycznym

Zniekształcenie między trenowaniem a zastosowaniem praktycznym to różnica między wydajnością podczas trenowania a wydajnością w praktyce. Takie odchylenie może być spowodowane przez:

  • rozbieżność między sposobem przetwarzania danych w systemach do trenowania i obsługiwania modeli;
  • zmiana danych między treningiem a meczem;
  • sprzęgła zwrotna między modelem a algorytmem.

Zauważyliśmy, że produkcyjne systemy uczenia maszynowego w Google mają nierówny podział na dane służące do trenowania i obsługi, co negatywnie wpływa na wydajność. Najlepszym rozwiązaniem jest monitorowanie tego parametru, aby zmiany w systemie i danych nie powodowały niezauważonych odchyleń.

Reguła 29. Najlepszym sposobem na zapewnienie, że model będzie działał tak samo podczas treningu i w czasie obsługi, jest zapisanie zestawu funkcji używanych podczas obsługi, a następnie przekierowanie tych funkcji do dziennika, aby można było z nich korzystać podczas treningu.

Nawet jeśli nie możesz tego zrobić w przypadku każdego przykładu, zrób to w przypadku niewielkiej ich części, aby móc sprawdzić spójność między wyświetlaniem a trenowaniem (patrz reguła nr 37). Zespoły, które przeprowadziły w Google takie pomiary, były czasem zaskoczone wynikami. Strona główna YouTube korzysta z funkcji rejestrowania w czasie wyświetlania, co znacznie poprawia jakość i zmniejsza złożoność kodu. W tej chwili wiele zespołów zmienia swoją infrastrukturę.

Reguła 30: nie pomijaj arbitralnie danych próbkowanych z uwzględnieniem wagi.

Gdy masz zbyt dużo danych, możesz zechcieć wziąć pliki 1–12 i zignorować pliki 13–99. To jest błąd. Dane, które nigdy nie zostały wyświetlone użytkownikowi, można pominąć, ale najlepszym rozwiązaniem jest zastosowanie wagi ważności. Waga ważności oznacza, że jeśli zdecydujesz się na wylosowanie przykładu X z 30% prawdopodobieństwo, nadasz mu wagę 10/3. W przypadku uwzględniania wagi ważności wszystkie właściwości kalibracji opisane w zasadzie 14nadal obowiązują.

Reguła 31: pamiętaj, że jeśli podczas trenowania i obsługiwania modelu złączasz dane z tabeli, dane w niej mogą się zmienić.

Załóżmy, że złączasz identyfikatory dokumentów z tabelą zawierającą ich właściwości (np. liczbę komentarzy lub kliknięć). W czasie odstępującym od trenowania do wyświetlania funkcje w tabeli mogą ulec zmianie. Prognoza modelu dla tego samego dokumentu może się różnić w trakcie trenowania i wyświetlania. Najprostszym sposobem na uniknięcie tego rodzaju problemów jest rejestrowanie funkcji w momencie ich wyświetlania (patrz reguła nr 32). Jeśli tabela zmienia się tylko powoli, możesz też robić zrzuty tabeli co godzinę lub co dzień, aby uzyskać dane o w miarę dokładnej wartości. Pamiętaj, że to nie rozwiązuje całkowicie problemu.

Zasada 32: w miarę możliwości używaj kodu z potoku treningowego w potoku służącym do obsługi.

Przetwarzanie wsadowe różni się od przetwarzania online. W przypadku przetwarzania online musisz obsługiwać każde żądanie po jego otrzymaniu (np. musisz przeprowadzić osobne wyszukiwanie dla każdego zapytania), podczas gdy w przypadku przetwarzania zbiorczego możesz łączyć zadania (np. przeprowadzać złączenia). W czasie wyświetlania odbywa się przetwarzanie online, natomiast szkolenie to zadanie przetwarzania wsadowego. Możesz jednak zrobić kilka rzeczy, aby ponownie użyć kodu. Możesz na przykład utworzyć obiekt, który jest specyficzny dla Twojego systemu, a w którym wyniki zapytań lub złączeń mogą być przechowywane w sposób zrozumiały dla człowieka, a błędy można łatwo testować. Następnie, gdy zbierzemy już wszystkie informacje, podczas obsługi lub szkolenia uruchamiamy wspólną metodę, aby połączyć obiekt do odczytu przez człowieka, który jest specyficzny dla naszego systemu, z formatem oczekiwanym przez system uczenia maszynowego. Eliminuje to źródło rozbieżności między trenowaniem a obsługą. W związku z tym staraj się nie używać 2 różnych języków programowania na potrzeby treningu i obsługi. Ta decyzja uniemożliwi Ci udostępnianie kodu.

Zasada 33: jeśli model jest tworzony na podstawie danych do 5 stycznia, przetestuj go na danych z 6 stycznia i później.

Ogólnie rzecz biorąc, skuteczność modelu należy mierzyć na podstawie danych zebranych po przeprowadzeniu trenowania, ponieważ lepiej odzwierciedla to, jak system będzie działał w produkcji. Jeśli model jest tworzony na podstawie danych do 5 stycznia, przetestuj go na danych z 6 stycznia. Z pewnością zauważysz, że skuteczność nie będzie już tak wysoka, ale nie powinna być znacznie gorsza. Ponieważ mogą występować efekty dzienne, nie możesz przewidzieć średniego współczynnika klikalności ani współczynnika konwersji, ale obszar pod krzywą, który reprezentuje prawdopodobieństwo przyznania przykładowi pozytywnemu wyniku wyższego niż przykładowi negatywnemu, powinien być dość zbliżony.

Reguła 34. W przypadku binarnej klasyfikacji na potrzeby filtrowania (np. wykrywania spamu lub określania interesujących e-maili) zrób małe krótkoterminowe ustępstwa w zakresie wydajności, aby uzyskać bardzo czyste dane.

W zadaniu filtrowania przykłady oznaczone jako negatywne nie są wyświetlane użytkownikowi. Załóżmy, że masz filtr, który blokuje 75% przykładów negatywnych przy wyświetlaniu. Możesz mieć pokusę, aby pobrać dodatkowe dane szkoleniowe z przypadków wyświetlanych użytkownikom. Jeśli na przykład użytkownik oznaczy jako spam e-maila, który przepuścił Twój filtr, możesz się z tego czegoś nauczyć.

Takie podejście powoduje jednak występowanie błędu próbkowania. Możesz zebrać czystsze dane, jeśli zamiast tego podczas wyświetlania oznaczysz 1% wszystkiego ruchu jako „trzymany z dala” i wyślesz wszystkie przykłady „trzymane z dala” do użytkownika. Twój filtr blokuje teraz co najmniej 74% przykładów negatywnych. Te przykłady mogą stać się danymi treningowymi.

Pamiętaj, że jeśli filtr blokuje co najmniej 95% przykładów negatywnych, to podejście staje się mniej przydatne. Jeśli jednak chcesz mierzyć skuteczność wyświetlania, możesz utworzyć jeszcze mniejszą próbkę (np. 0,1% lub 0,001%). Dziesięć tysięcy przykładów wystarczy do dość dokładnego oszacowania skuteczności.

Zasada 35.: uważaj na problemy z rankingiem.

Gdy zmienisz algorytm rankingu w taki sposób, że pojawią się inne wyniki, w efekcie zmienisz dane, które algorytm będzie widzieć w przyszłości. Ten rodzaj przekłamania będzie widoczny, dlatego model należy zaprojektować z uwzględnieniem tego. Istnieje wiele różnych podejść. Te podejścia to wszystkie sposoby na faworyzowanie danych, które Twój model już widział.

  1. Stosuj silniejsze uregulowanie funkcji, które obejmują więcej zapytań, a nie tylko jedno zapytanie. Dzięki temu model będzie faworyzować cechy specyficzne dla jednego lub kilku zapytań zamiast cech, które są wspólne dla wszystkich zapytań. Dzięki temu bardzo popularne wyniki nie będą się pojawiać w niezwiązanych zapytaniach. Pamiętaj, że jest to przeciwieństwo bardziej konwencjonalnych zaleceń dotyczących większej regularyzacji kolumn cech z większą liczbą unikalnych wartości.
  2. Dopuszczaj dodatnie wagi tylko w przypadku cech. W związku z tym każda dobra cecha będzie lepsza niż cecha otagowana jako „nieznana”.
  3. Nie mają funkcji przeznaczonych tylko do dokumentów. To jest skrajny wariant 1. Na przykład nawet jeśli dana aplikacja jest popularnym pobieraniem niezależnie od zapytania, nie chcesz wyświetlać jej wszędzie. Brak funkcji przeznaczonych tylko do dokumentów ułatwia to zadanie. Powodem, dla którego nie chcesz wyświetlać konkretnej popularnej aplikacji wszędzie, jest fakt, że ważne jest, aby wszystkie pożądane aplikacje były dostępne. Jeśli na przykład ktoś wyszukuje „aplikacja do obserwacji ptaków”, może pobrać „Angry Birds”, ale nie jest to jego zamiar. Wyświetlanie takiej aplikacji może zwiększyć liczbę pobrań, ale nie spełni ostatecznie potrzeb użytkownika.

Reguła 36. Unikaj sprzężeń zwrotnych w przypadku funkcji pozycji.

Lokalizacja treści ma ogromny wpływ na to, jak prawdopodobne jest, że użytkownik wejdzie z nią w interakcję. Jeśli umieścisz aplikację na pierwszym miejscu, będzie częściej klikana, a Ty będziesz mieć pewność, że jest ona bardziej atrakcyjna dla użytkowników. Jednym ze sposobów na rozwiązanie tego problemu jest dodanie funkcji związanych z pozycją, czyli funkcji dotyczących położenia treści na stronie. Trenujesz model za pomocą cech dotyczących pozycji, a on uczy się nadawać dużą wagę na przykład cesze „1. pozycja”. W przypadku przykładów z wartością „1st_position=true” model przypisuje mniejszą wagę innym czynnikom. Następnie podczas wyświetlania nie przypisujesz żadnej instancji funkcji pozycjonowania ani nie przypisujesz im wszystkich tych samych domyślnych funkcji, ponieważ oceniasz kandydatów, zanim zdecydujesz, w jakiej kolejności je wyświetlić.

Pamiętaj, że ze względu na tę asymetrię między trenowaniem a testowaniem należy zachować pewną odrębność cech pozycyjnych od reszty modelu. Idealnie jest, gdy model jest sumą funkcji cech związanych z pozycją i funkcji pozostałych cech. Nie krzyżuj na przykład cech dotyczących położenia z żadną cechą dokumentu.

Reguła 37: zmierz zniekształcenie między trenowaniem a zastosowaniem praktycznym.

Istnieje kilka czynników, które mogą powodować ogólne odchylenia. Możesz też podzielić go na kilka części:

  • Różnica między wydajnością na danych treningowych a danych holdout. Zasadniczo zawsze będzie to występować i nie zawsze jest to złe.
  • Różnica między skutecznością na danych z grupy testowej a danymi „następnego dnia”. Zawsze będzie to możliwe. Należy dostosować regularyzację, aby zmaksymalizować skuteczność następnego dnia. Jednak duże spadki skuteczności między danymi z grupy holdout a danymi z następnego dnia mogą wskazywać, że niektóre funkcje są zależne od czasu i mogą obniżać skuteczność modelu.
  • Różnica między skutecznością na podstawie danych „następnego dnia” a danych na żywo. Jeśli zastosujesz model do przykładu w danych treningowych i do tego samego przykładu podczas obsługi, powinien on dać dokładnie ten sam wynik (patrz reguła 5). Zatem rozbieżność wskazuje prawdopodobnie na błąd programistyczny.

Etap III: spowolnienie tempa wzrostu, udoskonalenie optymalizacji i modele złożone

Będą pewne oznaki, że druga faza dobiega końca. Po pierwsze, Twoje zyski zaczną maleć. W pewnych eksperymentach zaczniesz dokonywać wyborów między danymi: w niektórych eksperymentach niektóre dane będą rosnąć, a inne spadać. Tu zaczyna się zabawa. Ponieważ osiągnięcie takich zysków jest trudniejsze, systemy uczące się muszą być bardziej zaawansowane. Uwaga: w tym akapicie jest więcej ogólnych zasad niż w poprzednich. Wiele zespołów korzystało z uczenia maszynowego w ramach fazy I i II. Po zakończeniu etapu III zespoły muszą znaleźć własną ścieżkę.

Zasada 38. Nie marnuj czasu na nowe funkcje, jeśli problemem są niezgodne cele.

Gdy pomiary osiągną plateau, Twój zespół zacznie zajmować się problemami wykraczającymi poza zakres celów obecnego systemu uczenia maszynowego. Jak już wspomnieliśmy, jeśli obecny cel algorytmiczny nie obejmuje celów związanych z produktem, musisz zmienić cel lub cele związane z produktem. Możesz na przykład optymalizować kliknięcia, plusy lub pobierania, ale decyzje dotyczące uruchomienia należy podejmować częściowo na podstawie oceny ludzkich ekspertów.

Zasada 39: decyzje dotyczące wdrożenia są pochodnymi długoterminowych celów związanych z usługą.

Alicja ma pomysł na zmniejszenie strat logistycznych związanych z prognozowaniem liczby instalacji. Dodaje funkcję. Strata logistyczna maleje. Gdy przeprowadzi eksperyment na żywo, zauważy wzrost współczynnika instalacji. Jednak podczas spotkania poświęconego przeglądowi przed uruchomieniem ktoś z uczestników zwraca uwagę, że liczba aktywnych użytkowników dziennie spadła o 5%. Zespół decyduje się nie uruchamiać modelu. Alicja jest rozczarowana, ale zdaje sobie sprawę, że decyzje dotyczące uruchomienia zależą od wielu kryteriów, z których tylko niektóre można bezpośrednio optymalizować za pomocą ML.

Prawda jest taka, że w prawdziwym życiu nie ma „punktów krytycznych” wskazujących kondycję produktu. Zespół musi korzystać ze zgromadzonych statystyk, aby skutecznie przewidywać, jak skuteczny będzie system w przyszłości. Muszą oni zwracać uwagę na zaangażowanie, aktywnych użytkowników 1 dni, aktywnych użytkowników w ciągu 30 dni, przychody i zwrot z inwestycji reklamodawcy. Te dane, które można mierzyć w testach A/B, są tylko przybliżeniem długoterminowych celów: zadowolenia użytkowników, zwiększenia liczby użytkowników, zadowolenia partnerów i zysku, które można uznać za przybliżenie posiadania przydatnego produktu wysokiej jakości i dynamicznie rozwijającej się firmy za 5 lat.

Jedyne łatwe decyzje o wdrożeniu to te, gdy wszystkie dane ulegają poprawie (lub przynajmniej nie pogarszają się). Jeśli zespół ma do wyboru zaawansowany algorytm uczenia maszynowego i prostą heurystykę, a prosta heurystyka sprawdza się lepiej pod względem wszystkich tych danych, powinien wybrać heurystykę. Co więcej, nie ma wyraźnego rankingu wszystkich możliwych wartości danych. W szczególności rozważ te 2 sytuacje:

Eksperyment Liczba aktywnych użytkowników dziennie Przychody/dzień
A 1 milion 4 mln
B 2 miliony 2 miliony dolarów

Jeśli aktualny system to A, zespół prawdopodobnie nie przejdzie na system B. Jeśli obecny system to B, zespół prawdopodobnie nie przejdzie na A. Wydaje się to sprzeczne z racjonalnym zachowaniem, ale prognozy dotyczące zmian danych mogą się sprawdzić, ale też nie muszą, więc każda zmiana wiąże się z dużym ryzykiem. Każdy wskaźnik obejmuje ryzyko, które niepokoi zespół.

Co więcej, żaden wskaźnik nie odpowiada na najważniejsze pytanie zespołu: „Jak będzie wyglądać mój produkt za 5 lat?”.

Osoby prywatne z kolei zwykle wybierają jeden cel, który mogą bezpośrednio optymalizować. Większość narzędzi do uczenia maszynowego działa najlepiej w takim środowisku. Inżynier, który tworzy nowe funkcje, może w takim środowisku prowadzić stały strumień uruchamiania. Istnieje typ uczenia maszynowego, uczenie wielocelowe, które zaczyna rozwiązywać ten problem. Można na przykład sformułować problem z ograniczeniami, który ma dolne granice dla każdego rodzaju danych i optymalizuje pewną kombinację liniową danych. Jednak nawet wtedy nie wszystkie dane można łatwo ująć w formie celów uczenia maszynowego: jeśli dokument został kliknięty lub aplikacja zainstalowana, to dlatego, że treści zostały wyświetlone. Trudniej jest jednak ustalić, dlaczego użytkownik odwiedza Twoją witrynę. Jak przewidzieć przyszły sukces witryny jako całości? AI-complete: tak samo trudno jak komputerowe widzenie czy przetwarzanie języka naturalnego.

Zasada 40. Nie komplikuj zespołów.

Ujednolicone modele, które wykorzystują surowe funkcje i bezpośrednio nadają treści ranking, są najłatwiejsze do debugowania i zrozumienia. Lepsze wyniki może jednak przynieść zestaw modeli (czyli „model”, który łączy wyniki innych modeli). Aby zachować prostotę, każdy model powinien być albo zespołem, który bierze pod uwagę tylko dane wejściowe innych modeli, albo modelem podstawowym, który bierze pod uwagę wiele funkcji, ale nie oba te elementy jednocześnie. Jeśli masz modele na podstawie innych modeli, które są trenowane osobno, ich połączenie może spowodować nieprawidłowe działanie.

Użyj prostego modelu do łączenia, który jako dane wejściowe przyjmuje tylko dane wyjściowe „podstawowych” modeli. Chcesz też narzucić właściwości na te modele zbiorcze. Na przykład wzrost wyniku wygenerowanego przez model podstawowy nie powinien powodować spadku wyniku zespołu. Najlepiej też, aby modele wejściowe były interpretowalne semantycznie (np. skalibrowane), aby zmiany w podstawowych modelach nie wprowadzały zamieszania w modelu zbiorowym. Zapewnienie, że wzrost przewidywanego prawdopodobieństwa podstawowego klasyfikatora nie powoduje spadku przewidywanego prawdopodobieństwa zbioru.

Zasada 41. Gdy skuteczność osiągnie plateau, poszukaj nowych jakościowych źródeł informacji, które możesz dodać, zamiast ulepszać dotychczasowe sygnały.

Dodano informacje demograficzne o użytkowniku. Dodano informacje o słowach w dokumencie. Przeprowadziłeś eksplorację szablonów i dokonałeś regulacji regularyzacji. przez kilka kwartałów nie odnotowano żadnego uruchomienia, które przyniosło wzrost kluczowych wskaźników o więcej niż 1%. Co dalej?

Nadszedł czas na zbudowanie infrastruktury dla zupełnie innych funkcji, takich jak historia dokumentów, do których użytkownik uzyskał dostęp w ostatnim dniu, tygodniu lub roku, albo dane z innej usługi. Użyj elementów wikidata lub czegoś wewnętrznego w Twojej firmie (np. grafu wiedzy Google). Korzystaj z głębokiego uczenia się. Zacznij dostosowywać oczekiwania dotyczące zwrotu z inwestycji i odpowiednio zwiększaj swoje wysiłki. Podobnie jak w przypadku każdego projektu inżynierskiego, musisz porównać korzyści płynące z dodania nowych funkcji z kosztem zwiększenia złożoności.

Reguła 42: nie oczekuj, że różnorodność, personalizacja i trafność będą tak powiązane z popularnością, jak Ci się wydaje.

Różnorodność zestawu treści może oznaczać wiele rzeczy, a różnorodność źródeł treści jest jedną z najczęstszych. Personalizacja oznacza, że każdy użytkownik otrzymuje własne wyniki. Trafność oznacza, że wyniki dla konkretnego zapytania są bardziej odpowiednie niż jakiekolwiek inne. W związku z tym wszystkie te właściwości są zdefiniowane jako inne niż zwykłe.

Problem w tym, że zwykłe rzeczy trudno jest pokonać.

Pamiętaj, że jeśli Twój system mierzy kliknięcia, czas spędzony na stronie, wyświetlenia, +1, udostępnienia itp., mierzysz popularność treści. Czasami zespoły próbują uczyć się modelu osobistego z uwzględnieniem zróżnicowania. Aby dokonać personalizacji, dodają funkcje, które pozwolą systemowi na personalizację (niektóre funkcje reprezentujące zainteresowania użytkownika) lub zróżnicowanie (funkcje wskazujące, czy ten dokument ma jakieś cechy wspólne z innymi zwróconymi dokumentami, takie jak autor lub treść), i odkrywają, że te funkcje mają mniejszą wagę (lub czasami inny znak) niż oczekują.

Nie oznacza to, że różnorodność, personalizacja czy trafność nie mają wartości. Jak wspomniano w poprzedniej regule, możesz przeprowadzić przetwarzanie wtórne, aby zwiększyć różnorodność lub trafność. Jeśli zauważysz wzrost liczby celów długoterminowych, możesz stwierdzić, że różnorodność/trafność jest wartościowa, oprócz popularności. Możesz wtedy kontynuować przetwarzanie w postprocesie lub bezpośrednio zmodyfikować cel na podstawie różnorodności lub trafności.

Zasada 43: Twoi znajomi są zwykle tacy sami w różnych usługach. Twoje zainteresowania rzadko się zmieniają.

Zespoły w Google osiągnęły wiele sukcesów dzięki zastosowaniu modelu przewidującego bliskość połączenia w jednym produkcie i jego dobre działanie w drugim. Twoi znajomi są tacy, jacy są. Z drugiej strony, obserwujemy, że wiele zespołów ma problemy z funkcjami personalizacji w różnych usługach. Tak, wygląda na to, że powinno działać. Wygląda na to, że nie. Czasami działało używanie nieprzetworzonych danych z jednej usługi do przewidywania zachowań w innej. Pamiętaj, że nawet wiedza o tym, że użytkownik ma historię w innej usłudze, może być przydatna. Na przykład sama obecność aktywności użytkownika w 2 usługach może być wystarczająca do określenia, że konto jest wykorzystywane do spamowania.

W Google i poza nim jest wiele dokumentów dotyczących systemów uczących się.

Podziękowania

Dziękujemy Davidowi Westbrookowi, Peterowi Brandtowi, Samuelowi Ieongowi, Chenyu Zhao, Li Wei, Michalisowi Potamiasowi, Evanowi Rosenowi, Barry’emu Rosenbergowi, Christine Robson, Jamesowi Pine, Talowi Shakedowi, Tusharowi Chandra, Mustafie Ispir, Jeremiahowi Harmsenowi, Konstantinosowi Katsiapisowi, Glenowi Andersonowi, Danowi Duckworthowi, Shishirowi Birmiwalowi, Galowi Elidanowi, Su Lin Wu, Jaihui Liu, Fernando Pereira i Hrishikeshowi Aradhye za wiele poprawek, sugestii i przydatnych przykładów dotyczących tego dokumentu. Dziękujemy też Kristen Lefevre, Suddha Basu i Chrisowi Bergowi za pomoc w przygotowaniu wcześniejszej wersji. Wszelkie błędy, pominięcia i (o zgrozo!) niepopularne opinie są moje.

Dodatek

W tym dokumencie znajduje się wiele odniesień do usług Google. Poniżej znajdziesz krótki opis najczęstszych przykładów, aby lepiej zobrazować kontekst.

YouTube – omówienie

YouTube to usługa strumieniowego przesyłania filmów. Zarówno zespoły odpowiedzialne za sekcję „Następny” w YouTube, jak i zespoły zajmujące się stroną główną YouTube korzystają z modeli AI do ustalania kolejności rekomendacji filmów. Sekcja „Obejrzyj następny” zawiera rekomendacje filmów do obejrzenia po aktualnie odtwarzanym, a strona główna – filmów dla użytkowników przeglądających stronę główną.

Omówienie Google Play

Google Play ma wiele modeli, które rozwiązują różne problemy. Wyszukiwanie w Sklepie Play, spersonalizowane rekomendacje na stronie głównej Sklepu Play oraz aplikacje „Użytkownicy też zainstalowali” korzystają z systemów uczących się.

Omówienie Google+

Google Plus używał uczenia maszynowego w różnych sytuacjach: do rankingu postów w „strumieniach” wyświetlanych użytkownikowi, rankingu postów w sekcji „Co jest na czasie” (czyli postów, które są obecnie bardzo popularne), rankingu znajomych itd. W 2019 r. Google Plus zamknęło wszystkie konta osobiste, a 6 lipca 2020 r. zostało zastąpione przez Google Currents na kontach firmowych.