O1 в помощь дата-инженеру: может ли ИИ написать сложный SQL-запрос

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

o1 — думающая модель от OpenAI, представленная в сентябре 2024. Ее главная особенность в том, что она «размышляет» над своими ответами и строит цепочки рассуждений (отсюда и название). Это позволяет ей справляться с логическими и математическими задачами, ревьюить и писать код и SQL-запросы. Ее ответы должны быть более глубокими и логичными, чем у более простых моделей, с меньшим числом ошибок и галлюцинаций. 

За использование модели надо заплатить. Для подписчиков тарифа Plus за 20 долларов в месяц доступно ограниченное число запросов в неделю, подписчики Pro за 200 долларов, могут пользоваться o1 без ограничений. 

Мы с командой решили проверить качество работы o1 на примере из нашей практики — взяли реальную задачу из одного из кейсов и предложили модели ее решить. Задачу специально искали небанальную, с объединением данных из нескольких таблиц и оконными функциями. 

Суть задачи

У нас есть две таблицы. Из первой нужно убрать дубликаты в колонке uid и достать все значения по ключу yid из колонки с датой — если uid есть несколько одинаковых значений, то взять те, которые добавлены раньше всего по колонке happened_at. 

Из второй таблицы нужно также убрать дубликаты из client_id, а также взять данные из колонок device_category, operating_system_root, browser. Если значений в client_id несколько, нужно взять добавленное раньше, ориентируясь на данные из колонки date_time. 

В конце результаты обоих запросов нужно объединить. 

Попытка 1

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

Дата-инженер написал вот такой запрос:

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

Чтобы o1 смогла взяться за задачу, нужно подробно описать ее в промпте: 

«Нужно написать 2 sql запроса и потом смержить результаты между собой:

Первый запрос — таблица prod_events_fdw.events, из колонки uid убрать дубликаты (т.е. сделать уникальными), из колонки «data» которая в формате jsonb достать значения по ключу ‘yid’ и убрать все не цифровые символы — если по uid несколько одинаковых значений то брать по самой первой дате из колонки happened_at — привести колонку к типу данных varchar(50) и назвать колонку yid, также не включать в перечень строки в которых значение ‘yid’ равен NULL или пустой строке » и колонка title должна быть равна значению ‘register’. В результате должны быть колонки uid и yid.

Второй запрос — таблица yandex_metrica.sessions_stats, из колонки client_id убрать дубликаты (т.е. сделать уникальными), использовать колонки device_category, operating_system_root, browser — также для этих колонок если в client_id несколько одинаковых значений то брать по самой первой дате из колонки date_time, также не включать в перечень строки в которых client_id равен NULL или пустой строке » и колонка goal должна быть равна значению ‘JS ЛК’. В результате должны быть колонки client_id, device_category, operating_system_root, browser.

Вынести оба запроса в табличное выражение CTE и назвать showcase_prod_yid и showcase_metrics_client_id соответственно. Смержить эти запросы по колонкам yid и client_id и в выводе вывести колонки uid, client_id, device_category, operating_system_root, browser»

Модель в ответ выдала свой вариант запроса: 

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

Сравнение результатов

Вот,  что получилось у инженера:

А вот — что у o1:

Видите разницу? У o1 итоговая таблица на 2 строчки короче, чем у инженера. 

Из-за чего это могло произойти, если задача была подробно и корректно описана в промпте, а ИИ выдал жизнеспособный код? Причина становится ясна, если присмотреться к результатам и SQL-запросу от o1 повнимательнее — тогда станет понятно, что все дело в небольшом отличии  в логике выполнения запросов. 

В первом случае вначале отрабатывает блок where, где мы убираем пустые строки и Null, и только потом — оконная функция.

Во втором случае сначала происходит отбор каждого uid, а уже потом — только самых первых значений. Если они равны null или пустой строке, они убираются.

Наша догадка подтверждается, если посмотреть, какие данные «пропали» из выдачи:

Попытка 2: уточняем запрос

Когда мы нашли причину ошибки, мы решили дополнить запрос, чтобы ИИ доработал свой код:

«Я тебя попросил «если по uid несколько одинаковых значений то брать по самой первой дате из колонки happened_at» и «также для этих колонок если в client_id несколько одинаковых значений то брать по самой первой дате из колонки date_time», но можешь учесть момент что если первая дата была со значением null или пустой строкой, то брать следующее не пустое значение, то есть брать не первое значение во все, а первое не пустое или null значение для этих двух запросов».

В ответ модель сгенерировала еще более громоздкий код: 

Зато результат он выдает корректный: 

Попытка 3: c GPT-4o

GPT-4o — мультимодальная модель, также представленная OpenAI, но уже в мае 2024. Она доступна всем пользователям даже без подписки. Хотя она и не умеет размышлять над своими ответами, как o1, она тоже хорошо справляется со сложными задачами на логику, решает математические задачи и пишет код. 

В ответ на точно такой же запрос GPT-4o предложила корректный и даже не такой громоздкий код, как у o1:

Выводы

Можно ли сказать, что o1 изначально не справилась с задачей? Не совсем — мы же сами написали в промпте: «если по uid несколько одинаковых значений то брать по самой первой дате из колонки happened_at». Она и сделала, как просили. 

Когда такие сложные запросы пишет человек, он принимает во внимание внутренний контекст, который не может предугадать и учесть нейросеть. И даже в самом подробном промпте сложно перечислить все возможные тонкости. Из-за этого даже с очень четкими и детальными инструкциями, модель выдает рабочий, но не всегда оптимизированный или читабельный код. «Продвинутость» модели тоже не гарантирует идеальный результат — это мы видим по сравнению o1 и 4o, где менее мощный ИИ справился лучше. 

Возникает вопрос — зачем тратить время на написание длинного и сложного промпта, если можно вместо этого сразу взять и написать логичный и оптимизированный код самостоятельно? 

На данном этапе развития более удобным вариантом кажется использовать ИИ для создания написания маленьких кусков кода, которые легко проверить и отдебажить. Это поможет сэкономить время и при этом избежать досадных ошибок.