DataRobot とは

DataRobotは、データ前処理からモデル構築、デプロイ、モデル運用までを自動化するエンタープライズ向けAIプラットフォームです。DataRobotは、多様なデータソースからデータを簡単に取り込み、さまざまな機械学習アルゴリズムを使用して、ビジネスニーズに合った高精度なモデルを迅速に構築します。さらに、モデルの稼働状況や精度・データドリフト・バイアスと公平性など様々な観点でモデルのパフォーマンスを監視し、持続可能なモデル運用を実現します。

Apache Airflow とは

Apache Airflowは、オープンソースのワークフローオーケストレーションツールです。データ取得、ETLジョブ、機械学習タスクなど、さまざまなタスクをスケジュールして実行するために使用できます。スケーラブルで信頼性の高いワークフローを構築するための強力なフレームワークを提供します。

Apache AirflowとDataRobotを連携するメリット

DataRobotとApache Airflowを連携するとMLOpsワークフローを強化できます。これにより次のようなメリットが享受できます。

メリット１：モデルトレーニングとデプロイの自動化

機械学習のビジネス利用ではモデルトレーニング、デプロイ、予測を定義したMLOpsワークフローが必要となるケースがあります。特に定期的にモデルを再トレーニングするケースや、頻繁にデータドリフトが起こりその都度再トレーニングが必要となるケースではMLOpsワークフローの構築は必須です。MLOpsワークフローを事前に作成することで、外部環境の変化に迅速に対応し、モデルの品質とパフォーマンスを維持できます。

DAG (Directed Acyclic Graph)構築

DataRobotとApache Airflowを連携することで、たとえば図1のようなMLOpsワークフローを構築できます。この例では、Apache Airflowを使用して、DataRobotのジョブ（モデルトレーニング、デプロイ、予測）をスケジュールして実行しています。

なおDataRobot単独でも再トレーニングの自動化機能があり、再トレーニングのスケジュール実行や異常時の実行が可能です。それに対し、DataRobotとApache Airflowを連携することのメリットは、データ取得、ETLジョブまで含めたパイプラインをより柔軟にカスタマイズできる点にあるといえます。

メリット２：MLOpsワークフローの可視化とデバッグ

図1のようにApache Airflowは、MLOpsワークフローの実行状況を可視化するための強力なダッシュボードを提供します。また、ワークフローの進行状況をリアルタイムに確認でき、問題が発生した場合にはログを解析できます（図2）。これにより、ワークフローを監視し、問題をデバッグします。

メリット３：マルチクラウドへの対応

近年、企業におけるクラウド利用において、単一のクラウドベンダーに依存するのではなく、複数のクラウドサービスを組み合わせる「マルチクラウド」を採用するケースがあります。「マルチクラウド」には主に以下のようなメリットがあります。

• ベンダーロックインの回避
• 可用性の向上
• 柔軟性の向上

一方で、複数のクラウドに分散したデータやモデルを管理するためには、適切なガバナンス体制を構築したりスキル人材を獲得したりする必要があります。これは、特に大規模な組織においては大きな課題となります。

その課題に対して、Apache Airflowは各クラウドと接続することができるため、データが複数のクラウドに分散していてもワークフローを構築できます。

これはApache Airflowを利用すればデータのサイロ化を解決できると言っているわけではありません。マルチクラウド環境でも、機械学習に用いるデータは1つのデータウェアハウスやデータレイクに集約することがマルチクラウドの複雑さを解決する直接的な方法です。

1つのデータウェアハウスやデータレイクにデータを集約しておけば、データの管理コストを減らせるだけでなくチーム内外でのコラボレーションが加速するからです。

Apache AirflowとDataRobotを連携する方法

DataRobotとApache Airflowを連携するには、次の手順を実行します。詳細はApache Airflow用のDataRobot プロバイダーをご覧ください。

• Apache AirflowとDataRobotを連携する際の前提条件

DataRobotプロバイダーを使用するには、以下の依存関係をインストールした環境が必要です。

• Apache AirflowとDataRobotの連携手順

　（手順1） DataRobot APIキーを取得し、Apache Airflow上で接続設定を行います（図3）。

　（手順2）Apache Airflow環境にDataRobotプロバイダーをインストールします。Apache Airflow DAGページにインストールしたDataRobotプロバイダーが表示されます（図4）。

Apache Airflow用のDataRobotプロバイダーは、公開されているGitHubレポジトリからダウンロードできます。

DataRobotプロバイダーのモジュールには、DataRobot MLパイプラインのステップを自動化する複数のDataRobotオペレータとセンサーがあります。以下に代表的なオペレーターやセンサーを示します。各オペレータは特定のジョブを実行し、各センサーは事前に設定された動作が完了するのを待ちます。

オペレータ

• CreateProjectOperator: DataRobotプロジェクトを作成し、そのIDを返します。
• TrainModelsOperator: DataRobotのオートパイロットを実行し、モデルをトレーニングします。
• DeployModelOperator: 特定のモデルをデプロイし、デプロイIDを返します。
• DeployRecommendedModelOperator: 推奨モデルをデプロイし、デプロイIDを返します。
• ScorePredictionsOperator: デプロイしたモデルに対して予測を行い、バッチ予測ジョブ ID を返します。

センサー

• AutopilotCompleteSensor: Autopilotが完了したかどうかをチェックします。
• ScoringCompleteSensor: バッチスコアリングが完了したかどうかをチェックします。

　（手順3）Apache Airflow DAGを用いて、DataRobotジョブをスケジュールします。

Apache AirflowとDataRobotの連携でMLOpsワークフロー強化を実現

DataRobotとApache Airflowを連携することで、機械学習パイプラインを自動化しMLOpsワークフローを強化できます。これにより、データからより多くの価値を引き出すことができます。ぜひ、DataRobotとApache Airflowの組み合わせでMLOpsの可能性を広げてください。

機械学習プロジェクトの効率化を図るなら「DataRobot」

DataRobotでは、トライアル環境を提供しています。以下のURLから、アカウントを作成することができます。

https://www.datarobot.com/jp/trial/

トライアル環境では、DataRobotの主要な機能を使用することができます。機械学習モデルの開発や運用に興味がある方やすでに携わっている方も、ぜひこの機会にDataRobotを体験してみてください。

投稿 Apache AirflowとDataRobotを連携してMLOpsワークフローを強化する方法 は DataRobot に最初に表示されました。

今回は数ある機械学習のモデル精度の評価指標の中でも私のお気に入りであるにも関わらず前回の最適化指標ブログでは取り扱うことができなかったFVE  Binominalについて紹介したいと思います。分類モデルの精度を単一の指標で測る上ではトータルバランスで現時点最強の評価指標だと考えています。これまで分類問題ではとりあえずAUCを使っていた人もこのブログをきっかけにFVE  Binominalを利用いただければ幸いです。

機械学習モデル評価指標の重要性

機械学習モデルを構築する際にはモデルをどのようにフィッティングさせるかを基準に最適化指標および損失関数を決めていきます。多くの場合、その最適化指標を最も小さくしたモデルを選択することによって一番精度の良いモデルを選ぶというアプローチを行います。ただ、コンペティションのように争う指標が決まっているのであれば、その指標を基に判断するだけですが（実際には共通の目的で争うため、コンペは全く違う血肉を争う戦いがあります）、実務で機械学習を行う場合にはどの評価軸でモデルを比較するかの決定を下すことも重要となります。

評価軸が決まった後には、精度が最終的に合格かを判定する上では、きちんとした検証基準を置く必要があります。ただし、厳密な検証は手間もかかるので、実務者はとりあえず作成したモデルが「大体どれくらい精度がいいものか」知りたいということは多々あります。二値分類問題においては、多くの方がAUCをこの用途で利用しているかと思います。「AUCが0.5であれば完全にランダムなモデルと変わらない。AUCが0.8を超えていたら相当いいモデルとなっている。0.9を超えると精度が良すぎるのでリーケージを疑いたい」こういった話を聞いてモデルの評価基準にしている方は少なくありません。ただAUCには向いていないケースもあり、その評価指標の本質を理解していないとよもやの事故に遭う可能性もあります。

機械学習モデル評価指標「AUC(Area Under the Curve)」とは

AUCはArea Under the Curveを略したもので、一般的にはROC（Receiver  Operating Characteristic）曲線の下の面積（別のパターンとしてPR曲線の下の面積をとったものも存在しますが、本ブログではROC-AUCを以降AUCとして表記します）を表したものとなっています。

AUC(Area Under the Curve)の性質

ROC曲線はy軸をリコール、x軸を偽陽性率（フォールアウト）としたときに、モデルが取れる組み合わせをプロットしたときに描かれる曲線となっています。AUCの定義から完璧なモデルの場合にはリコールが1で偽陽性率が0となり、面積は1×1=1となります。逆にランダムなモデルを作るとROC曲線はリコール、偽陽性率（0,0）とリコール、偽陽性率（1,1）を結ぶ直線となり、AUCは三角形の面積の通り、1x1x0.5=0.5となります。この性質からAUCはプロジェクトが違ってもモデル精度をざっくりと比較でき、多くのプロジェクトにおいてモデルの精度を簡易的に測る上で頻繁に利用される指標となっています。ちなみに金融業界の与信モデルの評価指標としてよく使用されるAR値は2AUC-1と同義のため、AR値もAUCと同じ性質を持っています。

機械学習モデル評価指標「AUC(Area Under the Curve)」の欠点

では、機械学習モデル評価指標であるAUCの欠点について解説します。

AUCはリコールと偽陽性率（１）のみを見ていることから、結果として予測値順に並べた時の精度だけを見ていることになり、予測値と実測値の乖離をみていません。そしてターゲット比率が0.1%を切るようなプロジェクトにおいては、AUCが簡単に0.8を超えるなど高くなる傾向があります。AUCが高いのに実際に運用すると、思った以上にパフォーマンスが出ない（ビジネス指標における効果が出ない）ということがあります。

AUC(Area Under the Curve)活用時の失敗事例 

AUCが予測の順位しか見ないという特性を知らずに使用すると、思わぬ事故に遭遇する可能性があります。例えば、「正例が少ないためダウンサンプリングしたデータセットでモデリングを行い、高いAUCが得られた。しかし、本番での運用では予測値と実際の値に大きな乖離が生じた。予測の乖離があるにもかかわらず、AUCは悪化していなかったため、問題に気付くのに時間がかかった」という事例が挙げられます。

AUC(Area Under the Curve)失敗事例の検証

このような現象は簡単に試せるため、元のデータにダウンサンプリングを施し、AUCスコアの変化を観察してみましょう。

AUCがホールドアウトでも変化しないのがわかるかと思います。 ここで予測値と実測値の乖離も見れるリフトチャートを同じモデルで見て行きましょう。

学習データ（交差検定）では予測の青のラインと実測のオレンジのラインがうまくフィットしているのが分かります。ただ、ホールドアウトでは、予測の青のラインは正しく右肩上がりになっていることから傾向は捉えているように見えますが、予測値が大きく乖離しています。AUCはホールドアウトでも下がっていませんでしたが、これはAUCが順列を見ているという性質から説明でき、実はリフトチャートでも右肩上がりになっていたことからこのモデルは順列としては正しいものでした。

予測値は大幅に乖離しても順列だけはあっていれば問題ないAUCは、マーケティングのターゲティング分析のように上位1万件にDMを送付するという予測値そのものに注目しない分析では問題ありません。ただ、一件当たりのDMのコストを考えて予測CV率がx以上に送りたいなどを考えている、予測値に対して金利を設定するなどの場合には、全く役に立たないモデルになっているリスクを内包しています。

※ちなみにDataRobot内で実施するスマートダウンサンプリングは名前にスマートがついているように、ダウンサンプリングした比率のウェイトを入れることによって、上記の事象が発生するのを防ぐ仕組みが実装されております。

機械学習モデル評価指標「FVE (Fraction of variance) Binominal」とは

AUCの欠点についてここまで記載していきましたが、ここからはFVE  Binominalについて紹介していきます。

「FVE (Fraction of variance) Binominal」の特徴

以前のブログでも二値分類においては最適化指標はLoglossが最強と書かせていただきましたが、評価指標で使う上ではターゲットの比率によって値が変わることからモデルのざっくりとした当てはまりの良さを考える上では不向きでした。Loglossが1を下回っているから必ずしも当てはまりの良いモデルができたとは限りません。このLoglossの評価関数としての欠点を解消したのがFVE  Binominalとなります。

「FVE (Fraction of variance) Binominal」考え方と機械学習モデル指標として優れている点

FVE Binominalは以下の式で表現することができます。

FVE Binominal = 1 – Logloss(Model X)/Logloss(Majority Class Classifier)

考え方はシンプルで、ひたすらターゲットのクラス比率に合わせて予測値を出すモデル(Majority Class Classifier)と比較してどれだけそのモデルが改善できているかを表現しています。FVEは説明されたdeviance（尤離度）の割合と考えることができます。

仮に作成したモデルが単純にターゲット比率に合わせた予測値を出すだけのモデルと同様であれば、Logloss(Model X)/Logloss(Majority Class Classifier) = 1となり、FVE  Binominalは0となります。仮に完璧なモデルができた場合には、Loglossは0となるため、FVE  Binominalは1となります。よくAUCで完全ランダムなら0.5で完璧なモデルなら1という表現がありますが、FVE  Binominalでも同じようにランダムなら0で完璧なら1と考えることができます。また、Loglossをベースにすることによって、より予測値の期待値的にうまくいっているのかという部分にフォーカスした評価指標となっていますので、順列だけでなく予測値そのものにも注目するケース（貸し倒れ確率と合わせて金利テーブルを作成する場合など）ではとても有用な指標となります。

先ほどAUCではホールドアウトでも交差検定と比較してそこまで値の変化がしなかったものをFVE Binominalでみていくとホールドアウト部分がマイナス(-0.4361)になっているのが確認できます。ここから予測値と実測値がランダム以上に大きな乖離を持っていることがわかります。

機械学習モデル評価指標「FVE (Fraction of variance) Binominal」の精度

AUCだとみなさまの感覚として、0.75超えてきたならいいモデルで0.9超えたら怪しいという感覚（ここまでのブログからこの感覚が危険だということを理解した人も多いかと思いますが）を聞いたことがある人もいると思いますが、DataRobotのグローバルのデータサイエンティストの中で、FVE Binominalは以下のような基準で使われています。

———

プロジェクトが終了したら、最適なモデルをFVE Binomialで見てみましょう。

– FVE Binominal が0に近い＝機械学習には不向きなユースケース

– FVE Binominal > 0.25 = 良いユースケース

– FVE Binominal が1に近い = ターゲットリーケージを疑うべき状態

———

これは、DataRobotのグローバルで活躍するデータサイエンティストの経験則ですが、FVE Binominalが0.15など0から0.25の間の時はいくつかの解釈ができ、まだモデルの説明力をあげられる段階であり、チューニングやデータを追加すれば精度をあげられる可能性もありますし、ランダムよりは良いので、用途によっては問題ない精度ということもありえます。あくまでFVE Binominalもざっくりと当てはまり具合を見るものであって、犬と猫の分類のように簡単な問題であれば1に近づきますし、金融市場分析などで0.1を超えることも難しいということは覚えておいてください。

機械学習モデル評価指標「FVE (Fraction of variance) Binominal」の注意点

FVE Binominalの注意点をいくつかあげるとすると算出ロジックのベースがLoglossのため、Loglossと同じように誤ラベルの影響を大きく受けます。実際にはTrueのものがFalseとなっていた時にモデルが99%Trueと予測できていたにも関わらずデータ上はFalseのためLoglossが大きくなります。そのため、誤ラベルがある程度紛れてしまうような分析では、過小にモデルが評価される可能性があることには注意が必要です。またAUCでは順列を見ていて、FVE Binominalではスコアを見ているという性質からですが、仮にモデルの活用が予測値の上位x件を抽出した上でアクションを実行するという順列のみを見るケースではAUCを利用する場合もあります。FVE Binominalでは上位x件に含まれないデータに対するスコアのつき方も評価しているので、ビジネスアクションと関係ない部分が評価に含まれているためです。そして1番の欠点が知名度だと思います。このFVE Binominalは知名度がまだまだ低いため、初見の人には通じない可能性があります。ただAUC 0.8というのがデータサイエンティスト以外に正しく伝わるかというとそこに疑問は残りますので、みなさんがFVE Binominalの良さを広めて知名度拡充に努めていただけると助かります。

別のFVEシリーズ

今回、分類問題の鉄板損失関数Loglossを正規化したFVE Binominalを紹介させていただきましたが、連続値問題（回帰問題）においてはよいモデルを作るにはターゲット分布によって損失関数を選択する必要があります。そして損失関数でpoissonやganmaやtweedieを選んだ際にはLoglossと同じようにモデルの当てはまり具合がわからず、結局リフトチャートや残差チャートを見て視覚的に判断する必要があった経験をされた方も多いかと思います。実はFVEの考えは、poissonやganmaやtweedieにも応用でき、DataRobotではそれぞれFVE poisson、FVE ganma、FVE tweedieとして評価指標が用意されています。定義はいずれも、

1 – (error / baseline model error)となり、0だとベースラインモデルと同じで1だと完璧なモデルを意味します。0.25を超えれば良いモデルという感覚もそのまま利用できます。連続値問題ではR^2を利用する方が多いかと思いますが、FVEはR^2と非常に似た性質を持っています。ただ、logリンク関数を利用したモデル（DataRobotでは最適化指標にpoissonやganmaやtweedieが選択された際のモデル）にも対応できる点でも便利な評価指標となっています。

AUCより優れた機械学習モデル評価指標「FVE (Fraction of variance) Binominal」を有効活用するコツ

予測値へのアクションにおいて、予測確率が重要なウェイトを占めるテーマにおいては、ARスコアやAUCよりもはるかに有用なFVE Binominalをぜひ有効活用してみてください。

慣れてくるとFVE Binominalで大体の予測分布の形が想像できるようになり、AUCよりも鮮明にモデルの当てはまり度を単一の数字で想像できるようになります。またモデル運用において、AUCは変わってないが、FVE Binominalが悪化しているというケースに当たった際には、それぞれの性質を加味し、ターゲットの比率が変わっている可能性があるという部分に気づくきっかけにもなります。

出典

（１）The Relationship Between Precision-Recall and ROC Curves（Jesse Davis/Mark Goadrich）

投稿 分類プロジェクトの評価でAUCよりも便利なFVE Binominal｜DataRobot機械学習モデル評価指標解説 は DataRobot に最初に表示されました。

DataRobotで製造業/ヘルスケア業界のお客様を担当しているデータサイエンティストの長野です。技術的には生成AI領域を担当し、日本市場での生成AIプロダクトの導入と顧客支援を担当しています。

本記事では、生成AIの中でも特に注目を集めている技術領域の一つである「RAG（Retrieval-Augmented Generation）」に焦点を当てつつ、DataRobotで実現できる内容について解説させていただきます。

なお、本記事と関連するウェビナー「生成AI最前線：DataRobotを用いた実践RAG構築」では、実際のデモンストレーションを交えながらRAGに関して解説していますので、合わせてご確認いただければ幸いです。

LLMの活用パターンとRAG(Retrieval-Augumented Generation)の立ち位置

RAGについて踏み込む前に、ビジネスにおける大規模言語モデル（Large Language Model、以下LLM）の活用パターンを整理すると、大きく以下の3つに分けることができます。

活用パターン1. 事前学習済みLLM

このパターンでは、ChatGPTなどの既存の生成AIサービスやGPT3.5などのLLMをそのまま利用することを指します。導入コストが低いことがメリットとして挙げられます。執筆時点で多くの企業ではこのパターンでのLLM活用は進んでいると感じます。

活用パターン2. 検索拡張型LLM

検索拡張型LLMは、ユーザーからの入力に対して関連する情報を元に検索し、その結果をもとに回答を生成します。本記事の題材であるRAGがこのパターンに該当します。執筆時点でOpenAI社のgpt-4-turbo-previewは2023年12月、gpt-3.5 turboは2021年9月までの学習であり、最新の情報や社内文書も学習していません。そのため検索拡張型LLMが、社内文書や最新の情報を踏まえたLLMを構築する手法として注目を集めています。

活用パターン3. 追加学習/自作LLM

最後に、独自のニーズに合わせてLLMを追加学習させたり、オリジナルのLLMを開発するアプローチがあります。個々のユースケースに柔軟に対応させたLLMの開発ができる一方で、多くの企業にとってはまだまだ技術的ハードルの高い手段です。

この3パターンの中で、RAGが導入コストとユースケースとのマッチ度の観点で多くのユーザーが取り組まれている技術となります。

RAG(Retrieval-Augumented Generation)の課題

前章で解説したようにRAGの構築は比較的簡単に導入できる手法であると認識されていますが、弊社が実際にRAG開発に取り組まれている企業にヒアリングすると成果が出ていないケースも見受けられます。以下はその理由をまとめたものです。

課題1: テーマに対して技術的な課題を適切に捉えられていなかった

• 社内の文章を入れたら簡単にRAGが構築できると考え、あまり調査せずに中身がブラックボックスなツールを選定してしまう。
• Pythonライブラリを用いたRAG開発を試みるが、開発できるメンバーの不足や運用監視に苦労している。

課題2: RAGを構築できる人材が少なくスケールしない

• ユースケース毎に多くのRAGを開発する必要があるが、RAGの開発と運用監視の観点でプロジェクトが進んでいない。

課題3: 本番環境を想定した検証ができていなかった

• PoCを実施した結果、良さそうな結果は得られたが、本番導入を想定したハルシネーション対策や運用時の死活監視や精度監視までは確認できていない。

DataRobot生成AI機能を使うメリット

それでは、DataRobotの生成AI機能がこの問題に対してどのようにアプローチしているのかを以下の3つの視点からご紹介します。

DataRobot生成AI機能のメリット 1: RAGの開発

まず初めに、RAGが開発できないことには始まりません。DataRobotでは迅速なRAGの開発を実現できますが、この開発パートに関しては、後ほど詳しく解説します。

DataRobot生成AI機能のメリット2: API化/Webアプリ化

AIモデルを使って予測分析を行うユースケースでは予測結果のインサイトの取得も価値に繋がることが多く、実際に筆者が担当している製造業のお客様では要因分析のテーマでDataRobotをご活用されているケースも多くあります。要因分析のテーマでDataRobotをご活用されているお客様が非常に多くいます。一方で、生成AIのテーマでは、想定していた回答を返すだけではなく、実際にシステムへの組み込みやアプリケーションの開発まで求められるケースが非常に多いです。DataRobotではAPIによるシステム連携やStreamlitのDataRobotへのホスティング機能が充実しており、生成AI特有の課題に対しても十分にカバーできます。

DataRobot生成AI機能のメリット3: 運用監視とガードレール

予測AI/生成AIを問わず、あらゆるAIモデルはそのモデルを構築した時点から時間が経過すると精度パフォーマンスが劣化します。したがって、RAGを構築し生成AI機能を利用したアプリケーションを稼働させる際には、その精度パフォーマンスをはじめとする様々な品質指標を監視する仕組みも併せて稼働させることが必須です（予測AIモデルの運用を監視する仕組みはMLOpsと呼ばれていますが、生成AIシステムではLLMOpsと呼ばれています）。特に生成AIシステムでは、消費トークン数をトラッキングする、毒性のある単語/文章をガードレールにより弾くなど、様々な品質指標を設定してパフォーマンスを監視しながら、入力プロンプトの単位で適宜アクションをとる必要があります。DataRobotはこれらの要件に答えることができるAIライフサイクル・マネジメントプラットフォームです。

DataRobotを用いたRAG(Retrieval-Augumented Generation)構築

それでは、実際にDataRobotの画面を用いてRAGを構築してみます。NextGenインターフェイスでは予測AIと生成AIを同一のインターフェースから開発することができます。本ケースのようにRAGを構築する際は「データ」、「ベクターデータベース」、「プレイグラウンド」のタブを活用します。

データタブ：データの投入

RAGを構築する際に必要となるデータを投入します。2023年3月現在はtxtファイルとPDFファイルに対応しており、これらのファイルをZIPファイルにまとめて投入します。今回は、GPT3.5をそのまま使うと回答できないDataRobotの製品マニュアルをアップロードしてみました。

ベクターデータベースの構築

次にベクターデータベースを構築します。ベクターデータベースと聞くと構築が非常に困難に感じるかもしれませんが、DataRobotでは一つの画面上で簡単に設定することができます。主要なオプションを以下で解説します。

①埋め込みモデル

RAGに使用するデータを選択した後、「埋め込みモデル」タブをクリックし、今回使用する埋め込み（Embedding）モデルを選択します。Embeddingとは、後述するチャンクをベクトル情報に変換するモデルのことを指します。執筆時点では日本語も含む多言語対応モデルであるinfloat/multilingual-e5-baseなど、5種類のEmbeddingモデルから自由に選択することができます。埋め込み（Embedding）モデルの選択は回答の精度や出力のレスポンスに影響しますので、RAG開発フェーズで様々なモデルを試せることが重要です。infloat/multilingual-e5-baseのケースではチャンクを768次元のベクトル情報に展開します。これがベクターデータベースと呼ばれる理由です。

②チャンキング

チャンキングはテキストを分割する方法を指しており、一つ一つの固まりをチャンクと呼びます。一つ一つのチャンクをどのように分割するかによって同じデータでも得られる情報が変わります。極端な例ですが、文章を文単位の小さなチャンクに分割すると文脈の情報が欠落してしまいますし、反対に長文を一つのチャンクにすると本当に取得したい情報が得られないリスクがあります。チャンクを区切った際に、前後の文章も含める度合いをチャンクオーバーラップのパラメータで制御します。値を小さくしすぎると文脈が途切れてしまうリスクがありますが、大きくしすぎると、ベクターデータベースの容量が大きくなり、レスポンスタイムに影響します。

プレイグラウンドによる検証

ベクターデータベースの構築が完了したら、RAG構築の最後にプレイグラウンドを用いた実験を行います。プレイグラウンドは名前の通り、試行錯誤が非常にしやすい検証環境となっています。ここでは設定可能な主要パラメータについて解説します。

①LLM

LLMでは、DataRobotにプリセットされている多様なLLMの中から、自由に選択することができます。現在、選択肢としてGPT-3.5系、GPT-4系、AmazonTitan、Google Bisonの6種類が用意されています。さらに、皆様の会社で独自に契約されているLLMを、この選択肢に追加することも可能です（Bring-Your-Own LLM、以下BYOLLM）。

セキュリティポリシーの観点から、社内契約のLLMのみを使用可能な場合でも、BYOLLMのみをプレイグラウンド環境で利用する設定により、柔軟に対応することができます。これにより、各社のセキュリティ要件を満たしつつ、LLMの性能や特性を比較検討し、最適なモデルを選択することが可能になります。

②システムプロンプト

システムプロンプトは、通常のプロンプトとは異なる機能であり、RAGやLLMに対して、特定の役割や振る舞いを設定することができます。これにより、APIコストの最適化やエンドユーザーのニーズに合った回答の生成が可能になります。

ビジネスシーンにおいて、システムプロンプトを効果的に活用することで、例えば以下のようなメリットが期待できます。

トークン数の節約：「100文字以内で回答してください」といったプロンプトを設定することで、回答の文字数を制限し、トークン数を抑えることができます。

エンドユーザーのニーズに合った回答の提供：「箇条書きで答えてください」などのプロンプトを用いることで、情報を簡潔にまとめ、読みやすく構造化された回答を生成できます。

③ベクターデータベースを選択

こちらのタブを使用することで、RAGに用いるベクターデータベースを選択することができます。構築済みのベクターデータベースを選択することで、LLMに対して追加の文脈情報を提供し、より正確で関連性の高い回答を生成することが可能になります。もちろん、ベクターデータベースを選択しない場合は、素のLLMやシステムプロンプトのみを付与したLLMとして検証することも可能です。

RAGは一見すると複雑な技術に思えるかもしれませんが、DataRobotを使えば、実際の構築のプロセスは非常にシンプルになります。必要なデータを用意し、ボタンを数回クリックするだけで簡単にRAG用のベクターデータベースを作成することができますので、専門的な知識がなくても、誰でも手軽にRAGを活用することが可能となります。

RAGの設定が完了したので、実際の性能を確認してみましょう。画面の左側にはRAG（GPT3.5-Turbo + ベクターデータベース）の結果が、右側にはGPT-3.5 Turboのみの結果が表示されています。この比較機能を使うことで、データベースの有無による回答の違いを簡単に確認することができます。

DataRobotでは、最大3種類のブループリントを同時に比較することが可能です。これにより、異なるLLMやデータベースの組み合わせによる性能の違いを一目で把握することができます。

今回、「オートパイロットについて教えてください」というプロンプトを使って、素のGPT-3.5とRAGとの性能を比較してみました。その結果、両者の回答には明確な違いが見られました。

素のGPT-3.5では、ベクターデータベースを使用していないため、一般的な「オートパイロット」の概念について説明しています。つまり、自動運転技術や航空機の自動操縦システムなど、辞書的な定義に基づいた回答が生成されています。一方、RAGを構築したケースでは、DataRobotの文脈に基づいた回答が得られました(オートパイロットモードはDataRobotのモデリングモードの一つです)。

この比較結果から、RAGがタスクに関連する情報を適切に取り込み、文脈に沿った回答を生成できることが確認できました。データベースの選択と構築が適切に行われれば、RAGはビジネスにおける様々な場面で、より正確で有用な情報を提供できる可能性があります。

更に、RAGの場合は回答の生成に使った引用文を確認することができます。狙いたいドキュメントが正しく引用されているかなど、この画面を見ながらチェックします。

発展：RAG(Retrieval-Augumented Generation)のチューニングTips

最後に発展トピックスとしてRAGのチューニングのTipsについてご紹介します。RAGはデータの前処理やチャンキング戦略、プロンプトエンジニアリングと様々な改善ポイントがあるため、最初はどこから手をつけて良いのか分からないかもしれません。RAGは引用文を取得するまでの「検索パート」と引用文に含まれる情報から回答を生成する「生成パート」に分けることができます。大きな方針として、ドキュメントで狙いたい文章が引用文にない場合は、「生成パート」をいくら工夫しても精度を改善することは難しいので、まずは「検索パート」の工夫から考えてみるのが良いと思います。

「生成AI最前線：DataRobotを用いた実践RAG構築」Webinar無料視聴のご案内

本記事では、近年注目を集めているRetrieval-Augmented Generation（RAG）について、その基礎知識から実践的な活用方法までをDataRobotの生成AI機能にも触れながら包括的に解説いたしました。本記事が、RAGに関する理解を深め、皆様の生成AIプロジェクトの推進にお役立ていただければ幸いです。本記事と関連するウェビナー「生成AI最前線：DataRobotを用いた実践RAG構築」では、実際のデモンストレーションを交えながらRAGに関して解説しています。

投稿 RAG(Retrieval-Augumented Generation)構築と応用|生成AI×DataRobot活用術 は DataRobot に最初に表示されました。

ほとんどの企業は、最初に取り組むユースケースが予想以上に難しいことに気づきます。そして、疑問は山積みになっていきます。

ムーンショットプロジェクト（ハイリスク・ハイリターンのプロジェクト）を目指すべきか、それとも小さくとも着実に価値を創出できるように務めるべきか、あるいはその両方をミックスすべきか？どのように規模を拡大するのか？次に何をすべきなのか？悩みはつきないでしょう。

ChatGPTを筆頭とするGenerative modelsは、AIが活躍できるシチュエーションを完全に変え、組織にまったく新しい問いを投げかけました。予測AIから得られた価値を作るためのノウハウのうち、どのノウハウを生成AIに適用すればよいのでしょうか？

予測AIで価値を得るためにやるべきこと

予測AIから価値を生み出す企業は、最初のユースケースを積極的に提供する傾向があります。

彼らが実践している取り組むべきポイントは以下の通りです。 

・適切なプロジェクトを選択し、それらのプロジェクトを総合的に評価する

プロジェクトの技術的実現可能性に多くの時間を費やすという罠に陥りがちだが、成功しているチームは、組織の複数のレベルから適切なスポンサーシップと賛同を得ることも考えています。

・適切なステークホルダーをプロジェクトの早期から参加させる

最も成功しているチームは、結果に投資し、さらなるAIプロジェクトを依頼するビジネスユーザーを関係しています。

・成功の炎をあおる

プロジェクトの成功を祝い、鼓舞し、惰性を克服し、緊急性を生み出すことが大事です。ここでも、エグゼクティブ・スポンサーシップが大いに役立ちます。次なる野心的なプロジェクトの基盤を築くことに貢献します。

そして、私たちがお客様からよく言われる「やってはいけないこと」は以下の通りです。 

・最も困難で最も価値の高い問題から始めること

多くのリスクが生じるため、その問題から着手しないことをお勧めしています。

・データが完璧になるまでモデリングを延期すること

この考え方は、不必要に価値創出を先送りすることになりかねません。

・組織設計、オペレーティング・モデル、戦略を完璧にすることに集中すること

これによって、AIプロジェクトをスケールさせることが非常に困難になります。

生成AIの新たな技術的課題とは？

・計算要件の増加

生成AIのモデルを学習・実行するには、高性能の計算とハードウェアが必要になります。企業はこのハードウェアを所有するか、クラウドを利用する必要があります。

・モデルの評価

本来、生成AIモデルは新しいコンテンツを生み出します。予測モデルは、精度やAUCのような非常に明確な指標を使用します。生成AIでは、より主観的で複雑な評価指標が必要となり、実装が難しくなります。

人間が出力結果を評価するのではなく、体系的に評価することは、これらのモデルすべてに適用する公正な評価基準を決定することを意味しており、それは予測モデルを評価することに比べて難しい作業です。生成AIモデルを使い始めるのは簡単かもしれませんが、意味のある優れたモデルを生成させるのは難しいでしょう。

・倫理的なAI

企業は、生成AIのアウトプットが、成熟し、責任あるものであり、社会や組織にとって有害でないことを確認する必要があります。

生成AIの主な差別化要因と課題とは？

・正しい問題から始める

間違った問題を追及する組織は、価値を迅速に得ることに苦労します。例えば、費用対効果ではなく、生産性に焦点を当てる方が、はるかに成功しやすいと言えます。動きが遅すぎることも問題です。

・生成AIのユースケースのラストワンマイルは、予測的AIとは異なる

予測AIでは、ダッシュボードや利害関係者のフィードバックループといった消費メカニズムに多くの時間を費やします。生成AIのアウトプットは言語の形をとっているため、これらの価値提案に到達するのがより速くなります。人間の言語が持つ双方向性によって、より速く進むことが容易になるかもしれません。

・データは異なるものになるだろう

データに関連する課題の性質は異なるでしょう。生成AIモデルは、乱雑でマルチモーダルなデータを扱うのが得意なので、データの準備や変換に費やす時間が少し減るかもしれません。

生成AIでデータサイエンティスト（DS）は何が変わるのか？

・スキルセットの変化

生成的AIモデルがどのように機能するかを理解する必要があります。どのように出力を生成するのか？その欠点は何か？私たちが使う可能性のあるプロンプト戦略は何か？私たちデータサイエンティスト全員がもっと学ぶべき新しいパラダイムです。

・計算量の増加

これらのモデルを自分でホストしたい場合、より複雑なハードウェアを扱う必要があります。

・モデル出力の評価

さまざまな戦略を使ってさまざまなタイプのモデルを実験し、どの組み合わせが最も効果的かを学ばなければいけません。これは、異なるプロンプトやデータチャンキング戦略、モデルの埋め込みを試すことを意味します。異なる種類の実験を実行し、それらを効率的かつ体系的に評価したい。どの組み合わせが最良の結果をもたらすのか？

・モニタリング

このようなモデルは倫理的、法的な問題を引き起こす可能性があるため、より綿密なモニタリングが必要となる。より厳密に監視するシステムが必要である。

・新しいユーザー体験

人間をループに入れ、モデリングのワークフローにどのような新しいユーザー・エクスペリエンスを取り入れたいかを考える必要があるかもしれません。生成AIソリューションの構築に関わる主なペルソナは誰になるのか。予測AIとの対比について考える必要があります。

組織が直面する人材ニーズは、生成AIであっても変わらないでしょう。依然としてモデルのニュアンスを理解し、新しいテクノロジーを研究できる人材は必要です。機械学習エンジニア、データエンジニア、ドメインの専門家、AI倫理の専門家など、すべてが生成AIを成功させるために必要であることに変わりはないのです。

生成AIに期待できること、どのユースケースから始めるべきかについて興味のある方はwebinar「予測AIと生成AIの融合で新たなバリューの創出 ~生成AIブームで浮かび上がる現場のニーズと課題」をご覧ください。

※本Blogは、Value-Driven AI: Applying Lessons Learned from Predictive AI to Generative AIの抄訳版です。詳細については、原文をご覧ください。

投稿 バリュー・ドリブンAI：予測AIから学んだ教訓を生成AIに応用する は DataRobot に最初に表示されました。

DataRobotは実務担当者がモデリングからモデル運用まで行うための機械学習・AIプラットフォームとして知られていますが、データサイエンティスト（DS）の業務を加速するためのエンジンにもなります。

今回は、DS向けにDataRobot×Papermill×MLflowを使うことで、どれくらい業務を加速し、チーム内のコラボレーションを高められるのかを紹介します。AIアクセラレーターにサンプルコードを公開していますので、実際にコードを動かしてもらえればその威力を感じていただけます。

機械学習モデル構築は実験の繰り返し

機械学習モデルのビジネス利用は、一回モデルを作成して終わりではありません。Kaggleなどのコンペティションでもトップクラスになるためには試行錯誤を自動化することが重要ですが、時間と共にデータが変わっていく実ビジネスでは、この試行錯誤を自動化することがより重要になってきます。データの変化に対応が遅れてしまうと、機械学習モデルのビジネス利用により得られるインパクトが消失してしまうからです。

試行錯誤の過程では、大量のコードとモデルとメトリクスが作成されます。これらのアセットの対応関係が明確にわかるように、実験ログを管理することもとても大切です。

試行錯誤の自動化とログ管理が成功への近道

試行錯誤の自動化や実験ログの管理ができていれば、データサイエンティスト（DS)が陥りがちな失敗を防ぐこともできます。

多くのデータサイエンティスト（DS）にとって、機械学習の実験はゲーム感覚で楽しい瞬間であり、精度が良いモデルを作るために時間を忘れてコーディングしたなんていう経験がある人も多いのではないでしょうか。しかし、機械学習に没頭しすぎて、もしくは1人のDSの力量に依存しすぎて、機械学習プロジェクトが失敗するケースが多々あります。以下の失敗例は、そんな失敗の一部を集めたものです。

機械学習の実験過程の失敗例その１：再現性

• 膨大な試行錯誤により、実験ログの管理が疎かになり、モデルや出力結果を再現できない問題が発生
• 担当者が変更した際にログが残っておらず異常時に対応できないような最悪のケースも

機械学習の実験過程の失敗例その２：ヒューマンエラー

• コーディングはデータサイエンティストの経験や能力に依存するため、担当者レベルによってコードに技術的な誤りが発生することがある
• 経験のあるデータサイエンティストでも作業量が増えるほどヒューマンエラーによるミスが増える

機械学習の実験過程の失敗例その３：コスト管理

• モデル構築に膨大なリソースが発生し、投資対効果が悪化する
• モデル構築にリソースが偏り、課題定義やモデル運用の設計に投入するリソースが薄くなる

DataRobot, Papermill, MLflowの連携による実験効率化とログ管理

それでは、本稿で紹介するDataRobot、 Papermill、MLflowがどのように上記課題を解決するか解説します。まず、それぞれの道具の概要です。

データサイエンティストの道具その１：DataRobot

• DataRobotは、データサイエンティスト（DS）や開発者が機械学習モデルを迅速に開発、デプロイ、管理できるように設計された包括的かつオープンなエンドツーエンドのAIライフサイクル・プラットフォームです。
• GUIベースの操作だけでなく、Pythonクライアントを使うことができます。したがって、コードベースで、データの準備からモデルのトレーニング、評価、デプロイメント、モニタリングに至るまでのプロセスを自動化し、機械学習プロジェクトの複雑さと時間を大幅に削減します。

データサイエンティストの道具その２：Papermill

• Papermillは、ノートブックをパラメータ化して実行するためのオープンソースのツールであり、データサイエンスや機械学習のワークフローを自動化するために広く使用されています。
• ノートブックを入力として受け取り、実行時にパラメータを渡すことで、ノートブック内のコードを動的に実行することができます。これにより、異なるデータセットやパラメータで同じ分析を繰り返し実行する際の効率が大幅に向上します。

データサイエンティストの道具その３：MLflow

• MLflowは機械学習のライフサイクルを管理するためのオープンソースプラットフォームです。
• 機械学習の実験管理、モデルのトラッキング、デプロイメント、およびワークフローの全体を通しての管理を簡素化することを目的としています。

DataRobot、Papermill、MLflowを使うメリット

この3つの道具を使うメリットは、実験効率化とログ管理です。DataRobotは、GUI操作だけではなく、コードベースでモデルのトレーニングを自動化することができます。モデルのトレーニングには特徴量やアルゴリズムの選定も含まれ、その機能だけでもDSにとって鬼に金棒です。

さらに、Papermillを使うことでノートブックをバッチ実行できるため、DataRobotを用いた実験を効率化できます。たとえば、需要予測などの時系列分析では、学習データの期間や検定期間や特徴量セットについてさまざまなパターンを試します。学習データの期間で3種類、検定期間で2種類、特徴量セットで3種類あるケースでは、合計で3×2×3の18回分の実験をする必要があり、DataRobotでは18のエクスペリメント（プロジェクト）を作成することに対応します。その都度、毎回ノートブックを手動で作成していては大変ですし、ヒューマンエラーも多くなります。そこで、Papermillを使うことで、18のノートブックを自動で作成し、バッチ実行することができます。

同時に、MLflowを使うことで、18の実験結果を1つのダッシュボードで表示できます。

AIアクセラレーターのサンプルコード

それでは、AIアクセラレーターに公開されているサンプルコードを紹介します。サンプルコードでは、時系列モデルの作成を効率化しています。

以下の内容がシナリオです。

 ——-シナリオ——-

時系列モデルの作成では、試みるべき多くの実験があります。最も基本的なものには、複数の特徴量派生ウィンドウ（fdws）を試すことや、事前に既知の特徴量（kias）を有効にすることが含まれます。

<用語説明>

• 特徴量派生ウィンドウ（fdws）：DataRobotの時系列モデリングにおいて、DataRobotが自動で派生する特徴量のローリングウィンドウ（fdws= -28 ~ 0 daysと指定すれば、過去28日間の移動平均、ラグ、差分などの特徴量が自動で生成される）
• 事前に既知の特徴量（kias）：DataRobotの時系列モデリングにおいて、予測時点で値がわかっている特徴量のこと（休日やキャンペーンなど）

サンプルコードでは、実験を効率化するために、Papermillを用いてパラメータ（fdwsとkias）を変更しノートブックをバッチ実行します。パラメータを設定し、バッチ実行を指示するノートブックがバッチ実行用ノートブック（orchestration_notebook.ipynb）であり、その指示により複数の実験用ノートブック（experiment_notebook.ipynb）が作成され、バッチ実行が走るという関係になっています。機械学習モデル作成のエンジンはDataRobotを利用しており、実験ログはMLflowで管理します。

DataRobot、Papermill、MLflow連携の流れ

以下、バッチ実行用ノートブック（orchestration_notebook.ipynb）のコードの中身を詳しく解説します。

①パラメータの設定

シナリオに沿って、特徴量派生ウィンドウ（fdws）と事前に既知の特徴量（kias）に異なるパラメーターを与えて実験します。以下のセルの例に示されているように、3(fdwsが35,70,14の3種類)×2(kiasがFalseとTrueの2種類) = 6の異なる実験を行います。

②ノートブックのバッチ実行

①で定義したパラメータを実験用ノートブック（experiment_notebook.ipynb）に与え、バッチ実行します。for文でループ実行しており、ここでは6回分ループ実行が行われます。pmはPapermillのことで、引数として、

• input_path: 実験用ノートブックのパス
• output_path: 実験実行後のノートブックのパス
• parameters: 実験用ノートブックに与えるパラメータ

を指定します。

以下のセルを実行すると、自動でノートブックが6つ作成されて、バッチ実行が動きます。

それでは、次に、実験用ノートブック（experiment_notebook.ipynb）の中身を見てみましょう。

①機械学習モデルの作成

機械学習モデルの作成にはDataRobotを用います。以下のセルは、検定スキーム（time_partition）や特徴量セットの設定をしています。特徴量ウィンドウ（FDW）と事前に既知の特徴量（KIA）は、バッチ実行用ノートブック（orchestration_notebook.ipynb）から与えられたパラメータです。

以下のセルを実行すると、自動で複数のモデルが構築され、最も精度が良いモデルをDataRobotが選択してくれます。

②予測の実行

最も精度が良いモデルを使って予測を実行します。

③実験ログ管理

予測値と実測値を比較して、精度を算出し、MLflowを使って実験ログを記録します。ここでは、変更したパラメータと各種精度指標のスコアを記録しています。

サンプルコードを実行すると以下のようなアウトプットが得られます。アウトプットからわかるように、この3つの道具を使うことで、実験を効率化できるだけでなく、コードとモデルとメトリックスを実行後にアセットとしてそれぞれ残すことができ、後任者がコードとモデルの中身を再確認することもできます。

機械学習の実験効率化とログ管理を両立させる方法

今回は、実験効率化とログ管理のために、以下の方法をご紹介しました。

• DataRobotとMLflowを使用して、機械学習の実験を追跡およびログする方法
  • 利点：実験間での結果の一貫した比較が可能
• DataRobotとPapermillを使用して、機械学習の実験からアーティファクトを作成し、共同作業に必要な作業量を減らす方法
  • 利点：エラーを回避し、手動の作業量を減らすための実験の自動化が可能

ぜひサンプルコードを参考に、皆さまのプロジェクトにご活用ください。具体的な実装などでお困りの際は弊社までお問い合わせいただくか、下記のWebinarにご参加ください。

4/26（金）15:00〜開催！DataRobot x Papermill x MLflowで機械学習プロジェクトを加速
本ウェビナーでは、DataRobot、Papermill、MLflowを組み合わせて使用することで、機械学習の効率化とログ管理を両立させる方法についてご紹介します。さらに、AIアクセラレーターが提供するサンプルコードを使って、実際のシナリオを通じてこれらのツールの活用方法を詳しくご紹介します。

投稿 DataRobot, Papermill, MLflowを活用した機械学習効率化とログ管理 | AIのプロが解説 は DataRobot に最初に表示されました。

DataRobotで主に政府公共領域やヘルスケア業界のお客様を担当しているデータサイエンティストの若月です。

本稿ではAIシステムのコアとなる機械学習モデルのバイアスと公平性に注目し、2回に渡って解説しています。Part 1では、以下のトピックを取り上げました。

• バイアスと公平性とは、その重要性
• バイアスの発生原因
• 公平性指標

Part 2では、モデルのバイアスを軽減するための具体的な手法や公平性に配慮したモデル構築をするためのプロジェクト体制について考察し、さらにDataRobotが標準的に備えている公平性評価・バイアス軽減のための機能をご紹介します。

モデルのバイアスを軽減する

Part 1でご紹介した公平性指標に基づいてモデルのバイアスが検知できたとして、そのモデルからバイアスを軽減するにはどうすれば良いのでしょうか。実は機械学習においてバイアスを軽減しうるタイミングは大きく分けて3つあります。

1. データ準備段階でのバイアス軽減(Pre-Processing Bias Mitigation)
2. 学習時のバイアス軽減(In-Processing Bias Mitigation)
3. 予測時のバイアス軽減(Post-Processing Bias Mitigation)

それぞれにおいてさまざまな方法が提案されていますが、そのうちのいくつかをご紹介します。

データ準備段階でのバイアス軽減

1. データの生成・収集プロセス自体の見直し
   

Part 1で述べたようにバイアスの発生はデータの生成・収集プロセスに起因しているので、そのプロセス自体を見直すことは根本的にバイアスを排除するのに最も効果的な手段となります。例えば数の少ない属性のデータを収集するのは、コストとのトレードオフになり、かつあらゆるケースで可能な方法ではないですが、実施できる場合にはとても有効です。

一方でPart 1で述べたように、ラベル付けなどデータ生成に人間の判断が含まれることがあるとその判断によってバイアスが入り込んでしまうのは避けられません。また、後述する方法とは異なりデータを収集し直す必要があることからコストや時間もかかるというデメリットがあります。

2. 特徴量の選定・特徴量エンジニアリング
   

特徴量の見直しもバイアスの軽減に有効な場合もあります。ただし、ここで気をつけなければならないのは「バイアスと直接関係する特徴量だけを学習データから除いても本質的なバイアスを除去できるとは限らない」ということです。

例えば採用の選考モデルで求職者の性別をモデルの特徴量から除外しても、それ以外の特徴量が性別と何らかの形で関連している（プロキシ特徴量になっている）と、それらを用いて学習したモデルは性別という情報を暗に含んでいることになります。
ここで、後述のサンプリングの節でも説明している「保護された特徴量をターゲットとして予測モデルを作成」する手法を用いると、どういった特徴量が保護された特徴量に関連しているか理解することができます。

図１のような仮想例において、性別の予測モデルで部活の特徴量のインパクトがとても強く、部活について図２のようなワードクラウドがインサイトとして得られたとします。この場合には、例えばmens tennis/womens tennisといった単語をtennisに名寄せするなどの特徴量エンジニアリングを行う、といった方法も考えられるでしょう。
DataRobotを使えばこのような様々なモデリングも非常に簡単に行うことができる上、視覚的にも理解しやすい情報を提供してくれます。

3. サンプリング

手元のデータをそのまま全てモデリングに利用するのではなく、データ内のバイアスを軽減する目的でサンプリングを行います。サンプリングの方法としては、保護された特徴量をターゲットとして傾向スコアマッチングを行い、例えば男女間で近い特徴を持つデータのみを抽出してモデリングを行うなどが考えられます。ただし、サンプリングを行うことで意図しない別の観点でのバイアスが入り込む可能性も十分に考えられるため、注意して行う必要があります。（傾向スコアマッチングについては、弊社ブログの機械学習を用いた要因分析 – 実践編や機械学習を用いた要因分析 – 理論編 Part 2に詳細に解説されているため、ぜひご確認ください）

4. 学習データの重み付け

例えば特定の属性のデータが少ない場合、その属性を重視するよう行ごとの重み付けを行うことでバイアスを軽減できる可能性があります。重み付けをするとその行が学習時に複数回現われるような挙動になりますが、詳細については弊社の過去のブログ記事もご参照ください。

学習時のバイアス軽減

Adversarial Debiasing[1]

本来作りたい予測モデルに加え、その予測結果をもとに「保護された特徴量（=公平性を担保したいカテゴリ特徴量）」を予測する「敵対モデル（Adversary Model）」を作り、この二つのモデルの誤差からパラメータを更新する手法です（Generative Adversarial Networks[2], GANの考え方を取り入れています）。予測モデルの予測結果が完全に公平な”理想的”な状況では、敵対モデルの予測能力は限りなくランダムに近づくはずなので、予測モデルの誤差を最小化しつつ敵対モデルの誤差を最大化する最適な点を探します。このようなアプローチをとることで、精度とバイアス対処の両方を考慮したモデルを得ることができます。

予測時のバイアス軽減

1. 閾値の調整

公平性指標として、Part 1で紹介した好ましいクラスの再現率を採用しているケースを想定してみましょう。二値分類の予測においては予測ラベルを決定するための閾値を決める必要がありますが、保護された特徴量のクラスごとに異なる閾値を設定することで、クラス間の公平性を改善できます。一方で公平性を担保するために閾値に手を加えると精度指標としてのモデルの再現率・適合率も変わるため、最終的な閾値はビジネス上求められる精度と公平性の２つの観点から決定する必要があります。

2. Post-Processing Rejection Option-Based Classification[3]
   

分類問題において、「差別的な予測は予測閾値近傍のデータにおいて起こりやすい」という前提のもと、予測後に予測閾値近傍のデータ（予測結果）に対して予測ラベルを調整するという方法です。予測閾値付近のデータで下駄を履かせるなど調整をする、というとイメージしやすいかもしれません。

例えば採用の選考モデルで男性が女性よりも有利な予測をされているという状況の元で、予測閾値をわずかに下回った女性を採用（False → True）、予測閾値をわずかに上回った男性を不採用（True → False）、というように調整を行います。

実際のプロジェクトにおける留意点

公平性を欠いた機械学習モデルによるAIシステムが開発・運用されれば、プロジェクト中止や企業の社会的名声毀損など重大な結果につながる可能性があるのは本稿Part 1で述べた通りです。従って実際の機械学習プロジェクトにおいては、最初の企画段階でバイアスと公平性への留意点が漏れていないかプロジェクトメンバー間で議論することが必要です。さらには予測モデルで実現したい精度指標と同様に、バイアス評価を行うための公平性指標をプロジェクト毎に決定し、さらにモデルを実運用化する条件としてどの程度の値が求められるのかまで決定しておくべきです。

具体的な議論は機械学習プロジェクトのアイデアが固まり、詳細化していくフェーズにおいて行います。実務観点・データ観点双方から何に留意すべきか検討する必要がある以上、実務を十分に把握した分析担当者が議論をリードするのが理想的ではありますが、そのような知見・スキルを持ったメンバーがいなければ実務担当者と分析担当者が主体となって共同で議論を進める形をとることとなります。

しかし、プロジェクトを始める時点ではまだ具体的な問題点が判断できない、適切なバイアス評価方法が判断できない、といった状況であることも決して少なくないでしょう。その場合には、早期の段階からリスク管理担当者やコンプライアンス担当者をプロジェクトチームにアサインして、データ生成・収集プロセスやプロトタイプモデルのレビューに関わってもらう体制を持つことが推奨されます。

コンプライアンスの専門家による視点で公平性のリスクを早期に検知して対応すれば、プロジェクトの手戻りを防ぐことが期待できます。また、業界によっては関連する規制やガイドラインも存在しているので、それらを基準とすることもできます。例えば、米国では採用にあたりいわゆる”4/5ルール”が存在します。このルールに基づくと公平性指標指標としては「割合の平等性」を選択することになりますし、さらに指標としては低い方の値が0.8以上になることが求めらます。（公平性指標とその計算方法については本稿Part 1をご参照ください）

企業が組織的にAIを活用するステージになってくると、プロジェクトの進め方を組織内でテンプレート化することもあるかと思います。テンプレートの中にバイアスと公平性に関する議論並びに適切なメンバーによる承認を含めておくようにすれば、各プロジェクトにおいて議論が漏れる可能性を抑えられるでしょう。議論の主体となるのは先述のように業務担当者と分析担当者、承認者としては例えば各担当者の上長や独立したリスク管理担当者、コンプライアンス担当者などが考えられます。

参考までに、「人」に関わる意思決定プロセスをAIで高度化することを目的としたプロジェクト（例えば下記）においては、バイアスと公平性の観点から特に注意を払う必要があります。

• 採用プロセスにおける書類選考のAIによる効率化
• 住宅ローンの審査業務の効率化
• 犯罪リスクの高い地域の可視化
• 児童虐待リスクの予測
• 介護のハイリスク者の抽出
  

DataRobotでできること

DataRobotでは二値分類のプロジェクトで公平性の評価とバイアス軽減を行えます（バイアス軽減については2022年12月現在、クラウド版のみでのご提供になります）。

これらはプロジェクトの開始前に「保護された特徴量」（=公平性を担保したいカテゴリ特徴量）を指定してから通常通りモデリングを行うだけで簡単に実施可能です。なお、バイアス軽減については先にご紹介した手法のうちデータ準備段階でのバイアス軽減として学習データの重み付けを、予測時のバイアス軽減としてPost-Processing Reject Option-Based Classification を利用でき、状況に応じて使い分けることができます。

具体的な操作手順や詳細は公式ドキュメントが詳しいのでそちらをご参照ください。

公平性指標の確認

Part 1で解説した公平性の指標に基づき、予測モデルの公平性をUI上で確認できます。プライマリーで適用する公平性指標はモデリング開始前に「高度なオプション」から設定が必要ですが、モデリング完了後にリーダーボードから個別のモデルについて他の各指標による評価も確認可能です。

下図は前述の賃金が高いか低いかを予測する二値分類モデルの例ですが、女性（赤い棒グラフ）は男性（青い棒グラフ）よりも”不利に”予測されていることがわかります。

クラスごとの精度確認

リーダーボード上で、「保護された特徴量」の各カテゴリ値ごとに精度指標値が表示されるため、精度がクラス間で偏っていないかを確認できます。下図では男女それぞれについていくつかの精度指標で精度を表示しています。
 

DataRobot MLOpsを用いた予測結果の公平性トラッキング

モデルのデプロイ後も、各デプロイに対して行われた予測に対して公平性指標を確認できます。こうして機械学習モデルが実運用ステージに入った後も”不公平な”予測が行われていないかをトラック可能です。

バイアス軽減

開始ボタンを押す前に、「高度なオプション」の「バイアスと公平性」から「プライマリー公平性指標」を選び、「バイアス軽減の技法」を「前処理の再加重」あるいは「 却下オプションに基づく分類による後処理」（Post-Processing Reject Option-Based Classification）から選択できます。

あとは通常通りモデリングを行うだけで、モデリング完了後、リーダーボードの上位モデルに対してバイアス軽減処理を施したモデルが自動的に作成されます。なおバイアス軽減オプションを使ったからといって、期待通りのバイアス軽減がなされているとは限らないため、必ず公平性指標の確認を行うことが必要です。

以上のように、DataRobotを使うと公平性指標の計算・確認やバイアス軽減といった公平性の高いモデル作成に必要なタスクも特別なコーディングを要することなく簡単に行うことができます。もちろんモデルの構築も含め自動で行ってくれるので、機械学習プロジェクトメンバーは『公平性をどのように評価するか、どのようにバイアスに対処するか』のような、人間にしかできない重要な検討項目にフォーカスできます。

まとめ

本稿Part 1では

1. バイアスと公平性とは、その重要性
2. バイアスの発生原因
3. 公平性指標

Part 2では

4. バイアス軽減のさまざまな手法
5. 実際の機械学習プロジェクト推進における留意点
6. モデルのバイアスに対してDataRobotができること

を幅広くご紹介しました。繰り返しになりますが、公平性の観点は一つではないので、プロジェクトの特性に応じて対処方法を選定することが必要です。冒頭で述べたように、AIを幅広い業務で活用するのが当たり前になってきている今こそ、バイアスの小さな機械学習モデルをあらゆるレイヤーで作っていけるよう組織・体制を構築していくことが求められています。
一方、全てのプロジェクトで、上記指標の確認やバイアスを軽減したモデリングを分析者に求めたとしても、それら分析は実装の観点で障壁が高いことも事実です。DataRobotでは、誰でも簡単に、全てのプロジェクトでバイアスの確認やバイアス低減のための実装を行うことができます。バイアスに関する理解と、実装を可能にするプラットフォームで、次の時代に求められるAIプロジェクトを一緒に進めていきましょう。

参考文献

[1] B. H. Zhang, B. Lemoine, and M. Mitchell, “Mitigating Unwanted Biases with Adversarial Learning”, AIES ’18: Proceedings of the 2018 AAAI/ACM Conference on AI, Ethics, and Society, 2018

[2] Ian J. Goodfellow, Jean Pouget-Abadie, Mehdi Mirza, Bing Xu, David Warde-Farley, Sherjil Ozair, Aaron Courville, Yoshua Bengio, “Generative Adversarial Nets”, Advances in Neural Information Processing Systems 27 (NIPS 2014), 2014

[3] Kamiran, F., Karim, A., Zhang, X, “Decision theory for discrimination-aware classification”,  2012 IEEE International Conference on Data Mining (ICDM 2012), 2012

投稿 AI活用のさらなるステージ：バイアスと公平性 Part 2 は DataRobot に最初に表示されました。

DataRobotで主に政府公共領域やヘルスケア業界のお客様を担当しているデータサイエンティストの若月です。

機械学習によるAIが普及する中で、AIが倫理的な、公平な判断をしているかという観点にも焦点があてられるようになってきました。2020年に公開されたドキュメンタリー映画「CODED BIAS」では、白人男性より黒人女性の方が顔認識の精度が低くなってしまう例などをあげ、AIに関する社会問題を紹介しています。バイアスと公平性は、AIが社会に浸透してきた今こそ注目をしなければならない領域です。

本稿Part 1ではバイアスと公平性がなぜ重要なのか、その発生要因、機械学習モデルのバイアスをどのように評価するのかについて解説します。（Part 2では具体的にどのように機械学習モデルのバイアスを軽減するのか、機械学習プロジェクトにおいてどういった点に留意する必要があるのか、そしてDataRobotでどのようなことができるのかについて解説します）

バイアスと公平性とは

実証実験段階をクリアしたAIの社会実装が進む昨今、AIガバナンスの重要性が叫ばれるようになってきています。日本においても内閣府による「人間中心のAI社会原則」[1]（2019年）や、経済産業省による「我が国のAIガバナンスの在り方」[2]（2021年ver1.1に更新）「AI原則実践のためのガバナンス・ガイドライン」[3]（2022年ver1.1に更新）が発表されています。このようにAIの社会実装のガイドライン整備が進んできているのは、AIがただの実証実験にとどまらず、実際のビジネス・業務において当たり前のように活用されるようになったことの証左と言えるでしょう。一方で、筆者の所見ではAI活用のあり方を十分に設計・検討した上で実践できている組織は、2022年現在においてはまだ多いとは言えないように見受けられます。

AIガバナンスは非常に広範に渡る概念ではありますが、中でもモデルの公平性についてはモデル開発者・利用者含むステークホルダー全員がしっかりと意識する必要があります。先述の「人間中心のAI社会原則」においても、「公平性、説明責任及び透明性の原則」が定められており、AIの利用によって人々が不当な差別・不当な扱いを受けないように説明責任・信頼性が担保される必要があるとされています。

なぜAIの利用による差別が発生しうるのでしょうか。機械学習では過去のデータに基づいて将来の予測を行うので、学習したデータに意図的か意図的でないかにかかわらずバイアスが含まれていた場合、そこから得られる予測結果は偏見・ステレオタイプを含んだ不公平なものになっている恐れがあります。

たとえば、採用活動における書類選考過程をAIを用いて効率化しようとするプロジェクトがあったとします。データサイエンティストは過去の履歴書データなどを使ってモデルを作成しますが、もし過去の応募者・内定者の男女比に偏り（バイアス）があった場合、そのデータから作成した機械学習モデルは男女のどちらか一方に有利な評価を行う不公平なものになってしまっている可能性があります。無論「不公平な」モデルを実際に使用して意思決定を行うのは男女雇用機会均等の観点から望ましくないといえます。

このように単純に精度のみを追い求めて（知らず知らずのうちに）公平性を欠いたAIモデルを作ってしまい、もし将来不公平なモデルが作られていたこと/運用されていたことが発覚すればプロジェクトの中止、最悪の場合企業・組織の社会的信用にまで影響を与えてしまう可能性があります（米国における再犯予測システムの事例）。したがってプロジェクトに携わる全員が正しくモデルの公平性を理解し、推進する必要があります。

バイアス発生の根本原因

不公平なAIモデルが作られる原因となるバイアスはデータそのものに内在しますが、バイアス発生の根本原因はデータの収集・生成プロセスにあると言えるでしょう。具体的にまとめると以下3つの根本原因が考えられます。

データ量

データ量が少ない、もしくは全体としてはデータ量が多くても特定の属性に関するデータ量が少ないという状況では、属性によっては適切な予測ができないかもしれません。

例えば、国政選挙において誰が当選するかを予測するAIを仮想的に考えてみましょう。日本では2022年現在も、女性の政治参加率の低さがたびたび指摘されています。実際にそれを裏付けるデータとして女性国会議員の割合をみると2018年2月現在で衆議院10.1％（47人）、参議院20.7％（50人）と報告されています（内閣府による発表[4]）。

女性が少ない過去の実績データを使って作成したモデルによって国会議員全体の当選予測をしようとすると、データ数の多い男性候補者に比べて女性候補者の適切な予測ができない可能性があります。このように、社会的・歴史的背景によってそもそも特定の属性のデータが少ない、というバイアスは様々な分野で見られます。

サンプリング

データ量の例とも一部共通しますが、本来の母集団から特定の属性のみを抽出しているような状況では選択（セレクション）バイアスが発生します（参考：機械学習を用いた要因分析 – 理論編 Part 2）。例えば金融機関における与信審査において機械学習モデルを使って判定を行っている場合、モデルによって選別された”属性の良い”グループのみのデータが収集されることになるので、これもセレクションバイアスといえます。

ラベルづけ等、意思決定におけるバイアス

ビジネスデータにおいては人がラベルづけすることも多いですが、その人の判断そのものにバイアスが含まれていた場合、生成されたラベルにもバイアスが入り込むことになります。仮に、ある企業で男性の方が採用時に優遇されているという慣行（逆も然り）があったなら、採用予測モデル構築のために使われるトレーニングデータにはバイアスが含まれていると言えます。
公平性の考え方：公平性指標

モデルの公平性はどのように判断できるでしょうか。実はモデルの公平性を定量的に測定する指標がいくつか提案されていますが、どの指標を選択するかはプロジェクトによって変わってきます。例えば採用活動において男女の公平性を担保しようとしても、採用する男女の絶対数を合わせるのか、応募者に対する採用人数の比率を男女で合わせるのか、それは組織の方針によって決まってくるでしょう。以下では公平性指標の概要をご紹介します。（詳細は、DataRobotの公式ドキュメントもご参照ください）

具体例を示しながら説明するため、本章ではある従業員の賃金が一定金額以上かどうか（高いか低いか）を予測する二値分類モデルを仮想例として取り上げます。また、”好ましい”あるいは”好ましくない”という用語が出てきますが、この例では賃金が高いのが”好ましい”予測で、賃金が低いのが”好ましくない”予測とします。

それでは、以下のような男性10名、女性5名のデータをもとにいくつかの公平性指標を算出してみましょう。いずれの指標も男女間で値が近いほど公平である、と判断します。 本例ではモデルを性別に対して公平にしていきたいので、特徴量「性別」を予測結果に対して公平性を担保したいカテゴリ特徴量（以下”保護された特徴量”）と考えます。

公平性指標の一覧

各公平性指標の具体的な説明に入る前に、どのようなものがあるのか一覧で見てみましょう。

また、数式の表現については以下をご参照ください。

割合の平等性(Proportional Parity)

定義: 保護された特徴量の各クラス（男女）について、好ましい（賃金が高い）予測がなされたデータの全体に対する割合。

イメージ: 賃金が高いと予測した割合が男女で公平であるかどうかを確認します。

計算: 表１のデータでは、賃金が高いと予測されているのが男性だと10人中5人なので0.5になるのに対して、女性は5人中1人なので0.2です。なお、DataRobotでは最も値が高くなるクラスで正規化した値がデフォルトで表示されるので、男性だと0.5/0.5 = 1.0, 女性だと0.2/0.5 = 0.4となります。（この表示ルールは他の指標でも同様です）

同数の平等性(Equal Parity)

定義: 保護された特徴量の各クラス（男女）について、好ましい（賃金が高い）と予測された数。

イメージ: 賃金が高いと予測した数（割合ではない）が男女で公平であるかどうかを確認します。

計算: 表１の例では、賃金が高いと予測されているのが男性5人に対して、女性は1人です（正規化すると男性1.0, 女性0.2）。分類結果の絶対数を合わせたいときはこの指標を使うのが良いでしょう。

好ましいクラスのバランス(Favorable Class Balance) / 好ましくないクラスのバランス(Unfavorable Class Balance)

定義: 好ましいクラスのバランスは、保護された特徴量の各クラス（男女）について、実績として好ましい（賃金が高い）クラスに属するデータの予測スコアの平均。

イメージ: 賃金が高いと予測したラベルの割合ではなく、賃金が高いと予測する確率に公平性があるかどうかを確認します。予測する確率でランキングを作る際に用いられます。

計算: 表１の例では、「好ましいクラスのバランス」は正規化前の値が男性は0.614に対して女性は0.55です。「好ましくないクラスのバランス」では逆に、実績として賃金が低いクラスに属するデータの予測スコアの平均になります。

好ましいクラスの再現率の平等性(True Favorable Rate Parity) / 好ましくないクラスの再現率の平等性(True Unfavorable Rate Parity)

定義: 好ましいクラスの再現率の平等性は、保護された特徴量の各クラス（男女）について、好ましい（賃金が高い）クラスの再現率(Recall)。

イメージ: 精度評価指標として再現率を重視するようなプロジェクト（例えば医療業界における疾患の判定など）において、男女間での差が少ないモデルであることを担保したいときに用いられます。

計算: 「好ましいクラスの再現率の平等性」は表１の例では、正規化前の値が男性は4/7 = 0.57に対して女性は1/2 = 0.50です。
「好ましくないクラスの再現率の平等性」では逆に賃金が低いクラスの再現率を確認します。

好ましいクラスの適合率の平等性(Favorable Predictive Value Parity) / 好ましくないクラスの適合率の平等性(Unfavorable Predictive Value Parity)

定義: 好ましい予測値の平等性は、保護された特徴量の各クラス（男女）について、好ましい（賃金が高い）クラスの適合率(Precision)。

イメージ: 好ましいクラスの再現率の平等性と同じ発想ですが、精度評価指標として適合率を重視するようなプロジェクト（例えば児童虐待やハラスメントの判別など、モデルが検知した結果が間違っていたときに大きな問題になりかねないために偽陽性をなるべく少なくしたいテーマ）において、男女間での差が少ないモデルであることを担保したいときに用いられます。

計算: 「好ましいクラスの適合率の平等性」は、表１を例にすると、正規化前の値が男性は4/5 = 0.8に対して女性は1/1 = 1.0です。
「好ましくないクラスの適合率の平等性」では逆に賃金が低いクラスの適合率を確認します。

繰り返しになりますが、どういった指標を用いるかはプロジェクトによって変わってきますし、実際の計算例をみても男女間での差異が指標によってもかなり異なってくることが見て取れます（指標次第で男女間での値の大小が逆転しているものすらあります！）。従って、「〇〇を選べば良い」といった類のものではなく、ユースケースやドメイン知識、組織のポリシーに基づいて適切な指標をプロジェクトの担当者が選択する必要があります。

別の仮想例として「採用時の応募者一次スクリーニングプロジェクト」を考えてみましょう。もし組織の採用ポリシーが「応募人数に対する採用人数の割合について、男女間で大きな差が生じないようにする」であれば、公平性の指標は「割合の平等性」を採用するのが適正と考えられます。しかし、もし採用ポリシーが「応募者の男女比に関係なく、男女同数の内定者をだす」であれば、「同数の平等性」を採用するのが適正と考えられます。

このように、公平性指標の選択には絶対基準が存在するわけではなく、機械学習モデルで解決しようとしている課題（ユースケース）やそのモデルの運用ポリシー、組織のポリシー・ルールを反映させた指標を柔軟に選ぶ必要があります。

まとめ

以上、本稿Part1では以下のトピックに注目して解説しました。

• バイアスと公平性とは、その重要性
• バイアスの発生原因
• 公平性指標

本稿で述べた通り、バイアスと公平性はAIが組織的に活用されるようになった今こそ、改めてその重要性を認識する必要があります。AIの活用が実証実験にとどまっていた段階ではあまり意識が向けられていなかったかもしれませんが、これからますますAIの活用が広がる中でデータサイエンティストはもちろん、意思決定者からAIのユーザーに至るまで全員の理解は必須と言っても過言ではないでしょう。まずは読者の皆様が携わられている機械学習プロジェクトにおいて公平性を欠いたモデルが作られていないか、考えてみてはいかがでしょうか。
次回、本稿Part 2では以下を解説します。2023年1月に公開予定です。

• バイアス軽減のさまざまな手法
• 実際の機械学習プロジェクト推進における留意点
• モデルのバイアスに対してDataRobotができること
  

参考文献

[1] 「人間中心のAI社会原則」（内閣府）　(https://www8.cao.go.jp/cstp/ai/ningen/ningen.html)　（2022年11月7日に利用）

[2] 「我が国のAIガバナンスの在り方 ver1.1」　（経済産業省）（https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/2021070901_report.html)　（2022年11月7日に利用）

[3]「AI原則実践のためのガバナンス・ガイドライン ver. 1.1」　（経済産業省）（https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20220128_report.html)　（2022年11月7日に利用）

[4]「男女共同参画白書（概要版） 平成30年版」（内閣府）　(https://www.gender.go.jp/about_danjo/whitepaper/h30/gaiyou/html/honpen/b1_s01.html)　（2022年11月7日に利用）

投稿 AI活用のさらなるステージ：バイアスと公平性 Part 1 は DataRobot に最初に表示されました。

　本稿では、マーケティング、ヘルスケア、公共政策などの分野での活用が期待されるアップリフトモデリングをご紹介します。アップリフトモデリングのコンセプトは目新しいものではありませんが、AI・機械学習の発展により、誰でもアップリフトモデリングを実践できるようになりました。しかしながら、アップリフトモデリングに必要なデータセットや適用範囲を理解していないと、全く意味のないモデルが構築されてしまいます。そこで、本稿では、アップリフトモデリングの注意点やユースケースを説明し、 DataRobotを利用したモデリング方法をご紹介します。

1. アップリフトモデリングとは

　人生は選択の連続です。皆さんも、『もし転職すれば年収はどれくらいになるだろうか』とか、『もしジムに通えばどれくらいダイエットできるだろうか』などと考えることがあるかもしれません。ビジネスにおいても、「このユーザーにダイレクトメール（DM）を送れば購入してもらえるだろうか」とか、「値引きしなくても購入してもらえるだろうか」などと営業・マーケティング担当は日々、頭を悩ませているかもしれません。そもそも人間は2人分の人生を送れないので、「仮定のアクション」をとればどのような結果になるのかを想像するのです。

　少し哲学的な話になりましたが、因果推論^[1]の文脈では、現実とは反対の状況をシミュレーションすることを反実仮想といいます。本稿で紹介するアップリフトモデリングとは、まさに反実仮想の考えを用いて介入効果を予測する方法であり、マーケティング、ヘルスケア、公共政策などさまざまなフィールドで応用できます。

１−１．アップリフトモデリングの定義とメリット

　一般的に、アップリフトモデルは以下のように定義されます。^[2]

• アップリフトモデルとは、個別ないしサブグループごとに介入効果を予測・推論するモデルのこと。

　介入効果とは、ある対象に介入したときに観察される結果Aと、同じ対象に介入しなかったときに観察される結果Bとの差のことです（図1）。例えば、あるユーザーにクーポンを送付したときの購入確率が50%、同じユーザーにクーポンを送付しなかったときの購入確率が20%のとき、介入効果は 50% – 20% = 30% と計算されます。

　このように、ユーザーごとに介入効果を計算できれば、介入効果が高いユーザーに絞ってクーポンを送付することで費用対効果を改善できます。しかし、実際には、ある１人のユーザーに「介入したとき」と「介入しなかったとき」を両方とも体験してもらうことはできません。つまり、そのユーザーにクーポンを送ってしまえば、クーポンを送らなかったとしても購入したのかどうかは分かりません。

　　そこで、アップリフトモデルの出番です。アップリフトモデルを使って、我々がそのユーザーに「介入したとき」と「介入しなかったとき」の結果をシミュレーションし、介入効果を算出します。魔法のようなモデルと感じるかもしれませんが、モデリングに使用するデータセットを工夫すればそのようなモデルを構築することが可能です。データセットの工夫については後ほど詳しくご紹介します。

１−２．アップリフトモデリングを使うべきときとは

　アップリフトモデリングは、効果検証のいかなるケースでも使えるわけではありません。

　具体的に、アップリフトモデリングが適しているのは、以下のように我々が介入を検討している対象が4つのグループに分けられると想定されるときです（図2）。それぞれ見ていきましょう。

　「鉄板」ユーザーとはクーポンを発行する場合も買うし、クーポンを発行しない場合も買うユーザーです。一方で、「説得可能」なユーザーは、クーポンを発行しない場合は買わないが、クーポンを発行する場合に買うユーザーです。営業・マーケティング担当者は「鉄板」ユーザーではなく「説得可能」なユーザーにこそクーポンを送付したいはずです。また、クーポンを発行しても買わない「無関心」なユーザーやクーポンの発行により逆に買わなくなる「あまのじゃく」なユーザーにはクーポンを送付すべきではありません。

　介入効果の観点では、効果が大きい順に「説得可能」 >>「鉄板」，「無関心」>「あまのじゃく」という順番になります。アップリフトモデルで個々のユーザーの介入効果を推定して達成したいことは、「説得可能」なユーザーの選別です。

１−３．レスポンスモデルとの比較

　アップリフトモデリングは上図のように4つのグループがあるときに適していますが、世の中には「鉄板」が存在しないケースがあります。例えば、新しいブランドで、世間にまったく認知されていない製品です。

　このようなケースでは、何もせずとも買ってくれるような「鉄板」ユーザーはいないので、広告やプロモーションなどの介入を行うことが前提となります。そのため、これから介入すべきユーザーを選定するためには、これまでに介入した時の結果のデータのみを使用してモデリングします。このモデルは、介入したユーザーの中で、どのようなユーザーがレスポンス（＝購入）する確率が高いのか学習し、予測するモデルなのでレスポンスモデルと呼ばれます（表1）。^[3]

　一方で、アップリフトモデリングでは、介入しなくても購入する「鉄板」がいるため、介入したデータ（介入群データ）に加えて、介入していないデータ（対照群データ）もモデリングに利用します。介入していないユーザーの中で、どのようなユーザーが購入する確率が高いのか学習させるためです。

　モデル構築を担当する分析者は目の前の状況がどちらのユースケースに適しているのか見極めて両者を適切に使い分けることが大切です。

ここから、DataRobotを用いてアップリフトモデルを構築するための手順をご紹介します。まず、アップリフトモデリングの成功に欠かせないデータセットの工夫について話します。

２−１．データ準備

　アップリフトモデリングでは、介入群データと対照群データを使用すると述べました。ここで重要なのが、介入対象となるユーザーの選択にバイアスがあってはいけないという点です。では、なぜ、このような「選択バイアス」があるといけないのでしょうか。

　例として、外食デリバリーサービスの利用を促すDMを各世帯に送付するケースを考えます。このサービスの購入には、世帯人数、平均年齢、世帯収入、居住地、リモートワークの有無、夫婦共働きか、など様々な因子が関係していそうです。例えば、共働き世帯は外食デリバリーサービスを利用しやすいかもしれません。（なお、疫学分野ではこれらの因子を『曝露因子』と呼びます。）

　そこで、共働き世帯に絞ってDMを送付したとします。その結果、思惑どおり、DM送付した世帯は、DM送付していない世帯よりも全体としてサービスの購入確率が大きいことが分かりました。しかし、その購入確率の差は、DM送付が功を奏したからなのか、単純に共働き世帯が購入しやすいからなのか、それとも世帯収入などその他の因子が影響したからなのか判別できません。

　この状況を図で表すと次のような関係となります（図3）。原因から結果に向けて矢印が伸びています。われわれは、「DM送付」と「購入」の間の因果関係を知りたいのに、上記の仮想ケースでは「共働き世帯か」という尺度でDM送付対象を決めてしまったが故に、注目している因果関係の大きさ（＝介入効果）を見積もることができなくなっています。

　このように介入対象の選択にバイアスがかかってしまうと介入効果を正しく計ることができません。なお、ここで「共働き世帯か」のように、注目している要因にも結果にも影響する因子のことを交絡因子といいます。交絡因子がある状況でどのように因果推論するのかについては弊社ブログ「機械学習を用いた要因分析（理論編１、理論編２）」で詳しく解説しています。

　それでは、選択バイアスのないデータを準備するにはどうすればいいでしょうか。理想はランダム化比較試験（RCT）を実施することです。^[4] RCTでは、母集団を介入群と対照群にランダムに振り分けます。しかし、実世界においては選択バイアスがかかったデータしか手元になかったり、そもそも倫理的・コスト的にRCTが難しかったりするケースが見られます。そこで、観察データを用いた観察研究の文脈において選択バイアスを取り除くための方法として層別化や傾向スコアマッチングなど様々な手法が知られています。弊社ブログ「機械学習を用いた要因分析（実践編）」では、DataRobotを用いた傾向スコアマッチングのやり方をご紹介していますので、ぜひご覧ください。（なお「機械学習を用いた要因分析（理論編２）」に記載があるように、重要な交絡因子を網羅していることがこの手法を適用するための前提条件となるので、その点は十分にご留意ください。）

　選択バイアスの影響が無視できると考えられるデータセットを準備できてはじめてアップリフトモデリングを構築することができます。それでは、バイアスのないデータセットが準備できたとして、DataRobotでどのようにモデリングするのかご紹介します。

２−２．モデリングと予測実行

　DataRobotはシンプルなユーザーインターフェースでAIモデルを作成でき、モデル評価やインサイト確認、予測実行までスムーズに行うことができます。アップリフトモデリングでも基本的なモデリング手順は変わりません（図4）。

　まず、学習データをDataRobotにアップロードしモデルを作成します。なお、ここで使用する学習データは、母集団をランダムに介入群（DM送付=True）と対照群（DM送付=False）に分けてDMを送付した結果、各ユーザーが購入したかどうかTrueまたはFalseでラベル付けしたものです。^[5]

　次に、モデルの中身（インサイト）を確認します。

　最後に、予測データをモデルに投入し、各ユーザーごとに介入効果を予測します。ここで、予測データは各ユーザーにつきDM送付=Trueの行とDM送付=Falseの行を用意します（図5）。このように2行用意することで、同一人物に「介入したとき」と「介入しなかったとき」の2パターンをシミュレーションすることができるのです。その2パターンの購入確率の差が、介入効果になります。この図では、UserID＝10001の介入効果は0%に対し、UserID＝10002の介入効果は20%であるため後者にDMを送付したほうがよいと判断できます。

①モデルの作成

　まず、学習データをDataRobotにアップロードします。アップロードが完了すると以下のようなモデリング設定画面に移行します（図6）。何を予測しますか？に予測ターゲットを入力します。本データセットでの予測ターゲットは「購入」です。次に、開始ボタンを押してモデリングを開始します。

②モデルの確認

　モデリングが終了するとモデルの順位表であるリーダーボードの画面に移行します。リーダーボードでは各モデルの予測精度やインサイトを確認できます。

　それでは、1つモデルを選択し、解釈タブを開いてインサイトを確認します。まず、知りたいのは、「DM送付」が「購入」に対してどれくらいインパクトがあるのかです。そのインパクトは特徴量のインパクトで確認できます（図7）。グラフの縦軸は特徴量の名前、横軸は相対的なインパクトの大きさを示しています。

　グラフから「DM送付」は3番目にインパクトが大きい特徴量であることが分かります。仮に、「DM送付」のインパクトが非常に小さいときは、DM送付による効果が実際にはあったとしても、大きな効果として予測値に反映されないため介入効果の解釈が難しくなります。その場合は、もしインパクトの大きい交絡因子があればその特徴量で層別し、それぞれの群のデータでモデリングする（層別分析^[6]）などの工夫が必要です。

　特徴量のインパクトから、「DM送付」が「購入」に対してどれくらいインパクトがあるのかを確認できます。一方、この情報からは「DM送付」と「購入」の間にどのような関係性があるのかまでは分かりません。そこで、特徴量ごとの作用を確認します（図8）。

　特徴量ごとの作用では、DM送付＝TrueのときとDM送付＝Falseのときで、購入確率にどれくらい差があるのか分かります。DM送付＝Trueのときのほうが約4%購入確率が高いことが分かりますね。しかし、これは、あくまでデータ全体の平均的な傾向です。ユーザーの中には、DM送付が購入意思に影響しない「鉄板」や「無関心」のユーザーもいるかもしれませんが、特徴量ごとの作用ではユーザーごとの介入効果は分かりません。そこで、次に、ユーザーごとの介入効果を予測してみましょう。

③予測実行

　それでは、実際にDataRobotを使って介入効果を予測します。今回は最初にアップロードしたデータの20%に相当するホールドアウトをダウンロードし、介入効果を予測するための予測データを作成しました。

　予測データを予測を作成にアップロードし、予測を実行→予測をダウンロードの順にクリックし（図9）、CSV形式で予測値を確認できます。最後に、DM送付＝Trueのときの予測値とDM送付＝Falseのときの予測値の差をとって、各ユーザにおける介入効果を算出します。

２−３．モデル評価

　各ユーザーの介入効果の予測値を表に示します（図10）。この表では予測された介入効果が大きいユーザーから順にソートしてあります。したがって、上から順にDM送付していくことで高い費用対効果が得られると期待できます。

　一方で、果たして本当に、表の上に並ぶユーザーほど介入効果が大きいのか疑問に思いませんか？そこで、介入効果の実測値を算出してみましょう。この予測データには、各ユーザーが購入した（購入＝True）か購入していない（購入＝False）かの実測値があるので、介入効果の実測値を算出できます。なお、予測データも介入群と対照群の分け方にバイアスがない、もしくは補正されたものを使用する必要があります。（さらに、予測データに属する群と学習データに属する群の間にバイアスがないことも前提となります。）

　それでは、介入効果の実測値を算出します。まず、この表を使って、上から順にグループ0、グループ1‥‥グループ9というように10個のグループに分けます。グループの数は任意です。次に、各グループの中で、DM送付＝Trueのユーザーの購入確率の平均とDM送付＝Falseのユーザーの購入確率の平均を計算します。グループ0ではそれぞれ25%、16.6%と算出されます。次に、その差をとることで介入効果の実績値を算出します。25%-16.6%=8.4%が介入効果の実績値です。一方で、各グループで介入効果の予測値の平均を算出します。グループ0では予測値の平均は8.0%になります。

　その他のグループ1~9でも同様に介入効果を計算します。その結果が以下のグラフです（図11）。横軸がグループで、縦軸が購入確率です。青とオレンジのバーが、DM送付＝TrueないしDM送付＝Falseのときの平均購入確率（実測値）で、緑のバーがその差の介入効果の実測値です。そして、赤のバーが介入効果の予測値の平均となっています。緑と赤のバーを比較すると、赤の予測値が小さくなるにつれて、緑の実績値も小さくなっていることが分かります。予測が当たっている証拠です。

　さらに、グラフをよく見るとグループ５までは介入効果の実測値はプラスですが、グループ６以降はゼロまたはマイナスになっています。したがって、グループ６以降のユーザーにDMを送付しても、それによる効果は見込めないことが分かります。言い換えると、アップリフトモデルにより、DMを送付すべきユーザーを全体の60%に絞り込むことができたのです。

　DM送付には、作成、印刷、郵送費などのコストがかかりますので、ユーザー全員に送付するのに比較して40%もコストを削減することができ、且つ同じだけの効果が得られることになります。このように、グラフを描くことで、介入効果が高いグループを絞りこめているか判断できます。なお、複数のアップリフトモデルの精度を比較したいときは、The Area Under the Uplift Curve（AUUC）^[7]やQini係数^[2]などの評価指標で比べるほうがより細かな差を判定できます。

3. まとめ

　以上、アップリフトモデリングのコンセプトからDataRobotを用いたモデリングおよび予測実行までご紹介してきました。本稿で述べたことをまとめると以下になります。

• アップリフトモデリングの成功のためには、ユースケースを把握し、データ準備においては選択バイアスのないもしくは取り除いたデータを用意することが必要不可欠である。
• DataRobotを用いれば、シンプルな操作でアップリフトモデルを構築でき、予測実行まで簡単に行える。

皆様の業務においてアップリフトモデリングの活用イメージが膨らんでおりましたら幸いです。

参考文献

1. 因果推論の入門書として以下の書籍をお薦めいたします。
   1. データ分析の力 因果関係に迫る思考法 (光文社新書), 伊藤 公一朗 (著)
   2. 岩波データサイエンス Vol.3, 岩波データサイエンス刊行委員会 (編集)
2. Gutierrez, P., Gérardy, J. Y. (2017) Causal Inference and Uplift Modelling: A Review of the Literature. Proceedings of The 3rd International Conference on Predictive Applications and APIs, 1-13.
3. Radcliff, N. (2007) Using control groups to target on predicted lift: Building and assessing uplift model. Direct Market J Direct Market Assoc Anal Council, 1:14–21.
4. RCT大全 ランダム化比較試験は世界をどう変えたのか（みすず書房），アンドリュー・リー（著），上原裕美子（訳）
5. Kevin Hillstrom’s dataset from E-Mail Analytics And Data Mining Challenge(2008)で公開されているデータセットを一部加工
6. 岩波データサイエンス Vol.3, 岩波データサイエンス刊行委員会 (編集) p.17-20
7. Jaskowski, M., Jaroszewicz, S. (2012) Uplift modeling for clinical trial data. In ICML Workshop on Clinical Data Analysis

投稿 DataRobotを用いたアップリフトモデリング は DataRobot に最初に表示されました。

DataRobot で小売・流通業のお客様を担当しているデータサイエンティストの井原です。

データサイエンスにおけるモデリング段階で、実際に得られるデータのサンプル数が限られている場合があります。特に、特定のデータが少なくそのパターンを見つけにくい場合、目的とことなった結果を算出しているのに、表面上は問題がないようにみえてしまうことがあります。
本稿では、機械学習のモデリングにおいて偏りのあるデータに遭遇したときに、どう対処したらよいかを状況別に分けて紹介します。なお、ここで扱うデータはテーブルデータを前提としています。

不均衡データとはなにか

　機械学習の予測モデルを作る際に、予測対象となるターゲットのバランスが悪い場合があります。例えば、分類において片方のクラスが極端に少ない状況がこれに該当します。このような偏りのあるデータは不均衡データ（インバランスデータ）と呼ばれます。

　例えば、予測ターゲットが「正常」あるいは「異常」である二値分類のデータセットのうち、「正常」のラベルをもつサンプルが100,000、「異常」のラベルをもつサンプルが10の場合、異常のサンプル数が極端に少ない不均衡なデータになっています。

　このようにデータが不均衡になる原因として、サンプルの少ないクラスの事象は稀にしか起こらないイベントであることがよくあります。しかし、稀なイベントにも関わらず、実は全体に大きな影響を及ぼすことが多く、この稀なイベントを予測することは重要な課題です。

　データの不均衡は特定の分野に限らず幅広い分野で起こりえます。不均衡データが起こりやすい課題の例として、機械の故障検知、割引キャンペーンによって購買する人の検出、社員の退職予測、薬で副作用が起こる人の予測、クレジットカードの不正利用の検知などが挙げられます。これらの課題に共通しているのは、前述の通り、予測対象が稀なイベントであるという点です。ではこのような不均衡なデータを分析する際には何に注意をしたらよいのでしょうか。

不均衡データの分析における問題点

　不均衡なデータは通常のデータと比較して、サンプル数の少ない少数派クラス（マイノリティクラス）に対するモデルの感度が低くなります。そのため、不均衡データに適切な対処をせずにモデルを作ってしまうと精度、計算量、インサイトなどの面で問題が生じます。

　まずは精度面での問題をみていきましょう。例えば、割引キャンペーンによって購入する人を予測したい場合、モデリングに使用する過去のデータは購入した人が非常に少ないデータになっていることがあります。ここで、割引キャンペーン対象者1万人のうち、実際に購入まで至ったのは100人だったとしましょう。（図1）このような不均衡データを元にこれからの対象者がキャンペーンによって購入するかどうかをターゲットとしてモデリングしたときに、全員を「購入なし」と分類したとしても正解率 (Accuracy) は99%になります。　

数値だけ見ると良い予測精度ですが、モデリングの当初のターゲットである「割引キャンペーンで購入する人」100人は全く当てられていません。このように、何も意識せずに不均衡なデータでモデリングをすると、誤った結果を導いてしまうことがあります。

　不均衡データはモデルの精度面だけではなく、計算コストの問題も抱えています。前述の割引キャンペーンの例では、モデルを学習するときに、ほとんどの時間を「購入なし」に費やします。長い計算時間をかけても、結果的に「購入あり」の判別にはそれほど貢献できないモデルしか作ることができません。

　少数派のクラスが多数派のクラスより重要視されるような場合、モデル構築時にこの不均衡をどう考慮すればよいのでしょうか。

不均衡データの一般的な対処法

　不均衡データの代表的な対処法としてデータの工夫や適切な最適化指標の選択があります。ここでは不均衡データの対処法について、データサイズと不均衡具合の観点で状況を3つに分け、それぞれの対処法を紹介します。

1. データサイズがそれほど大きくない場合 (~数GB)

　データサイズが大きくなく計算量がそれほど問題にならない場合は、目的に沿った精度を得ることに注力します。不均衡データの対策として、多数派クラス（マジョリティクラス）のサンプルを捨てることによる偏りの低減（Negative Down Sampling）がよく使われますが、多数派のデータを捨てても精度が上がることはあまりなく最終的な問題解決にはなりません。

　計算量が問題にならない規模の不均衡データで確認したい点は最適化指標です。分類の最適化指標は、重要視する結果がターゲットそのもの（例：対象者が購入するかどうか）あるいはターゲットの確率（例：対象者が購入する確率）どちらであるか、特定のクラスを重要視するかどのクラスも同じように扱うのかなど、状況に応じて決める必要があります。目的に沿った最適化指標を選んでいないと、誤った結果になることがあります。例えば、二値分類でよく使われるROC曲線下の面積（ROC-AUC）は、片方のクラスを重視することはなく両方のクラスを同等に扱います。不均衡データの場合にこの最適化指標を使うと、多数派のクラスを重視しすぎてモデルの質によらずに高い値を取りやすくなることが多々あります。[1]

　最適化指標の選択方法の詳細についてはここでは触れませんが、不均衡なデータセットでも結果が変わらないLogLossや、少数派クラスを重きを置いたPR曲線の下の領域（PR曲線のAUC、AUC-PR）を最適化指標として使用するとよいでしょう。

2. 少数派クラスのサンプル数が少なくデータサイズが大きい場合 (約1~10%, 数十GB~)

　データサイズが大きいために計算時間がかかっているが少数派クラスのサンプル数はある程度確保できている場合、問題は全体のサンプル数が多すぎることです。そのため、まずは計算量を減らすことで効率よく分析を進めていきます。

　このような場合に一番最初に試すことは、少数派も多数派もまとめてランダムにサンプリングを行い、全体のデータサイズを小さくすることです。少数派と多数派の比率を維持したい場合は層化抽出を行いましょう。この理由は、データサイズが大きくなればなるほど精度が向上していくとは限らず、むしろ通常はある程度のデータサイズから精度改善が緩やかになるためです。

　ここで、どれくらいのサンプリングを行えばよいのかという疑問が生じます。データセットのサイズによる予測ののび具合は、学習データのサンプル数と予測性能の関係を表した学習曲線で確認します。まずは計算時間が許容できる範囲内で小さめのデータセットから試していくと良いでしょう。

　ある程度の精度を保ちながらデータのサイズを小さくすることで、計算時間を削減することができ、特徴量エンジニアリングなど他のところに時間をかけて精度改善の検討ができるようになります。

3. 少数派クラスのサンプル数が極端に少ないのにデータサイズが大きい場合（約1%以下, 数十GB）

　データの不均衡具合とデータサイズの大きさが問題である場合、両方の問題を解決する必要があります。ランダムサンプリングで全体のサンプル数を減らすと、今回重要視している少数派クラスのサンプル数も減ってしまいます。そこで、多数派のクラスだけをサンプリングする Negative Down Sampling によって計算量を削減します。

　ここで気になるのは、Negative Down Samplingによる精度低下です。これに対しては、サンプリングのシードを変えて繰り返しアンサンブルするブートストラップ法を用いることによって精度低下を補う方法がよく使われます。

　少し違った視点として、問題設計を変える方法もあります。故障検知など、異常状態のデータがなかなか取れない状況では、教師なしの異常検知として課題の再設定をすることもあります。

今回は、データセットサイズと不均衡具合に応じた状況別の一般的な対処法を紹介しています。データによっては該当しない対処法もありますので、あくまで一般的な方法だと理解しておいてください。

DataRobotにおける不均衡データの対処法

　前章では、状況別で以下のような不均衡データの対処法がありました。

1. 不均衡データにロバストな最適化指標の設定
2. 学習曲線の確認による適切なデータサイズの決定
3. Negative Down Samplingによる計算量の削減
4. Balanced Bootstrapによる精度低下の補填
5. 異常検知問題としての取り扱い

これらの方法をDataRobotで行うにはどうすればよいのでしょうか。もちろんDataRobotが自動で設定する点もありますが、ユーザ側で指定する箇所もあります。DataRobotがカバーしている機能の範囲を知り、正しく分析を進めていく方法をみていきましょう。

1. 不均衡データにロバストな最適化指標の設定

　不均衡なデータでモデリングする場合、DataRobotは自動的にターゲット変数の値の分布から最適なモデル最適化指標を選択します。

　これまでは分類問題を前提で話を進めてきましたが、不均衡データの問題は分類、回帰どちらでも起こりえる問題です。図2の分類の不均衡データセットの例では、DataRobotは前述のLogLossを最適化指標として選択しています。

同様に、回帰でも、例えばターゲットの値の大半をゼロが占めるような不均衡データ（ゼロ過剰）を扱うことがあります。このようなゼロ過剰の場合には、最適化指標としてTweedie Devianceがよく使われます。DataRobotは回帰の不均衡データの場合でも自動的に適切な最適化指標を選択します。なぜTweedie Devianceが使われるのかを知りたい方はドキュメントページDataRobotの指標をご確認ください。

　ここで、結果のROC曲線も確認しておきましょう。ROC曲線の情報を活用することで、不均衡なデータがモデルのパフォーマンスに与える影響を最小限に抑えることができます。前述の割引キャンペーンの例で考えてみましょう。キャンペーンを実施する際に、できる限りたくさんの人にキャンペーンで購入してほしいのですが、全員にキャンペーンチラシを送るとコストがかさんでしまいます。コストを抑えて購入率の高い人にだけ送付するのか、機会損失を防ぐために多めの人にキャンペーンを案内しておくのかについては、予算やキャンペーンの内容によって変わってきます。予測分布グラフの予測しきい値（図3）を調節することにより、割引キャンペーンで購入すると予測されたが実際は購入しなかった人（偽陽性）と購入しないと予測されたが実際は購入した人（偽陰性）それぞれがどれだけ許容できるかを決定します。これによって、少数派のクラスに対する予測が改善される可能性があります。

　不均衡データの場合、モデル評価指標のひとつであるマシューズ相関係数を参考にするとよいでしょう。（図4）マシューズ相関係数は混同行列の予測と実測の一致度合いを表す指標で、完全に一致していたら+1、不一致なら-1を取ります。データセットの多数派クラスと少数派クラスの大きさに比例した結果を返すため、不均衡なデータセットから構築されたモデルを評価するのに適しています。

2. 学習曲線の確認による適切なデータサイズの決定

　データセットのサイズを大きくすることに意味があるかどうかを判断ために、サンプルサイズごとの学習曲線を確認します。「どれくらいの規模のデータを用意すればよいのか」は不均衡データを扱うときだけでなく、一般的に機械学習モデルを作る際によく聞かれる質問です。扱うデータにより状況が異なるので決まった回答はありませんが、学習曲線でサンプルサイズを増やしたときにどれくらいスコアが上がるのかを確認することにより、必要なサンプルサイズのあたりを付けることができます。

　DataRobotでは、最初から全てのデータを使わず、最初はデータの一部を使って短時間でモモデリングを行います。図5では、全体の16%のデータから始まって32%、64%とデータを増やしたときに学習曲線（LogLossのスコアがどう減っているか）を確認できます。

もしデータを増やしたときにスコアがあまり変わっておらずビジネス面での影響が軽微である場合は、サンプルサイズを大きくする必要はないと判断できます。

3. Negative Down Samplingによる計算量の削減

　計算量を削減するために、多数派のクラスのサンプル数だけを減らすNegative Down Samplingを行い、クラスごとのサンプル数のバランスを取ります。（図6）しかし、これではサンプリングバイアスが生じ、少数派サンプルが過大評価されてしまいます。そこで、得られたデータセットの効果が元のクラスのバランスと同じになるように重みづけをします。

DataRobotではこの一連の作業をスマートダウンサンプリングとよんでいます。モデリング時にスマートダウンサンプリングのオプションを有効化して使用できます。（図7）なお、データセットのサイズが500MB以上、かつ多数派クラスが少数派クラスの2倍以上データ以下の時には、自動的にスマートダウンサンプリングが適用されます。

スマートダウンサンプリングの目的は、精度改善ではなくあくまで計算の高速化であることにご注意ください。

4. Balanced Bootstrapによる精度低下の補填

　サンプリングによる精度低下の影響を低減するため、ブートストラップ法を使うことは前章で取り上げました。DataRobotでは、“Balanced” という接頭辞がつくブループリントがBalanced Bootstrapに対応したモデルです。（図8）

このモデルが選ばれるかどうかは手動モードでなければDataRobotによって自動的に決定されるため、不均衡データに対してモデリングすると含まれることがあります。また、リポジトリから ”Balanced” から始まるモデルを選択する方法、あるいは高度なチューニングからbalanced_bootstrapのオプションをTrueにする方法で、手動で設定することも可能です。（図9）

5. 異常検知問題としての取り扱い

　DataRobotは分類や回帰の教師あり学習だけではなく、教師なしの異常検知にも対応しています。（図10）どうしても少数派クラスのサンプル数が十分に得られない場合は課題設定を見直すことも検討してください。

関連トピック

　最後に、不均衡データの対処法としてよく挙げられるデータの拡張（水増し）について触れます。計算量を減らす目的で行ったNegative Down Samplingでは多数派クラスのサンプル数を減らしましたが、逆に少数派クラスのサンプル数を水増しする方法（アップサンプリング）はどうでしょうか。水増しをした際に元データと水増しデータのサンプルのクラスラベルが同じと保証される場合は、精度向上の可能性があるでしょう。

　例えば、画像データで判別モデルを作る際に、画像を左右反転させたり角度を変えてデータ拡張（Data Augmentation）を行います。この拡張方法がある程度うまくいく理由は、大半の場合は左右反転してもターゲットが同じためです。データ拡張でも例えば人を判別する際に上下反転でデータ拡張を行ってもそれほど精度が上がらないことが大半です。人が逆さまの状態になっていることはあまりないためです。このことから、データを拡張する際には、元のデータと水増ししたデータが同じ対象物と認識できる場合、判別に有用な情報を増やす事ができると言えます。

　現在提案されているテーブルデータにおける少数派クラスのサンプル水増し方法は、元データと水増しデータのクラスラベルが同じであるという仮定が成立していないことがあります。データ拡張を検討する場合は、本当に問題を解決できる手段であるかどうかを考えて実施することが必要です。

最後に

　今回は、偏りのあるデータにおける一般的な対処法とDataRobotにおける対処法を取り上げました。より最適化指標や評価指標について深く知りたい方はモデル最適化指標点評価指標の選び方やマシューズ相関係数とはをご覧ください。不均衡データでもこんなに細かい対処はしなくてもよいのではないかと思われたかもしれません。しかし実際、最初に挙げた例のように「全て多数派クラスとして分類」を誤ったアクションにつなげてしまっている状況を時々みかけます。不均衡データに対するそれぞれの対処法で解決できる内容を理解することで、モデリングを実ビジネスに活用していただければと思っています。

　この投稿は、DataRobot Communityに投稿された質問が元になっています。DataRobotの操作方法だけでなく、予測モデリングやプロジェクト管理など、AIプロジェクトを行う上でのお困りごとがありましたらお気軽にコミュニティに投稿してください。

関連ページ

• [アーカイブ] DataRobotコミュニティウェビナー: 「DataRobotに相談してみよう」2022年7月回

参考文献

[1] T. Saito and M. Rehmsmeier, “The Precision-Recall Plot Is More Informative than the ROC Plot When Evaluating Binary Classifiers on Imbalanced Datasets,” PLoS One. 2015; 10(3): e0118432. Published online 2015 Mar 4. doi: 10.1371/journal.pone.0118432

投稿 機械学習における不均衡データへの対処法 は DataRobot に最初に表示されました。

需要予測は、多くの DataRobot ユーザーが取り組んでいる時系列のユースケースです。過去の販売データ、商品/製品の特徴、イベントカレンダー、経済指標に関するデータを使って、未来の需要予測を行います。この予測をもとに在庫管理やサプライチェーンの計画をして、業務全体の効率化を図ることができます。

さまざまな企業での需要予測における共通課題は、商品ライン、すなわちSKU (Stock Keeping Unit) の多さにどう対処するかです。ここでの問題は、SKU の数が多い場合、全ての SKU について正確な予測を作成するのは簡単ではないということです。特に、消費財を扱う典型的な小売業での需要予測モデルは、何千、何万もの SKU を予測しなければならないこともあります。

SKU 数が多い場合の需要予測モデルのパフォーマンスを向上させるためのいくつかのテクニック（手法）があります。これらのテクニックは商品のクラスタリングを中心としたもので、互いに「近い」または類似している商品カテゴリや SKU をクラスタリングし、一緒にモデル化します。

このブログでは、これらの手法に注目して解説します。需要予測のユースケースでは、これらのテクニックを一つだけでなく、複数適用することもできます。

1. 商品グループごとのクラスタリング

SKU のクラスタリングで最も直感的な方法は、商品グループによってクラスタリング（グループ化）することです。商品の種類によって需要のパターンが異なることは当然です。例えば、高価な宝飾品の需要は比較的低めで金の価格に大きく左右されますが、一般的にネックレスやイヤリングなどのファッション性の高いアクセサリーは需要パターンに一貫性があり取引量も多くなります。テーマ性のある宝飾品の販売パターンには強い季節性があり、バレンタインデーや母の日などの特定イベントにピークを迎えます。このように、ドメイン知識から需要の性質が似ていると考えられる商品グループを一緒にモデル化することでモデルに影響を及ぼす要因をよりよく捉え、結果的に予測精度を高めることができます。また、これらのデータセットを作るために機械学習などの方法を取る必要はなく、商品カテゴリごとにグルーピングすることで簡単に用意できます。

2. 売上プロファイルごとのクラスタリング

商品グループごとにモデルを構築する手法は、シンプルでわかりやすい出発点です。しかし、同じ商品グループでも、販売パターンや性質が大きく異なる商品が存在することもあります。そのような場合には、過去の売上をプロットしてパターンを可視化しながら陳腐化した商品や売上数にゼロがたくさんある商品を特定し、より良いサブクラスタリングを作成することができます。また、可視化によって潜在的なデータの問題を発見したり、ビジネス部門が気づいていないような興味深い販売パターンから洞察を得たりすることができます。

過去の販売パターンを可視化する場合、数千の SKU を可視化するには多少のコーディングスキルが必要かもしれませんが、Python や R で実現するのはそれほど難しい作業ではありません。また、Tableau（英語）や PowerBI などの BI ツールを使えば、これらのタスクを簡単に実行できます。

3. DataRobot でのパフォーマンスクラスタモデルの活用

上図のようなパフォーマンスクラスタモデルでは、ベースとなるモデルを用いたときの各系列の推定精度に基づいて系列データをクラスタリングします。ここではベースモデルとして eXtreme Gradient Boosting モデル（XGB）を使用しています。XGB の推定を数回繰り返した後、モデル性能が類似している系列データを個々のクラスタに割り当てます。上記モデルには5つのクラスタがあります。

モデルが作成したクラスタの数と各クラスタに含まれる系列の数に関する情報は、係数のセクションで確認できます。また、系列 ID とクラスタ番号の対応付けは、同じウィンドウのエクスポートオプションからダウンロードできます。

パフォーマンスクラスタモデルにおけるクラスタ数はモデルのハイパーパラメータの一つで、DataRobot オプション内の高度なチューニングの画面からモデル作成者が最大20クラスタまで設定可能です。

4. DataRobot における系列のインサイト機能の活用

また、系列のインサイトタブを使用して、個々の系列を調査することもできます。系列のインサイトは、異なるバックテストで選択した評価指標（例：SMAPE）に基づき、各系列がどれくらいの精度なのかを教えてくれます。

ここから、モデルのパフォーマンスおよび/または商品グループや販売プロファイルが類似している系列を発見できます。商品クラスタリングはモデル駆動型とビジネス駆動型を組み合わせて行えるので、この商品クラスタリングに基づいて、個々の DataRobot プロジェクトを構築します。

最後に、DataRobot にはデータの蓄積がないコールドスタートとデータがある程度確保できるウォームスタートの両方を同じモデルで扱うことができるブループリントがあります。一般的に、これらのブループリントは2段階のアプローチを使用します。

1. データ全体に対して、平均化された派生特徴量に対してうまく作用する主効果モデルを構築します。
2. ステップ1で得た他の商品に共通してみられる特徴量（利用可能な場合）を過去のデータが全くない商品に対して使用して予測を行い、各系列に対するインパクトの大きさを得ます。部分的にデータがある商品に対しては、データ全体に共通する特徴量だけでなく、系列パターンも使用して予測を行います。

以上をまとめると、需要予測のユースケースにおいて、商品クラスタリングのテクニックを使用してモデルの精度パフォーマンスを向上させることができます。また、モデル主導型とビジネス主導型の商品クラスタリングを組み合わせて使用することで、需要予測モデルを最適化できます。DataRobot の Automated Time Series (AutoTS) の詳細については、Automated Time Series の製品ページや、AutoTS HowTo (DataRobot University) の自習教材、 時系列予測に関連するオンデマンドウェブセミナーをご覧ください。

投稿 需要予測におけるクラスタリング技術の活用 は DataRobot に最初に表示されました。