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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На семь возможностей приходится почти весь ROI, который мы видим в проектах AI-ЛMS в 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) + ограждения + якоря цитирования.

Автоматическая проверка на плагиат и текст, написанный ИИ

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

Генерация контента и квизов с помощью 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, если команде так удобнее. Главное — базовая декомпозиция: отделение плоскости живого видео от плоскости контента.

Живые лекции для 2000 студентов в сессии

Запустить живую лекцию на 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.

Мини-кейс: разработка Scholarly длилась 12 месяцев

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

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

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

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

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

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

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

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

4. Где 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%. Ниже этих показателей вы добавляете шум, а не ценность.

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

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

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

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

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

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

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

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

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

Для рисков, специфичных для LLM, держите в CI набор тестов на prompt injection, ведите allow-лист системных промптов, очищайте персональные данные перед отправкой провайдеру LLM и логируйте каждое взаимодействие с ИИ со сроком хранения, соответствующим требованиям 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 курсов и менее 1000 слушателей. Teachable, Thinkific или Kajabi запустятся за неделю.
• У вас нет методической команды. Без методистов AI-функции усилят слабый контент, а не исправят его.
• Нужен запуск за 90 дней или меньше. Используйте SaaS-обучающий платформу и направьте инженерные ресурсы на разработку AI-модулей, а не на переписывание LMS.
• Ваше преимущество — контент, а не платформа. Отличный курс на простой LMS всегда лучше простого курса на идеальной LMS.

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

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

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

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

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