分 6 层讲解（由浅入深）：
- 意图识别到底在干嘛（最朴素版）
- 为什么"只靠 LLM 一次分类"会不稳（你截图的痛点）
- "前置意图 RAG"是什么、解决什么、和普通 RAG 的区别
- 这套方案在 LangGraph 中怎么拆节点（Router/召回/分类/抽槽/执行）
- 数据怎么建：意图库 vs 意图知识库（RAG）各放什么
- 评估与迭代：怎么从 0 到 100+ 次迭代把准确率做上去
1) 最朴素的意图识别：把一句话映射到"要办的事"
在 Agent 里，"意图"不是泛泛的主题，而是可执行的事务类型。
- 输入：
用户一句话 + 上下文 - 输出：
intent_id + slots(参数) + confidence + 是否需要澄清
例如（运维）：
- "查询昨天订单服务 P1 告警"
→ops.query_alerts+{service=order-service, time_range=昨天, severity=P1}
关键：意图库 决定"系统允许哪些 intent"。
LangGraph 的 Router 节点通常只允许输出意图库里已经注册的 intent（强约束，利于落地）。
2) 为什么"只靠一次 LLM 分类"会不稳？
你截图里提到的核心痛点是：
- 真实用户表达 各种各样 ：口语、缩写、反问、情绪化、同义改写
- 但它们意思相近 ，希望落到同一个 intent
- 这要求模型同时具备：
- 泛化能力 （见过类似没见过的说法也能识别）
- 领域适配 （垂直领域术语、内部系统名、业务黑话）
仅用一次 LLM Router（直接让它在几十/几百个 intent 里选）会遇到两类典型问题：
- 候选空间太大：intent 数量上来后，模型在"相似意图"之间容易摇摆
- 语料稀疏：某些少见表达/新业务/边界 case，模型没"见过"类似问法
- 难解释：为什么选这个 intent？很难给可追溯证据
- 迭代成本高：靠提示词/微调硬扛，周期长
所以才会出现"反馈智能体不够智能"。
3) "前置意图 RAG 召回"到底是什么？
3.1 一句话解释
先用 RAG 从"意图知识库"里召回最相似的几个意图样例/说明，再把这些作为证据喂给 LLM 去做最终意图分类与抽槽。
它把"直接在所有 intent 里选"变成了：
先缩小候选集（召回 TopK） → 再精判（LLM 分类/抽槽）
3.2 它和"常见知识问答 RAG"有什么不同？
普通 RAG：检索的是事实知识 （产品说明、文档、制度）来回答问题。
意图 RAG：检索的是意图映射知识（"这类问法通常属于哪个意图、需要哪些参数、边界是什么"）。
换句话说：
- 普通 RAG：为了"答对内容"
- 意图 RAG：为了"选对路由 + 抽对参数"
3.3 它解决了什么？
- 泛化更稳：用户说法五花八门，但向量相似度能先召回"同类问法"
- 减少 LLM 认知负担：从 300 个 intent 缩到 Top10，再让 LLM 精判
- 可解释：你可以把召回的样例/规则作为"为什么这么判"的证据
- 更易迭代：新增/修正意图边界，只要更新意图知识库（embedding 索引），不一定动模型
"在知识库里上传大量意图分类知识，用户提问时先用 RAG 召回找到相似 query 和意图对应关系，作为案例交给 LLM 处理"。
4) 在 LangGraph 里怎么拆这套方案？（流程见附件）
流程大概是：
开始 -> 泛化意图知识库(RAG) -> 意图识别LLM -> (意图1/2/n的抽槽LLM) -> 后续操作
4.1 你 README 里的"Router"节点在方案 C 会被拆成两段
以前 Router 可能"一步到位"：直接意图分类。
方案 C 更像两段：
- Intent Retrieval（RAG 召回）：从"泛化意图知识库"取 TopK 候选
- Intent Decide（LLM 精判）：在候选里选最终 intent，并抽取 slots
这也是工业界很常见的模式：Retrieval-augmented Routing。
4.2 "抽槽 LLM"为什么要按 intent 分开？
因为不同 intent 的槽位完全不同：
ops.query_alerts关注：service、time_range、severityops.performance_diagnosis关注：service、time_range、suspect_component、可能还要 env、regionops.create_ticket又是另一个槽位集合
所以模型结构化输出最好变成：
- 先判
intent - 然后用对应的
schema去抽该 intent 的 slots（甚至用不同 prompt/不同 tool/form）
LangGraph 上就是：
intent_decide -> conditional edges -> slot_extract_{intent}
5) 数据怎么建：意图库 vs 意图知识库（RAG）分别存什么？
这是很多人最容易混淆的点
5.1 意图库（Intent Library）------"系统契约"
它更像代码/配置层面的契约 ，要稳定、可管理、可版本化，结构化：
- intent_id（唯一）
- 描述
- slot schema（必填/类型/校验）
- handler/workflow 路由
- 低置信度/缺参的澄清策略
- 权限策略（企业里很关键）
这决定了"能执行什么、怎么执行、缺参怎么办"。
5.2 意图知识库（Intent KB for RAG）------"泛化样本与边界知识"
它是给召回用的，内容要丰富、覆盖广、可迭代：
- 同义问法/改写（大量）
- 反问/情绪表达的归一化样例（"你们系统又挂了？"→ 可能是告警/故障）
- 负样本边界（"这个不属于该意图，属于另一个"）
- 常见缺参提示（这类问法常缺 time_range）
- 模板化示例：
query -> intent -> slot hints
索引字段通常是：
text（用于 embedding 检索）intent_id（标签）slot_hints / rationale / examples（作为 LLM 精判的上下文）
这决定了"召回能不能把候选缩到靠谱范围"。
6) 如何做把效果做上去？（实践层）
你截图提到"100+ 次迭代后的意图识别提升解析"。这类迭代通常不是盲调 prompt，而是围绕 数据闭环 + 指标 做的。
6.1 关键指标（建议最少做到这几个）
- Intent Top1 Accuracy（最终命中对不对）
- TopK Recall（真意图是否在召回的 K 个候选里）
- Slot Fill Accuracy（槽位抽取对不对）
- Clarification Rate（澄清率：太高用户体验差，太低容易误执行）
- Fallback Rate（兜底率）
方案 C 里尤其看重：TopK Recall
因为只要召回把正确意图带进候选集，LLM 精判就容易很多。
6.2 常见迭代动作（从轻到重）
- 补意图 KB 的表达覆盖：新增同义/反问/情绪化样例
- 补负样本与边界说明：相似意图之间必须有"区分说明"
- 调召回策略：embedding 模型、chunk 粒度、TopK、重排 rerank
- 调精判 prompt/schema：让 LLM 严格在候选里选 + 输出结构化 JSON
- 加澄清策略：低置信度/候选差距小/缺必填槽位 → 必须追问
- 领域词表/别名系统/实体对齐：减少"服务名"类槽位错误
附件：
python
User Text
|
v
+--------------------+
| 1. Router | 受"意图库"约束：只允许输出已注册 intent
| - intent | 输出：intent/slots/confidence/missing_slots
| - slots |
| - confidence |
+---------+----------+
|
| needs_clarification?
+---- yes ----> +--------------------+ -> END(等待用户补充)
| | 2. Clarify |
| +--------------------+
|
no
v
+----------------------------+
| 3. Entity Linking (KG) | 用"知识图谱"把文本槽位对齐到实体ID
| - resolve service/component|
+-------------+--------------+
v
+----------------------------+
| 4. Slot Enrich (KG) | 用拓扑/组织/资产关系补全缺槽位
| - dependencies |
| - owner/team |
+-------------+--------------+
v
+----------------------------+
| 5. Execute Workflow | 按 intent 选择并执行工具链
| - call tools (mock) |
+-------------+--------------+
v
+----------------------------+
| 6. Synthesize | 汇总结果 + 证据链（可解释）
+-------------+--------------+
v
END