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

Sprawdzone metody w zakresie inżynierii ML

Martin Zinkewicz

Ten dokument jest przeznaczony dla osób mających podstawową wiedzę o systemach uczących się wykorzystują sprawdzone metody Google w zakresie systemów uczących się. it przedstawia styl dla systemów uczących się, podobny do Przewodnika stylów Google C++ i inne popularne przewodniki dotyczące praktycznego programowania. Jeśli masz za sobą zajęcia w systemach uczących się, stworzono lub pracował nad modelem opartym na uczeniu maszynowym, dysponujesz wiedzą potrzebną do przeczytania tego dokumentu.

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

Terminologia

Poniższe terminy będą wielokrotnie pojawiać się w toku dyskusji na temat skutecznych uczenie maszynowe

  • Instancja: obiekt, którego obiekt ma dotyczyć z prognozą. Może to być na przykład strona internetowa, do której chcesz sklasyfikować jako „o kotach” albo „nie o kotach”.
  • Etykieta: odpowiedź na zadanie prognozowania, czyli odpowiedź wygenerowana przez systemów uczących się i właściwą odpowiedź w danych treningowych. Dla: np. etykieta strony internetowej może wyglądać tak: „informacje o kotach”.
  • Funkcja: właściwość instancji używana w zadaniu prognozowania. Dla: strona może na przykład zawierać funkcję „zawiera słowo „kot”.
  • Kolumna cech: zbiór powiązanych cech, takich jak zbiór wszystkich możliwych krajów, w których mogą mieszkać użytkownicy. Przykład może obejmować jedną lub więcej funkcji obecny w kolumnie cech. „Kolumna cech” to terminologia charakterystyczna dla Google. Kolumna cech jest nazywana „przestrzenią nazw” w systemie VW (w firmie Yahoo/Microsoft) lub .
  • Przykład: instancja (z jej funkcjami) i etykieta.
  • Model: statystyczna reprezentacja zadania prognozowania. Wytrenujesz model na a następnie użyć modelu do prognozowania.
  • Dane: liczba, która jest dla Ciebie ważna. Mogą być bezpośrednio optymalizowane, ale nie muszą.
  • Cel: dane, które algorytm próbuje zoptymalizować.
  • Potok: infrastruktura otaczająca algorytm systemów uczących się. Obejmuje zbieranie danych z interfejsu i umieszczanie ich w danych treningowych , wytrenować co najmniej 1 model i wyeksportować je do środowiska produkcyjnego.
  • Współczynnik klikalności – odsetek użytkowników strony, którzy kliknęli w reklamie.

Omówienie

Aby tworzyć świetne produkty:

używaj uczenia maszynowego jak wielki inżynier, a nie wielki ale tym, którym nie jesteś.

Większość problemów, z którymi się borykasz, to w rzeczywistości problemy techniczne. Równomierny i zasobami wybitnego eksperta ds. systemów uczących się, pochodzą ze świetnych funkcji, a nie świetnych algorytmów systemów uczących się. Podstawowa zasada podejście jest takie:

  1. Upewnij się, że Twój potok jest dobrze osadzony od początku do końca.
  2. Zacznij od rozsądnego celu.
  3. Dodaj rozsądne funkcje w prosty sposób.
  4. Upewnij się, że potok jest sprawny.

Ta metoda sprawdzi się w przypadku bardzo długi okres. Odejdź od tego podejścia tylko wtedy, gdy nie ma już więcej dzięki którym zajdziesz dalej. Dodanie złożoności spowalnia kolejne wersje.

Po wykorzystaniu tych prostych sztuczek najnowocześniejsze systemy uczące się mogą z pewnością znajdzie się w Twojej przyszłości. Zapoznaj się z sekcją na temat: Faza III w projektach systemów uczących się.

Układ tego dokumentu jest następujący:

  1. Pierwsza część powinna pomóc Ci określić, czy jest odpowiedni czas na stworzenie systemów uczących się.
  2. Druga część dotyczy wdrożenia pierwszego potoku.
  3. Trzecia część dotyczy wprowadzenia powtarzania procesów przy jednoczesnym dodawaniu nowych funkcji do potoku, jak oceniać modele oraz zniekształcenia między trenowaniem a zastosowaniem.
  4. ostatnia część co zrobić, gdy dotrzesz na płaskowyż.
  5. Zobaczysz listę zadań oraz dodatku z kilkoma dotyczące systemów często używanych jako przykłady w tym dokumencie.

Przed wprowadzeniem systemów uczących się

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

Uczenie maszynowe to super, ale wymaga danych Teoretycznie można pobrać dane, wymyślić inny problem, a następnie dostosować model do nowego produktu. będą prawdopodobnie miały gorsze wyniki heurystyka. Jeśli uważasz, że uczenie maszynowe da Ci 100% lepszego wyniku, heurystyka zapewni Ci 50%, w danej dziedzinie.

Na przykład do ustalania pozycji aplikacji w portalu sprzedawcy aplikacji możesz użyć parametru współczynnik lub liczbę instalacji na podstawie danych heurystycznych. Jeśli wykryjesz spam, odfiltrowywać wydawców, którzy już wcześniej wysyłali spam. Nie bój się używać człowieka albo ją edytować. Jeśli chcesz uszeregować kontakty, uwzględnij ostatnio używane najwyższe (lub nawet uporządkowane w kolejności alfabetycznej). Jeśli uczenie maszynowe nie jest absolutnie wymagane dla Twojego produktu, nie używaj go, dopóki nie masz danych.

Reguła 2: zaprojektuj i zaimplementuj dane.

Zanim sformalalizujesz, co będzie robić Twoje systemy uczące się, sprawdź w obecnym systemie. Należy to zrobić z następujących powodów:

  1. Łatwiej jest wcześniej uzyskać uprawnienia od użytkowników systemu.
  2. Jeśli uważasz, że w przyszłości coś może być niepokojące, lepiej pobrać dane historyczne.
  3. Jeśli projektujesz swój system z uwzględnieniem instrumentacji metrycznych, na o Tobie działania w przyszłości. Konkretnie chodzi tu o to, żeby nie czuć zachwytu. dla ciągów w logach do instrumentowania wskaźników.
  4. Zauważysz, co się zmienia, a co pozostaje bez zmian. Przykład: Załóżmy, że chcesz bezpośrednio zoptymalizować liczbę aktywnych użytkowników danego dnia. Pamiętaj jednak: już podczas wczesnej manipulacji systemem możesz zauważyć, gwałtowne zmiany w interfejsie użytkownika nie zmienią tego w znaczący sposób. danych.

Zespół Google Plus mierzy liczbę rozszerzeń na odczyt, udostępnień za przeczytaną stronę, +1-ki na odczyt, komentowanie/przeczytanie, komentarze na użytkownika, udostępnianie na użytkownika itp., z których korzysta. podczas obliczania atrakcyjności posta. Pamiętaj też, że platformy eksperymentu, w której można grupować użytkowników w grupy i zbierać mają duże znaczenie w przypadku eksperymentów. Zobacz Reguła 12.

Bardziej liberalne podejście do zbierania danych pozwala uzyskać szerszy obraz systemu. Widzisz problem? Dodaj wskaźnik, aby go śledzić. Jestem podekscytowany pewnymi zmiany ilościowe w ostatniej wersji? Dodaj wskaźnik, aby go śledzić.

Zasada 3. Wybierz uczenie maszynowe zamiast skomplikowanej heurystyki.

Prosta metoda heurystyczna może sprawić, że produkt zostanie opublikowany. Złożona heurystyka których nie da się naprawić. Gdy masz już dane i podstawową koncepcję działań, przejdź do systemów uczących się. Jak w przypadku większości inżynierii oprogramowania lub zadania, warto stale aktualizować swoje podejście, niezależnie od tego, a także okaże się, że oparty na systemach uczących się jest łatwiejszy do aktualizowania i utrzymywania (zobacz Reguła 16).

ML Faza I: pierwszy potok

W trakcie pracy nad pierwszym potokiem skoncentruj się na infrastrukturze systemowej. Choć to świetna zabawa pomyśleć o całym uczeniu maszynowym, jakie mamy do dyspozycji. jeśli nie zaufamy najpierw agencji potoku.

Zasada nr 4: niech pierwszy model jest prosty i odpowiednio dobrana infrastruktura.

Pierwszy model stanowi największą atrakcyjność dla produktu, dlatego nie wymaga na fantazję. Infrastruktura będzie jednak o wiele więcej problemów niż Ty czego się spodziewać. Zanim ktokolwiek będzie mógł zacząć korzystać z Twojego nowego, zaawansowanego systemu uczącego się, aby określić:

  • Jak znaleźć przykłady do użycia w algorytmie uczenia się.
  • Pierwsze pytanie o to, co „dobre” i „zły” dla Twojego systemu.
  • Jak zintegrować model z aplikacją. Możesz zastosować aktywny model; wstępnie obliczyć model na przykładach offline i zapisywać wyniki w tabeli. Można na przykład wstępnie sklasyfikować strony internetowe i zapisać wyniki w tabeli, ale warto klasyfikować wiadomości czatu na żywo.

Wybór prostych funkcji ułatwia zapewnienie, że:

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

Mając już system, który niezawodnie wykonuje te trzy zadania, co pozwala robić większość rzeczy. Prosty model zapewnia podstawowe wskaźniki podstawowe zachowanie, które można wykorzystać do testowania bardziej złożonych modeli. Niektóre drużyny starają się jako „neutralnego” pierwsze uruchomienie: pierwsze wprowadzenie, które wyraźnie obniża priorytet dzięki systemom uczącym się, aby nie rozpraszać uwagi.

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

Sprawdź, czy infrastruktura jest podlegająca testom, a części edukacyjne system jest zamknięty, dzięki czemu można przetestować wszystko dookoła. Oto najważniejsze kwestie:

  1. Testowanie pobierania danych do algorytmu. Sprawdź, które kolumny cech powinny być wypełnione. Tam, gdzie pozwala na to prywatność, ręcznie sprawdź dane wejściowe Twojego algorytmu treningowego. Jeśli to możliwe, statystyk w potoku w porównaniu ze statystykami dla tych samych danych przetworzone w innym miejscu.
  2. Przetestuj pobieranie modeli z algorytmu trenowania. Upewnij się, że model w Twoim środowisku treningowym daje ten sam wynik co model w Twoim środowisku wyświetlania reklam (zobacz Reguła 37).

Uczenie maszynowe zawiera element nieprzewidywalności, przeprowadzić testy kodu służące do tworzenia przykładów podczas trenowania i wyświetlania oraz który można wczytać i używać podczas wyświetlania stałego modelu. Ważne jest też, dotyczące danych: zobacz Praktyczne porady dotyczące analizy dużych, złożonych zbiorów danych.

Reguła 6. Zachowaj ostrożność, jeśli podczas kopiowania potoków utracisz dane.

Często tworzymy potok, kopiując istniejący potok (np. programowanie cargo cult ), a stary potok usuwa dane potrzebne do utworzenia nowego. Na przykład potok Na topie w Google Plus. pomija starsze posty (ponieważ usiłuje ustalać ranking nowych postów). Ten potok był skopiowano do strumienia Google Plus, gdzie są starsze posty są wciąż istotne, ale w ramach potoku wciąż pojawiają się stare posty. Inny typowym wzorcem jest rejestrowanie tylko danych, które są widoczne dla użytkownika. Dane te są więc bezużyteczna, jeśli chcemy modelować, dlaczego dany post nie został wyświetlony przez użytkownika, ponieważ wszystkie negatywne przykłady zostały pominięte. Podobny problem wystąpił w: Graj. Podczas pracy na stronie głównej aplikacji Play został utworzony nowy potok, zawiera przykłady ze strony docelowej Gier Play, które nie zawierają żadnej funkcji, jednoznacznie identyfikować pochodzenie poszczególnych przykładów.

Reguła nr 7: zmień heurystykę w funkcje lub obsługuj je na zewnątrz.

Zwykle problemy, które uczenie maszynowe próbują rozwiązać, Zupełnie nowy. Istnieje system rankingowy lub klasyfikowania, niezależnie od problemu, który próbujesz rozwiązać. Oznacza to, że w internecie do reguł i heurystyki. Te same dane heurystyczne mogą poprawić wyniki podczas optymalizacji, dzięki systemom uczącym się. Twoje dane heurystyczne nie powinny być brane pod uwagę dostępne są informacje z dwóch powodów. Po pierwsze, przejście na komputer będzie działać płynniej. Po drugie, reguły te zwykle zawierają wiele system, którego nie chcesz się pozbyć. Istnieją cztery jak można wykorzystać istniejącą heurystykę:

  • Przetwarzanie wstępne z użyciem heurystyki. Jeśli funkcje są niesamowite, jest taka możliwość. Jeśli na przykład w filtrze spamu nadawca jest już na czarnej liście, nie próbuj od nowa uczyć się, co to jest „czarna lista” Blokuj wiadomość. To podejście najlepiej sprawdza się przy plikach binarnych, zadań klasyfikacji.
  • Utwórz cechę. Bezpośrednie tworzenie funkcji na podstawie heurystyki jest bardzo przydatne. Jeśli np. używasz metody heurystycznej do obliczania wyniku trafności dla zapytania możesz uwzględnić wynik jako wartość cechy. Później którzy mogą chcieć wykorzystać systemy uczące się, aby zmasować wartość (Na przykład konwersja wartości na jeden z skończonych zestawów dyskretnych lub łączenie go z innymi cechami), ale zacznij od użycia nieprzetworzonego generowanej przez heurystykę.
  • Wydobywanie nieprzetworzonych danych wejściowych z heurystyki. Jeśli istnieje kod heurystyczny dla aplikacji , który łączy liczbę instalacji, liczbę znaków w tekst i dzień tygodnia, rozdziel na części i dostarczanie tych danych do systemów uczących się. Niektóre techniki dotyczące zespołów obowiązują tutaj (patrz Reguła 40).
  • Zmodyfikuj etykietę. Ta opcja jest przydatna, gdy uważasz, że algorytm heurystyczny rejestruje informacje, które nie są aktualnie zawarte w etykiecie. Przykład: jeśli chcesz zmaksymalizować liczbę pobrań, ale chcesz też wysokiej jakości, spróbuj pomnożyć etykietę przez średnia liczba gwiazdek przyznanych aplikacji. Istnieje tu wiele swobody. Patrz sekcja „Twój pierwszy cel”.

Podczas korzystania z heurystyki w ML pamiętaj o zwiększonej złożoności systemu. Wykorzystanie starej heurystyki w nowym algorytmie uczenia maszynowego może aby uzyskać płynne przejście, ale zastanów się, czy aby uzyskać taki sam efekt.

Monitorowanie

Ogólnie rzecz biorąc, przestrzegaj zasad higieny alertów, np. traktuj alerty jako praktyczne. i mamy stronę panelu.

Zasada nr 8. Poznaj wymagania systemu w zakresie aktualności.

Jak bardzo wydajność spada, jeśli masz model, który ma od 1 dnia? Tydzień stary? Ćwierć wieku? Te informacje pomogą Ci zrozumieć priorytety monitorowania. Jeśli stracisz znaczną część produktu jakość, jeśli model nie zostanie zaktualizowany jeden dzień, ma sens by inżynier oglądał to bez przerwy. Większość reklam systemów wyświetlania reklam musi codziennie obsługiwać nowe reklamy i musi być w każdym dniu. Jeśli na przykład model ML dla Wyszukiwarka w Google Play nie jest aktualizowana, może mieć w mniej niż miesiąc. Niektóre modele dla „Na topie” Google Plus nie mają w swoim modelu identyfikatora posta, mogą nie będą eksportować tych modeli zbyt często. Inne modele z identyfikatorami postów są znacznie częstsze aktualizowanie. Pamiętaj też, że aktualność może się zmieniać z upływem czasu, zwłaszcza wtedy, gdy kolumny cech 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żna eksportować model. wyświetlania reklam. Jeśli wystąpi problem z wyeksportowanym modelem, model jest widoczny dla użytkowników. Google Cloud.

Przeprowadź kontrolę poprawności tuż przed wyeksportowaniem modelu. Przede wszystkim upewnij się, że wydajność modelu jest rozsądna w przypadku wstrzymywanych danych. Lub, jeśli masz martwiąc się danymi, nie eksportuj modelu. Wiele drużyn nieustannie wdrażane modele sprawdzają obszar pod Krzywa charakterystyki operacyjnej odbiornika (ROC) (lub AUC) przed wyeksportowaniem. W przypadku problemów dotyczących modeli, które nie zostały wyeksportowane, musisz dodać alert e-mail, ale problemy z modelem widocznym dla użytkowników mogą wymagać strony. Lepiej trzeba poczekać i upewnić się, że wpłynie to na użytkowników.

Reguła nr 10: uważaj na dyskretne błędy.

Ten problem występuje częściej w systemach uczących się niż w innych różne typy systemów. Załóżmy, że złączona tabela nie jest nie są już aktualizowane. Systemy uczące się dostosowują się do zmian i zachowują się wciąż będą dobre i stopniowo maleją. Czasem znajdziesz starsze niż miesiąc, a proste odświeżenie zwiększa wydajność. więcej niż jakakolwiek inna usługa w tym kwartale. Zasięg programu funkcja może ulec zmianie z powodu zmian wdrożeniowych, np. w kolumnie funkcji może być wypełniane w 90% przykładów i nagle spada do 60% przykłady. W Google Play tabela była nieaktualna przez 6 miesięcy i odświeżana Dzięki niej współczynnik instalacji wzrósł o 2%. Jeśli śledzisz statystyki i przeglądać dane ręcznie, możesz zmniejszyć tego rodzaju błędy.

Reguła 11. Nadaj kolumnom cech właścicieli i nadaj im dokumentację.

Jeśli system jest duży i jest wiele kolumn cech, dowiedz się, kto utworzył lub utrzymuje każdą kolumnę cech. Jeśli okaże się, że osoba, która rozumie, że kolumna funkcji jest opuszczana, upewnij się, że ktoś ma i informacjami o nich. Chociaż wiele kolumn cech ma nazwy opisowe, dobrze jest bardziej szczegółowy opis cech, miejsca jego pojawienia się oraz jak mogą one pomóc.

Twój pierwszy cel

Masz wiele wskaźników lub pomiarów systemu, na którym Ci zależy, ale algorytm uczenia maszynowego będzie często wymagał jednego celu, liczba, którą algorytm „próbuje” do optymalizacji. Rozróżniam tutaj między celami a wskaźnikami: wskaźnik to dowolna liczba, którą Twój system które mogą nie mieć znaczenia. Zobacz też Reguła 2.

Zasada nr 12: nie zastanawiaj się zbytnio, który cel bezpośrednio zoptymalizować.

Chcesz zarabiać pieniądze, uszczęśliwić użytkowników i zmieniać świat na lepsze miejsce. Masz dużo wskaźników, na których Ci zależy, i musisz mierzyć je wszystkie (zobacz regułę 2). Pamiętaj jednak: na początku procesu uczenia maszynowego zauważycie, że wszystkie rosną w górę, tych, których nie optymalizujesz bezpośrednio. Załóżmy na przykład, że zależy Ci na liczbę kliknięć i czas spędzony w witrynie. Jeśli optymalizujesz kampanię pod kątem liczby kliknięć, wydłużenie czasu oczekiwania na reklamy.

Postaw na prostotę i nie próbuj równoważyć różnych wskaźników. podczas gdy można łatwo zwiększyć wszystkie dane. Nie stosuj tej reguły jednak nie należy mylić swojego celu z ostatecznym stanem zdrowia system (zobacz Reguła 39). A jeśli firma zwiększa bezpośrednio i nie wprowadzać zmian, ale mogą zmienić cel, jest wymagana.

Reguła 13: wybierz proste, obserwowalne i możliwe do przypisania dane dla swojego pierwszego celu.

Często nie wiadomo, jaki jest prawdziwy cel. Uważasz, że tak, ale wtedy, porównasz dane i analizy starego systemu z nowymi systemami uczącymi się, system zauważa, że chcesz dostosować cel. Ponadto inny zespół członkowie często nie mogą dojść do porozumienia w sprawie prawdziwych celów. Celem systemów uczących się które jest łatwe do zmierzenia i stanowi reprezentację wartości „true” (prawda) Często nie ma w nim wartości „prawda” (zobacz Reguła 39). No więc na prostym celu ML i rozważ utworzenie „warstwy zasad” na górze który pozwoli Ci dodać skomplikowane (prawdopodobnie bardzo proste) funkcje logiczne, ostateczny ranking.

Najłatwiejszym modelowaniem jest zachowanie użytkownika, które jest bezpośrednio obserwowane i które można przypisać działanie systemu:

  • Czy ten link rankingowy został kliknięty?
  • Czy ten klasyfikowany obiekt został pobrany?
  • Czy ten obiekt o rankingu został przekazany, otrzymano na niego odpowiedź lub wysłano e-maila?
  • Czy ten oceniony obiekt został oceniony?
  • Czy ten obiekt został oznaczony jako spam, pornografia lub obraźliwy?

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

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

Efekty pośrednie są bardzo przydatne podczas przeprowadzania testów A/B oraz w trakcie wprowadzania na rynek. podejmują decyzje.

Nie próbuj też zmuszać systemów uczących się do ustalenia:

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

Są one ważne, ale jednocześnie niezwykle trudne do zmierzenia. Zamiast tego użyj proxy: jeśli użytkownik jest zadowolony, zostanie na dłużej w witrynie. Jeśli użytkownik jest zadowolony/zadowolona, odwiedzi ją ponownie jutro. Jeśli chodzi o samopoczucie że zdrowie firmy jest zaniepokojone, a każdy, kto chce połączyć, musi przeprowadzić osąd uczenia maszynowego zgodnie z charakterem sprzedawanego produktu swojego biznesplanu.

Reguła 14: rozpoczęcie od interpretowalnego modelu ułatwia debugowanie.

Regresja liniowa, regresja logistyczna i regresja Poissona jest motywowany modelem prawdopodobnym. Każda prognoza można interpretować jako prawdopodobieństwa lub wartości oczekiwanej. Dzięki temu łatwiej jest je debugować niż modele które korzystają z celów (strat zero-jeden, różne straty zawiasów itd.), które próbują bezpośrednio optymalizować dokładność klasyfikacji lub skuteczność w rankingu. Dla: na przykład, jeśli prawdopodobieństwo podczas trenowania odbiega od prawdopodobień przewidywanych w obok siebie lub przez badanie systemu produkcyjnego, to odchylenie może ujawniają problem.

Na przykład przy regresji liniowej, logistycznej czy Poissona istnieją podzbiory dane, dla których średnia prognozowana wartość równa się średniej etykietom (1– moment skalibrowany lub właśnie skalibrowany). To prawda, zakładając, że nie masz i że algorytm się zmodyfikował, oraz wynosi około co ogólnie jest zgodne z prawdą. Jeśli dana cecha ma wartość 1 lub 0 w każdym przykładzie, zbiór 3 przykładów, w których ta funkcja ma wartość 1. Ponadto, jeśli w przypadku funkcji o wartości 1 w każdym przykładzie, to zbiór wszystkich przykładów to skalibrowany.

W przypadku prostych modeli łatwiej jest radzić sobie z pętlami informacji zwrotnych (zobacz Reguła 36). Często przy podejmowaniu decyzji wykorzystujemy te prawdopodobne prognozy, np. pozycja o malejącej oczekiwanej wartości (tj. prawdopodobieństwa kliknięcia, pobrania itp.). Pamiętaj jednak przy wyborze modelu, decyzja ma większe znaczenie niż prawdopodobieństwo danych dla danego modelu (zobacz Reguła 27).

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

Ranking jakości to dobra sztuka, ale filtrowanie spamu to wojna. Sygnały, które wykorzystane do określania wysokiej jakości postów będą oczywiste dla osób, w Twoim systemie, a oni będą dostosować swoje posty, aby uzyskać te właściwości. W związku z tym: w rankingu jakości powinny być brane pod uwagę treści zamieszczane w dobrej wierze. wiara. Nie odrzucaj ucznia, który zajmuje się rankingiem jakości w przypadku spamu w rankingu bardzo. Podobnie treści „dla dorosłych” treści należy traktować niezależnie od jakości Ranking. Filtrowanie spamu to inna historia. Należy spodziewać się, że funkcje, które trzeba wygenerować, będą stale się zmieniać. Często to oczywiste reguły, które należy umieścić w systemie (jeśli post zawiera więcej niż trzy głosy za spam, nie zostaną pobrane itd.). Każdy zapamiętany model ma aktualizowane codziennie, a nawet znacznie szybciej. Reputacja twórcy będą odgrywać świetną rolę.

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

ML Faza II: inżynieria cech

W pierwszej fazie cyklu życia systemu uczącego się ważne jest przekazanie danych szkoleniowych do systemu edukacyjnego, wskaźników i tworzą infrastrukturę obsługującą dane. Po masz sprawny system z testami jednostkowym i systemowym, Zaczyna się faza II.

W drugiej fazie mamy dużo owoców, które łatwo się zawieszają. Dostępne są różne typy treści. dotyczące oczywistych funkcji, które można by wdrożyć do systemu. Dlatego druga opcja To faza systemów uczących się wymaga wykorzystania jak największej liczby funkcji łącząc je w intuicyjny sposób. Na tym etapie wszystkie wskaźniki powinny nadal rośnie. Planujemy wiele nowych funkcji, dlatego to świetny moment, zatrudnienie wielu inżynierów, którzy pomogą połączyć wszystkie dane potrzebne i stworzyć naprawdę wspaniały system nauczania.

Zasada nr 16: zaplanuj uruchomienie i iterację.

Nie oczekuj, że model, nad którym obecnie pracujesz, będzie ostatnim, możliwości wprowadzania na rynek, a nawet tego, że nigdy nie wypuszczasz modeli na rynek. Zatem Zastanów się, czy złożoność, którą dodajesz do tej usługi, spadnie . Wiele zespołów wprowadza model kwartalnie lub więcej lat. Istnieją 3 podstawowe powody wprowadzania nowych modeli na rynek:

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

Tak czy inaczej, obdarowanie modelem może być dobre: przyjrzenie się danym wykorzystanie przykładu może pomóc w znalezieniu nowych, a także starych, niedziałających sygnałów tych. Podczas tworzenia modelu zastanów się, jak łatwo możesz dodawać lub usuwać elementy lub łączyć funkcje. Zastanów się, jak łatwo można utworzyć nową kopię i weryfikacja potoku. Zastanów się, czy jesteśmy w stanie mieć dwie lub trzy kopie działające równolegle. Nie musisz się też martwić o to, czy funkcja 16 z 35 trafia do tej wersji potoku. Zapoznasz się otrzymasz w następnym kwartale.

Reguła 17. Zacznij od bezpośrednio obserwowanych i raportowanych cech, a nie od poznanych cech.

Może to wydawać się kontrowersyjne, ale pozwoli uniknąć wielu pułapek. Pierwszy z opiszmy, czym jest funkcja nauczona. Napotkana cecha jest funkcją generowane przez system zewnętrzny (np. nienadzorowany klaster) przez system) lub przez samego ucznia (np. za pomocą modelu opartego na czynnikach lub deep learning). Obie te metody mogą być przydatne, ale mogą powodować wiele problemów, więc nie mogą być w pierwszym modelu.

Jeśli do utworzenia funkcji użyjesz systemu zewnętrznego, pamiętaj, że zewnętrzny system który ma własny cel. Cel systemu zewnętrznego może być niewielki powiązane z aktualnym celem. Jeśli zrobisz zrzut ekranu zewnętrznego system może stać się nieaktualny. Jeśli zaktualizujesz funkcje to znaczenia mogą się zmienić. Jeśli korzystasz z systemu zewnętrznego do pamiętaj, że takie podejście wymaga dużej uwagi.

Głównym problemem w przypadku modeli opartych na czynnikach i modeli głębokich jest to, że są one niewypukłe. Nie ma więc gwarancji, że optymalne rozwiązanie będzie przybliżone lub znalezione, a minima lokalne przy każdej iteracji mogą być w inny sposób. Ta odmiana utrudnia ocenę wpływu że zmiana systemu jest istotna lub losowa. Tworząc model bez pozwala uzyskać świetną podstawową skuteczność. Po tym możesz zastosować bardziej ezoteryczne podejścia.

Reguła 18: odkrywaj te treści, które są uogólnione w różnych kontekstach.

Systemy uczące się są często niewielkim elementem znacznie pełniejszego obrazu. Dla: Jeśli na przykład wyobrazisz sobie wpis, który może zostać wykorzystany w „Na topie”, wiele osób da +1-ki postowi, udostępni go lub skomentuje, zanim pojawi się on w sekcji Gorące. Jeśli przekażesz te statystyki uczniowi, może on promować nowe posty. że nie ma żadnych danych w kontekście, na którym jest optymalizowana. W sekcji „Warte obejrzenia” w YouTube można wziąć pod uwagę liczbę oglądanych filmów lub obejrzenia (pokazuje, ile razy jeden film został obejrzany po drugim obejrzane) z wyszukiwarki YouTube. Możesz też używać wulgaryzmów ocen użytkowników. Jeśli natomiast masz działanie użytkownika, którego używasz jako etykiety, Pokazanie tego działania w dokumencie w innym kontekście może funkcji. Wszystkie te funkcje pozwalają nadać nowe treściom kontekst. Pamiętaj, że nie chodzi o personalizację: sprawdź, czy użytkownikowi podoba się najpierw treści w tym kontekście, a potem dowiedz się, komu bardziej, a komu mniej.

Reguła 19: używaj konkretnych funkcji, jeśli to możliwe.

Mając do dyspozycji ogromne ilości danych, łatwiej jest poznać miliony prostych funkcji niż o kilka złożonych funkcji. Identyfikatory pobieranych dokumentów Zapytania kanoniczne nie pozwalają ogólnie uogólnić, na podstawie etykiet zapytań nagłówka. Dlatego nie bójcie się grupować funkcji, w których każda z nich ma zastosowanie do niewielkiej części danych, ale wynosi ponad 90%. Możesz użyć regularyzacji, aby wyeliminować funkcji, które mają zastosowanie do zbyt małej liczby przykładów.

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

Obiekty można łączyć i modyfikować na różne sposoby. Systemy uczące się np. TensorFlow, pozwalają wstępnie przetwarzać dane przekształcenia. 2 najbardziej standardowe podejście to „dyskryminacja” i „krzyże”.

Dyskretyzacja obejmuje branie kilku cech i tworzenie wielu związane z nim cechy. Rozważ stosowanie ciągów znaków, takich jak wiek. Dostępne opcje jeśli użytkownik ma mniej niż 18 lat, może utworzyć cechę o wartości 1, 1 w wieku od 18 do 35 lat itd. Nie zastanawiajcie się nad granicami te histogramy: podstawowe kwantyle dają największy efekt.

Krzyże łączą co najmniej 2 kolumny cech. Kolumna cech w TensorFlow terminologia to zbiór jednorodnych cech, np. {male, female}, {US, Kanadzie, Meksyku} itp.). Krzyżyk to nowa kolumna cech z cechami w: np. {mężczyzna, kobieta} × {USA,Kanada, Meksyk}. Ta nowa kolumna funkcji będzie zawierać obiekt (mężczyzna, Kanada). Jeśli używasz TensorFlow i powiedz TensorFlow, żeby stworzył dla Ciebie ten krzyż, ta funkcja (mężczyzna, Kanada) być obecne w przykładach dotyczących mężczyzn Kanadyjczyków. Pamiętaj, że wymaga to ogromnej ilości danych do uczenia modeli z krzyżami 3, 4 lub większej liczby podstawy kolumn cech.

Krzyże, które tworzą bardzo duże kolumny cech, mogą być nadmierne. Przykład: Wyobraź sobie, że prowadzisz wyszukiwanie z kolumną cech ze słowami w zapytaniu i mamy kolumnę funkcji ze słowami w dokument. Możesz połączyć je z krzyżem, ale uzyskasz wiele funkcji (zobacz regułę 21).

W przypadku pracy z tekstem masz dwie możliwości. Najbardziej drakowska to iloczyn skalarny. Iloczyn skalarny w najprostszej postaci liczy po prostu liczbę słowa występujące w zapytaniu i dokumencie. Tę funkcję można następnie dyskryminacji. Innym podejściem jest przecięcie się: mamy więc cechę który jest obecny tylko wtedy, gdy słowo „kukurydze” znajduje się zarówno w dokumencie, jak i w sekcji oraz innej funkcji, która występuje tylko wtedy, gdy słowo „the” jest w zarówno dokument, jak i zapytanie.

Reguła 21. Liczba wag cech, których można uzyskać w modelu liniowym, jest mniej więcej proporcjonalna do ilości danych.

Fascynujące wyniki teorii uczenia statystycznego dotyczą odpowiedni poziom złożoności modelu, ale ta reguła obejmuje musisz wiedzieć. Niektóre z moich rozmów były wątpliwe, czego można się dowiedzieć z tysiąca przykładów, czy też że kiedykolwiek potrzebują ponad miliona przykładów, ponieważ utwierdzą w określonej metodzie systemów uczących się. Najważniejsze jest, aby dostosować swoją wiedzę do ilości posiadanych danych:

  1. Jeśli pracujecie nad systemem rankingowym i na świecie różnych słów w dokumentach i zapytaniu. Masz 1000 przykładów oznaczonych etykietami, użyj iloczynu skalarnego między dokumentami i funkcje zapytań TF-IDF, i kilka innych wysoce ludzkich funkcje zabezpieczeń. 1000 przykładów, tuzin funkcji.
  2. Jeśli masz milion przykładów, uwzględnij w części wspólnej dokument i zapytanie kolumn cech przy użyciu regularyzacji i ewentualnego wyboru cech. Zapewni to dostęp do milionów funkcji, ale przy regularnym będzie mieć ich mniej. Dziesięć milionów, może nawet sto tysięcy funkcji.
  3. Jeśli masz miliardy albo setki miliardów przykładów, możesz kolumny cech z tokenami dokumentów i zapytań, korzystając z wyboru funkcji i regularyzacji. Będziesz mieć miliard przykładów oraz 10 milionów funkcje zabezpieczeń. Teoria uczenia statystycznego rzadko daje precyzyjne granice, to dobry punkt wyjścia.

Podsumowując, użyj funkcji Reguła 28 aby decydować, których funkcji użyć.

Reguła 22: usuń funkcje, których już nie używasz.

Niewykorzystane funkcje powodują dług technologiczny. Jeśli okaże się, że nie używasz tagu i że połączenie jej z innymi funkcjami nie działa, z infrastruktury. Jeśli chcesz, żeby Twoja infrastruktura była czysta, że warto wypróbować jak najszybciej najbardziej obiecujące funkcje. Jeśli jest konieczne, każdy może zawsze dodać go z powrotem.

Weź pod uwagę informacje o tym, które funkcje dodać lub zachować. Ile ? Jeśli na przykład masz jakieś funkcji personalizacji, ale tylko 8% użytkowników korzysta z personalizacji nie będzie zbyt efektywna.

Jednocześnie niektóre funkcje mogą działać powyżej swojej wagi. Na przykład, jeśli masz cechę, która obejmuje tylko 1% danych, ale 90% przykładów w których jest pozytywna, to będzie wspaniała cecha, którą warto dodać.

Analiza układu przez człowieka

Przed przejściem do trzeciego fazy systemów uczących się ważne jest, skup się na czymś, czego nie jest nauczone na żadnych zajęciach z systemów uczących się: jak sprawdzić istniejący model i go ulepszyć. To coś więcej niż sztuka naukowych, ale istnieje kilka antywzorców, których można użyć.

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

To chyba najprostszy sposób, aby zespół się uwięził. Chociaż istnieje testy wewnętrzne przynoszą wiele korzyści (dzięki prototypowi w zespole), testy wewnętrzne (za pomocą prototypu wewnątrz firmy), pracownicy powinni sprawdzić czy skuteczność jest poprawna. Choć zmiana, która jest niewątpliwie zła, nie powinna być używana, wszystko, co wydaje się dość bliskie produkcji, powinno zostać dalej badać sprawę, płacąc laikom za odpowiadanie na pytania na platformie crowdsourcingowej lub eksperymentowaniu na żywo z udziałem prawdziwych użytkowników.

Dzieje się tak z 2 powodów. Po pierwsze, jesteście za blisko w kodzie. Być może zależy Ci na konkretnym aspekcie postów lub po prostu zbyt emocjonalnie zaangażowanych (np. stronniczości potwierdzenia). Po drugie, Twój czas jest zbyt cenny. Weź pod uwagę koszt dziewięciu inżynierów siedzących w jednym miejscu godzinne spotkanie i zastanów się, ile osób kupuje produkty platformie crowdsourcingowej.

Jeśli naprawdę chcesz poznać opinie użytkowników, korzystaj z interfejsu użytkownika . Utwórz profile użytkowników (jeden opis znajduje się w Sketching User Experiences) są na wczesnym etapie rozwoju i testują łatwość obsługi Opis pochodzi od Steve'a Kruga nie każ mi myśleć) później. Profile klientów polega na utworzeniu hipotetycznego użytkownika. Jeśli na przykład w zespole są mężczyźni, Warto stworzyć profil 35-letniej użytkowniczki funkcji) i spójrz na generowane przez nie wyniki, a nie 10 Mężczyźni w wieku 25–40 lat. Zachęcanie ludzi do oglądania ich reakcji (lokalnie lub zdalnie) w ramach testów łatwości obsługi może Ci też pomóc z perspektywy człowieka.

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

Jedne z najprostszych i czasem najbardziej użytecznych pomiarów, jakie można zrobić przed którzy oglądali Twój nowy model, jest obliczenie, jak bardzo różni się wyniki pochodzą z produkcji. Na przykład, jeśli masz problem z rankingiem, w obu modelach na próbce zapytań w całym systemie i sprawdzić wielkość różnicy symetrycznej wyników (ważona według rankingu pozycję). Jeśli różnica jest bardzo mała, można stwierdzić, kiedy nie działa. w eksperymencie, że niewiele się zmieni. Jeśli różnica jest bardzo duże, musisz mieć pewność, że zmiana jest na pewno prawidłowa. Analizuję zapytania, w których różnica symetryczna jest duża, może pomóc zrozumieć jakościowego charakteru zmian. Upewnij się jednak, że system stabilną. Upewnij się, że model w porównaniu ze sobą ma niski poziom (najlepiej 0) różnicy symetrycznej.

Reguła 25: gdy wybierasz modele, skuteczność przewidywana jest ważniejsza niż skuteczność prognozowana.

Model może próbować przewidzieć współczynnik klikalności. Ostatecznie jednak kluczowy jest pytanie, co zrobi z tą podpowiedź. Jeśli używasz go do określania pozycji w rankingu, dokumentów, jakość ostatecznego rankingu ma większe znaczenie niż do samej prognozy. Jeśli przewidujesz prawdopodobieństwo, że dokument jest spamem, oraz odcięcie tego, co jest zablokowane, precyzja tego, co jest dozwolone mają większe znaczenie. W większości przypadków te 2 rzeczy powinny być a gdy się nie zgadzają, prawdopodobnie będzie to niewielki zysk. Dlatego, jeśli następuje zmiana, która zwiększa straty logów, ale spowalnia wydajność należy poszukać innej funkcji. Jeśli stawki będą się powtarzać, czas ponownie przyjrzeć się celowi modelu.

Reguła 26. Poszukaj wzorców w mierzonych błędach i utwórz nowe funkcje.

Załóżmy, że widzisz przykład trenowania, w którym model poinformował, że model jest „nieprawidłowy”. W zadania klasyfikacji, ten błąd może być wynikiem fałszywie pozytywnych lub fałszywie negatywnych. W zadaniu rankingowym błędem może być para, w której pozytywna miała niższą pozycję niż ujemny. Najważniejsze jest to, że jest to przykład, jeśli system uczący się wie, że wystąpił błędny błąd i chciałby go naprawić, możliwość. Jeśli przyznasz modelowi cechę, która pozwala naprawić błąd, model będzie próbował go użyć.

Z drugiej strony, jeśli spróbujesz utworzyć cechę na podstawie przykładów, system nie wykryje błędów jako błędów, zostanie zignorowana. Przykład: Załóżmy, że w wyszukiwarce aplikacji Google Play ktoś wyszukuje hasło „gry bezpłatne”. Załóżmy, że Jeden z pierwszych wyników to mniej trafna aplikacja do gagów. Tworzysz więc cechę dla „gag aplikacji”. Jeśli jednak zależy Ci na maksymalnej liczbie instalacji, instalują aplikację gagów, która szuka bezpłatnych gier. cecha nie przyniosą pożądanego efektu.

Jeśli masz już przykłady, na których model się pomylił, poszukaj trendów, które które wykraczają poza aktualny zestaw funkcji. Jeśli na przykład system wydaje się Obniżając pozycję długich postów, a następnie wydłużając czas ich trwania. Nie przesadzaj ze szczegółami dodane funkcje. Jeśli chcesz dodać długość posta, nie próbuj zgadywać, co Wystarczy dodać kilkanaście cech, a model sam określi, co ma robić (zobacz Reguła 21 ). To najprostszy sposób, aby osiągnąć to, czego szukasz.

Reguła 27. Postaraj się określić zaobserwowane niepożądane zachowania.

Niektórzy członkowie Twojego zespołu zaczną być sfrustrowani właściwościami, w którym użytkownicy nie są zadowoleni, a które nie są rejestrowane przez obecną funkcję utraty danych. Na w tym momencie powinni zrobić wszystko, co będzie w stanie zmienić liczby. Na przykład, jeśli uważa, że zbyt wiele „aplikacji do gagi” są wyświetlane w wyszukiwarce Google Play, mogą poprosić weryfikatorów o rozpoznawanie aplikacji do gagów. (Możesz użyjemy danych oznaczonych przez człowieka w tym przypadku, ponieważ części zapytań odpowiada za dużą część ruchu). Jeśli są wymierne, można więc zacząć ich używać jako funkcji, celów lub danych. Ogólna zasada to „najpierw pomiar, potem optymalizacja”.

Zasada 28. Pamiętaj, że identyczne zachowanie w krótkim okresie nie oznacza jednakowego zachowania w dłuższej perspektywie.

Załóżmy, że mamy nowy system, który sprawdza każdy identyfikator dokumentu i dokładne zapytanie a następnie oblicza prawdopodobieństwo kliknięcia dla każdego dokumentu dla każdego zapytania. Okazuje się, że jego działanie jest niemal identyczne z obecnym systemem w obu i testów A/B, więc ze względu na jego prostotę warto je uruchomić. Zauważasz jednak, że nie wyświetlają się żadne nowe aplikacje. Dlaczego? Skoro system wyświetla tylko dokument na podstawie własnej historii dla danego zapytania, nie ma aby dowiedzieć się, że powinien być wyświetlany nowy dokument.

Jedynym sposobem na zrozumienie, jak taki system będzie działał w dłuższej perspektywie, jest zapoznanie się i trenuje tylko na danych pozyskanych, gdy model był aktywny. To bardzo trudne.

Zniekształcenie między trenowaniem a obsługą

Zniekształcenia między trenowaniem a zastosowaniem to różnica między wydajnością podczas trenowania podczas wyświetlania reklam. Przyczyny tej zniekształcenia mogą być następujące:

  • Rozbieżności między sposobem obsługi danych w potokach trenowania i potoków udostępniania.
  • Zmiana w danych między rozpoczęciem trenowania a wyświetlaniem reklam.
  • Pętla informacji zwrotnych między modelem a algorytmem.

Zaobserwowaliśmy w Google systemy produkcyjne systemów uczących się odchylenie wyświetlania, które negatywnie wpływa na skuteczność. Najlepszym rozwiązaniem jest jawnie je monitorować, aby zmiany w systemie i danych nie powodowały ich zniekształcenia. nie zauważono.

Zasada nr 29. Najlepszym sposobem na uczenie się tak, jakby trenujesz, jest zapisanie zestawu funkcji używanych podczas udostępniania, a potem zanotowanie ich w dzienniku, aby można było z nich korzystać podczas trenowania.

Nawet jeśli nie da się tak zrobić w każdym przykładzie, rób to dla niewielkiego ułamka, można sprawdzić spójność między udostępnianiem a trenowaniem (patrz Reguła 37). Zespoły, które to zrobiły wyniki pomiarów w Google były czasami zaskakujące. Strona główna YouTube przełączono na funkcje logowania w momencie udostępniania o znaczącej jakości i redukcją złożoności kodu, a wiele zespołów na ich infrastrukturze.

Reguła 30. Próbkowane dane o wadze znaczenia – nie porzucaj ich bez ograniczeń.

Gdy danych jest za dużo, łatwo się skłonić do pobrania plików 1–12, ignoruj pliki 13–99. To jest błąd. Chociaż dane, które były mogą zostać pominięte, wagi ważności są najlepsze dla odpoczynek. Znaczenie ważności oznacza, że jeśli zdecydujesz się z przykładu X z prawdopodobieństwem 30%, a następnie przypisz mu wagę 10/3. Z wagi znaczenia, wszystkie właściwości kalibracji omówione Reguła 14 i nie musisz przerywać działania.

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

Załóżmy, że dołączasz identyfikatory dokumentów za pomocą tabeli zawierającej funkcje tych dokumentów (na przykład liczby komentarzy lub kliknięć). Pomiędzy czasem trenowania a czasem obsługi funkcje w tabela może ulec zmianie. Prognoza modelu dotycząca tego samego dokumentu może różnią się między trenowaniem a wyświetlaniem. Najprostszy sposób, aby tego uniknąć problemem jest rejestrowanie funkcji w czasie udostępniania (patrz Reguła 32 ). Jeśli tabela to zmienia się tylko powoli, możesz też tworzyć zrzuty tabeli co godzinę lub codziennie, aby uzyskać rozsądnie zbliżone do siebie dane. Pamiętaj, że to nie rozwiąże problemu Google Cloud.

Reguła 32. W miarę możliwości stosuj kod pomiędzy potokiem trenowania a potokiem obsługi.

Przetwarzanie wsadowe różni się od przetwarzania online. Podczas przetwarzania online musisz przetwarzać każde otrzymane żądanie (np. przeprowadzić osobne wyszukiwanie) dla każdego zapytania), natomiast podczas przetwarzania wsadowego możesz łączyć zadania (np. złączenie). W momencie wyświetlenia trwa przetwarzanie online, a jest zadaniem przetwarzania wsadowego. Istnieją jednak pewne kwestie, co można zrobić, aby ponownie wykorzystać kod. Możesz na przykład utworzyć obiekt, który w konkretnym systemie, gdzie wyniki zapytań lub złączeń mogą w czytelny dla człowieka sposób, a błędy można łatwo przetestować. Następnie: po zebraniu wszystkich informacji podczas udostępniania lub trenowania użyj popularnej metody mostu między zrozumiałym dla człowieka obiektem, który jest w Twoim systemie oraz format systemu uczącego się których oczekuje. Eliminuje to źródło zniekształcenia między trenowaniem a zastosowaniem. Jako pamiętaj, by nie używać 2 różnych języków programowania i wyświetlanie reklam. W takiej sytuacji nie będziesz mieć możliwości podzielenia się w kodzie.

Reguła 33. Jeśli tworzysz model na podstawie danych do 5 stycznia, przetestuj go na danych od 6 stycznia i później.

Ogólnie rzecz biorąc, mierz wydajność modelu na podstawie danych zebranych po danych na których trenowano model, ponieważ lepiej odzwierciedla to działanie systemu produkcji. Jeśli do 5 stycznia utworzysz model na podstawie danych, przetestuj go na podstawie danych z 6 stycznia. Przewidujemy, że skuteczność nie będzie już tak skuteczna w przypadku nowych danych, ale nie będzie już radykalnie gorsza. Ponieważ mogą wystąpić dzienne efekty, możesz nie przewidywać średniej liczby kliknięć współczynnika konwersji lub współczynnika konwersji, ale tylko obszar pod krzywą, który reprezentuje prawdopodobieństwo przyznania przykładowi pozytywnego wyniku lepszego niż ujemnego powinny być w rozsądnym stopniu zbliżone.

Reguła nr 34: w klasyfikacji binarnej i filtrowaniu (np. w przypadku wykrywania spamu lub wykrywania interesujących e-maili) warto pogarszać efektywność działania bardzo czystych danych w krótkim okresie.

W zadaniu filtrowania przykłady oznaczone jako negatywne nie są wyświetlane użytkownika. Załóżmy, że masz filtr, który blokuje 75% przykładów negatywnych podczas wyświetlania. Może Cię kusić, aby wyciągnąć dodatkowe dane treningowe z instancji wyświetlanych użytkownikom. Jeśli na przykład użytkownik oznaczy e-maila jako spam, przez filtr, może warto wyciągnąć wnioski.

Takie podejście powoduje jednak dyskryminację próbkowania. Bardziej przejrzyste dane możesz zamiast tego oznaczyć 1% całego ruchu jako „wstrzymany” i wysłać cały i wyświetla użytkownikom przykłady. Teraz Twój filtr blokuje co najmniej 74% negatywnych przykładów. Te wstrzymane przykłady mogą stać się danymi treningowymi.

Pamiętaj, że jeśli filtr blokuje co najmniej 95% przykładów negatywnych, staje się mniej opłacalne. Jeśli jednak chcesz mierzyć liczbę wyświetleń można uzyskać bardziej subtelną próbkę (np. 0,1% lub 0,001%). Dziesięć tysięcy przykładów to wystarczająco dużo, aby można było dokładnie oszacować skuteczność.

Reguła 35. Uważaj na nieodłączne odchylenie problemów z rankingiem.

Gdy radykalnie zmienisz algorytm rankingowy na tyle radykalnie, że wyniki oznacza to, że udało Ci się zmienić dane, których będzie używać Twój algorytm które poznamy w przyszłości. Takie zniekształcenia będą widoczne, więc należy zaprojektować wokół niego. Jest wiele różnych metod. Te metody są wszystkie sposoby na faworyzowanie danych, które dany model już widział.

  1. Stosuj większą regularność funkcji, które obejmują więcej zapytań niż te funkcje, które są włączone tylko dla jednego zapytania. Dzięki temu model będzie faworyzować funkcji właściwych dla jednego lub kilku zapytań, a nie funkcji, które uogólniać na wszystkie zapytania. Takie podejście pomoże zapobiegać pojawianiu się przed wyciekiem do nietrafnych zapytań. Zwróć uwagę, że jest to funkcja odwrotna do bardziej konwencjonalnej porady o większym regularyzowaniu kolumn cech. które mają bardziej unikalne wartości.
  2. Zezwalaj tylko na cechy z wagą dodatnią. Dlatego każda dobra funkcja jest lepszy niż cecha, która jest „nieznana”.
  3. nie mają funkcji obejmujących tylko dokumenty. To ekstremalna wersja 1. Dla: nawet jeśli dana aplikacja jest popularna, niezależnie od tego, wyszukiwane hasło, nie chcesz wyświetlać go wszędzie. Brak dostępu tylko do dokumentów To bardzo proste. Powody, dla których nie chcesz wyświetlać określonej jest tak ważna dla użytkowników, dzięki czemu wszystkie niezbędne aplikacje są osiągalne. Jeśli na przykład ktoś szuka hasła aplikacji do obserwowania ptaków, mogą pobrać aplikację do obserwacji ptaków, to było dla nich zrozumiałe. Wyświetlanie takiej aplikacji może zwiększyć szybkość pobierania, ale potrzeby użytkownika.

Zasada 36. Unikaj pętli informacji zwrotnych z funkcjami pozycjonowania.

Pozycja treści w znacznym stopniu wpływa na prawdopodobieństwo interakcji użytkownika z nim. Jeśli umieścisz aplikację na pierwszej pozycji, będzie ona klikana częściej, i przekonasz się, że użytkownicy częściej ją klikają. Jednym ze sposobów radzenia sobie z jest dodanie cech pozycjonowania, tj. cech dotyczących położenia treści na stronie. Wytrenujesz model przy użyciu cech pozycjonujących, nauczy się wagi, np. cecha „pierwsza pozycja” bardzo często. Twój model w ten sposób przypisuje mniejszą wagę innym czynnikom dla przykładów z wartością „1stposition=true”. Podczas wyświetlania nie nadajesz żadnym instancjom właściwości pozycjonowania lub określasz, do nich wszystkich tych samych funkcji domyślnych, ponieważ najpierw oceniasz kandydatów decydują o kolejności ich wyświetlania.

Należy pamiętać, że właściwości pozycjonujące muszą być nieco oddzielone reszty modelu z powodu tej asymetrii między trenowaniem a testowaniem. Model musi stanowić sumę funkcji cech pozycjonujących i jest idealna dla pozostałych cech. Na przykład: cech pozycjonowania z dowolną cechą dokumentu.

Reguła 37: pomiar zniekształcenia trenowania/odchylenia obsługi.

Zniekształcenia w najbardziej ogólnym sensie mogą powodować kilka czynników. Możesz go też podzielić na kilka części:

  • Różnica między wydajnością danych treningowych a czasem wstrzymania i skalowalnych danych. Ogólnie rzecz biorąc, taka sytuacja będzie obowiązywać przez cały czas i nie zawsze jest źle.
  • Różnica między skutecznością danych z okresu wstrzymania i okresu następnego dnia i skalowalnych danych. Tak jak zawsze będzie w życiu. Należy dostosować regularyzację do i zmaksymalizować skuteczność następnego dnia. Jednak znaczny spadek skuteczności między wstrzymaniem a danymi z następnego dnia może wskazywać, że niektóre funkcje wrażliwe na upływ czasu i może pogorszyć wydajność modelu.
  • Różnica między skutecznością następnego dnia i transmisja na żywo i skalowalnych danych. Jeśli zastosujesz model do przykładu w danych treningowych i w taki sam sposób podczas wyświetlania, powinien dać dokładnie taki sam wynik (patrz Reguła 5 ). Tak więc tutaj rozbieżność wskazuje prawdopodobnie na błąd inżynieryjny.

Faza III ML: spowolniony wzrost, precyzowanie optymalizacji i modele złożone

Zdarzają się pewne sygnały wskazujące na to, że druga faza zbliża się do końca. Przede wszystkim Twoje miesięczne zyski zaczną spadać. Zaczniesz mieć kompromisów między wskaźnikami: niektóre będą rosnąć, a inne spadną. eksperymentów. To właśnie robi się ciekawie. Ponieważ zysk jest trudniejszy uczenie maszynowe musi stać się bardziej zaawansowane. Uwaga: zawiera więcej reguł dotyczących niebieskiego nieba niż we wcześniejszych sekcjach. Wiemy, że wiele zespołów Pomyśl o szczęśliwych czasach systemów uczących się faz I i II. Jedna faza Cel III został osiągnięty, zespoły muszą znaleźć własną ścieżkę.

Zasada nr 38: nie marnuj czasu na nowe funkcje, jeśli problem stają się niedopasowanymi celami.

W miarę upływu czasu Twój zespół zacznie analizować problemy, poza zakresem celów obecnego systemu uczącego się. Jako co zostało wspomniane wcześniej, jeśli cele produktowe nie są uwzględnione w istniejącym algorytmie musisz zmienić cel lub cele produktowe. Dla: możesz np. optymalizować kliknięcia, liczbę plus jedynek lub liczbę pobrań, decyzji częściowo na podstawie weryfikatorów.

Reguła 39. Decyzje o wprowadzeniu na rynek służą do realizacji długoterminowych celów związanych z produktem.

Alicja chce ograniczyć logistyczne straty związane z przewidywaniem instalacji. Ona dodaje cechę. Straty logistyczne spadają. Po przeprowadzeniu eksperymentu na żywo odnotowuje wzrost liczby instalacji. Gdy jednak robi przegląd premiery, ktoś zauważa, że liczba aktywnych użytkowników dziennie spada o 5%. Zespół postanawia nie uruchamiać modelu. Alicja jest rozczarowana, ale teraz zdaje sobie sprawę, że decyzje o wprowadzeniu produktu zależą od wielu kryteriów, z których tylko niektóre można optymalizować bezpośrednio za pomocą systemów uczących się.

Prawda jest taka, że prawdziwy świat nie jest lochem ani smokami: nie ma punkty" aby określić stan swojego produktu. Zespół musi użyć zbierane statystyki, aby można było skutecznie przewidywać, jak dobry będzie w przyszłości. Klient chce zadbać o zaangażowanie; liczba użytkowników aktywnych w ciągu 1 dnia, 30 Liczba aktywnych użytkowników dziennie, przychody i zwrot z inwestycji reklamodawcy. Te dane, które są mierzalne w testach A/B są w sobie miarodajne, jeśli chodzi o bardziej długoterminowe Cele: zadowolenie użytkowników, zwiększanie liczby użytkowników, satysfakcjonowanie partnerów i zysk, dla których można używać serwerów proxy, ponieważ mogą one i rozwijającą się firmę za pięć lat.

Jedyną prostą decyzją związaną z wprowadzeniem produktu na rynek jest sytuacja, w której wszystkie wskaźniki stają się lepsze (lub przynajmniej nie pogarsza się). Jeśli zespół ma wybór między zaawansowanym urządzeniem algorytm uczenia się i prostą heurystykę, jeśli prosta heurystyka w przypadku tych wszystkich wskaźników, powinien wybrać heurystykę. Ponadto nie jest jednoznaczny ranking wszystkich możliwych wartości danych. W szczególności weź pod uwagę w tych 2 scenariuszach:

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

Jeśli obecny system to A, raczej nie uda się zmienić systemu na B. Jeśli obecny system to B, zespół raczej nie przełączy się na system A. Ten wydaje się kolidować z racjonalnym postępowaniem; jednak prognozy zmian dane mogą się przesunąć, ale nie, więc niesie ze sobą duże ryzyko jedną z tych zmian. Każdy wskaźnik obejmuje ryzyko, którego dotyczy problem.

Poza tym żadne dane nie odzwierciedlają głównego problemu zespołu: „Gdzie jest mój produkt? za pięć lat”.

Z drugiej strony jednostki preferują jeden cel: bezpośrednio optymalizować. Większość narzędzi do uczenia maszynowego preferuje takie środowisko. An podczas wdrażania nowych funkcji mogą mieć stały dostęp do nowych funkcji, dla środowiska. Można powiedzieć, że mamy do czynienia z systemami uczącymi się, uczeniem wielocelowym, który rozwiązuje problem. Można na przykład sformułować problem ze satysfakcją ograniczenia, który ma dolne granice dla każdego wskaźnika; optymalizuje niektóre linearne kombinacje danych. Jednak nawet wtedy nie wszystkie danych można z łatwością przedstawić jako cele systemów uczących się. Jeśli dokument lub użytkownik zainstalował aplikację – oznacza to, że treść została wyświetlona. Ale znacznie trudniej jest ustalić, dlaczego dany użytkownik odwiedza Twoją witrynę. Jak przewidzieć sukces całej witryny jest Sztuczna inteligencja: tak trudny jak komputer rozpoznawania obrazu i przetwarzania języka naturalnego.

Zasada nr 40: stosuj proste stroje.

Ujednolicone modele, które przyjmują nieprzetworzone funkcje i bezpośrednio oceniają treści, najłatwiejsze do debugowania i zrozumienia. Grupa modeli ( „model” który łączy wyniki innych modeli) może działać lepiej. Aby zachować To proste. Każdy model powinien być komponentem, który przyjmuje tylko dane z innymi modelami lub model podstawowy z wieloma funkcjami, ale nie jednym i drugim. Jeśli na innych modelach trenowanych osobno, a potem łącząc je może powodować niewłaściwe działanie.

Do łączenia elementów użyj prostego modelu, który uwzględnia tylko dane wyjściowe „podstawowej” bazy. jako dane wejściowe. Chcesz też wyegzekwować właściwości w tych zespolonych modelach. Na przykład wzrost wyniku generowanego przez model podstawowy nie powinien obniżyć wynik zespołu. Najlepiej też, jeśli modele przychodzące są interpretowalny semantycznie (np. skalibrowany), tak aby zmiany podstawowe modele nie wprowadzają w błąd. Wymuś też wzrost przewidywanego prawdopodobieństwa bazowego klasyfikatora nie zwiększa zmniejszają przewidywane prawdopodobieństwo grupy.

Reguła 41: w przypadku spadku skuteczności szukaj nowych, jakościowo nowych źródeł informacji, zamiast doskonalić istniejące sygnały.

Dodałeś dane demograficzne dotyczące użytkownika. Dodałeś kilka miejsc informacje o słowach znajdujących się w dokumencie. Udało Ci się przejrzeć szablon i dostosowaliśmy regularyzację. Nowe funkcje w aplikacji niż w ciągu kilku kwartałów. Co dalej?

Nadszedł czas, by zacząć budować infrastrukturę do radykalnie odmiennej takie jak historia dokumentów, do których użytkownik otworzył ostatniego dnia, tygodnia lub roku albo dane z innej usługi. Używaj wikidata podmiotów lub podmiotów wewnętrznych firmy (np. Graf wiedzy). Użyj precyzyjnych danych systemów uczących się. Zacznij dostosowywać swoje oczekiwania co do wysokości zwrotu spodziewaj się inwestycji i odpowiednio rozszerz swoje wysiłki. Jak w każdym projektu inżynieryjnego, należy rozważyć korzyści płynące z dodania nowych funkcji z kosztem większej złożoności.

Zasada 42: nie oczekuj, że różnorodność, personalizacja i trafność treści nie będą miały takiego związku z popularnością, jak Ci się wydaje.

Różnorodność materiałów może oznaczać wiele rzeczy, których źródłem treści jest najczęściej. Personalizacja oznacza użytkownik uzyskuje własne wyniki. Trafność oznacza, że wyniki dla danego wyszukiwanie jest bardziej odpowiednie niż inne. Dlatego wszystkie 3 z właściwości te są zdefiniowane jako różniące się od zwykłych.

Problem w tym, że przeciętność jest trudna do pokonania.

Pamiętaj, że jeśli Twój system mierzy kliknięcia, spędzony czas, obejrzane filmy, +1-ki, udostępnień dalej itd., mierzysz popularność treści. Zespoły spróbuje nauczyć się własnego modelu przez różnorodność. Aby spersonalizować, dodają które umożliwiłyby personalizację systemu (niektóre funkcje reprezentujące zainteresowania użytkownika) lub ich zróżnicowania (funkcje wskazujące, czy dokument zawiera jakiekolwiek cechy wspólne ze zwracanymi dokumentami, takie jak autor lub treść), i przekonać się, że te cechy przybierają mniejszą wagę (lub mogą mieć inne cechy). niż się spodziewają.

Nie oznacza to jednak, że różnorodność, personalizacja ani trafność nie są cenne. Jak wspomnieliśmy w poprzedniej regule, możesz przeprowadzić obróbkę, aby zwiększyć czy ich różnorodność czy trafność. Jeśli zauważysz wzrost celów długoterminowych, możesz deklarują, że różnorodność/trafność jest cenna, niezależnie od popularności. Dostępne opcje kontynuuj obróbkę lub bezpośrednio zmodyfikuj w oparciu o różnorodność lub trafność.

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

Zespoły w Google bardzo się pochwaliły modelem przewidywania między jednym a drugim produktem, a w drugiej – dobrze. Twoi znajomi to, kim są. Z drugiej strony widziałem kilka drużyn, mają problemy z funkcjami personalizacji w różnych usługach. Wydaje się, że tak tak jak powinno. W tej chwili tak nie działa. Co się czasami dzieje funkcja ta wykorzystuje nieprzetworzone dane z jednej usługi do prognozowania zachowań w innej. Oprócz tego: pamiętaj, że nawet informacja o tym, że użytkownik ma historię w innej usłudze, pomocy. Na przykład aktywność użytkownika w dwóch usługach może być samo wskazówkę.

Istnieje wiele dokumentów dotyczących systemów uczących się zarówno w Google, jak i poza platformą.

Podziękowania

Dzięki Davidowi Westbrookowi, Peterowi Brandtowi, Samuelowi Ieong, Chenyu Zhao, Li Wei, Michalis Potamias, Evan Rosen, Barry Rosenberg, Christine Robson, James Pine, Tal Shaked, Tushar Chandra, Mustafa Ispir, Jeremiah Harmsen, Konstantinos Katsiapis, Glen Anderson, Dan Duckworth, Shishir Birmiwal, Gal Elidan, Su Lin Wu, Jaihui Liu, Fernando Pereira i Hrishikesh Aradhye. sugestie i przydatne przykłady w tym dokumencie. Oprócz tego dzięki Kristen Lefevre, Suddha Basu i Chris Berg, którzy pomagali przy poprzedniej wersji. Dowolne błędy, pominięcia lub (zaskakujące!) niepopularne opinie.

Dodatek

W tym dokumencie można znaleźć wiele odniesień do usług Google. Do podam krótki opis najczęstszych przykładów, poniżej.

YouTube – omówienie

YouTube to serwis streamingowy. YouTube „Warte obejrzenia” i strona główna YouTube Zespoły stron używają modeli ML do ustalania pozycji rekomendacji filmów. Polecamy „Warte obejrzenia” do obejrzenia po aktualnie odtwarzanym filmie, a na stronie głównej polecamy użytkownikom przeglądającym stronę główną.

Omówienie Google Play

Google Play ma wiele modeli rozwiązujących różne problemy. Wyszukiwarka Play, Google Play Zastosowanie spersonalizowanych rekomendacji na stronie głównej i aplikacji „Użytkownicy, którzy też zainstalowali” systemów uczących się.

Omówienie Google Plus

Google Plus wykorzystuje systemy uczące się w różnych sytuacjach: ranking postów w kategorii „strumień” liczby postów wyświetlanych przez użytkownika, ranking „Na topie” posty (posty) które obecnie są bardzo popularne), ranking osób, które znasz itp., Google+ w 2019 roku zamknęliśmy wszystkie konta osobiste i zastąpiliśmy je Google Currents. dla kont firmowych 6 lipca 2020 r.