4.0 KiB
关键设计取舍
1. 为什么先做 Trace，而不是只返回答案
普通 Chatbot 只关注最终回答，但故障诊断更需要可审计性。一次诊断至少要回答：
- 结论是什么。
- 证据来自哪里。
- 哪些步骤由哪个 Agent 完成。
- 如果答案不可靠，系统怎么降级。
因此项目把一次会话拆成：
diagnosis_session：会话摘要、最终答案、自评估、用户反馈。agent_step：模型输入输出、耗时、token 和工具调用标记。tool_invocation：真实工具调用参数、输出预览、成功状态和检索元数据。
代价是实现复杂度上升，收益是可回放、可调试、可演示。
2. 为什么 RAG 不直接隐藏在 Advisor 里
Spring AI Advisor 可以让 RAG 更隐式，但本项目的核心是 Agent 证据链。lookup_knowledge 必须作为显式工具调用出现，这样 Trace 里才能看到：
- Agent 什么时候决定检索。
- 用了什么 query。
- 命中了哪些文档。
- 相关性等级是什么。
- 证据如何支撑最终答案。
所以当前设计是：
Executor -> lookup_knowledge -> VectorSearchService -> VectorStore / SDK fallback
这牺牲了一点框架自动化，但保留了可审计性。
3. 为什么 L0 只做 hint，不直接返回
旧版 L0 关键词唯一命中时可能直接跳过 L1。这个策略速度快，但风险是：关键词子串命中不等于最终语义相关。
当前改成：
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_knowledgequery。 - 用
AiOpsRuleEvaluationService检查报告是否聚焦输入告警。
没有先做硬过滤，是因为有些相关告警可以作为风险背景。目标不是屏蔽上下文，而是控制主诊断对象。
7. 为什么反馈不改 status
status 表示执行状态，feedback 表示用户评价。一个执行成功但用户觉得没用的诊断，应该是：
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-demoprofile 使用 mock 日志和指标，主要服务稳定面试演示。
主动讲清这些限制，能体现工程判断：先把可追踪闭环打通，再逐步增强质量门和生产可靠性。