Как построить корпоративную экзаменационную платформу с AI: метод, пайплайн

Команда, которая решает автоматизировать внутреннюю аттестацию сотрудников через LLM, сталкивается с выбором: доверить генерацию вопросов модели «как есть» или построить управляемый конвейер. Второй вариант требует больше инженерной работы, но даёт контроль качества. Команда Sandboxer опубликовала практический разбор своей платформы Exam AI — с архитектурой, ошибками и конкретными решениями. Вот что из этого опыта можно взять для своей системы.

Источник: Habr

Что произошло. Компания Sandboxer построила внутреннюю платформу для аттестации сотрудников, где вопросы генерируются из нормативных документов через LLM. Система работает в multi-tenant режиме, поддерживает stateful экзамен, роли, апелляции и аналитику. Главное — они не отдали генерацию «на откуп» модели, а сделали пятиступенчатый пайплайн с человеком в контуре.

Почему это важно для бизнеса. Ручная подготовка экзаменов — долго, дорого и плохо масштабируется. При изменении регламента весь цикл начинается заново. AI-пайплайн сокращает путь «документ → экзамен», но без правильной архитектуры даёт поверхностные вопросы, дубли и тематические перекосы. Опыт Sandboxer показывает, какие компромиссы реальны, а какие — ловушки.

Что проверить до внедрения. Прежде чем копировать подход, убедитесь, что ваша команда готова к DDD-слоям, отдельному планированию генерации и обязательной экспертной проверке. Без этого AI-генерация не даст нужного качества.

Что изменилось в подходе к генерации экзаменов

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

Sandboxer поставил цель: сократить путь «документ → экзамен», но не потерять контроль качества. Их решение — не «отдать всё ИИ», а построить управляемый конвейер с явными стадиями.

Ключевое изменение: они перешли от прямого запроса к модели («дадим большой документ и попросим сгенерировать N вопросов») к многошаговому пайплайну. Первый подход давал тематические перекосы, поверхностные вопросы, дубли в разных формулировках и плохую воспроизводимость между запусками.

Архитектура: почему DDD-слои реально помогают

На backend команда изначально держала жёсткое разделение на четыре слоя:

• domain — сущности, value objects, протоколы;
• application — use cases;
• infrastructure — репозитории, внешние адаптеры, агенты;
• presentation — API и схемы.

Это звучит банально, но на длинной дистанции спасает. Когда появляется новый источник контента, новый LLM-провайдер или новый вариант scoring/validation, вы меняете адаптеры и оркестрацию, а не переписываете всё ядро.

Технический стек:

Для команды, которая планирует похожую систему, важно: DDD-слои — не бюрократия, а страховка от переписывания кода при смене LLM-провайдера или добавлении нового источника контента.

Пайплайн генерации вопросов: пять стадий

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

1. Scan. Документ режется на фрагменты, строятся эмбеддинги, формируется карта тем. Это позволяет понять структуру документа до генерации.

2. Plan. Отдельный шаг планирования: сколько вопросов на тему, какой тип контента, приоритеты, какие области знаний покрываем. Без этого шага модель «схлопывает» широкую тему в один конкретный сценарий.

3. Generate. Генерация не свободного текста, а строго типизированной структуры (Pydantic-схемы). Невалидный ответ → retry с уточнением требований.

4. Validate. Автопроверки кандидатов: semantic near-duplicate, валидность ожидаемого ответа, привязка к knowledge area, проверка формата и полноты.

5. Review. Последнее слово у эксперта: approve, edit или reject. Человек в контуре — обязательный quality gate.

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

Борьба с дубликатами: конкретный кейс

Один из самых неприятных продовых багов: пользователь просит 2 вопроса по теме, а получает два перефраза одного и того же кейса. Проблема архитектурная: пользователь мыслит «тема = широкая область», а модель часто мыслит «тема = конкретный сценарий».

Что сделали:

• На этапе scan начали нормализовать check_focus как нумерованный список независимых граней темы.
• На этапе generate стали жёстко выбирать одну грань на текущий вопрос.
• Добавили отрицательный контекст: последние формулировки + повторяющиеся опорные токены.
• В prompt зафиксировали требование менять формулировку и пример.

Для команды, внедряющей AI-генерацию, это ключевой урок: проблема дубликатов не решается одним промптом. Нужна архитектурная поддержка на уровне планирования и валидации.

Где риски и ограничения

Опыт Sandboxer полезен, но его нельзя копировать слепо. Вот что стоит проверить до внедрения.

Стоимость. Пайплайн с несколькими вызовами LLM (scan, plan, generate, validate) дороже одного прямого запроса. Нужно считать не только токены, но и время экспертов на review.

Зависимость от качества документов. Если исходные нормативные документы плохо структурированы, scan и plan будут давать мусор на входе.

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

Multi-tenant. Если платформа обслуживает несколько организаций, изоляция данных и конфигураций — отдельная сложность, которую Sandboxer упоминает, но не раскрывает детально.

Практический чек-лист для внедрения

Прежде чем строить свою систему, проверьте эти пункты:

• [ ] Есть ли у вас чёткое разделение на domain, application, infrastructure и presentation? Если нет — начните с этого, иначе смена LLM-провайдера потребует переписывания ядра.
• [ ] Разбит ли процесс генерации на отдельные стадии (scan, plan, generate, validate, review)? Если нет — вы получите дубли и тематические перекосы.
• [ ] Используете ли вы строго типизированные схемы (Pydantic) для выходных данных? Без них retry и валидация будут хаотичными.
• [ ] Есть ли у вас автоматическая проверка на semantic near-duplicate? Если нет — дубликаты станут хронической проблемой.
• [ ] Выделен ли ресурс на экспертную проверку? Без человека в контуре качество вопросов будет неприемлемым.
• [ ] Проверена ли стоимость одного цикла генерации (токены + время эксперта)? Если стоимость выше ручной подготовки, смысл автоматизации теряется.

Что можно сделать на этой неделе

1. Проведите аудит текущего процесса подготовки экзаменов. Замерьте время от появления нового регламента до готового экзамена. Это будет базой для сравнения.
2. Соберите 2-3 реальных документа и попробуйте прогнать их через простой промпт к LLM. Оцените количество дубликатов и поверхностных вопросов. Это покажет, нужен ли вам полноценный пайплайн.
3. Определите, кто будет экспертом на этапе review. Без этого человека внедрение AI-генерации не имеет смысла.
4. Оцените, готов ли ваш стек к DDD-слоям. Если backend — монолит без чёткого разделения, начните с рефакторинга, а не с AI-генерации.

Источники

• Habr статья: Как мы строим корпоративную экзаменационную платформу с AI

Генерация изображения

• Модель: flux-schnell
• Провайдер: replicate

Что почитать дальше

• AI-фотографии 2026: как работает генерация изображений, где применять и какие ограничения
• Silver Text Gate: многоуровневая фильтрация текста в AI — что даёт бизнесу и где внедрение тормозит
• {'seotitle': 'Silver Text Gate: платформа автоматической модерации — контроль качества русскоязычного контента
• Архитектура промышленного контент-завода: почему один инструмент не решает все
• AI-агент с Docker-песочницей на LangGraph: готовая архитектура для безопасного исполнения кода