# AIOps 轻量规则验证器

## 1. 改动是什么

AIOps 现在有一个确定性的后置质量门禁。最终告警报告持久化后，`AiOpsRuleEvaluationService` 会检查：

- 最终报告是否存在，且不是明显过短。
- payload 模式下，报告是否提到输入的告警和服务。
- 是否有证据工具调用，例如 `lookup_knowledge`、`query_metrics`、`query_logs`。

结果写入：

```text
diagnosis_session.self_evaluation.aiops_rule_evaluation
```

Trace API 会通过 session self-evaluation 展示这个结果。

## 2. 为什么先做规则型

这还不是完整 LLM Verifier。

AIOps 第一阶段质量风险比较具体，适合先用规则：

- 报告有没有生成。
- 报告有没有聚焦 payload。
- 有没有使用证据工具。
- 有没有把无关告警展开成主诊断对象。

规则验证稳定、便宜、容易解释，也不会在当前链路里额外引入一次隐藏模型调用。

## 3. 判定结果

当前评估器输出：

```text
PASS
WARN
FAIL
```

含义：

- `PASS`：核心检查通过。
- `WARN`：报告存在，但可能缺少 payload 关键词或证据工具。
- `FAIL`：缺少最终报告、报告过短等关键问题。

缺少 payload 关键词或证据工具先给 `WARN`，因为 demo/mock 环境下证据可能不可用，且报告措辞可能与 payload 字段不完全一致。

## 4. 面试回答

如果被问：为什么 AIOps 也需要验证器？

```text
Chat 已经有 LLM Verifier，因为用户问题开放度高。
AIOps 的第一阶段质量风险更明确：报告是否聚焦输入告警、是否使用证据工具、报告是否完整。
所以我先做了轻量规则验证器，把结果写入 self_evaluation，让 Trace 不只展示 Agent 做了什么，也展示输出是否通过基础质量门。
```

如果被问：为什么不直接复用 Chat Verifier？

```text
AIOps 验证语义和 Chat 不一样。
它要检查 alert scope、payload focus、证据工具覆盖，以及是否过度展开无关 active alerts。
直接复用 Chat Verifier 会混淆这些语义。
规则评估先提供稳定质量门，后续 AIOps LLM Verifier 可以基于同一套 trace contract 扩展。
```

## 5. 后续增强

- 引入 AIOps LLM Verifier，逐条校验根因和建议是否有 evidence refs。
- 把 rule evaluation 的 checks 在 Trace API 中结构化展示。
- 将 payload scope violation 沉淀为 bad case。