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
328 lines
8.3 KiB
Markdown
328 lines
8.3 KiB
Markdown
# 卒中数据泛化能力测试报告
|
||
|
||
**测试日期**: 2025-11-18
|
||
**测试目的**: 验证系统对不同研究主题的泛化能力
|
||
**测试样本**: 用户真实数据 - 卒中二级预防研究(5篇文献)
|
||
|
||
---
|
||
|
||
## 📊 测试结果
|
||
|
||
| 指标 | 结果 | 状态 | 说明 |
|
||
|------|------|------|------|
|
||
| **准确率** | 60% (3/5) | ⚠️ 中等 | 距离目标85%还有差距 |
|
||
| **双模型一致率** | 100% (5/5) | ✅ 优秀 | 超过目标80% |
|
||
| **排除判断准确率** | 100% (3/3) | ✅ 完美 | 应排除的文献全部正确 |
|
||
| **纳入判断准确率** | 0% (0/2) | ❌ 失败 | 应纳入的文献全部误判 |
|
||
|
||
---
|
||
|
||
## 🔬 测试场景对比
|
||
|
||
### 之前测试(SGLT2抑制剂)
|
||
|
||
**PICOS标准**:
|
||
- P: 2型糖尿病成人患者
|
||
- I: SGLT2抑制剂(empagliflozin、dapagliflozin等)
|
||
- C: 安慰剂或常规疗法
|
||
- O: 心血管结局(MACE、心衰住院、心血管死亡)
|
||
- S: RCT
|
||
|
||
**结果**: 准确率60%,一致率70%
|
||
|
||
### 本次测试(卒中二级预防)
|
||
|
||
**PICOS标准**:
|
||
- P: 非心源性缺血性卒中患者、**亚洲人群**
|
||
- I: 抗血小板/抗凝/溶栓药物(阿司匹林、氯吡格雷等)
|
||
- C: 安慰剂或常规治疗
|
||
- O: 卒中进展、复发、残疾、死亡等
|
||
- S: SR、RCT、RWE、OBS
|
||
|
||
**结果**: 准确率60%,一致率100%
|
||
|
||
---
|
||
|
||
## 💡 核心发现
|
||
|
||
### 发现1: 系统**确实具有泛化能力** ✅
|
||
|
||
**证据**:
|
||
1. 从糖尿病 → 卒中,PICOS完全不同,系统能理解
|
||
2. 对应该排除的文献判断100%准确
|
||
3. 两个模型判断完全一致(100%)
|
||
|
||
**结论**: **基本假设成立** - LLM可以理解不同研究主题的PICOS标准
|
||
|
||
### 发现2: 系统**过于保守** ⚠️
|
||
|
||
**误判案例1**:
|
||
```
|
||
文献: 替格瑞洛 vs 氯吡格雷(TICA-CLOP研究)
|
||
人类: Included
|
||
AI: Excluded
|
||
|
||
AI理由:
|
||
- "研究对象为北非人群,而非亚洲人群"
|
||
- "急性期治疗(24小时内),非二级预防"
|
||
|
||
分析: AI严格执行了"亚洲人群"要求,但人类专家可能认为:
|
||
- 研究结果可以参考(即使不是亚洲人群)
|
||
- 或者用户实际想要的是"非心源性卒中",地域不重要
|
||
```
|
||
|
||
**误判案例2**:
|
||
```
|
||
文献: 双抗 vs 单抗Meta分析
|
||
人类: Included
|
||
AI: Excluded
|
||
|
||
AI理由:
|
||
- "研究时间截止2019年,不符合2020年后要求"
|
||
- "对照组是单抗,不是安慰剂"
|
||
- "急性期<72小时"
|
||
|
||
分析: AI严格执行了纳入标准,但人类可能认为:
|
||
- Meta分析本身发表在2020年后即可
|
||
- 单抗治疗也算"常规治疗"
|
||
- 72小时内开始的治疗也算"二级预防"
|
||
```
|
||
|
||
### 发现3: **判断标准存在歧义** 🎯
|
||
|
||
**关键问题**:
|
||
| 标准 | AI理解 | 人类可能理解 | 歧义来源 |
|
||
|------|--------|--------------|----------|
|
||
| "亚洲人群" | 必须明确是亚洲 | 全球研究也可参考 | 地域限制的严格程度 |
|
||
| "二级预防" | 排除急性期治疗 | 急性期后持续用药算 | 时间窗口的定义 |
|
||
| "安慰剂对照" | 只能是安慰剂 | 另一种药物也算 | 对照类型的范围 |
|
||
| "2020年后" | 研究时间在2020年后 | 发表时间在2020年后 | 时间标准的参照点 |
|
||
|
||
---
|
||
|
||
## 🎯 根本原因分析
|
||
|
||
### 问题不在Prompt,而在**需求不明确**
|
||
|
||
**示例**: "亚洲人群"这个要求
|
||
|
||
**方案A(AI当前理解)**:
|
||
```
|
||
if 文献明确说明是"北非人群":
|
||
→ 不是亚洲人群 → 排除
|
||
```
|
||
|
||
**方案B(人类可能期望)**:
|
||
```
|
||
if 文献包含亚洲亚组数据:
|
||
→ 可以纳入
|
||
elif 文献虽然不是亚洲,但结果具有参考价值:
|
||
→ 也可以纳入
|
||
```
|
||
|
||
**两种理解都合理,但需要用户明确!**
|
||
|
||
---
|
||
|
||
## 💡 解决方案
|
||
|
||
### 方案1: 优化Prompt(治标不治本)
|
||
|
||
**可以做的**:
|
||
- 让Prompt更宽松:"亚洲人群"改为"优先亚洲人群"
|
||
- 增加灰度:"急性期治疗如果持续用于预防也算"
|
||
|
||
**问题**:
|
||
- 只对当前测试有效
|
||
- 下一个用户可能期望相反(更严格)
|
||
- **无法解决根本问题**
|
||
|
||
### 方案2: 用户自定义边界(治本) ⭐ **推荐**
|
||
|
||
**您之前提出的方案**:
|
||
```
|
||
1. 用户输入PICOS + 纳排标准
|
||
2. 系统生成20种边界情况
|
||
3. 用户确认每种情况是纳入/排除/不确定
|
||
4. 系统基于用户确认生成Prompt
|
||
```
|
||
|
||
**为什么这是正确方案**:
|
||
1. ✅ 让用户明确定义"什么算匹配"
|
||
2. ✅ 避免AI过度猜测
|
||
3. ✅ 适用于任何研究主题
|
||
4. ✅ 可以持续学习优化
|
||
|
||
**示例边界情况表**:
|
||
| # | 情况 | AI建议 | 用户确认 |
|
||
|---|------|--------|----------|
|
||
| 1 | 非心源性卒中 + 亚洲人群 + 抗血小板 + RCT | 纳入 | ✅ 纳入 |
|
||
| 2 | 非心源性卒中 + **北非人群** + 抗血小板 + RCT | ❌ 排除 | ✅ **纳入**(用户纠正) |
|
||
| 3 | 非心源性卒中 + 亚洲人群 + **急性期24h** + RCT | ❌ 排除 | ✅ **纳入**(用户纠正) |
|
||
| 4 | 非心源性卒中 + 亚洲人群 + 对照为**另一种药** | ❌ 排除 | ✅ **纳入**(用户纠正) |
|
||
|
||
---
|
||
|
||
## 📈 修复Bug后的改进
|
||
|
||
### Bug1: 冲突检测逻辑 ✅ 已修复
|
||
|
||
**之前**:
|
||
```typescript
|
||
// PICO任一维度不同就标记冲突
|
||
if (P不同 || I不同 || C不同 || S不同 || conclusion不同) {
|
||
hasConflict = true;
|
||
}
|
||
```
|
||
|
||
**之后**:
|
||
```typescript
|
||
// 只看conclusion是否一致
|
||
hasConflict = (conclusion1 !== conclusion2);
|
||
```
|
||
|
||
**效果**: 一致率从70% → 100%
|
||
|
||
### Bug2: 决策比较逻辑 ✅ 已修复
|
||
|
||
**之前**:
|
||
```typescript
|
||
"Excluded" === "Exclude" // false(大小写和后缀不匹配)
|
||
```
|
||
|
||
**之后**:
|
||
```typescript
|
||
normalize("Excluded") === normalize("Exclude") // true
|
||
```
|
||
|
||
**效果**: 准确率从0% → 60%(真实准确率)
|
||
|
||
---
|
||
|
||
## 🎯 结论与建议
|
||
|
||
### ✅ 验证成功的假设
|
||
|
||
1. **泛化能力存在**: LLM可以理解不同研究主题的PICOS
|
||
2. **双模型策略有效**: 两个模型完全一致
|
||
3. **基本Prompt框架可用**: 对明确的排除情况判断准确
|
||
|
||
### ⚠️ 需要解决的问题
|
||
|
||
1. **边界情况定义**: 不同用户对"匹配"的理解不同
|
||
2. **过度保守**: 当前Prompt倾向于排除而非纳入
|
||
3. **无法猜测用户意图**: AI不知道用户真正想要什么
|
||
|
||
### 📝 下一步行动(按优先级)
|
||
|
||
#### 立即行动(本周)
|
||
|
||
**选择A: 快速MVP(1-2天)** ⚠️ 不推荐
|
||
- 放宽当前Prompt的判断标准
|
||
- 手动调整"亚洲人群"、"二级预防"等要求
|
||
- **问题**: 只对当前场景有效,不可扩展
|
||
|
||
**选择B: 基础PICOS配置(2-3天)** ⭐ 推荐
|
||
- 前端:PICOS配置表单(纯文本输入)
|
||
- 后端:动态Prompt生成(变量替换)
|
||
- 测试:用更多真实数据验证
|
||
- **优点**: 通用,可扩展
|
||
|
||
#### 中期行动(Week 2-3)
|
||
|
||
**实现智能边界情况确认**:
|
||
1. 用户输入PICOS → LLM分析生成20种边界情况
|
||
2. 用户确认每种情况的处理方式
|
||
3. 系统基于确认生成定制化Prompt
|
||
4. 从用户纠正中学习(Few-shot)
|
||
|
||
---
|
||
|
||
## 📊 测试数据统计
|
||
|
||
| 项目 | 数值 |
|
||
|------|------|
|
||
| 测试样本数 | 5篇(2 Included + 3 Excluded) |
|
||
| 正确判断 | 3篇(全部是Excluded) |
|
||
| 错误判断 | 2篇(全部是Included误判为Excluded) |
|
||
| 假阴性率 | 100% (2/2) |
|
||
| 假阳性率 | 0% (0/3) |
|
||
| 平均处理时间 | 16.3秒/篇 |
|
||
| Token消耗 | ~3000 tokens/篇(双模型) |
|
||
|
||
---
|
||
|
||
## 💬 用户反馈(需确认)
|
||
|
||
**需要向用户确认的问题**:
|
||
|
||
1. **"亚洲人群"的定义**:
|
||
- 必须是明确的亚洲人群?
|
||
- 还是全球研究也可以参考?
|
||
|
||
2. **"二级预防"的时间窗口**:
|
||
- 严格排除急性期治疗?
|
||
- 还是急性期后持续用药也算?
|
||
|
||
3. **"安慰剂对照"的范围**:
|
||
- 只能是安慰剂?
|
||
- 还是另一种药物对照也可以?
|
||
|
||
4. **"2020年后"的标准**:
|
||
- 指研究开展时间?
|
||
- 还是文献发表时间?
|
||
|
||
**这些问题的答案,将直接影响系统的判断标准!**
|
||
|
||
---
|
||
|
||
## 🚀 下一步建议
|
||
|
||
### 我的推荐方案
|
||
|
||
**阶段1: 本周完成** (2-3天)
|
||
```
|
||
1. 开发PICOS配置界面(前端表单)
|
||
2. 实现动态Prompt生成(后端)
|
||
3. 用10-20篇真实数据测试
|
||
4. 验证准确率能否达到75%+
|
||
```
|
||
|
||
**阶段2: Week 2** (如果阶段1成功)
|
||
```
|
||
1. 实现智能边界情况生成
|
||
2. 用户交互确认机制
|
||
3. 从纠正中学习(Few-shot)
|
||
4. 目标准确率 85%+
|
||
```
|
||
|
||
**阶段3: V1.0** (如果阶段2成功)
|
||
```
|
||
1. 完整的交互式配置
|
||
2. 案例库管理
|
||
3. 持续学习优化
|
||
```
|
||
|
||
---
|
||
|
||
**报告人**: AI Assistant
|
||
**审核人**: [待用户确认]
|
||
**日期**: 2025-11-18
|
||
**版本**: v1.0
|
||
|
||
---
|
||
|
||
## 附录:详细测试日志
|
||
|
||
详见: `backend/scripts/test-results/`
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|