读前先问大方向的任务是什么Task把自然语言监控问题转换成当前云原生系统可执行的 PromQL。这个方向有什么问题Type这是带系统上下文的 text-to-PromQL 问题难点不只是语法还包括私有指标、标签以及 Service、Pod、Node 的动态关系。为什么有这些问题Why通用 LLM 缺少私有知识历史问答会因扩缩容而过期普通 RAG 难以恢复多跳关系。作者怎么解决How用 Prometheus、Kubernetes、Trace、系统文档构建知识图谱再用 LLM 解析问题、检索组件/指标/标签最后生成查询。怎么验证280 条问答对50 条历史样本、230 条测试比较 Basic Prompt、1/3/10-shot 和 PromCopilot并做检索、消融、用户研究。结果怎样GPT-4-Turbo 下 MetricAcc 91.3%、SyntaxAcc 96.1%、QueryAcc 69.1%10-shot 基线 QueryAcc 为 37.4%用户研究平均完成时间 101.65 秒。作者与机构作者Chenxi Zhang、Bicheng Zhang、Dingyu Yang、Xin Peng通讯作者、Miao Chen、Senyu Xie、Gang Chen、Wei Bi、Wei Li。机构西安电子科技大学复旦大学浙江大学国家区块链与数据安全重点实验室杭州高新区滨江区块链与数据安全研究院阿里巴巴集团。论文精读引言云原生系统包含大量节点、服务、API、Pod 和容器。Prometheus开源的时间序列监控系统负责采集、存储和查询指标提供监控数据PromQLPrometheus Query Language一种查询这些指标的领域特定语言负责把问题写成可执行查询。手写查询同时需要语言知识和当前系统上下文。例如“找出部署订单服务的节点中可用内存最多的节点”需要补齐指标名、标签名、Pod 和 Node。论文将这类任务定义为 text-to-PromQL它比 text-to-SQL 更依赖实时系统状态也比历史 few-shot 更容易受到动态部署影响。方法总体框架系统分为知识图谱构建和查询生成两阶段。生成阶段依次执行问题解析、组件关系检索、指标与标签检索、查询生成。系统上下文知识图谱Kubernetes管理容器化应用的编排平台里的组件被分成两组。系统组件实体Node 是承载 Pod 的主机Deployment 是控制应用发布的部署对象Namespace 是资源隔离空间ReplicaSet 是维持副本数量的控制器Pod 是 Kubernetes 中最小的可部署单元StatefulSet 是管理有状态 Pod 的控制器Service 是为一组 Pod 提供稳定访问入口的服务对象Container 是 Pod 内运行的容器API 是服务对外提供的接口。指标数据实体Metric 是一个指标定义例如 CPU 使用率Label-Value Pair 是标签和值例如 podts-gateway-service-…用来筛选某条时间序列。论文中的关系也可以按人话理解Service targets Pod 表示服务选择哪些 PodPod hosted by Node 表示 Pod 运行在哪台主机Pod contains Container 表示 Pod 内有哪些容器Service provides API 表示服务提供哪些接口Metric has Label-Value Pair 表示指标有哪些可用于过滤的标签值。四类数据源负责不同信息Prometheus API 给出指标名、类型、描述和标签Kubernetes API 给出资源及层级关系Trace分布式追踪数据给出服务调用链系统文档补充服务和 API 的语义。Neo4j图数据库存关系图Elasticsearch文本检索引擎存名称和描述并持续更新。问题解析先把一句话拆成两张“检索便签”LLM大语言模型先不生成查询而是把问题拆成两种中间结果。第一张便签是组件关系路径。例如“找出调用 ts-auth-service 的服务所运行 Pod 的 CPU 时间”会被写成(service: ts-auth-service) -requests-- (service: ?) --targets- (pod: ?)其中 ? 表示问题没有直接说出真实服务名和 Pod 名后续需要从系统图谱里查。第二张便签是指标-组件对例如“CPU timepod”。它告诉检索器要找的是 CPU 时间类指标而且指标要和 Pod 关联。代码中explore_path 调用 path_prompt 生成第一张便签get_metrics_description 调用 md_prompt 生成第二张便签。这样做的好处是把“找资源关系”和“找指标语义”分开避免一次检索同时处理两种不同证据。组件关系检索从模糊名字到真实路径这一步可以用“地图导航”来理解先对齐名字问句里的“ts-auth 服务”可能和系统里的真实名称略有不同。BM25基于词项相关度的检索排序算法在 Elasticsearch 中先找同类型实体的最相似名称。再沿关系走Neo4j 的 path_expand 从已对齐的实体出发按关系一跳一跳地找。? 不是让模型猜而是让图搜索枚举真实节点。保留多条候选路径如果一个服务有多个 Pod搜索会返回多条 Service → Pod → Node 路径而不是只保留一条。把路径交给后续模块这些真实路径会被转换成三元组和指标、标签一起放入最终 Prompt。论文 Fig. 8 的成功案例就是这个过程系统先找到调用 ts-auth-service 的 ts-gateway-service 和 ts-user-service再找到它们对应的 Pod最后把这些 Pod 与 container_cpu_usage_seconds_total 指标连接起来。这样模型拿到的是“当前系统真实关系”而不是凭常识猜测。指标与标签检索按组件类型筛选候选再用图谱两跳关系找 MetricBM25 排序后取 Top-10。组件相关标签沿 Metric → Label-Value Pair → Component 直接取得语义标签由 LLM 识别再由 BM25 对齐真实 label-value pair。查询生成get_promql 将指标信息、组件路径、指标连接路径和标签路径转成 triples再和原问题送入 promql_prompt。论文使用 CoT让模型先按步骤分析和固定 few-shot 示例约束输出格式这不同于 baseline 的历史问答 few-shot。实验数据集与开源数据集基于 TrainTicket6 个节点、96 个服务实例运行 7 天包含 209 个指标、2,489 个标签值对、140 个 API、77 个 Service、147 个 Pod、6 个 Node。280 条问题来自文档、教程、Stack Overflow 和 Alibaba Group 查询由研究人员设计并由工程师复核50 条历史样本230 条测试样本。代码与数据均开源FudanSELab/PromCopilot数据集说明在 README 的 PromCopilotDataSet。Baseline 与指标Basic Prompt 只使用 CoTFew-shot 检索 1/3/10 条历史问答PromCopilot 使用固定示例和当前图谱知识。MetricAcc指标集合完全正确。SyntaxAcc通过 Prometheus 语法检查。QueryAcc查询正确或属于人工确认的等价实现。结果、Finding 与实验边界RQ1整体效果。PromCopilot 在 GPT-4-Turbo 下达到 MetricAcc 91.3%、SyntaxAcc 96.1%、QueryAcc 69.1%说明结构化当前上下文显著提升了“真正正确”的查询比例但 69.1% 也说明仍有大量生成错误不能把它当成自动执行即可无误的系统。RQ2检索是否找对知识。指标检索 Recall 为 0.903reasoning path Recall 为 0.908组件路径的 Precision 较低说明系统倾向于多召回一些关系来减少漏检。这种取舍有利于最终生成但会增加 Prompt 长度和模型筛选负担。RQ3哪些模块贡献最大。去掉指标知识后 QueryAcc 从 69.1% 降到 27.8%去掉组件知识后降到 12.2%。因此两类知识都必要而动态组件关系对这类任务的影响更大。RQ4对工程师是否有用。8 位工程师使用 PromCopilot 的平均完成时间为 101.65 秒其他工具为 382.63 秒正确性评分 3.5实用性评分 3.75。它更像“带上下文的查询助手”而不是完全替代工程师的自动化运维系统。失败分析与后续改进。失败样本中查询生成错误 45 例占 59.21%指标知识检索错误 13 例组件关系路径抽取 6 例指标-组件对抽取 7 例组件知识检索 5 例。优先级应是先给最终生成增加 PromQL 专项能力再加入查询执行、错误回传、澄清问题和多候选输出。未覆盖的实验及其影响。论文没有在多个工业系统或多个 Kubernetes 集群上验证泛化因此不能确定换系统后仍保持 69.1%没有把“执行结果是否满足用户意图”作为独立自动指标因此 QueryAcc 可能低估语义等价、也可能高估表面正确用户研究只有 8 人、10 个任务结论更接近可用性信号而不是大规模统计结论没有做自动执行和二次修正闭环所以“发现错误后能否自动变好”仍未被实验验证。读后回顾动机与创新点作者要解决的不是单纯的 PromQL 语法生成而是动态系统上下文缺失。创新点有四个定义独立的 text-to-PromQL 任务和 benchmark用统一 schema 表示指标、标签、Kubernetes 资源和调用关系把问题解析拆成组件路径与指标-组件对组合 BM25、Neo4j 图搜索和 LLM。核心方法代码对照explore_pathpath_prompt → 元路径 → BM25 实体对齐 → Neo4j path_expand → reasoning paths。get_metrics_description问题 → 指标描述 组件类型。get_relevant_metricsElasticsearch scoped search Top-10 → metric_prompt 选指标。metrics_connectNeo4j metric_expand 连接指标和 Kubernetes 实体。get_lvp_pathslvp_prompt 识别标签语义 → BM25 找 label-value pair。get_promql所有路径转 triples → promql_prompt → 最终 PromQL。Prompt 分为五组path_prompt 约束实体关系md_prompt 抽取指标-组件对metric_prompt 筛选候选指标lvp_prompt 对齐标签语义promql_prompt 指导选择器、匹配、聚合和函数。论文方法侧重“知识图谱增强的协同推理”代码方法侧重“多个小 Prompt 串成可落日志的工程流水线”二者一一对应。性能贡献和实验相互印证组件知识消融后 QueryAcc 只剩 12.2%指标知识消融后降到 27.8%失败样本 59.21% 发生在最终生成说明当前核心瓶颈是 LLM 对标签、函数和计算逻辑的使用而不是完全没有检索到知识。工程参数为 Neo4j 5.14、Elasticsearch 8.11、Python 3.10、k10、m1、LLM 温度 0.3。优点是可解释、可逐阶段定位错误代价是依赖组件多且一次请求需多次 LLM 调用。实验分析RQ1 的结论结构化当前上下文比直接 Prompt 或历史 few-shot 更能提升 QueryAcc但 69.1% 仍不足以支持无人审核执行。RQ2 的结论指标和 reasoning path 的 Recall 都超过 0.90说明“找知识”总体有效Precision 较低说明 Prompt 中会混入无关关系。RQ3 的结论两类知识都不可缺少组件关系知识影响更大符合云原生资源动态变化的任务特征。RQ4 的结论工具明显缩短工程师完成查询的时间但用户研究规模小不能直接外推到所有运维团队。失败分析的结论下一步重点应是 PromQL 专项生成、执行反馈、澄清和多候选而不是简单增加历史样本。FindingPromCopilot 最有价值的部分不是“让 LLM 记住 PromQL”而是把当前系统上下文变成可检索、可组合、可解释的证据。组件关系图谱比单纯的指标文本检索更关键去掉它时 QueryAcc 只剩 12.2%。召回阶段已经相对可靠最终生成仍是主要错误源下一步应从 RAG 优化转向生成约束和执行闭环。论文的 69.1% 是基于 TrainTicket 和 230 条测试问题的结果不能直接当成其他工业系统的稳定成功率。下游任务与领域局限方法强绑定 Kubernetes、Prometheus 和 PromQL迁移到其他平台需要重做 schema、关系、Prompt 和检索逻辑。没有跨系统实验、自动执行反馈和大规模用户研究外部有效性仍有限。未来最值得补的是查询试运行、错误回传、自动修正、结果集合等价性和用户意图满足度评估。FAQQ1论文里的知识图谱大概长什么样有没有真实案例它不是抽象的“知识库”三个字而是一张由真实实体和关系组成的图。例如论文 Fig. 8 的成功案例中图谱里有 ts-auth-service、ts-gateway-service、ts-user-service 等 Servicets-gateway-service 和 ts-user-service 通过 requests 关系调用 ts-auth-service它们又通过 targets 关系连接到具体 Pod这些 Pod 再通过 container_cpu_usage_seconds_total 指标和对应的 pod 标签值连接起来。简化三元组如下ts-gateway-service --requests– ts-auth-servicets-gateway-service --targets– ts-gateway-service-… Podts-user-service --targets– ts-user-service-… Podcontainer_cpu_usage_seconds_total --has– podts-gateway-service-…podts-gateway-service-… --related_to– 对应 Pod这就是“多跳推理”先从被调用服务反向找到调用方再找到调用方的 Pod最后把 Pod 关系接到指标过滤条件。论文数据集包含 209 个指标、2,489 个标签值对、147 个 Pod 等真实快照数据。Q2为什么组件关系知识比指标知识更重要指标知识解决“查什么”组件知识解决“查谁”。数据集里有些指标来自公开 exporterLLM 可能凭预训练记忆猜对但服务当前部署到哪些 Pod、Pod 当前在哪个 Node通常只能从当前系统图谱得到。因此去掉组件知识后 QueryAcc 降到 12.2%下降幅度比去掉指标知识更大。参考资料论文PromCopilot代码与复现结果FudanSELab/PromCopilot数据集下载PromCopilotDataSetTrainTicketFudanSELab/train-ticketPrometheus官方文档