zhuyongxin
de5a5b09d9
Archive pre-refactor interview notes and add current deep-dives on architecture evolution, issue-derived stories, and evidence gates.
108 lines
4.0 KiB
Markdown
108 lines
4.0 KiB
Markdown
# 关键设计取舍
|
||
|
||
## 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 日志和指标，主要服务稳定面试演示。
|
||
|
||
主动讲清这些限制，能体现工程判断：先把可追踪闭环打通，再逐步增强质量门和生产可靠性。
|
||
|