翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
蒸留用トレーニングデータセットを準備する
モデルカスタムジョブを開始する前に、最低限のトレーニングデータセットを必要があります。カスタムモデルの入力データセットを準備するには、各行がレコードに対応する JSON オブジェクトである .jsonl ファイルを作成します。作成するファイルは、選択したモデルの蒸留とモデルの形式に準拠する必要があります。また、ファイル内のレコードがサイズ要件を満たしている必要があります。
入力データをプロンプトとして指定します。Amazon Bedrock は入力データを使用して教師モデルからのレスポンスを生成し、生成されたレスポンスを使用して生徒モデルをファインチューニングします。Amazon Bedrock が使用する入力の詳細と、ユースケースに最適なオプションの選択については、「Amazon Bedrock Model Distillation の仕組み」を参照してください。入力データセットを準備するには、いくつかのオプションがあります。
注記
Amazon Nova モデルには、蒸留に関するさまざまな要件があります。詳細については、「Amazon Nova モデルの蒸留」を参照してください。
「Amazon Bedrock Model Distillation でサポートされているモデルとリージョン」にリストされているモデルがサポートするのは、text-to-text モダリティのみです。
モデルの蒸留中に、Amazon Bedrock は合成データセットを生成します。このデータセットは、特定のユースケースに合わせて生徒モデルをファインチューニングするために使用されます。詳細については、「Amazon Bedrock Model Distillation の仕組み」を参照してください。
入力プロンプトを必要なユースケースに合わせて整形することで、合成データ生成プロセスを最適化できます。例えば、蒸留モデルのユースケースが検索拡張生成 (RAG) の場合、プロントで使用する形式は、エージェントユースケースに重点を置くモデルの場合とは異なります。
以下は、RAG またはエージェントのユースケースに合わせて入力プロンプトをフォーマットする方法の例です。
プロンプトを収集し、.jsonl ファイル形式で保存します。JSONL の各レコードには、次の構造を使用する必要があります。
-
schemaVersionフィールドを含めます。値はbedrock-conversion-2024である必要があります。 -
[オプション] モデルに割り当てられたロールを示すシステムプロンプトを含めます。
-
messagesフィールドに、モデルに提供される入力プロンプトを含むユーザーロールを追加します。 -
[オプション]
messagesフィールドに、必要なレスポンスを含むアシスタントロールを追加します。
Anthropic モデルと Meta Llama モデルは、シングルターン会話型プロンプトのみをサポートします。つまり、ユーザープロンプトは、1 つのみです。Amazon Nova モデルは、マルチターンの会話をサポートしているため、単一のレコード内で複数のユーザーとアシスタントのやり取りを提供できます。
形式の例:
{ "schemaVersion": "bedrock-conversation-2024", "system": [{ "text": "A chat between a curious User and an artificial intelligence Bot. The Bot gives helpful, detailed, and polite answers to the User's questions." }], "messages": [{ "role": "user", "content": [{ "text": "why is the sky blue" }] }, { "role": "assistant", "content": [{ "text": "The sky is blue because molecules in the air scatter blue light from the Sun more than other colors." }] } ] }}
データセットを検証する
蒸留ジョブを実行する前に、Python スクリプト
蒸留ジョブを作成するときに、CloudWatch Logs 呼び出しログからの既存の教師応答を Amazon Bedrock でトレーニングデータとして使用できます。Amazon Bedrock の場合、呼び出しログはモデル呼び出しの詳細なレコードです。
モデル蒸留で呼び出しのログ記録を使用するには、モデル呼び出しのログ記録をオンに設定し、モデル呼び出しオペレーションの 1 つを使用し、ログの保存先として Amazon S3 バケットを設定していることを確認します。モデル蒸留ジョブを開始する前に、ログにアクセスするための Amazon Bedrock アクセス許可を付与する必要があります。呼び出しログの設定の詳細については、「Amazon CloudWatch Logs を使用してモデル呼び出しをモニタリングする」を参照してください。
このオプションを使用すると、Amazon Bedrock でプロンプトのみを使用するか、呼び出しログからのプロンプトと応答のペアを使用するかを指定できます。Amazon Bedrock でプロンプトのみを使用する場合、Amazon Bedrock では教師モデルから高品質の多様な応答を生成するために所有データ合成テクニックが追加されることがあります。Amazon Bedrock でプロンプトと応答のペアを使用する場合、Amazon Bedrock では教師モデルからの応答を再生成されません。Amazon Bedrock では、呼び出しログからの応答を直接使用して、生徒モデルをファインチューニングします。
重要
生徒モデルをファインチューニングするために、最大 15,000 個のプロンプトまたはプロンプトと応答のペアを Amazon Bedrock に提供できます。特定の要件を満たすように生徒モデルを確実にファインチューニングするには、次の実践を強くお勧めします。
-
Amazon Bedrock でプロンプトのみを使用する場合は、すべてのモデルから少なくとも 100 個のプロンプトと応答のペアが生成されていることを確認します。
-
Amazon Bedrock で呼び出しログからの応答を使用するには、呼び出しログに、選択した教師モデルと完全に一致するモデルから生成されたプロンプトと応答のペアが少なくとも 100 個あることを確認します。
必要に応じて、いずれかのモデル呼び出しオペレーションを使用して呼び出しログのプロンプトと応答のペアにリクエストメタデータを追加し、後でそれを使用してログをフィルタリングできます。Amazon Bedrock では、フィルタリングされたログを使用して生徒モデルをファインチューニングできます。
複数のリクエストメタデータを使用してログをフィルタリングするには、1 つのブール演算子 (AND、OR、または NOT) を使用します。オペレーションを組み合わせることはできません。単一のリクエストメタデータのフィルタリングには、ブール演算子 NOT を使用します。
モデル蒸留で呼び出しログのプロンプトと応答にリクエストメタデータを追加する
モデル呼び出しのログ記録は、Amazon Bedrock で使用されるすべての呼び出しの呼び出しログ、モデル入力データ (プロンプト)、モデル出力データ (応答) などを収集します。ログ記録を有効にしている場合は、Invoke または Converse の API オペレーションを通じて Amazon Bedrock 基盤モデルを操作するたびにログを収集できます。Amazon Bedrock で呼び出しログからのプロンプトと関連する応答を使用して生徒モデルをファインチューニングする場合は、Amazon Bedrock にこれらのログへのアクセスを付与する必要があります。モデルによって既に生成されている応答を使用すると、より迅速に生徒モデルをファインチューニングできます。呼び出しログからの応答を使用すると、モデル蒸留のコスト効率も向上しますが、Amazon Bedrock 所有データ合成テクニックは追加されないため、よりパフォーマンスの高い蒸留モデルになる可能性があります。
呼び出しログを使用すると、Amazon Bedrock でモデル蒸留に使用するプロンプトと応答のペアを特定できます。これらのプロンプトと応答のペアは、特定のユースケースで使用できます。蒸留に使用するプロンプトと応答のペアを特定できるようにするには、モデルを呼び出すとき、または Converse API オペレーションを使用するときに、プロンプトと応答のペアにリクエストメタデータ文字列を追加する必要があります。リクエストメタデータは、" の形式で提供されます。priority" :
"High"
Invoke または Converse の API オペレーションを使用してモデルを操作し続けると、インタラクションとリクエストメタデータが呼び出しログに記録されます。リクエストメタデータを示す InvokeModel 呼び出しからの呼び出しログの例を次に示します。
{ "schemaType": "ModelInvocationLog", "schemaVersion": "1.0", "timestamp": "2024-09-11T17:16:18Z", "accountId": "XXXXX", "identity": { "arn": "arn:aws:sts::XXXXXXX:assumed-role/Admin/XXXXXX" }, "region": "us-east-1", "requestId": "7ee514f3-9eff-467c-af75-8fd564ce58e5", "operation": "InvokeModel", "modelId": "meta.llama3-1-405b-instruct-v1:0", "input": { "inputContentType": "application/json", "inputBodyJson": { "prompt": "story of two dogs", "max_tokens_to_sample": 300 }, "inputTokenCount": 13 }, "output": { "outputContentType": "application/json", "outputBodyJson": { "type": "completion", "completion": " Here is a story about two dogs:\n\nRex and Charlie were best friends who lived next door to each other. Every morning, their owners would let them out into the backyard to play. Rex was a golden retriever with long, shaggy fur. He loved to run and chase sticks. Charlie was a corgi with short legs and a big smile. He was happy just sniffing the grass and rolling around. \n\nThe two dogs spent every day playing together. Rex would grab a stick and bring it over to Charlie, wagging his tail excitedly. Charlie would take the other end of the stick in his mouth and they'd have a friendly game of tug-of-war. After tiring themselves out, they'd flop down in the warm sunshine for a nap. \n\nAt lunchtime, their owners would call them in for food. Rex would gobble up his kibble hungrily while Charlie ate his at a more leisurely pace. After lunch, it was right back outside for more playtime. The afternoon sunbeams would light up their fur as they chased each other around the yard. \n\nWhen it started getting late, their owners called them in for the night. Rex and Charlie would head inside, tired but happy after another fun day of play. After slurping up fresh water from their bowls, they'd curl up on their beds, Rex's fluffy golden tail tucked over his nose and little", "stop_reason": "max_tokens", "stop": null }, "outputTokenCount": 300 }, "requestMetadata": { "project": "CustomerService", "intent": "ComplaintResolution", "priority": "High" } }
モデル蒸留ジョブを開始するときに、呼び出しログを入力データソースとして指定できます。Amazon Bedrock コンソール、 API、または AWS SDK を使用して AWS CLI、モデル抽出ジョブを開始できます。
リクエストメタデータを提供するための要件
リクエストメタデータは、次の要件を満たしている必要があります。
-
JSON
key:value形式で提供されている。 -
キーと値のペアは、最大 256 文字の文字列である必要がある。
-
最大 16 個のキーと値のペアを指定する。
リクエストメタデータのフィルターの使用
リクエストメタデータにフィルターを適用して、生徒モデルをファインチューニングするために蒸留に含めるプロンプトと応答のペアを選択します。例えば、「project」:「CustomerService」および「priority」:「High」のリクエストメタデータを持つものだけを含める場合があるでしょう。
複数のリクエストメタデータを使用してログをフィルタリングするには、1 つのブール演算子 (AND、OR、または NOT) を使用します。オペレーションを組み合わせることはできません。単一のリクエストメタデータのフィルタリングには、ブール演算子 NOT を使用します。
モデル蒸留ジョブを開始するときに、入力データソースとして呼び出しログを指定し、プロンプトと応答のペアを選択するために使用するフィルターを指定できます。Amazon Bedrock コンソール、 API、または AWS SDK を使用して AWS CLI、モデル抽出ジョブを開始できます。詳細については、「Amazon Bedrock でモデル蒸留ジョブを送信する」を参照してください。
データセットを検証する
蒸留ジョブを実行する前に、Python スクリプト