PromCopilot：用知识图谱和大模型把自然语言变成PromQL

做监控排障的时候谁没在PromQL上卡过壳我印象很深的一次线上告警说CPU负载异常我下意识想查一下最近5分钟各节点的CPU用量结果在container_cpu_usage_seconds_total、node_cpu_seconds_total、process_cpu_seconds_total三个指标之间犹豫了半天rate还是irate、要不要sum by (instance)、阈值怎么构造来回试了七八次才写出一条能看的查询。那时候就在想要是能直接用大白话问一句“最近5分钟CPU使用率超过90%的节点有哪些”系统自己就能把PromQL给我拼好该多省事。PromCopilot做的恰好就是这件事——用知识图谱和大模型把自然语言变成PromQL。这篇论文精读我会把它解决的问题、整体架构、关键设计思路、实际落地时会踩的坑以及这套思路能迁移到什么场景一次讲透。1. 一句话痛点写PromQL为什么总是卡壳1.1 PromQL的门槛远比看起来高很多人觉得PromQL不过是一种查询语法看一遍文档就能上手。真到用的时候才会发现它的难点不在语法本身而在你首先得知道“查什么指标”。Prometheus生态里的指标命名虽然有一定约定俗成但实际部署之后不同组件、不同exporter暴露出来的指标五花八门同样是CPU容器看container_cpu_*节点看node_cpu_*进程看process_cpu_*它们单位和语义还不完全一样选择的依据完全取决于你想观察哪个层级。更折磨人的是函数和操作符的组合。rate和irate什么场景用哪个窗口到底给[5m]还是[1m]才不显得突兀sum by和sum without方向搞反是经常的事histogram_quantile做分位数计算时还得留意le标签是否完整offset用于环比对比但配错了窗口会让数据整个错位。加上标签过滤的时候、~、!~三种匹配符一个用错就会把结果查空或者查偏。每次写完PromQL最稳妥的做法还是去Prometheus的Graph页面实际跑一遍看看曲线形状确认没有语法错、语义错。这个过程相当耗时所以我一直觉得PromQL真正难的地方是“经验门槛”——你得清楚整个监控体系里有哪些指标、它们怎么关联、什么场景该用哪个。1.2 为什么直接让大模型写PromQL会翻车大模型出来了之后很多人第一反应是“让ChatGPT帮我写PromQL”。试过几次的人应该都有类似体验简单的查询比如“查CPU使用率”大部分模型能生成一个看起来像模像样的表达式但稍微复杂一点就暴露出一堆问题。首当其冲的是幻觉指标名。模型非常自信地给出一个不存在的指标比如把node_cpu_seconds_total写成node_cpu_utilization前者是计数器后者在标准exporter里根本不存在。就算指标存在标签名也可能记错比如把device写成devices或者把标签值的大小写搞错。这种幻觉在中文描述场景里更严重因为指标名本质是英文模型需要在中文语义和英文指标之间做翻译性映射一旦对应错了生成出来的查询就是“形式上正确、语义上跑偏”。其次是“上下文缺失”。大模型没有你的监控拓扑信息不知道你的集群里有哪些服务、哪些节点、哪些自定义指标光靠通用知识很难揣测你的具体环境。我试过一次让模型写一个“查订单服务错误率”的PromQL它给出了一个基于http_requests_total的合理猜测但实际上我的环境里这个指标根本不叫这个名字真实指标是order_service_http_requests_total这类自带业务前缀的指标名是模型不可能凭空猜出来的。还有一个容易被忽略的问题就算生成了能跑的PromQL它不一定“语义正确”。语法正确只保证了rate()里有参数、sum by的标签正确但不保证这个查询逻辑是你要的。比如“CPU使用率”和“CPU用量”在语义上完全不一样前者是瞬时百分比后者是累计计数器算出来的速率如果模型没理解你的真正意图写出来的查询虽然能出图但图不对题。这种错误比语法错误更隐蔽也更难发现。所以单纯“甩给大模型”这条路走不通。PromCopilot的思路是与其让大模型自由发挥不如先把你的查询意图用领域知识约束住——这个约束就来自知识图谱。2. PromCopilot的核心思路知识图谱补的不是“知识”是上下文2.1 大模型缺的不是语言能力是指标体系的上下文如果我们认真拆解“自然语言转PromQL”这个任务会发现它其实包含两个子任务第一理解用户到底想问什么第二把这个意图映射到具体的指标、标签、操作符和查询结构上。第一个子任务大模型很擅长第二个子任务其实是个“查表”加“组合”的过程——而“表”恰恰是模型不掌握的。这个“表”就是你的监控指标体系。它包含哪些信息呢指标名node_cpu_seconds_total、指标类型counter/gauge/histogram、指标含义描述在exporter文档或代码注释里、标签集合instance、job、device、指标之间的派生关系node_cpu_seconds_total通过rate()变成CPU速率再通过avg by (instance)变成每实例平均速率、以及上层业务语义order_service_http_requests_total是订单服务的总请求数计数器。大模型训练时见过无数开源项目的指标名但每个公司、每个团队的监控体系都是高度定制化的。就算你把指标清单塞进Prompt里指标一多几百上千个Prompt就太长而且这些指标之间的复杂关系也不是一份清单能表达的。知识图谱解决的是这个问题把指标、标签、服务、告警规则之间的语义关系结构化让系统在生成查询时能“查”到这个上下文而不是靠模型“回忆”。2.2 知识图谱在链路里的具体作用那知识图谱具体帮了什么忙论文里的设计结合我自己做监控系统时的理解大致有四个作用实体消歧。用户说“CPU”图谱知道候选指标不止一个于是按领域排序节点级优先node_cpu_seconds_total容器级给container_cpu_usage_seconds_total进程级给process_cpu_seconds_total。用户说的“CPU”到底是哪个层级的可以通过句子里其他实体比如“节点”“Pod”“服务”来消歧。候选空间的锁定。大模型不需要凭空编造指标名了而是从图谱检索出来的候选集合里去选。比如用户说“查订单服务的错误率”图谱先定位order_service这个服务实体再关联它的_total类计数器指标再找到错误类型的标签值。候选集合小了幻觉自然大幅减少。查询模板的生成。图谱里存了指标之间常见的聚合关系比如“错误率 错误计数器的rate值除以总计数器的rate值”。有了这种模板知识生成PromQL就从“逐字构造表达式”简化成“填槽”——把用户约束的标签值、时间范围、目标服务填进模板。语义校验。生成的PromQL里如果用了node_cpu_seconds_total却过滤了device这种标签图谱能识别出这个指标根本没有device标签直接拦截掉。这种校验是纯语法解析器做不到的。一句话概括知识图谱相当于给大模型搭了一个“脚手架”模型的灵活性和图谱的确定性结合在一起才能生成稳定可用的PromQL。2.3 整体流水线从用户输入到查询执行的完整路径PromCopilot的架构拆开来看其实是一个多阶段流水线自然语言输入 → 意图识别 → 实体抽取 → 图谱查询与候选生成 → Prompt组装 → 大模型生成PromQL → 语法/语义校验 → 执行与结果解释第一步不急着直接生成PromQL而是先分析用户意图。用户说“查一下CPU使用率”和“解释一下为什么CPU使用率突然变高了”虽然都提到CPU但前者需要生成查询后者可能只需要围绕已有查询做分析解释。意图分类可以用一个轻量模型或者规则做把“要查询”“要解释”“要诊断”等场景区分开。第二步是实体抽取。从自然语言里识别出指标相关的实体和约束条件指标主题CPU、内存、网络、实体对象节点、Pod、服务名、时间范围最近5分钟、昨天、某时间段、阈值条件大于90%、聚合维度按节点、按服务。这一步可以用小模型做也可以用大模型配合Few-shot做关键是抽取结果的稳定性。第三步是关键——图谱查询。系统拿着实体去知识图谱里查候选指标和关系链。比如“订单服务”“错误”“最近5分钟”图谱里能查到的关系可能是order_service -[exposes]- order_service_http_requests_total -[has_label]- code500。这一步把大模型“自由选择”的负担先解决掉确定了答案的搜索范围。第四步才轮到大模型登场。把图谱查到的候选指标、标签、它们之间的关系、用户原始输入一起组装进Prompt让模型从中选择并组合成PromQL。因为候选集已经限制了范围模型即使发挥也是在有限的格子里发挥翻车概率大幅降低。最后一步是校验。用Prometheus的语法解析器做语法检查再用图谱里的元数据做语义检查比如指标是否存在、标签是否合法、用法是否合理counter类型不能直接取百分比等。检查通过才交给Prometheus执行否则让模型带着错误信息重写一轮。3. 关键设计拆解从自然语言到可执行PromQL的每一步3.1 意图识别和实体抽取怎么做到稳定我在第一部分提到意图识别和实体抽取是整个链路里“看起来容易做起来难”的环节这里展开讲。意图识别方面我先试过用Prompt让大模型直接分类当时用的思路是“给出几个类别让模型选”比如query、explain、diagnose模型一般都能分对但偶尔会把“为什么”开头的句子误分类成query导致该解释的时候先生成了查询。后来改用“意图槽位”的联合抽取效果好很多让模型不仅输出意图还输出抽取到的指标主题、对象、时间范围、阈值。这样即便意图分错了槽位信息也还能用于后续流程不至于完全白费。如果对稳定性要求极高可以考虑用一个五六万条样本训练的小分类模型做前置过滤大模型只处理分类置信度低的case不过这个方案成本高一些适合对准确率极其敏感的团队。实体抽取的核心问题是“指标名词典”怎么建。我一开始想省事直接用LLM抽取效果不稳定同一个“CPU”有时候抽成“cpu usage”有时候抽成“CPUUtilization”下游没法统一处理。后来改成两层第一层用匹配算法在指标词典和别名表里找候选比如“CPU”对应cpu_usage、cpu_utilization等多个别名第二层才用LLM从候选里选最合适的。这种“规则优先、模型兜底”的组合在工程上远比纯模型稳定。还有个细节值得留意时间描述的标准化。用户说“最近五分钟”和“过去5分钟”和“5分钟内”其实是同一个意思统一成5m的格式看起来简单但实际坐着很多边界情况比如“昨天下午两点到三点”这种绝对时间范围PromQL里需要转成[2024-01-15 14:00:00 0800, 2024-01-15 15:00:00 0800]这种格式中间需要一套时间解析规则。3.2 Prompt设计先框定候选再让模型组合Prompt设计是整个方案里投入产出比最高的部分值得仔细琢磨。核心思路是“先缩小范围再让模型选择”而不是“让模型开放生成”。我建议的Prompt结构大概是这样的你是监控系统查询助手。请根据以下候选指标信息生成PromQL查询语句。 用户请求最近5分钟各节点CPU使用率超过90%的节点 候选指标 - node_cpu_seconds_totalcounter标签instance, job, cpu, mode 用法rate(node_cpu_seconds_total[5m]) 可以得到CPU使用速率 - node_load1gauge标签instance, job 用法直接取值表示1分钟平均负载 安全约束 1. 只能使用候选指标中的指标名不得凭空编造指标名 2. 标签必须使用候选指标中出现的标签 3. counter类型指标必须配合rate/irate使用 请分两步 第一步写出你对用户请求的理解 第二步给出最终的PromQL表达式并简要解释每部分的作用。这个Prompt有意识地把任务的“搜索空间”限定死了。即使模型想编指标名也必须从候选里选编出来也不会通过后端的语义校验。我在实践中发现加上“先写理解再写表达式”这一步能显著降低跑偏概率——模型在输出表达式之前被迫做了一次推理很多明显的语义错会在这一步被发现。关于候选指标的排序逻辑图谱返回的顺序也很重要。不要只是简单地把所有候选都丢进去最好按“相关性”排个序优先放通过关系链路匹配上的指标再放靠关键词匹配的兜底指标。这样Prompt里前面的候选信息更可靠模型优先选它们的概率更大。3.3 生成后的校验不是跑通语法就完事很多人以为生成的PromQL只要PromQL语法解析器能过就万事大吉这是最大的误区。语法正确和语义正确之间差了十万八千里。我在系统里加了四层校验语法校验调用Prometheus的promql.ParseExpr()判断表达式能否解析。指标存在性校验解析表达式后提取所有指标名与知识图谱里的指标集合比对不存在的直接拒绝。标签合法性校验检查PromQL里用到的标签名是否在指标的标签集合里同时检查标签值是否符合规范。查询结构合理性校验检查counter类型指标是否用了rate/irate/increase这类函数histogram类型是否用了histogram_quantilegauge类型有没有被错误地套上rate。这一步用AST遍历可以做掉。这四层校验跑完生成的PromQL基本达到了“可执行”的标准但还没到“语义准确”的标准。语义准确这件事比较难自动化我现在的做法是在新生成的查询执行后把返回的曲线摘要比如“最近5分钟该指标平均值是42.6中位数38.2最大值77.1有3个节点超过90%阈值”反馈给用户让用户确认“这确实是我要的吗”。如果用户不满意可以进一步补充描述做二次生成。这个过程虽然多了一步交互但符合真实排障场景的节奏。4. 如果我要在本地复刻一个PromCopilot怎么做4.1 先理清楚并不是所有组件都非得用论文里的原方案论文里的系统结构是完整的但落到我们自己的环境完全可以根据资源情况做取舍。我梳理了一下真正不能缺的核心组件只有三块知识图谱本身、候选检索逻辑、生成后的校验。其余都可以做简化降级。比如知识图谱的存储不一定非得上Neo4j这类正统图数据库。如果你手上指标量不大几千个以内用关系型数据库加临时图计算也完全够用再小一点甚至一组JSON文件和内存里的邻接表就能跑起来。我在自己搭的时候用的就是Neo4j但后来发现大部分查询只是两跳以内的关系检索用关系型数据库做两次JOIN效果差不多成本还低。这个结论可能跟论文里的选型有差异但工程上“够用就好别过度设计”。大模型这一层也可以灵活替换。论文里可能用了功能较强的商用模型但实际在本地部署场景下用Qwen2.5-7B或者Llama3.1-8B这类开源模型配合上面说的“候选限定Prompt”也能达到八九不离十的效果。因为候选指标已经框死了模型的主要工作是“按模板组合”对推理能力的要求不算特别高。4.2 一个最小可行版本的实现路径如果你跟我一样想尽快跑通一个“自然语言→PromQL”的Demo我强烈建议按下面这个顺序做从简到繁每步都能验证成果第一步先把知识图谱的数据源搞定。从Prometheus的/api/v1/metadata接口拉取所有指标元数据从/api/v1/targets拉取target信息再手动维护一份“业务服务→指标”的映射关系表。这三份数据合并成基础知识图谱。一开始不用追求关系完整先把指标和标签建起来。第二步写一段实体抽取的规则代码。用正则加词典做粗粒度抽取识别出指标主题、服务名、时间范围、阈值这四个槽位。真实场景下这个简单的抽取器就能搞定60%以上的常见查询。第三步用LLM做候选组合。写一个Python脚本把用户输入、候选指标列表、关系链路拼进Prompt结构可以参考上面3.2的模板调用本地或API的LLM输出PromQL。加上语法校验和指标存在性校验能拦住大部分错误。第四步跑一个Web Demo。用Gradio或Streamlit包一个简单的界面输入自然语言显示生成的PromQL和对应的Prometheus曲线截图。这样就能非常直观地验证效果。这个流程的核心逻辑是“渐进式增强”——每一步的产出都可以独立验证不会出现那种“搭了一个月最后发现方向错了”的情况。4.3 复刻过程中最重要的一个词持续维护PromCopilot这类系统不是“搭好就能用”的它存在一个非常实际的问题——监控指标体系是动态的。新服务上线会新增指标改版可能删除旧指标标签重命名更是家常便饭。如果知识图谱不跟着更新系统就会给出过时的候选指标生成出来的PromQL在老指标上可能能跑但在新指标上就是个错误查询。所以我强烈建议把“知识图谱更新”也做成一个自动化流水线定期从Prometheus拉取元数据对比知识图谱里的差异自动新增指标、标记废弃指标、同步标签变化。这个更新频率不能太低我自己的经验是至少每天跑一次如果Prometheus配置变动频繁还得做成事件触发式更新。4.4 评测自己的系统先从生成成功率说起最后说说怎么评测“我复刻出来的PromCopilot效果到底行不行”。最直观的指标是“生成成功率”——我用N条测试查询让系统生成PromQL能通过语法校验和语义校验的比例就是成功率。但这里有个坑测试集本身的质量直接决定了结果的可信度。我建议测试集至少覆盖四类场景单指标查询“查CPU使用率”、带筛选条件的查询“查订单服务在过去1小时5xx错误数”、多指标关联查询“查每个节点的内存使用率并对比磁盘IO”、以及带聚合的查询“按集群汇总各服务请求总量”。每类至少准备十条标注好预期的PromQL人工确认过语义准确的。跑完之后除了看成功率还要重点看失败的案例分析失败是实体抽取的问题、图谱检索的问题还是模型生成的问题逐一修复。另外一个值得关注的指标是“首轮成功率”——也就是不经过校验再生成第一轮就生成正确结果的比例。这个指标直接反映Prompt设计和图谱质量的水平首轮成功率越高系统的真实体验越好。因为我前面提过虽然可以做多轮修正但每多一轮修正响应延迟和资源消耗都翻倍用户体感也会明显下降。5. 论文之外的讨论这套思路还能用在哪5.1 从PromQL到SQL、Kusto、SPL自然语言查询DSL的通用范式研究完PromCopilot后我最大的感受是它的核心范式可以迁移到很多“自然语言查询结构化数据”的场景。NLP to SQL是这几年已被大量探索的方向但把知识图谱、候选集约束、检索增强和生成模型结合起来的思路在很多其他地方还远没有铺开。比如日志查询场景Splunk的SPL和Elastic的KQL都有一个共同的痛点字段名多且杂用户根本记不住。理想状态下用户说“查最近一小时订单失败日志中错误信息出现次数最多的前10条”系统应从事件类型、日志来源、字段字典组成的知识图谱里锁定候选字段再让大模型生成一条规范查询。类似地云监控的复杂告警规则、业务指标平台的自助分析这些场景本质都是在做“把自然语言翻译成DSL”的任务都可以套用同一条技术路径。这个范式之所以通用是因为它抓住了“大模型做NLU强、做精确API调用弱”这个本质矛盾。任何查询DSL的生成任务最终都必须落到准确的名字上——准确的表名、字段名、指标名——而这些恰恰是从训练语料里学不来的只有从当前数据字典的知识库里查才拿得到。5.2 大概率会遇到的那些坑既然是实战派多聊几个坑比较有价值。第一个坑是“指标体系没有治理就去建图谱”。很多团队Prometheus里的指标命名混乱到令人发指同一个含义有三个不同写法http_request_total和http_requests_total并存标签有的用service_name有的用svc_name。这种数据建出来的知识图谱候选指标永远带噪声大模型再怎么选择也都是矮个子里拔高个。所以建议先花时间做一轮指标治理或者至少在知识图谱里补充“同义词”和“废弃标记”机制。第二个坑是“跳过了用户反馈闭环”。生成系统一定要记录“用户对结果满不满意”“用户有没有手动改写PromQL”。这些反馈是知识图谱优化最宝贵的语料。比如用户多次把“订单错误”改写成带code~5..的查询图谱里就可以给“错误”这个实体补充一条关联下次生成的时候直接带上这个模式。没有反馈闭环系统就永远停留在初始水平。第三个坑是“过度追求一次到位”。自然语言查询这种任务追求100%准确率不现实更合理的产品形态是“多轮交互结果预览”。第一轮生成一个大概可用的PromQL用户看图确认或补充条件第二轮修正。这种交互设计能让用户更信任系统也会慢慢积累行为数据反哺给模型。我自己在使用这类系统时的体会是它最大的价值不是“替代人写PromQL”而是“把写PromQL的门槛降低到让人愿意去尝试排查”。很多监控系统里的疑难故障往往卡在“不知道怎么查”这一步有了自然语言转查询的能力新手愿意去查了老手也能省掉查文档翻链路的时间。顺着PromCopilot的思路往下走我觉得下一步很快会在“告警根因分析”和“监控数据问答”这两个方向开花结果。等那些系统也成熟了监控排障的体验应该会彻底不一样。