Как проходить сценарий
- Создать учебный case: это контейнер задания, версии и эталонных ошибок.
- Загрузить SVG/DXF: SVG нужен для отображения и разметки областей, DXF хранится как технический источник.
- Выделить эталонную область ошибки: преподаватель видит эталонный слой поверх SVG.
- Запустить DXF-анализ: система извлекает элементы чертежа и применяет детерминированные правила.
- Добавить expected finding: это ошибка, которую преподаватель ожидает увидеть в ответе ученика.
- Перейти в UI ученика и показать, что эталонная область ему не видна.
- После ответа ученика вернуться сюда для просмотра результата, expert review и audit.
- Открыть задание: case и SVG должны быть подготовлены преподавателем.
- Выделить область на чертеже: ученик видит только свой прямоугольник, без эталонных подсказок.
- Написать найденную ошибку и вариант исправления.
- Отправить annotation и запустить оценку.
- Посмотреть итог: прошел/не прошел, процент и детали проверки.
1. Case: учебное задание
Case хранит постановку задания, версию и набор ожидаемых ошибок. Для MVP это база админского сценария преподавателя.
2. Assets: файлы чертежа
SVG отображается в UI и проходит санитизацию. DXF можно загрузить для будущей машинной обработки, но инженерные ошибки в MVP ищутся по заранее размеченному expected finding.
3. SVG разметка: область ошибки
Красный прямоугольник имитирует область, которую выделяет преподаватель или ученик прямо на чертеже.
Потяни мышью по чертежу, чтобы выбрать прямоугольную область. Координаты считаются в SVG viewBox.
4. System DXF analysis: что нашёл алгоритм
Этот шаг использует не ручную разметку, а извлечённые из DXF размеры, тексты, допуски и шероховатости. Rule Engine возвращает findings с elementIds, regions и evidence. Если загружен SVG того же case, система также рисует фиолетовые `svgRegions` поверх чертежа.
JSON ниже показывает каноническую модель `drawing` и алгоритмические `findings`. Для production это главный explainable слой: почему правило сработало и на какие DXF-элементы оно ссылается.
5. Expected finding: эталонная ошибка
Expected finding описывает ошибку, которую должен найти ученик: код правила, зона на SVG, допустимые формулировки ошибки и допустимые варианты исправления.
JSON ниже показывает, что backend сохранил как эталон: `regions` используются геометрическим matcher-ом, `accepted*Phrases` используются текстовым сопоставлением, `weight` влияет на итоговый процент.
6. Student submission: ответ ученика
Submission показывает ученическую часть сценария: ученик выделяет область, пишет что не так и предлагает исправление. Backend не требует дословного совпадения, а сопоставляет область и смысловые фразы с эталоном.
JSON результата показывает `matches`, `score` и объяснения. Для бизнеса главное: какие expected findings засчитаны, какие не найдены, сколько процентов получил ученик.
7. Expert review и audit: ручная проверка
Если ученик нашёл другую корректную ошибку или предложил альтернативную формулировку, преподаватель может принять это экспертным решением. Все такие действия попадают в audit.
JSON audit нужен для проверки прозрачности: кто принял решение, к какой annotation оно относится и как это повлияло на результат.
8. AI text classification: SambaNova smoke
Сейчас подключена текстовая SambaNova-модель для классификации формулировок ученика. Это не Qwen-VL и не анализ изображения: модель не видит SVG/DXF, не ищет геометрию и не влияет на итоговый score.
9. AI vision smoke: Qwen-VL
Этот блок отправляет текущий SVG asset в vision-модель SambaNova. Ответ носит справочный характер: VLM не выставляет балл, не заменяет DXF Rule Engine и не считается источником истины по геометрии.
10. API log: техническая отладка JSON
Здесь видны HTTP-запросы и сырые JSON-ответы backend-а. Это полезно, когда нужно понять не экран, а фактический контракт API.