Использование больших языковых моделей в обучении студентов, кроме многих достоинств, создает дополнительные проблемы — существует реальный риск ухудшения базовых знаний у будущих инженеров. Меня зовут Игорь Никифоров, и я знаю, о чем говорю: более 14 лет я преподаю в Высшей школе программной инженерии Санкт-Петербургского политехнического университета Петра Великого, в том числе руковожу проектами совместной лаборатории с YADRO.
При этом я не считаю LLM-модели бичом современности. ChatGPT, DeepSeek и им подобные — всего лишь инструменты, новые технологии, которыми важно учиться пользоваться во благо. В статье поделюсь своими размышлениями на тему LLM в высшем образовании и расскажу о некоторых методиках приема лабораторных и практических работ в век нейросетей, часть из которых мы уже внедрили в образовательный процесс.
Большие языковые модели получили широкое признание у самых разных пользователей, студенты и преподаватели вузов не стали исключением. Особенно активно внедряют и используют LLM-модели на специальностях, связанных с программной инженерией. Здесь студенты изучают языки программирования и технологии, которые используются для создания самих технологий LLM и связанных с ними AI-агентов.
На данный момент существует более ста AI-агентов, которые применяются на разных этапах жизненного цикла разработки ПО и успешно используются инженерами в ведущих компаниях. Они способны на многое: редактируют код, выполняют команды взаимодействуют с веб-ресурсами и API, автоматизируют генерации тестовых сценариев. Яркий пример — инструмент OpenHands, который сам наполовину состоит из сгенерированного кода.
Использование LLM-моделей может существенно сократить время на разработку, но требует от пользователя определенных знаний, умений и навыков, таких как:
фундаментальные знания и представления в сфере использования LLM-моделей,
умение правильно формулировать запросы к модели,
понимание ограничений на использование моделей,
способность критически оценивать полученный результат и корректировать ошибки.
Эти навыки не возникают сами по себе — они формируются через опыт и практику.
Например, невозможно стать архитектором информационных систем, минуя этапы младшего, старшего и ведущего инженера. Если такой специалист не прошел все ступени профессионального роста, он рискует стать плохим архитектором. Он не будет понимать всех нюансов и проблем, с которыми сталкиваются инженеры, не осознает технических и прикладных особенностей связи и интеграции различных компонентов системы.
Ровно так же сложно стать хорошим инженером без освоения базы, азов программирования. При этом я наблюдаю, что многие студенты уже на младших курсах начинают активно использовать LLM-модели для выполнения лабораторных и курсовых работ, сдачи экзаменов, отчетов и рефератов. Они потенциально лишают себя возможности развить знания, умения и навыки на фундаментальном уровне, которые часто приходят только с самостоятельным опытом разработки.
Приведу пример из жизни. Студент хотел устроиться на стажировку на позицию «веб-разработчика» в крупную производственную компанию. Перед этим он успешно прошел курс «Технологии промышленной веб-разработки», сдал курсовой проект, где разрабатывал код на JavaScript и HTML. И, в целом, зарекомендовал себя как старательный, внимательный к деталям и технически подкованный начинающий специалист.
После прохождения собеседования руководители компании вернулись с неожиданной обратной связью: оказалось, студент практически не знает JavaScript и не понимает базовых алгоритмов. Как выяснилось позже, при выполнении курсового проекта студент активно использовал LLM-модели и автоматическую генерацию кода на основе естественного описания задач на неформализованном языке.
Этот случай наглядно показывает, что даже успешное выполнение учебных заданий с применением современных инструментов не всегда свидетельствует о реальном уровне знаний и навыков студента.
На просторах интернета и того же Хабра уже не раз тестировали возможности различных LLM-моделей и подсвечивали их недостатки: от некорректности кода и не всегда эффективных решений на архитектурном уровне до вопросов безопасности передачи данных и обеспечения конфиденциальности. Но еще более скрупулезного, на мой взгляд, анализа требует изучение применимости LLM-моделей и AI-агентов при подготовке высококвалифицированных инженеров, программистов, проектировщиков и подобных специалистов.
Традиционный подход к обучению
К сожалению или к счастью, в вузах до сих пор преобладает консервативный подход: студентам запрещают применять LLM-модели при выполнении заданий. Многие преподаватели запрещают их на всех курсах, совсем не учитывая потенциал технологий.
На одной из своих лекций по предмету «Наука о данных и аналитика больших объемов информации» я спросил у 30 магистрантов первого курса, используют ли они LLM-модели в учебе или работе. Руку поднял только один студент. Тогда я уточнил: «Не стесняйтесь, отвечайте честно. Кто действительно использует?» — и сам поднял руку. Вслед за мной руки подняли 29 человек из 30 (предполагаю, что последний просто не услышал вопроса).
Этот пример показывает, что LLM-модели стали неотъемлемой частью жизни студентов, помогая им решать повседневные задачи. Но из-за запретов обучающиеся стесняются признаться в этом. Получается, вместо того, чтобы учить студентов правильно применять новые технологии, мы создаем у них комплекс вины и неполноценности.
Быть консерватором, конечно, можно, но прогресс не остановить. Нам нужно научиться интегрировать новые технологии в образовательный процесс, а для этого сами преподаватели должны освоить их, понять их ограничения, проблемы и возможности.
Использование LLM-моделей для решения задач на старших курсах, на мой взгляд, не только допустимо, но и должно приветствоваться. Ведь это помогает студентам освоить современные технологии и инструменты на высоком уровне и повысить производительность решения инженерных задач. Кроме того, к этому времени студенты, как правило, уже обладают тем самым опытом работы на нижнем уровне. Это позволяет им критически смотреть на полученный результат и выявлять ошибки, неточности, огрехи и другие недостатки, радикально влияющие на конечное качество работы.
Проблемы преподавателя и студента
На младших курсах, где дается фундаментальное образование, стоит избегать использования LLM-моделей. Особенно при выполнении лабораторных работ по таким дисциплинам, как, например, «Алгоритмы и структуры данных», «Введение в язык программирования Go» или «Технологии промышленной разработки веб-приложений». Здесь студенты могут получить фундаментальные знания, прочувствовать всю сложность создания программ с нуля, набить руку.
Но реальность такова, что самостоятельно выполняют работы лишь единицы. Большинство студентов либо списывают готовые решения (в вузах часто существуют «серые» хранилища лабораторных работ, собранные за годы обучения предыдущими поколениями студентов и переходящие по наследству), либо используют LLM-модели для генерации кода. При этом, на мой взгляд, использование LLM-моделей для генерации кода предпочтительнее прямого списывания. Так студент хотя бы знакомится с новой технологией, а при списывания он не получает даже этого опыта.
Использование LLM-моделей среди студентов младших курсов получило такую популярность во многом в связи с уровнем сложности практических задач, которые выдают преподаватели. К примеру, задача реализации алгоритма сортировки Шелла из курса «Алгоритмы и структуры данных» с LLM-моделью решается легко. Чего не скажешь о решении какой-либо более творческой задачи или написании курсового проекта.
Защититься от списывания преподаватель может, например, путем создания уникальных вариантов заданий, которые меняются каждый год. Но даже такая мера не спасает от использования LLM-моделей. Студент может принести работающий код, но объяснить его работу он не сможет.
Казалось бы, чтобы избежать этого, можно проводить устное собеседование по содержанию работы. Но это требует от преподавателя высокой компетентности, постоянной практики и значительных временных затрат — порядка 10–15 минут на одного студента для качественной оценки выполнения задачи. Тут и возникает проблема: если реализовать практику устных собеседований, они могут занять более 60-70% времени преподавателя (только по одной дисциплине). А ведь у нас, помимо образовательного процесса, должно оставаться время на методическую работу, научную работу и созидание.
Помимо подготовки лабораторных работ и сдачи экзаменов, студенты также используют LLM-модели при написании отчетов, научных статей, выпускных квалификационных работ. Часто они это делают для ускорения исследования, подготовки рефератной части работы, переработки текста, построения более логичных переходов, исправления синтаксических и семантических ошибок. В целом, что тут плохого? LLM-модель выступает своего рода улучшенной версией поисковой системы или профессиональным редактором, который всегда под рукой. Все это в теории повысит качество итоговой работы.
Но подсвечу важные моменты:
Студент не получает базовых навыков поиска информации по наукоемким базам данных, таким как, например, DBLP. Такие навыки, как поиск по ключевым словам, подбор правильных ключевых слов или поиск по методике «снежный ком», остаются неразвитыми. А ведь поиск ответов на основе самых разных источников некоторые считают одним из главных навыков разработчика.
Нередко, используя сгенерированный текст, студент вставляет его в отчет без изменений и добавления собственных аналитических рассуждений. В итоге мы получаем работу низкого качества.
Иногда студенты полностью полагаться на LLM-модели в проверке орфографии и пунктуации, и это играет с ними злую шутку. Ни ChatGPT, ни DeepsSeek (особенно в плане пунктуации) не застрахованы от ошибок, поэтому за ними нужно обязательно перепроверять. Особенно в случаях, где важна грамматическая точность.
На сегодняшний день существует множество систем и подходов, которые позволяют определить автоматически сгенерированный текст с использованием LLM-моделей, — например, Scribbr , QuillBot, Grammarly. Это относится только к письменным работам, но не к автоматически сгенерированному программному коду.
Студентам и преподавателям при написании отчетов, статей и ВКР нужно заранее договариваться о правилах игры в плане прохождения проверок системами «антиплагиат»: какой процент может быть автоматически сгенерированным, что считается автоматически сгенерированным, а что нет.
Вопрос проверок статей в рецензируемые журналы выходит за пределы взаимодействия преподавателя и студента. Тут уже редакция журнала должна уточнять, является ли использование LLM-моделей поводом для формального отказа к рассмотрению статьи в сборник.
Как бы то ни было, преподаватель вынужден тратить время на проверку отчетов, статей и работ через систему «Антиплагиат», выявляя полностью списанный текст. А это также существенно замедляет процесс приема работ, проверки качества усвоенных знаний и базовой, фундаментальной квалификации студента.
Получается интересный парадокс. Студенты используют LLM-модели, чтобы сэкономить свое время, а преподаватели вынуждены, наоборот, тратить больше времени, чтобы обеспечить высокое качество контроля результата и знаний обучающихся .
Давайте рассмотрим способы, которые способны повлиять на этот перекос.
Подход «горизонтального масштабирования»
По крайней мере, на сегодняшний день автоматизировать прием лабораторных работ у студентов с использованием LLM-моделей не получится. Поэтому для снижения общей нагрузки на преподавателя можно использовать подход «горизонтального масштабирования» и делегирования одновременно.
Подход подразумевает активное вовлечение студентов старших курсов (магистрантов) в образовательный процесс в рамках учебной практики. Сейчас практика в учебных планах по направлению «Программная инженерия» концентрированная, но ее можно распределить на весь учебный год (3 и 4 семестры). Это позволит официально привлекать старших студентов для проверки практических работ у младших курсов.
Этот подход мы уже применяем в Политехе в дисциплинах «Алгоритмы и структуры данных», «Технологии программирования», «Введение в язык программирования Go» и скоро внедрим в дисциплине «Технологии промышленной разработки веб-приложений».
Вижу следующие преимущества такого подхода:
Это существенно снизит нагрузку на преподавателя, сделав его дирижером образовательного процесса, а не прямым исполнителем.
Студенты старших курсов, участвуя в образовательном процессе и обучая младших студентов, лучше усвоят необходимый для них материал — качество выпускников высшей школы повысится. Ведь не зря говорят: самый лучший способ чему-то научиться — это научить другого.
Студенты младших курсов получат больше технических знаний и навыков, переданных от студентов старших курсов. Многие из них к тому времени уже получают опыт коммерческой разработки в реальных компаниях.
Старшие студенты будут строго принимать лабораторные и практические работы у младших студентов, потому что сами только что прошли все этапы жульничества («академического обмана») преподавателя. Не зря говорят, что самый строгий преподаватель — это молодой преподаватель, аспирант.
У преподавателя появятся необходимые важные навыки управления коллективом молодых преподавателей-студентов и общения с ними. В итоге это еще лучше повлияет на весь образовательный процесс.
Возможно, среди студентов старших курсов найдется талантливый студент, который захочет связать свою жизнь с преподаванием, исследовательской деятельностью и сможет раскрыться в академическом направлении.
На мой взгляд, у такого подхода есть все шансы решить проблему получения студентами начальных курсов фундаментальных знаний без кратного увеличения времени преподавателей.
Безусловно, у «горизонтального масштабирования» есть и ограничения:
Его не применить к руководству курсовыми проектами и ВКР, так как студенты старших курсов еще не обладают соответствующей квалификацией — не смогут предоставить необходимую критику и дать нужные советы.
Также подход может привести к «конфликту интересов». Например, если проверяющий студент старшего курса живет на одном этаже со своим «подопечным» и не хочет сильно озадачивать друга. Решением проблемы может стать анонимный подход к проверке работ.
Ну и, конечно, преподавателям важно транслировать одну важную мысль. Любое жульничество студента в обучении — это не обман преподавателя, а в первую очередь самообман. Ведь студент лишает себя истинного роста и развития.
Методика проверки лабораторных и практических работ
Еще один вариант проверки заданий студентов состоит из четырех шагов.
Итак, студент выполняет лабораторную или практическую работу самостоятельно. Честность выполнения работы остается на усмотрение студента, а задача преподавателя сводится к проверке конечных знаний и навыков обучающегося.
Шаг 1. Студент загружает решение в систему автоматизированного тестирования, где работа проверяется на соответствие формальным правилам. В случае непрохождения студент может повторять проверку необходимое число раз.
Шаг 2. Онлайн-проверка работы в среде автоматизированного тестирования, где преподаватель комментирует код и указывает на недочеты реализации — аналогично системе код-ревью. При этом для проведения такой оценки могут привлекаться как сами студенты-одногруппники в режиме (peer-review), так и студенты старших курсов в рамках учебной практики. Этап считается пройденным после разрешения всех замечаний к работе.
Шаг 3. Устная сдача работы. На этом этапе студент объясняет преподавателю свое решение и отвечает на теоретические вопросы по решению.
Шаг 4. Последний шаг приема работы — видоизменение кода работы при преподавателе, где студент за 5-10 минут вносит изменения в код на основе заданных требований.
Теперь расскажу о системе, помогающей реализовать как минимум два первых шага — в GitLab (аналогично и в GitHub). Ее мы, например, уже используем со студентами курсов «Введение в язык программирования Go» и «Технологии параллельного программирования на C++» в Политехе.
Реализация методики проверки лабораторных работ с использованием системы контроля версий
Ко всем практическим заданиям, которые реализуются с использованием того или иного языка программирования, сформулированы четкие технические требования — на них обращают внимание преподаватели при проверке.
Общие положения
Публикация исходного кода, автоматическое тестирование и ревью практических заданий происходят на площадке GitLab. Каждый студент создает свой fork-репозиторий (от исходного root-репозитория, выданного преподавателем), в котором ведет работу.
Для сбора артефактов выполненных работ используется root-репозиторий, в котором хранятся только сданные практические работы студентов курса. Проверку практических работ производим в два этапа: сначала автоматизированное тестирование с использованием GitLab CI/CD, затем — ручная проверка преподавателями курса.
Требования к оформлению практических работ
Название основной директории, где студент размещает свои практически работы, должно состоять из имени и фамилии студента на английском языке, написанных строчными буквами и разделенных точкой. Например, ivan.ivanov/ или anton.petrov/.
Каждая практическая работа размещается в основной директории с указанием номера этой работы. Название практической работы — task-[номер задания]. Если практическая работа включает в себя несколько подзаданий, то для каждого подзадания создается отдельная директория. Название директории для подзадания: task-[номер практической работы]-[номер подзадания]. Например, ivan.ivanov/task-1/, ivan.ivanov/task-2-1/, ivan.ivanov/task-2-2/.
Решение каждой практической работы должно содержать в себе go.mod-файл с описанием модуля. Точка входа в программу (файл с функцией main) расположена по пути cmd/service/. Если практическая работа требует реализации нескольких сервисов, каждая точка входа размещается в своей поддиректории cmd. Например, ivan.ivanov/task-1/cmd/service/main.go, ivan.ivanov/task-2/cmd/connector/main.go, ivan.ivanov/task-2/cmd/backend/main.go.
Требования к публикации работ студентов
Практические работы публикуются в root-репозитории посредством создания Merge Request (далее – MR) из fork-репозитория студента в root-репозиторий на ветку master/main root-репозитория.
За актуальность кода в HEAD master/main ветки своего fork-репозитория отвечает студент. Публикуемые работы должны содержать актуальные изменения из root-репозитория на момент отправки работы на проверку.
Сроком сдачи работы считается дата отправки MR. Если в практической работе одно задание, на нее должен быть создан только один MR. Если в работе несколько подзадач, каждое подзадание публикуется в виде отдельного MR. Чтобы внести исправления в уже сданную работу, нужно внести их в текущий MR. Каждый коммит в MR должен содержать законченные изменения и проходить автоматизированное тестирование. В названии коммита студенту следует указать номер работы в квадратных скобках и кратко описать внесенные изменений на английском языке. Например, [TASK-1] Initial commit, [TASK-1-2] Add unit tests.
Коммиты в MR не должны вносить изменения в файлы и директории, относящиеся к системе тестирования практических работ и директории с решениями других студентов.
Автоматизированное тестирование практических работ
Автоматизированное тестирование основано на прохождении GitLab CI/CD для каждого коммита в публикуемом MR. Оно состоит из четырех этапов:
Наименование этапа | Краткое описание | Шаги этапа |
Sanity | Проверка оформления работы и корректности ее публикации в рамках MR. | sanity-branch (1.2, 3.1) |
Build | Сборка всех сервисов для всех измененных практических работ в рамках MR. | sanity-student (2.1, 3.7) |
Lint | Статический анализ исходного кода практических работ, публикуемых студентом в рамках MR. В качестве инструмента статического анализа используется golangci-lint. | sanity-files (2, 3.7) |
Test | Тестирование практических работ, публикуемых студентом в рамках MR. | build |
Для шагов build, lint и test на каждую практическую работу создается артефакт с описанием результатов прохождения автоматизированного тестирования, доступный как студентам, так и преподавателям курса. Журнал событий можно использовать при ручной проверке практических работ.
Работы студентов, не прошедшие хоты бы один шаг автоматизированного тестирования, оцениваются в 0 баллов. MR закрывается с пометкой о необходимости внесения правок в решение. Апеллирование результатов автоматизированного тестирования не предусмотрено — за исключением случаев выявления ошибок в исходном коде системы автоматизированного тестирования.
Ручная проверка работ
Теперь работа допускается до ручного тестирования преподавателем, которое происходит после каждой лекции в рамках практического занятия. Очередь проверки формируется на основе времени открытия MR. Комментарии и оценки за решение также фиксируются в MR по факту окончания сдачи работы на практическом занятии.
Если работа решена некорректно, MR закрывается с пометкой о необходимости внесения правок в решение. Если у решения есть недочеты, выявленные при ручной проверке, работа может быть закрыта после публикации исправлений в MR в рамках код-ревью по решению преподавателя. При этом оценивание практической работы может быть оспорено в рамках этапа код-ревью — в ходе дискуссии между студентом и преподавателем. В целом, преподаватель может вовсе отказаться от ручной проверки работы.
Если автоматизированное и ручное тестирование пройдены, работа считается принятой, а MR с исходным кодом решения добавляется в root-репозиторий.
Общие рекомендации применения LLM-моделей в образовании
Я также сформулировал некоторые общие рекомендации по тому, как, на мой взгляд, можно контролировать негативное влияние использования LLM-моделей и в итоге сделать их своими союзниками.
В образовательном процессе
Признать, что запретить студентам использование LLM-моделей невозможно.
Учить студентов на первом курсе по строго выработанной методике (которую еще нужно выработать), подчеркивая, что использование LLM-моделей в решении проверочных работ допустимо, но не на младших курсах (до третьего курса включительно). Поскольку на младших курсах нужно получить базовые знания и фундаментальные навыки.
Переосмыслить подход к формулированию практических заданий на младших курсах так, чтобы их решения не брались «в лоб» с использованием LLM-моделей. Возможно, за счет повышения сложности заданий или их творческой постановки.
Разрешить и поощрять использование LLM-моделей только на старших курсах, а также говорить о целесообразности применения этих технологий и анализе результатов применения.
Не нужно быть ретроградом. Следует использовать все возможности, которые предоставляют наука и технологии для более быстрого развития.
В проверке практических работ
Внедрить автоматическую проверку лабораторных работ через системы контроля версий с поддержкой CI, где работы будут проходить автотесты. Только после этого студент допускается к устной защите.
Проводить устное собеседование, чтобы убедиться, что студент понимает демонстрируемое им решение.
Внедрить лайвкодинг: просить написать кусочек кода, улучшив существующее решение прямо в момент сдачи.
Внедрять решения анализа логов систем, которые используют студенты в процессе выполнения заданий. Это позволит визуализировать, как студент выполнял работу, и понять, не списывал ли ее. Возможно, написать расширение для IDE и проверять отсутствие больших кодовых вставок (хитрый валидатор, учитывающие источник вставки и т.д.), можно даже сделать AI-агента. И кажется, разработка такого расширения может стать отличной темой для студенческого ВКР по направлению «Программная инженерия».
Во многом спорная опция, но она тоже приходит в голову как решение. Можно сопровождать сдачу лабораторных работ ускоренной видеозаписью экрана, которая демонстрирует самостоятельный процесс разработки кода. Опытный преподаватель, посмотрев процесс реализации лабораторной работы, может дать комментарии студенту по эффективности использования средств разработки, таких как IDE, отладчики и профилировщики, системы мониторинга утечек памяти и подобных.
Понимаю, что последний подход, скорее всего, вызовет шквал негодования. Ну и, конечно, может привести к новым способам академического жульничества. Также камера очень нервирует и может отрицательно сказаться на качестве выполнения работы.
В процессе написания курсовых работы и ВКР
Подчеркивать, что LLM-модели могут помочь в написании курсового проекта, но при этом студент должен уметь эффективно объединять различные маленькие кусочки когенерации в единое целое, а также отразить в работе свой опыт и знания.
При написании выпускной квалификационной работы (ВКР) призывать студента разрабатывать черновой текст самостоятельно. При использовании больших языковых моделей для генерации текста или кода просить добавить специализированный раздел с описанием особенностей применения LLM-модели в своей работе — методику применения и выявленные ограничения. Это позволит студенту сделать применение LLM-моделей осознанным, а преподавателю даст честную обратную связь о трудностях, ограничениях и тонкостях применения новых технологий.
Преподавателям
Не гнушаться использования LLM-моделей в работе и повседневной жизни. Так вы сами сформируете опыт работы с ними, будете лучше понимать студентов и сможете учить их пользоваться ими правильно. Этот совет актуален для всех направлений, не только для разработки программного обеспечения.
Внести предлагаемые требования к выполнению работ и критерии оценки их результатов в рабочие программы дисциплин (РПД). Это сделает взаимодействие студента и преподавателя в части применения LLM-моделей более строгим и формальным.
На мой взгляд, применение этих рекомендаций позволит воспитать у студентов более осознанный подход к обучению, при этом не взращивая в них комплекс вины за использование LLM-моделей или страха делиться успешным опытом работы с ними. Ведь главная задача образования — не просто передать знания, а подготовить студентов к жизни в быстро меняющемся мире, где критическое мышление, адаптивность и понимание технологий играют ключевую роль.
Вместо заключения
В завершение признаюсь, что при написании этой статьи я использовал DeepSeek. Эта LLM помогла мне расширить изначальный черновик статьи, добавить туда необходимых теоретических деталей и логичные переходы. Безусловно, я не бездумно использовал результаты вывода моделей, а проводил их редактуру. По грубым подсчетам я сэкономил себе примерно 7 часов на подготовке этой статьи. До ее финальной редактуры, результат который вы видите на Хабре, процент сгенерированного текста составил 7% от общего объема статьи.
Я поделился этим, чтобы еще раз повторить основной посыл статьи. Важно не запрещать использование таких современных технологий, как LLM-модели и AI-агенты, в образовательном процессе, а адаптироваться — контролировать качество усвоенных знаний с учетом возможного разрушительного для студента использования LLM и обучать его правильному использованию этой технологии.
Важно сфокусироваться на подготовке таких специалистов, которые могут создавать свои собственные передовые технологии, а не просто быть пользователями этих систем. Чтобы в будущем мы не оказались в этом меме.
Список дополнительных источников
Статья 2023 года — Large Language Models: A Comprehensive Survey of its Applications, Challenges, Limitations, and Future Prospects
Статья A survey on the application of large language models in software engineeringв журнале Computer Research and Modeling
Статья Large Language Model-Based Agents for Software Engineering: A Survey
Статья AI Agents Under Threat: A Survey of Key Security Challenges and Future Pathways (2024 год)
Статья A Survey of Hallucination Problems Based on Large Language Models в журнале Applied and Computational Engineering
Назаров Д. М., Применение больших языковых моделей в образовательном процессе
Дешина Л. А., Цифровые инструменты как драйвер в медицинском образовании
И. В. Никифоров, О. А. Юсупова, Н. В. Воинов, А. Д. Ковалев, «Методы, алгоритмы и архитектуры распределенной обработки больших данных — Санкт-Петербургский политехнический университет Петра Великого, 2023
Статья Analysis of student activity on the e-learning course based on "OpenEdu" platform logs
