この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは。AWS事業本部のKyoです。
8月にAWSからゲノム解析に関する新ソリューションが発表されていました。
Genomics Tertiary Analysis and Machine Learning using Amazon SageMaker
日本語名は、「SageMakerを使ったゲノムの三次解析と機械学習」といったところでしょうか。
これは何？
どんなソリューションなのかを公式ドキュメントから翻訳・抜粋します。
このソリューションには以下が含まれます。
1)ゲノミクス機械学習トレーニングデータセットの準備を自動化する方法
2)ゲノミクス機械学習モデルのトレーニングと展開パイプラインを開発する方法
3)テストデータを使用して予測値を生成し、モデルの性能を評価する方法
このソリューションは、AWS CloudFormationを利用してAWSクラウド上でのデプロイを自動化し、データ準備ジョブやソリューションノートへのアップデートのビルドとデプロイにはAWS CodePipeline、ソースコードリポジトリであるAWS CodeCommitを利用した継続的インテグレーションと継続的デリバリ（CI/CD）が含まれています。
ざっくりいうと、SageMakerを使ってゲノム解析を行うための環境を丸ごとCloudFormationにしましたというところのようです。
ゲノム解析を行うに当たってバイオインフォマティシャンは解析業務に集中したいはず。インフラ周りも考えると大変ですよね。そこでインフラまわりをCI/CDパイプライン化したのが本ソリューションです。
※図は公式ドキュメントより引用
これを元に改修を加えて利用することが想定されます。インフラの改修方法については以下にドキュメントがあります。
AWS Developer Guide: Genomics Tertiary Analysis and Machine Learning Using AWS Amazon SageMaker
今回のゴール
デフォルトでKaggleの問題Genetic Variant Classificationsが設定されていますので、これをやってみます。
問題
改めて翻訳した問題をみてみます。
ClinVarは、ヒトの遺伝的バリアントに関するアノテーションを収録した公開リソースである。これらのバリアントは、良性、良性の可能性が高い、有意性が不明、病原性の可能性が高い、病原性が高い、そして病原性が高いというように、臨床検査機関によって（通常は手動で）分類されています。臨床家や研究者が、そのバリアントが特定の患者の疾患に影響を与えるかどうかを解釈しようとするときに、（検査室によって）分類が異なるバリアントは混乱を引き起こす可能性があります。
目的は、ClinVarバリアントが競合する分類を持つかどうかを予測することです。これは、データセットの各レコードが遺伝的変異体であるバイナリ分類問題としてここに提示されます。
※画像はkaggleページより引用
問題解釈
以下のように解釈しました。
データセットを確認すると、染色体番号、位置、リファレンスアリル、変化後のアリル、といったカラムが46種類並んでいます。
今回の解析で重要になるのがCLNSIGINCLおよびCLASSというカラムです。
CLNSIGINCLはclinical significance、つまり臨床的意義を示します。これは、1つのバリアントに対して以下の3つの分類（および細分化した5パターン分け）がなされています。
- 分類1: 良性, 良性の可能性が高い
- 分類2: 疾患との関連性が明らかではない
- 分類3: 病原性, 病原性の可能性が高い
このうち2つ以上の分類が存在する場合を競合と言います（例: 良性, 病原性の可能性が高い が同時に存在 ）。1つの分類の2つの存在は競合とはみなされません（例: 良性, 良性の可能性が高い が同時に存在）。
競合があると、臨床家や研究者が患者の疾患への影響を解釈しようとした際に混乱を引き起こす可能性があります。
CLASSの値は各バリアントの分類の競合をバイナリで表現し、競合がない場合は0, 競合がある場合は1となります。
今回はこのデータセットを元にバリアントが競合を持つかどうか、つまりCLASSの推論を行う機械学習モデルを構築することをゴールとします。
やってみた
STEP1. スタックを起動する
こちらのテンプレートからCloudFormationで起動します。 プロジェクト名を入力するだけで、4つのスタックが生成されます。起動時間はトータルで10分程度でした。
画像は再掲ですが、数字がスタックと対応しています。
STEP2. モデル生成パイプラインを実行する
先ほどのCloudFormationによってSageMakerのノートブックインスタンスが起動しているのでJupyterを開き、
以下の順番でipynbファイルを実行していきます。
variant_classifier-autopilot.ipynb
行っていることとしては、S3からデータをロード、それをランダムにトレーニングデータ（80%）とテストデータ（20%）に分割し、CLASSというカラムに注目してAutopilotジョブを実行。アウトプットとして、データ探索ノートブック SageMakerAutopilotDataExplorationNotebook.ipynbと候補生成ノートブック SageMakerAutopilotCandidateDefinitionNotebook.ipynbの生成だと思います。
Amazon SageMaker Autopilot ノートブック出力
- Setup
- Get datalake bucket
- Dataset
- Setting up the SageMaker Autopilot Job
- Launching the SageMaker Autopilot Job
- Downloading the autopilot candidate Notebooks
SageMakerAutopilotDataExplorationNotebook.ipynb (データ探索ノートブック)
処理ではなく、先ほどのAutopilotジョブの入力となったデータセットについての概要がまとまっているので確認しました。 項目ごとのデータの欠損率、統計情報なども含まれていました。
We read 52150 rows from the training dataset. The dataset has 46 columns and the column named CLASS is used as the target column. This is identified as a BinaryClassification problem. Here are 2 examples of labels: ['0', '1'].
- Dataset Sample
- Column Analysis
- Percent of Missing Values
- Count Statistics
- Descriptive Statistics
SageMakerAutopilotCandidateDefinitionNotebook.ipynb (候補生成ノートブック)
処理の内容としては、推論パイプライン（下記参照）を生成し、 評価関数を使って最も性能の良いものを見つけて最終的にはデプロイを行うといったところだと思います。
なお、「Multi Algorithm Hyperparameter Tuning」には数時間必要でしたので、実行時にはご注意ください。
推論パイプラインは、データに対する推論要求を処理する 2〜5 個のコンテナの順番で構成される Amazon SageMaker モデルです。推論パイプラインを使用して、事前トレーニング済みの Amazon SageMaker 組み込みアルゴリズムと、Docker コンテナにパッケージ化された独自のカスタムアルゴリズムの任意の組み合わせを定義、展開します。推論パイプラインを使用して、事前処理、予測、および後処理のデータサイエンスタスクを組み合わせることができます。
- Sagemaker Setup
- Downloading Generated Candidates
- SageMaker Autopilot Job and Amazon Simple Storage Service (Amazon S3) Configuration
- Candidate Pipelines
- Generated Candidates
- Selected Candidates
- Executing the Candidate Pipelines
- Run Data Transformation Steps
- Multi Algorithm Hyperparameter Tuning
- Model Selection and Deployment
- Tuning Job Result Overview
- Model Deployment
実行後はこのような形でモデルがデプロイされていました。
STEP3.予測を生成し、モデルのパフォーマンスを評価する
variant_predictor@SageMaker.ipynb
先ほどトレーニングおよびデプロイしたモデルを利用して、テストデータのCLASSを推論します。
推論結果は、回答である実際のデータを比較することで、モデルの品質チェックを行っています。
- Setup
- Get the endpoint name
- Data Preprocessing
- Generate Predictions
- Model Evaluation
Model Evaluationには、混同行列およびROC曲線を利用しています。
これらの評価方法については、以下のQiita記事が分かりやすかったのでご紹介させていただきます。
実際の結果を見てみます。
混合行列が示すように、またAccuracyの割にRecallが低いということから、今回作成したモデルは実データの真偽にかかわらず陰性、すなわち「競合がない」という判定を下しやすいという傾向が見えてきました。
問題に立ち返って考えてみます。
臨床家や研究者が、そのバリアントが特定の患者の疾患に影響を与えるかどうかを解釈しようとするときに、（検査室によって）分類が異なるバリアントは混乱を引き起こす可能性があります。
今回の問題では、この混乱に対して正しく対応できることがビジネス上のゴールと言えます。
これをもとに偽陽性、偽陰性について考えてみます。
偽陽性については、使用者（臨床家や研究者）が「競合がある」前提で解釈を行うことになります。このケースでは、後で「競合がない」と判断されますが、判断された時点で解釈の精度が上がることになります。
一方で偽陰性については、使用者は「競合がない」前提で解釈を行うことになります。このケースでは、後で「競合がない」と判断されますが、判断された時点で解釈そのものが変わる恐れがあります。
以上から、偽陰性、つまりバリアントが本来競合を持つのに持たないと判断されることよりも、偽陽性として競合を持つと判断される方がトータルのリスクが低いのではないかと考えました。
実利用ではこういったビジネス要件に基づいたチューニングが必要になると思われます。これを行うためにも要件定義の際にモデルの定量的な性能目標の設定は重要になると考えました。
おわりに
本ブログでは、「Genomics Tertiary Analysis and Machine Learning using Amazon SageMaker」でkaggleの問題についてモデルの生成し、評価までを行ってみました。
CloudFormationで必要なものが全部揃い、Jupyter notebookも対話的であるため、一連の流れをかなりスムーズに行えたと思います。
以上、何かのお役に立てれば幸いです。
参考
ClinVar: improving access to variant interpretations and supporting evidence
genomics-tertiary-analysis-and-machine-learning-using-amazon-sagemaker
3
