リソース/モデルのトレーニング/データ準備

設定

トークン上限とTrim

すべてのプロバイダーは、1つの学習サンプルに含めることができるトークン数に上限を設けています。上限を超える長い会話は、Trim(最も古いやり取りから削除)されるか、Drop(除外)されます。

第5章読了時間 2分参考文献 3件

概要

モデルはテキストをトークンとして読み込み、学習では各サンプルを1つのトークンシーケンスとして処理します。プロバイダーはサンプルあたりのトークン上限(1つの学習レコードに含めることができる最長のシーケンス)を設定しています。学習時にはトークンを読み込むだけでなく、すべての重みをどのように変更すべきかを計算するためのメモリも必要となるため、この上限は通常の使用におけるモデルのコンテキストウィンドウよりも小さく設定されることが一般的です。

ほとんどのサポートチャットは簡単に収まります。収まらないのは、長時間のトラブルシューティングのスレッド、誰かがログファイルを貼り付けた会話、または午後中続いたようなチャットです。これらについては、それぞれどう扱うかの判断が必要です。

仕組み

予算
record tokens = system prompt + every earlier turn + the target reply
fits          = record tokens ≤ per-example limit

rough estimate: tokens ≈ characters ÷ 4   (English text)

Trimは、ターゲットとなる回答から遡って処理します。システムプロンプトとターゲットは常に保持され、全体のサイズが上限に収まるまで、会話の最初から順にやり取りが削除されます。やり取りは、ユーザーのメッセージとそれに対する回答がセットで丸ごと削除されるため、質問が消えて回答だけが宙に浮いた状態でレコードが始まることはありません。

systemあなたは次のサポートアシスタントです…250 · 保持
user · asstやり取り1:アカウントの設定1,500 · トリミング済み
user · asstやり取り2:昨年のデータのインポート1,300 · トリミング済み
user · asstやり取り3:212行目でのインポート失敗1,200 · 保持
userでは、212行目はどのように修正すればよいですか?350 · 保持
assistant212行目の日付の形式が間違っています。次のように変更してください…600 · ターゲット(保持)
5,200トークンの会話と3,000トークンの制限の例です。トリミングでは、レコードが制限内に収まるまで最も古いやり取りから順に削除されるため、システムプロンプト、直近のコンテキスト、およびターゲット応答はそのまま保持されます。

なぜ最も古い部分から削除するのでしょうか。ほとんどのチャットにおいて、最も関連性の高いコンテキストは最新のものです。つまり、回答しようとしている質問、引用されたばかりのエラーメッセージ、アシスタントが最後に提案した内容などです。また、長い入力に関する研究(Liu et al., 2023)でも、モデルはコンテキストの中間に埋もれた情報よりも、最初と最後の情報をうまく活用することが示されています。そのため、短く絞り込まれたレコードは、トークン数の減少が示唆するほどには情報を失いません。

Dropはレコードを除外します。会話の初期部分が回答に不可欠な場合に使用します。例えば、ユーザーが最初のメッセージでアカウントの種類や重要な制約を述べており、ターゲットとなる回答がそれに依存している場合などです。このようなチャットをTrimしたバージョンは、実際には必要な情報がない状態で回答するようモデルに教えることになり、結果としてモデルに推測で答えるよう暗に学習させてしまいます。

Trim一般的 デフォルト#

レコードが上限に収まるまで最も古いやり取りを削除し、システムプロンプト、最新のコンテキスト、およびターゲットを保持します。データセット内のすべてのサンプルが維持されます。

Drop#

上限を超えるレコードを除外します。回答が長い会話の初期に提供された詳細に依存している場合や、影響を受けるレコードがごくわずかな場合に選択します。

具体例:5,200トークンのスレッドと3,000トークンの制限
  1. レコードには、250トークンのシステムプロンプト、1,500、1,300、1,200トークンの3つの過去のやり取り、ユーザーの質問(350)、およびターゲットの応答(600)が含まれています。合計5,200トークンです。
  2. やり取り1を削除:3,700トークン。まだ超過しています。
  3. やり取り2を削除:2,400トークン。制限内に収まり、600トークンの余裕があります。
  4. トレーニングに使用されるレコードには、システムプロンプト、やり取り3(インポートエラーが引用された箇所)、質問、および回答が保持されます。これらはすべて、ターゲットが実際に参照する内容です。
  5. もしユーザーがやり取り1で「旧プランを利用している」と発言し、回答がそれに依存していた場合、Drop(除外)を選択する方が安全だったと言えます。

カウントが概算である理由

モデルファミリーごとに独自のトークナイザーがあるため、同じ文でも、あるモデルでは20トークン、別のモデルでは24トークンになることがあります。したがって、学習前に表示されるトークン数は推定値です(英語の場合、平均して1トークンあたり約4文字です)。プロバイダーはファイルを受信した際に正確なカウントを行います。コード、数字、URL、および英語以外のテキストは、通常、通常の英語よりも1文字あたりのトークン数が多くなるため、データにこれらが多く含まれる場合は余裕を持たせてください。

よくある間違い

  • システムプロンプトがすべてのレコードでカウントされることを忘れること。600トークンのプロンプトは、会話に使えるトークンを600減らします。
  • 回答が冒頭の発言に依存しているチャットをTrimし、モデルがアカウント情報を捏造する理由を不思議に思うこと。
  • 推定値が正確であると思い込み、コードや数字が多いデータで上限ぎりぎりまで実行すること。
  • Trimされたレコード数を無視すること。その大半がTrimされている場合、データセットはより上限の高いモデルに適している可能性があります。

参考文献および関連資料

外部ソースは新しいタブで開きます。

  1. 01Lost in the Middle: How Language Models Use Long ContextsLiu et al., 2023 · arXiv · arxiv.orgモデルは、長い入力の中間にある情報よりも、最初と最後にある情報をよりうまく活用します。
  2. 02Prepare data for fine-tuning your modelsAmazon Bedrock User Guide · docs.aws.amazon.com複数のモデルにおける実際のサンプルあたりのトークン上限の比較。
  3. 03Prepare supervised fine-tuning data for Gemini modelsGoogle Cloud documentation · docs.cloud.google.comサイズ上限を含む、別のプロバイダーのデータセット要件。

専門家が数週間かける作業を数分に短縮します

Scalataがお客様のチーム、データ、および統制にどのように適合するかをご確認ください。

営業へのお問い合わせ