Представьте: студент заканчивает урок по финансовой грамотности и видит три карточки — «следующие шаги». Не случайные, а именно те курсы, которые дополняют пройденное. Он кликает. Проводит ещё 40 минут на платформе. Платит за подписку во второй месяц. Это и есть рекомендательная система для EdTech — и она не требует команды ML-инженеров, чтобы начать работать.
Что такое рекомендательная система в EdTech и зачем она нужна
Рекомендательная система для EdTech — это механизм, который предлагает пользователю следующий контент на основе того, что он уже изучил, что изучают похожие на него студенты, или просто на основе тематической близости материалов. Ничего магического: в основе лежит логика «если ты изучил A, то тебе подойдёт B».
В контексте обучающих платформ рекомендации решают три конкретных проблемы. Первая — retention: студент не знает, что смотреть дальше, и уходит. Вторая — discovery: на платформе 500 курсов, человек находит только 5 из них. Третья — прогресс: без структурированного пути обучения люди бросают на полпути.
По данным исследований в сфере EdTech, платформы с персонализированными рекомендациями удерживают студентов на 30–40% дольше по сравнению с платформами без них. Для стартапа с подписочной моделью это прямой удар по churn rate.
Три типа рекомендаций: от простого к сложному
Рассмотрим, как рекомендательная система для edtech работает на практике.
Прежде чем думать о машинном обучении, важно понять: существует три принципиально разных подхода к рекомендациям. И начинать стоит с самого простого.
Контентная фильтрация (Content-Based Filtering)
Система анализирует сам контент — теги, категории, ключевые слова, описания курсов — и подбирает похожие материалы. Студент прошёл курс «Основы Python» с тегами программирование, Python, начинающие — система рекомендует другие курсы с теми же тегами.
Плюсы: не нужна история поведения пользователей, работает с первого дня. Минусы: рекомендации могут быть однообразными — система не «знает», что студент уже опытный и ему скучны курсы для начинающих.
Коллаборативная фильтрация (Collaborative Filtering)
Здесь логика другая: «студенты, похожие на тебя, также изучали вот это». Система ищет паттерны в поведении похожих пользователей и предлагает то, что они находили полезным.
Это мощный подход — но он требует данных. Минимальный порог для адекватных рекомендаций: несколько тысяч активных пользователей с историей прохождения курсов. Для MVP с нуля — преждевременно.
Гибридный подход
Комбинация контентной и коллаборативной фильтрации. Именно так работают Netflix и Spotify: сначала контентная логика, потом, по мере накопления данных, подключается коллаборативная составляющая. Большинство зрелых EdTech-платформ в итоге приходят к гибриду.
Как сделать рекомендации без ML: rule-based подход
Вопрос рекомендательная система для edtech заслуживает детального анализа.
Для MVP не нужно машинное обучение. Нужна чёткая логика правил — и она работает удивительно хорошо на старте.
Rule-based рекомендации строятся по схеме «условие → действие». Несколько конкретных примеров:
- Последовательность курсов: курс A помечен как «пресквизит» для B и C — после завершения A система автоматически показывает B и C.
- Тематическая близость: у курса есть теги «финансы» и «инвестиции» — система показывает другие курсы с теми же тегами, отсортированные по рейтингу.
- Уровень сложности: студент завершил три курса уровня «Beginner» — система начинает предлагать «Intermediate».
- Популярность в категории: «другие студенты в этой категории чаще всего изучали…» — даже без реального коллаборативного алгоритма это работает как социальное доказательство.
Реализация такого подхода — это по сути набор запросов к базе данных и несложная логика в бэкенде. Никаких библиотек машинного обучения, никакой GPU-инфраструктуры.
Когда нужен настоящий ML
Именно рекомендательная система для edtech определяет результат для бизнеса.
Rule-based логика хороша до определённого масштаба. Три сигнала, что пора переходить к ML:
1. Более 10 000 активных пользователей с историей действий. До этого порога данных недостаточно для адекватных коллаборативных рекомендаций — модель будет «угадывать» хуже простых правил.
2. Контент перестал быть однородным. Если на платформе появились видео, статьи, тесты, подкасты — теги уже не описывают всю семантику. Нужны векторные представления контента.
3. A/B-тесты показывают потолок rule-based подхода. Если click-through rate рекомендаций застрял на одном уровне и правила уже не улучшают его — это сигнал для перехода к ML-моделям.
Конкретные инструменты для EdTech MVP
Даже без полноценного ML можно использовать современные инструменты, которые значительно улучшают качество рекомендаций по сравнению с простыми тегами.
Векторный поиск: pgvector и Qdrant
Векторный поиск позволяет найти «семантически похожий» контент — не по точному совпадению тегов, а по смыслу. Описания курсов преобразуются в числовые векторы (embeddings) с помощью языковых моделей (например, OpenAI Embeddings), а затем ищутся ближайшие соседи.
pgvector — расширение для PostgreSQL. Если база данных уже на Postgres — это самый простой путь: никакой дополнительной инфраструктуры, запрос к похожим курсам выглядит как обычный SQL с оператором <-> (косинусное расстояние).
Qdrant — специализированная векторная БД. Подходит, когда объём контента большой (десятки тысяч единиц) и нужна высокая скорость поиска. Разворачивается в Docker, предоставляет REST API.
Готовые сервисы
AWS Personalize — полностью управляемый сервис от Amazon. Загружаете данные о пользователях и контенте, сервис обучает модель и предоставляет API для рекомендаций. Плюс — не нужна ML-экспертиза. Минус — стоимость при росте объёмов данных и запросов.
Для большинства EdTech MVP на старте оптимальный путь: rule-based логика + pgvector для семантической близости контента. Это даёт 80% пользы при 20% сложности полноценного ML-решения.
Что IT2BE встраивает в EdTech MVP за 22 дня
В рамках стандартного EdTech MVP мы реализуем рекомендательную систему на основе rule-based логики и векторного поиска. Конкретно это выглядит так:
- Теги и категории курсов — база для контентной фильтрации
- Граф последовательности курсов — «следующие шаги» после завершения модуля
- pgvector для семантической похожести по описаниям курсов
- Блок «Популярное в категории» — социальное доказательство без коллаборативного алгоритма
- API-эндпоинты для фронтенда: `GET /recommendations/{user_id}` → массив курсов с объяснением причины рекомендации
Архитектура намеренно строится так, чтобы потом — когда наберётся 10 000+ пользователей — можно было подключить настоящий ML-слой без переписывания основы.
Если вы строите EdTech-платформу и думаете о персонализации — запишитесь на 30-минутный Zoom-колл. Разберём вашу конкретную задачу: какой тип рекомендаций подойдёт на старте, что можно сделать за 22 дня, и как это масштабировать дальше.
Можно ли добавить рекомендации в уже готовый EdTech MVP?
Да, если архитектура бэкенда нормальная. Контентные рекомендации на основе тегов и pgvector встраиваются как дополнительный модуль без переписывания существующего кода. Главное — наличие структурированных метаданных у контента (теги, категории, описания). Если их нет — сначала нужно проставить.
Сколько данных нужно, чтобы рекомендации работали?
Для rule-based и контентной фильтрации — данные о пользователях не нужны вообще, достаточно метаданных контента. Для коллаборативной фильтрации минимальный порог — несколько тысяч пользователей с историей прохождения не менее 3–5 курсов каждый. До этого порога коллаборативный подход работает хуже простых правил.
Насколько сложно встроить pgvector в существующий Postgres?
Это расширение устанавливается одной командой в PostgreSQL 11+. Основная работа — генерация embeddings для описаний курсов через OpenAI Embeddings API (или аналоги) и их сохранение. После этого поиск похожего контента — обычный SQL-запрос. Для MVP с несколькими сотнями курсов производительность отличная без дополнительной оптимизации.
Что лучше: строить рекомендации самому или использовать AWS Personalize?
Для MVP — строить самому на rule-based + pgvector. AWS Personalize имеет смысл от нескольких десятков тысяч пользователей и событий в день, когда цена сервиса оправдывается экономией на разработке ML-пайплайна. На старте это избыточно и дороже, чем кастомное решение.