内部データ分析エージェントを構築した方法

ビッグデータおよび分析組織は、多くの場合、真に利己的なデータと洞察へのアクセスを作成するのに苦労しています。業界は何十年にもわたってこの問題を解決しようとして失敗しましたが、今では AI が信頼できる解決方法を提供してくれています。

GitHub 規模では、数十の製品チームに専用の分析サポートを提供することは困難であり、非常に多くのチームがこの問題を自力で解決する必要があります。製品チームやエンジニアリングチームが意思決定を行うために使用できる貴重な製品テレメトリは数多くありますが、データアナリストのサポートがなければ、どのデータモデル、どのグレイン、どのフィルターを把握し、クエリを作成して結果を検証することは常に困難でした。

Qubot は、GitHub Copilot を利用した社内分析エージェントです。 Qubot を使用すると、ハバー (GitHub 従業員と呼ばれるもの) は、GitHub のデータウェアハウス内のあらゆるデータモデルについて簡単な言葉で質問し、数秒以内に回答を得ることができます。

Cubot はレポートツールやダッシュボードの代替品ではありません。代わりに、「この機能の維持率が最も高いユーザーのグループはどれですか?」などの探索的な質問に使用されます。または「先週この指標の変動に最も貢献した製品はどれですか?」 Cubot にはメンテナンス費用がかからず、チームが不慣れなデータセットに迅速に取り組むのに役立ちます。

このブログ投稿では、Cubot をどのように構築し、どのように変化し、何を学んだのかについて説明します。

Cubot はどのように機能しますか?

このアーキテクチャには、ユーザーインターフェイス、コンテキスト層、クエリエンジンという 3 つの主要コンポーネントがあります。

ユーザーインターフェース

Cubot には、Slack、VS Code、Copilot CLI を通じてアクセスできます。 Slack インターフェイスは設定を必要とせず、Hubbers のお気に入りのコラボレーションツールです。誰かが Cubot Slack チャネルに質問を投稿すると、github.com 上で実行される Copilot Cloud Agent として Cubot インスタンスが生成されます。回答は Slack で直接提供されるため、ユーザーは結果を他のユーザーと共有できるだけでなく、スレッド内で繰り返して質問を開発または改良することもできます。すべての結果は、ユーザーがクエリを微調整したり、ダッシュボードで使用したりするために参照できるマークダウンレポートとしてプルリクエストにも保存されます。

Cubot は、ワークフローとより統合されたエクスペリエンスを求めるユーザーのために、VS Code および Copilot CLI でも使用できます。 Cubot は 1 つのコマンドでプラグインとしてインストールでき、ユーザーが構成した他のカスタムエージェント、スキル、ツールとともに、VS Code または Copilot CLI のエージェントセッションで使用できるようになります。

コンテキストレイヤー

当社のデータウェアハウスには、生のイベント (ブロンズ)、カスタマイズされたファクトとディメンション (シルバー)、特定のビジネスユースケース向けに設計された厳選されたデータセット (ゴールド) など、キュレーションのさまざまな段階のデータが含まれています。コンテキスト層はフェデレーション方式で構築され、データのタイプに対応する知識が含まれます。

ブロンズデータの場合、製品チームによって提供されたスキーマ情報とメタデータを含むテレメトリコンテキストがあります。
Silver Data については、データおよび分析チームによって作成された質問、使用方法のガイダンス、必須フィルターなどの例が用意されています。
ゴールドデータの場合は、それらのデータセットを所有するチームによって提供されるビジネスルールとメトリクスの定義があります。

また、ETL パイプラインを活用して、追加の信号と派生メタデータでコンテキストレイヤーを体系的に強化します。コンテキストは実行時に GitHub MCP サーバー経由でロードされ、コンテキストレイヤーから取得されます。

コンテキストエージェント

参照レイヤーは、複数のリポジトリに存在する新しい知識によって継続的に強化されます。 GitHub では、主にドキュメント作成に Markdown を使用しているため、さまざまなツールと連携する必要はありません。

単一のリファレンスエージェントを通じて、フェデレーションによるリファレンスの提供を合理化しました。チームは、標準化されたテンプレートを介して、または関連情報が含まれるリポジトリを参照することによって貢献できます。次に、エージェントはこの情報を取り込み、整理し、私たちの評価に基づいて Cubot にとって効果的であることが証明された構造化形式に正規化します。

評価の枠組み

コンテキスト層またはエージェント構成に対するすべての変更は、出荷前に評価されます。新しい知識でコンテキストレイヤーを強化したい場合は、プルリクエストを開くことができます。新しいコンテキストは、応答の精度、正解を見つけるまでの遅延を測定し、ユーザーに届く前に回帰を捕捉するオフライン評価フレームワークを受けます。

構造化されたテストケースで Cubot を評価するためのベンチマークフレームワークには、次の 3 つのコンポーネントがあります。

テストケース: 既知の正解、グラウンドトゥルース SQL、メタデータ (ドメイン、難易度) を含むプロンプトの厳選されたデータセット。
自動化された実行オーケストレーション: GitHub CLI を使用したエージェントタスクとして各テストケースの起動を自動化するスクリプト gh agent-task create複数のテストを並行して実行し、完了をポーリングして、詳細な JSON 結果を保存します。
データ収集: 保存された結果を読み取り、テストケースごとの指標 (完了率、精度、期間 (平均/最小/最大)) を計算するレポートスクリプト。

エンドツーエンドのフローは次のとおりです。テストケースの定義 → ケースごとに Cubot を N 回実行 → 結果の収集 → 統計の集計 → 構成の比較。

クエリエンジン

Cubot は、MCP サーバーを介して、GitHub の分析ワークロードのほとんどを強化する 2 つのクエリエンジンである Kusto と Trino の両方に接続します。私たちは Trino MCP サーバーのカスタム実装を開発しましたが、Kusto では Fabric RTI MCP サーバーのネイティブバージョンを展開しました。 Kusto は高速で、最近のイベントデータに対する探索的なクエリに適しています。 Trino は、複雑な結合と詳細な履歴分析を処理します。

Cubot は、どちらを使用するかをユーザーに強制するのではなく、デフォルトで Kusto に依存し、必要が生じた場合には自動的に Trino に切り替えます。

何が変わったのか、何を学んだのか

Qubot は GitHub で広く採用されており、何百人もの熱心なユーザーが何千もの質問をしています。データと分析の Slack チャネルでハバーが行う質問の数は、より自主性を持ってデータを探索し、複雑な質問のみにアクセスできるようになったため、劇的に減少しました。また、これまでデータウェアハウスに飛び込む勇気がなかったハバーでも、意思決定に必要なデータにアクセスできるようになります。これが、Slack、Copilot CLI、VS Code などの多くのインターフェイスが導入される理由の 1 つです。ハブは非常に技術的ですが、私たちは参入障壁がなく、構成も不要な代替手段を提供したいと考えていました。

CoPilot の推論機能を強化し、専門的な分析エージェントを作成するには、コンテキストレイヤーが重要であることがすぐにわかりました。私たちの実験では、構造化され、よく整理されたコンテキストにより、Cubot の精度が向上するだけでなく、正解を与える速度が 3 倍速くなることがわかりました。これは、この種のアーティファクトが、後でデータがどのように考えられるかについての第一級市民となるため、分析エンジニアリング分野に大きな影響を与えます。

Cubot は、ハブアンドスポークの実行に成功した稀な例です。これにより、製品チームがサーフェスのテレメトリを所有し、ビジネスチームがゴールドデータの定義を所有するため、データおよび分析チームのストレスが軽減されます。 Qubot は、この分散した知識をすべて GitHub 全体に利益をもたらす単一のツールに集中させる引力として機能し、パートナーチームが独自のドメインに限定された複数のツールを作成するのではなく、Qubot に貢献するインセンティブを提供します。