データセットが異なればスケーリング則も異なりますか?圧縮アルゴリズムを使用してそれを予測できます
一般に、ニューラル ネットワークのトレーニングに必要な計算が増えるほど、パフォーマンスが向上します。計算をスケールアップするときは、モデル パラメーターの数を増やすか、データ セットのサイズを増やすかを決定する必要があります。両方の要素を固定の計算予算内で比較検討する必要があります。 モデル パラメーターの数を増やす利点は、モデルの複雑さと表現能力が向上し、それによってトレーニング データの適合性が向上することです。ただし、パラメーターが多すぎると過剰適合が発生し、目に見えないデータに対するモデルのパフォーマンスが低下する可能性があります。 一方、データセットのサイズを拡張すると、モデルの汎化能力が向上し、過剰適合の問題が軽減されます。
パラメーターとデータを適切に割り当てることができる限り、固定されたコンピューティング予算の下でパフォーマンスを最大化できることをお伝えします。これまでの多くの研究では、ニューラル言語モデルのスケーリング則が調査されており、これらの研究では通常、パラメーターとトレーニング トークンの数は 1 対 1 に拡張されるべきであると結論付けられています。
ただし、以前の言語モデルのスケーリング則の研究は、分散したネットワーク テキストでトレーニングされた Transformer に基づいていました。これは非常に特殊なデータ分布であるため、当然のことながら、このような Web テキスト データ セットに基づいて取得されたスケーリング則は他の分布にも一般化できるのか、という疑問が生じます。
ネットワーク テキスト データの特定のケースのみを対象とした現在の言語モデル (チンチラなど) に加えて、その背後にはトレーニング データの属性に基づくより広範なスケーリング則があります。データ品質を向上させると言語モデルのパフォーマンスが大幅に向上する可能性があることを考慮すると、強化学習のスケーリング則はゲームの強度に応じて拡大する可能性があります。おそらく、現在の言語モデルのスケーリング則 (チンチラなど) はネットワーク テキスト データの特定のケースにのみ適用され、その背後にはトレーニング データの属性に基づいたより広範なスケーリング則があると想定できます。
それでは、トレーニングに使用されるトークン シーケンス データ セットのどのプロパティがニューラル スケーリング則の影響を受けやすいのでしょうか?言い換えれば、トレーニング プロセスに計算を最適に割り当てる方法を正確に予測したい場合、データのどのような特性を観察する必要があるのでしょうか。また、スケーリング則のデータ依存性は単なる理論的な問題なのでしょうか、それとも現実世界のデータセットにとっても重要なのでしょうか?
これらの問題を調査するために、AI データ会社 Reworkd の研究者である Rohan Pandey はいくつかの調査を行い、これらの質問に対する答えを得ました。さらに、彼は予測できる圧縮アルゴリズム gzip も提案しました。データの複雑さが拡張プロパティに及ぼす影響。
- 論文タイトル: gzip Predicts Data-dependent Scaling Laws
- 論文リンク: https://arxiv.org/pdf/2405.16684
彼の研究方法は次のとおりです。複雑さを制御するテキストデータの設定の下で、情報理論手法を使用して、スケーリング則のデータ依存性の理由を理解します。
彼が最終的に見つけた設定は、確率的文脈自由文法 (PCFG、1956 年にチョムスキーによって最初に提案) と呼ばれます。この設定は比較的自然で (自然言語、コードなどをモデル化できます)、制御可能な構文の複雑さを持ち、よく理解されている情報理論の原則に従っています。
実験では、PCFG の構文特性を調整することで、複雑さの異なる 6 つのデータセットを生成しました。データセットごとに、異なるサイズ (4.4M ~ 1.4B のパラメーター) の 6 つの言語モデルをトレーニングし、6 つの異なるトレーニング ステップ (100K ~ 100M トークン) でこれらの言語モデルの結果を記録しました。次に、スケーリング則を各データセットに当てはめたところ、スケーリング則のパラメーターが構文の複雑さに応じて意味のある変化を示すことがわかりました。形式文法におけるエントロピーに関する以前の研究に続き、複雑さの指標として、データセット内の各トークン シーケンスの圧縮率の中央値を使用しました。これは、gzip を使用して簡単に計算できます。
トレーニングデータの圧縮率が低下する(より複雑になる)につれて、スケーリング則計算の最適境界がパラメータ量からデータサイズに徐々にシフトすることがわかりました。次に、現実世界のコードと自然言語データセットの圧縮率を測定したところ、前者の方が圧縮性が高く、したがって異なるスケーリング則に従うと予測されることがわかりました。
PCFG の構文プロパティを通じてデータの複雑さを調整する
確率的文脈自由文法 (PCFG) は、自然言語の構文をモデル化するために使用できる計算言語学の基本ツールです。 PCFG は、生成ルール内の確率を関連付ける標準の文脈自由文法 (CFG) の拡張であり、それによって言語の曖昧さと変動性を定量化可能な方法で表現します。これらの文法は、各ノードが構文カテゴリを表し、各エッジが文の生成に使用される生成規則を表すツリーを生成します。 PCFG から文を生成する場合、ツリーのすべての葉ノードがエンドポイント (実際の語彙トークン) になるまで、適用された生成ルールのシーケンスが確率的にサンプリングされます。
PCFG の構文プロパティを制御して、テキスト データセットの複雑さを自然な方法で調整できます。具体的には、PCFG 作成関数が受け入れることができるパラメーターには、エンドポイントの数、非エンドポイントのデータ、生成ルールの右側の最大長、および非エンドポイントに許可される生成ルールの最大数が含まれます (この値が 1 の場合、指定された非エンドポイントは常に同じ右側を取得します)。直感的には、上記の各値が増加すると、構文の複雑さが増加します。
上記のパラメータに基づいて PCFG を作成するには、エンドポイントごとに、世代数 (RHS オプション)、これらの各世代の長さをランダムに選択し、エンドポイントからランダムにサンプリングすることによって生成ルールをインスタンス化し、非確率が割り当てられます (非エンドポイントの合計 RHS オプションによって正規化されます)。次に、すべての非エンドポイントに対して生成されたすべてのルールを収集し、NLTK 上に構築された PCFG パッケージを使用して文法をインスタンス化します。
次に、この文法 (与えられた制約の下でランダムに作成された) を使用して、確率的に文をサンプルし、トークン シーケンス データセットを構築します。後で、異なる文法でのトレーニング (異なる平均長の文を生成) を比較しやすくするために、同じ数のトークンで文をドキュメントにサンプリングすることにしました。コンテキストの長さがいっぱいになるまで、文法に基づいて文のサンプリングを続けます。オーバーフローがある場合は、文が直接切り捨てられます。
文は整数のみのエンドポイントで構成されているため、言語モデルのトークン ID と見なすことができ、未使用の整数 0 (自然言語のピリオドに実質的に相当します) が文を接続するために使用されます。明確にするために、これは自然言語のように「見える」文字列を生成してそれをトークン化することではありません。PCFG はトークン ID 自体のシーケンスを直接生成します。これで、6 セットの初期文法制約に基づいて、異なる複雑さを持つ 6 つのトークン シーケンス データ セットを生成できるようになりました。
gzip 圧縮率による構文の複雑さの測定
実際のデータセットだけでなく生成されたデータセットの複雑さを推定するために、Rohan Pandey は gzip と呼ばれる圧縮アルゴリズムを使用することを選択しました。
gzip の利点の 1 つは、圧縮率がエントロピーに反比例し、エントロピーが構文の複雑さに正比例することを示す、優れた理論的研究基盤があることです。具体的には、データセット内の 1000 個のトークンのトークン シーケンスごとに、gzip を使用して、元のデータに対する圧縮データのサイズ (バイト単位) の比率を計算します。
次に、圧縮率の中央値と標準偏差が計算され、構文の複雑さが高い文法ほどデータセットの圧縮がより困難になることが確認されます。
表 1 は、各文法の構文パラメータと測定された圧縮率を示しています。
非エンドポイント (文法カテゴリ)、エンドポイント (トークン)、右側のオプション、右側の長さが増加するにつれて、gzip 圧縮率も増加することがわかります。圧縮が難しくなります。
図 1 は、これらのデータセットを自然言語およびコード データとともにプロットしています。
複雑さの点で、一部の PCFG データセットはコード データ (容易に圧縮可能な部分) に近く、他の PCFG データセットは自然言語に近いことがわかります。
スケーリングの法則はデータの複雑さに敏感ですか?
データセットのスケーリング則を決定するために、研究者はいくつかの異なるサイズ (パラメーター量は 4.2M、8.8M、20.3M、59.0M、275.3M、1.4B) のモデルをトレーニングしました。表 6 にそのモデルを示します。アーキテクチャの詳細を確認し、その後、得られた損失結果に対してべき乗則フィッティングを実行しました。実験のほとんどは、PyTorch FSDP を使用して、80 GB VRAM を搭載した 4 台の NVIDIA A100 で実行されました。
図 2 に示すように、データセットの圧縮が容易であれば (圧縮率が低いほど)、モデルはより速く収束します。これは私たちの直観的な理解と一致しています。
これは、より複雑なデータセットをモデル化するには、より多くの計算量が必要であることを示唆していますが、計算上の最適限界がデータの複雑さの関数として直接変化するかどうかを判断するには、さらに多くの証拠が必要です。データの複雑さに対するスケーリング則の重要な感度を確立するには、各データセットのスケーリング則を計算し、そのフィッティング パラメーターを調査する必要があります。
gzip 圧縮率に基づいてデータ依存のスケーリング則を計算する
Hoffmann et al. 2022 年に提案されたスケーリング則の関数形式は、トレーニング損失をモデルとデータ サイズの関数として扱うことです。 :
ここで、N はモデルのパラメーターの数、D はトレーニング データ セット内のトークンの数です。彼らは、E は「自然テキストのエントロピー」であり、スケーリング則は「データセットに依存しない」と主張しています。しかし、Rohan Pandey がこの関数を使用してトレーニング結果を PCFG データ セットに適合させたところ、各データ セットのスケーリング則が大きく異なることがわかりました (表 2 を参照)。
このスケーリング則は、パラメータ量の計算上の最適な境界を取得できます (Kaplan et al. [2020] および Hoffmann et al. [2022] から導出)。これは次のように簡略化できます。
ここで、C は計算バジェット (FLOP 単位) です。
図 3 は、チンチラの計算された最適境界と各 PCFG データセットに適合したスケーリング則をプロットしています。
データの圧縮がますます難しくなるにつれて、フィッティングによって得られるスケーリング則の境界が、0.23
データセットの圧縮率に基づいてスケーリング則パラメーターを予測するには、各データセットの近似されたスケーリング則パラメーターに対して単純な線形回帰フィットを実行できます。前述したように、データセット D について、圧縮率 H を計算する方法は、まず各要素 d の元のビット量に対する圧縮ビット量の比率を計算し、次に全要素の平均を計算します。
各パラメータ (E、A、B、α、β) を予測する線が H から適合すると、各パラメータは圧縮率の関数として再定義できます:
ここで、m_x とn_x は、フィッティング後の線形回帰のパラメーターです。
表 3 はこれらの適合値 (および回帰の p 値) を示し、図 4 はこれらの線形回帰の視覚化結果です。
それらは、比率が異なるだけでほぼすべて単調減少しており、H 約 0.27 で α と β が交差します。 E (もともと定数に設定されている「自然言語のエントロピー」) は、H とともに増加する (ただし大幅ではない) 唯一のパラメーターであることに注意してください。
これで、式 (1) を圧縮率 H の関数として再パラメータ化できます:
ただし、ここでの実験の規模は非常に小さく、主に PCFG データセットに焦点を当てているため、Pandey は関数を拡張しました。チンチラを調整した後、データに依存するスケーリング則が得られました。は学習データの gzip 圧縮率の調整重み、追加されたパラメータ ' はチンチラ定数です。
圧縮率の交絡変数として構文パラメーターを排除する
上記の実験では、この圧縮率の尺度が、基礎となる構文特性 (語彙サイズなど) によって混同される可能性については触れていません。この問題に対処するために、図 5 に追加の結果を示します。
語彙サイズを安定に保ち、他の構文プロパティを変更しても (表 4)、gzip 圧縮率は依然としてスケーリング則のパラメータ変化を予測できることがわかります (相関関係は語彙を増やすよりもさらに強いです)設定)。
図 6 は、実際に見つかった反例です。これは、構文特性が大きく異なる (表 5) にもかかわらず、これらのデータ セットの最終的な gzip 圧縮率が同じである場合、スケーリング則パラメーターは大幅に変化しないことを示しています。
この等価語彙のケースでは、図 4 のような交差動作は観察されませんが、α の傾きは依然として β よりも急です (A は B よりも急です)。これは、gzip を使用した場合のことを示しています。圧縮率が増加すると、データの偏りという同じ現象が発生します。
したがって、これらの結果は、スケーリング則はトレーニング データに依存し、gzip 圧縮率はスケーリング プロパティに対するデータの複雑さの影響を適切に予測できることを示していると言えます。
以上がデータセットが異なればスケーリング則も異なりますか?圧縮アルゴリズムを使用してそれを予測できますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

Video Face Swap
完全無料の AI 顔交換ツールを使用して、あらゆるビデオの顔を簡単に交換できます。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック











CでChronoライブラリを使用すると、時間と時間の間隔をより正確に制御できます。このライブラリの魅力を探りましょう。 CのChronoライブラリは、時間と時間の間隔に対処するための最新の方法を提供する標準ライブラリの一部です。 Time.HとCtimeに苦しんでいるプログラマーにとって、Chronoは間違いなく恩恵です。コードの読みやすさと保守性を向上させるだけでなく、より高い精度と柔軟性も提供します。基本から始めましょう。 Chronoライブラリには、主に次の重要なコンポーネントが含まれています。STD:: Chrono :: System_Clock:現在の時間を取得するために使用されるシステムクロックを表します。 STD :: Chron

CのDMAとは、直接メモリアクセステクノロジーであるDirectMemoryAccessを指し、ハードウェアデバイスがCPU介入なしでメモリに直接データを送信できるようにします。 1)DMA操作は、ハードウェアデバイスとドライバーに大きく依存しており、実装方法はシステムごとに異なります。 2)メモリへの直接アクセスは、セキュリティリスクをもたらす可能性があり、コードの正確性とセキュリティを確保する必要があります。 3)DMAはパフォーマンスを改善できますが、不適切な使用はシステムのパフォーマンスの低下につながる可能性があります。実践と学習を通じて、DMAを使用するスキルを習得し、高速データ送信やリアルタイム信号処理などのシナリオでその効果を最大化できます。

CでのハイDPIディスプレイの取り扱いは、次の手順で達成できます。1)DPIを理解してスケーリングし、オペレーティングシステムAPIを使用してDPI情報を取得し、グラフィックスの出力を調整します。 2)クロスプラットフォームの互換性を処理し、SDLやQTなどのクロスプラットフォームグラフィックライブラリを使用します。 3)パフォーマンスの最適化を実行し、キャッシュ、ハードウェアアクセラレーション、および詳細レベルの動的調整によりパフォーマンスを改善します。 4)ぼやけたテキストやインターフェイス要素などの一般的な問題を解決し、DPIスケーリングを正しく適用することで解決します。

Cは、リアルタイムオペレーティングシステム(RTOS)プログラミングでうまく機能し、効率的な実行効率と正確な時間管理を提供します。 1)Cハードウェアリソースの直接的な動作と効率的なメモリ管理を通じて、RTOのニーズを満たします。 2)オブジェクト指向の機能を使用して、Cは柔軟なタスクスケジューリングシステムを設計できます。 3)Cは効率的な割り込み処理をサポートしますが、リアルタイムを確保するには、動的メモリの割り当てと例外処理を避ける必要があります。 4)テンプレートプログラミングとインライン関数は、パフォーマンスの最適化に役立ちます。 5)実際のアプリケーションでは、Cを使用して効率的なロギングシステムを実装できます。

MySQLでは、AlterTabletable_nameaddcolumnnew_columnvarchar(255)afterexisting_columnを使用してフィールドを追加し、andtabletable_namedopcolumncolumn_to_dropを使用してフィールドを削除します。フィールドを追加するときは、クエリのパフォーマンスとデータ構造を最適化する場所を指定する必要があります。フィールドを削除する前に、操作が不可逆的であることを確認する必要があります。オンラインDDL、バックアップデータ、テスト環境、および低負荷期間を使用したテーブル構造の変更は、パフォーマンスの最適化とベストプラクティスです。

Cのスレッドパフォーマンスの測定は、標準ライブラリのタイミングツール、パフォーマンス分析ツール、およびカスタムタイマーを使用できます。 1.ライブラリを使用して、実行時間を測定します。 2。パフォーマンス分析にはGPROFを使用します。手順には、コンピレーション中に-pgオプションを追加し、プログラムを実行してGmon.outファイルを生成し、パフォーマンスレポートの生成が含まれます。 3. ValgrindのCallGrindモジュールを使用して、より詳細な分析を実行します。手順には、プログラムを実行してCallGrind.outファイルを生成し、Kcachegrindを使用して結果を表示することが含まれます。 4.カスタムタイマーは、特定のコードセグメントの実行時間を柔軟に測定できます。これらの方法は、スレッドのパフォーマンスを完全に理解し、コードを最適化するのに役立ちます。

交換に組み込まれた量子化ツールには、1。Binance:Binance先物の定量的モジュール、低い取り扱い手数料を提供し、AIアシストトランザクションをサポートします。 2。OKX(OUYI):マルチアカウント管理とインテリジェントな注文ルーティングをサポートし、制度レベルのリスク制御を提供します。独立した定量的戦略プラットフォームには、3。3Commas:ドラッグアンドドロップ戦略ジェネレーター、マルチプラットフォームヘッジアービトラージに適しています。 4。Quadency:カスタマイズされたリスクしきい値をサポートするプロフェッショナルレベルのアルゴリズム戦略ライブラリ。 5。Pionex:組み込み16のプリセット戦略、低い取引手数料。垂直ドメインツールには、6。cryptohopper:クラウドベースの定量的プラットフォーム、150の技術指標をサポートします。 7。BITSGAP:

マウススクロールイベントの浸透の効果を実現する方法は? Webを閲覧すると、いくつかの特別なインタラクションデザインに遭遇することがよくあります。たとえば、DeepSeekの公式ウェブサイトでは、...
