TDDD92 AI-projekt

Slutrapporter i TDDD92

Vid kursens slut ska två slutliga rapporter lämnas in:

• En individuell slutrapport, som är en utökning av den individuella utredningsrapporten med nya avsnitt som även täcker det som har gjorts under projektarbetet.

• En kortare gemensam grupprapport, som täcker gemensamma delar i projektarbetet.

Här beskriver vi i princip hur de idealiska rapporterna skulle se ut. Man kanske inte alltid kan uppnå den perfekta beskrivningen i alla hänseenden, men det visar åt vilket håll man ska sikta.

Fokusera gärna extra mycket på tydlighet och precision i beskrivningar och resonemang. Luddighet och otydlighet är antagligen de vanligaste problemen i tidigare års rapporter.

Fråga om något är oklart!

Syfte

Slutrapporterna har en viktig roll i examinationen för projektmomentet. Givetvis tittar vi även på annat, som t.ex. resultatet av den implementation ni har gjort, men i rapporterna har ni en särskilt bra chans att ge oss mycket av den information vi kan basera betyget på. Det är också här som ni kan dra vår uppmärksamhet till det ni vill visa upp som en bas för ett högre individuellt betyg på projektet! (Detta kan även gälla sådant som t.ex. redan har diskuterats på seminarier och redovisningstillfällen.)

Se även information om delbetyg och kursbetyg.

Gruppens slutrapport

Gruppens slutrapport ("grupprapporten") ska beskriva arbetet på gruppnivå, och detta kräver typiskt 2-3 sidor information. Kortare rapporter är oftast inte tillräckligt informativa. Längre rapporter innehåller oftast information som inte behövs.

Rapporten är en aning mindre formell än den individuella utredningen / slutrapporten. Vi granskar inte språk och struktur men rapporten måste fortfarande vara tydlig och inte tvetydig eller svårläst. Den ska också följa samma stilmall som den individuella rapporten.

Vi förväntar vi oss följande information i egna rubriksatta avsnitt (lägg gärna till underrubriker men ändra inte på huvudrubrikerna):

• (Titel med kurskod, årtal, samtliga gruppmedlemmar med namn och LiU-ID)

• Mål: En beskrivning av det mål gruppen har satt upp. Läsaren (vi) känner redan till det generella målet med kursen! Det vi vill veta är: Vad har gruppen valt att fokusera på av alla de möjligheter som finns inom kursen (hur har ni profilerat er agent)? Vad har ni valt att hoppa över och inte fokusera på, och varför har ni tillsammans gjort dessa val?

  Även om ni inte har gjort en tydlig struktur för detta från början har ni säkert gjort mer eller mindre medvetna val i fråga om vad ni ser som viktiga delar och vad ni inte satsar på. Det kan vara till hjälp i bedömningen av arbetet.

• AI-tekniker: En mycket kortfattad punktlista på de AI-tekniker ni har valt att implementera. Detta kan vara på formen "Applicerat FOO-learning tillsammans med XYZ-search för att bestämma var och hur ABC ska utföras". Beskriv också vem eller vilka som har arbetat på detta. Var och en får mycket mer utrymme att beskriva teknikerna i den individuella delen, så var tydliga men håll det översiktligt. Poängen är att få en översikt över hela gruppens arbete, inte att förstå alla detaljer i varje individs arbete.

• Struktur och integration: En konceptuell beskrivning av den övergripande strukturen hos agenten som har utvecklats.

  Detta handlar alltså inte alls om kod, funktioner, klasser och källkodsfiler, utan vi vill förstå på en hög nivå hur allt är tänkt att fungera, hur de olika funktionaliteterna (AI och andra) är integrerade, och hur agenten egentligen tar sina beslut.

  Några exempel på frågor som kan besvaras av rapporten: Hur "drivs" agerandet framåt så att agenten faktiskt gör något? Hur och av vem används / anropas de olika individuella funktionaliteterna? Hur är alla funktionaliteter "kopplade" till varandra, hur interagerar de? "Vem" tar olika beslut? Hur och var skapas, hanteras och används olika sorters information?

  Diagram är mycket välkomna som en del i förklaringarna och rekommenderas starkt.

  När man har läst beskrivningen ska man förstå, på en hög abstraktionsnivå, att "aha, det är så agenten jobbar när den gör det jag ser i demonstrationen". Detta är bland annat kopplat till kursmålet att integrera AI-tekniker i system. En direkt koppling till olika funktioner, klasser, filer och andra implementationsdetaljer är inte önskvärd.

• Slutsatser: Slutsatser kring resultatet. Detta gäller alltså helheten, medan de enskilda teknikerna främst kan utvärderas i de individuella delarna av rapporten.

  Exempel på frågor att dra slutsatser om: Vad har vår agent för styrkor och svagheter? Varifrån kommer dessa styrkor och svagheter? Vad hade kunnat krävas för att slå den inbyggda motståndaren på nästa svårighetsnivå? Hur gick det i tävlingar mot andra agenter (inbyggda och andra gruppers agenter), och varför (styrkor och svagheter)? Vad hade gruppen gjort annorlunda om man påbörjade projektet idag med de kunskaper man har fått?

  Tänk på att motivera slutsatserna och kom ihåg att våra frågor bara är exempel för er inspiration, inte ett frågeformulär.

Den individuella slutrapporten

Den individuella slutrapporten är alltså en utökning av den ursprungliga utredningsrapporten.

Utredningsdelen

Den individuella slutrapporten inleds med den ursprungliga utredningsrapporten. Ändra titeln så att den innehåller ordet "slutrapport"!

Vi förväntar oss att du har tagit hänsyn till den återkoppling du har fått efter din första inlämning, både språkligt och i fråga om själva utredningen, och att du har uppdaterat rapporten enligt detta.

Om du har kommit till nya teoretiska slutsatser får du uppdatera utredningen med de slutsatserna. Men tänk på att du inte ska uppdatera inledningen med avseende på dina praktiska experimentella slutsatser som du har fått från själva implementationen. Den teoretiska utredningen kanske ledde dig till att tro att teknik A skulle vara bäst, medan du sedan insåg att det faktiskt var teknik B som fungerade bättre. Då varken behöver eller ska du uppdatera utredningen med den informationen. Den teoretiska utredningen ska fortfarande utgå från den information som du kunde få från de artiklar som du läste.

Har du bytt teknik? Om du byter till en annan av de tekniker som du jämförde i den ursprungliga rapporten är det inga problem. Om du byter till en helt ny teknik kan du ha kvar din ursprungliga beskrivning, och sedan beskriva den nya tekniken i den nya avslutande delen av rapporten.

Fråga om något är oklart!

Den utökade delen: Vid större förändringar i planeringen

Om du har bytt problem, teknik eller liknande, behöver du se till att tillräckligt mycket framkommer om det nya upplägget, utan att för den skull ta bort det du har gjort i den ursprungliga utredningsrapport. Vi behöver t.ex. få en beskrivning av nya tekniker eller nya sätt att modellera så vi kan utvärdera utifrån de teknikerna.

Ta upp detta till diskussion med oss så kan vi diskutera vad som är bäst i just ditt fall. Skapa en issue med lite information kring vad som har förändrats under höstens gång så utgår vi från det i vår diskussion.

Den utökade delen: När du fortsätter enligt den ursprungliga planen

Givet att du fortsätter enligt den ursprungliga planen från utredningsrapporten vet vi redan vilket problem och vilken teknik du ska använda. Utredningsdelen innehåller också en del information om modellering med mera. Då ska du utöka din rapport med fokus på följande information, som kan se omfattande ut men normalt ska få plats på cirka 2 sidor:

• Faktisk användning i StarCraft II: Hur har du faktiskt applicerat dessa tekniker i StarCraft? Detta är en viktig del av betygsunderlaget!

  Du har redan beskrivit hur du tänkte modellera problemet i StarCraft, mer eller mindre. Nu har du faktiskt genomfört modelleringen och du har mer konkret information om hur modellen blev. Låt den ursprungliga sektionen om användning av StarCraft II vara kvar i den första delen av rapporten, och lägg till den nya sektionen Faktisk användning i StarCraft II i den nya delen av rapporten.

  Här bör du beskriva hur du har modellerat problemet för att den valda tekniken ska lösa relevanta problem i StarCraft-världen. Till exempel kan detta inkludera val eller utveckling av features, variabler, nätstrukturer för BN, tillståndsrymder, rewardfunktioner, heuristiker, fältstyrkor, med mera. Var tydlig! Exempel: Om du använder ett sökträd, vad är då rotnoden, vad motsvarar bågarna, och vilka barn finns till en nod? Om du använder Bayesianska nätverk, vad motsvarar noderna? Om du använder potentialfält, vad motsvarar potentialerna, när räknas de ut och uppdateras, och så vidare? Nu har du alla detaljer. Beskriv dem tillräckligt tydligt!

  Om du har undersökt andra alternativ för hur du kunde ha applicerat algoritmen bör det också framgå, speciellt om du faktiskt har utvärderat de olika alternativen. Om du har fått delar av modelleringen från en StarCraft-artikel, istället för att välja och utveckla en modellering själv utifrån en generell funktionalitet (såsom A* som är mycket generell), ska detta framgå tydligt.

  Om du har använt replays eller andra data, tala då om både var de kommer från och vilka replays du har använt. (Om detta tar mycket plats går det bra att ta extra sidor till en tabell på slutet.)

  Var noga med att tala om vad resultatet blir. Exempel: Om du arbetar med byggnadsordning, talar du då om vad som ska byggas i nästa steg, eller vad som ska byggas i flera steg framåt? Eller talar du inte bara om vad som ska byggas, utan ser även till att det faktiskt blir byggt?

  Små diagram och figurer kan vara mycket användbara för att förklara och är starkt rekommenderade.

  Det är fullt tillåtet att återanvända text från den ursprungliga sektionen, så länge som den uppdateras med det du har gjort under andra kursperioden. Diskutera gärna också om dina inledande idéer fungerade eller om/varför/hur du har behövt tänka om / modellera om efter dina praktiska erfarenheter!

  Förtydligande: Intuitioner är viktiga, men det är också tydlighet och precision. Vi är inte ute efter en ungefärlig beskrivning för att kunna se att "det låter väl rimligt att använda ett liknande tillvägagångssätt". Vi är snarare ute efter att (i teorin) kunna upprepa det du gjorde genom att följa dina instruktioner! Så om du beräknar något med hjälp av ett avstånd, vad är då den exakta formeln du har använt? Om du skapar en heuristik, exakt hur beräknas den? Om du skapar en tillståndsrymd, exakt vilka tillstånd finns? Beskriver du inte detta kan läsaren inte återanvända dina insikter och inte veta exakt vad det var som egentligen fungerade.

• Kopplingar: En beskrivning av kopplingar till den övriga implementationen. Detta är viktigt då implementation och integration ingår i kursmålen!

  Är din implementation (alternativt dess in/utdata) mer eller mindre tätt kopplad till andra tekniker eller andra gruppmedlemmars individuella arbete? I så fall, hur? Vilka data får du från vem? Vilken information ger du till vem? Eller är den i princip fristående från övriga specifika AI-tekniker?

  Hur är den i övrigt inkopplad i agenten som en helhet, så att den faktiskt används när agenten spelar?

  Notera att "hur" är tänkt att tolkas på en högre abstraktionsnivå. Vi är inte intresserade av vilka Python-funktioner som anropar varandra, utan av hur teknikerna fungerar ihop, hur de hjälper varandra, hur de beror på varandra, vilken sorts information de ger och får – eller som ett alternativ, hur och varför de kan användas helt oberoende av varandra utan att den ena behöver känna till den andra. Ett enkelt diagram kan ofta vara bra för förståelsen.

  En övergripande beskrivning finns i gruppdelen, men där är fokus på helheten, så att säga. Här får du lite mer plats att diskutera just din egen integrering.

  Diskutera gärna hur integration och "inkoppling av funktionaliteterna" har påverkat ditt arbete. Finns det till exempel ytterligare krav som ställs på din teknik för att integrationen ska fungera? Har förenklingar skett genom att fler personer kan dela på implementerad funktionalitet?

• Resultat: En beskrivning, analys och utvärdering av resultatet för just din specifika AI-teknik.

  Detta är också en mycket viktig del: Att kunna utvärdera tekniska lösningar är ett av de uttryckliga kursmålen som måste examineras! Tänk också på att inte bara ge subjektiva värderingar utan fokusera på en motiverad och objektiv bedömning av det tekniska resultatet.

  Utvärderingen kan inkludera jämförelser mellan olika tekniker eller handla om resultatet när man applicerade en specifik teknik. Vad blev resultatet när du applicerade din teknik i StarCraft? Blev det bättre eller sämre när din funktionalitet aktiverades, jämfört med om man körde agenten utan din funktionalitet? Hur mycket, på vilket sätt, varför?

  Förtydligande: Vi pratar här om resultatet för agenten. Det handlar alltså inte bara om att t.ex. "byggnadsordningen blev annorlunda", även om det också är intressant att se detta (och på vilket sätt den blev annorlunda). Det vi är ute efter i projektet är en agent som spelar StarCraft II på ett bra sätt, och frågan är alltså på vilket sätt den valda tekniken bidrog till att nå närmare detta mål. "I och med att vi bygger i en bättre ordning händer X och det hjälper oss mot fienden genom Y".

  Förtydligande: Den huvudsakliga meningen med detta avsnitt är inte att man ska motivera sin egen "prestation", alltså varför man nådde dit man nådde. Vi är medvetna om att kurstiden inte alltid räcker för att man ska uppnå den perfekta implementationen, och mycket kan hända som man inte har kontroll över. Det handlar mer om att analysera varför den allmänna tekniken och den specifika implementationen gav vissa resultat, än om att analysera varför man själv kom dit man kom.

  Förtydligande: Det handlar inte heller om att man måste motivera varför det egna arbetet gjorde att agenten spelade mycket bättre. Det kan hända att det inte alls blev bättre. Beskriv detta och utvärdera varför det blev som det blev.

  Förtydligande: När vi säger "hur mycket, på vilket sätt, varför?" menar vi också att vi vill se tydliga beskrivningar av resultaten och hur de yttrade sig i spelet. Går det att se hur mycket oftare man vinner? "Lite oftare", är det 10% oftare eller 50% oftare? Ofta går det att beskriva mer kring skillnaderna: "förut gjorde den så här men med den nya tekniken beter den sig så här istället"... med en del detaljer som gör att man förstår det hela, och varför det inträffar. Det handlar alltså inte bara om en allmän slutsats om att "det gick väl bra", utan om att visa hur man uppfyller lärandemålet att kunna utvärdera AI-tekniker och hur de påverkar ett system.

  Vissa kanske också har delresultat att rapportera: Gör man på sätt A blir resultatet X, gör man på sätt B blir resultatet Y. Varför blev det så?

• Slutsatser kring AI-tekniker: Individuella slutsatser kring ditt arbete med AI-tekniker i projektet. Hur svårt var det att applicera en viss teknik? Gick det som du förväntade dig?

• Insatser i gemensamt arbete: En kort beskrivning / sammanfattning av vad du har gjort i den gemensamma implementationen och ungefär hur stor del av tiden du har lagt på den aspekten av agenten.

• Övrigt: Om du vill kan du även ta upp annat som du tycker kan vara relevant för bedömningen av hur du har uppnått kursens mål.

Det går utmärkt att lägga in nya underavsnitt för att dela upp de existerande avsnitten. I övrigt ska rapporten följa den struktur som ges ovan.

Tyngdpunkten i den individuella delen ska vara på det du själv har gjort inom dessa områden (modellering, utvärdering, eventuell algoritmutveckling, med mera). Ju mer du har fått från en artikel, desto större tyngd behöver läggas på andra områden. Har man till exempel fått både algoritm och modellering från en StarCraft-specifik artikel behöver man lägga extra mycket arbete på utvärderingen.

Ärliga och opartiska bedömningar!

Det är viktigt att göra en ärlig utvärdering i rapporterna.

Vi väntar oss inte att alla har valt den bästa tekniken redan från början, eller att alla har hunnit göra den perfekta implementationen. En viss miniminivå är visserligen nödvändig enligt kursmålen, men kursen har alltför begränsad tid för att man ska hinna med allt det man hade velat göra. Man ska alltså inte känna att man behöver skönmåla resultatet för att det ska bli godkänt.

Tvärtom är det mycket viktigare att visa insikter om hur det egentligen gick. Detta är en viktig del av kursmålen -- att kunna utvärdera. Det kan man göra genom att tydligt utvärdera t.ex. vilka försök som fungerade bra och vilka som inte fungerade bra (kanske AI-tekniken inte var lämplig trots allt?), och motivera varför det var så. Precis som i den individuella utredningen är det också viktigt att dra lagom starka slutsatser -- inte för svaga men inte heller starkare än vad man kan ge tydliga motiveringar för.

Hur formell är slutrapporten?

De nya delarna av slutrapporten är mindre formella än den del som gäller den individuella utredningen, på så sätt att de nya delarna inte ska språk- och strukturgranskas. Det är helt enkelt en rapport över era projektresultat.

Tänk ändå på att det ska vara klart och tydligt vad ni menar med det ni skriver, och att det ska framgå vad ni har gjort i projektet. Återigen: Detta är en av era viktigaste möjligheter att visa upp era kunskaper och framsteg, vilket ni på ett eller annat sätt behöver visa oss för att vi ska kunna motivera ett godkännande eller ett högre betyg.

Precis som i utredningsdelen behöver man inte beskriva allmänna egenskaper hos StarCraft, eller det allmänna syftet med grupparbetet i TDDD92, då detta kan antas vara känt av läsaren (examinatorn och handledarna). Det går så klart bra att beskriva specifika delar av StarCraft som man vill koppla sina resonemang till!

Deadlines och granskningsmöjligheter: Individuell slutrapport

Vi har försökt vara tydliga med vad som gäller angående deadlines, men kombinationen av eget arbete med grupparbete + möjligheten att olika gruppmedlemmar blir klara vid olika tider gör att det kan bli knepigt att täcka samtliga fall på ett förståeligt sätt. Ställ frågor om något är oklart!

Om du redan har lämnat in din individuella utredningsrapport för en inledande granskning efter HT1 (i oktober/november):

• Om du är färdig med uppdateringar och har lagt till de nya delarna i slutrapporten, kan du lämna in din individuella slutrapport för granskning och betygsättning till deadline fredag 2021-01-15. Detta gäller då båda rapportdelarna och båda kursmomenten i LADOK.

• Om du är färdig med uppdateringar i den individuella utredningsrapporten men inte har hunnit bli klar med de nya delarna i slutrapporten, kan du ändå lämna in din individuella utredningsrapport för granskning och betygsättning till deadline fredag 2021-01-15. Detta gäller då bara utredningsmomentet i LADOK, vilket är separat och kan ge egna HP utan att slutrapporten behöver vara klar.

• Om du inte känner dig färdig (med uppdateringar, implementation eller att skriva de nya avsnitten), har du möjlighet att vänta med inlämningen till ett extra inlämningstillfälle efter VT1 (mars/april).

• Det kommer också ett inlämningstillfälle i augustiperioden 2020.

Om du inte har lämnat in din individuella utredningsrapport tidigare:

• Om den individuella utredningsrapporten är redo kan du lämna in för inledande granskning till deadline fredag 2021-01-15.

  Du kan så klart lämna in en fullständig rapport inklusive den avslutande delen, men normalt får du ändå bara tillbaka de inledande kommentarerna på utredningsdelen. Detta återkopplingssteg är en viktig del av kursen som normalt inte kan hoppas över.

  Den slutliga rapporten kan sedan lämnas in för granskning och betygsättning vid ett extra inlämningstillfälle efter VT1 (mars/april).

• Om den individuella utredningsrapporten inte är redo ännu, kan du vänta ytterligare ett steg och lämna in för inledande granskning i mars/april samt för slutlig granskning i augustiperioden.

Plussning är möjlig vid inlämningstillfällena i mars/april och augusti. När nästa års kursomgång börjar finns ingen garanti att plussning kommer att fortsätta vara möjlig, eftersom kursens innehåll ständigt uppdateras och justeras. (På en tenta kan plussning vara möjlig under lång tid eftersom det då är upp till studenten att hålla sig uppdaterad med det nya kursinnehållet och ta den nya tentan så som den ser ut efter att kursen har förändrats. För den här kursen skulle det motsvara att genomföra hela projektet från början så som det ser ut efter att kursen har förändrats.)

Komplettering kan också kräva mer arbete när nästa kursomgång har börjat.

Som sagt, fråga om något är oklart. Det är svårt att täcka alla tänkbara fall.

Deadlines och granskningsmöjligheter: Grupprapport

Den gemensamma grupprapporten har samma deadlines som ovan.

Gruppmedlemmar som inte är färdiga med sitt individuella arbete bör ändå bidra till grupprapporten, som då ska beskriva vilka delar som inte är avslutade och hur långt man ändå har kommit med dem. Medlemmen som inte var helt färdig när rapporten skrevs lämnar sedan också in en uppdaterad grupprapport (där de egna delarna är uppdaterade) tillsammans med sin individuella slutrapport när den är färdig.

Om någon medlem inte alls kan bidra till den ursprungliga grupprapporten får övriga medlemmar diskutera detta med examinatorn, så får vi komma fram till hur vi hanterar detta i det specifika fallet. Detta kommer i vilket fall som helst inte att hindra er att lämna in en grupprapport för de som är färdiga.