Vinster:
- Att kunna urskilja var i ML-arbetsflödet (kod, data, dokument) artificiell intelligens sparar tid med låg risk, och var beslut som t.ex. metrisk/data/att sätta i produktion lämnas till människan, enligt uppgiftens risknivå.
- Möjlighet att tillämpa en disciplin som verifierar varje AI-utgång genom att ansluta den till källan, köra den igen, mäta den och föra den genom ett tekniskt filter.
- Förmåga att skaffa vanan att inte skicka rå konfidentiell och personlig information till externa verktyg, använda företagsgodkända verktyg och hantera säkerhetsfrågor endast i defensiva syften.
Artificiell intelligens i maskininlärningsteknik: roll, gränser, validering och ansvar
En maskininlärningsingenjör (ML-ingenjör: en mjukvaruproffs som designar, tränar och tar med modeller som lär sig från data till produktion) arbetar idag med ett annat artificiell intelligensverktyg vid varje steg i sitt jobb. En kodningsassistent är i kraft när man skriver kod, en konversationsmodell när man utforskar data och en stor språkmodell (LLM: ett neuralt nätverk med miljarder parametrar som förstår och producerar text) när man producerar dokumentation. Denna modul betraktar artificiell intelligens som både den produktutvecklade och det dagliga arbetsverktyget för en ML-ingenjör. Den verkar genom att tydligt avgränsa ansvarsgränserna utan att blanda de två rollerna.
I denna första enhet svarar vi på den grundläggande frågan: Var inom ML-teknik sparar artificiell intelligens realtid, och var måste vi överlåta beslutet till människor? Svaret är kärnan i ingenjörsdisciplinen: den som gör är snabb, den som verifierar är ansvarig.
Var kommer artificiell intelligens till användning inom ML-teknik?
Ett ML-projekt går igenom ungefär följande linjer: datainsamling, datarensning, funktionsteknik (översätta rådata till digitala signaler som modellen kan förstå), modellträning, utvärdering, implementering (deployment: öppna modellen för den verkliga användaren) och övervakning. AI hjälper vid varje stopp på den här linjen, men dess auktoritetsnivå varierar.
Områden med hög belöning, lågrisk: producera ett kodskelett, utarbeta en datatransformationsfunktion, tolka loggmeddelanden, beskriva en stackspårning, sammanfatta experimentanteckningar, skriva dokumentation och README, föreslå ett testfall. Här är den artificiella intelligensens misstag billiga; eftersom utgången redan kommer att genomgå testning och granskning.
Högriskområden: bestämma vilken data som ska användas till utbildning, bekräfta om en modell ska gå i produktion, bedöma ett mått är "tillräckligt bra", beslut att behandla personuppgifter, stänga en säkerhetssårbarhet som "skräp". Dessa påverkar pengar, integritet, juridiskt ansvar och användarnas förtroende. Artificiell intelligens ger förslag här; Beslutet fattas av den behöriga ingenjören och det ansvariga teamet.
Tips: Innan du lägger ut en uppgift till AI, fråga: "Vad kostar det om denna utdata är fel, och hur lätt kommer någon att ta tag i misstaget?" Om priset är lågt och det är lätt att fånga, skicka det vidare. Om priset är högt eller om det är svårt att fånga, använd AI endast för utkastet och du bestämmer dig.
Verifieringsdisciplin: tre steg
I ML-teknik är AI-utdata aldrig ett "färdigt arbete"; Det är ett utkast. Kör varje utgång genom dessa tre steg:
- Anslut den till källan. Om modellen sa ett tal, ett tröskelvärde eller en "bästa praxis", basera det på officiell dokumentation, faktiska värden i kodbasen eller ett uppmätt mått. "Anpassning av modellen" (hallucination: språkmodellens säker produktion av icke verklig information) fångas oftast här.
- Starta om och mät. Kör den genererade koden, beräkna om mätvärdet den producerar på din egen testuppsättning, validera den föreslagna SQL-frågan på ett litet urval. Kod som inte fungerar är värdelös, även om den ser snygg ut.
- Passera det genom ett tekniskt filter. Håller produktionen i skala? Har kantfall (tom data, mycket stor ingång, saknade fält) beaktats? Finns det ett säkerhets- och integritetsintrång? Endast en person som kan området kan göra detta steg.
Svag prompt / Stark prompt
Svag uppmaning: "Skriv en modellträningskod till mig."
Kraftfull uppmaning: "Skriv ett träningsskript för binär klassificering med scikit-learn. Inmatning: data/train.parquet, målkolumn is_churn. Det finns klassobalans (positiv frekvens ~8%), hantera det med class_weight. Använd PR-AUC (area under precision-återkallningskurvan) eftersom utvärderingsnoggrannhetsmätningen är slumpmässigt obalanserad för att Fixa är slumpmässigt obalanserad. till 42. Testa i slutet av kodutskriftsuppsättningen PR-AUC."
Skillnad: den andra snabbuppgiften innehåller datasanningen, korrekt mätvärde, obalansinformation och krav på repeterbarhet. Det är från detta sammanhang som utgången är verifierbar och användbar.
Integritet och datasäkerhet: ingenjörens första ansvar
ML-ingenjören berör ofta företagets mest känsliga data: kundregister, transaktionshistorik, hälso- eller finansdata, loggar över produktionssystem. Tre regler när du ger data till verktyg för artificiell intelligens:
- Skicka inte rå personlig och konfidentiell data till externa verktyg. Till exempel, istället för att klistra in kunders e-postmeddelanden i prompten, skicka schemat och dummy (syntetiska) prover. Använd maskerade exempel som "ex: ahmet@example.com" istället för riktiga data.
- Använd företagsgodkända fordon. Välj verktyg som är kontraktuellt tydliga var uppgifterna behandlas, om de lagras, om de används för utbildning eller inte. Att behandla företagsuppgifter med ett personligt konto är ett brott i de flesta företag.
- Minsta datapolicy. Ge det minsta sammanhang som behövs för att lösa uppgiften. Inte hela tabellen, men de relevanta 5 kolumnerna och schemat.
Varning: Antag att texten du ger till en språkmodell inte kan ångras. Skicka inte obearbetade personuppgifter och tänker "jag raderar det senare"; Risken uppstod i samma ögonblick som den skickades.
Defensiv användning inom säkerhetsområdet
ML-ingenjörer installerar ofta säkerhetssystem: bedrägeriupptäckt, klassificering av skadlig trafik, autentisering. Under hela den här modulen täcker vi säkerhetsfrågor endast i defensiva syften: att upptäcka attacken, härda systemet, stänga sårbarheten. Att använda artificiell intelligens för obehörig åtkomst, dataläckage eller obehöriga ingrepp i någon annans system är både olagligt och mot yrkesetik. När du hittar en sårbarhet är det rätta sättet att rapportera den på ett ansvarsfullt sätt och åtgärda det; inte utnyttja.
tre minifodral
Fall 1 - Sparad tid. En ML-ingenjör skulle normalt ägna en halv dag åt att göra utforskande dataanalys (EDA) av en datauppsättning med 40 kolumner. Han gav schemat och df.describe() utdata till den artificiella intelligensen och frågade: "Vilka kolumner har en hög extremvärde och felfrekvens, vilka transformationer rekommenderar du?" På 20 minuter fick han en prioriterad lista, som verifierade varje objekt med sin egen kod. Spara: ~3 timmar, låg risk för fel eftersom varje reklamation mäts.
Fall 2 - Upptäckt fel. "Träningsnoggrannheten är 99 %, jättebra", sa modellen en chattassistent. Ingenjören tillämpade det tredje steget (teknikfilter) och insåg: målkolumnen hade oavsiktligt läckt attribut (dataläckage: modellen ser information som den inte borde se under träning). Den faktiska prestandan var mycket lägre. Ingenjörens skepsis, inte AI:s "stora" tolkning, räddade jobbet.
Fall 3 – Förebyggande av integritetsintrång. Ett team klistrade in produktionsfelloggarna i en extern modell och sa "fixa det här felet". Det fanns kundidentifikationsnummer i loggarna. Teamet gjorde en regel att skriva ett litet skript som maskerar loggarna först (gör deras ID-nummer ***) och skicka dem på det sättet. Risken för intrång har försvunnit, assistanshastigheten har inte förändrats.
Kopierbara mallar
Uppgift: [vad man ska göra, enstaka mening]Kontext: [dataschema, storlek, begränsningar; INGA FAKTA personuppgifter]Begränsningar: [språk/bibliotek, prestanda, reproducerbarhet]Mätvärden: [hur man mäter framgång]Önskad utdata: [kod/beskrivning/lista] och varför i detta format
Kolla in den här koden. Utvärdera inte bara att det fungerar, utan även vad gäller:1) Kantfall (tom ingång, saknad kolumn, mycket stor data)2) Risk för dataläckage3) Reproducerbarhet (frö, version)Föreslå korrigeringar för varje problem du hittar. Markera "verifiera" där du inte är säker. Kod: [kod]
Tolka resultatet av detta mått, men fråga först: är detta mått korrekt för det här problemet? Problem: [balanserad/obalanserad klassificering, regression, rankning...]Rapporterat mått och värde: [t.ex. precision 0.99]Vilket mätvärde skulle du rekommendera och varför, och vilka tecken ska jag leta efter för att få mig att tvivla på det aktuella resultatet?
Kontrollera om det finns personlig/konfidentiell information i uppgifterna jag kommer att ge till följande uppmaning. Lista de fält (namn, e-post, ID-nummer, telefon, adress) som behöver maskeras i texten nedan. Text: [text]
Roll- och auktoritetstabell
Quest
Den artificiella intelligensens roll
Ägare av beslutet
Kodskelett / transformationsfunktion
draggenerator
Ingenjör (recensioner)
EDA / datasammanfattning
gaspedalen
Ingenjör (verifierar genom att mäta)
Metrisk tolkning
Förslag
ingenjör
Vilken data kommer att gå in i utbildningen?
Förslag
Team + dataägare
Sätt modellen i produktion
Påminnelse om checklista
Ansvarig ingenjör + team
Behandling av personuppgifter
Ingen (används ej)
Juridisk + personuppgiftsansvarig
Vanliga misstag
- Använda utgången utan att validera den. Det vanligaste och dyraste misstaget. Kod eller mått som ser bra ut betyder inte att det är korrekt.
- Klistra in rå konfidentiell data i verktyget. När den väl har skickats kan den inte tas tillbaka.
- Förlitar sig på fel mätvärde. Inkompatibla mätvärden som noggrannhet i obalanserad data och RMSE i rankningsproblem är missvisande.
- Misstag artificiell intelligens som beslutsfattare. Han ger förslag; Ansvaret ligger på undertecknaren.
- Kontextlös uppmaning. Tvetydiga förfrågningar som att "skriva en modell" producerar outdata som inte går att kontrollera.
Sammanfattningsvis
Artificiell intelligens är både produkten som utvecklats av ML-ingenjören och dess dagliga replikator. Dess värde är högst i lågrisk, lätt verifierade uppgifter som kod-data-dokument; Beslut som påverkar pengar, integritet och säkerhet ligger kvar hos personen. Anslut varje utgång till källan, mät igen, passera genom teknikfilter. Skydda konfidentiell data, använd godkända fordon, arbeta i säkerhet endast för defensiva ändamål. Denna disciplin är grunden för alla efterföljande enheter.
Applikationsuppgift
Välj en uppgift från ditt eget projekt (t.ex. skriva en datarensningsfunktion). Skriv först en svag uppmaning, skriv sedan en stark uppmaning med hjälp av mallen i den här enheten. Ta båda utgångarna, använd trestegsverifiering (länk till källa, kör om, konstruktionsfilter). Notera vilken prompt som sparar hur många minuter och hur många korrigeringar.
checklista
- [ ] Jag har bestämt risknivån (låg/hög) för min uppgift.
- [ ] Jag lade inte in några faktiska personliga/konfidentiella uppgifter i prompten; Jag maskerade det eller använde ett syntetiskt prov.
- [ ] Jag kopplade utgången till källan, körde den igen, filtrerade den ur ett tekniskt perspektiv.
- [ ] Jag kontrollerade att jag valde rätt mätvärde.
- [ ] Jag tog det kritiska beslutet (att sätta i produktion, databearbetning) själv/med teamet, jag överlät det inte till artificiell intelligens.
- [ ] Jag använde ett företagsgodkänt fordon.