AIclinicalresearch/docs/07-运维文档/07-Redis使用需求分析(按模块).md

Redis使用需求分析（按模块）

文档版本： V1.0
创建日期： 2025-12-12
分析范围： 7大核心业务模块
目的： 明确哪些模块需要Redis，哪些不需要

---

📋 目录

1. 分析维度与标准
2. 7大模块详细分析
3. Redis需求汇总
4. 实施优先级建议
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秒
   - 无需批量处理
   - 同步返回即可

实施建议

// 示例：缓存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改造实施计划
• Redis缓存与队列的区别说明
• 长时间任务可靠性分析