What this category's data looks like
Materials for scheduling and class-hour deduction in training institutions include three types: class schedules, class-hour deduction records, and class-change requests. Class schedules are published by the academic affairs office weekly or monthly, with fields including class, course, teacher, classroom, start and end time; class-hour deduction records are submitted by the instructor after class, with fields including student, course, number of class hours, teaching date, signature or receipt; class-change requests are initiated by the academic affairs office or the teacher, with fields including the original class session, target class session, reason for the class change, and confirmation by both parties. The three types of materials update at different rhythms: class schedules change with scheduling adjustments, class-hour deduction records accumulate per session, and class-change requests are generated per event. After materials enter the parsing and training task, they are first persisted as visible data rows and bound to a unique data identifier, then flow through the three index states; retrieval and subsequent processing produce basis entries that can be traced back to the original text, for replying to parents or writing into proposals.
Configuration and implementation checks
This step is executed by the parsing and training task (server-side task), outputting data rows and index states (parsed, indexing, indexed). The "basis entries that can be traced back to the original text" are then completed by retrieval and subsequent processing. After parsing is completed, parsing and chunking immediately persist as visible data rows and bind to a unique data identifier; the index flows through the three states, and data pending indexing does not participate in recall.
| Object | Check | Verification action |
|---|---|---|
| Class schedule | Fields include class, course, teacher, classroom, start and end time; the name and date of the same class session in two materials must match | Open the data row to check the status, confirm that the class schedule entry is in parsed, indexing, or indexed, and trace back to the original class session |
| Class-hour deduction record | Fields include student, course, number of class hours, teaching date, signature or receipt; entries missing a signature or receipt cannot be used as a basis | Check the file record and the data row separately, confirm that the number of class hours and teaching date are consistent with the class schedule, and check the signature or receipt |
| Class-change request | Fields include the original class session, target class session, reason for the class change, and confirmation by both parties; the version must be current, and unsynchronized old versions do not participate as a basis | Look at the data rows covered by the rebuild task, confirm that only data with completed indexing is covered, and check the version of the class-change request |
| Parsing and chunking | After parsing is completed, immediately persist as visible data rows and bind to a unique data identifier; chunking parameters such as chunkSize and chunkSplitter affect entry boundaries | Check that the data row status is consistent with the interface display, and confirm that trainingType corresponds to the processing mode |
Three common errors
- Symptom: the name and date of the same class session in the class schedule and the class-hour deduction record do not match. Cause: the two materials are updated separately and are not aligned by the same class session identifier.
- Symptom: the version of the class-change request is not synchronized, and the old version is still used as a basis. Cause: after the material is updated, it is not re-persisted and rebuilt, and the index still points to the old content.
- Symptom: a class-hour deduction record missing a signature or receipt is still referenced. Cause: parsing only completes persistence and does not check the signature field, so the retrieval layer cannot identify the missing part.
How to verify the setup
Acceptance of this feature: upload a material, see whether the data row status flows through parsed, indexing, and indexed, and see whether the data rows covered by the rebuild task contain only data with completed indexing; check the chunking and processing modes corresponding to chunkSize, chunkSplitter, and trainingType.
Business test: ask a basis question that spans materials, see whether the answer gives a traceable source, and confirm that the entry matches the original text and that the version is current.
- Open the data row to check the status, confirm that it is consistent with the interface display, and check the identifiers of the file record and the data row separately.
- View the data rows covered by the rebuild task, confirm that only data with completed indexing is covered, and that data pending indexing does not participate in the rebuild.