Abans d'inscriure's al nou curs d'aprenentatge automàtic avançat, posem a prova els estudiants potencials per determinar el seu nivell de preparació i entendre què han d'oferir exactament per preparar-se per al curs. Però sorgeix un dilema: d'una banda, hem de provar coneixements en Data Science, de l'altra, no podem organitzar un examen complet de 4 hores.
Per resoldre aquest problema, hem desplegat una seu de TestDev a l'equip de desenvolupament del curs de Ciència de Dades (i sembla que això és només el començament). Us presentem una llista de 10 inconvenients que es troben en desenvolupar proves per avaluar els coneixements. Tant de bo el món de l'aprenentatge en línia serà una mica millor després d'això.
Rake 1: no definir clarament els objectius de la prova
Per tal de definir correctament els objectius i crear una prova que els tingui en compte, en l'etapa de planificació hem de respondre diverses preguntes:
- Què estem comprovant realment?
- En quin entorn es realitzaran les proves i quins mecanismes s'utilitzen? Quines són les limitacions en aquest entorn? Aquest mateix punt us permetrà entendre els requisits tècnics del dispositiu en què es realitzarà la prova, i també del contingut (si la prova es fa des de telèfons, les imatges haurien de poder ser llegibles fins i tot en una pantalla petita, haurien de ser ser possible ampliar-los, etc.).
- Quant de temps trigarà la prova? Cal pensar en les condicions en què l'usuari realitzarà la prova. Podria haver-hi una situació en què hagi d'interrompre el procés de prova i continuar de nou?
- Hi haurà feedback? Com el formem i l'entreguem? Què necessites rebre? Hi ha un retard entre l'execució de la prova i la retroalimentació?
En el nostre cas, després de respondre aquestes preguntes, vam definir la següent llista d'objectius per a la prova:
- La prova hauria de mostrar si els futurs estudiants estan preparats per fer el curs i si tenen prou coneixements i habilitats.
- La prova ens ha de donar material per a la retroalimentació, indicar el tema en què els alumnes s'han equivocat, per tal que puguin millorar els seus coneixements. A continuació us explicarem com redactar-lo.
Rake 2: No elaborar les especificacions tècniques per al redactor expert de la prova
Per compondre ítems de prova, és molt important la participació d'un expert en l'àmbit en què s'estan provant els coneixements. I per a un expert, al seu torn, necessita una especificació tècnica competent (descripció), que inclogui els temes de la prova, els coneixements/habilitats que s'estan provant i el seu nivell.
Un expert no farà aquestes especificacions tècniques per si mateix, perquè la seva feina és elaborar tasques, no l'estructura de la prova. A més, poques persones desenvolupen proves professionalment, fins i tot en el procés d'ensenyament. Això s'ensenya en una especialitat separada: psicometria.
Si voleu familiaritzar-vos ràpidament amb la psicometria, a Rússia n'hi ha per a tots aquells interessats. Per a un estudi més aprofundit, l'Institut d'Educació té i l'escola de postgrau.
En preparar les especificacions tècniques, recollim una descripció detallada de la prova per a l'expert (o millor, juntament amb ell): temes de tasques, tipus de tasques, el seu nombre.
Com triar el tipus de tasques: havent decidit els temes, decidim quines tasques poden provar-ho millor? Opcions clàssiques: tasca oberta, tasca d'elecció múltiple o única, concordança, etc. (no us oblideu de les limitacions tècniques de l'entorn de proves!). Després de determinar i especificar el tipus de tasques, disposem d'una especificació tècnica preparada per a l'expert. Podeu anomenar-lo una especificació de prova.
Rake 3: no implicar un expert en desenvolupament de proves
A l'hora d'immergir un expert en el desenvolupament de proves, és molt important no només indicar-li "l'abast del treball", sinó implicar-lo en el propi procediment de desenvolupament.
Com fer que el treball amb un expert sigui el més eficaç possible:
- Configureu-lo amb antelació i dediqueu una estona a parlar sobre la ciència del desenvolupament de proves i la psicometria.
- Centra l'atenció de l'avaluador a crear una eina d'avaluació vàlida i fiable, no una llista de preguntes.
- Expliqueu que el seu treball inclou una etapa preparatòria, no només el desenvolupament de les tasques en si.
Alguns experts (per la seva naturalesa) poden percebre això com una prova del seu propi treball, i els expliquem que, encara que creem tasques excel·lents, és possible que simplement no s'adaptin als objectius específics de la prova.
Perquè el procés vagi ràpidament, preparem amb l'expert una taula de cobertura temàtica (coneixements i habilitats) que forma part de l'especificació de la prova. És aquesta taula la que ens permet resoldre amb precisió les preguntes i determinar què mesurarem. En cada cas concret es pot compilar de manera lleugerament diferent. La nostra tasca és comprovar fins a quin punt una persona entén els coneixements i les habilitats dels cursos bàsics anteriors per entendre fins a quin punt està preparada per estudiar en un nou curs.
Rake 4: pensar que l'expert "sàpiga millor"
Coneix millor el tema. Però no sempre s'explica clarament. És molt important comprovar la redacció dels treballs. Escriu instruccions clares, per exemple, "Tria una opció correcta". En el 1% dels casos, els experts preparen preguntes d'una manera que ells mateixos entenen. I això està bé. Però abans de lliurar la prova als qui la faran, s'ha de revisar i pentinar tot perquè les persones que facin la prova entenguin exactament què se'ls exigeix i no s'equivoquen només perquè puguin malinterpretar el text de la tasca.
Per evitar la doble interpretació de les tasques, realitzem "laboratoris cognitius". Demanem a les persones del públic objectiu que facin la prova, dient en veu alta el que pensen i gravant-la detalladament. Als "laboratoris cognitius" podeu "captar" preguntes poc clares, una redacció incorrecta i obtenir els primers comentaris sobre la prova.
Rake 5: ignora el temps d'execució de la prova
mode sarcasme: activat
Per descomptat, la nostra prova és la millor, tothom somia amb passar-la! Sí, les 4 hores.
mode sarcasme: apagat
Quan hi ha una llista de tot el que es pot comprovar, el més important és no fer-ho (a primera vista sembla estrany, no?). Cal tallar sense pietat, identificant els coneixements i les habilitats clau amb un expert (sí, també es poden provar diverses habilitats a la prova). Mirem el tipus de tasques i estimem el temps d'acabament objectiu: si tot és encara més que límits raonables, ho retallem!
Per reduir el volum, també podeu provar (acuradament) provar dues habilitats en una tasca. En aquest cas, és difícil entendre per què la persona s'ha equivocat, però si es fa correctament, es poden tenir en compte ambdues habilitats. És important assegurar-se que aquestes 2 habilitats corresponen a la mateixa àrea de coneixement.
Rake 6: No pensar en el sistema de puntuació
Sovint, a l'hora d'elaborar proves d'avaluació, utilitzen el sistema de puntuació clàssic, per exemple, 1 punt per a les tasques fàcils i 2 punts per a les difícils. Però no és universal. Només la suma de punts basada en els resultats de la prova no ens dirà gaire: no sabem per a quines tasques es van rebre aquests punts i només podem determinar el nombre de tasques correctes. Hem d'entendre exactament quines habilitats estan demostrant els participants. A més, volem donar-los comentaris sobre quins temes s'han de millorar.
Al cap i a la fi, estem fent una prova que dividirà les persones entre les que estan preparades i les que no estan preparades per completar el programa; aconsellarem a alguns que es preparin per al curs mitjançant una formació gratuïta. Per a nosaltres és important que aquest grup inclogui només aquells que realment ho necessiten i que estan preparats per a això.
Què fem en la nostra situació: determinem dins del grup de treball de desenvolupadors de proves quins grups de persones s'han d'identificar (per exemple, preparats per aprendre, parcialment preparats) i formem una taula de característiques d'aquests grups, indicant quines habilitats i coneixements serà rellevant per al grup de formació llest per aprendre. D'aquesta manera podeu formular la "dificultat" de les tasques per a aquestes proves.
Rake 7: avalueu els resultats només automàticament
Per descomptat, l'avaluació ha de ser el més objectiva possible, de manera que alguns dels materials de l'estudiant s'avaluen automàticament, "per claus", comparant-los amb les respostes correctes. Fins i tot si no hi ha un sistema de proves especial, hi ha moltes solucions gratuïtes. I si enteneu els principis d'escriure scripts, podeu fer el que vulgueu amb els formularis de Google i els resultats en taules. Si algunes de les tasques són revisades per experts, hem de pensar a donar respostes als experts, sense informació sobre els examinats. I pensa com integrar els resultats de les proves d'experts a l'avaluació final.
Al principi volíem fer diverses tasques obertes amb codi, on els experts avaluessin les solucions basant-se en criteris preformats, i fins i tot vam preparar un sistema que exporta respostes individuals dels participants de la prova a una taula especial per als experts i després importa els resultats a una taula amb els càlculs d'avaluació. Però després de parlar amb els representants del públic objectiu, el responsable de producte i el dissenyador educatiu, vam pensar que fer una entrevista tècnica amb comentaris instantanis d'experts i discussió del codi, així com qüestions individuals, seria molt més eficaç i útil per als mateixos participants. .
Ara l'expert verifica la realització de la prova, aclarint algunes preguntes. Per fer-ho, hem elaborat una guia de preguntes i criteris d'avaluació per a una entrevista tècnica. Abans de l'entrevista tècnica, l'examinador rep un mapa de les respostes del candidat per ajudar-lo a seleccionar les preguntes per fer.
Rake 8: No expliqueu els resultats de la prova
Proporcionar comentaris als participants és una qüestió a part. No només hem d'informar sobre la puntuació de la prova, sinó també proporcionar una comprensió dels resultats de la prova.
Pot ser:
- Tasques en què el participant s'ha equivocat i que ha realitzat correctament.
- Temes en què el participant s'ha equivocat.
- La seva classificació entre els que fan l'examen.
- Descripció del nivell del participant, d'acord, per exemple, amb la descripció del nivell d'especialista (a partir de la descripció de les vacants).
Durant el llançament pilot de la nostra prova, als que es volien inscriure al programa, juntament amb els resultats, vam mostrar una llista de temes que calia millorar. Però certament això no és l'ideal, millorarem i oferirem millors comentaris.
Rake 9: no comenteu la prova amb els desenvolupadors
Potser el més agut, que és especialment desagradable de trepitjar, és enviar la prova, la descripció i l'escala de puntuació als desenvolupadors "tal com estan".
Què s'ha de parlar exactament:
- L'aspecte de les preguntes, l'estructura, la posició dels gràfics, com és l'elecció de la resposta correcta.
- Com es calcula la puntuació (si cal? Hi ha condicions addicionals?
- Com es generen els comentaris, on obtenir els textos, hi ha blocs addicionals generats automàticament.
- Quina informació addicional necessiteu recollir i en quin moment (els mateixos contactes).
Per evitar malentesos, demanem als nostres desenvolupadors que codifiquen 2 o 3 preguntes diferents perquè puguin veure com són abans de codificar la prova en si.
Rake 10: sense provar, penja directament a producció
3 vegades, nois, la prova s'hauria de comprovar 3 vegades per persones diferents, o millor encara, 3 vegades cadascuna.Aquesta veritat es va obtenir amb sang, suor i píxels de línies de codi.
La nostra prova verifica el següent trio:
- Producte: comprova la prova de rendiment, aparença i mecànica.
- Desenvolupador de proves: comprova el text de les tasques, el seu ordre, la forma de treballar amb la prova, els tipus de tasques, les respostes correctes, la llegibilitat i la visualització normal dels gràfics.
- L'autor de les tasques (expert) verifica la fidelitat de la prova des d'una posició d'expert.
Un exemple de la pràctica: només a la tercera tirada, l'autor de les tasques va veure que 1 tasca quedava a la versió antiga de la redacció. Tots els anteriors també van governar activament. Però quan es va codificar la prova, semblava diferent del que s'imaginava originalment. És molt probable que alguna cosa s'hagi de corregir. Això s'ha de tenir en compte.
Total
Evitant amb cura tots aquests "rastrells", vam crear un especial , per comprovar els coneixements dels sol·licitants. Qualsevol pot provar-lo mentre estem preparant el següent material, en el qual us explicarem què va passar dins del bot, i en què es va transformar tot després.
Podeu obtenir una professió sol·licitada des de zero o pujar de nivell en termes d'habilitats i salari fent els cursos en línia de SkillFactory:
- (12 setmanes)
- (20 setmanes)
- (20 setmanes)
- (12 mesos)
Més cursos
- (12 mesos)
- (14 setmanes)
- (5 setmanes)
- (18 mesos)
- (6 mesos)
- (12 mesos)
- (8 mesos)
- (9 mesos)
- (12 mesos)
- (18 mesos)
- (18 mesos)
- (12 mesos)
- (9 mesos)
- (7 mesos)
Font: www.habr.com