Разработка AI-тьютора для персонализированного обучения на LLM

AI-тьютор не масштабируется: где ломается персонализация

AI-тьютор работает не как чат с готовыми ответами, а как система, которая на каждом шаге собирает контекст: профиль ученика, историю попыток, пройденные темы и рубрику текущего задания. Чем точнее собран этот контекст, тем выше качество ответов тьютора — объяснение попадает в реальный пробел, а не в типовой раздел учебника. Именно на этом держится персонализированное обучение, и именно здесь начинаются ограничения.

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

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

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

Эффект внедрения: скорость ответа, точность, нагрузка на методистов

Внедрение AI-тьютора измеряется не числом диалогов, а четырьмя сдвигами: долей верных разборов, временем подготовки занятия, объёмом ручных правок и поведением системы под пиковой нагрузкой. Ниже — что именно проверяем на приёмке и какие значения считаем рабочим результатом.

Точность разбора на материалах курса

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

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

Сколько ручной работы снимается с методистов

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

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

Форматы AI-тьютора: когда подходит каждый режим

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

Работа на готовой модели и на своих материалах

Готовая модель стартует без подготовки данных: тьютор держит диалог и отвечает на общие вопросы, но не знает вашей терминологии. Дообучение на своих материалах снимает это — тьютор воспроизводит принятый стиль разбора и оперирует вашими определениями. Плата — корпус согласованных пар «вопрос — эталонный ответ»; обновление знаний требует повторного дообучения, поэтому режим подходит для устойчивой методики, а не для меняющихся регламентов.

Границы режима с поиском по базе знаний

Поиск по базе знаний отвечает фактами из конкретных документов и оставляет ссылку на источник — знание не «вшито» в модель, а подставляется в запрос. Гибридный режим соединяет оба подхода: стиль разбора ошибок берётся из дообучения, факты — из базы.

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

Этапы внедрения: от аудита материалов до передачи

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

Аудит материалов и разметка

1. Аудит материалов. Собираем конспекты, записи занятий, банк заданий и внутренние регламенты, отмечаем противоречия, дубли и темы без источников. Результат — карта покрытия: по каким темам тьютор сможет отвечать опираясь на материал, а где нужен авторский текст.
2. Разметка данных. Приводим всё к единому виду и размечаем: тема, уровень сложности, тип задания, типовые ошибки. Чистая разметка — то, на чём строится персонализация: тьютор подбирает следующее задание по конкретному пробелу, а не по среднему баллу.
3. Схема взаимодействия. Фиксируем сценарии диалога: как тьютор выясняет цель, как ведёт по цепочке тем, что делает при неуверенности. Отдельно описываем честный отказ — если материала нет, тьютор говорит об этом, а не достраивает ответ.

Проверка на реальных сценариях

• Настройка логики ответов. Вместе с методистами собираем эталонные вопросы и эталонные ответы: формулировки, допустимые вариации, критерии зачёта. Это и настройка, и будущая линейка для измерений.
• Приёмочная проверка. Прогоняем эталонный набор и смотрим долю корректных ответов, долю обоснованных отказов и корректность подбора сложности. Расхождения разбираем и правим, пока метрики не сойдутся с согласованными.
• Пилот на группе. Ограниченный поток учеников работает с тьютором в обычном режиме; логи диалогов показывают, где он теряет контекст или уходит в лишние пояснения.
• Обучение команды и передача. Методистам — как пополнять материалы и обновлять эталонные ответы, сопровождению — как читать логи и метрики качества. Передаём конфигурацию, схему взаимодействия, набор проверок и документацию.

Комплект передачи: конфигурации, схемы, регламенты, разметка

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

Документация и порядок обновления

• Схема потоков данных: путь от вопроса ученика через поиск по базе знаний и генерацию ответа до записи в журнал, с пометками, где хранится история диалога и как она обезличивается перед выгрузкой.
• Конфигурация тьютора: системные инструкции, шаблоны ответов, порог уверенности, ниже которого тьютор говорит «не знаю» вместо догадки, и правила цитирования источника.
• Эталонные вопросы: набор пар «вопрос — ожидаемый ответ» с привязкой к материалам курса. Прогон по ним — регрессия перед каждым обновлением: сразу видно, что просело.
• Регламент обновления: кто добавляет материал в базу знаний, в каком порядке проверяет качество после загрузки и как откатывает неудачное обновление, не трогая остальное.
• Документация по сопровождению: где лежат конфигурации, как поднять окружение на стенде, что попадает в журналы и к каким метрикам привязаны оповещения.

Права доступа и границы тем

• Роли: администратор, редактор материалов, преподаватель, наблюдатель — у каждой свой набор операций, редактор не может менять системные инструкции.
• Границы тем: белый список предметных областей, запрещённые темы и сценарий ответа при выходе за них — вместо свободной генерации.
• Доступ к данным: разделение учебных и персональных данных, срок хранения диалогов и порядок удаления по запросу.

Комплект считается принятым, когда заказчик своими руками проводит одно тестовое обновление материала, прогоняет эталонные вопросы и откатывает изменение.

Кейс: рост доли завершённых заданий после переработки сценариев

Онлайн-школа с несколькими десятками курсов запустила ИИ-тьютора как первую линию поддержки: он отвечал на вопросы по материалу и проверял домашние задания. Тьютор работал поверх учебной платформы школы (Moodle), в контур которой встроили модель актуальной ветки.

Как было до: шаблонные ответы и отвал на середине курса

Ответ собирался поиском по ключевым словам: студент получал абзац из методички даже тогда, когда спрашивал о конкретной ошибке в своём решении. На составных заданиях третьего-четвёртого модуля доходимость падала с 71% до 39%, а преподаватели вручную переписывали 6 из 10 ответов тьютора — модель не видела ни предыдущих попыток студента, ни критериев проверки конкретного задания.

Что изменилось: метрики до и после

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

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

Готовая модель или дообучение: что выбрать под задачу?

Короткий ответ: готовая модель закрывает AI-тьютора, который объясняет стандартный курс, проверяет ответы по эталону и держит диалог. Дообучение нужно там, где ценность сидит в вашей методике: своя терминология, свои разборы ошибок, свой порядок объяснения темы.

Качество разбора расходится именно на узких темах. Готовая модель уверенно пересказывает общий материал, но смешивает близкие понятия и подставляет правдоподобные, хотя неверные ссылки на источники. Дообучение на выверенных парах «вопрос — эталонный разбор» закрепляет вашу терминологию: модель реже уходит в общие рассуждения и точнее показывает, где ошибка в решении ученика.

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

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

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

Технические сомнения: данные, качество ответов, приватность

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

Что делать, если тьютор уверенно отвечает неверно?

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

Можно ли ограничить темы, на которые отвечает тьютор?

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

Выдержит ли решение рост потока учеников?

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

Как обновлять знания без остановки сервиса?

Новая версия базы знаний индексируется параллельно и подключается переключением, предыдущая остаётся доступной для быстрого отката. Изменения проверяются на контрольном наборе вопросов: если качество падает, релиз не уходит в работу.

Обсудим задачу: подберём режим и вернёмся с планом

Предметный разговор начинается не с демонстрации модели, а с ваших материалов. Чем конкретнее входные данные, тем меньше допущений мы закладываем в оценку проекта и тем точнее план внедрения — без формулировки «уточним по ходу».

• 2–3 сценария обучения с реальными вопросами учеников: разбор ошибок, подготовка к экзамену, отработка темы с нуля. По ним видно, где тьютор обязан задать уточняющий вопрос, а где сразу объяснять.
• 10–20 эталонных вопросов с ожидаемыми ответами. Из них собираем приёмочные проверки и определяем, насколько строго ответ должен опираться на ваши источники.
• Ограничения по данным: какие материалы допустимо использовать, есть ли персональные данные, что нельзя передавать во внешние сервисы, нужна ли изоляция по группам учеников.
• Ожидания по метрикам: доля верных ответов на эталонном наборе, время до первого полезного ответа, доля отказов «не знаю» вместо выдуманного факта.
• Текущая инфраструктура: платформа обучения, форматы материалов (конспекты, PDF, видео), способ авторизации учеников и то, кто ведёт и обновляет контент.
• Роли и доступы: кто видит диалоги, кто правит базу знаний, нужны ли модерация ответов и журнал действий тьютора.

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