Provet ligger öppet.
Gör det utan att ansöka.

Uppgiften. Du får en Python-fil på sextio rader som tränar en klassificerare på sensordata från en produktionslinje. Den rapporterar 0,97 i träffsäkerhet på testmängden. Kollegan som skrev den är nöjd. Du ska säga om siffran går att lita på.

scaler = StandardScaler().fit(X)
X = scaler.transform(X)
X_tr, X_te, y_tr, y_te = train_test_split(X, y, test_size=0.2)
...
print(accuracy_score(y_te, model.predict(X_te)))   # 0.97

Frågan. Går siffran att lita på? Om inte: vad är fel, hur stort är felet ungefär, och hur ser den rättade koden ut?

VAD VI BEDÖMER

• Att du ser att skalningen sker före uppdelningen, så att testmängden läcker in i träningen.
• Att du hittar det andra felet också: klasserna är obalanserade, 96 mot 4 procent, och träffsäkerhet är då fel mått. En modell som alltid svarar normal får 0,96.
• Att du föreslår ett mått som betyder något här, till exempel precision, återkallelse eller PR-AUC, och motiverar valet utifrån vad ett missat fel kostar mot vad ett falsklarm kostar.

Vanligaste underkända svaret: att bara hitta läckaget. Det är hälften av uppgiften. Den obalanserade klassfördelningen är den som faktiskt gör siffran meningslös, och den syns bara om du tittar på datat.

Uppgiften. En modelltjänst i Kubernetes startar om ungefär var fyrtionde minut. Trafiken är jämn. Du får kubectl describe pod, de senaste hundra raderna logg och en graf över minnesanvändning.

State:          Running
Last State:     Terminated
  Reason:       OOMKilled
  Exit Code:    137
Restart Count:  17
Limits:         memory: 512Mi

Loggen slutar mitt i en rad varje gång. Minnesgrafen är en jämn uppförsbacke som nollställs vid varje omstart.

Frågan. Vad händer, hur bekräftar du det, och vad gör du åt det, i tur och ordning med det billigaste först?

VAD VI BEDÖMER

• Att du läser OOMKilled och exitkod 137 rätt: kärnan dödar processen, tjänsten kraschar inte själv.
• Att du skiljer på symptom och orsak. Att höja minnesgränsen flyttar omstarten till varannan timme, den tar inte bort läckan.
• Att du föreslår en ordning: höj gränsen för att sluta blöda, bekräfta läckan med en minnesprofil, hitta vad som växer: batchar som ackumuleras, en cache utan tak, tensorer som aldrig frigörs.
• Att du nämner vad du sätter för larm så att nästa gång upptäcks av dig och inte av kunden.

Vanligaste underkända svaret: ”öka minnesgränsen”. Rätt första åtgärd, men inte ett svar på frågan.

Uppgiften. En klassificerare för avvikelser i en produktionslinje går från 94 till 85 procents träffsäkerhet under tre veckor efter driftsättning. Koden är oförändrad. Modellvikterna är oförändrade. Du får indata, prediktioner och facit för hela perioden, dag för dag.

I datat: en av sexton sensorer började för nitton dagar sedan rapportera i en annan enhet efter ett fältbyte, en annan har fastnat på sitt senaste värde, och andelen körningar i nattskift har gått från 12 till 31 procent.

Frågan. Vilken av de tre förklarar tappet? Visa hur du avgör det, inte bara vad du tror. Vad föreslår du för åtgärd, och hur hindrar du att samma sak händer igen utan att någon märker det?

VAD VI BEDÖMER

• Att du mäter i stället för att gissa: jämför fördelningen per feature före och efter, och bryt ned felet per tidsperiod och per skift.
• Att du ser att alla tre är verkliga förändringar men bara en driver felet, och att du kan visa vilken.
• Att du skiljer på ett trasigt dataflöde och en verklig förändring i verksamheten. Det första lagas i integrationen, det andra kräver omträning. Fel åtgärd på fel orsak gör det värre.
• Att åtgärdsförslaget innehåller en detektion: validering av indata, larm på fördelningsförskjutning, en fastnad-sensor-kontroll.

Vanligaste underkända svaret: ”modelldrift”. Rätt ord, inget svar. Frågan är vad i datat som rörde sig och hur du vet det.

Uppgiften. Två tabeller. sensor med en avläsning per maskin var tionde sekund, tidsstämplad i UTC. arbetsorder med underhållsåtgärder, tidsstämplade i lokal tid utan tidszon, ibland dubblerade när någon registrerat samma åtgärd två gånger.

Du ska ta fram, per maskin och månad: antal åtgärder, mediantid mellan åtgärder, och medeltemperatur under de 24 timmarna före varje åtgärd.

Frågan. Skriv frågan. Skriv också ned vilka antaganden du tvingas göra, och vilket av dem som skulle göra mest skada om det var fel.

VAD VI BEDÖMER

• Att du hanterar tidszonen explicit, inklusive de två timmarna om året då lokal tid är tvetydig eller inte finns.
• Att du avdubblerar på något mer genomtänkt än DISTINCT. Samma åtgärd registrerad två gånger har ofta olika id och olika sekund.
• Att fönstret på 24 timmar före räknas mot faktisk tid, inte mot antal rader.
• Att du skriver ut antagandena. Den som listar sina antaganden får mer poäng än den som råkar gissa rätt utan att nämna det.

Vi läser inte efter dialekt. PostgreSQL, T-SQL eller Pandas fungerar lika bra, så länge det går att följa.

Uppgiften. Ett energibolag vill driftsätta en modell som förutsäger fel i ställverk och automatiskt sänker belastningen på en ledning när risken överstiger en tröskel. Ingen människa i loopen. Systemet loggar sina beslut.

Frågan. Är det ett högrisksystem enligt EU:s AI-förordning? Motivera med den bestämmelse du stödjer dig på. Om du behöver mer information för att svara: vilken, och varför är just den avgörande?

VAD VI BEDÖMER

• Att du går till bilaga III och punkten om kritisk infrastruktur i stället för att svara på magkänsla.
• Att du ser att svaret hänger på om systemet är en säkerhetskomponent i driften av eldistribution, och att du kan säga vad som avgör det.
• Att du frågar efter rätt sak: vad händer om modellen har fel åt båda hållen, och vad kan en människa göra åt det och hur snabbt.
• Att du skiljer på vad förordningen kräver och vad som är gott ingenjörsarbete. Båda behövs, men de är inte samma sak.

Vanligaste underkända svaret: ett tvärsäkert ja eller nej. Den här uppgiften mäter om du vet var gränsen för din kunskap går och kan säga det högt. Ett välmotiverat ”det beror på, och det här behöver jag veta” är fullt godkänt.