What this category's data looks like
Primary and secondary school admissions organizations intensively process three types of materials during the admissions season: admissions plans, application materials checklists, and admission lists. Sources include documents issued by education authorities, school-drafted detailed rules, and scanned certificates submitted by parents. The update rhythm advances on a rolling basis with the application, review, and admission batches. The three types of materials play different roles when entering the document parsing and chunking function: the admissions plan serves as the underlying rule draft and needs clause-level fragments extracted for retrieval; the application materials checklist serves as the basis for field comparison and needs to preserve field structures such as name, ID number, and date; the admission list serves as the result record and needs to be split by entry while preserving signature and receipt positions. Field characteristics are concentrated in names, quantities, dates, and signature columns. It is common for the same record to fail to match across two materials, for versions to be out of sync, and for signatures or receipts to be missing.
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 "unified terminology table and comparison draft" is then completed by retrieval and subsequent processing. After parsing is completed, parsing and chunking immediately persist to the database as visible data rows and bind a unique data identifier. The index transitions through three states, and data pending indexing does not participate in recall.
| Object | Check | Verification action |
|---|---|---|
| Admissions plan | Clause fragments can be traced back to the original text, and the same term is written consistently throughout | Check whether the data row status after chunking is parsed or indexing, and check whether chunkSize and chunkSplitter split according to clause boundaries |
| Application materials checklist | Name, quantity, and date fields match the admission list, and versions are in sync | Check the file record and data row separately, check the processing mode corresponding to trainingType, and confirm that the fields of the same record are consistent across the two materials |
| Admission list | Entry splitting preserves signature and receipt positions, and translated names can be traced back to the original text | Open the data row to check whether the status is indexed, and check whether the signature column and receipt fields are persisted together with the entry |
| Data row | Is in one of the three states parsed / indexing / 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 changing models only rebuilds indexed data |
Three common errors
- Symptom: Materials just uploaded cannot be found. Cause: The data row is in parsed or indexing, data pending indexing does not participate in recall, and you must wait for indexing to complete.
- Symptom: The same record's name, quantity, and date do not match between the application materials checklist and the admission list. Cause: The two materials' versions are not in sync, and the fields are not compared against the same terminology table.
- Symptom: After training fails, empty data rows are left behind, or rebuilding after changing models takes abnormally long. Cause: Rebuilding only targets data whose indexing has completed, while initial training covers data pending indexing and data being indexed; the two cannot be interchanged.
How to verify the setup
Acceptance for this feature: Upload one material, observe the data row status transitions and the coverage scope of the rebuild task, and confirm that the statuses are parsed, indexing, and indexed in sequence, and that rebuilding covers only indexed data rows.
Business test: Sample three terms and check whether their spelling is consistent throughout, verify whether translated names can be traced back to the original text, and confirm that signature and receipt fields are not missing.
- Open the data row to check the status, confirm that the identities of the file record and the data row are distinguishable, and check the file record and data row separately.
- Look at the data rows covered by the rebuild task, and confirm that it covers only data whose indexing has completed, and that data pending indexing does not participate in the rebuild chain.