Voitot:
- Kyky tunnistaa tietovuotojen tyypit (tavoite, aika, esikäsittely, ryhmitelty rivi) ja kysyä "liian hyvää ollakseen totta" -pisteet hälytyksenä
- Kyky estää vuodot erottamalla testisarja, putkisto ja oikea jako (kronologinen/ryhmitelty) ajoissa
- Kyky tehdä analyysistä toistettavissa kiinteillä siemenillä, version hallinnassa ja manuaalisten vaiheiden poistamisella
On kaksi virhettä, jotka hukkaavat eniten vaivaa datatieteessä, ja ne ovat molemmat salakavalia, koska ne johtavat katastrofiin juuri silloin, kun kaikki "näyttää olevan kunnossa". Ensimmäinen on tietovuoto: malli toimii hyvin testisarjassa, mutta kaatuu tuotannossa. Toinen on uusittamattomuus: suoritat analyysin kuusi kuukautta myöhemmin ja saat täysin erilaisen tuloksen. Tämä yksikkö on omistettu näiden kahden sudenkuopan syvälliseen tuntemiseen ja välttämiseen. Tekoäly voi lisätä molempia riskejä (tuottaa nopeasti, ehdottaa piilotettuja vuotoja, helpottaa manuaalisten vaiheiden suorittamista), mutta voi myös vähentää niitä, jos niitä käytetään oikein. Ero on kurissa.
Tietovuoto: selvänäkijämalli
Tietovuoto on, kun malli näkee harjoittelun aikana tietoa, jota sillä ei ole todellisen ennusteen aikaan. Malli "huijaa" näillä tiedoilla, näyttää hyvältä testisarjassa, mutta kaatuu tuotannossa ilman näitä tietoja. Vuodon oire on lähes aina sama: liian hyvää ollakseen totta. Ennen kuin iloitset, kun näet 99 % tarkkuuden, sinun tulee etsiä vuotoja.
Tärkeimmät vuototyypit ovat:
1. Maalivuoto: Ominaisuus on tulosta maalista. "Peruutettiin"-ennusteessa "peruutuspäivä"- tai "hyvityssumma"-sarakkeet ovat tavoitteen tulosta. Ne täytetään vasta, kun tulos on selvä.
2. Aikavuoto: Tulevaisuuden tiedon tuominen menneisyyteen. Kun lasket "viimeisen 30 päivän keskiarvoa", ota mukaan ennustepäivän jälkeiset päivät tai jaa aikasarja satunnaisesti.
3. Esikäsittelyvuoto: Muutosten, kuten skaalaus, täyttö ja koodaus, oppiminen kaikista tiedoista ennen koulutus-/testausosiota. Testitietojen keskiarvon laskeminen häiritsee harjoittelua.
4. Päällekkäinen/ryhmitelty rivivuoto: Samalle henkilölle kuuluvia rivejä esiintyy sekä koulutuksessa että testauksessa (saman potilaan kaksi käyntiä eri sarjoissa). Malli muistaa henkilön ulkoa.
Vuototyyppi
Miten syntyy
Kuinka ehkäistä
kohdevuoto
Sarake, joka on kohteen tulos
"Onko minulla se ennustushetkellä" -testi
aikavuoto
Tulevaisuuden tuominen menneisyyteen
Kronologinen jako, ikkunanhallinta
Esikäsittelyvuoto
Esijaettu muunnos
Putki, istuu juuri harjoituksesta
Ryhmitetty rivivuoto
Sama yksikkö kahdessa sarjassa
Jaa ryhmän mukaan (GroupKFold)
Ainoa kurinalaisuus vuotojen estämiseksi
Yleinen ratkaisu kaikentyyppisille vuodoille tiivistyy yhteen lauseeseen: Eristä testisarja mahdollisimman aikaisin matkimaan todellista tulevaisuutta, äläkä "opeta" sille mitään. Käytännössä tämä tarkoittaa: ensin jakaa, sitten oppia kaikki muunnokset vain koulutuksesta ja soveltaa niitä liukuhihnassa (rakenne, joka kerää kaikki vaiheet yhteen ketjuun). Esitä kunkin ominaisuuden kohdalla kysymys "onko minulla nämä tiedot ennusteen aikaan?" Jos aikaa on, jaa se kronologisesti; Jos sama yksikkö toistuu, jaa ryhmiin.
Varoitus: Vuodon vaarallisin puoli on, että se esiintyy onnistuneena. Huono malli tuottaa luonnollisesti huonoja tuloksia ja se huomataan; Vuotanut malli toimii loistavasti, miellyttää kaikkia, ja se otetaan tuotantoon – siitä romahdus alkaa. Siksi "erittäin hyvä" tulos on hälytyksen, ei juhlan aihe.
Toistettavuus: sama tulos kahdesti
Toistettavuus on kykyä saada sama tulos, kun suoritat analyysin uudelleen toisella kerralla, toisella koneella. Ilman tätä analyysisi on satunnainen, ei tieteellinen. Tärkeimmät syyt ja ratkaisut, jotka heikentävät toistettavuutta:
Manuaaliset vaiheet: Solun muuttaminen manuaalisesti Excelissä, kaavion manuaalinen muokkaaminen. Ratkaisu: sisällytä jokainen vaihe koodiin.
Kiinnittämätön satunnaisuus: Mallin koulutus, näytteenotto, jakaminen sisältävät satunnaisuutta. Ratkaisu: korjaa satunnainen siemen (satunnaisgeneraattorin alkuarvo) (random_state=42).
Versio muuttuu: Tulos voi muuttua, kun kirjaston versio muuttuu. Ratkaisu: korjaa riippuvuudet (requirements.txt, ympäristötiedosto).
Ei kirjaamista: Ei ole selvää, mitä tietoja, mitä koodia, mitä parametria käytettiin. Ratkaisu: versionhallinta (Git - järjestelmä, joka tallentaa kaikki koodin versiot) ja tietojen versiointi.
"Se toimii vain minun koneellani": Ratkaisu: dokumentoi ympäristö, käytä säiliöitä (Docker), jos mahdollista.
kolme minilaukkua
Tapaus 1 – Kohdevuoto. Terveysanalyysissä oli "kotikirjauksen jälkeinen lääkitys" -sarake, joka ennakoi "otetaanko potilas uudelleen hoitoon". Tämä kolonni täytettiin vasta potilaan kotiutumisen jälkeen. Malli antoi 96 %, tuotannossa 61 %. 8 viikon projekti oli roskaa. Oppitunti: kysy jokaiselta ominaisuudesta "onko se olemassa ennustushetkellä?"
Tapaus 2 – Esikäsittelyvuoto. Yksi tiimi skaalasi kaikki tiedot ja jakoi sen sitten. Testitietojen keskiarvo oli mukana skaalautuksessa. CV-pisteet 89%, todellinen tuotanto 76%. Valemenestys katosi, kun muutin Pipelineen ja opin muutoksista vasta harjoittelusta. Oppitunti: jaa ensin, muunna myöhemmin.
Tapaus 3 – Toistamisen epäonnistuminen. Eräs analyytikko halusi päivittää johdolle esittämänsä kaavion kolme kuukautta myöhemmin, mutta ei muistanut, kuinka hän sen tuotti; monet vaiheet tehtiin manuaalisesti Excelissä. Tulos ei toiminut ja luottamus horjui. Oppitunti: ei manuaalisia vaiheita, kaikki on koodissa ja Gitissä.
Neljä kopioitavaa mallia
1) Vuototarkastus:
Tehtäväsi: vuotojen tarkastaja. Kohde: "churn" (0/1), ennusteen viitepäivämäärä: Record_date. Annan sinulle tämän luettelon ominaisuuksista. JOKAINEN ominaisuus: (a) onko se seurausta tavoitteesta, (b) onko se käytettävissäni ennustushetkellä, (c) sisältääkö aikaikkuna tulevaisuuden? Merkitse se "vaarallinen/epäilyttävä/vuoto" ja kirjoita syy. Ominaisuudet: [lista]
2) Vuotamaton putkisto:
Määritä sklearn-putki: jaa ensin juna/testi (kerrostettu, siemen = 42), sovita sitten kaikki esikäsittely (impuutti, skaalaa, koodaus) VAIN koulutuksen prosessiin. Selitä, miksi koodi on vuotamaton, mikä vaihe opittiin missä.
3) Uusittavuuden tarkistuslistan koodi:
Haluan tehdä analyysistäni toistettavan. Ehdota koodia/rakennetta, joka lisää: (1) kova siemen kaikelle sattumanvaraisuudelle, (2) käytettyjen kirjastoversioiden tulostus, (3) datan ja tulosteen päivämäärä/versiotunniste. Anna minulle myös tarkistuslista varmistaaksesi, ettei manuaalisia vaiheita ole.
4) Ryhmitetty osio (sama yksikkövuoto):
Tiedoissa sama customer_id on useilla riveillä. Tee jako (GroupKFold taiGroupShuffleSplit, group = customer_id), joka ESTÄÄ samaa asiakasta olemasta sekä koulutuksessa että testauksessa. Sisällytä koodi varmistaaksesi, ettei asiakkaita ole molemmissa sarjoissa jakamisen jälkeen.
Heikko kehote / Vahva kehote
Heikko kehote:
Mallini palautti 98 % tarkkuuden, eikö olekin hienoa? Optimoi koodi.
98 %:n juhliminen piilottaa vuodon. Ennen optimointia tulee kyseenalaistaa, onko tämä pistemäärä todellinen vai ei.
Tehokas kehotus:
Tehtäväsi: vuotojen tarkastaja. Mallini palauttaa 98 %:n tarkkuuden testisarjassa, mikä kuulostaa minusta "liian hyvältä ollakseen totta". Tarkista: (1) ovatko ominaisuudet seurausta tavoitteesta, (2) ovatko muunnokset tehty ennen jakamista, (3) ovatko sama yksikkö kahdessa joukossa, (4) onko aikavuotoja. Listaa kaikki epäilyttävät kohdat; Keskity vuodon etsimiseen, älä pisteytyksen korjaamiseen.
Tässä korkeaa pistemäärää käsitellään merkkinä kyseenalaistaa, ei juhlimisena.
Yleisiä virheitä
- Juhlitaan "erittäin hyvää" tulosta. Liian hyvä ollakseen totta -tulos on vuotovaroitus, ei saavutus.
- Muunnoksen oppiminen kaikista tiedoista ennen jakamista. Yleisin vuoto; Jaa ensin putkijohdolla.
- Aikasarjan jakaminen satunnaisesti. Malli näkee tulevaisuuden; Kronologinen jako on pakollinen.
- Jätetään sama yksikkö kahdessa sarjassa. Malli muistaa henkilön; Jaa ryhmiin.
- Ei astu käsin ja kirjoita koodiin. Analyysi muuttuu toistamattomaksi; kaiken pitäisi olla koodissa ja Gitissä.
Vinkki: Kirjoita projektisi alkuun kaksilauseinen "kunnialupaus": "En ole koskenut testisarjaan millään tavalla ennen kuin näen sen tuotannossa. Jokainen vaihe on koodissa ja siemen on korjattu." Jos et voi allekirjoittaa näitä kahta lausetta rehellisesti, tuloksesi ei ole vielä luotettava.
Yhteenvetona
Tietovuoto ja uusittamattomuus ovat kaksi kalleinta hiljaista virhettä datatieteessä. Vuoto on mallin näkemys tulevaisuudesta ja esiintyy vääränä menestyksenä; Ratkaisu on jakaa testijoukko aikaisin, oppia muunnokset vain harjoittelusta (pipeline), kysyä jokaiselle ominaisuudelle kysymys "Onko minulla se ennustushetkellä" ja tehdä oikea jako (kronologinen/ryhmitelty). Toistettavuus on sitä, että saadaan sama tulos kahdesti; hänen ratkaisunsa on poistaa portaat manuaalisesti, kiinnittää siemen, jäädyttää versiot ja säilyttää kaiken Gitissä. Tekoäly voi joko lisätä tai vähentää näitä riskejä; Kurinpitosi ratkaisee.
Sovellustehtävä
Ota rakentamasi mallin (tai hypoteettisen) ominaisuusluettelo ja kysy jokaiselle ominaisuudelle kysymys "onko minulla nämä tiedot ennustehetkellä?" kirjallisesti; Etsi ainakin yksi vuotoehdokas. Täytä sitten tarkistuslista, jotta analyysisi voidaan toistaa: onko siemen korjattu, onko manuaalisia vaiheita, ovatko versiot rekisteröity, ovatko ne Gitissä. Korjaa puutteet.
tarkistuslista
- [ ] Kysyinkö "liian hyvää ollakseen totta" -pistemäärää vuotovaroituksena?
- [ ] Opinko kaikki muutokset splitin jälkeen, vain harjoittelusta?
- [ ] Olenko jakanut aika-/ryhmärakenteen mukaan (kronologinen/GroupKFold)?
- [ ] Olenko tehnyt kaiken satunnaisuuden toistettavaksi kiinteällä siemenellä?
- [ ] Poistinko manuaaliset vaiheet ja pidin kaiken koodin ja versionhallinnassa?