AI-платформа для обучения в 2026 году: уроки разработки Scholarly для 15 000 пользователей

Почему этот гайд написала Фора Софт

Мы разрабатываем edtech-продукты с 2005 года: виртуальные классы, площадки для живых лекций, AI-тьюторы, системы прокторинга, корпоративные порталы L&D. Scholarly — учебная платформа, которую мы выпустили для австралийского клиента, — сегодня обслуживает 15 000 активных слушателей и проводит живые лекции для 2 000 студентов в одной сессии на WebRTC и LiveKit. Цифры, архитектурные решения и подходы к комплаенсу в этом гайде — прямо из этого проекта и десятка похожих.

Мы работаем по методологии Agent Engineering: наши senior-инженеры управляют AI-агентами на этапах дизайна, генерации кода, написания тестов и ревью. Это позволяет сжать классический MVP AI-LMS с 7–9 месяцев до 4–6 при том же качестве и меньшей командой.

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

Что такое Scholarly — кратко

Scholarly — это онлайн-платформа для обучения «всё в одном», которую мы разработали для австралийского образовательного провайдера, переросшего связку из Zoom, Discord и разрозненных инструментов для совместной работы. Она объединяет живые лекции, записи, управление курсами, домашние задания, тестирование и доступ для родителей в один продукт и сегодня обслуживает 15 000 пользователей.

Четыре роли, одна платформа:

• Преподаватели проводят живые лекции до 2 000 студентов в одной сессии со скриншарингом, виртуальной доской, текстовым чатом и записью занятий. Каждая запись автоматически прикрепляется к курсу.
• Студенты подключаются к живым трансляциям, смотрят записи, проходят материалы, сдают тесты, отправляют домашние задания и получают обратную связь — всё в одном месте.
• Родители видят курсы своих детей, расписание, прогресс и учебные материалы — деталь, о которой K-12-покупатели спрашивают всегда.
• Администраторы и супер-администраторы создают курсы, планируют события, загружают материалы, управляют пользователями и ведут справочник.

Остальная часть гайда обобщает опыт Scholarly и более широкий ландшафт edtech 2026 года, чтобы ответить на вопрос, который чаще всего задают нам фаундеры: как мне разработать что-то подобное и где здесь место для AI?

Рынок AI в образовании в 2026 году — коротко

Мировой edtech в 2026 году оценивается примерно в 16 трлн ₽ и растёт темпами около 13% CAGR. Сегмент AI растёт куда быстрее: опубликованные прогнозы оценивают AI в образовании в 2026 году в 675–750 млрд ₽ с темпом 34–42% CAGR до 2030 года. Внедрение перешло из стадии эксперимента в стадию умолчания: 92% студентов используют AI для обучения, 60% преподавателей применяют AI как минимум раз в неделю, а 83% учреждений планируют развернуть AI-ассистентов преподавателя до конца 2026 года.

Доминируют три сегмента:

• K-12 — самая высокая нагрузка по комплаенсу (FERPA, COPPA, родительское согласие). Родители как полноценная роль пользователя — жёсткое требование, а не пожелание.
• Высшее образование — ассистенты для исследований и преподавания, обнаружение плагиата и работ, написанных AI, аудит академической добросовестности.
• Корпоративный L&D — время до выхода на компетенцию, обучение комплаенсу, рекомендации траекторий навыков. Это самый быстрорастущий сегмент.

Практический вывод: edtech, который побеждает в 2026 году, сочетает крепкое ядро LMS с тремя-четырьмя хорошо интегрированными AI-возможностями, а не с десятком сырых фич.

Своя разработка или готовое решение: как решить до первой строки кода

Купить LMS и наложить сверху AI — ответ по умолчанию для примерно 80% команд. Разрабатывать на заказ стоит, когда верно одно из четырёх: методика нестандартна, масштаб экстремальный, профиль комплаенса необычен или продукту нужен медиа- или AI-пайплайн, который не вмещается в коробочную LMS. Scholarly подходит под все четыре пункта: живые занятия на 2 000 мест, собственная модель курса, требования к хранению данных в Азиатско-Тихоокеанском регионе, лекционный UX на базе WebRTC.

Для более широкого обсуждения дилеммы «своя разработка или готовое решение» в продуктах с высокой долей видео см. наш материал об альтернативах Vonage Video API.

AI-возможности, которые реально дают результат

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

Адаптивные траектории обучения

База данных поведения плюс модель принятия решений, которая выстраивает последовательность контента, убирает уже освоенные пререквизиты и подкидывает повторение, когда слушатель буксует. Опубликованные кейсы (Squirrel AI, Carnegie MATHia, Duolingo) показывают, что время до достижения нужного уровня сокращается на 10–34% по сравнению с неадаптивными группами. Главный подводный камень — проблема холодного старта: адаптивная логика начинает работать только после примерно 10 взаимодействий со слушателем, поэтому сначала продумайте сильный путь по умолчанию.

AI-тьюторы и ассистенты на базе RAG

Чат на LLM, заземлённый на ваш курсовой контент через Retrieval-Augmented Generation (RAG). Тьютор видит урок, главу учебника и недавние ответы слушателя — и только потом отвечает. Khanmigo и LearnLM задают планку: сократический стиль, никакой раздачи готовых ответов. Стек: векторная БД (Qdrant, Weaviate, Pinecone) + LLM (Claude, GPT-4, Llama 3) + ограждения + якоря цитирования.

Автоматическая проверка и детекция плагиата и AI-текста

Проверка по рубрикам для эссе, кода и математики. Детекция копипаста и сгенерированных AI работ (Turnitin Clarity, HackerRank). Честная оговорка: детекция AI-текста пока несовершенна — до 94% AI-текста проскальзывает через некоторые инструменты, а ложные срабатывания непропорционально бьют по тем, для кого английский неродной. Используйте детекцию как сигнал для ревью с участием человека, а не как приговор.

Генерация контента и квизов с помощью AI

Банки вопросов для квизов, сгенерированные из транскриптов лекций или загруженных PDF. Стоимость ничтожна — 0,75–3,75 ₽ за вопрос на масштабе. Риск — утечка авторских прав: если обучаете модель на нелицензированном контенте, наследуете ответственность. Генерируйте только из лицензированного или собственного контента пользователя.

Распознавание речи, перевод, живые субтитры

Модели уровня Whisper для транскрипции, провайдеры уровня Verbit для живых субтитров и слой перевода, который доносит лекцию до неносителей языка. Это же практически бесплатно даёт вам соответствие WCAG 2.2. Архитектуру видео-перевода мы держим в отдельном плейбуке.

Предсказательный скоринг риска отсева

Аналитика на потоке событий, которая помечает слушателей с риском бросить курс за 2–4 недели до этого, чтобы кураторы успели вмешаться. В корпоративном L&D это единственная возможность, за которую покупатели готовы платить больше всего: она превращает слушателей в выпускников.

Видеоаналитика и сигналы вовлечённости

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

Эталонная архитектура: стек Scholarly

Реальный технологический стек Scholarly, без изменений:

• Фронтенд — JavaScript, React, Next.js. Серверный рендеринг для маркетинговых страниц и каталога курсов, клиентский — для комнаты живой лекции.
• Бэкенд — микросервисы на Go и Node.js. Go обрабатывает критичные к производительности участки (аутентификация, маршрутизация живых сессий, метаданные медиа); Node.js — контент, уведомления и интеграции.
• Живое видео — WebRTC + LiveKit, с фолбэком DASH/HLS для воспроизведения. LiveKit хорошо масштабируется до 2 000 участников в одной комнате.
• API-слой — GraphQL. Позволяет клиенту запросить ровно те поля, которые ему нужны, и сокращает количество обращений на сложных экранах с деталями курса.
• Инфраструктура — Kubernetes для оркестрации микросервисов, плюс управляемый кластер Postgres, объектное хранилище для записей и CDN для статики.
• AI-слой (опциональные расширения) — LLM-провайдер (Claude, GPT, Llama), векторная БД (Qdrant или Weaviate) для RAG, Whisper для транскрипции и feature store для адаптивной персонализации.

Шаблон масштабируется. Замените LiveKit на mediasoup или Kurento, если нужна серверная обработка медиа (см. наш гайд по Kurento Media Server). Замените Postgres на управляемый облачный аналог. Замените GraphQL на REST, если команде так удобнее. Главное — базовая декомпозиция: отделение плоскости живого видео от плоскости контента.

Живые лекции на 2 000 студентов в сессии

Запустить живую лекцию на 2 000 мест на WebRTC — это вам не «вставьте Zoom в iframe». Тут нужны три архитектурных решения, на которых спотыкаются 90% команд с первой попытки:

1. Вещательная модель, а не mesh. Преподаватель вещает, студенты подписываются. Один преподаватель отправляет одну (или несколько симулкаст) дорожек на SFU, SFU раздаёт их студентам. Студенты не отправляют видео, пока их не вызвали, — это удерживает суммарное число потоков на линейном, а не квадратичном уровне.

2. Publish-subscribe для взаимодействий. Чат, поднятая рука, опросы и реакции едут по отдельному pub/sub-каналу (Redis, NATS или управляемый аналог), а не по видеоплоскости. Перегрузка чата не должна снижать качество видео — никогда.

3. HLS-фолбэк для «длинного хвоста». Планшеты, старые Android-устройства и капризные сети иногда не способны удерживать сессию WebRTC 90 минут. Дайте им живой поток HLS или DASH с задержкой 5–10 секунд: плохое видео лучше, чем никакого.

Подробный разбор компромиссов медиасервера см. в нашем материале P2P vs MCU vs SFU и в гайде по архитектуре WebRTC для бизнеса в 2026 году.

Комплаенс: GDPR, FERPA, COPPA, WCAG 2.2, SOC 2

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

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

Модель затрат на собственную AI-платформу для обучения

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

Плюс 10–20% на сторонние позиции, которые мы всегда расписываем отдельно: подготовка контента и тестов, аудиты безопасности, ревью по WCAG, интеграция SSO, проверка соответствия SCORM/xAPI. Анализ компромиссов между поминутной оплатой и self-hosted на медиа-стороне см. в нашем материале о сравнении затрат LiveKit и Agora.

Мини-кейс: 12-месячная разработка Scholarly

Австралийская образовательная компания пришла к нам, работая на Zoom для лекций, Discord для чата, SaaS-LMS для заданий и Google Drive для материалов. У них было около 3 000 пользователей, и они теряли 20+ часов в неделю на администрирование, синхронизируя данные между инструментами. Им нужна была одна платформа, своя методика и запас для роста до 15 000+ пользователей.

Наш 12-месячный план дал заказную LMS на микросервисах Go/Node за фронтендом на React/Next.js, WebRTC плюс LiveKit для живых лекций с масштабированием до 2 000 студентов в комнате, GraphQL для сложных представлений курсов и Kubernetes для рантайма. AI-агенты в нашем пайплайне разработки сгенерировали порядка 70% обвязки сервисов, OpenAPI-спецификаций и тестов параллельно с ревью senior-инженеров — именно так мы удержали сроки.

Итог: 15 000 активных пользователей сегодня, до 2 000 студентов в одной живой лекции, время на администрирование сократилось с 20+ часов в неделю до менее чем 4, пайплайн записи лекций полностью автоматизирован. Свяжитесь с нами, и мы набросаем похожий путь для вашей аудитории.

Фреймворк принятия решения — выпустить за пять вопросов

Пройдите эти вопросы до того, как принять решение «своё или готовое». «Нет» на вопросы 1 и 2 почти наверняка означает, что вам подойдёт SaaS-LMS.

1. Ваша методика стандартная или собственная? Если учебный дизайн укладывается в «курсы с видео и квизами», любая крупная LMS его потянет. Если программе нужна ветвящаяся логика, нестандартные типы оценивания или продуктовый UX, заказная разработка становится привлекательной.

2. Какой потолок одновременной нагрузки в одной живой сессии? До 500 — спокойно тянет большинство платформ. От 500 до 2 000 — подталкивает к WebRTC-ориентированному дизайну вроде Scholarly. Выше 10 000 — это уже территория гибрида WebRTC + HLS.

3. Какие регламенты комплаенса применимы? GDPR, FERPA, COPPA, доступность, SOC 2 — каждый добавляет от 4 до 12 недель к разработке. Объединение ваших регламентов задаёт минимально реалистичные сроки.

4. Где AI находится в цикле обучения? Если AI — это и есть продукт (автономный тьютор, полностью адаптивная система), он должен быть встроенным. Если AI лишь дополняет существующий контент, можно стартовать с LMS плюс LTI-плагин.

5. Есть ли в команде девопс-инженер или SRE? Своя инфраструктура требует человека, который ведёт Kubernetes, CI/CD, учения по аварийному восстановлению и агрегацию логов. Никого на этой роли? Оставайтесь на управляемой LMS, пока не наймёте.

Пять подводных камней в проектах AI-платформ для обучения

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

2. Принимать срабатывание детектора за вердикт. У детекторов AI-текста и плагиата высокий уровень ложноположительных срабатываний, особенно на текстах неносителей английского. Используйте их как триаж-сигналы, открывающие ревью с участием человека, а не как основание для автоматических санкций.

3. Игнорировать проблему холодного старта. Адаптивным траекториям нужно около 10 взаимодействий со слушателем, чтобы хорошо персонализироваться. Заранее продумайте сильную программу по умолчанию и фазу разогрева; не запускайтесь с обещанием «100% адаптивно».

4. Прикручивать комплаенс в конце. Право на удаление по GDPR требует пайплайна мягкого удаления во всех сервисах. FERPA — аудируемого доступа к записям. WCAG — субтитров в живом пайплайне. Дооборудование каждого из этих пунктов удваивает работу.

5. Путать персонализацию с вовлечением. Адаптивный контент сам по себе упирает завершаемость в 60–70%. Геймификация, социальное доказательство, давление когорты и дедлайны двигают цифру дальше. Планируйте и то, и другое.

KPI: что измерять на AI-платформе для обучения

KPI качества. Доля завершения курса ≥ 70%, удержание знаний через 30 дней ≥ 65%, точность ответов AI-тьютора (выборочный аудит) ≥ 85%, точность субтитров ≥ 93%. Ниже этих значений вы добавляете шум, а не ценность.

Бизнес-KPI. Время до выхода на компетенцию для ролевых траекторий (целевой ориентир: на 20% меньше, чем без адаптивности), NPS ≥ 45, стоимость выпускника (цель: ≤ 375 ₽ для корпоративного L&D, зависит от курса для платных edtech-продуктов), ежемесячные активные слушатели, конверсия из триала в платных.

KPI надёжности. Успешный заход на живую лекцию ≥ 98%, успешная запись лекции ≥ 99,5%, P95 TTFB страницы контента < 800 мс, uptime ≥ 99,9%. Алерты по любому из этих показателей ловят плохие деплои раньше пользователей.

Как мы встраиваем AI в существующую LMS

Большинству клиентов не нужна полная переразработка вроде Scholarly — им нужны AI-возможности поверх той платформы, которую они уже используют. Наш стандартный формат работы для этого — 6–10 недель:

• Недели 1–2 — аудит существующего контента, выбор двух-трёх AI-возможностей с самым высоким измеримым ROI для ваших слушателей.
• Недели 3–6 — развёртывание индекса RAG, подключение LLM-провайдера, выпуск MVP тьютора или автопроверяльщика как LTI-плагина или встроенного модуля.
• Недели 7–10 — оценка на реальных данных слушателей, настройка промптов, замыкание петли с ревью человека, упрочнение под комплаенс, выкатка в продакшн.

Углублённый разбор дизайна умных тьюторов см. в нашем гайде по AI-системам тьюторинга для преподавателей.

Шаблоны безопасности, которые проходят процедуру закупки

Каждая закупочная презентация в edtech в 2026 году задаёт одни и те же восемь вопросов: где живут данные, у кого к ним доступ, как они шифруются, как обрабатывается инцидент, что будет, если слушатель отзовёт согласие, как проверяется LLM-провайдер, где аудит-лог и как часто проводится pentest. Заготовьте ответы до созвона — и сделка закроется на недели раньше.

Базовые шаблоны, которые мы закладываем в каждый проект уровня Scholarly: централизованный провайдер идентификации с SSO (SAML, OIDC, при необходимости LTI 1.3), шифрование в покое и при передаче с ротацией ключей, разделение данных по тенантам, неизменяемые аудит-логи, выделенная роль «AI-ревью», которая видит транскрипты тьютора, автоматические политики хранения данных, согласованные с GDPR/FERPA/COPPA, и письменный план реагирования на инциденты, отрабатываемый раз в квартал.

Для рисков, специфичных для LLM, держите в CI набор тестов на prompt injection, ведите allow-list системных промптов, очищайте персональные данные перед отправкой LLM-провайдеру и логируйте каждое AI-взаимодействие со сроком хранения, соответствующим вашим срокам по FERPA/GDPR. Наш материал «Безопасность WebRTC простым языком» параллельно покрывает медиаплоскость.

Какая LLM должна стоять под капотом у вашего тьютора?

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

• Claude (Anthropic) — отличная сократическая настройка, сильно справляется с длинным контекстом по курсовым материалам, хороший профиль безопасности. Наш выбор по умолчанию для тьюторов, обращённых к студентам.
• GPT-4 / GPT-4o (OpenAI) — широкие возможности, лучший в классе мультимодал. Подходит для генерации контента и тьюторов с упором на голосовой ввод.
• Gemini (Google) — сильна по фактологии и в интеграции с Google Workspace, если учреждение его использует.
• Llama 3 / Mistral (self-hosted) — когда данные должны оставаться в вашем VPC и у вас есть бюджет на GPU. Подходит для RAG-ориентированных тьюторов, где требования к рассуждениям умеренные.
• Специализированные образовательные модели (LearnLM и др.) — стоит присматриваться по мере их зрелости; пока они уже, чем фронтирные модели общего назначения.

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

Когда не стоит разрабатывать AI-платформу для обучения

Иногда правильный ответ проще. Мы отговариваем команды от собственной разработки, когда:

• В каталоге меньше 20 курсов и меньше 1 000 слушателей. Teachable, Thinkific или Kajabi запустятся за неделю.
• У вас нет методической команды. Без методистов AI-функции усилят слабый контент, а не починят его.
• Нужен запуск меньше чем за 90 дней. Возьмите SaaS-LMS и инвестируйте инженерные ресурсы в AI-модули, а не в переразработку LMS.
• Ваш дифференциатор — контент, а не софт. Отличный курс на простой LMS бьёт простой курс на идеальной LMS всегда.

Часто задаваемые вопросы

Что почитать дальше

Готовы выпустить собственную платформу уровня Scholarly

Scholarly показывает, как современная AI-платформа для обучения выглядит в продакшне: чёткое ядро LMS, живое видео, масштабируемое до 2 000 студентов, AI там, где он доказуемо улучшает результат, и комплаенс, заложенный в фундамент. Наш плейбук прост: покупайте то, что стало товаром, разрабатывайте то, что уникально, ставьте AI только там, где он отрабатывает свою стоимость.

Если вы оцениваете похожую разработку или прикидываете AI-надстройку над существующей LMS, следующий шаг — короткий созвон. Мы свяжем вашу методику, масштаб и комплаенс с подходящим стеком, оценим сроки и бюджет и оставим вам картину куда более ясную, чем неделя внутренних обсуждений.