タグ | データセット | メトリクス | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
この論文では、大規模言語モデル (LLM) のコンテキスト ウィンドウを 200 万トークンを超えて拡張する方法である LongRoPE を紹介します。
重要なアイデアは次のとおりです。
位置埋め込みにおける 2 つの形式の不均一性を特定して利用し、補間中の情報損失を最小限に抑えます。これにより、微調整せずに 8 倍のコンテキスト拡張が可能になります。
非常に大きなコンテキストを直接微調整するのではなく、256k の微調整による効率的なプログレッシブ拡張戦略を使用して、2048k コンテキストに到達します。
短いコンテキストの埋め込みを調整して、元のウィンドウ サイズ内でパフォーマンスを回復します。
この手法は LLaMA2 と Mistral に適用されます。さまざまなタスクにわたる実験により、4k から 2048k のコンテキスト長までパフォーマンスを維持する上で LongRoPE の有効性が実証されました。
Transformer アーキテクチャは、自己注意による 2 次計算の複雑さと、トレーニング時に見えないトークンの位置への一般化の欠如に悩まされています。セルフ アテンションの計算を大規模なコンテキストに拡張するために、RoPE、AliBi、アテンション シンクなどのさまざまな方法が提案されています。それにもかかわらず、これらのソリューションのいずれも、モデルの精度を維持しながら数百万のトークンを含むコンテキストに効果的に拡張することはできません。 。
このペーパーでは、LLM のコンテキスト ウィンドウを 200 万トークン以上に拡張する新しい技術 LongRoPE を紹介します。
LongRoPE は、プログレッシブ拡張戦略を利用して、まれで入手が困難な非常に長いテキストを直接微調整する必要なく、2048k コンテキスト ウィンドウを達成します。この戦略は、事前トレーニングされた LLM での 256k 拡張から始まり、その後、この長さで微調整が続きます。
元の(短い)コンテキスト ウィンドウでの潜在的なパフォーマンス低下に対処するために、LongRoPE は拡張 LLM で RoPE 再スケール係数をさらに調整し、位置補間を最小限に抑える検索アルゴリズムを使用して 256k の微調整された LLM で 4k および 8k コンテキスト ウィンドウにスケールダウンします。長さ 8k 未満のシーケンスの推論中に、RoPE はこれらの細心の注意を払って検索された再スケール係数で更新されます。
さまざまな LLM と長いコンテキストを必要とするタスクにわたるテストにより、LongRoPE の有効性が検証されました。この方法は、4k から 2048k トークンまでの評価長にわたって低い混乱度を大幅に維持し、パスキー取得で 90% 以上の精度を達成し、4096 コンテキスト ウィンドウ内で標準ベンチマークに匹敵する精度を実現します。
構造の変更とそれがモデルのパフォーマンスに与える影響について詳しく説明します。
LongRoPEモデル アーキテクチャは、大規模言語モデル (LLM) のコンテキスト ウィンドウを 200 万以上のトークンに拡張し、従来の Transformer アーキテクチャの制限に対処するように設計されています。重要な革新は、プログレッシブ拡張戦略と位置埋め込みの調整にあります。
主要なコンポーネントは次のとおりです。
class RoPEPositionalEncoding ( nn . Module ):
def __init__ ( self , d_model , max_len = 1000000 , base = 10000 ):
super (). __init__ ()
self . d_model = d_model
self . max_len = max_len
self . base = base
self . theta = torch . tensor ([ base ** ( - 2 * ( i // 2 ) / d_model ) for i in range ( d_model )])
def forward ( self , positions ):
angles = positions . unsqueeze ( - 1 ) * self . theta
sin_cos = torch . stack ([ angles . cos (), angles . sin ()], dim = - 1 )
return sin_cos . view ( * sin_cos . shape [: - 2 ], - 1 )
def non_uniform_interpolation ( pos_embed , extension_ratio , lambda_factors , n_hat ):
d_model = pos_embed . shape [ - 1 ]
interpolated_pos = pos_embed . clone ()
for i in range ( d_model // 2 ):
mask = torch . arange ( pos_embed . shape [ - 2 ], device = pos_embed . device ) < n_hat
scale = torch . where ( mask , torch . ones_like ( pos_embed [..., 0 ], device = pos_embed . device ),
1 / ( lambda_factors [ i ] * extension_ratio ))
interpolated_pos [..., 2 * i ] *= scale
interpolated_pos [..., 2 * i + 1 ] *= scale
return interpolated_pos
def progressive_extension ( model , data , base_length , target_length , population_size , num_mutations , num_crossovers , max_iterations ):
# Extend to 128k
lambda_factors_128k , n_hat_128k = search_lambda_factors ( model , data , 128000 / base_length , population_size , num_mutations , num_crossovers , max_iterations )
model = fine_tune ( model , data , 128000 , lambda_factors_128k , n_hat_128k , steps = 400 )
# Extend to 256k
lambda_factors_256k , n_hat_256k = search_lambda_factors ( model , data , 256000 / base_length , population_size , num_mutations , num_crossovers , max_iterations )
model = fine_tune ( model , data , 256000 , lambda_factors_256k , n_hat_256k , steps = 600 )
# Extend to target length
if target_length > 256000 :
final_lambda_factors , final_n_hat = search_lambda_factors ( model , data , target_length / base_length , population_size // 2 , num_mutations // 2 , num_crossovers // 2 , max_iterations // 2 )
model . lambda_factors [ "2048k" ] = final_lambda_factors
model . n_hat [ "2048k" ] = final_n_hat
return model , final_lambda_factors , final_n_hat , lambda_factors_256k , n_hat_256k
このアーキテクチャは、事前トレーニングされた LLM から始まり、そのコンテキスト ウィンドウを段階的に拡張します。最初に、モデルは 256k トークンのコンテキスト長を処理できるように微調整されます。この進歩的なアプローチにより、非常に長いテキストを直接微調整する必要がなくなります。これはまれであり、処理に計算コストがかかります。コンテキストの長さを徐々に長くすることで、モデルはより長いシーケンスに効果的に適応できます。
さまざまなコンテキスト長にわたってパフォーマンスを維持するために、LongRoPE は Rotary Positional Embeddings (RoPE) を調整します。このモデルは、位置埋め込みの不均一性を特定して利用し、補間中の情報損失を最小限に抑えます。これにより、微調整を必要とせずに 8 倍のコンテキスト拡張が可能になります。さらに、モデルは検索アルゴリズムを使用して、256k の微調整された LLM で短いコンテキスト (たとえば、4k および 8k トークン) の最適な再スケール係数を見つけます。これらの調整により、元のコンテキスト ウィンドウ サイズ内でもモデルが高いパフォーマンスを維持できるようになります。
このアーキテクチャには、増加したコンテキスト長を効率的に処理するために、いくつかの構造上の変更が組み込まれています。
レイヤーのスケーリング: コンテキスト ウィンドウの拡大に伴う安定性とパフォーマンスを確保するために、レイヤーのスケーリングが調整されます。
メモリ管理: システム リソースを圧迫することなく、大きなコンテキスト サイズを処理するために、効率的なメモリ管理手法が採用されています。
アテンション メカニズム: 強化されたアテンション メカニズムが統合されており、拡張されたコンテキストであってもモデルが入力シーケンスの関連部分に焦点を当てることができます。
トークンごとのアテンション: トークン間のコンテキスト上の関係をキャプチャするためにトークンごとのアテンション メカニズムが導入され、モデルが入力の意味論的な意味をよりよく理解できるようになります。
実験では、LongRoPE が 4k から 2048k トークンまでの評価長にわたって低い混乱度を維持し、長いコンテキストを必要とするタスクで高い精度を達成することが実証されています。これにより、コンテキスト内学習、長い文書の要約、数回の学習など、さまざまなアプリケーションに適しています。
詳細については、こちらの論文全文を参照してください。
LongRoPE の機能を可能にするコーディングと運用の詳細についての洞察。これには、主要なコンポーネントを示すスニペットまたは疑似コードが含まれる場合があります。
詳細については、論文を参照してください。
テキスト分析から広範なドキュメントの生成まで、さまざまなアプリケーションで LongRoPE を活用する方法を示す包括的な例。
# Example usage
data_path = "path/to/your/dataset"
d_model = 512
n_heads = 8
num_layers = 6
base_length = 4096
target_length = 2048 * 1024
data = load_data ( data_path )
model = LongRoPEModel ( d_model , n_heads , num_layers , base_length )
model = model . extend_context ( data , target_length )
input_ids = torch . randn ( 2 , target_length , d_model )
output = model ( input_ids )
print ( output . shape ) # Expected shape: (batch_size, target_length, d_model)
カスタム データセット トレーニング
カスタム データセットでトレーニングするには:
ハイパーパラメータの調整 LongRoPE のパフォーマンスはハイパーパラメータの影響を受ける可能性があります。調整する主なパラメータは次のとおりです。
ラムダ因子検索のpopulation_size
、 num_mutations
、およびnum_crossovers
トレーニングの安定性を高めるためにgradient_accumulation_steps
微調整するための学習率とスケジューラ パラメーター
LongRoPE を実装すると、次のような結果が得られます。
困惑:
パスキーの取得精度:
正確さ:
ベースラインモデルとの比較:
@article { ding2024longrope ,
title = { LongRoPE: Extending LLM Context Window Beyond 2 Million Tokens } ,
author = { Ding, Yiran and Zhang, Li Lyna and Zhang, Chengruidong and Xu, Yuanyuan and Shang, Ning and Xu, Jiahang and Yang, Fan and Yang, Mao } ,
journal = { arXiv preprint arXiv:2402.13753 } ,
year = { 2024 }
}
注: このリポジトリは進行中の作業であり、まだ運用環境で使用する準備ができていません。詳細については、論文を参照してください。