Börja med situationen

Välj ett låginsatsproblem som går att undersöka under kurstiden. Det kan anknyta till ditt program eller ett intresse, men projektet behöver en bestämd situation. "Använd AI i musik" är en ämnesidé. "Sortera ett eget, rättighetsklarerat bibliotek med trumloopar i tre fördefinierade ljudtyper" är närmare en prövbar uppgift.

Du kan arbeta i en av tre former:

• en enkel klassificerings- eller prediktionsprototyp med godkänd data,
• en sök- eller agentprototyp i en helt simulerad miljö,
• en prototyp som skapar eller granskar innehåll mot ett fast källpaket.

Projektets kärna måste vara en AI-relaterad metod eller en systematisk granskning av en sådan metod. Ett vanligt formulär med en chattfunktion bredvid räcker inte.

Skriv projektkontraktet

Ett projektkontrakt är en kort överenskommelse om vad du ska bygga och pröva. Fyll i följande delar innan du väljer verktyg:

1. Användare och situation: Vem ska använda prototypen, när och varför? 2. Input: Vilken information får systemet? 3. Output: Vilket avgränsat resultat ska systemet ge? 4. Arbetsflöde: Vilken människa gör vad före och efter outputen? 5. Framgångskriterier: Vilka observerbara resultat räknas som tillräckliga? 6. Viktig feltyp: Vilket misslyckande behöver upptäckas även om totalsiffran ser bra ut? 7. Icke-mål: Vad ska prototypen inte användas eller bedömas för?

Ett framgångskriterium behöver både mått och villkor. Skriv hellre "minst lika få betydelseändrande fel som den enkla regeln på samma 20 testfall" än "bra kvalitet". Bestäm också ett minsta godtagbart resultat innan du ser sluttestet.

Gör projektet mindre

Minska antalet användare, outputtyper, datakällor eller funktioner tills du kan följa ett enskilt fall genom hela systemet. En liten prototyp med ärlig utvärdering ger starkare evidens än många funktioner som aldrig testas.

Lämna projektkontraktet för godkännande. Samla inte in data och skapa inga externa konton innan underlag, verktyg och risknivå har godkänts. Efter godkännandet fryser du kontraktets första version. Senare ändringar märks som nya versioner med skäl.

Kontrollfråga

Byt kontrakt med en kamrat. Kamraten ska kunna peka ut exakt vilken input som går in, vilken output som kommer ut, hur framgång mäts och när systemet inte ska användas. Om någon del kräver en gissning behöver kontraktet avgränsas igen.

Underlaget måste passa frågan

Projektet kan använda tabellrader, bilder, texter, simulerade tillstånd eller ett fast källpaket. Oavsett form behöver du ett underlagskort. Ange ursprung, skapare, licens eller tillstånd, version, urval, fält eller innehållstyper, transformationer och kända begränsningar. Skriv också om materialet är verkligt, syntetiskt eller handkonstruerat.

Kontrollera passformen mot projektkontraktet. Ett dataset med tydliga etiketter kan vara användbart för en kursövning men ändå sakna den population som projektets användare möter. Ett källpaket kan vara rättighetsklarerat men sakna uppgiften som ett genererat svar behöver stödja. Välj använd, revidera eller använd inte innan byggandet börjar.

Jämför med en baseline

En baseline är en enkel, relevant jämförelse. Den kan vara en fast regel, en vanlig manuell rutin, ett slumpval med angiven fördelning eller lösningen ingen AI. Baseline ska göra samma avgränsade uppgift och mätas med samma testfall och kriterier.

Om projektet sorterar tre typer av exempel kan en regel baserad på ett enda särdrag vara baseline. Om projektet granskar källstöd kan en människa med samma källpaket vara jämförelsen. En avancerad prototyp som inte slår eller kompletterar en billig regel behöver ett särskilt starkt skäl för att användas.

Frys sluttestet

Dela arbetet i utveckling och sluttest. Under utvecklingen får du undersöka fel och ändra prototypen. Sluttestet hålls avskilt tills prototypversionen och kriterierna har frysts. Om du ändrar lösningen efter att ha sett sluttestet har testet blivit en del av utvecklingen och behöver ersättas med nytt, osett underlag.

Skriv testplanen före körningen:

• vilka fall och villkor som ska ingå,
• vilket facit eller bedömningssätt som används,
• vilka mått och feltyper som redovisas,
• vilken baseline som jämförs,
• vilken acceptansgräns och stoppregel som gäller,
• vilka slutsatser testet inte kan stödja.

Använd flera villkor när det är relevant, till exempel kort och lång text, ljust och mörkt bildläge eller enkel och blockerad karta. Ändra inte samtidigt uppgift, underlag och mätetal mellan prototyp och baseline.

Övning: försök underkänna planen

Låt en kamrat hitta ett sätt att få ett missvisande bra resultat genom att välja lätta testfall, läcka facit, byta mått eller ge baseline sämre information. Ändra planen så att genvägen inte fungerar. Spara den godkända testplanen som en egen version innan prototyparbetet fortsätter.

Bygg den minsta hela kedjan

Gör först en minsta fungerande prototyp. Den ska ta emot en tillåten input, genomföra den centrala AI-relaterade operationen och ge den output som projektkontraktet beskriver. Den behöver inte ha snyggt gränssnitt. Däremot ska ett fall kunna följas från input till resultat och mänskligt beslut.

Frys varje prövad version. Spara kod, regler, instruktioner eller systeminställningar tillsammans med underlagsversionen. Om en extern modell används ska du registrera leverantörens modellbeteckning och de inställningar som faktiskt visas, utan att påstå att dolda komponenter är kända.

En rad per försök

Ge varje försök ett stabilt försöks-id. Loggen ska minst innehålla:

| Fält | Vad du skriver | | --- | --- | | Försöks-id och tid | unik kod och tidpunkt | | Prototypversion | kod, regelpaket eller instruktion | | Underlag | ID och version | | Konfiguration | val som kan påverka output | | Avsiktlig ändring | en tydligt namngiven skillnad | | Resultat | mått och konkreta observationer | | Oväntat | fel, variation eller avvikelse | | Nästa beslut | behåll, återställ eller pröva vidare |

Ändra helst en sak åt gången. Om du samtidigt byter data, instruktion och mätetal kan ett bättre resultat inte kopplas till en bestämd ändring. Behöver flera saker ändras tillsammans ska paketet få en ny version och jämförelsen beskrivas som samlad.

Spara även det som misslyckas

Radera inte svaga försök ur berättelsen. Ett misslyckande kan visa att ett särdrag är skört, att instruktionen är tvetydig eller att prototypen bara flyttar felen mellan grupper. Markera däremot tydligt vilka körningar som var felsökning och vilka som ingår i den planerade jämförelsen.

Reproducerbarhet betyder i projektet att en annan person kan följa den dokumenterade proceduren med samma tillgängliga versioner och kontrollera om resultaten återkommer. Samma slumpfrö räcker inte om data, kod eller systemversion skiljer sig. Ett fjärrsystem kan dessutom ändras utan att du styr det. Då ska du redovisa vad du kunde låsa och vad du inte kunde låsa.

Milstolpe: frys prototypen

Välj en prototypversion före sluttestet. Skriv varför den valdes med stöd i utvecklingsresultaten, inte sluttestet. Skapa en kontrollsumma eller annan versionsidentifierare om verktyget tillåter det. Gör sedan en torrkörning av proceduren utan att öppna de dolda testsvaren.

Låt en kamrat läsa loggen och försöka peka ut exakt vilken version som ska testas. Om två filer, instruktioner eller resultat kan blandas ihop är dokumentationen inte färdig.