データウェアハウスからの回答

Perplexity Computer を Snowflake に接続し、日常的な言葉で信頼できるデータの回答を得る方法を学びます。

  • Noah Yonack

    Member of Data Staff, Perplexity

  • Patrick Summers

    Founding Enterprise Growth Lead

  • 既存のロール、権限、およびセキュリティ制御を維持しながら、ComputerをSnowflakeまたはDatabricksに接続します。
  • より信頼性の高い分析のために、ビジネス定義、テーブル関係、およびクエリパターンをキャプチャするデータマップを構築します。
  • 承認された他のエンタープライズソースとウェアハウスのデータを併用して、レポート、ダッシュボード、および定期的な監視ワークフローを作成します。

クエリの例

よくある質問

Computerをデータウェアハウスに接続する

データチームはどのようにComputerを利用しますか?

Computerは、ビジネスチームに対して管理されたデータウェアハウスへの自然言語インターフェイスを提供し、承認された他のシステムのコンテキストと組み合わせることができます。顧客は反復的なデータリクエストを削減し、データチームがモデリング、ガバナンス、戦略的分析に多くの時間を費やせるようにしています。これは、データウェアハウス、セマンティックレイヤー、データ品質向上への取り組みを置き換えるものではありません。

最善の開始方法はどのようなものですか?

よく理解されている1つのビジネスドメインと少数のユーザーグループから始めます。ユーザーOAuthの設定、承認されたスキーマとツールへのアクセスの制限、標準メトリックの文書化、データマップの生成とレビュー、そして信頼できるレポートに対する代表的な質問のテストを行います。SQLの品質、権限、コスト、ユーザーの行動にデータチームが満足した後にのみ、範囲を拡大してください。

Computerはプロアクティブにメトリックやデータパイプラインを監視できますか?

スケジュールされたタスクは、サポートされているソースに対して定期的なチェックを実行し、構成されたチャネルを通じて結果を配信できます。ユーザーは、データソース、実行頻度、しきい値、期待される出力、所有者、およびエスカレーションパスを定義する必要があります。

アーキテクチャとガバナンス

データマップとは何ですか?また、誰が所有すべきですか?

データマップは、重要なテーブル、カラム、リレーションシップ、クエリパターン、およびビジネスコンテキストをキャプチャする、組織レベルのコンテキストレイヤーです。Computerがビジネス上の質問をデータウェアハウス由来のクエリに翻訳するのを助けます。データプラットフォーム、アナリティクスエンジニアリング、またはデータガバナンスの所有者がこれを維持し、信頼できるメトリックの定義、提案された変更のレビュー、および持続的な補足コンテキストの追加を行う必要があります。

データウェアハウスは記録システム(System of Record)であり続けますか?

はい。データマップには、データのナビゲーション方法に関するコンテキストが保存されます。現在のメトリックには引き続きアクティブな接続が必要であり、SQLは顧客のSnowflakeまたはDatabricks環境内で実行されます。データウェアハウスは、データ、コンピュート、権限、クエリ履歴、およびアクセスポリシーの信頼できる情報源であり続けます。

IDと権限はどのように強制されますか?

ComputerはコネクタでユーザーOAuthを使用します。各ユーザーは個別のアカウントでサインインし、クエリはそのアカウントの構成されたロールコンテキスト内で実行されます。ウェアハウスネイティブの付与、行フィルター、列ポリシー、およびロール構成が信頼できる制御として維持されます。一部のコネクタでは共有サービスアカウントもサポートされていますが、各ユーザー個別の権限ではなく、サービスアカウントのアクセスモデルが適用されます。

Computerは、データウェアハウス、SaaSアプリケーション、ファイル、およびWebにわたるデータを統合できますか?

Computerは、有効化されたソースからの情報を1つのワークフローで組み合わせることができます。信頼性の高いエンティティ解決の必要性がなくなるわけではありません。重要なレポート作成のために、上流で標準の顧客、製品、アカウント識別子を維持し、承認されたクロスウォークを文書化し、各メトリックの信頼できる情報源(シングル・ソース・オブ・トゥルース)を定義してください。

精度と監査可能性

データチームは、生成されたSQLと回答をどのように検証すべきですか?

Computerはレビュー可能なSQLを生成します。データチームはSQLを検査し、重要な出力を信頼できるレポートと比較し、エッジケースをテストし、データマップ内の不足しているビジネスコンテキストを修正する必要があります。

システム間で意見が食い違う場合、信頼できるメトリックはどのように選択されますか?

データチームはその決定を明確にする必要があります。管理者はデータマップを編集して、承認された定義がライブのグランド・トゥルース(信頼できる事実)になるようにし、耐久性のあるビジネス定義を補足コンテキストに配置することができます。競合するユーザー修正は、自動的に解決されるのではなく、人間のレビューにルーティングされます。すべての重要なメトリックについて、標準のソース、粒度、必要なフィルター、所有者、および既知の代替手段を文書化してください。

どのような監査証跡が利用可能ですか?

Perplexity監査ログは、ユーザー入力、エージェントの動作、完了、エラー、および管理上の変更にわたるイベントをキャプチャします。SnowflakeやDatabricksなどのデータウェアハウスは、ウェアハウス側の信頼できるクエリおよびIDレコードを保持します。

監査人のためにすべての回答を正確に再現できますか?

正確で決定論的なリプレイは、公開されておらず、保証もされていません。監査ログ、スレッド、レビュー可能なSQL、データマップのバージョン履歴、およびウェアハウスのレコードは実行の再構築に役立ちますが、すべての回答をデータ、権限、データマップ、およびモデルランタイムの不変のスナップショットに結び付ける文書化された識別子はありません。厳格な再現性の要件を持つ組織は、独自のバージョン管理された証拠マニフェストを保持する必要があります。

セキュリティとコンプライアンス

データはどこに保持されますか?また、モデルのトレーニングに使用されますか?

エンタープライズデータは、Perplexityモデルのトレーニングやファインチューニングには使用されません。Computerのタスクは独立したサンドボックスで実行され、資格情報はサンドボックスとともに破棄されます。セッションアーティファクトとウェアハウスのクエリ履歴は個別に管理されます。添付されたセッションファイルは7日後に削除されます。エンタープライズ組織向けには、追加の設定可能な保持設定を利用できます。

セッションリソース

次のステップに進む準備はできましたか?

Perplexity が働き方をどう変えるかをご覧ください