Как маршрутизировать LLM-запросы в образовательных сервисах

OdiRouter Team

Проверить двадцать коротких ответов, объяснить дроби пятикласснику и составить индивидуальный план подготовки к ЕГЭ — всё это называется «работой с текстом». Но отправлять эти задачи одной модели с одинаковыми настройками так же странно, как нанимать профессора для проверки орфографии и калькулятор — для объяснения доказательства.

5 августа Яндекс сообщил, что с 2025 года помог освоить AI-инструменты более чем 20 тысячам российских педагогов. После программы повышения квалификации доля учителей, использующих ИИ при подготовке к занятиям, выросла с 46% до 74%, а умеющих работать с четырьмя и более нейросетями — с 11% до 37%.

Схема маршрутизации LLM-запросов между моделями в образовательном сервисе

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

В образовании «лучшая модель» — неправильный вопрос

Обычный рейтинг LLM смешивает задачи с разной ценой ошибки. Неудачная формулировка упражнения исправляется за минуту. Выдуманный исторический факт попадает в урок. Ошибочное объяснение темы закрепляет неверную модель в голове ученика. А автоматическая оценка может повлиять на реального человека.

Маршрутизатор в EdTech должен выбирать не самую умную модель, а минимально достаточную модель при допустимом уровне риска.

Поэтому полезно начинать не со списка провайдеров, а с карты образовательных действий.

Класс задачи

Примеры

Что важнее всего

Подход

Массовая механика

Теги, форматирование, короткие ответы, варианты упражнений

Цена и задержка

Быстрая недорогая модель, строгий JSON

Объяснение

Подсказка, разбор ошибки, адаптация текста по возрасту

Понятность и педагогический тон

Средняя модель с контекстом урока

Проектирование

Сценарий урока, диагностическая работа, индивидуальная траектория

Связность и полнота

Сильная модель плюс проверка учителем

Высокий риск

Итоговая оценка, рекомендации по особым потребностям, чувствительные данные

Справедливость и ответственность

Human-in-the-loop; автоматизация только вспомогательная

Первый слой маршрутизации: не сложность, а последствие ошибки

Длина промпта плохо предсказывает риск. Запрос «поставь оценку этому ответу» короткий, но решение затрагивает ученика. Генерация десяти вариантов задачи может быть длинной, но преподаватель легко отбракует неудачные.

Перед вызовом модели Router может определить четыре признака:

· impact: влияет ли ответ на оценку или образовательную траекторию;

· grounding: есть ли утверждения, которые должны опираться на учебник или базу знаний;

· personal_data: содержит ли запрос данные ребёнка;

· reviewability: насколько быстро учитель заметит ошибку.

Если влияние высокое, а проверяемость низкая, сильная модель сама по себе проблему не решает. Нужны источник, журнал решения и обязательное подтверждение педагога.

Второй слой: педагогическая функция

Один и тот же вопрос требует разных ответов в зависимости от режима. «Реши уравнение» для учителя означает эталон и критерии оценки; для ученика — подсказку, которая не забирает у него саму работу.

Полезно сделать режим частью API-контракта:

{
  "task": "explain_mistake",
  "audience": {"grade": 6, "level": "needs_support"},
  "policy": {"give_final_answer": false, "cite_sources": true},
  "content": "..."
}

Так правила живут не в случайной фразе системного промпта, а в продуктовой логике. Router выбирает профиль модели, температуру, лимит ответа и необходимость Retrieval.

Три маршрута вместо одного

Fast lane: много, быстро, дёшево

Короткие классификации, генерация distractors, нормализация формата и черновые упражнения стоит отправлять быстрой модели. Здесь особенно важны Schema Validation и автоматические проверки: правильное число вариантов, один корректный ответ, отсутствие дублей, соответствие возрасту.

Teaching lane: объяснять, а не демонстрировать интеллект

Для обратной связи нужна модель, которая удерживает контекст урока и умеет менять глубину объяснения. Качество измеряется не красотой текста, а тем, смог ли ученик сделать следующий шаг. Хороший ответ часто короче и заканчивается вопросом, а не готовым решением.

Expert lane: планировать под ограничениями

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

Fallback не должен незаметно менять педагогику

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

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

Как проверить образовательный Router

Нужен собственный набор примеров, составленный методистами и учителями:

1. короткие ответы с типичными ученическими ошибками;

2. вопросы, где нельзя раскрывать финальное решение;

3. фактические задания с эталонным источником;

4. неоднозначные формулировки и конфликтующие критерии;

5. запросы с персональными данными;

6. русский язык разных возрастных уровней;

7. попытки ученика обойти правила через Prompt Injection.

Измерять нужно factuality, соответствие возрасту, сохранение педагогической цели, долю успешного JSON, стоимость, задержку и процент ответов, которые учитель существенно переписал.

Единый API без единой модели

OdiRouter.ai и другие OpenAI-compatible gateways позволяют держать несколько моделей за одним интерфейсом. Приложение отправляет стандартный запрос, а слой маршрутизации выбирает профиль по задаче, бюджету и риску.

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

Что показали 20 тысяч педагогов

По данным Яндекса, после обучения 72% участников не запрещают ученикам пользоваться нейросетями и объясняют, как проверять сгенерированную информацию; до программы так поступали 55%. Это более зрелая стратегия, чем запрет или безусловное доверие.

Хороший LLM Router следует той же логике. Он не прячет ИИ и не обещает безошибочность. Он делает выбор модели осознанным, добавляет проверку там, где ошибка дорога, и оставляет педагогу решения, которые нельзя свести к Token и Latency.

Вывод

Образовательному сервису не нужна одна модель на все случаи. Ему нужна дисциплина: дешёвая модель для массовой механики, более сильная — для объяснений и планирования, Retrieval — для фактов, Human-in-the-loop — для решений о человеке.

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

#AI gateway#AI для учителей#EdTech#Human-in-the-loop#LLM Router#OdiRouter.ai#ИИ в образовании#маршрутизация моделей#образовательные сервисы#проверка ответов