0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ゼロから学ぶローカルLLM #7 コンテキストウィンドウとは? 長い文章を扱える仕組みを理解する

0
Posted at

はじめに

これまでの記事では、モデル、GPU・VRAM、量子化、推論エンジンなど、ローカルLLMを動かすために必要となる知識について整理してきました。

前回の記事では、LLMモデルを実際に動かす「推論エンジン」について整理しました。

今回は、LLMを利用しているとよく目にする「コンテキストウィンドウ」について整理していきます。

モデルについて調べていると、下記のような数字を目にすることがあります。

  • 8K
  • 32K
  • 128K

これらはモデルが一度に扱えるコンテキストの大きさを表しています。
コンテキストウィンドウについては以前の記事でも少し触れましたが、今回はもう少し詳しく、

  • コンテキストウィンドウとは何なのか
  • 8K・32K・128Kは何を表しているのか
  • トークンとはどのような関係なのか
  • 会話が長くなると何が起きるのか
  • コンテキストが大きければ性能も高いのか
  • KVキャッシュとは何なのか
  • なぜコンテキストが長くなるとメモリを使うのか
  • VRAMとはどのような関係なのか

といった内容を中心に整理していきます。

コンテキストウィンドウとは?

コンテキストウィンドウとは、簡単に言えばLLMが一度の推論で参照できる情報の範囲です。

LLMに質問するとき、モデルには現在入力した文章だけが渡されているわけではありません。
例えばチャット形式で、下記のような会話があったとします。

ユーザー:日本で一番高い山は?

AI:富士山です。

ユーザー:高さは?

最後の、

高さは?

という文章だけでは、何の高さを聞いているのか分かりません。
しかしLLMは、それまでの会話もコンテキストとして参照することで、

富士山の高さ

について質問されていると判断できます。
イメージを形にすると、下記のような関係になります。

コンテキストウィンドウ
┌────────────────────────────┐
│ ユーザー:日本で一番高い山は?       │
│ AI:富士山です。                   │
│ ユーザー:高さは?                 │
└────────────────────────────┘
              │
              ▼
             LLM
              │
              ▼
      「富士山の高さは3,776mです」

このように、LLMが回答を生成するときに参照できる情報の範囲がコンテキストウィンドウです。

コンテキストウィンドウはトークン数で表される

コンテキストウィンドウの大きさは、文字数ではなくトークン数で表されます。
以前の記事で、LLMは文章をそのまま扱うのではなく、トークンという単位へ分割して処理していることを整理しました。

モデルの説明には、下記のように記載されている場合があります。

8K context
32K context
128K context

このKは1,000を意味するため、大まかに整理すると下記のようになります。

8K   → 約8,000トークン
32K  → 約32,000トークン
128K → 約128,000トークン

つまり128Kのコンテキストウィンドウを持つモデルであれば、一度の推論で最大約128,000トークンまでの情報を扱えるということになります。

入力だけでなく出力も関係する

ここで注意したいのが、コンテキストウィンドウは単純に、

入力できる文章量

だけを表しているわけではないということです。
モデルや推論環境によって扱いは異なりますが、基本的には入力されたトークンと生成されるトークンを含めて考える必要があります。

例えばコンテキストウィンドウが8,000トークンだった場合、下記のような関係になります。

入力
6,000トークン

+

出力
2,000トークン

=

8,000トークン

入力でコンテキストウィンドウの大部分を使ってしまうと、その分だけ生成できる文章にも制約が出てきます。

そのためコンテキストウィンドウを見るときは「どれだけ入力できるか」だけではなく、入力と出力を含めてどの程度の情報を扱えるのかという視点が重要になります。

会話が長くなるとどうなる?

チャット形式でLLMを利用していると、会話は少しずつ長くなっていきます。
イメージを形にすると、下記のような流れになります。

1回目の会話
   ↓
2回目の会話
   ↓
3回目の会話
   ↓
4回目の会話
   ↓
……

会話を続けていくと、それまでの会話履歴もコンテキストとして扱われます。
非常に単純化すると、下記のような流れです。

会話が長くなる
      │
      ▼
コンテキストが増える
      │
      ▼
上限へ近づく

コンテキストウィンドウの上限を超える場合、利用しているアプリケーションや推論エンジンによっては、古い会話をコンテキストから外すなどの処理が必要になります。

つまりLLMが過去の会話を無制限に参照できるわけではありません。

コンテキストウィンドウは「記憶」ではない

ここは最初に勘違いしやすい部分だと思います。
コンテキストウィンドウが大きいモデルを見ると、

たくさん記憶できるモデル

のように感じます。

しかしコンテキストウィンドウは、LLMそのものの長期的な記憶ではありません。
あくまで、現在の推論で参照できる情報の範囲です。

大まかに整理すると、下記のような違いがあります。

コンテキスト
      │
      ▼
今回の推論で参照する情報


モデルのパラメータ
      │
      ▼
学習によって獲得した情報

会話を終了して新しいセッションを開始した場合、その会話内容をモデルそのものが新しく学習したわけではありません。

この「コンテキスト」と「モデルが持っている知識」の違いは、LLMを理解する上で重要になります。

コンテキストが大きいほど性能が高い?

では、コンテキストウィンドウが大きいモデルほど性能が高いのでしょうか。

必ずしもそうではありません。

例えば、下記のような2つのモデルがあったとします。

モデルA
コンテキスト:128K

モデルB
コンテキスト:32K

この場合でも、

モデルAの方が賢い

とは限りません。

コンテキストウィンドウが大きいということは、一度により多くの情報を扱えるということです。
モデルそのものの能力とは別の指標になります。

また、長いコンテキストを扱えるモデルであっても与えた情報すべてを同じ精度で理解し、必ず適切に利用できるとは限りません。

つまり、

コンテキストが大きい
        =
モデルの性能が高い

というわけではありません。

長いコンテキストは何に使える?

コンテキストウィンドウが大きいと、一度の推論でより多くの情報を渡せるようになります。
例えば下記のような用途が挙げられます。

  • 長い文章の要約
  • 大量のソースコードの解析
  • 長時間の会話
  • 複数の資料を使った質問
  • 長いログの解析

例えばソースコードをLLMに解析してもらう場合、イメージを形にすると下記のようになります。

小さいコンテキスト

ファイルA
   │
   ▼
LLM


大きいコンテキスト

ファイルA
ファイルB
ファイルC
ファイルD
   │
   ▼
LLM

このようにコンテキストウィンドウによって一度に渡せる情報量が変わります。
ローカルLLMを開発用途などで利用する場合にも、コンテキストウィンドウの大きさは重要な要素になります。

KVキャッシュとは?

ここから少し踏み込んで、コンテキストとメモリの関係について整理していきます。

LLMは文章を生成するとき、トークンを一つずつ生成していきます。
イメージを形にすると下記のような流れになります。

今日
 ↓
今日の
 ↓
今日の天気
 ↓
今日の天気は

このように、これまでのトークンを参照しながら次のトークンを生成します。
このとき、過去のトークンについて毎回すべての計算を最初からやり直すと非常に非効率です。

そこで利用されるのがKVキャッシュ(Key-Value Cache)です。

非常に単純化すると、下記のような仕組みです。

過去のトークン
      │
      ▼
計算結果を保存
      │
      ▼
KVキャッシュ
      │
      ▼
次のトークン生成時に再利用

一度計算した情報を保持して再利用することで、文章生成を効率化しています。

なぜコンテキストが長いとメモリを使う?

KVキャッシュには、これまで処理したトークンに関する情報が保存されます。
そのため、扱うトークン数が増えるほどKVキャッシュも大きくなります。

大まかに整理すると、下記のような違いがあります。

短いコンテキスト
      │
      ▼
保存する情報が少ない
      │
      ▼
KVキャッシュが小さい


長いコンテキスト
      │
      ▼
保存する情報が多い
      │
      ▼
KVキャッシュが大きい

つまりコンテキストウィンドウを大きくすると扱える情報量が増える一方で、推論時に必要となるメモリも増えていきます。

VRAMとの関係

以前の記事では、ローカルLLMではモデルを動かすためにVRAMが重要になることを整理しました。

VRAMはモデルのパラメータだけに使われるわけではありません。

推論時には下記などにも利用されます。

VRAM
 │
 ├─ モデル
 │
 ├─ KVキャッシュ
 │
 └─ 推論に必要なその他の領域

そのため、

モデルはVRAMに収まっている

からといって、必ずしも大きなコンテキストを設定できるとは限りません。
イメージを形にすると、下記のような関係になります。

モデル
   │
   ▼
VRAMを使用

+

長いコンテキスト
   │
   ▼
KVキャッシュが増える

=

さらにVRAMが必要

ここで、以前整理したGPU・VRAMの知識とコンテキストウィンドウの知識がつながってきます。

コンテキストウィンドウは大きければ良い?

コンテキストウィンドウを大きくすれば一度に多くの情報を扱えるようになります。

しかしその分だけ必要なメモリも増えていきます。

また、常に大量の情報をLLMへ渡せば良いというわけでもありません。

非常に単純化すると、下記のような考え方になります。

必要な情報
    │
    ▼
適切なコンテキスト量
    │
    ▼
LLMへ渡す

そのため利用できる最大値だけを見るのではなく、下記について考える必要があります。

  • 何をLLMにさせたいのか
  • どの程度の情報を扱うのか
  • どの程度のメモリを利用できるのか

ローカルLLMではモデル選びだけでなくコンテキストウィンドウも実行環境を考える上で重要な要素になります。

用語集

今回の記事で登場した用語を簡単に整理します。

用語 概要
コンテキスト LLMが現在の推論で参照する情報。プロンプトや会話履歴などが含まれる。
コンテキストウィンドウ LLMが一度の推論で扱えるコンテキストの範囲。主にトークン数で表される。
トークン LLMが文章を処理するときに利用する単位。
KVキャッシュ 過去のトークンについて計算した情報を保持し、次のトークン生成時に再利用する仕組み。
VRAM GPUが利用するメモリ。モデルだけでなくKVキャッシュなどにも利用される。

さいごに

コンテキストウィンドウについて理解するとモデルに記載されている8Kや32K、128Kといった数字が何を表しているのかが分かるようになります。

またコンテキストを大きくすれば良いというわけではなく、扱える情報量と必要なメモリのバランスを考えることも重要になります。

これまで学んできたトークンやVRAMの知識とも少しずつつながってきました。
ローカルLLMを適切に利用できるよう、引き続き理解を深めていきたいです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?