VeriInteresting: An Empirical Study of Model Prompt Interactions in Verilog Code Generation

本論文は、大規模言語モデルの推論能力、専門性、プロンプト設計戦略の相互作用を分析し、Verilog コード生成におけるモデルクラスごとの反応パターンや一般化可能な傾向を明らかにする実証研究である。

要約

論文「VeriInteresting」の解説：AI に Verilog（半導体設計言語）を書かせる実験

この論文は、**「最新の AI（言語モデル）に、半導体の設計図（Verilog という言語）を書かせると、どれくらいうまくいくのか？」**という疑問を、実際に 18 種類の AI を使って徹底的に実験した研究報告です。

半導体設計は、スマホやパソコンの心臓部を作る非常に重要な仕事ですが、AI による自動化はソフトウェア（アプリなど）の分野に比べて遅れています。なぜなら、**「少しのミスが、製品が完成した後に致命的な故障につながる」**からです。

この研究では、AI の性能を上げるために「どんな指示（プロンプト）を出せばいいか」や「AI の種類は重要か」を、料理や建築の例えを使って探り当てました。

---

🏗️ 1. 背景：なぜ半導体設計は難しいのか？

🍳 ソフトウェア vs 🏗️ ハードウェア

• ソフトウェア（アプリ）の AI：
  ソフトウェアのコードを AI に書かせると、少しバグがあっても「直せばいいや」という感覚で、何度も試行錯誤できます。AI も「とりあえず動くコード」を出せば、人間が後で修正すれば OK です。
• ハードウェア（半導体）の AI：
  半導体設計は**「一度焼いたら修正不能な陶器」**のようなものです。AI が「それっぽく見える」設計図を出しても、内部の信号のタイミングが 0.0001 秒ズレているだけで、製品が壊れてしまいます。
  • 例え話： ソフトウェアの AI は「料理のレシピ」を提案するシェフですが、ハードウェアの AI は「実際に鉄骨を組む大工」です。大工が「たぶん大丈夫だろう」という適当な柱を立てると、建物は倒壊します。

🔍 2. 実験のやり方：18 人の料理人をテスト

研究チームは、以下の 3 つの要素を組み合わせながら、18 種類の AI をテストしました。

1. AI の種類（モデル）：
   • 巨大な AI（LLM）： 頭が良いが、半導体の専門知識はない「天才的な料理人」。
   • 小さな AI（SLM）： 頭は普通だが、半導体の専門書を読ませた「見習い職人」。
   • 専門特化 AI： 半導体設計のデータで徹底的に鍛え上げられた「職人」。
2. 指示の出し方（プロンプト）：
   • 基本の指示： 「これを作ってください」とだけ言う。
   • 構造化指示： 「まず材料リストを書き、次に手順を説明し、最後にレシピを書いて」と細かく指定する。
   • 思考の連鎖（CoT）： 「なぜそうなるのか、理由を考えてから書いて」と指示する。
   • リファイン（書き直し）： 元の指示を AI 自身に「もっと分かりやすく書き直させてから」作らせる。
3. テスト基準（ベンチマーク）：
   • シミュレーション： 「実際に動かして、テストケースに合うか」チェックする（ソフトウェア的なテスト）。
   • 形式検証： 「数学的に、どんな入力でも絶対に正しいか」証明する（ハードウェア特有の厳格なテスト）。

💡 3. 驚きの発見：4 つの重要な教訓

① 「頭が良い AI」より「専門特化 AI」が勝つ場合も

• 発見： 巨大な AI は万能ですが、半導体特有の細かいルール（タイミング制約など）を無視しがちです。一方、専門特化された小さな AI は、その分野のルールを厳密に守ります。
• 例え話： 「何でもできる天才シェフ」に、伝統的な「和食」を作らせると、味が崩れることがあります。しかし、「和食に特化した職人」は、どんなに小さな AI でも、伝統的な味を守れます。
• 結論： 巨大な AI を使うより、**「半導体向けに訓練された AI」**を使う方が、指示を工夫しなくても良い結果が出ることが多いです。

② 「指示の出し方」は AI によって効果が違う

• 発見： ソフトウェア界で流行っている「思考の連鎖（CoT）」や「指示の書き直し」は、半導体設計では**「逆効果」**になることがありました。
• 例え話： 大工に「まず、この家の設計理由を 100 文字で説明してから、柱を立てて」と言ったら、大工は「説明」に夢中になって、柱の太さを間違えてしまいました。
• 結論： AI に「考えさせる」指示は、**小さな AI や専門特化 AI には不要（あるいは有害）**な場合があります。シンプルに「作って」と言う方が、ミスが少ないこともありました。

③ 「微調整（ファインチューニング）」vs「指示の工夫」

• 発見： AI を半導体データで「訓練し直す（微調整）」ことと、単に「指示を工夫する」ことでは、「訓練し直す」方が圧倒的に強いことが分かりました。
• 例え話： 指示の工夫は「料理人に『もっと塩味を』と伝えること」ですが、訓練し直すことは「料理人そのものを和食の修行に出すこと」です。後者の方が、根本的な実力が上がります。
• 結論： 指示を工夫するだけで限界があり、本格的に使うなら**「専門データで AI を鍛え直す」**のが一番の近道です。

④ 一つのテストでは本当の力は測れない

• 発見： 「テスト A」で 100 点の AI が、「テスト B」では 50 点になることがありました。
• 例え話： 「寿司のテスト」で 100 点の職人が、「天ぷらのテスト」では失敗するかもしれません。半導体設計も、テスト方法（シミュレーションか、数学的証明か）によって、AI の得意不得意が全く変わります。
• 結論： 一つのテスト結果だけで「この AI は最高だ」と判断するのは危険です。

🚀 4. 結論：これからどうすればいい？

この研究は、**「AI に半導体を作らせるのは、単に『すごい AI』を使えばいいわけではない」**と教えています。

• AI の選び方： 巨大な汎用 AI だけでなく、**「半導体専門で訓練された AI」**を組み合わせる。
• 指示の出し方： 何でもかんでも「考えさせて」指示するのではなく、AI の種類に合わせて指示を調整する（専門 AI にはシンプルに、汎用 AI には構造的に）。
• 評価の仕方： 一つのテストで終わらせず、複数の厳しさを試す必要がある。

🌟 まとめ

AI は半導体設計の未来を切り開く強力なツールですが、「万能の魔法の杖」ではありません。
「どんな AI に、どんな指示を出せば、安全で正確な設計図が作れるか」という**「AI と人間の新しい共働のルール」**を、この論文が初めて詳しく地図に描き出しました。

今後は、AI が「設計図を書く」だけでなく、**「設計図の安全性を自分でチェックする」**ような、より高度なシステムへの発展が期待されます。

技術概要

VeriInteresting: Verilog コード生成におけるモデルとプロンプトの相互作用に関する実証研究

技術的サマリー（日本語）

本論文は、大規模言語モデル（LM）を用いた Verilog（ハードウェア記述言語）コード生成における、モデルの特性とプロンプト設計の相互作用を体系的に調査した実証研究です。ソフトウェア生成とは異なり、ハードウェア設計は厳密なセマンティクス、タイミング制約、および論理的完全性を要求するため、既存のソフトウェア向けプロンプト戦略がそのまま適用可能かどうかを明らかにすることを目的としています。

以下に、問題定義、手法、主要な貢献、結果、および意義について詳述します。

1. 問題定義と背景

• ハードウェア設計の特殊性: Verilog は Python などのソフトウェアとは異なり、冗長で構造的であり、信号の接続やタイミング制約において長文脈の整合性が不可欠です。一見正しく見えるコードでも、タイミング違反や競合状態（レースコンディション）を含み、後工程で重大な欠陥を引き起こす可能性があります。
• データの制約: ハードウェア設計の多くはクローズドソースの知的財産（IP）であるため、大規模なオープンソースのトレーニングデータが不足しています。これにより、モデルの再トレーニングやファインチューニングが困難であり、既存のモデルを推論段階（Inference-time）で最大限に活用する手法が求められています。
• 研究のギャップ: ソフトウェア生成で有効なプロンプトエンジニアリング（構造化、CoT、ICL など）や推論時最適化が、ハードウェア設計タスクにおいてどの程度有効か、またモデルの規模や専門性がどのように影響するかは、体系的に評価されていませんでした。

2. 研究方法

本研究は、2 つの補完的なベンチマークと多様なモデル、そして制御されたプロンプト戦略を用いた大規模な因子実験（Factorial Design）を行いました。

• 評価ベンチマーク:
  1. Verilog Eval v2: 動的シミュレーション（Icarus Verilog）を用いて、テストベンチに対する機能正しさを評価。
  2. VeriThoughts: 形式的等価性チェック（Yosys による LEC）を用いて、すべての入力状態に対する機能的等価性を検証。
• 評価対象モデル（計 18 種類）:
  • 商用 LLM（GPT-4.1, GPT-5, Gemini 3, Claude Sonnet 4 など）。
  • オープンソースの汎用およびコード特化モデル（Qwen2.5 シリーズ、DeepSeek Coder など）。
  • Verilog 特化モデル（VeriReason, VeriThoughts：SFT や GRPO によるファインチューニング済み）。
• プロンプト戦略（推論時適応）:
  • ベースライン: 単一のパスプロンプト。
  • 構造化プロンプト (Struct): 一貫したタスク署名とモジュール化されたコンポーネントを強制。
  • プロンプト洗練 (Refine): 仕様を再書き換え・明確化してから RTL を生成する 2 段階パイプライン。
  • Chain-of-Thought (CoT): コード生成前の推論ステップの追加。
  • インコンテキスト学習 (ICL): 例示（Exemplars）の追加。
  • GEPA (Genetic-Pareto): 推論時のみでプロンプトを最適化する進化的アルゴリズム。
• 評価指標: Pass@k（k=1, 5, 10）、特に Pass@10 での成功率の変化を重点的に分析。

3. 主要な貢献と知見

RQ1: モデルの規模 vs. 専門特化

• 規模と特化のトレードオフ: 規模の拡大（パラメータ数の増加）と Verilog 特化（ファインチューニング）の両方が性能向上に寄与しますが、その挙動は異なります。
• ベンチマーク依存性: VeriThoughts 特化モデルは、自らのトレーニングデータ（形式的検証）では高い性能を示しますが、シミュレーションベースの Verilog Eval v2 では汎用モデルに劣る、あるいは性能が低下する傾向が見られました。これは、特定のベンチマークに過剰適合（Overfitting）している可能性を示唆しています。
• 小規模モデルの強み: 適切なプロンプト戦略（特に構造化）を用いれば、ファインチューニングされていない中規模のオープンソースモデル（例：Qwen-14B）は、商用モデルに匹敵する性能を発揮できることが示されました。

RQ2: プロンプト戦略への感度

• 構造化プロンプトの有効性: 多くのオープンソースモデル、特にコード特化モデルにおいて、構造化プロンプトは安定した性能向上をもたらしました。
• CoT の二面性: 推論ステップ（CoT）の追加は、構造化プロンプトと組み合わせた場合、小規模モデルのフォーマットエラーを軽減し性能を向上させることがありますが、VeriThoughts などの特化モデルや、形式的検証ベンチマークでは、不要な仮定が RTL に伝播し、逆に性能を低下させるケースがありました。
• プロンプト洗練の脆さ: 仕様の再書き換え（Refine）を行うパイプラインは、多くのモデルで性能を著しく低下させました。特に、モデルが「テストベンチの提案」など不要な出力を含めてしまい、評価失敗を招くケースが多く見られました。これは Verilog 生成において「安全なデフォルト戦略」ではないことを示しています。
• ICL の限界: 例示の追加は、安定したテンプレートと組み合わせた小規模モデルでは有効でしたが、特化モデルやベースラインでは無効、あるいは有害になることがありました。

RQ3: ファインチューニング vs. 強力なプロンプト

• 推論時最適化の限界: 強力なプロンプトエンジニアリング（構造化＋CoT）は、ファインチューニングされたモデルとのギャップを縮めることができますが、完全に埋めることはできません。
• 適応の目的: タスクの分布がファインチューニングの目的と一致する場合（例：VeriReason とシミュレーションベースの評価）、特化モデルはプロンプトのみでは到達できない性能を達成します。逆に、分布が異なる場合は、汎用モデルに強力なプロンプトを適用する方が効率的な場合があります。

RQ4: ベンチマーク間の安定性

• 相関と乖離: 2 つのベンチマーク間には正の相関（r=0.868）がありますが、多くのモデルで Verilog Eval v2（シミュレーション）の方が VeriThoughts（形式的検証）よりも難易度が高く、性能が低下しました。
• 単一ベンチマークの危険性: 特定のベンチマークでのみ評価すると、モデルの真の能力やプロンプト戦略の有効性を見誤る可能性があります。多角的な評価が不可欠です。

4. 結論と意義

• ソフトウェアとハードウェアの根本的な違い: Verilog 生成は、単なるコード生成のバリエーションではなく、質的に異なるタスク領域です。ソフトウェアでは有効な「反復的改善」や「部分的な正しさ」が許容されるのに対し、ハードウェアでは微小な意味的誤りが致命的な欠陥となります。このため、ソフトウェア向けに開発された多くの推論時テクニックは、ハードウェア設計では「脆く（Fragile）」、場合によっては逆効果になります。
• モデルとプロンプトの相互作用: 性能は単一の要因（モデルの規模やプロンプトの複雑さ）ではなく、モデルの特性と推論時のスキャフォールディング（支援）の相互作用によって決定されます。
• 実用的な指針:
  • ハードウェア設計への LM 導入においては、単一の「最高性能モデル」や「万能プロンプト」を追求するのではなく、ターゲットとなる検証フロー（シミュレーションか形式的検証か）とモデルの特性に合わせた戦略の選択が必要です。
  • 推論時のプロンプト最適化はコスト効率の良い第一歩ですが、特定のドメインに特化したタスクにおいては、トレーニング時の適応（ファインチューニング）が不可欠です。
  • 評価には、複数のベンチマークと評価プロトコルを用いた多角的な検証が必須です。

本研究は、ハードウェア設計における LM の展開を支援するための実証的な地図（Empirical Map）を提供し、より堅牢な評価手法と、ツールチェーンとの統合に向けた基礎を築くものです。