Образовательный проект: ИИ-тьютор на своём сервере

MAATRIX

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

Зачем образовательному проекту свой ИИ-тьютор

У образовательного контента есть особенность: он ценный и постоянно обновляется. Методички, конспекты лекций, ответы на частые вопросы, черновики следующих модулей — это интеллектуальная собственность школы, а не просто справочный текст. Когда вы загружаете всё это в облачный SaaS-сервис вроде готового чат-бота на базе ChatGPT-плагина, вы отдаёте эти материалы на сторону: они лежат на чужих серверах, синхронизируются с чужими логами, а иногда используются вендором для дообучения его собственных моделей (это стоит явно проверять в пользовательском соглашении конкретного сервиса — условия у всех разные и меняются).

Свой сервер решает три задачи разом:

• Контроль над данными. Материалы курса, переписка учеников с тьютором, черновики — всё остаётся у вас. Это особенно важно, если в курсе есть закрытый контент, который вы не хотите видеть у конкурентов.
• Предсказуемая стоимость при росте. SaaS-решения с ИИ-чатом обычно берут оплату за количество активных пользователей или сообщений. Когда в школе 50 учеников — это копейки. Когда 2000 — счёт может вырасти в разы быстрее, чем растёт выручка школы. Сервер с фиксированной арендной платой не зависит от числа вопросов.
• Гибкость под учебный процесс. Свой инстанс можно донастраивать под конкретный курс: другой промпт для системы, другая модель эмбеддингов, отдельная база под каждый поток учеников — SaaS такого обычно не даёт.

Из минусов — ответственность за апдейты, бэкапы и мониторинг ложится на вас или на того, кто администрирует сервер. Это не бесплатно с точки зрения времени, просто плата не растёт с числом учеников.

Как работает RAG-тьютор поверх материалов курса

Идея простая: вместо того чтобы модель "помнила" содержание курса (и путала детали или выдумывала то, чего не было), она каждый раз ищет релевантный фрагмент в реальных материалах и формирует ответ на его основе. Это называется RAG — retrieval-augmented generation, поиск с дополнением генерации.

Пайплайн выглядит так:

1. Материалы курса (текстовые конспекты, PDF-методички, транскрипты видео, FAQ) загружаются в векторную базу — они разбиваются на фрагменты (chunks) и превращаются в числовые векторы через модель эмбеддингов.
2. Ученик задаёт вопрос в чате.
3. Система находит несколько наиболее похожих по смыслу фрагментов из базы.
4. LLM получает вопрос ученика вместе с найденными фрагментами и формирует ответ, ссылаясь на конкретный источник — раздел методички или номер урока.

Для образовательного проекта это удобнее, чем просто дать ученикам доступ к ChatGPT: ответ строится не "из общих знаний интернета", а именно из вашей программы, вашей терминологии и вашей последовательности подачи материала. Если в курсе используется нестандартный термин или своя методика, тьютор будет отвечать в этой же логике, а не подсовывать общий ответ из открытого интернета.

Подробнее про сам механизм поиска с дополнением можно почитать в статье про RAG по своим документам на сервере — там разобрана техническая сторона вопроса подробнее, чем нужно для этого сценария.

Разворачиваем AnythingLLM под учебные материалы

AnythingLLM — готовый инструмент с веб-интерфейсом, который закрывает всю RAG-цепочку: загрузку документов, разбиение на фрагменты, векторную базу, чат и настройку системного промпта — без написания собственного пайплайна с нуля. Для образовательного проекта это разумный выбор: не нужно нанимать ML-инженера, чтобы поднять первую рабочую версию тьютора.

Минимальные требования для сервера под курс среднего размера (несколько сотен учеников, документы в основном текстовые):

Если вы не планируете гонять локальную LLM на своём железе, а хотите использовать модель через API (например, через прокси к OpenAI или через открытую модель на арендованном GPU-сервере), GPU не нужен вообще — сервер только хранит документы, считает эмбеддинги и обращается к LLM снаружи. Про то, сколько ресурсов реально нужно под разные сценарии, подробно разобрано в статье сколько RAM нужно для AnythingLLM.

Сама установка на Ubuntu 24.04 через Docker занимает буквально несколько команд:

docker run -d -p 3001:3001 \
  --name anythingllm \
  -v /opt/anythingllm/storage:/app/server/storage \
  -e STORAGE_DIR=/app/server/storage \
  mintplexlabs/anythingllm

После первого запуска интерфейс доступен на порту 3001, где нужно указать LLM-провайдера (внешний API или локальную модель через Ollama), модель эмбеддингов и создать рабочее пространство (workspace) под конкретный курс. Пошаговый разбор установки со всеми нюансами — в статье про установку AnythingLLM на Ubuntu 24.04.

Структура workspace: один курс — одно пространство

Частая ошибка — свалить все материалы школы в одну общую базу. Тогда тьютор для курса по маркетингу может начать цитировать методичку по программированию, если формулировки вопроса случайно похожи. AnythingLLM поддерживает несколько изолированных workspace в одном инстансе — используйте это:

• Один workspace на курс (или на поток, если содержание сильно меняется между потоками).
• В каждый workspace загружайте только релевантные документы: конспекты, официальные FAQ, регламенты, но не переписку в общем чате поддержки — там слишком много шума и неструктурированного текста, который ухудшает качество поиска.
• В системном промпте workspace явно пропишите ограничения — это критично, разберём в следующем разделе.

Для больших курсов с сотнями PDF и видео-транскриптов имеет смысл заранее продумать, какая модель эмбеддингов лучше справится с вашим языком и терминологией — на русскоязычных технических текстах разные модели ведут себя не одинаково. Сравнение вариантов — в статье про выбор модели эмбеддингов для RAG.

Честные ограничения: чего тьютор делать не должен

Это самая важная часть сценария, и её нельзя пропускать ни в реализации, ни в общении с учениками.

ИИ-тьютор на базе RAG хорошо справляется с:

• Быстрыми справочными вопросами ("на каком уроке разбирается тема X", "какая формула использовалась в модуле 3").
• Повторением уже пройденного материала — переформулировать своими словами то, что уже объяснялось в курсе.
• Навигацией по курсу — куда посмотреть, что перечитать перед экзаменом.
• Ответами на организационные вопросы, если регламенты школы тоже загружены в базу.

Тьютор плохо справляется или не должен использоваться для:

• Сложных концептуальных вопросов, где нужно понять пробел в рассуждении конкретного ученика, а не выдать готовый фрагмент текста. Модель может собрать связный ответ из фрагментов, но не заметит, что ученик путает два смежных понятия — это видит только человек, который ведёт диалог и задаёт наводящие вопросы.
• Оценки работ и развёрнутой обратной связи по заданиям, где нужна экспертная оценка, а не сверка с эталонным текстом.
• Ситуаций, где в базе нет ответа. Модель может либо честно сказать "не нашла в материалах", либо — если промпт настроен небрежно — начать домысливать из общих знаний. Это нужно явно пресекать в системном промпте: попросите модель прямо отвечать "этого нет в материалах курса, уточните у преподавателя", а не сочинять правдоподобный, но не проверенный ответ.

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

Экономика: свой сервер против встраивания в SaaS

Ключевой вопрос для школы, которая планирует расти: что произойдёт со стоимостью решения, когда учеников станет в 5-10 раз больше.

Готовые SaaS-платформы с ИИ-ассистентом обычно тарифицируют по числу активных пользователей, количеству сообщений в месяц или по объёму хранимых документов. Формула может выглядеть щедрой на старте (бесплатный тариф до N пользователей), но при росте счёт растёт линейно или ступенчато вместе с числом учеников — и это происходит ровно тогда, когда школа наименее готова к неожиданным расходам, потому что деньги от нового потока учеников ещё не поступили, а счёт от SaaS уже пришёл.

Свой сервер с AnythingLLM работает иначе: аренда сервера — фиксированная сумма в месяц независимо от того, 50 учеников задают вопросы или 2000. Переменные расходы остаются только на стороне LLM-провайдера, если вы используете внешний API (оплата за токены), и она масштабируется с реальным использованием, а не с числом зарегистрированных аккаунтов. Это можно прикинуть заранее — см. статью как считать стоимость LLM-запросов на своём сервере.

Ориентировочно (это именно ориентир, а не измеренная цифра — у вас будет по-другому в зависимости от объёма материалов, модели и провайдера LLM): для потока в несколько сотен активных учеников с умеренной интенсивностью вопросов сервера уровня 8 ГБ RAM / 4 ядра обычно достаточно для самого AnythingLLM, а основные переменные расходы уходят на вызовы LLM через API, если вы не держите модель локально.

Когда рост числа учеников делает свой сервер выгоднее SaaS с оплатой за пользователя — вопрос индивидуальный, но переломный момент обычно наступает быстрее, чем кажется на старте: SaaS-тарифы редко линейны в сторону пользователя, а аренда сервера — да.

Настройка под курс: промпт, доступ и разграничение

После загрузки материалов в workspace остаётся настроить поведение тьютора под конкретный курс:

• Системный промпт. Явно укажите роль ("ты — помощник по курсу X, отвечай только на основе загруженных материалов"), тон общения (дружелюбный, но не панибратский — зависит от аудитории курса), и обязательное ограничение — не выдумывать ответ, если его нет в источниках.
• Число возвращаемых фрагментов (chunks). Для образовательных материалов с чёткой структурой обычно достаточно 3-5 фрагментов на запрос — больше не всегда лучше, потому что модель может "потеряться" среди избыточного контекста.
• Доступ учеников. AnythingLLM поддерживает многопользовательский режим с ролями — можно дать ученикам доступ только к чату конкретного workspace, без возможности редактировать документы или видеть настройки системы.
• Логи и модерация. Стоит вести журнал вопросов учеников — не для слежки, а чтобы видеть, какие темы вызывают больше всего затруднений и где стоит доработать сам курс или явно упомянуть тему в промпте тьютора.

Если школа уже использует другой инструмент для сбора базы знаний или сравнивает варианты, есть смысл посмотреть на альтернативы — сравнение AnythingLLM с Open WebUI по функциональности и удобству разобрано в статье AnythingLLM против Open WebUI: что выгоднее и когда.

Частые вопросы