We're sunsetting PodQuest on 2025-07-28. Thank you for your support!
Export Podcast Subscriptions
Insights from Cleric: Building an Autonomous AI SRE // Willem Pienaar // #290
2025/2/11
MLOps.community
W
Willem Pienaar
Willem Pienaar: 作为Cleric的CTO,我一直在构建AI SRE。我们面临的挑战在于,工程师既要创造软件,又要将其部署到生产环境中并运行,这对现实世界产生影响。生产环境与开发环境不同,缺少测试、IDE和及时反馈。在企业公司的生产环境中,找到代表所有问题和解决方案的数据集非常困难,这使得问题变得复杂且动态。团队正在努力掌握理解和信任的界限,构建模块化组件,虽然对内部运作不确定,但仍将其部署到生产中以提高速度,尽管会逐渐失去理解。在激励机制不一致、团队众多且面临交付压力的情况下,生产环境变得不稳定。AI生成的代码将使系统更加复杂,组件之间的动态关系将更加难以理解。难以想象在整个企业规模的组织中,Kubernetes集群的复杂性会增加。为了找到根本原因,必须因果关系地遍历图,向上游追溯。LLM擅长提取关系和处理非结构化数据,可用于构建知识图谱。知识图谱构建后会迅速过时,因此需要高效决策。我们的Agent是一个诊断Agent,利用知识图谱快速找到问题的根本原因。即使知识图谱会快速过时,拥有它仍然非常重要。在后台扫描过程中,知识图谱可能会发现未被注意的问题,例如数据暴露或配置错误,并及时提醒工程师。LLM可以作为推理引擎,预测即将发生的故障,从而实现主动警报。虽然直接将LLM应用于指标图或云基础设施对象效率不高,但通过提炼推理能力到更精细的模型中,可以实现显著的改进。在后台扫描构建图时,我们使用更高效的模型,并设置每日预算以控制成本。后台扫描并非持续运行,而是像人一样获取云基础设施的最新信息,以便在出现问题时快速采取行动。在调查中,我们为Agent设置预算上限,并允许人工干预,以便在Agent提供有价值的信息时及时介入。Agent会在预算范围内运行,并在发现有价值的信息时通知人类,否则会保持沉默或提供调查结果。我们的目标是实现端到端的问题解决,Agent能够完成工程师需要判断和使用不同工具的步骤。目前,Agent主要用于缩小搜索范围,帮助工程师更快地定位问题所在的服务或集群。Agent可以有效地减少搜索空间,并与工程师协作,逐步学习和改进问题解决能力。我们以协作模式启动,快速减少搜索范围,告知检查过和未检查过的内容,然后工程师可以提供更多背景信息并进一步指导。Agent在成功时速度很快,失败时速度很慢。我们使用置信度评分和评论员来评估Agent,以避免向人类发送垃圾信息。关键在于节省工程师的时间,避免发送不良信息,因此了解Agent的优势和劣势非常重要。我们通过丰富事件信息、分析历史数据和用户反馈来评估Agent的置信度,以便在向人类提供信息之前对其进行评估。我们采用分层方法构建知识图谱,其中一些层具有更高的置信度和持久性,并使用不同技术进行更新。使用较小的微图可以更轻松地进行数据管理。大部分关键信息通常可以在相同的系统中找到,例如配置或代码变更。监控Slack和部署情况是有效的,查看发布和变更计划,并进行评估。总结Slack讨论串非常有用,可以提取问题、讨论和解决方案,并附上相关的PR。总结Slack讨论串可以作为指导或运行手册,展示团队如何解决问题,并包含实用知识。工程师面临的两个主要挑战是理解系统和流程,以及集成和访问定制系统。作为Agent,我们需要像团队中的新工程师一样被教导,否则无法成功。LLM具有适应性,可以尝试不同的方法来总结不同粒度的信息。可以将大量原始信息直接放入上下文窗口,也可以以更简洁的形式呈现,并提供查询工具以获取更多信息。关键在于一开始就提供价值,以便工程师认可并开始协作,从而形成良性循环。工程师应该觉得Agent有价值,从而开始协作,并提供更多信息以获得更多价值。工程师不希望仅仅审查Agent的工作而没有获得任何好处,因此互动必须提供价值和隐含的反馈。有三种类型的记忆:知识图谱、情景记忆和程序记忆,都需要被捕获。我们索引环境,提取程序,并存储在环境中获得的经验。我们非常重视数据安全,Agent只能读取数据,不能进行更改,所有数据都保留在客户环境中。我们主要存储情景记忆,即事件发生时如何解决问题的实例。我们通过监控系统健康状况来评估变更的有效性,并查看代码来预测人类将进行的更改。如果Agent提出的建议被批准,则表明Agent的建议是有效的。如果Agent提出的建议被拒绝,则表明Agent的建议是错误的。与工程师的互动是隐含的信息来源,这些信息会被附加到记忆中,但最终数据集仍然非常稀疏。我们在外部评估平台上训练Agent,并进行大量手工标注,以提高Agent的准确性。Agent是通用的,但会根据客户的上下文信息进行定制。我们将Cleric的新版本和提示、逻辑、推理以及解决问题的方法注入到Cleric中。这是一个分层挑战,既要实现所有客户的跨领域收益和评估平台驱动的准确性,又要实现客户流程的定制。我们通过置信度评分来避免向工程师发送过多的警报。如果置信度评分低于某个百分比,则不会通知任何人,并继续尝试确定是否确实存在问题。我们意识到这是一个建立信任的练习,不能仅仅回应我们发现的任何东西。许多团队正在尝试将置信度评分构建到他们的产品中,但这非常困难,因为这是一个无监督的问题。置信度评分由数据飞轮和经验驱动,并受到公司内部经验的影响。工程师可以设置阈值,只显示相关性极高的发现或诊断,并设置简洁性和特异性。我们采用异步方式,Agent会主动搜索信息并返回,如果置信度高,则会响应,否则会保持沉默。在同步模式下,Agent几乎总是会响应,置信度评分的重要性降低,因为用户可以不断优化答案。无法在Docker容器中重现生产环境,因此无法确定Agent的正确性。尽管如此,置信度评分仍然是一种强大的技术,可以消除大部分误报,并在我们没有实质内容时保持沉默。如果Agent不确定用户的意图,会要求用户澄清,以避免浪费时间和金钱。Agent会要求用户提供更具体的指示,并随着时间的推移逐渐放宽限制。对于Agent来说,需要确保用户在初始指令中足够具体,以避免浪费资源。我们希望Agent成为工程师喜欢使用的工具,并根据使用情况定价。
Deep Dive
Shownotes Transcript