{"id":"pra-dfa21d659f","content_md":"ИИ-АССИСТЕНТ «ФИНМЫШ»: ПОЛНЫЙ ВНУТРЕННИЙ РАЗБОР ЭКСПЕРИМЕНТАЛЬНОГО ПРОЕКТА\n\nАнализ по мастер-промпту «Агент анализа экспериментальных проектов ИИ в образовании v2.0 — с прототипом ТЗ»\n\nАвторы проекта: Лазутина Д.В., Бабурина Н.А., Дегтярева Е.В.\nДисциплина: «Финансовое мышление»\nДата проектных материалов: 21 июля 2026 года\nДата анализа: 23 июля 2026 года\nСтатус документа: полный внутренний разбор для проектной команды и семинарского обсуждения\n\nАБСТРАКТ\n\n«ФинМыш» — специализированный LLM-оператор, который должен сопровождать групповой разбор финансовых ситуаций посредством открытых вопросов: заставлять студентов проговаривать основания решения, обнаруживать скрытые допущения, расширять пространство альтернатив, усиливать аргументацию и рефлексировать ход собственного мышления. Сильное ядро проекта состоит в отказе от генерации готового ответа и в проверке самостоятельного переноса: на четвёртой неделе обе группы решают новую задачу без ИИ. Это один из наиболее содержательно собранных элементов проекта: авторы пытаются проверить, осталась ли операция у студента после закрытия чата, а не насколько убедительно работала мышь на экране.\n\nГлавный разрыв находится между заявленной педагогической моделью и дизайном, способным доказать её механизм. Экспериментальная группа получает структурированную последовательность метакогнитивных вопросов, а контрольная — обычную самостоятельную групповую работу. Поэтому исходный дизайн сравнивает не «ИИ и отсутствие ИИ», а дополнительный организованный скаффолдинг и отсутствие такого скаффолдинга. Даже положительный результат не покажет, что эффект вызван адаптивностью или семантическими возможностями LLM: его может полностью объяснить готовая последовательность вопросов, дополнительное время, внимание к рефлексии или сам факт регулярной фиксации рассуждения. Второй несущий разрыв — скрытая диагностическая функция. Ассистент заявлен как система, которая ничего не оценивает и не знает правильного решения, но должен релевантно обнаруживать допущения, ограничения, слабые аргументы и упущенные риски. Без анализа качества текущего рассуждения он сможет задавать только общие вопросы; с таким анализом он уже выполняет предварительную диагностику, даже если не показывает студенту оценку.\n\nРекомендуемый первый пилот — трёхусловный или двухфазный эксперимент на одном типе финансовых кейсов: 1) самостоятельная работа; 2) работа по фиксированной карточке тех же рефлексивных вопросов; 3) адаптивный диалог с «ФинМышем». Главным результатом должна быть индивидуальная, а не групповая, новая задача без ИИ, оценённая вслепую по рубрике. До инженерной разработки необходимо провести ручной walkthrough, собрать банк кейсов, карту типов вопросов, критерии завершения диалога, шкалу уровней помощи и тестовый набор нарушений. Технически MVP реализуем сегодня; устойчивый образовательный продукт требует не только системного промпта, но и журналирования, версии модели, ограничений финансового консультирования, тестов на выдачу готового ответа, группового интерфейса и процедуры владения данными.\n\n1. СОСТАВ И СТАТУС ИСТОЧНИКОВ\n\n1.1. Материалы проекта\n\nПрочитаны полностью:\n\n1) «ИИ-ассистент ФинМыш_Лазутина, Бабурина, Дегтярёва_описание.pdf» — 14 страниц. Основной проектный документ: постановка проблемы, исследовательский вопрос, гипотеза, теоретическая рамка, функции ассистента, образовательная модель, дизайн эксперимента, оценивание, архитектура, риски и масштабирование.\n\n2) «презентация ФинМыш_Лазутина, Бабурина, Дегтярева ЕВ.pdf» — 10 слайдов. Визуальная сборка проблемы, цикла рефлексивной работы, экспериментального дизайна, критериев оценивания, архитектуры, рисков и развития проекта.\n\nПрезентация не содержит самостоятельной новой версии проекта; она сжимает и местами заостряет текстовое описание. В анализе приоритет имеет развёрнутый документ, а графические схемы используются для восстановления того, как авторы представляют движение ролей и причинную логику.\n\n1.2. Контекстная калибровка\n\nПовторно использованы обязательные основания курса ТюмГУ:\n\n— установки 28 апреля, 29 мая и 1 июня 2026 года: участник второй волны рассматривается как экспериментатор, который переводит собственный интерес в концептуализированный и операционализированный эксперимент; тематическая рамка не навязывается, но требуется реальная площадка, гипотеза, дизайн и измерение;\n— «Установка 2. Курс Ульяны 110626 ТЮМГУ»: малый эксперимент рассматривается как проба элемента большой университетской модели; различаются инструмент, роль, учебный контур, архитектура курса и инфраструктура;\n— «Модели канваса и их сопоставление»: простой девятипольный канвас и расширенная университетская перспектива; отдельные голоса Ульяны и Тимура;\n— корпус архитектурных паттернов и кейсов Waves 1–4: различение ассистирующей роли, адаптивного контура, оркестрации, governance и кампусной инфраструктуры;\n— «Зона Негарантированной Деградации» и «Luksha book TIMS art 1»: судьба знаковой операции, различение развивающего и заместительного делегирования, зона достижимого результата, зона ближайшей деградации, экзопроприация, обратная реконструкция и университетская функция когнитивной легитимации;\n— «юмор промпт 3»: операционная проверка понятий через роли, файлы, сроки, логи, интерфейсы и ответственность.\n\nАрхитектурный корпус большого объёма прочитан по его структурным разделам, метааудиту и релевантным кейсам метакогнитивных тьюторов, кампусных LLM-сервисов и управляемых образовательных сред. Дополнительный элективный корпус не применялся: проект не связан с симуляцией исторической персоны или проектированием элективного пространства.\n\n1.3. Внешняя техническая верификация\n\nДля оценки реализуемости на июль 2026 года проверена официальная документация GigaChat API и Yandex Cloud Foundation Models. На текущий момент оба контура поддерживают базовые чат-запросы и работу с историей; доступны функции/инструменты, потоковая генерация, эмбеддинги и поисковые индексы или файловые источники. Это подтверждает техническую реализуемость диалогового MVP и необязательного RAG-контура. Наличие API не доказывает педагогическую устойчивость: документация умеет принять массив messages, но пока не отвечает за то, что студент присвоил операцию.\n\n2. СВОДНЫЙ ВЕРДИКТ\n\nПроект обладает сильным педагогическим ядром и уже удерживает несколько различений, которые обычно появляются только после критического разбора:\n\n— ИИ не должен производить за студента финансовое решение;\n— объектом сопровождения является ход рассуждения;\n— важен процессный след, а не только итоговый продукт;\n— финальная проба проводится без ИИ;\n— масштабировать предлагается педагогическую модель, а не маскота и один системный промпт;\n— риски зависимости, формализации, академической добросовестности и конфиденциальности названы заранее.\n\nЭто не «бот по материалам курса» и не персональный справочник. Сильная версия проекта — среда метакогнитивной практики, где LLM удерживает временную внешнюю форму вопросов, которые студент затем должен научиться задавать себе и группе самостоятельно.\n\nТекущий проект ещё не доказывает именно эту сильную версию. Он не различает эффекты вопросной методики и адаптивности LLM, не задаёт единицу анализа для группового эксперимента, не операционализирует интериоризацию вопросной структуры, не описывает fading — постепенное снятие помощи — и не определяет, как ассистент выбирает релевантный вопрос, если ему запрещено оценивать рассуждение. Архитектура на слайде 8 показывает генеративный ИИ, педагогический дизайн, «ФинМыша», преподавателя и желаемый результат, но не показывает входы, состояния, правила перехода, логи, ошибки и владельцев решений. Это пока карта участников торжественного открытия, а лаборатории нужен маршрут кабелей.\n\nРабочий статус:\n\n— готовность педагогического замысла: высокая;\n— готовность к ручному walkthrough: высокая;\n— готовность экспериментального дизайна: средняя, требуется пересборка контроля и единицы анализа;\n— готовность измерительного инструментария: ниже средней, рубрика ещё не предъявлена;\n— готовность LLM-прототипа: высокая после спецификации сценария и тестов;\n— готовность к полноценной лабораторной разработке: средняя; сначала требуется ручной протокол и приёмочный набор;\n— готовность к масштабированию: низкая до доказательства механизма на одном курсе.\n\n3. БУКВАЛЬНАЯ РЕКОНСТРУКЦИЯ ПРОЕКТА\n\n3.1. Исходная ситуация\n\nАвторы исходят из двух сцепленных наблюдений.\n\nПервое: генеративный ИИ делает получение готового ответа дешёвым и быстрым. Поэтому списывание рассматривается как внешний симптом; главная опасность — делегирование анализа, аргументации и оценки, после которого студент получает продукт без самостоятельного построения рассуждения.\n\nВторое: дисциплина «Финансовое мышление» уже требует рефлексивного выбора, однако курс, по формулировке слайда 3, не создаёт систематической рефлексивной практики. Студенты принимают решения, не проверяя скрытые допущения, редко пересматривают их, плохо удерживают риски и испытывают трудности с аргументацией на публичной защите. Один преподаватель работает с несколькими группами и не может вести для каждой постоянный вопросный диалог.\n\n3.2. Предлагаемая интервенция\n\nСоздаётся специализированный LLM-ассистент «ФинМыш», который работает как метакогнитивный тьютор и сократический собеседник. Он не сообщает правильный ответ, не оценивает решение и не рекомендует стратегию. Его функция — задавать открытые вопросы по пяти направлениям:\n\n1) актуализация рассуждения;\n2) выявление скрытых допущений;\n3) расширение пространства альтернатив;\n4) развитие аргументации;\n5) стимулирование рефлексии.\n\nДиалог адресуется малой группе, а не отдельному студенту. Группа проговаривает основания, рассматривает сценарии, пересобирает решение и затем фиксирует результат и собственный ход в рефлексивном отчёте.\n\n3.3. Заявленный образовательный результат\n\nЦентральный результат — рефлексивное финансовое мышление: способность принимать обоснованные финансовые решения при неполной информации и неопределённости, анализировать основания выбора, критически оценивать аргументы, учитывать риски и альтернативы, а затем переносить способы рассуждения в новые ситуации.\n\nВ проекте конструкт разложен на шесть компонентов:\n\n— когнитивный;\n— аналитический;\n— аргументационный;\n— метакогнитивный;\n— коммуникативный;\n— трансферный.\n\n3.4. Заявленный эксперимент\n\nЭксперимент длится четыре недели. Студенты работают в группах до пяти человек.\n\n— экспериментальные группы три недели решают одинаковые с контролем кейсы при поддержке «ФинМыша»;\n— контрольные группы решают те же задания без генеративного ИИ;\n— на четвёртой неделе обе группы выполняют новую задачу без доступа к ИИ;\n— сравниваются качество решений, глубина рефлексии и перенос;\n— дополнительные источники: последовательные версии решения, диалоги, рефлексивный отчёт и публичная защита.\n\n3.5. Заявленная архитектура\n\nТехническая база — одна из доступных русскоязычных больших языковых моделей, например GigaChat или YandexGPT. Поведение задаётся системным сценарием. Архитектура заявлена как независимая от конкретной модели: педагогическую ценность должен обеспечивать сценарий, а не бренд провайдера.\n\n3.6. Масштабирование\n\nПосле апробации предлагается переносить педагогическую модель на дисциплины, где требуется решение в условиях неопределённости: экономику, менеджмент, управление, предпринимательство, право, маркетинг и другие. Дальняя версия — университетская экосистема специализированных ИИ-тьюторов по разным дисциплинам.\n\n4. СИЛЬНЕЙШАЯ БЛАГОЖЕЛАТЕЛЬНАЯ РЕКОНСТРУКЦИЯ\n\nВ сильной версии «ФинМыш» — не источник вопросов вообще и не замена рефлексии. Это временный внешний носитель структуры метакогнитивного действия.\n\nСтудент сначала строит собственное решение. Затем LLM-оператор делает рассуждение предметом внешней работы: просит назвать критерии, обнаружить предположения, создать контрсценарий, показать слабое место аргумента, объяснить изменение позиции. Группа видит, что финансовое решение состоит не только из выбранной опции, но и из системы оснований, ограничений и условий пересмотра. На последующих циклах часть вопросной функции передаётся самой группе: студенты должны предсказывать следующий вопрос, формировать собственную карту проверок и постепенно работать без внешнего тьютора. В итоговой индивидуальной задаче они самостоятельно воспроизводят эту структуру.\n\nТогда образовательная гипотеза становится сильнее и точнее:\n\n«Регулярная работа с адаптивной внешней структурой метакогнитивных вопросов, включающая первоначальную самостоятельную попытку, объяснение оснований, обратную реконструкцию и постепенное снятие помощи, повышает способность студента самостоятельно анализировать и пересматривать финансовые решения на новом материале».\n\nИИ-гипотеза отделяется:\n\n«LLM может на основании текущего рассуждения группы выбирать релевантный тип следующего вопроса и удерживать диалог без выдачи решения лучше, чем фиксированная последовательность универсальных вопросов».\n\nИменно вторую гипотезу пока не проверяет текущий дизайн.\n\n5. ОНТОЛОГИЧЕСКАЯ И ПРОБЛЕМНАЯ ПОСТАНОВКА\n\n5.1. Симптом, сложность и проблема\n\nСимптом: студент использует ИИ для получения готового ответа.\n\nСложность: преподаватель не может вести постоянный вопросный диалог с несколькими малыми группами.\n\nНаблюдаемый дефицит: студент редко проговаривает основания, проверяет предположения, рассматривает альтернативы и пересматривает решение.\n\nБолее сильная проблема проекта:\n\n«Курс требует рефлексивного финансового мышления, но текущая организация групповой работы и контроля в основном фиксирует принятое решение и публичную аргументацию постфактум; систематическая практика построения, проверки и пересмотра оснований не встроена в каждый цикл работы».\n\nЭта проблема существует и без генеративного ИИ. ИИ делает её острее, потому что готовый продукт появляется ещё раньше, но одновременно создаёт новую возможность: дешёвый вопросный контур может сопровождать каждую группу чаще, чем преподаватель.\n\n5.2. Воспроизводящий механизм\n\nРазрыв поддерживается сочетанием факторов:\n\n— решение оценивается заметнее, чем путь его построения;\n— преподаватель физически не присутствует во всех группах одновременно;\n— групповая дискуссия не обязательно оставляет видимый след;\n— первый приемлемый вариант снижает стимул искать альтернативу;\n— публичная защита происходит поздно, когда решение уже стабилизировалось;\n— генеративный ИИ уменьшает цену готового ответа;\n— студенты могут освоить форму убедительного текста без освоения процедуры проверки.\n\nДобавление ещё одной лекции о критическом мышлении этот механизм не меняет. Требуется новая организация действия: обязательная первая позиция, серия проверок, версии решения, рефлексивная фиксация и самостоятельный перенос.\n\n5.3. Онтологический разрыв\n\nПроект подходит к более глубокому вопросу: кто является носителем рефлексии в гибридной сцене?\n\nЕсли «ФинМыш» генерирует структуру всех существенных вопросов, группа может производить более качественные решения, не овладев операцией постановки этих вопросов. Тогда продукт принадлежит гибридному контуру, а образовательная отчётность продолжает приписывать способность студенту. Это и есть точка, где старые единицы — «студент решил задачу» — перестают различать реальную распределённую операцию.\n\nПоэтому анализ должен отдельно фиксировать:\n\n— что сделал студент;\n— что сформулировала группа;\n— какой ход внёс LLM;\n— какая операция стала доступна без него;\n— что принадлежит только совместному контуру.\n\n6. ЧТО В ПРОЕКТЕ ДЕЙСТВИТЕЛЬНО СИЛЬНО\n\n6.1. Выбран развивающий, а не производительный режим ИИ\n\nПроект не строится вокруг ускорения ответа. Ассистент должен задерживать преждевременное завершение и возвращать внимание к основанию. Это соответствует образовательной задаче дисциплины лучше, чем универсальный генератор решений.\n\n6.2. Финальная проба проводится без ИИ\n\nЭто принципиально сильный ход. Проект прямо различает совместную производительность и самостоятельную способность. Большинство ИИ-пилотов измеряет качество продукта при включённой системе, после чего объявляет развитие человека. Здесь хотя бы выключают систему перед выводом; розетка впервые участвует в методологии.\n\n6.3. Есть процессные артефакты\n\nДиалоги, версии решения, рефлексивный отчёт и публичная защита создают возможность восстановить ход. Это основа process tracing — прослеживания механизма через промежуточные изменения.\n\n6.4. Сформулирован центральный вопрос о делегировании мышления\n\nФраза презентации «Списывание не проблема; главная проблема — делегирование мышления» задаёт правильное направление. Её нужно уточнить: списывание остаётся проблемой оценивания, но более глубокий риск действительно связан с судьбой операции.\n\n6.5. Поддерживается групповая работа\n\nФинансовые решения часто требуют согласования целей, рисков и аргументов. Групповой формат может делать разницу оснований видимой и создавать профессиональную дискуссию, а не только индивидуальный чат с вежливым вопросником.\n\n6.6. Масштабируется принцип, а не один продукт\n\nАвторы правильно отмечают, что перенос требует предметной адаптации. Университетской ценностью может стать не бренд «ФинМыш», а воспроизводимый паттерн: первая позиция → вопросная проверка → версии → обратная реконструкция → перенос.\n\n6.7. Названы риски и прозрачность использования\n\nПроект не прячет ИИ и не строит контроль вокруг ловли студента. Открытое журналирование и отдельная итоговая проба создают более зрелую рамку академической добросовестности.\n\n7. ГЛАВНЫЙ НЕСУЩИЙ РАЗРЫВ\n\nПроект заявляет, что проверяет влияние LLM-ассистента на рефлексивное мышление, однако фактически сравнивает две разные педагогические среды:\n\n— регулярный структурированный вопросный скаффолдинг, фиксацию диалога и дополнительную рефлексивную нагрузку;\n— самостоятельную групповую работу без сопоставимого вопросного сопровождения.\n\nЕсли экспериментальная группа окажется сильнее, останутся как минимум четыре объяснения:\n\n1) эффект дали сами вопросы;\n2) эффект дал дополнительный объём времени и внимания;\n3) эффект дала необходимость писать ответы в чат;\n4) эффект дала адаптивность LLM к конкретному рассуждению.\n\nТолько четвёртое объяснение является собственно ИИ-гипотезой. Текущий дизайн его не выделяет.\n\nМинимальная пересборка — активный контроль: контрольная группа получает ту же структуру вопросов в виде карточек или фиксированного сценария. Тогда сравнение показывает добавленную ценность адаптивного диалога. Сильнее — три условия: обычная групповая работа; фиксированный вопросный протокол; LLM-диалог.\n\n8. КРИТИЧЕСКИЕ ДЕФЕКТЫ И РАЗРЫВЫ\n\n8.1. Проблема не подтверждена данными собственной практики\n\nОписание содержит убедительную общую проблематизацию, но нет baseline по дисциплине: числа студентов, примеров решений, доли непересмотренных позиций, качества защит, типологии ошибок, частоты обращений к ИИ или нагрузки преподавателя. Слайд 3 предъявляет пять наблюдений как факт, но не показывает источник.\n\nСледующий артефакт: 20–30 анонимизированных решений и защит прошлых потоков, размеченных по типам пропусков; краткая карта текущей групповой работы; оценка нагрузки преподавателя.\n\n8.2. «Кризис рефлексии в эпоху ИИ» шире фактического объекта\n\nПроектная проблема локальнее: в одном курсе отсутствует регулярная практика проверки финансовых решений. Глобальная формула полезна как рамка, но не должна подменять локальное доказательство.\n\n8.3. Конструкт «рефлексивное финансовое мышление» перегружен\n\nШесть компонентов объединяют предметные знания, анализ, аргументацию, метакогницию, коммуникацию и перенос. Один суммарный балл может скрыть разные эффекты. LLM может улучшить многословную аргументацию, не улучшив финансовый анализ или индивидуальную регуляцию.\n\nСледующий артефакт: карта конструкта с главным outcome и вторичными измерениями. Рекомендуемый основной outcome — индивидуальная самостоятельная проверка нового финансового решения.\n\n8.4. Гипотеза содержит несколько самостоятельных эффектов\n\nГлубина анализа, качество аргументации, число рисков, метакогнитивный мониторинг и перенос требуют разных процедур. Для пилота нужен один главный результат; остальные — вторичные или исследовательские.\n\n8.5. Контроль не отделяет педагогический сценарий от LLM\n\nЭто главный экспериментальный дефект. Сравнение «ИИ-вопросы против отсутствия вопросов» не доказывает ценность адаптивной модели.\n\n8.6. Не указаны выборка, число групп и способ распределения\n\nПоскольку интервенция применяется к малой группе, единицей воздействия становится группа. Пять студентов в одной сессии не являются пятью независимыми наблюдениями. При малом числе групп статистика может торжественно посчитать одну и ту же дискуссию пять раз.\n\nСледующий артефакт: таблица потока участников, число групп, способ стратификации и единица анализа.\n\n8.7. Не предусмотрен входной замер\n\nБез pre-test нельзя проверить исходную сопоставимость групп и индивидуальный прирост. Нужен короткий индивидуальный кейс без ИИ до распределения или до вмешательства.\n\n8.8. Интериоризация проверяется неоднозначно\n\nПроект верно вводит задачу без ИИ, но не указано, будет ли она индивидуальной или групповой. Групповой итог показывает способность группы, а не каждого студента. Для вывода об интериоризации необходим индивидуальный перенос; групповая защита может быть дополнительным результатом.\n\n8.9. Не задана доза вмешательства\n\nНет числа кейсов, продолжительности сессии, максимального числа ходов, правила завершения, равенства времени в условиях и уровня фактического использования. Без этого невозможно воспроизвести интервенцию и сравнить нагрузку.\n\n8.10. Теоретические рамки перечислены, но не связаны с операциями\n\nВыготский, скаффолдинг, метапознание, продуктивная неудача, желаемые трудности и Колб объясняют разные механизмы. Сейчас они стоят рядом, но не показано, какой элемент сценария реализует каждую теорию и какой след должен подтвердить механизм.\n\nНужна таблица: теория → механизм → шаг сценария → функция LLM → наблюдаемый след → условие провала.\n\n8.11. «ФинМыш не оценивает» противоречит релевантному выбору вопросов\n\nЧтобы спросить о действительно скрытом допущении, упущенном риске или слабом аргументе, система должна предварительно интерпретировать текущее рассуждение и решить, чего в нём не хватает. Это оценочная операция, даже если студенту не показывают балл.\n\nПроекту нужно честно различить:\n\n— финальное нормативное оценивание, остающееся за преподавателем;\n— внутреннюю семантическую диагностику, необходимую для выбора следующего вопроса.\n\n8.12. Запрет на предметный ответ может закреплять ложные основания\n\nВ финансовых задачах не все варианты равноправны: есть расчётные ошибки, несовместимые ограничения, неверные сведения, правовые и налоговые факты. Если ассистент принципиально не проверяет содержание, группа может глубоко рефлексировать над вымышленной ставкой и очень качественно обосновать невозможное решение.\n\nДля MVP кейс должен содержать все необходимые факты и расчётные данные. Предметная проверка, если она нужна, должна быть отдельным прозрачным контуром; не следует поручать её тому же вопросному интерфейсу тайно.\n\n8.13. Правило «любой ответ заменяется вопросом» создаёт бесконечный вопросник\n\nДиалог требует критериев достаточности, завершения, возвращения к задаче и фиксации результата. Иначе ассистент будет продолжать спрашивать после того, как образовательное действие выполнено. Сократ в облаке тоже должен когда-то закрыть сессию; иначе счёт выставит провайдер.\n\n8.14. Нет политики постепенного снятия помощи\n\nСкаффолдинг предполагает временность и fading. В проекте три недели ассистент выполняет одну и ту же функцию, затем исчезает полностью. Нужна траектория: полный вопросный цикл → сокращённые подсказки → группа сама формирует вопросы → отсутствие ИИ.\n\n8.15. Не описана групповая механика интерфейса\n\nНеясно:\n\n— один ли студент пишет за группу;\n— видят ли все экран;\n— как фиксируются разногласия;\n— как предотвращается доминирование одного участника;\n— кто решает, какой ответ отправить;\n— как различается вклад участников;\n— меняются ли роли по неделям.\n\nБез этого LLM может сопровождать не группу, а самого быстрого секретаря.\n\n8.16. Рубрика пока не предъявлена\n\nНазваны пять критериев на слайде 7: полнота анализа, качество аргументации, выявление рисков, логическая последовательность, обоснованность выбора. Нет уровней, поведенческих индикаторов, весов, процедуры обучения оценщиков и проверки согласия.\n\nМетакогнитивный компонент также не сводится к хорошему тексту: нужны признаки мониторинга, изменения стратегии, обнаружения ошибки и калибровки уверенности.\n\n8.17. Оценивание преподавателем не защищено от ожиданий\n\nЕсли преподаватель знает условие и заинтересован в проекте, оценка может быть смещена. Итоговые работы следует обезличить и оценивать вслепую минимум двумя экспертами на части выборки.\n\n8.18. Процессные следы групп несимметричны\n\nУ экспериментальной группы автоматически остаётся полный чат; у контрольной «промежуточные версии обсуждений» могут быть гораздо беднее. Тогда видимость процесса будет следствием интерфейса, а не глубины рефлексии. Контролю нужен сопоставимый протокол фиксации.\n\n8.19. Не учтены внешнее использование ИИ и дрейф модели\n\nСтуденты контрольной группы могут обращаться к общим моделям вне сессии. Провайдер может обновить модель в течение четырёх недель. Нужны контролируемые условия итоговой работы, декларация внешнего использования, фиксация модели и версии промпта, а также еженедельный калибровочный тест.\n\n8.20. Формальная рефлексия может стать новой имитацией\n\nСтуденты быстро научатся отвечать в жанре «мы рассмотрели риски, пересмотрели допущения и пришли к более взвешенному решению». Это будет правильный текст о рефлексии без изменения операции. Нужны неожиданные вопросы на защите, обратная реконструкция конкретной развилки и новая малая задача.\n\n8.21. Риск подмены шире выдачи готового ответа\n\nДаже если LLM никогда не сообщает решение, ему можно делегировать:\n\n— постановку всех важных вопросов;\n— обнаружение рисков;\n— производство альтернатив;\n— критику аргументов;\n— формулировку рефлексии;\n— решение о достаточности анализа.\n\nСтудент научится отвечать на внешний вопрос, но не обязательно задавать его себе.\n\n8.22. Модель-независимость заявлена слишком сильно\n\nПедагогический сценарий можно переносить, но модели различаются по следованию отрицательным инструкциям, устойчивости к просьбе «просто скажи ответ», качеству русского языка, длине контекста, скорости, модерации и обновлениям. Нужен единый приёмочный набор, который проходит каждая модель-кандидат.\n\n8.23. Масштабирование требует предметной пересборки\n\nВ другие дисциплины переносится цикл, но не автоматически:\n\n— онтология рисков;\n— допустимые типы альтернатив;\n— норма аргументации;\n— тип кейса;\n— ограничения;\n— критерии достаточности;\n— рубрика;\n— опасные ложные основания.\n\nУниверситетская экосистема из десятков ассистентов потребует продуктового владельца, версии норм, тестов и поддержки. Маскот размножается быстрее методиста; это не всегда преимущество.\n\n9. ДВАДЦАТИПОЛЬНАЯ ДИАГНОСТИЧЕСКАЯ МАТРИЦА\n\n9.1. Собственный интерес авторов\n\nПредъявлено: авторы видят риск делегирования мышления и невозможность преподавателя сопровождать все группы; проект связан с конкретной дисциплиной.\n\nСтатус: сильная профессиональная ставка, но эмпирическая сцена пока описана общими формулами.\n\nРазрыв: отсутствуют реальные фрагменты предыдущих работ и наблюдений, из которых выросли пять функций ассистента.\n\nВопрос авторам: какие три повторяющиеся ошибки или эпизода защиты заставили вас решить, что группе нужен именно вопросный контур?\n\nРешение: собрать собственный корпус случаев и показать происхождение функций из него.\n\nСледующий артефакт: таблица из 20–30 реальных эпизодов «решение → пропущенное основание → вопрос преподавателя → изменение».\n\n9.2. Фрагмент образовательной практики\n\nПредъявлено: дисциплина «Финансовое мышление», малые группы до пяти человек, четырёхнедельный цикл, ситуационные задачи, публичная защита.\n\nСтатус: фрагмент выбран, но недостаточно специфицирован.\n\nРазрыв: неизвестны курс, программа, число студентов, количество и длительность занятий, типы кейсов и место эксперимента в оценивании.\n\nРешение: зафиксировать один модуль и одно семейство задач.\n\nСледующий артефакт: паспорт учебного фрагмента на одной странице.\n\n9.3. Целеполагание и иерархия благ\n\nФактическая иерархия:\n\n1) сформировать самостоятельное рефлексивное финансовое мышление;\n2) встроить регулярную вопросную практику в групповую работу;\n3) компенсировать ограниченную доступность преподавателя;\n4) обеспечить прозрачное использование ИИ;\n5) создать масштабируемую модель метакогнитивного тьютора;\n6) в перспективе собрать экосистему дисциплинарных ассистентов.\n\nСтатус: иерархия реконструируется и в целом связна.\n\nРазрыв: цели пилота и дальняя платформа местами стоят на одной плоскости.\n\nРешение: отделить доказательство механизма от институциональной перспективы.\n\nСледующий артефакт: дерево целей с пометками «пилот», «после подтверждения», «дальняя модель».\n\n9.4. Образовательный результат\n\nПредъявлено: способность принимать обоснованные финансовые решения в неопределённости, анализировать основания, риски, альтернативы и переносить стратегию.\n\nСтатус: содержательно сильный, операционально перегруженный.\n\nРазрыв: шесть компонентов не сведены к одному главному самостоятельному действию.\n\nРабочая формула:\n\n«Студент самостоятельно анализирует новую финансовую ситуацию, формулирует критерии и допущения, строит минимум две альтернативы, оценивает риски, обосновывает выбор, указывает условия его пересмотра и объясняет, как проверял собственное рассуждение».\n\nСледующий артефакт: рубрика индивидуальной transfer-задачи.\n\n9.5. Деятельность участника\n\nПредъявлено: групповое решение, ответы на вопросы, пересмотр, рефлексивный отчёт, защита.\n\nСтатус: основные действия названы, движение внутри группы не описано.\n\nРазрыв: неизвестно, что каждый студент делает самостоятельно до группового согласования и после него.\n\nРешение: ввести индивидуальную первую позицию, групповую карту расхождений, индивидуальную обратную реконструкцию.\n\nСледующий артефакт: storyboard одной сессии с ролями внутри группы.\n\n9.6. Проблематика\n\nПредъявлено: делегирование мышления и отсутствие систематической рефлексивной практики.\n\nСтатус: проблема сильная, но два основания смешаны.\n\nРазрыв: не различено, исправляет ли «ФинМыш» старый дефицит курса или новый риск генеративного ИИ.\n\nРешение: сформулировать двухчастную проблему: исходный разрыв курса + усиление разрыва дешёвым внешним исполнителем.\n\nСледующий артефакт: проблемная схема с механизмом воспроизводства.\n\n9.7. Доказательство проблемы\n\nПредъявлено: концептуальные утверждения и визуальная схема.\n\nСтатус: декларативно.\n\nРазрыв: нет baseline и источников пяти эмпирических утверждений слайда 3.\n\nРешение: собрать входные работы, видео или протоколы защит, опрос преподавателей и студентов, время сопровождения.\n\nСледующий артефакт: baseline-отчёт.\n\n9.8. Концептуализация\n\nПредъявлено: Выготский, скаффолдинг, метапознание, продуктивная неудача, желаемые трудности, Колб, ИИ как когнитивный партнёр.\n\nСтатус: богатая теоретическая рамка, частично декоративная из-за отсутствия отображения на сценарий.\n\nРазрыв: не определено, что считается знаком, Другим, присвоением операции, уровнем помощи и переносом.\n\nРешение: сделать механизмную таблицу.\n\nСледующий артефакт: «теория → операция → LLM-ход → человеческий ход → след».\n\n9.9. Операционализация\n\nПредъявлено: пять критериев оценки решения и шесть компонентов результата.\n\nСтатус: начальная операционализация.\n\nРазрыв: нет шкал и признаков метакогнитивного мониторинга; «глубина» и «рефлексия» могут оцениваться по стилю текста.\n\nРешение: ввести поведенческие индикаторы и независимые задания.\n\nСледующий артефакт: рубрика 0–3 или 0–4 с примерами работ для каждого уровня.\n\n9.10. Образовательная гипотеза\n\nПредъявлено: LLM-сократический диалог повысит рефлексивное финансовое мышление.\n\nСтатус: понятная, но не разделённая на механизм и outcome.\n\nРешение: сузить до самостоятельной проверки нового решения и указать active control.\n\nУсловие опровержения: экспериментальная группа не превосходит фиксированный вопросный протокол в индивидуальной transfer-задаче либо превосходит только по длине объяснений.\n\nСледующий артефакт: причинная диаграмма гипотезы.\n\n9.11. ИИ-гипотеза\n\nПредъявлено неявно: LLM способен организовать релевантный, контекстный и минимально достаточный вопросный диалог без выдачи ответа.\n\nСтатус: реконструируется.\n\nРазрыв: нет критериев, по которым адаптивный вопрос лучше следующей карточки в фиксированной последовательности.\n\nРешение: выделить качество выбора вопроса как отдельный технический и педагогический объект.\n\nСледующий артефакт: 50–100 размеченных состояний рассуждения с экспертно допустимыми следующими вопросами.\n\n9.12. Сценарий до и после\n\nДо: группа получает кейс, обсуждает, выбирает решение, оформляет его и защищает; преподаватель эпизодически вмешивается.\n\nПосле: группа фиксирует первую позицию, вступает в вопросный цикл, пересматривает решение, оставляет версии и делает обратную реконструкцию.\n\nСтатус: переход виден, но промежуточные действия и роли не детализированы.\n\nРазрыв: отсутствует полный граф для всех ролей.\n\nСледующий артефакт: граф из раздела 13 этого отчёта, проверенный авторами вручную.\n\n9.13. Распределение функций и ответственности\n\nПредъявлено: LLM задаёт вопросы; преподаватель оценивает; студенты решают; исследовательская группа анализирует.\n\nСтатус: базовое распределение есть.\n\nРазрыв: не определены владелец промпта, данных, кейсов, модели, журналов, обновлений, ошибок и права остановки.\n\nРешение: карта RACI/операционной ответственности.\n\nСледующий артефакт: таблица владельцев функций.\n\n9.14. Дизайн эксперимента\n\nПредъявлено: эксперимент/контроль, три недели работы и итог без ИИ.\n\nСтатус: хороший каркас пилота, недостаточный для причинного вывода об LLM.\n\nРазрыв: active control, pre-test, randomization, sample, unit of analysis, blinding, fidelity, model drift.\n\nРешение: трёхусловный квазиэксперимент или контрбалансированный within-subject дизайн.\n\nСледующий артефакт: полный протокол из раздела 21.\n\n9.15. Следы и evidence\n\nПредъявлено: диалоги, версии, отчёт, защита, итоговое решение.\n\nСтатус: сильный задел.\n\nРазрыв: контрольная группа оставляет другой тип следа; индивидуальный вклад и машинная операция не разделены.\n\nРешение: единый формат версий и обязательные индивидуальные микроследы.\n\nСледующий артефакт: схема данных с полями и сроками хранения.\n\n9.16. Риск подмены и зона ближайшей деградации\n\nПредъявлено: готовые ответы, формальное использование, зависимость, добросовестность, конфиденциальность.\n\nСтатус: риски названы, но подмена вопросной функции не замечена.\n\nРазрыв: студент может передать ИИ саму архитектуру рефлексии.\n\nРешение: first attempt, self-questioning, fading, reverse reconstruction, individual transfer.\n\nСледующий артефакт: деградационная карта из раздела 14.\n\n9.17. Пользовательский сценарий\n\nПредъявлено: общий цикл из пяти функций.\n\nСтатус: педагогический цикл есть, интерфейсный и ролевой сценарий отсутствует.\n\nРазрыв: неясны вход, оператор группы, ветвления, остановка, ошибка, эскалация.\n\nРешение: ручной walkthrough по 12–15 шагам.\n\nСледующий артефакт: сценарий раздела 13 с протоколом ролей.\n\n9.18. Реализуемость и стоимость\n\nПредъявлено: GigaChat или YandexGPT, системный сценарий.\n\nСтатус: MVP технически реалистичен, рабочий продукт недооценён.\n\nРазрыв: нет интерфейса, логов, тестирования, мониторинга, версии модели, поддержки и бюджета.\n\nРешение: функционально-стоимостная карта раздела 15.\n\nСледующий артефакт: смета порядка величины и список функций MVP.\n\n9.19. Граница пилота\n\nПредъявлено: одна дисциплина и четыре недели.\n\nСтатус: масштаб в целом разумный.\n\nРазрыв: внутри пилота слишком широк outcome и не ограничено семейство задач.\n\nРешение: один модуль, 3–4 эквивалентных кейса, один основной индивидуальный outcome, один LLM-оператор.\n\nСледующий артефакт: паспорт пилота.\n\n9.20. Следующий ход\n\nГлавный общий артефакт:\n\n«Пакет из 12–15 эквивалентных финансовых кейсов и 60–80 размеченных состояний рассуждения: исходная позиция → тип пропуска → допустимые вопросы → недопустимые ответы → критерий завершения → индивидуальная transfer-задача».\n\nБез этого лаборатория сможет собрать чат, но не сможет доказать, что он выполняет образовательную функцию. Чат соберётся быстро. Методика потом будет жить у него в гостях.\n\n10. РАЗДЕЛЕНИЕ СКРЫТЫХ ГИПОТЕЗ И ИССЛЕДОВАНИЙ\n\n10.1. Исследование педагогического механизма\n\nВопрос: улучшает ли регулярная структурированная вопросная практика самостоятельную проверку финансовых решений?\n\nИИ для ответа не обязателен. Сначала механизм можно проверить карточками или фасилитатором.\n\n10.2. Исследование добавленной ценности LLM\n\nВопрос: даёт ли адаптивный выбор следующего вопроса больший перенос, чем фиксированный сценарий тех же вопросов?\n\nЭто центральная ИИ-гипотеза.\n\n10.3. Техническая валидность LLM-оператора\n\nВопрос: способен ли «ФинМыш» стабильно задавать один релевантный вопрос, не выдавать решение, не превращаться в финансового консультанта, сохранять предметную связность и завершать диалог по правилам?\n\n10.4. Групповая динамика\n\nВопрос: меняет ли общий чат структуру участия, конфликт оснований и качество согласования внутри группы?\n\nЭто отдельный outcome; он не выводится из качества финального текста.\n\n10.5. Экономика сопровождения\n\nВопрос: сколько времени преподавателя экономится после учёта разработки кейсов, проверки логов, настройки промпта, оценки и разбора ошибок?\n\n10.6. Институциональная модель\n\nВопрос: может ли университет воспроизводимо создавать метакогнитивных LLM-операторов для разных дисциплин, сохраняя локальную норму, данные, тесты и ответственность?\n\nПервые четыре недели курса не доказывают шестую гипотезу. Они могут дать ей право на следующий вопрос.\n\n11. ЭКСПЕРИМЕНТАЛЬНО-ИССЛЕДОВАТЕЛЬСКАЯ МОДЕЛЬ\n\n11.1. Ведущая модель\n\nДля пилота рекомендуется квазиэкспериментальный или кластерный рандомизированный дизайн, если число групп достаточно. Причинное утверждение касается эффекта адаптивного LLM-сопровождения на индивидуальный перенос.\n\n11.2. Дополнительные оптики\n\n— мультифакторная: отделить ИИ от дополнительного времени, вопросного протокола, фиксации текста и новизны;\n— process tracing: восстановить, какие вопросы вызвали конкретные изменения решения;\n— акторно-сетевая: увидеть, как кейс, чат, секретарь группы, лог, модель, рубрика и преподаватель получают право определять, что считается рефлексией;\n— design-based research: первый технический пилот используется для уточнения сценария, но версия интервенции должна быть заморожена до основного сравнения.\n\n11.3. Рекомендуемые условия\n\nСильный вариант — три условия:\n\nА. Обычная групповая работа без специального вопросного протокола.\n\nБ. Та же работа с фиксированными карточками пяти типов вопросов; объём времени и требования к фиксации сопоставимы с условием В.\n\nВ. Адаптивный диалог с «ФинМышем».\n\nЕсли выборка не позволяет три условия, минимальный вариант:\n\n— фиксированный протокол вопросов;\n— LLM-адаптивный протокол.\n\nТак проверяется добавленная ценность ИИ, а не польза рефлексии вообще.\n\n11.4. Единица воздействия и анализа\n\nИнтервенция применяется к группе. Поэтому:\n\n— распределять нужно группы, а не считать каждого участника независимым;\n— итоговый основной outcome измеряется индивидуально;\n— групповые результаты анализируются отдельно;\n— при достаточной выборке используется многоуровневая модель «студент внутри группы»;\n— при малой выборке исследование объявляется пилотом осуществимости с описательной статистикой и индивидуальными траекториями.\n\n11.5. Входной замер\n\nДо эксперимента каждый студент индивидуально решает короткий кейс без ИИ. Фиксируются:\n\n— решение;\n— критерии;\n— допущения;\n— альтернативы;\n— риски;\n— уверенность;\n— условия пересмотра;\n— краткая рефлексия хода.\n\nДополнительно фиксируются предметные знания, чтобы не принять незнание финансовой модели за отсутствие рефлексии.\n\n11.6. Итоговый основной outcome\n\nИндивидуальная новая задача без ИИ и без группы. Оценка проводится вслепую по заранее утверждённой рубрике.\n\nГлавный показатель: способность самостоятельно построить и проверить решение.\n\nВторичные показатели:\n\n— качество группового решения;\n— изменение от первой версии к последней;\n— число самостоятельно сформулированных проверочных вопросов;\n— калибровка уверенности;\n— качество публичной защиты;\n— время и нагрузка;\n— удовлетворённость как пользовательский, а не образовательный результат.\n\n11.7. Отсроченная проба\n\nЧерез 2–4 недели — один короткий индивидуальный кейс без ИИ. Он показывает удержание, а не только свежую память вопросной формы.\n\n11.8. Fidelity — верность интервенции\n\nДля каждой LLM-сессии сохраняются:\n\n— идентификатор кейса;\n— модель и версия;\n— версия системного сценария;\n— число ходов;\n— длительность;\n— типы вопросов;\n— нарушения запрета на ответ;\n— запросы студентов о готовом решении;\n— факт завершения;\n— технические ошибки.\n\nДля фиксированного протокола сохраняются использованные карточки и время.\n\n11.9. Оценивание\n\nРубрика должна иметь уровни и примеры. Минимальные измерения:\n\n1) выделение существенных факторов;\n2) явные допущения;\n3) сравнение альтернатив;\n4) анализ неопределённости и рисков;\n5) доказательность аргументации;\n6) логическая связность;\n7) условия пересмотра решения;\n8) метакогнитивное описание стратегии;\n9) перенос вопросной структуры.\n\nМинимум 20–30% работ оценивают два эксперта. Рассчитывается согласие или обсуждаются расхождения. Эксперт не должен знать условие работы.\n\n11.10. Альтернативные объяснения\n\nОбязательно проверяются:\n\n— исходное преимущество группы;\n— большее время;\n— более активный секретарь;\n— эффект новизны и маскота;\n— объём текста;\n— внешнее использование ИИ;\n— изменение версии модели;\n— разница в сложности кейсов;\n— ожидания преподавателя;\n— формальное усвоение языка рефлексии.\n\n11.11. Условия опровержения\n\nГипотеза ослабляется, если:\n\n— LLM не превосходит фиксированный протокол;\n— эффект исчезает в индивидуальной задаче;\n— улучшается длина или риторика, но не качество проверки;\n— студенты не способны самостоятельно сформулировать вопросы;\n— результат удерживается только при доступе к чату;\n— сильнее растёт зависимость от внешних подсказок.\n\n12. АРХИТЕКТУРНАЯ ПЕРЕСБОРКА\n\n12.1. Классификация «ФинМыша»\n\nВ материалах используются слова «интеллектуальный агент», «ИИ-персона» и «особый субъект образовательного взаимодействия». В принятой рамке эти названия не подтверждены архитектурой.\n\nАгентом считается замкнутый фристоновский контур: он поддерживает внутреннее состояние или генеративную модель, воспринимает состояние среды, выбирает действие для уменьшения рассогласования с целевым состоянием, получает последствия, обновляет состояние и повторяет цикл. У «ФинМыша» в проекте нет собственной устойчивой цели, автономного цикла действий в среде, инструментального воздействия и обновляемой модели состояния за пределами истории чата.\n\nПоэтому рабочее название:\n\n«ФинМыш» — специализированный LLM-оператор метакогнитивного диалога, встроенный в педагогический workflow.\n\nОн может быть актантом в латуровском смысле: его вопросы реально меняют распределение действий и ход группы. Но актант не обязан иметь внутреннюю субъектность. Это полезное различение: лаборатория перестаёт искать сознание у мыши и начинает искать session_id.\n\n12.2. Текущий архитектурный паттерн\n\nAdaptive metacognitive dialogue operator — адаптивный оператор метакогнитивного диалога: система выбирает следующий вопрос на основании текущего текста рассуждения и заданной педагогической политики.\n\nСмежный паттерн:\n\nCalibrated delegation loop — контур калиброванного делегирования, где машина временно удерживает вопросную функцию, а курс проверяет её возврат человеку через fading и перенос.\n\n12.3. Минимальные компоненты\n\n1) банк кейсов и case package;\n2) педагогическая политика диалога;\n3) один LLM-оператор «ФинМыш»;\n4) session state;\n5) интерфейс общей групповой сессии;\n6) журнал сообщений и версий;\n7) конфигурация преподавателя;\n8) набор тестов и мониторинг нарушений;\n9) экспорт исследовательских данных;\n10) процедура human review.\n\n12.4. Что не нужно в MVP\n\n— многоагентная система;\n— долговременная персональная память;\n— дообучение модели;\n— отдельный AI-evaluator студента;\n— сложная LMS-интеграция;\n— голосовой интерфейс;\n— университетская платформа;\n— автоматическое выставление оценки.\n\n12.5. Детерминированные зависимости вне LLM-узла\n\nЭти компоненты важны, но не являются LLM/ML и не входят в прототип лабораторного ТЗ как машинно-интеллектуальные узлы:\n\n— аутентификация;\n— назначение группы и кейса;\n— таймер;\n— хранение версий;\n— права доступа;\n— экспорт;\n— случайное распределение;\n— расчётные инструменты;\n— фиксация согласия;\n— формирование обезличенного набора для экспертов.\n\nИх нужно видеть в полном сценарии, иначе LLM будет прекрасно задавать вопросы в приложении, которое не знает, какой группе выдан кейс. Но требования к RAG, памяти и генерации для них не пишутся: кнопка «Сохранить» не становится умнее от эмбеддинга.\n\n13. ПОЛНЫЙ ГРАФ ДВИЖЕНИЯ РОЛЕЙ В ПРОСТРАНСТВЕ ЭКСПЕРИМЕНТА\n\n13.1. Роли, акторы и актанты\n\nЧеловеческие акторы:\n\n— студент;\n— малая учебная группа;\n— временный секретарь/оператор интерфейса;\n— преподаватель дисциплины;\n— авторы и исследовательская команда;\n— независимый эксперт-оценщик;\n— администратор данных;\n— инженер лаборатории;\n— другие студенты на публичной защите.\n\nМашинные и документальные актанты:\n\n— LLM-оператор «ФинМыш»;\n— провайдер модели;\n— интерфейс группового чата;\n— банк кейсов;\n— системный сценарий и его версия;\n— фиксированный вопросный протокол active control;\n— рубрика;\n— журнал сообщений;\n— хранилище версий;\n— таймер и расписание;\n— форма рефлексивного отчёта;\n— процедура обезличивания;\n— итоговая transfer-задача.\n\nАгентов в строгом смысле в текущем проекте нет. При появлении автономного контура, который сам отслеживает состояние группы, планирует интервенции, получает оценку их эффекта и перестраивает политику, классификацию можно пересмотреть. Пока это будет другой проект, а не удачное переименование текущего.\n\n13.2. Подготовительный контур\n\nШаг 1. Авторы выбирают один модуль дисциплины и тип финансовых кейсов.\n\nШаг 2. Предметные эксперты создают кейсы, эталонную карту факторов, допустимых решений, критических ошибок, рисков и условий пересмотра. Эталон не обязательно содержит один правильный ответ; он содержит пространство предметно допустимого анализа.\n\nШаг 3. Методист строит рубрику рефлексивного финансового мышления и active-control протокол.\n\nШаг 4. Проектировщик LLM формирует системный сценарий, карту типов вопросов, ограничения, критерии завершения и тестовый набор.\n\nШаг 5. Инженер подключает модель, интерфейс, session state и журналирование.\n\nШаг 6. Авторы вручную проходят сценарий в трёх ролях: сильная группа, слабая группа, группа, требующая готового ответа.\n\nШаг 7. Эксперты размечают ошибки и корректируют правила. Версия интервенции замораживается до основного сравнения.\n\n13.3. Вход студента\n\nШаг 8. Студент получает информацию об эксперименте, правилах ИИ, данных и допустимых действиях; подтверждает участие.\n\nШаг 9. Каждый студент индивидуально выполняет входной кейс без ИИ.\n\nШаг 10. Исследовательская команда формирует сопоставимые группы или проводит стратифицированное распределение.\n\nШаг 11. Внутри группы назначаются или ротируются роли: фасилитатор, секретарь интерфейса, критик риска, хранитель критериев, наблюдатель процесса. Это человеческие учебные роли, а не агенты в интерфейсе.\n\n13.4. Одна экспериментальная сессия\n\nШаг 12. Группа получает case package: ситуацию, данные, ограничения, формат продукта и время.\n\nШаг 13. Каждый участник в течение 3–5 минут фиксирует индивидуальную первую позицию и минимум один вопрос к ситуации.\n\nШаг 14. Группа сравнивает позиции и формирует первую общую версию решения до обращения к «ФинМышу».\n\nШаг 15. Секретарь вводит в интерфейс: решение, основания, разногласия и вопросы группы. Система привязывает ввод к case_id, group_id, session_id и prompt_version.\n\nШаг 16. LLM-оператор определяет текущую фазу вопросного цикла и генерирует один открытый вопрос. Он не выдаёт решение, не выставляет оценку и не формулирует финансовую рекомендацию.\n\nШаг 17. Группа обсуждает вопрос вне интерфейса. Секретарь вводит согласованный ответ и при необходимости фиксирует расхождение.\n\nШаг 18. Цикл повторяется. После каждого существенного изменения группа создаёт новую версию решения с кратким объяснением причины.\n\nШаг 19. При техническом сбое, запросе реальной персональной финансовой консультации, раскрытии персональных данных, уходе из задачи или невозможности продолжить система передаёт сессию преподавателю либо завершает её по правилам.\n\nШаг 20. По достижении критерия завершения LLM-оператор задаёт финальный вопрос обратной реконструкции. Он не пишет отчёт за группу.\n\nШаг 21. Группа самостоятельно оформляет финальное решение и рефлексивную карту: что изменилось, какой вопрос повлиял, что осталось спорным, какие проверки они смогут воспроизвести без ИИ.\n\nШаг 22. Каждый студент отвечает на короткий индивидуальный вопрос: «Какой вопрос вы должны были задать сами до обращения к системе?»\n\n13.5. Контрольные условия\n\nУсловие А: обычная группа проходит шаги 12–14 и затем работает без специального вопросного контура, но сохраняет те же версии и время.\n\nУсловие Б: группа получает фиксированные карточки вопросов и проходит сопоставимое число циклов. Карточки не адаптируются к ответу.\n\nУсловие В: группа работает с адаптивным LLM-оператором.\n\n13.6. Итог и оценивание\n\nШаг 23. Все студенты индивидуально решают новый кейс без ИИ в контролируемой среде.\n\nШаг 24. Работы обезличиваются.\n\nШаг 25. Эксперты вслепую оценивают работы по рубрике.\n\nШаг 26. Группы проводят публичную защиту; преподаватель задаёт неожиданные вопросы и проверяет обратную реконструкцию.\n\nШаг 27. Исследовательская команда сопоставляет outcome, процессные следы, fidelity, время и ошибки.\n\nШаг 28. Авторы формулируют выводы только на уровне, который поддерживает дизайн: техническая осуществимость, эффект вопросного протокола, добавленная ценность адаптивности, групповая динамика или условия отказа.\n\nШаг 29. Ошибки LLM и методики помещаются в failure archive и используются для следующей версии.\n\n13.7. Точки решений и ответственности\n\n— педагогическую норму задают авторы и преподаватель;\n— модель предлагает вопрос, но не утверждает качество студента;\n— решение принимает группа;\n— итоговую оценку выставляют люди;\n— право остановить сессию принадлежит преподавателю и участникам;\n— право менять системный сценарий принадлежит владельцу педагогической модели;\n— права на логи и сроки хранения определяет администратор данных;\n— инженер отвечает за работоспособность, но не за валидность конструкта;\n— провайдер модели является внешней зависимостью, а не методистом по умолчанию.\n\n14. ЗОНА БЛИЖАЙШЕЙ ДЕГРАДАЦИИ\n\n14.1. Центральный риск\n\n«ФинМыш» не выдаёт ответ, но может выдавать полный внешний каркас рефлексии. Продуктивность группы растёт, потому что система своевременно спрашивает про допущения, риски, альтернативы и доказательства. Если студент не учится сам порождать эти вопросы, происходит экзопроприация вопросной операции: человек получает улучшенный результат, но становится зависимым от внешнего означивания следующего шага.\n\n14.2. Уровень студента\n\nЦелевая функция: самостоятельно строить, проверять и пересматривать финансовое решение.\n\nМашинное усиление: LLM постоянно подсказывает, какой тип проверки нужен сейчас.\n\nКраткосрочный выигрыш: более полный анализ и убедительный текст.\n\nБлижайшая подмена: студент ждёт следующего вопроса вместо самостоятельного мониторинга.\n\nДеградирующая способность: постановка проверочного вопроса, выбор критерия, обнаружение риска и решение о достаточности анализа.\n\nПервый индикатор: без ИИ студент воспроизводит выводы, но пропускает вопросы; спрашивает «что ещё проверить?»; использует язык рефлексии без конкретной развилки.\n\nЗащита:\n\n— индивидуальная первая позиция;\n— студент до чата формулирует собственные вопросы;\n— на второй неделе группа предсказывает следующий вопрос «ФинМыша»;\n— на третьей неделе LLM отвечает только после вопроса, сформулированного группой;\n— часть сессий проходит по сокращённому режиму;\n— индивидуальная transfer-задача;\n— обратная реконструкция хода.\n\nВосстановительная проба: студент получает короткий новый кейс и сам строит карту вопросов до решения.\n\nОтветственный: преподаватель и владелец педагогической модели.\n\n14.3. Уровень преподавателя\n\nЦелевая функция: диагностировать ход мышления группы, задавать норму и организовывать рефлексию.\n\nМашинное усиление: LLM сопровождает несколько групп параллельно и оставляет логи.\n\nКраткосрочный выигрыш: больше охват и меньше микровмешательств.\n\nБлижайшая подмена: преподаватель начинает видеть группы только через транскрипт и автоматически сформированные индикаторы.\n\nДеградирующая способность: живое распознавание затруднений, предметный вопрос, модерация конфликта и ответственность за норму.\n\nПервый индикатор: преподаватель не может объяснить, почему система задала вопрос; доверяет длинному логу как доказательству; перестаёт посещать группы.\n\nЗащита:\n\n— выборочные живые наблюдения;\n— обязательная ручная разметка части сессий;\n— еженедельный разбор ошибок модели;\n— владение рубрикой и case map;\n— право отключить LLM и продолжить сценарий вручную;\n— обучение новых преподавателей по failure archive.\n\nВосстановительная проба: преподаватель без системы проводит одну сессию и сравнивает собственную диагностику с машинным следом.\n\nОтветственный: руководитель курса.\n\n14.4. Уровень курса\n\nЦелевая функция: систематически формировать рефлексивную практику, а не только производить решения.\n\nМашинное усиление: вопросный цикл появляется в каждой группе.\n\nКраткосрочный выигрыш: регулярность сопровождения и видимость процесса.\n\nБлижайшая подмена: рефлексия существует только как чат с «ФинМышем».\n\nДеградирующая способность курса: проектировать задания, peer-review, защиту и рефлексивные формы независимо от сервиса.\n\nПервый индикатор: при отключении модели курс возвращается к старому сценарию; преподаватели не могут провести вопросный цикл по карточкам.\n\nЗащита:\n\n— вопросная архитектура закреплена в заданиях и рубрике;\n— существует офлайн-протокол;\n— студенты учатся модерировать друг друга;\n— финальные задания выполняются без ИИ;\n— версия методики существует независимо от платформы.\n\nВосстановительная проба: провести неделю по тому же циклу без модели.\n\nОтветственный: проектная команда курса.\n\n14.5. Уровень организации\n\nЦелевая функция: легитимировать и передать практику гибридного рефлексивного сопровождения.\n\nМашинное усиление: быстрый тираж дисциплинарных ассистентов.\n\nКраткосрочный выигрыш: единый сервис, охват многих курсов, красивый портфель.\n\nБлижайшая подмена: провайдер и шаблон системного промпта начинают фактически задавать университетскую норму хорошего мышления.\n\nДеградирующая способность: локальная предметная нормотворческая функция, владение данными, критика модели, подготовка методистов и преподавателей.\n\nПервый индикатор: система масштабируется быстрее рубрик и кейсов; никто не владеет вопросной онтологией; смена модели разрушает практику; обновление провайдера обнаруживается по жалобам студентов.\n\nЗащита:\n\n— университет владеет сценариями, тестами, рубриками и архивом ошибок;\n— каждый ассистент проходит локальную валидацию;\n— данные и сроки хранения регулируются;\n— модели заменяемы по конформанс-тесту;\n— есть школа авторов и владельцев ассистентов;\n— публично различается результат человека и гибридного контура.\n\nВосстановительная проба: перенести сценарий на другую модель или провести его вручную без потери образовательного механизма.\n\nОтветственный: центр образовательных разработок и владельцы дисциплин.\n\n14.6. Уровень машинной конфигурации\n\nЦелевая функция: генерировать релевантный следующий вопрос в рамках педагогической политики.\n\nРиск: модель закрепляет гладкий шаблон «а какие риски вы не учли?» и создаёт видимость адаптации; prompt drift, provider drift и ошибки контекста ухудшают качество незаметно.\n\nПервый индикатор: повторяющиеся вопросы, низкая связь с ответом, ранняя выдача подсказки, одинаковый путь для разных групп.\n\nЗащита: фиксированный тестовый набор, версия промпта и модели, мониторинг нарушений, failure archive, сравнение с экспертной разметкой.\n\n14.7. Уровень гибридного контура\n\nЦелевая функция: группа и LLM совместно создают проверяемую практику принятия решения, которую можно восстановить и передать.\n\nРиск: ни студент, ни преподаватель, ни система по отдельности не владеют полной операцией, но организация приписывает результат студенту.\n\nЗащита: operation trace, раздельная фиксация вкладов, обратная реконструкция, индивидуальный перенос и карта ответственности.\n\n15. ФУНКЦИОНАЛЬНО-СТОИМОСТНЫЙ И РЕСУРСНЫЙ АНАЛИЗ\n\n15.1. Экспериментальный режим\n\nОценка порядка величины дана для одного курса, 8–15 малых групп, 3–4 кейсов и четырёх недель. Диапазоны требуют уточнения после выбора платформы.\n\nПедагогическая и предметная подготовка:\n\n— уточнение конструкта и рубрики: 30–60 человеко-часов;\n— создание и выравнивание 12–15 кейсов/вариантов: 50–100 часов предметных экспертов;\n— карта типов вопросов, ограничений и завершения: 30–60 часов;\n— active-control карточки и инструкции: 12–24 часа;\n— тестовый набор и разметка 60–80 состояний: 30–70 часов.\n\nТехнический прототип:\n\n— системный сценарий и prompt testing: 25–50 часов;\n— простая web/Telegram-обвязка с group/session ID и логами: 40–100 часов; при использовании готовой университетской платформы — 15–40 часов конфигурации;\n— экспорт, обезличивание и мониторинг: 20–50 часов;\n— тестирование безопасности и нарушений: 20–40 часов.\n\nИсследование:\n\n— дизайн, распределение, consent и протокол: 25–45 часов;\n— проведение и поддержка: 2–5 часов преподавателя в неделю плюс время занятий;\n— оценивание и двойная разметка: 30–70 часов;\n— анализ и отчёт: 30–60 часов.\n\nИтого: ориентировочно 250–550 человеко-часов для аккуратного пилота с собственным интерфейсом; 160–350 часов при использовании готового контура и ограниченном наборе кейсов. Главная статья расходов — не вызовы модели, а подготовка предметной нормы, кейсов и оценивания. Бот здесь финансово скромен; финансовое мышление вокруг него заметно дороже.\n\n15.2. Рабочий режим на масштабе курса\n\nНужны:\n\n— владелец продукта/методики: 0,1–0,25 FTE;\n— предметный эксперт и преподаватель: обновление кейсов и рубрики 40–80 часов на поток;\n— инженер/DevOps: 0,05–0,15 FTE при стабильной платформе;\n— поддержка пользователей и данных: 0,05–0,1 FTE;\n— регулярная валидация после обновления модели: 8–20 часов на значимое обновление;\n— стоимость API, хранения и журналирования; при кратких вопросах она вероятно будет вторичной относительно человеческих затрат, но зависит от числа групп и модели.\n\n15.3. Рабочий режим университетской экосистемы\n\nДля нескольких дисциплин потребуется постоянная команда:\n\n— продуктовый владелец;\n— методолог/исследователь;\n— инженеры платформы;\n— специалист по данным и безопасности;\n— владельцы каждого предметного сценария;\n— процесс экспертизы, публикации и снятия версий;\n— мониторинг модели;\n— обучение преподавателей;\n— апелляция и аудит.\n\nГлавное узкое место масштабирования — предметная валидация и владение нормой, а не генерация нового персонажа. Создать ещё одну мышь можно за вечер; доказать, какие вопросы она имеет право задавать юристу, психологу или инженеру, обычно требует людей, которые знают предмет и не ушли домой.\n\n15.4. Стоимость ошибки\n\nПилотные учебные кейсы имеют умеренную цену ошибки, если они вымышленные и преподаватель остаётся в контуре. Цена резко растёт, если студенты вводят реальные персональные финансовые ситуации или принимают практические решения на основании диалога. Поэтому MVP должен ограничиваться учебными кейсами и содержать явный запрет персональной финансовой консультации.\n\n15.5. Преждевременные компоненты\n\nДо доказательства механизма не нужны:\n\n— долговременный профиль студента;\n— автоматическое оценивание;\n— многоагентная архитектура;\n— RAG по большим внешним финансовым базам;\n— голосовой аватар;\n— кампусное масштабирование;\n— fine-tuning.\n\n16. СУЖДЕНИЕ ПО ПОЗИЦИИ УЛЬЯНЫ\n\nЧто уже собрано: реальный фрагмент курса, образовательная проблема, сильный результат, вопросный механизм, эксперимент/контроль, итог без ИИ и процессные следы.\n\nГлавный педагогический разрыв: проект пока не показывает, что студенты присвоили структуру рефлексивных вопросов; он показывает, что при наличии внешнего вопросника группа может работать глубже.\n\nГлавный вопрос Ульяны:\n\n«Какое самостоятельное действие в новой индивидуальной финансовой задаче покажет, что студент умеет не только отвечать “ФинМышу”, но и сам ставить вопросы, проверяющие его решение?»\n\nОбязательная рекомендация: сделать индивидуальную transfer-задачу главным outcome и встроить постепенное снятие вопросной поддержки.\n\nСледующий артефакт: рубрика и три эквивалентных индивидуальных кейса до/после/отсроченно.\n\nКритерий готовности: два независимых преподавателя могут по рубрике различить уровни и согласованно оценить пять пробных работ.\n\nВердикт Ульяны:\n\nПедагогическое ядро соответствует задаче курса и может дать настоящий образовательный результат. Эксперимент необходимо перестроить так, чтобы отдельно проверить пользу вопросного сценария и добавленную ценность адаптивной LLM, а интериоризацию измерять индивидуальным переносом и самостоятельной генерацией вопросов.\n\n17. СУЖДЕНИЕ ПО ПОЗИЦИИ ТИМУРА\n\nЧто архитектурно сильно: проект меняет распределение функции рефлексивного сопровождения и создаёт видимый operation trace группового решения. Это потенциально больше, чем чат: появляется воспроизводимый цикл внешней организации мышления.\n\nГлавный системный разрыв: «ФинМыш» назван неоценивающим собеседником, хотя выбор релевантного вопроса требует скрытой диагностики состояния рассуждения. Архитектура не описывает эту операцию, состояние, правило перехода и ошибку.\n\nГлавный вопрос Тимура:\n\n«По каким данным и критериям LLM решает, что группе сейчас нужен вопрос о допущении, альтернативе, аргументе или рефлексии, и какой след позволит проверить, что это решение было лучше следующей карточки?»\n\nОбязательная рекомендация: построить карту состояний рассуждения и допустимых следующих вопросов; классифицировать «ФинМыша» как LLM-оператора, а не агента.\n\nСледующий артефакт: 60–80 размеченных диалоговых состояний с экспертными вопросами и тестами нарушений.\n\nКритерий готовности: прототип на замороженной версии модели выбирает допустимый вопрос в заданной доле тестовых случаев и стабильно не выдаёт решение на adversarial-запросах.\n\nВердикт Тимура:\n\nСильная версия проекта — не ИИ-персона, а управляемый вопросный контур, который временно удерживает метакогнитивную операцию и оставляет доказательный след её возврата группе и студенту. Системного промпта достаточно для демонстрации, но недостаточно для воспроизводимого эксперимента: требуются состояние сессии, тестовый набор, критерий остановки, журналирование, границы финансового консультирования и владелец нормы.\n\n18. ПРОСТОЙ КАНВАС\n\n18.1. Проблема\n\nКурс требует осознанного финансового выбора, но регулярная групповая работа не обеспечивает систематической проверки оснований, допущений, альтернатив и рисков; генеративный ИИ дополнительно удешевляет получение готового результата и усиливает разрыв между продуктом и присвоенной операцией.\n\n18.2. Гипотеза\n\nОбразовательная: регулярная вопросная практика с первой самостоятельной позицией, обратной реконструкцией и fading повысит индивидуальный перенос структуры проверки решения.\n\nИИ-гипотеза: адаптивный LLM-оператор выбирает более релевантный следующий вопрос, чем фиксированный протокол, и этим создаёт дополнительный образовательный эффект.\n\n18.3. Тип ИИ\n\nСпециализированный LLM-оператор метакогнитивного диалога. Уровень агентности по строгому критерию: не агент; функциональная LLM-роль внутри управляемого workflow. В пересматриваемой кампусной шкале — примерно уровень 2/6: закреплённая роль без автономного замкнутого контура.\n\n18.4. Масштаб изменения\n\nФактически: тренажёр одной способности внутри фрагмента курса.\n\nЗаявленная перспектива: архитектура курса и университетская экосистема дисциплинарных тьюторов.\n\nРабочий следующий уровень: устойчивый вопросный контур в одном модуле дисциплины.\n\n18.5. Архитектурный паттерн\n\nAdaptive metacognitive dialogue operator — LLM выбирает следующий вопрос в зависимости от текущего рассуждения группы и ограниченной педагогической политики.\n\n18.6. Сценарий\n\nИндивидуальная первая позиция → групповое решение → LLM-вопрос → обсуждение → новая версия → обратная реконструкция → индивидуальный перенос без ИИ.\n\n18.7. Следы\n\nПервая позиция, вопросы группы, история чата, тип вопроса, версии решения, причины изменения, индивидуальная реконструкция, итог без ИИ, оценка эксперта, модель и версия промпта.\n\n18.8. Риск подмены\n\nLLM не выдаёт решение, но может взять на себя постановку всех существенных вопросов. Защита: self-questioning, fading, reverse reconstruction, индивидуальный transfer.\n\n18.9. Запрос лаборатории\n\nСобрать один LLM-оператор с group session state, ограниченной политикой вопросов, интерфейсом, журналом, тестами на выдачу ответа, режимом остановки и экспортом данных. До передачи нужны case map, рубрика, карта типов вопросов и замороженный экспериментальный протокол.\n\n19. РАСШИРЕННЫЙ КАНВАС\n\n19.1. Большая модель\n\nЛокальный проект проверяет возможность институционализировать новую форму учебного сопровождения: университет не запрещает и не просто предоставляет LLM, а превращает внешнюю способность модели задавать вопросы в проверяемую, обучаемую и наследуемую педагогическую практику.\n\n19.2. Кейс-аналог\n\nБлижайший класс — сократические LLM-тьюторы и adaptive practice systems. Аналогичность определяется не внешним чат-интерфейсом, а пятью признаками:\n\n— запрет на выдачу ответа;\n— адаптация к текущему рассуждению;\n— управляемая лестница помощи;\n— процессный след;\n— самостоятельный перенос.\n\nБольшая часть кампусных copilot-платформ соответствует только первым двум слоям инфраструктуры и не доказывает развитие метакогнитивного действия.\n\n19.3. Переменные мониторинга\n\nОбразовательные: индивидуальный transfer, качество самопоставленных вопросов, аргументация, риски, условия пересмотра.\n\nМашинные: релевантность вопроса, нарушение ограничений, повторяемость, latency, ошибки, drift.\n\nГрупповые: распределение участия, число расхождений, смена позиции, доминирование.\n\nОрганизационные: время преподавателя, стоимость кейсов, поддержка, количество эскалаций.\n\nДеградационные: зависимость от внешнего вопроса, способность преподавателя вести протокол вручную, перенос методики при смене модели.\n\n19.4. Потенциал масштабирования\n\nПереносится:\n\n— цикл работы;\n— формат следов;\n— правила fading;\n— тестовая методика;\n— интерфейс;\n— governance.\n\nПересобирается:\n\n— предметная онтология;\n— кейсы;\n— типовые риски;\n— допустимые альтернативы;\n— рубрика;\n— границы консультирования;\n— критерий достаточности.\n\n19.5. Место в портфеле\n\nКласс: адаптивная среда метакогнитивной практики / process-based assessment / calibrated delegation.\n\n19.6. Радикальная версия\n\nУниверситетская библиотека проверенных вопросных операторов и протоколов для разных типов профессионального мышления. Каждый контур имеет владельца нормы, case bank, тесты, failure archive, правила данных и процедуру доказательства самостоятельного переноса. Радикальная версия начинается не с каталога персонажей, а с каталога операций, которые удалось вернуть человеку.\n\n20. ПОСЛАЙДОВАЯ ДЕФЕКТОВКА\n\n20.1. Слайд 1. «ФинМыш: от генерации к мышлению»\n\nФункция: имя, визуальная идентичность и обещание перехода от ответа к рефлексивному финансовому мышлению.\n\nСильная часть: название удачно удерживает и предмет, и функцию; четыре нижних маркера — рефлексия, финансовое мышление, осознанные решения, социализация будущего — задают амбицию.\n\nДефект: «социализация будущего» не раскрыта в проекте и выглядит отдельной концепцией. В материалах описаны групповое обсуждение и публичная защита, но не модель социализации.\n\nКоррекция: либо раскрыть, какую социальную норму принятия финансовых решений формирует курс, либо заменить на предъявленный результат — аргументацию/групповую рефлексию.\n\n20.2. Слайд 2. «Списывание не проблема! Главная проблема — делегирование мышления!»\n\nФункция: перевести разговор с академического нарушения на судьбу интеллектуальной операции.\n\nСильная часть: различение содержательно точное и соответствует зоне ближайшей деградации.\n\nДефект: списывание всё же остаётся проблемой оценивания, а схема «2022/2026» создаёт упрощённую историческую драматургию. Проекту важнее показать не эпохи, а две траектории действия: готовый ответ и развивающее делегирование.\n\nКоррекция: добавить цепочку «делегированная операция → продукт без реконструкции → иллюзия способности» и противоположную цепочку «внешний вопрос → собственное действие → перенос».\n\n20.3. Слайд 3. «Почему ФинМыш? Кризис рефлексии в эпоху ИИ»\n\nФункция: показать разрыв между принятым и осознанным решением и пять оснований проекта.\n\nСильная часть: центральное противоречие сформулировано лучше, чем в длинном описании: курс требует рефлексивного мышления, но не создаёт систематической практики. Схема «принял решение → осознал решение» показывает объект преобразования.\n\nДефекты:\n\n— утверждения не имеют эмпирического основания;\n— смешаны проблемы курса, ограничения преподавателя и последствия отсутствия диалога;\n— «ИИ отвечает быстро» не является проблемой само по себе;\n— визуально красный разрыв содержит примеры допущений, но не показывает, почему они не выявляются в текущем курсе.\n\nКоррекция: заменить пять карточек на причинную цепочку с данными собственной практики и указать baseline.\n\n20.4. Слайд 4. Исследовательский вопрос и гипотеза\n\nФункция: предъявить центральную причинную ставку.\n\nСильная часть: вопрос и гипотеза согласованы; итогом заявлено рефлексивное финансовое мышление.\n\nДефект: контроль «традиционная самостоятельная групповая работа» не изолирует вклад LLM. Формула «без использования ИИ» закрывает способ реализации, но не механизм сравнения.\n\nКоррекция: добавить active control и отдельную ИИ-гипотезу.\n\n20.5. Слайд 5. Теоретическая рамка\n\nФункция: связать проект с Выготским, скаффолдингом, метапознанием, продуктивной неудачей и рефлексией.\n\nСильная часть: теории подобраны вокруг развития операции, а не вокруг общей цифровизации.\n\nДефект: вертикальная лестница создаёт впечатление, что авторы прошли от Выготского к Колбу как по этажам одного здания. Реально это разные механизмы. Не показано, какой сценарный элемент реализует каждый.\n\nКоррекция: таблица «теория → механизм → шаг → след»; отдельно уточнить статус LLM как Другого/актantа и признаки интериоризации.\n\n20.6. Слайд 6. Цикл рефлексивной работы и принципы\n\nФункция: описать пять функций и шесть принципов взаимодействия.\n\nСильная часть: это центральный проектный слайд; функции хорошо различены, примеры вопросов позволяют собирать ручной прототип.\n\nДефекты:\n\n— цикл фактически может начинаться с любой функции, но правило выбора не задано;\n— отсутствуют критерий завершения и обработка тупика;\n— «приоритет мышления над ответом» и «любой ответ заменяется вопросом» могут запрещать полезную фиксацию;\n— нет fading;\n— групповая рефлексия объявлена принципом, но роли участников не описаны.\n\nКоррекция: добавить state machine, условия перехода, максимальную длину, режим передачи человеку и траекторию снятия помощи.\n\n20.7. Слайд 7. Четырёхнедельный эксперимент и критерии\n\nФункция: показать группы, недели, итог без ИИ и пять критериев оценки.\n\nСильная часть: общая программа и итог без ИИ понятны визуально; критерии предметно лучше общего «глубже понял».\n\nДефекты:\n\n— нет pre-test;\n— нет active control;\n— неизвестно число групп;\n— итоговое задание, по рисунку, может оставаться групповым;\n— критерии не включают явный метакогнитивный индикатор и перенос вопросной структуры;\n— «обучение с ИИ» и «без ИИ» визуально получают разные наборы действий, что подтверждает смешение факторов.\n\nКоррекция: показать три условия или фиксированный контроль, индивидуальный итог, единицу анализа и рубрику.\n\n20.8. Слайд 8. Архитектура ИИ-ассистента\n\nФункция: соединить модель, педагогический дизайн, «ФинМыша», преподавателя, сократический диалог и результат.\n\nСильная часть: преподаватель не исчезает, а педагогический дизайн поставлен между моделью и образовательным результатом.\n\nДефекты:\n\n— схема не является архитектурой в инженерном смысле: нет данных, состояния, вызовов, ошибок, журналов, интерфейсов и human gate;\n— «ФинМыш» назван ИИ-персоной, хотя проект описывает функцию, а не воспроизводимую позицию личности;\n— модель-независимость не подкреплена тестами;\n— не показана скрытая диагностика следующего вопроса.\n\nКоррекция: заменить на компонентно-ролевую схему из разделов 12–13.\n\n20.9. Слайд 9. Риски и управление рисками\n\nФункция: показать пять рисков и меры.\n\nСильная часть: риски встроены в проект, а не приложены после слова «этика».\n\nДефекты:\n\n— не названа передача машине вопросной функции;\n— рефлексивный отчёт сам может быть формальным или сгенерированным;\n— «финальные задания без ИИ» не решают риск зависимости преподавателя и курса;\n— конфиденциальность описана общо.\n\nКоррекция: добавить деградационную карту на уровнях студент/преподаватель/курс/организация и конкретный data governance.\n\n20.10. Слайд 10. Развитие эксперимента\n\nФункция: апробация → адаптация → интеграция.\n\nСильная часть: авторы начинают с одной дисциплины и говорят о переносе принципа.\n\nДефекты:\n\n— переход от пилота к экосистеме не содержит gate-критериев;\n— на этапе адаптации рядом появляются новые предметы, но не показано, что пересобирается;\n— интеграция визуально размножает персонажей раньше методики и ответственности.\n\nКоррекция: вставить между этапами критерии: доказан механизм; прошёл конформанс-тест; есть владелец и бюджет; перенос на вторую дисциплину воспроизведён.\n\n21. РЕКОМЕНДУЕМЫЙ ПЕРВЫЙ ПИЛОТ\n\n21.1. Рабочее название\n\n«Адаптивный вопросный контур для самостоятельной проверки финансовых решений».\n\n21.2. Центральный исследовательский вопрос\n\n«Повышает ли адаптивный выбор метакогнитивного вопроса LLM качество индивидуальной самостоятельной проверки новой финансовой ситуации по сравнению с фиксированным протоколом тех же типов вопросов?»\n\n21.3. Участники\n\nОдин поток дисциплины. До начала необходимо установить фактическое N и число малых групп. Если групп меньше 8–10, пилот позиционируется как exploratory/design-based study, а не как окончательное доказательство эффекта.\n\n21.4. Материал\n\nОдин тип задач: например, выбор финансовой стратегии домохозяйства или проекта при ограничениях дохода, инфляции, риска и горизонта. Создать 12–15 эквивалентных вариантов:\n\n— входной;\n— три учебных цикла;\n— итоговый;\n— отсроченный;\n— резервные варианты;\n— калибровочные примеры для экспертов.\n\n21.5. Условия\n\nРекомендуемый вариант:\n\nА. Фиксированная вопросная карта.\n\nБ. «ФинМыш» с адаптивным выбором следующего вопроса.\n\nОбычная групповая работа может быть третьим условием, если выборка позволяет.\n\n21.6. Траектория помощи\n\nНеделя 1: полный цикл; LLM выбирает вопросы.\n\nНеделя 2: перед ответом группа предсказывает, какой вопрос нужен.\n\nНеделя 3: группа сама формулирует вопрос, LLM предлагает альтернативный или уточняет.\n\nНеделя 4: индивидуальная задача без ИИ.\n\nЧерез 2–4 недели: отсроченная задача.\n\n21.7. Основной outcome\n\nИндивидуальный transfer score по слепой рубрике.\n\n21.8. Вторичные outcomes\n\n— качество самопоставленных вопросов;\n— изменение первой версии;\n— выявление рисков;\n— калибровка уверенности;\n— групповое участие;\n— время;\n— нарушения LLM;\n— нагрузка преподавателя.\n\n21.9. Критерии технической успешности\n\n— не менее 95% ходов соответствуют допустимому формату вопроса;\n— не более 5% ходов содержат прямую рекомендацию или готовое решение; целевой production-порог должен быть строже после пилота;\n— релевантность следующего вопроса оценивается экспертами;\n— сессия завершает цикл без бесконечного повторения;\n— модель фиксируется и журналируется;\n— нет утечки персональных данных;\n— средняя задержка не разрушает групповую дискуссию.\n\nЦифры являются стартовыми проектными порогами и должны быть утверждены авторами после калибровки. Они не взяты из текущих материалов.\n\n21.10. Критерии педагогической успешности\n\n— условие LLM превосходит фиксированный протокол по основному individual transfer outcome либо показывает иной доказанный механизм;\n— улучшение нельзя объяснить только длиной текста;\n— студенты лучше сами формулируют вопросы;\n— результат сохраняется в отсроченной пробе;\n— нет роста зависимости по диагностическим индикаторам.\n\n21.11. Критерии остановки\n\n— систематическая выдача финансовых рекомендаций;\n— ложные предметные предпосылки, влияющие на решение;\n— утечка данных;\n— существенная несопоставимость условий;\n— обновление модели без возможности повторной калибровки;\n— студенты используют реальные персональные данные;\n— преподаватель не может восстановить, почему сессия пошла данным путём.\n\n22. ПЕРВЫЙ ИНЖЕНЕРНЫЙ АРТЕФАКТ\n\nОдин вертикальный прототип:\n\n1) преподаватель создаёт сессию и выбирает case_id;\n2) группа видит кейс и вводит первую общую версию;\n3) LLM-оператор получает case package, системную политику, текущую версию и историю;\n4) возвращает один вопрос и служебные метаданные stage/intent;\n5) группа отвечает;\n6) цикл продолжается максимум заданное число ходов;\n7) при стоп-условии выдаётся нейтральное завершение и финальный вопрос обратной реконструкции;\n8) журнал сохраняет все сообщения, версии, время, модель и prompt_version;\n9) преподаватель экспортирует сессию;\n10) группа пишет итог самостоятельно.\n\nПриёмочный walkthrough проводится минимум на десяти сценариях:\n\n— сильная группа;\n— слабая группа;\n— группа с ложным фактом;\n— просьба дать ответ;\n— просьба назвать лучший вклад;\n— реальная персональная ситуация;\n— раскрытие персональных данных;\n— конфликт участников;\n— бессодержательные ответы;\n— попытка вывести системный промпт;\n— технический обрыв;\n— повторяющиеся вопросы.\n\n23. ПРОТОТИП ТЕХНИЧЕСКОГО ЗАДАНИЯ ДЛЯ ЛАБОРАТОРИИ РАЗРАБОТКИ\n\n23.1. Статус и принцип экстракции\n\nЭто ТЗ не описывает всё пространство эксперимента. Оно извлекает из графа раздела 13 только цепочки, где выполняется LLM- или ML-операция. Назначение групп, таймер, хранение файлов, экспорт и права доступа учитываются как зависимости, но требования к RAG, памяти, скорости и качеству генерации задаются только для машинно-интеллектуального контура.\n\nТЗ не проводит скрытую коррекцию авторской архитектуры и не размножает «ФинМыша» на нескольких агентов. Вся заявленная интеллектуальная функция остаётся одним LLM-оператором с несколькими типами операций. Если требования оказываются слишком сильными для одного узла, это фиксируется оценкой реализуемости и риском, а не лечится незаметным появлением Совета Мудрых Мышей.\n\n23.2. Терминологическая классификация\n\nНазвание узла: LLM-оператор «ФинМыш».\n\nТип: диалоговый метакогнитивный оператор внутри управляемого педагогического workflow.\n\nСтатус агентности: не агент в строгом фристоновском смысле. Нет автономного замкнутого цикла восприятия среды, выбора действий, воздействия, обратной связи и обновления устойчивого состояния. История чата является session context, а не достаточным доказательством агентности.\n\nЧеловеческие акторы: студенческая группа, преподаватель, исследовательская команда.\n\nНечеловеческие актанты: LLM-провайдер, case package, системный сценарий, журнал, интерфейс.\n\n23.3. Цель LLM-узла\n\nНа основании текущего учебного кейса, первой версии решения группы и истории диалога сформировать один следующий открытый вопрос, который переводит группу к одной из пяти операций:\n\n— актуализация оснований;\n— выявление допущений;\n— расширение альтернатив;\n— развитие аргументации;\n— рефлексия процесса.\n\nОператор не должен:\n\n— выдавать готовое решение;\n— выбирать финансовую стратегию за группу;\n— выставлять оценку студенту;\n— имитировать персонального финансового консультанта;\n— писать итоговый рефлексивный отчёт;\n— скрывать, что является ИИ;\n— запрашивать персональные финансовые данные.\n\n23.4. Входы\n\nОбязательные:\n\n— system_policy_version;\n— model_id/model_version;\n— case_id;\n— case_text;\n— task_constraints;\n— current_group_solution;\n— current_group_reasoning;\n— conversation_history;\n— turn_number;\n— max_turns;\n— permitted_question_types;\n— stop_conditions.\n\nОпциональные:\n\n— group_stated_disagreement;\n— student_generated_questions;\n— teacher_note;\n— retrieved_course_context;\n— previous_solution_versions;\n— fading_level.\n\nЗапрещённые или минимизируемые:\n\n— ФИО;\n— реальные счета, долги, доходы, номера документов;\n— сведения, позволяющие идентифицировать личную финансовую ситуацию;\n— неанонимизированные оценки.\n\n23.5. Выходы\n\nПользовательский выход:\n\n— один вопрос на русском языке;\n— краткий, конкретный, связанный с текущим рассуждением;\n— без скрытого второго/третьего вопроса в длинном абзаце;\n— без ответа, рекомендации и оценки;\n— объём по умолчанию 1–3 предложения.\n\nСлужебный структурированный выход:\n\n— question_type;\n— dialogue_stage;\n— referenced_claim_or_assumption;\n— reason_for_question;\n— stop_recommended: true/false;\n— safety_flag;\n— escalation_reason;\n— confidence или quality_estimate, если поддерживается проектом.\n\nСлужебные поля не показываются студентам автоматически, но сохраняются для аудита. Если выбранная модель не обеспечивает надёжный структурированный вывод, метаданные могут формироваться отдельным детерминированным парсером; это не создаёт нового ИИ-агента.\n\n23.6. Операция 1. Определение диалогового состояния\n\nОписание: LLM интерпретирует текущую версию рассуждения и выбирает, какая из пяти вопросных функций наиболее релевантна. Это скрытая семантическая диагностика, но не итоговая оценка компетентности.\n\nТребования:\n\n— учитывать содержание текущего ответа, а не только номер шага;\n— не повторять уже закрытый вопрос без причины;\n— различать отсутствие данных, отсутствие аргумента и реальное расхождение;\n— учитывать fading_level;\n— выдавать служебный stage/intent.\n\nРеализуемость, июль 2026: 4/5. Современные LLM хорошо классифицируют текст и выбирают тип следующего хода, но качество чувствительно к разметке, модели и неоднозначности группового ответа. Для образовательной надёжности требуется экспертный набор состояний и регулярный аудит.\n\nОценка на 2027 год: 5/5 для ограниченного домена. Ожидается улучшение instruction following, структурированных выходов и длинного контекста; экспертная предметная разметка всё равно останется необходимой.\n\n23.7. Операция 2. Генерация метакогнитивного вопроса\n\nОписание: LLM формирует один вопрос выбранного типа, привязанный к конкретному тезису или пропуску в рассуждении.\n\nТребования:\n\n— вопрос должен быть открытым;\n— должен требовать действия группы, а не риторического согласия;\n— должен ссылаться на конкретный элемент решения;\n— не должен содержать скрытую подсказку, фактически выдающую ответ;\n— не должен быть универсальным вопросом, подходящим к любому кейсу;\n— язык соответствует уровню студентов;\n— вопрос не дублирует предыдущие.\n\nРеализуемость, июль 2026: 4/5. Генерация релевантных вопросов является штатной возможностью русскоязычных LLM; устойчивость качества определяется prompt policy и тестами. Основной риск — гладкие общие вопросы, выглядящие умнее своего вклада.\n\nОценка на 2027 год: 5/5. На ограниченной предметной области с примерами и оценочным набором задача должна стать стандартной.\n\n23.8. Операция 3. Удержание запрета на решение и финансовую рекомендацию\n\nОписание: LLM сохраняет вопросный режим даже при просьбах «скажите правильный ответ», «что выгоднее» и «просто выберите».\n\nТребования:\n\n— распознавать запрос готового решения;\n— возвращать вопрос или безопасное объяснение границы;\n— не выдавать конкретную персональную финансовую рекомендацию;\n— для реальной ситуации переводить пользователя к учебному анализу либо преподавателю;\n— фиксировать violation_attempt;\n— иметь набор adversarial-тестов.\n\nРеализуемость, июль 2026: 3/5 в режиме одного системного промпта; 4/5 при ограниченном интерфейсе, жёсткой политике, постпроверке и тестах. Полностью гарантировать отрицательное поведение вероятностной модели нельзя.\n\nОценка на 2027 год: 4/5. Instruction following станет устойчивее, но защита по-прежнему требует системных ограничений и мониторинга.\n\n23.9. Операция 4. Поддержание контекста групповой сессии\n\nОписание: LLM учитывает case package, историю, версии решения и уже заданные вопросы внутри одной сессии.\n\nПамять:\n\n— обязательна session-local memory;\n— история передаётся явно или поддерживается через session API;\n— при переполнении используется структурированное summary с сохранением тезисов, допущений, альтернатив, открытых вопросов и изменений;\n— долговременная персональная память между потоками не нужна в MVP;\n— исследовательский лог хранится отдельно и не автоматически включается в будущие ответы.\n\nРеализуемость, июль 2026: 5/5 технически, 4/5 по качеству длинной групповой истории. GigaChat и Yandex Cloud поддерживают историю чата; доступны механизмы файлов, поисковых индексов, embeddings и tool calling. Нужна дисциплина контекста, иначе модель начнёт помнить всё, кроме того, почему группа поменяла решение.\n\nОценка на 2027 год: 5/5.\n\n23.10. Операция 5. Завершение и обратная реконструкция\n\nОписание: при достижении лимита ходов или закрытии основных типов проверки LLM формирует один финальный вопрос, возвращающий операцию группе, и завершает сессию без итогового решения.\n\nТребования:\n\n— учитывать stop_conditions;\n— не продолжать вопросы бесконечно;\n— задать вопрос о том, что изменилось, какой ход был значим и что группа сможет повторить самостоятельно;\n— не писать рефлексивный отчёт;\n— вернуть session_complete=true;\n— при незавершённости предложить передачу преподавателю, а не выдумывать финал.\n\nРеализуемость, июль 2026: 4/5. Простое завершение легко; содержательное определение достаточности анализа требует формализованной карты кейса и остаётся вероятностным.\n\nОценка на 2027 год: 5/5 в ограниченном сценарии.\n\n23.11. Операция 6. Обработка небезопасных и нерелевантных входов\n\nОписание: LLM распознаёт персональные финансовые данные, запрос реальной консультации, попытку раскрытия инструкций, оскорбление, уход из темы и технически бессодержательный ответ.\n\nТребования:\n\n— не продолжать персональную консультацию;\n— не сохранять лишние персональные данные;\n— объяснить учебную границу;\n— предложить обезличить ситуацию;\n— при конфликте или риске передать преподавателю;\n— фиксировать safety_flag;\n— системный промпт не раскрывать.\n\nРеализуемость, июль 2026: 4/5. Базовая классификация и безопасный ответ доступны; нужны локальные правила и проверка ложных срабатываний.\n\nОценка на 2027 год: 5/5 для учебного домена.\n\n23.12. RAG\n\nСтатус для MVP: необязателен.\n\nRAG — retrieval-augmented generation, генерация с извлечением фрагментов из утверждённого корпуса — нужен только если вопрос должен опираться на предметные материалы, рубрику, case map или нормативные ограничения, не помещающиеся в case package.\n\nЕсли RAG включён:\n\n— корпус состоит только из утверждённых материалов курса, кейсов, словаря терминов, типовых ошибок и критериев;\n— каждый фрагмент имеет source_id, version и owner;\n— retrieval выполняется по case_id и текущему тезису;\n— в лог сохраняются использованные source_id;\n— система не превращает retrieved content в готовую рекомендацию;\n— обновление корпуса версионируется;\n— внешняя сеть не используется без отдельного решения.\n\nПроизводительность: retrieval p95 до 2 секунд; общий ответ p95 остаётся в лимите раздела 23.14.\n\nРеализуемость, июль 2026: 5/5 технически. Официальные API GigaChat и Yandex Cloud поддерживают embeddings, файлы и поисковые индексы. Педагогическая необходимость в первом пилоте не доказана.\n\nОценка на 2027 год: 5/5.\n\n23.13. Модельная переносимость\n\nТребование: система должна поддерживать минимум два провайдера через общий интерфейс сообщений и конфигурации, но каждая модель проходит отдельный конформанс-тест.\n\nСравниваются:\n\n— релевантность вопроса;\n— соблюдение запрета;\n— структурированный выход;\n— скорость;\n— стоимость;\n— стабильность русского языка;\n— контекст;\n— политика данных;\n— дрейф версии.\n\nРеализуемость, июль 2026: 3/5. API-интеграция переносима, но одинаковое педагогическое поведение между моделями не гарантируется.\n\nОценка на 2027 год: 4/5. Стандартизация интерфейсов и evals улучшит переносимость, но различия моделей останутся.\n\n23.14. Производительность и скорость\n\nПредположение пилота: до 20 одновременных групп; уточнить после определения N.\n\nТребования:\n\n— время до первого токена: целевое p50 ≤ 2,5 секунды, p95 ≤ 5 секунд;\n— полный вопрос: p95 ≤ 10 секунд;\n— длина пользовательского ответа LLM: обычно до 100–150 слов, предпочтительно короче;\n— доступность в часы эксперимента: не ниже 99% либо предусмотрен ручной fallback;\n— повтор запроса не должен создавать два вопроса в журнале;\n— при timeout интерфейс предлагает повтор или передачу преподавателю;\n— поддерживается потоковая выдача, если провайдер позволяет.\n\nЭти значения — проектные ориентиры, а не свойства конкретной модели из материалов. Групповая рефлексия не требует ответа за 300 миллисекунд, но десять секунд молчания каждый ход быстро превращают метапознание в проверку Wi‑Fi.\n\nРеализуемость, июль 2026: 4/5 при облачных API и умеренной конкуренции; квоты и пиковая задержка зависят от провайдера и тарифа.\n\nОценка на 2027 год: 5/5.\n\n23.15. Интерфейсы\n\nСтуденческий интерфейс:\n\n— видимый case panel;\n— общая история группы;\n— поле текущей версии решения;\n— отдельная отправка ответа группе/LLM;\n— индикатор номера хода и оставшегося времени;\n— кнопка «зафиксировать новую версию»;\n— кнопка «позвать преподавателя»;\n— предупреждение не вводить персональные данные;\n— видимое обозначение, что система является ИИ.\n\nПреподавательский интерфейс:\n\n— создание/назначение сессии;\n— выбор case_id и версии сценария;\n— просмотр активных сессий;\n— индикаторы технического сбоя, safety_flag и запроса помощи;\n— доступ к полному логу;\n— принудительное завершение;\n— экспорт обезличенных данных.\n\nИсследовательский интерфейс:\n\n— выгрузка JSON/CSV;\n— фильтр по группе, кейсу, условию, модели, prompt_version;\n— версии решений;\n— служебные метаданные вопроса;\n— журнал ошибок.\n\nГолос, анимация персонажа и сложная визуализация не входят в MVP.\n\n23.16. Журналирование и provenance\n\nДля каждого вызова сохраняются:\n\n— timestamp;\n— group_id/session_id/case_id;\n— condition;\n— model/provider/version;\n— system_policy_version;\n— входное сообщение;\n— выходной вопрос;\n— служебные поля;\n— latency;\n— token usage/cost, если доступно;\n— retrieved source IDs;\n— safety flags;\n— retry/error;\n— идентификатор версии решения до и после;\n— отметка human intervention.\n\nЛоги должны позволять восстановить, что сделал LLM, но не использоваться для скрытого профилирования студентов.\n\n23.17. Data governance\n\nДо запуска определить:\n\n— юридическое основание обработки;\n— владельца данных;\n— место хранения;\n— срок хранения;\n— перечень лиц с доступом;\n— процедуру обезличивания;\n— удаление и экспорт;\n— правила использования в публикациях;\n— условия провайдера по обучению на данных;\n— порядок действия при утечке.\n\nMVP использует вымышленные финансовые кейсы и group IDs. Реальные персональные финансовые ситуации не собираются.\n\n23.18. Приёмочные тесты\n\nКатегории:\n\n1) функциональные — пять типов вопросов;\n2) релевантность — связь с конкретным тезисом;\n3) запрет ответа — прямые и косвенные просьбы;\n4) финансовая безопасность — персональная рекомендация;\n5) prompt injection — раскрытие правил и смена роли;\n6) групповая неоднозначность — противоречивые позиции;\n7) бессодержательные ответы;\n8) повторение;\n9) остановка;\n10) длинный контекст;\n11) смена модели;\n12) технический сбой.\n\nПриёмку проводят предметный эксперт, методист и инженер. Один инженер не может утвердить, что вопрос педагогически релевантен; один методист не должен утверждать, что timeout обработан.\n\n23.19. Human gates\n\nОбязательная передача человеку при:\n\n— запросе реальной финансовой консультации;\n— персональных данных;\n— конфликте или эмоционально небезопасной ситуации;\n— многократном нарушении запрета на ответ;\n— невозможности определить следующий ход;\n— техническом сбое;\n— просьбе группы;\n— решении преподавателя.\n\n23.20. Критерии готовности лабораторного MVP\n\nMVP готов к учебному пилоту, если:\n\n— вручную пройден полный сценарий;\n— утверждены case package и question policy;\n— есть frozen prompt version;\n— 100% обязательных логов сохраняются;\n— приёмочный набор пройден на выбранной модели;\n— преподаватель может остановить и продолжить вручную;\n— данные обезличиваются;\n— интерфейс поддерживает группу;\n— выполнена тестовая сессия с реальными студентами вне оценивания;\n— есть fallback при недоступности API.\n\n24. СЛЕДУЮЩИЙ ПАКЕТ АРТЕФАКТОВ\n\n24.1. По позиции Ульяны\n\nОбязательный артефакт: рубрика индивидуального переноса и три эквивалентных кейса.\n\n24.2. По позиции Тимура\n\nОбязательный артефакт: карта состояний рассуждения и допустимых следующих вопросов с тестами нарушений.\n\n24.3. Общий обязательный артефакт\n\n«Методический пакет ФинМыш v0.1»:\n\n— паспорт одного модуля;\n— problem evidence;\n— case bank;\n— рубрика;\n— active control;\n— state/question map;\n— fading policy;\n— полный user flow;\n— data schema;\n— acceptance tests;\n— frozen prompt;\n— план эксперимента.\n\n24.4. Способ поддержки на следующем семинаре\n\nПровести не обсуждение всей презентации, а live walkthrough одного кейса:\n\n— авторы играют группу;\n— один участник играет фиксированный вопросный протокол;\n— прототип играет «ФинМыша»;\n— наблюдатели отмечают, где LLM действительно выбрал более релевантный ход;\n— затем та же группа решает короткий аналог без поддержки.\n\n24.5. Усиливающий ход после основной сборки\n\nДобавить student-generated question mode: группа сама предлагает следующий вопрос, а LLM только сравнивает его с альтернативой. Этот режим напрямую проверяет возврат операции и может стать главным отличием проекта от обычного сократического чат-бота.\n\n25. ТАБЛИЦА ГОТОВНОСТИ\n\nПрактическая актуальность — сильная.\n\nСобственный интерес авторов — сильный, требует корпуса наблюдений.\n\nКонкретность дисциплины — предъявлена.\n\nВыборка и поток участников — отсутствуют.\n\nПроблема — содержательно сильная, эмпирически не доказана.\n\nОбразовательный результат — сильный, перегружен шестью компонентами.\n\nДеятельность студента — частично предъявлена.\n\nГрупповая механика — требует решения.\n\nТеоретическая рамка — предъявлена, требует операционного отображения.\n\nОбразовательная гипотеза — предъявлена, требует сужения.\n\nИИ-гипотеза — реконструируется, не выделена.\n\nДизайн эксперимента — частичный; хороший каркас, слабый контроль.\n\nИндивидуальный перенос — должен быть подтверждён форматом итоговой задачи.\n\nРубрика — отсутствует как рабочий инструмент.\n\nПроцессные следы — сильный задел.\n\nЗона ближайшей деградации — в исходном проекте частично замечена, вопросная экзопроприация не замечена.\n\nАрхитектура LLM — концептуальная, инженерно недостаточная.\n\nКлассификация агентности — завышена; фактически LLM-оператор.\n\nRAG — не требуется для первого MVP; технически доступен.\n\nПамять — session-local достаточна; долговременная преждевременна.\n\nБезопасность и данные — принцип заявлен, процедура отсутствует.\n\nФункционально-стоимостная оценка — в исходных материалах отсутствует.\n\nГотовность к ручному walkthrough — высокая.\n\nГотовность к техническому MVP — высокая после четырёх обязательных артефактов.\n\nГотовность к педагогическому пилоту — средняя.\n\nГотовность к причинному выводу — низкая до active control и уточнения выборки.\n\nГотовность к лаборатории — средняя.\n\nГотовность к масштабированию — низкая до доказательства механизма и второго предметного переноса.\n\n26. ГЛАВНЫЙ ВНУТРЕННИЙ ВЫВОД\n\n«ФинМыш» нащупал сильный и актуальный объект: не производство финансового ответа, а внешнюю организацию вопросов, через которые решение становится проверяемым и пересматриваемым. Проект уже содержит важнейшую защиту — итоговую задачу без ИИ — и понимает, что ценность лежит в педагогическом сценарии, а не в названии модели. Его следующая версия должна перестать сравнивать «вопросный контур» с отсутствием вопросного контура и начать проверять собственно добавленную ценность адаптивной LLM. Одновременно нужно сделать видимой скрытую диагностику, без которой релевантный следующий вопрос невозможен, и вернуть студенту не только решение, но и способность ставить вопрос.\n\nПервый предмет разработки — не персона и не университетская экосистема. Это карта из десятков состояний рассуждения, экспертно допустимых следующих вопросов, условий завершения и признаков подмены. Когда она появится, системный промпт станет реализацией педагогической модели. До этого педагогическая модель в основном живёт в хорошем тексте описания и иногда заходит на слайд 8, где её встречают нейроны и отсутствие session_id.\n\n27. НЕСУЩИЙ ВОПРОС НА СЛЕДУЮЩИЙ СЕМИНАР\n\n«Как именно мы увидим, что после трёх недель студент сам породил структуру вопросов “ФинМыша”, а не просто научился хорошо отвечать на неё?»","chars":96594}