What this category's data looks like
In the vocational school student internship management scenario, materials are mainly of three types: internship agreements, internship plans, and internship logs. Sources are academic affairs system exports, internship unit receipts, and supervising teacher archives. The update cadence advances by batch, with each batch containing multiple agreements and plans, and logs submitted weekly or monthly. Agreements focus on unit and position names, internship start and end dates, and signatures and seals; plans focus on batch headcount, number of positions, weekly schedule, and supervising teacher signature; logs focus on date, daily task name and quantity, and student and mentor signatures. After the three types of materials enter parsing and training tasks, each becomes a source of verifiable data rows: agreements and plans are used to establish the object and field baseline, logs are used to compare item by item whether names, quantities, and dates are consistent with the ledger, and signatures and receipts serve as completeness check items.
Configuration and implementation checks
This step is executed by parsing and training tasks (server-side tasks), outputting data rows and index status (parsed, indexing, indexed). The discrepancy list is then completed by retrieval and subsequent processing, used for the reviewer to confirm and write back.
| Object | Check | Verification action |
|---|---|---|
| Internship agreement | Unit name, position name, internship start and end dates, signatures and seals are consistent with the ledger item by item | Check fields and signatures by data row, and confirm the status is parsed, indexing, or indexed |
| Internship plan | Batch headcount, number of positions, weekly dates, and supervising teacher signature are consistent with the ledger | Check the identity of the file record and the data row, and check whether the chunks corresponding to chunkSize and chunkSplitter cover all fields |
| Internship log | Date, task name, quantity, and student and mentor signatures match the agreement and plan | Compare discrepancy fields item by item, and record missing signatures or receipt items |
| Parsing and training task | The rebuild scope only covers data that has completed indexing; data pending indexing does not participate in recall | View the data rows covered by the rebuild task, and check trainingType and the index status transitions |
Three common errors
- Symptom: the name, quantity, and date of the same record do not match between the agreement and the log. Cause: the two material versions are not synchronized, or one side was updated first without writing back to the ledger.
- Symptom: the material cannot be retrieved just after upload. Cause: the data row is in a pending-indexing state, and the retrieval layer is naturally isolated and does not recall it.
- Symptom: after a training failure, empty data rows are left behind, or rebuilding after switching models takes abnormally long. Cause: failed data was not cleaned up, and the rebuild scope mistakenly covers data pending indexing.
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, confirm that the three states parsed, indexing, and indexed are consistent with the interface display, and that the rebuild only covers data that has completed indexing.
Business test: use one real record to find fields inconsistent with the ledger, and hand them to the reviewer for confirmation and write-back.
- Open the data row verification status, check the file record and the data row separately, and confirm that the identifiers are distinguishable.
- View the data rows covered by the rebuild task, and check
trainingType,chunkSize,chunkSplitter, and the index status.