Error Taxonomies

An error taxonomy turns failures into structured evidence. Instead of reporting that “the assistant was wrong,” reviewers label what failed, why it likely failed, who was affected, and how severe the outcome was. That makes factual correctness, hallucinations, fairness, and adversarial evaluation comparable across releases.

Symptom, cause, consequence

A useful taxonomy separates symptom, cause, and consequence:

error_id: E03
symptom: wrong_entity
likely_cause: retrieval
severity: 5
affected_group: enterprise_customer
control_gap: citation_resolution
owner: retrieval
regression_test: rag_wrong_entity_017
status: open

The label wrong_answer is too broad to drive action. wrong_entity points toward retrieval or entity linking; unsupported_claim points toward generation and citation checks; pii_leak points toward privacy, access control, and policy enforcement. The taxonomy should be stable enough for trending but flexible enough to add new classes when an incident exposes a missing category.

Worked aggregation

A six-failure review inventory can be aggregated directly:

errorsymptomlikely causeseverity
E01unsupported_claimgeneration4
E02retrieval_missretrieval3
E03wrong_entityretrieval5
E04pii_leakpolicy5
E05unsafe_tool_callagent5
E06format_violationinterface1

The total severity is . The important output is not the count of six; it is the split by cause. Retrieval owns two failures, while policy and agent controls own separate high-severity failures. That distinction is what lets governance of model and knowledge base changes assign the next fix to the right owner.

Caveats

Taxonomies drift when reviewers improvise labels. Keep a short label dictionary, require examples for new classes, and periodically measure inter-reviewer agreement. For generative systems, store representative examples because a label without the prompt, retrieved context, output, and expected behavior is hard to audit.

References