Discourse AI + Data Explorer?

Funzionalità
, , ,
31

Ho provato anche quello. I risultati sono disordinati. Un esperimento interessante è fornire a GPT-3.5 una versione minima annotata dello schema del database Discourse solo per testare la sua capacità SQL. Mi rendo conto che è inefficiente in termini di token, ma è leggibile:

Schema minimo 
# == Informazioni sullo schema
#
# Nome tabella: users
#
#  id                        :integer          not null, primary key
#  username                  :string(60)       not null
#  created_at                :datetime         not null
#
# Nome tabella: groups
#
#  id                                 :integer          not null, primary key
#  name                               :string           not null
#  created_at                         :datetime         not null
#
# Nome tabella: group_users
#
#  id                 :integer          not null, primary key
#  group_id           :integer          not null
#  user_id            :integer          not null
#
# Nome tabella: posts
#
#  id                      :integer          not null, primary key
#  user_id                 :integer
#  topic_id                :integer          not null
#  deleted_at              :datetime         (L'applicazione "elimina logicamente" i post. Quando un post viene eliminato, la sua proprietà `deleted_at` viene impostata su un :datetime. A meno che non venga esplicitamente richiesto di restituire i post eliminati, assicurati che la colonna `deleted_at` sia `NOT NULL` quando scrivi query che richiedono dati relativi ai post.)
#
# Nome tabella: topics
#
#  id                        :integer          not null, primary key
#  title                     :string           not null
#  category_id               :integer
#  created_at                :datetime         not null
#  user_id                   :integer          (l'id dell'utente che ha creato l'argomento)
#  deleted_at                :datetime         (L'applicazione "elimina logicamente" gli argomenti. Quando un argomento viene eliminato, la sua proprietà `deleted_at` viene impostata su un :datetime. A meno che non venga esplicitamente richiesto di restituire gli argomenti eliminati, assicurati che la colonna `deleted_at` sia `NOT NULL` quando scrivi query che richiedono dati relativi agli argomenti.)
#
# Nome tabella: categories
#
#  id                                        :integer          not null, primary key
#  name                                      :string(50)       not null

Finora, i risultati che sto ottenendo sono impressionanti. Questo mi fa pensare che il problema potrebbe essere risolto semplicemente fornendo uno schema annotato nel prompt.

Per divertimento, gli ho chiesto che tipo di query potrebbe avere difficoltà a gestire:

Limitazioni di GPT-3.5
  1. Query gerarchiche: le query che coinvolgono strutture dati gerarchiche come relazioni ricorsive possono essere complesse. Ad esempio, interrogare le relazioni padre-figlio all’interno di una gerarchia di categorie.
  2. Query temporali: le query che coinvolgono dati basati sul tempo, come il calcolo di tendenze storiche o l’analisi di dati su intervalli di tempo specifici, potrebbero richiedere costrutti SQL più complessi.
  3. Funzioni finestra: sebbene abbia utilizzato funzioni finestra in query precedenti, usi più avanzati di funzioni finestra per attività analitiche complesse potrebbero essere impegnativi.
  4. Query geospaziali: database spaziali e query basate su dati geografici, come la ricerca di posizioni vicine o relazioni spaziali complesse, potrebbero essere complesse.
  5. Aggregazioni complesse: aggregazioni avanzate che coinvolgono più livelli di raggruppamento e calcoli potrebbero richiedere conoscenze SQL più complesse.
  6. Query di ottimizzazione: scrivere query altamente ottimizzate che coinvolgono indici, ottimizzazione delle query e miglioramenti delle prestazioni può essere complesso.
  7. Algoritmi personalizzati: l’implementazione di algoritmi o logiche personalizzate all’interno di una query SQL potrebbe essere impegnativa a causa della complessità della logica coinvolta.
  8. JOIN complessi: condizioni di join complesse o la combinazione di più join potrebbero richiedere un’attenta considerazione e forse costrutti SQL più complessi.
  9. Sottoquery e sottoquery correlate: sebbene possa gestire le sottoquery, sottoquery estremamente complesse o profondamente annidate potrebbero essere più impegnative.
  10. Pivoting e unpivoting: la trasformazione dei dati tra formati larghi e alti (pivoting e unpivoting) può diventare complessa in determinati scenari.

Dove trovo problemi è nel tentativo di disambiguare l’intero schema del database. Ad esempio, trovare un modo per annotare la tabella user_actions. Fornire solo definizioni dei suoi codici action_type non è sufficiente. Inizia a fare ipotesi su user_id, target_user_id e acting_user_id.

Le query richieste più frequentemente non utilizzano la maggior parte delle tabelle e delle colonne del database. Se l’IA viene aggiunta all’Esplora dati, potrebbe valere la pena considerare di avere modalità “base” e “avanzate”. La modalità base potrebbe fornire un prompt che copre la maggior parte dei casi d’uso. La modalità avanzata potrebbe consentire agli utenti di selezionare quali informazioni vengono fornite nel prompt.

Sarebbe interessante lavorare a ritroso da alcune richieste di query su meta, per vedere cosa dovrebbe essere fornito al prompt per far sì che GPT-3.5 crei correttamente la query.

3 Mi Piace