docs: 重构真实题目下的需求与资料文档体系
This commit is contained in:
443
docs/需求分析/6.agent_core模块需求分析.md
Normal file
443
docs/需求分析/6.agent_core模块需求分析.md
Normal file
@@ -0,0 +1,443 @@
|
||||
# Agent Core 模块需求分析
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
`agent_core` 是整套系统的能力中枢。在本题中，它不应再被描述为“一个通用 Prompt + RAG + Tool 的抽象核心”，而应被明确定位为：
|
||||
|
||||
> 注册申报资料审核编排引擎
|
||||
|
||||
它负责把法规规则、文档解析结果、字段抽取逻辑、一致性核查逻辑、风险输出模板和大模型能力组织成一个可执行的审核流程。
|
||||
|
||||
## 2. 模块总目标
|
||||
|
||||
本模块需要完成以下目标：
|
||||
|
||||
1. 基于题面要求完成文件目录汇总、完整性核查、字段抽取、回填准备、一致性检查和风险预警。
|
||||
2. 形成规则优先、模型辅助的审核框架，而不是完全依赖自由生成。
|
||||
3. 提供结构化、可追溯、可测试的输出。
|
||||
4. 保持与 Django 页面层和数据层的边界清晰。
|
||||
|
||||
## 3. 为什么 Agent Core 是本题真正的“答题核心”
|
||||
|
||||
本题的难点不在“接个大模型接口”，而在于以下几点如何落到一个统一编排里：
|
||||
|
||||
1. 资料目录与法规目录如何比对。
|
||||
2. 产品说明书、申请表、产品列表、声明文件之间如何抽取统一字段。
|
||||
3. 不同字段的“一致”与“不一致”如何定义。
|
||||
4. 风险预警如何从规则结果和模型解释中生成。
|
||||
|
||||
这些都属于 `agent_core` 的职责范围。
|
||||
|
||||
## 4. 核心能力拆分
|
||||
|
||||
建议将 `agent_core` 的能力拆成以下几个子域理解。
|
||||
|
||||
### 4.1 任务编排
|
||||
|
||||
根据不同任务入口，组织不同处理链路。例如：
|
||||
|
||||
- 目录汇总链路
|
||||
- 完整性检查链路
|
||||
- 字段抽取链路
|
||||
- 一致性核查链路
|
||||
- 综合风险链路
|
||||
|
||||
### 4.2 规则引擎
|
||||
|
||||
对以下事项优先使用规则处理：
|
||||
|
||||
- 章节点完整性
|
||||
- 必交文件判断
|
||||
- 文件归类
|
||||
- 固定字段抽取
|
||||
- 强一致字段比对
|
||||
|
||||
### 4.3 LLM 辅助推理
|
||||
|
||||
对以下事项由 LLM 作为辅助：
|
||||
|
||||
- 长段文本中的字段归纳
|
||||
- 语义等价判断
|
||||
- 风险说明文案生成
|
||||
- 处理建议生成
|
||||
- 无法通过简单规则覆盖的异常解释
|
||||
|
||||
### 4.4 RAG 检索
|
||||
|
||||
用于在文档较长、规则或用户问题较细时，从已入库资料中定位证据片段，为回答和审计提供支撑。
|
||||
|
||||
### 4.5 结构化输出
|
||||
|
||||
将每类任务输出为明确 schema，而不是一段随意文本。
|
||||
|
||||
## 5. 按题面要求拆解的能力需求
|
||||
|
||||
## 5.1 文件目录汇总能力
|
||||
|
||||
### 目标
|
||||
|
||||
自动汇总注册申报文件夹中的所有文件及页数。
|
||||
|
||||
### 需要的输入
|
||||
|
||||
- Documents 模块提供的文档记录
|
||||
- 文件页数
|
||||
- 文档归类信息
|
||||
|
||||
### 处理逻辑
|
||||
|
||||
1. 遍历当前项目 / 批次所有资料。
|
||||
2. 汇总文件名、章节点、页数、状态。
|
||||
3. 识别目录类文档与普通文档。
|
||||
4. 输出目录总表。
|
||||
|
||||
### 输出要求
|
||||
|
||||
结构化输出中至少包含：
|
||||
|
||||
- 文件清单
|
||||
- 文件数量
|
||||
- 总页数
|
||||
- 已识别章节点
|
||||
- 待确认文档
|
||||
|
||||
## 5.2 法规完整性核查能力
|
||||
|
||||
### 目标
|
||||
|
||||
对照 NMPA 法规要求，检查所需资料是否齐全，并识别缺失项。
|
||||
|
||||
### 规则依据
|
||||
|
||||
当前材料已明确可用依据包括：
|
||||
|
||||
- `附件 4 体外诊断试剂注册申报资料要求及说明`
|
||||
- `CH1.2 监管信息目录`
|
||||
- 题面中提及的 NMPA / CMDE 法规来源
|
||||
|
||||
### 处理逻辑
|
||||
|
||||
1. 装载法规目录模板。
|
||||
2. 装载当前资料实际清单。
|
||||
3. 以章节点和资料名称进行匹配。
|
||||
4. 区分：
|
||||
- 已提供
|
||||
- 缺失
|
||||
- 疑似已提供但命名不规范
|
||||
- 需人工判断
|
||||
5. 生成缺失项清单和建议动作。
|
||||
|
||||
### 关键难点
|
||||
|
||||
不是所有缺失都等价。需要区分：
|
||||
|
||||
- 监管强制项缺失
|
||||
- 目录中声明有但实际文件找不到
|
||||
- 文件存在但内容不符合该章节点用途
|
||||
|
||||
### 输出要求
|
||||
|
||||
- 命中项列表
|
||||
- 缺失项列表
|
||||
- 风险等级
|
||||
- 建议补充动作
|
||||
- 规则依据
|
||||
|
||||
## 5.3 产品关键信息抽取能力
|
||||
|
||||
### 目标
|
||||
|
||||
从产品文件中提取关键信息并自动填写到目标文件或结构化结果中。
|
||||
|
||||
### 目标字段建议
|
||||
|
||||
至少包括题面点名字段：
|
||||
|
||||
- 产品名称
|
||||
- 检测靶标
|
||||
- 适用范围 / 预期用途
|
||||
- 储存条件
|
||||
- 性能指标
|
||||
|
||||
结合样例材料，建议进一步扩展：
|
||||
|
||||
- 包装规格
|
||||
- 适用样本类型
|
||||
- 适用仪器
|
||||
- 分类编码
|
||||
- 临床评价路径
|
||||
- 申请人名称
|
||||
- 生产地址
|
||||
- 标准清单
|
||||
- 申报日期
|
||||
|
||||
### 字段来源优先级
|
||||
|
||||
需要明确来源优先级，例如：
|
||||
|
||||
1. 申请表
|
||||
2. 产品说明书
|
||||
3. 产品列表
|
||||
4. 声明类文件
|
||||
5. 其他说明材料
|
||||
|
||||
或根据字段类型分别设定优先级。
|
||||
|
||||
### 抽取逻辑
|
||||
|
||||
1. 规则抽取显式字段。
|
||||
2. 表格抽取规格、组分、标准清单等。
|
||||
3. 对长文本字段使用 LLM 归纳。
|
||||
4. 将结果写入统一字段池。
|
||||
5. 标记字段来源和置信状态。
|
||||
|
||||
### 输出要求
|
||||
|
||||
- 字段名
|
||||
- 字段值
|
||||
- 来源文档
|
||||
- 来源片段
|
||||
- 是否冲突
|
||||
- 是否可直接回填
|
||||
|
||||
## 5.4 自动回填准备能力
|
||||
|
||||
### 目标
|
||||
|
||||
将抽取得到的信息填入目标文件或目标字段。
|
||||
|
||||
### 首版建议范围
|
||||
|
||||
首版不必以“完整保真写回 Word 模板”为核心验收，而可以先实现：
|
||||
|
||||
- 申请表字段回填数据集
|
||||
- 对照清单字段回填数据集
|
||||
- 页面可视化回填预览
|
||||
|
||||
### 处理逻辑
|
||||
|
||||
1. 根据目标模板定义字段映射。
|
||||
2. 从统一字段池读取值。
|
||||
3. 对冲突字段进行拦截或提示。
|
||||
4. 生成回填预览结果。
|
||||
|
||||
### 后续扩展
|
||||
|
||||
如需求方确认需要真实文档导出，再增加 Word 模板写回。
|
||||
|
||||
## 5.5 一致性核查能力
|
||||
|
||||
### 目标
|
||||
|
||||
核查不同文档间相同信息是否一致，检测章节结构和规范性问题。
|
||||
|
||||
### 强一致字段
|
||||
|
||||
建议首版按强一致处理的字段包括：
|
||||
|
||||
- 产品名称
|
||||
- 申请人名称
|
||||
- 规格型号 / 包装规格
|
||||
- 分类编码
|
||||
- 申报产品名称对应的章节点标题
|
||||
|
||||
### 语义一致字段
|
||||
|
||||
可按语义一致或近似一致处理的字段包括：
|
||||
|
||||
- 预期用途 / 适用范围
|
||||
- 储存条件描述
|
||||
- 适用样本类型
|
||||
|
||||
### 结构核查
|
||||
|
||||
除字段一致性外，还应检查：
|
||||
|
||||
- 说明书是否包含关键章节
|
||||
- 目录页是否覆盖当前章节点
|
||||
- 文档标题是否规范
|
||||
- 是否存在不属于本产品的资料混入
|
||||
|
||||
### 典型异常示例
|
||||
|
||||
根据当前样例，系统应能识别：
|
||||
|
||||
- 说明书产品是“2019-nCoV”，申请表和产品列表是“呼吸道合胞病毒、肺炎支原体”。
|
||||
- 这类冲突应被直接标记为高风险或至少中高风险。
|
||||
|
||||
### 输出要求
|
||||
|
||||
- 一致字段列表
|
||||
- 冲突字段列表
|
||||
- 冲突明细
|
||||
- 风险等级
|
||||
- 处理建议
|
||||
|
||||
## 5.6 合规风险预警能力
|
||||
|
||||
### 目标
|
||||
|
||||
把完整性检查、字段抽取和一致性核查的结果汇总成可执行的风险清单。
|
||||
|
||||
### 风险类型建议
|
||||
|
||||
- 缺失风险
|
||||
- 混档风险
|
||||
- 字段冲突风险
|
||||
- 章节不规范风险
|
||||
- 历史申报事项风险
|
||||
- 资料真实性 / 版本一致性风险
|
||||
|
||||
### 风险分级建议
|
||||
|
||||
首版可采用：
|
||||
|
||||
- 高风险
|
||||
- 中风险
|
||||
- 低风险
|
||||
- 待人工确认
|
||||
|
||||
### 处理建议生成逻辑
|
||||
|
||||
规则部分负责给出基础动作，例如：
|
||||
|
||||
- “补充缺失文件”
|
||||
- “核对产品名称”
|
||||
- “重新确认临床资料版本”
|
||||
|
||||
LLM 负责把这些动作组织成自然语言建议，但不能改变底层规则结论。
|
||||
|
||||
## 6. 统一字段池设计需求
|
||||
|
||||
为支撑抽取、回填和一致性核查，建议在 `agent_core` 内形成统一字段池概念。
|
||||
|
||||
字段池至少记录：
|
||||
|
||||
- 字段名
|
||||
- 标准化字段值
|
||||
- 原始字段值
|
||||
- 来源文档
|
||||
- 来源位置
|
||||
- 置信度
|
||||
- 冲突状态
|
||||
- 最终推荐值
|
||||
|
||||
这是本题从“简单聊天 Demo”走向“资料审核系统”的关键能力之一。
|
||||
|
||||
## 7. 规则体系需求
|
||||
|
||||
### 7.1 完整性规则
|
||||
|
||||
用于判断：
|
||||
|
||||
- 某章节点是否必交
|
||||
- 当前资料是否命中
|
||||
- 缺失是否构成高风险
|
||||
|
||||
### 7.2 抽取规则
|
||||
|
||||
用于：
|
||||
|
||||
- 标题识别
|
||||
- 表格字段映射
|
||||
- 固定格式声明提取
|
||||
|
||||
### 7.3 一致性规则
|
||||
|
||||
用于定义：
|
||||
|
||||
- 哪些字段必须完全一致
|
||||
- 哪些字段允许近似匹配
|
||||
- 如何判断冲突严重度
|
||||
|
||||
### 7.4 风险映射规则
|
||||
|
||||
用于把缺失、冲突、不确定结果映射为风险级别和处理建议。
|
||||
|
||||
## 8. 工具体系需求
|
||||
|
||||
题面附加要求提到需要展示实际调用的关键工具/库。因此 `agent_core.tools` 中应逐步沉淀出与本题强相关的工具，而不是只保留通用样例工具。
|
||||
|
||||
建议工具方向包括：
|
||||
|
||||
1. 文档页数统计工具
|
||||
2. 章节点识别工具
|
||||
3. 必交项检查工具
|
||||
4. 字段抽取工具
|
||||
5. 字段一致性比对工具
|
||||
6. 风险汇总工具
|
||||
|
||||
这些工具都应通过 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. 将“回填准备结果”纳入正式输出结构。
|
||||
|
||||
## 13. 验收标准
|
||||
|
||||
本模块完成后，应至少满足：
|
||||
|
||||
1. 能支持目录汇总、完整性检查、字段抽取、一致性核查、风险预警五类核心任务。
|
||||
2. 核心结论有结构化输出，不依赖随意文本。
|
||||
3. 规则和模型分工清晰，法规判断不完全依赖大模型生成。
|
||||
4. 输出能关联到具体文档和证据片段。
|
||||
5. 测试环境下可以通过 Mock Provider 验证主要编排逻辑。
|
||||
Reference in New Issue
Block a user