大模型实践 | 为慧眼智能可观测平台插上 ChatInsight 的翅膀

ChatInsight 是网易杭州研究院（简称杭研）在慧眼智能可观测平台引入大模型开发的创新功能，支持通过自然语言交互实现高效数据共享与经验积累，以提高业务日常稳保工作效率。ChatInsight 目前已在网易云音乐、新闻、智企、严选、有道等业务落地，并已作为网易数帆 Cloud Native Copilot 的一项核心能力，集成了到云原生稳定性保障平台中。

在本文中，杭研技术专家青龙解读了 ChatInsight 的产品设计、实现原理及未来规划，并分享了网易公司沉淀的 AIGC 工程化实践经验，为读者更好地理解和应用 AIGC 技术提供参考。

ChatInsight 研发背景

在网易杭州研究院，大模型和 AIGC 技术已有广泛应用，如网易数帆有数ChatBI和 CodeWave 智能开发平台，就是知识增强领域大模型技术在数据分析、软件开发领域的典型应用。而在运维领域，引入 AIGC 的一项前沿创新就是慧眼 ChatInsight。

慧眼是杭研打造的一个智能可观测平台，为网易集团提供云原生环境下基础设施和业务的统一观测。ChatInsight 定位为慧眼智能可观测平台的自然语言交互入口，旨在利用 AIGC 技术手段，实现观测经验与数据的高效共享与积累，从而达到提高业务稳定性保障的目的。

在业务稳定性保障过程中，告警处理、问题定位和日常运维都依赖可观测数据作为决策支持。基于 AIGC 迅速且智能地获取所需的可观测数据，能够克服传统稳定性保障方案的挑战，缩短人工排查时间，提高工作效率。

传统的稳定性保障过程中存在三大问题：

1. 告警处理效率不高；

2. 故障定位效率有待提升；

3. 经验积累方式不规范，导致经验应用效率较低。

告警处理

在业务稳定性保障过程中，处理各种告警的一般方式包括：

1. 开发与运维人员根据个人经验或临时查阅 FAQ；

2. 登录告警平台查看告警信息，接着登录 APM 查看业务指标和拓扑信息，再登录到哨兵业务所在机器的指标，登录到业务日志系统查看业务日志，甚至登录到机器查看系统日志和进程指标等。在经过这些步骤后，问题未必能解决，甚至需要将问题转交给其他同事，如此循环。

整个过程效率低下，主要表现为：

1. 多平台导致频繁切换，查看不同数据源耗时；

2. 告警处理过程依赖个人经验和 FAQ 积累，由于个人经验差异较大，加上 FAQ 与数据相互隔离，导致处理流程不规范且难以预测。

故障定位

故障定位依赖应用、基础设施、中间件等许多不同来源的大量可观测数据，快速获取这些数据作为故障定位的支撑，需要不断的进行切换数据上下文甚至平台上下文，这就导致效率低下。

故障定位过程中涉及多人协作时，已发现的现象和结论往往难以有效传递给后来参与者，导致上下文信息缺失。为了弥补这一不足，人员之间需要进行大量沟通，消耗更多时间和精力。

经验沉淀

目前，经验沉淀通常以团队为单位进行，沉淀方式各异，主要采用文档记录。然而，文档与可观测平台数据缺乏联动，导致沉淀经验在重复使用过程中无法直接借助数据进行决策支持，降低了效率。此外，在处理告警的过程中，还需要根据告警信息检索相应的 FAQ 处理文档，进一步影响处理效率。

解决思路分析

可执行 FAQ

FAQ 代表“常见问题解答”（Frequently Asked Questions），是特定主题或领域中经常被人们提问的问题及其解答的集合，作为一种经验的载体。可执行 FAQ 在传统 FAQ 的基础上，额外添加了获取与决策支持相关的可观测数据的方式。

因此，可执行 FAQ = 经验 FAQ + 可执行可观测数据。

问题解决办法

由上表可见，解决问题的关键在于如何构建编排可观测数据并实现可执行 FAQ。在网易，由于不同团队的业务场景差异、视角不同以及团队成员经验水平不一，告警处理和故障处理所依赖的可观测数据呈现个性化特征。因此，我们需要需要寻找一种低成本的方式来编排和整合这些数据。而 AIGC 技术，就是这种合适的方式。

引入 AIGC 低成本编排可观测数据

编排可观测数据含义

用户可以根据需求动态打包告警对象的上下游、业务 RED、所在主机、所在 Pod 资源状况、日志、事件、网络和进程等信息。以收到业务 PodOOM 告警为例，需要查看以下可观测数据：

• 近 3 天 Pod 的内存使用量和内存使用率趋势图；

• 该 Pod 的内存 Limit；

• 该 Pod 所在宿主机的内存使用量和使用率；

• 该 Pod 资源的内存推荐值；

• 查询该 Pod 的日志。

为了获取这些可观测数据，我们需要以异常 Pod 为切入点进行数据获取。这个过程被称为“编排可观测数据”。

如何低成本编排可观测数据

直接通过代码实现可观测数据编排，则成本较高，而 AIGC 可以利用自然语言生成代码，降低整个过程的成本。具体而言，可以通过以下方式实现：

• 用户通过自然语言描述动态可观测数据的编排需求，利用 AIGC 将自然语言低成本地翻译成可被程序解释的程序模板；

• 平台方面编写一个通用的执行后端，输入为程序模板，输出为可观测数据的集合。

这正是 ChatInsight 所致力于实现的功能。

ChatInsight 编排可观测数据效果展示

告警处理效果展示

01:18

上述视频以 OOM 告警为例讲述告警处理的可执行 FAQ 的制作和关联以及生效过程。大体过程如下：

1. 通过自然语言在 ChatInsight Prompt 探索模块通过自然语言完成可观测数据的编排。本例中是一个复合跨维度查询，查询 pod xx 的内存限制和内存请求，该 Pod 所在主机的内存使用率和 CPU 使用率，以及该 Pod 的日志。ChatInsight 将此查询分解并将查询结果进行展示。

2. 将可执行的 FAQ（经验和可观测数据）保存下来。

   
   

3. 将可执行 FAQ 的 URL 配置到告警的内容中，并配置好变量和告警变量的关联。

   
   

4. 告警被触发，可直接获得具体的告警对象的 FAQ 信息，提升告警处理效率。

编排可观测数据效果展示

01:12

ChatInsight 的产品能力设计

轻松获取多维度数据

用户可以通过自然语言方式向慧眼智能可观测平台提出复杂的多维度数据需求，如获取 pod xx 的下游依赖 Pod 的 CPU 使用率、内存使用量和该 Pod 所在主机的 IP 地址。ChatInsight 会逐步智能回复对应的可观测数据，协助用户轻松快速筛选所需的数据。

生产、复制和分享可观测经验

ChatInsight 是可观测经验的载体，用户可以根据面临的场景和个人经验采用自然语言产出获取数据的方法，并将自然查询用语保存到个人收藏夹，方便复用；支持将查询对象和条件模版化，复用时支持用户修改查询对象，灵活的满足各种查询需求。

低成本解决个性化需求

ChatInsight 支持用户通过自然语言描述可观测数据需求，并智能地将查询需求分解和分步骤展示，整个过程中用户只需要对话描述需求即可，从而降低个性化数据查看的成本。

根据问题智能获取可观测数据

ChatInsight 后台对接了可观测 AI 模型，允许用户输入遇到的问题，并与可观测的 AI 助手交互。AI 助手将协助用户分析问题的可能原因，并获取对应的可观测数据，以便用户逐步解决问题。

ChatInsight 实现原理

ChatInsight 通过自然语言完成可观测数据的查询展示和分析，并借助大模型的通识实现故障定位。整个框架分为三层：功能层、实现层和数据源。功能由实现层访问数据源来实现。

功能层

ChatInsight 的产品功能主要由自然语言驱动，用户通过输入自然语言使用以下功能：

需求校验：校验可观测数据查询需求的完整性，针对表达不明确的内容进行提醒和补充，直至需求完整。

自然语言查询：将完整的自然语言需求拆分成子需求，转换为 API/PromQL 等获取数据，完成数据查询、结果组装，并返回前端展示。前端可修改查询时间并支持分页展示。

结伴故障定位：作为助手，允许用户通过自然语言描述问题，AIGC 提供可能的原因及已查询的可观测数据，辅助用户进行故障定位。

数据智能分析：该功能正在开发中，用户可选择分析对象，使用自然语言转 Python 快速完成图形绘制和展示。

ChatInsight 的辅助产品功能包括：

数据回放：记录自然语言转换后的后端 API 和 PromQL 等数据获取方式及数据关联到模板中，并对查询条件进行变量化。用户可根据模板和新的查询对象查询并回放数据展示。前端可修改查询时间并支持分页展示。

可观测对象名称补全：提醒用户查询对象，避免在其他平台复制对象名称。

经验/问题记事本：记录经验和问题，形成可执行 FAQ。记事本与数据回放在同一界面，实现用户根据经验查看数据，快速做出判断。

实现层

实现层由 LLM 的 AIGC 能力、Backend 后端以及向量数据库组成，具体包括：

• LLM：将自然语言转换为查询模板（API、PromQL、LokiQL 等），作为实现所有自然语言驱动功能的引擎。

• Backend：根据查询模板完成数据查询，作为与 LLM 通信的粘合剂，实现上述功能。

• 向量数据库：解决 LLM 脑容量的问题，提高自然语言处理的效率和能力。

如何使用 LLM 实现上述功能

1. 用户使用自然语言输入获取数据需求，例如查询 pod xx 的下游依赖的 Pod 所在主机的内核版本和所在主机的磁盘使用情况。

2. 需求校验模块将查询需求发送给 LLM，使用 LLM 完成查询需求校验。如上述查询需求中的磁盘使用情况属于非明确需求，LLM 会要求用户继续补充，直至认为需求完整。

3. 完整需求会被拆分成可独立执行的小需求。例如上述需求会被拆分为（1. pod xx 的下游依赖的 Pod；2. step1_pod 所在的主机；3. step2_host 的磁盘空间使用量）。

4. 每个拆分的子语句会继续使用 LLM 翻译成 API 或查询语句，Backend 将使用这些 API 或查询语句完成数据查询。Backend 将在子语句之间传递查询结果并循环执行，直至获取最终结果。

5. Backend 记录所有子语句查询数据的方式和关联方式，并对查询对象进行变量化，便于后续更换查询对象名称。

6. 查询数据以及整个分析过程会以流式返回给前端，前端时刻有数据反馈。

AIGC 工程化经验

Prompt 经验

在 ChatInsight 研发过程中，网易杭研大量使用领域大模型技术，也踩了很多坑，以下为一些经验分享：

• 举例说明非常重要，可提高理解程度。

• 在切分任务时，确保抽象干净，抽象之间尽量不存在逻辑共同点。

• 考虑到大模型的成熟度，设计思想应围绕大模型中的抽象对象，而非强行套用现有 UI 接口。

• 描述语言也存在上下文。相关联的描述应尽量抽象和分类，位置最好放在一起，让大模型清晰了解描述语言和抽象之间的关系。

实际落地工程化思考

1. AIGC 具有不确定性，因此在对接过程中，仅依靠训练调教是不够的。后端开发需要考虑兜底机制（1.尝试修复 2.错误检查 3.兜底案例修复），尽量让不确定内容变得确定。2. 大模型上下文有限不是问题，可通过任务切分来“大事化小”：

• 做好抽象，让领域大模型从源头理解抽象分类，需要适配领域大模型，甚至重新实现原子 API。

• 组织好抽象之间的关联关系，借用确定的中间关系语言或制定多个抽象，使用变量表示。

3. 大模型引入特定产品会遇到准确度问题。开发者可以采用以下方式提升准确度：

• 例子对大模型影响最大，引入语义搜索根据需求动态携带举例。

• 采用“防御式”编程，后端程序设计时要有兜底框架，并尝试修复。

• 对于精确度要求高且核心的场景，应当考虑使用领域大模型。

• 产品设计场景应尽量精细化，携带完整上下文，以提高准确度。

未来展望

对于“AIGC+云原生”的诗和远方，ChatInsight 的探索才刚刚起步，为实现观测经验与数据的高效共享与积累，还有较多工作要做。近期即将开展的部分工作如下：

• 丰富数据源支持：持续深入对接融合慧眼的数据源；

• 数据智能分析：实现数据的自动分析画图的能力，实现轻量版本的 code interpreter，提升可观测数据分析的效率；

• 扩展支持用户自定义指标：开发框架，支持用户自定义的数据源，继续扩展 ChatInsight 的使用场景；

• 可观测经验共享和沉淀：与业务团队共建，引入更多优质稳保经验，提升告警处理和故障定位的效率。

名词解释

慧眼：网易杭州研究院为云原生时代研发的智能可观测平台，实现基础设施和业务的统一观测。

AIGC：AI Generated Content，指由人工智能生成内容。在本文中，AIGC 技术用于将自然语言需求转换为可执行的程序模板，降低编排可观测数据的成本。

可观测数据：指用于监控和分析系统性能、健康状况和行为的数据。这些数据通常包括指标、日志、事件等，有助于运维人员快速定位和解决问题。

业务稳定性保障：指确保业务系统在各种条件下正常运行的一系列措施和方法。这包括告警处理、问题定位、日常运维等方面的工作。

FAQ：Frequently Asked Questions，常见问题解答。是特定主题或领域中经常被人们提问的问题及其解答的集合，作为一种经验的载体。

可执行 FAQ：在传统 FAQ 的基础上，额外添加了获取与决策支持相关的可观测数据的方式。可执行 FAQ = 经验 FAQ + 可执行可观测数据。

LLM：Large Language Model，大型语言模型。在本文中，LLM 用于将自然语言需求转换为可执行的程序模板，实现自然语言驱动的功能。

ChatInsight：一个基于 AIGC 技术的业务稳定性保障产品功能，通过自然语言交互实现观测经验与数据的高效共享与积累，帮助提高业务稳定性保障过程中的效率。

作者简介

青龙，网易杭州研究院资深云原生技术专家，10 年服务端开发和优化经验，目前致力于慧眼智能可观测平台设计与研发。曾负责网易数帆轻舟四层负载均衡数据面设计、服务网格性能优化、Serverless 平台底层开发和优化等工作。主要关注 Kubernetes、Istio、Knative、Cilium 等技术领域。