Features - User Management (Phase 4.1): - Database: Add user_modules table for fine-grained module permissions - Database: Add 4 user permissions (view/create/edit/delete) to role_permissions - Backend: UserService (780 lines) - CRUD with tenant isolation - Backend: UserController + UserRoutes (648 lines) - 13 API endpoints - Backend: Batch import users from Excel - Frontend: UserListPage (412 lines) - list/filter/search/pagination - Frontend: UserFormPage (341 lines) - create/edit with module config - Frontend: UserDetailPage (393 lines) - details/tenant/module management - Frontend: 3 modal components (592 lines) - import/assign/configure - API: GET/POST/PUT/DELETE /api/admin/users/* endpoints Architecture Upgrade - Module Permission System: - Backend: Add getUserModules() method in auth.service - Backend: Login API returns modules array in user object - Frontend: AuthContext adds hasModule() method - Frontend: Navigation filters modules based on user.modules - Frontend: RouteGuard checks requiredModule instead of requiredVersion - Frontend: Remove deprecated version-based permission system - UX: Only show accessible modules in navigation (clean UI) - UX: Smart redirect after login (avoid 403 for regular users) Fixes: - Fix UTF-8 encoding corruption in ~100 docs files - Fix pageSize type conversion in userService (String to Number) - Fix authUser undefined error in TopNavigation - Fix login redirect logic with role-based access check - Update Git commit guidelines v1.2 with UTF-8 safety rules Database Changes: - CREATE TABLE user_modules (user_id, tenant_id, module_code, is_enabled) - ADD UNIQUE CONSTRAINT (user_id, tenant_id, module_code) - INSERT 4 permissions + role assignments - UPDATE PUBLIC tenant with 8 module subscriptions Technical: - Backend: 5 new files (~2400 lines) - Frontend: 10 new files (~2500 lines) - Docs: 1 development record + 2 status updates + 1 guideline update - Total: ~4900 lines of code Status: User management 100% complete, module permission system operational
226 lines
5.9 KiB
Markdown
226 lines
5.9 KiB
Markdown
# 全文复筛开发计划 - 更新说明
|
||
|
||
> **更新日期**:2025-11-22
|
||
> **版本**:V1.1
|
||
> **更新原因**:基于质量保障策略讨论,优化技术方案
|
||
|
||
---
|
||
|
||
## 📊 核心变更总结
|
||
|
||
### 1️⃣ **提取策略:全文一次性 + Prompt工程优化**
|
||
|
||
**决策**:采用全文一次性输入策略,而非分段提取
|
||
|
||
**理由**:
|
||
- ✅ 实现复杂度低(2周 vs 3周)
|
||
- ✅ 快速验证可行性
|
||
- ✅ Nougat结构化已降低大模型负担
|
||
- ✅ 先进的Prompt工程可以减轻Lost in the Middle
|
||
|
||
**核心优化**:
|
||
1. **Nougat优先**:英文论文用Nougat提取(结构化Markdown)
|
||
2. **Section-Aware Prompting**:引导LLM逐章节处理
|
||
3. **Few-shot案例库**:特别强调"信息在中间位置"的案例
|
||
4. **JSON Schema约束**:强制证据链 + 处理日志 + 自我验证
|
||
|
||
---
|
||
|
||
### 2️⃣ **模型选择:DeepSeek-V3 + Qwen3-Max**
|
||
|
||
**变更**:从 GPT-4o + Claude-4.5 改为 DeepSeek-V3 + Qwen3-Max
|
||
|
||
**理由**:
|
||
- ✅ 成本友好:¥0.06/篇 vs ¥0.10/篇(节省40%)
|
||
- ✅ 通用能力层已支持
|
||
- ✅ 中文文献友好
|
||
- ✅ MVP阶段优先验证可行性,而非追求极致准确率
|
||
|
||
---
|
||
|
||
### 3️⃣ **质量保障:Cochrane标准 + 医学逻辑验证**
|
||
|
||
**新增服务**:
|
||
1. **MedicalLogicValidator**(医学逻辑验证)
|
||
- RCT必须有随机化
|
||
- 双盲研究必须说明盲法
|
||
- 样本量与基线数据一致性
|
||
- 等...共5条规则
|
||
|
||
2. **EvidenceChainValidator**(证据链验证)
|
||
- 强制原文引用(≥50字)
|
||
- 位置信息(章节、段落)
|
||
- 处理日志验证
|
||
|
||
3. **ConflictDetectionService**(增强)
|
||
- 基于Cochrane标准的严重程度分级
|
||
- 关键字段特殊处理
|
||
|
||
---
|
||
|
||
### 4️⃣ **Prompt模板:结构化分层**
|
||
|
||
**新目录结构**:
|
||
```
|
||
prompts/
|
||
├── system_prompt.md # System Prompt(Section-Aware)
|
||
├── user_prompt_template.md # User Prompt模板
|
||
├── cochrane_standards/ # Cochrane标准描述(分字段)
|
||
│ ├── 随机化方法.md
|
||
│ ├── 盲法.md
|
||
│ ├── 结果完整性.md
|
||
│ └── ...(共12个)
|
||
└── few_shot_examples/ # Few-shot医学案例库
|
||
├── 高质量RCT.md
|
||
├── 质量不足案例.md
|
||
└── 信息在中间位置案例.md # ← 特别重要
|
||
```
|
||
|
||
---
|
||
|
||
### 5️⃣ **开发周期:2周 + MVP验证3天**
|
||
|
||
**调整**:
|
||
- Week 1-2:开发(保持2周)
|
||
- Week 3(Day 11-13):MVP验证 + 条件升级决策
|
||
|
||
**MVP验证关键**:
|
||
- 测试10-15篇人工标注论文
|
||
- 评估准确率(目标≥85%)
|
||
- 如果<80%,升级为混合策略(关键字段分段提取)
|
||
|
||
---
|
||
|
||
### 6️⃣ **数据库设计增强**
|
||
|
||
**新增字段**:
|
||
- `promptVersion`:Prompt版本号
|
||
- `extractionMethod`:'nougat' | 'pymupdf'
|
||
- `structuredFormat`:是否为结构化格式
|
||
- `processingLog`:处理日志(验证逐章节处理)
|
||
- `logicValidation`:医学逻辑验证结果
|
||
- `evidenceComplete`:证据链是否完整
|
||
- `conflictSeverity`:冲突严重程度
|
||
- `reviewPriority`:复核优先级
|
||
|
||
---
|
||
|
||
## 🎯 关键技术要点
|
||
|
||
### Prompt工程核心策略
|
||
|
||
#### 1. Section-Aware Prompting
|
||
|
||
```markdown
|
||
⚠️ 重要:本文是完整全文(约20,000字),请按章节逐步处理。
|
||
|
||
## 处理流程(必须遵守):
|
||
|
||
### Step 1: 章节定位
|
||
快速浏览全文,识别关键章节(Abstract、Methods、Results...)
|
||
|
||
### Step 2: 分字段提取
|
||
对于每个字段:
|
||
1. 标注预期位置
|
||
2. 定位到章节
|
||
3. **逐段仔细阅读**(不要跳过中间)
|
||
4. 提取信息
|
||
5. 记录引用和位置
|
||
|
||
⚠️ 特别注意:
|
||
- Methods和Results在中间位置,最容易遗漏
|
||
- 这些章节很长,请分段阅读
|
||
|
||
### Step 3: 交叉验证
|
||
回到全文,搜索关键词,确认无遗漏
|
||
```
|
||
|
||
#### 2. Few-shot案例(重点:信息在中间)
|
||
|
||
```markdown
|
||
### 案例1:信息在Methods中间段落(易遗漏)⭐
|
||
|
||
全文19,500字:
|
||
- Methods(4,000字)
|
||
- 第1段:研究设计概述
|
||
- 第2段:入排标准
|
||
- **第3段:随机化方法** ← 关键!在中间
|
||
- 第4段:盲法
|
||
- ...
|
||
|
||
正确做法✅:逐段阅读,不跳过
|
||
错误示例❌:只看开头和结尾,跳过中间
|
||
```
|
||
|
||
#### 3. JSON Schema强制约束
|
||
|
||
```json
|
||
{
|
||
"processing_log": {
|
||
"sections_reviewed": ["Abstract", "Methods", "Results", "Tables"],
|
||
"paragraphs_read_per_section": {
|
||
"Methods": 7, // 必须≥3
|
||
"Results": 5 // 必须≥3
|
||
},
|
||
"middle_sections_attention": true // 必须关注中间
|
||
},
|
||
|
||
"verification": {
|
||
"keywords_searched": ["randomization", "blinding", "ITT"],
|
||
"reread_count": 2, // 至少重读1次
|
||
"found_missed_info": false
|
||
}
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
## 📈 预期效果
|
||
|
||
| 指标 | 目标 | 验证方法 |
|
||
|------|------|----------|
|
||
| **准确率(MVP)** | ≥ 85% | 人工标注10-15篇测试 |
|
||
| **Methods章节准确率** | ≥ 83% | 分章节评估 |
|
||
| **Results章节准确率** | ≥ 83% | 分章节评估 |
|
||
| **证据链完整性** | 100% | 自动检查 |
|
||
| **医学逻辑验证** | 100% | 规则引擎检查 |
|
||
| **成本** | ≤ ¥0.06/篇 | 实际消耗统计 |
|
||
| **处理时间** | ≤ 3分钟/篇 | 性能测试 |
|
||
|
||
---
|
||
|
||
## 🚀 条件升级路径
|
||
|
||
如果MVP准确率<80%,升级为**混合策略**:
|
||
|
||
```
|
||
关键字段(3个)→ 分段提取
|
||
- 随机化方法(Methods)
|
||
- 盲法(Methods)
|
||
- 结果完整性(Results + Figures)
|
||
|
||
其他字段(9个)→ 保持全文提取
|
||
- 研究设计、研究人群、干预措施等
|
||
|
||
开发增量:+1周
|
||
预期准确率:90%+
|
||
```
|
||
|
||
---
|
||
|
||
## 📚 相关文档
|
||
|
||
- [全文复筛质量保障策略](../02-技术设计/08-全文复筛质量保障策略.md)
|
||
- [标题摘要初筛质量保障策略](../02-技术设计/06-质量保障与可追溯策略.md)
|
||
- [数据库设计](../02-技术设计/01-数据库设计.md)
|
||
- [API设计规范](../02-技术设计/02-API设计规范.md)
|
||
|
||
---
|
||
|
||
**更新日志**:
|
||
- 2025-11-22: V1.1 - 基于质量保障讨论,确定全文一次性+Prompt优化策略
|
||
- 2025-11-22: V1.0 - 初始版本
|
||
|
||
|
||
|