What this category's data looks like
This page addresses the course selection, scheduling, and classroom resource allocation category. The materials come from three types of files: course offering plans, scheduling tables, and course selection rules, and the update cadence follows semester batches and temporary schedule changes. The three types of materials play different roles when entering document parsing and chunking: course offering plans provide course and class fields, scheduling tables provide time, classroom, and instructor fields, and course selection rules provide capacity, priority, and effective date fields. After parsing is complete, parsed chunks are immediately persisted as visible data rows and bound to a unique data identifier, so the identities of file records and data rows remain separate. Field characteristics are concentrated in course name, course code, class size, classroom number, class date, signature, and receipt. If the name, quantity, or date of the same record does not match across two materials, or if versions are not synchronized, or signatures or receipts are missing, subsequent retrieval and citation will deviate.
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. Successful parsing does not mean retrieval will definitely hit; it also depends on the index status.
| Object | Check | Verification action |
|---|---|---|
| Course offering plan | Course name, course code, class size, and signature date are consistent across versions | Verify the uniqueness of the current version, compare whether the old version is traceable and citations are synchronized, and check whether signatures and receipts are complete |
| Scheduling table | Classroom number, class date, instructor, and period match across versions | Verify file records and data rows separately, and confirm that fields are not misaligned after chunking by chunkSize and chunkSplitter |
| Course selection rules | Capacity, priority, effective date, and version number are updated in sync | Change one rule content and see whether the version number and citations are updated in sync, and confirm the processing mode corresponding to trainingType |
| Data row status | Is in one of the three states parsed / indexing / indexed and is consistent with the interface display | Open the data row to verify the status, and confirm that data pending indexing does not participate in recall |
Three common errors
- Symptom: the name, quantity, or date of the same course does not match across two materials. Cause: the course offering plan and scheduling table are maintained separately, versions are not synchronized, and signatures or receipts are missing.
- Symptom: newly uploaded materials cannot be found. Cause: successful parsing does not mean retrieval will definitely hit; the data row is still in parsed or indexing and has not entered indexed.
- Symptom: empty data rows remain after training fails. Cause: the initial training overwrites data that is pending indexing and being indexed, failed data is not edited or deleted in time, and rebuild only targets data whose indexing is already complete.
How to verify the setup
This feature acceptance: upload one material, observe the data row status transitions and the coverage scope of the rebuild task, and confirm that the three states parsed, indexing, and indexed are consistent with the interface display, and that rebuild only covers data whose indexing is already complete.
Business test: change one piece of content, see whether the version number and citations are updated in sync, and verify that the tokens and array count of the cited text are recorded separately.
- Open the data row to verify the status, confirm that the identities of file records and data rows remain separate, and that data in parsed or indexing does not participate in recall.
- Check the data rows covered by the rebuild task, confirm that it only targets data whose indexing is already complete, and that when rebuilding with a different model or synonyms, data pending indexing does not participate in the rebuild chain.