​

 作者：汪晟    达摩院数据库与存储实验室

引言

随着技术的不断沉淀，研发团队对通过发表学术论文向业界分享研究成果的诉求也愈发强烈。但对许多研发团队而言，论文撰写的相关问题较难把握，例如：如何评估已取得的技术成果是否具备学术价值？学术贡献能否达到顶会水平？如何将其有效转化为学术论文？笔者结合与达摩院数据库与存储实验室和阿里云数据库事业部联合发表二十余篇系统类顶会论文的经历，为大家解答上述问题，分享学术论文阅读、评估与撰写的相关经验。希望能让大家在未来的论文投稿中事半功倍！

顶会论文到底重不重要？难不难？

说到发表顶会论文，很多同学的第一反应是这是高校师生的专属工作，离自己团队的日常工作很远。但实际上，很多同学没意识到，自己的工作背后可能就蕴含着对所在领域有推进作用的学术价值。回顾过去，其实许多具有深远影响力的研究成果就来自于工业界。比如，Google 在 03 到 06 年发表的 GFS、MapReduce、BigTable 三篇论文，就引领了大数据领域的研究热潮，并催生了 HDFS、Hadoop、HBase 等应用广泛的开源项目。而上述研究成果正是从 Google 自身面临的业务挑战中挖掘而来。同时，学术界也意识到工业界提供的实际需求和最佳实践有着重要的指引作用。像数据库三大顶会 SIGMOD/VLDB/ICDE 都专门设有 Industrial Track，鼓励业界分享创新业务场景以及对研究成果实践效果的反馈。因此，从日常工作中发现、归纳研究成果，并以顶会论文方式输出，对个人、团队和所在领域都是非常有价值的。

那到底发表顶会论文难不难呢？大家的普遍认知是顶会论文竞争激烈，而企业本身缺乏写作经验，经常是投入很多精力最后却拿不到结果，ROI 太低了。但实际上，不同类型论文的写作要求不同，对于系统类论文，工业界并非处于劣势。具体来说，对于 “以发表论文为目标作研究”和“为已有技术成果发表论文”，两者的论文写作过程完全不同。后者的写作，更多的是要能够从偏工程的大型系统中挖掘、提炼关键研究点，从而将对核心问题的洞察和贡献分享出来。其论文的“形”是很容易通过经验传授的，论文内涵盖的技术深度与问题洞察才是真正的核心竞争力（我相信这也是很多团队工作的优势所在）。在具备了良好的抽象提炼和写作技巧的基础上，经过实践检验的技术干货是很容易被审稿人鉴赏和肯定的。

达摩院数据库与存储实验室和阿里云数据库事业部联合发表论文的经历，就是体现企业能够高效发表顶会论文的最好佐证。阿里集团在数据库领域有着深厚的技术积累，从早先支持了集团双十一交易峰值，发展到如今支持着阿里云上的企业客户，都体现了数据库团队的技术实力。然而，在学术论文方面却长期缺乏曝光度，自 2014 至 2017 的 4 年间仅发表了一篇顶会论文。随着达摩院数据库与存储实验室在 2018 年成立，我们有效地协助数据库各产品团队对自身技术亮点进行了学术提炼和论文撰写，顶会论文数量逐年增加。例如，2022 年我们在数据库三大顶会 SIGMOD/VLDB/ICDE 上共发表论文 15 篇（包括独立自研论文 8 篇、高校合作论文 7 篇），在学术界产生了非常不错的影响力。

对于有一定技术积累、但缺乏顶会投稿经验的产研团队，本文主要为大家解答下列问题：

● 如何判断技术成果是否具备学术价值？

● 如何评估学术贡献是否达到顶会水平？

● 如何从复杂系统中有效提炼学术贡献？

● 如何将技术成果有效转化为学术论文？

由于文章内容主要来源于个人在数据库领域的研究经历，存在主观偏差，希望大家结合各自领域的实际情况酌情吸收采纳。本文也参考了他人的公开素材，大家可以在文末的参考文献中查阅。

如何判断技术成果是否具备学术价值？

学术价值是一个比较抽象的概念，我们尝试用一句话来粗略性地描述一下学术价值：用有新意的方法有效地解决一个研究问题。

首先，什么是研究问题？日常研发工作中我们遇到的大多数问题可能是工程问题，即在解决方案明确之后，无需加以验证便大概知道方案一定能或者不能解决该问题。比如，我们通过增加系统资源、替换某个独立子模块就能解决的性能问题，多数都是工程问题。而对于研究问题，更多的时候是在脑海里有个基本的思路想法，但是以前没有人按这个思路尝试过，方案可行性和实际效果的不确定性很高，需要反复尝试。

其次，怎样算有效地解决？方法的有效性通常是一个相对的概念，绝大多数情况下每个方法都有其局限性，无法彻底解决目标问题。比如，数据库的事务并发问题，我们可以通过设计新的并发控制算法来不断提升系统事务能力，但很难说有某一种算法彻底解决了事务并发问题，再也不会成为系统瓶颈。因此，只要是相对于现有方案有一定提升就是有效的，提升维度根据具体问题也不尽相同，常见维度包括性能、成本、精度、安全性等。很多情况下，一个新的方法无法在所有维度和场景都优于现有方法，能在“满足某些特定条件下”解决问题也是有效的方法。

最后，什么是有新意度呢？从结果上来看，就是当所在研究领域的大多数研究者读完论文以后，对其将来的研究具有借鉴性和启发性。比如，提出了一个新的研究问题，或者用一种新的技术解决了一个已有问题。当然，新意度本身也是个相对的概念，当某个技术第一次被提出来的时候，对大家是非常有启发性的，但随着这个技术不断被更多的人掌握，也就逐步失去了进一步的启发性和新意度，最后变成了领域“共识”。需要特别指出的是，我们新意度是有“所在领域的大多数研究者”这个限定的，并不是说只有完全新的技术或想法才是有新意度的。比如，利用了另一个领域研究者们熟知的技术解决了本领域的问题，或者重新启用了本领域很多年之前出现但现在大家已经不熟悉的技术解决了新的问题，都是有新意的。

按照上述标准，如果你手头的技术成果能够用一句话总结为 “用什么方法怎样有效地解决了什么问题”，那么就存在潜在的学术价值。

一般而言，对于工作新意度的有效评估是比较费时费力的。我们需要查阅大量相关文献并整理脉络，从而确定自身工作在整个领域体系中的位置。为了能够快速有效地完成新意度的评估，我建议大家可以逐渐培养平时阅读论文的习惯。前期读论文的时候肯定是比较痛苦的，当积累了足够多的领域背景和阅读技巧之后，阅读就会变得越来越轻松。学习论文阅读方法的相关资料很多，大家可以自行学习，这里就不再展开。那评估某个具体工作的新意度，该如何开展呢？一般我们可以从相关的综述类论文和最新的顶会论文作为阅读列表，重点查阅其中涉及 Related Work 的章节，把其中引用的关键文章也加入到阅读列表中，从而逐步扩展成一个系统化的整理。在整理过程中，我们要带着问题阅读相应文章，比如：现有工作做到了什么程度？他们之间是什么演进关系？我们解决了哪些他们没解决的问题？为什么他们解决不了？我们在整个体系中是什么位置？

如何评估学术贡献是否达到顶会水平？

在衡量学术价值时，我们可以参考上述公式进行粗略的量化，即：学术价值 = 问题大小 * 有效性 * 新意度。大多数时候，我们很难取得在三个维度都非常出色的研究成果。个人认为，三个维度乘积大于等于 1000 分的研究成果是具有顶会潜力的。比如，在某一个维度 100 分、另一个维度 10 分就足以在领域内产生影响力了：Simple idea with big impact（强调方法有效性）；Advance of hard problem（强调问题重要性）；Exploration of new direction（强调新方法新思路）。绝大多数论文可能都是中规中矩的三项 10 分，这些论文也是有不错的学术价值的，通过每个单独工作的量变最终产生对整个方向的质变。

此外，找到合适的会议和 Track 也非常关键。以数据库领域的顶会 SIGMOD 为例，它包含了 Research Track（关注技术创新点本身）和 Industrial Track（关注研究成果的工业化实践），其中 Research Track 更进一步细分为 Data Management Track（关注数据管理系统设计）、Data Science Track（关注数据处理算法设计）和 Applications Track（关注新型数据应用场景）。我们要针对工作的特点，定位好最合适的 Track，在后续具体写作时，再根据 Track 调整论文侧重点和写法。面向某个 Track 撰写的论文，最后临时转投其他 Track 的风险是很大的，要尽量避免。

如何从复杂系统中有效提炼学术贡献？

这应该是最棘手的问题了。我们日常工作中开发的产品和系统，一定都是整个团队长期投入合作完成的，庞大而复杂，从中提炼学术贡献无从下手。其实，我们大可不必将整个系统看做一个不可分割的整体，而可以考虑将系统的主要贡献拆分方向形成多篇论文。从不同的粒度层面，我们可以看到不同角度的学术价值，比如是整个系统架构的创新？还是某个功能设计的创新？还是某个技术单点的创新？在一篇论文中，我们需要且仅需要围绕一个核心问题展开就可以。

此外，很多时候大家会在论文中像产品白皮书那样去描述自己的系统设计，这是一个省力（可以从现有文档里直接复用）、但效果非常差的写作方式。对于学术论文而言，读者更希望从中得到的是对他们的启发性，而不是技术实现细节。因此，阐述清楚技术决策背后的思考和依据才是论文的真正目标。一定要能够结合现有其他工作，从更高视角归纳我们效果更好的机会、发现、洞察是什么。

最后，讲清楚工作动机和故事脉络比讲清楚技术细节更重要。针对问题大、效果好、新意高等不同类型的工作，我们需要对症下药地设计逻辑脉络，引导读者认可相应的学术贡献。对于阿里的工作而言，真实业务场景通常都可以成为强化论文动机的优势项，比如没有人会质疑双十一对数据库的高要求。

如何将技术成果有效转化为学术论文？

最后，结合个人多年的投稿经验，我总结了 15 条论文写作建议，非常适合对大型系统做学术论文转化时参考执行： 

1. 指定一位主笔人统筹全文，避免出现逻辑、措辞不统一

在将一个系统转化为论文时，我们经常会这样做：找到各个子系统的负责人，让大家分头写对应章节，最后整合起来。这样的方式其实是非常低效的，由于每个人在写作过程中没有论文其他部分的上下文，经常会出现各章节背景铺垫过长、逻辑重复等情况，大部分内容在后续调整过程中会被整段删除。我的建议是不要着急堆文字，安排一位主笔人来统筹各章节的中心思想和结构逻辑。这个主笔人不需要是全程参与之前系统设计研发、最了解技术细节的同学，更重要的是他要在了解完工作后有统一清晰的整体思路。另外，在文章完成整合后，其他人后续的任何改动都需要主笔人来 Review 和调整，保证全文逻辑自洽、措辞统一。

2. 梳理技术全貌过程中，不要只看团队文档，要一对一访谈

主笔人需要在前期对技术全貌进行梳理，这个过程如果只阅读团队技术文档，是远远不够的。技术文档的目标受众不同，比如：技术文档更关注技术实现的细节，对于设计背后的思考并不一定说明；技术文档通常以相应研发同学的探索过程时间线为脉络来记录，并不一定是从逻辑上最精简、最容易理解的路径；技术文档中由于有些内容工程实现上特别简单，就直接略过了，但可能其背后有很大的学术价值。因此，我们需要对于文档中缺失的内容，与实际负责的同学作一对一访谈，挖掘出背后的逻辑和价值：为什么要做这个子功能？为什么这里用了方法 A 而没用方法 B？这个设计只是个常规设计还是个比较独特的做法？等等。

3. 明确论文的唯一核心点，能用一句话讲清楚关键价值

一篇学术论文只需要围绕一个核心目标点展开，其他核心点可以写另外的论文。以数据库产品 PolarDB 为例，我们可以围绕底层数据存储层的优化技术展开（PolarFS: An Ultra-low Latency and Failure Resilient Distributd File System for Shared Storage Cloud Database），围绕中间计算资源层的解耦技术展开（PolarDB Serverless: A Cloud Native Database for Disaggregated Data Centers），还可以围绕上层关系型分布式架构层展开（PolarDB-X: An Elastic Distributed Relational Database for Cloud-Native Applications）。在拟定手头将要写的文章的核心点时，可以通过上述介绍的评估学术贡献的方法，总结为 “用什么方法怎样有效地解决了什么问题”以明确关键价值。

4. 根据工作特点设计好 Intro 脉络，显式列出可证伪的贡献点

在确定了论文的核心点之后，我们需要进一步确认工作的主要优势在哪个维度，到底是场景很新颖？解决的问题很重要？效果很突出？还是使用方法新意度很高？然后，针对主要优势来梳理论文 Introduction 的故事线，并尽可能的通过吸引眼球的方式引导读者对该优势点进行认同。之后，我们需要把工作的具体贡献点总结为一个列表并显示列出，否则读者很难通过阅读论文的复杂逻辑自行总结提取出其中的关键贡献。同时，列表中的每个贡献点的描述必须是具象化、可证伪的，使得读者能够通过阅读后面的章节来论证这个结论是否是正确的。如果只是单纯的说“这个方法执行速度很快，效果很好”，是难以激发起读者阅读兴趣的。

5. Intro 中描述的贡献点和证据在后续章节都要有对应论证

当明确了 Intro 的整体脉络和全文的主要贡献点之后，我们需要对齐进行有效的组织。一般情况下，Intro 中需要做的是能够顺畅地描述清楚“背景→问题→挑战→方法→结论→贡献”的逻辑链路，目的是让读者能够首先认同问题的有效性，并通过你的引导最终推演出贡献的合理性。至于推演链路上的支持论据是如何得到的，无需具体展开，只需要关联到文章后续的对应章节即可。在 Intro 中加入 forward reference，是一个很好的连接各章节的手段。当我们整理完 Intro 以后，如果发现某个章节的内容完全不需要提及也不影响 Intro 整体逻辑链路，那么就需要重新审视这个章节的必要性。有些出于内容完整性而添加的，可以保留；其余的可以考虑直接删除。

6. 抽象的思考洞察和设计理念单独成章节，与技术细节剥离

在论文主体部分，建议可以将抽象的研究问题和核心的思考洞察整理出来，与具体的技术实现细节剥离，单独成章节。好的问题抽象和想法提炼对读者来说非常重要，甚至比技术细节更重要。因为想法理念的背后是论文作者对问题更本质的思考和洞察，对于其他读者而言是可以直接吸收后结合到他手头上其他研究问题上的，是最具有启发性的。而技术细节的描述，更多的其实是对想法理念的延伸和具象化。有了这样单独的章节，读者可以快速地掌握作者的大致想法，从而更精准地理解主要贡献、更容易地读懂后续的技术细节。同时，这也会促使读者带着疑问、有目的地阅读，激发其阅读兴趣。

7. 围绕核心点各技术子项梳理脉络，避免简单罗列技术细节

对于论文要解决的目标问题，我们通常会用到若干个技术手段来达成。在介绍这些技术点时，我们应该首先要围绕各个技术点进行结构化的梳理，避免简单地罗列技术细节。虽然论文的呈现是线性的，但技术点之间通常是树状或者网状的关系。一方面，我们需要考虑这些技术点分别解决了核心问题的哪些挑战，将他们分类，让读者沿着挑战阅读相应技术方案。另一方面，需要厘清这些技术点之间的依赖关系，比如两个技术点是并列独立的关系，还是递进优化的关系等等。将这些关系在章节开头解释清楚，使得读者在后续阅读时不至于迷失在技术细节中。

8. 技术细节不要面面俱到，围绕与核心点的关联程度作取舍

对于一个复杂系统，其技术细节一定也是非常繁琐的。在描述技术细节的过程中，我们无需追求面面俱到，而应该围绕这些技术细节与核心贡献之间的关联程度作取舍。摒弃不必要的技术细节，并不会影响到论文的贡献度；添加更多的细节，也不会为读者带来更多的启发性。如果只是一味地陈列大量的技术细节，反而可能会降低有效信息的密度、影响阅读流畅度。一般来说，有两类技术细节是可以考虑删减的：

1）与主要贡献点无关或者正交，直接套用其他现有方案就可以解决的内容；

2）对于基本概念理解以后，读者可以很容易独立推导出一样技术方案的内容。

9. 观点描述要遵循总分式表述，第一句话说清楚本段结论

在撰写每一个具体段落时，也有很多需要注意的地方，最终的目标就是要让读者能够非常容易地掌握本段的大意和结论。因此，在大多数情况下，我们应该遵循总分式的表述方式，用每段第一句话点明本段的目标。在给出某个结论的论证时，应该先给出结论，再罗列理由，比如，“我们观察到 A…；同时观察到 B…；所以我们认为 C 是正确的”就不如“我们认为 C 是正确的，因为我们观察到如下两点：A…；B…”更容易让读者流畅地阅读，他在看到最后的结论 C 后，可能还需要回过头去再看 A 和 B，判断下是否能推导出这个结论。类似的，当我们介绍技术细节时，也应该先讲清楚为什么这么做，再说具体是如何做的。

10. 能用结构化形式和具体样例呈现的尽量用，逻辑更清晰

论文中不可避免的会涉及复杂的算法、数据结构、流程等，这些都是相对抽象、难以理解的内容。为了能让读者能够更简单准确地理解，我们应该借助具体的样例来解释算法过程。将具体的数字、内容带入到抽象流程的输入、中间状态、输出中去，让读者自己能够通过样例推演出一样的结果。这个样例只需要涉及一个相对简单的场景，当用户了解基本原理以后，不需要更多样例也能够扩展理解通用场景。此外，我们也要尽可能的思考是否有能够用结构化形式展示的内容，比如列表、表格、伪代码、流程图等，这些都会让读者更容易对论文产生更系统化的认知，提升阅读效率。

11. 所有关键技术点都要有对应的实验设计，经得起推敲

论文中实验章节的设计也很关键，不合理的实验经常会成受到审稿人的挑战。一方面，我们要对整体工作设计 Macro-benchmark，与现有方案进行对比，验证方案整体的有效性。这个过程要特别关注实验的设计是否合理、对比是否公平，要避免用利于自身方法的特定 Workload 来说明方法在通用场景下的优越性。另一方面，我们也要对方案中的各个关键技术点设计 Micro-benchmark，从而证明整个方案中的每个设计点都是不可或缺，起到关键作用的。需要特别注意的是，在讨论实验时不能只是简单陈述图表中的实验结果，更需要给出现象背后的原因分析，比如：为什么结果是这样的？是否符合理论预期？有没有反直觉的情况出现？等等。

12. 不要在对比中故意贬低其他相关工作和友商产品

大家要意识到，学术研究与产品商业化是有很大不同的。研究不是一个“零和游戏”，没有一个既定的市场上限。因此，我们也完全不需要通过在 Related Work 中贬低他人的工作来体现我们工作的价值。研究是一个不断往前推进的过程，不同的工作在其发表时的起点和关注点都不尽相同。我们应该在肯定他人过往贡献的同时，从新机会点的视角来凸显我们工作的贡献。类似的，在实验章节，建议不要直接对比友商的产品，特别是非开源、商业化的产品。因为，这类产品通常都比较复杂，难以公平比较，不好的结果可能会受到友商的质疑。如果实验比较不可避免，可以考虑将结果发送给友商询问其合理性。

13. Related Work 位置认真考虑，相关性不高的放文末

Related Work 章节是让读者了解领域现状，确认论文贡献的主要内容。这个章节的摆放位置需要特别的考虑，当读者在缺乏相关背景知识时，对详细的工作对比分析其实很难读懂并产生共鸣。因此，我们可以参考如下的原则：

1）对于理解本文贡献有引路作用的工作，应该在 Intro 中作简单的提及，否则读者无法理解为什么必须用新提出来的方法；

2）对这个工作的完整细节以及其他相关度不高的工作，应该放在文末的 Related Work 章节详细讨论。同时，在 Related Work 章节不能只是简单的用并列句罗列一个个工作，更需要讨论不同工作之间的关联关系，并在最后总结性地强调一下能凸显出本文贡献的结论和机会点等。

14. 不要对读者背景作假设，多请不了解工作的同学提意见

我们在投稿之前，应该尽可能地找同学阅读并提意见。领域专家对稿件的反馈，对内容的严谨性很重要。但是，非专家同学对稿件的反馈，对论文的质量也同样重要，特别是对于易读性方面。因为，最后的审稿人很多时候也并不是你这个具体问题方向的专家，也会缺乏相关的背景知识。我们要尽量做到内容的自包含（self-contained），让非专家同学可以在不借助外力的情况下读懂论文。特别的，我们需要注意每一位同学在其第一次阅读这个稿件时的反馈，重点关注是读到哪个段落时出现了卡顿的感觉。这个地方一定出现了写作思路和文章表述上的断层，我们可以将向这位同学解释的内容进行整理，合并到文章中去。

15.审稿人的反馈意见非常宝贵，请虚心对待、尽力改进

审稿人的负面意见非常有价值的，我们应该克服内心对负面意见的抵触心理，深入认真思考：他的意见是不是合理的？如果能够优化解决他的问题，这篇文章会不会更体系化、更升华？我们也经常会看到前一个会议被拒的论文，在根据审稿意见修改后，成为后一个会议 Best Paper 的情况。从这个角度去思考，其实审稿意见是在帮助论文自身不断地完善。当然，有些时候，我们也会碰到审稿人意见是完全错误的情况。即便是这种时候，也不一定是审稿人的问题，我们应该冷静思考一下是不是在文章里本身就没有写清楚，而导致了审稿人的误解。我的建议是，尽全力改进审稿人的每一项反馈，这样等论文真正发表以后，每一位读者就都能够轻松读懂文章内容了。

​