What this category's data looks like
In the kindergarten home-school co-education communication scenario, materials come from four categories: teacher commitment items and response times, child performance descriptions, parent request classifications, and notification delivery records. After these materials enter the knowledge base, vector models and indexing provide retrieval support: commitment items and response times are used to check whether a response was given, child performance descriptions are used to compare observation records, parent request classifications are used to determine feedback categorization, and notification delivery is used to confirm arrival status. Data versions and change maintenance require that the current version be unique, old versions be traceable, and references be synchronized; therefore, each material is organized by version number and change records, and the update cadence follows the kindergarten's communication milestones and parent feedback cycles. In terms of field characteristics, each material records the version number, effective time, change description, and reference location, while the indexing side retains the correspondence between vector identifiers and the original data for subsequent retrieval and reference trimming.
Configuration and implementation checks
This part is executed by the indexing service and vector database, outputting vectors and indexing status (whether retrieval is possible and whether data in the same group is merged). The "version ledger and change records" are then completed by subsequent AI nodes, code nodes, or manual work (retrieval and reference trimming only take supporting materials). The indexing service and vector database are only responsible for the correspondence and merging of vectors and original data, and do not generate glossaries, comparison drafts, or version ledgers.
| Object | Check | Verification action |
|---|---|---|
| Commitment items and response time materials | Whether the commitment was responded to within the agreed time, and whether the response content corresponds to the commitment item | In the knowledge base settings, check that the indexing model is consistent with the vector model actually used by the knowledge base; open a data row and confirm that multiple vector identifiers are present in the index field and the status is indexed |
| Child performance description materials | Whether the description matches the observation record, and whether descriptions of the same child in the same period are consistent | Retrieve descriptions related to that child and see whether data in the same group is merged and whether the score takes the highest value; check whether limit are set according to the reference text budget |
| Parent request classification materials | Whether feedback is categorized, and whether the classification label matches the request content | Open the data row and check the index field to confirm that multiple vector identifiers for one data item are complete; check the data range covered by the rebuild task record to confirm that after changing the model, only data that has already been indexed is triggered |
| Notification delivery materials | Whether the notification was delivered, and whether the delivery status is synchronized with the version number | Change one place in the notification content and see whether the version number is updated and whether the reference location is synchronized; record the tokens of the reference text, record the number of array entries separately, and do not compare it for equality with the reference upper limit |
Three common errors
- Symptom: commitment items have been recorded but parent feedback has not been categorized, so the corresponding response cannot be retrieved during retrieval. Inspect the following: commitments and response times are not bound by version number, the old version is still referenced, and the current version is not unique.
- Symptom: child performance descriptions do not match observation records, and duplicate entries appear in retrieval results. Inspect the following: data in the same group is not merged, multiple vector identifiers are scattered, and the score does not take the highest value.
- Symptom: parent request classification is missing, and notification delivery status is inconsistent with the version number. Inspect the following: change records are not updated synchronously, references still point to old-version materials.
How to verify the setup
Acceptance for this feature: take one data row and look at the index field to confirm that multiple vector identifiers are present and the status is indexed; then retrieve once and see whether data in the same group is merged and whether the score takes the highest value.
Business test: change one place in the content and see whether the version number and references are updated synchronously; record the tokens of the reference text, record the number of array entries separately, and do not compare it for equality with the reference upper limit.
- In the knowledge base settings, check that the indexing model is consistent with the vector model actually used by the knowledge base, and open a data row to check whether the index field is complete.
- Check the data range covered by the rebuild task record to confirm that after changing the model, only data that has already been indexed is triggered; check whether
limitare set according to the reference text budget.