翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ヘルスケアとライフサイエンスのユースケースでの大規模言語モデルの使用
ここでは、医療およびライフサイエンスアプリケーションに大規模言語モデル (LLMs) を使用する方法について説明します。一部のユースケースでは、生成 AI 機能に大規模言語モデルを使用する必要があります。state-of-the-art LLMs にも利点と制限があり、このセクションの推奨事項は、ターゲット結果の達成に役立つように設計されています。
決定パスを使用して、ドメインの知識や利用可能なトレーニングデータなどの要因を考慮して、ユースケースに適した LLM ソリューションを決定できます。さらに、このセクションでは、一般的な事前トレーニング済み医療 LLMsとその選択と使用に関するベストプラクティスについて説明します。また、複雑で高性能なソリューションと、よりシンプルで低コストなアプローチのトレードオフについても説明します。
## LLM のユースケース
Amazon Comprehend Medical は、特定の NLP タスクを実行できます。詳細については、「[Amazon Comprehend Medical のユースケース](comprehend-medical.md#comprehend-medical-use-cases)」を参照してください。
LLM の論理および生成 AI 機能は、次のような高度な医療およびライフサイエンスのユースケースで必要になる場合があります。
+ カスタム医療エンティティまたはテキストカテゴリの分類
+ 臨床的な質問に回答する
+ メディカルレポートの概要
+ 医療情報からのインサイトの生成と検出
## カスタマイズアプローチ
LLMs実装方法を理解することが重要です。LLMs、多くのドメインからのトレーニングデータを含む数十億のパラメータでトレーニングされます。このトレーニングにより、LLM は最も一般化されたタスクに対処できます。ただし、ドメイン固有の知識が必要な場合に課題が発生することがよくあります。ヘルスケアとライフサイエンスの分野の知識の例としては、正確な回答を生成するために必要な臨床コード、医学用語、健康情報などがあります。したがって、これらのユースケースで LLM をそのまま使用すると (ドメインの知識を補足せずにゼロショットプロンプトを実行）、結果が不正確になる可能性があります。この課題を克服するために使用できる一般的なアプローチには、プロンプトエンジニアリング、検索拡張生成 (RAG)、ファインチューニングなどがあります。
### プロンプトエンジニアリング
*プロンプトエンジニアリング*は、LLM への入力を調整することで、生成 AI ソリューションをガイドして必要な出力を作成するプロセスです。関連するコンテキストで正確なプロンプトを作成することで、推論を必要とする専門的な医療タスクの完了に向けてモデルをガイドすることができます。効果的なプロンプトエンジニアリングにより、モデルの変更を必要とせずに、医療ユースケースのモデルパフォーマンスを大幅に向上させることができます。プロンプトエンジニアリングの詳細については、[「Amazon Bedrock を使用した高度なプロンプトエンジニアリングの実装](https://aws.amazon.com/blogs/machine-learning/implementing-advanced-prompt-engineering-with-amazon-bedrock/)」(AWS ブログ記事) を参照してください。少数ショットプロンプトとchain-of-thoughtプロンプトは、プロンプトエンジニアリングで使用できる手法です。
#### 数ショットプロンプト
少数ショットプロンプトは、LLM に同様のタスクの実行を求める前に、必要な入出力のいくつかの例を提供する手法です。医療の文脈では、このアプローチは、医療エンティティの認識や臨床メモの要約などの特殊なタスクに特に役立ちます。プロンプトに 3～5 個の高品質の例を含めることで、医学用語とドメイン固有のパターンに関するモデルの理解を大幅に向上させることができます。数ショットプロンプトの例については、[「Amazon Bedrock での LLMs](https://aws.amazon.com/blogs/machine-learning/few-shot-prompt-engineering-and-fine-tuning-for-llms-in-amazon-bedrock/)」(AWS ブログ記事) を参照してください。
例えば、臨床ノートから薬剤の投与量を抽出する場合、医療専門家が処方を記録する方法のバリエーションをモデルが認識するのに役立つさまざまな表記スタイルの例を提供できます。このアプローチは、標準化されたドキュメント形式を使用する場合や、データに一貫したパターンが存在する場合に特に効果的です。
#### Chain-of-thoughtプロンプト
*Chain-of-thought (CoT) プロンプト*は、LLM をステップstep-by-stepの推論プロセスでガイドします。これにより、複雑な医療上の意思決定のサポートや診断の推論タスクに役立ちます。臨床シナリオを分析するときにモデルに「ステップバイステップ」を明示的に指示することで、医療推論プロトコルに従う能力を向上させ、診断エラーを減らすことができます。
この手法は、臨床推論に差分診断や治療計画などの複数の論理的なステップが必要な場合に優れています。ただし、モデルのトレーニングデータ外で高度に専門的な医療知識を扱う場合や、クリティカルケアの決定に絶対精度が必要な場合、このアプローチには制限があります。
このような場合、CoT を別のアプローチと組み合わせると、より良い結果が得られます。1 つのオプションは、CoT と自己整合性プロンプト を組み合わせることです。詳細については、[「Amazon Bedrock での自己整合性プロンプトによる生成言語モデルのパフォーマンスの向上](https://aws.amazon.com/blogs/machine-learning/enhance-performance-of-generative-language-models-with-self-consistency-prompting-on-amazon-bedrock/)」(AWS ブログ記事) を参照してください。もう 1 つのオプションは、ReAct プロンプトなどの推論フレームワークを RAG と組み合わせることです。詳細については、[「RAG および ReAct プロンプトを使用して高度な生成 AI チャットベースのアシスタントを開発する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/develop-advanced-generative-ai-chat-based-assistants-by-using-rag-and-react-prompting.html)」(AWS 規範ガイダンス) を参照してください。
### 検索拡張生成
*Retrieval Augmented Generation (RAG)* は、LLM がレスポンスを生成する前にトレーニングデータソースの外部にある信頼できるデータソースを参照する生成 AI テクノロジーです。RAG システムは、ナレッジソースから医療オントロジー情報 (疾病の国際分類、国の医薬品ファイル、医療対象者の見出しなど) を取得できます。これにより、医療 NLP タスクをサポートするために LLM に追加のコンテキストが提供されます。
[Amazon Comprehend Medical と大規模言語モデルの組み合わせ](comprehend-medical-rag.md) セクションで説明したように、RAG アプローチを使用して Amazon Comprehend Medical からコンテキストを取得できます。その他の一般的なナレッジソースには、Amazon OpenSearch Service、Amazon Kendra、Amazon Aurora などのデータベースサービスに保存されている医療ドメインデータが含まれます。これらのナレッジソースから情報を抽出すると、特にベクトルデータベースを使用するセマンティッククエリでは、取得パフォーマンスに影響する可能性があります。
ドメイン固有の知識を保存および取得するもう 1 つのオプションは、RAG ワークフローで [Amazon Q Business](https://docs.aws.amazon.com/amazonq/latest/qbusiness-ug/what-is.html) を使用することです。Amazon Q Business は、内部ドキュメントリポジトリまたは公開ウェブサイト (ICD-10 データの場合は [CMS.gov](https://cms.gov/) など) のインデックスを作成できます。Amazon Q Business は、クエリを LLM に渡す前に、これらのソースから関連情報を抽出できます。
カスタム RAG ワークフローを構築する方法は複数あります。たとえば、ナレッジソースからデータを取得する方法は多数あります。簡単にするために、Amazon OpenSearch Service などのベクトルデータベースを使用して知識を埋め込みとして保存する一般的な取得アプローチをお勧めします。そのためには、文トランスフォーマーなどの埋め込みモデルを使用して、クエリとベクトルデータベースに保存されているナレッジの埋め込みを生成する必要があります。
フルマネージド型およびカスタム RAG アプローチの詳細については、[「Retrieval Augmented Generation options and architectures on AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/retrieval-augmented-generation-options/introduction.html)」を参照してください。
### ファインチューニング
既存のモデルを*微調整*するには、Amazon Titan、Mistral、Llama モデルなどの LLM を取得し、カスタムデータにモデルを適応させる必要があります。ファインチューニングにはさまざまな手法があり、そのほとんどはモデル内のすべてのパラメータを変更するのではなく、少数のパラメータのみを変更するものです。これは、*パラメータ効率の高い微調整 (PEFT) *と呼ばれます。詳細については、GitHub の[「Hugging Face PEFT](https://github.com/huggingface/peft)」を参照してください。
以下は、医療 NLP タスクの LLM を微調整する場合の 2 つの一般的なユースケースです。
+ **生成タスク** – デコーダーベースのモデルは生成 AI タスクを実行します。AI/ML 実務者はグラウンドトゥルースデータを使用して既存の LLM を微調整します。例えば、公的医療質問回答データセットである [MedQuAD](https://github.com/abachaa/MedQuAD) を使用して LLM をトレーニングできます。ファインチューニングされた LLM にクエリを呼び出す場合、LLM に追加のコンテキストを提供するために RAG アプローチは必要ありません。
+ **埋め込み** – エンコーダベースのモデルは、テキストを数値ベクトルに変換することで埋め込みを生成します。これらのエンコーダーベースのモデルは通常、*埋め込みモデル*と呼ばれます。*文変換モデルは*、文用に最適化された特定のタイプの埋め込みモデルです。目的は、入力テキストから埋め込みを生成することです。その後、埋め込みはセマンティック分析または取得タスクに使用されます。埋め込みモデルを微調整するには、トレーニングデータとして使用できるドキュメントなどの医療知識のコーパスが必要です。これは、文トランスフォーマーモデルを微調整するための類似性または感情に基づくテキストのペアで実現されます。詳細については、Hugging Face の「[Training and Finetuning Embedding Models with Sentence Transformers v3](https://huggingface.co/blog/train-sentence-transformers)」を参照してください。
[Amazon SageMaker Ground Truth ](https://docs.aws.amazon.com/sagemaker/latest/dg/sms.html)を使用して、ラベル付きの高品質のトレーニングデータセットを構築できます。Ground Truth のラベル付きデータセット出力を使用して、独自のモデルをトレーニングできます。出力を Amazon SageMaker AI モデルをトレーニングデータセットとして使用することもできます。名前付きエンティティ認識、単一ラベルテキスト分類、マルチラベルテキスト分類の詳細については、Amazon SageMaker AI ドキュメントの「[Ground Truth を使用したテキストラベル付け](https://docs.aws.amazon.com/sagemaker/latest/dg/sms-label-text.html)」を参照してください。
ファインチューニングの詳細については、このガイド[ヘルスケアにおける大規模言語モデルのファインチューニング](fine-tuning.md)の「」を参照してください。
## LLM の選択
[Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html) は、高性能 LLMs。詳細については、[「Amazon Bedrock でサポートされている基盤モデル](https://docs.aws.amazon.com/bedrock/latest/userguide/models-supported.html)」を参照してください。Amazon Bedrock のモデル評価ジョブを使用して、複数の出力からの出力を比較し、ユースケースに最適なモデルを選択できます。詳細については、Amazon [Bedrock ドキュメントの「Amazon Bedrock 評価を使用して最もパフォーマンスの高いモデルを選択する](https://docs.aws.amazon.com/bedrock/latest/userguide/model-evaluation.html)」を参照してください。
一部の LLMsでは、医療ドメインデータに関するトレーニングが制限されています。ユースケースで Amazon Bedrock がサポートしていない LLM または LLM の微調整が必要な場合は、[Amazon SageMaker AI ](https://docs.aws.amazon.com/sagemaker/latest/dg/whatis.html)の使用を検討してください。SageMaker AI では、微調整された LLM を使用するか、医療ドメインデータでトレーニングされたカスタム LLM を選択できます。
次の表LLMs の一覧です。
|
|
| LLM | タスク | ナレッジ | アーキテクチャ |
| --- |--- |--- |--- |
| [BioBERT](https://github.com/dmis-lab/biobert) | 情報の取得、テキスト分類、および名前付きエンティティの認識 | PubMed からの抜粋、PubMedCentral からの全文記事、一般的なドメイン知識 | エンコーダー |
| [ClinicalBERT](https://github.com/kexinhuang12345/clinicalBERT) | 情報の取得、テキスト分類、および名前付きエンティティの認識 | 電子ヘルスレコード (EHR) システムから 3,000,000 を超える患者レコードを含む大規模な多施設データセット | エンコーダー |
| [ClinicalGPT](https://huggingface.co/medicalai/ClinicalGPT-base-zh) | 要約、質疑応答、テキスト生成 | 医療記録、ドメイン固有の知識、マルチラウンド対話の相談など、広範で多様な医療データセット | デコーダー |
| [GatorTron-OG](https://catalog.ngc.nvidia.com/orgs/nvidia/teams/clara/models/gatortron_og) | 要約、質疑応答、テキスト生成、情報取得 | 臨床ノートと生体医学の文献 | エンコーダー |
| [Med-BERT](https://github.com/ZhiGroup/Med-BERT) | 情報の取得、テキスト分類、および名前付きエンティティの認識 | 医療テキスト、臨床ノート、研究論文、医療関連ドキュメントの大規模なデータセット | エンコーダー |
| [Med-PaLM](https://sites.research.google/med-palm/) | 医療目的の質疑応答 | 医療テキストとバイオメディカルテキストのデータセット | デコーダー |
| [medAlpaca](https://github.com/kbressem/medAlpaca) | 質問への回答と医療対話タスク | 医療フラッシュカード、Wiki、ダイアログデータセットなどのリソースを含むさまざまな医療テキスト | デコーダー |
| [BiomedBERT](https://huggingface.co/microsoft/BiomedNLP-BiomedBERT-base-uncased-abstract-fulltext) | 情報の取得、テキスト分類、および名前付きエンティティの認識 | PubMed および PubMedCentral からの全文記事から排他的に抽象化 | エンコーダー |
| [BioMedLM](https://github.com/stanford-crfm/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 ガードレール](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html)を使用できます。