Shahar Azulay, cobertura de solo 首席执行官兼联合创始人

Shahar Azulay， groundcover 的首席执行官兼联合创始人，是一位连续研发领导者。Shahar 在网络安全和机器学习领域拥有丰富的经验，曾在 Apple、DayTwo 和 Cymotive Technologies 等公司担任领导职务。Shahar 曾在以色列总理办公室的网络安全部门工作多年，并拥有以色列理工学院和特拉维夫大学的物理学、电气工程和计算机科学三个学位。Shahar 致力于运用从这一丰富背景中获得的技术知识，以最敏锐、最具创新性的形式将其应用于当今云原生战场，让开发者的世界变得更美好。

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

回顾您的历程——从领导以色列总理办公室的网络安全研发团队，到管理 Apple 的机器学习项目——哪些经历最终促使您创立了 groundcover？您最初是在何时认识到现代 AI 系统在可观测性方面存在空白的？

创立 groundcover 的动力源于我在 Apple 和 DayTwo 的时光。即使拥有巨额预算，我们也陷入两难境地：要么支付高昂费用记录一切，要么进行采样并盲目飞行。那时，我们就在寻找一种能解决这个问题的技术。当我们遇到扩展伯克利包过滤器（eBPF）时，很明显它将改变一切。eBPF 让我们能够看到内核中发生的一切，而无需依赖应用程序的更改。我不明白为什么可观测性工具没有利用这一点。AI 领域的空白是后来才变得清晰的。一旦我们的 Kubernetes 平台成熟，我们看到客户急于部署生成式 AI，同时将大语言模型视为黑盒。他们知道模型有响应，但不明白为什么其行为不可预测，或者为什么成本激增。我们意识到，智能体工作流本质上就是复杂的、非确定性的微服务，它们需要我们已经构建的同样的零接触可见性。

您在网络安全、嵌入式系统和机器学习研发方面的背景如何影响了 groundcover 背后的愿景？在构建一家专注于 LLM 驱动和智能体应用可观测性的公司时，您早期遇到了哪些挑战？

我的网络安全背景塑造了公司的基因。在情报领域，你假设自己无法控制应用程序。正是这种方法使得 groundcover 无需插桩。根据我的经验，要求开发人员修改代码是阻碍采用的最快方式。LLM 监控方面最困难的早期挑战是隐私。AI 的可观测性会捕获可能包含敏感个人身份信息或知识产权的提示。我的背景让我清楚地认识到，企业不会希望这些数据离开他们的环境。这就是我们构建云内架构的原因，使我们能够在将所有数据保留在客户自身环境内的同时，提供对智能体行为的深度可见性。

您如何定义 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 发出警报 – 您可以定义 SLO，例如“任何超过一秒的 LLM 调用都违反了我们的面向用户的 SLA”，并在满足这些条件时触发警报。随着时间的推移，类似的 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 通过自动发现 AI 流量来解决这些问题，然后为您提供：

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

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

展望未来，随着智能体 AI、多模型编排和监管压力的加速，您预计 LLM 可观测性在未来五年将如何演变？

我们仍处于早期阶段。在未来五年，我预计会有一些重大转变：

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

简而言之，LLM 可观测性将从“用于 AI 的锦上添花的仪表板”演变为连接组织在 AI 方面所做一切工作的可靠性、成本控制、数据治理和产品质量的中枢神经系统。

感谢这次精彩的采访,希望了解更多信息的读者请访问 cobertura do solo.