评估AI编程助手中的Solidity支持能力

AI驱动的代码助手（如GitHub的Copilot、Continue.dev和Tabby）正在使软件开发变得更快速、更高效。不幸的是，这些工具在Solidity方面往往表现不佳。因此，我们决定改进它们！

为了更轻松地使用AI工具编写、编辑和理解Solidity，我们采取了以下措施：

在Tabby和Continue.dev这两个本地、保护隐私的AI编程助手中添加了对Solidity的支持
创建了一个自定义代码补全评估工具CompChomper，用于评估不同模型在Solidity代码补全方面的表现

我们还评估了不同量化级别的流行代码模型，以确定哪些模型在Solidity方面表现最佳（截至2024年8月），并将它们与ChatGPT和Claude进行了比较。我们的结论是：本地模型与大型商业产品相比表现良好，甚至在某些补全风格上超越了它们。

然而，尽管这些模型很有用，特别是在原型设计方面，我们仍然要提醒Solidity开发者不要过于依赖AI助手。我们审查了使用AI辅助编写的合约，发现存在多个AI引起的错误：AI生成的代码在已知模式上运行良好，但在需要处理的实际定制场景中表现不佳。这就是为什么我们建议进行彻底的单元测试，使用Slither、Echidna或Medusa等自动化测试工具——当然，还有Trail of Bits的付费安全审计。

AI助手改进

在Trail of Bits，我们既审计也编写相当多的Solidity代码，并且会快速使用任何我们能找到的提高生产力的工具。一旦AI助手添加了对本地代码模型的支持，我们立即想要评估它们的工作效果。遗憾的是，在工具和模型层面都缺乏对Solidity语言的支持——因此我们提交了一些pull request。

Trail of Bits为Continue.dev和Tabby都添加了Solidity支持。这项工作还需要向上游贡献对tree-sitter-wasm的Solidity支持，以使其他使用tree-sitter的开发工具受益。

我们愿意为其他AI驱动的代码助手添加支持；请联系我们了解我们可以做些什么。

哪种模型最适合Solidity代码补全？

没有被基准测试的内容就不会得到关注，这意味着在大型语言代码模型中，Solidity被忽视了。Solidity在大约零个代码评估基准中存在（即使是包含22种语言的MultiPL也缺少Solidity）。可用的数据集质量也往往很差；我们查看了一个开源训练集，其中包含的.sol扩展名的垃圾文件比真正的Solidity代码还要多。

我们想要改进大型语言代码模型中的Solidity支持。然而，在改进之前，我们必须先进行测量。那么，流行的代码模型在Solidity补全方面表现如何（在我们进行这项工作时，即2024年8月）？

对于那些匆忙的人来说，先透露一下：我们测试过的最佳商业模型是Anthropic的Claude 3 Opus，而最佳的本地模型是您可以舒适运行的最大参数数量的DeepSeek Coder模型。对于某些类型的代码补全任务，本地模型也比大型商业模型更好。

我们还了解到：

量化到4位的较大模型在代码补全方面比同类型的较小模型更好
CodeLlama几乎肯定没有在Solidity上进行过训练
在这个特定用例中，Ollama中的CodeGemma支持存在微妙的问题

请继续阅读更详细的评估和我们的方法。

评估代码补全

编写一个好的评估非常困难，编写一个完美的评估是不可能的。部分出于必要性，部分为了更深入地理解LLM评估，我们创建了自己的代码补全评估工具CompChomper。

CompChomper使评估LLM在您关心的任务上的代码补全变得简单。您指定使用哪些git仓库作为数据集，以及您想要测量哪种补全风格。CompChomper提供了预处理、运行多个LLM（本地或通过Modal Labs在云端）和评分的基础设施。尽管CompChomper仅针对Solidity代码进行了测试，但它在很大程度上与语言无关，可以轻松重新用于测量其他编程语言的补全准确性。

有关CompChomper的更多信息，包括我们评估的技术细节，可以在CompChomper源代码和文档中找到。

我们测试了什么

最初我们开始评估流行的小型代码模型，但随着新模型的不断出现，我们忍不住添加了DeepSeek Coder V2 Light和Mistrals的Codestral。测试模型的完整列表是：

CodeGemma 2B, 7B（来自Google）
CodeLlama 7B（来自Meta）
Codestral 22B（来自Mistral）
CodeQwen1.5 7B（来自Qwen Team, Alibaba Group）
DeepSeek Coder V1.5 1.3B, 6.7B（来自DeepSeek AI）
DeepSeek Coder V2 Light（来自DeepSeek AI）
Starcoder2 3B, 7B（来自BigCode Project）

我们进一步评估了每个模型的多个变体。完整权重模型（16位浮点数）通过HuggingFace Transformers在本地提供服务，以评估原始模型能力。GGUF格式的8位量化（Q8）和4位量化（Q4_K_M）量化由Ollama提供服务。这些模型是开发人员可能实际使用的模型，测量不同的量化有助于我们理解模型权重量化的影响。

为了形成良好的基线，我们还评估了GPT-4o和GPT 3.5 Turbo（来自OpenAI）以及Claude 3 Opus、Claude 3 Sonnet和Claude 3.5 Sonnet（来自Anthropic）。

部分行补全结果

部分行补全基准测试测量模型完成部分代码行的准确性。您会使用这种情况的场景是当您键入函数调用时，希望模型自动填充正确的参数。以下是部分行补全的可视化表示：想象您刚刚完成键入require(。哪个模型会插入正确的代码？

1
2
3
4


function transferOwnership(address newOwnerAddress) external {
    require(                       
    _ownerAddress = newOwnerAddress
}

图1：蓝色是给模型的前缀，绿色是模型应该编写的未知文本，橙色是给模型的后缀。在这种情况下，正确的补全是msg.sender == _ownerAddress);。

部分行补全结果中最有趣的发现是，许多本地代码模型在这个任务上比大型商业模型更好。这可能通过更好的提示来改变（我们将发现更好提示的任务留给读者）。

图2：流行编码LLM的部分行补全结果。在这个测试中，本地模型的表现明显优于大型商业产品，前几名由DeepSeek Coder衍生产品主导。我们测试的本地模型专门为代码补全训练，而大型商业模型则为指令跟随训练。（最高分=98。）

整行补全

整行补全基准测试测量模型在给定前一行和下一行的情况下完成整行代码的准确性。您会使用这种情况的场景是当您键入函数名称时，希望LLM填充函数体。这种基准测试风格通常用于测试代码模型的中间填充能力，因为完整的前行和下行上下文减轻了使代码补全评估困难的白空格问题。以下是此任务的可视化表示。

1
2
3
4


function transferOwnership(address newOwnerAddress) external {
                                         
    _ownerAddress = newOwnerAddress;
}

图3：蓝色是给模型的前缀，绿色是模型应该编写的未知文本，橙色是给模型的后缀。在这种情况下，正确的补全是：require(msg.sender == _ownerAddress);。

大型模型在这个任务中领先，Claude3 Opus以微弱优势击败ChatGPT 4o。然而，最佳的本地模型与最佳托管商业产品非常接近。本地模型的能力差异很大；其中，DeepSeek衍生产品占据了前几名。

图4：流行编码LLM的整行补全结果。虽然商业模型刚刚略微超过本地模型，但结果非常接近。（最高分=98。）

我们学到了什么

总体而言，最佳的本地模型和托管模型在Solidity代码补全方面表现相当不错，而且并非所有模型都是平等的。我们还了解到，对于这个任务，模型大小比量化级别更重要，更大但更多量化的模型几乎总是击败更小但更少量化的替代方案。

表现最好的是DeepSeek coder的变体；最差的是CodeLlama的变体（显然根本没有在Solidity上训练过）和通过Ollama的CodeGemma（看起来在运行时出现了某种灾难性故障）。

看到我们的结果，可能会诱使人们得出结论认为LLM可以生成好的Solidity代码。请不要这样做！代码生成是与代码补全不同的任务。在我们看来，除了智能自动补全之外，使用AI辅助仍然是一个严重的风险。如前所述，LLM中的Solidity支持往往是事后才考虑的，而且缺乏训练数据（与Python等相比）。尚未创建的模式或构造还不能由LLM可靠地生成。这不是一个假设性问题；我们在审计过程中遇到了AI生成代码中的错误。

一如既往，即使是人类编写的代码，也没有替代严格的测试、验证和第三方审计的方法。

下一步是什么

既然我们既有了一套适当的评估，又有了性能基线，我们将微调所有这些模型，使它们在Solidity方面表现更好！这个过程已经在进行中；一旦完成，我们会立即向大家更新经过Solidity语言微调的模型。

如果您喜欢这篇文章，请分享： Twitter LinkedIn GitHub Mastodon Hacker News

深入评测AI编程助手对Solidity的支持能力

本文详细评测了多种AI编程助手对Solidity语言的支持能力，包括本地模型与商业模型的对比分析，并介绍了自定义评估工具CompChomper的开发和使用方法，为区块链开发者提供实用参考。