334 lines
13 KiB
Markdown
334 lines
13 KiB
Markdown
# 架构搭建思路汇报稿（基于 Demo 版）
|
||
|
||
## 一、汇报开场
|
||
|
||
各位老师好，我本次 Demo 搭建的是一个面向体外诊断试剂注册资料准备与审核的智能体原型。
|
||
|
||
这个 Demo 的目标不是简单做文件上传、文件解析或问答，而是把注册资料审核中几个高频、耗时、容易出错的环节串成一个可追溯的智能工作流，包括文件目录汇总、法规完整性核查、产品关键信息提取、申报表自动填充，以及异常风险预警。
|
||
|
||
从整体定位上看，它更像是一个“注册资料审核助手”：用户上传一批申报资料后，系统能够先把资料包结构化，再对照法规规则做核查，之后输出风险清单和整改建议，并把抽取到的产品信息继续复用到申报模板填表中。
|
||
|
||
## 二、Demo 运行结果展示
|
||
|
||
本次 Demo 目前可以展示四类核心运行结果。
|
||
|
||
### 1. 文件目录汇总表
|
||
|
||
用户上传注册资料文件夹、散装文件或压缩包后，系统会自动完成附件固化、压缩包解压、文件扫描和页数统计。
|
||
|
||
最终系统会生成 Markdown 汇总报告和 Excel 文件明细表，主要字段包括：
|
||
|
||
| 字段 | 说明 |
|
||
| --- | --- |
|
||
| 序号 | 文件在批次中的顺序 |
|
||
| 目录层级 | 文件所在的相对目录 |
|
||
| 文件名 | 原始文件名 |
|
||
| 类型 | PDF、Word、Excel、PPT 等文件类型 |
|
||
| 页数 | PDF 页数、Word 页数、PPT 幻灯片数或 Excel 工作表数 |
|
||
| 路径 | 文件在批次工作目录中的相对路径 |
|
||
| 状态 | success、failed、unsupported、uncertain 等 |
|
||
| 重试次数 | 页数统计失败时的重试记录 |
|
||
| 异常说明 | 不支持、不可确定或解析失败的原因 |
|
||
|
||
这个结果解决的是资料包进入系统后的第一步问题：先把杂乱的文件夹变成结构化的文件清单。
|
||
|
||
### 2. 法规完整性报告
|
||
|
||
在文件汇总结果基础上，系统会调用法规核查工作流，对照 NMPA 体外诊断试剂注册申报资料要求进行完整性检查。
|
||
|
||
Demo 中使用 `review_agent/regulatory_review/rules/nmpa_ivd_registration_v1.yaml` 作为结构化规则文件。规则文件中配置了附件 4 的资料要求，例如监管信息、综述资料、非临床资料、临床评价资料、说明书和标签样稿、质量管理体系文件等。
|
||
|
||
系统会检查是否缺少关键资料，例如：
|
||
|
||
| 检查对象 | 风险示例 |
|
||
| --- | --- |
|
||
| 注册申请表 | 缺失时生成阻断项或高风险 |
|
||
| 符合性声明 | 缺失时生成阻断项 |
|
||
| 产品技术要求 | 缺失时生成阻断项 |
|
||
| 注册检验报告 | 缺失时生成阻断项 |
|
||
| 产品说明书 | 缺失或章节不完整时生成高风险 |
|
||
| 标签样稿 | 缺失时生成高风险 |
|
||
| 临床评价资料 | 按适用条件生成条件性风险 |
|
||
| 质量管理体系文件 | 缺失时生成高风险 |
|
||
|
||
最终输出包括 Markdown 法规核查报告、Excel 问题清单和 JSON 结构化结果包。
|
||
|
||
### 3. 信息提取对照表
|
||
|
||
系统会从说明书、产品技术要求、注册检验报告、申请表等文件中抽取产品关键信息。
|
||
|
||
当前 Demo 中重点抽取的字段包括：
|
||
|
||
| 字段 | 用途 |
|
||
| --- | --- |
|
||
| 产品名称 | 用于一致性核查和申报表填充 |
|
||
| 型号规格 | 用于跨文件比对 |
|
||
| 预期用途 | 用于法规适用条件和模板填充 |
|
||
| 管理类别 | 用于法规判断 |
|
||
| 分类编码 | 用于注册资料核对 |
|
||
| 注册类型 | 用于模板选择和法规规则裁剪 |
|
||
| 临床评价路径 | 用于临床资料适用性判断 |
|
||
|
||
每个抽取结果都会保留来源文件、来源角色、证据片段、抽取方式和置信度。这样后续生成的填表内容不是黑盒结果，而是能够回溯到原始文件。
|
||
|
||
### 4. 异常预警列表
|
||
|
||
系统会把完整性缺失、章节异常、字段冲突、文本抽取失败、页数不可确定、通知失败等问题统一沉淀为风险项。
|
||
|
||
风险等级目前分为：
|
||
|
||
| 风险等级 | 含义 |
|
||
| --- | --- |
|
||
| 阻断项 | 影响注册资料完整性或关键合规判断，需要优先整改 |
|
||
| 高风险 | 可能影响审评，需要重点关注 |
|
||
| 中风险 | 建议整改或补充说明 |
|
||
| 低风险 | 轻微问题或格式提示 |
|
||
| 提示项 | 不直接影响结论，但建议人工确认 |
|
||
|
||
例如，如果系统发现不同文件中的“产品名称”或“型号规格”不一致，会生成一致性风险；如果缺少注册检验报告，会生成阻断项，并给出补充注册检验报告的整改建议。
|
||
|
||
## 三、智能体整体工作流
|
||
|
||
结合当前 Demo 的实现，智能体整体工作流可以概括为：
|
||
|
||
```text
|
||
文件扫描
|
||
-> 目录汇总
|
||
-> 法规匹配
|
||
-> 信息提取
|
||
-> 一致性核查
|
||
-> 风险预警
|
||
-> 报告导出
|
||
-> 通知与整改复核
|
||
```
|
||
|
||
从代码实现上看，系统拆成三条主链路。
|
||
|
||
### 1. 文件汇总链路
|
||
|
||
对应模块：`review_agent/file_summary`
|
||
|
||
主要流程为：
|
||
|
||
```text
|
||
文件上传
|
||
-> 附件固化
|
||
-> 压缩包解压
|
||
-> 文件扫描
|
||
-> 页数统计
|
||
-> 产品名识别
|
||
-> 报告输出
|
||
```
|
||
|
||
这个链路的核心作用是把原始资料包转换成结构化数据。系统会生成 `FileSummaryBatch` 和 `FileSummaryItem`，后续法规核查和自动填表都复用这套文件清单，不再重复扫描文件。
|
||
|
||
### 2. 法规核查链路
|
||
|
||
对应模块：`review_agent/regulatory_review`
|
||
|
||
主要流程为：
|
||
|
||
```text
|
||
准备资料
|
||
-> 适用条件确认
|
||
-> 规则范围裁剪
|
||
-> 完整性核查
|
||
-> 文本抽取
|
||
-> 章节核查
|
||
-> 一致性核查
|
||
-> 风险评估
|
||
-> 报告输出
|
||
```
|
||
|
||
这条链路的核心设计原则是：规则优先，RAG 补依据，LLM 做辅助。
|
||
|
||
也就是说，法规结论不直接交给大模型自由判断，而是优先由结构化规则文件决定；RAG 负责检索法规依据和原文片段；LLM 主要用于低置信度字段抽取、自然语言条件解析和结果复核。
|
||
|
||
### 3. 自动填表链路
|
||
|
||
对应模块：`review_agent/application_form_fill`
|
||
|
||
主要流程为：
|
||
|
||
```text
|
||
准备资料
|
||
-> 模板选择
|
||
-> 模板复制
|
||
-> 字段抽取
|
||
-> 冲突归并
|
||
-> Word 填写
|
||
-> 追溯清单导出
|
||
-> 结果通知
|
||
```
|
||
|
||
这条链路会复用前面抽取到的产品信息，自动选择申报模板，并将字段填入 Word 模板。对于冲突字段，Demo 中采用“说明书优先”的策略，同时在结果中保留冲突摘要和来源追溯。
|
||
|
||
## 四、Demo 实际调用的关键工具和库
|
||
|
||
本 Demo 在工具选型上以轻量、可本地运行、可解释、便于测试为原则。
|
||
|
||
### 1. 文件解析类工具
|
||
|
||
| 工具/库 | Demo 中的用途 | 选用理由 |
|
||
| --- | --- | --- |
|
||
| `pypdf` | PDF 页数统计和文本抽取 | 轻量、安装简单，适合 Demo 阶段快速处理 PDF |
|
||
| `python-docx` | DOCX 文本读取、Word 模板填充 | 可读取段落和表格，也能写入 Word 模板 |
|
||
| `python-pptx` | PPTX 幻灯片数量统计和文本读取 | 适合统计幻灯片数量和抽取文本 |
|
||
| `openpyxl` | XLSX 工作表统计、Excel 报告导出 | 同时支持读取和生成 Excel |
|
||
| `xlrd` | 旧版 XLS 文件读取 | 补充对历史 Excel 格式的支持 |
|
||
| `olefile` | 判断老 Office 文件 OLE 结构 | 用于 doc、xls、ppt 等老格式的兜底识别 |
|
||
| `py7zr` | 7z 压缩包解压 | 支持常见资料包压缩格式 |
|
||
| Python `zipfile` | ZIP 压缩包解压 | 标准库能力，无额外依赖 |
|
||
|
||
Demo 中没有选择重型 OCR 或复杂版式引擎，是因为当前阶段重点是打通审核链路和规则闭环。对于扫描件、图片 PDF、复杂版式 PDF，后续可以再接入 OCR 和更强的版式解析能力。
|
||
|
||
### 2. 规则和正则
|
||
|
||
系统使用 YAML 维护法规规则，例如 `nmpa_ivd_registration_v1.yaml`。每条规则包含规则编码、附件 4 编码、标题、资料类型、风险等级、匹配关键词、整改建议和 RAG 检索查询词。
|
||
|
||
正则表达式用于抽取结构化字段，例如：
|
||
|
||
```text
|
||
产品名称：xxx
|
||
型号规格：xxx
|
||
预期用途：xxx
|
||
管理类别：xxx
|
||
分类编码：xxx
|
||
```
|
||
|
||
选用规则和正则的原因是：这类注册资料中有大量固定标题和固定字段，使用确定性规则可以提高可解释性，也便于定位问题来源。
|
||
|
||
### 3. RAG 和向量检索
|
||
|
||
Demo 使用 ChromaDB 构建本地法规 RAG 索引。法规原文材料会被切分为文本块，并保存来源文件、chunk 编号等元数据。
|
||
|
||
向量 embedding 支持两种模式：
|
||
|
||
| 模式 | 用途 |
|
||
| --- | --- |
|
||
| SiliconFlow embedding | 用于真实语义检索 |
|
||
| deterministic/local embedding | 用于测试和 dry run |
|
||
|
||
RAG 在系统中的定位不是直接判断合规，而是为风险问题补充法规依据。例如完整性规则已经判断“缺少注册检验报告”，RAG 再检索相关法规条款，输出来源文件和依据片段，增强报告的可解释性。
|
||
|
||
### 4. LLM 调用
|
||
|
||
LLM 在 Demo 中主要承担辅助角色，包括：
|
||
|
||
| 场景 | LLM 作用 |
|
||
| --- | --- |
|
||
| 自然语言适用条件解析 | 将用户输入转换为结构化字段 |
|
||
| 低置信度字段抽取 | 正则抽取不足时补充结构化 JSON |
|
||
| 工作流结果复核 | 对中间结果做总结和校验 |
|
||
| 整改建议润色 | 在规则模板基础上优化表达 |
|
||
|
||
风险等级、法规结论和完整性判断不直接交给 LLM 决定，而是由规则引擎和风险评估服务控制。
|
||
|
||
### 5. 工作流和状态管理
|
||
|
||
系统使用 Django ORM 保存批次、节点、事件和导出文件。
|
||
|
||
关键模型包括：
|
||
|
||
| 模型 | 作用 |
|
||
| --- | --- |
|
||
| `FileSummaryBatch` | 文件汇总批次 |
|
||
| `FileSummaryItem` | 文件明细 |
|
||
| `RegulatoryReviewBatch` | 法规核查批次 |
|
||
| `RegulatoryIssue` | 法规问题和风险项 |
|
||
| `RegulatoryArtifact` | 法规核查过程产物 |
|
||
| `ApplicationFormFillBatch` | 自动填表批次 |
|
||
| `WorkflowNodeRun` | 工作流节点状态 |
|
||
| `WorkflowEvent` | SSE 事件和进度记录 |
|
||
| `ExportedSummaryFile` | Markdown、Excel、JSON、Word 等导出文件 |
|
||
|
||
前端通过 SSE 事件实时展示工作流卡片状态，使用户能够看到每个节点是否正在执行、是否成功、是否等待确认或失败。
|
||
|
||
## 五、难点规则处理方式
|
||
|
||
### 1. 文件完整性检测
|
||
|
||
文件完整性检测的难点在于：注册资料不是固定文件名，企业可能用不同命名方式组织材料。
|
||
|
||
Demo 的处理方式是使用多层匹配：
|
||
|
||
```text
|
||
规则要求项
|
||
-> 文件名关键词匹配
|
||
-> 相对路径匹配
|
||
-> 目录层级匹配
|
||
-> 必要时结合首页文本和字段候选
|
||
```
|
||
|
||
例如规则中要求“注册检验报告”，系统不仅查找文件名中是否包含“注册检验报告”，也会查找路径和目录中是否包含“检验报告”“检测报告”等别名。
|
||
|
||
如果没有匹配到文件，系统会生成 `Finding`，再由风险评估服务转换为 `RegulatoryIssue`。这样完整性问题既能被结构化记录，也能进入最终风险报告。
|
||
|
||
### 2. 信息一致性核查
|
||
|
||
一致性核查的难点在于：同一个字段可能散落在说明书、注册检验报告、产品技术要求、申请表等多个文件中。
|
||
|
||
Demo 的处理方式是：
|
||
|
||
```text
|
||
文本抽取
|
||
-> 字段正则识别
|
||
-> 同字段归并
|
||
-> 不同取值比对
|
||
-> 生成一致性风险
|
||
```
|
||
|
||
例如系统会从多个文件中抽取“产品名称”“型号规格”“预期用途”等字段。如果同一字段出现多个不同值，系统会生成高风险问题，并在证据中记录每个取值对应的来源文件。
|
||
|
||
这类结果可以直接辅助人工审核人员定位冲突来源。
|
||
|
||
### 3. 法规条款匹配
|
||
|
||
法规条款匹配的难点在于：法规原文长、条款多，直接让大模型判断容易不稳定，纯规则又缺少解释能力。
|
||
|
||
Demo 采用“双层法规能力”：
|
||
|
||
| 层级 | 职责 |
|
||
| --- | --- |
|
||
| 结构化规则库 | 负责判断应有哪些文件、哪些章节、哪些字段，以及风险等级 |
|
||
| RAG 法规依据索引 | 负责检索法规原文片段，补充依据说明 |
|
||
|
||
这种设计的好处是：判断逻辑稳定，报告解释充分，后续规则也可以由法规人员维护。
|
||
|
||
### 4. 过程留痕和可追溯
|
||
|
||
审核类系统不能只输出一个结论，还必须说明结论从哪里来。
|
||
|
||
Demo 中对关键过程都做了留痕：
|
||
|
||
| 过程 | 留痕内容 |
|
||
| --- | --- |
|
||
| 文件汇总 | 文件路径、页数、统计状态、异常说明 |
|
||
| 文本抽取 | 文本 hash、首页文本、章节候选、字段候选 |
|
||
| 完整性核查 | 规则编码、匹配关键词、命中文件或缺失证据 |
|
||
| 一致性核查 | 字段值、来源文件、冲突取值 |
|
||
| RAG 检索 | 法规来源、片段文本、检索分数 |
|
||
| 报告导出 | Markdown、Excel、JSON 结果包 |
|
||
| 自动填表 | 字段来源、冲突摘要、追溯清单 |
|
||
|
||
这保证了 Demo 输出的结果不是一次性回答，而是可以复核、下载、整改和继续追踪的过程资产。
|
||
|
||
## 六、总结
|
||
|
||
整体来看，本 Demo 的架构搭建思路可以概括为：
|
||
|
||
```text
|
||
先结构化资料
|
||
再匹配法规
|
||
再抽取字段
|
||
再核查一致性
|
||
再输出风险和报告
|
||
最后支持填表和整改闭环
|
||
```
|
||
|
||
它体现的是一个“资料输入、规则判断、证据追溯、风险输出、整改闭环”的智能体原型。
|
||
|
||
当前 Demo 已经完成了文件汇总、法规完整性核查、信息抽取、风险预警、报告导出和自动填表主链路。后续如果继续增强，可以重点补充 OCR、扫描件识别、复杂 PDF 版式解析、规则后台维护、人工确认界面、飞书真实消息闭环，以及更完整的多智能体编排能力。
|
||
|
||
最终希望这个智能体能够从一个 Demo 原型，逐步演进为注册资料准备和审核过程中的智能协作平台。
|