ChipNeMo: チップ設計のためのドメイン適応型 LLM: LLM アプリケーション

リンク一覧

• 概要と序文
• データセット
• ChipNemo ドメイン適応法
• LLM アプリケーション
• 評価
• 議論
• 関連事業
• 結論
• 謝辞、貢献、参考文献
• 付録

IV. LLMアプリケーション

私たちは設計チーム内で潜在的な LLM アプリケーションを調査し、それらをコード生成、質疑応答、分析とレポート、トリアージの4 つのバケットに分類しました。コード生成とは、設計コード、テストベンチ、アサーション、内部ツール スクリプトなどを生成する LLM のことを指します。Q&A とは、設計、ツール、インフラストラクチャなどに関する質問に答える LLM のことを指します。分析とレポートとは、データを分析してレポートを提供する LLM のことを指します。トリアージとは、ログとレポートに基づいて設計またはツールの問題のデバッグを支援する LLM のことを指します。トリアージカテゴリは今後の調査のために残しておきますが、それ以外の各カテゴリから 1 つの主要なアプリケーションを選択してこの作業で調査します。各アプリケーションの動機と技術的詳細を以下に示します。

A. エンジニアリングアシスタントチャットボット

このアプリケーションは、設計エンジニアがアーキテクチャ、設計、検証、構築に関する質問に答えるのを支援することを目的としており、これにより、他の人の生産性に影響を与えることなく、全体的な生産性を大幅に向上させることができます。設計エンジニアは、ブレインストーミング、ハードウェアの設計、コードの作成を楽しむことが多いですが、不足している設計知識に関する回答を待つことで作業が遅くなることがあります。エンジニアが誤った仮定に基づいてコードを書いたり、不慣れなコードをデバッグしたりしないようにすることで、設計の生産性を高めることもできます。社内調査によると、一般的なチップ設計者の時間の最大 60% が、設計仕様、テストベンチの構築、アーキテクチャの定義、ツールやインフラストラクチャなど、さまざまなトピックのデバッグまたはチェックリスト関連のタスクに費やされています。これらの問題の専門家は、多国籍企業では世界中に散らばっていることが多く、すぐに助けを求めるのが必ずしも便利であるとは限りません。そのため、社内の設計ドキュメント、コード、設計に関する記録データ、電子メールや企業のインスタント コミュニケーションなどの技術コミュニケーションから抽出された知識に基づくエンジニアリング アシスタント チャットボットは、設計の生産性を大幅に向上させるのに役立ちます。このアプリケーションは、セクション III-D で説明したドメイン適応型 RAG メソッドを使用して実装しました。

B. EDAスクリプト生成

産業用チップ設計フローにおけるもう1つの一般的なタスクは、EDAスクリプトを記述してさまざまなタスクを実行することです。

設計実装、イントロスペクション、変換などのさまざまなスクリプトが存在します。これらのスクリプトは、多くの場合、ツール固有のスクリプト ライブラリとカスタムの内部スクリプト ライブラリの両方を活用します。これらのライブラリの学習、ツールのドキュメントの参照、およびこれらのスクリプトの作成とデバッグには、かなりのエンジニアリング時間がかかります。

LLMは、幅広いタスクにおける小規模コード生成に優れていることが証明されているため[32]、これらのモデルをカスタマイズして、このドメイン固有のタスクにおけるエンジニアの生産性を向上させることは自然な流れです。この研究では、自然言語のタスク記述から2種類のスクリプトを生成することに焦点を当てています。1つ目は、設計編集および分析用の内部PythonライブラリであるTool1を活用するスクリプトです。2つ目は、業界をリードする静的タイミング解析ツールであるTool2が提供するコマンドインターフェイスを使用するTclスクリプトです。

このタスク用のドメイン固有の微調整データセットを構築するために、両方のツールの製品スクリプトを設計の専門家から収集しました。DAPT モデルは、コードに対して適切なインライン コメントを生成できることが分かりました。これにより、これらのモデルを使用して、追加のインライン コメントを生成することで、収集されたスクリプトの品質を向上させることができました。その後、人間の専門家がこれらのコメントを検証して修正し、関連するプロンプトを作成しました。これらのプロンプトとコードのペアは、セクション III-C で説明した形式で DSFT に使用されるデータを構成します。

最も有意義な方法でフィードバックを提供および収集するために、図 4 に示すフローの構築に多大な労力を費やしました。このフローでは、エンジニアが同じインターフェイスを介してモデルをクエリし、生成されたコードを実行できます。これにより、生成されたコードの正確性に自信を持てるだけでなく、エンジニアが機能するスクリプトを取得するために何回修正する必要があるかを確認できるため、正確なフィードバックを提供できます。ツール サーバーへのインタラクティブな接続を確立することで、ツール 1 とツール 2 の統合をサポートします。

さらに、ユーザー フィードバック フォームも提供しており、さまざまなモデルを比較したり、ユーザー フィードバックから貴重な洞察を得たりすることができます。この貴重な情報は、モデルをさらに改良するのに役立ちます。

C. バグの要約と分析

生産フローの各段階におけるさまざまな機能やバグの報告、トリアージ、デバッグ、解決を追跡することは、時間のかかるプロセスです。エンジニアリング マネージャーは、プロジェクトの状態を理解し、実行を迅速化するために、社内の問題追跡データベースの確認に多くの時間を費やしています。したがって、すべてのサポート情報を確認し、技術データと管理データの両方をすばやく要約し、次のステップを提案できるツールがあれば、チームの生産性が向上します。私たちは、LLM を使用して 3 つの異なる出力を生成することに重点を置いています。1 つは技術的な詳細に重点を置いた出力、1 つは管理的な詳細に重点を置いた出力、もう 1 つはタスク割り当ての推奨に重点を置いた出力です。

これらのタスクを調査するために、NVIDIA の社内バグ データベースである NVBugs を使用しました。このデータベースは、バグの報告、追跡、解決、および会社全体の一般的なタスクと機能の追跡に使用されます。DAPT データセットには大量のバグ データが含まれていたため、ChipNeMo モデルがこのタスクで優れたパフォーマンスを発揮すると予想されます。さらに、このタスク用に、バグの要約とタスク割り当てタスクの例を含むドメイン固有の SFT データセットを構築しました。

多くの場合、バグの説明には、長いコメント履歴とともに、ログ ファイルやコード ダンプの大きなスニペットが含まれています。このような場合、バグ テキストは LLM コンテキスト ウィンドウには大きすぎます。これを回避するために、2 つのソリューションを実装しました。まず、長いパス名を見つけて短いエイリアスに置き換え、文字列全体を処理することなく、モデルがバグ内の複数の場所で発生するパスを関連付けられるようにしました。次に、要約タスクを増分タスクに分割し、モデルが複数の要約およびバグ データ チャンクにわたってデータを蓄積するタスクを割り当てます。階層的なアプローチを使用し、バグは最初にコンテキスト ウィンドウに収まるチャンクに分割されます。次に、これらのチャンクが要約され、要約が蓄積されてからチャンクに分割されます。このプロセスは、要約のセット全体が単一のコンテキスト ウィンドウに収まり、単一の要約が生成されるまで繰り返されます。要約に使用される LLM とは関係なく、この同じアプローチを使用します。