feat(platform): Complete Postgres-Only architecture refactoring (Phase 1-7)
Major Changes: - Implement Platform-Only architecture pattern (unified task management) - Add PostgresCacheAdapter for unified caching (platform_schema.app_cache) - Add PgBossQueue for job queue management (platform_schema.job) - Implement CheckpointService using job.data (generic for all modules) - Add intelligent threshold-based dual-mode processing (THRESHOLD=50) - Add task splitting mechanism (auto chunk size recommendation) - Refactor ASL screening service with smart mode selection - Refactor DC extraction service with smart mode selection - Register workers for ASL and DC modules Technical Highlights: - All task management data stored in platform_schema.job.data (JSONB) - Business tables remain clean (no task management fields) - CheckpointService is generic (shared by all modules) - Zero code duplication (DRY principle) - Follows 3-layer architecture principle - Zero additional cost (no Redis needed, save 8400 CNY/year) Code Statistics: - New code: ~1750 lines - Modified code: ~500 lines - Test code: ~1800 lines - Documentation: ~3000 lines Testing: - Unit tests: 8/8 passed - Integration tests: 2/2 passed - Architecture validation: passed - Linter errors: 0 Files: - Platform layer: PostgresCacheAdapter, PgBossQueue, CheckpointService, utils - ASL module: screeningService, screeningWorker - DC module: ExtractionController, extractionWorker - Tests: 11 test files - Docs: Updated 4 key documents Status: Phase 1-7 completed, Phase 8-9 pending
This commit is contained in:
947
docs/07-运维文档/07-Redis使用需求分析(按模块).md
Normal file
947
docs/07-运维文档/07-Redis使用需求分析(按模块).md
Normal file
@@ -0,0 +1,947 @@
|
||||
# Redis使用需求分析（按模块）
|
||||
|
||||
> **文档版本：** V1.0
|
||||
> **创建日期：** 2025-12-12
|
||||
> **分析范围：** 7大核心业务模块
|
||||
> **目的：** 明确哪些模块需要Redis，哪些不需要
|
||||
|
||||
---
|
||||
|
||||
## 📋 目录
|
||||
|
||||
1. [分析维度与标准](#1-分析维度与标准)
|
||||
2. [7大模块详细分析](#2-7大模块详细分析)
|
||||
3. [Redis需求汇总](#3-redis需求汇总)
|
||||
4. [实施优先级建议](#4-实施优先级建议)
|
||||
5. [成本效益分析](#5-成本效益分析)
|
||||
|
||||
---
|
||||
|
||||
## 1. 分析维度与标准
|
||||
|
||||
### 1.1 评估维度
|
||||
|
||||
| 维度 | 说明 | 影响 |
|
||||
|------|------|------|
|
||||
| **任务时长** | 单次任务处理时间 | > 10分钟 → 必须用Redis队列 |
|
||||
| **LLM调用频率** | 是否频繁调用大模型 | 高频调用 → 需要Redis缓存 |
|
||||
| **数据重复性** | 是否有重复处理 | 高重复 → 需要Redis缓存 |
|
||||
| **用户规模** | 并发用户数 | > 20用户 → 需要Redis |
|
||||
| **数据量级** | 单次处理数据量 | 百万行 → 需要Redis队列 |
|
||||
| **实时性要求** | 响应速度要求 | < 1秒 → 可能需要Redis缓存 |
|
||||
|
||||
### 1.2 判断标准
|
||||
|
||||
#### **Redis缓存**（必须）
|
||||
|
||||
```
|
||||
满足以下任一条件：
|
||||
✅ LLM调用结果可复用（相同输入 → 相同输出）
|
||||
✅ 计算成本高（> 1秒）且结果可缓存
|
||||
✅ 多实例部署需要共享数据
|
||||
✅ 需要跨请求保持状态（Session）
|
||||
```
|
||||
|
||||
#### **Redis队列**（必须）
|
||||
|
||||
```
|
||||
满足以下任一条件：
|
||||
✅ 任务时长 > 10分钟
|
||||
✅ 任务涉及批量处理（> 100条）
|
||||
✅ 需要任务持久化（实例重启不丢失）
|
||||
✅ 需要任务重试（失败后自动重试）
|
||||
✅ SAE多实例需要协调任务分配
|
||||
```
|
||||
|
||||
#### **不需要Redis**（可选）
|
||||
|
||||
```
|
||||
满足以下所有条件：
|
||||
✅ 任务时长 < 10秒
|
||||
✅ 单次处理，无需缓存
|
||||
✅ 不调用LLM或调用频率极低
|
||||
✅ 单实例部署足够
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. 7大模块详细分析
|
||||
|
||||
### 模块1：AIA - AI智能问答 ⭐⭐⭐⭐
|
||||
|
||||
#### **功能描述**
|
||||
- 10+个专业智能体（选题评价、PICO梳理、样本量计算等）
|
||||
- 流式对话 + 非流式对话
|
||||
- 知识库模式（RAG检索）
|
||||
|
||||
#### **典型使用场景**
|
||||
```
|
||||
用户：如何进行PICO梳理？
|
||||
系统：调用LLM → 返回结构化回答（3-5秒）
|
||||
|
||||
用户：基于我的知识库，解答XXX问题
|
||||
系统：RAG检索 + LLM → 返回答案（5-10秒）
|
||||
```
|
||||
|
||||
#### **需求分析**
|
||||
|
||||
| 维度 | 评估 | 说明 |
|
||||
|------|------|------|
|
||||
| **任务时长** | 3-10秒 | 单次对话 |
|
||||
| **LLM调用** | 🔴 高频 | 每次对话都调用 |
|
||||
| **数据重复性** | 🟡 中等 | 常见问题会重复 |
|
||||
| **用户规模** | 🟡 中等 | 预计20-50并发 |
|
||||
| **批量处理** | ❌ 无 | 单次对话 |
|
||||
|
||||
#### **Redis需求**
|
||||
|
||||
```
|
||||
✅ Redis缓存：推荐
|
||||
理由：
|
||||
- 常见问题可以缓存（"如何进行PICO梳理？"）
|
||||
- 减少重复LLM调用，节省成本
|
||||
- 响应速度提升（从5秒降到50ms）
|
||||
|
||||
缓存策略：
|
||||
- 缓存key：问题+智能体ID的hash
|
||||
- TTL：1小时（问答变化不大）
|
||||
- 预计命中率：30-50%
|
||||
|
||||
❌ Redis队列：不需要
|
||||
理由：
|
||||
- 任务时长 < 10秒
|
||||
- 无需批量处理
|
||||
- 同步返回即可
|
||||
```
|
||||
|
||||
#### **实施建议**
|
||||
|
||||
```typescript
|
||||
// 示例：缓存LLM回答
|
||||
async function askAI(question: string, agentId: string) {
|
||||
const cacheKey = `aia:${agentId}:${hashQuestion(question)}`;
|
||||
|
||||
// 1. 先查缓存
|
||||
const cached = await cache.get(cacheKey);
|
||||
if (cached) {
|
||||
return cached; // ✅ 缓存命中，节省LLM调用
|
||||
}
|
||||
|
||||
// 2. 调用LLM
|
||||
const answer = await llm.ask(question);
|
||||
|
||||
// 3. 写入缓存
|
||||
await cache.set(cacheKey, answer, 3600); // 1小时
|
||||
|
||||
return answer;
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 模块2：PKB - 个人知识库 ⭐⭐⭐
|
||||
|
||||
#### **功能描述**
|
||||
- 用户创建私人文献库（每库50篇）
|
||||
- 上传文档（PDF/Word/TXT）
|
||||
- 基于库内文献进行RAG问答
|
||||
|
||||
#### **典型使用场景**
|
||||
```
|
||||
用户：上传50篇PDF到知识库
|
||||
系统：文档解析 → 向量化 → 存储（批处理，10-30分钟）
|
||||
|
||||
用户：基于知识库问答
|
||||
系统：向量检索 → LLM → 回答（3-5秒）
|
||||
```
|
||||
|
||||
#### **需求分析**
|
||||
|
||||
| 维度 | 评估 | 说明 |
|
||||
|------|------|------|
|
||||
| **任务时长** | 10-30分钟 | 批量上传处理 |
|
||||
| **LLM调用** | 🟡 中频 | 问答时调用 |
|
||||
| **数据重复性** | 🟡 中等 | 相同问题会重复 |
|
||||
| **用户规模** | 🟡 中等 | 每用户3个库 |
|
||||
| **批量处理** | ✅ 有 | 50篇文档处理 |
|
||||
|
||||
#### **Redis需求**
|
||||
|
||||
```
|
||||
✅ Redis缓存：推荐
|
||||
理由：
|
||||
- RAG检索结果可缓存（相同问题 → 相同答案）
|
||||
- 向量检索也可缓存
|
||||
- 减少重复计算
|
||||
|
||||
缓存策略：
|
||||
- 问答缓存：TTL 1小时
|
||||
- 向量检索缓存：TTL 30分钟
|
||||
|
||||
✅ Redis队列：推荐
|
||||
理由：
|
||||
- 批量上传50篇文档，处理时间10-30分钟
|
||||
- 需要后台处理（向量化耗时）
|
||||
- 实例重启不应丢失任务
|
||||
|
||||
队列策略：
|
||||
- 任务类型：'pkb:batch-upload'
|
||||
- 失败重试：3次
|
||||
```
|
||||
|
||||
#### **关键场景**
|
||||
|
||||
```
|
||||
场景：用户上传50篇PDF
|
||||
当前（MemoryQueue）：
|
||||
- 22:00 用户上传
|
||||
- 22:15 处理到20篇
|
||||
- 22:20 SAE实例缩容
|
||||
- ❌ 任务丢失
|
||||
|
||||
改用Redis队列：
|
||||
- 22:00 用户上传
|
||||
- 22:15 处理到20篇
|
||||
- 22:20 实例销毁
|
||||
- 22:21 新实例启动
|
||||
- ✅ 从第21篇继续处理
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 模块3：ASL - AI智能文献 ⭐⭐⭐⭐⭐ **重点模块**
|
||||
|
||||
#### **功能描述**
|
||||
- 标题摘要初筛（双模型并行）
|
||||
- 全文复筛（12字段提取）
|
||||
- Meta分析
|
||||
- 证据图谱
|
||||
|
||||
#### **典型使用场景**
|
||||
|
||||
```
|
||||
场景1：标题摘要初筛（1000篇）
|
||||
- 单篇耗时：6-10秒（双模型）
|
||||
- 总耗时：100-167分钟 ≈ 2小时
|
||||
- LLM调用：2000次（每篇2个模型）
|
||||
|
||||
场景2：全文复筛（100篇PDF）
|
||||
- 单篇耗时：30-60秒（12字段提取）
|
||||
- 总耗时：50-100分钟
|
||||
- LLM调用：200次（双模型）
|
||||
```
|
||||
|
||||
#### **需求分析**
|
||||
|
||||
| 维度 | 评估 | 说明 |
|
||||
|------|------|------|
|
||||
| **任务时长** | 🔴 2小时 | 1000篇文献 |
|
||||
| **LLM调用** | 🔴 超高频 | 2000次/任务 |
|
||||
| **数据重复性** | 🟡 中等 | 同一文献可能多次筛选 |
|
||||
| **用户规模** | 🟡 中等 | 预计20-50用户 |
|
||||
| **批量处理** | ✅ 大批量 | 1000篇 |
|
||||
|
||||
#### **Redis需求**
|
||||
|
||||
```
|
||||
🔴 Redis缓存：必须！
|
||||
理由：
|
||||
1. LLM成本巨大：
|
||||
- 1000篇 × 2模型 × ¥0.015 = ¥30/次
|
||||
- 如果重复调用，成本翻倍
|
||||
|
||||
2. 相同文献可能被多个项目筛选
|
||||
- 缓存可以跨项目复用
|
||||
- 节省60-80% LLM成本
|
||||
|
||||
3. 用户可能重新运行相同任务
|
||||
- 调整PICO标准后重新筛选
|
||||
- 缓存可以加速10倍
|
||||
|
||||
缓存策略：
|
||||
- key: fulltext:{pmid}:{model}
|
||||
- TTL: 30天（文献不变）
|
||||
- 预计命中率：60-80%
|
||||
|
||||
🔴 Redis队列：必须！
|
||||
理由：
|
||||
1. 任务时长2小时，SAE必然销毁实例
|
||||
2. 任务失败率 > 90%（如果用MemoryQueue）
|
||||
3. 用户体验极差（任务反复失败）
|
||||
4. LLM成本浪费（失败后重新调用）
|
||||
|
||||
队列策略：
|
||||
- 任务类型：'asl:title-screening'
|
||||
- 失败重试：3次
|
||||
- 优先级：高（用户等待）
|
||||
```
|
||||
|
||||
#### **成本对比**
|
||||
|
||||
```
|
||||
不用Redis（MemoryQueue + 无缓存）：
|
||||
- 任务成功率：10-30%
|
||||
- 用户需要重试：平均3次
|
||||
- LLM成本：¥30 × 3 = ¥90
|
||||
- 用户满意度：极差
|
||||
|
||||
使用Redis（队列 + 缓存）：
|
||||
- 任务成功率：99%+
|
||||
- 用户重试次数：几乎为0
|
||||
- LLM成本：¥30 × 40% = ¥12（60%缓存命中）
|
||||
- 用户满意度：优秀
|
||||
|
||||
节省成本：¥78/次
|
||||
如果每月10次任务：¥780/月
|
||||
Redis成本：¥9/月
|
||||
ROI：8,667%
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 模块4：DC - 数据清洗整理 ⭐⭐⭐⭐⭐ **重点模块**
|
||||
|
||||
#### **功能描述**
|
||||
- Tool A：医疗数据超级合并器
|
||||
- Tool B：病历结构化机器人（双模型NER）
|
||||
- Tool C：科研数据编辑器（AI代码生成）
|
||||
|
||||
#### **典型使用场景**
|
||||
|
||||
```
|
||||
场景1：Tool B - 批量提取病历（1000份）
|
||||
- 单份耗时：5-10秒（双模型）
|
||||
- 总耗时：83-167分钟 ≈ 1.5-3小时
|
||||
- LLM调用：2000次
|
||||
|
||||
场景2：Tool C - AI数据清洗
|
||||
- 单次清洗：3-10秒
|
||||
- 无需批量处理
|
||||
|
||||
场景3：Tool A - 数据合并（百万行）
|
||||
- 耗时：5-30分钟（取决于数据量）
|
||||
- 无LLM调用
|
||||
```
|
||||
|
||||
#### **需求分析**
|
||||
|
||||
| 维度 | Tool A | Tool B | Tool C |
|
||||
|------|--------|--------|--------|
|
||||
| **任务时长** | 5-30分钟 | 🔴 2-3小时 | 3-10秒 |
|
||||
| **LLM调用** | ❌ | 🔴 超高频 | 🟡 中频 |
|
||||
| **数据重复性** | ❌ | 🟡 中等 | 🟡 中等 |
|
||||
| **批量处理** | ✅ | ✅ | ❌ |
|
||||
|
||||
#### **Redis需求**
|
||||
|
||||
```
|
||||
Tool A（数据合并）：
|
||||
❌ Redis缓存：不需要
|
||||
理由：无LLM调用，无重复计算
|
||||
|
||||
✅ Redis队列：推荐
|
||||
理由：
|
||||
- 百万行数据处理，耗时5-30分钟
|
||||
- 避免实例销毁导致任务丢失
|
||||
|
||||
Tool B（病历提取）：
|
||||
🔴 Redis缓存：必须！
|
||||
理由：
|
||||
- 与ASL类似，LLM成本高
|
||||
- 相同病历可能被重复提取
|
||||
- 健康检查结果可以缓存（24小时）
|
||||
|
||||
缓存策略：
|
||||
- 健康检查：TTL 24小时
|
||||
- 提取结果：TTL 7天
|
||||
|
||||
🔴 Redis队列：必须！
|
||||
理由：
|
||||
- 1000份病历，耗时2-3小时
|
||||
- 与ASL相同原因
|
||||
|
||||
Tool C（AI数据清洗）：
|
||||
✅ Redis缓存：推荐
|
||||
理由：
|
||||
- AI代码生成结果可缓存
|
||||
- 相同操作不需要重复生成代码
|
||||
|
||||
缓存策略：
|
||||
- key: tool-c:{operation}:{hash}
|
||||
- TTL: 1小时
|
||||
|
||||
❌ Redis队列：不需要
|
||||
理由：
|
||||
- 单次操作 < 10秒
|
||||
- 无需批量处理
|
||||
```
|
||||
|
||||
#### **Tool B成本分析**
|
||||
|
||||
```
|
||||
1000份病历提取（双模型）：
|
||||
- LLM成本：¥430
|
||||
- 如果重复提取：¥430 × 2 = ¥860
|
||||
|
||||
使用Redis缓存：
|
||||
- 缓存命中率：40-60%
|
||||
- LLM成本：¥430 × 40% = ¥172
|
||||
- 节省：¥258/次
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 模块5：SSA - 智能统计分析 ⭐⭐⭐⭐
|
||||
|
||||
#### **功能描述**
|
||||
- 3条核心分析路径：队列研究、预测模型、RCT研究
|
||||
- 从数据上传 → 质控 → 分析 → 报告导出
|
||||
|
||||
#### **典型使用场景**
|
||||
|
||||
```
|
||||
场景1：队列研究（10万行数据）
|
||||
- 数据上传：1分钟
|
||||
- 数据质控：2-5分钟
|
||||
- 统计分析：5-20分钟
|
||||
- 报告生成：1-3分钟
|
||||
总耗时：10-30分钟
|
||||
|
||||
场景2：预测模型（机器学习）
|
||||
- 特征工程：5-10分钟
|
||||
- 模型训练：10-60分钟
|
||||
- 模型评估：2-5分钟
|
||||
总耗时：20-75分钟
|
||||
```
|
||||
|
||||
#### **需求分析**
|
||||
|
||||
| 维度 | 评估 | 说明 |
|
||||
|------|------|------|
|
||||
| **任务时长** | 🟡 10-75分钟 | 取决于分析类型 |
|
||||
| **LLM调用** | 🟢 低频 | 仅报告解读时调用 |
|
||||
| **数据重复性** | ❌ 低 | 每次数据不同 |
|
||||
| **用户规模** | 🟡 中等 | 预计20-30用户 |
|
||||
| **批量处理** | ✅ 有 | 大数据集处理 |
|
||||
|
||||
#### **Redis需求**
|
||||
|
||||
```
|
||||
⚠️ Redis缓存：可选
|
||||
理由：
|
||||
- LLM调用频率低（仅报告解读）
|
||||
- 统计分析结果通常不可复用
|
||||
- 但报告解读可以缓存
|
||||
|
||||
缓存策略（如果实施）：
|
||||
- 仅缓存LLM报告解读
|
||||
- TTL: 1小时
|
||||
|
||||
✅ Redis队列：推荐
|
||||
理由：
|
||||
- 任务时长 10-75分钟
|
||||
- 预测模型训练可能超1小时
|
||||
- 实例销毁会导致任务丢失
|
||||
|
||||
队列策略：
|
||||
- 任务类型：'ssa:cohort-analysis'
|
||||
- 失败重试：1次（统计分析幂等）
|
||||
```
|
||||
|
||||
#### **关键场景**
|
||||
|
||||
```
|
||||
场景：用户提交预测模型训练（60分钟）
|
||||
当前（MemoryQueue）：
|
||||
- 21:00 提交任务
|
||||
- 21:30 训练到50%
|
||||
- 21:31 实例销毁
|
||||
- ❌ 任务丢失
|
||||
|
||||
改用Redis队列：
|
||||
- 21:00 提交任务
|
||||
- 21:30 训练到50%
|
||||
- 21:31 实例销毁
|
||||
- 21:32 新实例启动
|
||||
- ⚠️ 问题：训练无法从50%继续
|
||||
- 💡 解决：定期保存checkpoint到OSS
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 模块6：ST - 统计分析工具 ⭐⭐⭐
|
||||
|
||||
#### **功能描述**
|
||||
- 100+种轻量化统计工具
|
||||
- 即时、小型的分析需求
|
||||
- t检验、卡方检验、相关分析等
|
||||
|
||||
#### **典型使用场景**
|
||||
|
||||
```
|
||||
场景：用户上传数据（100行），选择t检验
|
||||
- 数据上传：1秒
|
||||
- 统计计算：< 1秒
|
||||
- 结果展示：即时
|
||||
总耗时：< 2秒
|
||||
```
|
||||
|
||||
#### **需求分析**
|
||||
|
||||
| 维度 | 评估 | 说明 |
|
||||
|------|------|------|
|
||||
| **任务时长** | < 2秒 | 轻量化工具 |
|
||||
| **LLM调用** | ❌ 无 | 纯统计计算 |
|
||||
| **数据重复性** | ❌ 低 | 每次数据不同 |
|
||||
| **用户规模** | 🟡 中等 | 高频使用 |
|
||||
| **批量处理** | ❌ 无 | 单次分析 |
|
||||
|
||||
#### **Redis需求**
|
||||
|
||||
```
|
||||
❌ Redis缓存：不需要
|
||||
理由：
|
||||
- 无LLM调用
|
||||
- 统计计算极快（< 1秒）
|
||||
- 结果不可复用（数据每次不同）
|
||||
|
||||
❌ Redis队列：不需要
|
||||
理由：
|
||||
- 任务时长 < 2秒
|
||||
- 可以同步返回
|
||||
- 无需后台处理
|
||||
```
|
||||
|
||||
#### **结论**
|
||||
**ST模块完全不需要Redis！**
|
||||
|
||||
---
|
||||
|
||||
### 模块7：RVW - 稿件审查系统 ⭐⭐⭐
|
||||
|
||||
#### **功能描述**
|
||||
- 方法学评估
|
||||
- 审稿流程管理
|
||||
- 质量检查
|
||||
|
||||
#### **典型使用场景**
|
||||
|
||||
```
|
||||
场景1：方法学评估（单篇论文）
|
||||
- 文档上传：1秒
|
||||
- AI评估：10-30秒
|
||||
- 生成报告：3-5秒
|
||||
总耗时：15-40秒
|
||||
|
||||
场景2：批量审稿（10篇论文）
|
||||
- 批量上传：5秒
|
||||
- 批量评估：100-300秒（5-10分钟）
|
||||
- 报告生成：10秒
|
||||
总耗时：5-10分钟
|
||||
```
|
||||
|
||||
#### **需求分析**
|
||||
|
||||
| 维度 | 评估 | 说明 |
|
||||
|------|------|------|
|
||||
| **任务时长** | 15秒-10分钟 | 取决于批量大小 |
|
||||
| **LLM调用** | 🟡 中频 | 方法学评估 |
|
||||
| **数据重复性** | 🟡 中等 | 相同论文可能重复评估 |
|
||||
| **用户规模** | 🟢 低 | 预计5-10用户 |
|
||||
| **批量处理** | ⚠️ 可选 | 批量审稿 |
|
||||
|
||||
#### **Redis需求**
|
||||
|
||||
```
|
||||
✅ Redis缓存：推荐
|
||||
理由：
|
||||
- 相同论文可能被多次评估
|
||||
- LLM评估结果可复用
|
||||
- 节省LLM成本
|
||||
|
||||
缓存策略：
|
||||
- key: rvw:{paper_hash}:{model}
|
||||
- TTL: 7天
|
||||
|
||||
⚠️ Redis队列：可选
|
||||
理由：
|
||||
- 单篇审稿 < 1分钟，不需要队列
|
||||
- 批量审稿（10篇）约5-10分钟，建议用队列
|
||||
|
||||
决策标准：
|
||||
- 如果支持批量 > 10篇 → 需要队列
|
||||
- 否则，可以不用
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Redis需求汇总
|
||||
|
||||
### 3.1 Redis缓存需求汇总
|
||||
|
||||
| 模块 | 是否需要 | 优先级 | 预计命中率 | 年节省成本 |
|
||||
|------|---------|--------|-----------|-----------|
|
||||
| **ASL** | 🔴 必须 | P0 | 60-80% | ¥9,360 |
|
||||
| **DC (Tool B)** | 🔴 必须 | P0 | 40-60% | ¥3,096 |
|
||||
| **PKB** | ✅ 推荐 | P1 | 30-50% | ¥1,200 |
|
||||
| **AIA** | ✅ 推荐 | P1 | 30-50% | ¥2,400 |
|
||||
| **DC (Tool C)** | ✅ 推荐 | P2 | 20-30% | ¥500 |
|
||||
| **RVW** | ✅ 推荐 | P2 | 40-60% | ¥800 |
|
||||
| **SSA** | ⚠️ 可选 | P3 | 10-20% | ¥200 |
|
||||
| **DC (Tool A)** | ❌ 不需要 | - | 0% | ¥0 |
|
||||
| **ST** | ❌ 不需要 | - | 0% | ¥0 |
|
||||
|
||||
**总计年节省成本：¥17,556**
|
||||
**Redis成本：¥108/年**
|
||||
**ROI：16,256%**
|
||||
|
||||
---
|
||||
|
||||
### 3.2 Redis队列需求汇总
|
||||
|
||||
| 模块 | 是否需要 | 优先级 | 典型任务时长 | 失败风险 |
|
||||
|------|---------|--------|------------|---------|
|
||||
| **ASL** | 🔴 必须 | P0 | 2小时 | 95%+ |
|
||||
| **DC (Tool B)** | 🔴 必须 | P0 | 2-3小时 | 95%+ |
|
||||
| **DC (Tool A)** | ✅ 推荐 | P1 | 5-30分钟 | 70-90% |
|
||||
| **PKB** | ✅ 推荐 | P1 | 10-30分钟 | 70-90% |
|
||||
| **SSA** | ✅ 推荐 | P1 | 10-75分钟 | 70-95% |
|
||||
| **RVW** | ⚠️ 可选 | P3 | 5-10分钟 | 30-50% |
|
||||
| **DC (Tool C)** | ❌ 不需要 | - | < 10秒 | < 5% |
|
||||
| **AIA** | ❌ 不需要 | - | < 10秒 | < 5% |
|
||||
| **ST** | ❌ 不需要 | - | < 2秒 | 0% |
|
||||
|
||||
**结论**：
|
||||
- 2个模块**必须**用Redis队列（ASL、DC Tool B）
|
||||
- 3个模块**推荐**用Redis队列（DC Tool A、PKB、SSA）
|
||||
- 1个模块**可选**（RVW）
|
||||
- 3个模块**不需要**（DC Tool C、AIA、ST）
|
||||
|
||||
---
|
||||
|
||||
### 3.3 完整矩阵图
|
||||
|
||||
```
|
||||
Redis缓存 Redis队列
|
||||
┌──────────────────┬───────────┬────────────┐
|
||||
│ ASL │ 🔴 必须 │ 🔴 必须 │ ← 最重要
|
||||
│ DC (Tool B) │ 🔴 必须 │ 🔴 必须 │ ← 最重要
|
||||
├──────────────────┼───────────┼────────────┤
|
||||
│ DC (Tool A) │ ❌ 不需要 │ ✅ 推荐 │
|
||||
│ PKB │ ✅ 推荐 │ ✅ 推荐 │
|
||||
│ SSA │ ⚠️ 可选 │ ✅ 推荐 │
|
||||
├──────────────────┼───────────┼────────────┤
|
||||
│ AIA │ ✅ 推荐 │ ❌ 不需要 │
|
||||
│ DC (Tool C) │ ✅ 推荐 │ ❌ 不需要 │
|
||||
│ RVW │ ✅ 推荐 │ ⚠️ 可选 │
|
||||
├──────────────────┼───────────┼────────────┤
|
||||
│ ST │ ❌ 不需要 │ ❌ 不需要 │ ← 完全不需要
|
||||
└──────────────────┴───────────┴────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. 实施优先级建议
|
||||
|
||||
### 4.1 Phase 1：必须实施（本周）✅
|
||||
|
||||
#### **目标：保证核心功能可用**
|
||||
|
||||
```
|
||||
优先级P0（紧急，必须）：
|
||||
1. ASL模块
|
||||
- ✅ Redis缓存（LLM结果）
|
||||
- ✅ Redis队列（批量筛选）
|
||||
|
||||
2. DC Tool B模块
|
||||
- ✅ Redis缓存（健康检查 + LLM结果）
|
||||
- ✅ Redis队列（批量提取）
|
||||
|
||||
工作量：5天
|
||||
风险：高（不做会导致严重用户体验问题）
|
||||
收益：避免95%任务失败率 + 节省60% LLM成本
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 4.2 Phase 2：推荐实施（下周）⭐
|
||||
|
||||
#### **目标：提升用户体验，降低运营成本**
|
||||
|
||||
```
|
||||
优先级P1（重要，推荐）：
|
||||
3. PKB模块
|
||||
- ✅ Redis缓存（RAG问答）
|
||||
- ✅ Redis队列（批量上传）
|
||||
|
||||
4. DC Tool A模块
|
||||
- ✅ Redis队列（数据合并）
|
||||
|
||||
5. AIA模块
|
||||
- ✅ Redis缓存（常见问答）
|
||||
|
||||
工作量：3天
|
||||
风险：中（不做会影响用户满意度）
|
||||
收益：提升30%响应速度 + 节省30% LLM成本
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 4.3 Phase 3：可选实施（未来）⏳
|
||||
|
||||
#### **目标：锦上添花，优化体验**
|
||||
|
||||
```
|
||||
优先级P2-P3（次要，可选）：
|
||||
6. SSA模块
|
||||
- ⚠️ Redis队列（预测模型训练）
|
||||
|
||||
7. DC Tool C模块
|
||||
- ✅ Redis缓存（AI代码生成）
|
||||
|
||||
8. RVW模块
|
||||
- ✅ Redis缓存（方法学评估）
|
||||
- ⚠️ Redis队列（批量审稿）
|
||||
|
||||
工作量：2天
|
||||
风险：低
|
||||
收益：优化体验
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 4.4 不需要实施 ❌
|
||||
|
||||
```
|
||||
ST模块：
|
||||
- ❌ 完全不需要Redis
|
||||
- 理由：纯统计计算，极快（< 1秒）
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 成本效益分析
|
||||
|
||||
### 5.1 Redis成本
|
||||
|
||||
```
|
||||
阿里云Redis（256MB 高可用版）：
|
||||
- 首年成本：¥108（6折后）
|
||||
- 续费成本：¥180/年
|
||||
- 平均成本：¥144/年
|
||||
```
|
||||
|
||||
### 5.2 收益分析（年度）
|
||||
|
||||
#### **直接成本节省（LLM API费用）**
|
||||
|
||||
| 模块 | 年节省 | 说明 |
|
||||
|------|--------|------|
|
||||
| ASL | ¥9,360 | 缓存命中70%，每月10次任务 |
|
||||
| DC Tool B | ¥3,096 | 缓存命中50%，每月5次任务 |
|
||||
| PKB | ¥1,200 | 缓存命中40%，每月10次任务 |
|
||||
| AIA | ¥2,400 | 缓存命中40%，每月20次任务 |
|
||||
| 其他 | ¥1,500 | Tool C, RVW等 |
|
||||
| **合计** | **¥17,556** | |
|
||||
|
||||
#### **间接收益（用户体验提升）**
|
||||
|
||||
```
|
||||
任务成功率提升：
|
||||
- 从 10-30% → 99%+
|
||||
- 减少用户投诉：80-90%
|
||||
- 提升用户满意度：显著
|
||||
- 降低流失率：预计降低50%
|
||||
|
||||
响应速度提升：
|
||||
- LLM调用：从5秒 → 50ms（缓存命中）
|
||||
- 用户感知：明显提升
|
||||
|
||||
运营成本降低：
|
||||
- 减少客服工作量：70%
|
||||
- 减少退款/补偿：¥5,000/年
|
||||
```
|
||||
|
||||
### 5.3 ROI计算
|
||||
|
||||
```
|
||||
年度投资：¥144（Redis成本）
|
||||
年度收益：¥17,556（LLM成本节省）+ ¥5,000（运营成本）= ¥22,556
|
||||
|
||||
ROI = (¥22,556 - ¥144) / ¥144 × 100% = 15,564%
|
||||
|
||||
结论：每投入¥1，回报¥156
|
||||
```
|
||||
|
||||
### 5.4 不同规模下的ROI
|
||||
|
||||
| 用户规模 | LLM成本节省 | 运营成本节省 | Redis成本 | ROI |
|
||||
|---------|-----------|------------|----------|-----|
|
||||
| **小规模（10用户）** | ¥5,000 | ¥1,000 | ¥144 | 4,072% |
|
||||
| **中规模（50用户）** | ¥17,556 | ¥5,000 | ¥144 | 15,564% |
|
||||
| **大规模（200用户）** | ¥70,000 | ¥20,000 | ¥180 | 49,900% |
|
||||
|
||||
**结论**：用户规模越大，ROI越高！
|
||||
|
||||
---
|
||||
|
||||
## 6. 最终建议
|
||||
|
||||
### 6.1 明确结论
|
||||
|
||||
```
|
||||
问题：我们所有功能都需要Redis吗？
|
||||
答案：❌ 不是的！
|
||||
|
||||
需要Redis的模块：
|
||||
✅ ASL（必须：缓存+队列）
|
||||
✅ DC Tool B（必须：缓存+队列）
|
||||
✅ PKB（推荐：缓存+队列）
|
||||
✅ DC Tool A（推荐：队列）
|
||||
✅ AIA（推荐：缓存）
|
||||
⚠️ SSA（可选：队列）
|
||||
⚠️ RVW（可选：缓存+队列）
|
||||
|
||||
不需要Redis的模块：
|
||||
❌ ST（完全不需要）
|
||||
❌ DC Tool C（不需要队列，缓存可选）
|
||||
```
|
||||
|
||||
### 6.2 实施策略
|
||||
|
||||
```
|
||||
务实的渐进式实施：
|
||||
|
||||
第1周（必须）：
|
||||
- ✅ ASL + DC Tool B
|
||||
- 理由：2小时任务，不用Redis会有95%失败率
|
||||
|
||||
第2周（推荐）：
|
||||
- ✅ PKB + DC Tool A + AIA
|
||||
- 理由：提升用户体验，降低成本
|
||||
|
||||
第3周+（可选）：
|
||||
- ⏳ SSA + RVW
|
||||
- 理由：锦上添花
|
||||
|
||||
永远不做：
|
||||
- ❌ ST
|
||||
- 理由：完全没必要
|
||||
```
|
||||
|
||||
### 6.3 给产品经理的建议
|
||||
|
||||
```
|
||||
如果您问："我们要不要用Redis？"
|
||||
|
||||
我的回答是：
|
||||
1. ✅ 必须用，但不是所有模块都用
|
||||
2. ✅ 优先实施核心模块（ASL、DC Tool B）
|
||||
3. ✅ 其他模块根据实际情况决定
|
||||
4. ✅ ST模块完全不需要
|
||||
|
||||
如果您担心成本：
|
||||
- Redis年费：¥144
|
||||
- 节省LLM成本：¥17,556/年
|
||||
- ROI：15,564%
|
||||
- 结论：不用Redis才是最大的成本浪费！
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. 常见问题
|
||||
|
||||
### Q1：如果暂时只实施ASL和DC Tool B，其他模块会有问题吗？
|
||||
**A1**：不会有严重问题。
|
||||
|
||||
```
|
||||
其他模块影响：
|
||||
- PKB：可能偶尔任务丢失（10-20%概率）
|
||||
- DC Tool A：同上
|
||||
- AIA：可能LLM重复调用，成本略高
|
||||
- SSA：可能任务丢失
|
||||
- Tool C, ST：完全没影响
|
||||
```
|
||||
|
||||
### Q2：256MB Redis够用吗？
|
||||
**A2**：完全够用！
|
||||
|
||||
```
|
||||
内存占用预估：
|
||||
- LLM结果缓存：50MB
|
||||
- 任务队列数据：10MB
|
||||
- 系统开销：20MB
|
||||
─────────────────────
|
||||
总计：80MB / 256MB = 31%
|
||||
|
||||
结论：256MB足够支撑100用户规模
|
||||
```
|
||||
|
||||
### Q3：不用Redis队列，用数据库队列可以吗？
|
||||
**A3**：可以但不推荐。
|
||||
|
||||
```
|
||||
对比：
|
||||
Redis队列 数据库队列
|
||||
响应速度 < 1ms > 10ms
|
||||
功能完善度 ⭐⭐⭐⭐⭐ ⭐⭐⭐
|
||||
社区支持 ⭐⭐⭐⭐⭐ ⭐⭐
|
||||
开发成本 低（BullMQ） 中等
|
||||
|
||||
结论：您已经购买了Redis，没理由不用
|
||||
```
|
||||
|
||||
### Q4：能否只用Redis缓存，不用队列？
|
||||
**A4**：可以，但核心功能会不可用。
|
||||
|
||||
```
|
||||
只用Redis缓存的结果：
|
||||
✅ LLM成本控制：可以实现
|
||||
✅ 响应速度提升：可以实现
|
||||
❌ 长任务可靠性：无法保证（ASL、DC Tool B会有95%失败率）
|
||||
❌ 用户体验：极差
|
||||
|
||||
建议：缓存+队列一起实施
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8. 总结
|
||||
|
||||
### 核心要点
|
||||
|
||||
1. **不是所有模块都需要Redis**
|
||||
- 7个模块中，2个必须，4个推荐，1个不需要
|
||||
|
||||
2. **Redis的核心价值**
|
||||
- LLM成本节省：¥17,556/年
|
||||
- 任务可靠性：从30% → 99%+
|
||||
- 用户体验：显著提升
|
||||
|
||||
3. **优先级明确**
|
||||
- P0（必须）：ASL、DC Tool B
|
||||
- P1（推荐）：PKB、DC Tool A、AIA
|
||||
- P2-P3（可选）：SSA、RVW、DC Tool C
|
||||
- 不需要：ST
|
||||
|
||||
4. **投资回报率极高**
|
||||
- 投入：¥144/年
|
||||
- 回报：¥22,556/年
|
||||
- ROI：15,564%
|
||||
|
||||
5. **实施策略**
|
||||
- 渐进式：先核心，后周边
|
||||
- 务实：不过度设计
|
||||
- 灵活：根据实际情况调整
|
||||
|
||||
---
|
||||
|
||||
**文档维护者：** 技术团队
|
||||
**最后更新：** 2025-12-12
|
||||
**相关文档：**
|
||||
- [Redis改造实施计划](./04-Redis改造实施计划.md)
|
||||
- [Redis缓存与队列的区别说明](./05-Redis缓存与队列的区别说明.md)
|
||||
- [长时间任务可靠性分析](./06-长时间任务可靠性分析.md)
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user