В образовательном ИИ привычная логика развития продукта перестаёт работать. Продукт растёт в среде, где внешние изменения происходят быстрее, чем он успевает стабилизироваться, поэтому собрать монолит и рассчитывать на долгую устойчивость становится невозможно.
Фичи, которые сегодня выглядят ключевыми, через несколько месяцев теряют значение. Архитектурные решения быстро устаревают: то, что вчера выглядело как завершённая продуктовая конструкция, сегодня снова требует пересборки.
В этой статье — о том, что происходит с образовательным ИИ‑продуктом в условиях постоянных изменений рынка и технологий. Все выводы основаны на практическом опыте разработки и эксплуатации Кэмпа: от проектирования генерации до продуктовых решений.
Почему образовательный ИИ не может развиваться стабильно
В классическом EdTech можно долго жить на одной архитектуре. Программа курса обновляется раз в год, интерфейс — раз в пару лет, методология — ещё реже.
В ИИ-продукте для образования так не работает.
Причина такая: продукт находится между несколькими быстро меняющимися системами сразу — языковыми моделями, ИИ‑детекторами, требованиями вузов и ожиданиями студентов. Любое изменение в одной из этих систем моментально ломает равновесие.
Например, генератор текста может стабильно выдавать связные, логичные работы на тестах и в проде. Но меняется внешняя среда: одна модель перестаёт выдерживать нагрузку у провайдера, другая становится слишком дорогой, третья внезапно деградирует по качеству.
В такой ситуации невозможно ограничиться точечной правкой или новым промптом. Приходится пересобирать часть архитектуры целиком: менять модели, порядок шагов, логику обработки, а иногда и сам сценарий работы продукта.
Поэтому образовательный ИИ живёт не в режиме улучшений, а в режиме непрерывной реконструкции.
Когда логика наращивания фич перестаёт работать
Классическая продуктовая логика выглядит так:
Есть базовый продукт.
К нему добавляют фичи.
Фичи накапливаются, продукт становится «богаче».
В ИИ‑продукте эта схема ломается.
Возьмём генерацию учебного текста. На первый взгляд это одна задача — написать работу. На практике она распадается на множество разных операций:
определить цели и задачи;
собрать структуру;
связать главы между собой;
подобрать источники;
внедрить цитаты;
сохранить академический стиль;
не развалиться на ИИ‑детекте.
Каждый из этих шагов предъявляет разные требования к модели и логике работы системы. Одна модель не справляется со всем этим одновременно.
Попытка допилить генератор — добавить ещё одну фичу, шаг или правило поверх существующей логики — увеличивает нагрузку на систему, но не гарантирует роста качества. Чаще происходит обратное: растёт сложность, появляются побочные эффекты, а управляемость снижается.
Именно поэтому генерация в Кэмпе построена как многоступенчатая архитектура, где разные этапы решаются разными моделями. Подробно об этом мы рассказывали в статье «Как работает многошаговый генератор текстов в продакшене».
В такой конфигурации продукт нельзя развивать простым наращиванием фич. Его приходится регулярно упрощать, дробить и пересобирать, чтобы сохранять управляемость и качество результата.
Когда генератор перестаёт быть центром продукта
Многоступенчатая генерация решила часть проблем, но показала другое ограничение: сам генератор перестал быть удобной точкой развития продукта. Чем сложнее становилась архитектура, тем рискованнее было менять её целиком.
Вместо того, чтобы допиливать очередную версию генератора, мы начали выделять самостоятельные направления, которые можно менять независимо друг от друга.
Так появились отдельные продуктовые контуры:
генерация таблиц и графиков как отдельная задача, потому что попытки делать их в процессе генерации текста давали нестабильный результат;
подсказки по визуализации, которые появляются на этапе редактуры, когда структура уже понятна;
генерация презентаций, где логика построения, требования к структуре и критерии качества изначально отличаются от текстовых работ и не зависят от генератора текста.
Такой подход сделал продукт более гибким: теперь мы можем менять модели, логику или экономику конкретного направления, не задевая остальные. Это снизило риск регрессий, упростило эксперименты и дало возможность быстрее реагировать на внешние изменения без пересборки всей системы.
Фокус на задачах студента как точка устойчивости ИИ-продукта
Архитектурная гибкость позволила продукту быстрее адаптироваться к изменениям, но вскрыла другой предел. Даже когда генератор перестаёт быть центром системы, сама архитектура не отвечает на главный вопрос — за счёт чего продукт остаётся понятным и устойчивым для пользователя.
Именно здесь фокус смещается с внутренних механизмов на пользовательскую задачу. Внутри ИИ‑продукта легко увлечься моделями, архитектурой и метриками. Но для пользователя это не имеет значения. Студент смотрит не на внутреннее устройство продукта, а на то, решает ли он конкретную учебную задачу.
На практике это означает простые и жёсткие требования:
результат соответствует формальным требованиям вуза;
текст можно читать, править и дорабатывать внутри продукта;
структура не конфликтует с ожиданиями преподавателя;
финальные выводы остаются за студентом.
Если продукт меняется вместе с технологиями, но пользователь не понимает, как с ним работать, устойчивости не возникает.
Поэтому фокус смещается с того, как работает ИИ на то, как пользователь проходит учебную задачу. Нейросеть берёт на себя рутинные и формальные этапы — оформление, поиск, первичную структуру, — но не подменяет собой процесс принятия решений.
Именно это позволяет продукту оставаться рабочим даже в условиях постоянных изменений: когда обновляются модели, отличаются требования вузов и меняются внешние правила, пользователь сохраняет контроль над результатом.
Ключевые выводы
Когда изменения на рынке происходят быстрее, чем продукт успевает стабилизироваться, образовательный ИИ‑сервис нельзя развивать как набор фич или цепочку улучшений.
Он становится системой постоянных выборов и компромиссов: между скоростью изменений и ка��еством результата, между глубиной проработки и экономикой продукта, между автоматизацией и сохранением человеческого контроля.
В такой среде выигрывают не те, кто нашёл идеальную модель или устойчивую архитектуру, а те, кто умеет быстро пересобирать продукт, не теряя понятного пользовательского пути.
