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

Sprawdzone metody dla inżynierii systemów uczących się

Martin Zinkevich

Ten dokument ma pomóc osobom, które mają podstawową wiedzę o systemach uczących się, w wykorzystaniu sprawdzonych metod Google dotyczących systemów uczących się. Jest to styl oparty na systemach uczących się, podobny do przewodnika po stylu C++ w Google+ i innych popularnych przewodników po praktycznym programowaniu. Jeśli masz za sobą zajęcia związane z systemami uczącymi się, skompilowany lub dopracowany model oparty na systemach uczących się, musisz mieć odpowiednie tło, aby przeczytać ten dokument.

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

Terminologia

W naszej dyskusji na temat skutecznych systemów uczących się będziemy wielokrotnie powtarzali następujące terminy:

  • Instancja: element, co do którego chcesz wygenerować prognozę. Przykładem może być strona, którą chcesz sklasyfikować jako „o kotach” lub „nie na temat kotów”.
  • Etykieta: odpowiedź na zadanie związane z prognozą, czyli odpowiedź wyprodukowana przez system uczących się lub prawidłowa odpowiedź podana w danych treningowych. Na przykład etykieta strony internetowej może wyglądać tak: „informacje o kotach”.
  • Funkcja: właściwość instancji używanej w zadaniu prognozowania. Na przykład strona internetowa może mieć funkcję „zawiera słowo „kot”.
  • Kolumna cech: zbiór powiązanych funkcji, np. lista wszystkich możliwych krajów, w których mogą mieszkać użytkownicy. Przykład może zawierać jedną lub więcej cech w kolumnie cech. „Kolumna funkcji” oznacza terminologię specyficzną dla firmy Google. W systemie VW kolumna cech jest określana jako „przestrzeń nazw” (w Yahoo/Microsoft) lub w polu.
  • Przykład: instancja (z funkcjami) i etykieta.
  • Model: statystyczna reprezentacja zadania prognozowania. Trenujesz model na przykładach, a potem używasz go do prognozowania.
  • Dane: liczba, która ma dla Ciebie znaczenie. Optymalizacja może być bezpośrednio optymalizowana, ale nie.
  • Cel: dane, które Twój algorytm próbuje zoptymalizować.
  • Potok: infrastruktura otaczająca algorytm systemów uczących się. Obejmuje zbieranie danych z interfejsu, umieszczenie ich w treningowych plikach danych, trenowanie co najmniej jednego modelu i eksportowanie modeli do środowiska produkcyjnego.
  • Współczynnik klikalności – odsetek użytkowników strony internetowej, którzy kliknęli link w reklamie.

Opis

Aby tworzyć świetne produkty:

czy systemy uczące się są takie jak Ty, jak prawdziwy inżynier, jak Ty.

Większość problemów, które napotykasz, są w rzeczywistości problemy inżynieryjne. Nawet przy zasobach wybitnego eksperta ds. systemów uczących się większość korzyści tkwi w świetnych funkcjach, a nie algorytmach systemów uczących się. Oto podstawowe podejście:

  1. Upewnij się, że potok jest całkowicie kompletny.
  2. Zacznij od rozsądnego celu.
  3. W prosty sposób dodawaj zdroworozsądkowe funkcje.
  4. Dopilnuj, aby Twój potok był niezawodny.

Ta metoda sprawdza się przez dłuższy czas. Odejdź od tego podejścia tylko wtedy, gdy nie da się już osiągnąć więcej prostych sztuczek. Zwiększona złożoność spowalnia kolejne wersje.

Gdy już wyczerpiesz wszystkie proste sztuczki, nowoczesne systemy uczące się mogą okazać się w przyszłości niezwykle przydatne. Zapoznaj się z sekcją poświęconą projektom związanym z systemami uczącymi się w fazie III.

Układ dokumentu jest następujący:

  1. Pierwsza część powinna pomóc Ci zrozumieć, czy jest właściwy moment na zbudowanie systemu systemów uczących się.
  2. Druga część dotyczy wdrożenia pierwszego potoku.
  3. Trzecia część dotyczy uruchamiania i iteracji przy jednoczesnym dodawaniu do potoku nowych funkcji, ocenie modeli oraz zniekształceniu między trenowaniem a zastosowaniem praktycznym.
  4. Ostatnia część dotyczy tego, co zrobić po dotarciu na płaskowyż.
  5. Następnie podaliśmy listę powiązanych prac i załącznik z informacjami na temat systemów często wykorzystywanych jako przykłady w tym dokumencie.

Przed systemami uczącymi się

Zasada nr 1: nie bój się wprowadzić produktu na rynek bez systemów uczących się.

Systemy uczące się są fajne, ale wymagają danych Teoretycznie można wydobyć dane z innego problemu, a potem dostosować model na potrzeby nowego produktu, ale prawdopodobnie będzie to gorsze niż podstawowe heuristics. Jeśli uważasz, że systemy uczące się zapewnią Ci 100% korzyści, heurystyka pomoże Ci to osiągnąć w 50%.

Jeśli na przykład ustalasz ranking aplikacji w sklepie z aplikacjami, możesz użyć w formie heurystyki liczby instalacji lub liczby instalacji. Jeśli wykryjesz spam, odfiltruj wydawców, którzy wcześniej wysyłali spam. Nie bój się montować filmów ręcznie. Jeśli chcesz uporządkować kontakty, uporządkuj je jako najczęściej używane (a nawet alfabetycznie). Jeśli w przypadku Twojego produktu systemy uczące się nie są absolutnie niezbędne, nie używaj ich, dopóki nie będziesz mieć danych.

Zasada nr 2: najpierw zaprojektuj i zaimplementuj dane.

Zanim określisz sposób działania systemu uczącego się, postaraj się zgromadzić ich jak najwięcej. Dzieje się tak z tych powodów:

  1. Wcześniej łatwiej jest uzyskać uprawnienia użytkowników systemu.
  2. Jeśli uważasz, że coś może w przyszłości powodować niepokojące obawy, skorzystaj z danych historycznych.
  3. Jeśli zaprojektujesz swój system z myślą o instrukcjach metrycznych, w przyszłości wszystko pójdzie lepiej. W szczególności chodzi o to, żeby nie patrzeć na ciągi tekstowe w logach, aby instrumentować dane.
  4. Zobaczysz, co się zmienia, a co pozostaje bez zmian. Załóżmy na przykład, że chcesz bezpośrednio zoptymalizować liczbę użytkowników aktywnych w ciągu jednego dnia. Jednak już na wczesnym etapie manipulacji systemem możesz zauważyć, że drastyczne zmiany wrażeń użytkowników nie wpływają w sposób zauważalny na te dane.

Zespół Google Plus mierzy liczbę odczytów, udostępnień na przeczytanie, plus za przeczytanie, komentarze/przeczytane, komentarze na użytkownika, udostępnienia na użytkownika itp., które wykorzystuje do obliczania wartości atrakcyjności posta podczas wyświetlania. Ważne jest też środowisko eksperymentu, w którym możesz grupować użytkowników w zasobniki i zbierać statystyki według eksperymentu. Patrz Reguła 12.

Bardziej liberalnie w zakresie gromadzenia danych możesz uzyskać szerszy obraz systemu. Widzisz problem? Dodaj wskaźnik, aby go śledzić! Cieszy Cię pewna ilość zmian ilościowych w poprzedniej wersji? Dodaj wskaźnik, aby go śledzić!

Zasada 3. Zamiast złożonej heurystyki wybierz systemy uczące się.

Prosta metoda heurystyczna może pomóc Ci zaprezentować Twój produkt. Złożona heurystyka jest niemożliwa do utrzymania. Gdy masz już dane i podstawową koncepcję tego, co chcesz osiągnąć, przejdź do systemów uczących się. Tak jak w przypadku większości zadań inżynierii oprogramowania, warto stale aktualizować swoje podejście, niezależnie od tego, czy jest to model heurystyczny czy oparty na systemach uczących się. Przekonasz się, że taki model łatwiej jest aktualizować i obsługiwać (patrz reguła 16).

Faza I. ML: Twój pierwszy potok

W pierwszym potoku skup się na infrastrukturze systemowej. Zabawnie jest myśleć o tych wszystkich pomysłowych systemach uczących się, ale trudno będzie zrozumieć, co się stanie, jeśli nie zaufamy najpierw ich systemom uczącym się.

Zasada nr 4: zachowaj prostotę pierwszego modelu i zadbaj o odpowiednią infrastrukturę.

Pierwszy model zdecydowanie wyróżnia produkt, dlatego nie musi być zbyt wyrafinowany. Będziesz jednak napotkać znacznie więcej problemów z infrastrukturą, niż się spodziewasz. Zanim ktokolwiek będzie mógł korzystać z Twojego nowego, wymyślnego systemu uczącego się, musisz ustalić:

  • Jak uzyskać przykłady algorytmu uczenia się.
  • Pierwsze pytanie o to, co „dobre” i „złe” oznaczają dla Twojego systemu.
  • Jak zintegrować model z aplikacją. Możesz zastosować model w czasie rzeczywistym lub wstępnie obliczyć go na przykładach offline i zapisać wyniki w tabeli. Możesz na przykład wstępnie sklasyfikować strony internetowe i zapisać wyniki w tabeli, ale potem sklasyfikować wiadomości czatu na żywo.

Wybranie prostych funkcji sprawi, że:

  • Funkcje poprawnie docierają do algorytmu nauczania.
  • Model uczy się rozsądnych wag.
  • Funkcje poprawnie docierają do modelu na serwerze.

Kiedy masz już system, który niezawodnie wykonuje te 3 działania, wykonujesz większość pracy. Prosty model udostępnia wskaźniki podstawowe i podstawowe działanie, których możesz użyć do testowania bardziej złożonych modeli. Niektóre zespoły dążą do „neutralnego” wprowadzenia na rynek, czyli pierwszego podejścia, w którym wyraźnie obniżają znaczenie korzyści zapewnianych przez systemy uczące się, aby nie rozpraszać uwagi.

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

Zadbaj o to, aby infrastruktura dało się przetestować, a elementy systemu uczące się były zamknięte, aby można było testować wszystko, co jest dookoła. Oto najważniejsze kwestie:

  1. Testuj pobieranie danych do algorytmu. Sprawdź, czy kolumny cech, które powinny być wypełnione, są wypełnione. Jeśli pozwala na to prywatność, ręcznie sprawdź dane wejściowe algorytmu trenowania. W miarę możliwości sprawdzaj statystyki w swoim potoku w porównaniu ze statystykami tych samych danych przetwarzanych w innym miejscu.
  2. Testowanie pobierania modeli z algorytmu trenowania. Upewnij się, że model w środowisku treningowym ma taki sam wynik jak model w środowisku obsługi (patrz reguła 37).

Systemy uczące się cechują się nieprzewidywalnością, dlatego zadbaj o to, aby mieć testy kodu do tworzenia przykładów w trakcie trenowania i wyświetlania oraz móc wczytywać i wykorzystywać stały model podczas udostępniania. Ważne jest też, aby zrozumieć swoje dane: przeczytaj praktyczne porady dotyczące analizy dużych, złożonych zbiorów danych.

Reguła 6. Uważaj na to, by podczas kopiowania potoków utracić dane.

Często tworzymy potok, kopiując istniejący potok (programowanie związane z Cargo cult), a stary potok usuwa dane, które są potrzebne w nowym. Na przykład potok Na topie w Google Plus powoduje spadek starszych postów (ponieważ próbuje ustalać ranking nowych postów). Ten potok został skopiowany do strumienia Google Plus, gdzie starsze posty są nadal istotne, ale wciąż je usuwano. Innym częstym wzorcem jest rejestrowanie tylko tych danych, które widział użytkownik. Dane te są więc bezużyteczne, gdy chcemy określić, dlaczego dany post nie był widoczny dla użytkownika, ponieważ wszystkie negatywne przykłady zostały pominięte. Podobny problem wystąpił w Google Play. Podczas pracy na stronie głównej aplikacji Google Play utworzyliśmy nowy potok, który zawierał również przykłady ze strony docelowej Gier Play bez żadnych funkcji, które pomogłyby ustalić, skąd pochodzą poszczególne przykłady.

Zasada nr 7: przekształcanie heurystyki w funkcje lub obsługiwanie ich na zewnątrz.

Problemy, które systemy uczące się zwykle starają się rozwiązać, nie są zazwyczaj nowe. Istnieje system rankingu, klasyfikowania lub dowolnego problemu, który próbujesz rozwiązać. Oznacza to zbiór reguł i regresji heurystycznych. Te same mechanizmy heurystyczne mogą poprawić wyniki, jeśli zostaną dopracowane przy użyciu systemów uczących się. Dane heurystyczne należy wyszukiwać pod kątem posiadanych informacji z 2 powodów. Po pierwsze, przejście na system uczący się będzie płynniejsze. Po drugie, zwykle reguły te zawierają wiele intuicji co do systemu, którego nie chcesz odrzucić. Istnieją 4 sposoby korzystania z istniejących metod heurystycznych:

  • Przetwarzanie wstępne za pomocą heurystyki. Jeśli ta funkcja jest niesamowicie niesamowita, to jest taka opcja. Jeśli na przykład w filtrze spamu nadawca znajduje się już na czarnej liście, nie próbuj od nowa poznać znaczenia słowa „na czarnej liście”. Zablokuj wiadomość. To podejście ma sens w przypadku zadań klasyfikacji plików binarnych.
  • Utwórz funkcję. Bardzo dobrze jest tworzyć cechy bezpośrednio na podstawie metod heurystycznych. Jeśli np. używasz metod heurystycznych do obliczania wyniku trafności dla wyniku zapytania, możesz go uwzględnić jako wartość cechy. Później możesz użyć technik systemów uczących się do masażu wartości (np. przekonwertować wartość na jeden z skończonego zestawu wartości dyskretnych lub połączyć ją z innymi cechami), ale zacznij od użycia nieprzetworzonej wartości wytworzonej przez heurystyczną.
  • Wydobywać nieprzetworzone dane wejściowe heurystyki. Jeśli istnieją metody heurystyczne, które łączą liczbę instalacji, liczbę znaków w tekście i dzień tygodnia, rozważ rozdzielenie tych elementów i wpisanie ich do systemu nauki osobno. Tutaj możesz zastosować niektóre techniki stosowane w zespołach (patrz reguła 40).
  • Zmodyfikuj etykietę. Użyj tej opcji, jeśli Twoim zdaniem metoda heurystyczna rejestruje informacje nieuwzględnione obecnie w etykiecie. Jeśli na przykład chcesz zmaksymalizować liczbę pobrań, ale jednocześnie zależy Ci na treściach wysokiej jakości, być może rozwiązaniem będzie pomnożenie etykiety przez średnią liczbę gwiazdek, które otrzymała aplikacja. Zostało tu sporo swobody. Patrz „Twój pierwszy cel”.

Pamiętaj o większej złożoności korzystania z heurystyki w systemie ML. Wykorzystanie starych heurystyki w nowym algorytmie systemów uczących się może pomóc w zapewnieniu płynnego przejścia. Zastanów się jednak, czy istnieje prostszy sposób na osiągnięcie tego samego efektu.

Monitorowanie

Ogólnie rzecz biorąc, przestrzegaj zasad higieny wysyłania alertów, m.in. stosuj alerty w praktyce i miej stronę panelu.

Zasada nr 8: poznaj wymagania dotyczące aktualności swojego systemu.

Jak bardzo spada wydajność, jeśli masz model mający jeden dzień? Od tygodnia? Kwartał ? Te informacje pomogą Ci ustalić priorytety monitorowania działalności. Jeśli utracisz znaczną jakość produktów, jeśli model nie zostanie zaktualizowany przez 1 dzień, rozsądnie będzie zatrudnić inżyniera do stałego oglądania produktu. Większość systemów wyświetlania reklam codziennie ma nowe reklamy do wyświetlenia i musi je aktualizować. Jeśli na przykład nie zaktualizujesz modelu ML w wyszukiwarce w Google Play, może to mieć negatywny wpływ w okresie krótszym niż miesiąc. Niektóre modele w Google Plus nie mają identyfikatora posta, więc mogą rzadko je eksportować. Inne modele z identyfikatorami postów są aktualizowane znacznie częściej. Zauważ też, że aktualność może się zmieniać z czasem, zwłaszcza gdy do modelu są dodawane kolumny cech lub z niego usuwane.

Zasada nr 9. Wykrywaj problemy przed wyeksportowaniem modeli.

Wiele systemów uczących się ma etap, na którym eksportujesz model do udostępniania. Jeśli występuje problem z wyeksportowanym modelem, jest on widoczny dla użytkowników.

Bezpośrednio przed wyeksportowaniem modelu przeprowadź jego kontrolę zdrowotną. W szczególności należy zadbać o to, aby skuteczność modelu była uzasadniona w odniesieniu do przechowywanych danych. Jeśli masz wątpliwości dotyczące danych, nie eksportuj modelu. Wiele zespołów stale wdrażających modele sprawdza obszar pod krzywą ROC (lub AUC) przed eksportem. W przypadku problemów z modelami, które nie zostały wyeksportowane, wymagane są alerty e-mail, a problemy w modelu dla użytkowników mogą wymagać strony. Dlatego lepiej poczekać i zachować pewność, że wpłyną one na użytkowników.

Zasada 10. Uważaj na ciche niepowodzenia.

Ten problem występuje częściej w przypadku systemów uczących się niż systemów innych typów. Załóżmy, że konkretna tabela, do której chcesz dołączyć, nie jest już aktualizowana. System systemów uczących się będzie się dostosowywać i działać w dobrym stylu, a jego działanie będzie stopniowo pogarszać. Czasami możesz znaleźć tabele nieaktualne, a proste odświeżenie sprawia, że poprawia się skuteczność bardziej niż jakakolwiek inna funkcja w danym kwartale. Zasięg funkcji może się zmienić z powodu zmian w implementacji, np. kolumna cech może być wypełniona w 90% przykładów i nagle spada do 60% przykładów. Dawniej stolik w Google Play był nieaktualny przez 6 miesięcy, a odświeżenie go spowodowało wzrost liczby instalacji o 2%. Jeśli śledzisz statystyki danych i od czasu do czasu je przeprowadzasz ręcznie, możesz ograniczyć liczbę tego typu błędów.

Reguła 11. Udostępnij właścicieli kolumn funkcji i zapewnij im dokumentację.

Jeśli system jest duży i jest wiele kolumn cech, sprawdź, kto utworzył lub przechowuje poszczególne kolumny. Jeśli stwierdzisz, że osoba, która rozumie kolumnę cech, wychodzi z niej, upewnij się, że ma te informacje. Chociaż wiele kolumn cech ma nazwy opisowe, warto podać bardziej szczegółowy opis cech, ich źródła oraz sposobu, w jaki ma być pomocny.

Twój pierwszy cel

Masz wiele rodzajów danych (czyli wartości) związanych z systemem, który Cię interesuje, ale algorytm systemów uczących się często wymaga jednego celu – liczby, którą próbuje on zoptymalizować. Teraz odróżniam cele od danych: dane to dowolna liczba raportowana przez Twój system, która może, ale nie musi być ważna. Zapoznaj się też z regułą nr 2.

Zasada nr 12: nie zastanawiaj się zbyt długo, który cel chcesz bezpośrednio zoptymalizować.

Chcesz zarabiać pieniądze, dbać o zadowolenie użytkowników i zmieniać świat na lepsze. Dostępnych jest mnóstwo wskaźników, na których Ci zależy, i mierz je wszystkie (patrz Reguła 2). Na wczesnym etapie działania systemów uczących się zauważysz je wszystkie, nawet te, które nie są optymalizowane bezpośrednio. Załóżmy np., że zależy Ci na liczbie kliknięć i czasie spędzonym w witrynie. Jeśli optymalizujesz kampanię pod kątem liczby kliknięć, zaobserwujesz prawdopodobnie dłuższy czas trwania optymalizacji.

Trzymaj się prostych rozwiązań i nie zagłębiaj się w równowagę między różnymi wskaźnikami, skoro możesz z łatwością zwiększać ich liczbę. Nie należy jednak przesadzać z zasadami: nie należy mylić celu z ostateczną sytuacją w systemie (patrz Reguła nr 39). Jeśli stwierdzisz, że zwiększasz bezpośrednio zoptymalizowane dane, ale nie chcesz ich uruchamiać, konieczna może być obiektywna zmiana.

Zasada nr 13: jako pierwszy cel wybierz proste, obserwowalne i przydatne dane.

Często nie wiemy, jaki jest prawdziwy cel. Myślisz, że tak, ale gdy analizujesz dane i analizę zarówno starego, jak i nowego systemu uczącego się, zdajesz sobie sprawę, że musisz zmienić cel. Co więcej, różni członkowie zespołu często nie mogą dojść do porozumienia. Cel związany z systemami uczącymi się powinien być łatwy do zmierzenia i być wiarygodnym elementem. W rzeczywistości często nie ma „prawdziwego” celu (patrz Reguła 39). Wytrenuj prosty cel związany z systemami uczącymi się i zastanów się nad dodaniem „warstwy zasad”, która pozwoli na dodanie dodatkowej logiki (mam nadzieję, że jest to bardzo prosta logika) opracowania ostatecznego rankingu.

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

  • Czy kliknięto ten rankingowy link?
  • Czy ten oceniony obiekt został pobrany?
  • Czy ten sklasyfikowany obiekt został przekazany lub wysłana odpowiedź albo wysłano e-maila?
  • Czy ten oceniony obiekt został oceniony?
  • Czy pokazany obiekt został oznaczony jako spam, pornografia lub obraźliwe treści?

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

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

Efekty pośrednie to świetne dane, które można wykorzystać podczas testów A/B oraz przy podejmowaniu decyzji o wprowadzeniu aplikacji na rynek.

Nie próbuj sprawić, by systemy uczące się rozpoznawały:

  • Czy użytkownik jest zadowolony z produktu?
  • Czy użytkownik jest zadowolony z tej funkcji?
  • Czy produkt poprawia ogólne samopoczucie użytkownika?
  • Jak wpłynie to na ogólny stan firmy?

To wszystko jest ważne, ale też niezwykle trudne do zmierzenia. Zamiast tego używaj serwerów proxy: jeśli użytkownik będzie zadowolony, pozostał w witrynie dłużej. Jeśli użytkownik będzie zadowolony, ponownie odwiedzą stronę jutro. Jeśli chodzi o dobre samopoczucie i zdrowie firmy, kluczowa jest ocena człowieka, która pozwoli nam powiązać każdy wyuczony cel przez system z charakterem sprzedawanego produktu i z Twoim biznesplanem.

Zasada nr 14. Rozpoczęcie od zinterpretowalnego modelu ułatwia debugowanie.

Regresja liniowa, logistyczna i Poissona są bezpośrednio motywowane przez model prawdopodobny. Każdą prognozę można interpretować jako prawdopodobieństwo lub oczekiwaną wartość. Ułatwia to debugowanie w porównaniu z modelami wykorzystującymi cele (utrata 0 1, różne zawiasy itp.), które próbują bezpośrednio zoptymalizować dokładność klasyfikacji lub wydajność rankingu. Jeśli na przykład prawdopodobieństwa w trenowaniu odbiegają od prawdopodobieństwa prognozowanych jednocześnie lub w systemie produkcyjnym, odchylenie to może ujawnić problem.

Na przykład w regresji liniowej, logistycznej lub regresji Poissona występują podzbiory danych, w których średnia prognozowana wartość ma wartość średnią (skalibrowana 1-momentowa lub po prostu kalibrowana). Dzieje się tak przy założeniu, że nie występują u Ciebie żadne regularności, a algorytm uległ zbieżności. Ogólnie jest to mniej więcej prawdziwa rzeczywistość. Jeśli masz cechę, która w każdym przykładzie ma wartość 1 lub 0, zostanie skalibrowany zestaw 3 przykładów, w których ta cecha ma wartość 1. Poza tym, jeśli masz funkcję, która ma dla każdego przykładu wartość 1, kalibrowany jest zbiór wszystkich przykładów.

W przypadku prostych modeli łatwiej jest poradzić sobie z pętlą informacji zwrotnych (patrz reguła 36). Często w podejmowaniu decyzji wykorzystujemy te prognozy prawdopodobieństwa, np. ranking postów zmniejsza się oczekiwaną wartością (czyli prawdopodobieństwie kliknięcia, pobrania itd.). Pamiętaj jednak, że przy wyborze modelu decyzja ma większe znaczenie niż prawdopodobieństwo, że dane zostaną przekazane przez model (patrz reguła 27).

Reguła 15. Oddzielne filtrowanie spamu i ranking jakości na warstwie zasad.

Ranking jakości to sztuka, ale odfiltrowywanie spamu to wojna. Sygnały używane do określania wysokiej jakości postów będą oczywiste dla użytkowników Twojego systemu i będą oni odpowiednio dostosowywać swoje posty. Dlatego ranking jakości powinien skupiać się na rankingu treści opublikowanych w dobrej wierze. Nie należy umniejszać pozycji osoby oceniającej ranking jako spam przez wysoki poziom rankingowy spamu. Również treści dla dorosłych należy traktować niezależnie od rankingu jakości. To zupełnie inna sprawa dotycząca filtrowania spamu. Trzeba się spodziewać, że funkcje, które trzeba wygenerować, będą stale się zmieniać. System często wprowadza oczywiste reguły (jeśli post otrzymał więcej niż 3 głosy jako spam, nie pobieraj go itd.). Każdy zapamiętany model trzeba będzie aktualizować codziennie, a nawet szybciej. Reputacja twórcy treści jest bardzo ważna.

Na pewnym poziomie będzie trzeba zintegrować dane wyjściowe tych 2 systemów. Pamiętaj, że filtrowanie spamu w wynikach wyszukiwania powinno być prawdopodobnie bardziej agresywne niż filtrowanie spamu w e-mailach. Standardową praktyką jest też usuwanie spamu z danych treningowych dla klasyfikatora jakości.

Faza systemów uczących się, etap II: inżynieria funkcji

W pierwszej fazie cyklu życia systemu uczącego się najważniejszymi kwestiami jest umieszczenie danych treningowych w systemie, przygotowanie odpowiednich danych i stworzenie infrastruktury obsługującej. Gdy utworzysz kompleksowy system z instrumentowanymi testami jednostowymi i systemowymi, rozpocznie się faza II.

W drugiej fazie jest dużo nisko rosnących owoców. Do systemu można dodać wiele oczywistych funkcji. Dlatego druga faza systemów uczących się polega na wykorzystaniu jak największej liczby funkcji i ich łączeniu w intuicyjny sposób. Na tym etapie wszystkie wskaźniki powinny nadal rosnąć. Planujemy wprowadzić dużo zmian i jest to świetny moment na zatrudnienie wielu inżynierów, którzy będą mogli połączyć wszystkie dane potrzebne do stworzenia naprawdę świetnego systemu uczącego się.

Zasada nr 16: planuj rozpoczęcie kampanii i jej powtórzenie.

Nie oczekuj, że model, nad którym teraz pracujesz, nie będzie modelem, który zostanie wprowadzony na rynek, ani że kiedykolwiek zostanie on wycofany. Zastanów się więc, czy złożoność tego wdrożenia nie spowolni ich wprowadzania w przyszłości. Wiele zespołów od lat wprowadza model na kwartał na kwartał lub więcej. Są 3 podstawowe powody, dla których warto wprowadzić nowe modele:

  • Przygotowujesz też nowe funkcje
  • Dostrajasz regularyzację i łączysz stare funkcje na nowe sposoby.
  • Dopasowujesz cel.

Niezależnie od tego osądź modelowi nieco uczucia z miłością: przejrzenie informacji pochodzących z tego przykładu może pomóc w znalezieniu zarówno nowych, jak i starszych sygnałów. Podczas tworzenia modelu zastanów się, jak łatwo można dodawać, usuwać i łączyć funkcje. Zastanów się, jak łatwo można utworzyć nową kopię potoku i sprawdzić jego poprawność. Zastanów się, czy można jednocześnie tworzyć dwie lub trzy kopie. I nie martw się, czy funkcja 16 z 35 trafi do tej wersji potoku. Otrzymasz go w następnym kwartale.

Zasada 17. Zacznij od bezpośrednio zaobserwowanych i raportowanych funkcji, a nie od poznanych funkcji.

Może to być dość kontrowersyjna kwestia, ale eliminuje wiele pułapek. Najpierw wyjaśnijmy, czym jest nauczona funkcja. Nauczona cecha to cecha wygenerowana przez system zewnętrzny (np.nienadzorowany system grupowania) lub przez ucznia (np. za pomocą modelu czynnikowego lub deep learning). Obie te metody mogą być przydatne, ale mogą powodować wiele problemów, dlatego nie powinny być używane w pierwszym modelu.

Jeśli do tworzenia cech używasz systemu zewnętrznego, pamiętaj, że ma on swój własny cel. Cel systemu zewnętrznego może być tylko słabo skorelowany z Twoim obecnym celem. Jeśli wygenerujesz zrzut systemu zewnętrznego, może on stać się nieaktualny. Jeśli zaktualizujesz funkcje w systemie zewnętrznym, ich znaczenie może się zmienić. Jeśli do udostępniania funkcji używasz zewnętrznego systemu, pamiętaj, że to podejście wymaga dużej uwagi.

Głównym problemem w przypadku modeli czynnikowych i precyzyjnych modeli jest to, że są one niewypukłe. Nie ma więc gwarancji, że uda się znaleźć optymalne rozwiązanie, a lokalne minimum znalezione w każdej iteracji może być inne. Ta wariacja utrudnia ocenę, czy wpływ zmiany w systemie jest znaczący czy przypadkowy. Tworząc model bez szczegółowych funkcji, uzyskasz doskonałą wydajność bazową. Po osiągnięciu tego punktu odniesienia można spróbować bardziej skomplikowanych metod.

Zasada nr 18. Eksploruj za pomocą funkcji treści, które uogólniają treści w różnych kontekstach.

Często system systemów uczących się jest niewielką częścią znacznie większego obrazu. Jeśli na przykład wyobrazisz sobie, że wpis, który mógłby zostać wykorzystany w Na topie, wiele osób da mu +1, udostępni go lub skomentuje, zanim zostanie on opublikowany w Na topie. Jeśli dostarczysz te statystyki, będzie ona mogła promować nowe posty, dla których nie ma żadnych danych, w kontekście optymalizacji. Warte obejrzenia w YouTube mogą obejmować liczbę obejrzeń, czyli wspólne oglądanie (pokazuje, ile razy jeden film był obejrzany po drugim) z wyników wyszukiwania w YouTube. Możesz też używać bezpośrednich ocen użytkowników. I wreszcie, jeśli używasz działania użytkownika, którego używasz jako etykiety, zobaczenie tego działania w dokumencie w innym kontekście może być bardzo przydatne. Wszystkie te funkcje pozwalają uwzględnić nowe treści w kontekście. Pamiętaj, że tu nie chodzi o personalizację: najpierw sprawdź, czy komuś odpowiada dany kontekst, a później zorientuj się, komu bardziej się on podoba.

Zasada nr 19: jeśli to możliwe, używaj bardzo konkretnych funkcji.

Przy dużej ilości danych łatwiej jest poznać miliony prostych funkcji niż kilka złożonych funkcji. Identyfikatory pobieranych dokumentów i zapytań kanonicznych nie zapewniają znacznego uogólnienia, ale dostosowują ranking do etykiet w zapytaniach głównych. Nie bój się grup funkcji, w przypadku których każda z nich ma zastosowanie tylko do niewielkiej części Twoich danych, ale ogólne pokrycie przekracza 90%. Możesz użyć regularyzacji, aby wyeliminować te, które dotyczą zbyt małej liczby przykładów.

Zasada nr 20: łącz i modyfikuj istniejące funkcje, aby tworzyć nowe w sposób zrozumiały dla człowieka.

Istnieje wiele sposobów łączenia i modyfikowania funkcji. Systemy uczące się, takie jak TensorFlow, umożliwiają wstępne przetwarzanie danych przez przekształcenia. Dwa najbardziej standardowe podejścia to „dyskretyzacje” i „krzyże”.

Dyskretyzacja obejmuje stosowanie ciągłej funkcji i tworzenie z niej wielu odrębnych cech. Warto rozważyć stałe elementy, takie jak wiek. Możesz utworzyć cechę o wartości 1, gdy masz mniej niż 18 lat, inną cechę, czyli 1, gdy wiek jest między 18 a 35 lat, i tak dalej. Nie zastanawiaj się zbyt mocno granicami histogramu. Podstawowe kwantyle dają największy efekt.

Krzyże łączą dwie lub więcej kolumn cech. Kolumna cech w terminologii TensorFlow to zbiór jednorodnych cech (np. {male, Female}, {US, Canada, Mexico} itd.). Krzyżyk to nowa kolumna cech zawierająca cechy, np. {male, Female} × {US,Canada, Mexico}. Ta nowa kolumna cech będzie zawierać daną cechę (mężczyzna, Kanada). Jeśli używasz TensorFlow i prosisz TensorFlow, by utworzył ten krzyżyk, ta funkcja (mężczyźni z Kanady) pojawi się w przykładach reprezentujących mężczyzn z Kanady. Pamiętaj, że poznanie modeli z krzyżykami zawierającymi 3, 4 lub więcej kolumn cech podstawowych wymaga ogromnych ilości danych.

Krzyże, które generują bardzo duże kolumny cech, mogą się przeciążyć. Wyobraź sobie na przykład, że przeprowadzasz pewne wyszukiwanie, a w zapytaniu masz kolumnę cech ze słowami oraz kolumnę cech ze słowami z dokumentu. Możesz je połączyć krzyżowo, ale w rezultacie uzyskasz wiele właściwości (zobacz regułę 21).

Podczas pracy z tekstem są dwie możliwości. Najbardziej drakoński to iloczyn punktowy. Iloczyn skalarny w najprostszej postaci zlicza po prostu liczbę słów wspólnych w zapytaniu i dokumencie. Tę funkcję można następnie dyskretować. Innym podejściem jest skrzyżowanie: w tym przypadku funkcja występuje tylko wtedy, gdy słowo „pony” występuje zarówno w dokumencie, jak i w zapytaniu, oraz tylko wtedy, gdy słowo „the” występuje zarówno w dokumencie, jak i w zapytaniu.

Zasada nr 21: liczba wag cech, których można poznać w modelu liniowym, jest mniej więcej proporcjonalna do ilości posiadanych danych.

Istnieją fascynujące wyniki dotyczące teorii statystycznych dotyczących odpowiedniego poziomu złożoności modelu, ale ta reguła to w zasadzie wszystko, co musisz wiedzieć. Podczas rozmów z użytkownikami mieliśmy wątpliwości co do tego, czy można czegoś się nauczyć z tysiąca przykładów albo że potrzeba więcej niż miliona przykładów, ponieważ utknęli w określonej metodzie uczenia się. Najważniejsze jest dostosowanie procesu uczenia się do ilości danych:

  1. Jeśli pracujesz nad systemem rankingowym w wynikach wyszukiwania i w dokumentach i zapytaniu są miliony różnych słów oraz masz 1000 oznaczonych etykietami, użyj iloczynu punktowego między funkcjami dokumentów i zapytań, TF-IDF, i pół tuzina innych funkcji stworzonych przez człowieka. 1000 przykładów, kilkanaście funkcji.
  2. Jeśli masz milion przykładów, przełóż kolumny cech dokumentu i zapytania, stosując regularyzację i ewentualnie wybór cech. Dzięki temu będziesz mieć miliony funkcji, ale przy regularności będziesz mieć ich mniej. Dziesięć milionów przykładów, a może nawet sto tysięcy funkcji.
  3. Jeśli masz miliardy lub setki miliardów przykładów, możesz przekreślić kolumny cech z tokenami dokumentów i zapytań, korzystając z wyboru cech i regularności. Znajdziesz tam miliard przykładów i 10 milionów funkcji. Teoria uczenia statystycznego rzadko eliminuje ścisłe granice, ale stanowi świetną wskazówkę jako punkt wyjścia.

Ostatecznie skorzystaj z reguły nr 28, aby zdecydować, których funkcji chcesz używać.

Zasada nr 22: usuń dane z funkcji, których już nie używasz.

Nieużywane funkcje tworzą dług technologiczny. Jeśli okaże się, że nie korzystasz z danej funkcji, a połączenie jej z innymi nie działa, usuń ją ze swojej infrastruktury. Chcesz utrzymać czystość infrastruktury, aby można było jak najszybciej wypróbować najbardziej obiecujące funkcje. W razie potrzeby ktoś zawsze może przywrócić ją z powrotem.

Zastanów się, które funkcje warto dodać, a które zachować. Ile przykładów obejmuje ta funkcja? Jeśli np. masz jakieś funkcje personalizacji, ale tylko 8% użytkowników ma je, nie będzie ono zbyt skuteczne.

Jednocześnie niektóre funkcje mogą znacznie przekroczyć swoją wagę. Jeśli np. korzystasz z funkcji obejmującej tylko 1% danych, podczas gdy 90% pozytywnych przykładów z nią jest pozytywnych, warto ją dodać.

Analiza ludzkiego układu

Przed przejściem do trzeciej fazy systemów uczących się warto skupić się na czymś, czego nie omówiono na żadnej lekcji dotyczącej tych systemów: jak spojrzeć na istniejący model i go ulepszyć. To bardziej sztuka niż nauka, ale jest kilka antywzorców, których należy unikać.

Zasada nr 23: nie jesteś typowym użytkownikiem.

To chyba najprostszy sposób dla zespołu na zanurzenie. Testy wewnętrzne mają wiele zalet (korzystanie z prototypu w zespole) i testowanie (używanie prototypu w firmie), jednak pracownicy powinni sprawdzać, czy skuteczność jest prawidłowa. Nie należy stosować zmiany, która jest ewidentnie niepożądana, ale wszystko, co wydaje się być niemal niewykonalne, powinno zostać poddane dalszym testom. Mogą to być płatności laików za odpowiadanie na pytania na platformie crowdsourcing lub przeprowadzanie eksperymentów na żywo z udziałem prawdziwych użytkowników.

Dzieje się tak z dwóch powodów. Po pierwsze, znajdujesz się za blisko kodu. Być może szukasz konkretnego aspektu postów lub po prostu zbyt angażujesz się emocjonalnie (np. stronniczość potwierdzania). Po drugie, Twój czas jest zbyt cenny. Weźmy pod uwagę koszty dziewięciu inżynierów siedzących na godzinnym spotkaniu i liczby zakontraktowanych wytwórni, które kupują produkty na platformie crowdsourcing.

Jeśli naprawdę zależy Ci na opiniach użytkowników, zastosuj metodologie związane z wrażeniami użytkowników. Twórz profile użytkowników (jeden opis znajduje się w artykule Sketching User Experiences Billa Buxtona) na wczesnym etapie procesu i przeprowadzaj testy użyteczności (jeden opis znajduje się w publikacji Don’t Make Me Think autorstwa Steve'a Kruga). Profile klientów obejmują tworzenie hipotetycznego użytkownika. Jeśli na przykład cały zespół składa się z mężczyzn, warto zaprojektować profil użytkownika 35-letniej kobiety (wraz z funkcjami użytkownika) i przyjrzeć się osiąganym wynikom zamiast 10 wyników w przypadku mężczyzn w wieku 25–40 lat. Jeśli zachęcisz użytkowników do obserwowania ich reakcji na stronę (lokalnie lub zdalnie), podczas testów użyteczności możesz też spojrzeć na nią z nowej perspektywy.

Zasada nr 24: zmierz różnice między modelami.

Jednym z najprostszych i czasem najprzydatniejszych pomiarów, jakie można wykonać, zanim użytkownicy zaczną korzystać z nowego modelu, jest obliczenie, jak bardzo nowe wyniki różnią się od wyników uzyskanych w środowisku produkcyjnym. Jeśli np. masz problem z pozycją w rankingu, uruchom oba modele na próbce zapytań w całym systemie i sprawdź rozmiar symetrycznej różnicy wyników (ważonych według pozycji w rankingu). Jeśli różnica jest bardzo mała, można stwierdzić bez przeprowadzania eksperymentu, że nie będzie żadnych zmian. Jeśli różnica jest bardzo duża, musisz mieć pewność, że zmiana będzie zadowalająca. Przyjrzenie się zapytaniom, w których różnica symetryczna jest duża, pomoże Ci zrozumieć istotną jakość zmiany. Upewnij się jednak, że system jest stabilny. Dopilnuj, aby różnica symetryczna między modelem a modelem była niska (najlepiej zero).

Zasada nr 25: przy wyborze modeli wydajność użytkowa przeważa nad mocą predykcyjną.

Model może próbować przewidzieć współczynnik klikalności. Ostatecznie najważniejsze pytanie to jednak to, co z tą prognozą wykorzystano. Jeśli używasz go do pozycjonowania dokumentów, większa jakość ostatecznej pozycji w rankingu niż sama prognoza. Jeśli zidentyfikujesz prawdopodobieństwo, że dokument jest spamem, a następnie ustalisz, co zostanie zablokowane, bardziej liczy się precyzja tego, co jest dozwolone. Zwykle te 2 rzeczy muszą być zgodne: jeśli się nie zgadzają, będzie to raczej na niewielkim zysku. Jeśli więc nastąpi zmiana, która zwiększa utratę logów, ale zmniejsza wydajność systemu, poszukaj innej funkcji. Gdy to się stanie częściej, warto ponownie przyjrzeć się celowi modelu.

Reguła 26: wyszukaj wzorce w pomiarach błędów i utwórz nowe funkcje.

Załóżmy, że widzisz przykład treningowy, że model został „błędny”. W zadaniu klasyfikacji ten błąd może być fałszywie dodatni lub fałszywie negatywny. W zadaniu rankingowym błąd może występować w przypadku pary, w której wartość dodatnia jest niższa niż ujemna. Najważniejsze jest to, że system uczący się wie, że popełnił błąd i chce go naprawić, jeśli tylko nadarzy się taka możliwość. Jeśli udostępnisz modelowi funkcję, która umożliwia mu naprawienie błędu, model spróbuje jej użyć.

Z drugiej strony jeśli spróbujesz utworzyć funkcję na podstawie przykładów, której system nie uzna za błędy, zostanie ona zignorowana. Załóżmy na przykład, że w wyszukiwarce aplikacji Google Play ktoś wyszukuje „bezpłatne gry”. Załóżmy, że jeden z najlepszych wyników to mniej trafna aplikacja GAG. Tworzysz funkcję aplikacji GAG. Jeśli jednak chcesz zmaksymalizować liczbę instalacji, a użytkownicy zainstalują aplikację GAG, szukając bezpłatnych gier, funkcja „gagów” nie przyniesie oczekiwanego efektu.

Gdy już uzyskasz przykłady błędów w modelu, poszukaj trendów spoza obecnego zestawu funkcji. Jeśli na przykład system wydaje się degradować dłuższe posty, dodaj ich długość. Nie dodawaj zbyt szczegółowych informacji o funkcjach, które dodajesz. Jeśli chcesz dodać długość posta, nie próbuj zgadywać, co to znaczy, dodaj kilkanaście funkcji, a model sam domyśli, co z nimi zrobić (patrz Reguła nr 21). To najprostszy sposób, aby osiągnąć zamierzony efekt.

Zasada nr 27. Spróbuj ocenić zaobserwowane niepożądane zachowania.

Niektórzy członkowie Twojego zespołu zaczną frustrować się właściwościami systemu, które nie są im potrzebne, a które nie są przechwytywane przez istniejącą funkcję straty. Na tym etapie powinni zacząć robić wszystko, co w ich mocy, aby ich problemy przyniosły miarodajne wyniki. Jeśli na przykład uznają, że w wyszukiwarce Google Play pojawia się za dużo takich aplikacji, mogą skorzystać z pomocy weryfikatorów. W tym przypadku możesz użyć danych oznaczonych etykietami przez człowieka, ponieważ stosunkowo niewielka część zapytań odpowiada za dużą część ruchu. Jeśli problemy są wymierne, możesz zacząć ich używać jako funkcji, celów lub wskaźników. Ogólna zasada to „zmierz najpierw, optymalizuj potem”.

Zasada nr 28: pamiętaj, że identyczne krótkoterminowe zachowanie nie jest równoznaczne z identycznym działaniem w dłuższej perspektywie.

Wyobraź sobie, że masz nowy system, który analizuje każdy identyfikator doc_id i dokładny_zapytanie, a potem oblicza prawdopodobieństwo kliknięcia dla każdego dokumentu dla każdego zapytania. Okazuje się, że działa ono niemal tak samo jak obecny system zarówno pod względem skuteczności, jak i w testach A/B, dlatego z powodu jego prostoty uruchamiasz go. Widzisz jednak, że nie wyświetlają się żadne nowe aplikacje. Dlaczego? Ponieważ system wyświetla dokument tylko na podstawie jego własnej historii z tym zapytaniem, nie da się dowiedzieć, czy powinien wyświetlić się nowy dokument.

Jedynym sposobem, aby zrozumieć, jak system będzie działał w dłuższej perspektywie, jest trenowanie tylko na danych zebranych, gdy model był aktywny. To bardzo trudne.

Zniekształcenie podczas trenowania

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

  • Rozbieżność między sposobem obsługi danych w potokach trenowania i obsługi.
  • Zmiana danych między trenowaniem a wyświetlaniem.
  • Pętla informacji zwrotnych między modelem a algorytmem.

Zaobserwowaliśmy w Google produkcyjne systemy uczące się, w których występuje zniekształcenie w zakresie udostępniania trenowania, które negatywnie wpływa na wydajność. Najlepszym rozwiązaniem jest monitorowanie go tak, aby zmiany w systemie i danych nie powodowały niezauważonych zniekształceń.

Zasada nr 29. Najlepszy sposób, by mieć pewność, że trenujesz tak samo, jak korzystasz z serwisu, zapisz zestaw funkcji używanych w czasie wyświetlania, a potem umieść je w dzienniku, aby korzystać z nich w trakcie trenowania.

Nawet jeśli nie możesz tego zrobić w przypadku każdego przykładu, zrób to dla małego ułamka, by umożliwić sprawdzenie spójności między udostępnianiem a trenowaniem (zobacz regułę 37). Zespoły, które przeprowadziły te pomiary w Google, były czasem zaskoczone wynikami. YouTubewłączyliśmy funkcje rejestrowania, co pozwoliło znacznie poprawić jakość i zmniejszyć złożoność kodu, a wiele zespołów zmienia swoją infrastrukturę, o czym mówimy.

Zasada nr 30: próbkowane dane o wadze ważności – nie usuwaj ich arbitralnie.

Gdy danych jest za dużo, istnieje pokusa, aby przyjąć pliki 1–12 i zignorować pliki 13–99. To błąd. Chociaż dane, które nigdy nie zostały wyświetlone użytkownikowi, mogą zostać usunięte, ale ważenie ważności jest najlepsze w przypadku spoczynku. Ważenie ważności oznacza, że jeśli chcesz wykorzystać przykład X z prawdopodobieństwem równym 30%, przypiszesz mu wagę 10/3. Przy uwzględnianiu wagi wszystkie właściwości kalibracji omówione w regule 14 są nadal aktualne.

Zasada nr 31. Pamiętaj, że jeśli dołączysz dane z tabeli w czasie trenowania i wyświetlania, dane w tabeli mogą się zmienić.

Załóżmy, że złączasz identyfikatory dokumentów z tabelą zawierającą funkcje tych dokumentów (takie jak liczba komentarzy lub kliknięć). W okresie między trenowaniem a udostępnianiem funkcje w tabeli mogą się zmieniać. Prognozowanie modelu dotyczące tego samego dokumentu może się różnić między trenowaniem a wyświetlaniem. Najprostszym sposobem na uniknięcie tego typu problemów jest logowanie cech podczas wyświetlania (zobacz regułę nr 32). Jeśli tabela zmienia się tylko powoli, możesz też wyświetlać jej zrzuty co godzinę lub codziennie, aby w rozsądny sposób zamknąć dane. Pamiętaj, że to nadal nie rozwiąże problemu.

Reguła 32. W miarę możliwości wykorzystaj ponownie kod między potokiem trenowania a potokiem udostępniania.

Przetwarzanie wsadowe różni się od przetwarzania online. W przypadku przetwarzania online każde żądanie trzeba obsłużyć w momencie napływania (np. każde zapytanie należy wyszukać osobno), a w przypadku przetwarzania wsadowego można łączyć zadania (np. tworzyć złączenia). W momencie udostępniania wykonujesz przetwarzanie online, a trening to zadanie przetwarzania wsadowego. Są jednak sposoby, aby wykorzystać go wielokrotnie. Możesz na przykład utworzyć obiekt przeznaczony specjalnie dla Twojego systemu, w którym wyniki dowolnych zapytań lub złączeń mogą być przechowywane w sposób zrozumiały dla człowieka, a błędy można łatwo przetestować. Następnie, gdy zbierzesz wszystkie informacje, podczas udostępniania lub trenowania stosujesz wspólną metodę łączenia między obiektem zrozumiałym dla człowieka, charakterystycznym dla danego systemu, a także formatem, jakiego oczekuje system systemów uczących się. Wyeliminuje to źródło zniekształceń między trenowaniem a wytrenowaniem. Pamiętaj, aby nie używać 2 różnych języków programowania w trakcie trenowania i wyświetlania. Jeśli to zrobisz, udostępnianie kodu będzie niemal niemożliwe.

Reguła 33: jeśli utworzysz model na podstawie danych do 5 stycznia, przetestuj go na podstawie danych od 6 stycznia.

Ogólnie rzecz biorąc, mierz wydajność modelu na podstawie danych zgromadzonych po wytrenowaniu modelu, ponieważ lepiej odzwierciedla to, co system będzie robić w środowisku produkcyjnym. Jeśli utworzysz model na podstawie danych do 5 stycznia, przetestuj go na danych od 6 stycznia. Spodziewasz się, że w przypadku nowych danych skuteczność nie będzie już tak wysoka, ale nie będzie radykalnie obniżona. Ponieważ mogą to być efekty codzienne, nie można przewidzieć średniego współczynnika kliknięć ani współczynnika konwersji. Jednak obszar pod krzywą, który reprezentuje prawdopodobieństwo uzyskania wyniku pozytywnego lub negatywnego, powinien być dość zbliżony.

Zasada nr 34: w klasyfikacji binarnej służących do filtrowania (np. wykrywaniu spamu lub określaniu interesujących e-maili) wprowadzaj bardzo małe zmiany w wydajności, aby uzyskać bardzo przejrzyste dane.

W zadaniu filtrowania przykłady oznaczone jako negatywne nie są wyświetlane użytkownikowi. Załóżmy, że masz filtr, który podczas wyświetlania blokuje 75% negatywnych przykładów. Pobieranie dodatkowych danych treningowych z instancji wyświetlanych użytkownikom może być kuszące. Jeśli na przykład użytkownik oznaczy e-maila jako spam, przez który filtr został odfiltrowany, możesz wyciągnąć z tego wnioski.

Takie podejście powoduje jednak stronniczość w zakresie próbkowania. Jeśli zamiast tego podczas wyświetlania oznaczysz 1% całego ruchu jako „wstrzymany”, możesz zebrać czystsze dane, a potem wysłać użytkownikowi wszystkie wstrzymane przykłady. Teraz filtr blokuje co najmniej 74% negatywnych przykładów. Te opublikowane przykłady mogą stać się Twoimi danymi treningowymi.

Pamiętaj, że jeśli filtr blokuje co najmniej 95% negatywnych przykładów, takie podejście staje się mniej skuteczne. Jednak jeśli chcesz mierzyć skuteczność wyświetlania, możesz utworzyć jeszcze prostszą próbkę (np. 0,1% lub 0,001%). Do dość dokładnego oszacowania skuteczności wystarczy 10 tys. przykładów.

Zasada nr 35: wystrzegaj się nieodłącznego zniekształceń w rankingu.

Jeśli zmienisz algorytm tak radykalnie, że pojawią się inne wyniki, musisz zmienić dane, które algorytm będzie widzieć w przyszłości. Powstanie takie odchylenie, które należy uwzględnić w modelu. Można to zrobić na kilka sposobów. Wszystkie te metody faworyzują dane już zarejestrowane przez model.

  1. Zadbaj o lepszą regularyzację funkcji, które obejmują więcej zapytań, w odróżnieniu od tych, które są włączone tylko dla jednego zapytania. W ten sposób model będzie faworyzować funkcje specyficzne dla jednego lub kilku zapytań, a nie te, które uogólniają dla wszystkich zapytań. Takie podejście zapobiega wyciekom bardzo popularnych wyników do nietrafnych zapytań. Jest to przeciwieństwo bardziej konwencjonalnych porad polegających na większej regularyzacji kolumn cech z większą liczbą niepowtarzalnych wartości.
  2. Zezwalaj tylko na dodatnie wagi funkcji. Każda dobra cecha będzie więc lepsza niż ta „nieznana”.
  3. nie udostępnia funkcji tylko do dokumentu; To jest ekstremalna wersja punktu 1. Na przykład nawet jeśli dana aplikacja jest często pobierana bez względu na treść zapytania, nie należy jej wszędzie wyświetlać. Posiadanie funkcji tylko do dokumentu jest takie proste. Nie chcesz w każdym miejscu wyświetlać konkretnej, popularnej aplikacji. Wynika to z tego, jak ważne jest, aby wszystkie aplikacje, których potrzebujesz, były osiągalne. Jeśli np. ktoś wpisze hasło „aplikacja do obserwacji ptaków”, może pobrać „zdenerwowane ptaki”, ale nie było to ich zamiarem. Pokazywanie takiej aplikacji może zwiększyć liczbę pobrań, ale nie zaspokoić potrzeb użytkownika.

Zasada nr 36. Unikaj zapętleń dzięki funkcjom pozycjonującym.

Pozycja treści w znacznym stopniu wpływa na prawdopodobieństwo interakcji użytkownika z nią. Jeśli umieścisz aplikację na pierwszej pozycji, będzie ona częściej klikana, a tym samym zwiększy się prawdopodobieństwo jej kliknięcia. Można to osiągnąć między innymi przez dodanie funkcji pozycjonowania, czyli właściwości związanych z pozycją treści na stronie. Trenujesz model z wykorzystaniem funkcji pozycjonowania i uczy się on na przykład znaczne zwiększanie wagi cechy „pierwsza pozycja”. Dzięki temu model przypisuje mniejszą wagę innym czynnikom w przykładach z wartością „1stposition=true”. Następnie podczas wyświetlania nie przypisujesz żadnej instancji funkcji pozycjonowania lub udostępniasz im tę samą funkcję domyślną, ponieważ oceniasz kandydatów, zanim ustalono kolejność ich wyświetlania.

Zwróć uwagę, że z powodu asymetrii między trenowaniem a testowaniem wszystkie cechy pozycjonujące muszą być nieco oddzielone od reszty modelu. Idealnie byłoby, gdyby model stanowił sumę funkcji cech pozycjonujących i funkcji pozostałych cech. Na przykład nie krzyżuj cech pozycjonowania z żadnymi obiektami dokumentu.

Zasada 37. Mierzenie zniekształceń w zakresie trenowania/serwowania.

Jest kilka czynników, które mogą powodować zniekształcenia w najbardziej ogólnym sensie. Ponadto możesz podzielić go na kilka części:

  • Różnica między wydajnością danych treningowych a danymi o utrzymaniu. Ogólnie rzecz biorąc, taka sytuacja zawsze będzie obowiązywać i nie zawsze jest zła.
  • Różnica między skutecznością danych o wstrzymaniu a danymi z danego dnia. Pamiętaj, że ten element będzie zawsze istniał. Musisz dostosować regularyzację, aby zmaksymalizować skuteczność następnego dnia. Jednak znaczny spadek wydajności między danymi z okresu wstrzymania a danych następnego dnia może oznaczać, że niektóre funkcje są wrażliwe na czas i mogą pogarszać wydajność modelu.
  • Różnica między wynikami w danych „następnego dnia” a danymi aktywnymi. Jeśli zastosujesz model do przykładu w danych treningowych i ten sam przykład podczas wyświetlania, powinien on dać dokładnie taki sam wynik (patrz reguła 5). Rozbieżności w tym miejscu oznaczają prawdopodobnie błąd inżynierski.

Faza III ML: spowolniony rozwój, dopracowanie optymalizacji i złożone modele

Istnieją pewne oznaki, że druga faza jest bliska zamknięcia. Przede wszystkim Twoje miesięczne zyski zaczną się zmniejszać. Pojawią się różnice między wskaźnikami: w niektórych eksperymentach zauważysz wzrost, a inne spadną. Ta kwestia staje się ciekawa. Trudniej jest osiągnąć korzyści, więc systemy uczące się muszą być bardziej zaawansowane. Uwaga: ta sekcja ma więcej zasad dotyczących błękitnego nieba niż wcześniejsze sekcje. Wiele zespołów przechodzi fazę I i II fazy systemów uczących się. Po przejściu fazy III zespoły muszą znaleźć własną drogę do celu.

Zasada nr 38: nie trać czasu na nowe funkcje, jeśli pojawiły się niedopasowane cele.

W miarę osiągania kolejnych poziomów Twój zespół zacznie przyglądać się problemom, które wykraczają poza zakres celów obecnego systemu systemów uczących się. Jak już wspomnieliśmy, jeśli obecny cel algorytmiczny nie uwzględnia celów produktowych, musisz zmienić swój cel lub cele produktowe. Możesz na przykład zoptymalizować kliknięcia, kliknięcia plus jedynki lub pobrania, ale decyzje dotyczące wprowadzenia produktów będą częściowo podejmowane przez weryfikatorów.

Zasada nr 39. Decyzje dotyczące wprowadzenia produktu na rynek są wyznacznikiem długoterminowych celów produktowych.

Alicja chce ograniczyć logistyczną stratę wynikającą z przewidywania instalacji. Dodaje funkcję. Strata logistyczna spada. Po przeprowadzeniu eksperymentu na żywo zauważyła wzrost liczby instalacji. Jednak gdy organizuje spotkanie, na którym ma ocenić wprowadzenie aplikacji, ktoś zauważa, że liczba aktywnych użytkowników dziennie spada o 5%. Zespół postanawia nie uruchamiać modelu. Alicja jest rozczarowana, ale zdaje sobie sprawę, że decyzja o wprowadzeniu kampanii na rynek zależy od wielu kryteriów, z których tylko niektóre można bezpośrednio zoptymalizować za pomocą systemów uczących się.

Prawda jest taka, że w rzeczywistości nie są to lochy ani smoki. Nie ma żadnych „punktów trafień”, które określałyby stan Twojego produktu. Zespół musi wykorzystać zebrane statystyki, aby skutecznie przewidzieć skuteczność systemu w przyszłości. Muszą brać pod uwagę zaangażowanie, liczbę aktywnych użytkowników dziennie, 30 dziennych aktywnych użytkowników, przychody oraz zwrot z inwestycji reklamodawcy. Wskaźniki, które mierzą się same w testach A/B, to jedynie pośrednik długoterminowych celów: satysfakcji użytkowników, zwiększenia liczby użytkowników, satysfakcji partnerów i zysków. Nawet wtedy, po upływie pięciu lat, rozwój firmy i produkt o wysokiej jakości mogą być podstawą.

Podejmowanie decyzji o wprowadzeniu aplikacji jest proste, gdy wszystkie dane poprawiają się (lub przynajmniej nie pogorszą). Jeśli zespół ma możliwość wyboru między zaawansowanym algorytmem systemów uczących się a prostą metodą heurystyczną, to jeśli prosta heurystyka radzi sobie lepiej z każdym z tych wskaźników, powinien wybrać heurystyczną. Nie ma też żadnego wyraźnego rankingu wszystkich możliwych wartości danych. W szczególności rozważ te 2 scenariusze:

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

Jeśli obecny system to A, zespół najprawdopodobniej nie przełączy się na system B. W przypadku systemu B zespół najprawdopodobniej nie przełączy się na system A. Wydaje się to sprzeczne z racjonalnym zachowaniem. Przewidywania zmian danych mogą się jednak nie pokrywać, dlatego każda ze zmian wiąże się z dużym ryzykiem. Każdy wskaźnik obejmuje pewne ryzyko, którego dotyczy zespół.

Co więcej, żadne dane nie odpowiadają jego najistotniejszym obawom: „gdzie będzie mój produkt za pięć lat?”

Użytkownicy indywidualni natomiast preferują jeden cel, który można bezpośrednio zoptymalizować. Większość narzędzi do systemów uczących się preferuje takie środowisko. Inżynierowie testujący nowe funkcje mogą mieć stały strumień wprowadzania w takim środowisku. Istnieją systemy uczące się, wielocelowe, które pomagają rozwiązać ten problem. Można na przykład sformułować problem związany z ograniczeniem, który ma dolne granice każdego rodzaju danych, i optymalizację pewnej liniowej kombinacji danych. Jednak nawet wtedy nie wszystkie dane można łatwo przedstawić jako cele systemów uczących się. Gdy użytkownik kliknie dokument lub zainstaluje aplikację, dzieje się tak dlatego, że treść została pokazana. O wiele trudniej jest ustalić, dlaczego użytkownik odwiedza Twoją witrynę. Przewidywanie przyszłych wyników witryny jako całości jest zależne od metody AI-complete, tak trudnej jak rozpoznawanie mowy przez komputer czy przetwarzanie języka naturalnego.

Zasada nr 40: Układaj prostotę.

Ujednolicone modele, które przyjmują nieprzetworzone funkcje i bezpośrednio ustalają pozycję treści, to najłatwiejsze do debugowania i zrozumienia. Jednak zestaw modeli (czyli „model”, który łączy wyniki innych modeli), może działać lepiej. Dla uproszczenia każdy model powinien być zbiorem obejmującym tylko dane wejściowe z innych modeli lub model podstawowy oferujący wiele cech, ale nie oba jednocześnie. Jeśli takie modele są trenowane oddzielnie, połączenie ich może spowodować niewłaściwe działanie.

Użyj prostego modelu do grupowania, który jako dane wejściowe przyjmuje tylko dane wyjściowe z modeli „podstawowych”. Chcesz też egzekwować właściwości w tych modelach zbiorczych. Na przykład wzrost wyniku uzyskanego przez model podstawowy nie powinien obniżyć wyniku grupy. Najlepiej też, jeśli przychodzące modele są interpretowane semantycznie (np. kalibrowane), dzięki czemu zmiany w modelach bazowych nie wprowadzają w błąd modelu zbiorowego. Wymuszaj też, aby wzrost prawdopodobieństwa prognozowanego klasyfikatora nie zmniejszał przewidywanego prawdopodobieństwa grupy.

Zasada nr 41. W okresie spadków skuteczności poszukaj nowych jakościowo nowych źródeł informacji, które możesz dodać, zamiast ulepszać istniejące sygnały.

Dodano dane demograficzne dotyczące użytkownika. Dodajesz informacje o słowach w dokumencie. Udało Ci się już przeanalizować eksplorację szablonów i dostosować regularyzację. W ciągu kilku kwartałów nie pojawiły się nowe aplikacje, które poprawiałyby kluczowe dane o ponad 1%. Co dalej?

Czas zacząć tworzyć infrastrukturę pod kątem radykalnie różnych funkcji, na przykład historii dokumentów, z których ten użytkownik korzystał w ostatnim dniu, tygodniu lub roku czy danych z innej usługi. Używaj danych wikidata lub informacji wewnętrznych w Twojej firmie (np. grafu wiedzy Google). Użyj deep learning. Zacznij dostosowywać swoje oczekiwania co do zwrotu z inwestycji i podejmuj odpowiednie działania. Tak jak w przypadku każdego projektu inżynieryjnego, trzeba wziąć pod uwagę korzyści płynące z dodania nowych funkcji w stosunku do kosztów związanych z większą złożonością.

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

Różnorodność treści może oznaczać wiele rzeczy, a różnorodność źródeł materiałów jest jednym z najczęściej używanych. Dzięki personalizacji każdy użytkownik widzi własne wyniki. Trafność oznacza, że wyniki konkretnego zapytania są dla niego bardziej odpowiednie niż jakiekolwiek inne. Wszystkie 3 właściwości są więc zdefiniowane jako inne niż zwykłe.

Problem polega na tym, że zwyczaje są trudne do pokonania.

Pamiętaj, że jeśli Twój system mierzy kliknięcia, czas, oglądanie, +1-ki, udostępnienia itp., mierzysz popularność treści. Zespoły czasem próbują nauczyć się modelu osobistego opartego na różnorodności. W celu personalizacji dodają funkcje, które umożliwiają systemowi personalizację (niektóre funkcje reprezentujące zainteresowania użytkownika) lub urozmaicenie (funkcje wskazujące, czy dokument ma właściwości wspólne ze zwracanymi dokumentami, np. z autorem lub treścią), i odkrywa, że te funkcje mają mniejszą wagę (lub czasami inny znak) niż się spodziewają.

Nie oznacza to jednak, że różnorodność, personalizacja czy trafność są bezwartościowe. Jak wspomniano w poprzedniej regule, możesz przetwarzać dane po ich przetworzeniu, aby zwiększyć różnorodność lub trafność. Jeśli zauważysz wzrost celów długoterminowych, możesz zadeklarować, że poza popularnością liczy się różnorodność/trafność. Następnie możesz kontynuować obróbkę lub bezpośrednio zmodyfikować cel odpowiednio do różnorodności lub trafności.

Zasada nr 43: Twoi znajomi są zazwyczaj tacy sami w różnych produktach. W ogóle to nie jest Twoje zainteresowania.

Zespoły w Google bardzo często korzystają z modelu przewidzianego na stopień dopasowania relacji między usługami w Google. Twoi przyjaciele są kim są. Z drugiej strony wiem, że kilka zespołów ma problemy z funkcjami personalizacji w różnych usługach. Tak, wydaje się, że to powinno zadziałać. W tej chwili wydaje się, że tak nie jest. Czasami się sprawdza, wykorzystując nieprzetworzone dane z jednej usługi do przewidywania zachowań w innej. Pamiętaj też, że nawet świadomość, że dany użytkownik ma historię w innej usłudze, może pomóc. Na przykład aktywność użytkownika w 2 usługach może wskazywać samoczynnie.

W Google i na zewnątrz jest wiele dokumentów dotyczących systemów uczących się.

Podziękowania

Pomogli nam Du-Westbrook, Peter Brandt, Samuel Ieong, Chenyu Zhao, Li Wei, Michalis Potamias, Evan Rosen, Barry Rosenberg, Christine Robson, James Pine, Tal Shaked, Tushar Chandra, Mustafa Ispir, Jeremiah Harmsen, Konstantinos Galerapis Dziękuję też Kristen Lefevre, Suddhy Basu i Chrisowi Berg, którzy pomogli nam przy wcześniejszej wersji. Wszystkie błędy, pominięcia i niepopularne opinie są moją twórczością.

Dodatek

W tym dokumencie występuje wiele odniesień do usług Google. Aby zapewnić szerszy kontekst, poniżej zamieszczamy krótki opis najczęstszych przykładów.

YouTube – omówienie

YouTube to usługa strumieniowania filmów. Zarówno zespół YouTube Warte obejrzenia, jak i strona główna YouTube używają modeli systemów uczących się do ustalania pozycji rekomendacji filmów. Warte obejrzenia poleca filmy do obejrzenia po aktualnie odtwarzanym filmie, a na stronie głównej – użytkownikom przeglądającym stronę główną.

Omówienie Google Play

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

Omówienie Google+

Usługa Google Plus wykorzystywała systemy uczące się w różnych sytuacjach: ocenianie postów w strumieniu postów wyświetlanych przez użytkownika, ocenianie postów „Na topie” (postów, które są obecnie bardzo popularne), ustalanie pozycji znajomych w rankingu itd. W 2019 roku zamknęliśmy wszystkie konta osobiste w Google+, a 6 lipca 2020 r. zastąpiliśmy je usługami Google Currents w przypadku kont firmowych.