What this category's data looks like
In the graduate admissions re-examination and admission scenario, materials mainly come from re-examination plans, candidate score sheets, transfer lists, and various receipts. Re-examination plans are updated by batch, with fields including stage name, date, and signature column; candidate score sheets are updated on a rolling basis as grading progresses, with fields including candidate number, subject, score, and ranking; transfer lists are published by round, with fields including name, preliminary exam score, and proposed admission major. After the three types of materials enter parsing and training tasks, each is stored as an independent data row, bound to a unique data identifier, for use in subsequent retrieval and discrepancy location. During material verification, the name, quantity, and date of the same candidate across different materials must remain consistent; version synchronization and complete signature receipts are prerequisites for review.
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. After parsing is completed, parsed chunks are immediately stored as visible data rows and bound to a unique data identifier; the index transitions through three states, data pending indexing does not participate in recall, and changing the model only rebuilds data whose indexing has been completed.
| Object | Check | Verification action |
|---|---|---|
| Re-examination plan | Stage name, date, and signature column are consistent between the plan and the receipt; missing signature or receipt is deemed inconsistent | Check the parsing status of the plan data row, confirm that the signature column field has been stored, and check whether chunkSize and chunkSplitter split table rows completely |
| Candidate score sheet | The name, subject, score, and date of the same candidate number match across the two materials | Check the file record and data row identifier separately, search by candidate number, compare the score sheet and ledger fields, and record the discrepant fields |
| Transfer list | The proposed admission major, preliminary exam score, and date are synchronized with the re-examination plan version, and names and quantities are consistent | View the data rows covered by the rebuild task, confirm that it targets only data whose indexing has been completed, and check whether trainingType and the index status are indexed |
| Data row | Is in one of the three states parsed, indexing, or indexed and is 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 failed training data can be directly edited or deleted |
Three common errors
- Symptom: A newly uploaded material cannot be found. Cause: The data row is in parsed or indexing state; data pending indexing is naturally isolated at the retrieval layer and is not recalled, so you must wait for indexing to complete.
- Symptom: The same candidate's name or date does not match between the score sheet and the transfer list. Cause: The versions of the two materials are not synchronized, or table rows were split incompletely during parsing and chunking, causing field misalignment.
- Symptom: Empty data rows remain after training fails. Cause: Orphan data left by interrupted training is not edited or deleted in time, affecting subsequent discrepancy location and review write-back.
How to verify the setup
This feature's acceptance: Upload one material and observe the data row status transitions and the coverage scope of the rebuild task. The data row should go from parsed to indexing to indexed; the rebuild task covers only data whose indexing has been completed, and data pending indexing does not participate in the rebuild chain.
Business test: Use one real record to find fields inconsistent with the ledger, check the file record and data row identifier separately, record discrepancies in name, quantity, and date, and submit them to the reviewer for confirmation and write-back.
- Open the data row to check the status, confirm that the three states are consistent with the interface display, and that data pending indexing does not participate in recall.
- Check the file record and data row identifier separately, view the data rows covered by the rebuild task, and confirm that it targets only data whose indexing has been completed.