LLM 在处理 Python 方面很有帮助，但其他所有编程语言呢？

最近，许多人声称他们的 LLM 在编码方面表现最佳。他们的说法通常基于 HumanEval 基准测试中的自我报告评估。但当你深入了解这个基准测试时，你会意识到它只包含 164 个 Python 编程问题。这让我陷入了一个试图弄清楚 LLM 对不同语言的帮助程度的探索之旅。在这篇文章中，我试图根据 2023 年 Stack Overflow 开发者调查，对 38 种最常用的编程、脚本和标记语言进行估算。

方法

这不是一个容易回答的问题。我试图通过收集和审查多语言基准测试结果、公共数据集构成、现有的 GitHub 和 Stack Overflow 数据以及开发人员的奇闻轶事来大致了解情况。你可以在这里找到所有这些数据。

多语言基准测试结果

我查看了 MultiPL-E、BabelCode / TP3、 MBXP / Multilingual HumanEval 和 HumanEval-X 多语言基准测试。这些基准测试是将 HumanEval 和 MBPP 基准测试中的 Python 问题翻译成不同的语言，因此它们可能也无法特别代表开发者试图使用 LLM 的真实世界情况。此外，这些基准测试各自在一组不同的 LLM 上比较它们自己的编程语言子集。总而言之，仅使用基准测试评估很难回答这个问题。

公共数据集构成

我审查了 The Stack、CodeParrot、AlphaCode、CodeGen 和 PolyCoder 数据集的构成。我试图了解每种语言在用于训练模型的数据集中的代表性程度。然而，许多 LLM 创建者并不分享他们使用的数据。因此，这些公共数据集与更常见的私有数据集有多大代表性是未知的，但我预计会存在一些相似之处。数据的质量也可能因语言而异，即使数据量相似（例如，有些语言比其他语言更冗长）。

现有的 GitHub 和 Stack Overflow 数据

我从 GitHut 2.0 下载了数据，它试图通过汇总托管仓库上的事件和互动来分析 GitHub 上各种语言的使用情况。我还获取了 Stack Overflow 上用每种语言标记的问题数量。由于许多训练数据集不公开，我使用这些数据来更好地估计每种语言相对于其他语言的可用数据量。但这些数据只是一个粗略的近似值，因为 GitHub 只显示 pull request、issue、star 和 push 的数量，而许多 Stack Overflow 问题可能没有用其编程语言进行标记。

开发者反馈

我在 Reddit 上专门针对各种语言的 subreddits 中阅读了许多关于在编码时使用 LLM 的观点。尽管这些评论在比较不同语言时很难使用，但我从每个 subreddit 中挑选了一些引起我注意的评论，并将其也包含在数据中。

如何让 LLM 对更多语言更有帮助

在我们查看每种语言之前，重要的是要注意我们并非束手无策。有可能让 LLM 对更多语言更有帮助。实际上，我看到了三个主要机会

更好的基准测试

我们能采取的最重要的行动，以使 LLM 对更多语言更有帮助，可能是建立包含更多语言并在更广泛的任务范围上评估它们的基准测试。一旦做到这一点，我们将能更好地了解 LLM 对不同语言的帮助程度。这将清楚地显示出 LLM 在哪些方面表现不足，不仅针对特定语言，也针对开发者想要使用 LLM 的特定情况。

更好的数据集

我们可以采取的另一个重要行动，以使 LLM 对更多语言更有帮助，是收集包含在许多不同代表性情境中使用的更多语言的数据集。这些模型是根据其数据集学习的。也就是说，模型的行为很大程度上取决于用于训练它的数据集。因此，如果我们希望 LLM 对更多语言更有帮助，创建更好的数据集至关重要。

更好的模型

数据集和基准测试是模型性能的一些最大驱动因素。如果我们能推动针对更多语言的更好的基准测试和数据集，那将为我们推动对更多语言更有帮助的模型做好准备。此外，还可以训练或微调 LLM 以使其专门用于特定语言。更好的基准测试和数据集对此也将至关重要。

分层

查看数据后，我将所有语言分为四个层级，其中第一层包括 LLM 可能最有帮助的语言，第四层包括 LLM 可能最不有帮助的语言。话虽如此，LLM 对特定语言的帮助程度很大程度上取决于具体情况、开发者、LLM 本身、上下文以及许多其他因素。

第一层

C++

C++ 在 GitHub 和 Stack Overflow 上的存在感最大之一。这体现在它在公共 LLM 数据集中的代表性上，它是数据量最多的语言之一。它的性能在 MultiPL-E、BabelCode / TP3、MBXP / Multilingual HumanEval 和 HumanEval-X 基准测试中位居前列。然而，考虑到 C++ 通常用于对代码性能和精确算法实现要求非常高的情况，许多开发者认为 LLM 对 C++ 的帮助不如这一层级中的其他一些语言。

Java

LLM 在处理 Java 时的性能在 BabelCode / TP3、MBXP / Multilingual HumanEval、MultiPL-E 和 HumanEval-X 基准测试中位居前列。在公共 LLM 数据集中，关于它的数据比任何其他语言都多，并且它在 GitHub 和 Stack Overflow 上的存在感最大之一。话虽如此，开发者经常认为 LLM 在处理 Java 方面的帮助不如处理 JavaScript、Python 和 TypeScript。

JavaScript

JavaScript 在 GitHub 和 Stack Overflow 上的存在感最大之一。这也在其在公共 LLM 数据集中的代表性上有所体现，它是数据量最多的语言之一。正如预期，它在 MBXP / Multilingual HumanEval、BabelCode / TP3、MultiPL-E 和 HumanEval-X 基准测试中的性能也位居前列。许多开发者将其视为 LLM 最有帮助的语言之一。

PHP

LLM 在处理 PHP 时的性能在 BabelCode / TP3、MultiPL-E 和 MBXP / Multilingual HumanEval 基准测试中位居前列。它未包含在 HumanEval-X 基准测试中。它在 GitHub 和 Stack Overflow 上的存在感最大之一，并且是公共 LLM 数据集中数据量最多的语言之一。尽管如此，开发者通常不认为 LLM 在处理 PHP 方面的帮助能与 JavaScript、Python 和 TypeScript 相媲美。

Python

Python 在 GitHub 和 Stack Overflow 上的存在感最大之一。但令人惊讶的是，它在公共 LLM 数据集中的代表性不如这一层级中的其他一些语言。话虽如此，它在所有多语言基准测试中都位居前列。这并不奇怪，因为所有这些多语言基准测试都包含 HumanEval 数据集中的手写 Python 问题，几乎所有 LLM 创建者都使用这些问题来评估其 LLM 的代码能力。

TypeScript

与第一层级中的其他语言相比，TypeScript 在 GitHub 和 Stack Overflow 上的存在感以及在公共 LLM 数据集中的代表性都不那么大。然而，它是 MBXP / Multilingual HumanEval、BabelCode / TP3 和 MultiPL-E 基准测试中的顶级语言之一。它未包含在 HumanEval-X 基准测试中。一些人推测，它与 JavaScript 的相似性使得 LLM 在处理它时表现得比你预期的要好得多。

第二层

C

可以说 C 应该包含在第一层级中。它是公共 LLM 数据集中代表性最强的语言之一，在 GitHub 和 Stack Overflow 上有很高的存在感，并且与 C++ 相似。然而，它未包含在任何多语言基准测试中。它也经常用于对代码性能和精确算法实现要求非常重要的情况，因此开发者普遍认为 LLM 对 C 的帮助不大。

CSS

CSS 是一种样式表语言，与标记语言 HTML 一起使用。它未包含在多语言基准测试中。目前用于评估 LLM 在其他语言上表现的方法可能不适用于 CSS。话虽如此，它在 GitHub 和 Stack Overflow 上有很高的存在感，并且在公共 LLM 数据集中的代表性也相当大。

C#

LLM 在 MultiPL-E、MBXP / Multilingual HumanEval 和 BabelCode / TP3 基准测试中对 C# 的表现不如第一层级中的语言。它也未包含在 HumanEval-X 基准测试中。然而，它在公共 LLM 数据集中有很大的代表性，并且在 GitHub 和 Stack Overflow 上也有很高的存在感。

Go

LLM 在 MBXP / Multilingual HumanEval、BabelCode / TP3、MultiPL-E 和 HumanEval-X 基准测试中对 Go 的表现低于第一层级中的语言。它在 GitHub 和 Stack Overflow 上有相当大的存在感，同时在公共 LLM 数据集中也有相当可观的代表性。

HTML

与 CSS 类似，HTML 未包含在任何多语言基准测试中，并且目前用于评估 LLM 在其他语言上表现的方法可能不适用于 HTML。这是因为它是一种标记语言。但与 CSS 一样，它在 GitHub 和 Stack Overflow 上有很高的存在感，并且在公共 LLM 数据集中的代表性也相当大。

Ruby

LLM 在 MBXP / Multilingual HumanEval 和 MultiPL-E 基准测试中对 Ruby 的表现低于第一层级中的语言。它未包含在 BabelCode / TP3 和 HumanEval-X 基准测试中。它在公共 LLM 数据集中的代表性相当大，并且在 GitHub 和 Stack Overflow 上有很高的存在感。

第三层

第三层级中的语言在 GitHub 和 Stack Overflow 上的存在感通常小于前两个层级中的语言。它们在公共 LLM 数据集中的代表性也往往较小。

Bash

LLM 在 MultiPL-E 基准测试中对 Bash 的表现接近底部。它未包含在其他三个多语言基准测试中。

Haskell

LLM 在 BabelCode / TP3 基准测试中对 Haskell 的表现接近底部。它未包含在其他三个多语言基准测试中。

Julia

LLM 在 BabelCode / TP3 和 MultiPL-E 基准测试中对 Julia 的表现接近底部。它未包含在其他两个多语言基准测试中。

Lua

LLM 在 BabelCode / TP3 和 MultiPL-E 基准测试中对 Lua 的表现接近底部。它未包含在其他两个多语言基准测试中。

Perl

LLM 在 MultiPL-E 和 MBXP / Multilingual HumanEval 基准测试中对 Perl 的表现接近底部。它未包含在其他两个多语言基准测试中。

PowerShell

PowerShell 未包含在任何多语言基准测试中。

Rust

LLM 在 BabelCode / TP3 和 MultiPL-E 基准测试中对 Rust 的表现接近底部。它未包含在其他两个多语言基准测试中。

Scala

LLM 在 MultiPL-E 和 MBXP / Multilingual HumanEval 基准测试中对 Scala 的表现优于大多数其他语言。它未包含在其他两个多语言基准测试中。

SQL

SQL 未包含在任何多语言基准测试中。

Swift

LLM 在 MultiPL-E 和 MBXP / Multilingual HumanEval 基准测试中对 Swift 的表现接近底部。它未包含在其他两个多语言基准测试中。

VBA

VBA 未包含在任何多语言基准测试中。

第四层

第四层级中的许多语言的情况都非常相似。除了下面提到的一些例外，这些语言未包含在任何四个多语言基准测试中。Delphi 和 Solidity 似乎未包含在任何公共 LLM 数据集中，而其余语言（汇编语言除外）似乎在 The Stack 中有非常小但未指定的代表性，在任何其他公共 LLM 数据集中都没有代表性。所有这些语言在 GitHub 和 Stack Overflow 上的存在感在所有被调查的语言中都属于最小的。

Assembly

Assembly 在 The Stack 和 CodeParrot 数据集中有少量代表性。然而，Assembly 是处理器 ISA 的人类可读表示的通用术语，而不是单一语言。存在许多汇编语言，甚至同一 ISA 的不同表示。这是开发者表示 LLM 在编写汇编语言时帮助不大的一个重要因素。

Clojure

Dart

LLM 在 BabelCode / TP3 基准测试中对 Dart 进行了评估，但表现接近底部。

Delphi

Elixir

Erlang

GDScrip

Groovy

Kotlin

LLM 在 MBXP / Multilingual HumanEval 基准测试中对 Kotlin 进行了评估，但表现接近底部。

Lisp

MATLAB

Objective-C

R

LLM 在 MultiPL-E 和 BabelCode / TP3 基准测试中对 R 进行了评估，但表现接近底部。

Solidity

VB.NET

结论

许多开发者在编码时对使用 LLM 仍然持相当怀疑的态度，无论他们使用的是何种编程语言。有些人甚至表示他们很难看出 LLM 有何用处。尽管如此，越来越多的开发者已经找到了如何从 LLM 中获益的方法，并表示经常使用它们。

但即使在这些人中，关于何时、何地以及如何使用 LLM 也有许多不同的看法。例如，有人说 LLM 在学习一门语言时非常有用，而另一些人则说在你成为一门语言的专家之前不要接触它们。事实可能介于两者之间，因为它确实取决于你最佳的学习方式以及你在学习时如何使用 LLM。

要让开发者在编码时轻松利用 LLM，我们还有很长的路要走，尤其因为 LLM 在某些情况下会自信地编造内容，开发者需要自行判断是否遵循建议或完全避免在这些情况下使用 LLM。对于那些设法可靠地克服这一挑战的人来说，他们对 LLM 的前景感到非常兴奋，并期望它们随着时间的推移会变得更好。