FAQ
Hva er beste praksis for å utvikle en effektiv AI-tutor?
Automatisk maskinoversettelse av denne engelske siden, ennå ikke korrekturlest av en morsmålstalare.
Tutoren din er tre uker unna en pilot. Chatten fungerer, modellen forklarer en derivert rent, og den interne demoen fikk applaus. Så spør noen fra undervisningssenteret om det spesifikasjonen din ikke har noe felt for: etter en termin med denne tingen, vil studentene løse et problem når den ikke er i rommet? Det du har, er en funksjonsliste. Det du ikke har, er én setning som sier hva studenten må kunne gjøre alene til slutt.
En tutor er en policy pakket rundt en chatbot, og policyen avgjør om læring skjer. Navngi det kognitive arbeidet studenten må gjøre, få systemet til å kreve det (et forsøk før hjelp, en hintestige som trappes ned, en kontroll modellen ikke kan jukse seg unna), og evaluer med tutoren slått av. Modellkvaliteten avgjør hvor god samtalen føles. Policyen avgjør hva studenten kan i juni.
Kortversjonen
1. Skriv målet som en påstand om ytelse uten støtte, og utled hver funksjon fra den. Hvis en funksjon ikke kan spores tilbake til den setningen, er det en demofunksjon.
2. Bygg studentmodellen fra belegg du kan logge, og lagre hver diagnose som en hypotese med en konfidensverdi i stedet for som et faktum.
3. Fest hjelpestigen i koden, med navngitte trinn, og la grensesnittet koste studenten noe for hvert steg nedover.
4. Forankre innholdet i dine egne materialer, og overlat regning, algebra og kodekontroll til deterministiske verktøy som ikke kan hallusinere.
5. Test undervisningssvikt over hele samtaler: lekket svar, sykofanti, forsterkning av misoppfatninger, instruksjonsdrift.
6. Mål med en avvenningsfase og en forsinket test, ikke med en tilfredshetscore.
Skriv målet som en påstand om ytelse uten støtte
Tre lister, skrevet før noen velger en modell:
- Hva studentene skal kunne eller være i stand til etterpå.
- Hvilket kognitivt arbeid de selv må utføre.
- Hva tutoren kan gjøre for dem.
Litteraturen om intelligent veiledning gjør poenget at effektivitet avhenger av pedagogisk design og ikke av modellkapasitet alene, og svikten er lett å bygge ved et uhell. En tutor som er optimalisert for «fullfør problemet», vil undergrave en tutor som er optimalisert for «lær å løse problemet», samtidig som den består hver funksjonstest du skriver, fordi begge produserer riktige sluttresultater. Forskjellen ligger i hva studenten gjorde mellom spørsmålet og svaret.
Den andre listen er der utviklingsteam blir konkrete. Ta en mestringsetikett som «mestring av derivasjon» og nekt å la den bety å produsere den riktige deriverte. Del den opp i å gjenkjenne når en derivert er relevant, tolke den som en momentan endringsrate, velge regelen, gjennomføre prosedyren, forklare hvorfor valget var riktig, kontrollere om svaret er rimelig, og anvende det på et ukjent problem. Hver av disse er en egen ting å logge, og hver av dem tilsier en annen respons når den mangler. Denne oppdelingen er også forsvaret mot fellen med det riktige svaret, der en student når riktig svar gjennom feil resonnement og analysene dine registrerer en suksess. Å fange fellen med det riktige svaret og Når hjelp ikke hjelper beskriver begge versjoner av denne svikten i produksjon.
Bygg studentmodellen før samtalen
Studentmodellen holder to slags tilstand: anslag per begrep (grense: under utvikling, potensregel: mestret, produktregel: under utvikling, kjerneregel: ikke demonstrert) og hypoteser om misoppfatninger med belegget og konfidensen bak hver. Hold dem atskilt. Begrepsanslaget er det som driver valget av vanskelighetsgrad. Hypotesen er det som driver neste spørsmål.
Vær forsiktig med å la en LLM gjøre diagnosen på egen hånd. Benchmarking fant at LLM-tutorer kunne gjenkjenne klart riktig resonnement, men likevel avvise gyldige alternativer eller godta feil resonnement. En modell som ser det gode tilfellet og feilleser det tvetydige, svikter nettopp de studentene som trenger hjelpen. For områder der det får konsekvenser, er arkitekturen som overlever strukturert diagnose pluss fleksibel LLM-dialog, den ordningen Bekrefte det riktige, overse resten beskriver: din egen detektor fastslår hva studenten sannsynligvis gjorde, og modellen skriver samtalen rundt det funnet.
Gi diagnosen en eksplisitt sekvens som modellen ikke kan hoppe over: oppdage, verifisere, svare. Modellen kan foreslå en misoppfatning som en hypotese, men må så verifisere den mot studentens faktiske arbeid eller et målrettet spørsmål før tutoren svarer på den. Uten det trinnet finner systemet opp belegg og veileder deretter studenten for en feil de ikke gjorde, noe som både er ubrukelig og lett fornærmende.
Belegg som er verdt å logge, omtrent i rekkefølge etter nytte: nylige forsøk med mellomsvarene sine, demonstrert kunnskap per begrep, hjelpesøkende atferd (som i seg selv er et signal om selvtillit), og selvopplevd selvtillit der du samler den inn. Tilpass vanskelighetsgrad og hjelp fra den loggen, og behandle studentens siste prompt som ett innspill til den. En enkelt prompt er et dårlig anslag på hva en student kan, og en tutor som reagerer på den, vil kaste seg fram og tilbake.
Fest hjelpestigen, og la grensesnittet ta betalt for den
Skriv ned trinnene før du skriver en prompt, fordi stigen er en produktbeslutning med navngitte tilstander, og en toneinnstilling kan ikke uttrykke den. En sekvens som fungerer:
- Selvstendig forsøk.
- Metakognitivt spørsmål om hva studenten har prøvd.
- Konseptuell pekepinn.
- Identifiser den relevante regelen.
- Sett opp en del av problemet.
- Utført mellomsvar.
- Utført løsning.
- Studenten forklarer løsningen.
- Studenten løser et sammenlignbart problem uten hjelp.
Støtten trappes ned etter hvert som kompetansen øker, og det er mekanismen som står i sentrum for støtte. Å se en utført løsning demonstrerer ikke mestring, så enhver økt som når trinn sju, skylder deg trinn ni før den teller som fullført.
Det kausale belegget for å bygge stigen i det hele tatt kommer fra et felteksperiment der et ubeskyttet GPT-grensesnitt økte assistert matematikkytelse og reduserte etterfølgende ytelse på eksamen uten hjelp. En tutor som ga hint, fjernet i stor grad den læringsstraffen (Generativ AI uten sikkerhetsmekanismer kan skade læring). Begrensningen er arkitektonisk. Den samme modellen, gitt en annen hjelpeatferd, ga motsatte resultater på det målet som betyr noe.
Et større randomisert felteksperiment med mer enn 6 000 ungdomsskoleelever på en mestringsbasert øvingsplattform viser hvordan stigen ser ut i loggene. Elever som ble tildelt AI-støtte, gikk saktere fram og forsøkte færre spørsmål, og de svarte mer korrekt. Den tydeligste mekanismen var korrekthet på neste forsøk etter en feil: det trengtes færre forsøk for å komme tilbake til et riktig svar. Det mønsteret er en produktiv nedbremsing, og det er signaturen en hintestige skal etterlate (Å gjøre AI-veiledning produktiv).
Den samme studien gir en advarsel om dine egne dashbord. Kravet om tre riktige svar på rad hevet plattformdefinert mestring kraftig, uten å gi påvisbare gevinster på en forsinket test en uke senere. Det sterkeste belegget fra forsinket test dukket bare opp der AI-en satt inne i mestringsarbeidsflyten (koeffisient 0,085), ikke der den var tilgjengelig som frittstående tilgang. Hvis suksessmålet ditt er en streak-teller, vil du levere et system som optimaliserer streaken.
Friksjon i grensesnittet hører hjemme i samme designrunde. Ubegrensede hint bak en synlig knapp gjør hele stigen til en snarvei, og for tidlige hintforespørsler med overfladisk lesing er assosiert med lavere læringsutbytte. Å erstatte [Hint][Hint][Hint][Show Answer] med spørsmålene «hva har du prøvd?» og «hvilken del blokkerer deg?» (å velge en regel, sette opp likningen, gjøre algebraen, forstå begrepet) koster én skjerm og sender studenten til det trinnet de faktisk trenger. Det gir deg også loggdataene som forteller hvilket trinn de til vanlig hopper over.
Overlat de kontrollerbare delene til en kontrollør
Forankre genereringen i instruktørgodkjent materiale: lærebokavsnitt, kursnotater, utførte eksempler, terminologi, godkjente metoder, notasjon, oppgaveregler, retningslinjer og læreplanrelaterte ressurser. Gjenfinningsforsterket generering mot det korpuset reduserer hallusinasjonsrisiko og fjerner den ikke, slik RAG legger det fram. Vis referanser eller opphav i grensesnittet der en student kan kontrollere en påstand, fordi referansen er det som gjør forankringen reviderbar i ettertid.
Forankring gjør også en jobb som nøyaktighetsmålene ikke fanger. Et kurs har godkjente metoder, og en tutor som introduserer en matematisk gyldig teknikk som kurset ikke bruker, har lært studenten noe de vil bli trukket for. Gjenfinning fra kurslaget er hvordan tutoren holder seg innenfor metodemengden.
For områder med formelt kontrollerbare svar, legg til deterministiske verktøy: kalkulatorer, symbolske matematikksystemer, kodekjøring, kunnskapsgrafer, regelbaserte validatorer og fagspesifikke løsere. Arbeidsdelingen er det viktige. LLM-en håndterer forklaring og dialog. Den symbolske motoren verifiserer algebraisk ekvivalens, deriverte, integraler, likningsløsninger, kritiske punkter og numeriske tilnærminger. Et feil mellomsvar som verifikatoren fanger, blir et veiledningsøyeblikk. Et feil mellomsvar som ingenting fanger, blir en misoppfatning studenten bærer med seg til eksamen.
Krev at studenten handler på tilbakemeldingen
Tilbakemelding som sier «Riktig», «Feil» eller «Godt jobbet», er en scoringshendelse i undervisningens grensesnitt. Kunnskapsbasen behandler tilbakemelding som en sløyfe av tilbud og opptak: tilbakemelding støtter læring når studentene forstår den og handler på den, og den andre halvdelen er den halvdelen systemene vanligvis hopper over. Bygg tutoren slik at den navngir resonnementsteget som er involvert, sier hva som må revurderes, gir én konkret neste handling, og ber studenten forutsi eller forklare før tilbakemeldingen avsløres.
Sekvensen som bærer dette, er student først, AI andre, student igjen. Studenten genererer, velger, begrunner, vurderer eller reflekterer; tutoren svarer; studenten gjør noe med svaret. Design turstrukturen slik at dette ikke er valgfritt. Et system der modellen kan produsere tre avsnitt som svar på ett spørsmål, lærer studenten å spørre og lese.
Det langsiktige målet er internalisering. Studentene skal ende opp med å kjøre tutorens spørsmålsstilling og problemløsningsstrategier selv, som er agens-argumentet og grunnen til at stigen har et øverste trinn der tutoren er taus.
Design for det som skjer i runde førti
Pedagogisk sikkerhet er en egen testpakke, atskilt fra vanlig chatbotsikkerhet, og de fleste team leverer bare den andre. Toksisitet og motstand mot jailbreak sier ingenting om hvorvidt tutoren vil overlevere et svar til en student som spør to ganger, si seg enig i en feil metode fordi studenten hørtes trygg ut, gli ut av kursets metodemengde i løpet av en lang økt, eller dytte en student inn i kognitiv avlasting. Sykofanti er den som kommer gjennom først, fordi enighet leses som vennlighet og preferansedataene dine belønner det.
Test for lekket svar, forsterkning av misoppfatninger, overdreven enighet, upassende vanskelighetsgrad, avlasting, skjev behandling, tap av studentens agens, instruksjonsdrift og overkonfidens i feil forklaringer. Kjør testene på utvidede samtaler, ikke enkeltturer, fordi pedagogisk svikt akkumuleres: de ti første turene kan være eksemplariske og den ellevte kan oppheve økten. En tutor skal være vennlig og korrekt samtidig, også når studenten insisterer på en misoppfatning. Pedagogisk sikkerhet og AI-tutorsikkerhet og pedagogisk skade legger fram feiltaksonomien.
Sett dataarkitekturen i samme designdokument
Samle bare studentdata som er pedagogisk nødvendige, og vær i stand til å si hvorfor hvert felt finnes. Der du har vedvarende minne eller en studentmodell, gjør formålet synlig for studenten, gi dem passende kontroll over den, beskytt sensitiv informasjon, definer lagringstid, og ruter beslutninger med konsekvenser til en instruktør eller et annet menneskelig kontrollpunkt. En studentmodell som stille akkumulerer et konfidensanslag studenten aldri ser, er et personvernproblem og et pedagogisk problem.
Revider atferd på tvers av språkbakgrunner, ferdighetsnivåer, kulturelle kontekster, tilgjengelighetsbehov og nivåer av forkunnskap og AI-erfaring. Ulik ytelse på samme mål er en feil med en student festet til seg, og den vil ikke dukke opp i ditt samlede nøyaktighetstall.
Én tilgjengelighetsbeslutning fortjener sin egen linje: ikke gjør avansert prompting til en forutsetning for god undervisning. Hvis tutoren bare underviser godt når en student skriver en omhyggelig prompt, har du bygget et system som favoriserer studenter som allerede vet hvordan de skal snakke med modeller. Tutoren bør hjelpe studentene med å formulere produktive spørsmål, som også er en metakognisjon-ferdighet verdt å ha.
Instrumenter avvenningsintervallet
Øktmål vil ikke fortelle deg om tingen fungerer. Svarnøyaktighet, samtalelengde, studentpreferanse, tilfredshet, oppgavefullføring og engasjement stiger alle for systemer som ikke lærer bort noe, fordi studenter liker hjelp og hjelp er lett å måle. Evaluer ytelse uten hjelp, forsinket retensjon, overføring til nye problemer, korrigering av misoppfatninger, studentens uavhengighet, opptak av tilbakemelding, og ulike effekter på tvers av studentgrupper. Evaluering av AI i utdanning har metodene, og Den manglende evalueringsaksen argumenterer for at atferd er konstruktet.
To studier skjerper regelen mot selvrapportering og korte horisonter. En pilot med 38 nybegynnerstudenter i programmering fant en sterk sammenheng mellom bruk av generativ AI og opplevd læring (rs=0,802, p<0,001), mens indikatorene for selvstendig framgang uten instruktørstøtte scoret lavest. Forfatterne kaller gapet en kompetanseillusjon og epistemisk gjeld, og det er nettopp gapet et tilfredshetsmål belønner (Generativ AI som uformell kognitiv tutor).
Mer grunnleggende: mest evaluering stopper i det øyeblikket hjelpen tar slutt. Dynamikken i kognitiv utvasking navngir intervallet etter avvenning som ikke måles, og formaliserer fire utfall: elastisk tilbakesprang, delvis platå, latent støtte og overgjenoppretting. Utvaskingskurven har en tidskonstant for gjenoppretting, et ledd for hvor fullstendig gjenopprettingen er, og en hystereseindeks som sammenligner gjenlæringsinnsats med opprinnelig innsats. Siden reversibilitet avgjør alvorlighetsgrad, argumenterer rammeverket for at planlagt praksis uten hjelp bør doseres etter gjenopprettingskurven i stedet for å debatteres som et prinsippspørsmål. Evalueringsplanen din trenger en avvenningsfase i tillegg til en umiddelbar ettertest, og det randomiserte belegget for at kortvarig hjelp demper senere ytelse uten hjelp er grunnen til å legge den tidlig.
Gi lærerne noe de kan redigere
Før utrulling, la lærere teste realistiske studentprofiler, vanlige misoppfatninger, grensetilfeller, fiendtlige prompter, tvetydige svar og lange veiledningssamtaler. Logg den pedagogiske svikten og før den tilbake til systemprompter, veiledningspolicyer, kunnskapskilder, sikkerhetsmekanismer, studentmodellregler og modellvalg. Et flytende svar kan fortsatt være pedagogisk feil, og en lærer er den eneste anmelderen som kan se det.
Lees systematiske gjennomgang av 29 K-12-studier beskriver hva denne oppfølgingen består av og hvor den bryter sammen. Lærer-intervensjon er en gjentakende firesyklus av overvåking, vurdering, intervensjon og orkestrering. AI-varsler, dashbord og automatiserte scorer «fører ikke automatisk til pedagogisk handling». Den sterkeste lærerstrategien gjennomgangen finner, er pedagogisk oversettelse: å velge ut, revidere, supplere, oppsummere eller slette chatbotens tilbakemelding i stedet for å sende den videre.
To designadvarsler følger, og begge motsier den vanlige kjøreplanen. Mer AI-informasjon er ikke bedre: systemer som kontinuerlig sender ut diagnostikk, overbelastet lærerne og trakk oppmerksomheten bort fra deres egen observasjon. Prioriter det som er verdt å handle på, gjør det tolkbare, og tilby anbefalinger i en form en lærer kan godta, endre, utsette eller avvise. Mer lærerstøtte er heller ikke bedre: å utsette intervensjonen slik at studentene kan arbeide selvstendig, er i seg selv ekspertise. Strukturelle forhold, altså tid til å gjennomgå data, klassestørrelse og muligheten til fysisk å nå gruppene som trenger hjelp, er en del av intervensjonen og ikke bakgrunnslogistikk. Et dashbord bygget for en lærer uten fri time blir ikke åpnet.
Tilfelle én: en kalkulustutor, der verifisering er billig
En kalkulustutor for første semester på universitetet bør heve det studentene kan løse og forklare selvstendig etter at den er fjernet, ikke maksimere riktig fullførte oppgaver. Matematikkveiledning er spesielt sårbar for overdreven støtte, for tidlig hintbruk og feil diagnose av studentens resonnement, og alle tre er synlige i loggene dine hvis du ser etter (matematikkutdanning).
Forankring og verifisering. En byggeprosess i seks lag: kursmateriale og instruktørens retningslinjer, så et gjenfinningslag, så en oppgavemotor og studentmodell ved siden av en symbolsk verifikator og en diagnostisk motor, så et pedagogisk policylag, så konversasjonsgenerering, så studenten, så tilbake inn i studentmodellen. Verifikatoren er grunnen til at dette designet er håndterbart. Den avgjør om et uttrykk er ekvivalent, en derivert riktig, et integral evaluert, et kritisk punkt funnet, og den gjør det uten å spørre modellen om dens mening.
Én interaksjon. For å derivere avslører en konvensjonell chatbot svaret. En læringsorientert tutor resonnerer internt at studenten deriverte begge komponentene, men multipliserte resultatene, en mulig produktregel-som- misoppfatning, og stiller et diagnostisk spørsmål først: hvilken regel gjelder når to funksjoner multipliseres? Så skriver studenten produktregelen symbolsk, setter opp og , og først etter det verifiserer tutoren det endelige uttrykket. Legg merke til hvor mye av veiledningen som skjedde før noen modellprosa nådde studenten.
Flere representasjoner. Koble symbolske prosedyrer til formelen, grafen, tabellen, en verbal tolkning og en fysisk endringsratekontekst. Prosedyrisk flyt og konseptuell forståelse ser identiske ut på et riktig utfylt ark og skiller lag på overføringsoppgaven.
Dashbordet. Vis samlet belegg i stedet for ugjennomsiktige vurderinger: «produktregel, 62 % demonstrert mestring; vanlige mønstre, 18 % utelater ett ledd, 11 % multipliserer deriverte». Individuelle diagnoser sendes ut som hypoteser med belegget som støtter dem, som også er det som gjør dem reviderbare for en lærer (forklarbarhet betyr mer for læreren enn for studenten her).
Evalueringsplanen. Ytelse med tutoren, ytelse på sammenlignbare problemer uten den, forsinket retensjon, overføring til ukjente problemer, kvalitet på konseptuell forklaring, korrigering av misoppfatninger, passende kontra for tidlig hjelpesøking, lekket svar, diagnostiske rater for falske positive og falske negative, og ulike utfall. Sammenligningen som avgjør prosjektet, er assistert mot senere uassistert. En student som går fra 60 % til 95 % med tutoren og blir liggende på 60 % alene, har ikke fått veiledning.
Tilfelle to: en skrivecoach, der fasen avgjør tillatelsen
Skriving har ikke ett riktig svar, så verifisering er skjønn og designarbeidet flytter seg til fasestyring. Kunnskapsbasen rammer inn skriving som en kognitiv, sosial og retorisk prosess, som betyr at et AI-skrivesystem kan støtte læring og også kan eliminere nøyaktig den tenkningen oppgaven fantes for å utvikle (skriveopplæring, Coach, ikke krykke).
En kompetansemodell. Følg med på argument (tesens presisjon, samsvar mellom påstand og belegg, motargument), organisering (avsnittets fokus, logisk framdrift, overganger), belegg (kildens relevans, integrering, tolkning), revisjon (global revisjon og revisjon på setningsnivå, vurdering av tilbakemelding) og stil (klarhet, grammatikk, stemme). Hver av disse blir et eget signal i studentmodellen, som er det som i det hele tatt gjør målrettet tilbakemelding mulig.
Forankre coachen i oppgaven. Hent inn instruksjonene, instruktørens vurderingsmatrise, kurslitteraturen, siteringskravene, sjangerkonvensjonene, instruktørens eksempler og retningslinjene for AI-bruk, slik at tilbakemeldingen kan si «vurderingsmatrisen til instruktøren din ber deg koble hver hovedpåstand til belegg fra minst to kurslesninger» i stedet for å finne opp generelle forventninger. Generelle råd er standardsvikten i et uforankret skriveverktøy, og studentene merker det innen to økter.
Sett tillatelser per fase. AI-involvering i ulike faser påvirker opplevd eierskap ulikt. Planleggingsstøtte reduserer eierskap mindre enn utkaststøtte, og AI-generert utkastskriving gir den største nedgangen (Fra planlegging til revisjon). Det funnet oversettes direkte til en tillatelsestabell. I planleggingen stiller coachen spørsmål, sammenligner standpunkter, utfordrer antakelser og kritiserer disposisjoner, og genererer ikke argumentet. I utkastfasen produserer studenten prosa først, og coachen utvikler i stedet for å overta. I revisjonen diagnostiserer coachen og stopper der: uklare påstander, manglende belegg, belegg som ikke støtter påstanden, organisatoriske problemer, utkastet mot vurderingsmatrisen. I korrekturlesingen, etter revisjonen, håndterer den grammatikk, tegnsetting, konsishet og siteringsformatering.
En gjennomført interaksjon. For et essay om å kreve nettkurs skriver et generisk system om studentens avsnitt til polert prosa og gjør det intellektuelle arbeidet. En coach sier hva som fungerer, navngir hovedproblemet (avsnittet gir grunner, men forklarer aldri hvorfor de rettferdiggjør et universitetsomfattende pålegg), stiller et revisjonsspørsmål og ber studenten fullføre en setning med egne ord. Argumentet blir der det hører hjemme.
Prioritert tilbakemelding. Én styrke å bevare, ett spørsmål med stor effekt, ett spørsmål som krever skribentens skjønn, ett konkret revisjonsmål. Ikke førti kommentarer. En student som får førti kommentarer, sorterer dem etter lengde, og sorteringen har ingenting med det som betyr noe å gjøre.
La studenten vurdere tilbakemeldingen. Tilbakemeldingskompetanse er et læringsmål i seg selv. Spør med jevne mellomrom om studenten er enig i et forslag og hvorfor, og la dem avvise det. Utfallet er vurderende skjønn i stedet for etterlevelse, og det er også det eneste forsvaret mot en coach som tar trygt feil.
Bevar stemmen. Skill mellom feil, klarhetsproblemer, retoriske valg og stilpreferanser, og la de to siste være i fred. En coach som «korrigerer» retoriske valg, homogeniserer skrivingen mot den stilen modellen foretrekker, og den gjør mest skade på flerspråklige skribenter og ikke-standard retoriske tradisjoner (kvaliteten på AI-tilbakemelding er den generelle versjonen av dette problemet).
Lær av revisjonene. Lagre revisjonshistorikken i stedet for bare de endelige essayene. Et gjentatt mønster med «belegg introdusert, men ikke tolket» som blir bedre gjennom tre essay, er det mest nyttige signalet et skrivesystem kan ha, og det er gratis.
Evaluering. Kvalitet på AI-assistert og senere uassistert skriving, evne til å finne svakheter i ukjent tekst, revisjonskvalitet, opptak av tilbakemelding, evne til å forklare revisjoner, eierskap, avhengighet av AI-prosa, bevaring av stemme, skjevhet på tvers av dialekter og flerspråklige skribenter, samsvar med instruktørens vurdering, og forsinket overføring. Designet som skal svare på det, har tre armer: skrive selvstendig, AI genererer teksten, og en coach. Alle tre gruppene skriver så et nytt essay uten AI. Hvis den AI-genererte gruppen vinner i praksis og taper uten den, forbedret systemet ytelsen, ikke læringen. Mønstre på klassenivå fra dashbordet (41 % trenger støtte på koblingen mellom påstand og belegg) er et formativt vurderingssignal for instruktøren.
Å sammenligne de to byggene
| Designspørsmål | Kalkulustutor | Skrivecoach |
|---|---|---|
| Primært læringsobjekt | Matematiske begreper og problemløsning | Argumentasjon og skriveprosess |
| Verifisering | Ofte objektivt kontrollerbar | Krever vanligvis kontekstuell vurdering |
| Deterministiske verktøy | Symbolsk matematikkmotor, kalkulator | Grammatikk-, siterings- og matrisekontroller |
| AI-ens hovedrolle | Diagnostisere og støtte resonnement | Diagnostisere og støtte revisjon |
| Største risiko | Å gi bort løsningen | Å skrive teksten for studenten |
| Studenthandling som betyr noe | Løse og forklare | Skrive utkast, vurdere og revidere |
| Studentmodell | Begreper, prosedyrer, misoppfatninger | Argument, belegg, organisering, revisjon |
| Viktigste sikkerhetsmekanisme | Forsøk før løsning | Studentprosa før AI-omskriving |
| Overføringstest | Nye kalkulusoppgaver uten AI | Ny skriveoppgave uten AI |
| Suksesskriterium | Selvstendig matematisk resonnement | Selvstendig skriving og vurderende skjønn |
Begge systemene bruker det samme settet av AI-teknologier og kroppsliggjør ulike pedagogiske policyer, fordi fagene krever ulike slags tenkning. Regelen som lar seg generalisere, er å identifisere den kognitive aktiviteten som produserer læringen, og designe AI-en til å støtte den aktiviteten uten å utføre den. Den regelen går foran enhver bestemt modell, prompt, agentrammeverk eller grensesnitt.
Hva utviklingsteam gjør galt
Pedagogikken bor i systemprompten, så en omhyggelig prompt er et pedagogisk design. En prompt er ett lag av en policy som også omfatter hvilket belegg du samler, hvilket trinn grensesnittet tilbyr, hva verifikatoren kontrollerer, og hva dashbordet viser. En godt skrevet prompt på toppen av en studentmodell som ikke lagrer noe, vil produsere en flytende tutor uten minne om studenten, og stigen vil starte på nytt hver økt.
En bedre modell vil fikse diagnosen. Benchmarkresultatet over fant LLM-tutorer som gjenkjente riktig resonnement, men avviste gyldige alternativer og godtok feil, som er et feilmønster skala ikke åpenbart reparerer. Strukturert diagnose finnes fordi modellens vurdering er den delen du ikke kan revidere.
Tilfredshet og fullføring beviser at designet fungerer. De beviser at studentene fikk hjelp. Piloten med 38 programmeringsstudenter fant opplevd læring sterkt assosiert med bruk, mens selvstendig framgang scoret lavest, og mestringsstudien fant at et streak-krav hevet plattformmestring uten gevinst på forsinket test. Bygg avvenningsmålet inn i piloten, ellers lærer du feil lekse effektivt.
Gjenfinning gjør svarene pålitelige. Det reduserer hallusinasjonsrisiko og lar resten av feilflaten være intakt: en gjenfunnet passasje kan feilleses, en gyldig teknikk kan være feil for kurset, og modellen kan fortsatt ta trygt feil om et trinn den selv utledet. Gjenfinning er et gulv.
Å bestå sikkerhetspakken betyr at det er trygt for studentene. Vanlig sikkerhetstesting dekker toksisitet og jailbreaks. De pedagogiske sviktene som betyr noe her, lekket svar, sykofanti og instruksjonsdrift, er usynlige for den, og de akkumuleres over en samtale i stedet for å dukke opp i en enkelt tur.
Engasjement er målet. Samtalelengde og antall økter er de billigste målene å instrumentere, som er hvorfor de forfremmes til mål. Argumentet om støtte sier at den ideelle økten blir kortere etter hvert som studenten blir bedre, så en økning i engasjement er like sannsynlig et symptom.
Hva som kommer tilbake på deg
«Vi leverer om seks uker, og dette er et kvartals arbeid.» Mesteparten av arkitekturen er billig. En forsøksport, en konfigurert stige, gjenfinning over notater du allerede har, og et loggskjema med et avvenningsfelt er dager med arbeid. De dyre postene (studentmodell, verifikator, dashbord) kan starte bak et feature-flagg for ett kurs, og piloten er mer informativ når de billige delene er gjort.
«Studentene elsker det, og fullføringen er oppe.» Begge fakta er forenlige med et system som svarer godt på spørsmål og ikke lærer bort noe. Studien med 6 000 studenter fant saktere framgang og færre forsøkte spørsmål sammen med bedre nøyaktighet, så en nedgang i fullføring er heller ikke automatisk dårlig nytt. Rapporter ytelse uten hjelp ved siden av engasjementstallene, og la de to være uenige offentlig.
«Vi kan ikke kjøre en randomisert studie.» Du kan kjøre en sammenligning innen samme student uten en: samme mål, assistert i løpet av enheten, testet uten hjelp to uker senere, med den assisterte scoren rapportert ved siden av. Det designet svarer på produktspørsmålet og trenger ingen kontrollarm. Det det ikke kan fortelle deg, er kontrafaktisk for studenter som aldri brukte tutoren.
«Modellen er en leverandør-API, så hjelpeatferden er utenfor vår kontroll.» Trinnene bor i ditt eget orkestreringslag, og resultatet i eksperimentet med sikkerhetsmekanismer kom fra å endre hva tutoren fikk lov til å si, ikke fra å bytte modell. Forvent at leverandørens ettertrening trekker mot å svare raskt, fordi hjelpsomhet er det den er tunet for, og legg tilbakeholdenheten inn i din egen kode.
«Lærerne vil ikke bruke nok et dashbord.» De vil ikke bruke et som sender ut kontinuerlig diagnostikk, som K-12-gjennomgangen fant trakk oppmerksomheten bort fra deres egen observasjon. Gi dem et lite antall tolkbare signaler, en måte å godta eller avvise hver anbefaling på, og tid i uken til å se på dem.
«Vi har ikke fageksperter på huset.» Da vil tutoren undervise i generisk metode, og kursets notasjon vil drifte i løpet av en termin. En fagekspert i to dager i designfasen, som skriver misoppfatningslisten og listen over godkjente metoder, er den billigste posten i prosjektet og den teamene kutter først.
Hva du kan gjøre denne uken
1. Skriv setningen om ytelse uten hjelp for piloten, og sett den i spesifikasjonen, over funksjonslisten.
2. Legg til en forsøksport og logg den. Registrer om studenten forsøkte før det første hintet, og hvilket trinn de nådde.
3. Erstatt hint-knappen med spørsmålet om blokkeringspunktet, og logg svaret som en kategori.
4. Planlegg én kontroll uten hjelp to uker etter enheten, og sett den i kalenderen med en ansvarlig.
5. Bestill to dager med en faglærer for å skrive misoppfatningslisten og listen over godkjente metoder.
Hvor du kan gå videre
Å designe pedagogisk AI-programvare dekker reglene på programvarenivå som en tutor må oppfylle, og Å designe AI inn i læring dekker hvor tutoren sitter i et kursløp. Å evaluere AI-intervensjoner og Å kontrollere om pedagogisk AI virker håndterer om tingen fungerer. Hvis problemet ditt er at modellen svarer for villig, arbeider Å gjøre AI bedre til å støtte læring og Å trene AI-tutorer til å veilede i stedet for å svare gjennom treningssiden av det samme spørsmålet.
Tilknyttede FAQ
- Hvordan trener vi en AI-veileder til å veilede studentene i stedet for å svare dem?
- Hvordan kan vi gjøre AI bedre til å støtte læring i vårt eget fag?
- Hvordan vet vi at en pedagogisk AI virker riktig, og ikke bare skårer godt?
- Hva er beste praksis og tips for å designe effektiv pedagogisk AI-programvare?