HWE-Bench、実hardware bugでagentの70.7%修復率を測る
Original: HWE-Bench: Benchmarking LLM Agents on Real-World Hardware Bug Repair Tasks View original →
Hardware engineeringは、LLM agent評価で手薄になりがちな領域だった。多くのbenchmarkは、小さなHDL module生成にとどまっていたからだ。2026年4月16日07:19:34 UTCにarXivへ提出されたHWE-Benchは、評価対象を実際のrepository-level hardware bug repairへ広げている。
Benchmarkは、六つのmajor open-source projectにある過去のbug-fix pull requestから作られた417 task instancesで構成される。対象はVerilog/SystemVerilogとChiselにまたがり、RISC-V cores、SoCs、security roots-of-trustを含む。各taskはfully containerized environmentに置かれ、agentはreal bug reportを修正しなければならない。正しさはproject nativeのsimulationとregression flowsで確認される。
論文は七つのLLMと四つのagent frameworkを評価した。最高agentは全体で70.7%のtaskを解いた。だが重要なのは内訳だ。小さなcoreでは90%を超える一方、複雑なSoC-level projectでは65%未満に落ちる。つまり現在のagentは範囲が比較的閉じたlocal hardware fixには強いが、project structureや複数artifactの関係を理解する修正ではまだ苦戦する。
著者らは失敗を三つの段階に分ける。fault localization、hardware-semantic reasoning、そしてRTL、configuration、verification fileをまたぐcross-artifact coordinationだ。この分析はEDA teamにとって重い。Hardware bugは単なるtext editではなく、timing assumption、module interface、verification intent、project固有のbuild behaviorを同時に守る必要がある。
Chip teamにとって気になるのはvarianceだ。高い平均値は、あるcore familyではうまく動くが別のprojectでは失敗するagentを隠してしまう。だからbenchmark tableではmodel nameだけでなく、task-suite breadth、container fidelity、regression qualityも同じくらい重要になる。
HWE-Benchは、agentがhardware designを任せられるという宣言ではない。むしろ、どこで壊れるかを再現可能に示すpressure testだ。今後、難しいSoC-level caseで改善が進めば、hardware-aware agentはregression triage、open-source core maintenance、verification-driven repair workflowの実用的な補助役になり得る。
Related Articles
モデル順位表の弱点は、モデルではなく問題側にあるかもしれない。新しいarXiv論文は、評価タスクの25.7%以上に重大な問題を見つけ、欠陥タスクを除くとSWE-bench Verifiedの平均性能が9.9%動くと報告した。
Google I/O 2026の焦点は、Geminiを単独アプリではなく実行レイヤーとして広げることにある。Gemini 3.5 FlashはAPI、Antigravity、Android Studio、Search、Gemini appへ広がり、Gemini Omni Flashはvideo生成を同じ流れに乗せる。
Claude Opus 4.8の初期評価は、コーディングだけでなく実務型エージェント作業に広がっている。Artificial AnalysisはGDPval-AAで1890点、GPT-5.5 xhighを121点上回ったとした。
Comments (0)
No comments yet. Be the first to comment!