Как в Skillbox ускорили проверку коммуникации преподавателей и студентов

В Skillbox есть специальная позиция — куратор проверяющих преподавателей. Эти специалисты отвечают за работу экспертов, которые проверяют практические задания пользователей. Фактически, они помогают проверяющим преподавателям расти как менторам, регулировать свою нагрузку и также подключаются к проблемным кейсам.

Кураторы проверяющих преподавателей отвечают за:

• контроль качества проверок практических заданий и коммуникаций проверяющих экспертов с обучающимися;
• поиск и подключение проверяющих экспертов;
• регулирование их нагрузки и объем заработной платы.

Дмитрий Шурмакин, техлид в Skillbox, рассказал, как устроен цифровой помощник для кураторов преподавателей и что принципиально нового он вносит в работу специалистов.

У нас много разных курсов и направлений — в каждом свои паттерны обучения и коммуникации, которым важно соответствовать. Образование — это всегда двусторонний процесс: в нем есть студент и преподаватель, который должен сопровождать его и помогать учиться. Коммуникация очень важна. И здесь кроется главное отличие онлайн-образования от традиционного — в онлайн-процессе меньше прямого взаимодействия. Студент приходит домой, начинает учиться и может почувствовать себя одиноко: есть ты, есть монитор и где-то там, по ту сторону монитора — преподаватель.

В онлайне трудно удерживать внимание студента, поскольку большинство привыкло к классической схеме образования, когда за счет очного контакта с преподавателем устанавливается дисциплина, а также многим психологически легче концентрироваться на материале, когда обучение происходит в аудитории. Онлайн предполагает большую личную ответственность студента.

Поэтому преподаватель должен не просто рассказать какой-то материал, но и быть отличным коммуникатором, умеющим давать полноценную обратную связь — что особенно критично для платформ, которые предлагают материал в асинхронном режиме. Обратная связь в процессе обучения и выполнения практических задач — самая важная часть общения. А значит, в рамках этого общения преподавателю нужно быть максимально конструктивным.

В задачи куратора преподавателя входит проверка коммуникации со студентами. Раньше на проверку одной коммуникации у куратора уходило порядка трех минут: надо было найти сам разговор в админке LMS (Learning Management System — система управления обучением) , запросить данные у аналитиков. С нашими масштабами 3 минуты — непозволительная роскошь.

Мы непрерывно занимаемся улучшением продуктов, и общение с преподавателем — важная часть образовательного опыта наших студентов. Для его улучшения мы создали цифровой помощник для кураторов, позволяющий корректировать практические задания, которые могли оказаться слишком простыми или сложными, а также контролировать обратную связь от проверяющих преподавателей — например, негативные акты коммуникации. Это было важно потому, что именно это помогает студенту двигаться вперед, анализировать свои ошибки и понимать, что было сделано хорошо или нет.

Исторически LMS была платформой, на которой выкладывался контент, а студент в удобное время просматривал его, но со временем ее функционал изменился — теперь это целая экосистема, на которой происходит образовательный процесс. В современной LMS есть множество модулей: системы трекинга, мониторинга, документирования материалов, управления преподавателями и т. д.

Однако помимо внутренних модулей LMS, образовательные платформы обрастают и внешними сервисами-сателлитами — например, выстраивается система ресурсов для общения: чаты в телеграме, мессенджеры, рассылки и т. п. Эта система генерирует уведомления и в нужное время подсказывает студентам, чему стоит уделить больше внимания, что важно повторить, какой материал подучить, по каким направлениям планируются дополнительные образовательные события.

Актуализация материала производится за счет медиаплатформ и вебинарных платформ, с их помощью мы помогаем студентам общаться с интересными и опытными специалистами, задавать им вопросы. Всё это часть большой образовательной экосистемы.

На более общем уровне, чтобы понимать эффективность новых модулей LMS или направлений, мы опираемся на ряд метрик. Важную роль здесь играют показатели удовлетворенности CSAT (Customer Satisfaction Scor — уровень удовлетворенности программой или ее элементом) и NPS (Net Promoter Score — готовность пользователей рекомендовать курс) . Нам важно отслеживать, насколько студент доволен контентом, нравится ли ему сервис и сам процесс обучения. Еще в классической продуктовой аналитике используются метрики Retention Rate (коэффициент удержания пользователей) и Churn Rate (коэффициент оттока пользователей). Они позволяют понять, насколько активна текущая аудитория продукта. С помощью этих же метрик мы отслеживаем все свои продуктовые активности и эффективность внедрения новых фич или сервисов — они помогают измерить их влияние непосредственно на процесс обучения.

В рамках системы внутренней аналитики у нас есть различные цифровые сервисы — помощники для методистов, для кураторов преподавателей и т. д.И в рамках цифровых помощников используются более частные метрики: их можно декомпозировать на разные уровни, собирать показатели отдельно по видеолекциям, практическим заданиям, взаимодействию с преподавателем и т. д., чтобы оценить, какие узлы платформы или даже конкретные уроки требуют доработок в первую очередь.

Метрики, используемые в цифровом помощнике для кураторов:

• Количество итераций сдачи практической работы — это количество попыток сдать урок определенной контентной единицы. Если у студента не получилось сдать работу один, два, три, четыре раза, это уже сигнал для нас: возможно, мы не даем достаточно материала, что-то разъясняем поверхностно или даже упустили какой-то отдельный пласт знаний.
• Время проверки практической работы — время затраченное экспертом на проверку практической работы.
  
• Время прохождения модулей — разница между датой завершения модуля и датой начала модуля. Все модули просмотренные нелинейно из анализа выкидываются, так как искажают результаты метрики. Если мы видим, что какой-то модуль студент стал проходить аномально долго, то мы либо не попали в его workflow, либо есть какие-то внешние причины — например, студент уехал в отпуск, либо какие-то внутренние блоки — надоело проходить курс, материал показался неинтересным, пропал фокус и мотивация.
  

Важной частью помощника для кураторов также является анализ качества коммуникации с пользователями (оценка диалогов между преподавателями и пользователями) .

Цифровой помощник кураторов преподавателей содержит в себе инструменты и методы отслеживания коммуникации пользователей и преподавателей, а также их характер и качество. Это позволяет быстро реагировать на негативные события в процессе их взаимодействия. Опишем, как это происходит.

Поиск по фильтрам. Система позволяет найти информацию по текстовым коммуникациям пользователей и преподавателей. Для этого нужно выставить необходимые фильтры в меню и запустить поиск. В системе несколько групп фильтров. Например, в фильтре по пользователю можно выбрать конкретного преподавателя или студента. Далее идет фильтр по курсам — тут можно выбрать направление или конкретный курс, также если нас интересует конкретный курс, в нем мы можем выбрать определенный модуль. И фильтр по оценкам — где можно отслеживать оценки, которые ставят студенты преподавателям. Мы еженедельно анализируем плохие оценки, которые проставляют студенты, сопровождая их комментариями. Можно выбрать период и, например, низкие оценки 1-2-3. Будет видно, сколько таких оценок, от кого и кому проставлены. Затем можно зайти в диалоги и проанализировать, по какой причине была поставлена такая оценка.

Карточки коммуникаций. В фильтре «Оценки” также есть подфильтр “Лейблы”. Лейблы проставляются автоматически на основе алгоритмов ML с учетом конкретных слов и формулировок. Их всего десять, они видны внизу каждого сообщения преподавателя. Например, “Нецензурная лексика”, “Негативная окраска”, “Разъяснения по процессу обучения”, »Шаблонный ответ” и т.д. С их помощью куратор преподавателей может не проваливаться в каждую коммуникацию, а ориентироваться по меткам и таким образом экономить время, игнорируя ненужные коммуникации. По лейблам сразу можно понять, обращался ли преподаватель к студенту на «вы», была ли в коммуникации мотивационная часть — система автоматически умеет отслеживать даже конфликты и нецензурные выражения. Особенное внимание кураторы обращают на нецензурную лексику.

История конкретной коммуникации. Найдя интересующую карточку, можно попасть в историю коммуникации. Там будет видно, какое именно сообщение было помечено лейблом, заинтересовавшим куратора, а также вся переписка, домашняя работа и дополнительная информация о студенте. Здесь же куратор может оценить коммуникацию, переразметить лейб, оставить свой комментарий и экспертную оценку.

Для чего переразмечать лейблы? Распределение лейблов происходит автоматически на базе ML-движка, но изредка случаются погрешности. Тогда куратор может самостоятельно переместить метку — и таким образом система становится умнее и точнее.

Поиск чатов

Разграничение прав доступа. Сервисом стали активно пользоваться не только кураторы (это, кстати, один из интересных сайд-эффектов!) : он понравился и продюсерам, и другим сотрудникам. Они проводят аудит курсов на основе коммуникации студентов, смотрят часто задаваемые вопросы или сложные модули, которые можно дополнить материалами/изменить/заменить, подготовить FAQ. Поэтому нам понадобилось разграничить права доступа: не всем нужна возможность оценок, комментариев или просмотра информации о пользователях. Для некоторых групп пользователей у нас отключена часть опций.

Если раньше куратор занимался точечной работой, то после внедрения помощника вся информация стала собираться в одном месте, а кураторы получили возможность отслеживать больше проблемных мест. Используя технологии машинного обучения, мы помогаем отсеивать много ненужной информации и быстрее находить негативные акты коммуникаций.

Если раньше проверка одной коммуникации занимала три минуты, то теперь за эти же три минуты куратор может проверить 10-15 коммуникаций — в зависимости от опыта и сложности конкретного кейса.

Интересно, что мы решали проблему конкретных специалистов, а в итоге сервис оказался полезен и для других сотрудников. Например, в него часто заходят продюсеры — после запуска курса им важно понимать, как он развивается, что о нем думают студенты. Плюс они могут провести аудит материалов, отловить типичные проблемы, связанные с целевой аудиторией или с частыми вопросами.

Однако популярность у наших внутренних пользователей — это только косвенный признак. Потому что любое подобное решение преследует бизнес-цели и должно оцениваться по показателям и метрикам, которые в конечном итоге оказывают влияние на экономику компании.

Для нас это в первую очередь CSAT , который показывает отношение студентов к обучению. CSAT у нас делится на несколько разновидностей, например, материал задания, тесты, подача видео и т.д. Ключевой показатель CSAT, который отслеживают кураторы, — это взаимодействие с преподавателем. Ниже на графике динамика CSAT / взаимодействие с преподавателем по кварталам с момента внедрения цифрового помощника, т.к. благодаря ему стало удобнее работать с этой метрикой:

Да, это не совсем чистые данные — у нас большая платформа и параллельно мы развиваем много направлений, которые влияют на CSAT. Однако по обратной связи от коллег, которые пользуются сервисом, мы понимаем, что на сдвиг новый сервис точно повлиял.

Ни один современный сервис не работает без больших данных, а они, как правило, поступают из разных систем и в разном формате. К нам стекается информация из SQL и NoSQL баз данных, разных API — все это оркестрируется с помощью системы Prefect. После этого данные трансформируются с помощью DBT и отправляются в Data Lake, а часть из них попадает в PostgreSQL, который используется в наших сервисах — иногда это нужно для транзакционности.

Решение для продакшена основано на связке Vue + FastAPI.

• Запуск Data Lake. В контексте статьи это подразумевает именно сам движок, а не сущность, наполненную конкретными данными.

• Запуск EL процесса (Prefect) — заполняем заполняем систему данными (у нас ETL-процесс разбит на два этапа — EL и T).

• Запуск T-процесса (DBT) — этап трансформации данных с помощью DBT.
  

• Создание единого API для БД — чтобы сервис мог общаться с базами и получить из них данные.
• Создание бэкенда сервиса.
• Создание фронтенда сервиса.

• Фронтенд у нас собирается на Vue JS по технологии Single Page Application — все довольно привычно для современных IT-решений.

• После фронтенда идет Gateway, который отвечает за ролевую логику, логику распределения запросов по сервисам и т.д.

• А конкретные сервисы общаются с Gateway и пользователем через RabbitMQ.

• С базами данных сервисы общаются с помощью единого API.

Плюсы такой архитектуры:

• Простота разработки новых сервисов. Новые сервисы разрабатывать довольно просто — потому что они являются достаточно независимыми сущностями.

• Масштабируемость. За счет RabbitMQ сервисы легко масштабировать — при необходимости мы можем поднять по несколько экземпляров каждого из них, потому что все они крутятся в Kubernetes: позволяет быстро их разворачивать и обеспечивать большую пропускную способность.

• Гибкость. За счет ролевой модели Gateway обеспечивается гибкость сервисов — конечному разработчику не нужно задумываться, как разграничивать доступы внутри конкретных сущностей.

• Универсальность, т.к. это решение можно распространять и для помощи другим агентам внутри EdTech-компаний.

• Независимость от конкретного стека. А раз это микросервисная архитектура, то дизайн каждого микросервиса не зависит от стека и можно использовать для разработки любой язык программирования. В нашем случае это Python, но никто не запрещает использовать тот же Go.

Минусы такой архитектуры:

• Первичная разработка инфраструктуры и всей обвязки требует серьезных ресурсов.

• Наличие узких горлышек. Например, наш универсальный API — хотя он тоже работает в Kubernetes и может достаточно быстро масштабироваться.

Обычно построение аналитики проходит через такие этапы:

• Таблички в экселе

• Дашборды, чарты и интерактивные графики

• Данные как сервис — когда мы упаковываем данные в конкретное приложение.

LMS — от англ. learning management system, система управления обучением.

API — это набор правил, по которому разные приложения могут общаться между собой. Простая аналогия: зная, какой язык имеет статус государственного в определённой стране, вы сможете получать информацию от её жителей (например, спрашивать, как пройти в библиотеку и сколько стоит хлеб).

Data Lake («озеро данных») — подход к хранению необработанной, неструктурированной и разрозненной информации из разных источников: таблиц, писем, документов, видео, аудио и др.

ETL-системы (extract, transform, load) помогают собрать данные из разных источников, очистить их, привести к единому стандарту и загрузить в хранилище данных.

Dremio — техническое решение для «озера данных». Даёт возможность получать прямой доступ к информации с помощью похожих на SQL запросов, даже если данные получены из NoSQL-базы.

В NoSQL базах данных информация хранится не в упорядоченных строках, а в колонках, графах, документах и других необычных представлениях.

dbt — SQL-фреймворк, на котором строят конвейеры работы с данными: управляют процессом того, как данные собираются, очищаются и попадают в систему назначения.

MVP (Minimum Viable Product) — минимально жизнеспособный продукт. Простыми словами: это неидеальный продукт, который всё же выполняет основную функцию и уже представлен пользователям. Ключевая идея MVP в том, чтобы создать продукт с минимальными усилиями, предложить его клиентам и после дорабатывать.

Prefect — система управления рабочими процессами, инструмент, который позволяет автоматизировать запуск и выполнение процессов обработки данных.

RabbitMQ — это брокер сообщений. Он позволяет разным приложениям и сервисам обмениваться сообщениями и взаимодействовать друг с другом. Поддерживает много языков программирования и фреймворков.

Vue.js — JavaScript-фрейворк для создания пользовательской части веб-приложений (фронтенда).