それは大失敗でした。 
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 generated by ai from English
英語の質問からAIでSQLを生成することに関連する情報を探しました。リストに研究論文が含まれていることを期待していましたが、リストは主にアプリケーションのリストでした。多くのアプリケーションで共通して見られたパターンは、いくつかのデモを見た後で気づいたのですが、それらの多くは、Microsoft AccessのGUI SQLビルダーのように、ユーザーがテーブルとフィールドを選択してSQLステートメントを構築できる既存のツールを基点としていました。つまり、英語の質問から始めるのではなく、まずテーブル、そして時にはフィールドを選択してから、英語の質問を入力する必要がありました。これを不正行為とは考えませんが、そのようなAIを使用するには、ユーザーは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の上にどのようにレイヤー化されているか、またはどのようにインターフェースされているかについてのソースコードや詳細は見つかりませんでしたが、アイデアだけでも価値があります。
これは再び、飛行機のオートパイロットがどのように機能するか、そして以前に言及した本を思い出させます。（ref）オートパイロットと言うとき、二進法のスイッチを想像しないでください。オートパイロットに情報を提供し、何をすべきか、何をすべきでないかをオートパイロットに知らせるすべてのノブとスイッチを想像してください。
これに似た多くのツールが「copilot」という言葉を使っているようですが、Google検索で「llm copilot source code」と検索すると、私はそのアナロジーには同意しませんが、関連するアイデアを見つける方法なので、それに甘んじなければならないでしょう。
より良い解決策を見つけたと思ったので削除しました。インターネット上でホストされている、データベース全体の詳細情報を含むファイルをChatGPTに解析させるだけで、なぜすべてのテーブルを入力する必要があるのでしょうか？そのアプローチには技術的な問題があることが判明しました。そのため、削除された投稿で提案した方法に戻ります。いずれにせよ、テーブルの説明、クエリの例などを生成する必要があります。問題は、その情報をLLMにどのように渡すかということです。GPT-4での状況は以下の通りです。
はい、あなたが概説したアプローチは理にかなっており、自然言語での質問に基づいてSQLクエリの生成を支援するために私の能力を活用できる実行可能な方法です。
手順の概要は次のとおりです。
- 質問の解釈: ユーザーは自然言語で質問を提示し、私はそれを解釈して要求されている情報を理解します。
- テーブルの特定: 質問とDiscourseデータベースのすべてのテーブルのリストに基づいて、クエリに関連する可能性が最も高いテーブルを特定します。
- 詳細なテーブル情報: Discourseは、すべての列とクエリの例を含む、関連テーブルの詳細な説明を送信します。
- クエリの生成: 詳細なテーブル情報を使用して、ユーザーの質問に答えるSQLクエリを生成します。
このアプローチは、自然言語を理解し、構造化データクエリにマッピングする私の能力を活用します。また、Discourseによって提供される詳細なテーブル情報を効果的に活用します。
代替アプローチとしては、Discourseのデータベーススキーマと一般的なクエリパターンに特化してモデルをトレーニングすることが考えられます。これにはかなりの作業が必要であり、利用可能なリソースによっては実行不可能になる可能性があります。ただし、より正確で効率的なクエリ生成につながる可能性があります。
別の方法としては、ユーザーの質問が曖昧な場合や、複数のクエリが質問に答える可能性がある場合に、私が確認の質問をする、より対話的なダイアログを開発することが考えられます。これにより、プロセスがよりインタラクティブになり、より正確なクエリにつながる可能性があります。
最後の2つの段落で提案されている代替アプローチについては、最初のものは無視しますが、私が試みていることが信頼できる結果につながらない場合は、Discourseチームが検討すべきことかもしれません。
GPT-4に2番目の代替アプローチについて尋ねました。提供されたテーブル構造では回答できない質問があった場合、ユーザーに質問の言い換えを促すことができると、かなり自信を持って答えています。
そのため、Discourseデータベースのすべてのテーブルの説明を記述することに戻ります。allowed_pm_usersテーブルが何に使用されているかはわかりました。ar_internal_metadataテーブルは少し不可解ですが、今のところ無視できると思います。
これは今のところ私のお気に入りの選択肢ですが、実装するのは非常に難しいです。そのため、予想通り、もう一つ論文を紹介します。これもまた、多くの類似したアプローチがあるため、権威ある論文ではありません。
Lang Caoによる「DiagGPT: An LLM-based Chatbot with Automatic Topic Management for Task-Oriented Dialogue」（pdf）
必要に応じて、医療情報をPostgreSQL情報に置き換えるだけです。この論文の良い点は、プロンプトが提供されており、どのツールをエージェントと使用すべきかが示唆されていることです。
必要なのは「タスク指向対話」のようです。
Google検索：「タスク指向対話」
検索結果には以下が含まれます：Papers With Code - Task-Oriented Dialogue Systems
リーダーボードのエントリは「T5-3b(UnifiedSKG)」で、論文へのリンクが含まれています。
Tianbao Xie、Chen Henry Wu、Peng Shi、Ruiqi Zhong、Torsten Scholak、Michihiro Yasunaga、Chien-Sheng Wu、Ming Zhong、Pengcheng Yin、Sida I. Wang、Victor Zhong、Bailin Wang、Chengzu Li、Connor Boyle、Ansong Ni、Ziyu Yao、Dragomir Radev、Caiming Xiong、Lingpeng Kong、Rui Zhang、Noah A. Smith、Luke Zettlemoyer、Tao Yuによる「UnifiedSKG: Unifying and Multi-Tasking Structured Knowledge Grounding with Text-to-Text Language Models」（pdf）
これに注目してください
編集
https://python.langchain.com/ より
LLMとツールからSQLエージェントを構築します。（参照）
ページの下部にいくつかリストされていますが、このページを見るべきです。
ユースケース
エンタープライズデータはSQLデータベースに保存されていることがよくあります。
LLMを使用すると、自然言語でSQLデータベースと対話できます。
LangChainは、自然言語プロンプトに基づいてSQLクエリを構築および実行するためのSQLチェーンとエージェントを提供します。
これらは、SQLAlchemy（例：MySQL、PostgreSQL、Oracle SQL、Databricks、SQLite）でサポートされている任意のSQL方言と互換性があります。
これらは、次のようなユースケースを可能にします。
- 自然言語の質問に基づいて実行されるクエリの生成
- データベースデータに基づいて質問に回答できるチャットボットの作成
- ユーザーが分析したいインサイトに基づいたカスタムダッシュボードの構築
編集 (2023/08/23)
Spiderは、11人のイェール大学の学生によって注釈が付けられた、大規模な複雑でドメイン横断的なセマンティックパーシングおよびテキストツーSQLデータセットです。Spiderチャレンジの目標は、ドメイン横断的なデータベースへの自然言語インターフェースを開発することです。138の異なるドメインをカバーする200のデータベースに対して、10,181の質問と5,693の複雑なSQLクエリで構成されています。Spider 1.0では、異なる複雑なSQLクエリとデータベースがトレーニングセットとテストセットに登場します。これにうまく対応するには、システムは新しいSQLクエリだけでなく、新しいデータベーススキーマにもうまく汎化する必要があります。
編集 (2023/08/24)
Dataheraldは、構造化データに対するエンタープライズレベルの質問応答のために構築された、自然言語からSQLへのエンジンです。データベースから、平易な英語で質問に答えることができるAPIをセットアップできます。
私がよく他の人に言うように、人生には待っていれば無料で仕事をしてくれる人が現れることもあります。
期待通りの結果がまだ出ています。別の例を挙げます。私が望んでいたものを提供してくれました。後でトピックIDを確認するためにWHERE句を追加しましたが、それだけでした。事前にその情報を提供していれば、それもやってくれたかもしれません。
AI Bot モジュールに SQL Helper ペルソナが追加され、これらの種類の要求に対応できるようになりました。データ エクスプローラー クエリの作成に非常に役立ちます。
(ただし、確認することをお勧めします 
)
SQL Helper AI ボットの使用例を投稿できるトピックはありますか？
もしなければ、そのようなトピックを作成し、ここにリンクを追加すると良いかもしれません。他の人も例を探している可能性があり、このトピックが最初に見つかるかもしれません。
コミュニティと共有する価値のあるものがあれば、Data & reporting に新しいトピックを作成して投稿できます。また、これに役立つ新しい「会話を共有」ボタンもあります - Share Your AI Bot Conversations!
JammyDodger:
こんにちは、バート
プラグイン作成者グループのすべてのユーザーを見つけるクエリを書いてもらえますか？
gpt4_bot:
groups, group_users, users
関連テーブルのスキーマがわかったので、「plugin-authors」グループのすべてのユーザーを見つけるクエリを作成できます。スキーマに基づくと、「plugin-authors」グループのメンバーのユーザー名を取得するために、group_users テーブルを groups および users テーブルと結合する必要があります。
「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'
このクエリは、users テーブルからユーザー ID とユーザー名を選択し、user_id で group_users テーブルと結合し、次に group_id で groups テーブルと結合します。結果をフィルタリングして、「plugin-authors」という名前のグループの一部であるユーザーのみを含めます。
このトピックは43時間後に自動的に閉じられました。返信はもう許可されていません。