What this category's data looks like
In the scheduling and class-hour deduction scenario for training institutions, class schedules, class-hour deduction records, and schedule-change applications are the three core types of materials. Their fields cover course name, class, teacher, class date, number of class hours, student roster, signature, and receipt. Material sources include academic affairs system export tables, scanned paper signatures, schedule-change approval forms, and parent receipts. The update rhythm is weekly scheduling, per-session class-hour deduction, and immediate application for schedule changes. When these materials enter the vector model and indexing stage, class schedules serve as the index for scheduling structure, class-hour deduction records serve as the index for class-hour consumption facts, and schedule-change applications serve as the index for change basis. Together, the three support the generation of version ledgers and change records, but the indexing stage is only responsible for vectorization and recall merging; it does not produce the ledger itself.
Configuration and implementation checks
This stage is executed by the indexing service and vector database, outputting vectors and index status (whether recall is possible and whether data in the same group is merged). The "version ledger and change records" are then completed by subsequent AI nodes, code nodes, or manual work (retrieval and citation trimming only take supporting materials).
| Object | Check | Verification action |
|---|---|---|
| Class schedule | Check whether the course name, class, teacher, class date, number of class hours, and signature field are consistent with the current version | Open the knowledge base settings and check the index model; open a class schedule data row and check the index fields; run a retrieval once to see whether the same group is merged |
| Class-hour deduction record | Check whether the student roster, class-hour deduction date, number of class hours, signature or receipt match the class schedule and schedule-change application | Check the data scope covered by the rebuild task; retrieve a class-hour deduction record to see whether it can be recalled and whether data in the same group is merged |
| Schedule-change application | Check whether the dates before and after the schedule change, course name, quantity, and approval signature are consistent with the class schedule and class-hour deduction records | Sample a schedule-change data row and check the index fields; check the budget of limit in the cited text |
Three common errors
- Symptom: For the same class-hour deduction record, the course name and number of class hours do not match between the class schedule and the class-hour deduction table. Inspect the following: Versions are not synchronized.
- Symptom: A schedule-change application lacks a signature or receipt, but the class-hour deduction record is still retrieved. Inspect the following: When materials enter the index, current versions and old versions are not distinguished, and merging takes the highest score, masking the missing item.
- Symptom: After changing the vector model, recall quality decreases, and some data rows have content but cannot be retrieved. Inspect the following: The rebuild task is triggered only for data that has already been indexed and does not cover all data rows.
How to verify the setup
Acceptance for this feature: sample a data row and check the index fields to confirm that multiple vector identifiers are present; then run a retrieval once to see whether data in the same group is merged and the highest score is taken.
Business test: change one piece of content and see whether the version number and citations are updated synchronously; at the same time, check and record limit, and the number of citations separately.
- In the knowledge base settings, check that the index model is consistent with the vector model actually used; open a data row and check whether the index fields are complete.
- Check the data scope covered by the rebuild task and confirm whether all data rows that have already been indexed are triggered for rebuild after changing the model.