Why Text-to-SQL so hard?
Text-to-SQL выглядит очень простой идеей: пользователь пишет вопрос обычным языком, система превращает его в SQL и возвращает ответ. С ростом чат-интерфейсов стало очевидно, что формулировать вопросы текстом людям проще и привычнее, чем кликать поля в BI или писать запросы вручную. Поэтому почти все современные BI-инструменты пытаются встроить такой интерфейс.
Проблема в том, что естественный язык изначально неточный. Люди постоянно опускают контекст, используют расплывчатые формулировки и подразумевают вещи, которые понятны им самим, но не формальной системе. «Продажи», «последний месяц» или «праздник» могут означать разные вещи в зависимости от компании, страны или даже команды. Человек в такой ситуации задаст уточняющий вопрос, а модель вынуждена интерпретировать запрос в одиночку и часто делает это неверно.
Вторая проблема - реальные корпоративные базы данных. Они редко бывают аккуратно смоделированными. В них несколько версий одной и той же метрики, неочевидные связи между таблицами, исторические костыли и бизнес-логика, которая существует только в головах людей. Даже опытные дата-инженеры тратят месяцы, чтобы разобраться, какие таблицы и расчёты «правильные». Ожидать, что модель, не знающая контекста компании, сможет стабильно писать корректные запросы, довольно наивно.
Наконец, text-to-SQL - это не просто перевод из одного языка в другой. Один и тот же текстовый вопрос может быть корректно выражен десятками разных SQL-запросов. При этом SQL строгий, чувствителен к диалекту, плохо прощает ошибки и легко превращается в нечитаемый и неоптимальный код. В результате модели либо галлюцинируют поля и таблицы, либо генерируют рабочие, но неправильные или неэффективные запросы.
Заметно улучшить ситуацию помогает семантический слой. Он фиксирует бизнес-понятия, определения метрик и связи между сущностями, скрывая сложность физической схемы данных. В таком подходе модель больше не пытается понять устройство базы данных и не гадает, как именно считается тот или иной показатель. Она оперирует заранее определёнными бизнес-концепциями, а это резко снижает неоднозначность.
Хороший пример - подход Holistics. Вместо того чтобы генерировать SQL напрямую, они используют промежуточный аналитический язык AQL, построенный поверх семантического слоя. Модель переводит текстовый запрос в AQL, а уже система конвертирует его в SQL. Это означает, что модель описывает намерение на уровне бизнеса, а не работает с низкоуровневым языком запросов. Такой результат проще проверить человеку, сложнее «сломать» и легче контролировать с точки зрения бизнес-логики и доступов.
Главный вывод здесь в том, что проблемы text-to-SQL связаны не столько с качеством моделей, сколько с тем, что мы пытаемся заставить их работать на слишком низком уровне абстракции. Без семантического слоя и явных бизнес-определений любой прямой перевод текста в SQL будет хрупким. Более правильное решение - сначала зафиксировать смысл и намерение, а уже потом превращать их в исполняемый запрос.
Оригинальный текст с подробным разбором и примерами.
@five_minutes_of_data
Text-to-SQL выглядит очень простой идеей: пользователь пишет вопрос обычным языком, система превращает его в SQL и возвращает ответ. С ростом чат-интерфейсов стало очевидно, что формулировать вопросы текстом людям проще и привычнее, чем кликать поля в BI или писать запросы вручную. Поэтому почти все современные BI-инструменты пытаются встроить такой интерфейс.
Проблема в том, что естественный язык изначально неточный. Люди постоянно опускают контекст, используют расплывчатые формулировки и подразумевают вещи, которые понятны им самим, но не формальной системе. «Продажи», «последний месяц» или «праздник» могут означать разные вещи в зависимости от компании, страны или даже команды. Человек в такой ситуации задаст уточняющий вопрос, а модель вынуждена интерпретировать запрос в одиночку и часто делает это неверно.
Вторая проблема - реальные корпоративные базы данных. Они редко бывают аккуратно смоделированными. В них несколько версий одной и той же метрики, неочевидные связи между таблицами, исторические костыли и бизнес-логика, которая существует только в головах людей. Даже опытные дата-инженеры тратят месяцы, чтобы разобраться, какие таблицы и расчёты «правильные». Ожидать, что модель, не знающая контекста компании, сможет стабильно писать корректные запросы, довольно наивно.
Наконец, text-to-SQL - это не просто перевод из одного языка в другой. Один и тот же текстовый вопрос может быть корректно выражен десятками разных SQL-запросов. При этом SQL строгий, чувствителен к диалекту, плохо прощает ошибки и легко превращается в нечитаемый и неоптимальный код. В результате модели либо галлюцинируют поля и таблицы, либо генерируют рабочие, но неправильные или неэффективные запросы.
Заметно улучшить ситуацию помогает семантический слой. Он фиксирует бизнес-понятия, определения метрик и связи между сущностями, скрывая сложность физической схемы данных. В таком подходе модель больше не пытается понять устройство базы данных и не гадает, как именно считается тот или иной показатель. Она оперирует заранее определёнными бизнес-концепциями, а это резко снижает неоднозначность.
Хороший пример - подход Holistics. Вместо того чтобы генерировать SQL напрямую, они используют промежуточный аналитический язык AQL, построенный поверх семантического слоя. Модель переводит текстовый запрос в AQL, а уже система конвертирует его в SQL. Это означает, что модель описывает намерение на уровне бизнеса, а не работает с низкоуровневым языком запросов. Такой результат проще проверить человеку, сложнее «сломать» и легче контролировать с точки зрения бизнес-логики и доступов.
Главный вывод здесь в том, что проблемы text-to-SQL связаны не столько с качеством моделей, сколько с тем, что мы пытаемся заставить их работать на слишком низком уровне абстракции. Без семантического слоя и явных бизнес-определений любой прямой перевод текста в SQL будет хрупким. Более правильное решение - сначала зафиксировать смысл и намерение, а уже потом превращать их в исполняемый запрос.
Оригинальный текст с подробным разбором и примерами.
@five_minutes_of_data