What this category's data looks like
Materials in the laboratory hazardous chemicals procurement and ledger category include procurement application forms, usage registration forms, inventory ledgers, supplier receipts, and safety data sheets. Procurement application forms record the product name, specification, quantity, application date, and approval signature; usage registration forms record the user, usage date, purpose, and issuance signature; inventory ledgers record inbound, outbound, and balance quantities and inventory count dates. Materials are updated by batch and by month, and the same batch of reagents may appear in the application, usage, and ledger with inconsistent name abbreviations, quantity calibers, and date order. After entering the document parsing and chunking function, procurement application forms and usage registration forms serve as the source of business basis, inventory ledgers serve to verify quantities and balances, and receipts and data sheets serve as evidence of versions and signatures; each is parsed into data rows and bound to a unique data identifier for subsequent retrieval and answer citation.
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 retrieval and subsequent processing then complete the basis entries that can be traced back to the original text. After parsing is completed, parsed chunks are immediately persisted as visible data rows, the index transitions through three states, and data pending indexing does not participate in recall.
| Object | Check | Verification action |
|---|---|---|
| Procurement application form | Whether the product name, specification, quantity, application date, and approval signature on the application form can be matched item by item with the usage registration form and inventory ledger | Check the name abbreviations, quantity calibers, and date order between the application form and the ledger, and check whether approval signatures and receipts are complete; confirm that the data row status is parsed, indexing, or indexed |
| Usage registration form | Whether the user, usage date, purpose, and issuance signature in the usage record can be matched with the outbound record in the inventory ledger | Compare the usage quantity with the outbound quantity in the ledger, check the issuance signature; check whether the data row status is consistent with the interface display |
| Inventory ledger | Whether the inbound, outbound, and balance quantities and inventory count dates can form a continuous chain with the application form and usage registration form | Check the balance quantity and inventory count date, and check entries missing signatures or receipts; confirm that the rebuild task covers only indexed data rows |
| Parsing and training task (server-side task) | The three-state transition of data rows is consistent with the interface display, and the rebuild scope covers only data whose indexing has been completed | Check the file records and data row identifiers separately, view progress by trainingType category, and confirm that the chunking results corresponding to chunkSize and chunkSplitter fall within the same data row |
Three common errors
- Symptom: The names and quantities of the same batch of reagents do not match between the application form and the ledger. Cause: Name abbreviations and quantity calibers are not unified, and after parsing and chunking, the data rows each say something different.
- Symptom: Basis entries cannot be retrieved immediately after materials are uploaded. Cause: The data rows are in a pending-indexing state, and they do not participate in recall before indexing is completed.
- Symptom: After changing models, the rebuild takes abnormally long or training fails and leaves empty data rows. Cause: The rebuild scope is not limited to data whose indexing has been completed, and data pending indexing is pulled into the rebuild chain.
How to verify the setup
This function's acceptance check: upload one material, observe the data row status transition and the coverage scope of the rebuild task, and confirm that the status advances among parsed, indexing, and indexed, and that the rebuild covers only indexed data rows.
Business test: ask a basis question that spans materials, and see whether the answer provides a traceable source, such as whether the names, quantities, and dates in the application form and ledger match the original text.
- Open the data rows to check the status, confirm that it is consistent with the interface display, and check the identifiers of the file records and data rows separately.
- Check the data rows covered by the rebuild task, and confirm that it targets only data whose indexing has been completed, and that data pending indexing does not participate in the rebuild.