Kubiya 推出用于平台工程的第一代人工智能

Kubiya 推出用于平台工程的第一代人工智能

翻译自 Kubiya Launches First Generative AI for Platform Engineering 。

在 KubeCon EU 2023 上，用于 DevOps 的 Kubiya 对话式 AI 发布了第一个用于平台工程的生成式 AI 工作流引擎。

阿姆斯特丹 - 随着平台工程成为一种更广泛采用的学科，平台团队的待办事项只会增加。随着开发人员采用新的最佳实践和工具，该团队需要提高技能水平，并了解分布式、通常是七层堆栈中越来越多的内容。而旨在减少开发人员疲劳度的团队反过来又有自己不断增长的认知负荷要承担。

去年十月，Kubiya 推出了一款面向 DevOps 团队的对话式人工智能，旨在改善内部和外部开发人员的自助式、终端用户体验。现在，在 KubeCon+CloudNativeCon Europe 上， Kubiya 发布了一个新的生成 AI 工作流引擎，专为平台工程团队设计。

The New Stack 采访了首席执行官 Amit Eyal Govrin ，谈到生成式人工智能在整个软件开发生命周期中的不断增长的用例 - 以及行业如何更愿意接受它，因为 Kubiya 的定位从“ DevOps 团队的 Siri ”转变为“平台团队的 ChatGPT ”。

用于最终用户体验的生成式 AI

离开隐身模式大约六个月后，Kubiya 发现了两个常见的客户用例——内部开发人员和外部开发人员。第一个是在处理内部复杂性的企业内部，后者是为大约 1000 多家小型软件公司提供的，在客户需要访问基础设施时加快他们的响应时间。

Govrin 谈到了一家领先的数字媒体解决方案和服务公司的客户，而这家公司又拥有迪士尼和 NBCUniversal 等客户。他们的客户可能会请求他们提供服务器上安全管控的 Amazon S3 存储桶中存在的特定视频。发生这种情况时，传统上，客户必须确认请求的合法性并通过审批流程对其进行授权。然后，另一名员工必须前往 S3 存储桶，并在安全的 Slack 通道上将 secret 管理扩展到客户。然后，客户将在他们的端授权该请求，然后才能下载它。

想象一下，在跨职能团队之间有四五个不同的子流程，这些流程涉及到完整交易，并且经常需要提供方的项目经理手动配置所有这些不同的步骤，然后让 TAM （技术客户经理）从安全方式复制 S3 存储桶并将其发送给最终客户。由于来回沟通和人为干预，所有这些都可能需要几天时间。”戈夫林说道，回忆起 FTP 服务器时代。此过程通常需要一个项目经理、时间以及从本地服务器下载东西的人。

通过 Kubiya 的工作流自动化、安全访问控制和知识管理，团队可以更轻松地验证请求，并且甚至能够向最终客户提供 10 分钟的服务水平协议（SLA），消除了环节中的摩擦和人为因素。

这可以在客户关系已经存在的地方完成，比如 Slack 、 Notion 、 Confluent 或 Gitbook 。人类顾客只需问一个问题，比如“我能看到X演员最近的视频吗？”然后这种人机交互就会回应。

重要的是，像在 Slack 中一样，对话式人工智能用户体验包括人类反馈，如赞或踩或是或否等，澄清用户想要什么，并将其反馈回 Kubiya 的强化学习与人类反馈（RLHF）进行训练，提高其精度，并不断为最终用户定制响应。

这实际上是 ChatGPT 在许多企业应用案例中表现不佳的一个重要原因，”Govrin 观察到。他说，到目前为止，ChatGPT 无法验证其关于幻觉的响应——这些输出听起来很合理，但要么不准确，要么与问题无关——也不能正确保护数据的完整性以响应许多商业案例。谈到 Kubiya 时，他继续说：“我们不仅在特定领域的数据上对模型进行微调，而且还允许用户提供反馈——赞或踩——[这]将进一步加强模型，并个性化地适应组织和最终用户。

为什么 Kubernetes 需要对话式 AI 的帮助

不出所料，Kubiya 最常见的用例——或用户问题——是无所不在但并不总是易于理解的 Kubernetes 编排。

Kubernetes 的故障排除和操作混乱，往往充满人为错误，这是由于上下文切换和缺乏领域专业知识所致。通常通过 kubectl 、 Helm 、 Argo CD 等工具和命令处理的请求存在于数据孤岛和过时的维基中。” Govrin 告诉 The New Stack 。“能够将 Kubernetes 操作民主化为自然语言提示可以使许多经验不足的操作员平等竞争，并显著提高有经验的操作员的速度。

如果开发人员想要设置 Kubernetes 命名空间，他们可以在 Kubiya Slackbot 中输入“Kubernetes”，然后返回完整的 Kubernetes 部署流程图，从中选择命名空间。他们还可以更具体地询问：“给我创建 Kubernetes 命名空间的工作流程”，Slackbot 将返回一个触发该工作流程的简单方法，并提供有关其更多信息的链接。

值得注意的是，由于每个组织使用 Kubernetes 的方式不同（这也是它的挑战之一），Kubiya 的精细调整模型会学习并适应组织特定领域的知识，以优化其类似问答式、人机对话式的对话人工智能。

你可以通过简单的英文提示在聊天平台上应用 Helm Chart 并调试、回滚和获得对 Kubernetes 集群资源的可见性这一事实——就像您向 DevOps 或平台工程师询问一样——完全改变了用户体验。不需要使用如此多的工具和解决方案来执行这些简单操作，” Govrin 进一步解释道。

自然语言处理扩展到平台团队

如何在不必试图建立新平台的情况下，去帮助创建这些自动化和工作流程？”接着， Govrin 告诉 The New Stack 关于扩展 Kubiya 的用例和范围，超越个人用户体验并涵盖整个平台工程团队。“通常来说，平台工程是很费力的，需要设置和维护这些系统，并且创建新的工作流程对操作员来说非常繁重。这通常是他们购买决策中要考虑的一个因素：我是否想要投入所有时间和精力为自己创建所有这些定制操作？

平台工程团队不仅需要理解应用程序开发团队的需求，还要将它们连接起来以更快地提供业务价值 - 这本身就是一项艰巨的任务。但平台工程师还必须能够理解和创建业务逻辑和工作流，并将其传达给应用程序团队。这就是为什么在 KubeCon 上，Kubiya 推出了一个新功能，为其新 Web 应用程序提供生成式 AI 工作流创建的原因。

Govrin 提供了一个例子，即在 Kubiya 中输入“我想为 AWS SSM 创建一个新参数”，其中 SSM 代表 Amazon Web Services Systems Manager Agent 。生成的工作流程看起来像是人与机器之间的对话，可以包括必要的人类干预触发器。这与其他平台（如Jenkins）进行机器之间交互形成鲜明对比。

我们所说的是，有人进来要求某些需要以不同方式看待工作流程的东西。因此，我们看待工作流程的所有方式都是从人到机器。你如何创建这种体验，让它看起来和行为非常像另一端的某个人正在给你提供服务。” Govrin 解释了 Kubiya 生成式 AI 对话式工作流程的目标。

这用作工作流程模拟器，可以帮助平台团队在现有系统和流程中调试和评估新的工作流候选项的可用性。他们无需投入大量时间和精力，就能够在对话式人工智能、拖放设置中进行测试、运行和调试。平台工程师还可以导入 YAML 或 JSON，并将其全部以低代码形式直观地布置在现有业务逻辑中。

即使使用典型的低代码平台工程工具， Govrin 警告说测试新的 DevOps 工作流可能需要几个小时。 Kubiya 的新 Web 应用程序是基于属性的访问控制（ABAC）感知和业务逻辑感知。他解释说，这以及它的组织知识使其能够更快地回答特定于领域和业务的问题。

它允许团队以不同的方式提出和回答问题 - 其中一些只有您的团队可能知道，提供内部俚语名称和更传统的名称。

它会自动捕获并在知识库上进行培训，”他说。“这本质上是组织特定领域的知识，延伸到生成式工作流程创建。这两个工具给你几乎人类般的体验。”即使对于尚未创建的工作流程，用户也可以简单地进入 Slack 并要求新内容。

其他活跃的 Kubiya 使用案例包括将自然语言处理应用于 Backstage 开源开发平台，以增强和加速具有交互式用户体验的开发。

“我们正在抽象化所有的工作，” Govrin 说。