Instructional lesson planning assistant

Помічник з планування навчальних уроків перетворює стандартний запит викладача — «план уроку з теми X для 7 класу на 45 хвилин» — на структуровану чернетку з цілями, етапами, матеріалами та перевірочними завданнями. Асистент працює у зв'язці з CMS або LMS компанії та спирається на затверджену навчальну програму. Мета — зняти з викладача 70-80% часу на чернетку, залишивши йому творчу роботу: адаптацію під клас, вибір прикладів, фінальне редагування.

Процес за кроками:

1. Викладач задає параметри через веб-форму або чат-інтерфейс: предмет, тема, клас/рівень, тривалість, тип заняття (лекція, семінар, лабораторна), освітній стандарт.
2. AI-агент звертається до CMS/LMS та витягує релевантний контекст: навчальні стандарти, попередні плани з теми, методичні рекомендації відділу.
3. RAG-пошук знаходить фрагменти з внутрішньої бази знань — затверджені матеріали, успішні кейси, готові завдання.
4. Мовна модель генерує чернетку плану: цілі навчання, структура уроку з таймінгом, активності, список матеріалів, перевірочні питання.
5. Асистент прив'язує чернетку до конкретних стандартів і компетенцій, показує покриття навчальної програми.
6. Викладач редагує чернетку, затверджує фінальну версію, зберігає в CMS як новий план.
7. Схвалені плани поповнюють базу RAG — з часом якість наступних чернеток зростає завдяки накопиченню власних шаблонів і термінології.

Що асистент НЕ робить:

• Не проводить заняття і не оцінює учнів. Це інструмент підготовки планів, а не викладання чи контролю.
• Не замінює методичну експертизу. Чернетка потребує перевірки викладачем перед використанням з класом.
• Не генерує матеріали «з повітря». Якщо в базі немає даних з теми або стандарту, асистент явно повідомляє про прогалину, а не фантазує.

Технічний флоу спирається на три компоненти: CMS/LMS як джерело правди, RAG-шар для вилучення контексту, мовна модель для генерації чернетки. Асистент не переказує знання з пам'яті моделі — він дістає релевантні фрагменти з перевірених внутрішніх джерел і формує план суворо за ними.

Потік обробки запиту

1. Викладач надсилає запит через інтерфейс: веб-форма, чат-бот або плагін для CMS.
2. Backend парсить параметри (предмет, клас, тривалість, стандарт) і формує структурований промпт.
3. RAG-модуль виконує семантичний пошук по векторній базі: навчальна програма з предмету, минулі плани по темі, методичні рекомендації.
4. Знайдені фрагменти додаються в контекст моделі разом із шаблоном структури плану (цілі → етапи → активності → перевірка).
5. Мовна модель генерує чернетку, дотримуючись необхідних полів і формату.
6. Post-processing перевіряє прив'язку до стандартів, підсвічує згадки компетенцій, форматує таблицю тайминга уроку.
7. Чернетка повертається викладачеві у редагованому вигляді — в CMS, Google Docs або вбудованому редакторі.
8. Після затвердження план зберігається в CMS і індексується в RAG як нове джерело.

Компоненти системи

Реалізація за етапами

1. Тиждень 1: аудит навчального контенту. Інвентаризація CMS/LMS, вивантаження планів уроків, стандартів, методичок у структурованому вигляді.
2. Тиждень 1-2: налаштування vector DB та embedding pipeline. Індексація наявних матеріалів для першого RAG-контуру.
3. Тиждень 2-3: промпт-інжиніринг структури плану. Тестування на 20-30 реальних запитах від методистів.
4. Тиждень 3-4: UI-інтеграція. Плагін до CMS або окремий web-інтерфейс з авторизацією через SSO.
5. Тиждень 4: пілот з 5-10 викладачами. Збір feedback, коригування промптів, додавання edge cases.
6. Після пілоту: розширення на весь відділ. Feedback loop для покращення чернеток через дообучення на схвалених планах.

Якість і guardrails

Чернетка завжди проходить через викладача — асистент не публікує плани автоматично. Вбудовані перевірки: відповідність тривалості уроку, прив'язка до стандарту, наявність перевірних завдань. Якщо модель не знаходить потрібного контексту в RAG, вона повертає порожні секції з позначкою «даних у базі немає» замість вигадки. Логи запитів і відповідей зберігаються для аудиту методистами.

Впровадження потребує структурованого навчального контенту, доступу до LLM API та готовності методичної команди. Без цих трьох елементів проєкт іде в нескінченну підготовку даних ще до першого чернетки.

Дані та доступи

• CMS або LMS з навчальним контентом: навчальна програма, плани уроків, методичні матеріали. Рекомендований мінімум для первинної індексації RAG — кілька сотень одиниць контенту.
• Освітні стандарти у структурованому вигляді: PDF/DOCX з чіткою ієрархією або API до каталогу стандартів.
• Доступ до LLM API (AI-модель або аналог) з лімітами під плановане навантаження.
• Хостинг для vector DB та orchestration шару: власний сервер або хмара.

Готовність команди

• Методист або Head of Content — відповідальний за структуру плану, критерії якості, приймання чернеток.
• Викладач-амбасадор: 1-2 особи для пілота та формування feedback.
• Технічна роль: backend/інтеграційний інженер або зовнішній підрядник для CMS-конектора, RAG-шару, UI.
• Розуміння процесу: хто затверджує фінальні плани, де вони публікуються, хто оновлює базу знань.

Що додатково допомагає

• Версіонування планів у CMS — легше відстежувати еволюцію затверджених версій.
• Таксономія предметів і класів — спрощує маршрутизацію запитів та пошук у RAG.
• SSO для авторизації — викладачі не створюють окремі акаунти.

Таймлайн

Weekend-складність означає 2-4 тижні до робочого MVP за наявності структурованого контенту та готової команди. Без інвентаризації навчальних матеріалів термін зсувається на 2-3 тижні. Повноцінний rollout із feedback loop та донавчанням займає 6-8 тижнів з моменту запуску пілота.