Insights from Cleric: Building an Autonomous AI SRE // Willem Pienaar // #290
55:57 Share

Will 和 Pinar,Cleric 的 CTO。我们正在构建一个 AI SRE。我们的总部位于旧金山。黑咖啡是首选。如果你想加入一个由 AI 和基础设施领域的资深人士组成的团队,并解决一个真正棘手的问题,那就来和我们聊聊吧。

好极了。欢迎回到 MLOps 社区播客。我是主持人 Demetrius。今天我们与我的好朋友 Willem 进行了交谈。你们中的一些人可能认识他,他是 Cleric AI 的 CTO,正在使用一些非常新颖的技术......

AISRE,我们将在接下来的一个小时里深入探讨。我们讨论了他如何使用知识图谱来对他们的 AI 代理解决方案的根本原因问题进行分类。你们中的一些人可能认识 Willem,因为他也是构建开源特征存储 Feast 的同一个人。

四五年前我认识了他。从那时起,我就一直在密切关注他的工作。可以肯定地说,这个人从未让人失望。让我们现在就开始谈话吧。

让我们首先说明一下,我们在圣诞节前两天录制节目。所以当它发布时,我穿的这件毛衣就不太合适了。但今天我完全可以穿它。不幸的是,我没有像你一样酷的毛衣。我在阳光明媚的旧金山。但我猜是......雾很大。是的,圣诞节的气氛。老兄,我三天前发现......

四天前,如果你服用这种含有咖啡因的神奇药丸,它可以减少紧张感,所以我把它作为一种经验教训,或者说是......是的,你听说过它,是的,是的,老兄,我一直都在滥用我的咖啡因摄入量,并用这些药丸来服用,这太神奇了,我的效率提高了这么多,所以这是我 2025 年的秘密,送给所有人

携带一些镁来帮助睡眠或实际睡眠。好了,伙计。别再说了。你一直在构建 Cleric。你偶尔会参加我们举办的不同......

会议,并分享你的学习成果。但你最近发表了一篇博文,我想在这篇关于什么是 AI SRE 的博文中深入探讨一下,因为它感觉 SRE 与 MLOps 世界非常接近。而 AI 代理正是我们在“生产中的代理”会议上多次谈论的内容。

我们首先应该从这是一个多么困难的问题开始。为什么它很难?我们可以深入探讨这些领域,我认为我们将在这次谈话中深入探讨。也许只是为了设定舞台,每个人都在构建代理,就像代理现在很热门一样。但每个用例都不同,对吧?你可以在法律领域使用代理,你可以使用代理来撰写博文,你可以使用代理来管理社交媒体。我们这个领域棘手的事情之一是真正

如果你考虑工程师做的两件主要事情,那就是他们创建软件,然后将其部署到生产环境中,它运行并操作。它实际上必须对现实世界产生影响。第二个世界,即运营环境,与开发环境大相径庭。开发环境有测试,有 IDE,有时间反馈周期。它通常有基本事实,对吧?所以你可以进行更改并查看你的测试是否错误。有一些无许可的数据集存在。所以你可以去 GitHub,你可以找到像

人们正在创建的问题,像这些问题的解决方案一样的 PR。是的。但是考虑......

像企业公司的生产环境,你在哪里可以找到代表他们遇到的所有问题和所有解决方案的数据集?它不是摆在那里,对吧?你可以得到一些像根本原因和人们作为博文发布的东西,但这在大多数情况下是一个无监督的问题。这是一个非常复杂的问题。我想我们稍后可以详细讨论这些细节,但这确实是让我们面临挑战的原因。它是复杂的、庞大的、动态的系统。

是的,系统的复杂性并没有帮助。我还认为,随着编码副驾驶的兴起,这是否也使事情变得更加复杂?因为你在生产环境中运行的东西,你可能知道它是如何创建的,也可能不知道。非常多。我认为即使在我们这个规模很小的初创公司,它也已经成为内部的一个话题。

我们委托给 AI 的程度是多少?因为我们也在将工作外包并委托给我们在内部生成代码的代理。所以我认为所有团队都在努力达到理解和信心的界限。因此,你正在构建这些模块化组件,就像乐高积木一样,你不知道内部结构,但你将它们交付到生产环境中,并观察其成功和失败,因为它为你提供了如此高的速度。因此,投资回报率很高,但理解是你随着时间推移会失去的东西之一。我认为在规模上,是否

激励措施不一致的地方,你有很多不同的团队,他们都面临着交付更多产品的压力。皮带正在收紧,所以没有很多员工,他们必须做更多的事情。生产环境确实......人们就像把手伸进那堵该死的墙里,但最终它会破裂。在许多公司,它是不稳定的。是的,所以......

编码将使,或者说 AI 生成的编码将使这个系统更难处理。因此,这些相互关联的组件之间的动态,其中理解较少,将会爆炸式增长。是的,我们已经看到了这一点。

老兄,复杂系统上有许多不同的部分我想深入探讨。但首先引起我注意并一直在我脑海中回放的是你在会议上以及随后在你的博文中提出的这个知识图谱。你指出,这是我们在生产环境中创建的知识图谱,但它不像是一个巨大的 Kubernetes 集群。

这是一个相当小的 Kubernetes 集群,以及来自该集群的所有不同关系,以及所有 Slack 消息、所有 GitHub 问题以及该 Kubernetes 集群中涉及的所有内容,你都已绘制出来。而这仅仅是一个 Kubernetes 集群。所以我无法想象在整个组织中,例如企业规模,这会变得多么复杂。是的。

因此,如果你考虑我向你展示的特定集群或图,它是 Okta 遥测参考架构。它就像一个演示堆栈。它就像一个电子商务商店。它大约有 12 个或 13 个服务。是的,大约在这个范围内。我只向你展示了字面意义上大约 10% 的关系,甚至可能更少。而且它只在基础设施层,对吧?所以它甚至没有谈论像存储桶和云基础设施,没有谈论节点,没有谈论应用程序内部结构,对吧?所以如果你考虑一个云项目,例如一个 GCP 项目或 AWS 项目,

有一整棵树。有网络、区域,一直到 Kubernetes 集群。在一个集群中,有节点。有容器。在容器中,还有 pod。可能有多个容器。在这些许多进程中的每一个进程中,每个进程都有代码

带有变量,并且每个变量都会创建这个树状结构,但是这些树中的节点之间也可以有相互关系,例如这里的代码片段可以引用那里的 IP 地址,但是该 IP 地址是由某个地方的某些云服务提供的,并且它还连接到其他一些系统,你不能不使用这些信息,对吧?因为如果出现问题,而你正在......你知道,在你的膝上型电脑的镜头下,那么你必须因果地遍历该图以向上游移动以找到根本原因

在安全领域,这是一个经过充分研究的问题。人们一直在使用传统技术从云环境中提取这些信息。但大型语言模型确实开启了新的理解水平。因此,它们非常擅长提取这些关系,处理真正非结构化的数据。所以它可以是我们和你之间的对话。它可以是 Kubernetes 对象。它可以是所有这些,从非结构化到结构化的整个范围。你可以提取结构化信息。所以你可以构建这些图。

挑战实际上是双重的。所以你知道你需要使用这个图来找到根本原因,但它是模糊的,对吧?一旦你提取了这些信息,构建了这个图,它几乎会立即过时,因为系统变化如此之快,对吧?所以有人正在部署某些东西,IP 地址被滚动,pod 名称发生更改。因此,你需要能够使用你的代理做出有效的决策,对吧?所以为了确定这一点,

我们的代理现在本质上是一个诊断代理。因此,它可以帮助团队快速找到问题的根本原因。因此,如果你有一个警报触发,或者工程师向代理提出问题,它会快速利用这个图及其对生产环境的了解来找到根本原因。如果没有这个图,它仍然可以通过第一性原理来做到这一点,对吧?它仍然可以说......

查看所有可用内容,我会尝试这个,我会尝试那个。但是该图允许它非常有效地找到根本原因。因此,模糊性是挑战之一,它如此迅速地过时的事实,但无论如何,拥有它仍然非常重要。你提到了一些关于......

如何通过对图的视觉或理解,你可以升级那些被孤立地看待并不那么重要的问题。那么,你能解释一下这是如何运作的吗?

因此,该图本质上是,如果你在生产环境周围画一个框,对吧,有两类问题,对吧?有你设置警报并了解的内容。所以你告诉我们,好吧,我的警报触发了,这是一个问题,去看看它。另一个是我们扫描环境并识别问题。该图以两种方式构建。一种是后台作业。

它就像浏览你的基础设施并查找新事物并不断更新自身一样。另一种是当代理正在进行调查并且看到新信息时,它会将该信息抛回图中,因为它拥有 Miles 刚刚用来更新图的信息。但在这种后台扫描过程中,它可能会发现它没有意识到是问题的事情,但随后它会看到它,因为这实际上是一个问题。例如,它可以......

处理你的指标,或者它可以查看你在 Kubernetes 中的对象配置,或者它可能会找到一个存储桶,并且它正在尝试创建该节点,存储桶的更新状态,并且它会看到它公开暴露。然后它可以向工程师提出这个问题,

你的数据正在公开暴露,或者你错误配置了这个 pod,并且内存正在增长这个应用程序,在一两个小时内,它将崩溃,是的,所以大型语言模型有巨大的机会被用作推理引擎,它可以推断和预测即将发生的故障,你可以防止这种情况发生,因此你可以进入主动警报状态

当然,如果你使用大型语言模型将视觉模型直接应用于指标图或云基础设施中的对象,那么这在今天是相当低效的。但是,这里有一个巨大的低垂果实,你可以将许多这些推理能力提炼成针对这些任务中的每一个任务的更精细或更有针对性的模型。但是扫描是如何工作的呢?因为我知道你还提到

当代理试图进行根本原因分析时,代理会一直运行到它们用完积分或达到其支出限额为止,某种问题。但我可以想象你不仅仅是持续扫描,或者你每隔 X 秒、分钟或天就启动一次扫描吗?

是的,这有不同的部分。如果我们进行后台扫描图构建,我们会尝试使用更高效的模型。因此,由于数据量很大,你不会使用用于......

你知道,非常准确的推理。是的。因此成本较低。因此,你可以在此设置每日预算,然后达到预算。这不是持续运行并处理大量信息的事情。把它想象成一个人,对吧?你不会处理云基础设施中的所有日志和所有信息。你只是了解一下情况。最近的部署是什么?人们在 Slack 中进行的最近对话是什么?只是得到一个逐场解说。

这样,当出现问题时,你可以快速采取行动。你有快速思考的能力。你可以快速做出正确的决定。但在调查中,我们设置了一个上限。我们说,每次调查,比如说,设定 10 美分或 1 美元,或者任何金额。然后我们告诉代理,这是你被分配的金额。尽可能好地使用它。通过你的工具查找你可以使用的信息。然后允许人类说,好吧,

再深入一点或停止在这里,我会接管。哇。因此,一旦代理有有价值的信息要向他们展示,我们就会将人类纳入循环。因此,如果代理开始执行任务并且几乎没有发现任何东西,它可以向人类展示这一点并说没有。或者说,好吧,找不到任何东西。或者保持沉默。这取决于你如何配置它。但它总是会在该预算限制下停止。是的,......

它找不到任何东西的好处还在于,它将缩小人类必须去搜索的范围。因此,现在人类不必再去查看 AI 代理刚刚查看的所有这些垃圾,因为理想情况下

如果代理没有发现任何东西,那么它可能不在那里。因此,人类可以首先去其他地方寻找。如果他们用尽了所有选择,他们可以返回并尝试查看代理正在查看的地方,看看问题是否在那里。我认为这回到了这里根本问题。也许我们忽略了一些解决运营和值班运营问题的工具。

任何数量的 DataDog、仪表板或 kube-cub 和命令都不能将你的高级工程师从进入生产环境中解放出来。所以我们试图实现端到端解决方案。当我们发现问题时,代理能否一路走下去,多步骤,这在今天需要工程师的推理和判断,查看不同的工具,理解部落知识,理解系统部署的原因。

我们希望让代理到达那里,但你不能从那里开始,因为这是一个无监督的问题。你不能只是开始更改生产环境中的内容。没有人会那样做。现在,如果你从解决方案中缩小规模,这意味着更改,例如代码级更改、Terraform,它认为它在你的存储库中。如果你从那里回溯,它就是理解问题是什么。如果你进一步回溯,那就是搜索空间缩减,将问题三角定位到特定区域。也许不是说代码行,而是说这是服务或这是集群。

这对今天的工程师来说已经非常有吸引力了。或者你可以说,它不是这 400 个其他云集群或提供商或服务。它可能就在这一个中。这对今天的工程师来说非常有用。因此,搜索空间缩减是我们非常可靠的方面之一,也是我们开始的地方。而且......

我们以一种协作模式开始。因此,我们快速缩小搜索范围。我们告诉你我们检查了什么以及我们没有检查什么。然后作为一名工程师,我们可以说,好吧,这里有一些额外的上下文。再深入一点,尝试一下这个信息。在这种指导和协作中,我们向工程师学习,他们教导我们,随着时间的推移,我们在解决问题的道路上越来越好。是的,我知道你提到了内存,我想稍后讨论一下,但继续谈论金钱和成本,

以及代理或多或少有一个预算,他们可以花费并尝试找到他们正在寻找的东西。你是否认为代理会陷入递归循环,然后使用他们的全部预算而没有真正获得任何东西?或者这在六到十个月前相当普遍,但现在你已经找到了方法来

平衡这个问题。这个问题空间是一个,对你的产品进行小的添加或改进会随着时间的推移而产生很大的影响,因为它们是复合的。我们从解码代理(如 SWE 代理和其他代理)中学到了很多东西。因此,他们发现的一件事是,当代理成功时,它会非常快速地成功,而当它失败时,它会非常缓慢地失败。因此,你甚至可以将代理运行三、四、五、六、七分钟作为代理。

即使你根本没有对它进行评分,它也可能出错,如果它运行到......它很快得出结论,例如在 30 秒内,它很可能正确。我们的代理有时会追逐自己的尾巴,所以我们有一个置信度分数,并且我们在最后有一个评论者来评估代理,所以我们尽量不要向人类发送垃圾邮件

最终,这是关于注意力和节省他们的时间。因此,如果你不断抛出错误的发现和错误的信息,他们会将你从他们的生产环境中移除,因为它会很嘈杂,对吧?这是他们最不想看到的事情。因此,是的,根据用例的不同,代理可能会进入递归循环,或者它可能会进入它应该进入的方向。对我们来说,管理这种情况的一个非常有效的机制是了解我们在哪些方面擅长,在哪些方面不擅长。

因此,对于每个传入的问题或事件,我们都会进行丰富,然后构建该问题的完整上下文。然后我们查看,我们过去是否见过这种情况?类似的问题,我们过去是如何解决这个问题的,我们是否得到了积极的反馈?因此,如果我们检查正确的历史上下文,我们就可以很好地了解我们对某事的信心,然后再将这些信息呈现给人类,例如最终的发现结果。但是,是的,有时它确实会出错。我想想,知识图谱是你......

创建一次以了解情况,然后几乎没有什么东西会被更新,直到发生事件,你才会去探索更多,你使用的是哪种知识图谱?你使用的是许多不同的知识图谱吗?它只是一个大的知识图谱吗?在实践中它是什么样的?

我们最初使用的是一个大型知识图谱。这些知识图谱的问题在于它们通常......构建它们最快的方法是确定性方法,因此你可以运行 kubectl,并且你可以使用传统技术遍历集群。不涉及 AI 或大型语言模型。但是然后你想在其之上叠加模糊关系,在那里你看到这个容器对那里的某些东西有这个引用,或者这个配置映射提到了......

我在其他地方见过。因此,我们转向了一种更分层的方法。因此,我们有像多个图层一样的东西,其中一些图层具有更高的置信度和持久性,并且可以快速更新,或者可能使用不同的技术。然后你将更模糊的层叠加在其上或不同的层上。因此,你可以使用 owl 来画出集群之间或从 Kubernetes 集群到应用程序层或到下层之间的景象。

但是从数据管理的角度来看,使用较小的微图对我们来说更容易。你还在为知识图谱绘制哪些其他数据点,这些数据点在 AI SRE 试图对不同问题进行分类时以后会有所帮助?在大多数团队中,存在 80-20 的差距。

就像墨西哥卷饼的价值分配一样。因此,一些关键事实通常在同一个系统中找到。我认为是 Meta 或者,是的,他们进行了一些内部调查,发现他们 50% 或 60% 的生产问题仅仅是由于配置或代码更改造成的。任何扰乱其生产环境的事情。

因此,如果你只是查看人们正在部署的内容,就像你正在跟踪人类一样,你可能会发现很多问题。因此,监控 Slack、监控部署是最有效的事情之一。查看人们正在安排的发布或更改,并了解这些事件。因此,对这一点进行评估。然后在解决路径中,还有构建解决方案的方法。查看运行手册,查看人们过去是如何解决问题的,例如

通常发生的情况是,创建了一个 Slack 线程,对吧?因此,Slack 线程就像一个上下文容器,说明你如何从一个问题(有人为此创建了一个线程)到一个解决方案。总结这些 Slack 线程非常有用。所以你可以基本上说,

这位工程师遇到了这个问题,这是讨论,这是最终结论。并且通常会附加一个 PR。因此,你可以将其浓缩成几乎像指导或运行手册一样的东西。将它附加到新颖的场景中很有用,因为它向你展示了这个团队是如何工作的。它们通常包含可能的知识,对吧?这就是我们公司解决问题的方式。我们这样连接到我们的 VPN。我们

访问系统。这些是关键系统,对吧?生产环境中最重要的系统将被工程师不断引用,通常通过简写符号。如果你与大多数公司的工程师交谈,那将是两个更大的问题,对吧?一个是你不了解我们的系统、流程和上下文。

第二个是你不知道如何集成或访问这些系统,因为它们是定制的、独特的和内部开发的。因此,这些是我们作为代理面临的两个挑战。基本上,我们就像团队中的新工程师,你需要这个工程团队来教你。如果你没有被教导,那么你将永远不会成功。我希望这能回答你的问题。是的。你如何克服这个挑战?

你只是创建某种包含组织内相当常见的简写内容的词汇表吗?

是的,这有多个层次。我认为这是一个不断发展的领域。值得庆幸的是,所有方面在这个方面都相当适应性和宽容性。因此,我们可以尝试不同的方法来总结不同粒度的信息。因此,我们研究过,好吧,你可以只获取大量信息并将其直接放入上下文窗口,以相对原始的形式提供。这有效,但成本很高。然后你以更精简的形式显示它,并说,

这只是冰山一角。对于这些主题中的任何一个,你可以使用此工具进行查询并获取更多信息。并不总是很容易知道哪一个是最好的,因为它取决于手头的问题,对吧?因为有时关键因素,大海捞针,被埋得更深一层,代理看不到它,因为它必须调用一个工具才能到达它。因此,我们通常倾向于花费更多钱,并且......

只是让代理看到它,然后随着时间的推移优化成本和延迟。对我们来说,这实际上是关于

从一开始就很有价值。工程师应该发现我们很有价值,并且在这个价值中,合作开始了。然后它会创造一个良性循环,他们向我们提供更多信息,他们给我们更多信息,他们会获得更多价值,因为我们从他们的工作中承担了更多繁琐的工作。这就像在你的团队中培训新人一样。如果你看到,哦,这个人正在承担越来越多的任务,是的,我会给他们更多信息,我会给他们更大的范围。是的,我想深入了解一下

你刚才谈到的想法,例如你如何与代理互动,但我感觉问你关于内存以及你如何处理内存的引力太强了,所以我们必须首先走这条路,特别是

你只是缓存这些答案吗?你是否缓存了成功的运行?你如何知道某件事是成功的,然后你将它存储在哪里?你如何让代理访问它?他们知道,哦,我们以前见过这个。是的,酷。好极了。感觉这在......

理论上,你会说,是的,当然,我们只会存储这些成功的运行。但是当你分解它并说,好吧,成功意味着什么?

我们将把它存储在哪里?谁将能够访问它?我们将如何将其标记为成功?我当时在想,你甚至是如何标记这种东西的?因为是你坐在那里点击并进行人工标注吗?或者是你把它扔给另一个大型语言模型来说,是的,成功。它是什么样的?为我分解整个过程,因为当你真正看到它时,内存感觉相当复杂。

是的。这很大一部分也是 UX 挑战,因为人们不想只是坐在那里贴标签。我认为人们只是,尤其是工程师,真的厌倦了劣质代码,他们只是被扔了这种劣质代码,然后他们必须进行审查。他们想创造,我认为这就是我们试图做的事情,将他们从支持中解放出来。但这样做,你不想让他们不断地审查你的工作而没有好处。

所以这是关键。必须有互动,其中有隐式反馈,他们从中获得价值。所以我回到你关于内存的观点。因此,有效地,有三种类型的内存。有知识图谱,它捕获系统状态以及事物之间的关系。然后是情景记忆和程序记忆。程序记忆就像骑自行车一样。你的刹车在这里,你的踏板在这里。它就像指南。它几乎就像运行手册。

但是运行手册并没有描述我们在该日期遇到的这个特定问题。

我们做了什么?这个实例是情景或情景记忆。两者都需要捕获,对吧?所以当我们开始时,我们正在索引你的环境,获取所有这些关系和事物。然后我们还查看,好吧,我们能否从这个世界中提取我们可以从中获得程序的东西?然后最后,当我们体验事物或当我们理解这个环境中其他人的经验时,我们也可以将它们存储起来。

我们确实花费了大量时间,而且大多数公司都很重视数据安全。因此,我们在您的生产环境中部署,并且只有只读访问权限。因此,我们的代理无法进行更改。我们只能提出建议。所以您的所有数据都会保留。您想更改它,对吧?稍后我们将讨论如何最终达到不同的状态,但继续。是的,是的。我们想让您接近解决方案,但这是一条更长的路。

因此,我们主要将所有这些记忆存储为,我认为有价值的是剧集,对吧?这些是实例,例如如果发生这种情况或这种情况,我以这种方式解决了它。我们进行了黑色星期五促销,集群崩溃了,我们将其扩展,然后后来我们看到它正在工作,但是,它完成了。我们做了两三次,我们认为这是一个很好的模式,比如扩展是有效的。

但这都捕获在客户的环境中。我们主要的反馈方式是监控变更后的系统健康状况。哦,很好。我们可以查看系统并查看此更改是否有效,并且我们可以查看环境的代码,无论是应用程序代码还是基础设施代码。基本上,就像一个掩蔽问题一样,我们是否看到......

我们能否预测人为为了解决这个问题而做出的改变?如果他们这样做,那么就做出改变。特别是如果这是一个建议,那么我们看到他们实际上已经批准了我们所做的,对吧?他们实际上已经批准了我们的建议。这不是一个非常丰富的数据来源,因为他们可能做出的改变略有不同,或者我们可能无法访问这些系统。更有效的方法是......

因此,如果我们提出调查结果并说,这里有五个调查结果,这是我们的诊断,而你说,这很愚蠢,尝试其他方法,那么我们就知道这是错误的。所以我们得到了很多负面例子,对吧?所以这是不好的。所以它有点偏颇,但是当你最终说,好吧,我将证明这一点,我将把它发布给工程团队,或者我将更新我的值班笔记,或者我将,我希望你根据这些信息生成一个拉取请求。

然后突然我们得到了关于这方面的积极反馈。在用户体验中,这确实是隐含的信息来源,工程师的互动。这与这些记忆相关联。但最终,它仍然是一个非常稀疏的数据集。因此,这些记忆可能没有真正的标签。因此,对我们来说,大量的投资是我们独立于客户的评估基准。

我们在那里训练我们的代理,并且我们做了很多真正手工的标记,即使是较小的数据集也能使代理达到更高的精度。所以你想要两者兼顾,对吧?你想要真实的生产用例以及工程反馈,这确实提供了良好的信息。但评估基准最终是目前提供该覆盖范围的坚实基础。

但感觉评估必须针对客户,不是吗?而且感觉每个代理的每次部署都必须针对每个代理进行一些定制。或者我在这方面错了?模式非常......所以代理非常通用。代理获取每个客户的上下文信息,因此它被注入......

本地化的客户特定程序、记忆和所有这些东西。但这些都建立在在我们产品内部开发的基础之上,对吧?就像在母舰中,或者实际上它被称为Cleric神殿。很好。因此,我们分发 Cleric 的新版本以及我们的提示、逻辑、推理、通用记忆或解决问题的方法,

以神圣的方式注入到教士和中心。这是一个分层挑战,对吧?因为你确实希望对所有客户都有跨领域的好处,并且准确性由评估基准驱动,但也需要对其流程和客户特定方法进行定制。好吧,在 UI 和 UX 方面,关于我们如何做事,还有几件事让我着迷。具体来说,

你非常热衷于除非绝对需要,否则不会向工程师发出更多警报。我认为这是我自 2018 年以来一直在听到的事情,对吧?

这一切都与警报疲劳有关,以及当您拥有复杂的系统并设置所有这些监控和可观察性时,您不可避免地会不断收到提示,因为某些东西出了问题。因此,您确保做到这一点的方法,我认为这很有趣,是 A,有一个置信度分数。所以能够说,看,

我们认为是这样的,我们有 75% 的信心认为将会发生这种情况,或者这可能很糟糕,或者其他任何情况。然后 B,如果置信度分数低于某个百分比,您甚至根本不告诉任何人,并尝试找出它是否真的是一个问题?我猜你会继续工作或者忘记它。解释整个事情。

用户体验以及您是如何做到这一点的。是的,我们意识到,因为这是一个建立信任的过程,我们不能只回应我们发现的任何东西。代理有时只是不是,尤其是在入门阶段,对不起,在入门阶段,他们没有必要的访问权限,也没有上下文,对吧?因此,至少在开始训练代理时,您不希望它只是用这些原始想法来轰炸您。因此,置信度分数是

我认为许多团队实际上正在尝试将其构建到他们的产品中作为代理构建者。在这种情况下,这非常困难,因为它是一个如此无监督的问题。

我试图不深入原始细节,因为我们投入了很多努力,比如构建这个置信度分数是我们 IP 的很大一部分,就像,我们如何衡量我们自己的成功?为 IP 想出一个神圣的名字或其他什么。这不是你的 IP。这是你的,摩西在山上得到启示的时候是什么?那是,这不是你的 IP。这是你得到的启示。是的。

但高层次基本上是由这个数据飞轮驱动的。它确实是由经验驱动的。这也是工程师做事的方式。但这些可能是,同样,像产品基础层一样,也是这家公司的经验。因此,我们确实使用 ILM 进行自我评估,但它也由现有经验驱动和支持。

因此,我们注入很多这些经验,以及这些是积极的结果还是消极的结果。作为一名工程师,您可以设置阈值。因此,您可以说只应显示极其相关的发现或诊断。您可以设置简洁性和特异性。因此,您可以说,我只想要一句话,或者只给我一个词,或者给我所有原始信息。

因此,我们今天所做的是非常异步的。因此,警报病毒将从一个任务开始,它将找到我们可以找到的任何信息并返回。如果我们有信心,我们会回应。如果没有,我们会保持沉默。但是,您可以以异步方式与我们互动。因此,它以异步方式开始,然后您可以以异步方式来回踢球。在异步模式下,对不起,在同步模式下,

它非常互动且延迟较低。如果我们问你一个问题,我们会回应。因此,置信度分数就不那么重要了,因为这就像用户正在完善答案,说,回去,试试这个,回去,试试这个。但对我们来说,关键是我们必须拿出良好的初步调查结果。这就是为什么置信度分数如此重要的原因。但同样,它确实是由经验驱动的。重申一下,为什么这是一个如此复杂的问题

您不能只获取生产环境并说,好吧,我将在 Docker 容器中启动它并在特定时间点重现它。在许多公司,您甚至无法跨服务进行低测试。它太复杂了。因此,所有不同的团队都是相互关联的。您可以作为一家小型初创公司在 Heroku 或 Vercel 上运行一个应用程序来做到这一点。但在大多数公司大规模地做到这一点实际上是不可能的。所以......

你没有那个基本事实。你不能百分之百肯定你是对的还是错的。这就是我们现在的状态。尽管如此,置信度分数一直是一种非常强大的技术,至少可以消除大多数真阳性。或者当我们知道我们没有任何实质性内容时,只需保持沉默。但是你怎么知道你已经获得了足够的信息?

当你进行扫描或进行搜索以返回给人类并提供该信息时?此外,当您来回进行操作时,您如何知道您完全理解人类的要求?老实说,这是非常具有挑战性的关键部分之一。一个人会说结账服务已完成。

你需要知道他们可能根据工程师谈论的是生产环境。或者如果他们一直在谈论开发新功能,他们可能是在谈论开发环境。如果你走错了路,那么你可能会花费一些金钱和大量时间来调查一些无用的东西。

因此,我们所做的是,即使是在传入的初始消息中,如果我们不确定您在问什么,如果您没有足够具体,我们也会提出澄清问题。大多数代理构建者,即使认知是去骨的,他们也会这样做。最初他们会说,好吧,你是指 X、Y 和 Z 吗?好的,这是我的计划。好的,我现在就去做了。因此,从 UX 层面来看,这些产品中都建立了一种信心。这就是我们现在所处的位置。它

使用 ChatGPT,您有时可能会说,或者使用 Claude,一些非常不准确或含糊不清的内容,它可能会猜出正确的答案,因为成本不是多步骤的,对吧?它非常便宜。您可以快速修复文本。

但对我们来说,我们必须短路并确保您在初始说明中足够具体。然后随着时间的推移,稍微放松一点。当我们更多地了解您的团队在做什么,您在做什么时,您可以更加含糊。但就目前而言,它需要更具体的指导。说到多轮对话以及为某些事情花钱或试图不浪费金钱并走错树枝或兔子洞,

您如何看待代理的定价?它是完全基于消耗的?您是否在考虑 SRE 的价格?你说,哦,我们会按这个价格的一定百分比定价,因为我们节省了你的时间。在你看来,正确的定价基础是什么?

我们正在努力构建工程师喜欢使用的产品。因此,我们希望它成为牙刷。我们希望它成为您触手可及的东西,而不是您的可观察性平台,而不是进入控制台。因此,对我们来说,使用率非常重要。因此,我们不希望采购成为障碍。但现实情况是存在成本,这是一项业务,我们希望增加价值。金钱是您向我们展示我们有价值的方式。因此,最初的代理理念是,将会有这种

工程团队的增强,并且您可以以工程人员数量或员工数量的一小部分来收取数量级更低的费用,从而增强团队。我认为这个问题还有待商榷。我认为今天大多数代理构建者都在定价以进入生产环境或进入他们需要使用的系统以解决问题。

接近他们的角色,如果你看看 devon 做了什么,我认为他们也从每年 10k 或某种定价开始,我认为现在每月是 500 美元,但这主要是一个基于消耗的模型,因此您获得了一些承诺的计算小时数,这实际上为您提供了使用产品的时间

对我们来说,我们也围绕该模型进行定位。因此,因为我们不是 GA,所以我们的定价有点像波动,我们正在与我们的初始客户合作,以了解他们认为什么是合理的?他们认为什么是公平的?但我认为我们将采用与 Devon 模型非常相似的模型,即基于用量的模型。我们不希望工程师考虑,好吧,如果进行调查,这将花费我 X 美元。他们应该能够运行它并查看它是否有价值,并增加使用量。

但这将是关于您可以详细使用的分层计算量。因此,您每月可能会有 5,000 次调查或类似数量的调查。好的,很好。是的,因为这立刻浮现在我的脑海中,您希望人们尽可能多地使用它。但是,如果您采用基于用量的定价,那么不可避免地......

你会遇到摩擦,是的,我想用它,但这会花费我一些钱。是的。是的。因此,您确实希望预先设置一个承诺的金额。我们还在探索像拥有免费层或免费频段一样的东西。也许前 X 次只是,您可以试用一下。当您达到更高的限制时,您可以说,好吧,让我们打开水龙头。

所以我们甚至没有谈论工具的使用,但这感觉是如此复杂,因为您正在使用工具,您正在使用不同的工具,您正在使用一系列工具。您如何利用这些工具,对吧?因为如果您查看日志或您

直接与世界上的数据狗同步。您如何看待此工具的使用情况,以及在该领域克服的一些特别艰巨的挑战?同样,这又回到了为什么这如此具有挑战性,尤其是在我们看到的一件关键事情上,代理解决问题的方案与人类大相径庭。

但他们需要人类需要的大量东西。他们需要相同的工具。如果您将所有数据存储在 Datadog 中,我们可能无法仅通过查看运行在您云端前面的实际应用程序来找到解决问题所需的所有信息。因此,我们需要去 Datadog。所以我们需要在那里的访问权限。因此,工程团队给了我们这个访问权限。

如果您随后构建了一堆仪表板和指标,这就是您制定运行手册和流程以调试问题的方式,我们需要做的事情例如查看多个图表或图形,并在问题发生的时间范围内推断,在多个服务中发生哪些异常,因此如果其中两个是

在 CP 中激增并且相互关联。因此,我们应该查看它们之间的关系。但对于大型语言模型来说,这些都是极其困难的问题,甚至是视觉模型。它们并非为此而设计的。因此,在工具使用方面,大型语言模型或基础模型擅长某些类型的信息,尤其是语义信息,例如代码、配置、日志。

他们对跟踪的了解略少,但也相当不错。但他们真的不擅长指标。他们真的不擅长时间序列。因此,它实际上取决于您的可观察性堆栈,它将有多有用。因为对于人类来说,我们只是坐下来查看一堆仪表板,我们可以立即看到模式匹配。您可以看到这些是峰值。但对于大型语言模型来说,他们看到的却有所不同。

因此,我们会发现,随着时间的推移,这些可观察性工具至少可能会变得越来越不以人为中心,甚至可能变得多余。您可能会看到完全不同的诊断问题的方法。我认为蜂巢方法、基于跟踪的方法以及这些高基数事件可能是我认为最有可能获胜的主导模式。

你能快速解释一下吗?我不知道那是什么。所以基本上他们所做的是,或者慈善事业负责人和一些其他人多年来一直在推广的是记录跟踪,但附加了丰富的事件。因此,您基本上可以跟踪整个应用程序堆栈中的请求,并且,嗯,

您可以在沿途的多个步骤中记录完整的对象有效负载,并将其存储在您可以查询所有信息的系统中。因此,您拥有时间点,您还拥有跟踪的整个树。然后在每个点上,您可以看到各个属性和字段。因此,与查看时间序列相比,您会获得更多详细信息,您基本上会看到,好的,CPU 正在上升,CPU 正在下降。你能从中清理什么?你基本上必须像

像巫术一样,试图找到根本原因,对吧?但世界上的数据狗已经赚了很多钱......对不起,世界上的数据狗已经赚了很多钱来销售消费和多年来向工程师销售巫术。因此,保持这种现状存在真正的激励。但我认为,随着代理变得越来越占主导地位,我们将看到它们会转向最有价值的信息来源,然后......

如果您为您的代理提供越来越多的范围,您会发现 Datadog 很少参与这些根本原因分析。那么我们为什么还要为它们付费呢?所以我不确定未来两三年会是什么样子,但随着代理成为诊断和解决问题的首选方法,事情的发展将会很有趣。是的,我甚至没有想到这一点,对于人类使用来说,它就像 Datadog 设置得很好一样

很棒,因为我们查看它,它给了我们所需的一切,我们可以通过模式匹配非常快速地找到根本原因,但如果这成为代理难以做的事情之一,而不是让代理更好地理解指标,也许您只需提供不同的数据,以便它可以在没有这些指标的情况下找到根本原因,它将远离

读取这些服务的信息。如果你看看国际象棋和人工智能以及世界上的 Stockfish,这只是一个与特级大师对弈的人工智能。即使是顶级棋手也从人工智能那里学习。他们知道侧面的兵卒推进非常强大,或者车升起非常强大。所以现在

世界顶级棋手采用这些技术,他们从人工智能那里学习。但这也是因为总是有一个人参与其中。我们仍然想看到人们与人比赛。但是,如果您只把它留给人工智能,那么他们玩游戏的方式完全不同。他们看到了我们看不到的东西。我知道我没有在开始时完全回答你的问题,但这些工具是我们行动的基础。因此,可观察性堆栈是其中之一。但最终,我们为生产环境构建了一个完整的抽象。所以代理......

使用这些工具并学习如何使用这些工具,并知道哪些工具最有效,但是

我们还构建了一个可转移层。因此,您可以将代理从真实的生产环境转移到评估堆栈。它甚至不知道它是在评估堆栈中运行的。它现在突然只是在查看虚假服务、虚假 Kubernetes 集群、虚假数据文档、虚假场景、虚假世界。因此,这些工具是一个极其重要的抽象。这是代理需要的关键抽象之一。老实说,它

内存管理和工具是代理团队现在应该关注的两件大事,我认为,现在。等等,你为什么把它切换到这个虚假世界?因为那是你完全控制的地方。那是你可以引入你自己的场景、你自己的混乱并扩展你的代理的地方。但是,如果您这样做时工具不同、世界不同、经验不同,那么当您将其带入生产环境时,可转移性就会降低,那么它就会突然失败。所以你想要

像你工具或评估基准中的生产环境的真实相似物。你是否正在进行任何类型的混沌工程来查看代理的性能?是的,这几乎就是我们的评估堆栈。这是混乱。我们创造了一个世界,在这个世界中我们创造混乱,然后我们说,鉴于这个问题,发生了什么?根本原因是什么?我们看看我们能多接近采用原因。完美。

一个令人难以置信的名字的机会,比如路西法,这是地狱的第七层,我不知道类似的东西,是的,我们在博客文章中有一些想法,这些想法将会有更多参与者,所以 tpd 我想需要注意的一点是,

这是一个非常深奥的空间。因此,如果您查看自动驾驶汽车,生命攸关。因此,人们非常关心。您必须达到比人类驾驶汽车更高的标准。在这个领域非常相似,对吧?就像这些生产环境是神圣的。它们对这些公司很重要,对吧?它们是,如果它们崩溃了,或者发生了数据泄露或其他任何事情,那么它们的业务就岌岌可危了。首席技术官非常关心。我们必须达到的标准非常高。因此,我们非常重视安全。但是

我们正在构建的整个产品需要大量的关注,并且其中包含许多复杂性。因此,我认为作为一名工程师在这个领域工作非常引人注目,因为有很多引人注目的问题需要解决,例如知识图谱构建、置信度评分、如何进行评估,例如如何从这些环境中学习并将它们构建到您的核心产品中,工具层、混沌基准,所有这些东西。以及如何在可靠、可重复的方式下做到这一点?我认为另一个巨大的挑战是

如果您是 AWS 或 GCP 或使用此堆栈或其他堆栈,如果您是从电子商务到游戏再到社交媒体,您的代理有多通用?您可以盖章吗,或者您只能解决一类问题?因此,我们现在真正关注的事情之一是产品的可重复性和将其扩展到越来越多的企业。但是是的,我想说这是一个极其复杂的问题。即使我们今天很有价值,

真正的解决方案,端到端的解决方案,可能需要数年时间,就像自动驾驶汽车一样。花了数年时间才达到 Waymo 上路的地步。是的,我想问你的是真正的解决方案以及它如何像,首先这让我感到害怕,而且我没有在生产中运行任何东西,更不用说一个价值数百万美元的系统了。所以我只能想象你会

当你向工程师提出这个问题时,你会遇到很多阻力?令人惊讶的是,没有。肯定会有犹豫,但犹豫主要基于不确定性。例如,您到底能做什么?如果您向他们展示,例如,我们实际上无法更改任何内容。我们没有访问权限。例如,API 密钥是只读的,或者我们受到这些环境的限制。如果您通过他们已经拥有的流程(例如拉取请求)引入更改,并且已到位安全措施,

那么他们会非常开放地接受这些想法。我认为这很大一部分是工程师真的讨厌并讨厌支持。因此,他们渴望一些可以帮助他们摆脱困境的东西。但这是一种渐进的信任建设过程。我们已经与很多企业进行了交谈,几乎所有企业都有不同级别的敏感性。例如,您有大型客户,

您不想触碰他们的关键系统,但您有内部气流部署和您的 cicd 您的 gitlab 部署,如果该东西崩溃了,我们可以将其扩展,或者我们可以尝试在那里进行更改,对客户没有影响,因此我们今天真正帮助团队的领域是在较低严重性或低风险的地方,我们可以进行更改,并且如果随着时间的推移您压垮这些更改,工程师会将您介绍给更多

高价值的地方。但是,是的,现在我们正在避开关键系统,因为我们不想做出危险的更改。是的。而且感觉负担太重了。因此,即使您做得一切正确,因为它维护成本很高,

您现在还不想把自己陷进去。当工程师准备好时,让他们带您进来。当您感觉准备好了时,我当然可以理解这一点。此外,从行为上讲,工程师不会改变他们的,你知道的,他们使用的工具,在战争场景中的流程。当某些事情像轻松的环境时,他们愿意尝试人工智能并进行实验并采用它。

但如果这是一个关键情况,他们想引入人工智能并增加更多混乱,对吧?他们想要一些可以减少不确定性的事情。是的,这让我想起了我每次使用代理或构建涉及人工智能的系统时都会注意到的主要事情之一。提示可能是最大的障碍。对我来说,提示有时感觉像

我只需要做就行了。显然,我大多数时候并没有构建依赖于代理的产品,所以我没有动力坚持下去。但很多时候,我会长时间摆弄提示,以至于我生气了,因为我觉得我应该做我正在尝试做的事情。

而不是让 AI 来做?我对你没有答案。这只是野兽的本性。是的,没错。我想双击一下并说每个人都有这个问题。每个人都在为此而挣扎。你不知道你是否像一个提示更改或 20 个提示更改一样。他们非常擅长让您感觉越来越接近,但您可能并没有。我们在构建框架以进行评估方面取得了成功,以便我们至少可以理解

无论是来自生产环境还是评估。有一些样本,真相使我们知道或让我们相信我们正在得到答案。否则,你只会永远,对吧?就像不断调整事情却永远无法到达那里一样。就是这样。这令人沮丧,因为有些,是的,有时你会向前迈一步,向后迈两步,你会想,哦,我的上帝。内容创作中相当困难。我认为在您的领域更难。我几乎没有经历过

肯定不再用它来创作内容了,也许可以用它来帮我填补空白页面并获得大致方向,但总的来说,是的,我不喜欢它写作的方式,即使我最大限度地提示它,它也不像能给我深刻的见解,所以停止使用了,但你还在用GPT-3.5对吧?