注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
不正の検出や収益機会の提示など、アラートワークフローは自動的にユーザーがレビューするための問題を浮上させ、ボタンをクリックするだけで決定を下せます。これらのワークフローにより、チームはデータを手作業でつなぎ合わせる時間を費やすことなく、手元にある最も喫緊の問題を解決することに注意を集中できます。
FoundryのData Connectionとオントロジーを活用することで、組織はこのパターンを数ヶ月ではなく数日で実装し、安全かつ効率的にカスタマイズやメンテナンスを続けることができます。
アラートワークフローは、アラート(更新、問題、機会など)を自動的に浮上させ、ユーザーがレビューして決定を下すように設計されています。通常、ユーザーは優先順位の高いアラートとそれに関連するデータが提示され、それをもとに決定を下します。彼らの決定は、Foundryのデータに(場合によっては適切な場合はプロダクションシステムにも)書き戻すボタンを使って記録されます。
例として、不正検出のユーザーは、最も高い確率から最も低い確率の不正アラートのリストを受け取ることができます。アラートをクリックすると、ユーザーが不正かどうかを示すシンプルなボタンを使って、すべての関連情報が表示されます。
アラートフレームワークは、さまざまなデータソースを精査し、手作業でデータポイントを組み合わせて問題を特定し、問題の解決方法を決定するのに多くの時間を費やすユーザーにとって、非常に効果的なソリューションです。時には、エンドユーザーがこれらの問題の一部を浮上させる基本的なSQLクエリを持っていたり、作業が複雑すぎてデータを精査しないこともあります。
アラートは、不正の検出から収益機会の提示まで、さまざまなユースケースで使用できます。アラートは、データパイプライン、機械学習モデル、FoundryのRules、またはこれらの組み合わせを使って生成することができます。
以下は、アラートワークフローに関連するインターフェースのリストです。
アラートインターフェースは、ユーザーが活用する主要なアプリケーションです。このインターフェースから、エンドユーザーはすべてのアラート、アラートに関する決定を助けるデータ、そして決定を記録するために使用できるボタンを確認できます。
例として、以下に最も頻繁に使用されるコンポーネントが含まれたインターフェースが示されています。このインターフェースは、通常、Workshopで構築されます。
例えば、不正検出では、フィルターは不正確率スコアや特定の種類の不正などになる可能性があります。アラート自体は不正のケースであり、関連データには過去の支払いやユーザープロファイルが含まれることがあります。ボタンには通常、不正/不正でないといった選択肢が含まれ、ユーザーに説明を求めることがあります。
関連製品:
インパクトトラッカーは、アラートインターフェースに関連するプロダクションおよび運用指標を表示します。トラッカーは通常、マネージャーがアラートインターフェースでどのような決定が一般的に行われているか、目標KPIにどれだけ近づいているかなど、解決されたアラートの数などの指標をレビューするために使用されます。
以下に、最も頻繁に使用されるコンポーネントが含まれた例のトラッカーが示されています。このインターフェースは、QuiverまたはWorkshopで構築されることがあります。
不正検出では、このインパクトトラッカーは、レビューされた不正/非不正ケースの割合、ユーザーによって入力された不正の主要要因や説明、早期に不正を検出することで節約されるドルの影響、決定までの時間などを示すことがあります。
関連製品:
Foundry Rulesは、Foundryアプリケーションであり、コーディングの背景に関係なく、任意のユーザーがデータに対するルールを作成および維持することができるように、基準を定義するためのユーザーフレンドリーなポイント・アンド・クリックインターフェースを提供します。定義された各ルールは、アラートの種類を作成します。Foundry Rulesの実装は、以下のアラート自動化セクションで詳述されています。
関連製品:
以下は、アラートワークフローの設定に関連するオントロジー関連の概念のリストです。
アラートワークフローには、通常、トリガーのオブジェクトタイプ(顧客、金融取引、製造プロセス、サービスタイプなど)と、それに関連する特定のアラートオブジェクト(潜在的な不正アラート、サービスタイプに関連する収益機会、製造プロセスに関連するプロセス最適化機会など)が含まれます。
関連製品:
アクションは、このワークフローの中核であり、エンドユーザーの決定を記録します。ユーザーの視点では、これらはクリックするボタンです。バックエンドでは、ボタンはオントロジーアクションによって動作し、ユーザーがどのような決定をしたかを記録するように設定されています。典型的なアクションフィールドには以下が含まれます。
不正検出では、アクションはケースが不正かどうか、決定を下したユーザー、決定した時刻、その決定の理由(説明)、およびレビューされた特定のケースIDを記録します。
関連製品:
書き戻しは、Foundryでの決定を記録するための用語です。ドキュメントはWritebackページにあります。本質的には、オントロジーアプリケーションを通じてアラートオブジェクトのデータセットのコピーが作成されます。アクションは、アクションセクションで定義されたフィールドを、コピーされた(書き戻された)データセットに記録します。不正検出では、特定のケースで行われたアクションは、その後、オントロジーおよび関連データセットを更新して、行われた決定を反映させます(例えば、アラートが不正を特定したかどうかや調査結果の説明を設定します)。
Foundryに書き戻すだけでなく、SAPやOracleなどの本番システムにも書き戻すことが一般的です。これには通常、本番システムとの直接接続を読み取りおよび書き込み権限で設定し、書き戻しデータセットの結果を接続経由でフィードすることが含まれます。詳細については、パラントールチームにお問い合わせください。
関連製品:
以下は、Foundryでアラートを自動化するための関連トピックです。
Foundry Rulesは、コーディングのバックグラウンドや能力に関係なく、ユーザーがデータに対するルールを作成および維持できるようにするコンポーネントのセットです。Foundry Rulesは、任意の条件に基づいてさまざまな種類のアラートを定義するために使用できます。Foundry Rulesの出力は、アラートオブジェクトに変換することができます。
以下に、Foundry Rulesインターフェースの例が示されています。
不正検出では、顧客が特定の不正行為を定義し、それに該当するすべての関連ケースを浮上させるために、Foundry Rulesを使用することを選択することがあります。たとえば、ルールは、顧客が1日に2回以上の連続した課金を行った場合や、2つの異なる都市で同じ日に2回の連続した課金を行った場合などです。
関連製品:
時には、アラートの作成に関するロジックが非常に規定的であり、複雑なルールがデータパイプラインでコーディングされるのが最適です。
例えば、保険会社は、契約率に基づいて医療提供者に対する請求金額を支払わなければならず、その契約率はシステム内のコードのセットとして反映されます。契約が再交渉されると、新しい期間用の新しいコードセットが記録されるべきです。この場合、どのコードをいつ適用すべきかのロジックをすべてエンコードし、Foundryの提案オブジェクトを作成し、再交渉された契約からの新しいコードセットとともに期間を分割する提案をするのが最適です。
関連製品:
どのパターンを使用する場合でも、基礎となるデータ基盤は、パイプラインと外部ソースシステムへの同期から構築されます。
データ統合パイプラインは、SQL、Python、Javaなどのさまざまな言語で記述され、データソースをオントロジーに統合するために使用されます。
Foundryは、FTP、JDBC、REST API、S3など、幅広いソースからのデータ同期が可能です。さまざまなソースからのデータ同期と最も完全な真実のソースのコンパイルは、最も価値の高い決定を可能にするための鍵です。
このユースケースパターンに関する詳細情報が必要ですか? 類似のものを実装したいですか? Palantirで始める。