zhuyongxin
de5a5b09d9
Archive pre-refactor interview notes and add current deep-dives on architecture evolution, issue-derived stories, and evidence gates.
76 lines
2.2 KiB
Markdown
76 lines
2.2 KiB
Markdown
# AIOps 查询增强说明
|
||
|
||
## 1. 改动是什么
|
||
|
||
AIOps 在 `PAYLOAD_TARGETED` 模式下，会从告警 payload 中稳定生成一条推荐知识库检索 query。
|
||
|
||
参与拼接的非空字段：
|
||
|
||
```text
|
||
alertName service severity description timeRange userRequest
|
||
```
|
||
|
||
示例：
|
||
|
||
```text
|
||
HighCPUUsage payment-service P1 CPU 使用率超过 80% last_15m
|
||
```
|
||
|
||
最终会进入 Prompt：
|
||
|
||
```text
|
||
Recommended lookup_knowledge query: ...
|
||
```
|
||
|
||
## 2. 为什么重要
|
||
|
||
AIOps payload 里包含高价值检索词：
|
||
|
||
- 告警名称。
|
||
- 服务名。
|
||
- 严重等级。
|
||
- 症状描述。
|
||
- 时间范围。
|
||
- 用户补充请求。
|
||
|
||
如果完全让 Agent 从长 Prompt 里自己组织检索 query，可能遗漏服务名或告警名。推荐 query 让检索种子更稳定。
|
||
|
||
## 3. 设计取舍
|
||
|
||
这是 Prompt 层 query augmentation，不是隐藏检索。
|
||
|
||
我没有在 Agent 运行前自动调用 `lookup_knowledge`，原因是项目强调可追踪性：工具调用应该由 Agent 显式发起，并记录到 `tool_invocation`。
|
||
|
||
当前设计：
|
||
|
||
```text
|
||
AIOps payload
|
||
-> deterministic recommended retrieval query
|
||
-> Agent prompt
|
||
-> Agent 显式调用 lookup_knowledge
|
||
-> tool_invocation 记录真实检索行为
|
||
```
|
||
|
||
## 4. 面试回答
|
||
|
||
如果被问：AIOps payload 怎么提升 RAG 检索？
|
||
|
||
```text
|
||
我没有把告警 payload 粗暴替换成一个宽泛领域，而是提取 alertName、service、severity、description、timeRange 等高信号字段，拼成推荐的 lookup_knowledge query。
|
||
Agent 仍然显式调用工具，所以 trace 仍然能看到真实检索行为，但 query 不再完全依赖模型临场发挥。
|
||
```
|
||
|
||
如果被问：为什么不自动检索？
|
||
|
||
```text
|
||
自动检索会在 Agent 真正决策前制造一份隐藏证据。
|
||
这个项目的重点是可观测 Agent 执行，所以我选择 Prompt 层增强：给 Agent 一个更好的 query seed，但不改变工具调用必须显式可追踪的契约。
|
||
```
|
||
|
||
## 5. 后续增强
|
||
|
||
- 将 recommended query 写入 trace 的结构化字段，便于对比 Agent 实际 query。
|
||
- 对 payload 字段加权，例如 alertName/service 权重大于 timeRange。
|
||
- 后续接入 Query Transformer 时，保留原始 query、推荐 query、改写 query 三者的可追踪关系。
|
||
|