AGI 在网易云信的技术提效和业务创新

We believe our research will eventually lead to artificial general intelligence, a system that can solve human-level problems. Building safe and beneficial AGI is our mission.

                                                                                            ----  OpenAI

通用人工智能 AGI 作为 AI 的终极形态，是 AI 行业内追求的演进方向，从早期的图灵测试，到现在的 ChatGPT，AGI 的研究一直是 AI 领域的热门话题。ChatGPT 的出现让大家第一次意识到 AGI 的能力已经有了这么大的进展。

当然，当前阶段 AGI 还远未成熟，AI 辅助生成内容（AIGC）的方式是现阶段应用的主流方式。特别是最近半年以来，大模型行业每天都在发生新的进化，网易云信在这股浪潮下一直在思考，我们的业务和产品可以怎么更好的赶上这一波创新的浪潮，今天要讨论和分享的也是最近一段时间我们业务的思考和实践。

为了便于说明后续的一些实践，先介绍下云信的产品形态，作为 PaaS 平台，我们主要提供简单易用的 SDK API 接口，帮助开发者集成出通信能力，包括 IM 通信和 RTC 语音通信。这个图里可以看到我们提供的主要几个层次的服务。

• 最下层是通信网络，这个网络可以承载媒体、信令、消息等。
• 第三层是PaaS服务，是我们的核心SKU，包括IM即时通讯、音视频通话、直播、点播等。
• 第二层是整体的支撑能力，比如即时通讯里的单聊、群聊和大型的聊天室，音视频通话里的实时视频、美颜降噪等能力。
• 最上层是场景方案，我们希望提供给客户更简单易用的解决方案，包括可以直接插入各场景的组件。在娱乐社交、教育、医疗、金融等场景下，我们都有对应的代码级别的、能直接使用的解决方案。

软件研发生命周期和 AIGC 的结合场景

现在已经有很多种 AIGC 的应用方式，比较常见的一类是文字生产能力，输入一段文本，经过生成式 AI 模型处理后，进一步扩展新的内容，包括文本、代码、图片、音频、视频等。还有一种是多模态生产能力，就是输入图片、视频、音频等内容，再进一步生成更复杂的图片、音视频等。

这两种方式有一些已经相对成熟，特别是像文字生产能力，有很多已经上线在业务生产环节使用。比如生成营销内容、销售手册，包括写作、创作等，ChatGPT 的训练素材大半来自于 github，所以它对代码的理解非常强，生成的质量也很高。

那这些应用方式怎么与研发生命周期结合起来的？我们分析一个经典的软件研发生命周期的图例。

这里定义了几个阶段：需求分析、产品设计、开发、测试和部署、运营阶段，上面提到的文字、图片的生产能力，就可以切入到这里的每一个环节的。

在需求分析阶段，有很多资料需要收集和汇总，要创作很多文案，包括分析需求，调研市场，生成用户故事，这些都可以利用文本生成能力。

• 在产品设计阶段，产品交互设计、系统架构设计、流程图设计都可以通过 AI 的能力去降低工作量。
• 在开发阶段方面的应用，比如代码生成、代码重构、代码解释、测试用例编写、辅助数据生成等有相应的工具。
• 上线、运营、售后阶段，也可以通过使用 AI 能力，做线上性能和数据分析，建立智能文档问答、智能客户服务系统满足高效运营要求。

而这些 AIGC 能力和研发生命周期的结合的应用方式，还是得益于 AI 带来的更低成本的知识理解和智能决策、更强的协作和沟通能力、更好的工具和平台。    

知识理解和智能决策：AIGC 的出现，极大地降低了我们跨领域知识学习的成本，无论是新的知识技能的学习，还是对已有知识的进一步深入，都得到了极大的便利。对于我们这种 PaaS 企业来说，这一点尤为明显。我们经常需要接触来自不同行业，不同领域，不同方向的客户，而 GPT 能够帮助我们快速获取并理解这些新领域的知识，有效地补足我们的知识短板。例如，我们可以用麦肯锡的方法论向 GPT 提问，通过这样的互动，我们能迅速学习并掌握新的知识。

协作和沟通：我们每天都要面对大量的信息，这些信息的理解和流转是一个很大的消耗。然而，AI 的提取、总结、抽象和规范能力，可以帮助我们有效地处理这些信息，减轻信息过载带来的压力，缓解团队协作的瓶颈。例如，聊天工具的每日总结功能、文档工具的自动改写能力以及数据透视功能，都极大地提高了我们的工作效率和协作能力。

工具和平台：通过开源模型和开放 API 等的能力，将 AI 能力整合到已有的工具平台上，可以有效地对我们现有的工具和平台进行增强，提高我们的创作能力，降低创新的门槛。通过使用诸如 Copilot、Notion、Midjourney 这样的工具，我们能够快速生成代码、设计图、文档等，从而大大提高单位时间内的生产效率。 

云信 AIGC 的一些探索和实践

结合案例再看一下 AI 的能力和云信业务的实践方式。

首先是 SDLC 的产品需求分析阶段：

下图是我们研发流程的一个流程示意，表示了我们从接受需求，到评估、排期、开发、上线过程中各个角色应该做的事。每个框都是每个角色应该做的内容指引，图比较小，但其实细节不重要，这个流程很复杂，里面的某一个环节做得不好，就会影响到下一个环境，环环相扣，最终拖延了上线周期，或产生线上 bug，最终影响客户，影响效率。

但其实效率折损最大的漏洞是在这张图的外面，就是怎么获取需求，怎么和客户沟通，怎么知道客户想要的东西的诉求，这个才是最难的，写代码都还是其次了。我们作为 To B 的业务与 To C 的产品有一些不一样的地方，我们的客户是企业，企业的数量是远远小于终端用户的数量的，我们的新客户不像 C 端产品， C 端产品一个新功能上线，目标就是几百万新客户，达不到好像就很失败了，而 To B 的客户是用手指头数的，是一个一个谈下来，一个一个销售、售前去攻下来的，所以每一个客户都对我们非常重要，我们要不断挖掘怎么找到新客户的路径。

因此，在产品市场分析阶段，我们一直在探索如何将我们的 AI 技术运用到客户获取过程中，特别是如何提高获取潜在有效客户的效率。一种可能的解决方案是我们可以查看应用市场的 App 排行榜，分析那些客户的业务场景是否与云信匹配，是否有竞品存在，以及客户的工商信息，市场信息和背景信息等。但这个过程，获取排行榜，以及后续的分析和识别工作需要大量的人力投入。

然而，随着 AIGC 技术的发展，我们发现它具有极强的指标抽象和提炼能力。加上应用市场抓取的信息一般数据量不会太大，非常适合进行 few-shot 学习。通过训练 AIGC 模型，我们可以自动化地进行这些分析和识别打标工作，极大地提高了我们的工作效率。同时，这样的方法也可以帮助我们更精准地定位潜在客户，从而提高我们的市场竞争力。

第二个是 AIGC 与开发过程的结合

我们借鉴了微软基于 OpenAI 构建 Copilot 产品线的思路。实际上，我们认为 Copilot 这个概念非常适合当前 AIGC 的能力定位。AI 的作用就像一个助手，帮我们查漏补缺、做一些繁琐的工作，但并不是要取代我们，只是作为副驾驶，提供建议和想法，最终的决策还是由程序员自己来做。这种角色定位在当前 AI 的能力还未完全发展，在还未达到真正的通用人工智能（AGI）时，是非常匹配的。

例如，GitHub Copilot 的能力可以辅助我们进行代码补全、生成代码片段、排查和修复问题。

我的同事还将 OpenAI 集成到了我们 GitLab 的 MR 流程中，触发 AI Review 提供一个代码提交时的检查功能。

ChatGPT 给研发带来的提升，并不仅仅是代码的生产数量，还包括一些思考方向的优化。程序员有时候会很纠结，比如在打开一个空白的代码页面准备开始工作的时候，需要考虑很多复杂的问题，比如变量名怎么取、文件名要表达什么信息、函数的组织关系应该如何等等。但在 Copilot 的帮助下，很多问题能提供比较好的模板，给我们提供 quick start 的思路。

使用这类 AI 工具其实也是一个工程优化的过程。AI 当前并非处于完全可控的状态，我们需要不断进行尝试、调整和优化。在这个过程中，我们对于模型的理解其实是比较重要的，以下几个 TIPS 可以参考。

首先，我们需要给模型提供明确的指令，并尽量减少歧义。对于程序员来说，这个原则可能会感到既熟悉又陌生。在写传统编程语言时，明确的输入是一个基础要求，但当我们使用自然语言描述时，情况就不太一样了。自然语言的信息量大且容易预设一些前提，这就产生了所谓的“知识的诅咒”——我们很难把自己明白的事情清楚地解释给不明白的人。这个问题在与 AI 模型交流时尤其突出，因为大模型的思考模式并不完全和我们一致。例如，当我们让模型“翻转一个单词”的拼写时，大模型的基础单元是 token，它可能只是以 token 为单位进行了翻转，而没有以字母为单位进行翻转，这个和我们的一般的认识是不一致的。

其次，我们需要让模型有思考的时间。比如使用 COT（Chain of Thought）思维链模式，按步骤指导模型，明确每个步骤的输出，这样可以让模型更好地理解操作要求。

此外，无论是使用 one-shot 还是 few-shots，都是给模型提供示例，让它能按照示例明确需求，示例无论对于机器还是对于人类的学习都是一个非常重要的步骤。

最后，如果你觉得不确定，也可以让模型在条件不足时提问。在我们补充足够的信息后，模型再输出内容。这样可以确保结果的准确性。

借鉴以 AI 为 Copilot 的理念，我们让各个团队在业务开发过程中自行探寻针对特定场景的解决方案。例如，接下来要介绍的一个实际案例——“标注助手”。

我们的工作场景中，仍有许多涉及到传统机器学习算法的部分需要进一步优化，这类算法的效果很大程度上取决于我们进行标注的数据量——用人工的努力创造智能。

以我们的会议产品为例，我们为用户提供了集成到他们应用的会议模块。在这其中，背景虚化是一个普遍的需求。然而在一些特殊情况下，比如人物挥手的时候，背景虚化的效果不够理想。通常我们会通过收集大量训练素材，然后人工标注来改进算法，但是素材质量和标注结果通常难以达到我们的期望。

此时，AIGC 的多模态能力就能够发挥其独特优势，帮助我们解决这些问题。

我们在通过反馈得到一些 Bad Case 后，可以通过 BLIP 把 Bad Case 描述出来，然后通过 Stable Diffusion 生成足够多的 AI 图片，然后通过 Grouding Dino 把需要提取的内容框出来，再通过 SAM 模型把人像分割出来打标。这个过程可以通过程序串起来，降低人工标注的投入成本。

这种方法的优点在于显著减少了标注所需的时间和人工成本，相较于传统的手动标注，工作效率提升的同时还能保持非常高的精确性。在达到相同的精度下，我们的模型能够维持在原来大小的一半。后续我们可以将这整个流程进一步规范化和标准化，形成一个自动化的机器学习框架，用于更广泛的需要图像标注的场景。

以 AI 为 Copilot 的思维方式并不仅限于产品售前和售中的环节，对于售后服务，尤其是在面向开发者的 To B 业务中，AI 也能发挥重要的作用。我们知道，在 To B 业务中，特别是在 PaaS 类型的服务中，技术支持至关重要。我们面对的客户是开发者，他们可能提一些复杂的问题，需要写这段代码的研发花很大的精力和时间，才能理解和解决这类问题，为了尽量减少这类对研发资源的占用，我们需要为技术支持团队提供更好的工具和能力，以便他们更有效协助客户排查和定位问题。

我们碰到的常见的问题可以大致分为两类：

崩溃和异常，这是一类严重的问题，它表示程序出现了不符合预期的情况。我们建立了名为“Marvel”的异常收集系统，用于收集线上产生的堆栈，异常信息等数据。

另一类是功能和效果问题，比如在提供流媒体服务时，音视频效果的指标出现偏差、画质下降、音频卡顿等。这类问题并不会导致程序崩溃，但 SDK 的使用方式、API 的调用顺序、参数的使用等都可能影响最终的效果。要解决这类问题，需要非常精确地还原现场，我们构建了一个名为“指南针”的数据质量透明平台。该平台可以分析从各个终端上报的调用链，参数等信息，将业务使用的方式，问题发生的背景信息都上报至平台。

通过这两类平台收集到的信息，再结合我们过往的经验、汇总的决策树、源码信息等，作为上下文输入到大模型中。通过 AI 的帮助，我们可以得到一个初步的诊断，这可以帮助减轻我们筛查问题、分配问题、定位问题的人力瓶颈，我们把这个工具叫做 TroubleShoot Copilot。

在 AIGC 产生价值的环节里面，有一个很典型的用法是增强的知识库， 围绕知识库建立更好的服务体系，特别是以私有数据为基础的知识库显得尤为重要，因为企业内部信息大都是在 AI 模型预训练之外的，主要包括以下几类：

第一是产品能力知识库：这部分知识库主要关注我们的产品功能、性能和优化技巧。这些信息帮助我们的技术支持团队更好地理解产品，从而提供更有效的帮助。。

第二是客户信息知识库：这包括客户的详细信息，如客户档案、服务记录等，这些信息帮助我们理解客户的历史和需求，为客户提供更个性化的服务

第三是个人角色知识库：这种知识库包含特定角色或任务的相关信息，比如自己最常被问到的一些问题，自己负责的代码的一些解释等等，这些知识库可以帮助我们的团队更有效地满足各种角色的特定需求。

第一个场景是文档搜索。开发者平台都有文档搜索，文档搜索说简单很简单，搭一个 Elastic Search 就可以搞定，但说要做好搜索，很难。通常全文检索，在用户对产品理解不足的情况下（通常新用户的状态），很难得到有效的结果，我们产品搭配的搜索服务的满意度就一直不太好。借助 AI 做优化也是我们探索的方向。

GPT 对于私有的数据有几类应用的方式，一是嵌入，把内容做向量化，在外部存储向量化和内容的对应关系，然后把问题向量化后，通过向量的相似度找到对应的内容，这个过程还有很多细节要处理，比如做嵌入的时候，对文档拆分有较强的要求，我们做向量化的内容时，得到的长度，直接影响了最终搜索的效果，如果分的太小，那信息量太少，如果分的太大，就引入了太大的背景噪音。二是微调，基于开源的模型搭建，把训练素材投给开源的大模型，这个过程对训练数据集和训练硬件资源的要求也不低。

我们尝试的方案是综合多种方式的优势：通过 AI 去识别用户输入的搜索意图，拆解出明确的搜索关键字，把客户的问题与库里常见的问法和关键词结合起来，得到用户准确想搜索的内容，再通过全文检索的方式得到上下文，再把上下文通过 AI 进行总结和提炼，返回一个更有逻辑的回答，通过这样的方式把文档的搜索能力更好的体现出来。

第二个场景是客户服务过程。我们做客户服务时，通常会通过企微群的方式提供技术答疑服务，在群里可以实时解答开发者在使用我们产品过程中遇到的各种问题。而在此过程中，留下的服务记录和信息反馈对于我们而言也是极其宝贵的资产。它们可以帮助我们生成最佳实践、编制常见问题解答，甚至进行客户情绪分析。

然而，一个挑战就在于这种基于服务群的信息管理方式。因为它们缺乏有效的会话管理机制，处理这些会话的过程就变得十分复杂。想象一下，我们每个月要回答 4000 个问题，每个问题可能需要多次交互才能得到解答。而在这过程中，还可能出现多个问题同时交叉提问的情况。问题的内容长度不一，交互有时候会非常长。这就使得对技术支持的质检，以及对客户信息的回溯变得非常困难、耗费人力。

这正是我们需要 AI 技术帮助我们的地方，AI 能够处理这些繁复的提取、抽象和总结工作。例如，我们可以训练 AI 模型来识别和跟踪群会话内容，抽取每个独立的问题线索，对客户问题处理进度、待办事项落实情况、客情关系是否维系妥当、是否升级投诉做好分类和打标、汇总工作。这样我们就能更好地管理我们的技术支持记录，提高我们的服务质量，同时也为改进产品和优化用户体验提供了有力的数据支持，这是我们的 Customer Copilot 的作用所在。

第三个场景基于个人角色智能化的应用。这是我们正在尝试的一个新的方向，通过导入个人的专属的知识库信息，可以打造一个 24 小时在线的 AI 替身，协助本人回答问题，以便保持自己更持续的专注状态，减少一些思考中断。

总结

今天的案例，展示了我们如何从小场景、小功能切入，以 Copilot 的角度解决问题，提升产品研发的效能。研发效能的改进需要全体人员共同参与，这些 Copilot 工具集都是一线研发同学在编写代码、查找问题和服务客户过程中，为了解决问题而思考的方案。这也是这次 AI 浪潮我们感受到的一个变化：大家不仅愿意思考，而且敢于付诸实践。在这之前，有一些提效、创新的想法时，落地过程中会遇到很多阻碍，包括技术限制、人力限制、跨团队协作等，从而就把想法束之高阁了。而现在，从想法到落地的门槛降低了，有越来越多的工具帮助你写代码，分析思路，极大地降低了试错的成本，创新的动力也更强。

前面也提到 AIGC 和软件研发生命周期的结合应用中，AI 的参与会让我们对整个 SDLC 的各个阶段需要投入的时间比例进行调整，在这之前，SDLC 过程中，编码的细节非常多，需要仔细斟酌，有很大的体力工作量，还有就是匆匆做完系统设计后，在编码的过程中碰到具体问题再调整设计，导致编码时间被拉长放大。在应用了 AI 辅助生成代码的工具能力后，编码开发阶段以后可能不会是最占用研发人员时间的周期，AI 工具可以协助生成代码，缩短中间机械重复的胶水代码的生产时间。相应的，研发应该花更多的时间在系统设计，软件工程方面，这是区分研发水平高低和能力差别的更核心的特征，如何让代码能满足时间上的、规模上的、业务权衡取舍的变化：到底是一次性的代码还是要求运行几年以上的代码方案是不一样的，在不同用户的规模的要求不一样，在面对各种不同路径要做的决策，比如风险、ROI、是否接受不好的现状等等，都需要我们这个主驾有更多的脑力投入到里面，这个才是程序员应该发挥价值的点。

最后借用一张图来结束这次的分享，我们强调研发效能改进的重要性，其中一个关键因素是研发人员的体验是否足够好，一个好的研发体验可以带来更高的效率和幸福感。

研发体验的构成包括创造力（生产力的一部分）、研发影响力（将想法快速转化为具体成果的顺畅度）以及环境、流程和工具的满意度。这些因素相加，再乘方协作，最终形成一个优秀的开发体验。

AIGC 所涉及的诸多内容恰好能进一步增强这个公式的各个部分。无论是工具的生产力、流程的变化、快速尝试的能力，还是协作方面的改进，都可以通过 AI 能力得到强化。这正是 AI 助力研发效能的最佳途径，也是研发人员能从 AI 中获得幸福感的最好方式。