What this category's data looks like
This category's data involves study abroad service contracts, school application forms, personal statements, and other materials, with scattered sources and frequent updates, and fields including name, quantity, date, and signature. After contracts and application forms enter parsing and training tasks, they are first persisted as visible data rows, while personal statements and receipts participate in the same version chain as supplementary materials. If the name, quantity, or date of the same record do not match across two materials, or if versions are not synchronized, or signatures and receipts are missing, the materials cannot be matched at the retrieval layer. Materials are updated according to application rounds and deadline nodes; old versions must be traceable, the current version must be unique, and references must be synchronized.
Configuration and implementation checks
This step is executed by parsing and training tasks (server-side tasks), outputting data rows and index statuses (parsed, indexing, indexed). "Version ledger and change records" are then completed by retrieval and subsequent processing.
| Object | Check | Verification action |
|---|---|---|
| Study abroad service contract | Name, quantity, date, and signature are consistent between the contract and the application form | Check the contract and application form fields, confirm that signatures and receipts are complete, and view whether the data row status is parsed, indexing, or indexed |
| School application form | The name, quantity, and date of the same record match the personal statement | Compare the dates and names in the application form and personal statement, and check whether the data rows are persisted after parsing and chunking by chunkSize and chunkSplitter |
| Personal statement | The version number and references are synchronized, and the old version is traceable | After changing one piece of content, check whether the version number and references are synchronized, and verify the training mode and index status corresponding to trainingType |
| Version ledger and change records | The current version is unique, the old version is traceable, and references are synchronized | Open the data row to check whether the status is consistent with the interface display, and confirm that the rebuild task only covers data rows whose indexing has been completed |
Three common errors
- Symptom: newly uploaded materials cannot be found. Cause: the data row is in a pending-index status, and the retrieval layer is naturally isolated and does not recall it; successful parsing does not equal a retrieval hit.
- Symptom: empty data rows remain after training fails. Cause: interrupted training leaves orphan data, failed data is not edited or deleted in time, and gaps appear in the version ledger.
- Symptom: rebuild takes abnormally long after switching models. Cause: the rebuild scope is not limited to data whose indexing has been completed; pending-index data is pulled into the rebuild chain, and references and versions are not synchronized.
How to verify the setup
This feature's acceptance: upload one material, observe the data row status transitions and the coverage scope of the rebuild task, confirm that the status transitions among parsed, indexing, and indexed, and that the rebuild only covers data rows whose indexing has been completed.
Business test: change one piece of content, observe whether the version number and references are updated synchronously, and confirm that the current version is unique, the old version is traceable, and references are synchronized.
- Open the data row to check the status, confirm it is consistent with the interface display, and separately verify the identifiers of the file record and the data row.
- View the data rows covered by the rebuild task, confirm that only data whose indexing has been completed is covered, and verify that the tokens and array count of the reference text are recorded separately.