著者:
(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。
ChipNeMo は、LLM をチップ設計ドメインに適応させるために、複数のドメイン適応技術を実装しています。これらの技術には、チップ設計データ用のカスタム トークナイザー、大規模なドメイン データのコーパスを使用したドメイン適応型事前トレーニング、ドメイン固有のタスクを使用した教師あり微調整、微調整された検索モデルを使用した検索拡張生成が含まれます。このセクションでは、各技術の詳細について説明します。
A. トークナイザー
事前トレーニング済みのトークナイザーを採用する場合の主な目標は、ドメイン固有のデータに対するトークン化の効率を向上させ、一般的なデータセットに対する効率と言語モデルのパフォーマンスを維持し、再トレーニング/微調整の労力を最小限に抑えることです。これを実現するために、次の 4 段階のアプローチを開発しました。
• ステップ 1: ドメイン固有のデータを使用してトークナイザーを最初からトレーニングします。
• ステップ 2: 新しいトークナイザーの語彙から、汎用トークナイザーには存在せず、汎用データセットではほとんど見つからないトークンを識別します。
• ステップ 3: ステップ 2 で新しく識別されたトークンを使用して汎用トークナイザーを拡張します。
• ステップ 4: 汎用トークナイザーを利用して新しいトークンの埋め込みを初期化します。
具体的には、ステップ4では、新しいトークンに遭遇すると、事前にトレーニングされた汎用トークナイザーを使用してトークン化されます。新しいトークンの埋め込みは、汎用トークナイザー[24]によって生成されたトークンの埋め込みを平均化することによって決定され、出力層の重みはゼロに初期化されます。
ステップ 2 では、汎用データセットではあまり発生しない新しいトークンを選択的に導入することで、一般的なデータセットでの事前トレーニング済み LLM のパフォーマンスを維持するのに役立ちます。また、ステップ 4 では、汎用トークナイザーによってガイドされる新しいトークンの埋め込みの初期化により、LLM の再トレーニング/微調整に必要な労力を削減します。
B. ドメイン適応型事前学習
本研究では、事前学習済みの基礎ベースモデル LLaMA2 7B/13B に DAPT を適用します。各 DAPT モデルは、対応する事前学習済みの基礎ベースモデルの重みを使用して初期化されます。DAPT モデルをChipNeMoと名付けます。セクション III-A に示すようにトークナイザー拡張を使用し、それに応じて埋め込み重みを初期化します [24]。標準的な自己回帰言語モデリング目標を使用して、ドメイン固有のデータに対してさらに事前学習を行います。すべてのモデル学習手順は、効率を高めるためにテンソル並列処理 [26] やフラッシュアテンション [27] などの手法を取り入れた NVIDIA NeMo フレームワーク [25] を使用して行われます。
図2は、指定されたハイパーパラメータでのChipNeMoのトレーニング損失を示しています。トレーニング損失にスパイクが見られます。[28]の仮説とは対照的に、私たちのシナリオでは、これらのスパイクは「不良データ」に起因すると仮定しています。なぜなら、これらの不規則性は、異なるモデルサイズ間でも、同じモデルの同様のトレーニングステップで一貫して発生しているように見えるからです。これらの異常は、おそらく低い学習率を適用したため、後続のトレーニングステップに大きな支障をきたすようには見えなかったため(検証損失の顕著な低下なし)、この問題には対処しないことを選択しました。
C. 教師あり微調整
DAPT の後、教師あり微調整 (SFT) を使用してモデルの調整を実行します。グローバル バッチ サイズを 128 に縮小することを除き、すべてのモデルに対して DAPT と同じハイパーパラメータ トレーニング構成を採用します。すべての SFT データは、以下のチャット テンプレートに従って構造化されます。
<extra_id_0>システム\n{システム}
<extra_id_1>ユーザー\n{user_utterance}
<extra_id_1>アシスタント\n{chipnemo_response}
…
我々は自己回帰最適化目標を採用し、システムとユーザープロンプトから発生するトークンに関連する損失をマスクする戦略を実装しています[5]。このアプローチにより、バックプロパゲーション中に、回答トークンの最適化にのみ焦点が当てられるようになります。
約 1.1k のサンプルからなるドメイン SFT データセットを、128k のサンプルからなるより広範な一般チャット SFT データセットと組み合わせます。次に、データにランダム シャッフルを適用した後、1 つのエポックの微調整を行いました。ドメイン固有の SFT データセットを複数のエポックで拡張する実験を行いました。しかし、ドメイン内の質問を提示すると、モデルがすぐに過剰適合の兆候を示し、ドメイン SFT データセットからの無関係な回答を繰り返すことが明らかになりました。
さらに、ドメイン固有の SFT データを除外し、一般的なチャット データセットのみを使用して追加の SFT を実施しました。わかりやすくするために、すべての ChipNeMo モデルを次のように指定します。
ChipNeMo-Chat:ドメインと一般的なチャットデータの両方で微調整されたモデル。
ChipNeMo-Chat (noDSFT):一般的なチャットデータのみを使用して微調整されたモデル。
また、LLaMA2-Chat モデルなどのチャット アライメント モデルで DAPT を直接試してみました。DAPT によってモデルのアライメントが大幅に低下し、結果として得られたモデルが下流のタスクに役に立たなくなることがわかりました。
D. 検索拡張生成
LLM が不正確なテキスト、いわゆる幻覚を生成する可能性があることはよく知られています [29]。この現象は完全には解明されていませんが、正確性が重要となるエンジニアリング アシスタント チャットボットのコンテキストでは特に問題となるため、幻覚を軽減する必要があります。私たちの提案は、検索拡張生成 (RAG) 方式を活用することです。RAG は、質問と一緒にプロンプトに含める関連文章をデータベースから検索しようとします。これにより、LLM はより正確な回答を生成できるようになります。RAG にドメイン適応言語モデルを使用すると、ドメイン固有の質問に対する回答の品質が大幅に向上することがわかりました。また、既製の教師なし事前トレーニング済み高密度検索モデルを適度な量のドメイン固有のトレーニング データで微調整すると、検索精度が大幅に向上することがわかりました。ドメイン適応型 RAG 実装図を図 3 に示します。
私たちは、Tevatronフレームワーク[31]を使用して3000個のドメイン固有の自動生成サンプルを使用してe5_small_unsupervisedモデル[30]を微調整することで、ドメイン適応検索モデルを作成しました。サンプル生成とトレーニングプロセスについては、付録Cで説明します。
検索モデルを微調整することで大きなメリットが得られますが、ドキュメント コーパス内の文章に直接マップされないクエリや、文章に存在しないコンテキストを必要とするクエリでは、検索が依然として困難であるという事実は変わりません。残念ながら、これらのクエリは、実際の状況でエンジニアが尋ねるクエリをより代表するものでもあります。検索とドメイン適応型言語モデルを組み合わせることは、この問題に対処する 1 つの方法です。
この論文はCC 4.0ライセンスの下でarxivで公開されています。