Локальный ИИ для подготовки к ОГЭ и ЕГЭ: как учиться по ФИПИ, а не по выдумкам нейросети

Что актуально на 21 сентября 2026 года

ФИПИ уже опубликовал проекты документов, определяющих структуру и содержание КИМ ОГЭ и ЕГЭ 2027 года. На момент подготовки этой статьи они находятся на общественно-профессиональном обсуждении до 30 сентября 2026 года.

Это хороший пример, зачем AI-системе нужно versioning. Если загрузить в одну RAG-базу документы 2026 и проекты 2027 без метаданных, LLM легко смешает разные требования.

Почему обычный чат с LLM плохо подходит для серьёзной подготовки

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

Какие официальные материалы должны лежать в основе системы

Exam Profile: главная сущность всей системы

Exam Profile — это не PDF в RAG, а структурированный объект конкретного экзамена и года.

{
  "exam": "EGE",
  "subject": "russian",
  "year": 2027,
  "status": "draft_project",
  "source": "FIPI",
  "published_at": "2026-08-28",
  "discussion_until": "2026-09-30",
  "task_types": ["RU-2027-01", "RU-2027-02", "..."],
  "rubric_version": "2027-draft-1",
  "documents": {
    "codifier": "...",
    "specification": "...",
    "demo": "..."
  }
}

После утверждения итоговых документов создаётся новая версия профиля или меняется статус только после проверки diff.

Проект 2027 нельзя молча подменять утверждённой версией

Каждое задание должно иметь task_type_id

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

Если в 2028 году тот же проверяемый навык переедет на другой номер, исторические данные не развалятся.

Номер задания и навык — тоже не одно и то же

Одно задание может требовать нескольких навыков, а один навык встречаться в разных линиях. Поэтому нужна связь Task Type ↔ Skill Graph.

Если ученик трижды ошибается в одном номере, planner должен понять, что именно слабое: предметный навык, формат, вычисление или невнимательность.

Подготовку логично начинать с диагностического пробника

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

Для первого запуска необязательно сразу моделировать весь экзамен. Можно дать representative diagnostic: по 1–2 задания каждого крупного типа, а полный timed mock оставить после базовой диагностики.

Error Map: «неверно» слишком мало

Эта классификация важнее общего процента правильных ответов: для разных причин нужны разные interventions.

Методические материалы ФИПИ можно использовать как приоритет, но не как диагноз ребёнка

ФИПИ публикует аналитические и методические материалы по типичным ошибкам участников ЕГЭ. Это полезный источник для определения потенциально сложных тем и создания diagnostic coverage.

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

Как строить план подготовки

priority(task_type) =
    exam_relevance * 0.30
  + personal_weakness * 0.30
  + prerequisite_need * 0.15
  + forgetting_risk * 0.15
  + time_efficiency * 0.10

Это не универсальная научная формула, а пример прозрачной инженерной политики. Она лучше свободного решения LLM «сегодня давай порешаем номер 14».

Как генерировать аналоги заданий и не превращать подготовку в лотерею

LLM должна получать не просьбу «придумай похожий вопрос», а формализованный Task Spec, который построен из Exam Profile.

{
  "exam": "EGE",
  "subject": "math_profile",
  "year": 2027,
  "task_type_id": "MATH-P-2027-T08",
  "source_status": "generated_analogue",
  "skills": [
    "math.percent",
    "math.word_problem"
  ],
  "difficulty": "base",
  "answer_type": "numeric",
  "constraints": {
    "integer_answer": true,
    "single_solution": true
  },
  "validator": "python"
}

Дальше генератор создаёт несколько кандидатов, а validator выбрасывает те, у которых неправильный эталон, неоднозначное условие или нарушение ограничений.

Сгенерированный аналог нельзя называть «реальным заданием ФИПИ»

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

Validator — центральная защита от плохих AI-заданий

Важно разделять проверку задания до выдачи и проверку ответа ученика. Для генеративного тренажёра нужны обе.

Развёрнутые ответы нельзя оценивать как обычный multiple choice

Сочинение, доказательство, объяснение физического процесса или развёрнутый ответ могут иметь несколько корректных реализаций. Здесь LLM полезна как rubric assistant, но её оценка должна быть декомпозирована по критериям.

Учебный tutor может давать ориентировочную тренировочную оценку, но не должен обещать, что она совпадёт с решением официальной предметной комиссии.

Критерии тоже нужно версионировать

Даже если общий тип задания сохраняется, критерии и схемы оценивания могут меняться между годами. Поэтому rubric нельзя хранить как вечный prompt.

{
  "rubric_id": "RU-EGE-ESSAY-2027-DRAFT",
  "exam_year": 2027,
  "status": "draft_project",
  "source": "FIPI demo/specification",
  "criteria": [
    {"id": "K1", "max_score": "..."},
    {"id": "K2", "max_score": "..."}
  ],
  "effective_from": null
}

После выхода финальной версии новый rubric проходит diff, после чего старые тренировочные результаты остаются привязанными к старой схеме.

Русский язык: ИИ особенно полезен для error mapping и сочинения

ФИПИ в рекомендациях 2026 по русскому языку отдельно советует начинать с анализа кодификатора, спецификации и демоверсии, а затем работать с типичными ошибками. Это фактически уже готовая логика для автоматизированного planner.

Математика: максимальная польза от deterministic checking

Для многих математических задач можно автоматически проверить не только итог, но и свойства сгенерированного задания: наличие решения, единственность, целочисленность ответа, диапазон параметров.

Информатика: нужен настоящий sandbox, а не оценка кода «на глаз»

Если задание предполагает программу, ответ проверяется запуском на тестах. LLM может объяснять алгоритм и находить вероятную ошибку, но результат определяет runner.

Физика и химия: формула, единицы и reasoning — отдельными слоями

Генерация условия без solver опасна: модель может придумать числа, при которых ответ получается абсурдным или задача имеет лишнюю неоднозначность.

История, обществознание и литература: RAG и rubric важнее «памяти модели»

В гуманитарных предметах часть ответа нельзя свести к exact match. Зато можно жёстко контролировать источник фактов и структуру критерия.

Иностранные языки: письменная и устная части требуют разных pipeline

ФИПИ публикует для иностранных языков отдельные материалы письменной и устной частей и аудиофайлы, поэтому Exam Profile должен хранить эти компоненты раздельно.

Режим полного пробника должен быть жёстко отделён от обучения

Пробник нужен не для объяснения, а для измерения. Значит, во время него нельзя показывать подсказки, RAG-фрагменты, готовые формулы и answer reveal.

Это та же логика, что в отдельном Socratic/anti-cheating модуле: режим определяется session state, а не просьбой ученика.

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

Нельзя просто показать правильные ответы и считать работу завершённой. Для каждого промаха tutor должен ответить минимум на три вопроса: что произошло, какое знание/умение было нужно и как проверить его снова в новой формулировке.

Слабые типы заданий нужно возвращать через интервальное повторение

Если ученик разобрал ошибку сегодня, это не значит, что через две недели навык останется устойчивым. Поэтому Exam Planner должен передавать skills и task types в review scheduler.

Что хранить в Student DB

Так можно отвечать на практические вопросы: «на каких типах теряется больше времени?», «какие ошибки исчезли после разбора?», «какие навыки ломаются только в полном пробнике?».

Полная архитектура локальной системы подготовки

Практический локальный стек

Как собрать полезный MVP, не пытаясь охватить все экзамены сразу

1. Выбрать один экзамен и один предмет.Например, ОГЭ по математике или ЕГЭ по русскому.
2. Зафиксировать один Exam Profile.2026 approved или 2027 draft — не смешивать.
3. Разобрать 10–20 task types.ID, skills, answer type, checker.
4. Загрузить официальные документы в отдельную RAG-базу.С годом и статусом.
5. Сделать диагностический набор.По одному-двум заданиям на ключевые типы.
6. Подключить exact/numeric checker.Сначала то, что можно проверять детерминированно.
7. Добавить Task Generator.Только generated analogue + обязательная маркировка.
8. Ввести Error Map.Не хранить просто «неверно».
9. Добавить Adaptive Planner.Направлять ученика в skill, а не бесконечно решать один номер.
10. После этого — полный timed mock.Без hints и RAG до submit.
11. Развёрнутые ответы подключать последними.Там больше всего uncertainty и rubric complexity.

Как обновлять систему при публикации финальных КИМ 2027

На 21 сентября 2026 документы 2027 ещё проектные. После выхода финальных материалов система должна выполнить миграцию, а не просто заменить файлы.

Типичные ошибки при создании AI-тренажёра ОГЭ/ЕГЭ