AWS Clean Roomsで結合した データを使った機械学習 3rd Party Dataを用いた機械学習 2023/06/24 第24回勉強会

自己紹介 ● 名前: 西岡 賢一郎 ○ Twitter: @ken_nishi ○ note: 西岡賢一郎@研究者から経営者へ (https://note.com/kenichiro) ○ YouTube: 【経営xデータサイエンスx開発】西岡 賢一郎のチャンネル (https://www.youtube.com/channel/UCpiskjqLv1AJg64jFCQIyBg) ● 経歴 ○ 東京大学で位置予測アルゴリズムを研究し博士 (学術) を取得 ○ 東京大学の博士課程在学中にデータサイエンスをもとにしたサービスを提供する株式会社ト ライディアを設立 ○ トライディアを別のIT会社に売却し、CTOとして3年半務め、2021年10月末にCTOを退職 ○ CDPのスタートアップ (Sr. PdM)・株式会社データインフォームド (CEO)・株式会社ディース タッツ (CTO) ○ 自社および他社のプロダクト開発チーム・データサイエンスチームの立ち上げ経験

本日のお話 AWS Clean Roomsで結合したデータを使った機械学習の可能性について紹介 ● AWS Clean Roomsと2つのAnalysis Rule ● 機械学習に必要なデータ ● AWS Clean Roomsで生成されるデータの実例

AWS Clean Roomsと2つのAnalysis Rule

AWS Clean Roomsとは ● 生データを相手に共有することなく、3rd Partyデータを結合して分析できるようにするツール ● 結合のためのキーが必要 (e.g. 個人識別子) ● 結合に使用したキーは分析結果からは省かれる Data Clean Roomの分析イメージ

AWS Clean Roomsの2種類のAnalysis Rule AWS Clean Roomsの分析は2種類 ● Aggregation Type ○ COUNT、SUM、AVG関数を用いて統計情報を 任意の次元で集計するクエリーが可能 ○ セグメント分析、測定、アトリビューション など ● List Type ○ クエリ可能なメンバーのテーブルの重なりの 行レベルのリストを出力するクエリを許可 ○ データのエンリッチメントやセグメント構築 など

Analysis Rule Typeの制約 ● 異なる種類のAnalysis Rule Typeを使うクエリを走らせることはできない ● AggregationのRuleを持つテーブルのみ、もしくはListのRuleを持つテーブルのみ でクエリを構成する必要がある ● 同じテーブルをもとにしていても、Analysis Type用とList Type用それぞれのテー ブルを設定する必要がある

機械学習に必要なデータ

よくある機械学習 ● 学習に必要となる変数 ○ 教師あり学習: 説明変数と目的変数 ○ 教師なし学習: 説明変数 ● 複数ユーザのデータを用いてモデルを学習 ● 学習したモデルを用いて、ユーザ一人ひとりをスコアリング

AWS Clean Roomsで学習・推論データを用意 ● 学習と推論で説明変数を揃える必要がある

AWS Clean Roomsで生成されるデータ ● 結合には主に個人識別子が使われる ● 結合のキーは分析結果から取り除かれる ● 片方のデータをフィルタリングとしてのみ使うこともありうる ○ e. g. 属性C = Xに限定し、企業Aのデータのみでモデルを学習

Analysis Ruleによる出力結果の違い ● 結合に使ったキーが取り除かれるのは、Aggregation TypeとList Typeで共 通 ● Aggregation Typeでは複数ユーザが集計された結果となる ● List Typeではユーザの集計はされないが、重複する結果が削除される

AWS Clean Roomsで生成されるデータの実例

今回使用するデモデータ ● 2種類のAnalysis Rule ○ 3rd PartyデータをAggregation Typeで集計しつつ結合 ■ 3rd Partyに保存されている広告インプレッションデータを用いた分析 ○ 3rd PartyデータをList Typeで結合 ■ 3rd Partyに保存されているユーザ属性データを用いた分析

Analysis Rule: Aggregation Type ● Aggregate functions ○ 許可する集計関数とその関数を利用できるカラムを指定 ○ COUNT, COUNT DISTINCT, SUM, SUM DISTINCT, AVGか ら選択可能 ● Join controls ○ 他のテーブルとINNER JOINするためのキーを設定 (複数 キー指定可能) ○ JOINで使用するキーはクエリ結果には表示されない ○ テーブル単体でのクエリ (JOINなしのクエリ) の許可 ● Dimension controls (optional) ○ 集計するためのディメンション (キー) を指定 ● Scalar functions ○ ABS, ROUND, CASTなど13個の関数 (2023/04/29現在) から選択 可能 ○ 適用可能なスカラー関数を制御 ○ ディメンション列に適用可能 ○ 他の関数の上や他の関数内で使用できない ● Aggregation constraints ○ クエリ結果で返す行を制御 ○ 最小の集計値を設定できる (2以上)

Aggregation Typeで生成されるデータ ● 生成されるデータは複数のユーザがグルーピングされた状態で出力される ● しきい値以下のグループは削除されるが、しきい値以上であれば人数がわか るので、レコードを分割することで学習モデルを構築することは可能

グループされたデータを分割 グループされたデータを分割すると同じ特徴を持つユーザを複数作ることとなってしまい、モ デルに影響を与えてしまう

Analysis Rule: List Type ● Join controls ○ 他のテーブルとINNER JOINするためのキーを設定 (複数キー指定可能) ○ JOINで使用するキーはクエリ結果には表示されない ● List controls ○ 出力できるカラムを指定 ● AggregationのRule Typeに比べて指定する事項は少ない

List Typeで生成されるデータ ● ユーザ一人ひとりのレコードを作成できる ● DISTINCTで重複は削除されてしまう ● 結合に使った個人識別子は削除されてしまうので、このままだと推論に用いることができない ● 個人ごとの推論が必要ない場合なら問題ない ○ e. g. 推論値の分布などを用いたい場合など

List Typeの抜け道 ● 結合に使う個人識別子と対応する別のキーがあると、ユーザごとのデータを抽出で きてしまう ● このデータを用いれば、通常の学習および推論が実施できる ● ただし、この使い方は、AWS Clean Roomsを使用する目的と反する可能性がある

まとめ ● Aggregation TypeとList Typeのどちらでも機械学習に必要な説明変数と目 的変数を生成することは可能 ○ Aggregation Typeでは集計結果となるため、特徴量が平均化されてしまう ○ List Typeでは重複する行はまとめられる ○ 結合に用いる個人識別子はデータ生成過程で取り除かれてしまう ● List Typeを用いれば、個人識別子と対応するカラムを抽出することも可能 (ただし、データを保護するという目的からずれる可能性もある) ● 機械学習では、List Typeの方が使いやすい