What this category's data looks like
This page addresses the course selection, scheduling, and classroom resource allocation category. Material sources include three types: course offering plans, scheduling tables, and course selection rules. Course offering plans carry course names, credits, capacities, offering dates, and departmental signatures; scheduling tables carry classes, teachers, classrooms, time slots, and week numbers; course selection rules carry selection targets, priorities, add/drop deadlines, and receipts. The three material types are updated by semester or round, and among the fields, dates, quantities, names, and signature positions are most prone to discrepancies. When materials enter the parsing and chunking function, course offering plans and scheduling tables are stored as data rows to be indexed, and course selection rules, as rule-type materials, are likewise stored and bound to a unique data identifier; subsequently, retrieval and downstream processing generate basis entries that can be traced back to the original text, for answering parents or writing into proposals.
Configuration and implementation checks
Parsing and training tasks (server-side tasks) only output data rows and index status (parsed / indexing / indexed); basis entries that can be traced back to the original text must be produced afterward by retrieval and downstream processing. Data rows are stored immediately after parsing completes and are bound to a unique data identifier; the index transitions through three states, and data to be indexed does not participate in recall.
| Object | Check | Verification action |
|---|---|---|
| Course offering plan | Course names, credits, capacities, offering dates, and departmental signatures must be aligned item by item with the scheduling table | Check whether the names, quantities, dates, and signatures of the same course in the course offering plan and the scheduling table are consistent |
| Scheduling table | Classes, teachers, classrooms, time slots, and week numbers must be synchronized with the versions of the course offering plan and course selection rules | Check whether the version numbers and effective dates of the scheduling table, the course offering plan, and the course selection rules are consistent |
| Course selection rules | Selection targets, priorities, add/drop deadlines, and receipts must match the course offering plan and the scheduling table | Check whether the receipt signatures of the course selection rules and the date fields of the course offering plan and the scheduling table are consistent |
| Data row | The status is one of parsed / indexing / indexed and is consistent with what the interface displays | Open the data row to check the status, and check the values of chunkSize, chunkSplitter, and trainingType |
Three common errors
- Symptom: the name, quantity, or date of the same course does not match between two materials. Cause: the course offering plan and the scheduling table are updated independently, without field-level comparison.
- Symptom: after switching models, rebuilding takes abnormally long. Cause: the rebuild scope is not limited to data that has already been indexed, and data to be indexed is dragged into the rebuild chain.
- Symptom: course selection rules lack a signature or receipt. Cause: versions are not synchronized during material handoff, and signatures and receipts are not stored together with rule updates.
How to verify the setup
This feature's acceptance: upload one material, observe the data row status transitions and the coverage scope of the rebuild task, and confirm that after parsing completes the data is stored immediately as visible data rows, that the status transitions through parsed / indexing / indexed, and that the rebuild covers only data that has already been indexed.
Business test: ask a cross-material basis question, see whether the answer gives traceable sources, and check whether the number of citations and the tokens of the cited text are recorded separately.
- Open the data row to check the status, confirm it is consistent with what the interface displays, and check whether the identities of the file record and the data row are kept separate.
- View the data rows covered by the rebuild task, confirm it targets only data that has already been indexed, and check the values of
chunkSize,chunkSplitter, andtrainingType.