Каковы лучшие практики и советы по проектированию эффективного образовательного ПО с ИИ?

Автоматический перевод данной английской страницы, не проверенный носителем языка.

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

• Согласуйте систему с явными целями обучения.
• Обеспечивайте опору (scaffolding), а не выполняйте целевую когнитивную работу за учащегося.
• Опирайте ответы на одобренные преподавателем или авторитетные материалы, когда важна фактическая достоверность.
• Сообщайте о неопределённости.
• Обеспечьте путь эскалации к человеку.
• Проектируйте «добрые, но корректные» ответы вместо согласия с пользователем.
• Давайте преподавателям содержательные возможности настройки и контроля.
• Минимизируйте избыточные данные об учащемся и собирайте только то, что педагогически необходимо (см. Приватность).
• Проектируйте Доступность с самого начала.
• Тестируйте неравномерность качества работы для разных групп учащихся (см. Справедливость).
• Оценивайте продолжительное многоходовое взаимодействие, а не отдельные демонстрационные промпты.

Педагогическая безопасность

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

SafeTutors Бенчмарк превращает это предупреждение в числа. Для всех протестированных моделей — от открытых моделей на 3.8B параметров до GPT-5-mini — педагогический вред был универсальным, масштаб модели надёжно не улучшал безопасность, а частота отказов возрастала с 17.7% в одноходовых взаимодействиях до 77.8% в многоходовых диалогах, при этом характер нарушений зависел от предметной области. Таксономия бенчмарка из 11 измерений и 48 подрисков (когнитивные, эпистемические, метакогнитивные, аффективно-мотивационные, связанные с развитием и справедливостью, согласованность с инструкцией и другие) представляет собой пригодный чек-лист проектирования. Практический вывод для любого, кто формулирует требования к образовательному ПО: система может быть точной и «безопасной» по обычным метрикам, тихо подрывая обучение, поэтому многоходовая, учитывающая дисциплину оценка является обязательным требованием, а не завершающим шлюзом.

Доступность и справедливость

Доступность должна включать конкретные операционные требования, такие как управляемость с клавиатуры, совместимость с программами экранного доступа, субтитры и расшифровки, достаточный контраст, пригодные текстовые альтернативы и совместимость со вспомогательными технологиями; сгенерированные ИИ функции доступности всё равно требуют проверки качества. См. Доступность.

Тестирование на справедливость должно рассматривать весь конвейер и дезагрегировать поведение по языку, инвалидности, культуре и другим значимым характеристикам учащихся, не полагаясь только на агрегированную точность. См. рекомендации базы знаний по Снижение перекосов (bias mitigation), изложенные вместе со страницей Справедливость.

Проектирование ради ограниченной ответственности, а не автономии

Исследование партисипаторного проектирования Райхерта и коллег с шестью преподавателями средних школ — полезное корректирующее возражение предположению, что образовательный ИИ должен быть автономным агентом. Когда преподавателей попросили сделать на бумаге прототип классных чат-ботов, каждый описал ограниченного эксперта — специализированную возможность, ограниченную строго определённой областью и работающую под контролем человека, — по двум измерениям. Границы полномочий сохраняли за преподавателями окончательный контроль, поскольку профессиональную ответственность за обучение и безопасность студентов делегировать нельзя; границы экспертизы отражали отсутствие у ИИ контекстных знаний об отдельных студентах, динамике учебной аудитории и институциональных нормах.

Архитектура, которую они набросали, имела четыре взаимосвязанных компонента — ограничение контента, представление контента, адаптация к студенту и контроль преподавателя — опирающихся на три защитных слоя: границы области, ограничивающие охват; фильтрацию контента, позволяющую безопасную персонализацию; и возможность преподавателя отменить решение в неоднозначных случаях. Делегирование было выборочным: спроецированное на девять событий обучения Ганье, оно приветствовалось преподавателями для представления контента, предоставления практических задач и предложения формирующей Обратная связь, но отвергалось для постановки целей или проведения суммирующего Оценивание. Примечательно, что они отдавали приоритет поведенческой прозрачности — видимым границам и признакам неопределённости, — а не объяснениям модели, и все шестеро просили полное логирование диалогов, оповещения в реальном времени и возможность отмены решений как выражение профессиональной ответственности, а не недоверия.

Проектирование совместно с заинтересованными сторонами, а не только для них

Два дальнейших исследования это развивают. Ко и Хьюз применили ценностно-чувствительное проектирование к интеллектуальной тьюторной системе со студентами и преподавателями коммунальных колледжей — группой заинтересованных сторон, исторически исключённой из проектирования обучающих платформ, — и обнаружили устойчивые ценностные напряжения, которыми нужно управлять, а не решать: прозрачность в противовес интерпретируемости, конфиденциальность в противовес учебной осведомлённости и студенческая активность в противовес управляемому системой Скаффолдинг. Студенты предпочитали совместные, очеловеченные объяснения сырой прозрачности модели, и полученный прототип закодировал 16 согласованных с ценностями функций в областях Интерпретируемый ИИ, контроля с человеком в цикле и Приватность.

Обзор Ванга, Лю и Ислама 28 эмпирических исследований совместного проектирования преподавателей с ИИ добавляет словарь проектирования: генеративный ИИ используется в основном для планирования занятий, генерации промптов и творческих идей, при этом ИИ значительно чаще выступает как ассистент или генератор контента, чем как со-проектировщик, и выделяет четыре повторяющихся возможности — эффективность, отзывчивость, Креативность и справедливость, — по которым преподаватели могут судить, какой инструмент подходит к какой проектной задаче. Оба исследования рассматривают проектирование как коллаборацию с человеком в цикле совместной работы — исследование юзабилити, а не работу с сообществом, — и оба обнаружили, что опрошенные заинтересованные стороны выявили требования, которые не уловил бы ни один бенчмарк точности.

Опирайтесь на данные и проверяйте, не доверяя модели

Grounding — это архитектурное решение, а не промпт. EduGuard, безопасный основанный на поиске тьютор для вводного программирования, сочетает одобренный преподавателем поиск по материалам курса с архитектурно отдельным верификатором утверждений, явным контролем чрезмерной опоры и бенчмарком из 600 запросов, созданным преподавателями, охватывающим заблуждения, отладку, смешанные запросы и состязательные промпты с прямым требованием ответа, — превосходя базовые модели тьюторов на основе GPT-4o-mini и Llama сократического метода. Для проектировщиков это конкретная форма «опирайте ответы на одобренные преподавателем материалы»: разделите компоненты, которые проверяют, и компоненты, которые ведут диалог, и тестируйте на случаях, которые активно пытаются извлечь ответы. См. риск галлюцинаций.

О том, как эти принципы проектирования реализуются в построенном тьюторе — диагностика, лестница подсказок, обратная связь и оценка, — см. Каковы лучшие практики разработки эффективного ИИ-тьютора?; о педагогических значениях по умолчанию, которые определяют, хорошо ли используется хорошо построенный инструмент, см. Как следует встраивать ИИ в учебный опыт?.

Считайте работу студента недоверенным вводом для любой системы оценивания на базе ИИ. Модель угроз, которую упускает большинство рекомендаций по проектированию, — это состязательный контент внутри оцениваемого артефакта. Сострязательная red-team-оценка Хамбла (2026) проверила, могут ли студенты манипулировать системой оценивания на базе LLM через инъекцию промптов, встроенную в их работы, и выяснила, что манипуляция работает: инъекции, инструктирующие, переформулирующие или разыгрывающие роль проверяющего, сдвигают оценку, не меняя работу. Следствия для проектирования вытекают из того же принципа разделения, что и архитектура верификации выше: держите критерии оценивания и инструкции вне контекстного окна, контролируемого студентом, удаляйте или помечайте похожий на инструкции контент в работах, никогда не позволяйте работе задавать собственные критерии и сохраняйте решение человека для любой значимой оценки. Система оценивания с ИИ, которая читает свои инструкции из того же текста, который она оценивает, вручила критерии кандидату.