Это был полный провал. 
Использование Discourse AI - AI Bot
Запрос
Создайте изображение для этого SQL ``` WITH pairs AS ( SELECT p.user_id liked, pa.user_id liker FROM post_actions pa LEFT JOIN posts p ON p.id = pa.post_id WHERE post_action_type_id = 2 ) SELECT liker liker_user_id, liked liked_user_id, count(*) FROM pairs GROUP BY liked, liker ORDER BY count DESC LIMIT :limit ```
Результат
К вашему сведению
Вчера из любопытства я выполнил поиск в Google, похожий на этот:
SQL, сгенерированный ИИ на основе английского языка
чтобы найти соответствующую информацию о генерации SQL с помощью ИИ на основе вопросов на английском языке. Я надеялся увидеть в списке исследовательские работы, но список в основном состоял из приложений. Один паттерн, который я быстро заметил для многих перечисленных приложений (но не для всех), просмотрев несколько демо-версий на таких сайтах, заключался в том, что они использовали свои существующие инструменты, позволяющие пользователю выбирать таблицы и поля для построения SQL-запроса, подобно тому как работает визуальный конструктор SQL в Microsoft Access, в качестве отправной точки. Другими словами, пользователь не начинал с вопроса на английском языке, а сначала должен был выбрать таблицы, а иногда и поля, и только затем вводить вопрос на английском. Хотя я бы не назвал это обманом, это означает, что для использования такого ИИ пользователь должен обладать некоторыми знаниями SQL, в частности, пониманием того, что такое таблица и поле, чтобы инструмент мог работать.
Я прочитал ваш удалённый пост и согласен, что это тоже одна из идей, которая, на мой взгляд, обладает большим потенциалом.
Однако я считаю, что ей нужно больше. Недавно я прочитал статью (опять же, не являющуюся авторитетным источником), которая раскрывает эти идеи более подробно:
«ChatLogo: A Large Language Model-Driven Hybrid Natural-Programming Language Interface for Agent-based Modeling and Programming» (ЧатЛого: Гибридный интерфейс естественного и программируемого языка, управляемый большой языковой моделью, для агентного моделирования и программирования) авторства Джона Чена и Ури Виленски (pdf)
Некоторые ключевые выводы для меня:
- Поддержка начинающих программистов в «общении с компьютерами» на смеси языков программирования и естественного языка.
- Предоставление более дружелюбного интерфейса для учащихся без базовых знаний в области информатики, позволяющего им творчески самовыражаться через программирование компьютеров.
- Вместо того чтобы сразу писать код и давать инструкции, ChatLogo стремится прояснить потребности и намерения учащихся.
- Вместо того чтобы отправлять большие объёмы кода напрямую учащемуся, система пытается совместно разрабатывать код NetLogo. Учащийся свободен редактировать код: либо в NetLogo, либо на естественном языке через функцию «Ask» (Спросить).
- Вместо того чтобы преувеличивать правильность кода, система признаёт возможность ошибок и совместно с учащимся работает над устранением потенциальных проблем.
Мне не удалось найти исходный код или более подробную информацию о том, как Chat был встроен в NetLogo или взаимодействовал с ним, но сами по себе эти идеи уже представляют ценность.
Это снова напоминает мне, как работают автопилоты в самолётах, и книгу, которую я упоминал ранее (ссылка). Когда я говорю об автопилоте, не думайте о бинарном переключателе; думайте о всех ручках и переключателях, которые передают информацию автопилоту, сообщая ему, что делать, а чего не делать.
Хотя кажется, что многие другие инструменты, подобные этому, любят использовать слово copilot (сопилот), например, поиск Google по запросу llm copilot source code, я склонен не соглашаться с этой аналогией, но мне придётся с этим смириться, поскольку именно так можно найти связанные идеи.
Я удалил его, потому что подумал, что нашёл лучший способ решения проблемы — зачем вводить все эти таблицы вручную, если можно просто попросить ChatGPT проанализировать файл, размещённый в интернете, который содержит подробную информацию обо всей базе данных? Однако оказалось, что у такого подхода есть технические проблемы. Поэтому я возвращаюсь к тому, что предлагал в удалённом посте. В любом случае, описания таблиц, примеры запросов и т. д. всё равно придётся создать. Вопрос лишь в том, как передать эту информацию большой языковой модели (LLM). Вот как обстоят дела с GPT-4:
Да, предложенный вами подход имеет смысл и является жизнеспособным способом использования моих возможностей для помощи в генерации SQL-запросов на основе вопросов на естественном языке.
Вот пошаговое описание процесса:
- Интерпретация вопроса: Пользователь задаёт вопрос на естественном языке, который я анализирую, чтобы понять запрашиваемую информацию.
- Идентификация таблиц: На основе вопроса и списка всех таблиц в базе данных Discourse я определяю таблицы, которые, скорее всего, будут наиболее релевантны для запроса.
- Подробная информация о таблицах: Discourse предоставляет мне подробные описания соответствующих таблиц, включая все столбцы и примеры запросов.
- Генерация запроса: Используя подробную информацию о таблицах, я генерирую SQL-запрос, который отвечает на вопрос пользователя.
Этот подход использует мою способность понимать естественный язык и сопоставлять его со структурированными запросами к данным. Он также эффективно использует подробную информацию о таблицах, предоставляемую Discourse.
Что касается альтернативных подходов, одним из вариантов могло бы стать обучение модели специально на схеме базы данных Discourse и распространённых шаблонах запросов. Это, вероятно, потребовало бы значительных усилий и может оказаться неосуществимым в зависимости от доступных ресурсов. Однако такой подход потенциально мог бы привести к более точной и эффективной генерации запросов.
Другой вариант — разработать более интерактивный диалог, в котором я задавал бы уточняющие вопросы, если вопрос пользователя неоднозначен или если несколько запросов потенциально могли бы ответить на него. Это сделало бы процесс более интерактивным и могло бы привести к более точным запросам.
Из альтернативных подходов, упомянутых в последних двух абзацах, я игнорирую первый, но если то, что я пытаюсь сделать, не приведёт к надёжным результатам, это может быть тем, на что стоит обратить внимание команде Discourse.
Я спросил GPT-4 о втором альтернативном подходе. Он достаточно уверен, что, получив вопрос, на который нельзя ответить с помощью предоставленной структуры таблиц, он сможет побудить пользователя переформулировать свой вопрос.
Итак, я снова возвращаюсь к написанию описаний всех таблиц в базе данных Discourse. Теперь я знаю, для чего используется таблица allowed_pm_users. Таблица ar_internal_metadata немного сбивает с толку, но, думаю, её пока можно проигнорировать.
На данный момент это мой любимый вариант, хотя его реализация крайне сложна. Как вы уже догадались, это ещё одна статья. Опять же, это не авторитетная работа, так как существует множество аналогичных подходов.
“DiagGPT: LLM-чатбот с автоматическим управлением темами для диалогов, ориентированных на решение задач” от Ланга Цао (pdf)
Просто замените медицинскую информацию на информацию о PostgreSQL по мере необходимости. Приятно то, что в статье приведены промпты и предложено, какие инструменты и агенты использовать.
Поскольку то, что требуется, — это Task Oriented Dialogue (диалог, ориентированный на решение задач).
Поиск в Google: task oriented dialogue
Результаты поиска включают: Papers With Code - Task-Oriented Dialogue Systems
Запись в лидерборде — T5-3b(UnifiedSKG), которая содержит ссылку на статью
“UnifiedSKG: Объединение и многозадачность структурированного знания на основе текста с использованием текстовых языковых моделей” от Тяньбао Ся, Чен Хенри Ву, Пенг Ши, Жуи Ци Чжун, Торстен Шолак, Мичихиро Ясунга, Чень-Шэн Ву, Мин Чжун, Пенгчэн Инь, Сида И. Ван, Виктор Чжун, Байлинь Ван, Чэнцзу Ли, Коннор Бойл, Ансонг Ни, Цзыюй Яо, Драгомир Радев, Цаймин Сян, Линпэн Конг, Жуи Чжан, Ноа А. Смит, Люк Зеттлмойер и Тао Ю (pdf)
Обратите внимание на это
РЕДАКТИРОВАНИЕ
От https://python.langchain.com/
Создание SQL-агента на основе LLM и инструментов. (ссылка)
Внизу страницы перечислено несколько вариантов, на этот стоит обратить внимание
Сценарий использования
Корпоративные данные часто хранятся в базах данных SQL.
LLM позволяют взаимодействовать с базами данных SQL, используя естественный язык.
LangChain предлагает SQL-цепочки и агентов для создания и выполнения SQL-запросов на основе промптов на естественном языке.
Они совместимы с любым диалектом SQL, поддерживаемым SQLAlchemy (например, MySQL, PostgreSQL, Oracle SQL, Databricks, SQLite).
Они позволяют реализовать такие сценарии, как:
- Генерация запросов, которые будут выполняться на основе вопросов на естественном языке
- Создание чат-ботов, способных отвечать на вопросы на основе данных базы данных
- Построение пользовательских дашбордов на основе аналитических данных, которые хочет изучить пользователь
РЕДАКТИРОВАНИЕ (23.08.2023)
Spider — это крупномасштабный набор данных для семантического разбора и перевода текста в SQL сложных и межпредметных запросов, аннотированный 11 студентами Йельского университета. Цель конкурса Spider — разработать интерфейсы на естественном языке для межпредметных баз данных. Он включает 10 181 вопрос и 5 693 уникальных сложных SQL-запроса к 200 базам данных с несколькими таблицами, охватывающим 138 различных предметных областей. В Spider 1.0 различные сложные SQL-запросы и базы данных встречаются в обучающей и тестовой выборках. Чтобы успешно справиться с этим, системы должны хорошо обобщать не только новые SQL-запросы, но и новые схемы баз данных.
РЕДАКТИРОВАНИЕ (24.08.2023)
Dataherald — это движок перевода естественного языка в SQL, созданный для корпоративного уровня ответов на вопросы по структурированным данным. Он позволяет настроить API для вашей базы данных, который может отвечать на вопросы на простом английском языке.
Как я часто говорю другим, в некоторых вещах жизни просто нужно подождать, и кто-то сделает работу за вас бесплатно.
Я всё ещё получаю результаты, которыми полностью доволен. Вот ещё один пример. Оно дало мне то, что я хотел, после чего я добавил условие WHERE, чтобы самостоятельно проверить ID темы, но на этом всё. Вероятно, я мог бы предоставить эту информацию заранее, и оно бы тоже это сделало, хотя:
Теперь в модуле AI Bot есть персонаж SQL Helper, специально адаптированный для таких запросов и очень полезный для создания запросов в Data Explorer. 
(Хотя всё же стоит их перепроверять 
)
Есть ли тема, где можно публиковать примеры использования AI-бота SQL Helper?
Если нет, было бы здорово создать такую тему и добавить сюда ссылку на неё, так как другие пользователи могут искать примеры и в первую очередь найдут эту тему.
Я думаю, что если вы придумаете что-то стоящее, чем можно поделиться с сообществом, вы можете создать новую тему в #data-reporting. Также есть новая кнопка «Поделиться разговором», которая может быть полезна в этом случае — Share Your AI Bot Conversations!
JammyDodger:
Привет, Bert
Можешь написать мне запрос, который найдёт всех пользователей в группе plugin_authors?
gpt4_bot:
groups, group_users, users
Теперь, когда у нас есть схема соответствующих таблиц, мы можем написать запрос для поиска всех пользователей в группе ‘plugin-authors’. Исходя из схемы, нам нужно соединить таблицу group_users с таблицами groups и users, чтобы получить имена пользователей, состоящих в группе ‘plugin-authors’.
Вот запрос для поиска всех пользователей в группе ‘plugin-authors’:
SELECT u.id AS user_id, u.username
FROM users u
JOIN group_users gu ON gu.user_id = u.id
JOIN groups g ON g.id = gu.group_id
WHERE g.name = 'plugin_authors'
Этот запрос выбирает ID пользователя и имя пользователя из таблицы users, соединяя её с таблицей group_users по полю user_id, а затем с таблицей groups по полю group_id. Результаты фильтруются так, чтобы включить только тех пользователей, которые состоят в группе с именем ‘plugin_authors’.
Эта тема была автоматически закрыта через 43 часа. Новые ответы больше не принимаются.