ヘルスケアとライフサイエンスのユースケースに大規模言語モデルを使用する - AWS 規範ガイダンス
LLM のユースケースカスタマイズLLM の選択

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ヘルスケアとライフサイエンスのユースケースに大規模言語モデルを使用する

ここでは、医療およびライフサイエンスアプリケーションに大規模言語モデル (LLMs) を使用する方法について説明します。一部のユースケースでは、生成 AI 機能に大規模言語モデルを使用する必要があります。state-of-the-art LLMs にも利点と制限があり、このセクションの推奨事項は、ターゲット結果の達成に役立つように設計されています。

決定パスを使用して、ドメインの知識や利用可能なトレーニングデータなどの要因を考慮して、ユースケースに適した LLM ソリューションを決定できます。さらに、このセクションでは、一般的な事前トレーニング済み医療 LLMsとその選択と使用に関するベストプラクティスについて説明します。また、複雑で高性能なソリューションと、よりシンプルで低コストなアプローチとのトレードオフについても説明します。

LLM のユースケース

Amazon Comprehend Medical は、特定の NLP タスクを実行できます。詳細については、「Amazon Comprehend Medical のユースケース」を参照してください。

次のような高度なヘルスケアやライフサイエンスのユースケースでは、LLM の論理 AI および生成 AI 機能が必要になる場合があります。

  • カスタム医療エンティティまたはテキストカテゴリの分類

  • 臨床的な質問に回答する

  • メディカルレポートの概要

  • 医療情報からのインサイトの生成と検出

カスタマイズアプローチ

LLMs実装方法を理解することが重要です。LLMs は一般的に、多くのドメインからのトレーニングデータを含む数十億のパラメータでトレーニングされます。このトレーニングにより、LLM は最も一般化されたタスクに対処できます。ただし、ドメイン固有の知識が必要な場合に課題が発生することがよくあります。ヘルスケアとライフサイエンスの分野の知識の例としては、正確な回答を生成するために必要な臨床コード、医学用語、健康情報などがあります。したがって、これらのユースケースで LLM をそのまま使用すると (ドメインの知識を補足せずにゼロショットプロンプトを実行）、結果が不正確になる可能性があります。この課題を克服するために使用できるアプローチは、取得拡張生成と微調整の 2 つです。

検索拡張生成

Retrieval Augmented Generation (RAG) は、LLM がレスポンスを生成する前にトレーニングデータソースの外部にある信頼できるデータソースを参照する生成 AI テクノロジーです。RAG システムは、ナレッジソースから医療オントロジー情報 (疾病の国際分類、国の医薬品ファイル、医療対象者の見出しなど) を取得できます。これにより、LLM に追加のコンテキストが提供され、医療 NLP タスクがサポートされます。

Amazon Comprehend Medical と大規模言語モデルの組み合わせ セクションで説明したように、RAG アプローチを使用して Amazon Comprehend Medical からコンテキストを取得できます。その他の一般的なナレッジソースには、Amazon OpenSearch Service、Amazon Kendra、Amazon Aurora などのデータベースサービスに保存される医療ドメインデータが含まれます。これらのナレッジソースから情報を抽出すると、特にベクトルデータベースを使用するセマンティッククエリでは、取得パフォーマンスに影響する可能性があります。

ドメイン固有の知識を保存および取得するもう 1 つのオプションは、RAG ワークフローで Amazon Q Business を使用することです。Amazon Q Business は、内部ドキュメントリポジトリまたは公開ウェブサイト (ICD-10 データの場合は CMS.gov など) のインデックスを作成できます。Amazon Q Business は、クエリを LLM に渡す前に、これらのソースから関連情報を抽出できます。

カスタム RAG ワークフローを構築する方法は複数あります。たとえば、ナレッジソースからデータを取得する方法は多数あります。簡単にするために、Amazon OpenSearch Service などのベクトルデータベースを使用して知識を埋め込みとして保存する一般的な取得アプローチをお勧めします。そのためには、文トランスフォーマーなどの埋め込みモデルを使用して、クエリとベクトルデータベースに保存されているナレッジの埋め込みを生成する必要があります。

フルマネージド型およびカスタム RAG アプローチの詳細については、「Retrieval Augmented Generation options and architectures on AWS」を参照してください。

ファインチューニング

既存のモデルを微調整するには、Amazon Titan、Mistral、Llama モデルなどの LLM を取得し、そのモデルをカスタムデータに適応させる必要があります。ファインチューニングにはさまざまな手法があり、そのほとんどはモデル内のすべてのパラメータを変更するのではなく、少数のパラメータのみを変更する方法です。これは、パラメータ効率の高いファインチューニング (PEFT) と呼ばれます。詳細については、GitHub の「Hugging Face PEFT」を参照してください。

以下は、医療 NLP タスクの LLM を微調整する場合の 2 つの一般的なユースケースです。

  • 生成タスク – デコーダーベースのモデルは生成 AI タスクを実行します。AI/ML 実務者はグラウンドトゥルースデータを使用して既存の LLM を微調整します。例えば、公的医療上の質疑応答データセットである MedQuAD を使用して LLM をトレーニングできます。ファインチューニングされた LLM にクエリを呼び出す場合、LLM に追加のコンテキストを提供するために RAG アプローチは必要ありません。

  • 埋め込み – エンコーダベースのモデルは、テキストを数値ベクトルに変換することで埋め込みを生成します。これらのエンコーダベースのモデルは、通常埋め込みモデルと呼ばれます。文変換モデルは、文用に最適化された特定のタイプの埋め込みモデルです。目的は、入力テキストから埋め込みを生成することです。次に、埋め込みはセマンティック分析または取得タスクに使用されます。埋め込みモデルを微調整するには、トレーニングデータとして使用できるドキュメントなどの医療知識のコーパスが必要です。これは、文トランスフォーマーモデルをファインチューニングするための類似性または感情に基づくテキストのペアで実現されます。詳細については、Hugging Face の「Training and Finetuning Embedding Models with Sentence Transformers v3」を参照してください。

Amazon SageMaker Ground Truth を使用して、ラベル付きの高品質のトレーニングデータセットを構築できます。Ground Truth のラベル付きデータセット出力を使用して、独自のモデルをトレーニングできます。Amazon SageMaker AI モデルのトレーニングデータセットとして出力を使用することもできます。名前付きエンティティ認識、単一ラベルテキスト分類、マルチラベルテキスト分類の詳細については、Amazon SageMaker AI ドキュメントの「Ground Truth を使用したテキストラベル付け」を参照してください。

LLM の選択

Amazon Bedrock は、高パフォーマンスの LLMs。詳細については、「Amazon Bedrock でサポートされている基盤モデル」を参照してください。Amazon Bedrock のモデル評価ジョブを使用して、複数の出力からの出力を比較し、ユースケースに最適なモデルを選択できます。詳細については、Amazon Bedrock ドキュメントの「Amazon Bedrock 評価を使用して最もパフォーマンスの高いモデルを選択する」を参照してください。

一部の LLMsでは、医療ドメインデータに関するトレーニングが制限されています。ユースケースで Amazon Bedrock がサポートしていない LLM または LLM の微調整が必要な場合は、Amazon SageMaker AI の使用を検討してください。SageMaker AI では、微調整された LLM を使用するか、医療ドメインデータでトレーニングされたカスタム LLM を選択できます。

次の表LLMs を示します。

LLM タスク ナレッジ アーキテクチャ
BioBERT 情報の取得、テキスト分類、および名前付きエンティティの認識 PubMed からの抜粋、PubMedCentral からの全文記事、一般的なドメイン知識 エンコーダー
ClinicalBERT 情報の取得、テキスト分類、および名前付きエンティティの認識 大規模な多施設データセットと、電子医療記録 (EHR) システムから 3,000,000 を超える患者記録 エンコーダー
ClinicalGPT 要約、質疑応答、テキスト生成 医療記録、ドメイン固有の知識、マルチラウンド対話の相談など、広範で多様な医療データセット デコーダー
GatorTron-OG 要約、質疑応答、テキスト生成、情報取得 臨床ノートと生物医学の文献 エンコーダー
Med-BERT 情報の取得、テキスト分類、および名前付きエンティティの認識 医療テキスト、臨床ノート、研究論文、医療関連ドキュメントの大規模なデータセット エンコーダー
Med-PaLM 医療目的の質疑応答 医療テキストと生物医学テキストのデータセット デコーダー
medAlpaca 質問への回答と医療対話タスク 医療フラッシュカード、Wiki、ダイアログデータセットなどのリソースを含む、さまざまな医療テキスト デコーダー
BiomedBERT 情報の取得、テキスト分類、および名前付きエンティティの認識 PubMed からの抜粋と PubMedCentral からの全文記事のみ エンコーダー
BioMedLM 要約、質疑応答、テキスト生成 PubMed ナレッジソースからの生物医学文献 デコーダー

以下は、事前トレーニング済みの医療 LLMs。

  • トレーニングデータとその医療 NLP タスクとの関連性を理解します。

  • LLM アーキテクチャとその目的を特定します。エンコーダーは、埋め込みや NLP タスクに適しています。デコーダーは生成タスク用です。

  • 事前トレーニング済みの医療 LLM をホストするためのインフラストラクチャ、パフォーマンス、コスト要件を評価します。

  • 微調整が必要な場合は、トレーニングデータの正確なグラウンドトゥルースまたは知識を確保します。個人を特定できる情報 (PII) または保護された医療情報 (PHI) をマスクまたは編集してください。

実際の医療 NLP タスクは、知識や意図したユースケースの観点から、事前トレーニング済みの LLMs とは異なる場合があります。ドメイン固有の LLM が評価ベンチマークを満たさない場合は、独自のデータセットを使用して LLM を微調整することも、新しい基盤モデルをトレーニングすることもできます。新しい基盤モデルのトレーニングは、野心的で、多くの場合、コストがかかる事業です。ほとんどのユースケースでは、既存のモデルを微調整することをお勧めします。

事前トレーニング済みの医療 LLM を使用または微調整する場合は、インフラストラクチャ、セキュリティ、ガードレールに対応することが重要です。

インフラストラクチャ

オンデマンドまたはバッチ推論に Amazon Bedrock を使用する場合と比較して、事前トレーニング済みの医療 LLMs (Hugging Face からのみ) をホストするには、大量のリソースが必要です。事前トレーニング済みの医療 LLMsホストするには、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで実行される Amazon SageMaker AI イメージを、高速コンピューティング用の ml.g5 インスタンスや ml.inf2 インスタンスなどの 1 つ以上の GPUs と共に使用するのが一般的です AWS Inferentia。これは、LLMs消費するためです。

セキュリティとガードレール

ビジネスコンプライアンス要件に応じて、Amazon Comprehend と Amazon Comprehend Medical を使用して、トレーニングデータから個人を特定できる情報 (PII) と保護医療情報 (PHI) をマスクまたは編集することを検討してください。これにより、LLM がレスポンスを生成するときに機密データを使用するのを防ぐことができます。

生成 AI アプリケーションのバイアス、公平性、幻覚を考慮し、評価することをお勧めします。既存の LLM を使用している場合でも、微調整を使用している場合でも、有害な応答を防ぐためにガードレールを実装します。ガードレールは、生成 AI アプリケーションの要件と責任ある AI ポリシーに合わせてカスタマイズする保護手段です。例えば、Amazon Bedrock ガードレールを使用できます。