《架构师》（2024年第三季）

CONTENTS目录 特别专题AI编程新时代 大模型技术重塑智能研发新范式ABCoder在大模型编程领域的探索 大模型辅助需求代码开发：如何提升核心编码任务生成效果 当在本地就可以运行AI代码助手时，谁还需要GitHubCopilot呢？ 阿里许晓斌：我团队里AI替代程序员还不现实，AI编程工具没产生质变 热门演讲实录新旧架构交融 阿里云AI搜索RAG大模型优化实践 文档解析与向量化技术加速RAG应用落地Mooncake分离式推理架构创新与实践 Kimi背后的长文本大模型推理实践：以KVCache为中心的分离式推理架构端侧大模型推理挑战与优化：商汤SensePPL深度调优实践 大模型在华为推荐场景中的探索和应用 从飞书多维表格的经验，看大模型时代产品之道与技术人才发展华泰证券：事件驱动型微服务架构的实践与探索 北京银行如何构建全栈大模型应用体系？ 平安证券现象级应用：复用率高达19144的微卡片平台是如何构建的精益驱动下的金融智能化变革：大模型与知识工程的进化 II 架构师2024年第三季 本期主编Tina 流程编辑丁晓昀发行人霍泰稳 反馈feedbackgeekbangcom 商务合作hezuogeekbangorg 内容合作editorsgeekbangcom 推荐文章Article 2024年软件工程行业：两年间的变化、原因及未来趋势 InfoQ2024年趋势报告：AI智能体发展不及预期，RAG或成最大赢家字节跳动合并编译实践 单元化架构在字节跳动的落地实践 一行代码价值百万美元：从工程技术角度看云成本优化资源节省81，作业帮MySQL千表入湖仓实践 架构到底要不要分前端和后端？ 拒绝背锅！39岁失业后，我写出了一个超一万亿使用量的数据库Linux版微信正式官宣，居然选了这个90年代的老牌小众框架Netflix引入虚拟线程：性能和缺陷案例研究 访谈文章Interview 老程序员有责任培养新人拯救行业！专访世界编程大师UncleBob：不懂编程只会用AI助手是行业灾难！ AnthonyAlford访谈：AI架构入门 卷首语 越贴近AI开发过程的技能，越容易受到AI的冲击。编程作为AI公司大多数员工的核心技能，无论是在模型训练阶段还是应用阶段，都能形成完整的闭环。这种闭环能力也推动了编程领域的变革速度加快。因此，有观点认为，生成式AI的第一个杀手级应用场景已经出现，那就是AI编程助手。 微软于2022年推出的GitHubCopilot，目前已拥有约200万付费用户，年经常性收入 （ARR）高达3亿美元。而另一款备受关注的工具Cursor，今年收入高达6500万美元。社交媒体上充斥着关于它的各种“神奇故事”：例如“8岁女孩玩转AI编程，45分钟打造聊天机器人”，“我用CursorAI编程开发的App，登上了AppStore排行榜第一”等等。 像Cursor这样的工具，已经让产品经理或拥有创意想法的人能够快速制作出用于验证和试错的Demo。如果项目本身不太复杂，且对全面性要求不高，这种方式完全可行。过去可能需要依赖开发人员的帮助才能实现，而现在，这一门槛已经大幅降低，似乎也不再需要成为编程高手。 然而，鼓励不懂或不精通编程的非专业人士进入软件行业并自行编写软件，与我们此前提倡的“提升专业化水平”的方向有所背离。UncleBob在接受InfoQ采访时也表示，这对IT行业来说可能是一场“灾难”。他认为，人工智能不是人类智能的替代品，人工智能可以是很好的工具，但只有在知道如何使用这些工具的人手中才是如此。 AI编程助手的崛起无疑为编程行业带来了颠覆性的变化，但正如UncleBob所言，这一趋势也伴随着新的挑战。同时，AI编程助手并非万能，它们擅长处理重复性和简单的任务，但在复杂算法和系统架构设计等方面，仍然需要人类程序员的深度参与。AI可以 卷首语 作为辅助工具，但无法完全替代人类的创造力和判断力。总的来说，AI编程助手正在重塑我们的编程方式，但它并不是终点，而是一个全新的起点。 大模型技术重塑智能研发新范式 作者Kitty策划QCon全球软件开发大会 在大模型诞生之后，智能开发一直被视为AI落地的典型场景，走在前沿的开发者也快速接受了代码推荐为主要形态的AI辅助编程。但在此之后，我们期望大模型可以带来更大的效率提升，甚至对开发过程进行重塑与变革，使用全新的人与机的协同关系来让开发进入“真正的智能时代”。 在2024年10月1921日举办的QCon全球软件开发大会上，百度前端架构师、百度技术组织委员会Web方向负责人张立理带来了主题为“大模型技术重塑智能研发新范式”的演讲，从代码推荐到更大规模生成，从辅助到与人协同的角度，在开发工具能力发展、组织与团队引入AI、开发者改变开发形式这三个角度，讲述面向智能化变革面对的挑战与解决方法。 内容亮点： 通过IDE做成块、成篇的代码推荐的交互形式。 为了让编程现场和模型更好地结合在一起，有很多的细节与挑战。 把AI从编程这个环节，推向更广阔的Devops链条，并与现成平台结合让用户真正受益的案例。 以下是演讲实录（经InfoQ进行不改变原意的编辑整理）。 我分享的主题是《大模型技术重塑智能研发新范式》。在我看来，重塑并不是简单地将模型作为一个工具来使用，而是要让模型深入到研发的每一个环节，承担更多的功能和责任，实现真正的变革。我将从几个不同的角度来分享我对重塑的看法以及我的实践经验。 我来自百度的工程效能部，我们的主要任务是推动智能研发场景和相关产品的内部实施，比如我们的百度文心快码。在这方面，无论是我自己的使用体验还是对工具的研发，我都投入了大量的精力和积累了丰富的经验。 我将从几个视角来探讨所谓的重塑。首先，从研发工具的角度来看，自从GitHubCopilot大约两年半前推出以来，这一类代码助手应用经历了怎样的发展，带来了哪些变化。其次，从企业或团队的角度出发，如果我们想要将智能研发落到实处，真正提高效率，那么团队需要考虑哪些因素。最后，从开发者的角度来看，随着大模型技术的发展，我们开始接受以大模型为基础的产品，那么在此基础上，我们有哪些实践可以更好地利用这些大模型，以提升我们的开发效率。在演讲的最后，我还会进行一些总结，并对未来进行展望。 研发工具的发展 智能化的发展背景与落地诉求 我们先来探讨一下智能研发工具领域在这段时间里除了基础能力之外的发展和演变。随着大模型技术的迅速发展，早期在智能研发领域的产品，比如GitHubCopilot，主要提供的是代码补全功能，这是一种纯粹的辅助，旨在帮助开发者在编写代码时提升速度和 效率。然而，现在的工具已经不仅仅局限于这种辅助功能，它们已经从简单的补全转变为代码的生成，从辅助角色转变为与开发者协同工作，分担一部分任务，让开发者能够专注于其他部分。此外，这些工具已经从单一的代码层面进化到理解整个工程的层面，开始承担起工程层面的任务。这种转变体现在几个方面：代码生成的体量、工具承担的职责、生成的效果、提供的能力，以及最终的用户体验和交互方式。 GoFat：更大规模的代码补全 GoFat，是指智能研发工具在不断扩展其功能和能力。以代码续写为例，这是大家在使用这类工具时常见的功能：当你输入一行代码后，工具会显示一段灰色的幽灵文本，这是模型基于推理预测你接下来可能要编写的代码片段。你只需按下Tab键，这段文本就会上屏，替代你手动敲击键盘，从而提升编写效率。 传统的续写功能大多是以行为单位的，比如JetBrains的官方智能功能，称为FullLinecodecompletion，就是基于整行的补全。但以行为单位的补全与我们编写代码时的逻辑概念并不完全吻合。因此，许多工具开始尝试承担更多的代码生成任务，实现更大规模的补全。例如，快捷的代码补全可以扩展到一个分支，如果有注释作为引导，工具可以生成整个方法的逻辑代码，提供更大范围的补全，进一步提升开发效率。 在智能研发工具的发展过程中，我们不可避免地面临一个挑战：多写多错。在有限的上下文中，单行代码的准确率相当高，但随着代码行数的增加，准确率会下降。对于开发者来说，判断一行代码的正确性可能只需要05秒，但判断10行代码的正确性则可能5秒都做不完，这种复杂度的增加是非线性的。因此，在处理多行代码时，准确率变得极其重要。 智能开发产品从几个角度对准确率进行优化。首先是触发时机，并不是所有情况下都适合进行多行补全。例如，当你写了一半的代码时，补全这一行会更准确；但如果在此基础上继续补全三行，准确性就会降低。此外，如果没有上下文联系，比如只写了一个方法名“dowork”，此时补全多行代码显然是不合适的，因为缺乏足够的信息，只能进行猜测。因此，大多数产品会在特殊的语法节点进行控制，比如if、for语句，或者在有注释、连续空行以及其他逻辑的情况下，选择最合适的多行补全时机。 其次是推理逻辑，即模型能够获取的信息，包括前文、后文、相关文件、依赖文件以及库检索等。这部分在后续的开发者个人的章节会详细描述。 模型推理时不会因换行符而停止，而是会持续推导，但这种持续推导会导致错误率增加。因此，我们需要在语法层面控制结束位置，比如在if块结束时停止推理。 最后是质量检查，以规避模型的一些常见错误行为，比如输出连续重复的token或者与光标后的代码重复的内容。通过这些检查，我们可以隐藏不合格或明显低质量的推理结果，因为这些结果不仅不会提升效率，反而会增加开发者阅读代码的负担，降低效率。 根据我们的数据，多行推理的采纳率甚至可以超过平均值。在采样数据时，平均采纳率大约为41（并非最新数据），而多行推理，包括主流语言，可以达到50以上。这表明，当产品和模型结合得当时，进行更大规模的补全可以取得更好的效果。 BeRich：丰富的生成能力 BeRich，即工具的生成能力。除了补全代码，智能工具还提供了更丰富的功能。以代码调优为例，大模型天生具备解释、分析、总结和摘要的能力，因此，当我们要求模型进行代码优化时，它在局部代码规模上的表现是相对可靠的。例如，对于一段代码，模型能够指出其中的重复部分可以提取，建议将明显的字符串转换为常量，指出违反类型安全的地方，并提供修复后的代码。这样，我们不仅在编写代码的过程中使用模型，还可以在代码已经存在的情况下，进一步通过模型进行局部重构和优化，这些能力正在逐渐落地。同时，我们通过产品校验确保优化后的代码与实际代码能够无缝合并，没有任何逻辑上的损失，从而获得最佳的代码重构和优化效果。 另一个能力是函数拆分。我们并不是简单地让模型自由地做拆分，而是针对特定场景进行特殊的模型提示词优化。以前端React组件拆分为例，首先，我们会从组件中提取通用逻辑作为通用函数，这些函数可以在任何地方复用。其次，组件中有一个称为hook的概念，这是组件特有的可复用逻辑，我们也会将其提取为独立的可复用单元。最后，我们会将一个组件拆分成多个小组件，然后将它们重新组合在一起。这是我们在日常工作中进行代码拆分的常见实践。我们作为产品开发者所做的，就是将工程师的日常经验和实践转化为模型的提示词和产品能力，沉淀到我们的产品中。这样，经验丰富的工程师的实际效果可以让更广泛的开发者受益，这远远比简单地告诉模型去拆分函数要准确 得多。 SeekDeep：更深度地了解全库 SeekDeep，即更深度地了解整个代码库。过去，模型对于代码库的理解非常有限，以前它们在帮助编写代码时，主要依据的是光标前后的内容，以及中间应该写什么。然而，随着技术的进步，通过Embedding（嵌入）和向量化等手段，我们现在可以对整个代码库进行索引和理解。 最典型的例子是分析函数的作用。以前，模型可能只能逐行解释这个函数是做什么的。但现在，有了对整个代码库的理解后，我们可以清晰地看到业务逻辑流程，这不仅仅是函数调用的流程。我们可以了解这个业务逻辑的含义，它先做什么，后做什么，以及哪些模块会使用到这个业务逻辑。这种理解类似于流程图，能够直观地展现出来，让你不仅