What this category's data looks like
This page focuses on data versions and change maintenance in the scenario of primary and secondary school timetables and after-school service scheduling. Material sources include the master timetable exported from the academic affairs system, teacher assignment tables, after-school service project tables, as well as scheduling notices, adjustment receipts, and signed confirmation documents issued by the school. The update cadence is concentrated at the beginning of the semester, monthly, and at temporary schedule adjustment points, and the fields cover course name, assigned teacher, class, venue, start and end dates, number of class hours, and approval signature. The master timetable carries the global time slots and class distribution, the teacher assignment table carries the correspondence between personnel and subjects, and the after-school service project table carries the project, number of participants, and fee basis. When these three types of materials enter the document parsing and chunking function, each is stored as an independent data row and bound to a unique data identifier; the chunking results flow through the three states of parsed, indexing, and completed, for use in subsequent retrieval and version ledger generation.
Configuration and implementation checks
This step is executed by the parsing and training task (server-side task), which outputs data rows and index status (parsed, indexing, indexed). The version ledger and change records are then completed by retrieval and subsequent processing. After parsing is completed, parsed chunks are immediately stored as visible data rows and bound to a unique data identifier; data pending indexing does not participate in recall, and changing the model only rebuilds data that has completed indexing.
| Object | Check | Verification action |
|---|---|---|
| Master timetable | Whether the course name, class, start and end dates, and signature correspond item by item with the teacher assignment table | Open the data row to check whether the status is parsed, indexing, or indexed, and compare the dates and signature fields of the two materials |
| Teacher assignment table | Whether the assigned teacher, subject, and number of class hours are consistent with the basis of the after-school service project table | Check the file records and data rows separately, confirm that the identifiers are distinguishable, and check whether trainingType matches the processing mode |
| After-school service project table | Whether the project name, number of participants, and receipt match the time slots of the master timetable | Check whether the data rows covered by the rebuild task contain only data that has completed indexing, and record the number of references and reference text tokens |
| Parsing and chunking configuration | Whether the chunk boundaries are split according to the material structure, and whether data pending indexing is safely isolated | View the chunking results corresponding to chunkSize and chunkSplitter, and confirm that the index status transitions are consistent with the interface display |
Three common errors
- Symptom: The name, quantity, and date of the same course do not match across the two materials. Cause: The master timetable and the teacher assignment table are parsed and stored separately, without cross-material comparison and version alignment.
- Symptom: Old-version materials are still hit by retrieval, and the current version is not unique. Cause: The versions are not synchronized, the old-version data rows are not marked as invalid, and the index status is still completed.
- Symptom: The after-school service project table lacks a signature or receipt, and changes cannot be traced. Cause: After the material is parsed, the approval fields are not associated, and the version ledger does not record the signature status and change source.
How to verify the setup
This function's acceptance: upload one material, observe the data row status transitions and the coverage scope of the rebuild task, confirm that data pending indexing does not participate in recall and that changing the model only rebuilds data that has completed indexing, and check chunkSize, chunkSplitter, trainingType, and the chunking results.
Business test: change one piece of content, observe whether the version number and references are updated synchronously, and confirm that the current version is unique, the old version is traceable, and references are synchronized.
- Open the data row to check whether the status is consistent with the interface display, and check the identifiers of the file records and data rows separately.
- View the data rows covered by the rebuild task, confirm that only data that has completed indexing is covered, and separately record the number of references and reference text tokens.