StarCoder：愿源代码与你同在！

Raymond Li², Loubna Ben Allal¹, Yangtian Zi⁴, Niklas Muennighoff¹, Denis Kocetkov², Chenghao Mou, Marc Marone, Christopher Akik⁹,¹⁰, Jia Li⁵, Jenny Chim¹, Qian Liu¹³, Evgenii Zheltonozhskii¹⁴, Terry Yue Zhuo¹⁵,¹⁶, Thomas Wang¹, Olivier Dehaene¹, Mishig Davaadorj¹, Joel Lamy-Poirier², Joao Monteiro², Oleh Shliazhko², Nicolas Gontier², Nicholas Meade⁶,¹⁷, Armel Zebaze¹, Ming-Ho Yee⁴, Logesh Kumar Umapathi¹⁸, Jian Zhu¹⁹, Benjamin Lipkin²⁰, Muhtasham Oblokulov²¹, Zhiruo Wang⁷, Rudra Murthy²², Jason Stillerman²³, Siva Sankalp Patel²², Dmitry Abulkhanov⁵, Marco Zocca²⁴, Manan Dey²⁵, Zhihan Zhang²⁶, Nour Fahmy²⁷, Urvashi Bhattacharyya²⁸, Wenhao Yu²⁶, Swayam Singh³⁰, Sasha Luccioni¹, Paulo Villegas³¹, Maxim Kunakov³², Fedor Zhdanov³², Manuel Romero⁵, Tony Lee³³, Nadav Timor³⁴, Jennifer Ding³⁵, Claire Schlesinger⁴, Hailey Schoelkopf³⁷, Jan Ebert³⁸, Tri Dao³³, Mayank Mishra²², Alex Gu²⁰, Jennifer Robinson³, Carolyn Jane Anderson³⁶, Brendan Dolan-Gavitt²⁹, Danish Contractor⁵, Siva Reddy²,⁶, Daniel Fried⁷, Dzmitry Bahdanau², Yacine Jernite¹, Carlos Munoz Ferrandis¹, Sean Hughes³, Thomas Wolf¹, Arjun Guha⁴,¹², Leandro von Werra¹,, Harm de Vries²,

¹Hugging Face ²ServiceNow Research ³ServiceNow ⁴Northeastern University ⁵Independent ⁶Mila ⁷Carnegie Mellon University ⁸Johns Hopkins University ⁹Leipzig University ¹⁰ScadS.AI ¹¹Queen Mary University of London ¹²Roblox ¹³Sea AI Lab ¹⁴Technion - Israel Institute of Technology ¹⁵Monash University ¹⁶CSIRO's Data61 ¹⁷McGill University ¹⁸Saama AI Research Lab ¹⁹University of British Columbia ²⁰MIT ²¹Technical University of Munich ²²IBM Research ²³University of Vermont ²⁴UnfoldML ²⁵SAP ²⁶University of Notre Dame ²⁷Columbia University ²⁸Discover Dollar Pvt Ltd ²⁹NYU ³⁰University of Allahabad ³¹Telefonica I+D ³²Toloka ³³Stanford University ³⁴Weizmann Institute of Science ³⁵The Alan Turing Institute ³⁶Wellesley College ³⁷Eleuther AI ³⁸Forschungszentrum Jülich

通讯作者 (*) 可通过 contact@bigcode-project.org 联系

在OpenReview上审阅：https://openreview.net/forum?id=KoF0g41haE

摘要

BigCode社区，一个致力于负责任地开发大型代码语言模型（Code LLMs）的开放科学协作组织，推出了StarCoder和StarCoderBase：具有80亿（注：原文为15.5B，即155亿）参数、8K上下文长度、填充能力以及通过多查询注意力实现快速大批量推理的模型。StarCoderBase的训练数据源自The Stack (Kocetkov et al., 2022)，这是一个包含一万亿token的大型数据集，该数据集收集自具有宽松许可证的GitHub代码库，并配备了检查工具和退出流程。我们在StarCoderBase的基础上，使用350亿Python token进行了微调，从而创建了StarCoder。我们进行了迄今为止最全面的代码LLM评估，结果表明，StarCoderBase在所有支持多编程语言的开源代码LLM中表现最佳，并匹配或超越了OpenAI的code-cushman-001模型。此外，StarCoder在所有经过Python微调的模型中表现最优，同时仍保持了在其他编程语言上的性能。我们采取了几项重要步骤以实现安全的开放访问模型发布，包括改进的PII（个人身份信息）编辑流程和新颖的归因追踪工具，并根据更具商业可行性的开放责任AI模型许可版本，公开发布了StarCoder模型。

1 引言

生成式AI和大语言模型（LLMs；Brown et al., 2020; Chen et al., 2021; Chowdhery et al., 2022; Zhang et al., 2022; OpenAI, 2023a）预计将通过提高工作效率，在未来几年显著影响劳动力市场 (Eloundou et al., 2023; Bommasani et al., 2021; World Economic Forum, 2023)。在代码上训练的大语言模型（Code LLMs）的采用速度尤其快：微软的Copilot已经吸引了超过100万专业开发者 (Euronews, 2023)，GitHub报告称，Copilot用户在某些语言中编写的代码有35%依赖该工具生成 (Thompson, 2022)。然而，LLMs的开发和使用引发了关于版权、隐私和开放性的担忧。

在美国和欧盟等许多司法管辖区，关于用于训练语言模型的公共数据创作者的权利，引发了版权方面的担忧。人们质疑在此类数据上训练的机器学习模型是否符合美国的合理使用原则 (Kuhn, 2022; Butterick, 2022; Rothchild & Rothchild, 2022)，而最可能适用合理使用的情况是模型生成的内容是新颖的，与任何受版权保护的训练数据都不相似 (Lemley & Casey, 2020; Levendowski, 2018)。因此，Henderson et al. (2023) 建议LLM开发者应提供额外工具以确保这些模型符合现行版权法。值得一提的是，这些法律问题不仅仅是学术争论的主题：针对GitHub Copilot (DOE 1 v. and GitHub, Inc., 2022) 以及Stable Diffusion (Andersen et al v. Stability AI et al, 2023) 的诉讼已经提起。

对个人信息的担忧导致意大利暂时封禁了ChatGPT，并对OpenAI是否符合欧盟通用数据保护条例（GDPR）展开了调查 (BBC, 2023)。根据这些法规 (European Council, 2018; Lomas, 2022)，处理个人信息的组织必须拥有有效的法律依据。这些法律可能会影响那些从互联网收集海量公开数据（其中可能包含个人信息）的LLM开发者。在此规模下，获得数据创作者的明确同意很困难，且处理这些个人信息是否存在其他法律依据尚不确定。此外，即使有有效的法律依据，GDPR要求数据处理者告知个人其数据是如何被处理的，并提供数据访问控制，例如删除数据或修改错误数据的权利。这将要求LLM提供商对其收集的数据保持透明，并为个人提供检查其数据并可能将其删除的工具。

围绕生成式AI模型开发过程缺乏透明度和开放性的问题也引起了科学界的关注。许多模型在不同程度上是封闭访问的：从仅在组织内部可用 (Chowdhery et al., 2022; Hoffmann et al., 2022)，到通过付费API公开访问但开发过程的许多细节被隐藏 (Brown et al., 2020; OpenAI, 2023a)。虽然API访问允许研究人员实验这些模型，但限制了他们研究LLM安全性 (Perez et al., 2022)、检查模型内部工作原理 (Olsson et al., 2022) 以及为模型改进做出贡献的能力 (Togelius & Yannakakis, 2023)。

我们使用“开放访问”来指代其权重公开的模型。尽管存在其他开放访问模型，但这些项目的开放程度仍然各不相同；一些发布权重的模型对分发有限制 (Touvron et al., 2023)，或者不发布其训练数据集 (Nijkamp et al., 2023; Zhang et al., 2022; Fried et al., 2022)。即使在模型和训练数据都以宽松许可证发布的情况下 (Raffel et al., 2020; Tay et al., 2022)，外部研究人员通常也没有机会参与指导行业生产模型的开发。相比之下，其他LLM开发项目采取了完全开放的方法，旨在允许社区输入到模型开发中，发布训练数据，并在整个开发过程中实现外部审计 (Solaiman, 2023)。一个例子是BigScience研究研讨会 (BigScience Workshop, 2022)，这是一个开放的科研协作组织 (Akiki et al., 2022)，由数百名研究人员组成，合作发布了多语言LLM BLOOM (Scao et al., 2022; Muennighoff et al., 2022)。类似地，EleutherAI，一个由草根转变为非营利性的研究组织，已经发布了开放访问的LLM，包括GPT-NeoX (Black et al., 2022)、GPT-J (Wang & Komatsuzaki, 2021) 和Pythia (Biderman et al., 2023)，以及相关的训练数据 (Gao et al., 2021a)。

在本文中，我们描述了由BigCode社区开发和发布的开放访问代码LLM——StarCoder和StarCoderBase，重点关注尊重版权、隐私、透明度和社区驱动的模型开发。该项目是一个开放的科研协作，专注于负责任地开发代码LLM。它由两个工业研究实验室共同管理，包括来自不同学术机构和工业实验室的600多名成员。The Stack (Kocetkov et al., 2022) 是一个公开可用的代码LLM预训练数据集，具有透明的数据治理框架。The Stack包含6.4 TB的384种编程语言的宽松许可证源代码，并在v1.2版本的数据集中包括54 GB的GitHub议题和仓库级元数据。该数据集附带“Am I in The Stack”治理工具，供开发者检查其源代码是否属于该数据集，以及为希望将其代码从数据集中删除的人提供的退出流程。

StarCoder和StarCoderBase都是155亿参数的模型，使用来自The Stack的宽松许可数据进行训练。我们在来自80多种编程语言、GitHub议题、Git提交和Jupyter笔记本的1万亿token上训练了StarCoderBase。我们再用350亿Python token微调了StarCoderBase，得到了StarCoder模型。两个StarCoder模型都具备新颖的架构特性组合，例如8K token上下文长度 (Dao et al., 2022)、通过中间填充（FIM；Bavarian et al., 2022）实现的填充能力，以及通过多查询注意力（MQA；Shazeer, 2019）实现的快速大批量推理。我们对StarCoder模型进行了广泛的评估，并发布了一个演示，其中包含一个集成的归因工具，可以帮助用户定位可能从训练集中复制的模型生成内容。总的来说，我们的贡献可以总结如下。

• 我们发布了StarCoderBase和StarCoder，这是在80多种编程语言上训练的开放访问代码LLM，支持其他开放代码LLM所不具备的新颖能力和架构特性组合。

• 我们使用多样化的基准测试集 (Lai et al., 2022; Cassano et al., 2023; Pearce et al., 2022; Fried et al., 2022; Yee & Guha, 2023; Austin et al., 2021; Chen et al., 2021; Ben Allal et al., 2022; Hendrycks et al., 2020; Reddy et al., 2019; Cobbe et al., 2021; Nadeem et al., 2021; Gehman et al., 2020; Liang et al., 2022)，对代码LLM进行了迄今为止最全面的评估，结果表明：

  • StarCoder在所有支持多编程语言的开源代码LLM (Nijkamp et al., 2023; Zheng et al., 2023) 中表现最佳；

  • StarCoder匹配或超越了OpenAI的code-cushman-001模型；且

  • 在Python上微调后，StarCoder显著优于同样在Python上微调的现有LLM。

• 我们朝着安全的开放模型发布迈出了重要步骤：

  • 我们在OpenRAIL-M许可协议下发布StarCoder，该协议允许免版税访问、使用和分发模型，同时在确定的关键场景中嵌入了一套使用限制。我们致力于达成的许可协议版本： (i) 对希望使用和分发模型的公司更具商业可行性， (ii) 通过共享模型卡等AI文档 (Mitchell et al., 2019) 促进透明度和理解；

  • 我们在VSCode演示中集成了一种新的归因工具，可以帮助用户检测和定位可能从训练集中复制的模型生成内容。这是通过两步过程实现的，包括轻量级的成员检查，然后是对BM25索引的搜索（第9节）；且

  • 我们通过收集包含12,000个文件和22,950个标注实体的PII数据集，显著改进了PII编辑流程。我们在此数据集上微调了我们自己的编码器模型（StarEncoder），得到了一个鲁棒的PII检测模型（第4节）。

2 相关工作

语言模型 早期构建大规模语言模型的努力使用n-gram和简单的平滑技术 (Brants et al., 2007; Heafield et al., 2013; Buck et al., 2014)。其他方法将各种类型的神经网络架构应用于语言建模任务，如前馈网络 (Bengio et al., 2000) 和循环网络 (Mikolov et al., 2010; Jozefowicz et al., 2016)。Transformer架构 (Vaswani et al., 2017) 促进了高度可扩展语言模型的开发 (Radford et al., 2019; Brown et al., 2020)，这些模型在语言建模损失与模型大小、训练token数量和计算预算等扩展因子之间表现出可预测的关系 (Kaplan et al., 2020; Hoffmann et al., 2022)。

代码语言模型 Hindle et al. (2012) 首次将语言模型应用于代码，但依赖于以相对较小规模训练的n-gram模型。自然语言处理中开发的许多神经架构也成功应用于代码，包括用于生成代码表示的仅编码器模型 (Feng et al., 2020; Kanade et al., 2020) 和用于翻译、编辑、摘要和语言到代码任务的编码器-解码器模型 (Wang et al., 2021; Ahmad et al., 2021; Li et al., 2022)。仅解码器的Transformer架构产生了强大的代码生成模型，通常通过在来自GitHub的文本和代码混合数据上训练 (Chen et al., 2021; Austin et al., 2021; Fried et al., 2022; Zheng et al., 2023; Nijkamp et al., 2023)。这些模型大多没有完全开放，但PolyCoder (Xu et al., 2022) 和SantaCoder (Ben Allal et al., 2023) 是值得注意的例外，它们都开放了模型和训练数据。然而，这些模型相对较小（分别为27亿和11亿参数），并且在我们这项工作中探索的数据量（ < 300GB代码）上训练得较少。

封闭访问LLM 几家大型科技公司开发了顶级的LLM但没有发布它们。例子包括Google的PaLM (Chowdhery et al., 2022) 和LaMDA (Thoppilan et al., 2022)，DeepMind的Chinchilla (Hoffmann et al., 2022) 和Gopher (Rae et al., 2021)，以及NVIDIA的Megatron-Turing NLG (Smith et al., 2022)。OpenAI和其他AI初创公司，包括Cohere、Anthropic和Aleph Alpha，通过付费API服务提供LLM。这些公司没有发布模型权重，也没有提供关于创建这些模型所用方法的全面信息。OpenAI已经发布了GPT系列模型的几份技术报告 (Brown et al., 2020; Chen et al., 2021; OpenAI, 2023a)，展示了其模型的能力。

开放访问LLM 许多开放访问的LLM已经发布给AI社区，尽管它们通常不如封闭访问的强大。在本文中，当模型权重公开可用时，我们使用术语“开放访问LLM”。我们仍然注意到，开放访问模型在训练数据和过滤技术的透明度方面存在显著差异。例如，EleutherAI发布了GPT-NeoX-20B (Black et al., 2022) 和GPT-J-6B (Wang & Komatsuzaki, 2021)，以及这些模型训练所用的数据集 (Gao et al., 2021a)。Google发布了UL2-20B (Tay et al., 2022)，这是一个在公开可用的C4 (Raffel et al., 2020) 上训练的编码器-解码器模型。清华大学发布了GLM-130B (Zeng et al., 2022)（一个中英文LLM）和CodeGeX-13B (Zheng et al., 2023)（一个用于编程应用的LLM）的权重，但没有发布训练集。Salesforce发布了CodeGen-Mono-16B (Nijkamp et al., 2023)，但没有公开其专有的Python数据集。Meta在非商业许可下发布了OPT (Zhang et al., 2022)、LLaMA (Touvron et al., 2023) 和InCoder模型 (Fried et al., 2022)，并且仅提供了关于数据收集和过滤过程的高级细节。

3 数据整理与清洗

本节描述我们如何处理StarCoderBase的训练数据。我们将训练集限制在The Stack v1.2 (Kocetkov et al., 2022)，它仅包含来自宽松许可GitHub仓库的数据。在数据处理时，有44人选择退出The Stack。下面，我们描述如何通过结合启发式过滤和人工检查来进一步清洗数据。

3.1 编程语言

编程语言的选择 从The Stack中的358种编程语言中，我们选择了86种语言。数据到编程语言的分配仅基于文件扩展名进行 (Kocetkov et al., 2022)。我们包括了所有数据量超过500 MB的编程语言，以及在Github 2.0或2022年12月TIOBE编程语言流行度指数中排名前50的语言。此外，我们还包括了已选编程语言的方言（例如，Lisp的Racket和Scheme）。我们排除了配置语言（Nix、Puppet等）和不再积极支持的语言（ActionScript）。我们还包含了JSON和YAML等数据格式，但限制了其数据量（详见“JSON和YAML”段落）。所选编程语言的完整列表见表1和表2。在MultiPL-E (Cassano et al., 2023) 中出现的语言中，只有D和Swift未包含在训练集中。对于D，由于文件的语言误分类，导致在The Stack中的数据量少于2MB (Kocetkov et al., 2022)。Swift由于人为错误被从最终语言列表中排除。

人工检查 我们进行了人工检查以确保只保留高质量的数据。为此，我们从The Stack中为每种编程语言随机选择30,000个文件，按扩展名分类，并为每个扩展名最多保留1,000个文件。然后我们联系社区协助进行数据检查。我们指示标注者浏览50-100个文件，确认数据是否看起来像是人类编写的正常代码，而不是文本、数据或单行长行的自动生成代码。我们还要求标注者确定对于给定的文件扩展名，是否应使用我们的默认字母数字过滤器（要求超过25%的字母数字符号）和长行过滤器（要求行长度小于1000个字符）。十八位社区标注者评估了300种编程语言扩展名。检查后，我们排除了36个扩展名，并取消了27个扩展名的长行过滤器。数据检查的完整结果，包括标注者备注，可在此Google表格中找到。

XML过滤器 在检查数据时，我们注意到某些扩展名通常包含XML文件。例如，.sld扩展名有超过50%的文件是XML格式。为解决此问题，我们实现了一个简单的XML过滤器，检查文件前100个字符中是否存在“<?xml version=”。该过滤器被证明有效且误报很少。因此，我们将其应用于除XSLT（使用XML语法）外的所有编程语言。

字母过滤器 在调查过程中，我们发现某些扩展名，例如MATLAB，包含大量经常存储大张量的数据文件。为了识别这些文件，我们开发了一个字母过滤器，删除字母字符少于25%的文件。然而，当我们在一个小型数据子集上测试此过滤器时，观察到某些编程语言（如Assembly）的误报率很高。为解决此问题，我们重点关注了检测次数最多的25个扩展名，并手动验证是否应应用字母过滤器。

HTML 我们设计了一个自定义HTML过滤器，针对过多的HTML样板和链接。我们考虑了每个文件中可见文本的比例，仅保留那些可见文本至少占HTML代码20%且最小长度为100字符的文件。

JSON和YAML JSON和YAML文件天生比The Stack中的其他语言更偏向数据。为移除大部分数据文件，我们应用了以下过滤器。对于YAML，我们保留字符数在50-5000之间、平均行长度小于100、最大行长度小于1000且超过50%字母字符的文件。这些过滤器移除了约20%的文件和90%的数据量。对于JSON，我们保留字符数在50-5000之间且超过50%字母字符的文件，这移除了约70%的文件和98%的数据量。

表1：StarCoder训练数据概览。对于选定的编程语言，我们显示了去重后以及过滤后的文件数量和数据量。另见表2。
(表格数据略，内容同原文)

表2：StarCoder训练数据概览。对于选定的编程语言，我们显示了去重后以及过滤后的文件数量和数据量。另见表1。
(表格数据略，内容同原文)

3.2 Jupyter笔记本

所有Jupyter笔记本均从The Stack中获取。我们将Jupyter笔记本转换为两个不同的数据集：Jupyter脚本和Jupyter结构化。

表3：初步收集的Jupyter脚本概览，包含文件数量和百分比。
(表格数据略，内容同原文)

Jupyter脚本 我们利用Jupyter将笔记本转换为脚本。这是一个积极维护的软件，目前支持31种编程语言。要启动转换过程，Jupyter需要识别每个笔记本中的特定编程语言。我们从每个笔记本的元数据中提取此信息。然而，超过30,000个笔记本缺少任何编程语言信息，这使得将它们转换为脚本格式变得困难。为解决此问题，我们引入了Guessing，一个利用机器学习技术识别源代码编程语言的开源库。通过应用大于等于0.5的概率阈值，我们使用Guessing成功将未识别的笔记本数量减少到6,400个。最终，我们通过使用Jupyter积累了1,432,992个脚本。这些脚本中编程语言的分布如表3所示。我们通过从转换后的脚本中随机选择100个文件来评估语言覆盖范围，确保所有编程语言都在此样本中有所体现。

Jupyter结构化 为了创建此数据集，我们首先过滤掉不包含任何Python代码或Markdown文本的笔记本。使用每个笔记本元数据中的编程语言信息作为过滤非Python笔记本的标准。仅保留元数据中明确标记为“Python”的笔记本。然后，对于每个笔记本，将连续的Markdown块或代码块分别合并为大的Markdown或代码块。最终，我们得到了按时间顺序由每个笔记本分组的连续代码-文本对。通常，每个Jupyter代码-文本对包含紧挨在代码块之前的Markdown文本和Python代码，这形成了一个自然的

3.3 GitHub议题

我们使用了来自GitHub议题和拉取请求的自然语言对话，这些是作为The Stack v1.2的一部分收集的。每个对话由一系列带有操作的事件组成，例如打开议题、创建评论或关闭议题。每个事件包括作者的用户名、消息、操作和创建日期。我们按如下方式过滤这些数据：1) 首先，当用户通过电子邮件回复议题时，我们移除了自动生成的文本。我们使用的正则表达式见附录A。我们还删除了消息较短的议题（少于200个字符），并将评论的中间部分截断，最多保留100行，同时保留最后20行。这移除了18%的数据量。2) 接下来，我们排除了来自机器人的评论。为此，我们在评论作者的用户名中搜索机器人关键词（更多信息见附录A）。此步骤消除了17%的总事件，并导致14.7%的议题被清空。我们观察到，机器人生成的议题往往冗长，并包含大量日志和链接。3) 我们使用参与对话的用户数量作为质量指标。我们的标准是包括有两个或更多用户的对话。然而，如果单个用户评论中的总文本少于7,000个字符（第96百分位数），我们也保留涉及单个用户的对话。此外，如果单个用户创建的议题包含超过十个事件，我们将排除它们，因为这些议题往往质量较差或来自被忽视的机器人。通过实施这些过滤器，我们额外移除了14%的议题。4) 最后，我们使用来自fasttext库的模型过滤掉非英语议题。这一步对于能够使用PII检测模型准确编辑姓名是必要的（见第4.3节）。

最后，我们想指出的是，我们通过用对话中的参与者计数器替换用户名来对对话中的用户名进行匿名化处理。更多细节见第4.3节和第5.1节。

3.4 Git提交

Git提交数据是从BigQuery收集的，仅包括与The Stack中使用相同许可证和文件扩展名的仓库的单文件提交 (Kocetkov et al., 2022)。我们移除了所有来自选择退出The Stack的用户的仓库。原始数据集约为4 TB。我们对剩余数据的50%进行了采样，并使用启发式方法进行过滤，以构建高质量的数据集。我们在表4中列出并描述了所有过滤器。

一次提交中更改的行数可能远小于文件大小。为了避免在计算预算上花费太多来学习复制文件内容，我们只在20%的情况下使用完整文件，而对于剩余的80%，我们在第一个和最后一个更改行周围采样0到32行的窗口。生成的数据集包含64 GB的提交数据。

3.5 去重

我们遵循了Ben Allal et al. (2023) 的去重流程，包括计算所有源代码文件的MinHashes (Broder, 2000)，然后使用局部敏感哈希（LSH）将相似的代码文件映射到同一个桶中。我们使用了5-gram和0.7的Jaccard相似度。有关流程的更多细节，请参阅此博客文章。

我们将此近似去重过程应用于所有编程语言和Jupyter笔记本。然而，由于时间限制，我们无法将此过程应用于Git提交。此外，我们认为在GitHub议题中发现重复的可能性不大，因此没有对它们应用该过程。

3.6 数据源加权

表4：Git提交过滤器。
(表格数据略，内容同原文)

关于是否对某些编程语言进行上采样或下采样，社区内有几场讨论，因为分配给给定语言的数据源的计算预算量可能会显著影响模型在该语言上的性能。然而，我们意识到最大量的可用数据来自流行的编程语言，因此将使更大的最终用户群体受益。此外，在去重过程之后，我们发现一些高资源编程语言，如C、C++、C#、Java、Javascript、Python和PHP，拥有相似的数据量，范围从44到87 GB。这进一步强化了我们的信念，即我们不需要大幅重新加权现有的数据分布。因此，在这项工作中，我们在训练期间遵循数据的自然分布，并根据数据源的体积按比例采样。然而，我们对JSON、YAML和CSS做了例外，因为我们只希望LLM学习数据格式，而不将计算资源浪费在记忆这些文件中的数据上。出于这个原因，我们将JSON和YAML的数据源体积重新加权为1 GB，CSS为3GB。

4 PII编辑

本节概述了我们从训练数据中移除个人身份信息（PII）的努力。在第4.1节中，我们首先描述了我们如何收集大量PII标注。我们使用这些标注在第4.3节中探索了训练PII检测模型的各种技术，该模型建立在我们于第4.2节中开发的编码器模型之上。

4.1 数据收集

我们利用Toloka平台聘请了来自35个国家的1,399名众包工作者，为源代码中的PII标注数据集。平均而言，参与者完成了206项任务，收入约27美元，工作3.1小时。我们的目标是识别各种形式的PII，如姓名、用户名、邮箱、IP地址、密钥、密码和ID。为确保众包工作者获得公平报酬，我们设定了每小时7.30美元的工资率，同时考虑了不同国家的最低工资率及其相应的购买力。我们将标注资格限制在那些每小时7.30美元的工资率在购买力平价上相当于美国最高最低工资（16.50美元）的国家。参与标注的国家完整列表见附录B的表B.1。Toloka的众包工作者可以随时随地进行任务；没有义务完成特定任务或花费固定时间。因此，他们在处理任务时利用自由选择。在1,399名众包工作者中，695人填写了关于任务质量的调查，519人完成了调查。对于询问参与者是否愿意为另一个类似项目做出贡献的问题，平均得分在1-5分制下为4.92。

图1：标注PII数据集中编程语言的分布。

数据集包含12,000个文件，每个文件大约有50行代码，涉及31种编程语言。图1显示了数据集中编程语言的分布。为了增加稀有PII类型（如密钥和IP地址）的表示，从更大的样本中预先过滤了7,100个文件。我们利用了detect-secrets工具，激活了所有默认插件，以及Ben Allal et al. (2023) 用于检测邮箱、IPv4和IPv6地址的正则表达式。为了避免标注过于偏向这些检测工具，剩余的5,100个文件是从数据集中随机选择的，没有经过预过滤。

在标注过程中，我们根据PII出现的具体上下文区分了不同类型的PII。具体来说，我们区分了PII是出现在代码的许可证头中、被用作占位符、还是构成机密数据。这种分类是必要的，因为许可证头中的PII通常是作者自愿提供的用于代码归属，可能不需要屏蔽。类似地，占位符不是真正的秘密，也不需要屏蔽。我们将此分类应用于姓名、邮箱和用户名。所有PII实体的概览见表5。

标注者在数据集中共检测到22,950个PII实体。为了评估数据集的质量，我们手动检查了包含各种PII类型的300个文件，并计算了每种类型的召回率和精确率，如表5所示。我们发现标注秘密ID特别具有挑战性，因为标注者倾向于产生许多假阳性和假阴性。因此，我们决定从PII检测模型训练中排除此类别。

4.2 StarEncoder

作为我们PII检测工作的一部分，我们训练了一个仅编码器模型（即双向自注意力Transformer），该模型可以针对代码和文本相关任务进行高效微调。我们使用了来自BERT (Devlin et al., 2019; Liu et al., 2019) 的掩码语言建模（MLM）和下一句预测（NSP）目标，并预测输入句子中被掩码的标记，以及文档中一对句子是否相邻。

我们在输入中按如下方式分隔代码片段：[CLS] 片段1 [SEP] 片段2，其中两个代码片段随机选择，要么来自同一个源文件，要么来自两个不同的文档。对于MLM损失，我们以15%的概率独立掩码输入中的标记。对于NSP损失，我们使用应用于[CLS]标记输出的线性分类器。我们训练了100,000步，全局批次大小为4,096个序列，最大长度为1,024，因此大约有4000亿个token被观察到。这使用64张NVIDIA A100 GPU大约需要两天时间。关于模型架构的详细信息见表6。

表5：PII类型概览和收集到的标注数量。我们通过在300个文件上进行人工检查，报告召回率和精确率来调查标注质量。为进行检查，每个子类别被映射回其对应的PII类型。
(表格数据略，内容同原文)

表6：StarEncoder的模型架构。
(表格数据略，内容同原文)

4.3 PII检测模型

我们在标注的PII数据集上对StarEncoder进行微调，用于命名实体识别（NER）任务。我们在模型顶部添加了一个线性层作为token分类头，目标类别有6个：姓名、邮箱、密钥、密码、IP地址和用户名。由于标注质量低，我们排除了ID，并且由于模型在区分它们方面表现不佳，我们没有区分PII实体的类别（许可证头、占位符）。我们将数据集分成包含7,878个示例的训练集和包含4,000个示例的测试集，确保两个划分在不同PII类型上具有均衡的代表性。见表7。我们在 https://hf.co/BigCode 以受限访问方式提供训练和评估划分。

表7：标注PII数据集的训练-测试划分。
(表格数据略，内容同原文)

微调基线 我们在PII训练集上微调StarEncoder，以及来自Ben Allal et al. (2023) 的400个标注文件。我们在姓名、邮箱和IP地址上实现了超过90%的F1分数，在密码上实现了73.39%。模型在密钥和用户名上的表现相对较低，F1分数分别仅为56.66%和59.39%。我们将密钥的低性能归因于此类PII的标签数量有限，仅有308个实例。对于用户名，我们观察到模型经常将它们与装饰器和路径中的值混淆。这很可能是因为我们标注了社交媒体平台链接中的用户名。

伪标签 为了提高密钥和密码实体的检测，我们采用了Lee (2013) 描述的伪标签技术。该方法涉及在少量标注数据上训练模型，随后为大量未标注数据生成预测。具体来说，我们使用在Ben Allal et al. (2023) 的400个文件PII数据集上微调的两个编码器模型的集成，标注了18,000个文件。为了识别可靠的伪标签，我们计算了来自我们模型的平均概率logits，并应用了过滤标准。具体来说，我们为所有实体设置了0.5的最小阈值，但对于姓名和用户名，我们使用了更高的阈值0.6。然而，在审查结果后，我们发现密钥和密码存在大量误报。因此，我们决定只保留那些在前100个字符内前面有触发词（如key、auth或pwd）的实体。在微调标注数据集之前，在此合成数据集上进行训练为所有PII类别带来了优越的结果，如表8和9所示。只有检测用户名的性能没有显著提高，因此我们决定将其从PII简化过程中排除。

表8：PII检测性能比较：NER流水线与正则表达式基线。
(表格数据略，内容同原文)

表9：PII检测性能比较：仅标注数据的NER流水线与标注数据+伪标签。
(表格数据略，内容同原文)

与正则表达式基线的比较 我们将PII检测模型与Ben Allal et al. (2023) 中使用的正则表达式进行了比较。正则表达式仅支持检测邮箱、IP地址和密钥。请注意，我们改进了邮箱正则表达式，如附录中所述，以解决在此基准评估中发现的误报问题。此修改将正则表达式的F1分数从81.8%提高到96.83%。尽管如此，我们的PII检测模型在检测所有三个实体方面仍然超过了正则表达式方法，如表8所示。我们注意到，性能差异在密钥上尤其大，并且发现detect-secrets工具产生了许多误报，特别是在正则表达式评估中代表性不足的特定编程语言（如Go和C#）中。因此，该工具的总体精确率低于4%。

后处理 在将最佳PII检测模型应用于完整数据集之前，我们观察到一些常见的检测错误。我们添加了以下后处理技术以减少误报数量：

• 忽略少于4个字符的秘密。

• 仅通过要求姓名内至少有一个空格来检测全名。

• 忽略少于9个字符或使用乱码检测器检测为非乱码的密钥。

• 使用ipaddress python包忽略无效或私有（非面向互联网）的IP地址。我们还忽略了来自流行DNS服务器的IP地址。我们使用与Ben Allal et al. (2023) 中相同的列表。

PII占位符 我们用以下标记替换检测到的PII实体：
<NAME>， <EMAIL>， <KEY>， <PASSWORD>

对于IP地址的屏蔽，我们从5个合成的、私有的、非面向互联网的同类型IP地址中随机选择一个，这些地址见附录C。

GitHub议题 我们已经在GitHub议题中使用了正则表达式方法来检测密钥、IP地址和邮箱，因此我们仅使用PII检测模型来编辑姓名。我们通过用对话内的参与者计数器替换作者的用户名来对其匿名化，例如使用username_1来指代第二个参与者（格式细节见第5.1节）。我们将这些假名添加到每条评论的开头，以保留作者的发言者身份。此外，我们编辑消息中所有这些用户名的提及。注意，我们仅屏蔽对话中活跃参与者的用户名，非参与用户的提及不被匿名化。

计算资源 我们使用PII检测模型识别训练数据集中所有编程语言的PII，包括GitHub议题（仅姓名）、Git提交和Jupyter笔记本。总数据集大小为815 GB。我们在多张NVIDIA A100 80 GB GPU上运行推理，需要800 GPU小时。

5 模型训练

本节介绍StarCoder模型的训练过程信息。在继续之前，我们首先澄清两个模型之间的差异：

StarCoderBase 是第一个模型，在第3节描述的精心整理的数据集上训练了1万亿个token。

StarCoder 是StarCoderBase的微调版本，另外在350亿个Python token上训练（大约2个周期）。

在下文中，我们将展示如何格式化训练数据（第5.1节）、净化训练数据（第5.2节），并提供关于分词器（第5.3节）、模型架构（第5.4节）、训练过程（第5.5节）、多节点GPU设置（第5.6节）和CO2排放（第5.7节）的详细信息。

5.1 数据格式化

我们在下面为每个数据源提供格式化指南。我们在下面提供模板，其中 <token> 指的是一个标记，metadata和data分别指的是数据字段的占位符。

代码 我们将仓库名称、文件名和星标数量添加到代码文件的上下文之前。为了不过度拟合确切的星标数量，我们将GitHub星标分为五个桶：0、1-10、10-100、100-1000、1000+。为了使模型在推理期间能够无此元数据运行，我们独立地以0.2的概率随机添加仓库名称、文件名和星标。

<reponame>仓库名<filename>文件名<gh_stars>星标\n代码<|endoftext|>

对于此模板中的源代码（即代码），我们应用中间填充变换（FIM；Bavarian et al., 2022）。更准确地说，我们以0.5的FIM率在字符级别将FIM应用于源代码文件，并以0.5的概率使用PSM模式，以0.5的概率使用SPMv2模式。

议题 我们使用标记来标记议题的开始，随后包含其标题。我们使用 <issue_comment> 标记分隔评论序列，并在评论前包含匿名化的发言者标识符。具体来说，我们通过对话中的参与者计数器来指代作者，例如使用username_1指代议题中的第二个参与者。为了区分不同的轮次，我们分别使用comment1， id1来指代第二条评论及其匿名化的发言者ID。

<issue_start>Title: 标题\nusername_id0: 评论<issue_comment>username_id1: 评论1 ... <issue_closed (可选)><|endoftext|>

Jupyter脚本 Jupyter脚本的格式化方式与代码相同。

Jupyter结构化 解析后的Jupyter笔记本以文本、代码和输出的链条形式出现，我们用标记将它们分隔开。请注意，我们使用text2， code2， output2来指代笔记本中的第三个三元组。

< jupyter_start><jupyter_text>文本0< jupyter_code><jupyter_output>输出0< jupyter_text>...<|endoftext|>

Git提交 我们用标记分隔提交前的代码、提交消息和提交后的代码。如第3.4节所述，我们以20%的概率使用完整文件，否则在更改行周围使用一个小窗口（0-32行）。

<commit_before>代码前<commit_msg>消息<commit_after>代码后<|endoftext|>

我们将所有标记汇总在表10中。

5.2 训练数据净化

代码训练数据通过移除包含来自HumanEval和MBPP的文档字符串或解决方案、来自APPS的文档字符串、来自GSM8K的问题或来自DS1000的提示的文件来净化。（这些基准在第6节中进一步描述）。为指示通过净化移除的数据量，Python是匹配次数最多的语言，移除了558个文件。

表10：标记概览。
(表格数据略，内容同原文)

5.3 分词器

模型的分词器遵循我们在Ben Allal et al. (2023) 中提出的见解，并使用相同的设计选择：我们使用Hugging Face Tokenizers库 (MOI et al., 2022) 来训练字节级字节对编码，词汇表大小为49,152个token——包括表10中的标记。预分词步骤包括一个数字分割器和来自GPT-2预分词器的正则表达式分割器。

5.4 模型架构

我们训练了一个与SantaCoder (Ben Allal et al., 2023) 架构相同的155亿参数模型。它是一个仅解码器的Transformer，带有多查询注意力（MQA；Shazeer, 2019）和学习到的绝对位置嵌入。我们还将中间填充（FIM；Bavarian et al., 2022）变换应用于训练数据，见第5.1节。我们使用FlashAttention (Dao et al., 2022) 来加速注意力计算并减少其内存占用，使我们能够扩展到8K上下文长度。为了在训练期间使FlashAttention与MQA协同工作，我们在调用注意力内核之前简单地扩展键和值。架构超参数见表11。此外，我们还包含了SantaCoder (Ben Allal et al., 2023) 的超参数以作比较。

5.5 训练细节

StarCoderBase 模型训练了25万次迭代，批次大小为400万token，总计一万亿token。我们使用了Adam (Kingma & Ba, 2015) 优化器，β1 = 0.9，β2 = 0.95，ϵ = 10⁻⁸，权重衰减为0.1。学习率在2,000次迭代线性预热后，按照余弦衰减从3 × 10⁻⁴降至3 × 10⁻⁵。

StarCoder 从StarCoderBase开始，我们在训练数据的Python子集上对模型的Python变体进行了2个周期的微调。我们使用了与StarCoderBase相同的设置，不同之处在于我们使用了5 × 10⁻⁵的学习率，并在1,000次迭代线性预热后衰减至5 × 10⁻⁶。我们训练了8,500步。

表11：StarCoder的模型架构。我们还包含了SantaCoder（社区的先前工作）。
(表格数据略，内容同原文)

5.6 多节点GPU设置

我们在一个拥有512张A100 80 GB GPU的集群上训练模型，这些GPU分布在64个节点上。我们使用3D并行布局对模型进行分区，该布局同时使用张量并行和流水线并行（秩为4），一个模型副本需要16张GPU（两个节点）。为了充分利用集群的能力，我们使用了32倍的数据并行。为了优化GPU利用率并减少空闲计算气泡，我们保持微批次大小为1，并累积16步，得到全局批次大小为512（相当于400万token）。我们使用了Megatron-LM的分布式优化器，因为我们发现在这种配置下它能带来稍高的吞吐量。由于它需要以FP32进行梯度归约步骤，BF16的训练导致吞吐量比FP16低10%，但我们仍然使用它以避免训练不稳定。

除了几次重启外，我们没有遇到明显的训练不稳定情况。

5.7 CO2排放

StarCoderBase 我们报告训练StarCoderBase的碳足迹 (Lacoste et al., 2019)。根据训练所用的总GPU小时数（320,256）和每张GPU的平均功耗280W，训练过程中消耗的电量总计为89671.68千瓦时。乘以us-west-2 AWS位置的能源碳强度（0.15495 kgCO2e/kWh）和AWS数据中心的平均电能使用效率1.2，这相当于排放了16.68吨CO2当量。

StarCoder 微调后的模型增加了3.5%的训练时间，这意味着额外估计排放0.58吨CO2当量。

6 评估

在本节中，我们首先概述除了StarCoder和StarCoderBase之外我们评估的模型。然后，我们报告所有模型在HumanEval (Chen et al., 2021)、MBPP (Austin et al., 2021) 和DS-1000 (Lai et al., 2022) 评估基准上的Python语言性能。接着，我们使用各种基准和任务涵盖多语言评估。

代码LM评估工具 为了实现StarCoder和其他代码LLM的可重复和集中评估，我们开发了一个代码LM评估工具 (Ben Allal et al., 2022)，其灵感来自LM评估工具 (Gao et al., 2021b)。该工具提供了一个框架，利用数据并行性和用于执行的docker容器来高效评估代码模型。它支持多个基准，包括HumanEval、MultiPL-E和DS-1000。

评估的其他模型 我们将StarCoder和StarCoderBase与以下模型进行比较。

1. CodeGen-16B-Multi (Nijkamp et al., 2023) 是一个开放访问的160亿参数模型，它在Pile (Gao et al., 2021a) 上训练，然后在来自GitHub BigQuery数据集 (Smith, 2016) 的用C、C++、Go、Java、JavaScript和Python编写的额外代码上训练。

表12：在HumanEval和MBPP Python上将StarCoder的性能（pass@1）与其他几个模型进行比较。StarCoder和StarCoderBase在开放访问模型中获得了最高性能，并与封闭访问的code-cushman-001模型性能相当。
(表格数据略，内容同原文)

1. CodeGen-16B-Mono 是CodeGen-16B-Multi的一个版本，在来自GitHub的额外Python代码上进行了微调，尽管该数据集不公开。

2. CodeGeeX (Zheng et al., 2023) 是一个开放访问的130亿参数模型，在从Pile、CodeParrot数据集 (Wolf et al., 2020) 以及Python、Java和C++的额外数据中选出的23种编程语言上训练。CodeGeeX还包括自己的多语言基准套件HumanEval-X，我们将在下文讨论。

3. code-cushman-001 是OpenAI的一个120亿参数模型，是GitHub Copilot的初始模型 (Chen et al., 2021)。其训练集的细节未知。该模型已被OpenAI弃用，但在撰写本文时仍可从微软Azure OpenAI服务获得。

4. 最后，尽管它们并非专门为代码生成而训练，我们还是包含了来自LLaMA (Touvron et al., 2023)、PaLM (Chowdhery et al., 2022) 和LaMDA (Thoppilan et al., 2022) 论文的一些结果。LLaMA的许可证禁止商业使用，PaLM和LaMDA不公开可用。

6.1 StarCoder：Python评估

在本节中，我们评估StarCoder在Python上的性能，并将其与开放访问和封闭访问模型进行比较。我们首先报告在HumanEval (Chen et al., 2021) 和MBPP (Austin et al., 2021) 上的性能，这是两个广泛使用的Python性能基准。然而，我们还测量了在DS-1000 (Lai et al., 2022) 上的性能，这是一个基于StackOverflow问题的包含1,000个Python数据科学问题的代码补全基准。

6.1.1 HumanEval和MBPP基准

HumanEval (Chen et al., 2021) 和MBPP (Austin et al., 2021) 是代码LLM广泛使用的基准，包含数百个Python编程问题，这些问题使用测试用例来验证代码LLM产生的代码。代码LLM通过从其输出分布中采样来生成代码。我们使用pass@k指标报告性能 (Chen et al., 2021)：已解决问题的总分数，其中如果任何一个k个代码样本通过了所有测试用例，则认为问题已解决。与Chen et al. (2021) 一样，对于pass@1我们使用采样温度0.2，对于k > 1使用温度0.8。我们为所有开放访问模型的实验生成n = 200个样本。对于API模型，我们使用n = 20个样本，这足以估计pass@1。我们关注pass@k的最简单版本，即pass@1：模型单次尝试解决问题的可能性。

表12将StarCoder（和StarCoderBase）在HumanEval和MBPP上与几个开放访问和封闭访问模型进行了比较：

1. StarCoder 是两个基准上性能最高的开放访问模型。

2. StarCoder 优于最大的模型，包括PaLM、LaMDA和LLaMA，尽管其规模显著较小。

3. StarCoderBase 在Python上也很有能力，与CodeGen-16B-Mono（一个类似规模的、经过Python微调的开放访问模型）具有竞争力。

4. StarCoder 优于OpenAI的code-cushman-001（12B）模型。

6.1.2 DS-1000 Python数据科学基准

HumanEval和MBPP的一个主要限制是它们是一些简单的编程谜题，不能代表大多数程序员编写的代码。相比之下，DS-1000基准 (Lai et al., 2022) 包含一套1,000个现实且实用的数据科学工作流程，涵盖七个库，并根据测试用例对生成进行执行评估。

DS-1000支持两种评估模式：补全和插入（通过FIM）。我们报告所有模型的补全分数，但仅针对支持插入的模型报告插入分数：StarCoder模型和InCoder-6B (Fried et al., 2022)。DS-1000还根据所使用的库对问题进行分类：Matplotlib、NumPy、Pandas、SciPy、Scikit-Learn、PyTorch和TensorFlow。我们在表13中报告每个库的pass@1和总体分数，并得出以下结论：

1. StarCoder 在DS-1000基准的数据科学问题上显著优于所有其他模型。而且，这在每种数据科学库中都是如此。

表13：开放访问和封闭访问模型在DS-1000上的性能。所有模型均在温度 = 0.2，top_p = 0.5，max_length = 1024下评估。分数表示平均pass@1准确率，对40个样本取平均。*: Matplotlib任务没有右侧上下文，因此插入和补全格式相同。
(表格数据略，内容同原文)

1. StarCoderBase 也优于所有其他模型，但在DS-1000上略落后于StarCoder。

2. 我们确认了Lai et al. (2022) 的发现：模型在HumanEval和MBPP基准上的性能并不总是与在更真实的DS-1000基准上的性能相关。例如，CodeGen-Mono在HumanEval和MBPP上略优于code-cushman-001和StarCoder模型，但在DS-1000上明显更差。这表明在一系列基准上评估模型的重要性。

6.1.3 ODEX开放领域编码基准

我们之前的评估要么侧重于封闭领域（即，主要使用内置Python函数，如MBPP和HumanEval），要么侧重于特定领域（例如，数据科学，如DS-1000）。为了评估模型在更广泛的Python库上生成代码的能力，我们使用ODEX基准 (Wang et al., 2022)，该基准包含505个开放领域和440个封闭领域的Python编码查询，使用四种自然语言——英语、西班牙语、日语和俄语——并通过基于测试用例的执行进行评估。

我们报告了StarCoder和基线模型（包括Codex (code-davinci-001)、CodeGen16B-Mono和SantaCoder）的pass@1指标。除了整体执行准确率外，我们还将问题按语言和领域分类，分别是：(1) 封闭领域（仅使用内置Python函数）和开放领域（使用导入库中的函数）的查询，以及 (2) 指令分别用英语、西班牙语、日语和俄语编写的查询。我们在表14中报告了总体分数以及不同领域和语言的分数，并得出以下结论：

1. StarCoder 在ODEX基准的开放领域编码查询上显著优于所有其他模型。

2. StarCoderBase 也优于所有其他模型，在ODEX英语子集上甚至优于StarCoder，但在其他语言上略逊一筹。

3. 尽管整体执行准确率更高，但StarCoder和StarCoderBase模型在开放和封闭领域查询之间的差距通常小于其他基线模型。这一结果表明，StarCoder模型在开放领域（即涉及多样化的Python库）的编码查询方面获得了更通用的技能，而其他模型在从封闭领域转向开放领域时表现出更大的性能下降。

表14：按指令语言和代码领域划分的ODEX基准性能：开放问题使用库，封闭问题仅使用内置Python函数。
(表格数据略，内容同原文)

6.2 StarCoder和StarCoderBase：多语言评估

在本节中，我们主要关注StarCoderBase，并评估其在多种编程语言和编程任务上的性能，包括根据自然语言描述生成代码、为代码编写文档、预测类型注释等等。本节还表明，尽管经过Python微调，StarCoder仍然是一个非常强大的多语言代码LLM，甚至在某些语言上优于StarCoderBase。

表15：将StarCoder与多语言开放访问（例如CodeGen-16B-Multi）和封闭访问模型（例如code-cushman-001）在19种编程语言上进行比较。我们报告在HumanEval (Chen et al., 2021) 上的pass@1，我们使用MultiPL-E (Cassano et al., 2023) 将其从Python翻译成其他语言。
(表格数据略，内容同原文)

6.2.1 使用MultiPL-E在19种编程语言上进行评估

我们使用MultiPL-E (Cassano et al., 2023) 评估StarCoder将自然语言转化为多种编程语言中工作代码的能力，MultiPL-E将HumanEval (Chen et al., 2021) 和MBPP (Austin et al., 2021) Python基准翻译成其他18种编程语言，如下所述。

MultiPL-E拥有一组基于规则的编译器，可以将Python基准翻译成每种目标编程语言。每个编译器期望一个HumanEval格式的基准：1）自然语言描述（在文档字符串中），2）函数签名（名称、参数，可能还有类型），以及3）一组隐藏的断言。MultiPL-E编译器将函数签名、断言和文档字符串（可能包含文档集）翻译成目标语言。因此，MultiPL-E为我们提供了一套从HumanEval和MBPP派生的并行基准，用于跨编程语言比较模型性能。MultiPL-E语言包括高资源和低资源语言、静态和动态类型语言，以及各种其他编程语言特性。

表15显示了这些模型在19种编程语言上的表现，从中我们得出以下结论：

1. 在所有19种编程语言中，StarCoderBase 优于其他开放访问模型，有时性能超过2倍。

2. StarCoderBase 在我们评估的大多数语言上与code-cushman-001具有竞争力。有几个例外。例如，code-cushman-001 在C++、Java、Ruby和Swift上的表现优于StarCoderBase超过5%，而StarCoder在Julia上的表现优于code-cushman-001超过5%。

3. 尽管在Python上进行了微调，StarCoder 在大多数语言上仍保持竞争力，并且也优于其他开放模型。更令人惊讶的是，尽管是在Python上微调的，但StarCoder在某些语言上略优于StarCoderBase。目前，我们只能推测原因，对开放训练数据的进一步调查可能有助于阐明这一发现。

从表中还可以得出其他几个结论。例如，CodeGen-16B-Multi 在一些据称不在其训练集中的语言上表现比预期的要好，包括C#、Lua、PHP和TypeScript。它在TypeScript上的表现不那么令人惊讶，因为简单的JavaScript函数经过设计通常能在TypeScript中进行类型检查。类似地，StarCoder 在Swift上表现出高性能，尽管如第3.1节所述，Swift并未包含在其训练集中。

6.2.2 “Asleep at the Keyboard”安全基准

代码LLM的一个局限性是它们可能生成带有安全漏洞的代码 (Pearce et al., 2022)。Pearce et al. (2022) 的“Asleep at the Keyboard”基准包含跨三个评估轴的89个安全敏感场景：(1) 弱点多样性涵盖MITRE通用弱点枚举分类法中的18个不同漏洞类别，场景来自MITRE发布的2021年CWE前25最危险软件弱点列表；(2) 提示多样性评估模型针对单个漏洞类别（SQL注入）的提示变体的敏感性；(3) 领域多样性包含硬件描述语言Verilog中的安全场景。我们关注DoW，它包含跨18个CWE的54个场景（25个用C，29个用Python）。我们排除了缺乏自动化测试的场景，剩下40个场景（23个用C，17个用Python）。

Pearce et al. (2022) 先前评估了GitHub Copilot（截至2021年8月）的安全性，在本文中，我们使用相同的方法评估StarCoderBase、InCoder-6B、CodeGen-16B-Multi和OpenAI的code-cushman-001。我们使用原始基准测试方法：在温度0.2下为每个场景生成25个补全（每个模型1,000个补全）。数据集支持中间填充，因此我们在支持此功能的模型上包含了这种配置。结果显示在表16中；Valid 给出了语法有效解决方案的百分比（Python使用py_compile，C使用gcc），Insecure 显示了有效解决方案中包含该场景测试的漏洞的百分比。从这张表中，我们得出以下结论。

表16：Asleep at the Keyboard安全基准性能 (Pearce et al., 2022)。
(表格数据略，内容同原文)

1. StarCoderBase 具有最高的有效代码率。

2. InCoder-6B 的不安全代码生成率略低，但这可能是由于其有效补全率较低。

3. 在有效代码率超过95%的模型中，StarCoder 的不安全补全率最低。

6.2.3 中间填充基准

StarCoder模型支持中间填充（FIM）或填充，允许模型根据插入点周围的前缀和后缀代码生成代码。只有少数最近的模型支持FIM：来自OpenAI (Bavarian et al., 2022)、InCoder (Fried et al., 2022) 和我们之前在SantaCoder上的工作 (Ben Allal et al., 2023)。FIM开启了一系列超越从左到右代码补全的任务可能性。我们下面在四个已建立的FIM基准上评估StarCoderBase。

Python、Java和JavaScript的单行填充 Fried et al. (2022) 为Python提出了一个单行中间填充任务，该任务从HumanEval解决方案中屏蔽一行代码，并评估模型完成函数的能力。他们将每个HumanEval解决方案通过将解决方案主体中的每一非空、非注释行代码转化为一个中间填充任务，从而产生多个填充中间问题。Ben Allal et al. (2023) 将此基准推广到也支持Java和JavaScript，使用来自MultiPL-E翻译的模型生成解决方案。我们将StarCoderBase、SantaCoder和InCoder在此任务上的性能进行比较，使用行精确匹配进行评估（表17）。StarCoderBase 显著优于两个较小的模型。

表17：在Ben Allal et al. (2023) 的FIM基准上的单行中间填充性能。
(表格数据略，内容同原文)

Python返回类型预测 Pradel et al. (2020) 介绍了评估Python类型注释的方法和数据集。Fried et al. (2022) 改编并过滤了这项工作中的一组数据集，该数据集由来自GitHub的Python函数组成，并用它来评估填充模型在函数返回类型预测方面的性能。我们使用这个数据集将StarCoder、StarCoderBase和SantaCoder与InCoder在函数返回类型预测方面进行比较。我们的设置遵循Fried et al. (2022)：每个模型在条件化于每个函数的导入、主体和签名后，使用贪婪生成来填充返回类型。我们报告评估集中所有函数归一化注释的精确匹配准确率，以及仅具有非None注释的函数，遵循Fried et al. (2022)。我们发现StarCoder和StarCoderBase在Python返回类型预测方面优于现有方法（表18）。然而，我们注意到，由于此评估集中的函数取自GitHub仓库，它们可能与SantaCoder和StarCoder模型的训练数据重叠。

表18：Python返回类型预测的准确率，使用Fried et al. (2022) 对Pradel et al. (2020) 基准的改编。我们报告了总体F1分数（包括平凡的None类型预测）和非None类型的F1分数。
(表格数据略，内容同原文)

TypeScript类型预测 Yee & Guha (2023) 评估了TypeScript神经类型预测的方法。然而，他们并没有衡量准确率，而是认为基准应该衡量有多少项目或文件在使用预测类型时没有类型错误。这种方法使得评估那些从未翻译成TypeScript的JavaScript程序的类型预测成为可能，这减少了数据集污染的可能性。我们将StarCoderBase添加到他们的评估框架中，并将其与在原始工作中表现最好的类型预测模型InCoder进行比较。表19显示StarCoderBase优于InCoder：(1) 它产生了更多类型检查通过的包，(2) 在所有包中，它产生了更多没有错误的文件，并且 (3) 它比InCoder产生了更少的平凡类型注释。

表19：使用Yee & Guha (2023) 的数据集和方法论的TypeScript类型预测性能。我们只评估从未翻译成TypeScript的JavaScript包，并将StarCoder与Yee & Guha (2023) 中表现最好的模型InCoder进行比较。StarCoder在几个方面优于InCoder。
(表格数据略，内容同原文)

表20：CodeXGLUE代码总结任务的Python部分性能，评估函数文档字符串生成。模型使用其填充能力以零样本方式评估。
(表格数据略，内容同原文)

Python文档字符串生成 为了评估模型为函数生成文档的能力，我们使用了CodeXGLUE代码总结基准的Python子集 (Lu et al., 2021)。此基准构建自CodeSearchNet数据集 (Husain et al., 2019)，包含来自公共GitHub仓库的函数。模型在条件化于函数签名和主体后，使用贪婪解码填充每个函数的文档字符串。我们遵循以往工作的评估方案：使用平滑的4-gram BLEU (Papineni et al., 2002) 对生成的文档字符串与原始函数的参考文档字符串进行评估，仅使用生成和参考文档字符串的第一行（例如，删除可能在后续行中出现的参数描述和返回类型）。在表20中，我们看到StarCoder和StarCoderBase在文档字符串生成方面获得了比以往工作更高的性能。然而，我们注意到此评估数据集与用于训练SantaCoder和StarCoder模型的数据之间可能存在重叠。

6.3 训练过程中的性能提升

我们在每看到2000亿个token（总共10000亿）后的几个训练检查点评估StarCoderBase的性能。图2（右）显示了对于MultiPL-E支持的每种编程语言，训练过程中性能（pass@1）的变化。几个高资源编程语言的性能曲线表明，更长时间的训练可能会进一步提高它们的性能。

图2：通过数据大小（左）和编程语言（右）划分的StarCoderBase在几个训练检查点上的性能（pass@1）。左图中的线条是对除最左边点外的所有点的pass@1和log数据集大小的线性拟合，预计由于迁移学习，线性关系会在那里断裂（虚线）。拟合优度范围从600B检查点的R² = 0.399到1000B检查点的R² = 0.510。
(图片略，内容同原文)

然而，一些低资源语言在训练期间改进有限，甚至pass@1下降。例如，R的pass@1率在800B和1000B（最终）检查点之间显著下降。pass@1对数据大小的依赖性（图2，左）进一步支持了这一假设，即这与可用数据量有关。线性拟合的斜率在800B和1000B检查点之间增加，而截距减少，即性能仅对数据量足够大（≳1 GB）的语言有所提高。

我们手动检查了R在几个检查点上生成的补全，以更好地理解模型性能。有人可能会假设某些问题比其他问题更难，因此模型在600B、800B和1000B检查点上获得和失去了在R中解决它们的能力，但我们发现情况并非如此。相反，我们发现几个问题的每个问题成功率存在显著差异（表D.3）。对于这些问题，不同检查点之间的通过率变化似乎完全无关。此外，手动检查表明，失败是由小错误引起的，例如计算GCD时未取绝对值、未将字符串转换为字符数组或未检查边界情况。

6.4 长上下文困惑度

StarCoderBase使用8K token窗口进行训练，允许条件化和生成长代码文件。为了评估模型从这种更大上下文中受益的能力，我们将其使用完整8K token窗口大小与2K token窗口大小（许多先前代码模型中使用的）的困惑度 (Bahl et al., 1983) 进行了比较。

为确保StarCoderBase的训练数据与困惑度计算数据之间没有重叠，我们以表21中的每种语言从GitHub下载了10个GNU公共许可证（GPL）仓库。我们将来自所有仓库的文件编译成每种语言的单个文档。然后我们将这些文档分成8K token的块，并在两种条件下计算每个块最后1K个token的困惑度：(1) 模型窗口仅包含块中的最后2K个token（即正在预测的1K个token和前1K个token），以及(2) 模型窗口包含块中的所有8K个token（即正在预测的1K个token和前7K个token）。这评估了模型在预测代码时从额外的文件和仓库级上下文中受益的能力。在表21中，我们报告了所有块中这1K个token区域的平均困惑度。我们看到StarCoderBase确实从其8K上下文窗口提供的额外token条件中受益，所有语言的困惑度都显著降低。

表21：StarCoderBase在使用2K或8K token窗口大小的情况下，对来自10种语言仓库的评估区域（大小为1K token）的困惑度。较大的窗口大小显著降低了困惑度，证明了StarCoder的8K token窗口的益处。
(表格数据略，内容同原文)

7 自然语言评估

尽管StarCoder模型主要被开发为代码LLM，但它们也在大量自然语言文本上进行了训练。大约20%的训练token是自然语言数据：7% GitHub议题、10% Markdown、2% Jupyter笔记本和4% HTML。在本节中，我们评估StarCoderBase在几个自然语言任务上的表现：可能受益于代码和文本训练数据组合的自然语言推理和理解任务；以及评估模型产生不良文本输出倾向的自然语言生成任务，例如在文档生成或交互式助手设置中。

7.1 数学推理

最近的工作表明，代码LLM可以通过一种称为程序辅助语言模型（PAL；Gao et al., 2022）的技术成为有效的算术和符号推理器。使用PAL时，LLM读取推理问题并生成Python程序作为中间推理步骤，然后由Python解释器执行以产生答案。相比之下，思维链方法 (CoT；Wei et al., 2022) 提示LLM在生成答案之前用自然语言生成推理步骤。

我们研究了StarCoderBase在GSM8K (Cobbe et al., 2021) 上的推理能力，这是一组初中数学应用题。我们与两个CodeGen-16B模型 (Nijkamp et al., 2023) 和LLaMA模型家族 (Touvron et al., 2023) 进行了比较。我们的评估结果呈现在表22中，其中我们提供了StarCoderBase和LLaMA的CoT和PAL结果。

与先前比较PAL和CoT在代码LLM上的结果一致 (Gao et al., 2022)，我们发现StarCoderBase使用PAL（21.5%）比使用CoT（8.4%）表现更好。StarCoderBase显著优于使用PAL分别达到13.1%和8.6%的CodeGen-16B-Mono和CodeGen-16B-Multi。这些差异在应用多数投票的情况下仍然存在。对于LLaMA模型，CoT和PAL之间的差异要小得多，尽管我们观察到CoT在7B和13B LLaMA模型上表现略好。有趣的是，我们发现StarCoderBase在此推理基准上优于LLaMA-13B（17.8%）。然而，其性能仍落后于LLaMA-33B（38.7%）。

表22：GSM8K数学推理基准上的8-shot准确率。样本使用贪婪解码生成。maj1@k表示对k个生成进行多数投票。对于多数投票，我们改为使用p = 0.95和温度0.7的核采样生成样本，遵循Gao et al. (2022)。当模型未在给定指标上评估，或Language Model Evaluation Harness中不支持该指标时，我们使用“—”。LLaMA CoT的数字来自Touvron et al. (2023)。
(表格数据略，内容同原文)

7.2 世界知识与阅读理解

MMLU (Hendrycks et al., 2020) 是一个大规模的多任务语言理解基准，涵盖57个知识领域的多项选择题，包括人文学科、STEM和社会科学。CoQA (Reddy et al., 2019) 是一个用于对话问答系统的大规模数据集，衡量模型处理文本段落并回答一系列相互关联问题的能力。我们将StarCoderBase和StarCoder与CodeGen-16B-Multi (Nijkamp et al., 2023)、GPT-NeoX (Black et al., 2022)、LLaMA-7B和LLaMA-13B (Touvron et al., 2023) 进行比较。

我们在表23中呈现MMLU的5-shot准确率，在表24中呈现CoQA的零样本F1分数。在MMLU上，StarCoderBase显著优于CodeGen-16B-Multi（34.2% 对 27.8%），甚至以微弱优势超过GPT-NeoX（32.9%）。然而，两个LLaMA模型都优于StarCoderBase。在CoQA上，StarCoderBase表现优于CodeGen-16B-Multi，但被LLaMA和GPT-NeoX超越。

表23：MMLU语言理解基准上的5-shot准确率。
(表格数据略，内容同原文)

表24：CoQA问答挑战上的零样本准确率。
(表格数据略，内容同原文)

7.3 测量有害生成

当生成开放式文本（如代码文档或技术对话）时，代码LLM（类似于纯文本LLM）可能会产生有害输出。我们将StarCoderBase与先前的代码LLM在衡量模型产生文本中的社会偏见和毒性的基准上进行比较。

7.3.1 社会偏见

近期工作强调，LLMs常常从其预训练语料库中捕捉社会偏见和刻板印象 (Kurita et al., 2019; May et al., 2019; Hutchinson et al., 2020; Meade et al., 2023)。为了量化我们模型中的社会偏见，我们使用StereoSet (Nadeem et al., 2021)。

StereoSet 包含一系列填空式测试，用于衡量语言模型中的社会偏见。StereoSet中的每个示例由一个不完整的句子（例如，我们的管家是BLANK）和三个可能的补全组成。在这些补全中，一个是刻板的（例如，墨西哥人），另一个是反刻板的（例如，意大利人），第三个是不相关的（例如，计算机）。StereoSet定义了三个指标：刻板印象分数、语言建模分数和ICAT分数。刻板印象分数是模型在句子中偏好刻板补全而非反刻板补全的百分比。语言建模分数是模型偏好有意义的补全（刻板或反刻板）而非不相关补全的百分比。最后，Nadeem et al. (2021) 定义了一个理想化上下文关联测试（ICAT）分数，它结合了这两个指标：

ICAT=lms⋅min⁡(ss,100−ss)50ICAT=lms⋅50min(ss,100−ss)​

其中 lms 和 ss 分别表示语言模型分数和刻板印象分数。

我们在表25中报告了StarCoderBase，以及LLaMA-13B和CodeGen-Multi-16B的StereoSet结果。在所有四个偏见领域，我们发现StarCoderBase获得了最低的刻板印象分数，同时也具有竞争力的语言建模分数。这表明StarCoderBase较低的刻板印象分数不仅仅是由于较差的语言建模 (Meade et al., 2022)，这也由高ICAT分数所指示。

表25：性别、职业、种族和宗教偏见的StereoSet句内结果。刻板印象分数接近50%为最佳。语言建模分数和ICAT分数接近100%为最佳。
(表格数据略，内容同原文)

我们还使用Crowdsourced Stereotype Pairs (CrowS-Pairs; Nangia et al. 2020) 评估了StarCoderBase，并将读者引向表D.4中的结果。

7.3.2 毒性

为了评估从我们的模型生成的响应中的毒性，我们使用RealToxicityPrompts (Gehman et al., 2020)，这是一个包含句子级提示的集合，常常引发语言模型的不良响应。我们使用StarCoderBase对来自RealToxicityPrompts的10K个示例生成响应，最小长度为1个token，最大长度为128个token。我们使用核采样 (Holtzman et al., 2020)，p = 0.95，生成所有响应。

我们使用两种方法自动评估响应中的毒性：(i) 基于RoBERTa的 (Liu et al., 2019) 毒性分类器 (Vidgen et al., 2021) 和 (ii) 一个潜在冒犯词汇列表。对于毒性检测器，我们报告使用0.5阈值标记为有毒的响应百分比。对于冒犯词汇列表，我们报告包含冒犯词的响应百分比。我们注意到，虽然冒犯词汇列表可能潜在地错误标记响应，但它可以提供一种粗略的明显毒性度量。我们在表26中报告了结果。

表26：RealToxicityPrompts响应毒性结果。我们报告使用毒性分类器和冒犯词汇列表标记为有毒的响应百分比。分数越低表示生成内容毒性越小。
(表格数据略，内容同原文)

总的来说，我们观察到CodeGen-16B-Multi和StarCoderBase产生的有毒响应似乎都比LLaMA-13B少。例如，LLaMA-13B的响应中有1.43%包含潜在冒犯性token，而StarCoderBase为1.12%。我们还注意到CodeGen-16B-Multi似乎比StarCoderBase产生更少的有毒响应。

7.4 HELM中的推理任务

我们使用HELM (Liang et al., 2022) 评估StarCoderBase，HELM是一个评估套件，旨在通过报告模型在各种任务上的表现来提高LLM的透明度。我们评估模型利用其自然语言和代码预训练来处理HELM中的自然语言推理任务（不包括代码任务，因为我们有自己的广泛代码评估）。在撰写本文时，HELM基准不包括CodeGen、CodeGeex和LLaMA模型。因此，我们将StarCoderBase与

表27：HELM基准中自然语言推理任务的模型结果，按模型在这些任务上的平均排名排序。我们使用“—”表示模型未在给定指标上评估，或在HELM中记录了运行时错误（例如，code-davinci-002和code-cushman-001模型在LSAT和Legal Support上的“unmapped prediction”）。StarCoder通常显著优于其他开放访问模型，并且通常优于大得多的模型。
(表格数据略，内容同原文)

8 定性评估

在附录E中，我们重点介绍了一些我们与StarCoderBase进行的有趣互动。我们希望这些能作为对进一步探索模型能力感兴趣的研究人员和开发者的起点。我们在第E.1节中提供了如何使用Git提交、GitHub议题和Jupyter笔记本的模板来引导出有趣模型行为的示例。在第E.2节中，我们演示了如何在没有任何指令微调的情况下，提示StarCoder扮演技术助手的角色。在第E.3节中，我们发现还可以使用元数据和自然语言的组合来提示模型，以在HumanEval基准上获得更高的pass@1性能。

9 归因工具

随着生成式语言工具变得越来越普及和数据密集型，理解和检查它们所训练的海量文本的需求变得越来越迫切，这既是为了理解模型的失败模式，也是为了以归因追踪和模型生成输出的来源管理的形式提供透明的数据治理反馈。这种理解数据的需求 (Mitchell et al., 2022) 正日益被认识到，并以数据集检查工具和工具包的形式得到实现 (Akiki et al., 2023; Marone & Van Durme, 2023; Piktus et al., 2023)。正是从这个角度出发，我们发布了两个这样的数据检查工具：一个成员检查工具和一个BM25搜索索引。它们补充了现有的在GitHub仓库名称级别操作的“Am I in The Stack”工具。这两个新工具索引了仅用于训练的文件，并允许在文件内容上进行匹配。这些工具作为独立站点提供，但也集成到我们的VSCode演示中。这有助于用户识别可能从训练数据中复制的模型输出部分。通过利用搜索索引，用户可以定位复制片段的相应源文件和仓库。

9.1 成员检查

Marone & Van Durme (2023) 提出了用称为数据画像的成员测试工件来记录数据集。他们提供了一种基于布隆过滤器 (Bloom, 1970) 的具体实现，提供快速且轻量级的成员推断。我们在训练数据中长度为50个字符的字符串上构建了一个基于布隆过滤器的画像。此工件占用26 GB，约为数据大小的3%。该推理工具公开托管，以补充其他文档工件。

可以快速检查模型的生成，以大致评估与训练语料库的重叠程度。VSCode扩展支持将此用作快速的初次归因方法。然而，这要求匹配字符串大于最小大小，并且不尝试过滤常见或通用的代码片段。在初次检查之后，用户可以使用完整的搜索索引来进一步评估归因。

9.2 搜索索引

我们使用Elasticsearch 7.17 索引训练数据集，并提供两个搜索工具来查询它：一个专注于Python子集，一个覆盖整个数据集。代码本身使用小写过滤器和Lucene的ASCIIFoldingFilter进行预处理，使用3-gram分词器进行分词，并使用BM25作为相似度函数的默认Lucene实现进行索引。我们进一步将用户名和许可证字段索引为关键字字段，允许基于这些特定元数据字段进行轻松过滤和查找。两个索引目前都在一台虚拟机上以单节点模式运行。

10 社会影响与局限性

10.1 项目方法

开放科学与开放治理 StarCoder 是一个社区研究项目的成果。该项目本着开放科学的精神进行 (Woelfle et al., 2011)，专注于负责任地开发和使用代码LLM。通过项目期间实施的开放治理实践，决策中的优先权始终倾向于更负责任的选择，即使这可能引入限制，影响采纳或未来研究。例如，法律、伦理、治理工作组决定移除并不发布已识别的恶意代码数据集，即使这些数据可能对未来安全研究有用。

开放性与安全风险 Solaiman (2023) 解释了LLM开发过程中的开放程度如何与模型发布相关的潜在风险联系起来。当系统完全封闭开发时，权力更有可能集中在资源丰富的组织中，并且小型开发团队可能无法完全理解模型部署的影响和长期后果。此外，封闭开发系统通常更难被外部专家审计，并可能阻碍科学进步，因为研究人员无法在彼此的工作基础上进行构建。另一方面，完全开放的开发允许社区研究， democratizes 对模型的访问，并使整个开发过程中的审计成为可能。然而，如果没有适当的防护措施，开放的LLM开发会带来更高的滥用风险，因为增加模型访问权限也增加了模型造成伤害的可能性。即使发布的API可以被关闭，一旦模型权重被释放，几乎不可能收回。因此，在我们项目LLM的开发过程中，讨论和实施负责任的AI实践一直处于中心位置。

10.2 局限性

数据集与数据许可 StarCoder 在 The Stack v1.2 数据集的子集上训练。该数据集已使用许可证检测器进行过滤，以仅包含宽松许可的源代码。尽管如此，许可证检测器可能错误地分类了一些仓库。关于此许可证检测过程的更多细节，请参阅 Kocetkov et al. (2022)。

退出流程 尽管The Stack提供了移除开发者代码的方法，但其退出流程仅适用于单个仓库，并可能受益于进一步增强。例如，当代码在宽松或复制-left许可证下许可时，它可以被复制到另一个仓库，如果版权所有者选择退出，消除这些副本将具有挑战性。需要更多工作来为LLM的大规模训练集创建更好的数据控制和同意机制。

PII检测 尽管我们尽了最大努力去除PII（第4节），StarCoder 仍可能产生PII（但请注意，模型许可限制旨在生成或传播PII以伤害他人的使用）。正如在第4.2节中提到的，我们训练了一个仅编码器模型来检测代码和文本相关任务的PII，并注意到存在误报和漏报的可能性，这可能在处理敏感数据时导致意外后果。此外，PII检测模型的性能可能因不同数据类型和编程语言而异，需要针对特定用例进行进一步验证和微调。PII标注仅对经批准的个人可用，获准访问的研究人员和开发者被期望遵守道德标准并采取数据保护措施。通过使其可访问，我们的目标是鼓励PII编辑技术的进一步研究和开发。

恶意代码 在托管The Stack的Hugging Face平台上，一个恶意代码检测工具识别出654个文件为不安全。在我们的社区帮助下，我们在The Stack v1.2发布之前移除了这些文件。尽管如此，The Stack可能包含未检测到的恶意代码，StarCoder 可能能够生成恶意软件。因此，StarCoder OpenRAIL-M许可证包括一项使用限制，禁止生成和/或传播恶意软件（包括但不限于勒索软件）或任何其他可用于危害电子系统的内容。

模型局限性 StarCoder 受到LLMs典型局限性的影响，包括可能生成不准确、冒犯性、误导性、歧视年龄或性别的内容，或强化其他刻板印象。关于此类安全问题的调查，请参阅第7.3节。部署 StarCoder 需要进一步挑战和调整模型以防止此类行为，例如通过红队测试 (Perez et al., 2022)、对抗性测试 (Wan et al., 2023) 和/或添加稳健的安全层 (OpenAI, 2023b)。该模型以OpenRAIL-M许可证发布，该许可证对模型及其修改以及使用该模型的应用程序施加了可执行的使用限制。

仅英语评估 我们仅在基于英语的基准上评估了 StarCoder 的性能，以了解其编码能力和自然语言理解能力。为了使这些模型对更广泛的受众更易用，未来的研究应调查代码LLM在其他自然语言上的性能和局限性。

代码归因工具 StarCoder 的成员检查工具和BM25搜索索引仅限于针对用于训练的The Stack子集进行数据集检查，因此不会找到未包含或因本项目从数据集中移除的代码的匹配项。基于画像的成员测试工具使用哈希匹配，因此可能存在误报。它也有一个最小分辨率，需要一定量的上下文才能触发匹配。两个归因工具都不试图区分通用代码（例如，样板代码）或受保护内容。然而，我们希望这些工具将支持正在进行的研究，以负责任地开发LLMs。

10.3 社会影响

代码LLMs 我们期望代码LLMs能使来自不同背景的人学习编写更高质量的代码并开发低代码应用程序 (Leinonen et al., 2023)。随着专业开发人员被代码生成系统指导如何编写更健壮和高效的代码，关键任务软件可能变得更容易维护。然而，也应仔细考虑安全影响 (Sandoval et al., 2023)。虽然社会影响旨在积极，但代码LLMs的可访问性提高也伴随着某些风险，例如对生成代码的过度依赖以及对软件开发就业市场的长期影响。我们建议读者参考 Chen et al. (2021, 第7节) 对代码LLMs的更广泛影响分析，以及 Khlaaf et al. (2022) 对此新兴技术的深入风险评估和危害分析。

数据标注 对项目来说，仅使用信誉良好的数据标注服务非常重要。平衡成本（公平报酬）、时间（工作的时间点和完成时间是项目的关键路径）和质量（确保不影响PII检测模型的训练）之间的约束也很重要。虽然考虑了使用受薪员工进行传统数据标注服务，但在审查服务提供商及其报酬实践后，决定与Toloka众包工作者合作——大多数服务商无法就工人报酬提供足够的透明度和保证。我们确定报酬时考虑到了不同国家的最低工资率及其相应的购买力。我们将标注资格限制在那些每小时7.30美元的工资率在购买力平价上相当于美国最高最低工资（16.50美元）的国家。

反馈退出表格 在退出流程的第一阶段，个人被要求说明希望其代码被排除在数据集之外的原因。我们从希望退出的人那里反复听到的担忧是：

• 偏好选择加入而非选择退出。

• 认为无偿使用他们的代码是不公平的。

• 担心当前AI的局限性，以及模型生成可能追溯到他们的工作，导致潜在的法律责任。

• 认为他们的代码质量差，不适合AI训练。

• 他们的代码中存在PII，不希望被公开暴露。

因此，退出表格提供了一个机会，可以直接与内容创作者互动，并了解我们的工作对他们的影响。

对退出流程的社区反馈 我们对那些其数据用于The Stack的特定组织（The Alan Turing Institute 和 The Turing Way）的个人进行了社区研究，并为两个开放的国际研讨会（Open Data Day 2023 和 Mozilla Festival 2023，会议主题为“设计AI生产流程中的数据权利”）做出了贡献。这些定性访谈和参与式共同设计研讨会包括50名参与者，主要来自北美和欧洲，其角色包括研究科学家、社区经理、软件工程师和首席研究员。

社区研究的结果可以总结如下：在LLM数据集的治理方面，参与者认为知道更好，有选择权也更好。大多数参与者对其宽松许可的数据被用于训练LLMs持中性到积极的态度。尽管所有人都对“Am I in The Stack”工具印象深刻，但接受采访的人中没有一个表示真正希望退出。主要的收获似乎是，参与者发现项目的治理工具最有价值的方面在于它们能够提高对数据实践的认识，并赋予个人和社区根据其特定需求采取行动的能力。这些初步对话也凸显了将治理讨论和决策直接带到受影响社区的重要性，这是一个未来工作的重要方向，应将社区研究扩展到北美和欧洲以外。研讨会的参与者还提出了在数据权利考虑中应纳入的新群体的例子，包括艺术家、数据挖掘者和未来世代。共同创造的产出可以在MozFest Miro Board上查看。

11 结论

在本技术报告中，我们描述了BigCode社区在创建StarCoderBase和StarCoder（开放访问的155亿参数、在代码上训练的大语言模型）方面所做的努力。我们在研究和开发过程的所有方面提供了完全的透明度，包括训练数据、数据整理过程、PII编辑流程和模型训练。我们进行了迄今为止最广泛的代码LLM评估，发现StarCoder优于其他代码LLM，如CodeGen (Nijkamp et al., 2023) 和CodeGeeX (Zheng et al., 2023)，并匹配或超越了OpenAI的封闭访问模型code-cushman-001。通过以开放责任AI模型许可证发布StarCoder模型，并通过在GitHub上开源所有用于构建模型的代码库，我们旨在增加代码LLM在研究和开发者社区中的可访问性、可复现性和透明度。模型许可证包括使用限制，以确保模型的修改和使用该模型的应用程序遵守我们负责任的AI原则。此外，我们发布了一套新颖的归因工具，以帮助代码LLM的最终用户检测和定位可能从训练集中复制的模型生成内容。我们希望这些措施有助于实现安全的模型发布，确保性能强大的StarCoder模型始终是一股向善的力量。

致谢

我们感谢 Hugging Face 提供训练 StarCoder 模型的计算资源。我们还感谢 Suriya Gunasekar 在数据检查方面的帮助，以及 Sebastien Paquet 对这项工作的校对。Carolyn Jane Anderson、Arjun Guha、Ming-Ho Yee 和 Yangtian Zi 得到了美国国家科学基金会奖项 SES-2326174 和 CCF-2102288 的支持。Evgenii Zheltonozhskii 得到了以色列科学与人文学院 Adams Fellowships Program 的支持。