Как «Фабрика Решений» за 16 недель построила платформу независимого ассесмента ТОП-ИИ

В сентябре 2026 года в независимом ассесменте программ ТОП-ИИ участвовали 4 644 студента из 22 вузов. Их проверяла не родная кафедра, а общая платформа — с едиными правилами, единой шкалой и единой моделью компетенций. Платформу по заказу МФТИ построила команда «Фабрики Решений»: от первой строки кода до старта прошло шестнадцать недель.

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

Задача: одна шкала вместо двадцати двух

Программы ТОП-ИИ идут сразу в двух десятках вузов страны. Аналитический центр при Правительстве РФ заказал независимый ассесмент их студентов по итогам первого курса. Конкурс на его проведение выиграл МФТИ — и пришёл в «Фабрику Решений» за самой платформой.

Формулировка была жёсткой: не «каждый вуз оценивает своих», а одна платформа, одни правила и одна шкала для всех. На разработку отводилось одно лето. В сентябре система должна была принять почти пять тысяч студентов из 22 вузов и 78 образовательных программ.

За этой формулировкой стояли четыре проблемы.

• Несопоставимость. Одни и те же компетенции в разных вузах оценивают по-разному. Из таких оценок не понять, где программа работает, а где нет.
• Масштаб. Тысячи студентов, десятки программ и окно в несколько недель. Задания не должны утечь через тех, кто пройдёт ассесмент первым, а результаты — поддаваться подгонке.
• Доверие. Вуз не видит чужих студентов. В результатах нет ни фамилий, ни эталонных ответов, а раскрываются они только после того, как ассесмент завершат все.

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

Почему не взяли готовое

Рынок предлагает много частичных ответов: тестирование внутри LMS (Moodle, iSpring), проверку кода (Яндекс Контест, Codeforces, Stepik), прокторинг (Examus, ProctorEdu), HR-платформы оценки компетенций. Есть и федеральный интернет-экзамен ФИЭБ как пример массового независимого оценивания. Но каждое из этих решений закрывает одну грань задачи.

Прямого аналога, который соединял бы модель компетенций, индивидуальные варианты под неё, песочницу для кода и анонимную экспертную проверку, в команде не знают. Поэтому платформу собирали с нуля.

Решение: пять кабинетов в одном приложении

«Ассесмент ТОП-ИИ» — веб-платформа, в которой живут кабинеты пяти ролей. Роль определяется по учётной записи, и в чужой кабинет нельзя попасть даже по прямой ссылке.

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

Модель компетенций, которую вуз собирает сам

В основе платформы — компетентностно-ролевая модель (КРМ): глобальный справочник из 1244 единиц оценки. Он устроен как иерархия: домен, блок, компетенция, индикатор и уровень его сформированности.

Вуз раскрывает дерево, отмечает нужные единицы для каждой программы и указывает, какими инструментами и на каких задачах формируется компетенция. Затем подаёт набор на экспертизу — и набор фиксируется. Его можно выгрузить в PDF или загрузить готовой таблицей из Excel.

Здесь главное отличие платформы от «теста с баллами». Варианты заданий формируются на сервере заранее, под набор конкретной программы, и покрывают выбранные единицы оценки. Поэтому результат читается как картина по компетенциям, а не как сумма баллов.

Ассесмент без технических приключений

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

В кодовом задании — полноценный редактор с подсветкой под язык окружения и стартовым шаблоном. Кнопка «Проверить» прогоняет решение на сервере на открытом примере. Студент ещё до сдачи видит входные данные, свой вывод и ожидаемый результат.

Параллельно платформа ведёт наблюдение за сессией: фиксирует поведенческие события, по которым можно разобрать возможное списывание. Никакого видео и биометрии. Студента события не блокируют, а заказчик получает по ним отчёт в Excel и может разобрать спорные случаи.

Результаты, которым верят

Вуз и заказчик видят сводку «заявлено / завершили / прошли» по вузу и по программе. Ниже — матрица «студент × вопрос» с цветовыми исходами. У каждого студента есть своя страница: карта результатов и разбор только неверных и частично верных ответов.

Фамилий и эталонных ответов в результатах нет. Раскрываются они поэтапно — только когда ассесмент завершили все. Сам студент баллов в кабинете не видит: так решил заказчик.

Кабинет заказчика показывает живую динамику по вузам: сколько студентов не начали, сколько в процессе, сколько завершили. Пропустивших по уважительной причине заказчик назначает на резервное окно, а системный администратор открывает им доступ. А кабинет эксперта с анонимной очередью и оценкой «балл + комментарий» уже готов и ждёт заданий с открытым ответом в следующих циклах.

Как работали: шесть человек и одно лето

Со стороны «Фабрики Решений» над платформой работала команда из шести человек.

• Руководитель проекта вёл требования и коммуникацию с МФТИ и заказчиком.
• Фронтенд-разработчик собрал все пять кабинетов единого приложения на TypeScript и React.
• Три бэкенд-разработчика отвечали за сервисы авторизации, компетентной модели и ассесмента на Python, интеграцию с песочницей для кода и отчёты.
• Тестировщик проверял каждый кабинет перед релизом.

Небольшая команда здесь была плюсом: путь от замечания заказчика до правки на стенде оказался коротким. Платформу выпускали по частям — и вузы начали работать в системе уже на третьей неделе разработки.

Скорость без скидки на качество

Шестнадцать недель — срок, в который легко пожертвовать тестами. Команда пошла обратным путём. Больше тысячи автотестов и 80 сквозных сценариев выполняются при каждой сборке и не пускают поломку в прод.

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

Фронтенд — одностраничное приложение на React и TypeScript с единой дизайн-системой, встроенным редактором кода и поддержкой формул в заданиях. Бэкенд — несколько сервисов на Python, которые общаются через очередь событий и закрыты единым шлюзом. Код студентов исполняется в изолированной песочнице Judge0.

Решение сделать один фронтенд на все роли сэкономило месяцы на общих слоях: авторизации, дизайн-системе, обработке ошибок, тестах и деплое. При этом каждый кабинет загружается отдельно и изолирован от сбоев соседей. А удаление студента или корректировка балла расходятся по сервисам каскадом событий через Kafka.

Самым коварным оказалось время

Таймер ассесмента и метки событий сначала опирались на часы компьютера студента. А они у части людей сбиты на часы или подкручены вручную.

Теперь всё считается по времени сервера. Приложение берёт его из заголовков обычных ответов, без отдельных запросов. Длительности меряются монотонными часами, которые перевод системного времени не трогает.

Что ещё пришлось придумать

• Сохранение, которое переживает обрыв связи. Ответы сохраняются через полторы секунды после ввода и каждые тридцать секунд. При сбое сети запрос повторяется с нарастающей паузой, при закрытии вкладки — дописывается. После обрыва студент нажимает «Продолжить» и оказывается на том же месте.
• Длинные списки, которые не тормозят. На тестовых данных дерево КРМ и матрица результатов не тормозили вовсе. Но в Яндекс.Браузере дерево на полторы тысячи узлов начало подвисать. С тех пор в команде правило: любой список длиннее ста строк рисует только видимую часть. На матрице реального вуза — 215 студентов на 42 вопроса — элементов на странице стало в восемь раз меньше.
• Песочница, из которой ничего не утекает. Код студента запускается не из браузера, а через серверную часть. В браузер попадает только результат открытого примера, а приватные тесты и их ожидаемые выводы туда не доходят.
• Зашифрованный журнал наблюдения. События сессии шифруются прямо в браузере и уходят на сервер пачками. Ключ выводится из идентификатора сессии одинаково на клиенте и сервере. Поэтому журнал нельзя ни прочитать, ни подделать беглым взглядом в инструментах разработчика.
• апас прочности на пик. Задания грузятся по одному при открытии, а не всем списком при старте. Обновление токенов идёт одной цепочкой на все одновременные запросы, чтобы не множить обращения к серверу авторизации.

Архитектура на три года вперёд. Модель данных и идентификаторы единиц оценки заложены так, чтобы циклы 2027 и 2028 годов прошли без миграций.

Результат: окно прошло без критичных сбоев

Платформа работает в промышленной эксплуатации на серверах МФТИ. Основное окно ассесмента прошло с 7 по 30 сентября 2026 года, резервное — с 1 по 7 октября. Пик пришёлся на середину сентября, когда ассесмент одновременно проходили шесть-семь вузов.

Критичных сбоев не было. Мелкие погрешности случались, но устранялись быстро, и ни одна не остановила платформу. Сейчас идёт работа с результатами: вузы и заказчик изучают сводки, матрицы и разборы.

Проект в цифрах

Что дальше: от первого курса до выпуска

Ближайший год команда посвятит тому, что в ТЗ вынесли за рамки MVP и отложили в задел.

• Кабинет разработчика заданий: эксперты будут составлять и править задания прямо в платформе.
• Новые типы заданий.
• Локальные большие языковые модели (LLM) для проверки открытых ответов — с экспертом как финальной инстанцией.
• Доработка прокторинга.
• Апелляции внутри платформы.
• Профили компетенций студента.

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

Вторая цель — масштаб. Платформа с самого начала задумывалась как LMS независимого оценивания. Её можно разворачивать в других проектах и вузах — везде, где нужна одна шкала для многих участников.