RAG для EdTech: как мы сократили время поиска по учебным материалам с 8 минут до 25 секунд

Студент задаёт вопрос — и ждёт 8 минут, пока поддержка ищет ответ в хаосе из PDF, видео-транскриптов и Notion-страниц. За это время он теряет контекст, мотивацию, а платформа — деньги. Мы построили RAG-систему, которая решает эту задачу за 25 секунд. Разбираем архитектуру, подводные камни и конкретные метрики внедрения.

Проблема: 8 минут на поиск ответа — почему это критично для EdTech

Образовательная платформа с 15 000+ активных студентов накопила несколько тысяч единиц контента: лекции в PDF, видео-транскрипты, конспекты в Notion, методические пособия с формулами LaTeX. Всё это — база знаний, к которой студенты обращаются ежедневно.

Типичный сценарий: студент пишет в поддержку вопрос по теме курса. Оператор открывает внутренний поиск, не находит точного совпадения, переключается между Notion, Google Drive и папками с PDF. Среднее время ответа — 8 минут 12 секунд. При 400+ обращениях в день это 55 часов операторского времени в сутки.

Цифры до внедрения:

• Среднее время ответа: 8 мин 12 сек
• Нагрузка на поддержку: 420 обращений/день по контенту курсов
• Стоимость: 6 операторов на полную ставку только для ответов на вопросы по материалам
• Доля студентов, не дождавшихся ответа: 23%

Те 23% — прямые потери конверсии. Студент, не получивший ответ вовремя, реже завершает курс и реже покупает следующий.

Что такое RAG и почему именно этот подход

RAG (Retrieval-Augmented Generation) — архитектурный паттерн, при котором LLM не генерирует ответ «из головы», а сначала находит релевантные фрагменты из базы знаний, а затем формулирует ответ на их основе. Это принципиально снижает галлюцинации и позволяет работать с актуальными данными без переобучения модели.

Почему не fine-tuning?

Три причины:

1. Контент обновляется еженедельно. Новые лекции, правки в методичках, свежие видео. Fine-tuning потребовал бы регулярного переобучения — дорого и медленно.
2. Нужен контроль над источниками. Когда студент получает ответ, он должен видеть ссылку на конкретную лекцию и тему. Fine-tuned модель не умеет цитировать.
3. Стоимость. Fine-tuning GPT-4 на нескольких тысячах документов — десятки тысяч долларов без гарантии качества на специфическом контенте.

Почему не полнотекстовый поиск?

Elasticsearch уже стоял на платформе. Он справлялся с простыми запросами вроде «что такое производная», но ломался на многоуровневых: «объясни разницу между градиентным спуском и методом Ньютона для оптимизации на примере из третьей лекции». Полнотекстовый поиск ищет слова, а студенту нужен смысл.

Специфика образовательного контента: почему стандартные RAG-решения не работают

Большинство туториалов по RAG демонстрируют работу с однородными текстовыми документами на английском языке. Образовательный контент — другая реальность.

Проблема разнородных форматов

Учебные материалы — это PDF с формулами LaTeX, слайды презентаций, видео-транскрипты с таймкодами, Jupyter Notebook. Каждый формат требует своего пайплайна обработки.

PDF с формулами — отдельная головная боль. Стандартные парсеры (PyPDF2, pdfplumber) извлекают формулы как мусорный набор символов. Мы использовали Nougat (Meta) для OCR математических документов и marker для конвертации PDF в Markdown с сохранением структуры. Формулы LaTeX сохраняются как $...$-блоки, что позволяет embedding-модели хотя бы частично учитывать их семантику.

Видео-транскрипты обрабатывали через Whisper large-v3 с последующей пунктуацией и разбиением на смысловые сегменты. Каждый сегмент привязан к таймкоду — студент получает не просто ответ, а ссылку на конкретный момент в видео.

Notion-страницы экспортировали через API в Markdown, сохраняя иерархию заголовков — это критично для chunking.

Стратегия chunking для учебных материалов

Стандартный подход — нарезать текст на чанки по 500–1000 токенов с перекрытием. Для учебных материалов это работает плохо: учебный текст строится вокруг тем, и разрезать тему пополам — значит потерять смысл.

Мы реализовали иерархический семантический chunking:

1. Первый уровень — разбиение по структуре документа (H1, H2, H3). Каждый раздел — потенциальный чанк.
2. Второй уровень — если раздел превышает 800 токенов, он дробится по абзацам с сохранением контекста заголовков. Каждый дочерний чанк наследует заголовки родительских уровней.
3. Третий уровень — метаданные: курс, модуль, тема, тип контента (теория/практика/пример), уровень сложности.

Параметры, которые сработали:

• Размер чанка: 400–800 токенов (гибкий, зависит от структуры)
• Перекрытие: 50 токенов (только для параграфного уровня)
• Обязательный контекст: заголовок документа + заголовки разделов в начале каждого чанка

Этот подход дал прирост +18% к точности ответов по сравнению с фиксированным chunking по 512 токенов (измеряли на размеченном тестовом наборе из 500 вопросов).

Архитектура RAG-системы: от схемы к production

Pipeline:

Ingestion → Preprocessing → Embedding → Vector Store → Retrieval → Re-ranking → Generation → Response + Sources

Стек:

• Orchestration: LangChain + собственные обёртки
• Embedding: Cohere embed-multilingual-v3.0
• Vector DB: Qdrant (self-hosted)
• LLM: GPT-4o для генерации ответов
• Re-ranking: cross-encoder
• Инфраструктура: Kubernetes, мониторинг через Grafana + Prometheus

Выбор embedding-модели

Для русскоязычного образовательного контента выбор embedding-модели — критичное решение. Мы протестировали три варианта:

Модель	Размерность	NDCG@10 (русский)	Скорость
paraphrase-multilingual-mpnet-base-v2	768	0.72	Средняя
paraphrase-multilingual-MiniLM-L12-v2	384	0.68	Высокая
Cohere embed-multilingual-v3.0	1024	0.79	Высокая (API)

Выбрали Cohere embed-multilingual-v3.0 — лучшее качество на русскоязычных запросах, поддержка 100+ языков и 1024-мерные векторы обеспечивают хорошее разделение семантически близких, но различных концепций.

Trade-off: зависимость от внешнего API. Для mitigation держим кэш embedding-ов и fallback на локальную paraphrase-multilingual-mpnet-base-v2.

Выбор векторной базы данных

База	Деплой	Фильтрация по метаданным	Зрелость
Qdrant	Self-hosted / Cloud	Полноценная, с payload-индексами	Стабильная
Pinecone	Managed / BYOC	Базовая	Высокая
Weaviate	Self-hosted / Cloud	Встроенная, с GraphQL	Стабильная

Выбрали Qdrant self-hosted: полный контроль над данными (требование заказчика), мощная фильтрация по метаданным (курс, модуль, тип контента), поддержка payload-индексов для ускорения фильтрованного поиска. Развернули в Kubernetes-кластере клиента.

Retrieval pipeline: hybrid search + re-ranking

Простой cosine similarity даёт приемлемые результаты на однозначных вопросах, но студенческие запросы редко бывают однозначными. «Как решить задачу из домашки по второму модулю про деревья» — здесь и тематический фильтр, и тип контента, и конкретная тема.

Мы реализовали hybrid search:

1. Dense retrieval — семантический поиск по Cohere embeddings через Qdrant. Top-20 кандидатов.
2. Sparse retrieval — BM25 по тому же корпусу. Ловит точные термины, которые dense search может пропустить.
3. Reciprocal Rank Fusion — объединение результатов с весами 0.7 (dense) / 0.3 (sparse).
4. Metadata filtering — если из запроса извлекается курс, модуль или тема, результаты фильтруются до re-ranking.
5. Re-ranking — cross-encoder/ms-marco-MiniLM-L12-v2 пересортировывает top-10 кандидатов.

Результат: top-5 чанков после re-ranking содержат релевантный ответ в 94% случаев на тестовом наборе из 500 размеченных вопросов.

Подводные камни production RAG-системы

Галлюцинации на специфической терминологии

LLM уверенно «дополняет» ответ информацией, которой нет в retrieved-чанках. Особенно на стыке смежных тем — модель «знает» общую теорию и подмешивает её к контенту курса.

Решение: строгий system prompt с инструкцией отвечать только на основе предоставленных фрагментов + постобработка, сравнивающая ключевые утверждения ответа с source-чанками. Если утверждение не подтверждается источником — пометка «требует проверки преподавателя».

Деградация на длинных документах

Лекция на 30 страниц после chunking превращается в 40–60 чанков. Retrieval может вернуть чанки из разных частей, и LLM собирает бессвязный ответ.

Решение: parent-child chunking. Мелкие чанки используются для поиска, но в контекст LLM передаётся более крупный «родительский» чанк с окружающим контекстом.

Формулы в ответах

Модель получает LaTeX-формулы из source-чанков, но иногда «ломает» их при генерации — меняет скобки, теряет индексы.

Решение: формулы оборачиваются специальными тегами при ingestion. В post-processing формулы извлекаются из оригинальных чанков и вставляются «как есть», без перегенерации.

Latency при пиковой нагрузке

В 20:00–22:00 (пик учебной активности) нагрузка вырастает в 4–5 раз. Embedding через Cohere API — 200–400 мс, re-ranking — 150–300 мс, генерация GPT-4o — 2–4 секунды.

Решение: кэширование embedding-ов частых запросов, предварительная генерация ответов на top-100 популярных вопросов, автоскейлинг Qdrant-реплик.

Мультиуровневые запросы

Новичок и продвинутый студент задают один вопрос, но ожидают ответы разной глубины.

Решение: извлечение профиля студента (курс, прогресс, уровень) и передача в system prompt. Модель адаптирует сложность: для новичков — больше контекста и аналогий, для продвинутых — сразу к сути.

Результаты: метрики до и после

Метрика	До RAG	После RAG	Изменение
Среднее время ответа	8 мин 12 сек	25 сек	−97%
Точность ответов (экспертная оценка)	—	94% (top-5 relevance)	—
Обращений в поддержку/день	420	85	−80%
Операторов на линии	6	2	−67%
Доля не дождавшихся ответа	23%	3%	−87%
NPS (модуль поддержки)	34	67	+33 пункта

Точность измеряли двумя способами:

• Автоматический: на размеченном наборе из 500 вопросов с эталонными ответами — NDCG@5 для retrieval и human-like score для генерации.
• Экспертный: преподаватели оценивали 200 ответов — 89% верных, 8% частично верных, 3% неверных.

Стоимость и ROI

Статья	Сумма
Инфраструктура (Kubernetes, Qdrant, мониторинг)	~80 000 ₽/мес
API-токены (Cohere embeddings + GPT-4o)	~120 000 ₽/мес
Поддержка и доработки	~40 000 ₽/мес

Стоимость одного ответа: ~4.5 ₽ (embedding запроса + retrieval + генерация GPT-4o ~800 output tokens). При 350 автоматических ответах в день — около 47 000 ₽/мес.

Экономия на операторах: 4 ставки × средняя зарплата оператора поддержки = значительная ежемесячная экономия. Система окупила разработку за 4 месяца после запуска.

Что влияет на стоимость долгосрочно:

• Объём базы знаний — больше документов = больше storage и embedding-ов, но рост линейный.
• Модель генерации — GPT-4o стоит $2.50/1M input + $10/1M output tokens. Переход на GPT-4o-mini снижает стоимость генерации в 10 раз при умеренной потере качества.
• Частота обновления контента — каждое обновление = re-embedding изменённых документов. При еженедельных обновлениях это некритично.

Когда RAG имеет смысл: чеклист для EdTech-платформы

RAG подойдёт, если:

• База знаний от 500 документов
• Контент обновляется чаще раза в месяц
• Запросы пользователей семантически сложные («объясни связь между X и Y»)
• Нужна трассируемость — ответ должен ссылаться на источник
• Есть бюджет на API-токены: минимум 50 000–100 000 ₽/мес

RAG не нужен, если:

• Контент — менее 100 документов. Проще сделать FAQ-бот с ручной разметкой.
• Все запросы фактологические (дата, цена, расписание). Обычная БД + API справятся лучше.
• Нет ресурсов на поддержку. RAG требует мониторинга качества ответов и регулярной калибровки.

Что дальше: направления развития

Персонализация по уровню студента. Сейчас адаптация работает на уровне system prompt. Следующий шаг — персональные embedding-пространства, где retrieval учитывает историю обучения и возвращает материалы, оптимальные для текущего уровня.

Мультимодальный RAG. Пока мы работаем с текстовыми представлениями всех форматов. Мультимодальные модели (GPT-4o, Gemini) позволяют включить в retrieval изображения, графики и диаграммы напрямую.

Интеграция с LMS. RAG-система как встроенный ассистент в Moodle, Canvas или собственной LMS. Студент задаёт вопрос прямо в интерфейсе курса и получает ответ с навигацией к нужному месту в лекции.

---

RAG для образовательного контента — технически более сложная задача, чем RAG для типовой документации. Разнородные форматы, специфическая терминология, разные уровни аудитории — всё это требует нестандартных решений на каждом этапе pipeline. Но результат того стоит: 25 секунд вместо 8 минут — разница, которую чувствует каждый студент.

---

Подписывайтесь на наш канал: @vibelogia

Поделимся опытом

hello@vibelab.ru

8 800 201 85 68

Написать в Telegram