What this category's data looks like
Materials for the business basis query for examination organization and violation handling come from three sets: this center's examination manual, examination room record sheets, and violation fact records. The examination manual is revised by semester, with fields including examination name, time, process, and violation clause number; examination room record sheets are generated by session, with fields including examination room number, expected and actual number of attendees, invigilator signature, and date; violation fact records are generated by event, with fields including candidate information, violation circumstances, evidence, handling opinion, and receipt signature. After the three sets of materials enter the parsing and training task, each is split into data rows and bound to a unique data identifier, becoming retrievable basis entries. In terms of update cadence, the manual is re-versioned as regulations are adjusted, while record sheets and fact records are generated incrementally by session and event. During queries, it often happens that the name, quantity, or date of the same record does not match across two materials, versions are not synchronized, or signatures or receipts are missing, so basis entries must be able to point back to the original text and verify version and signature.
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). "Basis entries that can point back to the original text" are then completed by retrieval and subsequent processing. After parsing is completed, parsing and chunking are immediately persisted 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 |
|---|---|---|
| Examination manual | Clause number, examination name, date, and version number must be consistent with the current version, and the signature field must be complete | View the data rows after chunking according to chunkSize and chunkSplitter, and check whether the clause number and version number match the original text |
| Examination room record sheet | Examination room number, expected and actual number of attendees, invigilator signature, and date must be consistent with the session record | Check the file record and the data row separately to see whether the number of attendees, date, and signature match the other material |
| Violation fact record | Violation circumstances, evidence, handling opinion, and receipt signature must be consistent with the event record | Open the data row to check the status and confirm it is in one of parsed / indexing / indexed and consistent with what the interface displays |
| Data rows and index status | In one of the three states, data pending indexing is not recalled, and changing the model only rebuilds data that has completed indexing | View the training mode according to trainingType, and see whether the data rows covered by the rebuild task include only data that has completed indexing |
Three common errors
- Symptom: the name, quantity, or date of the same violation record does not match between the examination room record sheet and the violation fact record. Cause: the two sets of materials are entered separately and are not aligned by the same event identifier.
- Symptom: the examination manual clause has already been re-versioned, but retrieval still returns the old-version basis. Cause: the version is not synchronized, and the old-version data row is still in the completed indexing state.
- Symptom: the basis entry lacks a signature or receipt, and the original text cannot be pointed to when replying to parents. Cause: the signature field of the record sheet or fact record has not been completed, and it still exists as a visible data row after parsing.
How to verify the setup
This feature's acceptance: upload one set of materials and observe the status transitions of data rows and the coverage scope of the rebuild task; confirm that after parsing is completed it is immediately persisted as visible data rows, the status transitions from parsed to indexing to indexed, changing the model only rebuilds data that has completed indexing, and data pending indexing does not participate in rebuilding.
Business test: ask a basis question that spans materials and see whether the answer gives a source that can be pointed back to; check and record the tokens of the quoted text and the number of array items separately. quoteMaxToken is the budget for quoted content and is not compared for equality with the number of array items.
- Open the data row to check the status and confirm it is in one of parsed / indexing / indexed and consistent with what the interface displays; data from failed training can be directly edited or deleted.
- Check the file record and the data row separately, confirm that the identities of the file record and the data row are distinguishable, and see whether the data rows covered by the rebuild task include only data that has completed indexing.