Opracowaliśmy sposoby mapowania nieprzetworzonych danych na odpowiednie wektory cech, ale to jeszcze nie wszystko. Musimy teraz ustalić, jakie rodzaje wartości przyczyniają się do realizowania dobrych cech w obrębie tych wektorów cech.
Unikaj rzadko używanych wartości cech dyskretnych
Dobre wartości cech powinny występować w zbiorze danych co najmniej 5 razy.
Dzięki temu model może nauczyć się, w jaki sposób ta wartość cechy odnosi się do etykiety.
Oznacza to, że posiadanie wielu przykładów z tą samą wartością dyskretną daje modelowi szansę na zobaczenie cechy w różnych ustawieniach i w zamian ustalenie, kiedy jest to dobra prognoza dla etykiety. Na przykład cecha house_type prawdopodobnie zawiera wiele przykładów, w których jej wartość wynosiła victorian:
✔This is a good example:house_type: victorian
Jeśli wartość cechy pojawia się tylko raz lub bardzo rzadko, model nie może wygenerować prognoz na podstawie tej cechy. Na przykład unique_house_id jest złą funkcją, ponieważ każda wartość zostałaby użyta tylko raz, więc model nie mógłby się od niej niczego nauczyć:
The following is an example of a unique value. This should be avoided.✘unique_house_id: 8SK982ZZ1242Z
Wolę jasne i jednoznaczne znaczenie
Każda cecha powinna mieć jasne i zrozumiałe znaczenie dla wszystkich osób w projekcie. Na przykład ta dobra cecha ma jasną nazwę, a jej wartość odzwierciedla sens w odniesieniu do niej:
✔The meaning of the following value is clear from the label and value.house_age_years: 27
I na odwrót: dla nikogo innego poza inżynierem, który ją utworzył, nie da się rozszyfrować znaczenia tych wartości:
✘The following is an example of a value that is unclear. This should be avoidedhouse_age: 851472000
W niektórych przypadkach zaszumiane dane (zamiast niewłaściwej konfiguracji) powodują niejasne wartości. Na przykład wartość user_age_years pochodzi ze źródła, które nie sprawdzało odpowiednich wartości:
✘The following is an example of noisy/bad data. This should be avoided.user_age_years: 277
Nie łącz wartości „magicznych” z rzeczywistymi danymi.
Dobre obiekty zmiennoprzecinkowe nie mają nietypowych nieciągłości poza zakresem ani wartości „magicznych”. Załóżmy np., że cecha ma wartość zmiennoprzecinkową od 0 do 1. Zatem następujące wartości:
✔The following is a good example:quality_rating: 0.82 quality_rating: 0.37
Jeśli jednak użytkownik nie wpisał quality_rating, być może zbiór danych reprezentuje jego brak za pomocą magicznej wartości podobnej do tej:
✘The following is an example of a magic value. This should be avoided.quality_rating: -1
Aby wyraźnie oznaczyć wartości magiczne, utwórz funkcję logiczną, która wskazuje, czy podano quality_rating. Nadaj tej funkcji wartości logicznej nazwę np. is_quality_rating_defined.
W pierwotnej funkcji zastąp wartości magiczne w ten sposób:
- W przypadku zmiennych, które mają ograniczony zestaw wartości (zmiennych dyskretnych), dodaj do zbioru nową wartość i użyj jej do sygnalizowania braku wartości cechy.
- W przypadku zmiennych ciągłych upewnij się, że brakujące wartości nie wpływają na model, używając wartości średniej danych cechy.
Uwzględnij niestabilność wysyłania
Definicja cech nie powinna się z czasem zmieniać. Przydatna jest np. ta wartość, ponieważ prawdopodobnie nazwa miasta się nie zmieni. (Zauważ, że nadal musimy przekonwertować ciąg taki jak „br/sao_paulo” na wektor jedno-gorący).
✔This is a good example:city_id: "br/sao_paulo"
Zbieranie wartości wywnioskowanej przez inny model wiąże się jednak z dodatkowymi kosztami. Być może wartość „219” oznacza obecnie São Paulo, ale łatwo można ją zmienić w przyszłości w drugim modelu:
✘The following is an example of a value that could change. This should be avoided.inferred_city_cluster: "219"