docs(requirements): 梳理注册资料审核Agent需求
This commit is contained in:
zhiye.sun
335
docs/设计文档/1.注册资料审核Agent设计思路.md
Normal file
335
docs/设计文档/1.注册资料审核Agent设计思路.md
Normal file
@@ -0,0 +1,335 @@
|
||||
# 注册资料审核 Agent 需求分析与设计思路
|
||||
|
||||
## 1. 题目理解
|
||||
|
||||
本题要求建设的不是普通文档问答机器人，而是面向 NMPA 体外诊断试剂注册申报资料的“资料准备与审核 Agent”。
|
||||
|
||||
系统需要围绕一个注册资料包完成以下闭环：
|
||||
|
||||
1. 接收并解析一批申报资料。
|
||||
2. 自动汇总文件目录与页数。
|
||||
3. 对照 NMPA 法规和本地公告附件包检查资料完整性。
|
||||
4. 从产品资料中抽取核心字段。
|
||||
5. 将抽取结果填入申报表格、对照清单或目标模板。
|
||||
6. 检查文档结构、章节规范性和跨文档字段一致性。
|
||||
7. 输出合规风险预警、责任人通知建议和整改动作。
|
||||
|
||||
因此，系统设计的重点应从“单文档对话”转向“资料包级审核编排”。
|
||||
|
||||
## 2. 输入资料口径
|
||||
|
||||
### 2.1 待审核资料
|
||||
|
||||
题目第一项要求“自动汇总文件夹文件目录与页数”，这意味着首版输入不应只支持单文件上传，还要覆盖资料包导入。
|
||||
|
||||
V1 建议支持以下导入方式：
|
||||
|
||||
1. 多文件批量上传。
|
||||
2. 文件夹拖拽或前端批量选择文件。
|
||||
3. 压缩包上传并自动解压。
|
||||
|
||||
压缩包格式建议覆盖：
|
||||
|
||||
1. `zip`
|
||||
2. `rar`
|
||||
3. `7z`
|
||||
|
||||
系统解包后应保留原始相对路径，用于还原资料目录、识别章节点和发现文件夹结构异常。
|
||||
|
||||
### 2.2 法规依据资料
|
||||
|
||||
法规核查不应只依赖在线网页或大模型记忆。当前本地材料中已经提供了主规则依据：
|
||||
|
||||
```text
|
||||
docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/
|
||||
```
|
||||
|
||||
该目录下资料应作为 V1 的主规则包，包括注册申报资料要求、格式要求、安全和性能基本原则清单、注册证格式、变更和延续注册资料要求等。
|
||||
|
||||
`docs/原始材料/附件 4 体外诊断试剂注册申报资料要求及说明.doc` 可作为同源补充材料。
|
||||
|
||||
外部网站 `cmde.org.cn` 和 `nmpa.gov.cn` 在 V1 中主要作为法规来源说明和后续在线更新依据，不作为演示时的唯一实时依赖。
|
||||
|
||||
## 3. 核心需求重整
|
||||
|
||||
### 3.1 自动汇总文件目录与页数
|
||||
|
||||
系统应扫描当前资料包中的所有文件，形成目录汇总表。
|
||||
|
||||
目录汇总表至少包含：
|
||||
|
||||
| 字段 | 说明 |
|
||||
|---|---|
|
||||
| 原始路径 | 解压或上传后的相对路径 |
|
||||
| 文件名 | 原始文件名 |
|
||||
| 文件类型 | PDF、DOCX、DOC、TXT、MD 等 |
|
||||
| 页数 | 可精确统计或估算 |
|
||||
| 章节点 | 如 CH1.2、CH1.4、CH1.11.5 |
|
||||
| 资料名称 | 识别出的注册资料名称 |
|
||||
| 处理状态 | 已解析、解析失败、待人工确认 |
|
||||
| 是否命中法规目录 | 用于后续完整性核查 |
|
||||
|
||||
页数统计策略：
|
||||
|
||||
1. PDF 优先用 `pdfplumber` 或 `PyMuPDF` 精确统计。
|
||||
2. DOCX 优先解析段落、表格和属性，页数可先标记为估算或待确认。
|
||||
3. DOC 可通过兼容解析工具或转换后处理，失败时保留异常提示。
|
||||
4. 扫描件或无法提取正文的文件标记为“需 OCR / 待人工复核”。
|
||||
|
||||
### 3.2 按 NMPA 法规要求核查完整性
|
||||
|
||||
完整性核查的规则来源应优先来自本地公告附件包。
|
||||
|
||||
V1 规则建议拆成三层：
|
||||
|
||||
1. 资料齐套性：是否具备注册申报资料要求中的必交文件。
|
||||
2. 章节点结构：文件是否落在正确章节，目录与实际文件是否一致。
|
||||
3. 格式模板：申请表、注册证、清单、声明类文件是否符合对应格式要求。
|
||||
|
||||
核查结果需要区分：
|
||||
|
||||
| 状态 | 说明 |
|
||||
|---|---|
|
||||
| 已提供 | 文件和章节点均匹配 |
|
||||
| 缺失 | 必交资料未找到 |
|
||||
| 疑似提供 | 文件名或内容疑似匹配，但命名/归类不规范 |
|
||||
| 错放 | 文件存在但章节点或目录位置不合理 |
|
||||
| 待复核 | 规则无法直接判定 |
|
||||
|
||||
自动通知责任人属于完整性核查后的动作。V1 可先输出责任角色和通知载荷，例如“CH4 临床评价资料缺失 -> 临床注册负责人”，后续再接飞书机器人执行 `@` 通知。
|
||||
|
||||
### 3.3 产品关键信息抽取与回填
|
||||
|
||||
题目中明确要求抽取：
|
||||
|
||||
1. 产品名称
|
||||
2. 检测靶标
|
||||
3. 适用范围
|
||||
4. 储存条件
|
||||
5. 性能指标
|
||||
|
||||
结合样例材料，首版建议以 `docs/原始材料/目标产品说明书.docx` 作为核心抽取样本，同时从申请表、产品列表、声明类文件中抽取可比对字段。
|
||||
|
||||
抽取结果先进入“统一字段池”，再用于回填。
|
||||
|
||||
统一字段池字段建议：
|
||||
|
||||
| 字段 | 说明 |
|
||||
|---|---|
|
||||
| field_key | 标准字段编码 |
|
||||
| field_label | 中文字段名 |
|
||||
| value | 标准化字段值 |
|
||||
| raw_value | 原文值 |
|
||||
| source_document | 来源文件 |
|
||||
| source_location | 来源章节、表格或页码 |
|
||||
| confidence | 置信度 |
|
||||
| conflict_status | 一致、冲突、待确认 |
|
||||
| fillable | 是否可回填 |
|
||||
|
||||
回填目标当前仍需确认。默认建议按两步走：
|
||||
|
||||
1. V1 先输出结构化回填表和回填预览，覆盖注册申报表格或法规对照清单字段。
|
||||
2. 后续基于 Word 模板库生成可导出的目标文件。
|
||||
|
||||
如果业务方确认“目标文件”就是某个指定申报表或对照清单，应在模板库中建立字段映射，而不是把回填逻辑写死在 Prompt 中。
|
||||
|
||||
### 3.4 文档结构、信息一致性与章节规范性核查
|
||||
|
||||
结构核查应覆盖两类对象：
|
||||
|
||||
1. 单文档内部章节是否完整。
|
||||
2. 资料包整体章节点是否符合 NMPA 目录结构。
|
||||
|
||||
以说明书或性能研究资料为例，需要检查是否包含分析灵敏度、特异性、重复性等必检项目。
|
||||
|
||||
一致性核查应基于统一字段池执行。首版按当前项目口径采用严格一致规则，即同一审核范围内同一字段只要文本不一致，就标记为冲突或待人工复核。
|
||||
|
||||
强一致字段建议包括：
|
||||
|
||||
1. 产品名称
|
||||
2. 规格型号 / 包装规格
|
||||
3. 申请人名称
|
||||
4. 检测靶标
|
||||
5. 适用范围 / 预期用途
|
||||
6. 储存条件
|
||||
|
||||
当前样例中存在“目标产品说明书”和第 1 章监管资料产品名称不一致的情况。系统不应在需求阶段强行解释为同一产品，而应设计为：
|
||||
|
||||
1. 用户先选择审核范围或项目批次。
|
||||
2. 系统对选定范围内的文件做一致性核查。
|
||||
3. 若发现跨产品资料混入，输出混档风险。
|
||||
|
||||
### 3.5 合规风险预警与处理建议
|
||||
|
||||
风险清单应把完整性、结构、字段一致性和抽取失败结果统一汇总。
|
||||
|
||||
风险项字段建议：
|
||||
|
||||
| 字段 | 说明 |
|
||||
|---|---|
|
||||
| risk_level | 高 / 中 / 低 |
|
||||
| risk_type | 缺失、错放、冲突、格式不规范、混档、待复核 |
|
||||
| related_document | 涉及文件 |
|
||||
| requirement_source | 法规或规则来源 |
|
||||
| description | 问题描述 |
|
||||
| suggestion | 处理建议 |
|
||||
| owner_role | 建议责任角色 |
|
||||
| notification_message | 可发送给责任人的通知摘要 |
|
||||
|
||||
示例：
|
||||
|
||||
```text
|
||||
文件 CH4 临床评价资料：未在当前资料包中识别到临床评估报告。建议补充临床评价资料，并由临床注册负责人复核。
|
||||
```
|
||||
|
||||
```text
|
||||
产品名称冲突：说明书中的产品名称与申请表中的产品名称不一致。建议先确认当前审核范围是否混入其他产品资料。
|
||||
```
|
||||
|
||||
## 4. Agent 编排设计
|
||||
|
||||
### 4.1 总体链路
|
||||
|
||||
建议 Agent Core 采用固定编排链路：
|
||||
|
||||
```text
|
||||
资料导入
|
||||
-> 解压与文件扫描
|
||||
-> 页数统计与目录汇总
|
||||
-> 文本 / 表格 / 章节解析
|
||||
-> 章节点归类
|
||||
-> 法规规则匹配
|
||||
-> 字段抽取与统一字段池
|
||||
-> 一致性核查
|
||||
-> 风险汇总
|
||||
-> 回填预览 / Word 生成
|
||||
-> 审计记录与责任人通知
|
||||
```
|
||||
|
||||
### 4.2 规则优先，模型辅助
|
||||
|
||||
法规完整性、必交项、章节点和强一致字段不应交给大模型自由判断。
|
||||
|
||||
推荐分工：
|
||||
|
||||
| 能力 | 处理方式 |
|
||||
|---|---|
|
||||
| 文件扫描、解压、页数统计 | 工具 / 服务层 |
|
||||
| 法规目录匹配 | 结构化规则 |
|
||||
| 必交项缺失判断 | 结构化规则 |
|
||||
| 固定字段抽取 | 正则、标题、表格规则 |
|
||||
| 长文本字段归纳 | LLM 辅助 |
|
||||
| 法规条款引用 | RAG 辅助 |
|
||||
| 风险文案与建议 | 规则结论 + LLM 组织语言 |
|
||||
|
||||
### 4.3 RAG 的职责
|
||||
|
||||
RAG 不作为最终合规判断引擎，只负责：
|
||||
|
||||
1. 从法规原文中找证据。
|
||||
2. 从业务资料中找来源片段。
|
||||
3. 为审计记录保留可追溯依据。
|
||||
4. 支持用户追问“为什么这么判”。
|
||||
|
||||
### 4.4 Tool Registry 建议工具
|
||||
|
||||
Agent Core 后续应注册以下工具：
|
||||
|
||||
1. `scan_submission_package`：扫描资料包并保留目录结构。
|
||||
2. `extract_archive`：解压 zip、rar、7z。
|
||||
3. `count_document_pages`：统计或估算页数。
|
||||
4. `classify_chapter_node`：识别章节点和资料名称。
|
||||
5. `check_nmpa_completeness`：按结构化规则检查齐套性。
|
||||
6. `extract_product_fields`：抽取产品核心字段。
|
||||
7. `compare_field_consistency`：执行字段一致性比对。
|
||||
8. `check_document_structure`：检查章节和必检项目。
|
||||
9. `build_risk_alerts`：汇总风险和处理建议。
|
||||
10. `build_fill_preview`：生成回填预览。
|
||||
11. `render_word_template`：按模板生成 Word 文件。
|
||||
12. `build_owner_notification`：生成责任人通知载荷。
|
||||
|
||||
## 5. Django 模块落地思路
|
||||
|
||||
### 5.1 Documents
|
||||
|
||||
Documents 是资料治理中心，应从“单文件上传记录”升级为“资料包 + 文件记录 + 解析结果”。
|
||||
|
||||
需要新增或强化：
|
||||
|
||||
1. 资料包批次。
|
||||
2. 压缩包解压记录。
|
||||
3. 原始相对路径。
|
||||
4. 页数和页数可信度。
|
||||
5. 章节点识别状态。
|
||||
6. 文本、表格和标题解析状态。
|
||||
7. 业务资料与法规资料隔离。
|
||||
|
||||
### 5.2 Agent Core
|
||||
|
||||
Agent Core 是审核编排引擎，应沉淀：
|
||||
|
||||
1. 注册资料审核专用输出 schema。
|
||||
2. NMPA 规则包加载器。
|
||||
3. 统一字段池。
|
||||
4. 风险映射规则。
|
||||
5. RAG 证据检索。
|
||||
6. Word 模板回填接口。
|
||||
|
||||
### 5.3 Chat
|
||||
|
||||
Chat 页面应升级为注册审核工作台。
|
||||
|
||||
建议保留自然语言输入，同时提供快捷任务按钮：
|
||||
|
||||
1. 汇总当前资料目录及页数。
|
||||
2. 检查资料完整性。
|
||||
3. 抽取产品核心信息。
|
||||
4. 检查一致性。
|
||||
5. 生成风险预警报告。
|
||||
|
||||
### 5.4 Audit
|
||||
|
||||
Audit 需要记录：
|
||||
|
||||
1. 审核范围。
|
||||
2. 使用的规则版本。
|
||||
3. 参与文件清单。
|
||||
4. 工具调用结果。
|
||||
5. 风险结论。
|
||||
6. 回填输出文件。
|
||||
7. 通知责任人结果。
|
||||
|
||||
## 6. V1 实现优先级
|
||||
|
||||
建议按以下顺序落地，保证演示先闭环：
|
||||
|
||||
1. 批量上传 / 压缩包解压 / 文件目录汇总。
|
||||
2. PDF、DOCX 页数统计和解析状态展示。
|
||||
3. 基于公告附件包整理结构化必交项规则。
|
||||
4. 完整性核查与缺失项风险输出。
|
||||
5. 从目标产品说明书抽取产品名称、靶标、适用范围、储存条件、性能指标。
|
||||
6. 对说明书、申请表、产品列表做字段一致性核查。
|
||||
7. 输出综合风险报告和处理建议。
|
||||
8. 回填预览和 Word 模板导出。
|
||||
9. 责任人通知载荷与飞书机器人演示。
|
||||
|
||||
## 7. 待确认事项
|
||||
|
||||
以下问题不阻塞 V1 需求整理，但会影响实现细节：
|
||||
|
||||
1. “目标文件”具体是注册申请表、对照清单，还是另一个业务方指定模板。
|
||||
2. DOCX 页数是否必须精确，还是允许首版标记为估算。
|
||||
3. 压缩包内多层目录是否按原目录作为章节点依据。
|
||||
4. rar、7z 解压是否允许依赖系统工具，还是必须纯 Python 实现。
|
||||
5. 责任人是按章节点、资料类型、项目角色还是具体人员维护。
|
||||
6. 第 2 至第 6 章是否会补充企业真实样本用于内容级演示。
|
||||
|
||||
## 8. 结论
|
||||
|
||||
本题最稳的设计表达是：
|
||||
|
||||
```text
|
||||
资料包治理 + 本地法规规则包 + 统一字段池 + 规则优先的 Agent 编排 + RAG 证据解释 + 风险与回填输出
|
||||
```
|
||||
|
||||
这样既能覆盖题面五个要求，也能解释为什么系统需要 Django、Documents、Agent Core、RAG、Tool Registry 和 Audit 这些边界。
|
||||
@@ -16,7 +16,7 @@
|
||||
|
||||
系统需要覆盖的业务闭环至少包括：
|
||||
|
||||
1. 扫描申报文件夹，形成资料目录、文件清单、页数统计和章节点归属。
|
||||
1. 导入申报资料包，支持批量文件、文件夹和压缩包形式，形成资料目录、文件清单、页数统计和章节点归属。
|
||||
2. 基于法规要求和申报目录模板，判断资料是否齐全、是否放对位置、是否缺少关键附件。
|
||||
3. 从说明书、申请表、产品列表、声明文件等材料中提取关键信息，形成统一字段池。
|
||||
4. 利用统一字段池回填申请表、对照清单、章节目录或其他待生成文件。
|
||||
@@ -134,6 +134,8 @@
|
||||
|
||||
7. 系统展示当前完整性结论所依据的公告附件、资料要求和模板来源。
|
||||
|
||||
导入环节建议明确支持两种演示路径：一是直接批量上传样例文件，二是上传包含多级目录的压缩包并由系统自动解压。压缩包格式建议覆盖 `zip`、`rar`、`7z`，其中 `rar` 和 `7z` 可在实现设计中根据本地依赖情况选择纯 Python 或系统工具方案。
|
||||
|
||||
## 7. 已确认事项
|
||||
|
||||
以下内容已根据最新沟通结果确认，并已同步进入后续模块需求：
|
||||
@@ -221,6 +223,9 @@
|
||||
2. 用户新写模板进入模板库后，模板版本、生效范围和审批流程是否需要管理。
|
||||
3. 责任人配置是仅按章节点维护，还是同时支持按任务类型、项目角色双维度维护。
|
||||
4. 后端知识库更新入口是否只允许管理员使用，还是允许业务审核人员参与人工校订。
|
||||
5. “自动填写至目标文件”的目标文件具体是注册申请表、法规对照清单、章节目录，还是业务方另行提供的 Word 模板。
|
||||
6. DOCX / DOC 页数统计是否要求达到精确页数，还是允许首版使用估算页数并标记可信度。
|
||||
7. `rar`、`7z` 解包是否允许依赖本地系统工具，还是必须完全使用 Python 库实现。
|
||||
|
||||
## 9. 本轮需求分析采用的默认假设
|
||||
|
||||
@@ -237,6 +242,7 @@
|
||||
9. 飞书接入属于本次 Demo 明确范围，需支持在飞书内完成任务选择、结果查看和责任人通知，并支持群聊机器人入口。
|
||||
10. V1 的法规任务边界先聚焦“注册申报”，变更备案和延续注册在规则架构上预留扩展位，但不作为当前主验收范围。
|
||||
11. 系统需要提供后端管理页面，支持人工校订、模板管理、责任人维护和知识库更新。
|
||||
12. 资料包导入首版应支持批量文件和压缩包，压缩包解包后保留原始相对路径。
|
||||
|
||||
## 10. 结论
|
||||
|
||||
|
||||
@@ -51,7 +51,7 @@ V1 聚焦“可运行、可讲解、可演示”的注册资料审核闭环，
|
||||
### 4.1 V1 必须覆盖
|
||||
|
||||
1. 资料上传与管理
|
||||
2. 文件目录与页数汇总
|
||||
2. 资料包导入、压缩包解包、文件目录与页数汇总
|
||||
3. 法规完整性检查
|
||||
4. 产品关键信息抽取
|
||||
5. 跨文档一致性核查
|
||||
@@ -72,6 +72,8 @@ V1 聚焦“可运行、可讲解、可演示”的注册资料审核闭环，
|
||||
3. 首版法规校验可以本地规则为主，不强依赖联网抓取最新法规。
|
||||
4. 首版需要支持飞书内完成任务选择、结果查看和责任人通知，并支持群聊机器人入口及手动维护责任人 / 飞书账号映射。
|
||||
5. 首版法规任务边界以“注册申报”主流程为核心，变更备案和延续注册暂作为规则扩展方向。
|
||||
6. 首版如 DOCX / DOC 页数无法精确恢复，可标记为估算页数或待复核，但必须在目录汇总中明确可信度。
|
||||
7. 回填目标文件在业务未最终确认前，先以结构化回填字段表和模板回填预览作为交付口径。
|
||||
|
||||
## 5. 业务闭环
|
||||
|
||||
@@ -95,6 +97,8 @@ V1 聚焦“可运行、可讲解、可演示”的注册资料审核闭环，
|
||||
2. 同步建设结构化规则文件，避免让完整性校验完全依赖检索文本。
|
||||
3. 提供后台管理页面，支持人工校订和知识库更新。
|
||||
|
||||
资料导入层需要按“资料包”而不是“单文件”设计。V1 至少应支持批量文件上传，并预留文件夹导入和压缩包导入能力。压缩包导入建议支持 `zip`、`rar`、`7z`，解包后保留原始相对路径，用于生成目录汇总、识别章节点和发现文件夹结构异常。
|
||||
|
||||
在法规维度上，建议把完整流程理解为：
|
||||
|
||||
1. 识别当前审核任务属于“注册申报”主流程。
|
||||
|
||||
@@ -42,6 +42,14 @@
|
||||
|
||||
必要时为后续 OCR 或图片扫描件预留扩展位。
|
||||
|
||||
结合题面“自动汇总文件夹文件目录与页数”的要求，Documents 模块还需要支持资料包级导入，而不是只支持单文件：
|
||||
|
||||
- 多文件批量上传
|
||||
- 文件夹选择或拖拽上传
|
||||
- 压缩包上传并自动解包
|
||||
|
||||
压缩包建议覆盖 `zip`、`rar`、`7z` 等常见格式。解包后应保留压缩包内的原始相对路径，用于还原资料目录、识别章节点和判断是否存在目录层级异常。
|
||||
|
||||
除用户上传的申报资料外，系统还需要支持管理平台内置法规资料，例如：
|
||||
|
||||
- 注册申报资料要求及说明
|
||||
@@ -194,6 +202,15 @@
|
||||
|
||||
如果是批量导入，系统还应支持一次性上传多个资料。
|
||||
|
||||
如果上传的是压缩包，流程应扩展为：
|
||||
|
||||
1. 保存原始压缩包。
|
||||
2. 校验压缩包格式和大小。
|
||||
3. 解包到当前项目 / 批次的隔离目录。
|
||||
4. 遍历解包后的文件并创建文档记录。
|
||||
5. 保留每个文件的原始相对路径和所属压缩包来源。
|
||||
6. 对解包失败、空包、嵌套异常或不支持格式给出业务化提示。
|
||||
|
||||
### 6.2 文件识别与归类流程
|
||||
|
||||
上传后，系统应尽量自动识别文件属于哪个章节点。识别依据可以包括：
|
||||
@@ -222,6 +239,14 @@
|
||||
|
||||
即便首版不能对所有 Word 做精确页数恢复，也需要在需求上明确“统计可信度”和“估算标识”。
|
||||
|
||||
页数结果建议拆分为：
|
||||
|
||||
- `page_count`
|
||||
- `page_count_method`
|
||||
- `page_count_confidence`
|
||||
|
||||
例如 PDF 解析可标记为“精确”，DOCX 首版可标记为“估算”，DOC 或解析失败文件可标记为“待人工复核”。
|
||||
|
||||
### 6.4 文本抽取与索引流程
|
||||
|
||||
系统应按文档类型采用不同策略：
|
||||
@@ -289,9 +314,11 @@ Documents 模块应能直接输出一份“资料目录总览”，字段建议
|
||||
文档列表页不应只是“文件上传记录”，而应成为资料治理面板。建议展示：
|
||||
|
||||
- 文件名
|
||||
- 原始相对路径
|
||||
- 章节点
|
||||
- 资料名称
|
||||
- 页数
|
||||
- 页数可信度
|
||||
- 所属项目 / 批次
|
||||
- 解析状态
|
||||
- 入库状态
|
||||
@@ -364,6 +391,7 @@ Documents 不负责审计结论，但应为审计提供文档 ID、处理过程
|
||||
4. 增加文档归类与页数统计能力。
|
||||
5. 增加重复版本识别和疑似混档识别。
|
||||
6. 增加法规资料类型识别与业务资料 / 法规资料隔离管理。
|
||||
7. 增加资料包导入、压缩包解包、原始相对路径记录和解包异常提示。
|
||||
|
||||
## 13. 验收标准
|
||||
|
||||
|
||||
@@ -93,10 +93,12 @@
|
||||
|
||||
### 处理逻辑
|
||||
|
||||
1. 遍历当前项目 / 批次所有资料。
|
||||
2. 汇总文件名、章节点、页数、状态。
|
||||
3. 识别目录类文档与普通文档。
|
||||
4. 输出目录总表。
|
||||
1. 接收 Documents 模块提供的资料包、批量文件或压缩包解包结果。
|
||||
2. 遍历当前项目 / 批次所有资料。
|
||||
3. 保留原始相对路径、文件名、文件类型、页数、页数可信度和处理状态。
|
||||
4. 识别目录类文档与普通文档。
|
||||
5. 识别章节点、资料名称和是否命中法规目录项。
|
||||
6. 输出目录总表。
|
||||
|
||||
### 输出要求
|
||||
|
||||
@@ -105,6 +107,7 @@
|
||||
- 文件清单
|
||||
- 文件数量
|
||||
- 总页数
|
||||
- 页数统计可信度
|
||||
- 已识别章节点
|
||||
- 待确认文档
|
||||
|
||||
@@ -123,6 +126,8 @@
|
||||
- 题面中提及的 NMPA / CMDE 法规来源
|
||||
- `关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告` 附件包
|
||||
|
||||
V1 默认以 `docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/` 下的公告附件包作为主规则源。NMPA / CMDE 官网链接用于说明法规来源和后续在线更新方向，不作为当前演示时的唯一实时依赖。
|
||||
|
||||
结合新增公告附件包，法规规则来源建议分层管理：
|
||||
|
||||
1. 注册申报资料要求及说明
|
||||
@@ -241,6 +246,8 @@
|
||||
- 新的 Word 文档生成与导出能力
|
||||
- 基于模板库的高保真版式回填能力
|
||||
|
||||
当前题面只说明“自动填写至目标文件”，但未明确目标文件是哪一类表格。结合现有材料，V1 默认先把 `目标产品说明书` 中抽取的产品名称、检测靶标、适用范围、储存条件、性能指标等字段写入统一字段池，并输出申请表 / 对照清单方向的回填预览。目标模板一旦确认，再通过模板库字段映射生成具体 Word 文件。
|
||||
|
||||
### 处理逻辑
|
||||
|
||||
1. 根据目标模板定义字段映射。
|
||||
@@ -441,19 +448,22 @@ LLM 负责把这些动作组织成自然语言建议，但不能改变底层规
|
||||
|
||||
建议工具方向包括：
|
||||
|
||||
1. 文档页数统计工具
|
||||
2. 章节点识别工具
|
||||
3. 必交项检查工具
|
||||
4. 字段抽取工具
|
||||
5. 字段一致性比对工具
|
||||
6. 风险汇总工具
|
||||
7. 审核范围确认工具
|
||||
8. 法规流程识别工具
|
||||
9. 格式模板映射工具
|
||||
10. Word 模板回填与导出工具
|
||||
11. 飞书消息摘要生成与通知载荷组装工具
|
||||
12. 责任人映射解析工具
|
||||
13. 规则切片与结构化回写工具
|
||||
1. 资料包扫描工具
|
||||
2. `zip` / `rar` / `7z` 压缩包解包工具
|
||||
3. 文档页数统计工具
|
||||
4. 章节点识别工具
|
||||
5. 必交项检查工具
|
||||
6. 字段抽取工具
|
||||
7. 字段一致性比对工具
|
||||
8. 文档结构规范检查工具
|
||||
9. 风险汇总工具
|
||||
10. 审核范围确认工具
|
||||
11. 法规流程识别工具
|
||||
12. 格式模板映射工具
|
||||
13. Word 模板回填与导出工具
|
||||
14. 飞书消息摘要生成与通知载荷组装工具
|
||||
15. 责任人映射解析工具
|
||||
16. 规则切片与结构化回写工具
|
||||
|
||||
这些工具都应通过 Tool Registry 注册，符合项目既有边界要求。
|
||||
|
||||
|
||||
@@ -32,6 +32,7 @@
|
||||
7. 法规知识按“章 -> 条 -> 要求项 -> 模板字段”四级结构维护。
|
||||
8. 飞书接入属于本次 Demo 范围，需要支持群聊机器人，并在飞书内完成任务选择、结果查看和责任人通知。
|
||||
9. 系统需要提供后台管理页面，支持人工校订、知识库更新、模板管理和责任人维护。
|
||||
10. 资料导入应按资料包处理，首版支持批量文件和压缩包，压缩包建议覆盖 `zip`、`rar`、`7z`。
|
||||
|
||||
---
|
||||
|
||||
@@ -158,6 +159,30 @@
|
||||
|
||||
- 决定一致性冲突是“核心演示点”还是“样本噪声”。
|
||||
|
||||
### Q6-1 资料包导入需要支持哪些输入形式？
|
||||
|
||||
建议提问方式：
|
||||
|
||||
> 资料一般会以什么形式交给系统？是直接选择一个文件夹、批量选择多个文件，还是上传一个压缩包？
|
||||
|
||||
建议引导业务按下列类型回答：
|
||||
|
||||
1. 批量文件
|
||||
2. 文件夹
|
||||
3. zip 压缩包
|
||||
4. rar 压缩包
|
||||
5. 7z 压缩包
|
||||
|
||||
建议记录答案：
|
||||
|
||||
- 必须支持：
|
||||
- 可后续支持：
|
||||
- 是否需要保留压缩包内原始目录：
|
||||
|
||||
为什么要问：
|
||||
|
||||
- 决定 Documents 模块的上传、解包、目录还原和异常提示实现。
|
||||
|
||||
---
|
||||
|
||||
## 4.3 自动审核与人工复核边界
|
||||
|
||||
Reference in New Issue
Block a user