Skip to content
NTPU AI Learn

IL 201 · Module 4

Testing and Failure Analysis

Test on the acceptance set with development kept separate from acceptance, break down errors and rework by category, and write a failure log.

Start Section 1
  • Duration240 min
  • LevelAdvanced
  • PrerequisiteComplete Module 3 (Prototype Build), with a reproducible run log in hand
0 / 3 completed

Learning objectives

  • Run the acceptance test and confirm development and acceptance judging stayed genuinely separate.
  • Find the classification error in a draft failure-log summary and write a corrected version.
  • Identify high-risk errors that must not be hidden behind an overall average, and disclose insufficient sample sizes.

Acceptance testing and failure analysis

80 min

Keeping development and acceptance separate

Before formal testing begins, confirm the Module 2 dev/acceptance split has not been broken: the prototype version must be frozen before any acceptance-set case is looked at.

  1. Step 1
    Freeze the prototype version and record the run_id at the moment of freezing; this version must not be tuned based on acceptance results afterward.
  2. Step 2
    Run the frozen version against every acceptance-set case, recording the full Module 3 run-log fields.
  3. Step 3
    Any change to the prototype counts as a new version; it must go through freezing and acceptance again from scratch: the old version's acceptance score cannot be carried forward.

Warning

Common mistake: partway through acceptance testing, noticing a category performing poorly and "quickly patching" the prompt before finishing the run on the same acceptance set. The resulting score is now contaminated by acceptance data and cannot represent a genuine acceptance result.

Key takeaway: Version freezing is the precondition for a trustworthy acceptance test; any change to the prototype after freezing must be treated as a new version and re-accepted.

80 min

Exercise: find the error in a failure log

Below is a first draft (v1) of a failure-log summary. Try to spot at least one problem yourself before reading the corrected version (v2) and the correction notes. This is the course's required "fully-worked example with a deliberate error and correction notes."

Failure log summary v1 (a flawed draft)

Overall accuracy: 92% (37/40 cases correct) Conclusion: performing well, recommend proceeding to the next stage.

Failure log summary v2 (corrected, broken down by category)

Normal cases (24)
Accuracy 96% (23/24), no critical errors.
Missing-information cases (8)
Accuracy 88% (7/8); 1 case wrongly treated an unanswerable question as answerable and gave a guessed answer (critical error).
Conflicting-sources cases (4)
Accuracy 75% (3/4); 1 case failed to detect a document conflict and cited the older version directly (critical error).
No-answer cases (4)
Sample size too small (4 cases); this result is informational only and not sufficient for a conclusion: retest with a larger sample.
Critical errors overall
2 critical errors (1 missing-information, 1 conflicting-sources), 5% of all cases, but both are the "AI confidently states a wrong answer" type: higher risk than ordinary errors, and must not be ignored even at 92% overall accuracy.

Warning

Correction notes: v1 gives only a single overall accuracy of 92%, blending high-risk "AI confidently states a wrong answer" critical errors together with minor errors into one average, with no breakdown by case category and no disclosure that the "no answer" category has too few samples. v2 reports by category, explicitly flags critical errors and their risk profile, and honestly discloses the under-sampled category: this is the failure analysis IL 201 requires.

Key takeaway: A 92% overall accuracy can hide two critical 'AI confidently states a wrong answer' errors; an analysis with no category breakdown and no flagged critical errors cannot let a sponsor make the right call.

80 min

Write your own failure log

Minimum failure-log fields (reusing SYN-CS-001's failure_log.csv format)
FieldDescription
case_idThe matching acceptance-set case id
case_categoryThe case category
is_critical_errorWhether this is a critical error (e.g. confidently wrong information, a permission violation)
error_descriptionA specific description of the error, not a vague phrase like "not quite accurate"
rework_neededHow much manual correction was needed (none / minor / major rework)

Info

SYN-CS-001's failure_log.csv and experiment_results.csv provide synthetic examples you can use as a format and level-of-detail reference before writing your own failure log: never copy their conclusions directly into your own project.
  1. Exercise
    For your Module 3 prototype, complete testing and a failure log for at least 10 acceptance-set cases, reporting accuracy per case category and listing every critical error separately.
  2. Self-check
    Confirm your failure log does not hide any critical error inside an overall average, and does not treat an under-sampled category as a settled conclusion.
Check yourself

A failure-log summary states only "92% overall accuracy, recommend proceeding to the next stage." What is the main problem with this?

A failure-log summary states only "92% overall accuracy, recommend proceeding to the next stage." What is the main problem with this?

Key takeaway: A failure log's value is not a good-looking overall score; it is an honest account of where errors happen, how severe they are, and how much evidence backs that conclusion.

Save as PDF

What next?