Zasady dotyczące systemów uczących się:

Sprawdzone metody inżynierii ML

Martin Zinkevich

Ten dokument ma na celu pomóc osobom, które mają podstawową wiedzę o systemach uczących się, w połączeniu ze sprawdzonymi metodami Google dotyczącymi systemów uczących się. Jest to styl opracowany przy użyciu systemów uczących się, podobnie jak Przewodnik po stylach Google C++ i inne popularne praktyczne programy. Jeśli uczestniczysz w zajęciach w dziedzinie systemów uczących się albo tworzysz lub pracujesz nad modelem uczącym się, masz odpowiednie doświadczenie w czytaniu tego dokumentu.

Martin Zinkevich wprowadza 10 swoich ulubionych reguł systemów uczących się. Czytaj dalej, aby poznać wszystkie 43 reguły.

Terminologia

Podczas dyskusji na temat efektywnego uczenia się maszynowego będziemy wielokrotnie powtarzać następujące terminy:

  • Wystąpienie: prognoza, którą chcesz przewidzieć. Może to być na przykład strona internetowa, którą chcesz sklasyfikować jako „Informacje o kotach” lub „Nie o kotach”.
  • Etykieta: odpowiedź na zadanie prognozowania to odpowiedź udzielona przez system uczący się lub poprawna odpowiedź w danych treningowych. Na przykład etykieta dla strony internetowej może brzmieć „Informacje o kotach”.
  • Funkcja: właściwość instancji używanej w zadaniu prognozowania. Na przykład strona może zawierać 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ć jedną lub więcej funkcji w kolumnie cech. „Kolumna funkcji” to terminologia Google. W systemie VW (w Yahoo/Microsoft) kolumna ta jest określana jako „przestrzeń nazw” lub pole.
  • Przykład: wystąpienie (z funkcjami) i etykieta.
  • Model: reprezentacja statystyczna zadania prognozowania. Trenujesz model na przykładach, a potem używasz go do prognozowania.
  • Dane: liczba, która Cię interesuje. Optymalizacja może nie być możliwa bezpośrednio.
  • Cel: dane, które algorytm próbuje zoptymalizować.
  • Potok: infrastruktura otaczająca algorytm systemów uczących się. Obejmuje to zbieranie danych z interfejsu, umieszczanie ich w plikach danych treningowych, trenowanie jednego lub kilku modeli oraz wyeksportowanie ich do środowiska produkcyjnego.
  • Współczynnik klikalności to odsetek użytkowników strony internetowej, którzy kliknęli link w reklamie.

Omówienie

Aby tworzyć świetne produkty:

czy uczą się oni jak wielcy inżynierzy, a nie jak wielcy eksperci systemów uczących się.

W większości przypadków są to problemy techniczne, Mimo że wszystkie zasoby doświadczonego eksperta od systemów uczących się są w większym stopniu, większość korzyści wiąże się ze świetnymi funkcjami, a nie specjalnymi algorytmami systemów uczących się. Podstawowe podejście:

  1. Upewnij się, że potok jest niezawodny.
  2. Zacznij od rozsądnego celu.
  3. Dodaj proste funkcje w prosty sposób.
  4. Upewnij się, że potok jest sprawny.

To podejście sprawdza się przez dłuższy czas. Odejdź od tego podejścia tylko wtedy, gdy nie ma więcej prostych sztuczek, które pozwolą Ci dojść dalej. Dodanie złożoności spowalnia przyszłe wersje.

Gdy wyczerpiesz już te proste sztuczki, najnowocześniejsze systemy uczące się mogą okazać się w przyszłości. Patrz sekcja dotycząca projektów systemów uczących się w fazie III.

Dokument jest zorganizowany w następujący sposób:

  1. Pierwsza część powinna pomóc Ci zrozumieć, czy nadszedł czas na stworzenie systemu uczącego się.
  2. Druga część dotyczy wdrożenia pierwszego potoku.
  3. W trzeciej części dowiesz się, jak uruchomić i iterować podczas dodawania nowych funkcji do potoku oraz jak oceniać modele i zniekształcenie między trenowaniem a zastosowaniem praktycznym.
  4. Ostatnią częścią jest tu, co zrobić, gdy dotrzesz do płaskowyżu.
  5. Następnie przedstawiamy listę powiązanych zadań i załącznik z ogólnymi informacjami o systemach używanych często w tym dokumencie.

Przed systemami uczącymi się

Reguła 1. Nie bój się uruchomić produktu bez systemów uczących się.

Systemy uczące się są fajne, ale wymagają danych. Teoretycznie możesz wziąć pod uwagę dane z innego problemu i dostosować model dla nowego produktu, ale prawdopodobnie nie będzie to zbyt podstawowe wyniki w przypadku metody heurystycznej. Jeśli uważasz, że systemy uczące się zapewnią Ci 100% wzrostu, heurystyka zapewni Ci 50% drogi do celu.

Jeśli np. ustalasz pozycję aplikacji w rankingu w sklepie z aplikacjami, jako danych heurystycznych możesz użyć liczby instalacji lub liczby instalacji. Jeśli wykrywasz spam, odfiltruj wydawców, którzy wcześniej wysyłali spam. Nie bój się też edycji manualnej. Jeśli chcesz określić pozycję kontaktów, uszereguj te, które są najczęściej używane (a nawet alfabetyczne). Jeśli systemy uczące się nie są absolutnie wymagane, nie używaj ich, dopóki nie uzyskasz danych.

Reguła 2. Projektowanie i wdrażanie danych.

Zanim sfinalizujesz działanie systemu uczącego się, śledź jak najwięcej elementów w swoim systemie. Wykonaj te czynności:

  1. Wcześniej można uzyskać zgodę użytkowników systemu.
  2. Jeśli myślisz, że w przyszłości możesz mieć jakieś obawy, lepiej skorzystać z danych historycznych.
  3. Jeśli zaprojektujesz system z uwzględnieniem instrumentacji danych, w przyszłości wszystko pójdzie lepiej. Szczególnie zależy Ci na tym, aby nie czekać na ciągi znaków w dziennikach w celu instrumentowania wskaźników.
  4. Zauważysz, co się zmieniło, a co pozostaje bez zmian. Załóżmy na przykład, że chcesz bezpośrednio zoptymalizować liczbę użytkowników aktywnych w ciągu 1 dnia. Podczas wczesnej manipulacji systemu możesz jednak zauważyć, że radykalne zmiany w komforcie użytkowania nie zmieniają tych danych w znaczący sposób.

Zespół Google Plus mierzy wskaźniki liczby odczytów, udostępnień na odczyt, dodatkowych 1 odczytu, komentarzy/odczytu, komentarzy na użytkownika, udostępnień na użytkownika itd., na podstawie których określono ich jakość. Pamiętaj też, że ważne jest środowisko eksperymentalne, w którym można grupować użytkowników w grupy i agregować statystyki według eksperymentu. (zobacz regułę 12).

Dzięki większej swobody w zbieraniu danych możesz uzyskać pełniejszy obraz systemu. Problem? Dodaj dane, które chcesz śledzić. Podchodzisz do sprawy częściowo z nowością? Dodaj dane, które chcesz śledzić.

Reguła 3. Wybierz systemy uczące się zamiast złożonej heurystyki.

Prosty heurystyka może pomóc Ci uzyskać zamierzony efekt produktu. Złożona heurystyka nie da się utrzymać. Gdy będziesz już mieć dane i podstawową wiedzę, o co Ci chodzi, przejdź do systemów uczących się. Podobnie jak w przypadku większości zadań z zakresu inżynierii oprogramowania, konieczne jest ciągłe aktualizowanie podejścia, zarówno w przypadku modeli heurystycznych, jak i systemów uczących się. Przekonasz się, że łatwiej jest go aktualizować i obsługiwać (patrz Reguła 16).

Faza ML: pierwszy potok

Skoncentruj się na infrastrukturze systemowej pierwszego potoku. Chociaż wymyślanie wszystkich wymyślnych systemów uczących się jest ciekawe, trudno jest przewidzieć, co się wydarzy, jeśli najpierw nie będziesz mieć zaufania do potoku.

Reguła 4. Pierwszy model powinien być prosty, a infrastruktura – odpowiednia.

Pierwszy z nich daje największe korzyści dla Twojego produktu, dlatego nie musi on być wyrafinowany. Będzie to jednak dużo więcej problemów, niż się spodziewasz. Zanim ktokolwiek będzie mógł korzystać z wymyślnego nowego systemu uczącego się, musisz określić:

  • Uzyskiwanie przykładowych algorytmów nauczania.
  • Najpierw określ, co „dobre” i „złe” oznacza dla Twojego systemu.
  • Integracja modelu z aplikacją. Możesz zastosować model na żywo lub obliczyć go na przykładach offline i zapisać wyniki w tabeli. Możesz na przykład wstępnie sklasyfikować strony internetowe i przechowywać wyniki w tabeli, ale sklasyfikować wiadomości czatu na żywo.

Wybierając proste funkcje, możesz mieć pewność, że:

  • Funkcje prawidłowo docierają do algorytmu nauki.
  • Model uczy się rozsądnych wag.
  • Funkcje prawidłowo docierają do modelu z serwera.

Jeśli dysponujesz systemem, który w niezawodny sposób wykonuje te 3 czynności, większość pracy jest w pełni wykonana. Prosty model udostępnia dane podstawowe i podstawowe dane, których możesz użyć do testowania bardziej złożonych modeli. Niektóre zespoły dążą do „neutralnego” wprowadzenia na rynek: pierwsze, które w wyraźny sposób zmniejsza priorytety systemów uczących się, aby nie rozpraszać uwagi.

Reguła 5. Testowanie infrastruktury niezależnie od systemów uczących się.

Zadbaj o to, aby infrastrukturę można było testować, i upewnij się, że elementy szkoleniowe w systemie są zamknięte, aby można było przetestować wszystko wokół. Oto najważniejsze kwestie:

  1. Testowanie pobierania danych do algorytmu. Sprawdź, czy kolumny cech, które powinny zostać wypełnione, powinny być wypełnione. Tam, gdzie pozwala na ochronę prywatności, sprawdzaj dane wejściowe algorytmu algorytmu. Jeśli to możliwe, sprawdź statystyki w potoku w porównaniu ze statystykami dotyczącymi 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 Twoim środowisku obsługi (zobacz regułę 37).

Systemy uczące się mają element nieprzewidywalny, więc musisz przeprowadzać testy kodu umożliwiającego tworzenie przykładów w trenowania i serwowaniu danych oraz możliwość wczytywania i używania stałego modelu podczas udostępniania. Ważne jest również, aby zrozumieć swoje dane: zobacz Praktyczne porady dotyczące analizowania dużych, złożonych zbiorów danych.

Reguła 6. Podczas kopiowania potoków zachowaj ostrożność.

Często tworzymy potok, kopiując istniejący potok (tj. programowanie kultowych ładunków), a stary proces usuwa dane, które są potrzebne w przypadku nowego potoku. Na przykład potok Na topie w Google+ usuwa starsze posty (ponieważ próbuje określić pozycję nowych postów). Ten potok został skopiowany do strumienia Google Plus, gdzie starsze posty są nadal istotne, ale potok nadal usuwał stare. Innym popularnym schematem jest rejestrowanie tylko tych danych, które użytkownik widział. Te dane są bezużyteczne, jeśli chcemy sprawdzić, dlaczego użytkownik nie widzi danego posta, ponieważ wszystkie wykluczające przykłady zostały usunięte. Podobny problem wystąpił w Google Play. Podczas pracy na stronie głównej aplikacji Google Play stworzyliśmy nowy potok, który zawierał też przykłady ze strony docelowej Gier Play bez żadnej funkcji pozwalającej zidentyfikować, skąd pochodzą poszczególne przykłady.

Reguła 7. Zamień heurystykę w funkcje lub przetwarzaj je na zewnątrz.

Zwykle problemy, które systemy uczące się próbują rozwiązać, nie są zupełnie nowe. Istnieje już system rankingowy, sklasyfikowania lub innego problemu, który próbujesz rozwiązać. To oznacza, że istnieje kilka reguł i metod heurystycznych. Te same dane heurystyczne mogą pomóc Ci uzyskać wzrost, jeśli ulepszysz je za pomocą systemów uczących się. Z 2 powodów należy wyodrębnić informacje heurystyczne pod kątem wszelkich informacji. Po pierwsze: przejście na system uczący się będzie płynniejsze. Po drugie, reguły te zazwyczaj zawierają dużo intuicji na temat systemu, którego nie chcesz rzucać. Istnieją 4 sposoby na wykorzystanie istniejącej heurystyki:

  • Przetwarzanie wstępne z użyciem heurystyki. Jeśli ta funkcja jest niezwykle świetna, masz taką możliwość. Jeśli na przykład w filtrze spamu nadawca jest już na czarnej liście, nie próbuj na nowo zrozumieć, co to jest „czarna lista”. Zablokuj wiadomość. To podejście sprawdza się najlepiej w przypadku zadań związanych z klasyfikacją binarną.
  • Utwórz funkcję. Bezpośrednie tworzenie cech z heurystyki jest bardzo przydatne. Jeśli na przykład używasz algorytmu heurystycznego do obliczania wyniku trafności wyniku zapytania, możesz uwzględnić wynik jako wartość cechy. Później możesz użyć technik stosowanych w systemach uczących się do masowania wartości (np. przekonwertowania wartości w jeden skończony zestaw wartości odrębnych lub łączenia jej z innymi funkcjami), ale najpierw użyć nieprzetworzonej wartości wygenerowanej przez heurystykę.
  • Kopanie nieprzetworzonych danych heurystycznych. Jeśli dane heurystyczne dla aplikacji, które łączą liczbę instalacji, liczbę znaków w tekście i dzień tygodnia, rozważ wyodrębnienie tych fragmentów i wprowadzenie tych danych do samodzielnej nauki. W tym miejscu mają zastosowanie pewne techniki dotyczące zbiorów (zobacz regułę nr 40).
  • Zmodyfikuj etykietę. Ta opcja jest dostępna, gdy uważasz, że dane heurystyczne nie są obecnie uwzględnione w etykietie. Jeśli np. próbujesz zmaksymalizować liczbę pobrań, ale zależy Ci też na jakości treści, dobrym rozwiązaniem może być pomnożenie etykiety przez średnią liczbę gwiazdek otrzymanych przez aplikację. Możesz się z niej dowiedzieć wiele. Zobacz „Twój pierwszy cel”.

Pamiętaj o dodatkowej złożoności korzystania z heurystyki w systemie ML. Skorzystanie ze starego heurystyki w nowym algorytmie systemów uczących się może pomóc w płynnym przejściu na nowe środowisko, ale zastanów się, czy nie prostszy sposób na uzyskanie takiego samego efektu.

Monitorowanie

Ogólnie rzecz biorąc, należy zadbać o dobrą higienę alertów, np. utworzyć przydatne alerty i stronę w panelu.

Reguła 8. Sprawdzaj wymagania dotyczące częstotliwości aktualizacji systemu.

Jak bardzo wydajność spada, jeśli masz model dzienny? Masz tydzień? Kwartał? Te informacje pomogą Ci zrozumieć priorytety monitorowania. Jeśli przez dłuższy czas nie będziesz mieć wystarczającej jakości produktów, może to być inżynier, który będzie je stale monitorować. Większość systemów wyświetlania reklam obsługuje nowe reklamy każdego dnia i musi być aktualizowana codziennie. Jeśli na przykład model systemów uczących się w przypadku wyszukiwarki Google Play nie zostanie zaktualizowany, może to mieć negatywny wpływ w ciągu miesiąca. Niektóre modele „Na topie” w Google Plus nie mają identyfikatora publikowania, więc mogą one rzadko eksportować te modele. Inne modele zawierające identyfikatory postów są aktualizowane znacznie częściej. Zwróć też uwagę, że częstotliwość aktualizacji może się zmieniać z czasem, zwłaszcza gdy kolumny modelu są dodawane do modelu lub z niego usuwane.

Reguła 9. Wykrywaj problemy przed wyeksportowaniem modeli.

Wiele systemów uczących się ma etap, na którym możesz wyeksportować model do obsługi. Jeśli wystąpi problem z wyeksportowanym modelem, jest on związany z użytkownikiem.

Wyeksportuj, zanim wyeksportujesz model. W szczególności upewnij się, że wydajność modelu jest rozsądna w zakresie przechowywania danych. Jeśli masz wątpliwości związane z danymi, nie eksportuj modelu. Wiele zespołów stale wdrażających modele sprawdza obszar pod krzywą Rook (lub AUC) przed wyeksportowaniem. Problemy z modelami, które nie zostały wyeksportowane, wymagają alertów e-mail, ale problemy z modelem dla użytkowników mogą wymagać strony. Dlatego lepiej poczekać i upewnić się, że zmiana nie będzie miała wpływu na użytkowników.

Reguła 10. Uważaj na awarie.

Ten problem częściej występuje w przypadku systemów uczących się niż w innych typach systemów. Załóżmy, że określona tabela, którą dołączasz, nie jest już aktualizowana. System systemów uczących się będzie się dostosowywać, a zachowanie będzie działać prawidłowo i stopniowo się zmniejsza. Czasem możesz znaleźć tabele, które są nieaktualne w ciągu kilku miesięcy, a proste odświeżenie poprawia skuteczność w porównaniu do innych premier w tym kwartale. Zasięg funkcji może się zmienić ze względu na zmiany w implementacji: na przykład kolumna cech może zostać uzupełniona w 90% przykładów i nagle spadnie do 60% przykładów. W Google Play tabela była od 6 miesięcy nieaktualna, a odświeżenie tabeli spowodowało wzrost liczby instalacji o 2%. Tego typu awarie możesz śledzić, jeśli śledzisz statystyki danych i sporadycznie ręcznie je sprawdzasz.

Reguła 11. Udostępnij właścicielom kolumn dokumentację i dokumentację.

Jeśli system jest duży i zawiera wiele kolumn cech, sprawdź, kto utworzył lub obsługuje każdą kolumnę cech. Jeśli zauważysz, że osoba, która rozumie kolumnę funkcji, rezygnuje, sprawdź, czy ktoś ma potrzebne informacje. Chociaż wiele kolumn z nazwami cech ma opisowe nazwy, dobrze jest mieć bardziej szczegółowy opis cech, źródła pochodzenia danych i tego, jak należy je wykorzystać.

Twój pierwszy cel

Masz wiele wskaźników lub pomiarów systemu, na których Ci zależy, ale algorytm systemów uczących się często będzie wymagać jednego celu, czyli liczby, którą algorytm próbuje „zoptymalizować”. Rozróżniam tu cele i dane – dane to dowolna liczba zgłoszona przez system, która może być ważna. Zapoznaj się też z regułą nr 2.

Reguła 12. Nie zapominaj o celach, które chcesz zoptymalizować bezpośrednio.

Chcesz zarabiać pieniądze, dbać o zadowolenie użytkowników i zmieniać świat na lepsze. Istnieje wiele wskaźników, które są dla Ciebie istotne, i mierz je wszystkie (patrz Reguła 2). Jednak na wczesnym etapie procesu systemów uczących się zauważysz, że wszystko rośnie, nawet jeśli nie przeprowadzasz optymalizacji bezpośrednio. Załóżmy, że interesują Cię liczba kliknięć i czas spędzony w witrynie. Jeśli korzystasz z optymalizacji pod kątem liczby kliknięć, prawdopodobnie spędzą Ci więcej czasu.

Trzymaj się prostych rozwiązań, nie zapominając o zrównoważeniu różnych rodzajów danych, gdy można łatwo zwiększyć ich liczbę. Nie stosuj jednak tej reguły zbyt często: nie myl celu z ostatecznym stanem systemu (patrz Reguła nr 39). Jeśli okaże się, że zwiększasz ilość danych bezpośrednio zoptymalizowanych, ale nie chcesz wprowadzać na rynek, konieczne może być wprowadzenie kilku obiektywnych zmian.

Reguła 13. Wybierz prosty, możliwy do obserwowania i przypisany wskaźnik do pierwszego celu.

Często nie wiemy, co jest prawdziwe, a jednocześnie analizujemy dane i analizę porównawczą starych i nowych systemów ML. Poza tym różni członkowie zespołu często nie mogą rozumieć prawdziwego celu. Cel ML powinien być łatwy do zmierzenia i pełni funkcję serwera proxy do celu „true”. Właściwie często nie ma „prawdziwego” celu (patrz Reguła 39). Naucz się więc prostego celu dotyczącego systemów uczących się i rozważ umieszczenie u góry „warstwy zasad”, która pozwoli dodać dodatkową logikę (prawdopodobnie bardzo logiczną) do ostatecznego rankingu.

Najłatwiej jest modelować zachowania użytkowników, które są bezpośrednio obserwowane i przypisane do działania systemu:

  • Czy ten link do rankingu został kliknięty?
  • Czy ten obiekt z rankingu został pobrany?
  • Czy ten obiekt rankingowy został przekazany dalej, a na niego wysłana odpowiedź lub e-mail?
  • Czy ten obiekt w rankingu został oceniony?
  • Czy ten obiekt został oznaczony jako spam, treści pornograficzne lub obraźliwe?

Najpierw nie modelowaniaj efektów pośrednich:

  • Czy użytkownik odwiedził następnego dnia?
  • Jak długo użytkownik odwiedza witrynę?
  • Jaka była liczba aktywnych użytkowników dziennie?

Efekty pośrednie tworzą świetne dane. Można ich używać podczas testów A/B oraz w czasie podejmowania decyzji o ich uruchomieniu.

Nie próbuj też nauczyć się, żeby:

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

Wszystkie są bardzo ważne, ale niezwykle trudne do zmierzenia. Zamiast tego używaj serwerów proxy: jeśli użytkownik jest zadowolony, zostanie na stronie dłużej. Jeśli użytkownik jest zadowolony, odwiedzi ją jutro. Aby zadbać o dobre samopoczucie i zdrowie firmy, należy zdać sobie sprawę, że każdy algorytm jest zgodny z charakterem sprzedawanych produktów i planem biznesowym.

Reguła 14. Korzystanie z zrozumiałego modelu ułatwia debugowanie.

Regresja liniowa, regresja logistyczna i regresja Poissona są bezpośrednio motywowane modelem prawdopodobnym. Każda prognoza może być interpretowana jako prawdopodobieństwo lub wartość oczekiwana. Ułatwia to debugowanie w porównaniu z modelami, które korzystają z celów (zerowa utrata jednego miejsca, różne straty zawiasów itd.), które mają na celu bezpośrednie optymalizowanie dokładności klasyfikacji lub wydajności rankingu. Na przykład, jeśli prawdopodobieństwo trenowania różni się od prawdopodobieństwa wystąpienia zmian prognozowanych równolegle lub przez sprawdzenie systemu produkcyjnego, może to oznaczać problem.

Na przykład w regresji linearnej, logistycznej lub Poissona występują podzbiory danych, w których średnia oczekiwana wartość równa się średniej wartości etykiety (kalibracja 1 momentu lub tylko kalibrowana). Dzieje się tak przy założeniu, że nie masz żadnej regularnej operacji i że Twój algorytm się połączył, oraz że jest to przybliżone zjawisko. Jeśli masz cechę, która dla każdego przykładu ma wartość 1 lub 0, zostanie ona skalibrowana w 3 przykładach. Jeśli cecha wynosi 1 dla każdego przykładu, zestaw wszystkich przykładów jest skalibrowany.

W prostych modelach łatwiej jest zapętlić informacje zwrotne (patrz reguła 36). Często przy podejmowaniu takiej decyzji używamy przewidywalnych prognoz, np. postów w rankingu obniżonych, spodziewanych (np. prawdopodobieństwa kliknięcia/pobrania itp.). Pamiętaj jednak, że w odpowiednim momencie musisz wybrać model, który ma kluczowe znaczenie. Decyzja ma jednak większe znaczenie niż prawdopodobieństwo, że dane będą dostępne w modelu (patrz Reguła 27).

Reguła 15. Oddzielanie filtrowania spamu i rankingu jakości w warstwie zasad

Ranking jakości to świetna sztuka, ale filtrowanie spamu to nie lada wyczyn. Sygnały używane do określania wysokiej jakości postów będą oczywiste dla osób korzystających z Twojego systemu i będą modyfikować swoje posty, tak aby miały te właściwości. Dlatego ranking jakości powinien koncentrować się na rankingu treści publikowanych w dobrej wierze. Nie należy obniżać wysokiej jakości wyników wyszukiwania, jeśli chodzi o tworzenie spamu. Z kolei treści dla dorosłych należy traktować oddzielnie od rankingu Jakość. Filtrowanie spamu to zupełnie inna sprawa. Funkcje, które musisz wygenerować, stale się zmieniają. W systemie często obowiązują oczywiste reguły (jeśli post zawiera więcej niż 3 głosy o spamie, nie można go odzyskać itp.). Każdy nauczony model musi być aktualizowany codziennie, a jeśli nie, to szybciej. Dużą rolę odgrywa reputacja twórcy treści.

Na pewnym poziomie dane wyjściowe z tych dwóch systemów będą musiały zostać zintegrowane. Pamiętaj, że filtrowanie spamu w wynikach wyszukiwania powinno być bardziej agresywne niż filtrowanie spamu w e-mailach. Dzieje się tak przy założeniu, że nie masz normalizacji i Twój algorytm się nie połączył. Ogólnie jest to prawdziwe. Standardowo usuwamy spam z danych treningowych klasyfikatora jakości.

ML: faza II: inżynieria cech

Na pierwszym etapie cyklu życia systemów uczących się ważne problemy polegają na tym, aby dane treningowe zostały przeniesione do systemu, uzyskać wskaźniki dostosowane do danych i stworzyliśmy infrastrukturę obsługi. Gdy masz kompleksowy, kompleksowy system z testami jednostek i systemu, rozpoczyna się drugi etap.

Na drugim etapie należy zebrać dużo owoców. W systemie można udostępnić różne oczywiste funkcje. Dlatego drugi etap systemów uczących się polega na pobieraniu jak największej liczby funkcji i łączeniu ich w intuicyjny sposób. Na tym etapie wszystkie wskaźniki wzrasta. Planujemy wprowadzić wiele funkcji, a to doskonały moment, aby zatrudnić wielu inżynierów, którzy będą mogli połączyć wszystkie dane potrzebne do stworzenia naprawdę doskonałego systemu edukacyjnego.

Reguła 16. Planuj uruchomienie i powtarzanie programu.

Nie oczekuj, że model, nad którym obecnie pracujesz, będzie ostatnim, który zostanie wprowadzony, lub nawet że w ogóle przestaniesz uruchamiać modele. Dlatego zastanów się, czy złożoność, którą dodajesz za pomocą tej wersji, spowalnia przyszłe procesy. Wiele zespołów wprowadziło model na kwartał lub dłużej na lata. Istnieją 3 podstawowe powody wprowadzania nowych modeli:

  • Wymyślasz nowe funkcje.
  • Przeprowadzasz optymalizację i łączymy stare funkcje na nowe sposoby.
  • Dostrajasz cel.

Bez względu na to, co można powiedzieć o modelu, warto w nim pogratulować. Analizowanie danych przekazywanych w przykładzie może pomóc w znalezieniu nowych, a także starych, uszkodzonych sygnałów. Podczas tworzenia modelu zastanów się, jak łatwo można dodawać i usuwać oraz ponownie łączyć funkcje. Pomyśl o tym, jak łatwo jest utworzyć nową kopię potoku i sprawdzić jej poprawność. Zastanów się, czy można uruchomić równolegle 2 lub 3 kopie. Nie musisz się też martwić, czy funkcja 16 z 35 znajdzie się w tej wersji potoku. Otrzymasz go w następnym kwartale.

Reguła 17. Zacznij od funkcji bezpośrednio obserwowanych i raportowanych, a nie funkcji nauczonych.

Może to być kontrowersyjna kwestia, ale unika wielu pułapek. Przede wszystkim omówmy funkcję, której się nauczyliśmy. Opracowana funkcja to funkcja generowana przez system zewnętrzny (np.system grupowania nienadzorowanego) lub przez samych uczniów (np. z użyciem modelu zależnego lub deep learning). Oba te rozwiązania mogą być przydatne, ale mogą sprawiać dużo problemów, więc nie powinny być używane w pierwszym modelu.

Jeśli do tworzenia funkcji używasz systemu zewnętrznego, pamiętaj, że system zewnętrzny ma swój cel. Cel systemu zewnętrznego może być tylko w niewielkim stopniu związany z Twoim obecnym celem. Jeśli pobierzesz zrzut z systemu zewnętrznego, może on stać się przestarzały. Jeśli zaktualizujesz funkcje z poziomu systemu zewnętrznego, ich znaczenie może się zmienić. Jeśli korzystasz z funkcji systemów zewnętrznych, pamiętaj, że ta metoda wymaga dużej uwagi.

Głównym problemem związanym z modelami uwzględnianymi i głębokimi jest to, że nie są wyprostowane. W związku z tym nie ma gwarancji, że optymalne rozwiązanie znajdzie w przybliżeniu lub zostanie odnalezione, a lokalna miniatura w każdej iteracji może być inna. Ta odmiana utrudnia ocenę, czy zmiany wprowadzone w systemie są istotne czy losowe. Tworząc model bez funkcji głębokich, możesz uzyskać doskonałą wydajność bazową. Po osiągnięciu punktu odniesienia można wypróbować więcej ezoterycznych metod.

Reguła 18. Odkrywaj treści uogólniane w różnych kontekstach.

Systemy uczące się stanowią niewielki fragment znacznie większego obrazu. Wyobraź sobie na przykład, że post może być wykorzystany w Na topie. Wiele osób da +1-kę, udostępni i skomentuje go jeszcze raz. Jeśli podasz te statystyki, może on promować nowe posty, dla których nie ma żadnych danych w kontekście, w jakim optymalizuje je. Funkcja Co jeszcze warto obejrzeć w YouTube może wykorzystywać łączną liczbę obejrzeń, czyli ile razy jeden film został obejrzany po obejrzeniu drugiego filmu w wyszukiwarce w YouTube. Możesz też użyć bezpośrednich ocen użytkowników. Pamiętaj też, że gdy używasz działania użytkownika, którego używasz jako etykiety, świetnym rozwiązaniem może być pokazanie go w dokumencie w innym kontekście. Wszystkie te funkcje umożliwiają wstawienie nowych treści do kontekstu. Nie chodzi tu o personalizację – najpierw określ, czy ktoś przypadł do gustu w tym kontekście, a potem określ, kto bardziej lubi to robić.

Reguła 19. W miarę możliwości używaj bardzo konkretnych funkcji.

Przy mnóstwie danych łatwiej jest nauczyć się obsługi prostych funkcji niż kilku złożonych funkcji. Identyfikatory pobieranych dokumentów i zapytania kanoniczne nie są zwykle uogólniane, ale ustalają pozycję w rankingu względem etykiet dotyczących zapytań nagłówka. Nie należy więc obawiać się korzystania z grup funkcji, w których każda z nich ma zastosowanie tylko do niewielkiej części danych, ale jej całkowity zasięg przekracza 90%. Możesz użyć regularnego usuwania, aby wyeliminować funkcje, które dotyczą zbyt wielu przykładów.

Reguła 20. Łączenie i modyfikowanie istniejących funkcji w celu tworzenia nowych funkcji w sposób przystępny dla użytkowników.

Funkcje można łączyć i modyfikować na wiele sposobów. Systemy uczące się, takie jak TensorFlow, umożliwiają wstępne przetwarzanie danych dzięki transformacjom. 2 standardowe podejścia to „dyskryminacja” i „krzyży”.

Dyskryminacja polega na stosowaniu stałego obiektu i tworzeniu z niego wielu odrębnych cech. Weź pod uwagę funkcję stałą, na przykład wiek. Możesz utworzyć funkcję o wartości 1, jeśli wiek jest mniejszy niż 18 lat, lub kolejną, która wynosi 1, gdy wiek to 18–35 lat itd. Nie przesadzaj granicom tych histogramów: podstawowe kwantyle mają największe znaczenie.

Krzyże łączą ze sobą co najmniej 2 kolumny cech. Kolumna funkcji w terminologii TensorFlow zawiera zestaw jednorodnych funkcji (np. {male, female}, {US, Canada, Meksyk} itd.). Krzyż to nowa kolumna z cechami zawierającymi funkcje, takie jak {male, female} × {US,Canada, Meksyk}. Ta nowa kolumna będzie zawierać cechę (mężczyzna, Kanada). Jeśli korzystasz z TensorFlow, wysyłając prośbę o utworzenie tego krzyżyka, ta funkcja (męska, Kanada) będzie widoczna w przykładach przedstawiających mężczyzn z Kanady. Pamiętaj, że do trenowania modeli potrzebne są ogromne ilości danych, które obejmują 3, 4 lub więcej kolumn cech podstawowych.

Krzyże, które generują bardzo duże kolumny, mogą przekroczyć budżet. Załóżmy, że przeprowadzasz pewne wyszukiwanie i masz kolumnę cech ze słowami w zapytaniu oraz kolumnę funkcji ze słowami w dokumencie. Możesz je połączyć z krzyżem, ale zyskasz wiele funkcji (patrz Reguła 21).

W przypadku pracy z tekstem dostępne są 2 opcje alternatywne. Najbardziej drażliwy produkt z kropek. Produkt z kropką w najprostszej postaci po prostu zlicza liczbę słów wspólnych między zapytaniem a dokumentem. Następnie można zdyskwalifikować tę funkcję. Kolejnym podejściem jest skrzyżowanie: mamy więc funkcję, która występuje, tylko jeśli słowo „kucyk” występuje zarówno w dokumencie, jak i w zapytaniu, oraz inną funkcję występującą, gdy w dokumencie i zapytaniu występuje słowo „the”.

Reguła 21. Liczba wag funkcji, których można się nauczyć w modelu liniowym, jest w przybliżeniu proporcjonalna do ilości danych.

Istnieją fascynujące wyniki statystyczne teoretyki, które dotyczą odpowiedniego poziomu złożoności modelu, ale w zasadzie to wszystko, co musisz wiedzieć. Zdarzało mi się wątpliwe, że z tysiąca przykładów można się czegoś nauczyć, a czegoś potrzebujesz więcej niż milion, bo utknęły w jakiejś metodzie. Najważniejsze jest dostosowanie nauki do rozmiaru danych:

  1. Jeśli pracujesz w systemie rankingowym wyszukiwarki, w dokumentach i zapytaniu znajdują się miliony różnych słów, a Ty masz 1000 przykładów, użyj usługi zawierającej kropki między funkcjami dokumentu i zapytania, TF-IDF, a półdziesiątki innych zaawansowanych funkcji. 1000 przykładów, kilkanaście funkcji.
  2. Jeśli masz milion przykładów, przekrój kolumny dokumentu i zapytania, korzystając z funkcji regularnej i ewentualnej funkcji. To pozwoli Ci korzystać z milionów funkcji, ale dzięki regularności możesz z kolei je zmniejszyć. Przykłady 10 milionów, a nawet 100 tysięcy.
  3. Jeśli masz setki lub setki miliardów przykładów, możesz łączyć kolumny cech z tokenami dokumentów i zapytań, korzystając z wyboru i regularnej funkcji. Będziesz mieć miliard przykładów i 10 milionów funkcji. Teoria uczenia się statystycznego rzadko daje konkretne granice, ale daje doskonałe wskazówki na początek.

Na koniec użyj reguły 28, aby zdecydować, których funkcji chcesz używać.

Reguła 22. Wyczyść funkcje, których już nie używasz.

Nieużywane funkcje powodują zadłużenie techniczne. Jeśli stwierdzisz, że nie używasz jakiejś funkcji i że nie łączy się ona z innymi funkcjami, usuń ją ze swojej infrastruktury. Warto zadbać o czystość infrastruktury, tak aby jak najszybciej można było wypróbować najbardziej obiecujące funkcje. W razie potrzeby ktoś może dodać z powrotem Twój obiekt.

Zastanów się nad tym, jakie funkcje dodać lub zachować. Ile przykładów ma ta funkcja? Jeśli na przykład masz funkcje personalizacji, z których tylko 8% ma funkcje personalizacji, nie będzie to zbyt skuteczne.

Jednocześnie niektóre funkcje mogą rzucić się ponad waga. Jeśli na przykład masz funkcję, która obejmuje tylko 1% danych, ale 90% przykładów z tą funkcją jest pozytywne, tę funkcję warto dodać.

Analiza człowieka w systemie

Zanim przejdziemy do trzeciej fazy systemów uczących się, musisz skupić się na czymś, czego nie uczy się na żadnych zajęciach z systemów uczących się: jak patrzeć na istniejący model i go ulepszać. To bardziej sztuka niż nauka, ale można jej uniknąć, stosując kilka wzorów.

Reguła 23. Nie jesteś typowym użytkownikiem.

To prawdopodobnie najprostsza metoda wymagająca od zespołu pomocy. Chociaż testy wewnętrzne dają wiele korzyści (przy użyciu prototypu w zespole) i testowanie (za pomocą prototypu w firmie) pracownicy powinni sprawdzić, czy wydajność jest prawidłowa. Zmiana, która w przypadku oczywistego błędu jest niewłaściwa, nie powinna być stosowana. Jednak wszystko, co wygląda wydajnie w pobliżu produkcji, należy dokładniej przetestować, odpowiadając na pytania na platformie związanej z crowdsourcingiem lub przeprowadzając eksperyment na żywo z udziałem prawdziwych użytkowników.

Dzieje się tak z 2 powodów. Po pierwsze, jesteś zbyt blisko kodu. Szukasz konkretnego aspektu postów lub po prostu zbyt wzbudzasz emocje (np. stronniczość potwierdzenia). Po drugie, czas jest zbyt cenny. Weźmy pod uwagę koszt dziewięciu inżynierów, którzy biorą udział w jednym godzinnym spotkaniu, i pomyślcie, ile zakontraktowanych ludzkich wytwórni można kupić na platformie do crowdsourcingu.

Jeśli chcesz naprawdę poznać opinię użytkowników, użyj metodologii dotyczących wrażeń użytkownika. Utwórz profile użytkowników (1 opis znajduje się w sekcji Sketching User Experience) Billa Buxtona na etapie wczesnego procesu i testowania użyteczności (jeden opis znajduje się w filmie Don't Make Me Think) Steve'a Kruga. Profile klientów obejmują tworzenie hipotetycznej nazwy użytkownika. Jeśli na przykład Twój zespół to mężczyźni, dobrym pomysłem może być zaprojektowanie 35-letniego profilu kobiety (wraz z cechami użytkownika) i porównanie wyników generowanych przez mężczyzn z grupami od 25 do 40 roku życia. Zachęcanie prawdziwych użytkowników do obserwowania witryny (lokalnie lub zdalnie) podczas testowania łatwości obsługi, może również przynieść spojrzenie z nowej perspektywy.

Reguła 24. Zmierz delta między modelami.

Jednym z najłatwiejszych i najprzydatniejszych pomiarów, jakie możesz wykonać, zanim którykolwiek użytkownik zapozna się z Twoim nowym modelem, jest oszacowanie, jak bardzo nowe wyniki różnią się od wyników produkcji. Jeśli na przykład masz problem z rankingiem, uruchom oba modele na próbce zapytań w całym systemie i sprawdź symetryczną różnicę w wynikach (ważoną według pozycji w rankingu). Jeśli różnica jest bardzo mała, możesz stwierdzić, że eksperyment nie wykazuje żadnych zmian. Jeśli różnica jest bardzo duża, należy się upewnić, że zmiana jest dobra. Przyglądanie się zapytaniom, gdzie różnica symetryczna jest wysoka, może pomóc w jakościowej ocenie tej zmiany. Zadbaj o to, by system był stabilny. Upewnij się, że model w porównaniu do samego siebie ma niską (najlepiej zero) różnicę symetryczną.

Reguła 25. Przy wyborze modeli skuteczność użytkowa ma w stosunku do potęgi prognozowanej.

Model może próbować przewidzieć współczynnik klikalności. Najważniejsze jest jednak to, co robisz z tą prognozą. Jeśli używasz go do ustalania pozycji dokumentów, jakość ostatecznej pozycji jest ważniejsza niż sama prognoza. Jeśli przewidzieć prawdopodobieństwo, że dokument zawiera spam, a następnie określisz, co jest zablokowane, liczy się przede wszystkim dokładność tego, co jest dozwolone. Najczęściej te 2 sposoby powinny się zgadzać: jeśli się nie zgadzają, będzie raczej niewielkie. Jeśli więc jakaś zmiana powoduje utratę logów, ale obniża wydajność systemu, poszukaj innej funkcji. Kiedy to nastąpi częściej, warto zastanowić się nad celem modelu.

Reguła 26. Szukaj wzorców w pomiarach błędów i twórz nowe funkcje.

Załóżmy, że widzisz przykład trenowania, który zawiera błąd. W zadaniu klasyfikacji ten błąd może być fałszywie pozytywny lub fałszywie negatywny. W zadaniu dotyczącym rankingu błąd może oznaczać parę, w której wartość pozytywna była niższa niż wartość ujemna. Najważniejszą kwestią jest to, że jest to przykład systemu, który wie, że popełnił błąd, i chce go naprawić, jeśli da się to zrobić. Jeśli nadasz modelowi funkcję, która umożliwia jego naprawienie, model spróbuje z niej skorzystać.

Z drugiej strony, jeśli spróbujesz utworzyć funkcję na podstawie przykładów, które system nie uzna za błędy, zostanie ona zignorowana. Załóżmy na przykład, że w wyszukiwarce aplikacji z Google Play ktoś wyszukuje hasło „bezpłatne gry”. Załóżmy, że jednym z najlepszych wyników jest mniej trafna aplikacja. Możesz więc utworzyć funkcję dla aplikacji „gag”. Jeśli jednak maksymalizujesz liczbę instalacji, a użytkownicy szukający bezpłatnych gier używają aplikacji „gag”, działanie funkcji „gag” nie przyniesie oczekiwanego rezultatu.

Gdy poznasz przykłady wadliwego modelu, zwróć uwagę na trendy wykraczające poza obecny zestaw funkcji. Jeśli np. system wydaje się publikować dłuższe posty, dodaj do nich długość. Nie podawaj zbyt szczegółowych informacji o nowych funkcjach. Jeśli chcesz dodać długość posta, nie próbuj zgadywać, ile ma on zawierać. Wystarczy dodać kilkanaście funkcji, a model pozwoli im się zorientować, co z nimi zrobić (zobacz regułę nr 21). To najprostszy sposób na uzyskanie oczekiwanego efektu.

Reguła 27. Staraj się ocenić zaobserwowane niepożądane zachowanie.

Niektórzy członkowie Twojego zespołu będą sfrustrowani właściwościami nielubianego systemu, które nie zostały zebrane przez funkcję utraty. Na tym etapie powinien zrobić wszystko, co konieczne, aby zmienić swoje dane w liczba ciągła. Jeśli np. użytkownik uzna, że w wyszukiwarce Google Play wyświetla się zbyt wiele „aplikacji tego typu”, może poprosić o to weryfikatorów. W tym przypadku możesz użyć danych oznaczonych etykietami, ponieważ stosunkowo niewielkie odsetek zapytań odpowiada za znaczną część ruchu. Jeśli problemy są wymierne, możesz zacząć używać ich jako funkcji, celów lub danych. Ogólna zasada jest taka: najpierw mierz, optymalizuj drugi raz.

Reguła 28. Pamiętaj, że identyczne krótkoterminowe zachowania nie oznaczają identycznego długoterminowego zachowania.

Wyobraź sobie, że masz nowy system, który sprawdza każdy identyfikator dokumentu i dokładnego zapytania, a następnie oblicza prawdopodobieństwo kliknięcia każdego dokumentu dla każdego zapytania. Okazuje się, że jego działanie jest niemal identyczne z obecnym systemem, zarówno przy testach A/B, jak i ze względu na prostotę, więc je uruchamiasz. Zauważasz jednak, że nie wyświetlają się żadne nowe aplikacje. Dlaczego? Ponieważ Twój system wyświetla dokument tylko na podstawie jego własnej historii z tym zapytaniem, nie da się sprawdzić, czy powinien być wyświetlany nowy dokument.

Jedynym sposobem na zrozumienie, jak taki system może działać w dłuższej perspektywie, jest wytrenowanie modelu tylko na danych pozyskanych z użycia modelu. Jest to bardzo trudne.

Zniekształcenie między trenowaniem a zastosowaniem praktycznym

Zniekształcenie między trenowaniem a zastosowaniem praktycznym różni się od wydajności podczas trenowania i wydajności podczas udostępniania. To zniekształcenie może być spowodowane przez:

  • Rozbieżności między sposobem obsługi danych w potokach trenowania i obsługi.
  • Zmiana w przedziale danych między czasem trenowania i obsługi.
  • pętla informacji zwrotnych między modelem a algorytmem.

Zaobserwowano zniekształcenia między trenowaniem a systemem uczenia maszynowe w Google, które negatywnie wpływają na wydajność. Najlepszym rozwiązaniem jest gruntowne monitorowanie działania, aby zmiany wprowadzane w systemie i danych nie były niezauważalne.

Reguła 29. Najlepszym sposobem na zagwarantowanie, że trenujesz tak, jak obsługujesz, jest zapisanie zestawu funkcji używanych podczas udostępniania, a następnie zastosowanie ich do dziennika w celu użycia ich w czasie trenowania.

Nawet jeśli nie możesz tego zrobić w przypadku każdego przykładu, zrób to w przypadku niewielkiego ułamka, aby potwierdzić spójność między udostępnianiem a szkoleniem (patrz reguła 37). Zespoły, które dokonały tego pomiaru w Google, były zaskoczone wynikami. Strona główna YouTube została przełączona na funkcje logowania w momencie wyświetlania, co znacznie poprawia jakość i złożoność kodu. Poza tym wiele zespołów zmienia swoją infrastrukturę.

Reguła 30. Próbkowane dane dotyczące wagi są ważne i nie należy ich pomijać.

Gdy masz zbyt wiele danych, kuszą Cię pliki od 1 do 12 i ignorujesz pliki od 13 do 99. To błąd. Dane, które nigdy nie zostały wyświetlone użytkownikowi, mogą być porzucone, ale ważenie według wagi jest najlepszym sposobem na odpoczynek. Waga ważności oznacza, że jeśli chcesz użyć przykładowego testu X z prawdopodobieństwem 30%, jego waga powinna wynosić 10/3. Podczas przypisywania wagi wszystkie właściwości kalibracji omówione w regule 14 są nadal wstrzymane.

Reguła 31. Pamiętaj, że jeśli dołączysz do tabeli dane podczas trenowania i wyświetlania, dane w tabeli mogą ulec zmianie.

Załóżmy, że dołączasz identyfikatory dokumentów w tabeli zawierającej funkcje dotyczące tych dokumentów (np. liczbę komentarzy lub kliknięć). W okresie między trenowaniem a udostępnianiem funkcji w tabeli mogą się zmieniać. Prognozowanie modelu tego samego dokumentu może się wtedy różnić między trenowaniem a udostępnianiem. Najłatwiejszym sposobem uniknięcia tego rodzaju problemów jest rejestrowanie funkcji w czasie ich wyświetlania (patrz Reguła 32). Jeśli tabela zmienia się tylko powoli, możesz też migać ją co godzinę lub codziennie, aby uzyskać przydatne dane. Nie rozwiązuje to jednak całego problemu.

Reguła 32. W miarę możliwości używaj ponownie kodu między potokiem trenowania a potokiem obsługi.

Przetwarzanie wsadowe różni się od przetwarzania online. W przetwarzaniu online musisz obsługiwać wszystkie otrzymane żądania (np. musisz przeprowadzić osobne wyszukiwanie dla każdego zapytania), natomiast w przypadku przetwarzania wsadowego możesz połączyć zadania (np. dołączenie). W czasie, gdy odbywa się przetwarzanie online, przetwarzasz je w trybie online, natomiast trenowanie to przetwarzanie wsadowe. Jest jednak kilka rzeczy, które możesz zrobić, aby ponownie wykorzystać kod. Możesz na przykład utworzyć obiekt charakterystyczny dla Twojego systemu, w którym wyniki zapytań i połączeń mogą być zapisywane w czytelny dla człowieka sposób, a błędy można łatwo testować. Następnie, gdy zbierzesz wszystkie informacje, na potrzeby obsługi lub trenowania będziesz korzystać z typowej metody łączenia obiektu, który jest zrozumiały dla człowieka, z określonym formatem używanym przez systemy uczące się. To eliminuje źródło zniekształcenia między trenowaniem a zastosowaniem praktycznym. W tym przypadku nie używaj 2 różnych języków programowania między trenowaniem a wyświetlaniem treści. Ta decyzja będzie praktycznie niedostępna.

Reguła 33: jeśli model jest produkowany na podstawie danych do 5 stycznia, przetestuj go na danych z okresu od 6 stycznia i później.

Ogólnie rzecz biorąc, mierzyj wydajność modelu na danych zebranych po wytrenowaniu modelu, ponieważ lepiej odzwierciedla to, jak system będzie produkował. Jeśli produkujesz model na podstawie danych do 5 stycznia, przetestuj go na danych z 6 stycznia. Wydaje się, że nowe dane nie będą mieć tak dobrych wyników, ale nie powinny się znacząco zmniejszyć. Z powodu dziennych efektów nie możesz przewidzieć średniego współczynnika klikalności lub współczynnika konwersji, ale obszar pod krzywą, który odpowiada prawdopodobieństwu pozytywnego przykładu na wynik wyższy niż negatywny, powinien być dość zbliżony.

Reguła 34. W klasyfikacji binarnej służącej do filtrowania (np. do wykrywania spamu lub określania interesujących e-maili) poświęcaj uwagę krótko-poważnym wynikom w celu dostarczania bardzo czystych danych.

W zadaniu filtrowania przykłady oznaczone jako wykluczające nie są wyświetlane użytkownikowi. Załóżmy, że masz filtr, który blokuje 75% wykluczonych przykładów podczas wyświetlania reklam. Może się kuszyć do dodatkowych danych treningowych z instancji wyświetlanych użytkownikom. Jeśli na przykład użytkownik oznaczy e-maila jako spam, możesz to sprawdzić.

Ta metoda wprowadza jednak odchylenie próby. Możesz zebrać bardziej przejrzyste dane, jeśli zamiast tego podczas wyświetlania oznaczysz 1% całego ruchu jako „wstrzymanych”, a wszystkie przesłane przykłady prześlesz użytkownikowi. Teraz Twój filtr blokuje co najmniej 74% wykluczających przykładów. Te wskazane przykłady mogą stać się danymi treningowymi.

Pamiętaj, że jeśli filtr blokuje co najmniej 95% wykluczających przykładów, takie podejście jest mniej opłacalne. Nawet jeśli chcesz zmierzyć wydajność wyświetlania, możesz utworzyć próbkę jeszcze bardziej zniekształconą (np. 0,1% lub 0,001%). Wystarcza 10 tysięcy przykładów, aby dokładnie oszacować skuteczność.

Reguła 35: wystrzegaj się niepokojącego odchylenia związanego z rankingiem.

Gdy zmieniasz algorytm rankingowy na tyle głęboko, że wyświetlane są różne wyniki, skutecznie zmieniasz dane, które będą dla Ciebie widoczne w przyszłości. Pojawią się zniekształcenia te i odpowiednio zaprojektuj model. Istnieje wiele różnych metod. Te podejścia to wszystkie sposoby faworyzowania danych, które były już widoczne w Twoim modelu.

  1. Korzystaj z regularniejszej synchronizacji funkcji, które obejmują więcej zapytań niż te, które są włączone tylko dla jednego zapytania. Dzięki temu model będzie faworyzować funkcje typowe dla danego zapytania lub kilku zapytań zamiast ogólnych dla wszystkich zapytań. Takie podejście może zapobiec pojawianiu się bardzo popularnych wyników w przypadku nietrafnych zapytań. Jest to przeciwieństwo bardziej konwencjonalnym wskazówkom dotyczącym bardziej systematycznego stosowania kolumn cech z bardziej unikalnymi wartościami.
  2. Zezwalaj na stosowanie tylko pozytywnych ocen funkcji. Dlatego każda dobra funkcja będzie lepsza niż „nieznana”.
  3. nie są dostępne wyłącznie funkcje związane z dokumentami; To skrajna wersja nr 1. Na przykład, nawet jeśli dana aplikacja jest popularna do pobrania, bez względu na to, czego dotyczyło zapytanie, nie chcesz wyświetlać jej wszędzie. Brak funkcji samego dokumentu to bardzo proste. Powód, dla którego nie chcesz wyświetlać danej popularnej aplikacji w dowolnym miejscu, jest taki, że wszystkie aplikacje są łatwo dostępne. Na przykład jeśli ktoś wpisze w wyszukiwarce hasło „aplikacja do obserwacji ptaków”, może pobrać „strumieniowe ptaki”, ale nie było to wyraźnie celem. Wyświetlanie takiej aplikacji może poprawić szybkość pobierania, ale w ostatecznym rozrachunku nie zaspokajać potrzeb użytkownika.

Reguła 36. Unikaj zapętlenia informacji w funkcjach pozycjonowania.

Pozycja treści znacznie wpływa na prawdopodobieństwo, że użytkownik wejdzie z nim w interakcję. Jeśli umieścisz aplikację na pierwszej pozycji, będzie ona częściej klikana i będziesz mieć większą pewność, że zostanie kliknięta. Jednym ze sposobów rozwiązania tego problemu jest dodanie funkcji pozycjonowania, tj. funkcji pozycji treści na stronie. Trenujesz model z funkcjami pozycjonującymi i uczy się on na przykład ważyć, na przykład cechę „pierwsza pozycja”. Twój model przypisuje więc mniejszą wagę innym czynnikom w przykładach z wartością „1stposition=true”. Następnie w trakcie wyświetlania aplikacji nie są dostępne żadne funkcje pozycjonujące ani wszystkie funkcje domyślne, ponieważ przed ustaleniem kolejności ich wyświetlania wybierana jest ocena kandydatów.

Ważne jest, aby oddzielić poszczególne cechy pozycji od reszty modelu ze względu na asymetrię między trenowaniem a testowaniem. Najlepiej, aby model był sumą funkcji umiejscowionej i funkcji reszty funkcji. Nie porównuj na przykład funkcji pozycjonowania z funkcjami dokumentów.

Reguła 37. Zniekształcanie trenowania/wyświetlania.

Jest kilka przyczyn, które mogą spowodować zniekształcenie najogólniejszego sensu. Możesz ją podzielić na kilka części:

  • Różnica między skutecznością danych treningowych a danymi wstrzymanymi. Zawsze istnieje i nie zawsze jest zła.
  • Różnica między skutecznością danych wstrzymanych a danymi z dnia następnego. To zawsze będzie istnienie. Dopracuj swoje regularne rutyny, aby osiągnąć maksymalną skuteczność następnego dnia. Jednak duży spadek wydajności między danymi wstrzymanymi a następnymi może wskazywać na to, że niektóre funkcje są podatne na upływ czasu i mogą obniżyć wydajność modelu.
  • Różnica między skutecznością danych z następnego dnia a danymi na żywo. Jeśli stosujesz model do przykładu w danych treningowych i ten sam przykład podczas udostępniania, powinien on dokładnie osiągnąć ten sam wynik (patrz Reguła 5). Dlatego rozbieżność najprawdopodobniej wskazuje na błąd techniczny.

ML

Mogą się tam pojawić pewne oznaki, że faza zbliża się do końca. Po pierwsze, miesięczne zyski zaczną maleć. Zauważysz pewne zależności między danymi: w niektórych eksperymentach nastąpi wzrost, a w innych – wzrost. To ciekawe zadanie. Uzyskanie korzyści jest trudniejsze, dlatego systemy uczące się muszą być bardziej złożone. Zastrzeżenie: ta sekcja ma więcej reguł dotyczących nieba niż wcześniejsze sekcje. Widzimy, że wiele zespołów przechodzi szczęśliwe czasy na fazach I i II. Po osiągnięciu fazy III zespoły muszą znaleźć własną ścieżkę.

Reguła 38. Nie marnuj czasu na nowe funkcje, jeśli problem stanowi niedopasowane cele.

W ramach platformy pomiarowej Twój zespół zacznie analizować problemy wykraczające poza zakres obecnych systemów uczących się. Jak wspomnieliśmy wcześniej, jeśli Twoje cele produktowe nie są uwzględnione w dotychczasowym celu algorytmicznym, musisz zmienić cel lub cele produktowe. Na przykład możesz zoptymalizować kliknięcia, kliknięcia przycisku +1 lub pobrania, ale podejmować decyzje dotyczące wprowadzenia na podstawie testów ocenianych przez człowieka.

Reguła 39. Decyzje związane z wprowadzeniem produktu są pośrednikiem w długoterminowych celach związanych z produktami.

Alicja ma pomysł, jak zmniejszyć straty logistyczne związane z przewidywaniem instalacji. Dodaje funkcję. Strata logistyczna traci. Podczas eksperymentu na żywo zauważa wzrost liczby instalacji. Marta mówi jednak, że podczas spotkania z ekspertami liczba aktywnych użytkowników dziennie spada o 5%. Zespół postanawia nie uruchamiać modelu. Alicja jest rozczarowana, ale teraz zdaje sobie sprawę, że decyzje dotyczące uruchamiania zależą od wielu kryteriów. Tylko niektóre z nich można zoptymalizować bezpośrednio za pomocą systemów uczących się.

Prawda jest taka, że prawdziwy świat nie jest lochami ani smokami: nie ma „punktów trafień” określających kondycję produktu. Zespół musi wykorzystać zgromadzone dane, aby przewidzieć skuteczność systemu na przyszłość. Muszą się troszczyć o zaangażowanie, liczbę użytkowników aktywnych w ciągu 1 dnia, 30 aktywnych użytkowników, przychody oraz zwrot z inwestycji przez reklamodawcę. Te dane, które można mierzyć w testach A/B, służą jedynie celom długoterminowym: satysfakcjonowaniu użytkowników, zwiększaniu liczby użytkowników, zaspokajaniu partnerów i zysku. Można je nawet uznać za dobrze działające usługi wysokiej jakości i dobrze prosperującą firmę za pięć lat.

Jedyne, co łatwo zrobić, to decyzja, gdy wszystkie dane się poprawiają (lub przynajmniej nie pogarszają). Jeśli zespół ma wybór między zaawansowanym algorytmem systemów uczących się a prostym algorytmem heurystycznym, a prosta metoda heurystyczna lepiej sprawdza się we wszystkich tych wskaźnikach, powinna wybrać metodę heurystyczną. Nie ma też wyraźnego rankingu wszystkich możliwych wartości danych. Weź pod uwagę te 2 sytuacje:

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

Jeśli bieżący system to A, zespół prawdopodobnie nie przejdzie na B. Jeśli obecny system to B, zespół najprawdopodobniej nie przejdzie na A. Wygląda na to, że jest to sprzeczne z racjonalnym zachowaniem. Jednak prognozy zmian wskaźników mogą się nie udać, co wiąże się z dużym ryzykiem każdej z tych zmian. Każdy rodzaj danych niesie ze sobą pewne ryzyko, które budzą wątpliwości zespołu.

Co więcej, żadne dane nie dotyczą najważniejszych kwestii związanych z zespołem: „Gdzie jest moja usługa za 5 lat?”.

Z kolei osobom fizycznym preferuje jeden cel, który może bezpośrednio optymalizować. Większość narzędzi korzystających z systemów uczących się preferuje takie środowisko. Inżynier eliminujący nowe funkcje może uzyskiwać na bieżąco premierę w takim środowisku. Istnieje jeden z tych typów systemów uczących się – systemy uczące się – i które pomagają w rozwiązaniu tego problemu. Można na przykład sformułować problem ograniczenia zadowolenia z granicami poszczególnych wskaźników i zoptymalizować wybraną liniową kombinację danych. Jednak nie wszystkie dane można łatwo określić jako cele systemów uczących się: po kliknięciu dokumentu lub zainstalowaniu aplikacji jest to spowodowane tym, że treść została pokazana. Jednak dużo trudniej jest ustalić, dlaczego użytkownik odwiedza Twoją witrynę. Jak można przewidzieć przyszły sukces całej witryny:

Reguła 40: nie zwracaj uwagi na prosty interfejs.

Modele ujednolicone, które uwzględniają nieprzetworzone funkcje i bezpośrednią pozycję w rankingu treści, to najprostsze modele do debugowania i rozumienia. Jednak zestaw modeli („model”, który łączy wyniki innych modeli) może być lepszym rozwiązaniem. Dla uproszczenia każdy model powinien być zbiorem zawierającym tylko dane z innych modeli lub modelem podstawowym korzystającym z wielu funkcji, ale nie z obu tych rozwiązań. Jeśli na modelach oprócz innych wytrenowanych modeli masz wytrenowane, połączenie ich może spowodować złe zachowanie.

Użyj prostego modelu do grupowania, które jako dane wejściowe pobiera tylko dane wyjściowe swoich „podstawowych modeli”. Chcesz też egzekwować właściwości w tych modelach zestawu. Na przykład wzrost wyniku uzyskanego przez model podstawowy nie powinien obniżać wyniku zespołu. Najlepiej, jeśli modele przychodzące są zrozumiałe semantycznie (np. kalibrowane), aby nie wprowadzać w błąd modeli złożonych. Wymuszaj też, że zwiększenie prawdopodobieństwa w przypadku klasyfikatora bazowego nie zmniejsza przewidywanego prawdopodobieństwa zespołu.

Zasada nr 41: w przypadku danych dotyczących skuteczności trzeba szukać nowych źródeł informacji, zamiast dodawać istniejące.

Dodano dane demograficzne na temat użytkownika. Dodałeś kilka informacji o słowach w dokumencie. Udało Ci się zapoznać z szablonem i dostosować. W ciągu kilku kwartałów odnotowujesz wprowadzenie najważniejszych danych o ponad 1%. Co dalej?

Zacznij tworzyć infrastrukturę dla radykalnie różnych funkcji, takich jak historia dokumentów, do których użytkownik korzystał w ciągu ostatniego dnia, tygodnia lub roku, albo danych z innej usługi. Używaj jednostek wikidata lub innych informacji wewnątrz firmy (np. Grafu wiedzy Google). Używaj deep learning. Zacznij dostosowywać oczekiwania względem oczekiwanego zwrotu z inwestycji i rozwijaj swoje działania. Tak jak w przypadku każdego projektu inżynierskiego, musisz wziąć pod uwagę korzyści związane z dodaniem nowych funkcji, a także podnosić koszty.

Zasada nr 42: nie oczekuj, że różnorodność, personalizacja czy trafność będą na tyle korelacyjne, jak sądzisz.

Zróżnicowanie zestawu treści może oznaczać wiele, a źródłem treści jest jedna z najpopularniejszych. Personalizacja oznacza, że każdy użytkownik ma własne wyniki. Trafność wskazuje, że wyniki danego zapytania są dla niego bardziej odpowiednie od pozostałych. Wszystkie te 3 usługi są więc określane inaczej niż zwykłe.

Problem w tym, że co zwykle się nie udaje.

Zwróć uwagę, że jeśli Twój system mierzy kliknięcia, czas, czas oglądania, +1-ki, udostępnienia itp., mierzysz popularność treści. Zespoły starają się czasem nauczyć osobisty model różnorodności. Do personalizacji dodaje się funkcje, które pozwalają na personalizację systemu (niektóre funkcje reprezentujące zainteresowania użytkownika) lub dywersyfikację (cechy wskazujące, czy ten dokument ma cechy wspólne z innymi zwracanymi dokumentami, takie jak autor lub treść), i odnotowują, że te funkcje mają mniejszą wagę (lub inny znak) niż oczekiwano.

Nie oznacza to, że różnorodność, personalizacja czy trafność są bezwartościowe. Jak wspomniano w poprzedniej regule, możesz dokonać postedycji, aby zwiększyć różnorodność i trafność. Jeśli cele na dłuższą metę wzrosną, możesz zadeklarować, że różnorodność/trafność jest cenna, niezależnie od popularności. Następnie możesz dalej korzystać z obróbki lub bezpośrednio zmienić celowy charakter w zależności od różnorodności lub trafności.

Zasada nr 43: Twoi znajomi są zwykle tacy sami w różnych usługach. Twoje zainteresowania zwykle nie.

Zespoły w Google mają sporo pracy, jeśli chodzi o wykorzystanie modelu, który przewiduje bliskość połączenia w jednej usłudze, i dobrze sprawdza się w innej. Twoi znajomi są. Z drugiej strony widziałem, jak kilka zespołów walczy z funkcjami personalizacji w różnych usługach. Tak. Wygląda na to, że wszystko powinno działać. Na razie wygląda na to, że nie. Czasem udało się wykorzystać nieprzetworzone dane z jednej usługi do prognozowania zachowania w innej. Pamiętaj, że nawet informacje o tym, że użytkownik ma historię w innej usłudze, mogą być przydatne. Aktywność na przykład w dwóch usługach może wskazywać na to, że sama jest używana.

Istnieje wiele dokumentów dotyczących systemów uczących się zarówno w Google, jak i na zewnątrz.

Podziękowania

Dziękujemy dzięki David Westbrook, Peterowi Brandtowi, Samuelowi Ieong, Chenyu Zhao, Li Wei, Michalisowi Potamias, Evanowi Rosenowi, Barrym Rosenbergowi, Christine Robson, James Pine, Tal Shaked, Tushar Chandra, Mustafa Ispir, Jeremiah Harmsen, Herstanu-d'U-deta, Dziękuję też Kristen Lefevre, Suddha Basu i Chrisowi Bergowi, którzy pomogli we wcześniejszej wersji. Wszelkie błędy, pominięcia lub niepopularne opinie są moje.

Dodatek

W tym dokumencie znajdziesz wiele odniesień do usług Google. Aby podać szerszy kontekst, zamieszczam krótki opis najczęstszych przykładów.

YouTube – omówienie

YouTube to usługa strumieniowej transmisji wideo. Zarówno zespoły YouTube ds. oglądania, jak i strony głównej YouTube wykorzystują modele systemów uczących się do ustalania pozycji filmu w rankingu. Filmy warte obejrzenia są polecane po obejrzeniu aktualnie odtwarzanego materiału, a strona główna – polecane użytkownikom, którzy przeglądają stronę główną.

Omówienie Google Play

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

Omówienie Google+

Google+ korzysta z systemów uczących się w różnych sytuacjach, np. do określania pozycji postów w „strumieniu” wyświetlanych przez użytkowników, rankingu „Na topie” (popularnych w danej chwili), rankingu znajomych osób itp. W 2019 r. konto Google Plus zostało zamknięte. 6 lipca 2020 r. zastąpiliśmy usługę Google Currents dla kont firmowych.