Discourse AI + Data Explorer?

Merkmal
, , ,
31

Ich habe das versucht. Die Ergebnisse sind überall verstreut. Ein interessantes Experiment ist es, GPT-3.5 ein minimal annotiertes Schema der Discourse-Datenbank zur Verfügung zu stellen, nur um seine SQL-Fähigkeiten zu testen. Mir ist bewusst, dass dies in Bezug auf Tokens ineffizient ist, aber es ist lesbar:

Minimales Schema 
# == Schema Information
#
# Table name: users
#
#  id                        :integer          not null, primary key
#  username                  :string(60)       not null
#  created_at                :datetime         not null
#
# Table name: groups
#
#  id                                 :integer          not null, primary key
#  name                               :string           not null
#  created_at                         :datetime         not null
#
# Table name: group_users
#
#  id                 :integer          not null, primary key
#  group_id           :integer          not null
#  user_id            :integer          not null
#
# Table name: posts
#
#  id                      :integer          not null, primary key
#  user_id                 :integer
#  topic_id                :integer          not null
#  deleted_at              :datetime         (Die Anwendung \"soft deleted\" Beiträge. Wenn ein Beitrag gelöscht wird, wird seine `deleted_at`-Eigenschaft auf ein :datetime gesetzt. Sofern nicht ausdrücklich nach gelöschten Beiträgen gefragt wird, stellen Sie sicher, dass die Spalte `deleted_at` `NOT NULL` ist, wenn Sie Abfragen schreiben, die sich auf Beiträge beziehen.)
#
# Table name: topics
#
#  id                        :integer          not null, primary key
#  title                     :string           not null
#  category_id               :integer
#  created_at                :datetime         not null
#  user_id                   :integer          (die ID des Benutzers, der das Thema erstellt hat)
#  deleted_at                :datetime         (Die Anwendung \"soft deleted\" Themen. Wenn ein Thema gelöscht wird, wird seine `deleted_at`-Eigenschaft auf ein :datetime gesetzt. Sofern nicht ausdrücklich nach gelöschten Themen gefragt wird, stellen Sie sicher, dass die Spalte `deleted_at` `NOT NULL` ist, wenn Sie Abfragen schreiben, die sich auf Themen beziehen.)
#
# Table name: categories
#
#  id                                        :integer          not null, primary key
#  name                                      :string(50)       not null

Bisher sind die Ergebnisse, die ich erhalte, beeindruckend. Das bringt mich auf den Gedanken, dass das Problem einfach durch die Angabe eines annotierten Schemas im Prompt gelöst werden könnte.

Zum Spaß habe ich es gefragt, mit welchen Arten von Abfragen es Schwierigkeiten haben könnte:

GPT-3.5-Einschränkungen
  1. Hierarchische Abfragen: Abfragen, die hierarchische Datenstrukturen wie rekursive Beziehungen beinhalten, können komplex sein. Zum Beispiel das Abfragen von Eltern-Kind-Beziehungen innerhalb einer Kategoriehierarchie.
  2. Zeitliche Abfragen: Abfragen, die zeitbasierte Daten beinhalten, wie die Berechnung historischer Trends oder die Analyse von Daten über bestimmte Zeitintervalle, erfordern möglicherweise komplexere SQL-Konstrukte.
  3. Fensterfunktionen: Obwohl ich Fensterfunktionen in früheren Abfragen verwendet habe, könnten fortgeschrittenere Verwendungen von Fensterfunktionen für komplexe analytische Aufgaben eine Herausforderung darstellen.
  4. Geospatiale Abfragen: Räumliche Datenbanken und Abfragen basierend auf geografischen Daten, wie das Finden von Orten in der Nähe oder komplexe räumliche Beziehungen, können komplex sein.
  5. Komplexe Aggregationen: Fortgeschrittene Aggregationen, die mehrere Gruppierungs- und Berechnungsebenen beinhalten, erfordern möglicherweise komplexere SQL-Kenntnisse.
  6. Optimierungsabfragen: Das Schreiben hochoptimierter Abfragen, die Indizes, Query Tuning und Leistungsverbesserungen beinhalten, kann komplex sein.
  7. Benutzerdefinierte Algorithmen: Die Implementierung benutzerdefinierter Algorithmen oder Logik innerhalb einer SQL-Abfrage kann aufgrund der Komplexität der beteiligten Logik schwierig sein.
  8. Erweiterte JOINs: Komplexe JOIN-Bedingungen oder die Kombination mehrerer JOINs erfordern möglicherweise sorgfältige Überlegung und möglicherweise komplexere SQL-Konstrukte.
  9. Unterabfragen und korrelierte Unterabfragen: Obwohl ich Unterabfragen verarbeiten kann, können extrem komplexe oder tief verschachtelte Unterabfragen eine größere Herausforderung darstellen.
  10. Pivoting und Unpivoting: Die Transformation von Daten zwischen breiten und hohen Formaten (Pivoting und Unpivoting) kann in bestimmten Szenarien komplex werden.

Wo ich Probleme habe, ist die Disambiguierung des vollständigen Datenbankschemas. Zum Beispiel das Finden einer Möglichkeit, die Tabelle user_actions zu annotieren. Allein die Definitionen ihrer action_type-Codes reichen nicht aus. Sie beginnt zu raten bezüglich user_id, target_user_id und acting_user_id.

Die am häufigsten nachgefragten Abfragen nutzen nicht die meisten Tabellen und Spalten in der Datenbank. Wenn KI zum Data Explorer hinzugefügt wird, könnte es sich lohnen, über „Basis“- und „Erweiterte“-Modi nachzudenken. Der Basismodus könnte einen Prompt liefern, der die meisten Anwendungsfälle abdeckt. Der erweiterte Modus könnte es Benutzern ermöglichen, auszuwählen, welche Informationen im Prompt enthalten sind.

Es wäre interessant, von ein paar Anfragen nach Abfragen zu Meta rückwärts zu arbeiten, um zu sehen, was im Prompt bereitgestellt werden müsste, damit GPT-3.5 die Abfrage erfolgreich erstellen kann.

3 „Gefällt mir“