サイトへの侵入者（詐欺）と戦うための自動システムの作成

過去約 XNUMX か月間、私は不正行為 (不正行為、不正行為など) に対処するためのシステムを、そのための初期インフラストラクチャなしで作成してきました。 私たちが見つけてシステムに実装した今日のアイデアは、多くの不正行為の検出と分析に役立ちます。 この記事では、技術的な部分には立ち入らずに、私たちが従った原則と、システムの現在の状態を達成するために何をしたかについて話したいと思います。

私たちのシステムの原則

「自動」や「詐欺」などの用語を聞くと、おそらく機械学習、Apache Spark、Hadoop、Python、Airflow、および Apache Foundation エコシステムやデータ サイエンス分野のその他のテクノロジーについて考え始めるでしょう。 これらのツールの使用には、通常は言及されない側面があると思います。それは、使用する前にエンタープライズ システムに特定の前提条件が整っている必要があるということです。 つまり、データ レイクとストレージを含むエンタープライズ データ プラットフォームが必要です。 しかし、そのようなプラットフォームがなく、それでもこのプラクティスを開発する必要がある場合はどうすればよいでしょうか? 以下で説明する原則は、実用的なアイデアを見つけるのではなく、アイデアを改善することに集中できる点に到達するのに役立ちました。 ただし、これはプロジェクトの「停滞期」ではありません。 計画には技術面と製品面でさらに多くのことが含まれています。

原則 1: ビジネス価値を第一に

私たちは「ビジネス価値」をあらゆる取り組みの最前線に置きます。 一般に、自動分析システムは、高度な自動化と技術的な複雑性を備えた複雑なシステムのグループに属します。 完全なソリューションを最初から作成すると、非常に時間がかかります。 私たちはビジネス価値を第一に考え、技術の成熟度を第二に考えることにしました。 実生活では、これは私たちが先進技術を定説として受け入れないことを意味します。 私たちは、現時点で最適なテクノロジーを選択します。 時間が経つと、いくつかのモジュールを再実装する必要があるように見えるかもしれません。 これが私たちが受け入れた妥協案です。

原則 2: 拡張知能

機械学習ソリューションの開発に深く関わっていない人のほとんどは、人間の代替が目標であると考えるかもしれません。 実際、機械学習ソリューションは完璧とは程遠く、置き換えが可能なのは特定の領域のみです。 私たちは、不正行為に関するデータの不均衡と、機械学習モデルの機能の完全なリストを提供できないといういくつかの理由から、最初からこのアイデアを放棄しました。 対照的に、私たちは拡張インテリジェンス オプションを選択しました。 これは、AI のサポート的な役割に焦点を当てた人工知能の代替概念であり、認知技術が人間の知能に取って代わるものではなく、強化するように設計されているという事実を強調しています。 [1]

これを念頭に置くと、最初から完全な機械学習ソリューションを開発するには多大な労力が必要となり、ビジネスの価値創造が遅れてしまいます。 私たちは、ドメイン専門家の指導の下、機械学習の反復的に成長する側面を備えたシステムを構築することにしました。 このようなシステムの開発で難しいのは、これが不正行為であるかどうかだけではなく、アナリストにケーススタディを提供する必要があることです。 一般に、顧客の行動の異常は不審なケースであり、専門家が調査し、何らかの対応をする必要があります。 これらの記録された事件のうち、実際に詐欺として分類できるのはほんのわずかです。

原則 3: 豊富な分析プラットフォーム

私たちのシステムで最も難しい部分は、システムのワークフローのエンドツーエンドの検証です。 アナリストと開発者は、分析に使用されたすべての指標を含む履歴データセットを簡単に取得できる必要があります。 さらに、データ プラットフォームは、既存の指標セットを新しい指標で補完する簡単な方法を提供する必要があります。 私たちが作成するプロセスは、単なるソフトウェア プロセスではなく、前の期間の再計算、新しい指標の追加、データ予測の変更を容易にする必要があります。 これは、実稼働システムが生成するすべてのデータを蓄積することで実現できます。 そうなると、だんだんとデータが邪魔になってきます。 増え続ける使用しないデータを保存し、保護する必要があります。 このようなシナリオでは、データは時間の経過とともにますます無関係になりますが、それでもデータを管理する努力が必要です。 私たちにとって、データの蓄積は意味がなかったので、別のアプローチを使用することにしました。 私たちは、分類したい対象エンティティを中心にリアルタイム データ ウェアハウスを編成し、最新の期間を確認できるデータのみを保存することにしました。 この取り組みの課題は、私たちのシステムが複数のデータ ストアとソフトウェア モジュールを備えた異機種混合であり、一貫した方法で動作させるには慎重な計画が必要であることです。

当社システムの設計コンセプト

私たちのシステムには、取り込みシステム、計算システム、BI 分析、追跡システムという XNUMX つの主要コンポーネントがあります。 これらは特定の分離された目的を果たしており、私たちは特定の開発アプローチに従ってそれらを分離したままにしています。

契約に基づいた設計

まず最初に、コンポーネントはコンポーネント間で受け渡される特定のデータ構造 (コントラクト) のみに依存すべきであるということに同意しました。 これにより、コンポーネント間の統合が容易になり、コンポーネントの特定の構成 (および順序) を強制する必要がなくなります。 たとえば、場合によっては、これにより受信システムをアラート追跡システムと直接統合できるようになります。 この場合、これは合意された通知契約に従って行われます。 これは、他のコンポーネントが使用できるコントラクトを使用して、両方のコンポーネントが統合されることを意味します。 入力システムから追跡システムにアラートを追加するための追加の契約は追加しません。 このアプローチでは、あらかじめ定められた最小数の契約を使用する必要があり、システムと通信が簡素化されます。 基本的に、私たちは「Contract First Design」と呼ばれるアプローチを採用しており、それをストリーミング契約に適用しています。 [2]

どこでもストリーミング

システム内で状態を保存および管理すると、必然的に実装が複雑になります。 一般に、状態はどのコンポーネントからもアクセスできる必要があり、状態は一貫性があり、すべてのコンポーネントにわたって最新の値を提供する必要があり、正しい値で信頼できるものでなければなりません。 さらに、最新の状態を取得するために永続ストレージを呼び出すと、I/O の量が増加し、リアルタイム パイプラインで使用されるアルゴリズムが複雑になります。 このため、可能であれば状態ストレージをシステムから完全に削除することにしました。 このアプローチでは、送信されるデータ ユニット (メッセージ) に必要なデータがすべて含まれている必要があります。 たとえば、いくつかの観測値の合計数 (特定の特性を持つ操作またはケースの数) を計算する必要がある場合、メモリ内で計算し、そのような値のストリームを生成します。 依存モジュールはパーティショニングとバッチ処理を使用してストリームをエンティティごとに分割し、最新の値を操作します。 このアプローチにより、そのようなデータを保存するための永続ディスク ストレージが必要なくなりました。 私たちのシステムはメッセージ ブローカーとして Kafka を使用しており、KSQL を使用してデータベースとして使用できます。 [3] しかし、これを使用すると、私たちのソリューションが Kafka に強く結びついてしまうため、私たちはそれを使用しないことにしました。 私たちが選択したアプローチにより、システムに大きな内部変更を加えることなく、Kafka を別のメッセージ ブローカーに置き換えることができます。

この概念は、ディスク ストレージやデータベースを使用しないという意味ではありません。 システムのパフォーマンスをチェックして分析するには、さまざまな指標や状態を表す大量のデータをディスクに保存する必要があります。 ここで重要な点は、リアルタイム アルゴリズムはそのようなデータに依存しないということです。 ほとんどの場合、保存されたデータは、オフライン分析、デバッグ、特定のケースとシステムが生成する結果の追跡に使用されます。

システムの問題

ある程度のレベルまで解決できた問題もありますが、より思慮深い解決策が必要です。 それぞれの項目には独立した記事を作成する価値があるため、今のところはここでのみ言及したいと思います。

• データの自動分析、発見、探索のために意味のある関連データを生成するのに役立つプロセスとポリシーを定義する必要があります。
• システムを自動チューニングして最新のデータに更新する作業中の人による分析結果の紹介。 これはモデルの更新であるだけでなく、プロセスの更新とデータの理解の向上でもあります。
• IF-ELSE と ML の決定論的アプローチの間のバランスを見つける。 ある人は「ML は絶望的な人々のためのツールである」と言いました。 これは、アルゴリズムを最適化および改善する方法が分からなくなったときに ML を使用する必要があることを意味します。 一方、決定論的アプローチでは、予見できなかった異常を検出することはできません。
• データ内のメトリクス間の仮説や相関関係をテストする簡単な方法が必要です。
• システムには複数レベルの真陽性結果が必要です。 詐欺事件は、システムにとってプラスとみなされる全事件のほんの一部にすぎません。 たとえば、アナリストは検討のためにすべての疑わしいケースを受け取りたいと考えていますが、そのうちのほんの一部だけが不正です。 システムは、実際の詐欺であるか単なる疑わしい行為であるかにかかわらず、すべてのケースをアナリストに効果的に提供する必要があります。
• データ プラットフォームは、その場で作成および計算された計算を含む履歴データセットを取得できる必要があります。
• 少なくとも XNUMX つの異なる環境 (運用環境、実験環境 (ベータ)、開​​発者向け) でのシステム コンポーネントのいずれかのシンプルかつ自動展開。
• そして最後に大事なことを言い忘れました。 モデルを分析できる広範なベンチマーク プラットフォームを作成する必要があります。 [4]

リファレンス

1. 拡張知能とは何ですか?
2. API ファーストの設計手法の実装
3. Kafka が「イベント ストリーミング データベース」に変身
4. AUC—ROC 曲線について

出所： habr.com