データマップについて

Snowflake または Databricks を Perplexity に接続すると、Computer はデータウェアハウスまたはレイクハウスのデータマップを生成します。データマップは、Computer が自然言語の質問を正確なクエリに変換できるよう、データモデルに関する重要な情報（重要なテーブルとカラム、一般的なクエリパターン、オブジェクト間の関係）を取得します。

これはデータ環境のマップとして機能し、Computer がどこに何があり、通常どのように使用されているかを理解するのに役立ちます。一度生成されると、データマップは継続的に改善されます。ユーザーフィードバックから学習し、管理者が直接編集でき、変更は常にレビューおよびロールバックできるようにバージョン管理されます。

データマップの生成が開始されると、Computer は接続されたアカウントの権限を使用してデータモデルを調査します。このプロセスではスキーマ、テーブル、ビュー、過去の使用パターンを検証して、データの包括的な理解を構築します。

データマップは、組織ごとのバージョン管理されたリポジトリに安全に保存され、組織のメンバーのみがアクセスできます。

データマップは 組織につき1つで、その組織のすべてのメンバーが共有します。管理者が生成を実行する際は、個人ではなく組織全体の代表として行います。

Snowflake のデータマップ生成は、Snowflake コネクターの設定から組織管理者が開始します。Perplexity には 2 つの Snowflake コネクターがあり、管理者は組織が設定したコネクターからデータマップを生成します：

使用される ID は、Snowflake のアカウント使用状況ビューを読み取れる必要があります（ 要件 を参照）。これらの権限が不足している場合、生成は部分的なデータマップを生成するのではなく、明確な権限エラーで最初から失敗します。

Databricks の場合、生成はコネクター設定から開始者の Databricks OAuth ID を使用して開始されます。Computer は Unity Catalog でそのユーザーが見ることができるカタログ、スキーマ、テーブルを列挙し、使用シグナルのために Databricks システムテーブルを読み取ります。開始者が Unity Catalog で見ることができるものが、データマップに含まれる内容を定義します。

補足コンテキストを追加できます。これはデータを説明するファイルのアップロードやメモの追加です（例：重要なテーブルが表すもの、ビジネス定義、一般的なクエリパターン）。補足コンテキストは生成後にコネクターモーダルから 補足コンテキスト — ファイルのアップロードやメモの追加でデータを説明できます（例：重要なテーブルが表すもの、ビジネス定義、一般的なクエリパターン）— Computer がデータをより正確に解釈できるようになります。 Supplementary context is fed into every generation run and is 再生成によって影響を受けません。そのため、時間をかけて追加し続けても、失う心配はありません。

生成が完了すると、コネクターモーダルの データマップを生成 ボタンが ナレッジを表示に変わります。 ナレッジを表示 をクリックすると、 データマップエディターが開き、管理者は Computer がデータについて学んだすべてのコンテンツを閲覧、編集、管理できます。 データマップを再生成 は、初期データマップが作成された後にコネクターモーダルから使用できます — see データマップの再生成 の説明と保持されるものについてご覧ください。

データマップの生成には 最大90分かかる場合があります（データウェアハウスまたはレイクハウスのサイズと複雑さによって異なります）。ページを開いたままにしておく必要はありません。プロセスはバックグラウンドで実行され、 ナレッジを表示 ボタンが完了後にコネクターモーダルに表示されます。

データマップエディターは管理者向けのデータマップビューで、組織管理者ツールからアクセスできます。Snowflake と Databricks のナレッジを個別のセクションに分離し、基礎となるビジネスコンテキスト、テーブルクラスター、クエリパターンは直接読み書きできるファイルとして整理されています。

エディターから管理者は以下の操作が可能です：

エディターでの直接編集は通常使用では永続的ですが、自動生成されたコンテンツと共存しており、 そのウェアハウスのデータマップを再生成すると保持されません — see データマップの再生成 below.

チームが使うほど、データマップは改善されます。ユーザーがスレッド内でデータエージェントを修正すると（例：「クエリカウントには query_events の代わりに fct_queries を使用してください」または「クエリボリュームメトリクスから type = 'internal' を除外してください」）、Computer はそのフィードバックを記録してデータマップの改善に使用します。

パイプラインは safe, reviewable、および 組織全体で共有される:

ユーザーが Data Scientist スレッドでフィードバックを提供すると、Computer はフィールド、期待される値と実際の値のロジック、コンテキストなどの構造化された修正を記録し、今後の応答を改善します。

1日に1回、Computer は各組織の過去24時間に記録された修正を確認し、単一の統合された proposed update をデータマップに：

結果は管理者がレビューできる単一の提案としてデータマップエディターに表示されます。

管理者 承認 （変更がデータマップに適用）または 却下 （提案が破棄されます）。承認が変更を「デプロイ」します — チームが次にデータに関する質問をすると、更新されたデータマップが使用されます。別途公開ステップはありません。

この人間参加型パターンは意図的なものです。Computer がリアルな使用から継続的に学習しながら、管理者がグラウンドトゥルースとして信頼されるものを制御し続けられるようにします。

管理者は実行できます データマップを再生成 コネクターモーダルからいつでも実行できます。現在、再生成は 再生成するウェアハウスの最初からの再構築:

再生成はウェアハウスのデータマップとその管理者編集を置き換えるため、意図的に実行する必要があります。 管理者編集を保持するより安全な再生成と、別途の明示的な「完全リセット」については、ロードマップに含まれていますが、現在はまだ提供されていません。

データマップの生成に使用されるアイデンティティ（キーペア/PAT 認証の場合はサービスアカウント、OAuth 認証の場合は開始管理者の Snowflake ユーザー）は、SNOWFLAKE.ACCOUNT_USAGE スキーマの次の2つのビューを読み取れる必要があります：

初期セットアップ時にこのアクセスをまだ付与していない場合は、次のコマンドを ACCOUNTADMIN:

次に、接続ロールから確認します：

If ACCESS_HISTORY が利用できない場合（Snowflake Standard Edition）、生成は QUERY_HISTORY のみにフォールバックします。データマップは引き続き機能しますが、列の系譜とテーブルアクセスカウントに関するシグナルの精度がやや低下します。

完全なセットアップ手順については、以下をご覧ください： Perplexity と Snowflake の接続.

Databricks の生成では、開始者の OAuth アイデンティティが使用され、Unity Catalog の権限が継承されます。追加の権限付与は不要です。知っておくべき実用的な注意点がいくつかあります：

完全なセットアップ手順については、以下をご覧ください： Perplexity と Databricks の接続.