著者:
(1)Mingjie Liu、NVIDIA {同等の貢献}
(2)Teodor-Dumitru Ene、NVIDIA {同等の貢献}
(3)ロバート・カービー、NVIDIA {同等の貢献}
(4)クリス・チェン、NVIDIA {同等の貢献}
(5)ナサニエル・ピンクニー、NVIDIA {平等な貢献}
(6)Rongjian Liang、NVIDIA {同等の貢献}
(7)ジョナ・アルベン、NVIDIA
(8)ヒムヤンシュ・アナンド、NVIDIA
(9)サンミトラ・バナージー、NVIDIA
(10)イスメット・バイラクタログル、NVIDIA
(11)ボニータ・バスカラン、NVIDIA
(12)ブライアン・カタンツァーロ、NVIDIA
(13)アルジュン・チャウドゥリ、NVIDIA
(14)シャロン・クレイ、NVIDIA
(15)ビル・ダリー、NVIDIA
(16)ローラ・ダン、NVIDIA
(17)パリクシット・デシュパンデ、NVIDIA
(18)シッダーント・ドーディ、NVIDIA
(19)サミール・ハレペテ、NVIDIA
(20)エリック・ヒル、NVIDIA
(21)Jiashang Hu、NVIDIA;
(22)スミット・ジェイン、NVIDIA
(23)ブルーチェク・カイラニー、NVIDIA
(24)ジョージ・コーカイ、NVIDIA
(25)キショール・クナル、NVIDIA
(26)シャオウェイ・リー、NVIDIA
(27)チャーリー・リンド、NVIDIA
(28)ハオ・リウ、NVIDIA
(29)スチュアート・オーバーマン、NVIDIA
(30)NVIDIAのスジート・オマール氏
(31)スリードハール・プラティ、NVIDIA
(23)ジョナサン・ライマン、NVIDIA
(33)アンバー・サルカー、NVIDIA
(34)NVIDIAの邵正江氏
(35)ハンフェイ・サン、NVIDIA
(36) Pratik P Suthar、NVIDIA;
(37)ヴァルン・テジ、NVIDIA
(38)ウォーカー・ターナー、NVIDIA
(39)Kaizhe Xu、NVIDIA;
(40)レン・ハオシン、NVIDIA。
収集は、関連する設計データとドキュメントを識別し、該当する場合はプレーンテキストに変換し、基本的な品質メトリックを使用してフィルタリングし、正確なファイル重複排除のためにチェックサムを計算し、保存用に圧縮するように設計された一連のシェルおよび Python スクリプトを使用して実装されました。収集フローでは、既製の LLM 固有のスクレイピングおよび収集スクリプトを使用しませんでした。これは、内部データ ソース (ネットワーク ファイル システムと内部 Web アプリケーションの両方) の現場データ収集を通じてスペース要件を最小限に抑えることを目指していたためです。ファイル システム ベースの収集では、追加の生データ セットをローカルに保存するのではなく、品質のためにフィルタリングされた状態でデータが所定の場所に保持されました。
設計および検証データの収集には、Verilog および VHDL (RTL およびネットリスト)、C++、Spice、Tcl、さまざまなスクリプト言語、ビルド関連の構成ファイルなど、さまざまなソース ファイルが含まれていました。社内 Web サービスからのデータは、REST API 呼び出しと従来のクロールによって収集されました。どちらの場合も、オープンソースの BeautifulSoup [52] Python ライブラリを使用して HTML フォーマットが削除され、コーディング例の不注意な削除を最小限に抑えましたが、その代わりに、定型的なナビゲーション バーやその他の HTML ページ要素が増えました。データ収集フローは、すぐに使用できる Python 変換ライブラリとオープンソース ツールを使用して、.docx、.pptx、.pdf などの従来のドキュメント形式をサポートしました。
ほとんどの内部データは高品質であると考えられるため、最小限のフィルタリングが適用されました。行数フィルタリングを使用して、極端に大きいファイルや小さいファイルが除外されるようにし、ファイルは手動で作成されたものとツールで生成されたものの大まかなカテゴリに分類されました。
このセクションでは、ドメイン適応型の事前トレーニング済みモデルに関する詳細な結果を示します。また、ドメイン適応型の事前トレーニングに関するアブレーション実験についても詳しく説明します。
DAPTハイパーパラメータ:詳細は表VIに示されています。
自動評価結果:自動評価ベンチマークの詳細な結果を表 VII および表 VIII に示します。簡潔にするために、このセクションの残りの部分では、アブレーション研究の集約されたベンチマーク結果を示します。
•チップ: 表 III (5 ショット) からドメイン内の設計、スクリプト、バグ、回路のベンチマークの平均結果を報告します。
• MMLU:様々なテーマでよく使われる集約ベンチマークであるMMLU(5ショット)[22]の全体的な結果を報告します。
•推論:Winogrande [53]、hellaswag [54]、ARC-easy [55]、RACE-High [56]など、常識推論(0ショット)に関する一般的な公開ベンチマークの平均結果を報告します。
•コード:HumanEval [23]、VerilogEval-Machine [12]、VerilogEval-Human [12]などの貪欲デコードを使用したコーディングベンチマークの平均合格率を報告します。
トークナイザーの拡張:セクション III-A で説明したように、オリジナルの LLaMA2 トークナイザーと拡張トークナイザーを使用して DAPT を実験しました。図 11 は、オリジナルの変更されていないトークナイザーを使用した ChipNeMo の平滑化されたトレーニング損失を示しています。図 2 と比較すると、基礎モデルの事前トレーニング中に追加されたトークンが観察されないため、拡張トークナイザーは初期化時にトレーニング損失が大きいことがわかります。1 エポックの DAPT でも同様のトレーニング損失が達成されています。
表 IX は、集約された自動評価ベンチマークの結果を示しています。注意深いトークナイザーの拡張と重みの初期化は、一般的な学術ベンチマークでのモデルのパフォーマンスにわずかにしか影響しないことに注意してください。DAPT は、Verilog コーディングを含むすべてのトークナイザーでドメイン ベンチマークを大幅に改善しました (HumanEval では大きな違いはありません)。トークナイザーを拡張すると、モデルの一般的な言語とドメイン機能が低下することなく、トークナイザーとトレーニングの効率が向上するという利点があると結論付けています。
公開データセットのミックスイン:セクション II-A で紹介したように、DAPT には、基礎モデルの事前トレーニングによく使用される公開データセットからサンプリングした公開データを含めました。DAPT に Wikipedia などの公開データをミックスすることで、トークナイザーの拡張によってもたらされる混乱を「修正」し、一般的な自然言語機能を向上させることができると期待していました。
モデル。ドメイン データのみを使用して、トークナイザー拡張による DAPT の別のラウンドを実施し、約 1.1 エポックのデータに相当する同じステップ数のトレーニングを行いました。公開データのミックスインにより結果がわずかに改善されることがわかりました。詳細な結果を表 X に示します。
図12は、パブリックデータセットのミックスインを含む拡張トークナイザーを使用したChipNeMo-7Bのトレーニング損失を示しています。最初のトレーニングステップでトレーニング損失に大きなスパイクが見られましたが、7Bモデルの最終的なトレーニング損失は13Bの元のDAPTハイパーパラメータよりも優れていました。ただし、表XIIに示すように、ドメイン内チップ設計を含む自然言語ベンチマーク全体で大幅な劣化が見られます。コーディング機能は、[32]の調査結果と一致して向上しました。
我々のケースは[32]のケースとは異なることを強調する。我々も事前学習済みのチェックポイントから初期化する「継続的な事前学習」を行っているが、モデルが一般的な能力に関して高いパフォーマンスを維持することを望んでいる。
ドメインデータセットの情報と知識(モデルの事前トレーニングでは見えない)をモデルの重みに蒸留する。対照的に、[32]は、主に自然言語要素が欠けている公開コードデータを使用して、コーディング関連のタスクに主に焦点を当てています。私たちは、より低い学習率がドメイン適応に二重の役割を果たしたと仮定しています。DAPTを通じてドメイン知識の蒸留を促進しながら、ベースモデルからあまり逸脱しないバランスを維持し、一般的な自然言語機能を維持しながら、ドメイン内タスクのパフォーマンスを大幅に向上させました。
パラメータ効率的なファインチューニング (PEFT):パラメータ効率的なファインチューニングは、事前トレーニング済みモデルの重みを固定し、トレーニング可能なパラメータをより小さなアダプタモデルに注入して、下流のタスクを効率的にファインチューニングします。低ランク適応 (LoRA) [16] を使用して、DAPT での PEFT の使用を検討します。トランスフォーマー層の実装では KQV を単一の投影に融合するため、各自己注意層に単一の低ランク投影用の LoRA アダプタを組み合わせて追加します。表 VI と同じ DAPT トレーニング設定を使用して、元の LLaMA2 トークナイザーで LLaMA2-13B モデルを実験します。2 つの実験を実行し、それぞれ 2,640 万 (小) と 2 億 1,120 万 (大) の追加のトレーニング可能なパラメータを導入しました。
図 13 は、LoRA モデルのトレーニング損失曲線を示し、フル パラメータ トレーニングと比較しています。両方の LoRA モデルで、損失は急速に収束し、特定のポイントを超えると減少が止まります。表 XIII は、LoRA モデルの評価結果を示しています。両方の LoRA モデルは、ドメイン内チップ設計タスクでフル パラメータ トレーニングを大幅に下回っています。LoRA モデルは、チップ設計タスクで非 DAPT モデルよりも改善され、より大きなモデルではわずかに優れた (ただし有意ではない) 結果を示しています。
トレーニング サンプルを手動で生成するのは非常に手間がかかるため、自動的に生成するプロセスを実装することにしました。対照学習を使用してモデルを微調整しているため、各サンプルには、正確さを最大化するために、特にハード ネガティブの肯定的な文章と否定的な文章の両方のセットが必要です。
1) データセットのサンプリング手順:図 14 は、サンプルを生成するための手順を示しています。
• ステップ1: 文書コーパスから一節をランダムに選択する
• ステップ2: 言語モデル(Vicuna)を使用して文章から有効なクエリを生成する
• ステップ3: 既存の検索モデル(文変換)を使用して、文書コーパスからクエリの上位N個の文章を取得します。各文章は潜在的なハードネガティブです。
• ステップ4: 取得した文章の一部は実際には肯定的な内容である可能性があるため、同じ言語モデルを使用して肯定的な文章を除外します。
• ステップ5: このフィルタリングプロセスの後でも否定的な文章が十分でない場合は、コーパスからランダムに文章を補足します。
当初の研究ではVicuna [4]とSentence Transformer [33]を使用しましたが、それぞれLLaMA2 [5]とBM25 [42]に簡単に置き換えて、商業的に実行可能な検索モデルを作成することができます。
2) ヒット品質の比較:すべてのヒットが同じように作成されるわけではありません。以下の仕様例の一節は、クエリに明確かつ完全に答えています。ビルド例の一節には答えが含まれていますが、クエリに答えるにはより多くのコンテキストが必要です。
仕様例:ヒットした文章はクエリに明確に答えます。
ビルドの例:クエリに完全に答えるには、追加情報が必要です。例: DL とは何ですか? Arch-Build-Hotseat-XXX が DL であることをどうやって知るのですか?
D. 追加評価データ
表XIVは、エンジニアリングアシスタントチャットボットアプリケーションのすべてのモデルの評価データを示しています。
表XVは、EDAスクリプト生成タスクにおけるすべてのモデルの評価結果を示しています。
表XVIは、バグ要約および分析タスクにおけるすべてのモデルの評価結果を示しています。
1) エンジニアリングアシスタントチャットボット:
2) EDA スクリプト生成:一部の関数名とコマンドは難読化されています。
3) バグの概要と分析:ユーザー名、チップ名、パスは難読化されています。
この論文はCC 4.0ライセンスの下でarxivで公開されています。