What this category's data looks like
This category's data looks like this: Credit management for primary and secondary school teacher training involves three core types of materials: training notices, credit recognition forms, and participant lists. Training notices are issued by education administrative departments or training institutions, and contain the training project name, start and end dates, number of class hours, target participants, and official seal; credit recognition forms are filled in by the teacher's school or training institution, and contain the teacher's name, ID number, training project, recognized credits, and review signature; participant lists are provided by the training organizer, and contain name, unit, training date, sign-in, and receipt. The three types of materials have different update rhythms: notices are issued with project batches, recognition forms are summarized by semester, and lists are supplemented after training ends. After entering the document parsing and chunking function, each takes on a different role: notices are used to verify the project name and dates, recognition forms are used to verify the credit amount and signature, and lists are used to verify the participants and receipts. Field characteristics are concentrated in four categories: name, quantity, date, and signature. The same record should remain consistent across the three materials, which is the basis for comparison in discrepancy localization.
Configuration and implementation checks
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 persisted as visible data rows and bound to a unique data identifier, and the index transitions through the three states parsed, indexing, and indexed.
| Object | Check | Verification action |
|---|---|---|
| Training notice | Whether the project name, start and end dates, number of class hours, and official seal are consistent with the ledger | Check the data row status after the notice is persisted, confirm that it enters indexing after parsed, then check whether the chunkSize and chunkSplitter splitting of notice fields preserves the date and official seal positions |
| Credit recognition form | Whether the teacher's name, number of recognized credits, review signature, and recognition date are consistent with the ledger | Check the identity identifiers of the file record and the data row separately, view the recognition form splitting mode by trainingType, and confirm that the signature and quantity fields are not truncated |
| Participant list | Whether the participant names, units, training dates, and sign-in receipts are consistent with the ledger | Check whether the list data rows are in indexed, and check that the rebuild task coverage includes only data rows with completed indexing |
| Data row status | Is in one of the three states and consistent with the interface display | Open the data row to check the status, confirm that data pending indexing does not participate in recall, and that rebuild targets only data with completed indexing |
Three common errors
- Symptom: The name or unit of the same teacher does not match between the notice and the list. Cause: The two material versions were not synchronized, and after parsing the data rows are independent of each other, with no cross-material comparison performed.
- Symptom: The number of credits in the recognition form is inconsistent with the ledger quantity. Cause: The quantity field was truncated during chunking or was not bound to a unique data identifier, and old-version data was retrieved during retrieval recall.
- Symptom: The notice lacks a signature or the list lacks a receipt, and the discrepancy list does not flag it. Cause: The signature and receipt fields were not included in the verification dimensions; successful parsing does not equal a retrieval hit.
How to verify the setup
How to verify the setup: Acceptance for this function: upload one material, observe the data row status transitions and the coverage of the rebuild task, and confirm that the transitions from parsed to indexing to indexed are consistent with the interface display, and that rebuild covers only data rows with completed indexing.
Business test: Use one real record to find fields inconsistent with the ledger, check the file record and the data row separately, and locate discrepancies in the four field categories: name, quantity, date, and signature.
- Open the data row to check the status, confirm that the three-state transitions are consistent with the interface display, and that data pending indexing does not participate in recall.
- Check the identity identifiers of the file record and the data row separately, and see whether the data rows covered by the rebuild task include only those with completed indexing.