What this category's data looks like
The category materials for enterprise independent skilled talent evaluation typically include three types: enterprise evaluation filing forms, evaluation specifications, and candidate rosters. The sources are the enterprise human resources department and the vocational skill appraisal institution, and the update rhythm rolls with filing batches, evaluation specification versions, and candidate registration cycles. The filing form carries institution information, evaluation occupation and level, and signatures and seals; the evaluation specification carries the assessment plan, scoring rules, and terminology definitions; the roster carries candidate identity, applied occupation level, and unit information. When the three types of materials enter the document parsing and chunking function, their roles differ: the filing form and evaluation specification serve as terminology sources and specification bases, while the roster serves as a record carrier. After chunking, each becomes an independent data row for subsequent retrieval and terminology comparison.
Configuration and implementation checks
This step is executed by the parsing and training task (server-side task), 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, and the index transitions through three states.
| Object | Check | Verification action |
|---|---|---|
| Enterprise evaluation filing form | The institution name, evaluation occupation, level, and signature and seal fields in the material must correspond item by item with the evaluation specification and roster, and dates and receipts must not be missing | Separately check the file record and the data row, confirm that the filing form data row status is parsed and then enters indexing, open the data row to check the signature and date fields |
| Evaluation specification | The terminology definitions and scoring rules in the specification must be consistent with the occupation level in the filing form, and the same term must be written consistently throughout | Use chunkSize and chunkSplitter to control chunking, check whether the writing of terms is consistent across the specification's chunks, and confirm that the translated name can refer back to the original text |
| Candidate roster | The candidate names, applied occupation levels, units, and quantities in the roster must correspond with the filing form and evaluation specification, and dates and versions must be synchronized | Check the status transitions of the roster data rows, confirm that when trainingType is Vector or QA the data row status is consistent with the interface display, and sample three terms to check their writing throughout |
| Data rows and file records | The identities of file records and data rows are distinguishable, and data rows are in one of the three states and consistent with the interface display | Separately check file records and data rows, and inspect whether the data rows covered by the rebuild task contain only the indexed status |
Three common errors
- Symptom: The same candidate's name, applied occupation level, or quantity does not match across two materials. Cause: The versions of the filing form and roster are not synchronized, and after chunking they are persisted separately, lacking cross-material field comparison.
- Symptom: Dates, signatures, or receipts are missing from the evaluation specification and filing form. Cause: The scanned material has missing pages or the signature field is unfilled, and after parsing the data row is still in a visible state and is not intercepted.
- Symptom: Newly uploaded materials cannot be found. Cause: The data row is in parsed or indexing, and data pending indexing does not participate in recall, so it is necessary to wait for the status to become indexed.
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, confirm that the three states parsed to indexing to indexed are consistent with the interface display, and that rebuild covers only indexed data.
Business test: Sample three terms to check whether their writing is consistent throughout, and confirm that the translated name can refer back to the original text.
- Open the data row to check the status, confirm that the data row is in one of the three states and consistent with the interface display, and separately check the file record and the data row.
- Inspect the data rows covered by the rebuild task, confirm that they contain only the indexed status, and that after changing models the rebuild scope does not include data pending indexing.