docs: reorganize MVP interview documentation

2026-07-05 15:29:28 +08:00
parent b22f2d22c8
commit 88e0a6c944
51 changed files with 4352 additions and 1318 deletions
@@ -0,0 +1,225 @@
+# 面试故事案例
+
+**用途**：把项目能力讲成可被面试官理解的工程故事  
+**使用方式**：按问题选择一个故事，不需要从头到尾背诵
+
+## 故事 1：从黑盒 Chatbot 到可追踪 Agent
+
+### 面试官问题
+
+```text
+这个项目和普通调用大模型有什么区别？
+```
+
+### 30 秒回答
+
+```text
+普通 Chatbot 只给最终答案，出了问题很难解释答案怎么来的。
+我这个项目把诊断过程拆成 Planner、Executor、Verifier，并把每个 Agent 步骤和每次工具调用落库。
+最后通过 Trace API 可以回放：模型怎么规划、调用了哪些工具、工具返回了什么证据、Verifier 怎么判断答案可信。
+```
+
+### 展开讲法
+
+一开始最容易做的是：用户问题进来，直接让模型回答。但故障诊断场景不能只看答案，因为答案可能看起来合理却没有证据支撑。
+
+所以我把系统拆成三层：
+
+- `diagnosis_session` 记录一次诊断的主状态和最终答案。
+- `agent_step` 记录 Planner、Executor、Verifier 的模型调用。
+- `tool_invocation` 记录知识库、日志、指标等真实工具证据。
+
+这样就能做到：答案不是孤立文本，而是一条可审计的执行链。
+
+### 可展示文件
+
+- `mvp/architecture/interview-one-pager.md`
+- `mvp/architecture/session-trace-lifecycle.md`
+- `mvp/demo/output/trace-response.json`
+
+### 主动说不足
+
+```text
+当前 tool_invocation.step_id 还不是每次都强绑定具体 agent_step，后续可以加 runId 和更严格的 step 关联，让多轮同 session 诊断更清晰。
+```
+
+## 故事 2：RAG 从自研 SDK 检索迁移到 Spring AI VectorStore
+
+### 面试官问题
+
+```text
+你的 RAG 是怎么设计的？为什么不用框架全包？
+```
+
+### 30 秒回答
+
+```text
+我把 RAG 分成两部分：通用检索基础设施尽量交给 Spring AI VectorStore，业务可观测链路留在项目里。
+所以 Agent 仍然显式调用 lookup_knowledge，底层通过 VectorSearchService 走 Spring AI VectorStore，失败时 fallback 到原 Milvus SDK。
+这样既能减少自研检索代码，又不会丢失工具调用 trace。
+```
+
+### 展开讲法
+
+旧实现里，Milvus SDK 查询、topK、filter、score 映射都在业务代码里。它能跑，但后续扩展成本高。
+
+我没有直接把 RAG 隐藏进 Advisor，因为这个项目的核心是 Agent 工程，需要知道 Agent 何时检索、检索了什么、证据怎么支撑诊断。
+
+于是我保留了边界：
+
+```text
+Executor -> lookup_knowledge -> VectorSearchService -> VectorStore / SDK fallback
+```
+
+同时把 L0 从“直接返回结果”降级为 domain/entity hint，降低关键词误召回的风险。
+
+### 可展示文件
+
+- `mvp/architecture/rag-architecture.md`
+- `mvp/architecture/retrieval-observability.md`
+- `interview/rag-refactor-story.md`
+
+### 主动说不足
+
+```text
+当前还没有完整 hybrid search 和 rerank。
+我先做 golden cases、VectorStore 主路径和 SDK fallback，是为了让每一步迁移都能被验证。
+```
+
+## 故事 3：Verifier 如何降低幻觉风险
+
+### 面试官问题
+
+```text
+Agent 怎么保证不胡说？
+```
+
+### 30 秒回答
+
+```text
+我没有假设模型天然可靠，而是加了 Verifier。
+Executor 给出答案后，Verifier 只拿 executor_final_answer 和 tool_trace_summary，不允许做新检索。
+它把答案里的关键事实逐条校验，输出 PASS、LOW_CONFID 或 REJECT。
+这个结果会写回 self_evaluation，Trace API 可以看到。
+```
+
+### 展开讲法
+
+Verifier 的关键不是再问一次模型“你觉得对吗”，而是让它基于真实工具调用做 groundedness 检查。
+
+`ToolTraceSummaryService` 会从 `tool_invocation` 里整理证据索引，包含：
+
+- 工具名。
+- 输入摘要。
+- 输出摘要。
+- evidence level。
+- source invocation ids。
+
+Verifier 输出结构化 JSON，ChatService 根据 verdict 决定是否输出、补证据或降级。
+
+### 可展示文件
+
+- `mvp/architecture/harness-quality-gates.md`
+- `mvp/architecture/feedback-architecture.md`
+- `src/main/resources/prompts/chat-verifier-prompt.md`
+
+### 主动说不足
+
+```text
+AIOps 当前还是轻量 rule evaluation，不是完整 LLM Verifier。
+这是有意收敛：先用规则保证 payload 聚焦和工具证据使用，后续再加 AIOps LLM Verifier。
+```
+
+## 故事 4：AIOps 告警为什么要做 payload scope control
+
+### 面试官问题
+
+```text
+AIOps 场景和普通 Chat 有什么区别？
+```
+
+### 30 秒回答
+
+```text
+AIOps 告警有一个很关键的问题：环境里可能同时有很多活跃告警，Agent 容易跑偏。
+所以我把 AIOps 分成 PAYLOAD_TARGETED 和 AUTO_DISCOVERY。
+如果请求带 alert payload，最终报告必须聚焦输入告警，并且会把 alertName、service、severity、description 拼成 recommended lookup_knowledge query。
+```
+
+### 展开讲法
+
+没有 payload 时，Agent 可以先查询活跃告警，再选择目标排查。
+
+但有 payload 时，用户已经告诉系统“我要查这个告警”。这时如果 Agent 把其他活跃告警写成主根因，产品体验会很差。
+
+所以我做了两件事：
+
+- Prompt 中明确 `PAYLOAD_TARGETED` 范围。
+- `AiOpsRuleEvaluationService` 检查最终报告是否聚焦输入告警，以及是否使用证据工具。
+
+### 可展示文件
+
+- `mvp/architecture/agent-orchestration.md`
+- `mvp/architecture/current-mvp-architecture.md`
+- `interview/aiops-query-augmentation.md`
+- `interview/aiops-lightweight-verifier.md`
+
+### 主动说不足
+
+```text
+当前 scope control 主要靠 prompt 和规则评估。
+后续可以把 AIOps 也接入类似 Chat Verifier 的事实校验，让告警报告的每个根因和建议都有 evidence refs。
+```
+
+## 故事 5：反馈不是点赞按钮，而是案例沉淀入口
+
+### 面试官问题
+
+```text
+用户反馈在系统里有什么用？
+```
+
+### 30 秒回答
+
+```text
+反馈不只是前端按钮。
+用户提交 useful 后，系统会把同一个 diagnosis_session 沉淀为 case_library。
+not_useful 不会改执行状态，而是作为 bad case 信号保留。
+这样 status、self_evaluation、feedback 三个维度是分开的。
+```
+
+### 展开讲法
+
+我刻意没有把 `not_useful` 写成 `FAILED`。因为失败表示系统执行异常，而用户觉得不好用是质量标签。
+
+当前设计里：
+
+```text
+status          -> 执行是否成功
+self_evaluation -> 系统自己判断证据和事实支撑度
+feedback        -> 用户是否认可
+```
+
+`useful` 会进入 `CaseLibraryService.createFromSession`，生成可复用案例。后续可以做相似案例推荐或高质量样本积累。
+
+### 可展示文件
+
+- `mvp/architecture/feedback-architecture.md`
+- `mvp/architecture/data-model.md`
+- `mvp/demo/output/feedback-response.json`
+
+### 主动说不足
+
+```text
+当前 case_library 的 rootCause 和 solution 还直接使用完整 answer。
+后续应该从报告中结构化抽取 rootCause、solution、errorCode 和 service，提高案例复用质量。
+```
+
+## 结尾万能总结
+
+```text
+这个项目我最想展示的不是某一个模型效果，而是 Agent 工程化能力：
+一个诊断答案从哪里来、用了什么证据、是否被验证、用户是否认可、后续怎么沉淀和回归。
+这些链路都被结构化记录下来，所以它可以继续演进，而不是一次性 demo。
+```
+