Discourse AI + Data Explorer？

特徴
, , ,
31

それを試しました。結果はバラバラです。興味深い実験は、SQLの能力をテストするために、Discourseデータベーススキーマの最小限のアノテーション付きバージョンをGPT-3.5に提供することです。トークンの効率は悪いことは承知していますが、読みやすいです。

最小スキーマ 
# == スキーマ情報
#
# テーブル名: users
#
#  id                        :integer          not null, primary key
#  username                  :string(60)       not null
#  created_at                :datetime         not null
#
# テーブル名: groups
#
#  id                                 :integer          not null, primary key
#  name                               :string           not null
#  created_at                         :datetime         not null
#
# テーブル名: group_users
#
#  id                 :integer          not null, primary key
#  group_id           :integer          not null
#  user_id            :integer          not null
#
# テーブル名: posts
#
#  id                      :integer          not null, primary key
#  user_id                 :integer
#  topic_id                :integer          not null
#  deleted_at              :datetime         (アプリケーションは投稿を「ソフトデリート」します。投稿が削除されると、`deleted_at` プロパティが `:datetime` に設定されます。削除された投稿を返すように明示的に要求されない限り、投稿に関連するデータを要求するクエリを作成する際に、`deleted_at` 列が `NOT NULL` であることを確認してください。)
#
# テーブル名: topics
#
#  id                        :integer          not null, primary key
#  title                     :string           not null
#  category_id               :integer
#  created_at                :datetime         not null
#  user_id                   :integer          (トピックを作成したユーザーのID)
#  deleted_at                :datetime         (アプリケーションはトピックを「ソフトデリート」します。トピックが削除されると、`deleted_at` プロパティが `:datetime` に設定されます。削除されたトピックを返すように明示的に要求されない限り、トピックに関連するデータを要求するクエリを作成する際に、`deleted_at` 列が `NOT NULL` であることを確認してください。)
#
# テーブル名: categories
#
#  id                                        :integer          not null, primary key
#  name                                      :string(50)       not null

これまでのところ、得られている結果は印象的です。プロンプトにアノテーション付きスキーマを提供するだけで問題が解決する可能性があると考えています。

楽しみのために、GPT-3.5にどのようなクエリで苦労するか尋ねてみました。

GPT-3.5の制限
  1. 階層クエリ: 再帰的な関係のような階層的なデータ構造を含むクエリは複雑になる可能性があります。例えば、カテゴリ階層内の親-子関係をクエリすることなどです。
  2. 時間的クエリ: 履歴トレンドの計算や特定の時間間隔でのデータの分析など、時間ベースのデータを含むクエリは、より複雑なSQL構文が必要になる場合があります。
  3. ウィンドウ関数: 以前のクエリでウィンドウ関数を使用しましたが、複雑な分析タスクのためのウィンドウ関数のより高度な使用は困難な場合があります。
  4. 地理空間クエリ: 空間データベースや、近くの場所や複雑な空間関係の検索などの地理データに基づいたクエリは、複雑になる可能性があります。
  5. 複雑な集計: 複数のグループ化レベルと計算を含む高度な集計は、より複雑なSQL知識が必要になる場合があります。
  6. 最適化クエリ: インデックス、クエリチューニング、パフォーマンス改善を含む、高度に最適化されたクエリの作成は複雑になる可能性があります。
  7. カスタムアルゴリズム: クエリロジックの複雑さにより、SQLクエリ内にカスタムアルゴリズムまたはロジックを実装することは困難な場合があります。
  8. 高度なJOIN: 複雑なJOIN条件や複数のJOINの結合は、慎重な検討と、より複雑なSQL構文が必要になる場合があります。
  9. サブクエリと相関サブクエリ: サブクエリは処理できますが、非常に複雑または深くネストされたサブクエリはより困難になる可能性があります。
  10. ピボットとアンピボット: データの幅広形式と縦長形式間の変換（ピボットとアンピボット）は、特定のシナリオで複雑になる可能性があります。

問題が発生しているのは、データベーススキーマ全体を曖昧にすることです。例えば、user_actions テーブルにアノテーションを付ける方法を見つけることです。その action_type コードの定義を提供するだけでは不十分です。user_id、target_user_id、acting_user_id について推測し始めます。

最も一般的に要求されるクエリは、データベースのほとんどのテーブルや列を使用しません。データエクスプローラーにAIを追加する場合、「基本」モードと「高度」モードを検討する価値があるかもしれません。基本モードは、ほとんどのユースケースをカバーするプロンプトを提供できます。高度モードでは、ユーザーがプロンプトに設定する情報を選択できます。

GPT-3.5が正常にクエリを作成できるようにするために、メタに対するクエリの要求から逆算して、プロンプトに何を提供する必要があるかを確認するのは興味深いかもしれません。

「いいね！」 3