448 lines
12 KiB
Markdown
448 lines
12 KiB
Markdown
# 智能体聊天助手性能优化方案
|
||
|
||
## 一、当前性能瓶颈分析
|
||
|
||
### 1. 主要瓶颈识别
|
||
|
||
#### 🔴 **最大瓶颈：LLM API 调用（串行执行）**
|
||
|
||
当前工作流包含多个 LLM 节点，**串行执行**：
|
||
1. **意图理解节点** (`llm-intent`) - 约 1-2 秒
|
||
2. **问题回答节点** (`llm-question`) - 约 2-5 秒
|
||
3. **格式化回复节点** (`llm-format`) - 约 1-2 秒
|
||
|
||
**总耗时**：约 **4-9 秒**（取决于 LLM API 响应速度）
|
||
|
||
#### 🟡 **次要瓶颈：前端轮询机制**
|
||
|
||
- 当前轮询间隔：**500ms**
|
||
- 每次轮询需要 2 个 API 请求（状态 + 详情）
|
||
- 在 5 秒的执行时间内，会产生 **20 次请求**
|
||
|
||
#### 🟢 **较小瓶颈：Redis 查询和数据库写入**
|
||
|
||
- Redis 查询：通常 < 10ms（可忽略）
|
||
- 数据库日志写入：可能影响性能（但已在 Celery 中异步处理）
|
||
|
||
### 2. 性能测试数据
|
||
|
||
```
|
||
单次对话执行时间分解：
|
||
├─ 开始节点: ~1ms
|
||
├─ 查询记忆: ~5ms (Redis)
|
||
├─ 合并上下文: ~1ms
|
||
├─ 意图理解: ~1500ms (LLM API)
|
||
├─ 意图路由: ~1ms
|
||
├─ 问题回答: ~3000ms (LLM API)
|
||
├─ 合并回复: ~1ms
|
||
├─ 更新记忆: ~5ms (Redis)
|
||
├─ 格式化回复: ~1500ms (LLM API)
|
||
└─ 结束节点: ~1ms
|
||
总计: ~6015ms (约6秒)
|
||
```
|
||
|
||
## 二、优化方案
|
||
|
||
### 方案 1：LLM 调用优化 ⭐⭐⭐⭐⭐
|
||
|
||
#### 1.1 并行执行可并行的 LLM 节点
|
||
|
||
**问题**：当前 `llm-format` 节点必须等待 `llm-question` 完成，但实际上可以优化。
|
||
|
||
**优化方案**：合并 `llm-question` 和 `llm-format` 节点
|
||
|
||
```python
|
||
# 修改 llm-question 节点的 prompt，直接生成格式化好的回复
|
||
prompt = """你是一个知识渊博、乐于助人的AI助手。请回答用户的问题。
|
||
|
||
用户问题：{{user_input}}
|
||
对话历史：{{memory.conversation_history}}
|
||
意图分析：{{output}}
|
||
|
||
请提供：
|
||
1. 直接、准确的答案
|
||
2. 必要的解释和说明
|
||
3. 如果问题不明确，友好地询问更多信息
|
||
|
||
请以自然、易懂的方式回答，长度控制在200字以内。直接输出回答内容，确保回复自然、流畅，无需额外格式化。"""
|
||
```
|
||
|
||
**效果**：减少 1 个 LLM 调用，节省 **1-2 秒**
|
||
|
||
#### 1.2 使用流式响应（Streaming）
|
||
|
||
**当前**：等待完整响应后才返回
|
||
|
||
**优化**：使用流式响应，边生成边返回
|
||
|
||
```python
|
||
# backend/app/services/llm_service.py
|
||
async def call_llm_stream(
|
||
self,
|
||
prompt: str,
|
||
provider: str = "openai",
|
||
model: Optional[str] = None,
|
||
**kwargs
|
||
) -> AsyncIterator[str]:
|
||
"""流式调用LLM"""
|
||
if provider == "deepseek":
|
||
client = self.deepseek_client
|
||
response = await client.chat.completions.create(
|
||
model=model or "deepseek-chat",
|
||
messages=[{"role": "user", "content": prompt}],
|
||
stream=True, # 启用流式
|
||
**kwargs
|
||
)
|
||
async for chunk in response:
|
||
if chunk.choices[0].delta.content:
|
||
yield chunk.choices[0].delta.content
|
||
```
|
||
|
||
**效果**：
|
||
- 用户感知延迟降低 **50-70%**
|
||
- 首字响应时间从 3 秒降至 **0.5-1 秒**
|
||
|
||
#### 1.3 LLM 响应缓存
|
||
|
||
**场景**：相同或相似的问题可以复用之前的回答
|
||
|
||
```python
|
||
# 在 cache-query 节点后添加缓存检查
|
||
# 使用问题的 hash 作为缓存 key
|
||
import hashlib
|
||
|
||
question_hash = hashlib.md5(user_input.encode()).hexdigest()
|
||
cache_key = f"llm_response_{question_hash}"
|
||
|
||
# 检查缓存
|
||
cached_response = redis_client.get(cache_key)
|
||
if cached_response:
|
||
return cached_response # 直接返回，节省 LLM 调用
|
||
```
|
||
|
||
**效果**：重复问题响应时间从 5 秒降至 **< 100ms**
|
||
|
||
#### 1.4 减少 max_tokens 限制
|
||
|
||
**当前配置**：
|
||
- `llm-intent`: max_tokens=1000
|
||
- `llm-question`: max_tokens=2000
|
||
- `llm-format`: max_tokens=500
|
||
|
||
**优化**：
|
||
- `llm-intent`: max_tokens=200（意图识别不需要太长）
|
||
- `llm-question`: max_tokens=1000（200字约500 tokens）
|
||
- 删除 `llm-format` 节点
|
||
|
||
**效果**：减少 token 生成时间，节省 **0.5-1 秒**
|
||
|
||
### 方案 2：前端优化 ⭐⭐⭐⭐
|
||
|
||
#### 2.1 使用 WebSocket 替代轮询
|
||
|
||
**当前**：每 500ms 轮询一次，产生大量请求
|
||
|
||
**优化**：使用 WebSocket 实时推送执行状态
|
||
|
||
```typescript
|
||
// frontend/src/composables/useWebSocket.ts
|
||
// 已有 WebSocket 实现，但未在聊天组件中使用
|
||
|
||
// 修改 AgentChatPreview.vue
|
||
import { useWebSocket } from '@/composables/useWebSocket'
|
||
|
||
const { status, result, connect, disconnect } = useWebSocket(execution.id)
|
||
|
||
watch(result, (newResult) => {
|
||
if (newResult && !replyAdded) {
|
||
replyAdded = true
|
||
messages.value.push({
|
||
role: 'agent',
|
||
content: extractReply(newResult),
|
||
timestamp: Date.now()
|
||
})
|
||
}
|
||
})
|
||
```
|
||
|
||
**效果**：
|
||
- 减少 90% 的 HTTP 请求
|
||
- 实时性提升（延迟从 500ms 降至 < 100ms）
|
||
- 服务器负载降低
|
||
|
||
#### 2.2 智能轮询（自适应间隔）
|
||
|
||
如果无法使用 WebSocket，可以优化轮询策略：
|
||
|
||
```typescript
|
||
// 动态调整轮询间隔
|
||
let pollingInterval = 500 // 初始 500ms
|
||
let consecutiveNoChange = 0
|
||
|
||
const checkStatus = async () => {
|
||
const oldStatus = lastStatus
|
||
const newStatus = await getStatus()
|
||
|
||
if (oldStatus === newStatus) {
|
||
consecutiveNoChange++
|
||
// 如果连续3次状态未变化，增加轮询间隔
|
||
if (consecutiveNoChange >= 3) {
|
||
pollingInterval = Math.min(pollingInterval * 1.5, 2000) // 最大2秒
|
||
}
|
||
} else {
|
||
consecutiveNoChange = 0
|
||
pollingInterval = 500 // 重置为初始值
|
||
}
|
||
|
||
setTimeout(checkStatus, pollingInterval)
|
||
}
|
||
```
|
||
|
||
**效果**：减少 30-50% 的无效请求
|
||
|
||
### 方案 3：工作流优化 ⭐⭐⭐
|
||
|
||
#### 3.1 简化工作流结构
|
||
|
||
**当前流程**：
|
||
```
|
||
开始 → 查询记忆 → 合并上下文 → 意图理解 → 意图路由 →
|
||
[5个分支] → 合并回复 → 更新记忆 → 格式化回复 → 结束
|
||
```
|
||
|
||
**优化流程**：
|
||
```
|
||
开始 → 查询记忆 → 合并上下文 → 意图理解 → 意图路由 →
|
||
[5个分支，直接生成最终回复] → 更新记忆 → 结束
|
||
```
|
||
|
||
**关键修改**：
|
||
- 删除 `llm-format` 节点
|
||
- 在各个分支节点中直接生成格式化好的回复
|
||
- 删除 `merge-response` 节点（如果只有一个分支被激活）
|
||
|
||
**效果**：减少 1-2 个节点执行，节省 **1-2 秒**
|
||
|
||
#### 3.2 条件优化：跳过不必要的节点
|
||
|
||
**场景**：如果用户只是简单问候，不需要完整的问题回答流程
|
||
|
||
```python
|
||
# 在 switch-intent 节点后，对于 greeting 意图
|
||
# 可以直接使用模板回复，跳过 LLM 调用
|
||
|
||
if intent == "greeting":
|
||
# 使用预定义模板
|
||
response = "你好！很高兴见到你，有什么我可以帮助你的吗？"
|
||
# 跳过 llm-greeting 节点
|
||
else:
|
||
# 正常执行 LLM 节点
|
||
response = await llm_question(...)
|
||
```
|
||
|
||
**效果**：简单场景响应时间从 5 秒降至 **< 1 秒**
|
||
|
||
### 方案 4：缓存优化 ⭐⭐⭐
|
||
|
||
#### 4.1 对话历史截断
|
||
|
||
**问题**：对话历史过长会增加 LLM prompt 长度，影响响应速度
|
||
|
||
**优化**：只保留最近 N 条对话
|
||
|
||
```python
|
||
# 在 cache-update 节点中
|
||
conversation_history = memory.conversation_history[-20:] # 只保留最近20条
|
||
```
|
||
|
||
**效果**：
|
||
- 减少 prompt 长度，节省 **0.2-0.5 秒**
|
||
- 降低 token 消耗
|
||
|
||
#### 4.2 智能摘要
|
||
|
||
**更高级的方案**：将旧对话压缩为摘要
|
||
|
||
```python
|
||
# 如果对话历史超过50条，生成摘要
|
||
if len(conversation_history) > 50:
|
||
# 保留最近20条
|
||
recent_history = conversation_history[-20:]
|
||
# 将前面的对话压缩为摘要
|
||
old_history = conversation_history[:-20]
|
||
summary = await llm_summarize(old_history) # 异步生成摘要
|
||
conversation_history = [{"role": "system", "content": summary}] + recent_history
|
||
```
|
||
|
||
**效果**：在保持上下文的同时，减少 prompt 长度
|
||
|
||
### 方案 5：数据库优化 ⭐⭐
|
||
|
||
#### 5.1 异步日志写入
|
||
|
||
**当前**：每个节点执行后立即写入日志
|
||
|
||
**优化**：批量写入日志
|
||
|
||
```python
|
||
# 收集日志，定期批量写入
|
||
log_buffer = []
|
||
async def flush_logs():
|
||
if log_buffer:
|
||
db.bulk_insert_mappings(ExecutionLog, log_buffer)
|
||
db.commit()
|
||
log_buffer.clear()
|
||
|
||
# 每100ms或每10条日志刷新一次
|
||
```
|
||
|
||
**效果**：减少数据库写入次数，提升 **5-10%** 性能
|
||
|
||
#### 5.2 减少日志详细程度
|
||
|
||
**生产环境**：只记录关键日志（错误、警告）
|
||
|
||
```python
|
||
# 根据环境变量控制日志级别
|
||
if settings.DEBUG:
|
||
logger.setLevel(logging.DEBUG)
|
||
else:
|
||
logger.setLevel(logging.WARNING) # 只记录警告和错误
|
||
```
|
||
|
||
**效果**：减少日志 I/O，提升 **2-5%** 性能
|
||
|
||
## 三、实施优先级
|
||
|
||
### 🔥 **高优先级（立即实施）**
|
||
|
||
1. **删除 llm-format 节点** ⭐⭐⭐⭐⭐
|
||
- 实施难度：低
|
||
- 效果：节省 1-2 秒
|
||
- 预计时间：30 分钟
|
||
|
||
2. **优化 max_tokens 配置** ⭐⭐⭐⭐
|
||
- 实施难度：低
|
||
- 效果：节省 0.5-1 秒
|
||
- 预计时间：15 分钟
|
||
|
||
3. **对话历史截断** ⭐⭐⭐⭐
|
||
- 实施难度：低
|
||
- 效果：节省 0.2-0.5 秒 + 降低 token 消耗
|
||
- 预计时间：30 分钟
|
||
|
||
### 🟡 **中优先级（近期实施）**
|
||
|
||
4. **使用 WebSocket 替代轮询** ⭐⭐⭐⭐
|
||
- 实施难度：中
|
||
- 效果：提升实时性，减少服务器负载
|
||
- 预计时间：2-3 小时
|
||
|
||
5. **简化工作流结构** ⭐⭐⭐
|
||
- 实施难度：中
|
||
- 效果：节省 1-2 秒
|
||
- 预计时间：1-2 小时
|
||
|
||
6. **智能轮询（如果不用 WebSocket）** ⭐⭐⭐
|
||
- 实施难度：低
|
||
- 效果：减少 30-50% 无效请求
|
||
- 预计时间：1 小时
|
||
|
||
### 🟢 **低优先级（长期优化）**
|
||
|
||
7. **流式响应** ⭐⭐⭐⭐⭐
|
||
- 实施难度：高
|
||
- 效果：显著提升用户体验（首字响应时间降低 50-70%）
|
||
- 预计时间：4-6 小时
|
||
|
||
8. **LLM 响应缓存** ⭐⭐⭐
|
||
- 实施难度：中
|
||
- 效果：重复问题响应时间 < 100ms
|
||
- 预计时间：2-3 小时
|
||
|
||
9. **条件优化（跳过不必要节点）** ⭐⭐⭐
|
||
- 实施难度：中
|
||
- 效果：简单场景响应时间 < 1 秒
|
||
- 预计时间：2-3 小时
|
||
|
||
## 四、预期效果
|
||
|
||
### 优化前
|
||
- **平均响应时间**：5-6 秒
|
||
- **首字响应时间**：3-4 秒
|
||
- **HTTP 请求数**：20+ 次/对话
|
||
|
||
### 优化后（实施高优先级方案）
|
||
|
||
- **平均响应时间**：**3-4 秒**（提升 40%）
|
||
- **首字响应时间**：**2-3 秒**（提升 25%）
|
||
- **HTTP 请求数**：**2-5 次/对话**（减少 75%）
|
||
|
||
### 优化后（实施所有方案）
|
||
|
||
- **平均响应时间**：**1.5-2.5 秒**（提升 60%）
|
||
- **首字响应时间**：**0.5-1 秒**（提升 75%，使用流式响应）
|
||
- **HTTP 请求数**：**1-2 次/对话**（使用 WebSocket）
|
||
|
||
## 五、具体实施步骤
|
||
|
||
### 步骤 1：快速优化（30 分钟）
|
||
|
||
```bash
|
||
# 1. 修改工作流配置，删除 llm-format 节点
|
||
# 2. 优化各 LLM 节点的 max_tokens
|
||
# 3. 添加对话历史截断逻辑
|
||
```
|
||
|
||
### 步骤 2：前端优化（2-3 小时）
|
||
|
||
```bash
|
||
# 1. 在 AgentChatPreview.vue 中集成 WebSocket
|
||
# 2. 替换轮询逻辑
|
||
# 3. 测试实时性
|
||
```
|
||
|
||
### 步骤 3：高级优化（可选，4-6 小时）
|
||
|
||
```bash
|
||
# 1. 实现流式响应
|
||
# 2. 添加 LLM 响应缓存
|
||
# 3. 优化工作流结构
|
||
```
|
||
|
||
## 六、监控指标
|
||
|
||
实施优化后，建议监控以下指标：
|
||
|
||
1. **响应时间分布**
|
||
- P50（中位数）
|
||
- P95（95% 分位数）
|
||
- P99（99% 分位数）
|
||
|
||
2. **LLM 调用时间**
|
||
- 各节点的平均调用时间
|
||
- Token 消耗
|
||
|
||
3. **前端指标**
|
||
- 首字响应时间（TTFB）
|
||
- 完整响应时间
|
||
- HTTP 请求数量
|
||
|
||
4. **服务器负载**
|
||
- CPU 使用率
|
||
- 内存使用率
|
||
- 数据库连接数
|
||
|
||
## 七、注意事项
|
||
|
||
1. **流式响应**：需要修改前端 UI，支持逐步显示文本
|
||
2. **缓存策略**：需要考虑缓存失效和更新机制
|
||
3. **向后兼容**：优化不应破坏现有功能
|
||
4. **测试覆盖**：每个优化都需要充分测试
|
||
|
||
---
|
||
|
||
**文档版本**：v1.0
|
||
**创建时间**：2024年
|
||
**维护人员**：AI Assistant
|