What this category's data looks like
Undergraduate program revision involves three types of materials: program plans, course syllabi, and credit structure tables. Sources are academic affairs system exports, departmental submissions, and meeting minutes attachments. The update cadence follows revision batches. Fields include course name, credit count, effective date, and signature field. The program plan is the master record, course syllabi support course-level content, and the credit structure table verifies credit distribution. When these three types of materials enter knowledge base retrieval and recall, each serves as a candidate chunk source, recalled by the retrieval node according to the mode and merged and reranked for subsequent nodes or manual comparison of fields and dates.
Configuration and implementation checks
This step is executed by the knowledge base retrieval service (retrieval node and search test), outputting candidate chunks and similarity scores (after mode, merge, rerank, filter, and limit truncation). The version ledger and change records are completed by subsequent nodes or manually.
| Object | Check | Verification action |
|---|---|---|
| Program plan | Fields include course name, credit count, effective date, and signature field; must be aligned item by item with course syllabi and credit structure table | In the search test, search by course name and effective date, record the number of candidates and scores, and check whether name, count, and date are consistent |
| Course syllabus | Course name and credit count must match the corresponding record in the program plan; signature or receipt is indispensable | Switch searchMode to semantic, full-text, or hybrid and search once each, comparing whether candidate chunks cover the same course record |
| Credit structure table | Credit count and date must match the program plan; if versions are not synchronized, values will not match | Compare the top few rankings before and after enabling usingReRank, record similarity scores and the number of candidates after limit truncation |
| Version ledger and change records | The current version is unique, old versions are traceable, references are synchronized; missing signature or receipt is considered incomplete | After changing one piece of content, re-search and check whether the version number and reference text are synchronized and updated, and separately record the number of items in the reference array |
Three common errors
- Symptom: The name, count, and date of the same course do not match across two materials. Cause: Versions are not synchronized or field entry is inconsistent, and retrieval candidates do not cover the same record.
- Symptom: Old program plans are still recalled, and current and old versions are mixed in the candidates. Cause: Change records are not updated, reference synchronization lags, and candidates are not filtered by version.
- Symptom: Materials lack signatures or receipts, and revision records are incomplete. Cause: Omissions in the submission step, knowledge base chunks do not include the signature field, and effectiveness cannot be confirmed during verification.
How to verify the setup
Acceptance for this feature: Test once each with synonym-rewritten questions, compare candidates and scores, then toggle rerank on and off to observe the top few rankings.
Business test: Change one piece of content and see whether the version number and references are synchronized and updated.
- In the search test, switch
searchModeamong semantic, full-text, and hybrid modes, and record the number of candidates andsimilarityscores. - Enable and disable
usingReRankto compare the top few rankings, and check the tokens and array item count of the reference text afterlimittruncation.