赞
踩
在上一年里,已经有不少的企业在工具链上落地了生成式 AI,结合我们对于这些企业的分析,以及最近在国内的一些 “新技术” 趋势,诸如于鸿蒙原生应用的初步兴起。从这些案例与趋势中,我们也看到了一些新的可能方向。
结合我们在 LLM as-Copilot,LLM as-Integrator,LLM as-Facilitator 的三阶段框架,以及我们内部的分析材料,我大体将其总结为 6 个趋势:
其中的部分知识几乎是我们先前达到一致的,所以让我们反过来来讲述这个故事。
在开始新的趋势总结之前,我们不得不提及的一点是:研发数字化。在过去的一年里,我与差不多 10 家公司的研发相关负责人交流 AI 辅助研发。事实上,阻碍大部分企业应用生成式 AI ,原因除了模型限制之外,还有研发的数字化水平差。
我们要面临的第一个问题是:标准化没有落地。简单来说,规范化、平台化、指标驱动四个成熟度来考虑问题时,有些组织还处于规范落地难的问题,更谈不上指标驱动改进。幸运的是生成式 AI 结合工具可以改进规范落地难的问题,也算是一个潜在的弯道机会 —— 前提是要有足够的魄力推进。
除此,我们还要面临的第二个问题是:知识的管理 —— 组织中存在大量不可言传的知识(歪个楼,比如内容八卦)。我们会遇到的挑战有:
没有记录、没有显性化。
大量的过时的知识 —— 你不知道哪个文档是旧的。
大量的非文本知识 —— 某天拍的会议白板,字都不认识了。
简单来说,这些是我们知识债务的一部分。
场景一:遗留系统迁移。生成式 AI 的特性在自然语言翻译上表达得不错,在编程语言上也有非常突出的表现。所以,去年我们也在 AutoDev 做了相关特性的分析,并构建了一系列相关的遗留系统功能。而在商业产品上,我们也可以看到诸如 IBM watsonx Code Assistant for Z 这样的 Cobol 转 Java 专用工具。
而如何分析遗留系统迁移,依旧是一个复杂的问题。现有的工具更多的是由人来设计迁移,由 AI 来辅助。
场景二:系统间翻译。随着,越来越多的大厂开始开发鸿蒙应用,我们在实践中也发现了生成式 AI 在这方面的优势。由于移动系统的 UI 差异并不大,可以通过翻译来实现部分功能迁移。尽管,我们遇到大量的生成式 AI 缺少新的专有知识(ArkUI、ArkTS、HarmonyOS API),但是结合将思维链和 RAG 与之相结合可以达到更可接受的结果。
AI 生成代码需要结合现有的规范等信息,才能生成行之有效的代码。对于 Spring 一统江湖的后端代码开发来说,构建这种生成式 AI 友好的架构是一件很容易的事。但是,由于大中小型组织都有自己的品牌指南、风格指南、设计系统,所以生成式 AI 在前端领域颇有挑战。
从现有的模式来看,主要 AI 辅助 UI 设计可以分为三类:
辅助需求沟通的原型生成。
结合低代码平台的 UI 设计生成。
结合 IDE 插件的 UI 代码生成。
考虑到前端需求的复杂式,显然如果能从第二种场景入手会更容易,而场景三更适合于新手学习和使用框架、开发人员使用新框架。
线上问题修复。在没有生成式 AI 之前,传统的判定式 AI 已经能实现大量的自动化。常规应用程序性能监控(APM)工具,可以从线上运行时报的错误,映射到对应的出错代码。PS:再结合需求与代码的关联信息,我们可以准确推断出哪次需求变更造成的影响。在有了生成式 AI 之后,线上的问题可以直接转换为问题的修复 PR,辅助你修复问题,诸如于 NewRelic 也有类似的功能上线。
故障定位。在包含大量子系统(如单个微服务)复杂的系统中,网络与问题的排除变得异常重要。在缺乏工具时,人类也经常在某个丢失关键信息,而 AI 正好可以辅助我们去解决此类问题,诸如于 AWS 的 AI 辅助网络故障排除。
考虑到我只是 Dev 领域的专家,而非是 Ops 领域的专家,也不能解读出更多了。
现如今已经有大量的线上应用引入了 AI 能力,诸如于星巴克推出的换脸活动等等,这一类的 AI 应用引入了一系列的 AI 基础设施。因此,对于中大型组织来说 ,除了考虑合适的私有化部署模型,还需要构建快速的 AI DevOps 基础设施,以作为支撑。
除了大模型本身的各类监测之外,我们还需要模型本身的运营成本 —— 特别是当你调用第三方 API 之后,以构建更好的 AiBizDevFinGitSecOps 体系( 本文内容由网友自发贡献,转载请注明出处:【wpsshop博客】
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。