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

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

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

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

LLM のユースケース

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

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

カスタマイズアプローチ

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

プロンプトエンジニアリング

プロンプトエンジニアリングは、LLM への入力を調整することで、生成 AI ソリューションをガイドして必要な出力を作成するプロセスです。関連するコンテキストで正確なプロンプトを作成することで、推論を必要とする専門的な医療タスクの完了に向けてモデルをガイドすることができます。効果的なプロンプトエンジニアリングにより、モデルの変更を必要とせずに、医療ユースケースのモデルパフォーマンスを大幅に向上させることができます。プロンプトエンジニアリングの詳細については、「Amazon Bedrock を使用した高度なプロンプトエンジニアリングの実装」(AWS ブログ記事) を参照してください。少数ショットプロンプトとchain-of-thoughtプロンプトは、プロンプトエンジニアリングで使用できる手法です。

数ショットプロンプト

少数ショットプロンプトは、LLM に同様のタスクの実行を求める前に、必要な入出力のいくつかの例を提供する手法です。医療の文脈では、このアプローチは、医療エンティティの認識や臨床メモの要約などの特殊なタスクに特に役立ちます。プロンプトに 3～5 個の高品質の例を含めることで、医学用語とドメイン固有のパターンに対するモデルの理解を大幅に向上させることができます。数ショットプロンプトの例については、「Amazon Bedrock での LLMs」(AWS ブログ記事) を参照してください。

例えば、臨床ノートから薬剤の投与量を抽出する場合、医療専門家が処方を記録する方法のバリエーションをモデルが認識するのに役立つさまざまな表記スタイルの例を提供できます。このアプローチは、標準化されたドキュメント形式を使用する場合や、データに一貫したパターンが存在する場合に特に効果的です。

Chain-of-thoughtプロンプト

Chain-of-thought (CoT) プロンプトは、LLM をステップstep-by-stepの推論プロセスでガイドします。これにより、複雑な医療上の意思決定のサポートや診断の推論タスクに役立ちます。臨床シナリオを分析するときにモデルに「ステップバイステップ」を明示的に指示することで、医療推論プロトコルに従う能力を向上させ、診断エラーを減らすことができます。

この手法は、臨床推論に差分診断や治療計画など、複数の論理的なステップが必要な場合に優れています。ただし、モデルのトレーニングデータ外で高度に専門的な医療知識を扱う場合や、クリティカルケアの決定に絶対精度が必要な場合、このアプローチには制限があります。

このような場合、CoT を別のアプローチと組み合わせると、より良い結果が得られます。1 つのオプションは、CoT と自己整合性プロンプトを組み合わせることです。詳細については、「Amazon Bedrock での自己整合性プロンプトによる生成言語モデルのパフォーマンスの向上」(AWS ブログ記事) を参照してください。もう 1 つのオプションは、ReAct プロンプトなどの推論フレームワークを RAG と組み合わせることです。詳細については、「RAG および ReAct プロンプトを使用して高度な生成 AI チャットベースのアシスタントを開発する」(AWS 規範ガイダンス) を参照してください。

検索拡張生成

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

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 つの一般的なユースケースです。

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 の一覧です。

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

実際の医療 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 ガードレールを使用できます。