AI / Technology
DeepSeek-Coder当大语言模型遇上编程——代码智能的崛起
从公开仓库到训练序列的五步数据流程
图 1｜原创教学图。箭头表示数据依次经过规则过滤、依赖解析、仓库级去重与质量筛选，最终变成训练序列；不代表各阶段的数据量比例。依据：§2，Figure 2 的文字说明。
- 训练单位从文件走向仓库。 文件之间的依赖顺序被放进训练样本，而不是把每个文件当孤岛。
- 模型既学续写，也学补洞。 50% PSM 的中间填空策略在消融实验中兼顾了两种能力。
- 结果很强，但不是生产保证。 跨文件消融支持仓库级训练有效；标准基准仍无法覆盖安全、维护成本和真实团队效率。
单文件训练与仓库依赖序列的差别
图 2｜原创教学图。左侧表示文件被孤立处理，右侧表示按调用依赖组织文件；“仓库序列”只表达训练数据的组织方式，不代表模型会执行依赖图。依据：§2.2，Algorithm 1。
真实代码常把定义和调用拆在不同文件里。一个补全点可能依赖别处的类、函数或配置；如果训练样本只保留当前文件，模型就看不到这些关系。论文把这视为现有代码模型难以处理项目级任务的一项原因。[来源：§2.2]
续写与中间填空的训练目标
图 3｜原创教学图。上排只用左侧预测后续；下排同时利用缺口两侧预测中段。图中不表示 token 的实际数量。依据：§3.1.1–§3.1.2。
普通续写只根据左侧内容预测下一个 token，编辑代码却常要参考缺口两边。中间填空训练会把文本切成前缀、中段、后缀，再重排成“前缀—后缀—中段”等形式，让模型学会根据左右文补回缺失内容。1.3B 模型的消融显示，100% FIM 最擅长补中间，却让常规续写最弱；作者因此选择 50% PSM 作为折中。[来源：§3.1.2；Figure 3]
四类任务共同构成多角度评测
图 4｜原创教学图。四个箭头表示四种独立的评测视角，不表示它们被合成为一个总分。依据：§4.1–§4.3。
数值来源：Table 3、Table 4、Table 5。HumanEval 的 50.3% 是多语言列的平均值；论文文字将相对改进约写为 9% 和 11%。
基准通过与真实工程之间仍有验证鸿沟
图 5｜原创教学图。吊桥表示从基准证据到生产可靠性还需额外验证，不表示论文发现了特定事故。
先用自己的仓库做离线测试，再做小范围影子评估。至少分别测跨文件引用是否正确、代码能否编译并通过测试、安全扫描是否报警、延迟和显存是否可接受，以及开发者接受后是否真的少返工。不要把公开基准分数直接换算成“节省多少工程师时间”。
研究附录
论文原题： DeepSeek-Coder: When the Large Language Model Meets Programming -- The Rise of Code Intelligence
作者： Daya Guo 等 · 版本： arXiv:2401.14196v2，2024-01-26
主来源： arXiv 摘要 · 论文 PDF
核心结论
这篇论文真正改变了什么？
DeepSeek-Coder 的重点不是单纯堆参数，而是让模型在训练时更像在读一个真实项目：它保留文件路径，按 import、include 等调用关系排列同一仓库的文件，再让模型同时练习“接着写”和“补中间”。作者据此训练了 1.3B、6.7B、33B 三档开放代码模型，训练量为 2 万亿 token，上下文窗口为 16K。[来源：摘要；§1；§2.2；§3.1]
读完只需记住三点：
- 训练单位从文件走向仓库。 文件之间的依赖顺序被放进训练样本，而不是把每个文件当孤岛。
- 模型既学续写，也学补洞。 50% PSM 的中间填空策略在消融实验中兼顾了两种能力。
- 结果很强，但不是生产保证。 跨文件消融支持仓库级训练有效；标准基准仍无法覆盖安全、维护成本和真实团队效率。
问题
为什么只读单个文件不够？
真实代码常把定义和调用拆在不同文件里。一个补全点可能依赖别处的类、函数或配置；如果训练样本只保留当前文件，模型就看不到这些关系。论文把这视为现有代码模型难以处理项目级任务的一项原因。[来源：§2.2]
开放模型当时差在哪里？
作者关注的是开放代码模型与闭源模型之间的性能差距。此前的 CodeGen、StarCoder、CodeLlama 等已经证明专门训练代码模型可行，但论文指出，研究者难以检查或改造闭源强模型。DeepSeek-Coder 因而同时追求开放权重、多个参数规模和更强的代码表现。[来源：§1；§4 开头]
方法
数据怎样从 GitHub 变成训练材料？
作者收集 2023 年 2 月以前创建的公开仓库，覆盖 87 种编程语言。初步规则过滤后只剩原始数据的 32.8%；随后解析跨文件调用、按仓库去重，再用编译器、质量模型和启发式规则筛掉低质量代码。清洗后的代码数据约 797.92 GB、6.03173 亿个文件；最终训练混合物由 87% 源代码、10% 英文代码相关文本和 3% 中文通用文本组成。[来源：§2；Table 1]
仓库级顺序怎样保留上下文？
系统用正则表达式识别 Python 的 import、C# 的 using、C 的 include 等调用关系，再用能容忍环的改造拓扑排序排列文件。依赖项尽量出现在使用它的文件之前，每个文件开头还加入路径注释。仓库级去重以拼接后的整仓代码为样本，避免删掉几个重复文件后破坏项目结构。[来源：§2.2–§2.3；Algorithm 1]
为什么还要练“补中间”？
普通续写只根据左侧内容预测下一个 token，编辑代码却常要参考缺口两边。中间填空训练会把文本切成前缀、中段、后缀，再重排成“前缀—后缀—中段”等形式，让模型学会根据左右文补回缺失内容。1.3B 模型的消融显示，100% FIM 最擅长补中间，却让常规续写最弱；作者因此选择 50% PSM 作为折中。[来源：§3.1.2；Figure 3]
证据与局限
哪些结果最有说服力？
论文不是只测一种题，而是覆盖代码生成、数据科学库调用、中间补全和跨文件补全。下面选取可直接核对、含义清楚的结果；不同基准不能横向当成同一种“总能力分”。[来源：§4]
| 评测 | DeepSeek-Coder | 对照 | 论文报告的结果 |
|---|---|---|---|
| HumanEval 平均准确率 | Base 33B：50.3% | CodeLlama-Base 34B：41.0% | 高 9.3 个百分点 |
| MBPP | Base 33B：66.0% | CodeLlama-Base 34B：55.2% | 高 10.8 个百分点 |
| DS-1000 平均 Pass@1 | Base 33B：40.2% | CodeLlama-Base 34B：34.3% | 高 5.9 个百分点 |
| LeetCode Contest Pass@1 | Instruct 33B：27.8% | 论文称高于 GPT-3.5-Turbo | 仍与 GPT-4 有明显差距 |
数值来源：Table 3、Table 4、Table 5。HumanEval 的 50.3% 是多语言列的平均值；论文文字将相对改进约写为 9% 和 11%。
仓库级训练真的带来帮助吗？
最直接的证据来自 CrossCodeEval 消融。加入 BM25 检索后，完整 6.7B 模型在 Java、TypeScript、C# 的精确匹配率分别是 17.72%、14.03%、16.23%；去掉仓库级预训练后分别降到 16.64%、13.23%、14.48%。Python 几乎持平（16.14% 对 16.02%）。这支持“仓库组织有帮助”，但效果因语言而异，也不能证明所有提升都来自这一项设计。[来源：§4.3；Table 7]
这些实验还不能说明什么？
HumanEval 和 MBPP 偏向短小题目，论文自己也指出它们未必代表程序员日常代码。CrossCodeEval 虽刻意使用晚于训练截止时间的仓库，但评测上下文最多只有 512 token，生成最多 50 token，仍远小于完整工程。论文没有报告训练算力与能耗、漏洞与恶意代码风险、许可证污染、真实 IDE 延迟、长期维护质量，也没有用开发者对照实验测生产力。[来源：§4.1 的 DS-1000 讨论；§4.3 实验设置；全文未报告项]
实际意义
对开发者和产品团队意味着什么？
这项工作给出的实用方向是：代码助手不该只看当前文件，也要检索相关文件，并把路径与依赖关系交给模型。6.7B 版本在论文的补全测试里提供了较好的效率—准确率折中，适合资源受限场景先行验证；33B 更强，但部署成本需要另算。这里是基于论文结果的产品解释，不是作者对任何具体业务的保证。[来源：§4.2；§4.3]
上线前应该怎样验证？
先用自己的仓库做离线测试，再做小范围影子评估。至少分别测跨文件引用是否正确、代码能否编译并通过测试、安全扫描是否报警、延迟和显存是否可接受，以及开发者接受后是否真的少返工。不要把公开基准分数直接换算成“节省多少工程师时间”。
核查附录：读论文时盯住哪些问题？
- 数据边界： GitHub 数据截止到 2023 年 2 月前；CrossCodeEval 仓库来自 2023 年 3–6 月，作者用时间切分降低直接泄漏风险。[§2.1；§4.3]
- 污染处理： 对 HumanEval、MBPP、GSM8K、MATH 使用 10-gram 匹配过滤；短于 10-gram、但至少 3-gram 的测试串用精确匹配。[§2.4]
- 结果口径： Base 与 Instruct 模型、Pass@1 与精确匹配、不同提示和上下文上限不可混为一谈。[§4 各表]
- 可复核问题： 仓库依赖只靠正则抽取会漏掉多少动态调用？同样数据和训练预算下，仓库排序的净收益是多少？论文没有完整回答。
一句话收束： DeepSeek-Coder 说明，代码模型的进步不只来自参数量，也来自把训练数据组织得更像真实软件工程；但从“会做题”到“能放心进仓库”，仍隔着一整套工程验证。
关于这篇论文的三个关键问题
DeepSeek-Coder：当大语言模型遇上编程——代码智能的崛起 解决了什么问题？
真实代码常把定义和调用拆在不同文件里。一个补全点可能依赖别处的类、函数或配置；如果训练样本只保留当前文件，模型就看不到这些关系。论文把这视为现有代码模型难以处理项目级任务的一项原因。[来源：§2.2]
DeepSeek-Coder：当大语言模型遇上编程——代码智能的崛起 的核心结论有哪些证据？
最直接的证据来自 CrossCodeEval 消融。加入 BM25 检索后，完整 6.7B 模型在 Java、TypeScript、C# 的精确匹配率分别是 17.72%、14.03%、16.23%；去掉仓库级预训练后分别降到 16.64%、13.23%、14.48%。Python 几乎持平（16.14% 对 16.02%）。这支持“仓库组织有帮助”，但效果因语言而异，也不能证明所有提升都来自这一项设计。[来源：§4.3；Table 7]
阅读 DeepSeek-Coder：当大语言模型遇上编程——代码智能的崛起 时最需要注意什么局限？
HumanEval 和 MBPP 偏向短小题目，论文自己也指出它们未必代表程序员日常代码。CrossCodeEval 虽刻意使用晚于训练截止时间的仓库，但评测上下文最多只有 512 token，生成最多 50 token，仍远小于完整工程。论文没有报告训练算力与能耗、漏洞与恶意代码风险、许可证污染、真实 IDE 延迟、长期维护质量，也没有用开发者对照实验测生产力。[来源：§4.1 的 DS-1000 讨论；§4.3 实验设置；全文未报告项]