Comments 9
Превратить вопрос человека в корректный SQL
Легко решается: все мои человеческие запросы это сразу SQL. Потому что SQL простой как палка
Ну-ну... Ползаешь, бывало, по SQL на 4 тыс строк и собираешь концы..
Это всё равно что признаться что в вашем проекте на императивном языке (типа Питона) есть функция на 4 тыс строк и вы считаете это нормальным
Был у меня такой случай. Запросил как-то у LLM: "Имеются таблицы приходов и расходов со структрой такой-то.... Составь SQL для получения данных о реализации диванов за последний месяц"
Вернул запрос на получение данных из таблицы приходов.
Уточняю у LLM, почему реализация - это приход? Отвечает: "Реализация - это поступление выручки - т.е. данные берем из таблицы приходов"
LLM отлично транслирует текст с одного языка в другой, но смысл текста может измениться, и нам ещё нужно научиться работать с данным инструментом в реальх задачах.
Некоторые популярные модели некорректно предлагают простейшие запросы: "Имеются таблицы приходов и расходов номенклатуры на складе, сформируй SQL расчета остатков на складе на указанную дату" - отличный вопрос для собеседования.
Добрый день! Спасибо за интересную статью.
Как вы считаете, в чем преимущество SQL-of-thought над ручным написанием SQL запросов?
100% точности здесь, кажется, добиться крайне трудно. Таким образом любой сгенерированный SQL запрос в любом случае необходимо проверять вручную, а значит - обладать значительными знаниями SQL.
Таким образом, я не вижу экономии времени (нужно перепроверять сложные запросы а простые быстрее написать на sql чем оформлять промпт) и не вижу возможности людям без знаний SQL пользоваться Text-to-SQL поскольку это банально опасно для бизнеса.
Т.е. LLM-мам до написания кода на процедурном языке plpgsql ещё как до луны пешком?
Почему Text-to-SQL до сих пор ломается и как это исправить