What this category's data looks like
This page addresses the kindergarten health care and meal management scenario. Materials come from three parties: the health room, the cafeteria, and the classes: morning check and absence cause registration, quantified recipes, food ingredient procurement and acceptance sheets, retention sample records, and disinfection time schedules. These materials are updated daily or weekly, and the fields mainly consist of ingredient names and specifications, retention sample times and batches, disinfection time periods, and absence cause classification. Naming conventions, units of measurement, and date formats often differ across sources. When entering this feature, each material is first stored as an independent file record, then split into data rows, each of which takes on a searchable and verifiable role; whether the name, quantity, and date of the same object are consistent across two materials is carried by the data rows and awaits subsequent retrieval and comparison. The materials themselves do not directly produce a discrepancy list.
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). The "discrepancy list" is then completed by retrieval and subsequent processing. After parsing is complete, parsing and chunking are immediately stored as visible data rows and bound to a unique data identifier. The index transitions through three states. Data pending indexing does not participate in recall. Changing the model only rebuilds data that has completed indexing.
| Object | Check | Verification action |
|---|---|---|
| Retention sample records | Retention sample time and batch are consistent with the acceptance document | Verify the file record and the data row separately, compare the retention sample batch with the acceptance sheet batch, and confirm that the data row status is one of parsed / indexing / indexed |
| Quantified recipes | Ingredient names and specifications are consistent with the procurement category | Verify the ingredient names and specifications in the recipe and the procurement sheet, check whether data row chunking splits the same ingredient into multiple rows, and record the discrepancy fields |
| Disinfection records | Disinfection time periods cover all required periods of the day | Verify the disinfection records period by period, identify the data rows corresponding to missing periods, and confirm that their index status matches the interface display |
| Training task | The rebuild scope covers only data that has completed indexing | Inspect the data rows covered by the rebuild task, and verify chunkSize, chunkSplitter, trainingType, and the data row status |
Three common errors
- Symptom: the document and the retention sample batch do not match. Cause: retention sample records and acceptance sheets are filled in by different roles, and the batch number or retention sample time is written inconsistently. After chunking, they fall into different data rows, and the mismatch is only exposed during retrieval and comparison.
- Symptom: the recipe and the procurement category are inconsistent. Cause: recipes are compiled weekly while procurement orders are placed daily, and ingredient names and specifications are written differently in the two types of materials. The data rows are not normalized, so discrepancy localization requires checking item by item.
- Symptom: disinfection records are missing time periods. Cause: the disinfection time schedule is registered by shift, and individual periods are omitted or merged. After parsing, there is no corresponding data row for that period, which appears as incomplete records during retrieval.
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 data row status is parsed / indexing / indexed and consistent with the interface display, and that the rebuild covers only data that has completed indexing.
Business test: use one real record to find a field inconsistent with the ledger, such as retention sample batch, ingredient specification, or disinfection time period, and hand it to the reviewer for confirmation and write-back.
- Open the data row to verify the status, confirm that it is in one of the three states and consistent with the interface display, and that data pending indexing does not participate in recall.
- Verify the file record and the data row separately, and check whether the data rows covered by the rebuild task contain only data that has completed indexing.