Комментарии 14
Спасибо за статью. Мы сейчас трудимся над схожей задачей. Только для упрощения сделали результирующая таблицу, чтобы не утонуть в дебрях сложных структур связей таблиц. Несколько мыслей по вашей статье:
1.
После генерации ответа модели мы парсим его для выделения только SQL-кода, затем этот запрос проверяем на корректность при помощи sqlglot
Это можно делать за счет самого же промта. В конце просто просим убрать все лишнее из ответа, кроме sql запроса и проверить еще раз сам sql запрос на синтаксис. ChatGPT с этим справлялся отлично. Одно из основных правил формирования промта - проверь себя в конце выполнения.
2. DDL это хорошо, мы тоже такие рекомендации много раз встречали, но это не всегда помогает с пониманием связей таблиц у ИИ. Куда более эффективно - это описание таблиц в виде json. Где описываются признаки поля (тип данных, атрибут, ключ и т.д.), текстовое описание смысла этого поля (какие данные там хранятся), пример данных, связи этого поля с другими полями из других таблиц. Такое описание в промте показало максимальный результат.
3. Для ChatGPT есть много плагинов, которые обещают разобраться со структурой базы и построить корректный sql запрос, но они в бОльшистве случаев полагаются только на таблицу со схемой. Но она не всегда заполняется и не полностью. Поэтому мы снова приходим к самостоятельному формирования описания.
4. Объемы промта вырастают до гигантских размеров за счет всех описаний. Стоимость таких запросов не оправдывает пользу, по крайней мере сейчас и для нас. Поэтому мы тоже засматриваемся на опенсорс модели, но пока не решаемся залезть в эти дебри. Но благодаря вашей статье видим, что это вполне достижимо) Здорово, что отечественные решения пытаются использовать трамплин в виде того же chatgpt, чтобы прыгнуть еще дальше.
Спасибо за интерес к тематике и идеи!
1. Мы выбрали "алгоритмический" способ по следующим причинам - это скорость ответа и корректность 100%( там точно есть баги, просто мы еще их не поймали ). И как бонус - это diff AST двух sql и конвертация из одного синтаксиса в другой.
2. Спасибо, мы используем всю информацию как Вы описали и это действительно очень помогает, только не в формате json, возможно не указали это явно в статье.
4 Да, объемы большие, и даже после "фильтрации" только нужных колонок и/или таблиц из векторной БД для больших БД контекст может быть все равно огромным. Сейчас пробуем применить подходы похожие на такие - https://arxiv.org/pdf/2312.03463v1.pdf
И к слову - на прошлой неделе запустили бенчмарк text2sql на GigaChat PRO и он "из коробки" на некоторых тестах показал точность ~80%.
Подскажите, а сильно результат бенчмарков зависит от сложности схемы данных? Предположим будет схема, в которой 40 таблиц и в совокупности 300 колонок. Видите перспективу добиться адекватных результатов в подобных случаях?
Задача однозначно сложная и сейчас под такую БД нужно подстраиваться. Как один из вариантов - дообучить модель на нужной БД, например, если есть примеры вопрос<->sql. Или можно попробовать загрузить все в векторную БД и при запросе подгружать в промпт модели только семантически похожие примеры вопрос<->sql и семантически схожие таблицы и описание этих таблиц/колонок, примеры занчений итд.
p.s в целом сейчас можно сгенерировать пары sql<->вопрос с помощью LLM и автоматом обучать модель под конкретную БД, но пока такой подход для сложных БД работает средне(как пример можно посмотреть тут - https://github.com/Dataherald/dataherald/tree/main/dataherald/sql_generator )
Спасибо за статью. У меня только один пока вопрос - сколько часов сотрудников было использовано на эксперименты в рамках описанных выше работ?
"Для SQL на лёгких и средних запросах мы добились точности 60+ %."
Представим, что добились точности 99,99%. В чем здесь цель задачи для бизнеса? ( на первый взгляд тривиальный вопрос).
Мы постарались ответить на этот вопрос в первой части - "Будущее BI? Или уже настоящее?". И задача text2sql это просто одна из списка задач. Как пример, можно посмотреть видео от Copilot in Power BI Demo
Мне кажется, самое сложное в задаче text2sql — это поиск в базах данных со свободным вводом. В статье вы говорите про это, приводя пример 'мужчина/женщина или male/female'. 1) Могли бы вы рассказать, как вы реализуете этот поиск? 2) Можно ли гипотетически добиться результата в 99% правильных ответов, если одно и то же значение легко может находиться в двух или более столбцах?
Не уверен, что правильно понял вопрос, но попробую ответить. Для определения, какие значения хранятся в поле "пол" есть несколько способов - один из них использовать различные агенты, которые имеют прямой коннект к БД и в любой момент могут получить список таблиц/бд/колонок, примеры значений итд (например, https://python.langchain.com/docs/integrations/toolkits/sql_database )
Второй способ - заранее просканировать БД и собрать примеры данных и категории ( все встречающиеся значения в колонке, например - м и ж).
2) В целом не стоит забывать о возможности диалога и возможности уточнить ( если вариантов более одного). Лично мое мнение - что в ближайший 1-2 года можно будет получить точность 95%+ на больших и сложных БД. Просто 99% - это довольно много и в больших БД часто на вопрос можно ответить по-разному, например, у "Data Engineers + DB Students" - точность 93% https://bird-bench.github.io/
Вы правильно меня поняли, но, мне кажется, проблема сложнее.
Мы отказались от первого варианта, потому что в колонке может быть слишком много значений. Возможно, стоит запрашивать количество, и, если оно находится в приемлемом коридоре, передавать в контекст. Однако, поскольку этот вариант не покрывает все случаи, мы пока что остановились на поиске без регистра. GPT хорошо обрабатывает склонения и в целом часто делает правильные предположения о том, где может находиться значение. Но здесь тоже есть некоторые проблемы.
Во-первых, когда делают поиск по словосочетанию "найди все платежи от Альфа-Банка", пользователь на естественном языке не ставит дефис, и мы не можем найти это в базе. Во-вторых, представьте, что у нас есть колонки "контрагент" и "организация", и там и там может храниться ООО, и GPT может запросить не тот столбец.
Скажите, рассматривали ли вы варианты поиска:
1) нечеткую логику (pg_trgm в Postgres)
2) полнотекстовый поиск?
По-моему, без решения этой проблемы невозможно достичь 95 процентов правильных ответов.
Как раз с ИИ это сейчас повышает шанс поиска таких значений. Что интересное я заметил: ИИ старается стоить логические выводы (причем почти всегда точные), если не находит прямого ответа на критерии поиска.
Я просил отобрать из таблицы всех физ лиц. У меня в таблице было отдельный столбец содержащий именно этот признак (столбец содержал только значения "физические лица" и "юридические лица"). НО, как оказалось в дальнейшем, ИИ не доходил до этого поля, ввиду ограничений в 50 строк (это не очень афишируется, то он на самом деле имеет ограничение в таблице в 50 строк в одной запросе). Так вот, чтобы компенсировать отсутсвие прямого ответа на запрос про физ лица, он брал поле "Наименование Контрагента" и строил запрос where Name_KA NOT LIKE %ООО%, Name_KA NOT LIKE %ОАО% и т.д.) Поэтому с свободным вводом как раз будет все проще с ИИ, в отличии от алгоритмических методов, на мой взгляд.
Вот еще интересный проект/исследование на эту тему https://github.com/vanna-ai/vanna/blob/main/papers/ai-sql-accuracy-2023-08-17.md
Возможно для улучшения этих результатов имело бы смысл научиться сначала подходам - как строить модели данных, с нормализацией/денормализацией, с учетом частот запросов, объемов данных итп.
Разговариваем с BI на естественном языке