Document Parsing and Chunking for Student Awards, Financial Aid and Hardship Assessment: Find Supporting Evidence

Student Financial Aid: review parsing for evidence lookup. Check source versions, input mappings and the values received by downstream nodes.

What this category's data looks like

The materials in the student awards, grants, loans, and hardship determination scenario are mainly of three types: family economic hardship determination forms, scholarship and grant application forms, and loan receipts. They come from student submissions at this institution and preliminary review archiving by departments, are centrally updated once each academic year, and are appended during the semester due to supplementary entries, changes in family circumstances, or loan batches arriving. When the three types of materials enter the document parsing and chunking function, their roles differ: the determination form carries fields such as family population, income, and hardship level, and is the backbone of the determination basis; the application form carries application intent, award records, and signature fields, and is used to verify eligibility and the approval chain; the loan receipt carries the disbursement amount, arrival date, and receipt number, and is used to verify the loan facts. Field characteristics are concentrated in name, student ID, amount, date, and signature fields. Date formats, amount units, and name spellings often differ across materials, and missing signatures and receipt items are also relatively common. After chunking, location information that can point back to the original text must be retained to facilitate item-by-item comparison.

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). "Basis entries that can point back to the original text" are completed next by retrieval and subsequent processing. After parsing is completed, parsing and chunking are immediately persisted 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 whose indexing has been completed.

ObjectCheckVerification action
Family economic hardship determination formName, student ID, family population, income, hardship level, signature, and date must be consistent with the original text, and the version must be the current effective oneOpen the data row, check whether the status is parsed, indexing, or indexed, and point back to the original text to compare the fields
Scholarship and grant application formApplication level, award records, signature field, and date must match the original text, and the name and quantity of the same record must not conflict with other materialsSeparately check the identifiers of the file record and the data row, and check whether entries are complete after splitting by chunkSize and chunkSplitter
Loan receiptDisbursement amount, arrival date, receipt number, and missing signature or receipt items must be consistent with the original text; entries whose versions are not synchronized must not be used as a basisCheck the data rows covered by the rebuild task, confirm that only indexed data is covered, and that trainingType corresponds to the processing mode
Data row statusIt is in one of the three states and is consistent with the interface display; data pending indexing does not participate in recallOpen the data row to check the status, confirm that data being indexed is not recalled, and that data with failed training can be edited or deleted

Three common errors

  • Symptom: The name spelling or family population count for the same student does not match between the determination form and the application form. Cause: The two materials are entered separately, lacking cross-material field comparison and a unified standard.
  • Symptom: The amount or arrival date on the loan receipt is inconsistent with the record in the application form, and the entries cannot corroborate each other. Cause: The versions are not synchronized, and the old receipt remains in recallable data.
  • Symptom: The application form lacks a signature or the loan receipt lacks a receipt number, yet the basis entry is still cited. Cause: After chunking, the original-text locations of the signature field and receipt fields are not retained, and missing items are not identified.

How to verify the setup

This function's acceptance: upload one material, observe the data row status transitions and the coverage scope of the rebuild task, confirm that parsing and chunking are immediately persisted after parsing is completed and bound to a unique data identifier, that the status transitions through parsed, indexing, and indexed, and that changing the model only rebuilds data whose indexing has been completed.

Business test: ask a cross-material basis question, see whether the answer provides a citable source that can point back, and check that the citation count and citation content budget are recorded separately; for the citation upper limit, look at the tokens of the cited text.

  • Open the data row to check whether the status is consistent with the interface display, confirm that data pending indexing does not participate in recall, and that data with failed training can be directly edited or deleted.
  • Separately check the identifiers of the file record and the data row, check whether chunkSize, chunkSplitter, and trainingType correspond to the actual processing mode, and confirm that the rebuild task only covers data whose indexing has been completed.