Discourse AI + Data Explorer?

Внести вклад Функция
, , ,
31

Я пробовал это. Результаты получаются крайне нестабильными. Интересный эксперимент — предоставить GPT-3.5 минимальную аннотированную версию схемы базы данных Discourse, чтобы просто проверить его способности в SQL. Я понимаю, что это неэффективно с точки зрения токенов, зато это читаемо:

Минимальная схема 
# == Информация о схеме
#
# Имя таблицы: users
#
#  id                        :integer          не null, первичный ключ
#  username                  :string(60)       не null
#  created_at                :datetime         не null
#
# Имя таблицы: groups
#
#  id                                 :integer          не null, первичный ключ
#  name                               :string           не null
#  created_at                         :datetime         не null
#
# Имя таблицы: group_users
#
#  id                 :integer          не null, первичный ключ
#  group_id           :integer          не null
#  user_id            :integer          не null
#
# Имя таблицы: posts
#
#  id                      :integer          не null, первичный ключ
#  user_id                 :integer
#  topic_id                :integer          не null
#  deleted_at              :datetime         (Приложение выполняет «мягкое удаление» постов. Когда пост удаляется, его свойство `deleted_at` устанавливается в значение :datetime. Если явно не требуется возвращать удалённые посты, при написании запросов, касающихся данных о постах, убедитесь, что столбец `deleted_at` имеет ограничение `NOT NULL`.)
#
# Имя таблицы: topics
#
#  id                        :integer          не null, первичный ключ
#  title                     :string           не null
#  category_id               :integer
#  created_at                :datetime         не null
#  user_id                   :integer          (id пользователя, создавшего тему)
#  deleted_at                :datetime         (Приложение выполняет «мягкое удаление» тем. Когда тема удаляется, её свойство `deleted_at` устанавливается в значение :datetime. Если явно не требуется возвращать удалённые темы, при написании запросов, касающихся данных о темах, убедитесь, что столбец `deleted_at` имеет ограничение `NOT NULL`.)
#
# Имя таблицы: categories
#
#  id                                        :integer          не null, первичный ключ
#  name                                      :string(50)       не null

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

Для интереса я спросил его, с какими типами запросов он, вероятно, столкнётся с трудностями:

Ограничения GPT-3.5
  1. Иерархические запросы: Запросы, работающие с иерархическими структурами данных, такими как рекурсивные связи, могут быть сложными. Например, запросы для поиска отношений «родитель–потомок» внутри иерархии категорий.
  2. Временные запросы: Запросы, связанные с данными, зависящими от времени, например, расчёт исторических тенденций или анализ данных за определённые интервалы времени, могут требовать более сложных конструкций SQL.
  3. Оконные функции: Хотя я использовал оконные функции в предыдущих запросах, более продвинутое их применение для сложных аналитических задач может оказаться сложным.
  4. Геопространственные запросы: Работа с пространственными базами данных и запросы, основанные на географических данных, такие как поиск ближайших локаций или сложных пространственных связей, могут быть сложными.
  5. Сложные агрегации: Продвинутые агрегации, включающие многоуровневое группирование и вычисления, могут требовать более глубоких знаний SQL.
  6. Оптимизационные запросы: Написание высокооптимизированных запросов, использующих индексы, настройку запросов и улучшение производительности, может быть сложным.
  7. Пользовательские алгоритмы: Реализация пользовательских алгоритмов или логики внутри SQL-запроса может быть сложной из-за сложности самой логики.
  8. Продвинутые JOIN: Сложные условия соединения или комбинация нескольких соединений могут требовать тщательного подхода и, возможно, более сложных конструкций SQL.
  9. Подзапросы и коррелированные подзапросы: Хотя я могу обрабатывать подзапросы, крайне сложные или глубоко вложенные подзапросы могут оказаться более сложными.
  10. Поворот и обратный поворот данных: Преобразование данных между широким и длинным форматами (поворот и обратный поворот) в некоторых сценариях может стать сложным.

Проблемы возникают при попытке устранить неоднозначность полной схемы базы данных. Например, найти способ аннотировать таблицу user_actions. Простого предоставления определений её кодов action_type недостаточно. Модель начинает угадывать значения для user_id, target_user_id и acting_user_id.

Наиболее часто запрашиваемые запросы не используют большинство таблиц и столбцов в базе данных. Если в Data Explorer будет добавлен ИИ, возможно, стоит рассмотреть наличие режимов «базовый» и «продвинутый». Базовый режим мог бы использовать промпт, покрывающий большинство случаев использования. Продвинутый режим мог бы позволить пользователям выбирать, какая информация включается в промпт.

Было бы интересно пойти от обратного, взяв несколько запросов на мета-форуме, чтобы понять, что именно нужно предоставить в промпте, чтобы GPT-3.5 успешно создал соответствующий запрос.

3 лайка