Flink 2.3 实时 AI 推理实战 —— 第 17 章 实战一：实时告警智能归因与分级
章节定位：第七篇开战。本章是前十六章能力的第一次总装——把 CREATE MODEL、ML_PREDICT、异步推理、降级兜底、双落地、监控评估、安全合规，拧成一条可直接上生产的告警智能归因链路。业务上解决 TSP 平台最痛的问题：告警洪峰淹没人工作业。你将看到完整的业务拆解、链路设计、Prompt 工程、解析校验、可靠性闭环与效果验证，所有代码可逐段复制运行。
版本基线：Apache Flink 2.3.0（JDK 17）+ Kafka 3.x + Paimon 1.4.x + Doris 4.1
章节导读
- 17.1 业务需求与目标拆解
- 17.2 链路设计
- 17.3 Prompt 设计：稳定 JSON 输出
- 17.4 结果解析与校验
- 17.5 可靠性设计：降级、限流、缓存与人工闭环
- 17.6 效果验证
- 17.7 全量实战代码
- 17.8 本章小结与下章预告
17.1 业务需求与目标拆解
17.1.1 痛点
TSP 平台告警现状(某车企真实画像脱敏): 日均告警 8~12 万条,峰值 200+/秒 人工值班 6 人三班倒,人均日处理 600+,只能处理 P0/P1 大量 P2/P3 告警无人看 → 小故障拖成大故障,客诉率上升17.1.2 目标：AI 归因四件套
| 输出 | 说明 | 示例 |
|---|---|---|
| 类别 label | 动力/电池/底盘/车身/电气/其他 | 电池 |
| 严重等级 severity | P0（立即处置）~P3（观察） | P1 |
| 根因 reason | 一句话根因归纳 | BMS 报单体压差超限，疑似 3 号模组老化 |
| 处置建议 suggestion | 可操作的处置动作 | 进站检测 3 号模组，必要时均衡充电 |
| 置信度 confidence | 0~1，低于阈值转人工 | 0.87 |
17.1.3 输入样例
{"event_id":"ALM20261010001","vin":"LFV3A28K9P3123456","collect_time":1791571200,"alert_code":"BMS_0412","alert_text":"动力电池单体电压差超限,当前压差187mV,阈值120mV,3号模组,车速62km/h,SOC 45%"}17.1.4 成功标准（先定义，后验收）
① P0/P1 召回率 ≥ 98%(漏报高危是红线) ② 整体分级准确率 ≥ 90%(对照人工标注) ③ 处置建议人工采纳率 ≥ 60% ④ 端到端 P99 ≤ 5s,成本 ≤ 预算(12.6 测算)17.2 链路设计
17.2.1 架构总览
┌──────────── 人工审核台 ────────────┐ │ 低置信/兜底告警 → 人工标注 │ └──────────────┬─────────────────────┘ │ 审核结果回流(标注样本) ▼ ┌────────┐ ┌─────────────────────────────────┐ ┌──────────┐ │ Kafka │─▶│ Flink 推理作业 │─▶│ Doris │ │ alert │ │ ①清洗过滤 ②缓存命中查询 │ │ 结果服务 │ └────────┘ │ ③ML_PREDICT(异步) ④JSON解析校验 │ │ UK+MoW │ │ ⑤失败降级(规则兜底) │ └──────────┘ └───────────────┬─────────────────┘ ├──────────────────▶ Paimon(审计/样本湖) └──────────────────▶ Kafka labeled(高置信回流)17.2.2 组件职责
| 组件 | 职责 | 关键约束 |
|---|---|---|
| Kafka alert | 告警源流 | group.id 配置化 + group-offsets |
| Flink 推理作业 | 归因主链路 | 异步推理、30s Checkpoint、无限重试 |
| Doris alert_attribution | 结果服务 | UK(event_id)+MoW+倒排索引 |
| Paimon alert_audit | 审计+样本湖 | 反引号显式列清单 |
| Kafka alert_labeled | 人工标注回流 | 喂在线评估（14.1.3 闭环校正） |
| 内网 LLM 网关 | 模型调用入口 | 密钥集中、审计、限流（16.2） |
17.2.3 为什么缓存前置
告警高度重复:同一 alert_code+相似文本占流量 60% 以上 → 先查缓存(按 alert_code+文本哈希),命中直接返回,零模型成本 → 未命中才调 ML_PREDICT,结果回填缓存 → 13.4 结果缓存的生产级落地17.3 Prompt 设计：稳定 JSON 输出
17.3.1 System Prompt 全文
你是车联网 TSP 平台的告警分析专家,拥有 10 年三电与整车故障诊断经验。 【任务】对车辆告警文本进行归因分析,输出严格 JSON。 【类别枚举】只允许:动力 | 电池 | 底盘 | 车身 | 电气 | 其他 【严重等级定义】 P0:涉及人身安全/起火风险/车辆失控,立即处置 P1:核心功能受损(动力受限/无法充电),当日处置 P2:功能降级可行驶,本周内处置 P3:提示类,观察即可 【输出契约】只输出 JSON,无任何其他文字: {"label":"...","severity":0|1|2|3,"reason":"50字内根因","suggestion":"100字内处置建议","confidence":0.0~1.0} 【约束】 - 信息不足时 confidence ≤ 0.5,不得编造具体模组号/故障件 - reason 必须基于告警文本中的证据,禁止推测文本未提及的部件 - severity 输出数字:0 表示 P0,依此类推17.3.2 少样本示例（user-prompt 前缀）
示例1: 输入:BMS_0412 动力电池单体电压差超限,压差187mV,阈值120mV,3号模组 输出:{"label":"电池","severity":1,"reason":"3号模组单体压差187mV超阈值120mV,一致性劣化","suggestion":"进站读取单体电压明细,必要时对3号模组均衡充电","confidence":0.87} 示例2: 输入:TPMS_002 右后轮胎压报警,当前1.6bar 输出:{"label":"底盘","severity":2,"reason":"右后轮胎压1.6bar低于标准值","suggestion":"提醒车主检查轮胎是否扎钉漏气,补充胎压至2.5bar","confidence":0.95}17.3.3 设计要点对照表
| 要点 | 本章做法 | 依据 |
|---|---|---|
| 标签封闭枚举 | 只允许 6 类，SQL 侧二次校验 | 6.5 约束输出 |
| 等级数字化 | severity 输出 0-3 而非 “P0” | 减少解析分歧，便于 SQL 过滤 |
| 置信度自评 | 信息不足强制 ≤0.5 | 为人工分流提供依据 |
| 防编造 | reason 必须基于文本证据 | 6.5 防幻觉 |
| 少样本 | 2 个典型示例锚定格式 | 少样本 > 长指令 |
17.4 结果解析与校验
17.4.1 解析 + 校验 SQL
CREATETEMPORARYVIEWalert_parsedASSELECTp.event_id,p.vin,p.collect_time,p.alert_code,p.alert_text,JSON_VALUE(r.result,'$.label')ASlabel,CAST(JSON_VALUE(r.result,'$.severity')ASTINYINT)ASseverity,JSON_VALUE(r.result,'$.reason')ASreason,JSON_VALUE(r.result,'$.suggestion')ASsuggestion,CAST(JSON_VALUE(r.result,'$.confidence')ASDOUBLE)ASconfidence,'qwen-plus-v2'ASmodel_ver,FALSEASdegradedFROMalert_filtered p,LATERALTABLE(ML_PREDICT(TABLEalert_filtered,MODEL alert_attr_v2,DESCRIPTOR(alert_text),CONFIG('async'='true','timeout'='30s')))rWHEREr.resultISNOTNULL;-- 超时/失败样本不进入本视图,走 17.5.1 降级17.4.2 四道输出校验
CREATETEMPORARYVIEWalert_validatedASSELECT*,CASEWHENlabelNOTIN('动力','电池','底盘','车身','电气','其他')THEN'BAD_LABEL'WHENseverityNOTIN(0,1,2,3)THEN'BAD_SEVERITY'WHENconfidenceISNULLORconfidence<0ORconfidence>1THEN'BAD_CONF'WHENreasonISNULLORLENGTH(reason)>100THEN'BAD_REASON'ELSE'OK'ENDAScheck_flagFROMalert_parsed;-- check_flag <> 'OK' → 走规则兜底并标记 degraded,样本入湖供 badcase 分析设计思想: 模型输出永远不可信,校验是最后一道防线(13.6 输出校验) 非法输出 ≠ 丢弃 → 降级通道接管,告警不丢是底线17.5 可靠性设计：降级、限流、缓存与人工闭环
17.5.1 超时降级：规则兜底
-- 推理失败/超时样本:按 alert_code 映射表给保守分级,保证告警可达CREATETEMPORARYVIEWalert_degradedASSELECTf.event_id,f.vin,f.collect_time,f.alert_code,f.alert_text,m.default_labelASlabel,m.default_severityASseverity,-- 映射表按码表给保守等级(就高不就低)'模型超时,规则兜底'ASreason,m.default_suggestionASsuggestion,0.0ASconfidence,'rule-fallback'ASmodel_ver,TRUEASdegradedFROMalert_timeout f-- ML_PREDICT 未返回的样本LEFTJOINalert_code_ruleFORSYSTEM_TIMEASOFf.proc_timeASmONf.alert_code=m.alert_code;-- 维表:码→保守分级(读 JDBC)兜底三原则: ① 告警不丢——再差的分级也比没有强 ② 就高不就低——拿不准的按高等级处理,宁可误报不可漏报 ③ degraded=true 打标——14.4 监控该指标,>5% 持续 10 分钟即 P1 告警17.5.2 限流与缓存
限流(12.4): 单 subtask 异步并发 32,超出自然反压 网关侧配额 429 → 退避重试,不穿透到主链路 缓存(13.4): key = alert_code + MD5(alert_text 归一化) 命中直接短路,实测命中率 62% → 成本与延迟双降17.5.3 人工审核闭环
分流规则: confidence < 0.6 或 degraded=true → 推人工审核台 confidence ≥ 0.6 → 直发下游 + 回流 labeled topic 人工审核结果 → Kafka alert_labeled: ① 在线评估样本(14.1):持续计算准确率,发现漂移 ② badcase 库:prompt 迭代与少样本更新的素材 ③ 采纳率统计(17.6):建议被改写的比例 闭环价值:模型不是上线即定型的,人工每天都在教它17.6 效果验证
17.6.1 四项指标口径
| 指标 | 口径 | 基线 |
|---|---|---|
| 分级准确率 | AI severity = 人工复核 severity 的比例 | ≥90% |
| P0/P1 召回率 | 人工判 P0/P1 中 AI 也判 P0/P1 的比例 | ≥98%（红线） |
| 误报率 | AI 判 P0/P1 但人工判更低级的比例 | ≤10% |
| 采纳率 | 处置建议被人工原样采纳的比例 | ≥60% |
17.6.2 验证 SQL（对照人工标注）
SELECTCOUNT(*)AStotal,AVG(CASEWHENa.severity=l.human_severityTHEN1.0ELSE0END)ASacc,AVG(CASEWHENl.human_severity<=1ANDa.severity<=1THEN1.0WHENl.human_severity<=1THEN0.0END)ASp01_recall,AVG(CASEWHENa.severity<=1ANDl.human_severity>1THEN1.0WHENa.severity<=1THEN0.0END)ASfalse_alarm,AVG(CASEWHENa.suggestion=l.human_suggestionTHEN1.0ELSE0END)ASadopt_rateFROMdoris_cat.tsp.alert_attribution aJOINkafka_labeled lONa.event_id=l.event_idWHEREa.degraded=FALSE;-- 只统计真实模型产出,兜底样本单列17.6.3 灰期观察重点
首周:误报率是最大风险——P0 误报会触发应急流程,消耗信任 → 灰度期 severity 0 的 AI 判定强制人工二次确认 两周:召回率稳定后放开 P0 自动流转 月度:按 alert_code 维度看准确率长尾,垫底码进 prompt 优化清单17.7 全量实战代码
17.7.1 端到端 SQL（节录主链路）
-- ① 模型注册(envsubst 注入,16.2)CREATEMODEL alert_attr_v2 INPUT(alert_text STRING)OUTPUT(result STRING)WITH('task'='chat_completions','type'='remote','provider'='openai','endpoint'='${LLM_GATEWAY}','model'='qwen-plus','api-key'='${LLM_API_KEY}','system-prompt'='<17.3.1 全文>');-- ② 主流:清洗 → 过滤 → (缓存旁路) → 推理 → 校验(17.4)-- ③ 双写:Doris 服务 + Paimon 审计(15.6 statement set)EXECUTESTATEMENTSETBEGININSERTINTOdoris_cat.tsp.alert_attribution(`event_id`,`vin`,`collect_time`,`alert_code`,`alert_text`,`label`,`severity`,`reason`,`suggestion`,`confidence`,`model_ver`,`degraded`,`proc_time`)SELECTevent_id,vin,FROM_UNIXTIME(collect_time),alert_code,alert_text,label,severity,reason,suggestion,confidence,model_ver,degraded,FROM_UNIXTIME(UNIX_TIMESTAMP())FROMalert_final;-- validated ∪ degraded 合并视图INSERTINTOpaimon_cat.tsp.alert_audit(`event_id`,`vin_hash`,`alert_text`,`result_json`,`model_ver`,`degraded`,`dt`)SELECTevent_id,SHA2(vin,256),alert_text,result_json,model_ver,degraded,DATE_FORMAT(proc_time,'yyyy-MM-dd')FROMalert_raw_with_result;END;17.7.2 提交与检查单
./bin/sql-client.sh-falert_attribution.sql\-Dpipeline.name="alert-attribution-v2"\-Dexecution.checkpointing.interval=30s\-Drestart-strategy=fixed-delay\-Drestart-strategy.fixed-delay.attempts=2147483647\-Drestart-strategy.fixed-delay.delay=10s\-Dtable.dml-sync=true上线检查单(本章版): □ P0/P1 召回率影子期实测 ≥ 98%(红线不过不上线) □ 降级通道实测:断网关 30s,degraded 打标,告警零丢失 □ 缓存命中率 ≥ 50%,未命中链路 P99 ≤ 5s □ 人工审核台已就绪,低置信分流规则生效 □ 四道输出校验拦截样本入湖,badcase 可回溯 □ 密钥走网关,审计表 VIN 已哈希17.8 本章小结与下章预告
本章小结
┌──────────────────────────────────────────────────────────────┐ │ 第 17 章 要点回顾 │ └──────────────────────────────────────────────────────────────┘ ✓ 业务:告警洪峰 8~12 万/日;四件套输出(类别/等级/根因/ 建议+置信度);成功标准先行(P0/P1 召回 98% 红线) ✓ 链路:缓存前置(62% 命中)→ 异步推理 → 四道校验 → Doris 服务 + Paimon 审计双写 + labeled 回流 ✓ Prompt:封闭枚举+等级数字化+置信度自评+证据约束+ 少样本锚格式 ✓ 可靠性:超时走码表规则兜底(就高不就低); 低置信+兜底样本进人工审核;审核结果反哺评估与 prompt ✓ 验证:准确率/召回/误报/采纳率四指标; 灰期 P0 强制人工二确,逐步放权 ✓ 核心心法:模型输出不可信,校验兜底是底线; 人工不是被替代,而是站在闭环里教模型下章预告
第 18 章 实战二：维修知识库 RAG 智能助手（终章）
系列终章——多源维修文档（手册/工单/故障码库）接入 → 清洗切分 → embedding 入湖 → Doris 向量索引；在线链路：故障描述 → embedding → VECTOR_SEARCH 召回 → 带引用答案生成；新工单实时自动生成处置建议；幻觉控制与知识权限；系列三条核心经验总结与 Flink Agents 展望。
官方参考资料
- Apache Flink 2.3 Documentation（首页，含 SQL / Table API 参考）
- Flink 2.1 发布公告（ML_PREDICT / Model DDL 能力介绍）
- Flink 2.2 发布公告（Table API 推理与 VECTOR_SEARCH 增强）
本章实战代码清单
序号 内容 说明 1 System Prompt 全文 + 少样本示例 17.3.1 / 17.3.2 2 解析视图 + 四道输出校验 SQL 17.4 3 码表规则降级兜底视图 SQL 17.5.1 4 四指标验证 SQL（对照人工标注） 17.6.2 5 端到端双写 statement set + 提交命令 17.7 6 本章版上线检查单 17.7.2
