Päästä päähän -integraatio, MLOps ja insinöörin vastuu

Voitot:

• Kyky suunnitella tekoälyllä tuettu autoprojekti konseptista tuotantoon ja ylläpitää sitä seurantasyklillä
• Kyky arvioida malliversioiden hallintaa, tiedon siirtymistä ja uudelleenkoulutustarpeita
• Kyky skaalata tekoälyä turvallisesti säilyttäen samalla vastuullisuuden, jäljitettävyyden ja dokumentoinnin koko projektin ajan

Tämän moduulin viimeisessä osassa kokoamme kaikki osat yhteen. Olemme nähneet, kuinka tekoälyä käytetään yksittäisissä yksiköissä suunnittelusta tuotantoon, testauksesta toimitusketjuun. Mutta todellisessa projektissa nämä eivät ole yksittäisiä vaiheita, vaan elinkaari: dataa kerätään, malli rakennetaan, se pannaan tuotantoon, sitä seurataan ja kun se vanhenee, se uusitaan. Tämän syklin ylläpitoa kutsutaan MLOpsiksi (Machine Learning Operations). Tämä yksikkö kattaa tekoälyllä toimivan autoprojektin perustamisen, ylläpidon ja vastuullisuuden ylläpitämisen alusta loppuun.

Tekoälyprojektin elinkaari

Tyypillinen päästä päähän -kulku autoteollisuudessa:

1. Ongelman ja arvon määrittely: Mitä liiketoimintaongelmaa ratkaisemme? Miten menestystä mitataan? Onko tämä turvallisuuskriittinen toiminto?
2. Tiedonkeruu ja merkitseminen: Lähteet (CAN, testaus, tuotanto, telematiikka), laatu, luottamuksellisuus.
3. Mallin kehittäminen: Attribuutti, malli, todentaminen (vuotojen hallinta, yksikön konsistenssi).
4. Todentaminen ja turvallisuusarviointi: Riippumaton testaus, jos vaaditaan ISO 26262/SOTIF.
5. Käyttöönotto: Mallin käyttöönotto laitteistossa, verkossa tai pilvessä.
6. Valvonta: Suorituskyky, tiedon siirtyminen, hälytyksen tarkkuus.
7. Uudelleenkoulutus: Mallin päivittäminen, kun se vanhenee.
8. Dokumentointi ja jäljitettävyys: Kirjaa jokainen vaihe; kuka, milloin, miksi.

Tämä sykli ei lopu lopullisesti; pyörii jatkuvasti. Autoteollisuudessa on vaarallista "asettaa ja unohtaa" malli.

Vinkki: Projektia käynnistettäessä "kuka tarkkailee tätä mallia, kun se on kentällä, millä mittarilla ja kuinka usein?" Jos et osaa vastata kysymykseen, malli ei ole vielä valmis tuotantoon.

Mallin versionhallinta ja jäljitettävyys

Jäljitettävyys autoteollisuudessa ei ole luksusta, vaan usein lakisääteinen velvoite. Kun ongelma ilmenee, sinun pitäisi pystyä vastaamaan kysymykseen "mikä malliversio, millä tiedoilla se on koulutettu, kuka sen hyväksyi?" Hyvät käytännöt:

• Mallin versiointi: Jokaisen mallin numero, harjoitustiedot ja päivämäärä tallennetaan.
• Tietojen versiointi: Tiedot, joihin se opetettiin, on jäädytetty.
• Päätösloki: Kuka antoi hyväksynnän ja millä todisteilla.
• Palautussuunnitelma: Jos uusi malli osoittautuu huonoksi, voit palata vanhaan.

kohde

Miksi se on tarpeen

Riski, jos puuttuu

Mallin versio

Mikä versio on kentällä?

Ongelmaa ei voida jäljittää

Datan versio

Millä hän oli koulutettu?

ei toistettavissa

Hyväksyntätietue

Kuka on vastuussa?

ei voida saattaa vastuuseen

kumoa

Paluu huonosta versiosta

Pitkä seisokki kentällä

Tietojen ajautuminen ja mallin rappeutuminen

Malli on tilannekuva maailmasta, jossa se on koulutettu. Mutta maailma muuttuu: uusi osatoimittaja tuo erilaisen anturitoleranssin, uusi ajoneuvomalli tulee ulos, vuodenajat vaihtuvat, ajotavat muuttuvat. Mallin suorituskyky heikkenee hiljaa, kun syöttötietojen jakauma siirtyy pois harjoitusajasta. Tätä tiedon ajautumista ja siitä johtuvaa suorituskyvyn heikkenemistä kutsutaan mallin heikkenemiseksi.

Vaarana on, että tämä lasku on hiljainen: malli ei romahda, ei tee virheitä, se vain menee pieleen. Siksi:

• Valvo tulon jakautumista (ryömintätunnistus).
• Tarkkaile suorituskykymittareita todellisilla tuloksilla (ovatko hälytykset tarkkoja?).
• Käynnistä uudelleenkoulutus, kun kynnys ylittyy.

Varoitus: Oletus, että "kun malli on koulutettu, se antaa saman suorituskyvyn ikuisesti" on väärä ja riskialtis autoteollisuudessa. Ilman ryömintävalvontaa tuotantoon otettu malli voi tietämättään tulla epäluotettavaksi.

Päästä päähän -esimerkkiskenaario: ennakoiva huoltokalusto

Tehdään siitä konkretia. Olet asentamassa turbovian varhaisvaroitusjärjestelmää rahtilaivastolle:

1. Arvo: Vähennä seisokkeja ja hinauskustannuksia; onnistuminen = todellinen vian/väärän hälytyksen saldo tallennettu.
2. Tiedot: 40 ajoneuvon CAN-signaalit, historialliset vikatiedot; VIN on anonymisoitu.
3. Malli: Anomalia + RUL; aikasarjavuoto estetty; Epävarmuusalue on esitetty.
4. Varmentaminen: Aiempien vikojen jälkitestaus; Väärän hälytyksen hinta punnittiin.
5. Tuotanto: Päivittäiset pisteet pilvessä; paneeli teknikolle.
6. Valvonta: Drift-hallinta, kun uusi ajoneuvomalli lisätään; hälytystarkkuus viikoittain.
7. Uudelleenkoulutus: Neljännesvuosittainen päivitys uudella ajoneuvotyypillä ja uusilla vikaesimerkeillä.
8. Dokumentaatio: Malliversio, dataversio, sertifioiva insinööri rekisteröity.

Mikään askel tässä virtauksessa ei sano "AI päättänyt, tehty"; Henkilö on vastuussa jokaisesta vaiheesta.

Pienet tapaustutkimukset

Tapaus 1 - Hiljainen rappeutuminen. Laadunvalvontamalli toimii hyvin yhden vuoden, jonka jälkeen vuotoaste kasvaa hitaasti. Perimmäinen syy: Toimittajan vaihtuessa osan pintarakenne muuttui hieman erilaiseksi (drift), ja malli alkoi pitää tätä "normaalina". Poikkeaman valvonta perustetaan ja malli koulutetaan uudelleen. Tulos: Ilman valvontaa haavoittuvuus olisi jäänyt huomaamatta kuukausia.

Tapaus 2 - Jäljitettävyys tallennettu. Kentältä tulee väärä hälytysvalitus. Päätöslokista tiimi selvittää, mikä malliversio toimii minkäkin tiedon kanssa; Se havaitsee, että ongelma johtuu tietyn version kynnysasetuksesta, ja palauttaa kyseisen version. Tulos: Jos versiota ja päätöstietuetta ei ollut, ongelmaa ei voitu jäljittää.

Tapaus 3 - Uudelleenkoulutuskuri. Kun uusi sähköinen malli liittyy laivastoon, olemassa oleva ennakoiva huoltomalli herättää paljon vääriä hälytyksiä tähän ajoneuvoon (voimansiirto, jota se ei ole koskaan nähnyt). Ennen uuden mallin käyttöönottoa tiimi tallentaa drift-varoituksen ja laajentaa mallia uusilla ajoneuvotiedoilla. Tulos: Drift-seuranta havaitsi varhain uuden tuotteen mukana tulleen huonontumisen.

kehotemalleja

Malli 1 – hankesuunnitelmaluonnos:

Rooli: AI-projektin johtaja (autoteollisuus).Tehtävä: Auta minua suunnittelemaan tekoälyllä toimiva projekti päästä päähän.Konteksti: Ennakoiva huolto; 40 ajoneuvon kalusto; VIN on anonyymi. Rajoitus: Harkitse arvon määrittelyn, datan, mallin, todentamisen, tuotannon, valvonnan, uudelleenkoulutuksen ja dokumentoinnin vaiheita erikseen; ilmoittaa, kuka on vastuussa kustakin vaiheesta.Tuloste: Vaihe | tuotos | vastuullinen | riskitaulukko.

Malli 2 - Valvontasuunnitelma:

Rooli: Olet MLOps-insinööri. Tehtävä: Suosittele seurantasuunnitelmaa kentällä olevalle mallille. Konteksti: Syötteiden jakautuminen voi muuttua ajan myötä (uusi toimittaja, uusi työkalu); suorituskykyä voidaan mitata todellisilla tuloksilla.Tuloste: Seurattava metriikka | kynnys | käynnistettävä toimenpide.

Malli 3 – Drift-luokitus:

Rooli: Datatieteilijä. Tehtävä: Selitä kuinka havaita tietojen ajautuminen ja milloin uudelleenkoulutusta tarvitaan. Konteksti: Tuotantolinjan visuaalisen tarkastuksen malli; Toimittaja saattaa vaihtua. Lähtö: Signaali | mittaus | uudelleenkoulutuksen laukaisin.

Malli 4 – Jäljitettävyyden tarkistuslista:

Rooli: Olet laadun/vaatimustenmukaisuuden tarkastaja. Tehtävä: Luo mallille jäljitettävyyden tarkistuslista. Konteksti: Autoteollisuus; Ongelman ilmetessä tulee vastata kysymykseen "mikä versio, mitkä tiedot, kuka sen on hyväksynyt".Tuloste: Tuote | miksi se on tarpeen | kuinka tallentaa kaavio.

Heikko kehote / Vahva kehote

Heikko kehote:

Laita malli tuotantoon.

Ei seurantaa, ei versiointia, ei tilivelvollisuutta eikä palautuksia; Hiljainen rappeutuminen ja jäljittämättömät ongelmat ovat väistämättömiä.

Tehokas kehotus:

Rooli: Olet MLOps- ja autoteollisuuden laatukonsultti. Tehtävä: Luo tarkistuslista, jonka tarvitsen ottaakseni mallin vastuullisesti tuotantoon. Konteksti: Ennakoiva huoltokalusto; Uusia ajoneuvotyyppejä lisätään ajan myötä; VIN anonymous.Constraint: Sisällytä seuranta, ajautuman havaitseminen, version/datan kirjaaminen, vahvistus ja palautussuunnitelma; Ilmoita, kuka on vastuussa kustakin kohteesta; "aseta ja unohda" -ehdotus.Tuloste: Vaihe | välttämättömyys | vastuullinen | riskitaulukko.

Yleisiä virheitä

• "Aseta se ja unohda se" -lähestymistapa. Ilman valvontaa malli hajoaa hiljaa.
• Ei pidä versio-/tietorekisteriä. Ongelmaa ei voida jäljittää tai toistaa.
• Ei palautussuunnitelmaa. Jos toipuminen huonosta julkaisusta kestää pitkään, kentällä tulee pitkä vika.
• Ei odoteta Driftiä. Uusi toimittaja/työkalu/kausi häiritsee mallia; seuranta on välttämätöntä.
• Vastuun jättäminen epäselväksi. Vastauksen "kuka on vastuussa" pitäisi olla selkeä joka vaiheessa.

Yhteenvetona

• Tekoälyllä toimiva autoteollisuusprojekti ei ole kertaluonteinen vaan jatkuva elinkaari (MLOps).
• Mallien ja tietojen versiointi, päätösten kirjaaminen ja palautuksen suunnittelu ovat välttämättömiä jäljitettävyyden kannalta.
• Tietojen ajautuminen kumoaa mallin hiljaa; panosta ja suorituskykyä tulee seurata ja kouluttaa uudelleen tarvittaessa.
• Päästä päähän -esimerkissä jokaisella askeleella on vastuuhenkilö; Ei ole "AI päättänyt, se on ohi".
• "Aseta ja unohda" on riskialtista autoteollisuudessa; seurantaa, dokumentointia ja vastuullisuutta ylläpidetään koko hankkeen ajan.

Sovellustehtävä

Yhdistä tässä moduulissa oppimasi yhdeksi projektiksi (esim. tuotantolinjan silmämääräinen tarkastus tai ennakoiva huolto). (1) Laadi päästä päähän -projektisuunnitelma mallin 1 avulla; Kirjoita ylös jokaisesta vaiheesta vastuussa oleva henkilö. (2) Määrittele seurantasuunnitelma ja ajelehtimia mallin 2 avulla. (3) Valmistele jäljitettävyyden tarkistuslista mallin 4 avulla. (4) Tee yhteenveto kappaleessa, kuinka käytit kolmea ankkurointialaa moduulin alusta tähän projektiin.

tarkistuslista

• [ ] Suunnittelin projektin päästä päähän -elinkaariksi.
• [ ] Määrittelin päätöstietueen malli- ja dataversioinnilla.
• [ ] Asetin seurantasuunnitelman ja drift-laukaisimet.
• [ ] Tein palautussuunnitelman.
• [ ] Olen selventänyt, kuka on vastuussa kustakin vaiheesta.
• [ ] Ylläpidin kolmea ankkurivalidointia ja ihmisturvallisuuden kannalta kriittistä validointia.

Moduulin tentti

1. Mikä on tekoälyn rooli autojen turvallisuuskriittisissä päätöksissä (esim. jarruohjelmiston todentaminen)?

• A) Nopeuttaa analysointia, mutta lopullinen hyväksyntä ja vastuu jää pätevälle insinöörille ✔
• B) Jos dataa on riittävästi, se voidaan ottaa tuotantoon ilman insinöörin hyväksyntää
• C) Tekoälyä ei voida käyttää missään vaiheessa kriittisissä järjestelmissä, kuten jarruissa
• D) Jos mallin tarkkuus ylittää 99 %, ihmisen todentaminen on tarpeetonta

Kuvaus: Tekoäly nopeuttaa analysointia, luo ehdokasratkaisuja ja yhteenvetoja; Turvallisuuskriittinen päätös ja lopullinen hyväksyntä ovat kuitenkin pätevän insinöörin vastuulla. Tekoäly ei korvaa insinöörin validointia.

2. Mitkä ovat kolme riippumatonta tarkistusta, joita käytetään tekoälyn tulosten testaamiseen kolmella ankkurivalidointialalla?

• A) Kehotteen pituus, kieli ja muoto
• B) Todisteet suuruusluokasta, teknisestä järkevyydestä ja riippumattomasta testauksesta/mittauksesta ✔
• C) Mallin koko, harjoitusaika ja GPU:iden määrä
• D) Toimittajan merkki, hinta ja toimitusaika

Kuvaus: Kolme ankkuria; suuruusluokka (järjestyksen tarkistus), tekninen uskottavuus (fysiikka/kokemus) ja ristiinvalidointi riippumattomien testi-/mittaustodistusten kanssa. Nämä kolme luovat luottamusta todisteisiin, eivät luota tekoälyyn.

3. Mikä on kriittisin varmennus CFD- tai FEA-simulaatiota nopeuttavan "korvikemallin" tulokselle?

• A) Korvausmalli on aina tarkempi kuin todellinen ratkaisija
• B) Riittää, kun renderöinti näyttää esteettisesti miellyttävältä
• C) Vertailu referenssiratkaisuun ja epäluotettavuuden hyväksyminen harjoitustilan ulkopuolella liikkuessa ✔
• D) Verkon riippumattomuutta ei tarvitse tarkastella, jos yksi ajo konvergoi

Kuvaus: Korvausmalli tuottaa nopeita ennusteita todellisen ratkaisijan sijaan; mutta se on epäluotettava sen suunnittelutilan ulkopuolella, jossa se on koulutettu. Tulos tulee varmistaa merkitsemällä ekstrapolointialue referenssihigh-fidelity-simulaatiolla ja fyysisillä rajaehdoilla.

4. Mikä on oikea lauseke tasolle 2 (osittainen automaatio) SAE-automaatiotasoilla?

• A) Ajoneuvo voi ajaa ilman kuljettajaa kaikissa olosuhteissa
• B) Järjestelmä ei suorita ajotehtäviä, antaa vain varoituksia
• C) Ei haittaa, jos hän ei istu kuljettajan istuimella
• D) Järjestelmä tukee ohjausta ja nopeutta, mutta kuljettaja säilyttää jatkuvan valvonnan ja vastuun ✔

Kuvaus: Tasolla 2 järjestelmä tukee ohjausta ja nopeutta/etäisyyttä samanaikaisesti, mutta kuljettaja säilyttää jatkuvan valvonnan ja on valmis ottamaan haltuunsa milloin tahansa; Vastuu on kuljettajalla. Tasolla 3 ja sitä korkeammalla järjestelmä ottaa tietyissä olosuhteissa vastuulleen ajotehtävät.

5. Miksi "poistumisnopeus" on kriittinen mittari visuaalisten vikojen havaitsemisessa tuotantolinjalla?

• A) Viallisen osan hyväksyminen ja lähettäminen kentälle aiheuttaa turvallisuus- ja takaisinkutsuriskin ✔
• B) Se on tärkeä vain siksi, että se hidastaa linjan nopeutta
• C) Vuotomäärä koskee vain maalivirheitä
• D) Vuotonopeus mittaa mallin harjoitusaikaa

Kuvaus: Laiton; Viallinen osa katsotaan täydelliseksi ja kulkee linjan läpi (väärä negatiivinen). Autojen turvallisuuden osan osalta vuoto on paljon kalliimpaa kuin väärä hylkääminen, koska se voi johtaa epäonnistumiseen tai takaisinvetoon kentällä; Kynnystä säädetään vastaavasti.

6. Mikä on 'jäljellä olevan käyttöiän' (RUL) arvion tarkin käyttö ennakoivassa kunnossapidossa?

• A) RUL lasketaan vain moottoriöljylle
• B) Se tulee esittää epävarmuusvälillä ja tulkita huoltoikkunan ja turvamarginaalin mukaan ✔
• C) Se on otettava yhdeksi tarkaksi päiväarvoksi, eikä tarkastuksia tulisi tehdä ennen sitä päivää.
• D) Anturit voidaan sammuttaa, jos RUL on korkea

Kuvaus: RUL on komponentin arvioitu jäljellä oleva toiminta-aika vikaantumiseen asti; Se tulee esittää epävarmuusvälillä ja tulkita huoltosuunnitelman ja turvamarginaalin mukaisesti. Sen sijaan, että luottaisi sokeasti yhteen pisteen arvioon, luottamusväli ja väärän hälytyksen hinta otetaan huomioon.

7. Mitä insinöörin tulee tehdä, kun tekoäly merkitsee poikkeaman tietestitallenteessa testidata-analyysissä?

• A) Kun näet poikkeaman, testi tulee automaattisesti katsoa epäonnistuneeksi.
• B) Tekoälyn ei pitäisi katsoa tietoja ollenkaan, jos se ei ole merkinnyt sitä
• C) Tarkista poikkeama raakatiedoilla, mittausepävarmuudella ja toistettavuudella ✔
• D) Poista poikkeamat ja tyhjennä raportti

Selitys: Tekoälyn ilmoittama poikkeama on vihje, ei johtopäätös. Insinöörin on tarkistettava mittausepävarmuus, anturin vian mahdollisuus ja toistettavuus sekä tarkistettava poikkeama raakatiedoilla ja hyväksymiskriteereillä. Automaattinen hyväksyminen tai hylkääminen ei ole tarkoituksenmukaista.

8. Mikä todentaminen on pakollista tekoälyn keventämistutkimuksessa ehdottamalle materiaalimuutokselle?

• A) Sen on vain oltava kevyempi
• B) Aineistotietokannan yksi rivi voidaan pitää todisteena
• C) Törmäyskäyttäytyminen on merkityksetöntä kevyissä materiaaleissa
• D) Mekaaniset, väsymis-, törmäys-, valmistettavuus- ja kustannusvaatimukset tulee testata yhdessä ✔

Huomautus: Materiaalisuositusta ei voida hyväksyä pelkästään tiheys/lujuussuhteen perusteella; mekaaniset ominaisuudet, väsymys, törmäyskäyttäytyminen, valmistettavuus, korroosio, hinta- ja turvallisuusvaatimukset on tarkastettava yhdessä ja vahvistettava fysikaalisilla testeillä.

9. Miksi "yhden lähteen riski" autoteollisuuden toimitusketjussa vaatii erityistä huomiota tekoälysuosituksissa?

• A) Yhden toimittajan toimintahäiriö voi pysäyttää kaiken tuotannon; Toinen lähde ja puskuri tulee arvioida ✔
• B) Yksi lähde on aina turvallisin vaihtoehto
• C) Riskianalyysi on tarpeeton, jos tekoälyä ehdotetaan
• D) Yhden lähteen riski koskee vain rengasta

Selitys: Jos osa tulee yhdeltä toimittajalta, tuotanto pysähtyy, kun kyseisessä toimittajassa on ongelma. AI voi suositella yhtä kustannusoptimointilähdettä; Insinöörin/suunnittelijan on tasapainotettava tämä toissijaisen resurssin, varastopuskurin ja skenaarioanalyysin kanssa. Hinta ei ole ainoa kriteeri.

10. Mitä 'tietovuoto' tarkoittaa suoritettaessa telemetria-analyysiä Pythonilla ja miksi se on vaarallista?

• A) Tietoja vuotaa levyltä ja poistetaan
• B) Malli näkee koulutuksessa informaatiota, jota ei voida tietää ennustushetkellä; Paisuttaa pisteet, romahtaa kentälle ✔
• C) Graafisten värien sekoitus
• D) Esiintyy vain kuvatiedoissa

Kuvaus: Tietovuoto; Tällöin malli näkee koulutuksessa informaatiota, jota ei todellisuudessa voi tietää ennustehetkellä (esimerkiksi tulevaisuuden arvo tai tavoitteeseen liittyvä attribuutti). Tämä nostaa keinotekoisesti testitulosta, mutta kaataa kentän suorituskykyä. Menneisyyden/tulevaisuuden ero on säilytettävä huolellisesti aikasarjassa.

11. Mitä ASIL-luokitus määrittää ISO 26262 toiminnallisen turvallisuuden yhteydessä?

• A) Ajoneuvon suurin nopeus
• B) Mallin harjoitustietojoukon koko
• C) ✔ Vaadittu turvallisuustaso vaaran vakavuuden, altistumisen ja hallittavuuden mukaan.
• D) Toimittajan luottoluokitus

Kuvaus: ASIL (Automotive Safety Integrity Level) määrittää turvatoimien tason (A:sta D:hen, D on korkein), jonka vaara vaatii sen vakavuuden, altistumisen ja hallittavuuden arvioinnin perusteella. Korkea ASIL vaatii tiukempaa kehitystä, todentamista ja dokumentointia.

12. Miten ISO 21448 (SOTIF) eroaa klassisesta toimintaturvallisuudesta (ISO 26262)?

• A) Käsittelee vain laitteistoviat
• B) Säätelee vain ohjelmistojen lisensointia
• C) SOTIF on ISO 26262:n vanha nimi
• D) Käsittelee riittämättömästä toimivuudesta ja tunnistamattomista skenaarioista aiheutuvia riskejä, vaikka vika ei olisikaan ✔

Kuvaus: ISO 26262 käsittelee toimintahäiriöistä/laitteisto-ohjelmistovirheistä aiheutuvia riskejä, kun taas SOTIF (Safety of the Intended Functionality) käsittelee riskejä, jotka johtuvat riittämättömästä havaitsemisesta, tunnistamattomista skenaarioista ja toiminnallisista rajoituksista, vaikka järjestelmä ei toimisi ollenkaan; on erityisen kriittinen tekoälyyn perustuvassa havaitsemisessa.

13. Mikä on paras lähestymistapa yksityisyyden kannalta, kun työskentelet kuljettajan ja ajoneuvon telemetriatietojen kanssa?

• A) KVKK/GDPR-yhteensopivuus anonymisoinnin, tietojen minimoinnin ja käyttötarkoituksen rajoittamisen kanssa ✔
• B) Kaikkien raakatietojen lähettäminen julkiseen malliin VIN-numeron kanssa
• C) Yksityisyys koskee vain markkinointitietoja
• D) Sijaintitietoja ei koskaan pidetä henkilötiedona

Kuvaus: Tiedot, kuten sijainti, ajokäyttäytyminen ja alustanumero (VIN), voivat tunnistaa henkilön. Oikein lähestymistapa; tietojen anonymisointi/pseudonymisointi, vain tarpeellisen kerääminen (tietojen minimointi), käyttötarkoituksen rajoittaminen ja KVKK/GDPR-yhteensopivuus. Raaka VIN-koodin tai sijainnin lähettäminen kolmannen osapuolen työkaluille on riskialtista.

14. Miksi tuotantoon otetun tekoälymallin "data driftiä" on seurattava?

• A) Kun malli on koulutettu, se antaa saman suorituskyvyn loputtomiin.
• B) Suorituskyky heikkenee hiljaa, kun tulojakauma muuttuu ajan myötä; uudelleenkoulutus on käynnistettävä ✔
• C) Drift on vain laitteiston fyysistä tärinää
• D) Valvonta on tarpeetonta, koska malli päivittyy automaattisesti

Selitys: Tosimaailma muuttuu (uusi osien toimittaja, kausi, uusi ajoneuvomalli); Mallin suorituskyky laskee hiljaa, kun syöttöjakauma siirtyy pois harjoitusajasta. Uudelleenkoulutuksen käynnistävät drift-seuranta ja suorituskykymittarit. "Aseta ja unohda" -lähestymistapa on riskialtista autoteollisuudessa.