zhuyongxin
de5a5b09d9
Archive pre-refactor interview notes and add current deep-dives on architecture evolution, issue-derived stories, and evidence gates.
75 lines
2.4 KiB
Markdown
75 lines
2.4 KiB
Markdown
# 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。
|
||
|