docs(requirements): 固化资料包解析确认口径
This commit is contained in:
@@ -28,13 +28,15 @@ V1 建议支持以下导入方式:
|
||||
2. 文件夹拖拽或前端批量选择文件。
|
||||
3. 压缩包上传并自动解压。
|
||||
|
||||
压缩包格式建议覆盖:
|
||||
压缩包格式覆盖:
|
||||
|
||||
1. `zip`
|
||||
2. `rar`
|
||||
3. `7z`
|
||||
|
||||
系统解包后应保留原始相对路径,用于还原资料目录、识别章节点和发现文件夹结构异常。
|
||||
系统解包后应保留原始相对路径,用于还原资料目录、识别章节点和发现文件夹结构异常。压缩包内多层目录按原目录作为章节点识别依据。
|
||||
|
||||
`rar`、`7z` 解压必须采用纯 Python 实现,允许新增第三方 Python 依赖包,避免服务器部署时依赖系统级解压工具。
|
||||
|
||||
### 2.2 法规依据资料
|
||||
|
||||
@@ -63,7 +65,7 @@ docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批
|
||||
| 原始路径 | 解压或上传后的相对路径 |
|
||||
| 文件名 | 原始文件名 |
|
||||
| 文件类型 | PDF、DOCX、DOC、TXT、MD 等 |
|
||||
| 页数 | 可精确统计或估算 |
|
||||
| 页数 | 精确页数或待复核状态 |
|
||||
| 章节点 | 如 CH1.2、CH1.4、CH1.11.5 |
|
||||
| 资料名称 | 识别出的注册资料名称 |
|
||||
| 处理状态 | 已解析、解析失败、待人工确认 |
|
||||
@@ -72,8 +74,8 @@ docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批
|
||||
页数统计策略:
|
||||
|
||||
1. PDF 优先用 `pdfplumber` 或 `PyMuPDF` 精确统计。
|
||||
2. DOCX 优先解析段落、表格和属性,页数可先标记为估算或待确认。
|
||||
3. DOC 可通过兼容解析工具或转换后处理,失败时保留异常提示。
|
||||
2. DOCX 页数必须精确统计,不能以估算页数作为 V1 验收结果。
|
||||
3. DOC 可通过兼容解析工具或转换后处理,无法精确统计时标记为待人工复核。
|
||||
4. 扫描件或无法提取正文的文件标记为“需 OCR / 待人工复核”。
|
||||
|
||||
### 3.2 按 NMPA 法规要求核查完整性
|
||||
@@ -96,7 +98,7 @@ V1 规则建议拆成三层:
|
||||
| 错放 | 文件存在但章节点或目录位置不合理 |
|
||||
| 待复核 | 规则无法直接判定 |
|
||||
|
||||
自动通知责任人属于完整性核查后的动作。V1 可先输出责任角色和通知载荷,例如“CH4 临床评价资料缺失 -> 临床注册负责人”,后续再接飞书机器人执行 `@` 通知。
|
||||
自动通知责任人属于完整性核查后的动作。V1 责任人先通过后台或配置文件手动维护,并按资料章节配置。系统可先输出责任角色和通知载荷,例如“CH4 临床评价资料缺失 -> 临床注册负责人”,后续再接飞书机器人执行 `@` 通知。
|
||||
|
||||
### 3.3 产品关键信息抽取与回填
|
||||
|
||||
@@ -236,8 +238,8 @@ RAG 不作为最终合规判断引擎,只负责:
|
||||
Agent Core 后续应注册以下工具:
|
||||
|
||||
1. `scan_submission_package`:扫描资料包并保留目录结构。
|
||||
2. `extract_archive`:解压 zip、rar、7z。
|
||||
3. `count_document_pages`:统计或估算页数。
|
||||
2. `extract_archive`:解压 zip、rar、7z,其中 rar、7z 必须使用纯 Python 依赖实现。
|
||||
3. `count_document_pages`:统计页数,DOCX 必须精确统计。
|
||||
4. `classify_chapter_node`:识别章节点和资料名称。
|
||||
5. `check_nmpa_completeness`:按结构化规则检查齐套性。
|
||||
6. `extract_product_fields`:抽取产品核心字段。
|
||||
@@ -304,8 +306,8 @@ Audit 需要记录:
|
||||
建议按以下顺序落地,保证演示先闭环:
|
||||
|
||||
1. 批量上传 / 压缩包解压 / 文件目录汇总。
|
||||
2. PDF、DOCX 页数统计和解析状态展示。
|
||||
3. 基于公告附件包整理结构化必交项规则。
|
||||
2. PDF、DOCX 页数统计和解析状态展示,其中 DOCX 必须精确统计。
|
||||
3. 基于公告附件包整理结构化必交项规则,第 2 至第 6 章先做规则级初步确认。
|
||||
4. 完整性核查与缺失项风险输出。
|
||||
5. 从目标产品说明书抽取产品名称、靶标、适用范围、储存条件、性能指标。
|
||||
6. 对说明书、申请表、产品列表做字段一致性核查。
|
||||
@@ -313,16 +315,19 @@ Audit 需要记录:
|
||||
8. 回填预览和 Word 模板导出。
|
||||
9. 责任人通知载荷与飞书机器人演示。
|
||||
|
||||
## 7. 待确认事项
|
||||
## 7. 已确认约束与剩余待确认事项
|
||||
|
||||
以下问题不阻塞 V1 需求整理,但会影响实现细节:
|
||||
以下约束已经确认,应作为后续实现依据:
|
||||
|
||||
1. DOCX 页数必须精确统计。
|
||||
2. 压缩包内多层目录按原目录作为章节点依据。
|
||||
3. `rar`、`7z` 解压必须纯 Python 实现,允许新增第三方依赖包。
|
||||
4. 责任人先手动配置,按资料章节维护。
|
||||
5. 第 2 至第 6 章不补充企业真实样本,先按公告附件包进行规则级初步确认。
|
||||
|
||||
剩余待确认事项:
|
||||
|
||||
1. “目标文件”具体是注册申请表、对照清单,还是另一个业务方指定模板。
|
||||
2. DOCX 页数是否必须精确,还是允许首版标记为估算。
|
||||
3. 压缩包内多层目录是否按原目录作为章节点依据。
|
||||
4. rar、7z 解压是否允许依赖系统工具,还是必须纯 Python 实现。
|
||||
5. 责任人是按章节点、资料类型、项目角色还是具体人员维护。
|
||||
6. 第 2 至第 6 章是否会补充企业真实样本用于内容级演示。
|
||||
|
||||
## 8. 结论
|
||||
|
||||
|
||||
Reference in New Issue
Block a user