226 lines
7.2 KiB
Markdown
226 lines
7.2 KiB
Markdown
# 面试故事案例
|
||
|
||
**用途**：把项目能力讲成可被面试官理解的工程故事
|
||
**使用方式**：按问题选择一个故事，不需要从头到尾背诵
|
||
|
||
## 故事 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。
|
||
```
|
||
|