Артефакт 1. Полная дефектовка — для нас

В новом архиве обнаружен один проект:

«Эксперимент по внедрению ИИДА»

ИИДА — ИИ в Дата-Аналитике. Авторы: Елена Петровна Киселица и Светлана Александровна Иванова, кафедра экономики и финансов ТюмГУ.

Материалы прочитаны полностью:

● Презентация проекта — 28 слайдов

● Сопроводительный текст

RTF представляет собой сокращённый рекламно-аннотационный пересказ презентации и новых содержательных данных почти не добавляет.

1\. Сводный вердикт

У проекта есть сильная практическая проблема, удачно выбранная предметная область и потенциально ценный продуктовый ход: создать в Jupyter среду продвинутой практики для студентов, которые проходят стандартные задания быстрее остальной группы.

Однако в текущем виде перед нами:

● уже довольно подробно описанная идея продукта;

● предварительный перечень функций;

● набор предполагаемых эффектов;

● слабое эмпирическое обоснование;

● экспериментальный дизайн, который не позволяет установить причинный эффект ИИДА;

● четыре разных гипотезы, сложенные в одну;

● архитектура, пока обозначенная названиями блоков;

● «техническое задание», состоящее из наименования, среды, аудитории и сроков.

То есть проект находится в статусе:

содержательно перспективная продуктовая концепция, ещё не собранная ни как образовательный эксперимент, ни как инженерное ТЗ.

Главный дефект — авторы сразу проектируют довольно крупную систему и обещают её эффективность, не разделив:

1\. качество генерируемых заданий; 2. качество машинного оценивания; 3. образовательный эффект подсказок; 4. экономию времени преподавателя.

Пока ИИДА должен одновременно генерировать, адаптировать, проверять, учить, измерять метакогницию, экономить время и затем быть готовым к тиражированию. Это уже не пилот, а небольшое министерство внутри Jupyter Notebook.

2\. Реконструкция замысла

Исходная ситуация

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

Авторы называют это «образовательным вакуумом» сильных студентов.

Предлагаемый продукт

ИИДА должен быть встроен в Jupyter Notebook и выполнять несколько функций:

● генерировать индивидуальные исследовательские задания;

● создавать синтетические датасеты с заданными зависимостями, шумами и аномалиями;

● проверять код;

● оценивать интерпретации, выводы и визуализации;

● выдавать пошаговые подсказки;

● подстраивать сложность следующих задач под продвижение студента;

● передавать результаты в Moodle или Modeus — в разных частях презентации фигурируют разные системы.

Целевая аудитория

Студенты, которые:

● уже хорошо владеют Python;

● быстро усваивают материал;

● справляются со стандартными заданиями;

● способны к самостоятельной работе;

● нуждаются в более сложных исследовательских задачах.

Тематический охват

Пять направлений:

1\. текстовые данные; 2. предобработка таблиц; 3. корреляция и проверка гипотез; 4. визуализация; 5. кластеризация.

Заявленные результаты

Для студентов:

● более высокое качество аналитических отчётов;

● ускорение адаптации к новым данным;

● повышение метакогнитивной точности;

● более глубокое освоение сложных тем;

● рост вовлечённости.

Для преподавателя:

● сокращение времени на разработку заданий;

● сокращение времени на проверку;

● передача ИИДА до 80% рутинной работы.

Для университета:

● масштабируемый инструмент работы с сильными студентами;

● прототип, готовый к тиражированию;

● статистический отчёт о доказанной эффективности.

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

3\. Что в проекте действительно сильное

3.1. Выбрана реальная педагогическая ситуация

Работа с сильными студентами часто исчезает из поля внимания, поскольку текущие затруднения остальных участников требуют немедленной реакции преподавателя. Авторы опираются на собственную предметную практику, а не начинают с любимой нейросети.

3.2. Дата-аналитика подходит для такого эксперимента

В этой области остаётся много наблюдаемых следов:

● код;

● версии ноутбука;

● результаты вычислений;

● выбранные методы;

● визуализации;

● текстовые интерпретации;

● количество попыток;

● время выполнения;

● последовательность исправлений.

Это позволяет видеть ход действия студента, а не только финальный файл, внезапно безупречный и примерно на 14 лет опытнее автора.

3.3. Есть содержательная возможность генерировать контролируемые задачи

Синтетические датасеты можно строить с заранее заданными:

● зависимостями;

● выбросами;

● пропусками;

● смешивающими факторами;

● шумами;

● скрытыми структурами.

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

3.4. Авторы понимают, что проверять требуется больше, чем код

Они отдельно называют:

● логику рассуждений;

● обоснованность вывода;

● интерпретацию;

● визуализацию.

Это важный ход. Простая проверка исполнения Python здесь действительно не покрывает образовательную задачу.

3.5. Есть попытка построить контрольный дизайн и карту рисков

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

4\. Главные критические дефекты

Критический дефект 1. Проблема подменена формулировкой решения

На слайде 3 центральная проблема сформулирована как:

автоматизация создания заданий и экспертной проверки.

Это уже решение.

Исходная образовательная проблема звучит иначе:

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

А проблема преподавателя:

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

Это две связанные, но разные проблемы. Автоматизация — одна из возможных интервенций.

Критический дефект 2. Экспериментальная и контрольная группы несопоставимы

На слайде 23:

● экспериментальная группа — сильные студенты с продвинутым Python;

● контрольная группа — студенты с любым уровнем владения Python.

При такой конструкции любой результат можно объяснить исходной подготовкой.

Кроме того:

● экспериментальная группа получает пять выбранных тем;

● контрольная — все темы дисциплины;

● экспериментальная получает адаптивные задания, мгновенную обратную связь, тьютора и автоматическую проверку;

● контрольная — статические задания и отложенную проверку преподавателя.

Здесь одновременно меняются:

● состав участников;

● сложность;

● содержание;

● тип заданий;

● скорость обратной связи;

● источник обратной связи;

● наличие подсказок;

● механизм адаптации;

● способ оценивания.

Даже при красивом p-value узнать, что именно сработало, будет невозможно.

Критический дефект 3. В один эксперимент сложены четыре самостоятельные гипотезы

Инженерная гипотеза

Можно автоматически создавать валидные, разнообразные и контролируемые датасеты и задания.

Оценочная гипотеза

LLM способен оценивать код, ход рассуждения, интерпретацию и визуализацию с приемлемым совпадением с экспертами.

Образовательная гипотеза

Адаптивные задачи и пошаговые подсказки улучшают действие сильных студентов.

Экономическая гипотеза

Такая система сокращает преподавательское время без снижения качества сопровождения.

У каждой из них:

● отдельный объект проверки;

● отдельные метрики;

● отдельный дизайн;

● отдельные условия провала.

Сейчас они сведены в общую H1: «ИИДА всё улучшает».

Критический дефект 4. Образовательный результат не выбран

В презентации одновременно заявлены:

● качество отчётов;

● глубина интерпретации;

● обоснованность;

● креативность;

● скорость адаптации;

● метакогнитивная точность;

● успеваемость;

● освоение материала;

● вовлечённость;

● удовлетворённость;

● снижение типичных ошибок.

Это полноценная исследовательская программа, а не набор метрик одного пилота.

Для первого эксперимента необходимо выбрать одну центральную способность. Например:

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

Остальные параметры могут стать вторичными.

Критический дефект 5. «Автономный ИИ-симулятор» пока является названием

Из описания видно несколько возможных модулей:

● генератор данных;

● генератор задания;

● проверщик кода;

● оценщик интерпретации;

● механизм подсказок;

● адаптер сложности.

Но не показано:

● что система воспринимает;

● какое состояние студента хранит;

● как выбирает следующую задачу;

● на каких правилах меняет сложность;

● когда сама принимает решение;

● когда передаёт случай преподавателю;

● где проходит граница автономии.

По фактически описанным функциям это пока:

адаптивная среда практики с генератором задач, проверкой и тьюторским контуром.

Уровень агентности — примерно 2: ИИ получает различённую функциональную роль. До автономного контура уровня 3 система дойдёт, когда появятся цикл диагностики, модель состояния студента, правила выбора интервенции и контролируемое завершение цикла.

Критический дефект 6. «Техническое задание» ещё отсутствует

Слайд 22 содержит:

● название;

● среду;

● целевую аудиторию;

● сроки.

Это паспорт идеи.

В ТЗ должны появиться как минимум:

● пользовательские роли;

● последовательность действий;

● функциональные модули;

● входные и выходные данные;

● схема хранения;

● интеграции;

● политика подсказок;

● правила проверки;

● human gates;

● сценарии ошибок;

● требования к логированию;

● требования к безопасности;

● критерии приёмки каждого модуля.

Лаборатория пока может обсуждать концепцию, но оценивать разработку ей ещё нечего.

5\. Полная диагностическая матрица

1\. Собственный интерес авторов

Есть: хорошо различима практическая заинтересованность в работе с более подготовленными студентами.

Дефект: отсутствует конкретная история возникновения проекта:

● на каком курсе;

● сколько лет наблюдается проблема;

● сколько студентов ежегодно оказывается в этой ситуации;

● какие действия преподаватели уже пробовали;

● где именно они упёрлись в предел.

Что нужно: короткий кейс из реального курса с цифрами и описанием одного занятия или модуля.

2\. Фрагмент образовательной практики

Есть: дата-аналитика, Jupyter Notebook, сильные студенты, середина семестра.

Дефект: объект остаётся широким. Пять тем, целый семестр, несколько типов результата, интеграция с LMS.

Что нужно: выделить один законченный фрагмент. Оптимальный кандидат:

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

Здесь можно задать контролируемую структуру данных и проверить качество интерпретации.

3\. Исходное целеполагание

Смешаны две цели:

1\. развитие сильных студентов; 2. снижение нагрузки преподавателя.

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

Для образовательного эксперимента центральной должна стать первая:

развитие способности выполнять и обосновывать исследовательский анализ новых данных.

Экономия времени проверяется отдельно.

4\. Образовательный результат

Назван, но распылён.

Требуется одна формула результата:

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

Тогда можно строить задания, рубрику и следы.

5\. Деятельность студента

Из презентации можно реконструировать:

1\. получает задачу; 2. работает в Notebook; 3. пишет код;

4\. строит визуализацию; 5. формулирует вывод; 6. получает машинную оценку; 7. получает подсказку; 8. исправляет решение.

Дефект: не показано, где именно студент совершает учебное действие, а где ИИДА делает его вместо него.

Особенно опасные места:

● выбор метода;

● формулировка гипотезы;

● интерпретация результата;

● обнаружение ошибки;

● решение о достаточности анализа.

6\. Проблематика

Проблема в целом собрана удачно, но выражение «образовательный вакуум» пока остаётся сильной метафорой.

Нужно различить:

● скуку;

● отсутствие задач;

● отсутствие обратной связи;

● прекращение развития;

● снижение мотивации;

● уход в самостоятельные внешние проекты.

Это разные процессы и требуют разных решений.

7\. Доказательство существования проблемы

На слайдах 8–9 представлены данные опроса и успеваемости.

Проценты на слайде 8 кратны 0,943%, что позволяет предположить выборку N = 106. Тогда доля с результатом выше 80 баллов — около 18 студентов. Это наша реконструкция; сама презентация размер выборки, метод и процедуру не сообщает.

На слайде 9 у «сильных студентов»:

● 12 отмечают, что было слишком просто и неинтересно;

● 12 отмечают наличие свободного времени;

● 2 — технические сложности;

● 1 — проблемы с данными.

Вероятно, допускался множественный выбор. Это тоже не указано.

Основные дефекты эмпирики:

● нет размера и состава выборки;

● нет определения «сильного студента»;

● нет текста вопросника;

● нет даты и курса;

● нет разделения между данными всех студентов и сильной подгруппы;

● нет данных об отсутствии обратной связи;

● нет измерения преподавательской нагрузки;

● показатель «затруднение/интерес» соединяет противоположные конструкции.

Например, 83% по визуализации может означать высокий интерес, высокую сложность либо оба варианта. График исправно показывает число. Что это число означает, графику поручить забыли.

8\. Концептуализация и теоретическое основание

На слайде 10 используются исследования ИИ-симуляций и виртуальных студентов в подготовке преподавателей.

Проблема — несоответствие объекта.

Цитируемые работы обсуждают:

● обучение преподавателей через симуляцию;

● виртуальных студентов;

● аутентичность диалога;

● suspension of disbelief.

ИИДА должен:

● генерировать аналитические задания;

● оценивать решения;

● давать обратную связь;

● адаптировать сложность.

Это другой педагогический механизм.

Нужны основания по четырём направлениям:

1\. адаптивная практика;

2\. deliberate practice и сложность задания; 3. формирующая обратная связь и scaffolding; 4. валидность автоматизированного оценивания открытых решений.

Слово «симулятор» сейчас направило литературный поиск в соседнее здание.

9\. Операционализация

Метрики перечислены, но не превращены в измерительные процедуры.

Качество решения

Нужна рубрика, например:

● корректность постановки задачи;

● выбор метода;

● техническая корректность;

● качество проверки предпосылок;

● интерпретация;

● границы вывода;

● качество визуального представления.

Скорость адаптации

Нужно определить:

● что такое новый тип данных;

● что считается эффективным решением;

● какая единица — минуты, попытки или число подсказок;

● когда задача считается завершённой.

Метакогнитивная точность

Нужно собирать:

● прогноз студента о качестве ответа;

● уверенность до проверки;

● фактическую экспертную оценку;

● разницу между уверенностью и результатом.

Время преподавателя

Нужно фиксировать:

● подготовку задания;

● проверку;

● ответы на вопросы;

● разбор эскалаций;

● исправление ошибок ИИДА;

● настройку и обслуживание системы.

Система может сократить проверку на 30 минут и добавить 47 минут расследования, почему она поставила кластеризации пятёрку за уверенность.

10\. Образовательная гипотеза

Текущая H1 перечисляет ожидаемые улучшения, но не содержит механизма.

Рабочая формула могла бы выглядеть так:

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

Здесь есть:

● интервенция;

● механизм;

● действие;

● результат;

● сравнение.

11\. ИИ-гипотеза

Её в презентации следует выделить отдельно:

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

Ключевое слово — комбинация.

Не стоит поручать LLM всё:

Детерминированный слой

● генерация датасета по параметрам;

● проверка структуры данных;

● запуск кода;

● тесты;

● проверка воспроизводимости;

● вычисление эталонных характеристик.

Семантический слой

● анализ обоснования;

● интерпретация;

● качество аргументации;

● формирование вопроса или подсказки.

Человеческий слой

● калибровка рубрики;

● разбор спорных случаев;

● утверждение сложных задач;

● изменение образовательной политики;

● итоговая экспертная оценка в пилоте.

12\. Сценарий «до / после»

До ● единое задание для группы;

● сильный студент быстро завершает;

● преподаватель занят другими студентами;

● дополнительная задача либо отсутствует, либо проверяется поздно;

● продвижение сильного студента не фиксируется.

После — пока только реконструкция

● ИИДА выбирает или создаёт задачу;

● студент решает её в Notebook;

● система проверяет исполнимость и базовые ошибки;

● LLM оценивает объяснение;

● система задаёт вопрос или выдаёт подсказку;

● студент делает следующую попытку;

● сложность меняется;

● преподаватель видит итог либо получает эскалацию.

Этот сценарий следует описать по шагам и ветвлениям. Сейчас он существует между стрелками на слайде 14.

13\. Распределение функций

Преподаватель

Предположительно:

● задаёт рамку темы;

● определяет требования;

● утверждает типы заданий;

● калибрует оценивание;

● разбирает сложные случаи.

ИИДА

● генерирует;

● проверяет;

● оценивает;

● подсказывает;

● адаптирует;

● логирует.

Студент

● решает;

● объясняет;

● исправляет;

● рефлексирует.

Неопределённые функции

● кто утверждает валидность нового задания;

● кто определяет сложность;

● кто решает, что студент готов перейти дальше;

● кто оспаривает машинную оценку;

● кто отвечает за ошибочную подсказку;

● кто обслуживает промпты и модели;

● кто следит за дрейфом качества;

● кто принимает итоговую оценку.

14\. Дизайн эксперимента

Текущая версия непригодна для причинного вывода.

Главные нарушения:

● группы различаются по исходной подготовке;

● содержание заданий различается;

● тип заданий различается;

● интенсивность помощи различается;

● способ оценивания различается;

● скорость обратной связи различается;

● участники могут различаться по мотивации;

● размер групп 15–20 человек мал для большого числа метрик;

● рандомизация не описана;

● предтест не встроен в схему;

● экспертное оценивание не ослеплено;

● нет анализа мощности;

● нет критериев исключения;

● нет правил обработки пропусков.

Наиболее реалистичный дизайн

При небольшой выборке — перекрёстный дизайн AB/BA.

Все участники — сильные студенты, отобранные по одному предтесту.

● Половина сначала решает семейство задач A с ИИДА, затем семейство B без ИИДА.

● Вторая половина сначала B с ИИДА, затем A без ИИДА.

● Семейства задач предварительно выравниваются по сложности.

● Финальный перенос проверяется на новой задаче без ИИДА.

● Оценивание выполняют эксперты, не знающие условия выполнения.

Так каждый студент частично становится собственной контрольной точкой.

15\. Следы и evidence

Необходимый минимальный журнал:

● ID и версия задания;

● параметры и seed датасета;

● версия генератора;

● версия модели;

● промпт оценщика;

● старт и конец попытки;

● версии кода;

● ошибки исполнения;

● полученные результаты;

● текстовая интерпретация;

● самооценка и уверенность;

● оценка ИИДА;

● показанные подсказки;

● следующая попытка;

● итоговая экспертная оценка;

● решение преподавателя о переопределении машинной оценки.

Без этого будет финальная работа, оценка и ощущение, что что-то полезное происходило. Само обучение к моменту отчёта уже покинет помещение.

16\. Риски подмены

В текущей таблице рисков отражены технические сбои, эффект новизны и различия исходного уровня. Почти отсутствуют образовательные риски.

Критические риски:

● ИИДА начинает формулировать интерпретацию вместо студента;

● подсказка содержит фактический ход решения;

● студент учится угадывать предпочтения оценщика;

● машинная оценка превращается в цель вместо качества анализа;

● студент многократно перегенерирует задания до удобного;

● сильный студент обходит интерфейс и решает задачу внешней моделью;

● система закрепляет ошибочное решение;

● LLM оценивает гладкость текста как глубину;

● преподаватель перестаёт видеть, какие ошибки стали массовыми;

● автоматизация снижает содержательный контакт с сильными студентами.

Необходимы:

● лестница подсказок;

● задержка перед первой подсказкой;

● обязательная собственная попытка;

● разделение диагностики и ответа;

● скрытые проверочные задания;

● перенос без ИИДА;

● текстовое обоснование;

● возможность апелляции;

● выборочная проверка преподавателем;

● устная защита части решений.

17\. Пользовательский сценарий

Полноценный сценарий в материалах отсутствует.

Нужен storyboard примерно такого типа:

1\. студент получает задачу; 2. фиксирует первичную гипотезу; 3. оценивает собственную уверенность; 4. создаёт первую версию решения; 5. детерминированный контур проверяет исполнение; 6. семантический оценщик применяет рубрику; 7. политика подсказок выбирает вопрос; 8. студент отвечает или исправляет решение; 9. после заданного числа циклов случай завершается либо передаётся

преподавателю; 10. студент выполняет краткую рефлексию; 11. система обновляет профиль освоения; 12. преподаватель видит сводку и спорные случаи.

18\. Реализуемость

В текущей постановке требуется одновременно разработать:

● Jupyter-интеграцию;

● генератор датасетов;

● генератор заданий;

● валидатор;

● песочницу исполнения;

● LLM-оценщик;

● механизм подсказок;

● модель студента;

● адаптивный планировщик;

● логирование;

● преподавательский интерфейс;

● Moodle-интеграцию;

● возможно, Modeus-интеграцию.

Это крупная система.

Слайды 14 и 22 расходятся:

● в архитектуре указан Modeus;

● в описании среды — Moodle.

Возможно, нужны обе системы, но тогда требуется объяснить функцию каждой.

19\. Граница пилота

Сейчас граница отсутствует. Предлагаемая минимальная версия:

● одна тема;

● одно семейство исследовательских задач;

● один генератор датасетов;

● одна рубрика;

● один LLM-оценщик;

● три уровня подсказок;

● 12–20 сильных студентов;

● 2–3 недели;

● Jupyter Notebook;

● без интеграции с Moodle и Modeus;

● выгрузка результатов в простой журнал;

● обязательная экспертная перепроверка всех машинных оценок.

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

20\. Следующий ход

Проекту не требуется сейчас «дописать ТЗ». Ему требуется разделить программу на четыре проверки и выбрать первую.

6\. Четыре эксперимента вместо одного

Эксперимент А. Валидность генератора

Вопрос: Может ли система создавать разнообразные, корректные и сопоставимые

по сложности задания?

Проверяется экспертами без студентов.

Артефакты:

● 30–50 сгенерированных задач;

● автоматическая валидация;

● экспертная оценка;

● процент брака;

● карта типов ошибок.

Эксперимент B. Валидность машинного оценивания

Вопрос: Насколько оценка ИИДА совпадает с оценками преподавателей?

Нужны:

● набор решений разного качества;

● слепая оценка 2–3 экспертов;

● оценка ИИДА;

● анализ расхождений;

● порог передачи преподавателю.

Эксперимент C. Образовательный эффект

Вопрос: Улучшает ли дозированная обратная связь действие студента и перенос?

Здесь появляются студенты, предтест, одинаковые семейства задач, crossover или рандомизация и независимая итоговая проверка.

Эксперимент D. Экономия преподавательского времени

Вопрос: Сокращается ли общее время сопровождения с учётом настройки,

проверки эскалаций и исправления ошибок системы?

Это измеряется отдельно. Фраза «ИИДА берёт на себя 80% рутины» пока не имеет источника или расчёта.

7\. Суждение по модели Ульяны

Общая оценка

Авторы нашли содержательную образовательную ситуацию, однако слишком быстро перешли от наблюдаемой проблемы к крупному продукту.

В текущем виде невозможно понять:

● какую именно способность студента формирует ИИДА;

● за счёт какого образовательного механизма;

● какое действие остаётся за студентом;

● по какому следу будет установлено изменение;

● что именно опровергнет гипотезу.

Главный вопрос Ульяны

Что сильный студент после работы с ИИДА сможет самостоятельно сделать на новом материале лучше, чем он делал до неё?

Не «получит больше задач», не «будет вовлечён», не «быстрее выполнит». Какое предметное действие изменится?

Обязательные рекомендации

1\. Выбрать одну способность. 2. Выделить один тип задач. 3. Описать механизм подсказки. 4. Определить самостоятельную итоговую пробу без ИИДА. 5. Создать экспертную рубрику до разработки продукта. 6. Сравнивать сопоставимых сильных студентов. 7. Отделить образовательный эффект от удобства интерфейса и эффекта

новизны.

Вердикт Ульяны

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

8\. Суждение по модели Тимура

Общая оценка

Проект правильно нащупал переход от обычного чат-бота к ИИ, встроенному в предметную среду действия. Это сильнее, чем отдельный помощник в соседнем окне.

Но пока:

● тип ИИ определён неточно;

● автономность заявлена, но не спроектирована;

● архитектура сведена к стрелкам между преподавателем, студентом и ИИДА;

● технические и семантические функции смешаны;

● пилот сразу нагружен платформенными интеграциями.

Архитектурная классификация

Основной паттерн:

Adaptive Practice Environment + Assessment Pipeline + Jupyter Sandbox.

Это сочетание:

● генератора задач;

● исполняемой предметной среды;

● оценочного контура;

● тьюторского контура;

● адаптивной последовательности.

Это пока не мультиагентная система и не автономный симулятор в строгом смысле.

Минимальная архитектура

1\. Task Specification Layer — описание параметров задания. 2. Dataset Generator — детерминированная генерация данных. 3. Dataset Validator — проверка валидности. 4. Jupyter Workspace — среда действия студента. 5. Execution Checker — исполнение и технические тесты. 6. Semantic Evaluator — оценка объяснений по рубрике. 7. Hint Policy — выбор уровня подсказки. 8. Student State — фиксируемые признаки продвижения. 9. Trace Store — журнал действий и версий. 10. Human Review Queue — спорные случаи. 11. Teacher Dashboard — наблюдение и изменение правил.

Главный вопрос Тимура

Какое решение система принимает сама, на основании каких данных и куда уходит случай, когда уверенности недостаточно?

Обязательные рекомендации

1\. Перестать использовать «автономный» до описания автономного цикла. 2. Разделить генератор, валидатор, оценщик и тьютора. 3. Синтетические данные создавать кодом, LLM использовать для смысловых

частей. 4. Ввести human gate.

5\. Спроектировать лог следов до интерфейса. 6. Убрать Moodle/Modeus из первого пилота. 7. Подготовить критерии приёмки каждого модуля.

Вердикт Тимура

Архитектурная ставка сильная: ИИ помещается внутрь предметного рабочего пространства. Сейчас проект описывает желаемые функции, но ещё не систему. Лаборатории следует передавать один узкий контур, а не просьбу изготовить персонализированную образовательную платформу к февралю.

9\. Простой канвас

Поле Состояние Внутренний диагноз

Проблема Частично собрано Реальная ситуация есть, но

доказательная база неполна, а проблема заменяется автоматизацией

Гипотеза Слабо Перечень ожидаемых эффектов без

механизма; четыре гипотезы объединены

Тип ИИ Требует пересборки Назван автономным симулятором;

фактически адаптивная среда, генератор, оценщик и тьютор

Масштаб Завышен От локальной проблемы переход сразу к

платформе, LMS-интеграции и тиражированию

Архитектурный паттерн

Реконструируется нами

Adaptive Practice + Assessment Pipeline + Sandbox

Сценарий Практически

отсутствует

Есть роли и стрелки, нет последовательности действий, ветвлений и human gates

Следы Отсутствуют Метрики названы, но журнал событий и

доказательные артефакты не спроектированы

Риск подмены Частично Технические риски есть, образовательные

риски почти не рассмотрены

Запрос лаборатории

Преждевременный Содержание ТЗ не достигает уровня ТЗ; требуется ручной и полуавтоматический прототип

10\. Расширенный канвас

Большая модель

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

● общая группа продолжает базовую работу;

● сильные студенты получают индивидуализированную исследовательскую практику;

● преподаватель видит следы, вмешивается в содержательно сложных местах.

Это уже больше, чем генератор заданий.

Кейс-аналог

Прямой кейс-аналог в презентации отсутствует. Использованные исследования виртуальных студентов методологически удалены от продукта.

Нужны аналоги по следующим типам:

● adaptive coding practice;

● intelligent tutoring в исполняемой среде;

● автоматизированная проверка notebook;

● генерация синтетических аналитических задач;

● LLM feedback on open-ended data analysis.

Переменные мониторинга

Требуется разделить:

Образовательные

● перенос;

● качество интерпретации;

● самостоятельность;

● число и тип ошибок;

● калибровка самооценки.

Машинные

● процент невалидных задач;

● согласие с экспертами;

● доля эскалаций;

● ложноположительные оценки;

● утечка решения в подсказках;

● стоимость одного цикла;

● задержка ответа.

Организационные

● преподавательское время;

● время настройки;

● время разбора исключений;

● число студентов, реально использующих продвинутый трек.

Потенциал масштабирования

Масштабируемый объект здесь — не готовый ИИДА целиком, а компоненты:

● формат спецификации задачи;

● генератор контролируемых датасетов;

● схема логирования;

● рубрика смысловой оценки;

● политика подсказок;

● Jupyter-интеграция;

● очередь человеческой проверки.

Место в портфеле ТюмГУ

Проект стоит размещать в кластере:

ИИ-среды предметной практики / адаптивные тренажёры / assessment pipeline / работа с исполняемыми артефактами.

Он может дать общую инфраструктуру для:

● статистики;

● программирования;

● эконометрики;

● вычислительной химии;

● инженерного моделирования;

● других дисциплин, где результат можно частично проверить исполнением и тестами.

Радикальная версия

Радикальный вариант — непрерывная исследовательская студия, где ИИ:

● строит индивидуальный фронтир задач;

● отслеживает освоенные способы;

● формирует новые датасеты;

● собирает траекторию решений;

● соединяет студентов со схожими или дополнительными стратегиями;

● передаёт преподавателю только случаи, требующие экспертного вмешательства.

Это возможная большая модель. Строить её в первом семестре не требуется.

11\. Послайдовая дефектовка

Слайд 1

Нормальная идентификация проекта и авторов. Название сообщает только факт внедрения, но не образовательную ставку.

Слайд 2

Сильное начальное противоречие. При этом «фундаментальное противоречие современной системы ВО» слишком велико для предъявленных данных. Лучше фиксировать противоречие конкретного типа курса.

Слайд 3

Главная ошибка: решение названо центральной проблемой. «Бесконечный поток» — маркетинговая формула без необходимости и критерия.

Слайд 4

Список функций назван архитектурой. «Симулятор» и «автономный» не объяснены. Не показаны данные, состояние, цикл и решение системы.

Слайд 5

Общее позиционирование. Дублирует функции, образовательного механизма не добавляет.

Слайды 6–7

Повторяют, что продукт соответствует предметной специфике. Слайд 7 объявляет «подтверждённую эффективность», хотя используемые исследования относятся к другой ситуации.

Слайды 8–9

Самая полезная эмпирическая часть, но отсутствует паспорт исследования. График «затруднение/интерес» методически неинтерпретируем. Из данных можно вывести гипотезу о проблеме, но пока нельзя считать её доказанной.

Слайд 10

Источники подобраны по слову «симуляция», а не по механизму проекта. Нужна новая теоретическая база.

Слайды 11–13

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

Слайд 14

Схема ролей есть, архитектуры нет. Не показаны Jupyter, хранилище, генератор, валидатор, оценщик, логи и human gate. Возникает Modeus, который позже превращается в Moodle.

Слайды 15–16

H0/H1 формально присутствуют, но объединяют много исходов. Подгипотезы вводят дополнительные переменные. Формулировка «высокий показатель успеваемости» не операционализирована.

Слайд 17

Польза понятна. «80% рутины» не обоснованы. В заголовке заявлена польза вузу, в содержании присутствуют только студент и преподаватель.

Слайд 18

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

Слайд 19

Четыре этапа перечислены, но нет:

● содержания этапов;

● результатов;

● критериев перехода;

● ответственных;

● дат внутри периода.

Слайд 20

Метрики резко сокращаются до удовлетворённости, освоения и времени преподавателя, что расходится с гипотезами слайда 15.

Слайд 21

Отчёт заранее должен подтвердить положительный результат. Исследование должно допускать отрицательный вывод. Готовность к тиражированию не следует из одного пилота.

Слайд 22

Это паспорт продукта, не ТЗ.

Слайд 23

Критический дефект контрольного дизайна: группы различаются по исходному уровню. Часть ячеек контрольной группы заполнена неполно.

Слайд 24

Условия различаются сразу по пяти параметрам. Причинный эффект ИИДА выделить нельзя.

Слайд 25

Экспериментальная и контрольная группы выполняют разное содержание. Сравнение становится недействительным.

Слайд 26

Хорошая попытка карты рисков. Не хватает рисков подмены, приватности, академической честности, стоимости, дрейфа модели, безопасности исполнения кода и качества оценивания. Некоторые меры слишком общие: «предусмотреть восстановление данных» пока является пожеланием к будущему предусмотрению.

Слайд 27

Сформулирован образ желаемого будущего, но отсутствуют критерии, по которым будет установлено, что вакуум исчез, преподаватель высвободился, а решение стало масштабируемым.

Слайд 28

Функцию выполняет.

Сопроводительный RTF

Полностью повторяет позитивную продуктовую историю и усиливает слова «инновационный», «трансформация», «масштабируемая платформа». Для работы над проектом он не нужен. Для внешней аннотации его следует переписать после сборки эксперимента.

12\. Что мы должны двигать на семинаре

Главный ход — не разбирать все недочёты подряд. Это внутренний материал.

На семинаре требуется поставить один разворачивающий вопрос:

Какую из четырёх гипотез ИИДА вы хотите проверить первой: качество генерации заданий, качество машинной оценки, образовательный эффект подсказок или экономию времени преподавателя?

После ответа можно двигать проект к минимальному пилоту.

Наиболее продуктивная первая последовательность:

1\. проверить генератор и валидатор без студентов; 2. откалибровать машинную оценку на размеченных работах;

3\. провести узкий образовательный crossover-пилот; 4. после этого измерять реальную экономию времени.

13\. Рекомендуемый следующий пакет артефактов

Обязательный пакет по модели Ульяны

1\. Одна формула образовательного результата. 2. Одно семейство задач. 3. Рубрика оценки. 4. Описание самостоятельной итоговой пробы. 5. Протокол сопоставимого эксперимента. 6. Формула условия опровержения гипотезы.

Обязательный пакет по модели Тимура

1\. Компонентная архитектура ИИДА. 2. Сценарий из 10–12 шагов. 3. Разделение детерминированных и LLM-функций. 4. Схема логирования. 5. Human gates и очередь эскалаций. 6. Граница первой версии. 7. Критерии технической приёмки.

Первый инженерный артефакт

Не Jupyter-плагин и не Moodle-интеграция.

Первый артефакт:

ручной вертикальный прототип одного полного цикла на одной задаче: генерация датасета → решение → автоматические тесты → LLM-оценка по рубрике → подсказка → повторная попытка → экспертная сверка.

Когда этот цикл пройдёт десять разных решений и не развалится, можно обсуждать интерфейс.

14\. Итоговый внутренний статус

Контур Статус

Практическая актуальность Сильная

Собственный интерес авторов

Сильный, требует конкретизации

Доказательство проблемы Частичное

Образовательный механизм Не собран

Гипотеза Перегружена и неразделена

Экспериментальный дизайн Критически дефектный

Роль ИИ Функции названы, тип не различён

Архитектура Эскиз ролей

Следы и измерения Не спроектированы

Риски Частично проработаны

Техническое задание Отсутствует

Готовность к разработке Только узкий прототип

Потенциал проекта Высокий

Место в портфеле Адаптивная предметная среда и оценочный

pipeline

Главный внутренний вывод:

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