当大语言模型过度回答：测量与缓解基于LLM的硬件描述语言问答中的质量问题

# 当大语言模型过度回答：测量与缓解基于LLM的硬件描述语言问答中的质量问题

来源：https://arxiv.org/html/2607.17063
2nd贾晨3rd吕文浩4th张欢5th夏英杰11通讯作者。

###### 摘要

大语言模型（LLMs）的快速发展使从业者越来越依赖它们来回答关于硬件描述语言（HDLs）的问题。由于HDL最终会被综合为物理硬件，一个不精确或冗余的答案可能会传播为时序违例或不可综合的逻辑，这些问题要到设计流程后期才会显现，这使得HDL答案的质量尤其重要。然而，LLM生成答案的质量，特别是与人类专家提供的答案相比，仍然不明确。为探究这一问题，我们收集了来自Stack Overflow的6,246个带已采纳答案的HDL问答帖，并将其整理为一个数据集，按四类主要类别（概念类、调试类、生成类、优化类）和十类子类别的分类法进行组织。利用该数据集，我们设计了一项由19名具有1-3年经验的HDL工程师参与的用户研究。我们的发现揭示了一种普遍的“过度回答”倾向：LLM提供正确的内容，但将其埋没在冗余的替代方案（65.7%）和冗长的填充（69.1%）中，同时近一半的答案（49.0%）未能完全与专家答案一致——然而参与者仍因可读性（58.3%）而偏好LLM的回答。受这些发现启发，我们提出了一种用于改进基于LLM的HDL问答的多智能体框架。该框架采用多角色智能体辩论来消除核心内容中的冗余，以及类别特定的细化来改善非核心内容的简洁性。我们使用LLM作为评判器以及两种结构指标来评估答案质量：核心答案数量（反映冗余，因为LLM常提供多个替代方案）和非核心内容长度（反映冗长）。在四个主流LLM上的评估结果显示，我们的框架将核心答案的平均质量分数从3.71提升到4.67（+0.96），非核心内容质量从3.72提升到4.23（+0.51）（按五分制）。同时，核心答案数量平均减少37%，非核心内容长度平均减少31%。这些结果表明，任务感知的细化可以生成更简洁、更聚焦的HDL答案，同时提高其核心技术质量。

## I 引言

参考图1图1：LLM生成的答案与针对一个Verilog问题的已采纳答案之间的质量差距示例。人类专家集中于一个决定性的解决方案，而LLM则提供多个替代答案进行规避（冗余，根据我们的用户研究为65.7%），并在回答中填充不必要的背景和总结（冗长，69.1%）。

硬件描述语言在硬件设计中扮演核心角色，因为用这些语言编写的代码直接决定了寄存器传输级（RTL）系统的正确性和行为[17](https://arxiv.org/html/2607.17063#bib.bib45)。工程师传统上依赖诸如Stack Overflow[11](https://arxiv.org/html/2607.17063#bib.bib22)等问答平台来解决设计、调试和优化挑战。然而，随着大语言模型的出现，越来越多的工程师转向LLM寻求帮助[14](https://arxiv.org/html/2607.17063#bib.bib20)，[28](https://arxiv.org/html/2607.17063#bib.bib21)。随着LLM生成流畅回答的能力日益增强，一个重要的问题随之产生：LLM生成的答案与人类专家在真实HDL问答中提供的已采纳答案有何不同？图1给出了一个Verilog调试问题的例子。人类专家提供一个单一、针对性的解决方案，而LLM返回几个答案，随后是解决问题所不需要的背景信息。我们将这种冗余替代方案和冗长填充的结合称为“过度回答”——LLM并非无法回答，而是回答得太多。

然而，评估一个问题答案的质量并不容易。现有关于LLM用于HDL的工作主要针对代码生成[12](https://arxiv.org/html/2607.17063#bib.bib30)，[22](https://arxiv.org/html/2607.17063#bib.bib23)]和功能正确性，通常通过仿真[21](https://arxiv.org/html/2607.17063#bib.bib24)]或基于综合的指标[24](https://arxiv.org/html/2607.17063#bib.bib25)，[29](https://arxiv.org/html/2607.17063#bib.bib41)]进行评估。然而，现实世界的HDL问答本质上是开放式的：即使一个功能上正确的答案，如果冗长或与专家实践不一致，对工程师的价值也可能有限。因此，答案的质量不仅取决于功能正确性，还取决于多个方面，如冗余度、简洁性、可读性和工程实用性[9](https://arxiv.org/html/2607.17063#bib.bib15)——这些维度在HDL背景下很大程度上仍未得到探索。

为填补这一空白，本文分为两部分进行组织。

**用户研究。**我们进行用户研究以表征LLM生成的答案与Stack Overflow上人类专家提供的已采纳答案之间的质量差距。我们构建了一个包含6,246个Stack Overflow HDL问题及其相应已采纳答案的数据集。根据先前关于LLM用于HDL的工作[39](https://arxiv.org/html/2607.17063#bib.bib11)，问题被分为四个任务类别（概念类、调试类、生成类、优化类）和十个细粒度子类别。利用该数据集，19名具有1-3年经验的Verilog和硬件工程师从可读性、冗余度、简洁性以及与已采纳答案的一致性这四个维度对LLM生成的答案和已采纳答案进行评估。

用户研究揭示了一个多维度的质量差距。我们发现，65.7%的LLM回答在其“核心答案”（直接回答问题的部分）中表现出冗余，即提供多个替代方案；而69.1%的回答填充了问题并未要求的“非核心内容”（背景、重述和总结）。此外，在49.0%的案例中，LLM答案并未完全覆盖已采纳答案。尽管存在这些局限，在58.3%的评估问题中，参与者仍偏好LLM生成的答案的可读性，而非相应的已采纳答案。这些发现表明，LLM并非单纯比人类专家差；相反，它们呈现出一种不同的质量特征：更具可读性和解释性，但也更冗余、更冗长，且与已采纳答案的一致性更低。

**任务感知多智能体框架。**受上述发现启发，我们提出了一种任务感知的多智能体细化框架。在任务类别的指导下，该框架首先对每个问题进行剖析，推断其任务类型、用户意图和验证需求，然后使用多角色智能体辩论消除核心答案中的冗余，并使用类别特定的细化来减少非核心内容中的冗长。由于核心答案是联合进行审查的，辩论不仅剔除不正确的候选答案，也剔除那些仅仅重新包装了更强解决方案的衍生答案，同时保留任务关键性材料，仅移除可有可无的背景和总结。

我们在四个主流LLM上评估了我们的框架。该框架将核心答案的平均质量从3.71提升到4.67（+0.96），非核心内容质量从3.72提升到4.23（+0.51）（按五分制），同时核心答案数量减少37%，非核心内容长度减少31%。这些提升在所有四个骨干模型和四个任务类别上均保持，表明改进源于结构化解构和辩论，而非任何单一模型或任务。进一步的一致性分析显示，细化保持或略微提升了与已采纳答案的一致性，证实答案数量的减少来自丢弃非必要内容，而非削减实质性信息。

总之，本文作出以下贡献：

- • 我们与19名Verilog和硬件工程师进行了一项实证用户研究，揭示了一个多维度的质量差距。
- • 我们提出了一种任务感知的多智能体细化框架，该框架消除核心答案中的冗余并减少非核心内容中的冗长，在保持与已采纳答案一致性的同时提高答案质量。
- • 我们将由6,246个真实世界HDL问答对及其已采纳答案组成的数据集以及框架的源代码发布在 https://github.com/ZitengHu/HDLQA，以促进进一步研究。

## II 背景

### II-A 硬件描述语言开发

硬件描述语言在寄存器传输级对数字电路进行建模、仿真和综合[27](https://arxiv.org/html/2607.17063#bib.bib43)。最广泛采用的两种语言，Verilog和VHDL，分别被标准化为IEEE 1364[16](https://arxiv.org/html/2607.17063#bib.bib44)]和IEEE 1076[18](https://arxiv.org/html/2607.17063#bib.bib12)]，SystemVerilog作为设计和验证的超集扩展了Verilog。与通用代码不同，HDL最终会被综合为物理硬件，对正确性、时序和可综合性施加了严格要求[17](https://arxiv.org/html/2607.17063#bib.bib45)。典型的工作流程涵盖设计、仿真、调试和优化[27](https://arxiv.org/html/2607.17063#bib.bib43)]，这些任务在认知需求上差异显著——从概念问题的语言语义，到调试的因果推理[33](https://arxiv.org/html/2607.17063#bib.bib31)，[35](https://arxiv.org/html/2607.17063#bib.bib32)]，到符合可综合标准的代码生成[21](https://arxiv.org/html/2607.17063#bib.bib24)，[24](https://arxiv.org/html/2607.17063#bib.bib25)]，以及针对时序-资源权衡的优化[37](https://arxiv.org/html/2607.17063#bib.bib28)]。

### II-B 实践中的HDL问答

由于HDL会被综合为硬件，一个错误的答案可能会传播为时序违例或不可综合的逻辑，这些问题要到设计流程后期才会显现[27](https://arxiv.org/html/2607.17063#bib.bib43)，[6](https://arxiv.org/html/2607.17063#bib.bib42)]。工程师长期以来依赖如Stack Overflow等问答平台，其中提问者认可的“已采纳答案”作为同行验证的参考[11](https://arxiv.org/html/2607.17063#bib.bib22)]。HDL问题与工具行为、标准合规性和硬件语义紧密相关[16](https://arxiv.org/html/2607.17063#bib.bib44)，[39](https://arxiv.org/html/2607.17063#bib.bib11)]，因此一个有用的答案不仅要正确，还必须与已有实践一致。随着工程师越来越多地使用LLM来替代这些平台[28](https://arxiv.org/html/2607.17063#bib.bib21)，[14](https://arxiv.org/html/2607.17063#bib.bib20)]，答案的价值不仅取决于功能正确性，还取决于它是否简洁、聚焦，并且与专家回答的方式一致——这些是代码生成指标如VerilogEval和RTLLM所未能捕捉的[21](https://arxiv.org/html/2607.17063#bib.bib24)，[24](https://arxiv.org/html/2607.17063#bib.bib25)]。这促使我们研究HDL答案的“交际”质量作为一个独特的问题。

表 I: HDL Q&A 任务的分布与定义
| 主类别 | 子类别 | 描述 | 实例数量 | 排名 |
| :--- | :--- | :--- | :--- | :--- |
| \rowcolorgray!20 概念类 (2,009) | syntax-explanation | 语言结构、语义或编码规则[6](https://arxiv.org/html/2607.17063#bib.bib42)。 | 1,450 | 2 |
| | tool-usage | 操作EDA工具链并解释其消息[27](https://arxiv.org/html/2607.17063#bib.bib43)。 | 559 | 4 |
| 调试类 (3,139) | functional-error | 能够编译，但行为偏离规范[35](https://arxiv.org/html/2607.17063#bib.bib32)。 | 1,452 | 1 |
| | syntax-error | 违反HDL语法；无法编译或实例化[33](https://arxiv.org/html/2607.17063#bib.bib31)。 | 1,189 | 3 |
| | synthesis-error | 仿真正确但不可综合[6](https://arxiv.org/html/2607.17063#bib.bib42)。 | 498 | 5 |
| \rowcolorgray!20 生成类 (630) | logic-generation | 面向控制或结构的RTL（例如，FSMs，解码器）[21](https://arxiv.org/html/2607.17063#bib.bib24)。 | 488 | 6 |
| | arithmetic-generation | 数据通路或算术硬件（例如，加法器，乘法器）[24](https://arxiv.org/html/2607.17063#bib.bib25)。 | 142 | 9 |
| 优化类 (468) | readability-optimization | 不改变功能的重构以提高清晰度[27](https://arxiv.org/html/2607.17063#bib.bib43)。 | 191 | 7 |
| | ppa-optimization | 改善功耗、性能或面积[29](https://arxiv.org/html/2607.17063#bib.bib41)。 | 152 | 8 |
| | security-optimization | 针对硬件级威胁的加固[8](https://arxiv.org/html/2607.17063#bib.bib39)，[15](https://arxiv.org/html/2607.17063#bib.bib40)。 | 125 | 10 |
### II-C HDL任务类型

先前关于LLM用于HDL的工作按照重复出现的线索组织了硬件任务[39](https://arxiv.org/html/2607.17063#bib.bib11)——从规范到RTL的生成[21](https://arxiv.org/html/2607.17063#bib.bib24)，[24](https://arxiv.org/html/2607.17063#bib.bib25)]、调试和修复[33](https://arxiv.org/html/2607.17063#bib.bib31)，[35](https://arxiv.org/html/2607.17063#bib.bib32)]、涵盖验证和问答的更广泛工作流[30](https://arxiv.org/html/2607.17063#bib.bib27)]，以及针对功耗、性能和面积的优化[29](https://arxiv.org/html/2607.17063#bib.bib41)，[22](https://arxiv.org/html/2607.17063#bib.bib23)]。基于这些区分，我们将HDL问题分为四个主要类别——*概念类*、*调试类*、*生成类*和*优化类*——涵盖十个子类别，其定义和分布总结于表I。

## III 用户研究：LLM与人类专家之间的质量差距

为研究LLM生成的答案与HDL问答帖中已采纳答案之间的质量差异，我们遵循图2所示的流程。具体来说，我们收集带有已采纳答案的Stack Overflow帖子，通过关键词（例如，Verilog、SystemVerilog、VHDL）筛选出HDL相关的帖子，并设计一个涵盖概念类、调试类、生成类和优化类类别的任务分类法，以及用于LLM分类的标注规则。我们在363个问题的分层样本上验证了该分类法和规则，根据观察到的分歧完善了模糊规则，然后将完善的分类器应用于所有6,246个问题以进行下游分析。

参考图2图2：构建和标注HDL Q&A数据集的流程。我们首先收集HDL相关帖子。然后，设计初始分类法和规则，通过人工验证验证和完善它们，然后将最终确定的规则用于大规模LLM分类。

### III-A 数据收集与处理

#### III-A1 Stack Overflow帖子

我们使用公共Stack Overflow数据转储，这是一个累积快照，包含从网站建立到转储发布日期（[2025-06-30]版本）的所有帖子。从这个快照中，我们仅保留具有人类专家提供的已采纳答案的问题，因为已采纳答案为开发人员如何解决实际问题提供了实用的参考。对于每个这样的帖子，我们提取了问题标题、正文、标签、代码片段、已采纳答案、答案/问题分数、创建时间和其他元数据。