Качество любой метрики зависит от качества данных, на основании которых эта метрика рассчитывается. В компьютерных науках существует концепция «мусор на входе – мусор на выходе», которая заключается в том, что некорректные (или «мусорные», то есть содержащие шум или ошибки) входные данные приводят к абсурдному результату. Рассмотрим несколько ситуаций, иллюстрирующих эту концепцию. Все примеры реальны и основаны на онлайн-тренажере по программированию, в котором студенты решают задачи, сопровождающиеся краткой теорией и встроенными подсказками, которыми можно воспользоваться по желанию. Задачи по содержанию объединены в блоки – уроки.
Ситуация 1. Система логирования данных фиксирует только общее количество (или долю) верно решенных студентом задач в уроке. Это очень ограниченный подход к логированию, так как он не фиксирует результаты решения отдельных задач. Аналитик, работающий с такими данными, видит, например, что студент решил 7 из 10 позиций. Однако это не дает информации о том, с какими именно задачами он не справился, соответственно, отсутствует возможность рассчитать трудность каждой. В результате методист, разрабатывающий курс, может сделать неверные выводы о том, какие задачи и связанная с ними теория нуждаются в доработке.
Ситуация 2. Представим, что система записывает информацию о решении студентом каждой задачи, при этом логирует только последнюю попытку, удаляя все предыдущие. В этом случае аналитик получает искаженную информацию, так как последние попытки в подавляющем большинстве случаев успешны. Такие данные скрывают реальную картину усилий студента, потому что мы не знаем, сколько попыток им было предпринято, прежде чем он нашел правильное решение. Это может ввести в заблуждение методиста, который, основываясь на полученных данных, может считать, что студенты с легкостью справляются с предложенными задачами, и, возможно, задумается о том, чтобы добавить задачи «со звездочкой».
Ситуация 3. Система логирует каждую попытку решения задачи, но не фиксирует использование студентами подсказок. Аналитик может интерпретировать успешные попытки как хорошее освоение материала, но такая интерпретация окажется искаженной и даже ложной. Методист, не имея информации о том, как студенты используют дополнительные ресурсы, не оценит их значимости в процессе обучения.
В каждом из этих примеров мы видим феномен «не то чтобы совсем “мусор на входе – мусор на выходе”», но «недостаточно тщательный подход к отбору данных на входе – возможные ошибки на выходе», и это происходит из-за недостаточности или неадекватности логированных данных. В первом случае, когда отслеживается только общее количество решенных задач, мы теряем информацию о сложности отдельных заданий и о том, с какими именно проблемами сталкиваются студенты. Во втором примере, фиксируя только последнюю попытку решения, упускаем из виду всю историю попыток и усилий, что создает ошибочное представление об обучении. В третьем случае, не учитывая использование подсказок, получаем искаженное представление об успехе студентов. Таким образом, в каждом из этих сценариев неполные или неадекватные данные ведут к неправильным или искаженным выводам, что влияет на качество разработки и оптимизации EdTech-продуктов.
Описанные ситуации подчеркивают критическую важность корректного логирования данных. Тщательное и всестороннее логирование не только помогает аналитикам получить адекватное представление об учебном процессе, но и обеспечивает методистов необходимой информацией для адаптации и улучшения курсов. Так мы можем сформулировать первый принцип: лог должен репрезентировать взаимодействие студента с образовательным продуктом. Это значит, что каждое учебное действие студента внутри продукта должно логироваться.
Для корректного логирования нужно определить минимальные (атомарные) учебные элементы внутри продукта. Что считается минимальным элементом? Например, одно задание в тесте. Почему этот элемент минимальный? Потому что тестовое задание одно, и оно цельно или неделимо. Другими словами, нет ничего более мелкого и при этом цельного. Минимальным учебным элементом является видеоролик или текстовый материал. Видеоролик и текстовый материал – целые и неделимые единицы контента. А вот урок, состоящий из одного видеоролика, одного текстового материала и трех тестовых заданий, минимальным учебным элементом назвать нельзя.
Для иллюстрации воспользуемся метафорой «яблоневый сад». Сад один, но он может быть рассмотрен как группа деревьев. Дерево – как совокупность веток. Каждая ветка – как набор листьев и плодов. Таким образом, лист и плод будут минимальными элементами. Конечно, мы можем увлечься и начать препарировать листья и плоды, а затем вооружиться микроскопом… Но все же образ чего-то минимально целого и, главное, здравый смысл остановят нас. Почему здравый смысл? Потому что поиск минимального элемента мы ведем в интересах методиста и студента, а для большинства учебных продуктов минимальными элементами будут одно задание и одна единица учебного материала в формате видео или текста.
Разобравшись с минимальными учебными элементами, можем определиться и с минимальными учебными действиями. Эта книга написана в большей степени для практиков образования, чем для академических исследователей. А практика любит простоту. Именно поэтому, исходя из простоты, минимальным учебным действием будем считать цельное взаимодействие студента с минимальным учебным элементом. Например, в случае тестового задания этим взаимодействием является выполнение этого задания (пока мы не говорим о правильности выполнения; об этом речь пойдет далее). В случае, когда рассматриваются текстовый материал и видеоролик, минимальными учебными действиями будут прочтение этого материала и просмотр ролика. Почему такой подход простой? Потому что мы можем однозначно ответить на вопрос о том, совершено ли студентом минимальное учебное действие: «Да, тестовое задание выполнено»; «Нет, видеоролик не просмотрен»; «Да, текстовый материал прочитан». Такой подход обеспечивает достаточность данных для дальнейшей психометрической работы.
Однако возникает вопрос: а разве нельзя прочесть половину текстового материала или просмотреть половину видеоролика? Конечно, можно. Для этого существуют более сложные подходы к логированию данных, фиксирующие, например, старт, паузу, возобновление, завершение взаимодействия с видеороликом или текстовым материалом. Такое тонкое логирование в настоящее время используется преимущественно в академических исследованиях: например, можно ли по положению курсора на экране оценивать, куда смотрит студент, чтобы не использовать трудоемкие айтрекеры. Но, учитывая практический, а не академический фокус этой книги, будем относить такое логирование к дополнительным возможностям.
Итак, мы разобрались с тем, что такое минимальные учебные элементы и минимальные учебные действия. И помним главный принцип: лог должен репрезентировать взаимодействие студента с образовательным продуктом. Теперь выясним, как корректно логировать минимальные учебные действия.
Для корректного логирования нужно понимать, как устроено минимальное учебное действие в продукте, какова его механика. Начнем с самого простого случая: студент выполняет тестовое задание с одним верным вариантом ответа. Это минимальное действие предполагает только два исхода: верный либо неверный ответ. В табл. 1 представлено, как может выглядеть лог этого учебного действия.
Таблица 1. Лог, фиксирующий только верное или неверное выполнение студентом двух заданий. Длинный формат
В аналитике используют два формата данных: длинный (long) и широкий (wide). В длинном формате каждое действие студента представлено отдельной строкой. В широком – действие приводится на пересечении строки и столбца, где в строке – идентификатор студента, а в столбце – идентификатор действия. Широкий формат для представленного примера приведен в табл. 2.
Таблица 2. Лог, фиксирующий только верное или неверное выполнение задания. Широкий формат
Форматы можно преобразовывать друг в друга, но лишь длинный позволяет детально логировать действия студента, он более гибкий, и, как правило, именно он применяется на практике. Далее мы будем рассматривать только такой формат представления данных.
Мы видим, что лог содержит по два минимальных учебных действия для двух студентов с идентификаторами s001 и s002. Они выполняли два задания с идентификаторами t001 и t002 соответственно. При этом студент s001 с первым заданием справился (выполнил верно), а со вторым – нет (выполнил неверно). Студент s002 справился с обоими заданиями. Важно отметить, что такой лог соответствует простейшей механике, когда у студента есть только одна попытка для выполнения задания. Если студент не приступал к выполнению задания, лог будет отсутствовать.
Но что, если студенту доступны несколько (или бесконечное число) попыток для выполнения задания? В таком случае необходимо логирование каждой попытки, а лог может принять следующий вид (табл. 3):
Таблица 3. Лог, фиксирующий количество попыток и правильность выполнения заданий
Мы видим пять строк лога, отражающих взаимодействие студента s001 с двумя заданиями t001 и t002. С первым заданием студент справился с третьей попытки, соответственно, мы видим три строки, где в первой и второй отмечен неверный ответ (0 в переменной is_correct), а в третьей – верный (1 в переменной is_correct). Со вторым заданием студент справился со второй попытки, соответственно, в логе мы видим две строки. Для идентификации попыток важно добавить в структуру еще одну переменную – отметку времени совершения попытки (timestamp).
На практике часто встречаются ситуации, когда студент, выполняя задание, может дать частично верный ответ. Так, существует разновидность тестовых заданий, в которых необходимо выбрать несколько верных ответов из нескольких возможных. Кроме того, в тренажерах по программированию или анализу данных встречаются задачи, состоящие из нескольких действий (например: 1) отсортировать, 2) отфильтровать, 3) построить график). В исследовательской литературе задания, которые имеют один верный ответ, называют дихотомическими, или бинарными (возможные баллы за такое задание: 0 или 1). Задания, для которых возможен частично верный ответ, называют политомическими (за них можно получить баллы 0, 1, 2 и т. д. в зависимости от количества верно выполненных элементов).
Возникает вопрос: как должна выглядеть переменная is_correct в случае политомического задания (в котором возможен частично верный ответ)? Есть большое количество способов логирования. Но моя практика показывает, что наиболее часто встречаются два варианта. Первый – перевести частично верный ответ к дихотомическому (или бинарному) формату, где, например, если решение студента верно наполовину и более, присваивать 1, а если менее – 0. Возможны как более строгая, так и более мягкая формы перевода. В более строгом случае 1 мы начисляем только при полностью верном решении, а в остальных случаях – 0. В более мягкой форме 1 можно присваивать решению, в котором хотя бы что-то было выбрано/сделано верно. Форму следует выбирать совместно с командой методистов, в идеальном варианте – посоветоваться со специалистом-психометриком. Но, признаюсь, этот вариант мне нравится меньше всего, потому что в любом случае мы отправляем в лог искаженную информацию о реальном поведении студента. А ведь мы помним главный принцип: лог должен репрезентировать взаимодействие студента с образовательным продуктом. Чтобы следовать этому принципу, я разработал второй вариант – универсальное подробное логирование.
При универсальном подробном логировании мы заменяем переменную is_correct четырьмя переменными: task_correct, task_incorrect, selected_correct и selected_incorrect, где task_correct – это общее количество верных вариантов ответа в задании, задуманное автором; task_incorrect – общее количество неверных вариантов ответа; selected_correct – количество верных вариантов ответа, выбранное студентом, и, наконец, selected_incorrect – количество неверных вариантов ответа, выбранное студентом. Универсальное подробное логирование позволяет записывать результаты выполнения любых заданий без потери информации.
Рассмотрим разные сценарии отдельно.
Начнем с ранее описанного задания, в котором есть только один верный вариант ответа. В таком случае при логировании работают всего две колонки: task_correct, которая показывает, что в задании только один верный вариант ответа, и selected_correct, которая показывает, выбрал ли студент этот верный вариант ответа (или, в случае с задачами, выполнил ли студент задачу верно). Для таких заданий эти колонки неприменимы, и лог будет иметь следующий вид (табл. 4):
Таблица 4. Универсальный подробный лог двух попыток решения для задания с одним верным ответом
Мы видим, что студент s001 при первой попытке не справился с этим заданием, что обозначено как 0 в переменной selected_correct. Со второй попытки студент выполнил задание верно, следовательно, в колонке selected_correct отмечено 1. При этом колонки task_incorrect и selected incorrect имеют значения NA (not applicable, то есть «неприменимо»), так как в задании возможен только один верный ответ.
У рассмотренного задания есть частный случай типа «альтернатива». В таких заданиях только два варианта ответа: да/нет. Если студент справляется с первой попытки, то лог будет таким (табл. 5):
Таблица 5. Универсальный подробный лог задания с одним верным и одним неверным ответом, решенного с первой попытки
Мы снова встречаем значения NA в колонках task_incorrect и selected_incorrect, потому что в заданиях, где возможен только один верный ответ (а задание типа «альтернатива» является именно таким), эти колонки неприменимы.
Теперь рассмотрим задание, в котором возможны несколько верных вариантов ответа, например три из пяти предложенных. В этом случае лог принимает следующий вид (табл. 6):
Таблица 6. Универсальный подробный лог для двух попыток решения политомического задания с тремя верными и двумя неверными ответами
Колонки task_correct и task_incorrect отображают дизайн задания: мы видим, что имеются три верных и два неверных варианта ответа, а их общее число равно сумме этих колонок – пяти. Колонки selected_correct и selected_incorrect показывают результат выполнения студентом задания при каждой попытке. Мы видим, что при первой попытке студент выбрал один верный ответ (из трех возможных) и два неверных (из двух возможных), а при второй – три (из трех возможных) верных и ноль неверных.
Наконец, если студент решает задачу с пятью действиями (где нет неверных вариантов), лог будет выглядеть так (табл. 7):
Таблица 7. Универсальный подробный лог для задач, в которых нет готовых для выбора верных и неверных ответов
Мы снова видим значения NA в колонках task_incorrect и selected_incorrect. Но на этот раз в задаче по конструкции отсутствуют неверные варианты ответа, поэтому их логирование в эти колонки неприменимо. Мы также видим, что студент справился с тремя действиями из пяти. Именно поэтому в колонке selected_correct стоит цифра 3, а в колонке task_correct – 5.
Обобщим. При универсальном подробном логировании колонки task_incorrect и selected_incorrect будут оставаться пустыми (неприменимыми) в двух случаях: если в заданиях предусмотрен только один верный ответ и если в задании не предусмотрены неверные варианты. В первом случае эти колонки неприменимы потому, что колонки task_correct и selected_incorrect уже несут в себе информацию, справился ли студент с этим заданием или нет, и в заполнении колонок task_incorrect и selected_incorrect нет никакой необходимости. А во втором случае эти колонки неприменимы потому, что в самом задании отсутствует механика выбора неверного варианта ответа, а значит, заполнять колонки task_incorrect и selected_incorrect попросту нечем.
А что, если механика минимального учебного действия устроена так, что студент может воспользоваться подсказкой, доступной в учебном продукте? Тогда это необходимо залогировать, потому что решение без подсказки и решение с подсказкой – принципиально разные учебные действия. Рассмотрим пример логирования минимальных учебных действий с учетом использования подсказок.
Представим задание, в котором возможны несколько верных вариантов ответа, например три из пяти предложенных. В этом случае лог принимает следующий вид (табл. 8):
Таблица 8. Лог политомического задания, решенного полностью верно со второй попытки, с добавлением фиксации использования подсказки
Из лога мы видим, что первая попытка решения задания t001 была неудачной. Но при выполнении второй попытки студент s001 воспользовался подсказкой (в новой переменной hint_used видим отметку 1) и в результате выполнил задание верно.
А что, если подсказки разные или в учебном продукте имеются другие помогающие механики? Ответ простой: следуя принципу «лог должен репрезентировать взаимодействие студента с образовательным продуктом», необходимо включать в лог все механики, доступные студенту в образовательном продукте. А для того чтобы ничего не упустить, нужно провести валидацию лога.
Процесс валидации лога заключается в том, чтобы пройти полноценную с точки зрения доступных учебных механик часть продукта, например урок или тему. При этом следует законспектировать все свои действия, которые должны быть максимально разнообразными как по отдельности, так и в комбинации: дать неверный ответ, дать верный ответ, воспользоваться подсказкой, выбрать сразу все варианты ответа, отправить задание на проверку, не отметив ни одного ответа, и так далее. Затем нужно сравнить ваши реальные действия с залогированными. Корректный лог должен включать все, что вы делали, взаимодействуя с продуктом. Выявленные расхождения необходимо учесть в новой версии логирования. В дальнейшем при добавлении новых механик в учебный продукт нужно помнить о том, что их следует отразить и в логе. Другими словами, валидация лога производится при каждом изменении и/или дополнении механик продукта.