zhuyongxin
de5a5b09d9
Archive pre-refactor interview notes and add current deep-dives on architecture evolution, issue-derived stories, and evidence gates.
2.4 KiB
2.4 KiB
AIOps 轻量规则验证器
1. 改动是什么
AIOps 现在有一个确定性的后置质量门禁。最终告警报告持久化后，AiOpsRuleEvaluationService 会检查：
- 最终报告是否存在，且不是明显过短。
- payload 模式下，报告是否提到输入的告警和服务。
- 是否有证据工具调用，例如
lookup_knowledge、query_metrics、query_logs。
结果写入：
diagnosis_session.self_evaluation.aiops_rule_evaluation
Trace API 会通过 session self-evaluation 展示这个结果。
2. 为什么先做规则型
这还不是完整 LLM Verifier。
AIOps 第一阶段质量风险比较具体，适合先用规则：
- 报告有没有生成。
- 报告有没有聚焦 payload。
- 有没有使用证据工具。
- 有没有把无关告警展开成主诊断对象。
规则验证稳定、便宜、容易解释，也不会在当前链路里额外引入一次隐藏模型调用。
3. 判定结果
当前评估器输出：
PASS
WARN
FAIL
含义：
PASS：核心检查通过。WARN：报告存在，但可能缺少 payload 关键词或证据工具。FAIL：缺少最终报告、报告过短等关键问题。
缺少 payload 关键词或证据工具先给 WARN，因为 demo/mock 环境下证据可能不可用，且报告措辞可能与 payload 字段不完全一致。
4. 面试回答
如果被问：为什么 AIOps 也需要验证器？
Chat 已经有 LLM Verifier，因为用户问题开放度高。
AIOps 的第一阶段质量风险更明确：报告是否聚焦输入告警、是否使用证据工具、报告是否完整。
所以我先做了轻量规则验证器，把结果写入 self_evaluation，让 Trace 不只展示 Agent 做了什么，也展示输出是否通过基础质量门。
如果被问：为什么不直接复用 Chat Verifier？
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。