Wir haben nach Möglichkeiten gesucht, Rohdaten geeigneten Featurevektoren zuzuordnen, aber das ist nur ein Teil der Arbeit. Jetzt müssen wir uns ansehen, welche Arten von Werten tatsächlich gute Merkmale in diesen Featurevektoren darstellen.
Selten verwendete Featurewerte vermeiden
Gute Featurewerte sollten in einem Datensatz etwa fünfmal vorkommen.
Auf diese Weise kann ein Modell lernen, wie dieser Featurewert mit dem Label zusammenhängt.
Wenn also viele Beispiele mit demselben diskreten Wert vorliegen, kann das Modell das Feature in verschiedenen Einstellungen sehen und so bestimmen, wann es ein guter Prädiktor für das Label ist. Beispielsweise würde ein house_type-Feature wahrscheinlich viele Beispiele mit dem Wert victorian enthalten:
✔This is a good example:house_type: victorian
Wenn der Wert eines Features jedoch nur einmal oder sehr selten angezeigt wird, kann das Modell keine Vorhersagen auf der Grundlage dieses Features treffen. unique_house_id ist beispielsweise ein schlechtes Feature, da jeder Wert nur einmal verwendet werden würde. Das Modell konnte also nichts daraus lernen:
The following is an example of a unique value. This should be avoided.✘unique_house_id: 8SK982ZZ1242Z
Klare und offensichtliche Bedeutungen bevorzugen
Jede Funktion sollte für alle am Projekt beteiligten Personen eine klare und offensichtliche Bedeutung haben. Beispielsweise ist das folgende gute Feature klar benannt und der Wert kann in Bezug auf den Namen sinnvoll sein:
✔The meaning of the following value is clear from the label and value.house_age_years: 27
Umgekehrt ist die Bedeutung des folgenden Featurewerts für niemanden außer dem Entwickler, der ihn erstellt hat, verständlich:
✘The following is an example of a value that is unclear. This should be avoidedhouse_age: 851472000
In einigen Fällen führen verrauschte Daten (anstatt falscher Entwicklungsentscheidungen) zu unklaren Werten. Die folgenden user_age_years stammen beispielsweise aus einer Quelle, die nicht auf geeignete Werte geprüft hat:
✘The following is an example of noisy/bad data. This should be avoided.user_age_years: 277
Vermischen Sie „magische“ Werte nicht mit tatsächlichen Daten
Gute Gleitkomma-Features enthalten keine ungewöhnlichen Abweichungen außerhalb des Bereichs oder magische Werte. Angenommen, ein Feature hat einen Gleitkommawert zwischen 0 und 1. Werte wie die folgenden sind also in Ordnung:
✔The following is a good example:quality_rating: 0.82 quality_rating: 0.37
Wenn ein Nutzer jedoch keinen quality_rating-Wert eingegeben hat, hat das Dataset sein Fehlen möglicherweise mit einem magischen Wert wie dem folgenden dargestellt:
✘The following is an example of a magic value. This should be avoided.quality_rating: -1
Wenn Sie magische Werte explizit kennzeichnen möchten, erstellen Sie ein boolesches Feature, das angibt, ob ein quality_rating angegeben wurde oder nicht. Geben Sie diesem booleschen Feature einen Namen wie is_quality_rating_defined.
Ersetzen Sie in der ursprünglichen Funktion die magischen Werte so:
- Fügen Sie für Variablen, die einen endlichen Satz von Werten (diskrete Variablen) annehmen, einen neuen Wert hinzu und verwenden Sie ihn, um anzuzeigen, dass der Merkmalswert fehlt.
- Achten Sie bei kontinuierlichen Variablen darauf, dass fehlende Werte sich nicht auf das Modell auswirken. Verwenden Sie dazu den Mittelwert der Featuredaten.
Instabilität vorgelagert
Die Definition eines Elements sollte sich im Laufe der Zeit nicht ändern. Der folgende Wert ist beispielsweise nützlich, da sich der Name der Stadt wahrscheinlich nicht ändert. (Beachten Sie, dass wir eine Zeichenfolge wie "br/sao_paulo" trotzdem in einen One-Hot-Vektor umwandeln müssen.)
✔This is a good example:city_id: "br/sao_paulo"
Das Erfassen eines Werts, der von einem anderen Modell abgeleitet wird, ist jedoch mit zusätzlichen Kosten verbunden. Vielleicht stellt der Wert „219“ derzeit São Paulo dar, aber diese Darstellung könnte sich bei einer zukünftigen Ausführung des anderen Modells leicht ändern:
✘The following is an example of a value that could change. This should be avoided.inferred_city_cluster: "219"