34047007@qq.com
a6cd99a4ca
OncoLit: a multi-tenant oncology literature search, feed, and collaboration platform. Built with FastAPI + Vue 3 + PostgreSQL. Includes PubMed pipeline, drug approvals, AI summaries, and systematic review tools.
679 lines
30 KiB
Markdown
679 lines
30 KiB
Markdown
# AI 辅助功能规划
|
||
|
||
> 最后更新：2026-07-12
|
||
|
||
## 一、定位与分级
|
||
|
||
### 核心理念
|
||
|
||
按**用户投入度**分级——用得越深，价值越大，付费意愿越强。
|
||
|
||
| 层级 | 本质 | 用户投入 | 付费天花板 |
|
||
|---|---|---|---|
|
||
| Tier 1 AI 解读 | 一次性信息压缩 | 零（进来就看） | 免费/专业版 |
|
||
| Tier 2 知识库 + RAG | 持续积累的结构化资产 | 收藏/上传即建库 | 专业版/团队版 |
|
||
| Tier 3 个性化 AI | 主动助手，按需配置 | 设定研究方向/模板 | 团队版 |
|
||
|
||
### 与现有功能的关系
|
||
|
||
文献 `ai_summary` JSON 列已存在，但管道导入不生成，**全部 1.4M 基线文献 `ai_summary` 均为 NULL**。Tier 1 的核心是：有缓存直接展示，无缓存显示"生成 AI 解读"按钮，用户点击后调用 DeepSeek 并持久化到数据库。Tier 2 和 3 是全新功能，需要新建数据模型和服务。
|
||
|
||
### 与评分系统的协同
|
||
|
||
评分系统解决**"哪篇值得读"**，AI 辅助解决**"读完后得到了什么"**。评分在前端排序层，AI 在内容展示层，互不依赖但互补——高分文献自动获得更深入的 AI 解读。
|
||
|
||
---
|
||
|
||
## 二、Tier 1：AI 文献解读
|
||
|
||
### 定位
|
||
|
||
**不改变用户习惯，进来就看。** 核心价值是省时间，降低文献阅读的认知负担。
|
||
|
||
### 功能
|
||
|
||
| 功能 | 数据来源 | 当前状态 |
|
||
|---|---|---|
|
||
| 一句话总结（one-liner） | `ai_summary.summary` | 空（需按需生成） |
|
||
| 结构化解读（背景/方法/结果/结论） | `ai_summary.sections` | 空（需按需生成） |
|
||
| 中文翻译 | `ai_summary.translation` | 空（需按需生成） |
|
||
| PICO 抽取 | `pico` 字段（population/intervention/comparison/outcome） | Meta 分析已有，前端未展示 |
|
||
| 关键数据提取 | `ai_summary.tables`（样本量、HR、PFS/OS 等） | 后端无此格式，需新增输出模板 |
|
||
|
||
### 前端展示
|
||
|
||
在文献详情页新增「AI 解读」标签页，与「摘要」「全文」并列：
|
||
|
||
```
|
||
┌──────────────────────────────────────────────┐
|
||
│ 摘要 │ AI 解读 │ 全文 ← 标签页切换 │
|
||
├──────────────────────────────────────────────┤
|
||
│ │
|
||
│ 一句话总结 │
|
||
│ 这项 III 期研究显示 Amivantamab 联合化疗比化 │
|
||
│ 疗显著改善 PFS（9.2 vs 5.8 月），可能改变 │
|
||
│ EGFR Exon20ins 一线标准。 │
|
||
│ │
|
||
│ ── 研究背景 ── │
|
||
│ EGFR Exon20ins 对传统 TKI 不敏感... │
|
||
│ │
|
||
│ ── 关键数据 ── │
|
||
│ │ 指标 │ 试验组 │ 对照组 │ HR │ │
|
||
│ │ mPFS │ 9.2mo │ 5.8mo │ 0.58 │ │
|
||
│ │ 客观缓解率 │ 53% │ 29% │ │ │
|
||
│ │ 3级AE │ 42% │ 36% │ │ │
|
||
│ │
|
||
│ ── 临床意义 ── │
|
||
│ 首个针对 EGFR Exon20ins 一线 III 期数据， │
|
||
│ 已纳入 NCCN 指南推荐。 │
|
||
└──────────────────────────────────────────────┘
|
||
```
|
||
|
||
### 免费 vs 付费差异
|
||
|
||
| 功能 | 免费 | 专业版 | 团队版 |
|
||
|---|---|---|---|
|
||
| 一句话总结 | ✅ 每日前 5 篇 | ✅ 无限 | ✅ 无限 |
|
||
| 结构化解读 | ❌ | ✅ | ✅ |
|
||
| 关键数据表格 | ❌ | ✅ | ✅ |
|
||
| 中文翻译 | ❌ | ✅ | ✅ |
|
||
|
||
### 执行
|
||
|
||
前端工作 + 调用已有后端 API。
|
||
|
||
- **有 `ai_summary` 的文献**（新管道导入后可能有）→ 直接渲染展示
|
||
- **无 `ai_summary` 的文献**（全部基线 1.4M 篇 + 管道未触发生成的）→ 显示「生成 AI 解读」按钮
|
||
- 用户点击 → 调 `POST /ai/generate/{pmid}` → DeepSeek 生成 → 写入 `ai_summary` JSON 列 → 返回前端展示
|
||
- 后续任何用户打开同篇文献 → 直接命中数据库
|
||
- **不做批量预生成、无定时任务、不改变管道导入逻辑**
|
||
|
||
这个按需生成用现有 `AiProviderConfig` 配置即可，**不依赖 embedding/ES**，只取 title+abstract → DeepSeek → 入库。
|
||
|
||
|
||
---
|
||
|
||
## 三、Tier 2：知识库 + RAG
|
||
|
||
### 定位
|
||
|
||
**从"收藏夹"升级为"用户的第二个大脑"。** 用户收藏的文献、上传的文件、写的笔记，混合成一个可检索、可问答的个人知识库。
|
||
|
||
### 3.1 核心原则：收藏即建库
|
||
|
||
用户不需要做任何额外操作。收藏一篇文章，自动进入知识库。知识库不是另一个页面，而是收藏功能的自然延伸。
|
||
|
||
```
|
||
用户点击收藏
|
||
↓
|
||
写入 user_favorite（已有表）
|
||
↓
|
||
新增一条 knowledge_entry
|
||
↓
|
||
异步 embedding（ARQ 任务）
|
||
↓
|
||
写入 ES 向量索引
|
||
```
|
||
|
||
### 3.2 多源融合
|
||
|
||
知识库不只装文献，而是三类数据的混合：
|
||
|
||
| 来源 | 进入方式 | 存储 |
|
||
|---|---|---|
|
||
| 平台文献 | 用户收藏/评分（自动） | 已有 DB + ES |
|
||
| 用户笔记 | 在文献详情页写笔记（自动关联） | 已有 notes 表 |
|
||
| 用户上传文件 | 手动上传 PDF/Word/PPT/Markdown | 对象存储 MinIO/COS |
|
||
| 第三方文档 | 乐享集成/本地同步（预留接口） | 适配器模式 |
|
||
|
||
所有来源统一进入 `knowledge_entries` 表，统一 embedding，统一检索。
|
||
|
||
### 3.3 RAG 问答
|
||
|
||
用户在知识库页面提问，基于自己的知识库回答：
|
||
|
||
```
|
||
用户提问：EGFR 20ins 耐药机制有哪些？
|
||
↓
|
||
1. query embedding（调 embedding 服务转为向量）
|
||
↓
|
||
2. 向量检索（ES knn，过滤 tenant + user，top_k=8）
|
||
↓
|
||
3. 召回结果 + metadata 拼入 prompt
|
||
↓
|
||
4. DeepSeek 生成回答 + 标注引用来源
|
||
```
|
||
|
||
引用来源标注：
|
||
|
||
```
|
||
回答：
|
||
目前针对 EGFR Exon20ins 的耐药机制主要包括...
|
||
|
||
参考文献：
|
||
[1] Amivantamab in EGFR Exon20ins NSCLC... (PMID: 38712345)
|
||
[2] Mobocertinib 耐药机制分析... (您收藏的文献)
|
||
[3] 您整理的耐药机制笔记.docx (您上传的文件)
|
||
```
|
||
|
||
### 3.4 知识图谱（分步实施）
|
||
|
||
#### 设计说明
|
||
|
||
知识图谱不是 RAG 的前置依赖，而是在 RAG 有了用户和内容之后**自然长出**的增值特性。RAG 擅长"找相似文本"，图谱擅长"看关系路径"——两者互补。
|
||
|
||
不存在时先不产生价值，与其急着做不如等用户有数据积累后再做。
|
||
|
||
#### Phase 1：共现关系图谱（最简单，有收藏数据即可跑）
|
||
|
||
```
|
||
用户收藏了 100 篇文献
|
||
↓
|
||
后台 NER 提取药物、基因、疾病、研究类型等实体
|
||
↓
|
||
同一篇文献中出现的实体自动建立共现关系
|
||
↓
|
||
前端展示为"探索"视图：实体节点 + 关联线
|
||
```
|
||
|
||
用户看到的是：
|
||
```
|
||
[奥希替尼] ─── 出现在 12 篇收藏中 ─── [EGFR Exon19del]
|
||
│ │
|
||
│ 出现在 5 篇收藏中 │ 出现在 8 篇收藏中
|
||
│ │
|
||
[Amivantamab] ─── 出现在 3 篇收藏中 ─── [EGFR Exon20ins]
|
||
```
|
||
|
||
对用户的价值：**"我收藏的文献里，哪些概念是关联的？"**——帮助用户发现自己的知识盲区或研究热点。
|
||
|
||
#### Phase 2：外部知识融合（需要对接外部数据源）
|
||
|
||
将 PubChem、DrugBank、ClinicalTrials.gov 的结构化关系导入，叠加在用户图谱之上：
|
||
|
||
```
|
||
[奥希替尼] ── 靶向 ──→ [EGFR T790M] ← 权威层 (DrugBank)
|
||
[奥希替尼] ── 获批适应症 ──→ [NSCLC] ← 权威层
|
||
[奥希替尼] ── 用户标注 ──→ [耐药机制笔记] ← 用户层
|
||
```
|
||
|
||
两层叠加：用户看到的不只是"哪些文献提到了奥希替尼"，还包括"奥希替尼的靶点是什么、获批了哪些适应症"。
|
||
|
||
#### Phase 3：图谱问答（融合 RAG + Graph）
|
||
|
||
用户问"奥希替尼耐药后有哪些方案"，系统先查图谱关系链：
|
||
|
||
```
|
||
[奥希替尼] ── 耐药后方案 ──→ [Amivantamab, 化疗, MET抑制剂...]
|
||
↓
|
||
找到关联文献（每篇文献可能对应多个方案）
|
||
↓
|
||
RAG 检索具体数据（HR、PFS、OS）
|
||
↓
|
||
回答："奥希替尼耐药后可选方案包括：1) Amivantamab + 化疗（mPFS 9.2mo）..."
|
||
```
|
||
|
||
**这本质是 GraphRAG，但对当前阶段太远了。** Phase 1-2 足够先用起来。
|
||
|
||
### 3.5 数据模型
|
||
|
||
```python
|
||
class KnowledgeEntry(Base):
|
||
"""知识库条目——收藏/上传/笔记的统一入口"""
|
||
__tablename__ = "knowledge_entries"
|
||
|
||
id: Mapped[uuid.UUID] = mapped_column(primary_key=True)
|
||
tenant_id: Mapped[uuid.UUID] = mapped_column(ForeignKey("tenants.id"))
|
||
user_id: Mapped[uuid.UUID] = mapped_column(ForeignKey("users.id"))
|
||
|
||
entry_type: Mapped[str] # literature | note | file
|
||
source_type: Mapped[str | None] # global_literature | user_note | upload
|
||
source_id: Mapped[str | None] # pmid | note_id | upload_id
|
||
|
||
chunk_text: Mapped[str] # 分块后的文本
|
||
chunk_index: Mapped[int] # 第几块（一篇文献可多块）
|
||
metadata: Mapped[dict | None] # JSON，来源/页码/标签
|
||
|
||
embedding_id: Mapped[str | None] # ES doc id
|
||
is_embedded: Mapped[bool] = mapped_column(default=False)
|
||
created_at: Mapped[datetime] = mapped_column(server_default=func.now())
|
||
```
|
||
|
||
### 3.6 前端展示
|
||
|
||
知识库页面布局：
|
||
|
||
```
|
||
┌──────────────────────────────────────────────────┐
|
||
│ 🔍 搜索知识库... 视图切换 │
|
||
├──────────────────────────────────────────────────┤
|
||
│ 筛选: 全部 | 文献 | 笔记 | 上传文件 │
|
||
├──────────────────────────────────────────────────┤
|
||
│ ┌────────────────────┐ ┌────────────────────┐ │
|
||
│ │ 📄 肺癌新辅助免疫 │ │ 📎 耐药机制笔记 │ │
|
||
│ │ 治疗III期研究... │ │ 上传 2026-07-11 │ │
|
||
│ │ 收藏 2026-07-10 │ │ 2页 · docx │ │
|
||
│ │ EGFR, 免疫治疗 │ │ │ │
|
||
│ └────────────────────┘ └────────────────────┘ │
|
||
│ ┌────────────────────────────────────────┐ │
|
||
│ │ 💬 问你的知识库... [发送] │ │
|
||
│ └────────────────────────────────────────┘ │
|
||
└──────────────────────────────────────────────────┘
|
||
```
|
||
|
||
同时保留现有 LibraryView（收藏夹管理），在其上加一个入口："探索知识库"。
|
||
|
||
---
|
||
|
||
## 四、Tier 3：个性化 AI
|
||
|
||
### 定位
|
||
|
||
**从"被动应答"到"主动理解"。** 用户告诉 AI 自己的研究方向，AI 据此调整所有解读的角度。
|
||
|
||
### 4.1 研究方向配置
|
||
|
||
用户设定：
|
||
|
||
```json
|
||
{
|
||
"direction": "肺癌靶向治疗和耐药机制",
|
||
"focus": ["EGFR突变", "耐药机制", "双抗"],
|
||
"patient_population": "EGFR突变NSCLC患者",
|
||
"preferred_therapy": ["靶向治疗", "ADC"],
|
||
"avoid": ["基础研究", "cell line实验"]
|
||
}
|
||
```
|
||
|
||
设定后，Tier 1 和 Tier 2 的所有输出自动适配：
|
||
|
||
| 场景 | 无研究方向时 | 有研究方向时 |
|
||
|---|---|---|
|
||
| AI 解读 | 标准结构化摘要 | 重点突出 EGFR 相关数据、耐药机制讨论 |
|
||
| RAG 问答 | 泛泛回答 | 优先引用靶向治疗相关的收藏文献 |
|
||
| 每日 Feed | 按评分排序 | 研究方向相关文献自动提升优先级 |
|
||
|
||
### 4.2 自定义 Prompt 模板（高阶）
|
||
|
||
用户可编写自己的 AI 解读模板：
|
||
|
||
```
|
||
用户预设模板（免疫方向）：
|
||
"请重点分析：1) 肿瘤微环境相关数据（TIL、PD-L1、TMB）
|
||
2) 免疫相关不良事件（irAE）的发生率和处理
|
||
3) 生物标志物分析（如适用）"
|
||
|
||
→ 之后每次 AI 解读都按此模板执行
|
||
```
|
||
|
||
实现方式：prompt 模板不涉及后端改动，在 `AiProviderConfig` 的 prompt 字段中附加用户模板。每次调用 DeepSeek 时拼接。
|
||
|
||
### 4.3 多模型选择
|
||
|
||
| 模型 | 用途 | 成本 | 适用层级 |
|
||
|---|---|---|---|
|
||
| DeepSeek（默认） | 日常解读、RAG 问答 | 低 | Tier 1+2 |
|
||
| GPT-4o | 深度分析、复杂推理 | 高 | Tier 3 |
|
||
| 本地模型（Ollama） | 敏感数据不经过外网 | 零 API 费用 | 团队版私有部署 |
|
||
|
||
用户可在设置中选择默认模型。不同模型走不同的 API Key 配置（`AiProviderConfig` 已有此设计）。
|
||
|
||
### 4.4 免费 vs 付费差异
|
||
|
||
| 功能 | 免费 | 专业版 | 团队版 |
|
||
|---|---|---|---|
|
||
| 研究方向配置 | ❌ | ✅ 1 个方向 | ✅ 不限 |
|
||
| AI 解读按方向适配 | ❌ | ✅ | ✅ |
|
||
| 自定义 prompt 模板 | ❌ | ❌ | ✅（管理员设） |
|
||
| 多模型选择 | ❌ | ❌ | ✅ |
|
||
| 模型调用量配额 | 5 次/天 | 50 次/天 | 按需 |
|
||
|
||
---
|
||
|
||
## 五、执行顺序
|
||
|
||
```
|
||
Phase 1 Tier 1 AI 解读前端 + 按需生成（合并原 Phase 1 + Phase 5）
|
||
读写：LiteratureDetailView.vue 新增 AI 解读标签页 + "生成"按钮
|
||
依赖：`ai_summary` JSON 列 + POST /ai/generate/{pmid} API（均有）
|
||
说明：无批量预生成，全部用户触发。不依赖 embedding/ES。
|
||
|
||
Phase 2 Tier 2 基础——收藏即入知识库
|
||
读写：knowledge_entries 表 + 收藏时自动插入
|
||
依赖：无（新增模型 + 简单逻辑）
|
||
注意：此阶段不上 embedding 和 RAG，只做"浏览我的知识库"
|
||
|
||
Phase 3 Tier 2 增强——embedding + 全文搜索
|
||
读写：embedding 服务 + ES 向量索引 + ARQ 任务
|
||
依赖：需要部署 embedding 模型（bge-m3）
|
||
注意：此阶段仍不上 RAG Q&A，知识库可搜索即可
|
||
|
||
Phase 4 Tier 2 完成——RAG 问答
|
||
读写：POST /kb/ask API + 前端对话界面
|
||
依赖：Phase 3 完成后才可检索
|
||
|
||
Phase 5 知识图谱 Phase 1——共现关系图谱
|
||
读写：NER 抽取 + 实体-关系存储 + 前端探索视图
|
||
依赖：用户收藏达到一定量级（建议 500+ 条/租户）
|
||
|
||
Phase 6 Tier 3 个性化 AI
|
||
读写：研究方向配置 UI + prompt 模板 + 模型选择
|
||
依赖：Tier 1+2 稳定运行，有活跃用户
|
||
|
||
Phase 7 Tier 2 用户上传文件
|
||
读写：文件上传 API + 解析（PDF/Word） + 入知识库
|
||
依赖：对象存储基础设施已就绪
|
||
|
||
Phase 8 知识图谱 Phase 2——外部知识融合
|
||
...
|
||
```
|
||
|
||
### 分阶段原则
|
||
|
||
- **Phase 1 可独立上线**——前端 + 调用已有 API，无外部依赖。基线文献全部无 AI 摘要，默认展示"生成"按钮
|
||
- **Phase 2-4 是 Tier 2 的三步走**——先不 embed 先可浏览，再可搜索，再可问答。**每一步都能独立上线，每一步都比上一步更有价值**
|
||
- **Phase 5 不急于做**——等用户收藏量上来再做，不然图谱是空的
|
||
- **Phase 6+ 依赖活跃用户基础**
|
||
|
||
---
|
||
|
||
## 六、基础设施依赖
|
||
|
||
**Tier 1（AI 解读）无需新基础设施**——复用现有 DeepSeek API（`AiProviderConfig`）、`ai_summary` 字段、`POST /ai/generate/{pmid}` 端点。不依赖 embedding/ES。
|
||
|
||
以下为 Tier 2/3 及图谱所需的新组件：
|
||
|
||
| 新组件 | 用途 | 用于 Tier | 可复用现有 |
|
||
|---|---|---|---|
|
||
| `knowledge_entries` 表 | 知识库条目 | Tier 2 | ❌ 新表 |
|
||
| embedding 服务 | 文本→向量 | Tier 2+3 | ❌ 新部署 |
|
||
| ES dense_vector 索引 | 向量存储 | Tier 2 | ✅ ES 已有 |
|
||
| NER 抽取服务 | 实体识别 | 图谱 | ❌ 新服务 |
|
||
| 对象存储（文件上传） | PDF/Word 存储 | Tier 2 | ✅ MinIO/COS 已有 |
|
||
| 文件解析服务 | PDF→文本 | Tier 2 | ❌ 新模块 |
|
||
|
||
**embedding 服务部署建议：**
|
||
|
||
用 `sentence-transformers` + `bge-m3` 模型，FastAPI 包装。单容器 2GB 内存，CPU 推理足够（每日 ~50 个收藏动作）。先部署一个最小实例，不够再加 GPU。
|
||
|
||
```python
|
||
# embedding_service.py（示意）
|
||
from sentence_transformers import SentenceTransformer
|
||
|
||
model = SentenceTransformer("BAAI/bge-m3")
|
||
|
||
@app.post("/embed")
|
||
async def embed(texts: list[str]):
|
||
embeddings = model.encode(texts, normalize_embeddings=True)
|
||
return {"embeddings": embeddings.tolist()}
|
||
```
|
||
|
||
---
|
||
|
||
## 七、AI 辅助科研（未来方向）
|
||
|
||
### 7.1 定位与前提
|
||
|
||
> 从"帮医生省时间读文献"升级到"帮医生发现研究机会"。
|
||
>
|
||
> 前三个 Tier 解决的是**信息过载**（Tier 1 → 省时间、Tier 2 → 建知识库、Tier 3 → 个性化），AI 辅助科研解决的是**知识到洞察的跨越**。
|
||
|
||
**关键判断：** AI 辅助科研不是独立产品，而是现有 73 万篇肿瘤文献数据库 + AI 能力之上的一层分析应用。不做垂直的"科研 AI 平台"，而是让用户在看完文献后，自然产生下一步研究思路。
|
||
|
||
**前提条件（当前阶段不实现）：**
|
||
- 基线导入完成，数据库稳定在 100 万+ 篇文献
|
||
- ClinicalTrials.gov 集成完成（[数据源计划](docs/05-数据源丰富计划.md)）
|
||
- PubChem 或 DrugBank 集成完成
|
||
- 有活跃的付费用户基础（专业版/团队版）
|
||
|
||
### 7.2 功能矩阵
|
||
|
||
| 功能 | 核心能力 | 数据依赖 | 价值 | 复杂度 |
|
||
|---|---|---|---|---|
|
||
| 趋势扫描 | MeSH 标签时间序列分析 | 仅需现有数据库 | 发现热点/冷点 | 低 |
|
||
| 空白分析 | 研究设计 × 癌种 × 药物交叉 | 现有 DB + ClinicalTrials | 发现未被充分研究的领域 | 中 |
|
||
| 证据综合 | 系统性综述辅助（PRISMA 流程） | 现有 DB + 搜索 | 加速综述写作 | 中 |
|
||
| 假设生成 | 跨领域关联推理 | 现有 DB + 外部知识库 | 新研究思路 | 高 |
|
||
| 写作辅助 | 引用推荐 + 文献综述段落生成 | 现有 DB + RAG | 提高论文写作效率 | 中 |
|
||
|
||
### 7.3 功能详解
|
||
|
||
#### 7.3.1 趋势扫描（Research Trend Scout）
|
||
|
||
**本质：** 把 MeSH 标签当成时间序列，看什么在增长、什么在衰退。
|
||
|
||
**数据基础：** 我们的数据库按年组织，每条文献有 MeSH 标签。统计每年每个标签下的文献数量，就能画出趋势线。
|
||
|
||
```
|
||
标签：双特异性抗体（Bispecific Antibodies）
|
||
|
||
2021: 12 篇 ████████
|
||
2022: 28 篇 ██████████████████
|
||
2023: 45 篇 ██████████████████████████████
|
||
2024: 89 篇 ██████████████████████████████████████████████████████
|
||
2025: 142 篇 ████████████████████████████████████████████████████████████████████████████████
|
||
|
||
增长率: 2024→2025 = +59.6%
|
||
相关标签: ADC, CD3, DLL3, 血液肿瘤, 实体瘤
|
||
```
|
||
|
||
**用户价值：**
|
||
- 肿瘤科主任了解领域全貌："今年肺癌免疫治疗还有哪些新方向？"
|
||
- 研究生选题："有什么快速增长但还不太卷的方向？"
|
||
- MDT 团队规划："我们科室应该关注哪些新技术？"
|
||
|
||
**实现路径：**
|
||
- 不需要新数据源，只用现有 `global_literature` + `global_literature_tags`
|
||
- 按年统计每个标签的文献数 → 计算增长率（YoY, 3-year CAGR）
|
||
- 标签间相关性分析（哪些标签经常同篇出现 → 发现研究热点群组）
|
||
- 前端：趋势线图 + 热力图 + 标签关联网络
|
||
|
||
**复杂度评估：低。** 纯 SQL 聚合 + 前端图表。后端 100 行代码，前端可复用现有图表组件。
|
||
|
||
#### 7.3.2 空白分析（Research Gap Analyzer）
|
||
|
||
**本质：** 已知某药物在某癌种有效，但同一机制在其他癌种是否被研究过？
|
||
|
||
**典型场景：**
|
||
- "免疫治疗在胰腺癌中为什么失败率高？有多少研究涉及？"
|
||
- "ADC 药物在 HER2-low 乳腺癌之外，哪些癌种也有 HER2 低表达？"
|
||
- "哪个癌种在 2026 年还没有 III 期 RCT 更新？"
|
||
|
||
**数据基础：**
|
||
- 现有数据库：文献总量 + 研究设计分类 + PICO
|
||
- ClinicalTrials.gov（需集成）：临床试验全景
|
||
- PubChem/DrugBank：药物-靶点关系
|
||
|
||
**分析维度交叉：**
|
||
|
||
```
|
||
NSCLC SCLC Breast Pancreatic CRC Gastric
|
||
免疫治疗 ████ ██ ███ ██ ██ ██
|
||
ADC ███ █ ████ █ █ █
|
||
CAR-T █ ███ ██ █ ██ █
|
||
双抗 ██ █ ██ █ █ ██
|
||
T cell engager █ █ █ █ ██ █
|
||
|
||
色阶: █=1-10篇 ██=11-50 ███=51-200 ████=200+
|
||
空白 = 该领域几乎没有研究 = 潜在的研究方向
|
||
```
|
||
|
||
**用户价值：**
|
||
- 帮助研究者找到真正的研究空白（不是"没人做过"而是"有理论基础但没人做过"）
|
||
- 基金申请时用来论证"本研究填补了XX空白"
|
||
- 科室科研规划时明确投入方向
|
||
|
||
**复杂度评估：中。** 主要是 ClinicalTrials.gov 的集成工作量。数据集成本身已在规划中（参考数据源丰富计划），分析逻辑本身不复杂。
|
||
|
||
#### 7.3.3 证据综合（Evidence Synthesis / AI Systematic Review）
|
||
|
||
**本质：** 系统性综述是肿瘤学研究的核心方法。AI 不是替代研究者，而是把最机械的部分自动化。
|
||
|
||
**用户旅程：**
|
||
|
||
```
|
||
研究者提出 PICOS 问题:
|
||
"在 EGFR 20ins NSCLC 中，Amivantamab 对比化疗的疗效和安全性？"
|
||
|
||
Step 1: AI 生成搜索策略
|
||
└→ 自动构造 PubMed 查询语句
|
||
└→ 推荐 MeSH 词 + 自由词组合
|
||
└→ 输出 PRISMA 流程图可用的搜索策略
|
||
|
||
Step 2: 检索 + 去重
|
||
└→ 在我们的数据库中搜索 + 可扩展到 PubMed
|
||
└→ 自动去重（基于 PMID）
|
||
|
||
Step 3: AI 筛选（Title/Abstract）
|
||
└→ 对每篇文献判断是否符合纳入标准
|
||
└→ 输出："纳入 12 篇 / 排除 48 篇 / 存疑 5 篇（需人工判断）"
|
||
|
||
Step 4: 数据提取
|
||
└→ 从纳入文献提取：样本量、人群、干预、对照、结局
|
||
└→ 输出结构化证据表格
|
||
|
||
Step 5: 辅助合成
|
||
└→ 森林图草稿
|
||
└→ 异质性分析提示
|
||
└→ 证据质量评价（GRADE 辅助）
|
||
```
|
||
|
||
**与现有功能的关系：**
|
||
- 搜索策略生成 → 复用现有搜索 API（`search_engine.py`）
|
||
- 筛选 → 需要新的 AI 判断 pipeline
|
||
- 数据提取 → 复用现有 PICO 抽取（`pico` 字段）
|
||
- 导出 → 复用现有批量导出
|
||
|
||
**价值判断：** 这是 AI 辅助科研中**用户需求最强烈**的功能。每个肿瘤科研究生/年轻医生在写综述时都经历过"筛 3000 篇文献"的痛苦。但工程复杂度也最高。
|
||
|
||
**复杂度评估：中高。** 影响范围大（搜索 + 筛选 + 提取 + 合成），需要独立模块。建议从 Step 1-3（搜索策略 + 自动筛选）开始 MVP，确认用户买单再做 Step 4-5。
|
||
|
||
#### 7.3.4 假设生成（Hypothesis Generator）
|
||
|
||
**本质：** 跨文献、跨癌种、跨药物的模式匹配——发现"这个药在那个癌种有效，同样的机制在另一个癌种可能也有效"。
|
||
|
||
**数据驱动 vs 模型驱动：**
|
||
- **数据驱动（可行）：** 找相同靶点的药在不同癌种的疗效差异。如果 Drug X 靶向靶点 T，在 Cancer A 有阳性 III 期数据，但在 Cancer B 只有病例报告，则 Cancer B 可能是研究空白
|
||
- **模型驱动（远期）：** 让 AI 阅读大量文献后，"猜测"某个新组合可能有效。这需要更强大的推理能力和已知的知识图谱，当前阶段不建议做
|
||
|
||
**数据驱动的实现思路：**
|
||
|
||
```
|
||
1. 从 PubChem/DrugBank 获取药物-靶点关系
|
||
2. 从文献中提取药物-癌种疗效数据
|
||
3. 交叉匹配：
|
||
药物 X → 靶点 T → 在 Cancer A 有效
|
||
药物 Y → 靶点 T → 在 Cancer B 有数据吗？
|
||
4. 输出假设：
|
||
"Drug X 在 Cancer A 中显示 ORR 60%，机制是靶向 T。
|
||
Cancer C 也高度表达 T（来自文献 PMID: 12345），
|
||
但尚无 Drug X 在 Cancer C 的研究。
|
||
建议探索 Drug X 在 Cancer C 中的疗效。"
|
||
```
|
||
|
||
**复杂度评估：高。** 需要 PubChem 完整集成、药物-靶点命名标准化、实体对齐。这是最远离当前产品的能力。
|
||
|
||
#### 7.3.5 写作辅助（Writing Assistant）
|
||
|
||
**本质：** 利用文献数据库 + AI，在用户写作时提供引用推荐和背景段落。
|
||
|
||
**功能：**
|
||
- **智能引用推荐：** 用户在写"EGFR 突变在亚洲 NSCLC 患者中的发生率"时，AI 自动推荐最相关、最高引的 3-5 篇参考文献
|
||
- **文献综述段落生成：** "写一段关于 Amivantamab 临床开发历程的综述，引用关键研究"
|
||
- **格式自动匹配：** 引文格式自动转为目标期刊格式
|
||
|
||
**实现方式：**
|
||
- 引用推荐 → 基于搜索 API（已有）+ 评分排序（即将有）
|
||
- 段落生成 → 基于 RAG（Tier 2 完成后的自然延伸）
|
||
- 格式转换 → 已有导出模块
|
||
|
||
**复杂度评估：中。** Tier 2 的 RAG 完成后，写作辅助是上层应用。引用推荐最实用、最轻量，可以独立先行。
|
||
|
||
### 7.4 与现有产品的关系
|
||
|
||
```
|
||
现有产品核心：
|
||
帮用户"发现"值得读的文献
|
||
│
|
||
Tier 1-3 AI 辅助：
|
||
帮用户"理解"已发现的文献
|
||
│
|
||
AI 辅助科研（本节）：
|
||
帮用户"创造"新的知识
|
||
```
|
||
|
||
三者串起来，用户在每个环节都有价值：
|
||
|
||
```
|
||
发现 → 已有能力（标签匹配 + Feed + 搜索 + 评分排序）
|
||
↓
|
||
理解 → Tier 1-3（AI 解读 + 知识库 + 个性化）
|
||
↓
|
||
创造 → AI 辅助科研（趋势 + 空白 + 综合 + 假设 + 写作）
|
||
```
|
||
|
||
**不冲突的地方：**
|
||
- AI 辅助科研不改变 Feed/搜索/收藏等核心链路
|
||
- 是对"高级用户"（研究人员、研究生、PI）的增值功能
|
||
- 可作为独立的付费附加模块（按需付费或更高的订阅层级）
|
||
|
||
### 7.5 执行顺序与条件
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────┐
|
||
│ 条件：基线导入完成 + ClinicalTrials.gov 集成就绪 │
|
||
└─────────────────────────────────────────────────────┘
|
||
│
|
||
▼
|
||
Phase A 趋势扫描（低复杂度，独立可用）
|
||
读写：后端趋势分析 API + 前端趋势图
|
||
数据：仅需现有数据库
|
||
工期：~1 周（后端 2 天 + 前端 3 天）
|
||
|
||
Phase B 证据综合 MVP（搜索策略 + AI 筛选）
|
||
读写：AI 筛选 pipeline + PRISMA 流程管理
|
||
数据：现有 DB + DeepSeek
|
||
工期：~2 周
|
||
注意：验证用户是否愿意为"自动筛选"付费
|
||
|
||
←─ 在此验证用户需求，再决定是否继续 ─→
|
||
|
||
Phase C 空白分析
|
||
读写：ClinicaTrials 集成 + 交叉分析
|
||
数据：ClinicalTrials.gov 完整导入后
|
||
工期：依赖数据集成进度
|
||
|
||
Phase D 写作辅助
|
||
读写：引用推荐 API + 段落生成
|
||
数据：Tier 2 RAG 完成后
|
||
工期：依赖 Tier 2 进度
|
||
|
||
Phase E 假设生成
|
||
读写：PubChem 集成 + 实体对齐 + 关联推理
|
||
数据：PubChem/DrugBank 完整导入后
|
||
工期：远期
|
||
```
|
||
|
||
**核心判断：不做则已，要做就做 Phase A 先。** 趋势扫描基于现有数据，无外部依赖，是证明"AI 辅助科研"这个方向是否有用户买单的最小闭环。
|
||
|
||
### 7.6 风险与取舍
|
||
|
||
| 风险 | 说明 | 缓解措施 |
|
||
|---|---|---|
|
||
| 用户不需要"科研辅助" | 可能目标用户（临床医生）只想看文献，不想做研究 | Phase A 先验证，不做大规模开发 |
|
||
| 趋势扫描价值不够深 | 只是"统计图"，用户看一眼就完了 | 结合空白分析才有深度，但走得太快可能做无用功 |
|
||
| 证据综合做成了"学术不端"工具 | AI 写综述可能被滥用绕过真正的文献阅读 | 定位为"辅助"不是"替代"，要求人工确认每一步 |
|
||
| 数据量不够支撑有意义的趋势分析 | 73 万篇肿瘤文献对一个癌种细分后可能太少 | 先做粗粒度趋势（癌种级），细粒度（突变级）等基线完成后 |
|
||
| 合规风险（AI 辅助科研的学术诚信） | 期刊可能不允许 AI 生成内容 | 所有 AI 输出标注"AI generated"，引文必须人工验证 |
|
||
|
||
---
|
||
|
||
## 八、不做的改动
|
||
|
||
- **知识库不替代收藏夹**——收藏夹仍是"快速保存到列表"，知识库是"自动积累可检索"。两者共存，收藏夹入口保留在 LibraryView
|
||
- **不上 GraphRAG（当前阶段）**——Phase 1-2 的共现图谱已经足够提供"探索"体验，GraphRAG 的工程复杂度远高于收益，等用户量和数据量足够再说
|
||
- **不上 agents/workflow 编排**——Tier 3 的个性化只是 prompt 模板 + 模型选择，不做多 agent 编排
|
||
- **不重建文件预览**——上传的 PDF/Word 用对象存储的预览 URL 或用 iframe 嵌入，不做自建文档阅读器
|
||
- **不改变现有 Feed 引擎**——研究方向配置影响的是 AI 解读角度，不是 Feed 匹配逻辑
|
||
- **不做用户级 embedding 模型微调**——方向配置通过 prompt 工程实现，不训练模型
|