What this category's data looks like
Graduate training process management involves materials such as training plans, proposal reports, and mid-term assessment forms. The sources are supervisors, school secretaries, and the graduate students themselves, and the update cadence advances with the semester, with submissions made in batches at the proposal and mid-term milestones. When materials enter this feature, each plays a different role: the training plan provides course and credit fields, the proposal report provides topic selection, date, and signature fields, and the mid-term assessment form provides assessment conclusion, quantity, and receipt fields. The field characteristic is that the name, quantity, and date of the same record must be consistent across two materials, and signatures and receipts must be complete. Materials are uploaded as documents, parsed and chunked, and then stored as data rows for subsequent retrieval and discrepancy localization.
Configuration and implementation checks
This step is executed by the parsing and training task (server-side task), which outputs data rows and index status (parsed, indexing, indexed). The "discrepancy list" is then completed by retrieval and subsequent processing. After parsing is complete, parsed chunks 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 |
|---|---|---|
| Training plan | Course name, credit quantity, start and end dates, and signature field must be consistent with the ledger | Open the data row to check the status, confirm the fields and dates, and check whether the signature field is complete |
| Proposal report | Topic name, proposal date, review signature, and receipt must correspond to the training plan | Verify the file record and the data row separately, confirm the date and signature, and record the discrepancy fields |
| Mid-term assessment form | Assessment conclusion, quantity, date, and signature must connect with the proposal report | Look at the data rows covered by the rebuild task and confirm that only data with completed indexing is covered |
| Data row status | Is in one of the three states and is consistent with the interface display | Open the data row to check the status, and confirm that parsed, indexing, and indexed are consistent with the interface |
Three common errors
- Symptom: The name, quantity, and date of the same record do not match across two materials. Cause: Materials are submitted in batches, fields are not aligned to the same object, and discrepancies are not localized before review.
- Symptom: Versions are not synchronized, and an old training plan coexists with a new proposal report. Cause: Rebuilding only targets data with completed indexing, and data pending indexing does not participate in the rebuild chain.
- Symptom: Signatures or receipts are missing, and the materials are incomplete. Cause: Successful parsing does not mean retrieval will definitely hit; the index status also matters, and data pending indexing does not participate in recall.
How to verify the setup
Feature acceptance: Upload one material, observe the data row status transitions and the coverage scope of the rebuild task, verify the three states parsed, indexing, and indexed against the interface display, confirm that rebuilding only covers data with completed indexing, and check how the chunkSize, chunkSplitter, and trainingType related configurations are reflected on the data rows.
Business test: Use one real record to find fields inconsistent with the ledger, verify the file record and the data row separately, record discrepancies in name, quantity, date, and signature, and submit them to the reviewer for confirmation and write-back.
- Open the data row to check the status, confirm that the three-state transitions are consistent with the interface display, and verify the file record and the data row separately.
- Look at the data rows covered by the rebuild task, confirm that only data with completed indexing is covered, and record cases where data pending indexing does not participate in recall.