Hur jag bygger frågebanker som inte överanpassas till ett facit
Om en användare kan memorera formen på frågorna i stället för kunskapen har träningssystemet lärt ut databasen, inte ämnet. Det är särskilt lätt att råka bygga så när samma question IDs återkommer ofta.
Om en användare kan memorera formen på frågorna i stället för kunskapen har träningssystemet lärt ut databasen, inte ämnet. Det är särskilt lätt att råka bygga så när samma question IDs återkommer ofta.
Jag skiljer kunskapsenhet från frågevariant
En kunskapsenhet kan ha flera sätt att testas:
Poängen är inte variation för variationens skull. Varianterna ska kräva samma underliggande kunskap utan att samma ordsekvens blir facit.
Varje fråga är mer än en fråga och ett svar
För att en kunskapsenhet som K-042 ska gå att förvalta i skala måste varje fråga bära egen metadata, inte bara text och rätt svar: question_id, knowledge_area, source_topic, difficulty, question_type, correct_answer, distractors, explanation, source_reference, review_status och language_versions. Då går det att analysera banken i stället för att bläddra i en stor JSON-fil — bland annat genom att kontrollera coverage: hur många frågor finns per kunskapsområde, innan luckorna upptäcks av att en användare råkar möta samma sak fem gånger.
En genererad fråga är heller inte automatiskt en produktionsfråga. Jag använder explicita statusar i stil med DRAFT -> FACT_CHECKED -> PEDAGOGICALLY_REVIEWED -> TRANSLATION_READY -> ACTIVE, så att "vi har 800 frågor" inte blandas ihop med "vi har 800 godkända frågor". När strukturen finns på plats blir AI:n dessutom bättre på att variera formuleringen utan att av misstag byta vad frågan faktiskt testar.
Distraktorer ska representera riktiga missförstånd
Slumpmässiga felalternativ gör frågan lätt. Jag försöker hellre bygga distraktorer från närliggande begrepp, vanliga sammanblandningar eller rimliga men felaktiga slutsatser.
De måste förstås faktagranskas så att två svar inte råkar bli försvarbara.
Urvalet behöver minne
Vid träning vill jag veta vilka knowledge claims personen redan sett, vilka som besvarats fel och vilka som behöver repetition. Då kan systemet balansera:
- nya frågor,
- svaga områden,
- spacing/repetition,
- total coverage.
Ett facit i sig är inte vägledning
Ett provresultat säger hur det gick, men ganska lite om vad personen bör göra härnäst. Jag löser det under själva språkmodellen: varje svar kopplas till en kunskapsenhet, så att systemet först kan räkna deterministiskt — antal försök, rätt, fel, senast sedd och en confidence-nivå per kunskapsområde. AI:n behöver då inte gissa vilka frågor som hör ihop; den relationen finns redan i datamodellen, och kan i stället göra det den är bra på: sammanfatta svaga områden på begriplig svenska, föreslå vad som bör tränas först, förklara skillnaden mellan två begrepp som ofta blandas ihop och sätta ihop ett kort repetitionspass från redan godkända frågor.
Ett enda fel är dock inte alltid en kunskapslucka — det kan vara slarv eller en tvetydig fråga — så jag väger in flera observationer och helst olika frågevarianter innan systemet drar en stark slutsats. Målet är att gå från "du är svag på samhällskunskap" till något som faktiskt går att agera på: vilka tre frågor som missades, vilket område de hörde till och vilket nästa pass som föreslås.
Provsimulering ska inte visa hela banken
I ett provläge vill jag samplea från en blueprint, inte ta "alla frågor från kapitel 3". Det minskar memorering och gör flera försök meningsfulla.
Ett dåligt mått är rå accuracy
Om användaren får samma fråga fem gånger kan 100 procent rätt säga väldigt lite. Jag vill hellre se performance per knowledge claim och hur den håller när formuleringen ändras.