大規模言語モデル（LLM）は、人工知能の分野でますます重要な役割を果たしている。LLMをより良く理解し応用するためには、その中核となる概念についてより深く理解する必要がある。本稿では、「トークン」、「最大出力長」、「文脈長」という3つの主要概念に焦点を当て、読者がLLM技術をより効果的に活用できるよう、理解の障壁を取り除く手助けをする。
トークン：LLMの基本処理ユニット
トークン トークンは、自然言語テキストを処理するための大規模言語モデル（LLM）の基本単位であり、モデルが認識して処理できる最小の意味単位として理解することができる。 トークンは「単語」や「フレーズ」に大雑把に類似させることができるが、より正確には、モデルがテキスト分析と生成の基礎とするビルディングブロックと表現される。
実際には、トークンと単語数の間には一定の換算関係がある。 一般的には
- 1 英字 ≒ 0.3 トークン
- 1漢字≒0.6トークン
したがって、我々は次のことができる。概算属原則として漢字は トークン.
上の図に示すように、LLMにテキストを入力すると、モデルはまずテキストをトークン列にスライスし、次にこれらのトークン列を処理して期待する出力を生成する。 次の図は、テキストのトークン化のプロセスを鮮明に示している：
最大出力長（出力限界）：モデルの単一テキスト生成の上限値
には ディープシーク シリーズのモデルを例にとると、異なるモデルが最大出力長に制限を設けていることがわかる。
以上。ディープシーク・チャット モデル対応 ディープシーク-V3 バージョンに対して ディープシーク・リーズナー モデルは次のようになる。 ディープシーク-R1 バージョン。 推論モデルR1と対話モデルV3はともに、最大出力長を 8K.
漢字1文字がトークン1個にほぼ等しいという近似変換関係を考慮する。8K の最大出力長は次のように解釈できる： このモデルは、1回の対話で最大約8000の漢字を生成することができる。.
最大出力長という概念は、比較的直感的で理解しやすい。これは、モデルが各回答で生成できるテキストの最大量を制限するものである。 この限界に達すると、モデルはそれ以上コンテンツを生成し続けることができなくなります。
コンテキストウィンドウ：モデルの記憶範囲。
コンテキストの長さは、技術分野では「コンテキストの長さ」とも呼ばれる。 コンテキスト・ウィンドウは、LLMの能力を理解するための重要なパラメーターである。 引き続き ディープシーク このモデルを例として説明する：
図に示すように、推論モデルも対話モデルもディープシーク な コンテキスト・ウィンドウ すべて 64K. だから64K のコンテキストの長さは具体的に何を意味するのか？
コンテキストの長さを理解するためには、まずその定義を明確にする必要がある。 コンテキストウィンドウとは、1回の推論セッションでラージ言語モデル（LLM）が処理できるトークンの最大数のこと。. この合計は2つの部分からなる：
(1) 入力セクションプロンプト、対話履歴、追加文書の内容など、ユーザーから提供されたすべての入力。
(2) 出力セクション: モデルが現在生成して返しているレスポンスの内容。
つまり、私たちがLLMと1回だけ対話する場合、私たちが質問を入力してからモデルが回答を返すまでの全過程を「1回の推論」と呼ぶ。 この推論の間、すべての入力と出力のテキストコンテンツ（トークンでカウントされる）の合計は、以下の値を超えてはならない。 コンテキスト・ウィンドウ の制限事項である。 ディープシーク モデルでは、この制限は 64K使用されている漢字の数は約6万字。
念のため言っておく。では、入力できる内容に制限はあるのでしょうか？ 答えはイエスである。 前述したように、モデルのコンテキスト長は64K、最大出力長は8Kである。 したがって、1回の対話において、入力内容の最大トークン数は、理論的には、コンテキスト長から最大出力長を引いたもの、つまり、64K - 8K = 56Kである。 まとめると、1回の質疑応答において、ユーザーは最大約56,000語を入力でき、モデルは最大約8,000語を出力できる。
マルチラウンド対話のためのコンテキスト処理メカニズム
実際には、LLMと複数ラウンドの対話を行うことが多い。 では、複数ラウンドの対話ではどのように文脈を扱うのでしょうか？ それは ディープシーク 例えば、複数ラウンドの対話を開始する場合、サーバー側はユーザーのダイアログコンテキストはデフォルトでは保存されません。. これは、次のことを意味する。新しい対話のリクエストごとに、ユーザーは対話の履歴を含むすべてのコンテンツをつなぎ合わせ、入力情報としてAPIに渡す必要がある。.
多ラウンド・ダイアログの仕組みをより分かりやすく説明するために、DeepSeek API を使用した多ラウンド・ダイアログの Python サンプル・コードを示します：
from openai import OpenAI
client = OpenAI(api_key="", base_url="https://api.deepseek.com")
#ラウンド1
messages = [{"role": "user", "content": "世界で一番高い山は？" }].
response = client.chat.completions.create(
model="deepseek-chat"、
メッセージ
)
messages.append(response.choices[0].message)
print(f "メッセージ ラウンド 1: {messages}")
#ラウンド2
messages.append({"role": "user", "content": "2番目は？" })
response = client.chat.completions.create(
model="deepseek-chat"、
メッセージ
)
messages.append(response.choices[0].message)
print(f "メッセージラウンド2: {messages}")
最初の対話リクエストの際にAPIに渡されるmessagesパラメータの内容は以下の通り：
[
{ "role": "user", "content": "世界で一番高い山は？" }.
]
2回目の対話のリクエストに必要：
(1)前回の対話ラウンドのモデルの出力を メッセージ リストの最後；
(2) ユーザーの新しい質問を メッセージ リストの最後。
つまり、2回目の対話では、APIに渡されるメッセージ・パラメーターには以下の内容が含まれることになる：
[
{ "role": "user", "content": "世界で一番高い山は？" }, { "role": "assistant", "content": "世界で一番高い山はエベレストです。｝
{"role": "assistant", "content": "世界で一番高い山はエベレストです。"}, {"role": "user", "content": "2番目は何ですか。
{役割": "ユーザー", "内容": "2番目は何ですか？｝
}
従って、多ラウンド対話の本質は、次のようなものを組み合わせることにある。過去の対話記録（ユーザー入力とモデル出力を含む）は、最新のユーザー入力の前にスプライスされ、スプライスされた完全な対話が一括してLLMに提出される。
つまり、複数ラウンドの対話シナリオでは、各ラウンドのコンテキストウィンドウは常に64Kのままではなく、ラウンド数が増えるにつれて減少します。 例えば、最初のラウンドの対話の入力と出力が合計32Kトークンを使用する場合、2番目のラウンドの対話では、使用可能なコンテキストウィンドウは32Kにしかならない。 この原理は、上で分析したコンテキストの長さの制限と一致する。
このメカニズムによれば、各ラウンドの対話のインプットとアウトプットが非常に長いとすると、モデルの限界を超えるには数ラウンドの対話が必要ではないか？ しかし実際には、対話が何ラウンドも続いても、モデルは適切に応答できるようだ。
それはとてもいい質問だ。もうひとつの重要な概念、"コンテクストの切り捨て "につながる。
文脈の切り捨て：非常に長いダイアログを扱うための戦略
LLMベースの製品（DeepSeek、Wisdom Spectrumなど）を使用する場合、サービスプロバイダーは通常、コンテキストウィンドウのハードリミットをユーザーに直接公開せず、Context Truncationを使用する。Context Truncation戦略は、非常に長いテキストの処理を実現するために使用される。
例えば、このモデルがネイティブで64Kのコンテキストウィンドウをサポートしているとする。 ユーザーが複数回の対話で64Kまたはそれに近い値を蓄積した後、ユーザーが新しいリクエスト(例えば2Kトークンのリクエスト)を開始した場合、コンテキストウィンドウの制限を超えることになる。 この場合、通常サーバーは最新の 64K トークン（最新の入力を含む）は保持され、対話履歴の最も古い部分は破棄される**。 ユーザーにとって、最新の入力は保持され、最も古い入力（あるいは出力）はモデルによって「忘れ去られる」。**
このため、何度も対話を繰り返すと、モデルから正常な返答が得られても、モデルが「記憶喪失」になることがある。 コンテクスト・ウィンドウの容量には限りがあるため、モデルは過去の対話情報をすべて記憶することはできず、「最近のことは覚えていて、昔のことは忘れる」ことしかできないのだ。
強調しなければならないのは「コンテキストの切り捨て」は、モデル自体に内在する機能ではなく、エンジニアリング・レベルで実装される戦略である**。 サーバー側がバックグラウンドでこれを行うため、ユーザーは通常、使用時に切り捨て処理の存在を認識することはない。**
まとめると、コンテキストの長さ、最大出力長、コンテキストの切り捨てについて、次のような結論が得られる：
- コンテキストウィンドウ（例えば64K）は、モデルが一つのリクエストを処理するためのハードリミットである。トークンの入力と出力の総数は、この制限を超えてはならない。
- 複数ラウンドのダイアログにおける非常に長いテキストの、文脈に応じた切り捨てポリシーによるサーバーサイドでの管理複数ラウンドの対話が可能 コンテキスト・ウィンドウ しかし、これはモデルの長期記憶容量を犠牲にすることになる。
- コンテクスト・ウィンドウの制限は、通常、サービス・プロバイダーがコストをコントロールしたり、リスクを軽減したりするための戦略である。モデル自体の技術的能力はまったく同じではない。
モデルパラメータの比較：OpenAIとAnthropic
最大出力長とコンテキスト長のパラメータ設定は、モデルベンダーによって異なる。 次の図は、OpenAIとAnthropicを例に、いくつかのモデルのパラメータ設定を示しています：
図中、"Context Tokens "はコンテキストの長さを表し、"Output Tokens "は最大出力長を表す。
技術的原則：制限の背後にある理由
なぜLLMは最大出力長やコンテキスト長に制限を設けているのですか？ 技術的な観点からは、これはモデル・アーキテクチャと計算資源に関する制約が関係している。 つまり、コンテキストウィンドウの制限は、以下の重要な要素によって決定される：
(1) ポジションコードの範囲： 変圧器 このモデルは、各トークンに位置情報を割り当てるために位置エンコーディング（RoPE、ALiBiなど）に依存しており、位置エンコーディングの設計範囲は、モデルが扱える最大シーケンス長を直接決定する。
(2) 自己アテンション・メカニズムの計算それぞれの新しいトークンを生成するとき、モデルはそのトークンと過去のすべてのトークン （入力と生成された出力の両方）との間の注意の重みを計算する必要がある。 したがって、シーケンスの全長は厳しく制限される。 さらに、KV キャッシュのメモリ使用量はシーケンスの全長と正の相関があり、コンテキス トウィンドウの長さを超えるとメモリオーバーや計算エラーが発生する可能性がある。
典型的なアプリケーション・シナリオと対応策
最大出力長および文脈長という概念と、その背後にある技術的原理を理解することは極めて重要である。 この知識を習得した後、ユーザーは、大規模モデルツールを使用する際の対応戦略を策定し、その使用の効率と効果を高めるべきである。 以下に、いくつかの典型的な適用シナリオを列挙し、それに対応する対応策を示す：
- 短い入力＋長い出力
- アプリケーションシナリオユーザーは、少額のトークン（例えば1K）を入力し、記事やストーリーなどの長編コンテンツを生成するモデルを求めます。
- パラメータ設定APIコール時に max_tokens パラメータをより大きな値に設定する。 63,000 (で入力したのと同じ数のメダルを入力してください）。 max_tokens 以下 コンテキスト・ウィンドウ 例えば、1K + 63K ≤ 64K)。
- 潜在的リスクモデル出力は、品質チェックのため早期に終了することがある（例：過度の繰り返し、微妙な単語が含まれているなど）。
- 長い入力＋短い出力
- アプリケーションシナリオユーザーは長い文書（例えば60Kトークン）を入力し、それを要約し、情報を抽出するなどして、短い出力を生成するようモデルに依頼する。
- パラメータ設定を設定できます。 max_tokens パラメータを小さい値に設定する。 4,000 (例：60K + 4K ≤ 64K）。
- 潜在的リスクモデルが実際に必要とする出力トークンの数が max_tokens 出力の完全性を確保するために入力文書が圧縮される場合（例えば、重要な段落が抽出される、冗長な情報が削減されるなど）、出力は圧縮される。
- 多ラウンドの対話管理
- 規則複数回の対話では、入力と出力のトークンの累積数が、以下の値を超えないように注意する必要がある。 コンテキスト・ウィンドウ を超えると切り捨てられる）。
- 典型例::
(1)ラウンド1の対話：ユーザーは10Kトークンを入力し、モデルは10Kトークンを出力し、20Kトークンを蓄積する。
(2)ラウンド2ダイアログ：ユーザー入力30Kトークン、モデル出力14Kトークン、累積64Kトークン。
(3)ラウンド3の対話：ユーザーは5Kトークンを入力し、サーバーは最も古い5Kトークンを切り捨て、最新の59Kトークンを保持する。 トークン 履歴に、新たに5Kトークンの入力を加え、合計64Kトークンとなる。
トークン、最大出力長、コンテキスト長という3つのコアコンセプトを理解し、具体的なアプリケーションシナリオに基づいて合理的な戦略を策定することで、LLM技術をより効果的に活用し、その潜在能力をフルに活用することができる。
日本語 
简体中文 
English 
Deutsch (Sie) 
Português do Brasil