# 关键设计取舍

## 1. 为什么先做 Trace，而不是只返回答案

普通 Chatbot 只关注最终回答，但故障诊断更需要可审计性。一次诊断至少要回答：

- 结论是什么。
- 证据来自哪里。
- 哪些步骤由哪个 Agent 完成。
- 如果答案不可靠，系统怎么降级。

因此项目把一次会话拆成：

- `diagnosis_session`：会话摘要、最终答案、自评估、用户反馈。
- `agent_step`：模型输入输出、耗时、token 和工具调用标记。
- `tool_invocation`：真实工具调用参数、输出预览、成功状态和检索元数据。

代价是实现复杂度上升，收益是可回放、可调试、可演示。

## 2. 为什么 RAG 不直接隐藏在 Advisor 里

Spring AI Advisor 可以让 RAG 更隐式，但本项目的核心是 Agent 证据链。`lookup_knowledge` 必须作为显式工具调用出现，这样 Trace 里才能看到：

- Agent 什么时候决定检索。
- 用了什么 query。
- 命中了哪些文档。
- 相关性等级是什么。
- 证据如何支撑最终答案。

所以当前设计是：

```text
Executor -> lookup_knowledge -> VectorSearchService -> VectorStore / SDK fallback
```

这牺牲了一点框架自动化，但保留了可审计性。

## 3. 为什么 L0 只做 hint，不直接返回

旧版 L0 关键词唯一命中时可能直接跳过 L1。这个策略速度快，但风险是：关键词子串命中不等于最终语义相关。

当前改成：

```text
L0 = domain/entity hint
L1 = semantic retrieval
postprocess = evidence shaping + trace
```

L0 仍然有价值：错误码、服务名、告警名、指标名都很适合做精确 hint。但最终证据仍需要 L1 和后处理支撑。

## 4. 为什么保留 Milvus SDK fallback

Spring AI VectorStore 是当前读路径主方向，但 SDK fallback 没有删除，原因有三点：

- 迁移安全：旧 SDK 路径已经被验证过。
- 运行韧性：VectorStore 配置、schema、collection 出问题时可以回退。
- 面试稳定：检索抽象迁移不应该破坏主 demo。

这不是“没有迁完”，而是分阶段迁移：先稳定读路径，再决定是否迁移写入和索引。

## 5. 为什么 Chat 有 Verifier，AIOps 先用规则评估

Chat 问题更开放，容易出现跨领域推理，所以需要 LLM Verifier 做 groundedness 校验。

AIOps 当前优先解决更具体的问题：

- 最终报告是否存在。
- payload 模式是否聚焦输入告警。
- 是否使用了证据工具。
- 是否把无关活跃告警展开成主根因。

这些用规则就能稳定检查。后续可以在同一个 `self_evaluation` 容器下增加 AIOps LLM Verifier。

## 6. 为什么 AIOps payload scope 先用 Prompt + Rule

真实告警环境里可能同时有多个 active alerts。用户传入 `HighCPUUsage/payment-service` 时，Agent 如果把所有告警都展开分析，报告会跑偏。

当前选择：

- Prompt 中加入 `PAYLOAD_TARGETED`。
- 从 payload 生成 recommended `lookup_knowledge` query。
- 用 `AiOpsRuleEvaluationService` 检查报告是否聚焦输入告警。

没有先做硬过滤，是因为有些相关告警可以作为风险背景。目标不是屏蔽上下文，而是控制主诊断对象。

## 7. 为什么反馈不改 status

`status` 表示执行状态，`feedback` 表示用户评价。一个执行成功但用户觉得没用的诊断，应该是：

```text
status = SUCCESS
feedback = not_useful
```

这样才能区分系统异常和质量问题。`useful` 反馈会沉淀 `case_library`，`not_useful` 作为 bad case 信号保留。

## 8. 可以主动承认的限制

- AIOps 还没有完整 LLM Verifier。
- RAG 还没有 hybrid search、rerank、邻居 chunk 扩展。
- `case_library` 的 rootCause/solution 仍需要结构化抽取。
- `tool_invocation.step_id` 关联还可以更严格。
- `mvp-demo` profile 使用 mock 日志和指标，主要服务稳定面试演示。

主动讲清这些限制，能体现工程判断：先把可追踪闭环打通，再逐步增强质量门和生产可靠性。