What this category's data looks like
In the graduate admissions re-examination and admission scenario, the materials are mainly re-examination plans, candidate score sheets, and adjustment lists; the sources are internal documents issued by admissions units and system exports, and the update cadence rolls forward as batches progress. The re-examination plan contains application conditions, re-examination subjects, weights, and admission rules, with fields including major, date, and signature; the candidate score sheet contains preliminary examination, re-examination, total score, and ranking, with fields including candidate number, subject, score, and date; the adjustment list contains adjustment major, quota, proposed admission, and receipt, with fields including name, quantity, date, and signature. When these three types of materials enter the document parsing and chunking function, each plays its own role as a basis source: the re-examination plan provides rule clauses, the score sheet provides score facts, and the adjustment list provides quota and process status. After parsing and chunking, they are stored as data rows for retrieval and subsequent processing to generate basis entries that can be traced back to the original text.
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). "Basis entries that can be traced back to the original text" are then completed by retrieval and subsequent processing.
| Object | Check | Verification action |
|---|---|---|
| Re-examination plan | Whether the date and signature of the rule clauses are consistent with the current version | Open the data row to check the status, use chunkSize and chunkSplitter to see whether the chunks cover the clauses, and verify the signature and date fields |
| Candidate score sheet | Whether the name, quantity, and date of the same candidate match across the two materials | Verify the file records and data rows separately, and check whether the candidate number, subject, and score in the score sheet and the re-examination plan are consistent |
| Adjustment list | Whether the adjustment quota, proposed admission, and receipt are complete and version-synchronized | Verify the quantity, date, and signature of the adjustment list and the score sheet, confirm records missing signatures or receipts, and check the index status corresponding to trainingType |
| Data row index status | Is in one of parsed / indexing / indexed and consistent with the interface display | Look at the data rows covered by the rebuild task, confirm that only indexed data is covered, and that data pending indexing does not participate in recall |
Three common errors
- Symptom: the name, quantity, and date of the same candidate do not match between the score sheet and the adjustment list. Cause: the two material versions are not synchronized, or the candidate number and signature receipt were not verified during entry.
- Symptom: a newly uploaded material cannot be found. Cause: the data row is in parsed or indexing and has not completed indexing, so the retrieval layer naturally isolates it and it is not recalled.
- Symptom: empty data rows remain after training fails. Cause: successful parsing does not equal completed indexing, and failed data is not edited or deleted, causing the status to be inconsistent with the interface display.
How to verify the setup
This function's acceptance: upload one material, observe the data row status transitions and the coverage scope of the rebuild task, and confirm the statuses are parsed, indexing, and indexed, and that rebuild only covers indexed data.
Business test: ask a basis question that spans materials, see whether the answer gives a traceable source, and verify that the tokens of the cited text and the number of array entries are recorded separately.
- Open the data row to check the status, verify the file records and data rows separately, and confirm that the unique data identifier is bound correctly.
- Check the data rows covered by the rebuild task, and confirm that changing the model only rebuilds data that has completed indexing, while data pending indexing does not participate.