1 of 19

ИИ-генерация в вузе: �вид со стороны преподавателей

Денис Королев · доцент · МИЭМ НИУ ВШЭ · Секция «AI / ML»

2 of 19

02

О СПИКЕРЕ

Денис Королев

Доцент · МИЭМ НИУ ВШЭ

О СЕБЕ

Заведующий лабораторией Сетевых видеотехнологий в МИЭМ НИУ ВШЭ
Соавтор проектной модели обучения МИЭМ
С этого года материалы и опросы – через ИИ (генерация и проверка)

ОПЫТ

31 год в мультимедии-в-образовании
23 года преподавания на инженерном факультете
22 года в создании цифровых сервисов для очного образования
20 лет в видеотехнологиях и стриминге
11 лет в МООК
1 год в ИИ-генерации учебного контента

КОНТАКТ

@dkorolev79 · dkorolevl@hse.ru

3 of 19

ЧАСТЬ 01

Контекст и задача

Опросы/экзамены: 3 минуты на студента.
Подготовка материалов сопоставима по срокам с временем его актуальности
Проектное обучение – нужен онбординг (индивидуальное обучение по запросу)
Решение: ИИ-проверятор, ИИ-генерация. Нейро-микрокурсы.

4 of 19

04

“

Это не идеальное решение, но оно возможное, достаточное, удовлетворяющее все стороны.

И уже работает.

5 of 19

05

ПРОБЛЕМА

Почему это важно

Было, но прошло:

Экзамен – форма обучения.
Вопрос в билете – тема для начала разговора.
Диалог приводит к пониманию.
Теория подтверждается практикой.

3

Минуты на студента

270

Студентов в потоке

300+

Проектов одновременно

Компромисс:

Опрос с автопроверкой. Обратная связь с разбором ответа от LLM
Автоподдержание диалога на экзамене
Генерация тематических материалов и вопросников (КИМ), включая иллюстрации
Банк материалов для онбординга в проекты

1400

Студентов в проектах

Всего в МИЭМе:

На потоковом экзамене:

6 of 19

06

СРАВНЕНИЕ ПОДХОДОВ

Что было и что стало

БЫЛО

Устный экзамен – нет времени и возможности пообщаться, зарегламентированность процедуры.
Последовательные ответы, процедура растягивается.

Подготовка материалов часто дольше времени его актуальности. Долго и трудоёмко.
Сочинение вопросов – муторно.

В проектах долгое погружение новичков в контекст
Дообучение по специфическим темам – на “старших товарищах”

СТАЛО

Экзамен – проходит параллельно, преподаватель видит процесс, студенты подходят с апелляцией
Копипаст, переключение вкладок/приложений фиксируются.

Студенты имеют полный актуальный материал курса
Подготовка темы – меньше часа (потом читать)

В проектах база знаний конвертируется в материал онбординга с автопроверкой
Знания далее подтверждаются практикой

7 of 19

07

ДЕМОНСТРАЦИЯ: ЭКЗАМЕН

8 of 19

08

ДЕМОНСТРАЦИЯ: ЭКЗАМЕН

9 of 19

09

АРХИТЕКТУРА РЕШЕНИЯ

Использование n8n

n8n использовался как middleware-слой между интерфейсом, ML-модулями и инфраструктурой

На этапе прототипирования нам было важно быстро собирать и менять сценарии взаимодействия между ботом, LLM и инфраструктурными сервисами.� Вместо написания отдельного backend для каждой интеграции мы использовали n8n как слой оркестрации.

Фактически он выступал middleware между мессенджером, ML-модулями и инфраструктурой. Это позволило визуально собирать workflow, быстро менять логику опросов и тестировать новые сценарии без полного переразвертывания системы.

Отдельно это упростило работу с асинхронными событиями, отказоустойчивостью при обращении к LLM API. Для исследовательского и быстро меняющегося ML-продукта такой подход оказался существенно быстрее классической backend-разработки.

10 of 19

10

АРХИТЕКТУРА РЕШЕНИЯ

Три компонента системы

01 · Data layer

Учебные материалы и контекст курса

02 · Model layer

LLM-оценивание

03 · Serving

Оркестрация и взаимодействие

Учебные материалы, вопросы и ответы курса
Векторный поиск по материалам для RAG
Хранение состояний сессий и результатов опросов

Оценивание по критериям полноты и корректности
RAG +�prompt engineering + rubric-based grading
Система судей

n8n как middleware
Интеграция мессенджеров, LLM API и инфраструктуры
Масштабирование под синхронные опросы большого потока студентов

Архитектурно систему можно разделить на три независимых слоя.

Первый — Data layer. Здесь находятся учебные материалы курса, вопросы, результаты опросов и состояния диалога. Использовался векторный поиск по материалам курса для RAG.

Второй слой — основной ML-контур системы. Здесь LLM выполняет оценивание ответов по критериям полноты и корректности (можно развернуть, что это такое) и генерирует обратную связь на основе материалов курса. Для повышения качества помимо prompt engineering использовались rubric-based grading, retrieval augmentation и система судей (оценивание полноты и корректности происходит не в едином запросе, а на каждый критерий идет отдельный с подробным промптом, уточняющим существование другого).

Третий слой — Serving и orchestration. Он отвечает за интеграцию всех компонентов между собой: мессенджеров, LLM API, баз данных и хранилищ. Здесь же реализована асинхронная обработка запросов и механизмы устойчивости к пиковым нагрузкам во время синхронных экзаменов.

LLM: Qwen3.5-9B-Q4

Эмбеддер для RAG: multilingual-e5-large

Векторная БД: Qdrant

Инференс LLM: Trition Inference Server

Хранилище истории чатов: Redis

API: кастомный докерфайл с FastAPI

11 of 19

11

АРХИТЕКТУРА РЕШЕНИЯ

Инструменты

LLM

Эмбеддер

Векторная БД

QWEN3.5-9B-Q4

Multilingual-e5-large

Qdrant

Инференс LLM

История чатов

API

Triton Inference Server

Redis

Кастомный докерфайл с FastAPI

Архитектурно систему можно разделить на три независимых слоя.

Первый — Data layer. Здесь находятся учебные материалы курса, вопросы, результаты опросов и состояния диалога. Использовался векторный поиск по материалам курса для RAG.

Второй слой — основной ML-контур системы. Здесь LLM выполняет оценивание ответов по критериям полноты и корректности (можно развернуть, что это такое) и генерирует обратную связь на основе материалов курса. Для повышения качества помимо prompt engineering использовались rubric-based grading, retrieval augmentation и система судей (оценивание полноты и корректности происходит не в едином запросе, а на каждый критерий идет отдельный с подробным промптом, уточняющим существование другого).

Третий слой — Serving и orchestration. Он отвечает за интеграцию всех компонентов между собой: мессенджеров, LLM API, баз данных и хранилищ. Здесь же реализована асинхронная обработка запросов и механизмы устойчивости к пиковым нагрузкам во время синхронных экзаменов.

LLM: Qwen3.5-9B-Q4

Эмбеддер для RAG: multilingual-e5-large

Векторная БД: Qdrant

Инференс LLM: Trition Inference Server

Хранилище истории чатов: Redis

API: кастомный докерфайл с FastAPI

12 of 19

12

90,8%

ГЛАВНАЯ МЕТРИКА

Accuracy согласованности с экспертной оценкой�

Сравнение оценок LLM и преподавателей на реальных ответах студентов с допуском в шаг

Датасет из открытых ответов образовательного процесса
Rubric-based grading: полнота + корректность ответа, независимые LLM-судьи
RAG + векторный поиск по материалам курса

Основной метрикой для нас была согласованность автоматической оценки с экспертной оценкой преподавателей.

Финальная версия системы показала accuracy 90.8% на датасете реальных ответов студентов, собранных в рамках образовательного процесса. При оценке мы сравнивали итоговые баллы, выставленные системой, с ручной проверкой преподавателей.

На качество результата повлияли несколько факторов.

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

Во-вторых, использование rubric-based grading и системы независимых LLM-судей. Вместо единой общей оценки модель отдельно анализировала полноту и корректность ответа, после чего итоговый балл формировался на основе нескольких независимых оценок. Такой подход заметно снизил вариативность результатов и повысил согласованность с экспертной проверкой.

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

13 of 19

13

ДЕМОНСТРАЦИЯ: СЕРВИС ОПРОСОВ

14 of 19

14

Генератор курсов

15 of 19

15

Генератор курсов

16 of 19

16

АРХИТЕКТУРА РЕШЕНИЯ

Особенности генерации

ВАШ контекст

Объём

Ограничения

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

Одна “лекция” (тема):

80 страниц текста
50-80 вопросов и тестов
Это материал курса МООК

Картинки:

На каждый подраздел �(2 уровень заголовка) – промпт на иллюстрацию

Формулы пока не приручали
Обычные технические темы без сложных формул получаются
Программные темы в среднем получаются лучше аппаратных
Опрос с LLM через LTI или external grader

Обязательно вычитывать весь материал!

Лажа будет. Не “если”, а “когда”.

Архитектурно систему можно разделить на три независимых слоя.

Первый — Data layer. Здесь находятся учебные материалы курса, вопросы, результаты опросов и состояния диалога. Использовался векторный поиск по материалам курса для RAG.

Второй слой — основной ML-контур системы. Здесь LLM выполняет оценивание ответов по критериям полноты и корректности (можно развернуть, что это такое) и генерирует обратную связь на основе материалов курса. Для повышения качества помимо prompt engineering использовались rubric-based grading, retrieval augmentation и система судей (оценивание полноты и корректности происходит не в едином запросе, а на каждый критерий идет отдельный с подробным промптом, уточняющим существование другого).

Третий слой — Serving и orchestration. Он отвечает за интеграцию всех компонентов между собой: мессенджеров, LLM API, баз данных и хранилищ. Здесь же реализована асинхронная обработка запросов и механизмы устойчивости к пиковым нагрузкам во время синхронных экзаменов.

LLM: Qwen3.5-9B-Q4

Эмбеддер для RAG: multilingual-e5-large

Векторная БД: Qdrant

Инференс LLM: Trition Inference Server

Хранилище истории чатов: Redis

API: кастомный докерфайл с FastAPI

17 of 19

17

Генератор курсов

Видеотехнологии:�протоколы потокового видео

Stepik

18 of 19

Q&A

Задавайте вопросы — обсудим детали

@dkorolev79 · ODS.AI/EVENTS/DATAFEST2026

19 of 19

@dkorolev79

EMAIL

dkorolev@hse.ru

SLIDES

google.slides

Спасибо!