Files
wecom_it_smart_desk/docs/02-技术文档/技术架构/技术方案-REQ-AI-001-复杂场景与统一路由-v1.0.md
T

342 lines
12 KiB
Markdown
Raw Normal View History

# 技术方案 - REQ-AI-001 复杂场景与统一路由
> **版本**: v1.1
> **日期**: 2026-07-27
> **REQ编号**: REQ-AI-001
> **关联PRD**: `PRD-REQ-AI-001-复杂场景与统一路由-v1.1.md`
> **状态**: 架构设计
> **架构师**: 高见远(Bob
---
## 目录
- [一、设计理念](#一设计理念)
- [二、统一路由层](#二统一路由层)
- [三、复杂场景重构第一阶段](#三复杂场景重构第一阶段)
- [四、复杂场景重构第二阶段](#四复杂场景重构第二阶段)
- [五、技术架构总结](#五技术架构总结)
- [六、验收标准](#六验收标准)
---
## 一、设计理念
### 1.1 TeliChat 三重约束机制
借鉴 TeliChat 白盒架构,确保复杂对话场景的可靠性:
| 约束 | 作用 | 实现方式 |
|------|------|---------|
| **拓扑结构限制** | 限制对话可以走到哪里 | `ScenarioConfig.actions` 有序列表 + Python 代码路由 |
| **信息状态约束** | 决定当前已经知道什么 | `auto_information_items` PostgreSQL 表 |
| **Python 代码约束** | 负责真正的业务判断 | FastAPI 业务逻辑 |
### 1.2 信息项修饰机制
| 修饰 | 含义 | 在复杂场景中的应用 |
|------|------|------------------|
| `固定` | 用户回答后不再重复询问 | 已通过系统获取的信息(操作系统、用户名) |
| `增量` | 允许用户补充新信息 | 故障描述、错误信息 — **非线性跳转核心** |
| `明确` | 必须明确回答 | 紧急程度确认 — **信息更正核心** |
| `隐含` | 可以从上下文推断 | AI 推断的问题类型 |
| `复述` | 要求用户确认信息正确性 | 重要操作确认 — **信息更正核心** |
| `必需` | 必须填写才能进入下一节点 | 必填字段 — **任务中断恢复核心** |
### 1.3 全局意图类型
| 意图 | 用户表达示例 | 处理策略 | 对应场景 |
|------|-------------|---------|---------|
| `SKIP` | "这个问题先不管了" | 跳过当前节点,记录未完成 | 非线性跳转 |
| `INSERT` | "对了,我的打印机也有问题" | 插入新任务到队列 | 多意图并行 |
| `RESUME` | "还是说回刚才那个网络问题" | 恢复之前话题 | 任务中断恢复 |
| `SWITCH` | "先帮我看看VPN吧" | 切换到指定话题 | 非线性跳转 |
| `CORRECT` | "刚才说错了,是win10" | 更新信息项值 | 信息更正 |
| `SUPPLEMENT` | "再补充一下,是财务部的电脑" | 增量补充信息 | 信息更正 |
| `PAUSE` | "我先去开会,等会继续" | 保存状态,等待恢复 | 任务中断恢复 |
| `RESUME_TASK` | "好了,继续吧" | 恢复中断的任务 | 任务中断恢复 |
| `ESCALATE` | "叫个人工来" | 转接坐席 | 所有场景 |
---
## 二、统一路由层
### 2.1 业务路由推荐
当员工提问涉及非IT问题(如行政、HR、财务等)时,自动推荐对应部门的联系人。<br>**注**:打印机、复印机、扫描仪属于IT服务范畴,不在此列。
#### 2.1.1 核心技术挑战与对策
| 挑战 | 对策 |
|------|------|
| **向后兼容**:扩展 Dify Prompt 后不能破坏现有审批识别 | 原审批判断规则原文保留不动,仅新增非IT判断段落;原3字段语义和取值不变,新增3字段 |
| **路由检测时机**:在消息处理流程中何时调用 Dify | 在 `process_h5_ai_reply` 后台任务中新增路由检测步骤,位于 BYOD 检测之后,打招呼/呼叫人工检测之前 |
| **误路由防护**IT问题被误识别为非IT | `routing_confidence < 0.7` 不触发名片推荐,走正常 AI 回复流程 |
#### 2.1.2 多层级路由模型
```
部门(department) → 业务(business) → 应用(application) → 角色(role) → 职责(responsibility)
联系方式(contact_point)
```
联系方式可配置在任意层级,匹配时采用「就近原则」:
- 优先查找职责级别
- 其次角色级别
- 再次应用级别
- 以此类推
#### 2.1.3 Dify 统一意图识别
扩展 Dify Prompt 输出格式:
```json
{
"is_approval_request": true/false,
"confidence": 0.0-1.0,
"approval_type": "设备申请",
"intent_type": "approval" / "it_consult" / "non_it_routing" / "chitchat",
"business_category": "行政" / "人力资源" / "财务" / null,
"routing_confidence": 0.0-1.0
}
```
**判断优先级链**
1. IT审批意图 → intent_type: "approval"
2. IT范围内咨询/报修 → intent_type: "it_consult"
3. 非IT业务路由 → intent_type: "non_it_routing"
4. 闲聊/无关 → intent_type: "chitchat"
---
## 三、复杂场景重构第一阶段
### 3.1 核心技术挑战
| 挑战 | 说明 | 对策 |
|------|------|------|
| **不引入 Neo4j 实现 TeliChat 三重约束** | 本阶段约束不引入 Neo4j | 三重约束映射:拓扑 → `ScenarioConfig.actions` 有序列表 + Python 代码路由;信息状态 → `auto_information_items` PostgreSQL 表 |
| **全局意图识别与现有场景识别的兼容** | 新增 PAUSE/RESUME_TASK/CORRECT/SUPPLEMENT 4 种全局意图 | 在 IntentRouter.detect() 前置一层全局意图检测,命中全局意图时跳过场景识别 |
| **暂停状态持久化与恢复点一致性** | 暂停时需保存完整上下文 | PostgreSQL 持久化会话状态 + Redis 存储恢复点快照(含 TTL 25h 自动过期) |
| **信息项版本管理与更正锁定** | 更正需保留变更历史 | `auto_information_items` 表记录 `version` + `update_history``is_locked` 字段控制更正锁定 |
| **24 小时超时自动关闭** | 暂停超过 24 小时需自动关闭会话 | 后台定时任务扫描 `paused` 状态会话,超时则标记 `closed` |
### 3.2 总体架构
```
员工 H5 / 坐席工作台
│ HTTP / WebSocket
FastAPI 路由层 (api/automation.py)
新增: /pause /resume /correct /supplement /info-items /paused
自动化服务层 (services/automation/)
├── IntentRouter (+全局意图检测)
├── SessionManager (+pause/resume/correct/supplement)
├── InformationItemService (新增)
├── TimeoutCleaner (新增, 24h扫描)
└── ProgressPublisher (+5种新WS事件)
┌────┴────┐
▼ ▼ ▼
PostgreSQL Redis Dify
+新表 +恢复点 AI
```
### 3.3 数据模型
#### 3.3.1 `auto_information_items` 表
```sql
CREATE TABLE auto_information_items (
id VARCHAR(36) PRIMARY KEY,
session_id VARCHAR(36) NOT NULL,
name VARCHAR(128) NOT NULL,
value TEXT NOT NULL DEFAULT '',
modifiers JSON NOT NULL DEFAULT '[]',
is_filled BOOLEAN NOT NULL DEFAULT FALSE,
is_locked BOOLEAN NOT NULL DEFAULT FALSE,
version INTEGER NOT NULL DEFAULT 1,
update_history JSON NOT NULL DEFAULT '[]',
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
```
#### 3.3.2 `auto_sessions` 表新增字段
```sql
ALTER TABLE auto_sessions ADD COLUMN paused_at TIMESTAMPTZ;
```
### 3.4 核心功能
| 功能 | 说明 |
|------|------|
| **暂停/恢复** | 员工可暂停会话并指定时间恢复,坐席可代恢复/关闭 |
| **信息更正** | 支持 CORRECT 意图更新信息项值,保留版本历史 |
| **信息补充** | 支持 SUPPLEMENT 意图增量补充信息 |
| **超时关闭** | 暂停超过24小时自动关闭会话 |
| **坐席感知** | 坐席工作台实时看到暂停/恢复/更正事件 |
---
## 四、复杂场景重构第二阶段
### 4.1 上下文压缩
#### 4.1.1 Tokenizer 选择
| 方案 | 说明 | 优先级 |
|------|------|--------|
| `tiktoken`cl100k_base | OpenAI 官方编码器,与 Dify/GPT 系列模型一致 | 首选 |
| 字符估算兜底 | 1 token ≈ 1.5 个中文字符估算 | 兜底 |
#### 4.1.2 压缩引擎设计
```python
class ContextCompressor:
def count_tokens(messages: list) -> int
def should_compress(session_id) -> bool
def compress(session_id, messages, info_items, actions, task_node) -> CompressedContext
def _extract_key_info(info_items, actions, task_node) -> str
def _summarize_history(messages_to_compress) -> str
def _progressive_compress(context, level=1) -> str
```
#### 4.1.3 渐进式压缩策略
| 级别 | 策略 | 压缩效果 |
|------|------|---------|
| Level 1 | LLM 摘要 + 保留最近4轮对话 | token 降低约 60% |
| Level 2 | LLM 摘要 + 保留最近2轮对话 | token 降低约 80% |
| Level 3 | 纯关键信息 + 保留最近1轮对话 | token 降低约 90% |
| 超出 | 截断最旧消息 | 降级保护 |
### 4.2 多轮纠错
#### 4.2.1 快照机制
每次更正前创建快照,支持撤销最近5次更正:
```python
class SnapshotService:
def create_snapshot(session_id, trigger_item_key, correction_ids) -> InformationSnapshot
def undo_correction(session_id) -> dict # 限制最近5次
def get_snapshot_history(session_id) -> list
def get_version_diff(session_id, v1, v2) -> dict
```
#### 4.2.2 批量更正
```python
class CorrectionService:
def batch_correct(session_id, corrections: list) -> BatchCorrectResult # 原子性事务
def check_dependencies(session_id, item_key) -> list # 依赖联动警告
```
### 4.3 数据模型
```sql
-- 上下文压缩记录表
CREATE TABLE auto_context_compressions (
id SERIAL PRIMARY KEY,
session_id VARCHAR(36) NOT NULL,
tokens_before INTEGER NOT NULL,
tokens_after INTEGER NOT NULL,
compression_ratio NUMERIC(5,2) NOT NULL,
compression_level SMALLINT NOT NULL DEFAULT 1,
summary TEXT,
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
-- 信息项快照表
CREATE TABLE auto_information_snapshots (
id SERIAL PRIMARY KEY,
session_id VARCHAR(36) NOT NULL,
trigger_item_key VARCHAR(64) NOT NULL,
snapshot_data JSON NOT NULL,
correction_ids JSON NOT NULL DEFAULT '[]',
is_undone BOOLEAN NOT NULL DEFAULT FALSE,
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
```
---
## 五、技术架构总结
### 5.1 核心技术栈
| 层 | 技术栈 |
|---|--------|
| 后端 | FastAPI + SQLAlchemy + PostgreSQL + Redis |
| H5前端 | Vue3 + Vant4 + TypeScript |
| 坐席前端 | Vue3 + Element Plus |
| AI意图识别 | Dify 原生 API(扩展现有 Prompt |
### 5.2 技术债务规避
| 项 | 规避方案 |
|----|----------|
| LLM 幻觉 | 代码约束 + 拓扑限制(TeliChat 核心解决) |
| 图谱复杂度 | 设计跳转权限控制 |
| 状态一致性 | 使用事务保证 |
| 性能 | 添加缓存层 |
---
## 六、验收标准
### 6.1 统一路由层
| 场景 | 验收条件 |
|------|----------|
| 非IT路由触发 | 员工发送"名片印刷找谁" → Dify识别为 non_it_routing → 发送名片卡片 |
| 路由置信度阈值 | routing_confidence < 0.7 → 不触发名片推荐,走正常AI流程 |
| 审批识别兼容性 | 审批问题仍正常识别,不受路由Prompt影响 |
### 6.2 复杂场景第一阶段
| 场景 | 验收条件 |
|------|----------|
| 暂停功能 | 员工输入"先去开会" → 会话暂停 → 恢复点保存到Redis |
| 恢复功能 | 员工输入"继续" → 恢复暂停会话 → 从断点继续执行 |
| 信息更正 | 员工说"刚才说错了,是win10" → 信息项更新 → 版本历史记录 |
| 超时关闭 | 暂停超过24小时 → 会话自动标记closed → 员工收到通知 |
### 6.3 复杂场景第二阶段
| 场景 | 验收条件 |
|------|----------|
| 上下文压缩 | 消息token超过6000 → 自动压缩 → token降低60%以上 |
| 批量更正 | 一次提交多个更正 → 原子性事务 → 全部成功或全部回滚 |
| 更正撤销 | 可撤销最近5次更正 → 信息项回滚到历史版本 |
---
## 变更记录
| 变更日期 | 变更内容 | 变更类型 | 关联PRD |
|----------|---------|---------|---------|
| 2026-07-27 | 新增智能打招呼检测:解决"您好+具体问题"被误判为纯打招呼的问题,新增 `_SUBSTANTIVE_KEYWORDS` 实质问题关键词列表 | 缺陷修复 | PRD-REQ-AI-001-v1.2 |
---
## 附录:源文档归档记录
本技术方案合并自以下文档:
| 源文档 | 合并章节 |
|--------|----------|
| 复杂场景技术方案-v1.1.md | 一、设计理念 |
| 复杂场景重构第一阶段-v1.0.md | 三、复杂场景重构第一阶段 |
| 复杂场景重构第二阶段-v1.0.md | 四、复杂场景重构第二阶段 |
| 业务路由推荐-v2.1.1.md | 二、统一路由层 |
---
*本文档为 REQ-AI-001 复杂场景与统一路由的完整技术方案*