这个品类的数据长什么样
学校安全隐患排查与校园事件上报，常见材料包括安全检查表、隐患整改台账、突发事件报告、家长告知回执与应急预案版本页。来源多为园内自查记录、上级检查反馈、班级日报与门卫登记，更新节奏为每日巡查、每周汇总、每月归档、事件发生后即时补报。字段特征集中在检查项目、隐患描述、整改责任人、整改期限、复查结论、事件经过、上报时间、签字与回执。材料进入解析与训练任务时，安全检查表与整改台账承担字段比对角色，突发事件报告承担时间线与签字核验角色，预案版本页承担现行性判断角色，回执承担送达确认角色。
配置怎么定
这一环由解析与训练任务（服务端任务）执行，输出数据行与索引状态（已解析、索引中、已完成）。「可回指原文的依据条目」由检索与后续处理接着完成。解析分块在解析完成后立即落库为可见数据行并绑定唯一数据标识，索引按 parsed、indexing、indexed 三态流转。
| 对象 | 判断 | 核验动作 |
|---|---|---|
| 安全检查表 | 检查项目、日期与签字需与整改台账对得上，缺签字或回执视为依据不完整 | 分别核对文件记录与数据行，确认检查日期、检查人签字与复查结论一致 |
| 隐患整改台账 | 同一隐患在两份材料里的名称、数量、日期不能对不上，版本需为现行 | 打开数据行核对状态是否为 parsed 或 indexed，并比对整改期限与复查日期 |
| 突发事件报告 | 事件经过、上报时间与回执需能回指原文，缺回执视为送达未闭环 | 核对报告与回执的签字栏，确认上报时间与家长告知时间一致 |
| 数据行与索引状态 | 处于三态之一且与界面显示一致，待索引数据不参与召回 | 看重建任务覆盖的数据行是否只含已完成索引的数据，并核对 trainingType 与 chunkSize |
容易做错的三处
- 现象：同一隐患在检查表与整改台账里的名称、数量、日期对不上。原因：两份材料分别录入，未做跨材料字段比对与回指原文核验。
- 现象：预案版本未同步，答复家长时引用了旧版条款。原因：版本页未随现行文件更新，检索仍召回历史分块。
- 现象：突发事件报告缺签字或回执，依据条目无法闭环。原因：上报与告知环节未收齐回执，材料进入解析时字段不完整。
怎么确认配好了
本功能验收：上传一份材料，看数据行状态流转与重建任务的覆盖范围。数据行应从 parsed 进入 indexing 再到 indexed，待索引数据不参与召回；换模型只对已完成索引的数据重建，核对 trainingType、chunkSplitter 与 chunkSize 的落库结果。
业务测试：问一个跨材料的依据问题，看回答是否给出可回指的出处。例如问某次隐患整改是否在规定期限内复查，回答需回指安全检查表与整改台账原文，并标明日期与签字。
- 分别核对文件记录与数据行，确认文件记录与数据行各自的身份分得开，状态与界面显示一致。
- 看重建任务覆盖的数据行是否只含已完成索引的数据，并核对
trainingType、chunkSplitter与chunkSize的落库结果。