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

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

AI-тьютор працює не як чат із готовими відповідями, а як система, яка на кожному кроці збирає контекст: профіль учня, історію спроб, пройдені теми та рубрику поточного завдання.

Чим точніше зібрано цей контекст, тим вища якість відповідей тьютора — пояснення потрапляє в реальну прогалину, а не в типовий розділ підручника. Саме на цьому тримається персоналізоване навчання, і саме тут починаються обмеження.

Ламається все на довгих курсах. Профіль зростає, історія спроб налічує сотні подій, і в запит потрапляє лише частина — решту відкидають за формальними ознаками.

Відповіді сходяться до одного й того самого пояснення для різних учнів: персоналізація вироджується в переказ модуля, а учень перестає отримувати реакцію на свою конкретну помилку. Зовні система працює, змістовно — вже ні.

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

Методисти правлять одні й ті самі невдалі відповіді, оновлюють еталони після кожної правки програми й не встигають перевіряти, чи не розійшлася оцінка із задумом курсу.

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

Далі розбираємо, як це закривається: який контекст збирати, як перевіряти відповіді автоматично й де свідомо залишити методиста в контурі.

Ефект впровадження: швидкість відповіді, точність, навантаження на методистів

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

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

Тьютор відповідає не за загальною енциклопедією, а за програмою конкретного курсу: методичні матеріали, приклади рішень і критерії оцінювання завантажено в індекс, і кожна відповідь надходить із посиланням на джерело.

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

Після налаштування сценаріїв розбору, розбиття матеріалу на змістові блоки й окремої перевірки на межових завданнях частка правильних розборів виходить на 85–90%. Решта розбіжностей стосується спірних формулювань у самих завданнях — це вже привід правити умови, а не модель.

Скільки ручної роботи знімається з методистів

Автоматична перевірка забирає рутину: завдання з формалізованою відповіддю — тести, розрахунки, задачі з прогоном рішення — перевіряються одразу, методисту залишаються тільки роботи, де тьютор відзначив неоднозначність.

Частка ручних правок у перевірених роботах падає з більшості до поодиноких випадків, і це видно із журналу: кожне втручання фіксується з причиною.

Час підготовки заняття скорочується з кількох годин до короткої вичитки: тьютор збирає чернетку розбору, добір прикладів і список типових помилок групи, методист править формулювання й додає те, що знає тільки він.

Під піковим навантаженням — перед дедлайном або іспитом — система тримає чергу запитів і розподіляє її між копіями сервісу, тому відповіді надходять без зниження якості й без ручного «гасіння» з боку викладачів.

Формати AI-тьютора: коли підходить кожен режим

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

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

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

Плата — корпус узгоджених пар «питання — еталонна відповідь»; оновлення знань потребує повторного донавчання, тому режим підходить для сталої методики, а не для змінних регламентів.

Межі режиму з пошуком по базі знань

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

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

Етапи впровадження: від аудиту матеріалів до передачі

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

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

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

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

• Налаштування логіки відповідей. Разом із методистами збираємо еталонні питання та еталонні відповіді: формулювання, допустимі варіації, критерії заліку. Це і налаштування, і майбутня лінійка для вимірювань.
• Приймальна перевірка. Проганяємо еталонний набір і дивимося частку коректних відповідей, частку обґрунтованих відмов і коректність підбору складності. Розбіжності розбираємо й правимо, поки метрики не зійдуться з узгодженими.
• Пілот на групі. Обмежений потік учнів працює з тьютором у звичайному режимі; логи діалогів показують, де він втрачає контекст або йде в зайві пояснення.
• Навчання команди та передача. Методистам — як поповнювати матеріали й оновлювати еталонні відповіді, супроводу — як читати логи й метрики якості. Передаємо конфігурацію, схему взаємодії, набір перевірок і документацію.

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

Здача AI-тьютора — це не демонстрація працюючого чату, а комплект, який команда замовника веде далі сама.

Усе, що налаштовувалося під предметну область, фіксується в артефактах: конфігурація тьютора, схема потоків даних, набір еталонних питань, регламент оновлення матеріалів і правила доступу. Нижче — що саме лежить у передачі та за якою ознакою це можна перевірити на прийманні.

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

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

Права доступу та межі тем

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

Комплект вважається прийнятим, коли замовник власними руками проводить одне тестове оновлення матеріалу, проганяє еталонні питання й відкочує зміну.

Кейс: зростання частки завершених завдань після переробки сценаріїв

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

Як було до: шаблонні відповіді та відсів у середині курсу

Відповідь збиралася пошуком за ключовими словами: студент отримував абзац із методички навіть тоді, коли питав про конкретну помилку у своєму рішенні.

На складених завданнях третього-четвертого модуля завершуваність падала з 71% до 39%, а викладачі вручну переписували 6 із 10 відповідей тьютора — модель не бачила ні попередніх спроб студента, ні критеріїв перевірки конкретного завдання.

Що змінилося: метрики до та після

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

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

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

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

Якість розбору розходиться саме на вузьких темах. Готова модель впевнено переказує загальний матеріал, але змішує близькі поняття й підставляє правдоподібні, хоч і неправильні посилання на джерела.

Донавчання на вивірених парах «питання — еталонний розбір» закріплює вашу термінологію: модель рідше йде в загальні міркування й точніше показує, де помилка в рішенні учня.

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

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

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

Донавчена версія — ваш артефакт: поведінка відтворювана, але нові предмети й правки методики потребують перенавчання.

Частіше виграє гібрид: готова модель веде діалог і тримає загальну мову, донавчання відповідає за вузький шар методики та розбір типових помилок.

За висновками Огляду практик адаптації мовних моделей і нашим досвідом такий варіант дає якість, близьку до повного донавчання, за помітно меншого обсягу підготовки матеріалів і коротшого терміну запуску.

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

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

Що робити, якщо тьютор упевнено відповідає неправильно?

Генерація обмежена базою знань: відповідь збирається за знайденими фрагментами з посиланням на джерело. Якщо релевантних фрагментів немає, тьютор повідомляє, що в матеріалах цього немає, замість здогаду. Частку відповідей із підтвердженим джерелом і кількість ескалацій до викладача видно в журналі.

Чи можна обмежити теми, на які відповідає тьютор?

Так, дозволені теми задаються списком на рівні конфігурації: запит поза списком отримує ввічливу відмову та пропозицію звернутися до викладача. Для чутливих курсів додаємо правила формулювань і перевірку відповіді перед видачею.

Чи витримає рішення зростання потоку учнів?

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

Як оновлювати знання без зупинки сервісу?

Нова версія бази знань індексується паралельно й підключається перемиканням, попередня залишається доступною для швидкого відкату. Зміни перевіряються на контрольному наборі питань: якщо якість падає, реліз не йде в роботу.

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

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

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

У відповідь ми віддаємо оцінку проєкту з розбивкою за етапами, план впровадження з контрольними точками й межі першої версії: які сценарії закриваємо одразу, які — у другій ітерації. Якщо частини матеріалів немає, запропонуємо, чим їх замінити на час пілоту, щоб не зсувати старт.