Kunstig intelligens i ML Engineering: Rolle, grenser, validering og ansvar

Gevinster:

• Å kunne skille hvor i ML arbeidsflyten (kode, data, dokument) kunstig intelligens sparer tid med lav risiko, og hvor beslutninger som metrikk / data / sette i produksjon er overlatt til mennesket, i henhold til oppgavens risikonivå.
• Evne til å bruke en disiplin som verifiserer hver AI-utgang ved å koble den til kilden, kjøre den på nytt, måle den og sende den gjennom et ingeniørfilter.
• Evne til å tilegne seg en vane med å ikke sende rå konfidensielle og personlige data til eksterne verktøy, bruke bedriftsgodkjente verktøy og håndtere sikkerhetsproblemer kun for defensive formål.

Kunstig intelligens i maskinlæringsteknikk: Rolle, grenser, validering og ansvar

En maskinlæringsingeniør (ML-ingeniør: en programvareekspert som designer, trener og bringer modeller som lærer fra data til produksjon) jobber i dag med et annet kunstig intelligensverktøy på hvert trinn i jobben sin. En kodeassistent er i kraft når du skriver kode, en samtalemodell når du utforsker data, og en stor språkmodell (LLM: et nevralt nettverk med milliarder av parametere som forstår og produserer tekst) når du produserer dokumentasjon. Denne modulen betrakter kunstig intelligens som både produktet utviklet og det daglige arbeidsverktøyet til en ML-ingeniør. Den opererer ved å tydelig avgrense ansvarsgrensene uten å blande de to rollene.

I denne første enheten svarer vi på det grunnleggende spørsmålet: Hvor i ML-teknikk sparer kunstig intelligens sanntid, og hvor må vi overlate avgjørelsen til mennesker? Svaret ligger i hjertet av ingeniørdisiplinen: den som lager er rask, den som verifiserer er ansvarlig.

Hvor kommer kunstig intelligens til nytte i ML-teknikk?

Et ML-prosjekt går omtrent gjennom følgende linjer: datainnsamling, datarensing, funksjonsteknikk (oversettelse av rådata til digitale signaler som modellen kan forstå), modelltrening, evaluering, utrulling (distribusjon: åpne modellen for den virkelige brukeren) og overvåking. AI hjelper på hvert stopp på denne linjen, men autoritetsnivået varierer.

Områder med høy belønning og lav risiko: produsere et kodeskjelett, utarbeide en datatransformasjonsfunksjon, tolke loggmeldinger, beskrive en stabelsporing, oppsummere eksperimentnotater, skrive dokumentasjon og README-er, foreslå en testcase. Her er kunstig intelligenss feil billige; fordi utgangen allerede vil gå gjennom testing og gjennomgang.

Høyrisikoområder: bestemme hvilke data som skal inn i opplæringen, bekrefte om en modell skal settes i produksjon, bedømme en beregning er "god nok", beslutning om å behandle personopplysninger, lukke en sikkerhetssårbarhet som "søppel". Disse påvirker penger, personvern, juridisk ansvar og brukertillit. Kunstig intelligens gir forslag her; Beslutningen tas av den kompetente ingeniøren og det ansvarlige teamet.

Tips: Før du outsourcer en oppgave til AI, spør: "Hva koster det hvis denne utgangen er feil, og hvor lett vil noen ta feilen?" Hvis prisen er lav og fangst er enkelt, gi det videre. Hvis prisen er høy eller fangst er vanskelig, bruk kun AI for utkastet og du bestemmer deg.

Verifikasjonsdisiplin: tre trinn

I ML-teknikk er AI-utgang aldri et "ferdig arbeid"; Det er et utkast. Kjør hver utgang gjennom disse tre trinnene:

1. Koble den til kilden. Hvis modellen sa et tall, en terskel eller en "beste praksis", baser det på offisiell dokumentasjon, faktisk verdi i kodebasen eller en målt beregning. "Tilpasning av modellen" (hallusinasjon: den trygge produksjonen av ikke-reell informasjon av språkmodellen) fanges oftest opp her.
2. Start på nytt og mål. Kjør den genererte koden, beregn beregningen den produserer på ditt eget testsett, valider den foreslåtte SQL-spørringen på et lite utvalg. Kode som ikke fungerer er verdiløs, selv om den ser fin ut.
3. Før den gjennom et ingeniørfilter. Holder utgangen i skala? Har kantsaker (tomme data, svært store inndata, manglende felt) blitt vurdert? Er det et sikkerhets- og personvernbrudd? Bare en person som kan feltet kan gjøre dette trinnet.

Svak forespørsel / Sterk forespørsel

Svak melding: "Skriv meg en modelltreningskode."

Kraftig ledetekst: "Skriv et treningsskript for binær klassifisering med scikit-learn. Inndata: data/train.parquet, målkolonne is_churn. Det er klasseubalanse (positiv rate ~8%), håndter det med class_weight. Bruk PR-AUC (areal under presisjons-gjenkallingskurven) da evalueringsverdien er tilfeldig og ubalansert, fordi den ikke er tilfeldig balansert. til 42. Test på slutten av kodeutskriftssettet PR-AUC."

Forskjell: den andre spørsmålsoppgaven inneholder datasannheten, korrekt metrikk, ubalanseinformasjon og repeterbarhetskrav. Det er fra denne konteksten at utgangen er verifiserbar og brukbar.

Personvern og datasikkerhet: ingeniørens første ansvar

ML-ingeniøren berører ofte selskapets mest sensitive data: kunderegistre, transaksjonshistorikk, helse- eller økonomiske data, logger over produksjonssystemer. Tre regler når du gir data til verktøy for kunstig intelligens:

• Ikke send rå personlige og konfidensielle data til eksterne verktøy. Send for eksempel skjemaet og dummy (syntetiske) prøvene i stedet for å lime inn kunde-e-poster i ledeteksten. Bruk maskerte eksempel som "ex: ahmet@example.com" i stedet for ekte data.
• Bruk bedriftsgodkjente kjøretøy. Velg verktøy som er kontraktsmessig tydelige hvor dataene behandles, om de lagres, om de brukes til utdanning eller ikke. Behandling av bedriftsdata med en personlig konto er et brudd i de fleste bedrifter.
• Minimumsdatapolicy. Gi minimum kontekst som trengs for å løse oppgaven. Ikke hele tabellen, men de relevante 5 kolonnene og skjemaet.

Forsiktig: Anta at teksten du gir til en språkmodell ikke kan angres. Ikke send rå personopplysninger og tenker "jeg sletter det senere"; Risikoen oppsto i det øyeblikket den ble sendt.

Defensiv bruk innen sikkerhet

ML-ingeniører installerer ofte sikkerhetssystemer: svindeloppdagelse, klassifisering av skadelig trafikk, autentisering. Gjennom denne modulen dekker vi sikkerhetsproblemer kun for defensive formål: oppdage angrepet, herde systemet, lukke sårbarheten. Å bruke kunstig intelligens for uautorisert tilgang, datalekkasje eller uautorisert inngrep i andres system er både ulovlig og i strid med yrkesetikken. Når du finner en sårbarhet, er den riktige måten å rapportere den på en ansvarlig måte og fikse den; ikke utnytte.

tre minisaker

Tilfelle 1 - Tid spart. En ML-ingeniør vil normalt bruke en halv dag på å gjøre utforskende dataanalyse (EDA) av et datasett med 40 kolonner. Han ga utdataene fra skjemaet og df.describe() til den kunstige intelligensen og spurte: "Hvilke kolonner har en høy uteligger og manglende rate, hvilke transformasjoner anbefaler du?" På 20 minutter mottok han en prioritert liste, som bekreftet hvert element med sin egen kode. Spar: ~3 timer, lav risiko for feil fordi alle krav ble målt.

Tilfelle 2 - Fanget feil. "Treningsnøyaktigheten er 99 %, flott," sa modellen en chat-assistent. Ingeniøren brukte det tredje trinnet (ingeniørfilter) og innså: målkolonnen hadde ved et uhell lekket attributter (datalekkasje: modellen ser informasjon den ikke skal se i trening). Faktisk ytelse var mye lavere. Ingeniørens skepsis, ikke AIs «store» tolkning, reddet jobben.

Sak 3 – Forebygging av personvernbrudd. Et team limte inn produksjonsfeilloggene i en ekstern modell og sa "fiks denne feilen". Det var kundeidentifikasjonsnummer i loggene. Teamet laget en regel om å skrive et lite skript som maskerer loggene først (gjør ID-numrene ***) og sende dem den veien. Risikoen for brudd er forsvunnet, hastigheten på bistanden har ikke endret seg.

Kopierbare maler

Oppgave: [hva du skal gjøre, enkelt setning]Kontekst: [dataskjema, størrelse, begrensninger; INGEN FAKTISKE personopplysninger]Begrensninger: [språk/bibliotek, ytelse, reproduserbarhet]Beregninger: [hvordan måle suksess]Ønsket utdata: [kode/beskrivelse/liste] og hvorfor i dette formatet

Sjekk ut denne koden. Vurder ikke bare at det fungerer, men også i forhold til:1) Kantsaker (tom input, manglende kolonne, svært store data)2) Risiko for datalekkasje3) Reproduserbarhet (seed, versjon)Foreslå rettelser for hvert problem du finner. Merk "bekreft" der du ikke er sikker. Kode: [kode]

Tolk resultatet av denne metrikken, men spør først: er denne metrikken riktig for dette problemet?Problem: [balansert/ubalansert klassifisering, regresjon, rangering...]Rapportert metrikk og verdi: [f.eks. nøyaktighet 0.99]Hvilken beregning vil du anbefale og hvorfor, og hvilke tegn bør jeg se etter for å få meg til å tvile på det nåværende resultatet?

Sjekk om det er personlig/konfidensiell informasjon i dataene jeg vil gi til følgende forespørsel. List opp feltene (navn, e-post, ID-nummer, telefon, adresse) som må maskeres i teksten nedenfor. Tekst: [tekst]

Rolle- og autoritetstabell

Quest

Rollen til kunstig intelligens

Eier av vedtaket

Kodeskjelett / transformasjonsfunksjon

trekkgenerator

Ingeniør (anmeldelser)

EDA / datasammendrag

akselerator

Ingeniør (verifiserer ved å måle)

Metrisk tolkning

Forslag

ingeniør

Hvilke data vil gå inn i trening?

Forslag

Team + dataeier

Sett modellen i produksjon

Sjekkliste påminnelse

Ansvarlig ingeniør + team

Behandling av personopplysninger

Ingen (ikke brukt)

Juridisk + behandlingsansvarlig

Vanlige feil

• Bruk av utdata uten å validere det. Den vanligste og dyreste feilen. Kode eller beregning som ser bra ut, betyr ikke at den er riktig.
• Lime inn rå konfidensielle data i verktøyet. Når den er sendt, kan den ikke tas tilbake.
• Stoler på feil metrikk. Inkompatible beregninger som nøyaktighet i ubalanserte data og RMSE i rangeringsproblemer er misvisende.
• Ta feil av kunstig intelligens som beslutningstaker. Han gir forslag; Ansvaret ligger hos underskriveren.
• Kontekstløs forespørsel. Tvetydige forespørsler som "skriv en modell" produserer utdata som ikke kan verifiseres.

Oppsummert

Kunstig intelligens er både produktet utviklet av ML-ingeniøren og dens daglige replikator. Verdien er høyest i lavrisiko, lett verifiserte oppgaver som kode-data-dokument; Avgjørelser som påvirker penger, personvern og sikkerhet forblir hos personen. Koble hver utgang til kilden, mål igjen, pass gjennom ingeniørfilter. Beskytt konfidensielle data, bruk godkjente kjøretøy, arbeid i sikkerhet kun for defensive formål. Denne disiplinen er grunnlaget for alle påfølgende enheter.

Søknadsoppgave

Velg en oppgave fra ditt eget prosjekt (f.eks. å skrive en datarensefunksjon). Skriv først en svak forespørsel, og skriv deretter en sterk forespørsel ved å bruke malen i denne enheten. Ta begge utgangene, bruk tre-trinns bekreftelse (lenke til kilde, rekjøring, ingeniørfilter). Merk hvilken prompt som sparer hvor mange minutter og hvor mange korrigeringer.

sjekkliste

• [ ] Jeg har bestemt risikonivået (lavt/høyt) for oppgaven min.
• [ ] Jeg la ikke inn noen faktiske personlige/konfidensielle data i forespørselen; Jeg maskerte det eller brukte en syntetisk prøve.
• [ ] Jeg koblet utgangen til kilden, kjørte den på nytt, filtrerte den fra et ingeniørperspektiv.
• [ ] Jeg sjekket at jeg valgte riktig beregning.
• [ ] Jeg tok den kritiske avgjørelsen (å sette den i produksjon, databehandling) selv/med teamet, jeg overlot det ikke til kunstig intelligens.
• [ ] Jeg brukte et bedriftsgodkjent kjøretøy.