4,788 文字
みなさん、こんにちは。本日はデータウェアハウス、スプレッドシート、CSVのための統合テキストからSQLへの変換について、お話をさせていただきます。少し長くて難しいタイトルですが、この講演でもう少し分かりやすくご説明したいと思います。
私はDustのソリューションエンジニアのAldenです。Dustは基本的にAIオペレーティングシステムの会社で、お客様の企業知識を組み込んだ専門的なアシスタントの構築をサポートしています。これは様々な形態を取ることができ、多くのビルディングブロックを組み合わせることができます。この後詳しくお話ししますが、良いところは、私たちが強力なAPIとデベロッパープラットフォームを持っているため、アシスタントをどこにでも組み込むことができる点です。例えばここではZendeskに組み込まれており、サイドバーにDustのアシスタントがあるので、エージェントは会社のデータや他のZendeskチケットに直接アクセスできます。
先ほど触れたビルディングブロックですが、基本的に社内ナレッジの追加、セマンティック検索、コード解釈、ウェブ検索、文字起こしなどを追加できます。今日お話しするのはテーブルクエリについてです。基本的に、通常のテキストからテーブルにクエリを実行できるようにしたいと考えています。
小さなデモからはじめましょう。これは私が構築したアシスタントで、Snowflakeウェアハウスに接続されています。Dustプラットフォームで送信されたメッセージの1週間あたりの平均数を可視化し、上位10のワークスペースを異なる色で、残りを別の色で区別するように依頼しています。ここで起きているのは、テーブルにクエリを実行し、何をしているのかを私たちに伝え、Snowflakeからデータを受け取り、Reactコンポーネントを構築し、そのコンポーネントがコードインタープリターによって解釈され、きれいなグラフが作成されるという流れです。面白いのは、指数関数的な曲線が見られることで、これは私たちにとって良い兆候です。
このアシスタントが使用したツールを見てみると、思考のチェーンが働いているのがわかります。なぜこれを行ったのかを説明し、使用されたSQLクエリが表示されます。SQLがかなり長いことがわかりますが、誰かにこれを作成してもらうには、時間がかかるかSQLの深い知識が必要になります。
会話を続けて、メッセージ数ではなくアクティブユーザー数について同じことを尋ね、同時に最も使用されているアシスタントについても同じことを尋ねてみましょう。これは同じ会話の中で2番目に尋ねたことなので、3つの異なるグラフが表示されます。1つの会話で多くのデータポイントが得られ、面白いのは、データポイントがプロンプトに直接表示されないことです。コンポーネントの生成に時間がかかりすぎてしまうためです。
この3つのグラフで本当にやりたいことは、これらのコンポーネント、これらのグラフを切り替えられる実際のボタンを持つ1つの組み合わされたReactコンポーネントを作ることです。それを今お願いしているところです。コンポーネントを構築しますが、面白いのは、データをCSVファイルとしてモデルに直接アップロードしたので、データを再利用できることです。
ファイルにズームインしてみましょう。はい、ここにメッセージ、ユーザー、エージェントの3つのファイルがあります。Reactコンポーネントは、データを含むファイルを使用してグラフを作成し、そして完成です。3つのグラフ、素敵なボタン、そして切り替えができます。SQLについて何も知る必要がなく、コーディングについても何も知る必要がありません。
これはSnowflakeウェアハウスでした。1つのデータベースにデータを問い合わせましたが、異なる場所から異なるソースを使用したい場合はどうでしょうか。Google Driveに従業員と役職のファイルがあり、CSVにユーザーのワークスペース使用状況があり、Dustを最も使用している役職を知りたい場合を考えてみましょう。これは非常に良い情報です。どのチームが使用しているのか、どのようなユースケースがあるのかを知りたいからです。
異なる場所からデータをマージする方法を見てみましょう。アシスタントを構築していますが、基本的にアシスタントは、ツールが付属した一連の指示です。ここで私のツールはテーブルのクエリで、構築したツールの説明があります。ユーザーのアクティビティと役職に関する情報です。後で見ていきます。
ここで重要な部分は、選択したデータベースです。例えば、そのアシスタントにウェブ検索を有効にしたい場合は、ウェブ検索のボックスにチェックを入れるだけで、パリ2024オリンピックで各国が獲得したメダル数などを尋ねてグラフ化することができますが、今は自分のデータだけを使用したいと思います。
私のクエリテーブルツールはこのように構築されています。Google Sheetの従業員役職スプレッドシートと、DustのAPIから直接ダウンロードした使用状況のCSVがあります。このアシスタントに、トップ5ユーザーの役職を尋ねてみましょう。トップ20やトップ100でも構いませんが、ここで重要なのはSQLクエリです。基本的に、2つのテーブルに対して通常のSQLクエリを実行しているだけです。2つのテーブルは2つのファイルで、異なるストレージ、異なる世界から来ています。本来なら同じ場所で会話することはできないはずですが、ここでは従業員のメールアドレスで2つのファイルを左結合しただけで、名前、ユーザーメッセージ数、役職が得られました。質問するだけで、異なる場所から来る2つの異なるファイルをマージすることができました。
これがどのように機能するのか説明するために、Dustのアーキテクチャについて少しお話ししる必要があります。いくつかのコンポーネントがあります。最初のものは「フロント」と呼ばれ、基本的に顧客がAPI、ウェブUI等で接続する場所です。これは「コネクタ」と呼ばれるものに接続されています。誰かがDustにデータを接続する際、Google Drive、Notion、Slack、GitHub等を接続することを決めた場合、コネクタを通じて同期されます。すべてのデータはPostgreSQLデータベースに同期され、保存されます。そして、LLMと直接通信し、ベクトル検索データベースであるQuadrantデータベースと通信するRustアプリケーションである「コア」と通信します。これが私たちのRAGの仕組みです。
Dustにファイルをアップロードする際に何が起こるのでしょうか。フロントからアップロードできます。例えば、UIにCSVを単にドロップするか、コネクタからアップロードできます。Google Driveを接続して新しいスプレッドシートが表示され、すべてを同期する場合などです。私たちが行っているのは、これらのファイルをCSVとして統一することです。元のファイル入力が何であれ、スプレッドシート、データベース、Google Sheetであっても、CSVになります。
そして、それを解析し、カラムの型を見つけようとします。そこから、LLMにとって最も使いやすい実際のカラム名を見つけようとします。LLMが使いやすいように、実際のファイルとは異なる名前で保存しています。すべてをPostgreSQLデータベースに保存し、それを拡張スキーマと呼んでいます。ユーザーが実際に質問すると、その両方をLLMに送信します。拡張スキーマと実際のクエリを送信することを決め、それをDBMLと呼ばれる言語として送信します。
そして、それを関数呼び出しを使用できるモデルに送信します。私たちはモデルに依存しませんが、この特定のツールには関数呼び出しが必要で、関数呼び出しは2つの異なる結果を返します。基本的に構造化された出力、思考のチェーン、そしてクエリです。
もう少し深く掘り下げてみましょう。基本的に、LLMに送信しているのは完全な会話履歴です。先ほど見たように、「ユーザーについて同じことをして」「メッセージについて同じことをして」と言いました。次に、先ほど話した文書化されたカラムである拡張スキーマを見ます。特定の値を見つけた場合、カラムに列挙型を見つけた場合、仕事を再度容易にするために、そのカラムで可能な特定の値も送信します。
そして、いくつかの例を送信します。すべてのテーブルヘッダー、つまり基本的にすべてのファイルを取り、最初の16行をLLMに送信して、データ構造を確実に認識させます。その後、構造化された出力呼び出しを行います。実際、私たちの側では構造化された出力が利用可能になる前にこれを構築したため、関数呼び出しを行っていますが、今では構造化された出力呼び出しに切り替えることができます。
これは3つのものを返します。先ほどツールを開いたときに表示された小さな紫色の四角で示された思考のチェーン、ファイルがある場合にダウンロードするファイルのタイトル（ときにはユーザーは質問をするだけで、データベースに何もないこともあります）、そしてSQLクエリ、またはSQLクエリを実行しないことを決めた場合は何も返しません。
SQLクエリがある場合、2つの異なるパスがあります。ウェアハウスの場合（現在はSnowflakeのみですが、RedshiftとBigQueryも追加予定です）、単にウェアハウスでクエリを実行して結果を取得します。ファイルの場合は少し複雑になります。実際にはメモリ内にJust-in-timeデータベースを起動します。Rustで起動するSQLiteデータベースで、非常に高速です。LLMからのレイテンシーが十分に大きいため、データベースを起動して供給する時間があります。
LLMが考えている間にすべてのファイルをデータベースに供給し、データベースが準備できます。すべてのファイルがテーブルとして準備され、任意のテーブルで左結合を実行できます。クエリを実行した後は、かなり簡単です。クエリ結果をCSVとして保存し、S3またはGCSにアップロードします。
これが、その後に私が示したことです。その後、その上にコンポーネントを構築したい場合、コンポーネントは多くのトークンを生成する必要なく、単にファイルを使用できます。最初は、すべてのデータポイントを直接LLMに入力して構築を始めました。それは非常にコストがかかり、非常に遅かったです。LLMが全体のコンポーネントを構築し、すべてのデータポイントを生成していたからです。ファイルを使用する方が遥かに簡単です。
LLMが結果のデータ構造を確実に理解できるように、LLMにも数行を表示します。その後、LLMはRechartsを使用してかなり素敵なチャーティングコードを生成できます。D3.jsも実装中です。このコンポーネントはすべてのファイル、CSVをダウンロードし、そしてグラフが完成します。
基本的に、ここにいる皆さんの目標はAGIに到達することですよね。私たちはそれに向かって急いでいますが、私たちの側では自然言語BIに到達したと思います。これは多くの非技術チームによって使用されており、以前はできなかったBIを実行できるようになっています。
ダッシュボードなどで同じことができる可能性はありますが、ダッシュボードを構築する時間と、単にウェアハウースや完全に範囲外のファイルに質問をする時間を比較すると、その差は本当に大きいです。
以上です。ありがとうございました。
コメント