docs(需求分析): 按Agent原型重写核心需求
This commit is contained in:
@@ -2,199 +2,252 @@
|
||||
|
||||
## 1. 文档目的
|
||||
|
||||
本文档作为当前项目 V1 阶段的总需求索引文档，用于统一说明本轮笔试题对应的产品定位、目标用户、核心业务闭环、模块拆分方式和后续阅读路径。
|
||||
本文档用于基于最新版演示原型、现有原始材料和项目边界，重新定义 V1 阶段的需求基线。
|
||||
|
||||
与历史“通用 AI Agent Demo 框架”定位不同，本轮 V1 需求以 `docs/` 目录中的真实题面与资料样本为准，系统目标已经切换为：
|
||||
当前系统不再按“传统审核系统多页面菜单”叙事，而是明确采用：
|
||||
|
||||
> 试剂盒临床注册文件准备与审核智能体平台
|
||||
> 以 Agent 对话为核心的试剂盒临床注册文件准备与审核平台
|
||||
|
||||
V1 需要同时满足三类目标：
|
||||
|
||||
1. 能用对话驱动审核任务。
|
||||
2. 能把资料包、知识库、审核记录和飞书通知纳入统一闭环。
|
||||
3. 能以可讲解、可追溯、可扩展的方式支撑后续 Django 实现。
|
||||
|
||||
## 2. 产品定位
|
||||
|
||||
本系统面向 **NMPA 境内第三类体外诊断试剂注册申报资料准备与审核** 场景，服务于需要整理、核查、抽取、回填和追踪注册资料的业务人员。
|
||||
本系统面向 NMPA 境内第三类体外诊断试剂注册申报资料准备与审核场景，服务对象包括：
|
||||
|
||||
系统主体围绕注册申报审核场景展开，但能力目标是沉淀为“通用的试剂盒临床注册文件准备与审核智能体”，而不是只绑定某一个具体试剂盒产品。
|
||||
1. 注册申报专员
|
||||
2. 注册资料负责人
|
||||
3. 质量/法规专员
|
||||
4. 审核复核人员
|
||||
5. 平台治理管理员
|
||||
|
||||
系统不再以“适配任意业务题”的通用 Demo 作为对外主叙事，而是聚焦以下业务价值：
|
||||
产品不再只是“上传文件后生成报表”的审核系统，也不只是“自由聊天的问答机器人”，而是一个围绕资料包审核任务编排的 Agent 工作台。
|
||||
|
||||
1. 自动汇总注册资料目录与页数。
|
||||
2. 对照法规要求检查资料完整性。
|
||||
3. 抽取产品关键信息并形成统一字段池。
|
||||
4. 支持将产品核心信息自动填入注册申报表格或对照清单。
|
||||
5. 核查跨文档信息一致性与章节规范性。
|
||||
6. 输出合规风险预警和处理建议。
|
||||
## 3. 最新版原型对应的产品形态
|
||||
|
||||
## 3. 原始材料依据
|
||||
基于当前最新版原型，V1 顶层产品形态固定为 4 个一级入口：
|
||||
|
||||
当前需求分析主要基于以下材料整理：
|
||||
1. `审核智能体`
|
||||
2. `资料包`
|
||||
3. `知识库`
|
||||
4. `处理历史`
|
||||
|
||||
1. `docs/【模拟题二】试剂盒临床注册文件准备与审核Agent/【模拟题二】试剂盒临床注册文件准备与审核Agent.md`
|
||||
2. `docs/目标产品说明书.docx`
|
||||
3. `docs/附件 4 体外诊断试剂注册申报资料要求及说明.doc`
|
||||
4. `docs/第1章 监管信息/` 下的监管目录、申请表、产品列表、声明与沟通记录样例
|
||||
5. `docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/` 下的公告附件包
|
||||
这 4 个入口分别承担：
|
||||
|
||||
其中新增公告附件包使法规依据不再只是单篇“资料要求说明”，而是扩展为一组正式规则来源，包括：
|
||||
### 3.1 审核智能体
|
||||
|
||||
1. 体外诊断试剂注册申报资料要求及说明
|
||||
2. 医疗器械注册申报资料和批准证明文件格式要求（体外诊断试剂）
|
||||
3. 体外诊断试剂安全和性能基本原则清单
|
||||
4. 中华人民共和国医疗器械注册证（体外诊断试剂）格式
|
||||
5. 体外诊断试剂变更备案 / 变更注册申报资料要求及说明
|
||||
6. 体外诊断试剂延续注册申报资料要求及说明
|
||||
作为统一任务入口，承接：
|
||||
|
||||
当前 V1 默认以“公告附件包”作为主规则来源，并将 `附件 4 体外诊断试剂注册申报资料要求及说明` 视作同源补充材料，而不是独立的第二套规则来源。
|
||||
1. 资料上传
|
||||
2. 自然语言提问
|
||||
3. 任务模板选择
|
||||
4. 节点式审核执行
|
||||
5. 结构化结论查看
|
||||
6. 风险与整改建议输出
|
||||
|
||||
## 4. V1 范围
|
||||
### 3.2 资料包
|
||||
|
||||
V1 聚焦“可运行、可讲解、可演示”的注册资料审核闭环，不追求一次性做成完整商业平台。
|
||||
作为资料治理入口，承接：
|
||||
|
||||
### 4.1 V1 必须覆盖
|
||||
1. 资料包导入
|
||||
2. 按产品名称建立资料包记录
|
||||
3. 资料包与对话会话关联
|
||||
4. 目录、页数、章节点、异常结果查看
|
||||
5. 按产品名称或批次号搜索资料包
|
||||
|
||||
1. 资料上传与管理
|
||||
2. 资料包导入、压缩包解包、文件目录与页数汇总
|
||||
3. 法规完整性检查
|
||||
4. 产品关键信息抽取
|
||||
5. 跨文档一致性核查
|
||||
6. 风险预警输出
|
||||
7. 审计留痕
|
||||
8. 本地可运行与 Docker 演示启动
|
||||
### 3.3 知识库
|
||||
|
||||
其中第 3 项“法规完整性检查”在 V1 中建议明确分为三层：
|
||||
作为治理入口，承接：
|
||||
|
||||
1. 资料齐套性检查
|
||||
2. 章节点和结构合规性检查
|
||||
3. 批准证明文件格式与输出映射检查
|
||||
1. 法规资料上传
|
||||
2. 业务资料上传
|
||||
3. RAG 文档源管理
|
||||
4. 切片解析与向量入库
|
||||
5. 字段 Schema 管理
|
||||
6. 模板映射管理
|
||||
7. 飞书通知配置与责任人映射
|
||||
|
||||
### 4.2 V1 可接受的简化
|
||||
其中“法规依据”不再单独作为顶级页面存在，而是作为知识库中的法规资料，通过 RAG 命中在 Agent 对话中返回。
|
||||
|
||||
1. 首版可优先覆盖第 1 章监管信息，并为全章扩展预留结构。
|
||||
2. 首版即要求具备“生成新的 Word 文档并支持导出”的能力，且输出版式必须达到可直接报送级别。
|
||||
3. 首版法规校验可以本地规则为主，不强依赖联网抓取最新法规。
|
||||
4. 首版需要支持飞书内完成任务选择、结果查看和责任人通知，并支持群聊机器人入口及手动维护责任人 / 飞书账号映射。
|
||||
5. 首版法规任务边界以“注册申报”主流程为核心，变更备案和延续注册暂作为规则扩展方向。
|
||||
6. DOCX 页数必须精确统计，不能以估算页数作为 V1 验收结果；DOC 如受格式限制无法精确统计，应标记为待复核。
|
||||
7. 回填目标已确认为注册申报表格或对照清单，首版应输出结构化回填结果，并支持按模板生成 Word 文件。
|
||||
### 3.4 处理历史
|
||||
|
||||
## 5. 业务闭环
|
||||
作为留痕入口，承接：
|
||||
|
||||
建议按以下业务闭环理解整套系统：
|
||||
1. 按批次回看历史任务
|
||||
2. 查看资料规模和任务类型
|
||||
3. 查看最终结论和风险状态
|
||||
4. 查看关联会话、附件和摘要
|
||||
5. 支撑审计与复核
|
||||
|
||||
1. 导入注册申报资料。
|
||||
2. 识别文档、统计页数、构建目录。
|
||||
3. 依据法规目录进行完整性核查。
|
||||
4. 从说明书、申请表、产品列表等材料中抽取统一字段。
|
||||
5. 将产品名称、检测靶标、适用范围、储存条件、性能指标等核心信息自动填入注册申报表格或对照清单。
|
||||
6. 对同名字段进行跨文档一致性比对。
|
||||
7. 形成风险清单、回填结果和审计记录。
|
||||
## 4. 原始材料依据
|
||||
|
||||
在规则执行层，建议采用“双层知识底座”：
|
||||
当前需求分析以以下资料为主：
|
||||
|
||||
1. 结构化规则文件负责完整性判断、强一致比对和风险映射。
|
||||
2. 公告附件原文切片入 RAG，负责条款引用、证据检索和解释说明。
|
||||
1. `docs/原始材料/【模拟题二】试剂盒临床注册文件准备与审核Agent.docx`
|
||||
2. `docs/原始材料/目标产品说明书.docx`
|
||||
3. `docs/原始材料/附件 4 体外诊断试剂注册申报资料要求及说明.doc`
|
||||
4. `docs/原始材料/第1章 监管信息/` 下样例资料
|
||||
5. `docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/` 下公告附件包
|
||||
6. 最新版原型文件 `docs/原型设计/registration-prototype-demo.html`
|
||||
|
||||
其中法规知识维护方式应固定为：
|
||||
## 5. V1 核心业务闭环
|
||||
|
||||
1. 按“章 -> 条 -> 要求项 -> 模板字段”四级结构维护。
|
||||
2. 同步建设结构化规则文件，避免让完整性校验完全依赖检索文本。
|
||||
3. 提供后台管理页面，支持人工校订和知识库更新。
|
||||
V1 需要围绕以下闭环展开：
|
||||
|
||||
资料导入层需要按“资料包”而不是“单文件”设计。V1 至少应支持批量文件上传、文件夹导入和压缩包导入能力。压缩包导入支持 `zip`、`rar`、`7z`，解包后保留原始相对路径，并将压缩包内多层目录按原目录作为章节点识别依据。`rar`、`7z` 解压必须采用纯 Python 实现，允许增加第三方依赖包，避免服务器部署时依赖系统级解压工具。
|
||||
1. 导入资料包。
|
||||
2. 解析资料包并识别产品名称。
|
||||
3. 以解析后的产品名称建立资料包记录和对话会话。
|
||||
4. 汇总目录、页数和章节点。
|
||||
5. 基于法规规则和 RAG 证据执行完整性检查。
|
||||
6. 抽取统一字段池并执行一致性核查。
|
||||
7. 汇总风险并给出是否允许正式导出的结论。
|
||||
8. 在任务完成或出现异常时，通过飞书 `@` 对应处理人。
|
||||
9. 将过程结果写入处理历史与审计留痕。
|
||||
|
||||
第 2 至第 6 章首版不补充企业真实样本，先以公告附件包进行资料要求、章节点结构和模板口径的规则级初步确认。责任人首版通过后台或配置文件手动维护，并按资料章节配置。
|
||||
## 6. V1 必须覆盖的能力
|
||||
|
||||
在法规维度上，建议把完整流程理解为：
|
||||
### 6.1 Agent 对话驱动
|
||||
|
||||
1. 识别当前审核任务属于“注册申报”主流程。
|
||||
2. 匹配对应的资料要求与章节点模板。
|
||||
3. 检查资料齐套性与章节结构。
|
||||
4. 对需要回填或输出的批准证明文件格式做字段映射准备。
|
||||
1. 支持通过对话发起审核任务。
|
||||
2. 支持上传附件并结合当前会话继续执行。
|
||||
3. 支持推荐提示词模板。
|
||||
4. 支持以节点方式展示目录汇总、完整性检查、字段抽取、一致性核查和风险结论。
|
||||
|
||||
## 6. 模块拆分
|
||||
### 6.2 资料包中心
|
||||
|
||||
V1 需求分析按项目现有主模块拆分，不做过度细分：
|
||||
1. 支持批量文件、文件夹、压缩包导入。
|
||||
2. 支持资料包与会话一一关联。
|
||||
3. 对话名称默认采用解析后的产品名称。
|
||||
4. 支持按产品名称和批次号搜索资料包。
|
||||
5. 支持从资料包跳转回对应对话。
|
||||
|
||||
1. [1.config模块需求分析.md](F:\PyCharm\DEMO-AGENT\docs\需求分析\1.config模块需求分析.md)
|
||||
2. [2.scenarios模块需求分析.md](F:\PyCharm\DEMO-AGENT\docs\需求分析\2.scenarios模块需求分析.md)
|
||||
3. [3.documents模块需求分析.md](F:\PyCharm\DEMO-AGENT\docs\需求分析\3.documents模块需求分析.md)
|
||||
4. [4.chat模块需求分析.md](F:\PyCharm\DEMO-AGENT\docs\需求分析\4.chat模块需求分析.md)
|
||||
5. [5.audit模块需求分析.md](F:\PyCharm\DEMO-AGENT\docs\需求分析\5.audit模块需求分析.md)
|
||||
6. [6.agent_core模块需求分析.md](F:\PyCharm\DEMO-AGENT\docs\需求分析\6.agent_core模块需求分析.md)
|
||||
### 6.3 知识库与 RAG
|
||||
|
||||
另附一份待确认事项文档，供与需求方沟通时直接使用：
|
||||
1. 支持法规资料和业务资料分层管理。
|
||||
2. 支持 RAG 文档源 CRUD。
|
||||
3. 支持切片解析、重建向量和召回状态管理。
|
||||
4. 支持在对话中返回法规命中依据。
|
||||
5. 支持字段 Schema、模板映射、责任人映射和飞书配置治理。
|
||||
|
||||
- [0.需求重构总览与待确认事项.md](F:\PyCharm\DEMO-AGENT\docs\需求分析\0.需求重构总览与待确认事项.md)
|
||||
### 6.4 风险与导出
|
||||
|
||||
## 7. 当前识别出的关键业务特征
|
||||
1. 支持完整性风险、字段冲突风险、混档风险、低置信度风险统一汇总。
|
||||
2. 支持草稿导出与正式导出阻断。
|
||||
3. 支持结构化整改建议。
|
||||
|
||||
### 7.1 审核对象是“资料包”
|
||||
### 6.5 飞书协同
|
||||
|
||||
本题输入对象是整套注册申报资料，不是单篇文档问答。
|
||||
1. 支持飞书群聊/机器人通知。
|
||||
2. 风险任务执行完成或执行异常时，可直接 `@` 处理人。
|
||||
3. 责任人信息中必须包含飞书账号相关字段。
|
||||
4. 支持通过 Web 详情链接回到平台查看完整结果。
|
||||
|
||||
### 7.2 审核标准是“法规目录 + 资料内容”
|
||||
## 7. 关键业务对象
|
||||
|
||||
系统既要看是否有文件，也要看是否放对章节点、内容是否对应。
|
||||
### 7.1 资料包
|
||||
|
||||
### 7.3 系统必须具备“冲突识别”
|
||||
资料包是 V1 的一级业务对象，不再把“单文件”视为默认审核对象。
|
||||
|
||||
当前样例中已经存在不同产品资料混入的迹象。这不要求系统默认把全部材料视为同一个产品，而是要求系统具备以下能力：
|
||||
资料包至少包含：
|
||||
|
||||
1. 支持按项目批次或文档范围界定审核对象。
|
||||
2. 对被划入同一审核对象的资料执行严格一致性检查。
|
||||
3. 对混档、错归类和跨产品资料混入给出风险提示。
|
||||
1. `batch_id`
|
||||
2. `product_name`
|
||||
3. `conversation_id`
|
||||
4. `workflow_type`
|
||||
5. `file_count`
|
||||
6. `page_count`
|
||||
7. `chapter_summary`
|
||||
8. `import_status`
|
||||
|
||||
### 7.4 系统必须具备“可解释性”
|
||||
### 7.2 对话会话
|
||||
|
||||
所有缺失判断、字段抽取和风险预警都应尽量有证据、有来源、有审计记录。
|
||||
会话与资料包绑定，至少包含：
|
||||
|
||||
### 7.5 系统必须具备“法规分层引用”
|
||||
1. `conversation_id`
|
||||
2. `product_name`
|
||||
3. `batch_id`
|
||||
4. `task_status`
|
||||
5. `messages`
|
||||
6. `node_results`
|
||||
|
||||
结合新增公告附件包，系统应能区分并引用不同层级的规则来源，而不是把所有法规依据混成一条说明：
|
||||
### 7.3 角色信息
|
||||
|
||||
1. 资料要求类依据
|
||||
2. 格式要求类依据
|
||||
3. 安全和性能基本原则类依据
|
||||
4. 批准证明文件格式类依据
|
||||
角色信息需要从“只有角色名”升级为“可通知的责任人实体”，至少包含：
|
||||
|
||||
### 7.6 系统需要具备“多入口访问能力”
|
||||
1. `owner_role`
|
||||
2. `owner_name`
|
||||
3. `department`
|
||||
4. `chapter_scope`
|
||||
5. `risk_scope`
|
||||
6. `feishu_user_id`
|
||||
7. `feishu_open_id`
|
||||
8. `feishu_name`
|
||||
9. `notify_enabled`
|
||||
|
||||
V1 除 Web 工作台外，还需要实际支持飞书入口能力，使审核任务可以从浏览器工作台扩展到飞书会话和飞书群聊机器人场景。
|
||||
### 7.4 飞书通知任务
|
||||
|
||||
### 7.7 系统需要具备“后台治理能力”
|
||||
飞书通知对象至少包含：
|
||||
|
||||
除前台审核能力外，V1 还需要提供后台管理能力，用于维护规则包、模板库、责任人映射和知识库更新入口。
|
||||
1. `batch_id`
|
||||
2. `conversation_id`
|
||||
3. `trigger_source`
|
||||
4. `notify_reason`
|
||||
5. `owner_role`
|
||||
6. `feishu_user_id`
|
||||
7. `message_status`
|
||||
8. `web_detail_url`
|
||||
|
||||
## 8. 后续文档与实现衔接建议
|
||||
## 8. 需求约束
|
||||
|
||||
后续若继续推进设计与开发，建议按如下顺序展开：
|
||||
### 8.1 规则优先
|
||||
|
||||
1. 先确认待确认事项中的产品范围、回填目标和法规范围。
|
||||
2. 基于模块需求文档输出设计文档。
|
||||
3. 按 `config -> scenarios -> documents -> agent_core -> chat -> audit` 顺序推进重构。
|
||||
4. 同步更新 README、AGENTS 和场景配置命名。
|
||||
完整性检查、强一致判断、导出阻断必须规则优先，LLM 只做解释和补充。
|
||||
|
||||
当前仓库已补充一组演示型原型设计文档与单文件 HTML，作为设计到实现之间的中间层交付：
|
||||
### 8.2 RAG 职责边界
|
||||
|
||||
- [整体原型设计](F:\PyCharm\DEMO-AGENT\docs\原型设计\1.整体原型设计.md)
|
||||
- [分页原型设计目录](F:\PyCharm\DEMO-AGENT\docs\原型设计)
|
||||
- [单文件演示站 HTML](F:\PyCharm\DEMO-AGENT\docs\原型设计\registration-prototype-demo.html)
|
||||
RAG 负责：
|
||||
|
||||
该组原型资产覆盖：
|
||||
1. 法规依据定位
|
||||
2. 业务资料证据定位
|
||||
3. 对话解释支撑
|
||||
|
||||
1. 资料包导入页
|
||||
2. 审核任务工作台
|
||||
3. 法规完整性检查页
|
||||
4. 字段抽取与字段池页
|
||||
5. 一致性核查页
|
||||
6. 风险预警页
|
||||
7. Word 回填导出页
|
||||
8. 飞书通知视图
|
||||
9. 知识库与治理台 CRUD 设计
|
||||
RAG 不直接代替规则引擎输出最终合规结论。
|
||||
|
||||
## 9. 结论
|
||||
### 8.3 飞书通知触发方式
|
||||
|
||||
当前 V1 需求已经从“通用 Agent Demo 基座”重构为“注册申报资料审核系统”。后续所有设计、实现和讲解，建议都围绕以下四个关键词展开：
|
||||
当前 Demo 要求固定支持两类通知时机：
|
||||
|
||||
1. 文件夹级资料治理
|
||||
2. 法规目录级完整性校验
|
||||
3. 统一字段池与跨文档一致性检查
|
||||
4. 可追溯的风险预警与审计留痕
|
||||
1. 任务执行完成后发送结果摘要并 `@` 处理人。
|
||||
2. 任务执行异常后发送异常摘要并 `@` 处理人。
|
||||
|
||||
### 8.4 本地可演示
|
||||
|
||||
V1 必须保持：
|
||||
|
||||
1. Web 可访问
|
||||
2. 关键流程可离线演示
|
||||
3. 不依赖真实大模型在线调用才能完成基础演示
|
||||
|
||||
## 9. 模块拆分建议
|
||||
|
||||
仍按现有模块边界推进，但职责解释需要更新：
|
||||
|
||||
1. `config`：配置、静态资源、环境变量、飞书集成基础配置
|
||||
2. `documents`：资料包、文档、页数、目录、章节点、资料搜索
|
||||
3. `chat`：Agent 对话工作台、节点执行区、提示词模板、会话历史
|
||||
4. `audit`：处理历史、审计链路、通知留痕
|
||||
5. `agent_core`：审核编排、规则执行、RAG 检索、结构化输出
|
||||
|
||||
## 10. 本轮重写结论
|
||||
|
||||
V1 现在的正确叙事应是：
|
||||
|
||||
1. 以资料包为审核对象。
|
||||
2. 以 Agent 对话为主要执行入口。
|
||||
3. 以知识库/RAG 为法规和业务依据底座。
|
||||
4. 以处理历史和飞书协同保证可追溯和可协同。
|
||||
|
||||
这意味着后续需求分析和详细设计都应围绕“Agent 工作台式产品”继续重写，而不再沿用旧的固定报表式多页面系统思路。
|
||||
|
||||
@@ -2,406 +2,117 @@
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
`apps.documents` 是本题最关键的业务入口之一。对于“试剂盒临床注册文件准备与审核”场景，它不只是一个上传附件页面，而是：
|
||||
`apps.documents` 不再只是“文件上传页”，而是：
|
||||
|
||||
> 注册申报资料治理中心
|
||||
> 资料包中心
|
||||
|
||||
该模块需要承接从资料接收、文件识别、内容抽取、章节点归类、页数统计、入库索引到状态反馈的完整过程。
|
||||
它负责让资料包成为可查询、可绑定会话、可参与审核、可进入知识库和可触发通知的一级业务对象。
|
||||
|
||||
## 2. 业务目标
|
||||
## 2. 模块目标
|
||||
|
||||
本模块需要支撑以下真实业务目标：
|
||||
本模块需要支撑以下目标：
|
||||
|
||||
1. 接收注册申报资料包中的各类文件。
|
||||
2. 建立每份文件的结构化档案。
|
||||
3. 自动形成目录汇总和页数统计结果。
|
||||
4. 为法规完整性核查和一致性核查提供可靠的文档底座。
|
||||
5. 为抽取、回填、审计和导出提供统一的文档主数据。
|
||||
1. 接收资料包导入。
|
||||
2. 识别资料包产品名称。
|
||||
3. 统计文件数、页数和章节点。
|
||||
4. 将资料包与对话记录绑定。
|
||||
5. 支持按产品名称和批次号搜索资料包。
|
||||
6. 为后续完整性检查、字段抽取和一致性核查提供文档底座。
|
||||
|
||||
结合新增公告材料，本模块还应承担“法规原文资料资产管理”的基础职责，即把上传的业务资料与平台内置的法规依据材料区分管理。
|
||||
## 3. 资料包优先原则
|
||||
|
||||
## 3. 为什么 Documents 模块是本题核心
|
||||
V1 以资料包为主对象，而不是单文件。
|
||||
|
||||
题面第一条就要求“自动汇总注册申报文件夹中的所有文件及页数”，第二条要求“对照 NMPA 法规要求核查文件完整性”。这两个要求都建立在一个前提上：
|
||||
资料包记录至少需要：
|
||||
|
||||
系统必须先“看懂当前资料包里到底有什么”。
|
||||
1. `batch_id`
|
||||
2. `product_name`
|
||||
3. `conversation_id`
|
||||
4. `workflow_type`
|
||||
5. `file_count`
|
||||
6. `page_count`
|
||||
7. `chapter_summary`
|
||||
8. `import_status`
|
||||
9. `exception_count`
|
||||
|
||||
因此，Documents 模块不是配角，而是全流程的第一责任模块。
|
||||
## 4. 产品名称解析要求
|
||||
|
||||
## 4. 核心职责
|
||||
资料包导入后需要尽早解析产品名称，用于：
|
||||
|
||||
### 4.1 原始文件接收
|
||||
1. 生成会话标题
|
||||
2. 建立资料包搜索索引
|
||||
3. 支持同产品批次管理
|
||||
4. 作为后续字段抽取和一致性核查的主键之一
|
||||
|
||||
支持上传和保存：
|
||||
首版产品名称优先来源：
|
||||
|
||||
- PDF
|
||||
- DOCX
|
||||
- DOC
|
||||
- MD
|
||||
- TXT
|
||||
1. 申请表
|
||||
2. 说明书
|
||||
3. 产品列表
|
||||
|
||||
必要时为后续 OCR 或图片扫描件预留扩展位。
|
||||
若多个来源冲突，可先取主来源值建立会话标题，同时把冲突标记给后续一致性核查处理。
|
||||
|
||||
结合题面“自动汇总文件夹文件目录与页数”的要求，Documents 模块还需要支持资料包级导入，而不是只支持单文件：
|
||||
## 5. 支持的导入能力
|
||||
|
||||
- 多文件批量上传
|
||||
- 文件夹选择或拖拽上传
|
||||
- 压缩包上传并自动解包
|
||||
1. 多文件上传
|
||||
2. 文件夹导入
|
||||
3. 压缩包导入
|
||||
4. 批次追加上传
|
||||
|
||||
压缩包覆盖 `zip`、`rar`、`7z` 等常见格式。解包后应保留压缩包内的原始相对路径，并将多层目录按原目录作为章节点识别依据，用于还原资料目录、识别章节点和判断是否存在目录层级异常。
|
||||
压缩包仍要求支持：
|
||||
|
||||
`rar`、`7z` 解压必须采用纯 Python 实现，允许新增第三方 Python 包依赖，避免服务器部署时依赖系统级解压工具。
|
||||
1. `zip`
|
||||
2. `rar`
|
||||
3. `7z`
|
||||
|
||||
除用户上传的申报资料外，系统还需要支持管理平台内置法规资料，例如：
|
||||
并保留原始相对路径。
|
||||
|
||||
- 注册申报资料要求及说明
|
||||
- 批准证明文件格式要求
|
||||
- 安全和性能基本原则清单
|
||||
- 注册证 / 变更注册（备案）文件格式
|
||||
## 6. 页面与交互要求
|
||||
|
||||
### 4.2 文件基础信息管理
|
||||
基于最新版原型，资料包页需要支持：
|
||||
|
||||
每份资料至少要记录：
|
||||
1. 资料包总览表
|
||||
2. 产品名称搜索框
|
||||
3. 按批次号辅助查询
|
||||
4. 从资料包跳转回对应对话
|
||||
5. 文件清单与章节点展示
|
||||
|
||||
- 文件 ID
|
||||
- 原始文件名
|
||||
- 文件类型
|
||||
- 文件大小
|
||||
- 上传时间
|
||||
- 所属项目 / 批次
|
||||
- 所属任务或场景
|
||||
- 当前处理状态
|
||||
## 7. 搜索需求
|
||||
|
||||
对于法规资料，建议额外记录：
|
||||
资料包页至少应支持：
|
||||
|
||||
- 法规类型
|
||||
- 法规流程类型
|
||||
- 版本来源
|
||||
- 是否为系统内置规则依据
|
||||
1. 按产品名称搜索
|
||||
2. 按批次号搜索
|
||||
|
||||
### 4.3 页数统计与目录归属
|
||||
搜索结果应直接返回资料包记录，而不是只返回文件。
|
||||
|
||||
系统要能为每份文件识别：
|
||||
## 8. 与对话记录的关系
|
||||
|
||||
- 页数
|
||||
- 章节归属
|
||||
- 资料名称
|
||||
- 是否匹配法规目录项
|
||||
Documents 模块需要对外提供：
|
||||
|
||||
这部分是题面要求中的显式能力，不能只靠 Chat 页面临时回答。
|
||||
1. `conversation_id`
|
||||
2. `product_name`
|
||||
3. `batch_id`
|
||||
|
||||
### 4.4 文本与表格抽取
|
||||
确保：
|
||||
|
||||
为后续规则比对和字段提取，需要抽取：
|
||||
1. 一个资料包可以定位到一个主会话
|
||||
2. 一个主会话默认绑定一个资料包
|
||||
3. 用户可以从资料包页直接跳到会话页
|
||||
|
||||
- 正文文本
|
||||
- 标题层级
|
||||
- 表格内容
|
||||
- 可能的关键信息段落
|
||||
## 9. 与知识库的关系
|
||||
|
||||
例如 `目标产品说明书.docx` 中大量关键信息位于结构化段落和表格中，若只做粗暴全文提取，会显著影响抽取质量。
|
||||
Documents 管理的是审核资料包；知识库管理的是法规资料、模板资料和业务知识资料。
|
||||
|
||||
### 4.5 入库索引
|
||||
二者都属于文档资产，但职责不同：
|
||||
|
||||
对适合检索的内容建立索引，供 `agent_core` 的 RAG 或规则定位使用。
|
||||
1. 资料包用于当前审核任务事实输入
|
||||
2. 知识库用于 RAG 检索、法规依据和模板治理
|
||||
|
||||
对法规原文资料，建议单独建立“法规知识索引”，切片时优先保留以下结构语义：
|
||||
## 10. 验收标准
|
||||
|
||||
- 所属法规文档
|
||||
- 适用流程类型
|
||||
- 章 / 条 / 清单项编号
|
||||
- 模板字段或格式要求类型
|
||||
|
||||
### 4.6 状态反馈与异常处理
|
||||
|
||||
文件处理流程要有明确状态，例如：
|
||||
|
||||
- 已上传
|
||||
- 已解析
|
||||
- 已入库
|
||||
- 解析失败
|
||||
- 待人工确认
|
||||
|
||||
不能只记录一个“成功 / 失败”。
|
||||
|
||||
## 5. 注册资料业务下的文件模型需求
|
||||
|
||||
### 5.1 现有上传模型的不足
|
||||
|
||||
当前 `UploadedDocument` 更像一个通用文档记录，适合简单 RAG Demo，但对本题不够。至少还缺少以下业务字段：
|
||||
|
||||
- `project_id` 或 `submission_batch_id`
|
||||
- `chapter_code`
|
||||
- `chapter_name`
|
||||
- `document_code`
|
||||
- `declared_document_name`
|
||||
- `page_count`
|
||||
- `source_version`
|
||||
- `extraction_status`
|
||||
- `index_status`
|
||||
- `consistency_status`
|
||||
- `completeness_match_status`
|
||||
|
||||
### 5.2 建议新增的业务语义字段
|
||||
|
||||
#### 5.2.1 章节点字段
|
||||
|
||||
需要支持类似：
|
||||
|
||||
- `CH1.2`
|
||||
- `CH1.4`
|
||||
- `CH1.5`
|
||||
- `CH1.11.5`
|
||||
|
||||
这样系统才能把法规模板、样例目录和实际文件真正对齐。
|
||||
|
||||
#### 5.2.2 文档类别字段
|
||||
|
||||
例如：
|
||||
|
||||
- 监管信息
|
||||
- 综述资料
|
||||
- 非临床资料
|
||||
- 临床评价资料
|
||||
- 产品说明书和标签样稿
|
||||
- 质量管理体系文件
|
||||
|
||||
#### 5.2.3 处理质量字段
|
||||
|
||||
建议记录：
|
||||
|
||||
- 是否成功提取文本
|
||||
- 是否成功提取表格
|
||||
- 是否页数统计可信
|
||||
- 是否疑似扫描件
|
||||
- 是否需要 OCR
|
||||
|
||||
这些字段会直接影响后续审核可信度。
|
||||
|
||||
#### 5.2.4 规则来源字段
|
||||
|
||||
建议增加：
|
||||
|
||||
- `source_role`
|
||||
区分“业务申报资料”与“法规依据资料”。
|
||||
|
||||
- `workflow_type`
|
||||
区分 `registration`、`change`、`renewal` 等流程类型。
|
||||
|
||||
- `format_template_type`
|
||||
标记该文件是否属于批准证明文件格式模板。
|
||||
|
||||
## 6. 关键业务流程需求
|
||||
|
||||
### 6.1 文件上传流程
|
||||
|
||||
用户上传文件后，系统应完成：
|
||||
|
||||
1. 基础校验：格式、大小、文件名合法性。
|
||||
2. 保存原始文件。
|
||||
3. 创建文档记录。
|
||||
4. 返回上传结果与下一步动作提示。
|
||||
|
||||
如果是批量导入，系统还应支持一次性上传多个资料。
|
||||
|
||||
如果上传的是压缩包，流程应扩展为：
|
||||
|
||||
1. 保存原始压缩包。
|
||||
2. 校验压缩包格式和大小。
|
||||
3. 解包到当前项目 / 批次的隔离目录。
|
||||
4. 遍历解包后的文件并创建文档记录。
|
||||
5. 保留每个文件的原始相对路径和所属压缩包来源。
|
||||
6. 对解包失败、空包、嵌套异常或不支持格式给出业务化提示。
|
||||
|
||||
### 6.2 文件识别与归类流程
|
||||
|
||||
上传后，系统应尽量自动识别文件属于哪个章节点。识别依据可以包括：
|
||||
|
||||
- 文件名中的章节点编码
|
||||
- 标题中的资料名称
|
||||
- 正文中出现的标准标题
|
||||
- 用户手工选择的类别
|
||||
|
||||
如果自动识别不确定，应标记为“待人工确认”，而不是强行归类。
|
||||
|
||||
对于法规资料，还应进一步识别其所属层级，例如：
|
||||
|
||||
1. 资料要求说明
|
||||
2. 格式要求说明
|
||||
3. 安全和性能基本原则
|
||||
4. 批准证明文件格式
|
||||
|
||||
### 6.3 页数统计流程
|
||||
|
||||
页数统计是本题显式要求，需支持：
|
||||
|
||||
- PDF 精确页数统计
|
||||
- DOCX 精确页数统计
|
||||
- DOC 文件页数统计或待人工复核策略
|
||||
- 目录页码与实际文件页数比对
|
||||
|
||||
DOCX 页数必须精确，不能以估算页数作为 V1 验收结果。DOC 如受格式限制无法精确统计，应标记为“待人工复核”。
|
||||
|
||||
页数结果建议拆分为：
|
||||
|
||||
- `page_count`
|
||||
- `page_count_method`
|
||||
- `page_count_confidence`
|
||||
|
||||
例如 PDF 和 DOCX 解析应标记为“精确”，DOC 或解析失败文件可标记为“待人工复核”。
|
||||
|
||||
### 6.4 文本抽取与索引流程
|
||||
|
||||
系统应按文档类型采用不同策略：
|
||||
|
||||
- PDF：优先文本解析，必要时 OCR 兜底
|
||||
- DOCX：提取段落和表格
|
||||
- DOC：首版可使用兼容方式提取正文，异常时提醒
|
||||
- MD/TXT：直接读取
|
||||
|
||||
抽取成功后，生成：
|
||||
|
||||
- 全文文本
|
||||
- 标题/章节结构
|
||||
- 表格结构
|
||||
- 可供索引的切片
|
||||
|
||||
### 6.5 目录汇总输出流程
|
||||
|
||||
Documents 模块应能直接输出一份“资料目录总览”，字段建议包括：
|
||||
|
||||
- 文件名
|
||||
- 资料名称
|
||||
- 章节点
|
||||
- 文件类型
|
||||
- 页数
|
||||
- 上传时间
|
||||
- 处理状态
|
||||
- 是否命中法规模板
|
||||
|
||||
这份目录总览既可作为页面列表，也可作为后续报告输入。
|
||||
|
||||
## 7. 与题面和样例资料的强关联需求
|
||||
|
||||
### 7.1 要能识别目录型文档
|
||||
|
||||
如 `CH1.2 监管信息目录.docx`，它本身不是普通资料正文，而是全章目录。系统需要把这类文件识别为“目录类文档”，并作为后续完整性比对的重要基准。
|
||||
|
||||
### 7.2 要能识别声明类文档
|
||||
|
||||
如：
|
||||
|
||||
- `CH1.11.1 符合标准的清单.docx`
|
||||
- `CH1.11.5 真实性声明.docx`
|
||||
- `CH1.11.6 符合性声明.docx`
|
||||
|
||||
这些文件看起来篇幅短，但在法规齐套性里往往是必需项，Documents 模块需要保留它们的业务属性，而不是简单按长度或内容量弱化其价值。
|
||||
|
||||
### 7.3 要能识别历史沟通说明类文档
|
||||
|
||||
`CH1.9 产品申报前沟通的说明.doc` 体现出历史申报背景和监管沟通信息，这类文件在合规审查中重要性很高，应单独分类标记。
|
||||
|
||||
### 7.4 要能区分业务资料与法规依据资料
|
||||
|
||||
结合新增公告材料，Documents 模块应把以下两类材料明确分开管理：
|
||||
|
||||
1. 待审核的业务申报资料
|
||||
2. 用于审核的法规依据与模板资料
|
||||
|
||||
否则后续在索引、引用和一致性检查时，容易把法规模板错误混入业务资料集合。
|
||||
|
||||
## 8. 列表页与上传页需求
|
||||
|
||||
### 8.1 文档列表页需求
|
||||
|
||||
文档列表页不应只是“文件上传记录”，而应成为资料治理面板。建议展示：
|
||||
|
||||
- 文件名
|
||||
- 原始相对路径
|
||||
- 章节点
|
||||
- 资料名称
|
||||
- 页数
|
||||
- 页数可信度
|
||||
- 所属项目 / 批次
|
||||
- 解析状态
|
||||
- 入库状态
|
||||
- 风险提示
|
||||
- 最后更新时间
|
||||
|
||||
### 8.2 上传页需求
|
||||
|
||||
上传页应支持：
|
||||
|
||||
- 选择所属项目或申报批次
|
||||
- 选择任务类型或章节点
|
||||
- 上传单文件或多文件
|
||||
- 上传后立即触发解析或稍后批量处理
|
||||
|
||||
如果首版只保留单文件上传，也应在需求中明确“后续需要支持批量导入资料包”。
|
||||
|
||||
## 9. 与其他模块的协作边界
|
||||
|
||||
### 9.1 与 Scenarios 模块
|
||||
|
||||
Scenarios 负责定义当前任务需要什么资料；Documents 负责把资料真正落地并结构化。
|
||||
|
||||
### 9.2 与 Agent Core 模块
|
||||
|
||||
Agent Core 负责对文档内容做审核与抽取；Documents 提供可靠的原始内容、切片和元数据。
|
||||
|
||||
### 9.3 与 Audit 模块
|
||||
|
||||
Documents 不负责审计结论，但应为审计提供文档 ID、处理过程和失败原因等基础事实。
|
||||
|
||||
## 10. 异常与边界情况
|
||||
|
||||
本模块必须考虑以下情况：
|
||||
|
||||
1. 文件存在但正文为空。
|
||||
2. 文件格式伪装，例如后缀为 `.docx` 但内容异常。
|
||||
3. Word / PDF 无法正常抽取文本。
|
||||
4. 文件内容与文件名章节点不一致。
|
||||
5. 同一资料重复上传多个版本。
|
||||
6. 同一批次中混入其他产品资料。
|
||||
|
||||
第 6 点尤其重要，因为当前样例材料已经体现出不同产品信息混杂的问题。
|
||||
|
||||
此外，还应避免把法规依据资料误当成业务申报资料写入同一业务索引集合。
|
||||
|
||||
## 11. 首版建议的可交付结果
|
||||
|
||||
首版建议 Documents 模块至少能产出三类结果：
|
||||
|
||||
1. 文档主数据列表
|
||||
2. 文档解析结果
|
||||
3. 目录汇总表
|
||||
|
||||
其中目录汇总表是本题最关键的页面成果之一，建议作为可单独展示的功能输出。
|
||||
|
||||
## 12. 当前代码基线下的重构建议
|
||||
|
||||
### 12.1 可以保留的部分
|
||||
|
||||
- 上传记录模型的基本思路
|
||||
- 文档列表与上传页的页面骨架
|
||||
- 入库和失败提示机制
|
||||
|
||||
### 12.2 需要增强的部分
|
||||
|
||||
1. 从“文档上传记录”升级为“注册资料记录”。
|
||||
2. 增加章节点、页数、资料名称、项目批次等字段。
|
||||
3. 增加表格抽取和目录类文件识别。
|
||||
4. 增加文档归类与页数统计能力。
|
||||
5. 增加重复版本识别和疑似混档识别。
|
||||
6. 增加法规资料类型识别与业务资料 / 法规资料隔离管理。
|
||||
7. 增加资料包导入、压缩包解包、原始相对路径记录和解包异常提示。
|
||||
|
||||
## 13. 验收标准
|
||||
|
||||
本模块验收时，应至少满足：
|
||||
|
||||
1. 能上传并管理题目中涉及的 Word、PDF、文本类资料。
|
||||
2. 能为每份资料建立结构化记录。
|
||||
3. 能输出文件目录与页数汇总结果。
|
||||
4. 能为后续完整性核查和一致性核查提供可靠输入。
|
||||
5. 出现解析失败时，页面有明确可理解的错误提示。
|
||||
1. 导入资料包后能形成批次记录。
|
||||
2. 能解析出产品名称并用于会话标题。
|
||||
3. 资料包页可按产品名称搜索。
|
||||
4. 资料包记录能跳转回对应对话。
|
||||
5. 文件清单、页数和章节点可用于后续审核任务消费。
|
||||
|
||||
@@ -2,307 +2,153 @@
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
`apps.chat` 在当前项目中是用户输入问题并查看 Agent 返回结果的页面。对于本题，它依然是核心交互入口，但定位需要从“自由问答页面”升级为：
|
||||
`apps.chat` 已从传统“问答页面”升级为：
|
||||
|
||||
> 注册申报审核工作台
|
||||
> 审核智能体工作台
|
||||
|
||||
也就是说，Chat 模块不只是让用户随便问一句话，而是要承接“选择任务、限定资料范围、发起审核、查看结构化结论、查看证据和建议”的完整操作流程。
|
||||
它是 V1 的主入口，负责把资料包、对话、任务模板、节点结果、结构化结论、飞书通知结果串成一个完整的人机协作界面。
|
||||
|
||||
## 2. 模块目标
|
||||
|
||||
本模块需要实现以下目标：
|
||||
|
||||
1. 为注册审核人员提供统一的任务执行入口。
|
||||
2. 让用户能明确知道自己当前在执行哪类审核任务。
|
||||
3. 让系统输出不仅有自然语言回答，还有结构化结论、引用证据、回填字段、风险建议。
|
||||
4. 保证结果可追溯、可解释、可复核，而不是只给一个“大模型说了什么”。
|
||||
5. 支持通过 Web 工作台与飞书入口两类方式访问智能体、触发审核和查看结果，并保证核心流程可在飞书内闭环完成。
|
||||
1. 让用户通过对话发起审核任务。
|
||||
2. 让对话始终绑定到具体资料包和具体产品名称。
|
||||
3. 让任务结果按节点展示，而不是只返回一段自然语言。
|
||||
4. 让用户能直接看到 RAG 命中的法规依据、风险摘要和导出建议。
|
||||
5. 支持执行完成或异常后触发飞书 `@` 处理人。
|
||||
|
||||
## 3. 为什么 Chat 模块仍然必要
|
||||
## 3. 页面形态要求
|
||||
|
||||
虽然本题也可以做成一组固定报表，但保留 Chat / 工作台交互有三个价值：
|
||||
基于最新版原型，Chat 模块页面形态固定为三栏：
|
||||
|
||||
1. 复试演示更直观，容易展示 Agent 的编排能力。
|
||||
2. 用户可以用自然语言提出临时核查要求，例如“只检查 CH1 监管信息”“比较说明书和申请表中的产品名称是否一致”。
|
||||
3. Chat 页面可以作为多个任务的统一结果承载层，而不需要为每个任务都单独写一套复杂页面。
|
||||
### 3.1 左栏：对话历史
|
||||
|
||||
## 4. 交互定位建议
|
||||
1. 按资料包会话展示历史记录。
|
||||
2. 会话名称直接使用解析后的产品名称。
|
||||
3. 会话至少显示时间、状态、摘要。
|
||||
4. 点击会话可切换当前资料包上下文。
|
||||
|
||||
### 4.1 不建议保持纯聊天式体验
|
||||
### 3.2 中栏：主对话区
|
||||
|
||||
如果只保留一个输入框，让用户手工描述所有操作，体验会过于依赖 prompt，不像一个业务系统。
|
||||
1. 展示欢迎区、推荐提示词和节点导航。
|
||||
2. 展示用户消息、Agent 计划、节点结果和最终结论。
|
||||
3. 支持节点点击跳转。
|
||||
4. 支持底部输入框继续追问。
|
||||
|
||||
建议采用“任务工作台 + 辅助对话”的模式，页面中同时提供：
|
||||
### 3.3 右栏：上传栏 + 功能卡片
|
||||
|
||||
- 当前任务名称
|
||||
- 输入问题框
|
||||
- 资料范围选择
|
||||
- 建议提问模板
|
||||
- 结构化结果区
|
||||
- 证据引用区
|
||||
- 风险列表区
|
||||
- 审计入口
|
||||
1. 上半区展示上传资料入口和当前会话已上传附件。
|
||||
2. 下半区展示能力卡片。
|
||||
3. 能力卡片随任务模板变化展示不同内容。
|
||||
|
||||
### 4.2 建议突出“任务上下文”
|
||||
## 4. 关键业务约束
|
||||
|
||||
用户进入页面后，应明确看到：
|
||||
### 4.1 对话必须绑定资料包
|
||||
|
||||
- 当前任务是什么
|
||||
- 当前使用了哪些资料
|
||||
- 当前是否启用了法规规则
|
||||
- 当前是否启用了字段池 / RAG / 工具
|
||||
用户不能在无上下文状态下执行审核。每次任务都应绑定：
|
||||
|
||||
这对复试讲解非常重要，因为它能体现系统是“受控执行”而不是“随便问模型”。
|
||||
1. `conversation_id`
|
||||
2. `batch_id`
|
||||
3. `product_name`
|
||||
4. `document_scope`
|
||||
|
||||
## 5. 典型使用场景
|
||||
### 4.2 对话名称必须来源于解析结果
|
||||
|
||||
### 5.1 发起完整性检查
|
||||
会话标题默认使用资料包解析出的产品名称，而不是“新对话”或“注册批次审核主线”。
|
||||
|
||||
用户输入类似：
|
||||
### 4.3 结果必须结构化
|
||||
|
||||
- “检查当前上传资料是否满足第 1 章监管信息要求”
|
||||
- “列出 CH1 缺失文件和风险等级”
|
||||
Chat 模块至少要展示：
|
||||
|
||||
系统返回：
|
||||
1. 目录汇总结果
|
||||
2. 完整性检查结果
|
||||
3. 字段抽取结果
|
||||
4. 一致性核查结果
|
||||
5. 风险结论
|
||||
6. 飞书通知结果
|
||||
|
||||
- 已识别文件数
|
||||
- 命中法规目录项
|
||||
- 缺失项清单
|
||||
- 错放项清单
|
||||
- 处理建议
|
||||
## 5. 输入需求
|
||||
|
||||
### 5.2 发起字段抽取
|
||||
### 5.1 输入类型
|
||||
|
||||
用户输入类似：
|
||||
1. 自然语言任务指令
|
||||
2. 资料上传
|
||||
3. 节点模板选择
|
||||
4. 建议提示词点击
|
||||
|
||||
- “从说明书和产品列表抽取产品名称、检测靶标、适用范围、储存条件、性能指标，并填入申报表或对照清单”
|
||||
### 5.2 建议提示词
|
||||
|
||||
系统返回：
|
||||
V1 推荐固定提供：
|
||||
|
||||
- 统一字段表
|
||||
- 字段来源文档
|
||||
- 置信度或待确认状态
|
||||
- 注册申报表格或对照清单的回填结果
|
||||
- 字段冲突时的拦截提示
|
||||
1. 自动汇总文件夹目录与页数
|
||||
2. 执行法规完整性检查
|
||||
3. 抽取字段并生成字段池
|
||||
4. 解释冲突字段原因
|
||||
5. 给出整改与导出建议
|
||||
|
||||
### 5.3 发起一致性核查
|
||||
### 5.3 附件上传
|
||||
|
||||
用户输入类似：
|
||||
Chat 模块中的上传不是独立附件功能，而是资料包流程的会话入口，因此上传后应自动触发：
|
||||
|
||||
- “检查申请表、说明书、产品列表里的产品名称和规格是否一致”
|
||||
1. 资料包批次创建或追加
|
||||
2. 产品名称解析
|
||||
3. 对话上下文绑定
|
||||
|
||||
系统返回：
|
||||
## 6. 输出需求
|
||||
|
||||
- 一致字段
|
||||
- 冲突字段
|
||||
- 冲突来源
|
||||
- 判定依据
|
||||
- 建议处理动作
|
||||
### 6.1 节点式结果
|
||||
|
||||
### 5.4 发起综合风险报告
|
||||
结果不能只有长文本，必须形成节点：
|
||||
|
||||
用户输入类似：
|
||||
1. 目录汇总
|
||||
2. 完整性检查
|
||||
3. 字段抽取
|
||||
4. 风险结论
|
||||
|
||||
- “生成本批申报资料的综合风险预警”
|
||||
### 6.2 RAG 依据展示
|
||||
|
||||
系统返回：
|
||||
当 Agent 在对话中引用法规或业务依据时，应展示：
|
||||
|
||||
- 风险摘要
|
||||
- 高优先级问题
|
||||
- 待补文件
|
||||
- 需人工确认事项
|
||||
- 建议整改顺序
|
||||
1. 依据来源文档
|
||||
2. 命中条款或切片标签
|
||||
3. 解释摘要
|
||||
|
||||
## 6. 输入层需求
|
||||
### 6.3 飞书通知结果展示
|
||||
|
||||
### 6.1 用户输入类型
|
||||
当执行完成或发生异常后，Chat 模块应能展示：
|
||||
|
||||
本模块应支持三类输入：
|
||||
1. 是否已触发飞书通知
|
||||
2. 通知原因
|
||||
3. 被 `@` 的处理人
|
||||
4. Web 详情链接
|
||||
5. 发送状态或失败原因
|
||||
|
||||
1. 自然语言问题
|
||||
2. 结构化参数选择
|
||||
3. 资料范围选择
|
||||
## 7. 飞书相关需求
|
||||
|
||||
### 6.2 结构化参数选择
|
||||
Chat 模块需要消费角色信息中的飞书字段。责任人实体至少包含：
|
||||
|
||||
建议用户在页面上可选：
|
||||
1. `owner_role`
|
||||
2. `owner_name`
|
||||
3. `feishu_user_id`
|
||||
4. `feishu_open_id`
|
||||
5. `feishu_name`
|
||||
6. `notify_enabled`
|
||||
|
||||
- 审核任务类型
|
||||
- 资料章节点范围
|
||||
- 指定文档范围
|
||||
- 输出模式
|
||||
当前 Demo 通知策略固定为：
|
||||
|
||||
输出模式可包括：
|
||||
1. 审核任务执行完成后，飞书摘要卡片 `@` 处理人。
|
||||
2. 审核任务执行异常后，飞书异常消息 `@` 处理人。
|
||||
|
||||
- 简洁结论
|
||||
- 结构化清单
|
||||
- 回填字段视图
|
||||
- 风险报告视图
|
||||
## 8. 与其他模块边界
|
||||
|
||||
### 6.3 建议提示词模板
|
||||
1. `documents` 提供资料包、产品名称、文件范围和目录事实。
|
||||
2. `agent_core` 提供任务编排、RAG 检索和结构化输出。
|
||||
3. `audit` 提供处理历史和通知留痕。
|
||||
|
||||
页面上可给出快捷操作示例，例如：
|
||||
## 9. 验收标准
|
||||
|
||||
- “汇总当前资料目录及页数”
|
||||
- “检查 CH1 监管信息是否齐套”
|
||||
- “抽取说明书中的核心产品信息并填入对照清单”
|
||||
- “检查说明书与申请表是否一致”
|
||||
|
||||
这样能降低演示时的自由输入风险。
|
||||
|
||||
### 6.4 飞书访问入口
|
||||
|
||||
飞书交互不应只是消息转发，而应支持在飞书内完成关键流程。交互设计上至少应纳入以下能力：
|
||||
|
||||
1. 通过飞书消息或群聊机器人入口触发某个审核任务。
|
||||
2. 在飞书内完成任务选择、结果查看和责任人通知。
|
||||
3. 支持手动维护后的责任人 / 飞书账号映射生效。
|
||||
|
||||
飞书开放平台接入路线中，群聊机器人属于 Demo 必备入口；文档评论区 `@bot` 或应用会话能力可作为后续扩展。
|
||||
|
||||
## 7. 输出层需求
|
||||
|
||||
### 7.1 自然语言结论
|
||||
|
||||
仍然需要保留总体回答，用于快速概括结果。
|
||||
|
||||
### 7.2 结构化结果
|
||||
|
||||
结构化结果是本题的重点，建议至少支持以下几类：
|
||||
|
||||
- 目录汇总结果
|
||||
- 完整性检查结果
|
||||
- 字段抽取结果
|
||||
- 一致性核查结果
|
||||
- 风险预警结果
|
||||
|
||||
### 7.3 引用证据
|
||||
|
||||
每个关键结论尽量附带来源，例如：
|
||||
|
||||
- 来源文档名
|
||||
- 来源章节
|
||||
- 引用片段
|
||||
- 引用页码或位置
|
||||
|
||||
对于法规完整性核查，还应尽量附带命中的法规条目或模板条目。
|
||||
|
||||
### 7.4 回填结果展示
|
||||
|
||||
对于“自动填写至目标文件”的题面要求，Chat 页面建议至少支持：
|
||||
|
||||
- 展示待回填字段
|
||||
- 展示字段值
|
||||
- 展示来源文档
|
||||
- 展示是否存在冲突
|
||||
- 展示已填入的注册申报表格或对照清单字段
|
||||
- 展示是否已生成新的 Word 文档
|
||||
- 展示导出入口
|
||||
|
||||
输出结果不仅要展示回填数据，还应明确展示“已自动填入注册申报表格 / 对照清单”“已按模板生成可直接报送版 Word”及其导出入口。
|
||||
|
||||
### 7.5 飞书端结果展示
|
||||
|
||||
飞书端至少应能展示：
|
||||
|
||||
- 当前任务名称
|
||||
- 结果摘要
|
||||
- 风险等级
|
||||
- 关键缺失项或冲突项
|
||||
- 责任人通知结果
|
||||
- Web 详情页或导出文件链接
|
||||
|
||||
### 7.6 风险提示
|
||||
|
||||
风险输出不应混在普通回答里，建议单独展示：
|
||||
|
||||
- 风险等级
|
||||
- 风险类型
|
||||
- 涉及文档
|
||||
- 问题描述
|
||||
- 建议动作
|
||||
- 是否需人工复核
|
||||
|
||||
## 8. 页面展示要求
|
||||
|
||||
### 8.1 结果要适合讲解
|
||||
|
||||
复试场景下，页面展示必须清楚，不适合只显示一个 JSON。建议将结果拆成几个清晰区块：
|
||||
|
||||
- 执行摘要
|
||||
- 结构化结果
|
||||
- 证据引用
|
||||
- 工具调用记录
|
||||
- 风险预警
|
||||
- 审计入口
|
||||
|
||||
### 8.2 异常提示要业务化
|
||||
|
||||
不能只提示“调用失败”。应该尽量说明：
|
||||
|
||||
- 当前无可用文档
|
||||
- 资料未完成入库
|
||||
- 未找到目标章节点资料
|
||||
- 字段抽取结果存在冲突，需人工确认
|
||||
- 法规规则未配置，无法执行完整性检查
|
||||
|
||||
### 8.3 支持“只看选中文档”
|
||||
|
||||
当前测试已覆盖按文档 ID 传递范围，这在本题里非常有用。因为注册审核人员往往只想检查某一章或某几个文件。
|
||||
|
||||
## 9. 结果可信度与人工复核
|
||||
|
||||
本题不应把系统塑造成“自动替代注册专员”的黑盒工具，因此 Chat 页面必须支持“需人工复核”的输出状态。
|
||||
|
||||
适合标记人工复核的情况包括：
|
||||
|
||||
1. 文档抽取失败或疑似扫描件。
|
||||
2. 字段在不同文档中出现冲突。
|
||||
3. 章节归类不确定。
|
||||
4. 规则无法直接判断是否缺失。
|
||||
5. 审核范围界定不清，无法确认哪些资料属于同一项目批次。
|
||||
|
||||
## 10. 与其他模块的边界
|
||||
|
||||
### 10.1 与 Scenarios 模块
|
||||
|
||||
Scenarios 定义任务入口，Chat 承担任务执行界面。
|
||||
|
||||
### 10.2 与 Documents 模块
|
||||
|
||||
Documents 提供资料和元数据，Chat 负责让用户选择资料并展示结果。
|
||||
|
||||
### 10.3 与 Agent Core 模块
|
||||
|
||||
Agent Core 生成审核结果，Chat 只负责参数组织和结果呈现，不负责规则实现。
|
||||
|
||||
### 10.4 与 Audit 模块
|
||||
|
||||
Chat 是大多数审计记录的触发入口，应把每次关键执行与审计日志关联起来。
|
||||
|
||||
## 11. 当前代码基线下的重构建议
|
||||
|
||||
### 11.1 建议保留
|
||||
|
||||
- 用户输入表单和提交流程
|
||||
- 结构化结果、引用片段、工具调用展示能力
|
||||
- 审计入口跳转
|
||||
- 选中文档范围传递机制
|
||||
|
||||
### 11.2 建议增强
|
||||
|
||||
1. 从“通用对话页”升级为“注册审核工作台”。
|
||||
2. 增加任务上下文展示和建议操作模板。
|
||||
3. 增加字段回填视图和风险清单视图。
|
||||
4. 增加资料范围、章节点范围选择。
|
||||
5. 增加人工复核标记的展示。
|
||||
|
||||
## 12. 验收标准
|
||||
|
||||
本模块验收时，应达到以下状态：
|
||||
|
||||
1. 用户能清楚知道当前执行的是哪项注册审核任务。
|
||||
2. 结果输出同时包含自然语言总结和结构化内容。
|
||||
3. 能查看引用证据、风险项和工具调用过程。
|
||||
4. 能基于选中文档或章节点做定向审核。
|
||||
5. 对失败、冲突和不确定情况给出清楚的人工复核提示。
|
||||
1. 用户能在一个会话中完成资料上传、任务发起和结果查看。
|
||||
2. 对话历史以产品名称展示，而不是泛化标题。
|
||||
3. 节点式结果、RAG 依据和飞书通知结果都能在页面上承载。
|
||||
4. 执行完成或异常的飞书通知逻辑有明确展示位和字段依赖。
|
||||
|
||||
@@ -2,261 +2,103 @@
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
`apps.audit` 在本题中绝不能只被理解为“对话历史”。对于注册申报资料准备与审核系统，它的定位应当是：
|
||||
`apps.audit` 在最新版产品形态中对应：
|
||||
|
||||
> 合规审查留痕与复核中心
|
||||
> 处理历史与审计留痕中心
|
||||
|
||||
因为本题输出的是“资料是否齐套、字段是否一致、哪里有合规风险”，这类结果天然需要留痕、可回溯、可解释。
|
||||
它不仅保存对话历史，还要保存资料包、节点执行、风险结论和飞书通知的完整链路。
|
||||
|
||||
## 2. 模块目标
|
||||
|
||||
本模块需要实现以下目标：
|
||||
1. 记录每次 Agent 审核任务。
|
||||
2. 记录资料包与会话绑定关系。
|
||||
3. 记录节点执行结果与最终风险状态。
|
||||
4. 记录飞书通知触发、接收人和回执。
|
||||
5. 支持处理历史页按批次回看任务。
|
||||
|
||||
1. 对每一次资料审核、字段抽取、完整性检查和风险预警形成可查询记录。
|
||||
2. 保留输入条件、处理范围、输出结果、证据来源和失败原因。
|
||||
3. 为演示“系统不是黑盒”提供直接支撑。
|
||||
4. 在不泄露敏感信息的前提下，支持问题追溯和结果复核。
|
||||
5. 为 Web 端与飞书端的多入口执行留存统一审计链路。
|
||||
## 3. 审计对象
|
||||
|
||||
## 3. 为什么本题对审计要求更高
|
||||
V1 至少需要覆盖：
|
||||
|
||||
在普通问答 Demo 中，审计模块往往只是锦上添花。但在本题里，审计本身就是业务可信度的一部分，原因包括：
|
||||
1. 资料包导入任务
|
||||
2. 目录汇总任务
|
||||
3. 完整性检查任务
|
||||
4. 字段抽取任务
|
||||
5. 一致性核查任务
|
||||
6. 风险预警任务
|
||||
7. 飞书通知任务
|
||||
|
||||
1. 注册申报属于强监管场景，任何自动结论都应能追溯。
|
||||
2. 题面明确要求输出风险预警和处理建议，这些建议后续可能影响资料补正方向。
|
||||
3. 当前样例中已经出现跨文档冲突、二次申报、历史临床资料替换等复杂情境，没有审计留痕会很难解释系统为何得出某个结论。
|
||||
## 4. 关键字段
|
||||
|
||||
## 4. 核心职责
|
||||
### 4.1 基础字段
|
||||
|
||||
### 4.1 执行留痕
|
||||
1. `audit_id`
|
||||
2. `batch_id`
|
||||
3. `conversation_id`
|
||||
4. `product_name`
|
||||
5. `task_type`
|
||||
6. `status`
|
||||
7. `created_at`
|
||||
|
||||
记录每次任务执行的基本信息：
|
||||
### 4.2 节点结果字段
|
||||
|
||||
- 执行时间
|
||||
- 操作人
|
||||
- 任务类型
|
||||
- 使用场景
|
||||
- 输入问题
|
||||
- 选中文档范围
|
||||
- 申报批次
|
||||
1. `node_name`
|
||||
2. `node_status`
|
||||
3. `node_summary`
|
||||
4. `source_report_ids`
|
||||
|
||||
### 4.2 处理结果留痕
|
||||
### 4.3 飞书留痕字段
|
||||
|
||||
记录：
|
||||
1. `trigger_source`
|
||||
2. `notify_reason`
|
||||
3. `owner_role`
|
||||
4. `feishu_user_id`
|
||||
5. `feishu_open_id`
|
||||
6. `feishu_name`
|
||||
7. `feishu_message_id`
|
||||
8. `message_status`
|
||||
9. `error_message`
|
||||
|
||||
- 最终自然语言回答
|
||||
- 结构化结果
|
||||
- 风险清单
|
||||
- 回填字段结果
|
||||
- 缺失文件清单
|
||||
## 5. 处理历史页要求
|
||||
|
||||
### 4.3 证据留痕
|
||||
处理历史页应展示：
|
||||
|
||||
记录：
|
||||
1. 批次号
|
||||
2. 产品名称
|
||||
3. 任务名称
|
||||
4. 时间
|
||||
5. 风险状态
|
||||
6. 资料规模
|
||||
7. 最终结果
|
||||
8. 节点链路
|
||||
|
||||
- 引用文档
|
||||
- 引用片段
|
||||
- 命中的法规条目或目录项
|
||||
- 使用的规则版本
|
||||
- 工具调用过程
|
||||
## 6. 飞书协同留痕要求
|
||||
|
||||
### 4.4 异常留痕
|
||||
在 V1 中，飞书通知有两个固定触发时机：
|
||||
|
||||
记录：
|
||||
1. 审核任务执行完成
|
||||
2. 审核任务执行异常
|
||||
|
||||
- 解析失败
|
||||
- 入库失败
|
||||
- 规则缺失
|
||||
- 模型调用失败
|
||||
- 输出冲突待人工确认
|
||||
两类通知都必须在审计中保留：
|
||||
|
||||
本题尤其需要保留失败和不确定状态，而不只是保存成功记录。
|
||||
1. 谁被 `@`
|
||||
2. 为什么被 `@`
|
||||
3. 发送是否成功
|
||||
4. 是否有 Web 详情页回链
|
||||
|
||||
## 5. 审计对象定义
|
||||
## 7. 与角色信息的关系
|
||||
|
||||
建议将审计对象扩展为以下几类：
|
||||
审计模块必须能记录责任人实体中的飞书字段，至少包括：
|
||||
|
||||
1. 资料目录汇总任务
|
||||
2. 完整性检查任务
|
||||
3. 字段抽取任务
|
||||
4. 一致性核查任务
|
||||
5. 风险预警任务
|
||||
6. 手工重试、重新入库、重新核查等操作
|
||||
1. `owner_role`
|
||||
2. `owner_name`
|
||||
3. `feishu_user_id`
|
||||
4. `feishu_open_id`
|
||||
5. `feishu_name`
|
||||
|
||||
这样可以避免审计模块只能记录“聊天问答”，却看不到文件处理和重跑过程。
|
||||
## 8. 验收标准
|
||||
|
||||
## 6. 审计记录字段需求
|
||||
|
||||
### 6.1 基础字段
|
||||
|
||||
- `audit_id`
|
||||
- `task_type`
|
||||
- `scenario_id`
|
||||
- `project_id`
|
||||
- `submission_batch_id`
|
||||
- `created_at`
|
||||
- `status`
|
||||
|
||||
### 6.2 输入字段
|
||||
|
||||
- 用户输入问题
|
||||
- 执行参数
|
||||
- 选中文档 ID 列表
|
||||
- 章节点范围
|
||||
- 规则版本
|
||||
- 模型名称
|
||||
- 触发入口类型（Web / 飞书群聊 / 飞书评论 / 飞书应用会话）
|
||||
- 飞书会话或消息标识
|
||||
|
||||
### 6.3 输出字段
|
||||
|
||||
- 最终摘要
|
||||
- 结构化输出 JSON
|
||||
- 风险等级
|
||||
- 是否通过
|
||||
- 是否存在人工复核项
|
||||
- 缺失项数量
|
||||
- 冲突项数量
|
||||
|
||||
### 6.4 证据字段
|
||||
|
||||
- 引用文档信息
|
||||
- 引用片段
|
||||
- 工具调用结果
|
||||
- 命中规则项
|
||||
- 风险评分明细
|
||||
|
||||
### 6.5 错误字段
|
||||
|
||||
- 错误类型
|
||||
- 错误信息
|
||||
- 失败阶段
|
||||
- 是否可重试
|
||||
|
||||
## 7. 与题面强相关的审计需求
|
||||
|
||||
### 7.1 对完整性检查结果留痕
|
||||
|
||||
当系统判断“缺少临床评估报告”或“缺少某项监管声明”时，应能回查：
|
||||
|
||||
- 是依据哪一版规则判断的
|
||||
- 当前已识别到哪些资料
|
||||
- 哪些资料被判定未命中
|
||||
|
||||
### 7.2 对一致性冲突留痕
|
||||
|
||||
当系统判定：
|
||||
|
||||
> 说明书与申请表中的产品名称不一致
|
||||
|
||||
则审计中必须保留：
|
||||
|
||||
- 冲突字段名
|
||||
- 冲突值
|
||||
- 对应来源文档
|
||||
- 判定时间
|
||||
- 所属审核范围
|
||||
|
||||
当前项目目标是通用试剂盒注册审核智能体，因此审计还必须能够说明“这些文档为什么会被纳入同一轮一致性核查”，否则冲突结论容易失真。
|
||||
|
||||
### 7.3 对历史申报说明的审计价值
|
||||
|
||||
`CH1.9` 涉及历史受理号、撤回、临床数据替换等事项，若系统在风险报告中引用这部分内容，应在审计中保留相关证据链，方便后续说明“为什么标记为历史事项风险”。
|
||||
|
||||
## 8. 页面需求
|
||||
|
||||
### 8.1 审计列表页
|
||||
|
||||
列表页不应仅展示“问了什么问题”，还应体现业务摘要。建议展示：
|
||||
|
||||
- 执行时间
|
||||
- 任务类型
|
||||
- 项目 / 批次
|
||||
- 状态
|
||||
- 风险等级
|
||||
- 缺失项数
|
||||
- 冲突项数
|
||||
- 是否需人工复核
|
||||
|
||||
### 8.2 审计详情页
|
||||
|
||||
详情页建议展示：
|
||||
|
||||
- 输入问题与参数
|
||||
- 结果摘要
|
||||
- 结构化结果
|
||||
- 引用证据
|
||||
- 工具调用
|
||||
- 原始输出
|
||||
- 错误信息
|
||||
- 脱敏后的上下文信息
|
||||
|
||||
## 9. 脱敏与安全要求
|
||||
|
||||
### 9.1 不能写入敏感密钥
|
||||
|
||||
这一点与 AGENTS 约定一致，日志中不能保存：
|
||||
|
||||
- API Key
|
||||
- 密钥类环境变量
|
||||
- 不必要的鉴权头
|
||||
|
||||
### 9.2 业务敏感信息控制
|
||||
|
||||
虽然当前题目材料以产品注册资料为主，但后续真实环境中可能包含：
|
||||
|
||||
- 企业联系人
|
||||
- 手机号 / 邮箱
|
||||
- 临床机构信息
|
||||
- 受理号
|
||||
|
||||
首版至少要具备“展示层脱敏”的设计意识。
|
||||
|
||||
### 9.3 原始输出保留边界
|
||||
|
||||
如果 LLM 原始输出中包含大量无效 prompt 内容或潜在敏感字段，应允许：
|
||||
|
||||
- 存摘要，不存完整原文
|
||||
- 或仅对管理员展示原始输出
|
||||
|
||||
## 10. 与其他模块的边界
|
||||
|
||||
### 10.1 与 Chat 模块
|
||||
|
||||
Chat 是主要触发入口；Audit 负责把执行结果沉淀为可追踪记录。
|
||||
|
||||
### 10.2 与 Documents 模块
|
||||
|
||||
Documents 提供文档处理事实；Audit 负责记录这些事实如何被某次审核任务引用。
|
||||
|
||||
### 10.3 与 Agent Core 模块
|
||||
|
||||
Agent Core 负责产出结论与证据；Audit 负责记录这些产出及其上下文。
|
||||
|
||||
## 11. 当前代码基线下的重构建议
|
||||
|
||||
### 11.1 建议保留
|
||||
|
||||
- 审计列表与详情页骨架
|
||||
- 原始输出展示能力
|
||||
- 敏感信息脱敏思路
|
||||
- 成功与失败均记录的机制
|
||||
|
||||
### 11.2 建议增强
|
||||
|
||||
1. 将“对话日志”扩展为“任务执行审计”。
|
||||
2. 增加项目批次、任务类型、章节点范围、规则版本等字段。
|
||||
3. 增加缺失项数、冲突项数、人工复核标记等业务指标。
|
||||
4. 增加法规命中项、字段来源和风险依据的留痕。
|
||||
5. 增加飞书触发来源、回传状态和责任人通知记录。
|
||||
|
||||
## 12. 验收标准
|
||||
|
||||
本模块验收时，应达到以下状态：
|
||||
|
||||
1. 每次关键审核任务都能形成完整审计记录。
|
||||
2. 审计详情足以解释“系统为什么得出这个结论”。
|
||||
3. 成功、失败和待人工复核都可记录。
|
||||
4. 页面层可快速筛选高风险或异常记录。
|
||||
5. 敏感密钥不会进入审计内容。
|
||||
6. 审计中能够明确体现“任一高风险即不通过”的最终判定依据。
|
||||
1. 处理历史页能回看历史审核任务。
|
||||
2. 能从历史中看出资料包、产品名称和对话的对应关系。
|
||||
3. 飞书通知的完成态和异常态都能留痕。
|
||||
4. 审计详情足以解释“为什么通知了这个处理人”。
|
||||
|
||||
@@ -2,550 +2,108 @@
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
`agent_core` 是整套系统的能力中枢。在本题中，它不应再被描述为“一个通用 Prompt + RAG + Tool 的抽象核心”，而应被明确定位为：
|
||||
`agent_core` 的定位更新为：
|
||||
|
||||
> 注册申报资料审核编排引擎
|
||||
> 资料包审核 Agent 编排引擎
|
||||
|
||||
它负责把法规规则、文档解析结果、字段抽取逻辑、一致性核查逻辑、风险输出模板和大模型能力组织成一个可执行的审核流程。
|
||||
它不再只服务固定报表页面，而是直接服务：
|
||||
|
||||
## 2. 模块总目标
|
||||
1. 对话任务编排
|
||||
2. 资料包上下文绑定
|
||||
3. RAG 法规与业务依据检索
|
||||
4. 节点式结构化输出
|
||||
5. 飞书通知触发载荷生成
|
||||
|
||||
本模块需要完成以下目标：
|
||||
## 2. 核心目标
|
||||
|
||||
1. 基于题面要求完成文件目录汇总、完整性核查、字段抽取、自动回填、一致性检查和风险预警。
|
||||
2. 形成规则优先、模型辅助的审核框架，而不是完全依赖自由生成。
|
||||
3. 提供结构化、可追溯、可测试的输出。
|
||||
4. 保持与 Django 页面层和数据层的边界清晰。
|
||||
1. 在会话上下文中执行目录汇总、完整性检查、字段抽取、一致性核查和风险预警。
|
||||
2. 使用规则优先、RAG 取证、LLM 辅助解释的工作模式。
|
||||
3. 输出适合对话节点展示的结构化结果。
|
||||
4. 在任务完成或异常时生成飞书通知载荷。
|
||||
|
||||
## 3. 为什么 Agent Core 是本题真正的“答题核心”
|
||||
## 3. 输入上下文要求
|
||||
|
||||
本题的难点不在“接个大模型接口”，而在于以下几点如何落到一个统一编排里：
|
||||
Agent Core 执行时必须显式接收：
|
||||
|
||||
1. 资料目录与法规目录如何比对。
|
||||
2. 产品说明书、申请表、产品列表、声明文件之间如何抽取统一字段。
|
||||
3. 不同字段的“一致”与“不一致”如何定义。
|
||||
4. 风险预警如何从规则结果和模型解释中生成。
|
||||
1. `conversation_id`
|
||||
2. `batch_id`
|
||||
3. `product_name`
|
||||
4. `document_scope`
|
||||
5. `task_template`
|
||||
6. `knowledge_scope`
|
||||
|
||||
这些都属于 `agent_core` 的职责范围。
|
||||
## 4. 编排能力拆分
|
||||
|
||||
## 4. 核心能力拆分
|
||||
### 4.1 对话入口编排
|
||||
|
||||
建议将 `agent_core` 的能力拆成以下几个子域理解。
|
||||
根据用户指令和模板，决定当前执行：
|
||||
|
||||
### 4.1 任务编排
|
||||
1. 目录汇总
|
||||
2. 完整性检查
|
||||
3. 字段抽取
|
||||
4. 一致性核查
|
||||
5. 风险结论
|
||||
|
||||
根据不同任务入口，组织不同处理链路。例如：
|
||||
### 4.2 RAG 检索能力
|
||||
|
||||
- 目录汇总链路
|
||||
- 完整性检查链路
|
||||
- 字段抽取链路
|
||||
- 一致性核查链路
|
||||
- 综合风险链路
|
||||
RAG 负责：
|
||||
|
||||
### 4.2 规则引擎
|
||||
1. 命中法规依据
|
||||
2. 命中业务依据
|
||||
3. 为对话解释提供证据
|
||||
|
||||
对以下事项优先使用规则处理：
|
||||
### 4.3 节点结果输出
|
||||
|
||||
- 章节点完整性
|
||||
- 必交文件判断
|
||||
- 文件归类
|
||||
- 固定字段抽取
|
||||
- 强一致字段比对
|
||||
每一步结果要输出为可对话展示的节点，而不是单纯 JSON。
|
||||
|
||||
### 4.3 LLM 辅助推理
|
||||
### 4.4 通知上下文生成
|
||||
|
||||
对以下事项由 LLM 作为辅助：
|
||||
在任务完成或异常时，生成：
|
||||
|
||||
- 长段文本中的字段归纳
|
||||
- 风险说明文案生成
|
||||
- 处理建议生成
|
||||
- 无法通过简单规则覆盖的异常解释
|
||||
1. 通知原因
|
||||
2. 责任角色
|
||||
3. 飞书目标账号
|
||||
4. 摘要内容
|
||||
5. Web 详情链接
|
||||
|
||||
### 4.4 RAG 检索
|
||||
## 5. 飞书相关需求
|
||||
|
||||
用于在文档较长、规则或用户问题较细时，从已入库资料中定位证据片段，为回答和审计提供支撑。
|
||||
Agent Core 需要消费角色信息中的飞书字段：
|
||||
|
||||
对本题而言，RAG 不仅要覆盖业务申报资料，也要覆盖公告附件包等法规原文资料。但它的职责应限定为：
|
||||
1. `owner_role`
|
||||
2. `owner_name`
|
||||
3. `feishu_user_id`
|
||||
4. `feishu_open_id`
|
||||
5. `feishu_name`
|
||||
6. `notify_enabled`
|
||||
|
||||
1. 为规则判断提供证据定位。
|
||||
2. 为结果解释提供法规引用。
|
||||
3. 为审计留痕提供可追溯片段。
|
||||
V1 固定通知策略：
|
||||
|
||||
不能把 RAG 检索命中的段落直接等同于最终合规判断。
|
||||
1. 执行完成后 `@` 处理人
|
||||
2. 执行异常后 `@` 处理人
|
||||
|
||||
### 4.5 结构化输出
|
||||
## 6. 结构化输出要求
|
||||
|
||||
将每类任务输出为明确 schema，而不是一段随意文本。
|
||||
除原有报告外，还应新增对话友好型输出对象：
|
||||
|
||||
## 5. 按题面要求拆解的能力需求
|
||||
1. `conversation_node_result`
|
||||
2. `rag_evidence_item`
|
||||
3. `owner_notification_payload`
|
||||
|
||||
## 5.1 文件目录汇总能力
|
||||
## 7. 与知识库的关系
|
||||
|
||||
### 目标
|
||||
知识库不只是配置后台，而是 Agent Core 的运行底座，至少包括：
|
||||
|
||||
自动汇总注册申报文件夹中的所有文件及页数。
|
||||
1. 法规资料切片
|
||||
2. 业务资料切片
|
||||
3. 字段 Schema
|
||||
4. 模板映射
|
||||
5. 责任人映射
|
||||
6. 飞书通知配置
|
||||
|
||||
### 需要的输入
|
||||
## 8. 验收标准
|
||||
|
||||
- Documents 模块提供的文档记录
|
||||
- 文件页数
|
||||
- 文档归类信息
|
||||
|
||||
### 处理逻辑
|
||||
|
||||
1. 接收 Documents 模块提供的资料包、批量文件或压缩包解包结果。
|
||||
2. 遍历当前项目 / 批次所有资料。
|
||||
3. 保留原始相对路径、文件名、文件类型、页数、页数可信度和处理状态。
|
||||
4. 将压缩包内多层目录按原目录作为章节点识别依据。
|
||||
5. 识别目录类文档与普通文档。
|
||||
6. 识别章节点、资料名称和是否命中法规目录项。
|
||||
7. 输出目录总表。
|
||||
|
||||
### 输出要求
|
||||
|
||||
结构化输出中至少包含：
|
||||
|
||||
- 文件清单
|
||||
- 文件数量
|
||||
- 总页数
|
||||
- 页数统计可信度
|
||||
- 已识别章节点
|
||||
- 待确认文档
|
||||
|
||||
DOCX 页数必须精确统计，不能以估算页数作为 V1 验收结果。DOC 如受格式限制无法精确统计，应标记为待人工复核。
|
||||
|
||||
## 5.2 法规完整性核查能力
|
||||
|
||||
### 目标
|
||||
|
||||
对照 NMPA 法规要求，检查所需资料是否齐全，并识别缺失项。
|
||||
|
||||
### 规则依据
|
||||
|
||||
当前材料已明确可用依据包括：
|
||||
|
||||
- `附件 4 体外诊断试剂注册申报资料要求及说明`
|
||||
- `CH1.2 监管信息目录`
|
||||
- 题面中提及的 NMPA / CMDE 法规来源
|
||||
- `关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告` 附件包
|
||||
|
||||
V1 默认以 `docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/` 下的公告附件包作为主规则源。NMPA / CMDE 官网链接用于说明法规来源和后续在线更新方向，不作为当前演示时的唯一实时依赖。
|
||||
|
||||
结合新增公告附件包，法规规则来源建议分层管理：
|
||||
|
||||
1. 注册申报资料要求及说明
|
||||
2. 医疗器械注册申报资料和批准证明文件格式要求（体外诊断试剂）
|
||||
3. 体外诊断试剂安全和性能基本原则清单
|
||||
4. 中华人民共和国医疗器械注册证（体外诊断试剂）格式
|
||||
5. 变更备案 / 变更注册申报资料要求及说明
|
||||
6. 延续注册申报资料要求及说明
|
||||
|
||||
### 处理逻辑
|
||||
|
||||
1. 装载法规目录模板。
|
||||
2. 装载当前资料实际清单。
|
||||
3. 以章节点和资料名称进行匹配。
|
||||
4. 区分：
|
||||
- 已提供
|
||||
- 缺失
|
||||
- 疑似已提供但命名不规范
|
||||
- 需人工判断
|
||||
5. 生成缺失项清单和建议动作。
|
||||
|
||||
### 关键难点
|
||||
|
||||
不是所有缺失都等价。需要区分：
|
||||
|
||||
- 监管强制项缺失
|
||||
- 目录中声明有但实际文件找不到
|
||||
- 文件存在但内容不符合该章节点用途
|
||||
|
||||
此外，还需要区分：
|
||||
|
||||
- 资料要求缺失
|
||||
- 文件格式要求不满足
|
||||
- 安全和性能基本原则映射不完整
|
||||
|
||||
### 输出要求
|
||||
|
||||
- 命中项列表
|
||||
- 缺失项列表
|
||||
- 风险等级
|
||||
- 建议补充动作
|
||||
- 规则依据
|
||||
|
||||
## 5.3 产品关键信息抽取能力
|
||||
|
||||
### 目标
|
||||
|
||||
从产品文件中提取关键信息，并自动填写到注册申报表格或对照清单中。
|
||||
|
||||
### 目标字段建议
|
||||
|
||||
至少包括题面点名字段：
|
||||
|
||||
- 产品名称
|
||||
- 检测靶标
|
||||
- 适用范围 / 预期用途
|
||||
- 储存条件
|
||||
- 性能指标
|
||||
|
||||
结合样例材料，建议进一步扩展：
|
||||
|
||||
- 包装规格
|
||||
- 适用样本类型
|
||||
- 适用仪器
|
||||
- 分类编码
|
||||
- 临床评价路径
|
||||
- 申请人名称
|
||||
- 生产地址
|
||||
- 标准清单
|
||||
- 申报日期
|
||||
|
||||
考虑到系统目标是“通用的试剂盒临床注册文件准备与审核智能体”，字段 schema 应优先沉淀通用注册字段，而不是只对某一具体产品定制。
|
||||
|
||||
### 字段来源优先级
|
||||
|
||||
需要明确来源优先级，例如：
|
||||
|
||||
1. 申请表
|
||||
2. 产品说明书
|
||||
3. 产品列表
|
||||
4. 声明类文件
|
||||
5. 其他说明材料
|
||||
|
||||
或根据字段类型分别设定优先级。
|
||||
|
||||
### 抽取逻辑
|
||||
|
||||
1. 规则抽取显式字段。
|
||||
2. 表格抽取规格、组分、标准清单等。
|
||||
3. 对长文本字段使用 LLM 归纳。
|
||||
4. 将结果写入统一字段池。
|
||||
5. 标记字段来源和置信状态。
|
||||
|
||||
### 输出要求
|
||||
|
||||
- 字段名
|
||||
- 字段值
|
||||
- 来源文档
|
||||
- 来源片段
|
||||
- 是否冲突
|
||||
- 是否已填入注册申报表格或对照清单
|
||||
|
||||
## 5.4 自动回填能力
|
||||
|
||||
### 目标
|
||||
|
||||
将抽取得到的产品名称、检测靶标、适用范围、储存条件、性能指标等核心信息填入注册申报表格或对照清单。
|
||||
|
||||
### 首版建议范围
|
||||
|
||||
首版即需要满足以下交付目标：
|
||||
|
||||
- 申请表字段回填数据集
|
||||
- 对照清单字段回填数据集
|
||||
- 页面可视化回填结果
|
||||
- 新的 Word 文档生成与导出能力
|
||||
- 基于模板库的高保真版式回填能力
|
||||
|
||||
当前已确认回填目标为注册申报表格或对照清单。V1 默认先把 `目标产品说明书` 中抽取的产品名称、检测靶标、适用范围、储存条件、性能指标等字段写入统一字段池，再按申请表 / 对照清单字段映射自动生成回填结果。若后续提供专用 Word 模板，则通过模板库字段映射生成具体 Word 文件。
|
||||
|
||||
### 处理逻辑
|
||||
|
||||
1. 根据目标模板定义字段映射。
|
||||
2. 从统一字段池读取值。
|
||||
3. 对冲突字段进行拦截或提示。
|
||||
4. 写入注册申报表格或对照清单的目标字段。
|
||||
5. 生成回填结果、导出文件和审计记录。
|
||||
|
||||
### 后续扩展
|
||||
|
||||
Word 输出必须满足以下要求：
|
||||
|
||||
1. 支持将用户新增模板纳入模板库。
|
||||
2. 回填时按模板字段映射写入指定模板。
|
||||
3. 输出文档的标题层级、表格、页眉页脚、盖章位和整体版式需达到可直接报送级别。
|
||||
|
||||
结合新增公告附件包中的批准证明文件格式材料，回填能力的后续扩展方向应进一步明确为：
|
||||
|
||||
1. 按注册证 / 批准证明文件格式模板生成字段映射。
|
||||
2. 按不同法规流程类型切换不同输出模板。
|
||||
|
||||
## 5.5 一致性核查能力
|
||||
|
||||
### 目标
|
||||
|
||||
核查不同文档间相同信息是否一致，检测章节结构和规范性问题。
|
||||
|
||||
### 强一致字段
|
||||
|
||||
建议首版按强一致处理的字段包括：
|
||||
|
||||
- 产品名称
|
||||
- 申请人名称
|
||||
- 规格型号 / 包装规格
|
||||
- 分类编码
|
||||
- 申报产品名称对应的章节点标题
|
||||
|
||||
结合最新确认，当前阶段不采用“语义一致即可通过”的宽松规则。对于被纳入同一审核范围的相同字段，默认按完全一致处理；如出现措辞差异，也应先判为冲突或待复核。
|
||||
|
||||
### 审核范围前置规则
|
||||
|
||||
一致性核查前必须先明确：
|
||||
|
||||
1. 哪些文档属于同一项目 / 批次 / 审核范围。
|
||||
2. 哪些文档只是通用样本材料，不能直接混入同一轮一致性比对。
|
||||
|
||||
因此，一致性核查链路应包含“审核范围确认”这一步，而不是直接对全部文档做全量比较。
|
||||
|
||||
### 结构核查
|
||||
|
||||
除字段一致性外，还应检查：
|
||||
|
||||
- 说明书是否包含关键章节
|
||||
- 目录页是否覆盖当前章节点
|
||||
- 文档标题是否规范
|
||||
- 是否存在不属于本产品的资料混入
|
||||
|
||||
### 典型异常示例
|
||||
|
||||
根据当前样例，系统应能识别：
|
||||
|
||||
- 若这些文档被划入同一审核范围，则“2019-nCoV”与“呼吸道合胞病毒、肺炎支原体”构成明确冲突。
|
||||
- 若这些文档本身被认定属于不同资料组，则系统应提示“存在跨产品样例混入，不应直接合并审核”。
|
||||
|
||||
### 输出要求
|
||||
|
||||
- 一致字段列表
|
||||
- 冲突字段列表
|
||||
- 冲突明细
|
||||
- 风险等级
|
||||
- 处理建议
|
||||
|
||||
## 5.6 合规风险预警能力
|
||||
|
||||
### 目标
|
||||
|
||||
把完整性检查、字段抽取和一致性核查的结果汇总成可执行的风险清单。
|
||||
|
||||
### 风险类型建议
|
||||
|
||||
- 缺失风险
|
||||
- 混档风险
|
||||
- 字段冲突风险
|
||||
- 章节不规范风险
|
||||
- 历史申报事项风险
|
||||
- 资料真实性 / 版本一致性风险
|
||||
- 法规适用情形错误风险
|
||||
|
||||
### 风险分级建议
|
||||
|
||||
首版可采用：
|
||||
|
||||
- 高风险
|
||||
- 中风险
|
||||
- 低风险
|
||||
|
||||
另行保留“待人工复核”状态，但它不是风险等级，而是处理状态。
|
||||
|
||||
### 风险准入规则
|
||||
|
||||
风险判定应采用综合分析机制，对至少以下维度分别评分：
|
||||
|
||||
1. 法规完整性
|
||||
2. 跨文档字段一致性
|
||||
3. 文档结构与章节规范性
|
||||
4. 历史事项与版本风险
|
||||
5. 法规流程适用性风险
|
||||
|
||||
综合规则如下：
|
||||
|
||||
1. 任一维度出现高风险项，则本次审核直接判定为不通过。
|
||||
2. 无高风险但存在多个中风险项时，应给出“待整改后复核”的建议。
|
||||
3. 低风险项可进入整改建议清单，但不单独阻断。
|
||||
|
||||
### 处理建议生成逻辑
|
||||
|
||||
规则部分负责给出基础动作，例如：
|
||||
|
||||
- “补充缺失文件”
|
||||
- “核对产品名称”
|
||||
- “重新确认临床资料版本”
|
||||
|
||||
LLM 负责把这些动作组织成自然语言建议，但不能改变底层规则结论。
|
||||
|
||||
## 6. 统一字段池设计需求
|
||||
|
||||
为支撑抽取、回填和一致性核查，建议在 `agent_core` 内形成统一字段池概念。
|
||||
|
||||
字段池至少记录：
|
||||
|
||||
- 字段名
|
||||
- 标准化字段值
|
||||
- 原始字段值
|
||||
- 来源文档
|
||||
- 来源位置
|
||||
- 置信度
|
||||
- 冲突状态
|
||||
- 最终推荐值
|
||||
|
||||
这是本题从“简单聊天 Demo”走向“资料审核系统”的关键能力之一。
|
||||
|
||||
## 7. 规则体系需求
|
||||
|
||||
### 7.1 完整性规则
|
||||
|
||||
用于判断：
|
||||
|
||||
- 某章节点是否必交
|
||||
- 当前资料是否命中
|
||||
- 缺失是否构成高风险
|
||||
|
||||
这里应进一步拆为三个子层：
|
||||
|
||||
1. 资料要求层完整性规则
|
||||
2. 结构目录层完整性规则
|
||||
3. 格式模板层完整性规则
|
||||
|
||||
同时，这三层规则都应能映射回“章 -> 条 -> 要求项 -> 模板字段”四级知识结构。
|
||||
|
||||
### 7.2 抽取规则
|
||||
|
||||
用于：
|
||||
|
||||
- 标题识别
|
||||
- 表格字段映射
|
||||
- 固定格式声明提取
|
||||
|
||||
对于法规资料本身，还应支持抽取：
|
||||
|
||||
- 附件编号
|
||||
- 法规流程类型
|
||||
- 适用范围说明
|
||||
- 批准证明文件格式字段
|
||||
|
||||
并为后台管理页面提供人工校订后的结构化回写入口。
|
||||
|
||||
### 7.3 一致性规则
|
||||
|
||||
用于定义：
|
||||
|
||||
- 哪些字段必须完全一致
|
||||
- 如何判断冲突严重度
|
||||
- 如何在执行前确认审核范围
|
||||
|
||||
### 7.4 风险映射规则
|
||||
|
||||
用于把缺失、冲突、不确定结果映射为风险级别、综合得分、是否通过和处理建议。
|
||||
|
||||
新增公告材料后，风险映射还应能够体现“适用情形错误”的风险，例如：
|
||||
|
||||
1. 把变更备案规则误用于首次注册申报
|
||||
2. 把延续注册格式误用于注册申报输出
|
||||
|
||||
同时，若系统生成 Word 输出失败、模板字段无法落位或导出格式破坏严重，也应形成独立的交付风险提示。
|
||||
|
||||
## 8. 工具体系需求
|
||||
|
||||
题面附加要求提到需要展示实际调用的关键工具/库。因此 `agent_core.tools` 中应逐步沉淀出与本题强相关的工具，而不是只保留通用样例工具。
|
||||
|
||||
建议工具方向包括：
|
||||
|
||||
1. 资料包扫描工具
|
||||
2. `zip` / `rar` / `7z` 压缩包解包工具，`rar` 和 `7z` 必须采用纯 Python 依赖实现
|
||||
3. 文档页数统计工具，DOCX 页数必须精确统计
|
||||
4. 章节点识别工具
|
||||
5. 必交项检查工具
|
||||
6. 字段抽取工具
|
||||
7. 字段一致性比对工具
|
||||
8. 文档结构规范检查工具
|
||||
9. 风险汇总工具
|
||||
10. 审核范围确认工具
|
||||
11. 法规流程识别工具
|
||||
12. 格式模板映射工具
|
||||
13. Word 模板回填与导出工具
|
||||
14. 飞书消息摘要生成与通知载荷组装工具
|
||||
15. 责任人映射解析工具，首版按资料章节手动配置
|
||||
16. 规则切片与结构化回写工具
|
||||
|
||||
这些工具都应通过 Tool Registry 注册，符合项目既有边界要求。
|
||||
|
||||
## 9. LLM Provider 需求
|
||||
|
||||
### 9.1 不允许业务代码散落模型调用
|
||||
|
||||
所有模型调用继续通过 Provider 统一处理。
|
||||
|
||||
### 9.2 模型在本题中的使用原则
|
||||
|
||||
本题应坚持：
|
||||
|
||||
1. 规则优先
|
||||
2. 证据优先
|
||||
3. 模型负责解释、补充和归纳
|
||||
4. 模型不应凭空判断法规完整性
|
||||
|
||||
### 9.3 测试要求
|
||||
|
||||
所有核心编排逻辑应继续支持 Mock Provider，以保证回归测试离线可跑。
|
||||
|
||||
## 10. 结构化输出 Schema 需求
|
||||
|
||||
建议至少定义以下输出类型：
|
||||
|
||||
1. `registration_overview_report`
|
||||
2. `registration_completeness_report`
|
||||
3. `registration_field_extraction_report`
|
||||
4. `registration_consistency_report`
|
||||
5. `registration_risk_report`
|
||||
|
||||
每种输出都应有稳定字段，便于页面展示与测试覆盖。
|
||||
|
||||
## 11. 与其他模块的边界
|
||||
|
||||
### 11.1 与 Documents 模块
|
||||
|
||||
Documents 负责提供资料事实；Agent Core 负责把这些事实转化为审核结论。
|
||||
|
||||
### 11.2 与 Chat 模块
|
||||
|
||||
Chat 负责接收用户意图和展示结果；Agent Core 负责执行任务链路。
|
||||
|
||||
### 11.3 与 Audit 模块
|
||||
|
||||
Audit 负责记录过程和结果；Agent Core 负责产出可记录的结构化执行信息。
|
||||
|
||||
## 12. 当前代码基线下的重构建议
|
||||
|
||||
### 12.1 建议保留
|
||||
|
||||
- Prompt 编排机制
|
||||
- 结构化结果对象
|
||||
- Tool Registry
|
||||
- RAG fallback / Chroma 双路径思路
|
||||
- Mock Provider 测试策略
|
||||
|
||||
### 12.2 建议增强
|
||||
|
||||
1. 从通用场景输出转向注册审核专用输出 schema。
|
||||
2. 增加法规完整性规则和目录模板匹配逻辑。
|
||||
3. 增加统一字段池。
|
||||
4. 增加一致性核查与风险汇总工具。
|
||||
5. 将“注册申报表格 / 对照清单回填结果”纳入正式输出结构。
|
||||
6. 增加“是否通过”和“风险评分明细”输出字段。
|
||||
7. 增加法规分层规则管理，以及注册申报 / 变更 / 延续三类流程的扩展边界。
|
||||
8. 增加模板库驱动的高保真 Word 生成链路。
|
||||
9. 增加后端管理入口所需的规则回写、人工校订和责任人映射能力。
|
||||
|
||||
## 13. 验收标准
|
||||
|
||||
本模块完成后，应至少满足：
|
||||
|
||||
1. 能支持目录汇总、完整性检查、字段抽取、一致性核查、风险预警五类核心任务。
|
||||
2. 核心结论有结构化输出，不依赖随意文本。
|
||||
3. 规则和模型分工清晰，法规判断不完全依赖大模型生成。
|
||||
4. 输出能关联到具体文档和证据片段。
|
||||
5. 测试环境下可以通过 Mock Provider 验证主要编排逻辑。
|
||||
6. 法规原文可切片入 RAG，但最终完整性与准入判断仍由规则链路主导。
|
||||
7. Word 输出结果能够基于模板库生成可直接报送级版式文档。
|
||||
1. Agent Core 能在会话上下文中完成完整审核链路。
|
||||
2. 能输出对话节点结果和 RAG 依据。
|
||||
3. 能生成执行完成/异常两类飞书通知上下文。
|
||||
4. 能基于责任人飞书字段构建 `@` 处理人载荷。
|
||||
|
||||
Reference in New Issue
Block a user