意图分类

一、纯 LLM 意图分类（1.0 阶段）
1️⃣ 架构本质

最早最简单的方案是：

用户问题 → Prompt → LLM → 输出 intent（chat / rag / tool / code）

例如：

请判断用户意图：

输出：chat | rag | tool | code
2️⃣ 特点
✔ 优点
快速上线
不需要额外系统
依赖 LLM 自身能力
❌ 问题（企业级会直接踩坑）

1. 不稳定（核心问题）

同一句话：

今天 → rag
明天 → chat
温度一变 → 分类漂移
2. 无业务约束

LLM 不知道：

你有哪些知识库
有哪些工具
哪些模型可用

👉 它只是“猜”

3. 无可控性

企业系统最怕：

错路由 → 错答案 → 业务事故
4. 无扩展能力

新增能力只能：

改 prompt + 再调试

没有结构化扩展机制

二、升级：意图分类 + 规则增强（1.5 阶段）

很多团队会加一层：

规则 + LLM 混合判断

例如：

if "天气" in query:
return "tool-weather"

if "报表" in query:
return "sql"

LLM fallback:
classify(query)
问题依旧：
规则爆炸
维护成本高
多团队协作困难

三、真正企业级：意图知识库 + 检索路由（2.0 核心）

这是你问的重点👇

🧠 核心思想（非常关键）

👉 不再让 LLM “猜意图”
👉 而是让系统“查意图”

1️⃣ 意图不再是 prompt 分类，而是“知识对象”

我们把意图变成结构化数据：

{
"intent": "rag_query",
"description": "知识库问答",
"examples": ["帮我查xxx", "这个政策是什么"],
"kb_id": ["hr_kb", "legal_kb"],
"retrieval_strategy": "vector_search",
"top_k": 5
}

3️⃣ 路由变成“检索问题”

不是分类，而是：

query → embedding → intent库 → top-k intent

4️⃣ 架构升级
🔥 新架构：
┌──────────────┐
│ Intent KB │
│ (向量数据库) │
└──────┬───────┘
│
用户 query → embedding ─┼──→ similarity search
│
┌──────▼───────┐
│ Top-K Intent │
└──────┬───────┘
│
Router decision
│
┌────────┬────────┬────────┐
▼ ▼ ▼ ▼
chat rag tool code

2️⃣ 可扩展性强

新增能力：

👉 只要插入一条 intent 记录

不需要改 prompt

3️⃣ 可解释性强

可以解释：

为什么走这个路由？

因为：

query → embedding → intent_hr (0.87)

支持多路由（关键升级点）

LLM 分类只能：

单标签

意图检索可以：

top-3 intents：

1. rag_hr (0.91)
2. rag_policy (0.82)
3. chat (0.60)

👉 可以做混合策略

五、企业级最终形态（3.0）

真实生产系统一般是：

🔥 Hybrid Router
┌──────────────┐
│ Rule Engine │（强规则）
└──────┬───────┘
│
┌──────▼───────┐
│ Intent Search │（向量）
└──────┬───────┘
│
┌──────▼───────┐
│ LLM Judge │（二次确认）
└──────┬───────┘
│
Final Route

🔥 三层路由体系
Intent KB（向量检索）
Tool Registry（工具注册中心）
RAG KB Router（多知识库选择）

🧠 企业级 Agent Router 架构（Vue + FastAPI + LangGraph + pgvector）

或者直接给你：

意图库表结构设计（SQL）
embedding schema
router 代码（Python）
LangGraph实现版本

🧠 三层路由体系（写作整理版）

在企业级 LLM / Agent 系统中，常见的高可控路由架构可以抽象为“三层路由体系”，用于替代传统的纯 LLM 意图分类方式。

1. Intent KB（向量检索）

通过向量数据库构建“意图知识库”，将用户 query 与历史意图描述、示例进行 embedding 匹配，从而实现语义级意图召回与排序，而不是依赖模型硬分类。

2. Tool Registry（工具注册中心）

将所有可用工具（如搜索、数据库查询、天气、代码执行等）统一注册为结构化能力单元，包含名称、描述、输入输出 schema 与调用条件，实现可插拔式工具调度。

3. RAG KB Router（多知识库选择）

根据意图匹配结果，进一步路由到具体知识库（如 HR、技术文档、产品手册等），并选择对应的检索策略（pgvector / Milvus / hybrid search），完成最终的知识增强生成流程。

下面给你一个可落地的闭环 Hybrid Router 示例（企业级简化版），包含：

Rule Engine（强规则）
Intent Search（向量检索 mock）
LLM Judge（二次确认 mock）
Final Route 执行闭环

这个闭环的关键点（企业级重点）
1️⃣ Rule Engine 是“兜底确定性层”
命中直接执行
不走 LLM
用于：
天气
SQL
强业务路径
2️⃣ Intent Search 是“语义召回层”
embedding 相似度
找候选路由
替代“LLM猜分类”
3️⃣ LLM Judge 是“纠偏层”

作用：

防止 embedding 误召回
做业务偏好修正
做上下文推理
4️⃣ Executor 是“能力执行层”

真正业务落点：

RAG
Tool
Code
Chat
🚀 企业升级方向（你下一步可以做）

如果你要升级成真正生产级系统👇

1. Intent Search → pgvector
   存 intent embedding
   支持 metadata filter
2. Judge → LangGraph Node
   可加 memory
   multi-step reasoning
3. Router → 可观测系统
   trace
   score log
   intent hit rate

如果你想，我可以下一步帮你升级成：

🔥 LangGraph 版本 Hybrid Router（生产级）

或者

🔥 FastAPI + pgvector + Vue 管控台完整架构