What this category's data looks like
This category's data looks like Academic education management in technical colleges involves three types of materials: student registration forms, teaching plans, and skills training records. Student registration forms are updated at semester registration points, with fields including student name, student ID, registration date, and signature; teaching plans are published by major and grade version, with fields including course name, number of class hours, start and end dates, and approval signature; skills training records are generated on a rolling basis by week or module, with fields including training item, consumable quantity, completion date, and instructor signature. When materials enter the document parsing and chunking function, student registration forms serve as the baseline for identity and registration status, teaching plans serve as the baseline for courses and class hours, and skills training records serve as the baseline for process and consumable quantity. After parsing and chunking, the three types of materials are stored as retrievable data rows for subsequent retrieval and comparison, forming the input for discrepancy localization.
Configuration and implementation checks
This step is executed by the parsing and training task (server-side task), outputting data rows and index status (parsed, indexing, indexed). The "discrepancy list" is then completed by retrieval and subsequent processing. After parsing is completed, parsing and chunking are immediately stored as visible data rows and bound to a unique data identifier; the index transitions through three states, and data pending indexing does not participate in recall.
| Object | Check | Verification action |
|---|---|---|
| Student registration form | The name, student ID, registration date, and signature of the same student are consistent in both materials | Check whether the data row status is parsed / indexing / indexed, separately check the identifiers of the file record and the data row, and check whether the chunk boundaries corresponding to chunkSize and chunkSplitter cut off the name or date |
| Teaching plan | The course name, number of class hours, start and end dates, and approval signature of the same course are consistent in both materials | Check whether the data row status is consistent with the interface display, check whether the processing mode corresponding to trainingType covers the course and class hour fields, and confirm that the rebuild task only covers data rows whose indexing has been completed |
| Skills training record | The item name, consumable quantity, completion date, and instructor signature of the same training item are consistent in both materials | Check whether the data row status is parsed, indexing, or indexed, check whether chunking splits the training item and quantity into different data rows, and confirm that data pending indexing is not recalled |
Three common errors
- Symptom: Materials that were just uploaded cannot be found. Cause: The data row is in parsed or indexing status, and data pending indexing is naturally isolated at the retrieval layer and is not recalled.
- Symptom: The name, quantity, and date of the same record do not match in the two materials. Cause: Chunk boundaries cut off fields or versions are not synchronized, causing field placement to be misaligned.
- Symptom: Empty data rows remain after training fails. Cause: Training interruption leaves orphan data, and materials lacking signatures or receipts have not completed parsing and storage.
How to verify the setup
Acceptance of this function: Upload one material, observe the data row status transitions and the coverage scope of the rebuild task, confirm that the status is parsed / indexing / indexed, that rebuild only covers data rows whose indexing has been completed, and check the settings corresponding to chunkSize, chunkSplitter, and trainingType.
Business test: Use one real record to find fields inconsistent with the ledger, submit them to the reviewer for confirmation, and write them back.
- Open the data row to check the status, separately check the identifiers of the file record and the data row, and confirm that the identities of the file record and the data row are distinguishable.
- Look at the data rows covered by the rebuild task, confirm that only data whose indexing has been completed is covered, and that data pending indexing does not participate in the rebuild chain.