PGConf.Академия 2026

В докладе рассматривается применение генеративного ИИ для создания вариативных практических заданий по МДК 11.01, аналогичных модулям демо-экзамена по специальности 09.02.07. Представлены подходы к генерации заданий по нормализации, SQL-запросам, триггерам и хранимым функциям на основе демонстрационных баз Postgres Pro. Приведены результаты апробации, демонстрирующие сокращение времени разработки заданий в 10 раз при сохранении высокого качества обучения и успеваемости студентов (95.2% правильных ответов). Даны практические рекомендации по внедрению ИИ-инструментов в учебный процесс.

На практических занятиях по базам данных важно не только получить правильный ответ, но и иметь возможность проверить гипотезу, ошибиться и повторить эксперимент. Для этого студенту нужна изменяемая база с известным исходным состоянием, а преподавателю — возможность воспроизвести решение в тех же условиях. Рассмотрим организацию таких практикумов по PostgreSQL с помощью Taidon — открытого инструмента подготовки и повторного использования состояний баз данных. SQL-рецепт задаёт исходную схему и данные; подготовленное состояние используется для создания отдельных изменяемых экземпляров. Эксперименты не изменяют сохранённую исходную точку, поэтому новую попытку можно начать с неё, не повторяя уже выполненную подготовку при наличии состояния в кэше. На примере учебной базы покажем цикл лабораторной работы: подготовку задания, изменение данных и схемы, повторный запуск с исходного состояния и воспроизведение решения преподавателем. Обсудим разделение рецепта подготовки, студенческого решения и проверок, использование привычных PostgreSQL-клиентов, а также границы воспроизводимости и требования к локальному окружению. Основное внимание уделим методике организации эксперимента; устройство кэша и снимков рассмотрим лишь в объёме, необходимом для понимания возможностей и ограничений инструмента. Доклад адресован преподавателям баз данных и разработчикам практикумов, которым нужны повторяемые задания с полноценным PostgreSQL, включая изменение данных, схемы, функций и триггеров.

Статья посвящена разработке учебного практикума по диагностике блокировочной деградации в PostgreSQL 18. Его цель — дополнить изучение механизма транзакций наблюдением за поведением СУБД при конкурентной нагрузке. В практикуме воспроизводятся четыре типа конфликтов: конкуренция за «горячую» запись, широкий UPDATE с вложенным SELECT, DDL-блокировка и взаимоблокировка. Для локализации используются pg_stat_activity, pg_locks и pg_blocking_pids(), а влияние оценивается по TPS, p99, p99,9 и динамике очереди ожиданий. Техническая воспроизводимость проверена в 75 прогонах — по 15 для baseline и каждого конфликтного режима. Среднее парное отношение TPS сценария к TPS baseline составило 0,066 для hotspot, 0,243 для широкого UPDATE и 0,221 для DDL. В сценарии широкого UPDATE средняя p99,9 достигла 817 мс против 23 мс в baseline, а очередь наблюдалась в 77,8% снимков. Результаты подтверждают пригодность сценариев для воспроизводимой демонстрации связи между блокировками и деградацией производительности; оценка образовательного эффекта требует отдельного исследования.

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