五分钟DevOps：AI正在抢走我们的饭碗!!

在过去的一年左右，我进行了一些小型实验，看看AI是否已经让我变得多余，还是这仅仅是令人屏息的营销炒作。我尝试了从“给我一个……的正则表达式”到“写一份关于……的30分钟演示文稿的大纲”等各种事情，结果五花八门，有些出乎意料。一年前，AI对于解决简单问题之外的任务结果并不令人印象深刻。编造依赖和无效语法是家常便饭。我曾询问ChatGPT关于何时使用GitFlow（见这篇文章），它的表现差得离谱。然而，最近与LLM辅助开发相关的试验使我确信是时候修改我的工作流程了。我害怕被取代吗？不。但是我相信其他人会被取代。在解释原因之前，我想先聊聊我参加的一个AI活动。

在纽约市，我被邀请参加了首届面向GenAI的DevOps黑客松，这个活动大约有60人参加，规模不大。团队由陌生人组成，围绕投票选出的问题自组织。

约翰·威尔斯和帕特里克·杜博伊斯主持了这次活动。帕特里克在2008年创造了“DevOps”这个词，并且创立了第一个DevOpsDays活动。约翰是《DevOps手册》的合著者，也是早期的DevOps思想领袖之一。所以，我们请到了真正的DevOps元老。

“GenAI 的 DevOps”是什么意思？这显然不仅仅是为了更好地编写YAML。我们想测试一些将GenAI解决方案应用于让我们的工作更轻松的想法。尽管提出了几个有趣的用例，但其中一个特别吸引我的是“在事件期间识别问题、根本原因和假设”。我花了很多个不眠之夜来做这件事，所以对此非常感兴趣。团队设计了一个关于如何摄入信息以训练模型的方案，但由于时间不够，未能创建一个PoC。尽管如此，我认为AI辅助运维很快将成为一种普及的产品。这是一个太大的痛点，需要解决。

我参与的团队专注于“专家服务”。我们希望训练一个模型，使其能够更好地理解和利用文档和培训材料。文档是一个重要的工具，除非它们过时或难以找到。在我之前的职位中，我们大量使用了文档作为我们内部开发者平台的一线支持，即直接面向用户的支持——这使我们能够保持一个精简的支持团队；八个人支持19,000人。然而，我们经常需要引导人们找到相关的文档信息。通过我们的小妙招，我们想要看看是否可以通过改变搜索模式，将寻找信息的过程转变为对话方式，看看模型是否可以建议解决问题。

我们从约翰和帕特里克提供的种子应用开始，以及我从DojoConsortium.org熟悉的文档。我的团队中的每个人都是开发者，但没有人精通Python。然而，通过向ChatGPT提问，我们完成了从GitHub抓取Markdown、按主题拆分页面并将信息添加到模型中的任务。加载完文档后，我问了一个团队经常提问的问题：“一个故事应该多大？”结果如下：

嗯，这并不是我想要的。我在文档里找了找，希望找到关于推荐的任务时长的指导。我需要回顾一下文档，看看错误是在文档中还是在我们处理数据的方式上。不过好的一面是，它确实提供了一种使任务变得更小的方法。这就跟我们自己使用产品一样重要，以便发现问题并改进。

在讨论了结果与预期之后，我们的谈话集中在了这个用例的发展流程是怎样的。 “我们如何获得反馈以改进响应？”、“当信息更新时，流程会是什么样的？”、“我们如何移除或更新过时的信息？”、“我们如何衡量响应的质量？”等等。虽然工具可能不同，但基本原则仍然适用。

• 和其他从未合作过的工程师一起群组讨论非常有趣，他们也是专业的技术人员，致力于解决问题，而不是那些自封为10倍工程师的人。我们都能互相学习，并一起咒骂计算机。
• 大型语言模型可以通过使其更容易被发现并把关键词搜索转化为对话来使文档和培训变得相关。它可以跨组织进行交叉引用并返回信息，提供更丰富的背景信息或甚至发现矛盾的信息。想象一下，当你收到一个自动警报，告诉你一项合规政策变化与其他政策相冲突。有如此多的可能性。
• 实现一个简单的黑客行为比我想象的要容易。是的，我们有一个种子，但种子中的代码量非常小，不到100行。大部分繁重的工作是由LangChain库和MongoDB作为向量数据库完成的。下一步，我大部分的学习将是如何对信息进行分类，以便模型更好地索引。
• 这并不是魔法。如果你想让你的大型语言模型适应你的上下文，那么你需要可观察性来改进它返回的信息。人们在问什么问题？答案的准确性如何？在信息更新时，如何保持模型的时效性并防止它提供过时的信息？
• 在把所有东西扔进模型之前，先考虑一下信息的生命周期。我们得出的结论是，相对静态的信息，如政策、培训、程序等，非常适合模型，但应避免快速变化或短暂的信息。
• 垃圾进，垃圾出。模型永远不如提供信息的人聪明，它只能偶然地揭示一些惊人的联系。再次强调，没有什么是魔法。

之后，我参加了一个行业晚宴，讨论人工智能。我发现人们担心人工智能会对社会和行业产生怎样的影响。

有一个人非常坚持认为需要从大型语言模型（LLM）中移除偏见。这是一个有效的担忧，但也是徒劳的。你知道多少工具会假设左撇子不存在？你的应用程序是否考虑到色盲的存在？代码中有偏见，训练材料中有偏见，解释输出的人也有偏见。我们创造的工具永远不比我们更好。它们只是比我们通常更快地完成某些任务的我们自身的反映。不过真正让我害怕的是，我看到人们给予大型语言模型生成的信息那么多的信任，比一个普通人告诉他们的还要多。这对我来说真的很可怕。与其要求不可能的事，我们应该教育人们使用批判性思维去辨别，并意识到偏见会存在于我们所做的每一件事中。

另一个担忧是，生成式AI只不过是另一个区块链泡沫。我对此强烈不同意。当时大家都在试图将区块链强行应用到各个领域，因为它很火。确实有一些用例中区块链会很有价值，但这些用例也需要在整个信息供应链上广泛采用。LLM有很多应用场景，既可以针对单个应用，也可以更广泛。我可以想到几个能立即改善日常工作的用例，并且我会在我的工作中帮助实施这些用例。LLM将会成为不可或缺的平台工具，而不仅仅是在编码方面的辅助工具。

在参加活动之前，我做了一个小实验。我将验收准则输入了ChatGPT 4，并要求它基于这些可测试的功能给我生成一个React应用程序。它做到了，且应用程序可以运行。它使用了一个我从未用过的拖放库，这将需要花费数小时来学习。它生成了我不会讨厌的可维护的代码。从“我很好奇这是否行得通？”到拥有一个可用的POC（概念验证），整个过程不到3小时。这是否意味着开发人员可以被写用户故事并运行生成代码的人取代？许多人的梦想终于成真了！不啊。

Gen AI 对开发者的平台来说是个大好消息。它替我完成了那些枯燥的商品化编码任务，并消除了我必须停下来学习新库的需要。然而，开发不仅仅是编写代码。我必须理解我正在解决的问题，并以一种可测试的方式描述这个问题。这就像在一个更高层次的语言里工作，让我能花更多时间在思考“是什么”而不是“如何做”上。但仅靠说“它以这种方式表现”是不够的，构建大型系统需要更多。直到我们有了能理解工程权衡并能将模糊想法转化为可测试结果的自我意识机器，我们仍然需要软件工程师。当然，到那时，人类可能已经不需要工作了。

我对这一点有一个保留意见。认为大语言模型会让开发人员变得多余的说法大多不准确，但并非完全错误。认为只要解决 LeetCode 问题就能成为优秀开发人员的人已经可以被替代了。他们解决的是已经被解决的问题，他们缺乏创新。掌握领域知识、解决难题并能描述可测试解决方案的开发人员需求将增加。别再做 LeetCode 练习了，用大语言模型处理繁琐任务，并向成为解决软件问题的领域专家努力。

LLM只是工具而已。更好的工具可以放大使用者的技能。如果技能水平较差，这个工具会把这一点暴露无遗。关于我们在GenAI DevOps黑客赛期间遇到的操作问题，我目前还没有答案。我还在学习。我有一些想法，但它们需要被测试。我们需要让好的模式浮现并广泛讨论，因为这些工具将改变我们的工作方式。如果你有任何回答或只是想法，都可以联系我。让我们一起学习吧。

特别感谢约翰和帕特里克主办了这次活动，谢谢他们。

• LeapFrogAI — 开源、自托管的AI平台，设计用于在离线环境中部署
• 学习LLM和GenAI以提升开发、安全和运维能力 — Patrick DuBois的学习指南
• 编程中的LLM提示示例 — Martin Fowler的博文