最近我在做监控运维智能化相关的研究读到一篇很有意思的论文讲的是怎么把自然语言直接变成 PromQL 查询语句。该项目把知识图谱和大模型结合起来做了一个叫 PromCopilot 的系统。说实话PromQL 这门查询语言在监控领域用得很多但真正能把它写好的人并不多。如果能够让一线运维人员直接用大白话问出“最近五分钟哪些节点的 CPU 使用率超过 80%”系统自动生成对应的查询语句这能省下大量学习和翻文档的时间。这篇论文的思路并不复杂但设计得很巧妙。核心就是不再让大模型“裸奔”着写 PromQL而是先通过知识图谱把监控指标、标签、业务语义组织成一张网再把这张网的相关片段喂给大模型当上下文让模型基于真实的指标体系去生成查询。整个过程解决了大模型容易编造不存在的指标名、写出来的 PromQL 语法对但执行不了的痛点。这篇文章适合运维工程师、可观测性平台开发者以及对大模型应用有兴趣的同学阅读我会把自己读论文时梳理的关键设计、实现细节和个人判断都写下来。1. 先聊聊为什么自然语言到 PromQL 这么难1.1 PromQL 本身是门“好写难精”的查询语言PromQL 是 Prometheus 的查询语言看起来语法不复杂只有选择器、函数、聚合操作符这么几类东西但真正用得顺手需要熟悉大量指标命名规则、标签设计习惯和监控模型。比如要查“CPU 使用率”你至少得知道指标名是node_cpu_seconds_total还是container_cpu_usage_seconds_total还得搞清楚mode标签怎么过滤rate()和irate()分别在什么场景下用。这些知识分散在指标文档、代码和运维经验里很难一次性写对。而且现实中的监控指标规模远超想象。一个中等规模的 Kubernetes 集群Prometheus 里可能就暴露着几万个时间序列指标名也有几百上千个。普通用户连有哪些指标都不一定知道更不要说知道每个指标对应的标签和含义。面向这样的指标体系自然语言转 PromQL 本质上是一个“在巨大候选空间里做受约束生成”的任务难度比传统 Text-to-SQL 高不少因为 PromQL 没有 SQL 那样的强 schema 约束指标命名的“自由度过高”。1.2 直接让大模型裸写 PromQL问题出在哪很多人第一反应是既然大模型这么强直接把自然语言丢给它让它生成 PromQL 不就行了我在实际测试中也试过类似方案最常见的失败模式有三种。第一是指标名幻觉模型会“一本正经”地编造出server_cpu_usage_rate这种看起来合理但实际不存在的指标名查询结果必然为空。第二是标签和聚合逻辑错误模型分不清sum by (instance)和sum without (instance)的区别或者把rate作用在已经是比率的指标上导致结果语义完全错误。第三是示例缺失导致生成不稳定同一个问法在不同上下文里可能生成完全不同的查询。这些问题的根源在于大模型对 PromQL 语法有很强的生成能力但它缺少对“当前这个 Prometheus 实例里到底有哪些指标”的感知。就像让一个文学功底很好的人写代码但完全不给他看需求文档里的字段定义他写得再流畅也容易跑偏。所以问题的关键不是模型能力而是上下文信息缺失。1.3 PromCopilot 给出的解题思路PromCopilot 的核心洞察很有启发性它把“通用语言知识”和“本地监控知识”做了显式拆分。大模型负责它擅长的自然语言理解和查询生成知识图谱则负责提供本地、具体、精确的指标上下文。两个模块协同工作而不是让大模型承担所有事情。具体来说整个系统会先把自然语言问题解析出意图然后去知识图谱里检索相关的指标、标签和查询模式把检索结果当作上下文拼进提示词再交给大模型生成 PromQL最后用语法检查器和执行反馈做验证与修正。这套“检索增强生成”的思路本质上就是 RAG 在时序监控领域的落地应用只是检索的对象从普通文档换成了精心设计的知识图谱。2. 架构拆解知识图谱和大模型如何分工2.1 整体的处理链路这篇论文给出的系统框架我梳理了一下大致是五个环节。先看输入用户用自然语言提出查询比如“查一下线上订单服务过去 1 小时的请求错误率趋势”。第一步是意图理解把问题里的时间范围、聚合粒度、过滤条件、业务对象解析出来。第二步是知识图谱检索系统把这个意图转化成图谱查询找出最可能相关的指标实体。第三步是生成候选查询大模型拿到“用户问题 图谱上下文 少量示例”后生成 PromQL。第四步是校验用 Prometheus 的语法解析器检查生成的语句是否合法同时检查其中的指标名和标签是否真的存在于目标实例。最后一步是执行或反馈如果一切正常就返回结果如果校验不通过就把错误信息反馈给模型进行修正。整条链路用的是行业里常说的“多层漏斗”思路每一层都在把错误的可能性往外筛。2.2 知识图谱在整个链路里的定位知识图谱在这里承担的是“领域知识底座”的角色。没有它大模型就只能靠训练时形成的泛化知识猜指标名有了它系统能精确知道当前环境里有哪些监控指标、每个指标的标签集合、指标之间的派生关系以及业务概念和指标的对应关系。我理解这里的知识图谱本质上是一个“监控指标的语义网”。它把http_request_duration_seconds_bucket、http_request_total这类指标节点通过derived_from、related_to、belongs_to_service等关系连接在一起同时把“响应时间”“延迟”“RT”这类自然语言表达通过别名边挂到对应指标上。这样当用户说“延迟高”的时候图谱能告诉大模型用户其实在说http_request_duration_seconds这个指标而且通常后面要跟histogram_quantile()聚合函数。2.3 大模型在整个链路里的定位大模型在这套架构里的定位非常清晰它是一个“语言到查询的翻译器”而不是“知识库”。它不需要知道指标叫什么因为它可以从上下文里拿到准确名称它只需要理解自然语言的语义知道如何把“过去 5 分钟”“平均”“按实例分组”这些表达映射成 PromQL 的语法元素。这种分工我觉得是论文里最有价值的工程判断。大模型的知识有截止日期而监控指标体系是实时变化的。今天新增的指标、改名的指标、废弃的标签大模型不可能及时知道但知识图谱可以通过自动同步机制保持最新。把变化的、精确的知识交给图谱把不变的、通用的语言能力交给大模型这个解耦思路在真实系统里非常重要。3. 知识图谱构建把监控指标梳理成“语义地图”3.1 指标实体的建模方式知识图谱构建的第一步是定义节点类型。论文里的设计以监控指标为核心实体类型大致包括Metric、Label、Service、Tag、Alias和QueryPattern。其中Metric是基础代表一个指标名如container_memory_working_set_bytesLabel代表这个指标上的标签键如pod、namespace、containerService代表业务服务如“订单服务”“支付服务”Alias代表自然语言的说法比如“内存占用”“内存使用率”。节点之间通过边连接比如Metric -has_label- Label、Metric -belongs_to_service- Service、Metric -has_alias- Alias。这个建模方式不算特别新颖但胜在实用。它没有去做复杂的本体推理而是把查询 PromQL 真正需要的最小信息集合结构化。我自己的理解是这里最关键的是“用户语言”和“监控指标”之间的映射层没有这个映射层后面的自然语言检索就无从谈起。3.2 标签、别名和层级关系构建图谱时最花功夫的是收集和整理。指标名可以从 Prometheus 的/api/v1/metadata接口自动拉取但映射关系和业务归属通常需要人工整理。论文里提到的做法是从已有的监控规则、告警规则、Dashboard JSON 文件和运维文档中抽取出关系再结合人工审核。这里有个非常值得注意的细节一个指标往往需要多个自然语言别名。比如http_request_duration_seconds有人叫它“请求延迟”有人叫“响应时间”有人叫“RT”还有人直接说“卡不卡”。这些表达都要挂在同一个指标上。同时还要区分“指标”和“指标用法”比如同一个指标查“当前值”用http_requests_total直接看 counter查“速率”就得包rate()查“分位数”就得配合histogram_quantile()。这些常用“套路”也要在图谱里以QueryPattern的形式存下来。3.3 从自然语言到候选指标的检索逻辑图谱建好之后关键问题是怎么检索。用户输入自然语言后系统需要先做实体识别和意图解析把问题里的名词和动词抽取出来。比如“订单服务过去一小时请求错误率”可以抽取出业务对象“订单服务”、时间范围“过去一小时”、查询目标“错误率”。然后基于抽取结果去图谱里匹配Alias节点和Service节点再顺着边把候选指标捞出来。这里可以用多种检索策略的组合比如基于向量相似度的语义检索也可以基于图谱结构做图遍历比如从“订单服务”节点出发找到它关联的所有指标再按照“错误率”这个表达的相似度排序。论文的实验里候选召回准确率对最终查询生成的影响非常大如果 Top-5 候选指标里没有正确答案大模型再怎么生成也没用。所以知识图谱这部分不是一个“锦上添花”的模块而是整个系统的地基。4. 大模型的提示词设计与生成机制4.1 候选指标如何进入提示词知识图谱检索出来的候选指标不会全部塞给大模型论文里的做法是取 Top-K 个最相关的指标每个指标配上它的标签、别名和一句简短注释然后转成结构化的文本块。比如metric: http_request_duration_seconds_bucket labels: service, instance, le alias: 请求延迟, 响应时间, RT usage: 配合 histogram_quantile 计算分位数然后把这些文本块和用户问题、系统指令拼在一起。这里对提示词的格式要求比较高因为如果指标描述太冗长模型容易被噪音干扰如果太简短模型又不知道该怎么用。论文里的格式借鉴了表格化描述的思路让每个指标的知识区块结构一致模型可以快速定位到需要的信息。我自己尝试过类似做法实践中发现一个经验把候选指标放在用户问题之前、系统指令之后的效果最好。如果把指标列表放在最后模型可能已经开始了错误的预测生成的查询路径很难被后续信息纠正。这也符合大模型注意力机制的特点离生成位置最近、且在指令明确之后的内容对生成的影响权重最大。4.2 示例选择与输出约束提示词里还需要放少量示例。论文里用的是“动态示例选择”策略从经过验证的问题、PromQL对中选择和当前问题最相似的两三个案例放进提示词。这个思路和 Few-shot 学习是一致的但示例的质量比数量更重要。在输出约束上论文要求模型只输出一条完整的 PromQL并且明确声明“不要做任何解释”。这是为了避免模型在输出里夹杂自然语言导致解析失败。同时会限制模型只能使用提示词中出现的指标名从源头防止指标名幻觉。这一招很有效我也在别的文本生成任务里验证过限制输出范围比事后纠错成本低得多。4.3 校验、纠错与多轮生成生成完成不代表流程结束。PromCopilot 设计了“校验-反馈-再生成”的闭环。第一层是语法校验直接把生成的 PromQL 丢给 Prometheus 的 parser能解析过去就说语法没问题。第二层是语义校验检查指标名是否在候选池或真实 metadata 里标签名是否存在于指标上函数参数类型是否匹配。第三层是执行校验如果真的有一个可查询的 Prometheus 实例可以把生成的查询执行一下看是否返回正常数据。任何一层失败都会生成一条具体的错误信息比如“未知标签 envx可选标签为 service, instance”然后回传给大模型让它修正。这个机制在论文里被称作“多轮修正”我实测下来是提升准确率最直接的手段。第一次生成的准确率通常只有六到七成但经过一轮修正后能到九成以上这个提升非常明显。5. 论文评估结果怎么看5.1 评测指标论文对系统效果的评估不是只看“生成结果能不能跑”而是拆成了几个维度。第一是查询语法正确率超过这个基本才能谈别的。第二是指标名准确率看系统生成的查询里使用的指标是否与人工标注答案一致。第三是查询语义等价率也就是生成的 PromQL 和标准答案虽然写法不同但执行结果在误差范围内一致。这个“语义等价”指标我觉得特别关键因为 PromQL 的写法很灵活sum(rate(x[5m]))和sum(increase(x[5m])) / 300在某些场景下语义相近单看文本相似度会误判。用执行结果来评价生成质量是这个领域目前比较公允的做法背后有一整套测试数据和结果对比的功夫。5.2 对比基线和关键结论基线方面论文对比了几种方案包括直接用大模型生成但不提供任何图上下文、只提供指标列表但不提供结构关系、以及完整的 PromCopilot 链路。结果显示完整方案在各项指标上都明显领先。尤其是“不提供任何上下文”的裸模型即使是大参数量的模型编造指标名的概率也非常高说明单靠模型参数里的通用知识根本扛不住监控场景的精确性要求。这个结论和业界很多大模型应用的经验是一致的垂域任务里模型能力固然重要但上下文工程往往决定成败。监控领域如此其他强 schema、强事实约束的场景也是如此。论文还做了用户实验让有经验的运维工程师和相对刚入门的人分别使用系统结果都提升了效率但初学者的提升更明显因为系统帮他们补上了“不知道有哪些指标”这块短板。5.3 数据集的局限不过这篇论文的实验数据集规模不大覆盖的场景也相对集中。我注意到的局限有三个。第一指标集来自单一环境或有限环境通用性还有待验证换一个指标命名风格完全不同的系统知识图谱就要重新构建。第二测试问题大多围绕常见的监控查询意图对极端复杂查询比如多级子查询、基于时间偏移的比较查询涉及较少。第三知识图谱的构建和更新维护成本没有深入讨论而这恰恰是实际落地时最头疼的问题。6. 落地的三条路和常见问题6.1 直接抄作业的两种用法如果想把 PromCopilot 的思路用在自己环境里有两种路径。一种是轻量版不建完整知识图谱先把 Prometheus 的指标 metadata 拉出来加上一份指标常见别名映射表存成 JSON 或 SQLite查询时做个简单的文本匹配和向量检索把候选指标拼进提示词再走“生成-校验-修正”的闭环。这个版本两天就能搭出来适合验证效果。另一种是完整版把知识图谱当成基础设施来建设用图数据库存指标和关系的完整语义网配置自动同步任务定期从 Prometheus API、告警规则和 Dashboard 里抽取更新同时建立操作日志回流机制把人工确认过的正确查询对沉淀成语料反过来优化提示词示例。这个版本适合生产环境能长期持续发挥作用。6.2 生产环境落地常见的四类问题和实操细节第一类问题是图谱更新滞后。Prometheus 的指标每天都在变化如果知识图谱不同步检索出来的候选指标可能已经废弃。建议把同步做成定时任务并针对重点指标配置人工审核流。第二类问题是多集群多环境支持。不同集群的指标命名和标签习惯可能完全不同知识图谱需要按环境分区否则检索结果会互相干扰。第三类问题是成本和延迟。大模型生成需要时间和 token 预算如果查询场景对实时性要求高可以考虑用小模型加强提示词的方式或者增加结果缓存层。第四类问题是权限和安全。监控查询往往涉及业务敏感数据生成的 PromQL 里的标签过滤可能需要遵循权限边界建议在最终执行前加一层授权校验。6.3 成本估算参考成本主要来自大模型 API 调用和知识图谱存储。假设每天有 1000 次查询每次触发生成加一次修正平均消耗约 3000 token那么每天大约 300 万 token按主流模型的价格折算每天的成本在百元左右。如果换成开源小模型私有化部署推理成本能明显下降但要牺牲一部分生成质量。知识图谱存储方面一个中等规模的监控体系指标几千个关系几万条用图数据库存很便宜主要成本还是在人的精力上——图谱的初始构建和维护才是真正的大头。7. 一些启发和扩展7.1 知识图谱与 LLM 的结合之道这篇论文给我最大的启发不是 PromQL 本身而是它与“图谱 大模型”这套组合方法论。在垂直领域大模型的价值不在于“什么都知道”而在于“给足上下文后什么都能写”。知识图谱恰好是构造高质量上下文的最佳载体之一因为它把零散的指标文档、告警规则、业务命名组织成了机器可读、模型可用的结构化知识。现在很多人一说大模型应用就想着微调其实对于变化频繁、领域性强、但规模可枚举的知识检索增强通常比微调更划算。领域知识在不断变化时微调就像把新知识烧进模型参数里每次更新都要重新训练而图谱方案只需要改几行数据。这在监控这种“每天都有新指标”的场景里优势是压倒性的。7.2 这套思路还能用在哪些场景顺着这个思路能做的事情远不止 PromQL。SQL 查询生成同样适用尤其当数据库表多、命名不规范、团队对字段不熟悉时把表结构、字段注释、常用查询模板放进知识图谱再让大模型做 Text-to-SQL效果会明显优于直接生成。告警归因分析也是一个方向把监控指标、日志关键词、变更事件的关系建图大模型可以结合图谱路径解释故障根因。还有运维知识问答、报表自动生成、甚至安全事件分析都是“自然语言 - 领域查询语言/动作”的同一类问题底层方法论是通用的。7.3 未来可能的演进方向论文里没有细说的地方也是我觉得最有潜力的方向。一个是图谱的自学习能力能不能从用户每一次成功或不成功的查询中自动抽取新的别名、修正错误关系让图谱越用越准。另一个是多模态监控知识的融合比如把大盘图表的可视化配置、告警模板文本也纳入图谱。还有 RAG 与 Agent 的结合让系统不仅生成查询还能自主执行、对比结果、解释异常变成一个真正的“监控助手”。我读这篇论文时感受最深的一点是再强大模型言语生成的结构化查询方案也不能完全脱离领域的“锚”。PromCopilot 用知识图谱把大模型的想象框在了现实指标体系中这种约束不是限制而是护航。它让大模型从“发挥创造力”变为“在真实边界内做最优选择”这才是技术落地的正确姿势。如果未来监控平台能把这种“语义理解 指标检索 自动生成”的交互方式做成标准能力运维工程师的工作方式一定会被重新定义。
