Цепочка генерации
Как эталон превращается в проверенные варианты: анализ, генерация, проверки, починка и роль эталонного набора.
Эта статья — для заказчика и жюри: что происходит под капотом между загрузкой эталона и готовым комплектом в библиотеке. Без кода, но с той же логикой, что реализована в рабочей версии на teacherflow.ru.
Краткий обзор методики — в разделе Контроль качества; профиль сложности и пороги — в Методологии контроля сложности.
Схема процесса
детерминированная подстановка чисел
генерация через модель
ответы, похожесть, инварианты
до 4 попыток на комплект
→ снова к шагу «Три судьи»
На простых числовых задачах математики часть вариантов собирается шаблоном без вызова модели — это ускоряет комплект и снижает расход токенов. Смысловые проверки и пороги сложности действуют для обоих путей.
Шесть этапов по смыслу
1. Анализатор. По эталону (текст, файл, OCR) система определяет предмет, тип задания, инварианты («что нельзя менять»), вариативные элементы и профиль сложности — число шагов, операции, уровень задачи, форма ответа. Это не «пересказ условия», а структура для последующих проверок.
2. Генератор. Создаёт запрошенное число вариантов (от 2 до 10). Для простой математики с числами часть комплектов собирается шаблоном без вызова языковой модели: подставляются другие числа в том же каркасе задачи. Для остальных случаев — GigaChat Pro. Оба пути сходятся в черновике вариантов, который дальше проходит одинаковые проверки.
3. Дешёвые проверки. До обращения к «судьям» срабатывают быстрые правила: совпадение ответов между вариантами, похожесть формулировок, явные нарушения инвариантов. Если ответ однозначен, модель не дублирует ту же проверку.
4–5. Три судьи и голосование. Три независимые смысловые оценки (структура, сложность для ученика, уникальность комплекта) сочетаются с числовым профилем и порогами из YAML-политик по предмету. Итог — принять, предупредить или отправить на доработку.
6. Починка. Только варианты с браком перегенерируются или уточняются — не весь комплект целиком. Бюджет попыток на один запрос ограничен (до четырёх циклов на комплект), чтобы уложиться в разумное время и лимиты API.
Успешные варианты сохраняются в базе; учитель видит вердикты, может сравнить с эталоном, отредактировать и экспортировать.
Зачем нужен эталонный набор (goldset)
Качество нельзя «заморозить» одним удачным демо. В проекте есть эталонный набор (goldset) — каталог проверенных сцен «эталон → хороший вариант» по школьным предметам (сейчас около 50 сцен по матрице предметов) и отдельно 9 антипримеров — заведомо плохих вариантов, которые система обязана отклонять.
| Что проверяем | Порог | Зачем |
|---|---|---|
| Хорошие пары goldset | ≥ 80% успеха | Регрессия не ухудшила генерацию |
| Антипаттерны | ≥ 80% отказов | Система не «проглатывает» типичный брак |
Прогон выполняется на той же GigaChat, что и в продакшене, при каждом существенном изменении промптов, политик или логики пайплайна. Если порог не выполнен — изменение не попадает в рабочую ветку. Для заказчика это означает: качество не держится на обещаниях команды, а на воспроизводимом камертоне и автоматическом контроле перед релизом.
Ядро с самыми жёсткими политиками — математика 5–9 и английский A2–B1; остальные предметы каталога подключены к той же матрице и проходят тот же gate по мере расширения фикстур.
Что это даёт на демо
- Можно показать прозрачную цепочку, а не «магию чата».
- Можно честно говорить о гибриде: шаблон там, где задача числовая и предсказуемая; модель — где нужен смысл и язык.
- Можно сослаться на goldset как на инженерную дисциплину качества, аналогичную тестам в разработке ПО.
Подробнее о профиле сложности, осях и вердиктах — в Методологии; о скорости и лимитах API — в Скорости и устойчивости.