沙哈尔·阿祖莱（Shahar Azulay），Groundcover的CEO和联合创始人

沙哈尔·阿祖莱（Shahar Azulay），Groundcover的CEO和联合创始人，是一位连续的研发领导者。沙哈尔在网络安全和机器学习领域拥有丰富的经验，曾在苹果、DayTwo和Cymotive Technologies等公司担任领导职务。沙哈尔在以色列总理办公室的网络安全部门工作了多年，并拥有来自以色列理工大学和特拉维夫大学的三个学位：物理、电气工程和计算机科学。沙哈尔努力利用他丰富的背景和技术知识，将其带到今天的云原生战场中，使世界变得更好。

Groundcover是一款云原生可观察性平台，旨在为工程团队提供对其系统的完整、实时可见性，而无需传统监控工具的复杂性或成本。Groundcover基于eBPF技术，能够在云原生和Kubernetes环境中收集和关联日志、指标、跟踪和事件，而无需代码更改，从而实现更快的根因分析和更清晰的系统洞察。该平台强调可预测的定价、灵活的部署（保持数据在客户的云中）和端到端的可观察性，涵盖基础设施、应用程序和现代AI驱动的工作负载。

回顾你的旅程——从以色列总理办公室的网络安全研发团队到苹果的机器学习项目——是什么经历最终促使你创立Groundcover？你是什么时候意识到现代AI系统的可观察性缺口的？

创立Groundcover的动力来自我在苹果和DayTwo的经历。即使拥有巨大的预算，我们也被迫在支付巨额费用来记录一切或采样和盲目飞行之间做出选择。回到那时，我们正在寻找一种能够解决这个问题的技术。一旦我们遇到了扩展的伯克利数据包过滤器（eBPF），就很明显它将改变一切。eBPF使我们能够在不依赖应用程序更改的情况下看到内核中发生的一切。我无法理解为什么可观察性工具没有利用这一点。AI缺口后来变得明显。一旦我们的Kubernetes平台成熟，我们看到客户正在将GenAI部署到生产环境中，同时将LLM视为黑盒子。他们知道模型响应了，但不知道为什么模型行为不可预测或为什么成本激增。我们意识到，代理工作流只是复杂的、非确定性的微服务，需要与我们已经建立的零接触可见性相同的可见性。

你的网络安全、嵌入式系统和机器学习研发背景如何影响Groundcover的愿景？你在构建一个专注于LLM驱动和代理应用的可观察性公司时面临的早期挑战是什么？

我的网络安全背景塑造了公司的DNA。在情报世界中，你假设自己无法控制应用程序。这种方法就是为什么Groundcover不需要仪器化的原因。我从经验中知道，要求开发人员修改代码是阻止采用最快的方法。监控LLM的最难的早期挑战是隐私。LLM的可观察性捕获可能包含敏感的个人身份信息（PII）或知识产权（IP）的提示。我的背景使我意识到，企业不会希望这些数据离开他们的环境。这就是为什么我们建立了自己的云架构，使我们能够在不将数据发送到第三方的情况下提供对代理行为的深入可见性。

你如何定义LLM的可观察性，它与传统监控或机器学习监控有什么不同？

LLM的可观察性是指监控使用大型语言模型的生产系统的实践，以便捕获每个推理的完整上下文：提示、上下文、完成、令牌使用、延迟、错误、模型元数据和理想的下游反馈或质量信号。与仅仅询问“服务是否正常运行和快速？”或“此请求是否出错？”不同，LLM的可观察性帮助您回答诸如“为什么此特定请求成功或失败？”、“多步骤工作流中实际发生了什么？”和“对提示、上下文或模型版本的更改如何影响成本、延迟和输出质量？”等问题。这与传统监控或甚至经典的机器学习监控非常不同。传统方法是为确定性系统、基础设施指标和静态阈值而设计的。LLM应用程序是非确定性的、开放式的和高度依赖上下文的。成功往往是语义和主观的，而不仅仅是200与500状态码的区别。这意味着您需要跟踪输入和输出、理解工具调用和检索步骤、评估响应（例如幻觉或策略违规）并将令牌级别的成本和延迟与周围的应用程序和基础设施联系起来。

LLM驱动的应用程序引入了哪些挑战，使传统的可观察性工具变得不充分？

LLM驱动的系统引入了几个挑战，这些挑战暴露了传统工具的局限性：

• 复杂的多步骤工作流 – 我们从简单的“调用模型，获取响应”流程转变为多回合代理、多步骤管道、检索增强生成和工具使用。工作流中的任何步骤（例如检索、增强、嵌入、工具调用或模型调用）的沉默故障都可能破坏整个体验。传统监控通常不会提供包含提示和响应的完整、跟踪级别的工作流视图。
• 快速演化的AI栈 – 团队正在以以前从未见过的速度添加新模型、工具和供应商。在许多公司中，没人能自信地列出哪些模型目前处于生产环境中。经典的可观察性通常假设您有时间来仪器化SDK、重新部署和仔细策划要测量的内容。这根本跟不上AI的采用速度。
• 基于令牌的经济和配额 – 定价和速率限制与令牌和上下文长度绑定，这些通常由开发人员、提示或用户行为控制，而不是由中央操作控制。传统工具不适合显示“谁在哪个模型、哪个工作流和哪个延迟下消耗了多少令牌”。
• 语义正确性而不是二进制成功 – 一个LLM可以返回200并且仍然产生幻觉、偏离提示或违反策略。传统工具将其视为成功。您需要一种可以显示提示和响应并提供足够的上下文来检查行为的可观察性，并随着时间的推移，可以插入自动质量检查。
• 流入第三方的敏感输入数据 – LLM邀请用户通过类似聊天的界面共享非常敏感的信息。现在您负责该数据、其存储位置以及哪些供应商可以看到它。传统的基于SaaS的可观察性工具通常会将所有遥测数据发送到第三方，这对于这些工作负载来说是不可接受的。

所有这些都意味着LLM系统需要一种可观察性，它是AI感知的、上下文丰富的，并且比今天大多数团队使用的工具依赖于手动仪器化的程度要小。

哪些信号或指标对于了解LLM系统的性能和质量最重要，包括延迟、令牌使用和提示/响应行为？

在实践中，有几类信号很重要：

延迟和吞吐量

• 每个请求的端到端延迟，包括模型时间和周围应用程序时间。
• 每个模型和每个工作流的尾部延迟（P90、P95、P99）。
• 每个模型、路由和服务的吞吐量，以便您知道负载实际上来自哪里。

令牌使用和成本驱动因素

• 每个请求的输入和输出令牌，按模型划分。
• 每个模型、团队、用户和工作流的聚合令牌使用情况随时间变化。
• 检索密集型管道的上下文大小，以便您可以看到提示何时爆炸。
• 这就是让您能够回答“谁实际上在花费我们的AI预算，并且在什么上面花费？”的问题。

提示和响应行为

• 代表性跟踪中的实际提示和响应有效负载，包括工具调用和推理路径。
• LLM选择调用的工具及其调用顺序。
• 对类似提示的响应的变化，以便您可以判断行为的稳定性如何。

可靠性和错误

• 特定于模型的错误率和类型（提供商错误、超时、身份验证问题、配额错误）。
• 与LLM调用相关的周围工作流中的故障，例如工具超时或检索错误。

经典基础设施上下文

• 为LLM调用编排的服务的容器CPU、内存和网络指标。
• 描述应用程序试图执行的操作的相关日志。

当您可以在一个地方看到所有这些时，LLM的可观察性就会从“我知道某些东西很慢或很贵”转变为“我知道哪个模型、哪个提示模式和哪个服务负责以及为什么”。

可观察性如何帮助团队检测诸如提示漂移、幻觉或输出质量的逐渐恶化等沉默故障？

LLM系统中的沉默故障通常发生在基础设施层面一切看起来“绿色”的情况下，但实际行为正在漂移。可观察性有几种帮助方式：

• 跟踪整个工作流，而不仅仅是模型调用 – 通过捕获从客户端到服务到检索到模型到工具的整个请求路径，您可以看到行为发生了变化。例如，也许检索开始返回更少的文档，或者工具调用间歇性地失败，模型正在即兴发挥。
• 保持提示、上下文和响应在视野中 – 当您可以在跟踪旁边检查提示和响应时，很容易发现新的提示版本、系统指令或上下文源的变化，即使延迟和错误率保持不变，也会改变行为。
• 根据语义条件进行筛选和切片 – 一旦您拥有丰富的LLM遥测数据，您就可以筛选出诸如“超过一秒的bedrock调用”、“使用此模型家族的请求”或“涉及此特定路由的跟踪”等内容，然后阅读提示和响应以查看模型是否在特定场景中漂移或产生幻觉。
• 针对业务级别的SLO进行警报 – 您可以定义诸如“任何LLM调用超过一秒就会违反我们的用户面向SLA”等SLO，并在这些条件被满足时触发警报。随着时间的推移，类似的SLO可以与质量评分或策略检查绑定，因此您在质量下降时收到警报，而不仅仅是在基础设施故障时。

因为可观察性层具有访问AI特定信号和经典日志、指标和跟踪的访问权限，所以它成为捕获其他情况下会悄悄降低用户体验的问题的自然位置。

Groundcover的方法如何支持诊断多步骤代理工作流和工具调用中的不可预测的延迟或意外行为？

Groundcover采用了一种专为现代AI系统设计的方法。我们使用基于eBPF的传感器在内核级别观察微服务之间的流量，而无需代码更改或重新部署。只要您引入LLM工作流，我们就可以自动发现这些调用。如果您明天开始使用像Anthropic、OpenAI或Bedrock这样的新模型，Groundcover会自动捕获该流量。这为您提供：

• 多跳工作流的端到端跟踪 – 您可以看到请求在服务（包括LLM或工具）中的完整路径。
• 每个LLM调用的深度上下文 – 每个调用都包括使用的模型、延迟、令牌使用、提示、响应和相关日志和基础设施指标。
• 延迟和条件的强大筛选 – 例如，您可以筛选出所有超过一秒的Claude 3.5调用，并立即检查违反SLA的跟踪。
• 与LLM行为绑定的警报和仪表板 – 一旦数据可用，您就可以为SLA违规或构建跟踪延迟、吞吐量、令牌使用和错误的仪表板创建警报。

因为所有内容都在边缘通过eBPF收集并存储在您自己的云中，因此您可以在不添加仪器化的情况下获得这种高粒度的视图。

您在LLM部署中看到哪些数据安全和合规风险？可观察性如何帮助减轻这些风险？

LLM部署带来一些独特的数据风险：

• 无界限的用户输入 – 用户可以通过聊天式界面输入极其敏感的信息到聊天机器人和AI驱动的界面中。这可能包括个人数据、客户数据或您从未打算收集的受监管信息。
• 第三方模型提供商 – 一旦您将该数据发送到外部LLM提供商，您就对数据的去向、存储方式以及哪些供应商参与其中负责。对于GDPR、数据驻留和客户信任，这有着重大影响。
• 遥测作为敏感数据的第二份副本 – 如果您的可观察性堆栈将完整有效负载发送到SaaS供应商，您现在在环境外拥有敏感信息的另一个副本。

Groundcover的架构旨在解决这些问题：

• 我们使用一种自带云模型，即完整的可观察性后端在您的云帐户中运行，在子帐户中作为完全托管的数据平面。控制平面由我们运行，但我们不访问、存储或处理您的遥测数据。
• 因为我们可以在您的环境中安全地捕获有效负载，所以您可以在不将数据发送到第三方的情况下观察提示、响应和工作流。没有第三方存储您的LLM跟踪，也没有额外的数据出口需要担心。
• 有了这种可见性，您可以看到谁正在上传什么以及数据流向哪里，检测到对敏感数据的意外使用，并执行有关允许的模型和区域的策略。

换句话说，可观察性不仅成为可靠性和成本的工具，也成为隐私、数据驻留和合规性的关键控制点。

当组织从一个LLM集成扩展到许多AI驱动的服务时，什么样的运营挑战往往会出现，涉及可见性、可靠性和成本？

第一个集成通常是一个单一的模型在一个单一的工作流中。在这个阶段，事情看起来很容易管理。随着团队看到价值，使用量就会爆发，几个挑战就会出现：

• 模型和供应商扩散 – 团队正在以以前从未见过的速度添加新模型、工具和供应商。在许多公司中，没人能够自信地列出哪些模型目前处于生产环境中。
• 令牌使用的成本惊喜 – 令牌消耗会随着上下文长度和工作流复杂性的增加而增长。没有对每个模型和工作流的令牌使用的可见性，管理成本将非常困难。
• 对外部提供商的可靠性依赖 – 用户面向的API变得对模型延迟或错误敏感，这可能会破坏SLA，即使核心基础设施是健康的。
• 日益增长的仪器化债务 – 传统的可观察性假设您可以在需要时添加仪器化。在快速发展的AI栈中，开发人员很少有时间进行此操作。

Groundcover通过以下方式解决这些问题：

• 对使用的模型和供应商的集中可见性。
• 显示延迟、吞吐量和令牌使用随时间变化的仪表板。
• LLM行为与依赖于它的服务之间的关联。
• 与AI驱动的SLO违规相关的警报。

这使得从“一个很酷的AI功能”扩展到“AI融入到几十个关键服务中”而不失去控制变得更加容易。

展望未来五年，随着代理AI、多模型编排和监管压力的加剧，您如何预期LLM的可观察性将会演变？

我们仍然处于早期阶段。未来五年，我预计会发生几次重大变化：

• 从请求级别到代理级别的理解 – 可观察性将扩展到捕获工具序列、推理路径和重试逻辑，而不仅仅是模型调用。
• 更丰富的语义和策略信号 – 自动质量检查将成为幻觉、安全问题和品牌一致性等方面的标准指标。
• 与治理和隐私的更紧密耦合 – 随着监管的增长，可观察性也将作为数据驻留、保留和批准模型使用的执行和审计层。
• 跨模型、多供应商的优化 – 团队将根据性能和成本动态地将流量路由到模型，受实时可观察性数据的指导。
• 更少的手动仪器化 – 像eBPF基于的收集和自动发现这样的技术将成为默认设置，因此团队可以在不减慢速度的情况下创新。

简而言之，LLM的可观察性将从“AI的不错仪表盘”演变为连接可靠性、成本控制、数据治理和产品质量的中央神经系统，涵盖组织在AI方面所做的一切。

感谢这次精彩的采访，希望阅读本文的读者可以访问Groundcover，了解更多信息。