HaHafeng
dc6b292308
ASL Tool 3 Development Plan: - Architecture blueprint v1.5 (6 rounds of architecture review, 13 red lines) - M1/M2/M3 sprint checklists (Skeleton Pipeline / HITL Workbench / Dynamic Template Engine) - Code patterns cookbook (9 chapters: Fan-out, Prompt engineering, ACL, SSE dual-track, etc.) - Key patterns: Fan-out with Last Child Wins, Optimistic Locking, teamConcurrency throttling - PKB ACL integration (anti-corruption layer), MinerU Cache-Aside, NOTIFY/LISTEN cross-pod SSE - Data consistency snapshot for long-running extraction tasks Platform capability: - Add distributed Fan-out task pattern development guide (7 patterns + 10 anti-patterns) - Add system-level async architecture risk analysis blueprint - Add PDF table extraction engine design and usage guide (MinerU integration) - Add table extraction source code (TableExtractionManager + MinerU engine) Documentation updates: - Update ASL module status with Tool 3 V2.0 plan readiness - Update system status document (v6.2) with latest milestones - Add V2.0 product requirements, prototypes, and data dictionary specs - Add architecture review documents (4 rounds of review feedback) - Add test PDF files for extraction validation Co-authored-by: Cursor <cursoragent@cursor.com>
127 lines
6.6 KiB
Markdown
127 lines
6.6 KiB
Markdown
# **ASL 工具 3：全文智能提取数据字典与变量规范 (EBM Expert 版)**
|
||
|
||
**文档目的：** 为 ASL 工具 3 的底层大模型 (如 DeepSeek-V3) 定义结构化的提取目标 (JSON Schema)，确保提取的数据能完美喂给下游的系统综述 (Tool 4\) 和 Meta 分析引擎 (Tool 5)。
|
||
|
||
**设计原则：** 模块化、按需动态提取、强制 Quote 溯源。
|
||
|
||
## **🎯 核心逻辑：提取什么取决于下游“要画什么图”**
|
||
|
||
工具 3 的提取不是盲目的，它的所有字段都严格服务于最终的科研图表。我们将其分为四大核心模块：
|
||
|
||
### **模块一：通用基础元数据 (Basic Metadata)**
|
||
|
||
**提取来源：** PDF 首页、标题、摘要、致谢部分。
|
||
|
||
**下游用途：** 形成文献特征清单、排查同一临床试验的重复发表。
|
||
|
||
| 变量名 (JSON Key) | 字段含义 | 数据类型 | 提取位置说明 |
|
||
| :---- | :---- | :---- | :---- |
|
||
| study\_id | 研究标识 (第一作者+年份) | String | 通常在全文头部，例：*Gandhi 2018* |
|
||
| nct\_number | 临床试验注册号 | String | 摘要末尾或方法学开头，用于多篇文章去重 |
|
||
| study\_design | 研究设计类型 | Enum | 摘要或方法学 (如 RCT, Cohort Study) |
|
||
| funding\_source | 资金来源与利益冲突 | String | 文章末尾 Funding / COI 部分 |
|
||
|
||
### **模块二：基线特征数据 (Baseline Characteristics)**
|
||
|
||
**提取来源：** 核心来源于文献中的 **Table 1**。
|
||
|
||
**下游用途：** 直接送入【工具 4】，由后端矩阵转置后，自动拼装成论文的《表 1\. 纳入研究基线特征总表》。
|
||
|
||
*注：基线数据具有一定的领域特异性，以下为最通用的核心变量。*
|
||
|
||
| 变量名 (JSON Key) | 字段含义 | 数据类型 | 提取位置说明 |
|
||
| :---- | :---- | :---- | :---- |
|
||
| treatment\_name | 实验组干预措施 | String | Table 1 表头或方法学，需包含剂量/频次 |
|
||
| control\_name | 对照组干预措施 | String | Table 1 表头或方法学 (如 Placebo) |
|
||
| n\_treatment | 实验组样本量 | Integer | Table 1 顶部列总数 (N=xxx) |
|
||
| n\_control | 对照组样本量 | Integer | Table 1 顶部列总数 (N=xxx) |
|
||
| age\_treatment | 实验组年龄 (Mean±SD) | String | Table 1 中的 Age 行 |
|
||
| age\_control | 对照组年龄 (Mean±SD) | String | Table 1 中的 Age 行 |
|
||
| male\_percent | 男性比例 (%) | String | Table 1 中的 Sex/Gender 行计算或直提 |
|
||
|
||
### **模块三：方法学与偏倚风险评估 (Risk of Bias \- RoB 2.0)**
|
||
|
||
**提取来源：** 核心来源于文献的 **Methods (方法学)** 正文段落。
|
||
|
||
**下游用途：** 送入【工具 4】，生成 Cochrane 标准的“偏倚风险红绿灯图”。
|
||
|
||
大模型需要像方法学专家一样，阅读方法学正文并进行**定性评价** (Low/High/Unclear Risk)：
|
||
|
||
| 变量名 (JSON Key) | 评估维度 (RoB 2.0) | AI 判断逻辑与提取目标 |
|
||
| :---- | :---- | :---- |
|
||
| rob\_randomization | 随机序列产生 | 寻找 "computer-generated", "random number table" 等词，评估是否为真随机。 |
|
||
| rob\_allocation | 分配隐藏 | 寻找 "central web-based", "opaque envelopes" 等词。 |
|
||
| rob\_blinding | 盲法实施 | 寻找 "double-blind", "open-label" 以及盲法对象 (患者、研究者、结局评估者)。 |
|
||
| rob\_attrition | 失访与数据完整性 | 从 Results 或 Consort 图中提取失访率，寻找 "Intention-to-treat (ITT)" 分析字眼。 |
|
||
|
||
### **模块四：结局指标数据 (Outcomes) —— ⚠️ 动态提取的核心**
|
||
|
||
这是最复杂的部分。**根据用户在【工具 5】中想要做的 Meta 分析类型的不同，工具 3 必须动态切换其提取的 JSON Schema。**
|
||
|
||
提取来源：正文的 **Results** 段落、**Table 2/3** (结局表)、**Kaplan-Meier 曲线下方的文字**。
|
||
|
||
#### **场景 A：生存分析 / 时间-事件分析 (适用于肿瘤、心血管)**
|
||
|
||
**关注点：** 结局不仅看是否发生，还看“何时”发生。
|
||
|
||
**提取字典 (送入 Tool 5 的 HR 模板)：**
|
||
|
||
* endpoint\_name: 终点名称 (如 OS, PFS, MACE)
|
||
* hr\_value: 风险比 (Hazard Ratio)
|
||
* hr\_ci\_lower: 95% 置信区间下限
|
||
* hr\_ci\_upper: 95% 置信区间上限
|
||
* p\_value: 统计学 P 值
|
||
|
||
#### **场景 B：二分类数据 (适用于感染率、死亡率、有效/无效)**
|
||
|
||
**关注点：** 绝对的发生人数与总人数。
|
||
|
||
**提取字典 (送入 Tool 5 的 Dichotomous 模板)：**
|
||
|
||
* event\_treatment: 实验组发生事件的**具体人数** (从正文或表格中抓取)
|
||
* total\_treatment: 实验组该指标的**分析总人数** (注意：可能与基线总人数不同，需看是否排除失访)
|
||
* event\_control: 对照组发生事件的具体人数
|
||
* total\_control: 对照组分析总人数
|
||
|
||
#### **场景 C：连续型数据 (适用于评分量表、血压下降值、住院天数)**
|
||
|
||
**关注点：** 均值、标准差与样本量。
|
||
|
||
**提取字典 (送入 Tool 5 的 Continuous 模板)：**
|
||
|
||
* mean\_treatment: 实验组结局指标均值
|
||
* sd\_treatment: 实验组结局指标标准差 (SD) *(注：若原文提供 SE 或 95% CI，要求 LLM 尝试换算为 SD，或原样摘录待人工换算)*
|
||
* n\_treatment: 实验组分析人数
|
||
* mean\_control: 对照组均值
|
||
* sd\_control: 对照组标准差
|
||
* n\_control: 对照组分析人数
|
||
|
||
### **模块五：Quote 溯源系统 (Anti-Hallucination)**
|
||
|
||
这是我们系统的底层信任机制。
|
||
|
||
上述四大模块中，**每一个提取出的字段（尤其是数字），都必须在 JSON 中强制附带一个成对的 \_quote 字段。**
|
||
|
||
**示例 (LLM 输出格式)：**
|
||
|
||
{
|
||
"hr\_value": 0.63,
|
||
"hr\_value\_quote": "The risk of disease progression or death was significantly lower in the intervention group (hazard ratio, 0.63; 95% CI, 0.52 to 0.76; P\<0.001)."
|
||
}
|
||
|
||
**规范要求：**
|
||
|
||
1. Quote 必须是 PDF 解析出的 Markdown 中的**原话**，不得修改任何一个单词。
|
||
2. 对于表格中提取的数据，Quote 必须指出表名与行列坐标，例如：*"Table 2, Row 'Overall Survival', Column 'Hazard Ratio'."*
|
||
|
||
## **📊 最终输出报告 (Output)**
|
||
|
||
当【工具 3】完成批处理后，它的输出不是一篇长篇大论的文章，而是**两项高度结构化的科研资产**：
|
||
|
||
1. **供人查阅的 Excel 数据宽表 (Data Extraction Matrix)：**
|
||
* 行：每一篇文献（Study）。
|
||
* 列：上述所有提取的变量。
|
||
* 相邻列：每一个变量紧跟一列对应的 Quote 原文。
|
||
* *这张表医生可以直接带走，作为发顶刊时必备的 Supplementary Appendix。*
|
||
2. **供系统流转的 JSON Payload：**
|
||
* 系统在后台将这些结构化数据自动推送至【工具 4】画图，推送至【工具 5】执行 R 语言计算。 |