Error Analysis for LLM Applications

When an LLM application fails, the visible answer may be only one part of the cause. A wrong response can stem from an unclear prompt, poor retrieval, stale data, a tool-call error, model behavior, or a mismatch between the product goal and the evaluation. Error analysis makes failures concrete by reviewing traces and assigning categories. Start with a defined outcome and collect a sample of successes and failures from representative workflows. Label errors with a consistent taxonomy—such as factual error, missing constraint, refusal, retrieval miss, invalid tool call, formatting failure, or unsafe action. Record severity, task type, model and prompt version, and whether a human had to intervene. Use examples and annotation guidance so reviewers apply labels consistently. Counts can show common failures, while severity and user impact reveal which issues deserve attention first. Stratify the sample where needed so rare but costly cases are not drowned out by frequent low-impact issues. A random production sample can reveal broad patterns; targeted samples can investigate a particular failure, but their rates should not be presented as population prevalence. OpenAI’s evaluation guidance recommends examining traces and using structured graders to find failure modes; its evaluation flywheel example discusses reading failing traces and applying labels. After a fix, rerun the same cases and a holdout set to check for regressions. Error analysis guides work, but it does not prove causality unless the proposed fix is tested.