StarCoder: may the source be with you!论文分享

今天分享的论文是《StarCoder: may the source be with you!》

原文链接：[2305.06161] StarCoder: may the source be with you!

一篇关于微调LLM的论文，为了学习微调LLM然后进行LLM漏洞挖掘所以看的文章。

BigCode社区是一个致力于负责任开发代码大型语言模型（Code LLMs）的开放科学合作组织，该社区推出了StarCoder和StarCoderBase：这是两个具有155亿参数的模型，具备8K上下文长度、填充能力，并且通过多查询注意力实现了快速大批量推理。StarCoderBase基于The Stack（Kocetkov等人，2022）中的1万亿个标记进行训练，The Stack是一个包含经过许可的GitHub仓库的大型集合，配备了检查工具和退出流程。本文在350亿个Python标记上对StarCoderBase进行了微调，从而创建了StarCoder。本文进行了迄今为止最全面的代码LLM评估，结果表明，StarCoderBase在支持多种编程语言的开源代码LLM中表现优于所有同类模型，并且与OpenAI的code-cushman-001模型相当甚至更优。此外，StarCoder在针对Python进行微调后，不仅在Python任务上表现出色，还能在其他编程语言上保持性能。本文采取了若干重要措施来确保模型安全发布，包括改进的个人可识别信息（PII）删除管道和新颖的归因追踪工具，并根据更具商业可行性的Open Responsible AI Model许可证公开提供StarCoder模型。

生成式人工智能和大型语言模型（LLMs；Brown等人，2020；Chen等人，2021；Chowdhery等人，2022；Zhang等人，2022；OpenAI，2023a）预计将在未来几年对劳动力市场产生重大影响（Eloundou等人，2023；Bommasani等人，2021；世界经济论坛，2023），提升工作效率。针对代码训练的LLM（代码LLM）的应用尤为迅速：微软的Copilot已吸引了超过100万专业开发者（Euronews，2023），而GitHub报告称，对于某些语言，Copilot用户依赖该工具生成的代码占其编写代码总量的35%（Thompson，2022）。然而，LLM的开发和使用引发了关于版权、隐私和开放性的担忧。

在包括美国和欧盟在内的许多司法管辖区，都存在关于内容创作者权利的版权问题，这些创作者的公开数据被用于训练语言模型。有人质疑，在美国，基于此类数据训练的机器学习模型是否属于合理使用原则的范畴（Kuhn，2022；Butterick，2022；Rothchild & Rothchild，2022）。当模型生成的新内容与任何受版权保护的训练数据不相似时，才最有可能被认定为合理使用（Lemley & Casey，2020；Levendowski，2018）。因此，Henderson等人（2023）建议LLM开发者应提供额外工具，以确保这些模型符合当前的版权法。值得注意的是，这些法律问题不仅是学术讨论的主题：针对GitHub Copilot（DOE 1诉GitHub公司，2022）和Stable Diffusion（Andersen等人诉Stability AI等人，2023）的诉讼已经提起。

对个人信息的担忧导致意大利暂时禁止了ChatGPT，并对OpenAI是否遵守欧盟的《通用数据保护条例》（GDPR）展开了持续调查（BBC，2023）。根据这些法规（欧洲理事会，2018；Lomas，2022），处理个人信息的组织必须有合法依据。这些法律可能会对从互联网收集大量公开数据的LLM开发者产生影响，因为这些数据可能包含个人信息。在如此大规模的数据收集中，获得数据创作者的明确同意是困难的，而且对于处理这些个人信息是否存在其他法律依据也不确定。此外，即使有合法依据，GDPR也要求数据处理者告知个人其数据是如何被处理的，并提供数据访问控制，例如数据删除权或错误数据修改权。这就要求LLM提供者透明公开其收集的数据，并提供工具让个人检查自己的数据并有可能删除它。

生成式AI模型开发过程缺乏透明度和开放性，这也引起了科学界的担忧。许多模型在不同程度上属于闭源：从仅在开发机构内部可用（Chowdhery等人，2022；Hoffmann等人，2022），到通过付费API公开访问但隐藏开发过程的许多细节（Brown等人，2020；OpenAI，2023a）。尽管API访问允许研究人员对这些模型进行实验，但它限制了他们研究LLM安全性的能力（Perez等人，2022）、检查模型内部工作机制的能力（Olsson等人，2022）以及为模型改进做出贡献的能力（Togelius & Yannakakis，2023）。

本文将“开源访问”定义为模型权重公开的模型。尽管存在其他开源访问模型，但这些项目的开放程度仍各不相同；一些发布了权重的模型对模型分发有限制（Touvron等人，2023），或者不发布训练数据集（Nijkamp等人，2023；Zhang等人，2022；Fried等人，2022）。即使在模型和训练数据都被许可发布的情况下（Raffel等人，2020；Tay等人，2022），外部研究人员通常也没有机会参与指导行业生产模型的开发。相比之下，其他LLM开发项目采取了完全开放的方法，旨在允许社区参与模型开发、发布训练数据，并在整个开发过程中接受外部审计（Solaiman，2023）。BigScience研究研讨会（BigScience Workshop，2022）就是一个例子，这是一个由数百名研究人员组成的开放科学合作组织（Akiki等人，2022），他们合作发布了多语言LLM——BLOOM（Scao等人，2022；Muennighoff等人，2022）。同样，EleutherAI是一个从草根组织发展为非营利研究计划的机构，它发布了包括GPT-NeoX（Black等人，2022）、GPT-J（Wang & Komatsuzaki，2021）和Pythia（Biderman等人，2023）在内的开源访问LLM，以及相关的训练数据（Gao等人，2021a）。

在本文中，描述了由BigCode社区开发和发布的开源代码LLM——StarCoder和StarCoderBase，重点关注尊重版权、隐私、透明度和社区驱动的模型开发。该项目是一个专注于负责任开发代码LLM的开放科学合作项目，由两个行业研究实验室共同管理，由来自不同学术机构和行业实验室的600多名成员组成。The Stack（Kocetkov等人，2022）是一个公开可用的代码LLM预训练数据集，具有透明的数据治理框架。The Stack包含6.4 TB经过许可的384种编程语言的源代码，在数据集的v1.2版本中还包括54 GB的GitHub问题和仓库级元数据。该数据集配备了“我是否在The Stack中”这一治理工具，供开发者检查自己的源代码是否属于该数据集，同时也为希望将自己的代码从数据集中移除的开发者提供了退出流程。

StarCoder和StarCoderBase都是155亿参数的模型，基于The Stack中经过许可的数据进行训练。本文在来自80多种编程语言、GitHub问题、Git提交和Jupyter笔记本的1万亿个标记上训练了StarCoderBase。本文在另外350亿个Python标记上对StarCoderBase进行了微调，从而得到了StarCoder模型。这两个StarCoder模型具有一系列新颖的架构特征组合，例如8K标记的上下文长度（Dao等人，2022）、通过中间填充（FIM；Bavarian等人，2022）实现的填充能力，以及通过多查询注意力（MQA；Shazeer，2019）实现的快速大批量推理。本文对StarCoder模型进行了广泛评估，并发布了一个演示程序以及一个集成的归因工具，该工具可以帮助用户定位模型生成内容中可能从训练集中复制的部分。

本文的主要贡献如下：

- 本文发布了StarCoderBase和StarCoder，这两个开源代码LLM在80多种编程语言上进行了训练，支持其他开源代码LLM所不具备的新颖功能和架构特征组合。

- 本文使用多样化的基准（Lai等人，2022；Cassano等人，2023；Pearce等人，2022；Fried等人，2022；Yee & Guha，2023；Austin等人，2021；Chen等人，2021；Ben Allal等人，2022；Hendrycks等人，2020；Reddy等人，2019；Cobbe等人，2021；Nadeem等人，2021；Gehman等人，2020；Liang等人，2022）对代码LLM进行了迄今为止最全面的评估，结果表明：

    - StarCoder在支持多种编程语言的所有开源LLM中表现最佳（Nijkamp等人，2023；Zheng等人，2023）；

    - StarCoder与OpenAI的code-cushman-001模型相当甚至更优；

    - 当针对Python进行微调时，StarCoder大幅优于其他同样针对Python进行微调的现有LLM。

- 本文为安全发布开源模型采取了重要措施：

    - 本文根据OpenRAIL-M许可协议发布StarCoder，该协议允许免版税地访问、使用和分发模型，同时在已确定的关键场景中嵌入了一系列使用限制。本文制定的许可协议版本：（i）对于希望使用和分发该模型的公司而言更具商业可行性；（ii）通过共享AI文档（如模型卡片）来促进透明度和理解（Mitchell等人，2019）；

    - 本文在VSCode演示程序中集成了一个新的归因工具，该工具可以帮助用户检测和定位模型生成内容中可能从训练集中复制的部分。这是通过一个两步流程实现的，该流程包括轻量级成员资格检查，然后在BM25索引上进行搜索（第9节）；

    - 本文通过收集包含12,000个文件和22,950个带注释实体的PII数据集，显著改进了PII删除管道。本文在该数据集上对自己的编码器模型（StarEncoder）进行了微调，得到了一个强大的PII检测模型（第4节）。

相关工作

语言模型

早期构建大规模语言模型的工作使用了n-gram和简单的平滑技术（Brants等人，2007；Heafield等人，2013；Buck等人，2014）。其他方法将各种神经网络架构（如前馈网络（Bengio等人，2000）和循环网络（Mikolov等人，2010；Jozefowicz等人，2016））应用于语言建模任务。Transformer架构（Vaswani等人，2017）推动了高可扩展语言模型的发展（Radford等人，2019；Brown等人，2020），这些模型在语言建模损失与模型规模、训练标记数量和计算预算等缩放因子之间表现出可预测的关系（Kaplan等人，2020；Hoffmann等人，2022）。

代码语言模型

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

闭源LLM

多家大型科技公司开发了性能顶尖的LLM但未发布，例如谷歌的PaLM（Chowdhery等人，2022）和LaMDA（Thoppilan等人，2022）、DeepMind的Chinchilla（Hoffmann等人，2022）和Gopher（Rae等人，2021），以及NVIDIA的Megatron-Turing NLG（Smith等人，2022）。OpenAI和其他AI初创公司（包括Cohere、Anthropic和Aleph Alpha）以付费API服务形式提供LLM，这些公司既未发布模型权重，也未提供创建模型方法的全面信息。OpenAI已发布GPT系列模型的多篇技术报告（Brown等人，2020；Chen等人，2021；OpenAI，2023a），展示其模型的能力。

开源LLM

众多开源LLM已发布给AI社区，尽管其性能通常不及闭源模型。在本文中，当模型权重公开可用时，本文使用“开源LLM”这一术语。值得注意的是，开源模型在训练数据和过滤技术的透明度方面存在显著差异。例如，EleutherAI发布了GPT-NeoX-20B（Black等人，2022）和GPT-J-6B（Wang & Komatsuzaki，2021），以及这些模型训练所用的数据集（Gao等人，2021a）。谷歌发布了UL2-20B（Tay等人，2022），这是一种基于公开可用的C4数据集（Raffel等人，2020）训练的编码器-解码器模型。清华大学发布了GLM-130B（Zeng等人，2022）和CodeGeeX-13B（Zheng等人，2023）的权重，但未发布训练集。Salesforce发布了CodeGen-Mono-16B（Nijkamp等人，2023），但未披露专有的Python数据集。Meta在非商业许可下发布了OPT（Zhang等人，2022）、LLaMA（Touvron等人，2023）和InCoder模型（Fried等人，2022），仅提供数据收集和过滤过程的高级别细节。

数据整理与清洗

编程语言

编程语言选择

从The Stack中的358种编程语言中，本文选择了86种。根据文件扩展名对数据进行编程语言分配（Kocetkov等人，2022）。本文纳入了所有数据量超过500MB的编程语言，以及在Githut 2.0或2022年12月TIOBE编程语言流行度指数中排名前50的语言。此外，本文还纳入了已选编程语言的方言（例如Lisp的Racket和Scheme）。本文排除了配置语言（如Nix、Puppet等）和不再积极维护的语言（如ActionScript）。本文也纳入了JSON和YAML等数据格式，但限制了其数据量（详见“JSON和YAML”段落）。所选编程语言的完整列表可在表中找到。在MultiPL-E（Cassano等人，2023）包含的语言中，只有D和Swift未纳入训练集。对于D语言，文件的语言错误分类导致The Stack中其数据量不足2MB（Kocetkov等人，2022）；Swift因人为错误被排除在最终语言列表之外。

可视化检查

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

XML过滤

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

字母过滤

在调查中本文发现，某些扩展名（如MATLAB）包含许多频繁存储大张量的数据文件。为识别这些文件，本文开发了一个字母过滤器，移除字母字符少于25%的文件。然而，当本文在小部分数据上测试此过滤器时，发现其对某些编程语言（如汇编语言）的误报率很高。为解决此问题，本文关注检测次数最多的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%的数据量。

本文使用了作为The Stack v1.2组件收集的GitHub问题和拉取请求中的自然语言对话。每个对话由一系列带有操作的事件组成，如打开问题、创建评论或关闭问题。每个事件包括作者的用户名、消息、操作和创建日期。本文按以下方式过滤这些数据：

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节。

Git提交数据从BigQuery收集，仅包含与The Stack中使用相同许可证和文件扩展名的仓库的单文件提交。本文移除了所有选择退出The Stack的用户的仓库，原始数据集约4 TB。本文对文件进行50%的采样，并使用启发式方法过滤剩余数据以构建高质量数据集，所有过滤器列于下表并描述如下。

提交中的代码变更行数可能与文件大小相比较少。为避免在学习复制文件内容上花费过多计算资源，本文仅20%的时间使用完整文件，其余80%在第一个和最后一个变更行周围0-32行的窗口内采样，最终得到的数据集包含64 GB的提交数据。

社会影响与局限性

项目方法

开放科学与开放治理

StarCoder是一个社区研究项目的成果，该项目以开放科学（Woelfle等人，2011）的精神开展，专注于代码LLM的负责任开发和使用。通过项目全过程的开放治理实践，决策始终优先考虑更负责任的选项，即使这意味着引入可能影响采用率或未来研究的限制。例如，法律、伦理与治理工作组决定删除并不发布已识别的恶意代码数据集，尽管这些数据可能对未来的安全研究有用。

开放性与安全风险

Solaiman（2023）解释了LLM开发过程的开放程度如何与模型发布相关的潜在风险相联系。当系统以完全封闭的方式开发时，权力更有可能集中在资源丰富的组织手中，而小型开发团队可能无法完全理解模型部署的影响和长期后果。此外，封闭开发系统通常难以被外部专家审计，并且可能阻碍科学进步，因为研究人员无法在彼此的工作基础上进行构建。另一方面，完全开放的开发允许社区研究、民主化模型访问，并支持整个开发过程的审计。然而，如果没有适当的保障措施，开放LLM开发会带来更高的滥用风险，因为模型访问的增加也会增加模型造成伤害的可能性。尽管已发布的API可以关闭，但一旦模型权重发布，就几乎不可能收回。因此，在本文项目的LLM开发过程中，讨论和实施负责任的AI实践一直是核心工作。

局限性

数据集与数据许可

StarCoder基于The Stack v1.2数据集的一个子集进行训练，该数据集已使用许可证检测器过滤，仅包含经过许可的源代码。尽管如此，许可证检测器可能错误分类了许多仓库，有关此许可证检测过程的更多详细信息，请参见Kocetkov等人（2022）。

退出流程

尽管The Stack提供了移除开发者代码的方法，但其退出流程仅适用于单个仓库，仍需进一步改进。例如，当代码根据宽松或Copyleft许可证获得许可时，它可以被复制到另一个仓库，如果版权所有者选择退出，要消除此类副本具有挑战性。为LLM的大规

PII检测

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

恶意代码

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

模型局限性

StarCoder存在LLM的典型局限性，包括可能生成不准确、冒犯性、误导性、基于年龄或性别歧视的内容，或强化其他刻板印象的内容。有关此类安全问题的调查，请参见第7.3节。StarCoder的部署需要进一步挑战和调整模型，以防止此类行为，例如通过红队测试（Perez等人，2022）、对抗性测试（Wan等人，2023）和/或添加强大的安全层（OpenAI，2023b）。该模型根据OpenRAIL-M许可证发布，该许可证对模型及其修改以及使用该模型的应用施加了可执行的使用限制。

仅英语评估

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

代码归因工具

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

社会影响

代码LLM

本文预计代码LLM将使来自不同背景的人们能够学习编写更高质量的代码并开发低代码应用程序（Leinonen等人，2023）。随着专业开发人员在代码生成系统的指导下编写更健壮和高效的代码，关键任务软件的维护可能会变得更加容易。然而，也应仔细考虑安全影响（Sandoval等人，2023）。尽管预期社会影响是积极的，但代码LLM可访问性的增加带来了某些风险，例如过度依赖生成的代码以及对软件开发就业市场的长期影响。有关代码LLM的更广泛影响分析，请参见Chen等人（2021，第7节），以及Khlaaf等人（2022）对这一新兴技术的深入风险评估和危害分析。

数据注释

项目仅使用信誉良好的数据注释服务非常重要。平衡成本（公平补偿）、时间（工作的时间和完成时间是项目的关键路径）和质量（确保PII检测模型训练不受影响）也很重要。尽管考虑了使用受薪员工的传统数据注释服务，但在审查服务提供商及其补偿实践后，决定与Toloka众包工作者合作——大多数提供商无法提供足够的透明度和工人补偿保证。本文对补偿的确定考虑了不同国家的最低工资及其相应的购买力，本文将注释资格限制在按购买力平价计算7.30美元/小时的时薪相当于美国最高最低工资（16.50美元）的国家。

反馈退出表单

在退出流程的第一阶段，要求个人说明希望其代码从数据集中排除的原因。本文从希望退出的个人那里听到的常见担忧包括：

- 偏好选择加入而非选择退出的方法。

- 认为在没有补偿的情况下使用其代码是不公平的。

- 对当前AI局限性的担忧，以及模型生成内容可能追溯到其工作的潜在法律责任。

- 认为其代码质量差，不适合AI训练。

- 其代码中存在PII，不希望公开暴露。

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

社区对退出流程的反馈

本文与The Stack中使用其数据的特定组织（Alan Turing研究所和Turing Way）的个人进行了社区研究，并为两个开放的国际研讨会做出了贡献（2023年开放数据日和2023年Mozilla Festival，其中有一个名为“AI生产管道中的数据权利设计”的会议）。这些定性访谈和参与式共同设计研讨会包括50名参与者，主要来自北美和欧洲，角色包括研究科学家、社区经理、软件工程师和首席研究员（PI）。

社区研究的结果可以总结如下：在LLM数据集的治理方面，参与者认为“知道更好”和“有选择更好”。大多数参与者对其经过许可的数据被用于训练LLM持中立到积极的态度。尽管所有人都对“我是否在The Stack中”工具印象良好，但没有一位受访者表示实际希望退出。主要结论似乎是，参与者发现该项目的治理工具最有价值的地方在于其提高数据实践意识的能力，并授权个人和社区根据其特定需求采取行动。这些初步对话还强调了将治理讨论和决策直接带给受影响社区的重要性，这是未来工作的重要方向，应该将社区研究扩展到北美和欧洲以外的地区。研讨会的参与者还提出了在数据权利考虑中应关注的新群体的例子，包括艺术家、数据矿工和后代。共同创建的输出可以在这个MozFest Miro板上查看。

做个总结：

在本技术报告中，描述了BigCode社区创建StarCoderBase和StarCoder的努力，这是在代码上训练的155亿参数开源大型语言模型。本文对研究和开发过程的所有方面提供了完全透明度，包括训练数据、数据整理过程、PII脱敏管道和模型训练。本文进行了迄今为止最广泛的代码LLM评估，发现StarCoder优于其他代码LLM，如CodeGen（Nijkamp等人，2023）和CodeGeeX（Zheng等人，2023），并与OpenAI的闭源code-cushman-001模型相当或更优。通过使用Open Responsible AI Model许可证发布StarCoder模型，并在GitHub上开源构建模型的所有代码存储库，本文旨在增加代码LLM在研究和开发者社区中的访问性、可重复性和透明度。模型许可证包含使用限制，以确保模型的修改和使用该模型的应用遵守本文的负责任AI原则。此外，本文发布了一套新颖的归因工具，以帮助代码LLM的最终用户检测和定位模型生成内容中可能从训练集复制的部分。本文希望这些措施有助于安全发布模型，确保高性能的StarCoder模型继续成为一股向善的力量。