На хакатоне SkillFactory компания Neoflex поставила перед студентами практическую задачу — создать MVP ИИ-сервиса для автоматической проверки тестовых заданий кандидатов в Учебный центр. В статье рассказываем, как команда организовала разработку, решила проблему воспроизводимости оценок, построила сквозной пайплайн обработки заданий и представила решение, которое может стать основой для автоматизации процесса отбора.
С какой задачей пришли партнеры
Компания Neoflex регулярно набирает участников на внутренние образовательные программы для начинающих специалистов. Важный этап отбора — тестовое задание, по которому команда оценивает уровень подготовки кандидатов. Когда заявок становится слишком много, проверять их сложнее.
На хакатоне SkillFactory компания Neoflex предложила студентам решить эту проблему — разработать MVP ИИ-агента, который будет автоматически проверять тестовые задания кандидатов и формировать развернутую оценку. Целью было не только сократить время проверки, но и сделать процесс более масштабируемым и прозрачным — как для организаторов, так и для участников.
От команд мы ожидали идей и интересных подходов к решению задачи. По итогам хотелось не только увидеть работающий прототип, но и найти талантливых специалистов, которых сможем рекомендовать к трудоустройству.
Партнеры обозначили не только функциональные, но и качественные требования. По замыслу ИИ-агент должен:
- проверять тестовые задания и выставлять оценку по десятибалльной шкале;
- формировать отдельную обратную связь для организаторов и для кандидатов;
- корректно обрабатывать нестандартные случаи — например, пустые ответы или частично выполненные задания;
- выдавать результат в едином формате, пригодном для интеграции с таблицами и ботом.
Особый акцент партнеры сделали на воспроизводимости решения: код должен быть опубликован в репозитории, а архитектура и логика оценивания — подробно описаны, чтобы сервис можно было развивать и интегрировать в существующий процесс отбора.
Как студенты работали над проектом
Над кейсом работали несколько команд, но лучшим по итогам финальной защиты стало решение команды №8. В нее вошли шесть участников с разным профессиональным опытом — от разработки и анализа данных до бизнес-аналитики, управления в ретейле и предпринимательства. Такое сочетание позволило посмотреть на задачу не только с инженерной, но и с продуктовой стороны.
Тимлид команды спроектировал общий каркас MVP, а также продумал взаимодействие всех компонентов и интеграцию с базой данных, объектным хранилищем и LLM-моделью. Остальные участники разделили между собой этапы обработки данных. Каждый отвечал за отдельный модуль пайплайна — за загрузку и нормализацию файлов, оценку работ, формирование обратной связи, экспорт результатов и интеграцию с Telegram.
Мы сразу строили работу так, чтобы максимально распараллелить разработку при минимальном архитектурном риске. На хакатоне время — самый ценный ресурс, поэтому еще до начала разработки зафиксировали стек технологий, требования, границы MVP, целевую архитектуру, модель данных и основные контракты между компонентами системы. Когда эти решения были приняты, команда разделилась на несколько независимых треков: одни занимались инфраструктурой и базой данных, другие — API и Telegram, третьи — модулем оценки на основе LLM, четвертые — экспортом результатов и тестированием. Благодаря этому мы смогли одновременно разрабатывать парсинг документов, цепочку оценки и интеграцию с Telegram, практически не мешая друг другу и не создавая конфликтов при сборке общего решения.
Работу над проектом команда разбила на несколько этапов. Сначала участники детально изучили требования заказчика и определили границы MVP: они решили строить не просто сервис автопроверки, а полноценную систему с четко определенным жизненным циклом обработки каждого задания. После этого студенты спроектировали архитектуру пайплайна — от получения задания до выдачи оценки и обратной связи.
Следующим этапом стало создание базовой инфраструктуры. Команда реализовала единый runtime-каркас приложения, настроила слоистую архитектуру, систему хранения данных в PostgreSQL и объектном S3-совместимом хранилище, а также механизм миграций. Отдельно разработали собственный evaluation framework, который отвечал за взаимодействие с языковой моделью, хранение параметров каждого запуска и воспроизводимость результатов.
После этого участники реализовали отдельные сервисы обработки. Система научилась принимать задания в разных форматах — TXT, DOCX и PDF, а также распознавать изображениях с помощью OCR, нормализовывать данные, передавать их в модуль оценки и формировать два независимых варианта обратной связи — для кандидата и для команды Учебного центра. Дополнительно разработали экспорт результатов в таблицы, интеграцию с Telegram и минимальный веб-интерфейс для администраторов и кандидатов.
В качестве технологической основы команда использовала Python 3.12, FastAPI, PostgreSQL, Docker Compose и OpenAI-совместимый API для работы с LLM. Для обработки документов применяли нативный парсинг PDF и DOCX, а также Tesseract OCR для изображений. Очередь обработки реализовали без внешнего брокера сообщений — на механизме PostgreSQL с использованием FOR UPDATE SKIP LOCKED. Это позволило не усложнять инфраструктуру и одновременно обрабатывать несколько заданий.
Самой сложной задачей оказалось сделать оценку воспроизводимой, а не зависящей от того, какой ответ в конкретный момент сгенерирует LLM. Простого запроса „оцени работу по десятибалльной шкале“ здесь недостаточно — это превращается в лотерею. Поэтому мы вынесли итоговый скоринг в отдельный детерминированный слой, а также начали сохранять все параметры, которые влияют на результат: версию цепочки, модель, настройки генерации и другие. Еще одной серьезной задачей стала нормализация входных данных: кандидаты могли присылать текстовые документы, PDF, сканы или изображения, и все это нужно было привести к единому формату для дальнейшей обработки. При этом самым интересным для нас было превратить набор отдельных скриптов в полноценную инженерную систему. Мы построили пайплайн из независимых стадий с единым контрактом, благодаря чему его легко тестировать, расширять и сопровождать. Еще одним важным решением стал детерминированный скоринг поверх LLM: модель отвечает за анализ работы по критериям, а итоговую оценку рассчитывает уже наш код. Такой подход позволил сохранить преимущества языковой модели и одновременно сделать результаты прозрачными и объяснимыми.
Одной из особенностей проекта стало то, что значительную часть инфраструктуры команда написала самостоятельно. Помимо архитектурного каркаса, студенты разработали собственный фреймворк оценки, который определял логику взаимодействия с LLM, рассчитывал итоговую оценку по десятибалльной шкале и сохранял параметры каждого запуска модели. Благодаря этому результаты можно было воспроизводить и анализировать, что было одним из ключевых требований заказчика.
Каким получился итоговый продукт
По итогам хакатона команда представила MVP сервиса автоматической проверки тестовых заданий. В основе решения — сквозной пайплайн, который сопровождает работу кандидата на всех этапах — от загрузки задания до формирования оценки, обратной связи и передачи результатов организаторам.
Система поддерживает два сценария подачи работы. Кандидат может загрузить тестовое задание через API или начать процесс в Telegram, после чего бот выдает ссылку на форму отправки. Независимо от способа загрузки сервис принимает файлы в разных форматах — TXT, DOCX, PDF и изображения, распознавая текст даже в сканированных документах с помощью OCR.
После обработки данные проходят через модуль оценки на основе LLM. Команда построила его по принципу rubric-driven evaluation: языковая модель анализирует работу по заранее заданным критериям и возвращает ответ в строгом формате JSON. Итоговая оценка по десятибалльной шкале рассчитывается отдельно, что делает результаты воспроизводимыми и позволяет объяснить, почему кандидат получил именно такой балл.
Из одного результата оценки система автоматически формирует два варианта обратной связи. Организаторы получают подробный технический разбор работы, а кандидат — рекомендации, которые помогают понять сильные стороны решения и возможные точки роста. Дополнительно реализованы экспорт результатов в CSV для команды Учебного центра и подготовка сообщений для последующей рассылки через Telegram.
Отдельное внимание команда уделила надежности сервиса. В системе реализовали механизм восстановления задач после сбоев, ведение журнала всех обращений к языковой модели с сохранением параметров каждого запуска, базовый административный интерфейс для просмотра работ и результатов, а также набор автоматических тестов и Docker-инфраструктуру, позволяющую быстро развернуть сервис.
При этом часть возможностей команда сознательно оставила за пределами MVP. В частности, не вошли инструменты для повторной обработки ошибок и оповещения администраторов о проблемных заданиях, полноценный диалоговый сценарий работы с кандидатом в Telegram и расширенная система регулярной проверки качества модели на эталонных наборах данных.
Мы высоко оцениваем результат команды-победителя. Ребята реализовали работоспособного ИИ-агента строго по нашему ТЗ, а также добавили собственные продуманные наперед функции, которые мы упустили. В процессе работы ребята не стеснялись задавать уточняющие вопросы, что помогло точнее попасть в задачу. На защите они не ограничились заготовленной презентацией — показали живое демо продукта и грамотно отвечали на вопросы. Мы планируем по мере возможности использовать наработки студентов в реальном процессе Учебного центра — для автоматизации проверки тестовых заданий.
