How to Systematically Fix Bad Cases in Large Language Models

Definition of Bad Cases

A bad case for a large language model is any response that deviates from the expected behavior in a specific application scenario. Bad cases can manifest as hallucinations, repetitive outputs, unsafe answers, or mismatched retrieval results, and they arise from diverse causes throughout the model lifecycle.

General Repair Workflow

The remediation process follows four systematic steps:

Discover the problem : Collect failure samples through manual testing (human evaluation, annotation, user feedback) and automated testing (simulators, fixed test suites, continuous integration).

Summarize patterns : Group the samples, label recurring patterns (e.g., hallucination, repetition, unsafe content), and define actionable standards for annotation teams.

Evaluate impact : Compute a priority score as impact = probability × severity, where probability is the observed frequency of the pattern and severity reflects business or safety risk.

Repair : Apply either root‑cause elimination (model‑level changes) or symptom masking (post‑generation safeguards) based on the impact assessment.

Mechanistic (Training‑Stage) Fixes

The model training pipeline consists of four stages. Interventions at each stage target different categories of bad cases.

Pre‑training : Issues such as pervasive repetition often require a new base model (e.g., upgrading from GPT‑3.5 to GPT‑4). This is the most costly but raises the overall capability ceiling.

Supervised Fine‑Tuning (SFT) and Alignment : Inject targeted examples that demonstrate the correct behavior. For alignment, construct positive examples for the reward model and negative examples for identified bad cases, then fine‑tune with algorithms such as PPO or DPO. This “patch” approach can quickly reduce specific failure modes.

Inference‑Stage Fixes

During deployment, two complementary techniques can mitigate residual problems without retraining.

Generation‑parameter tuning : Adjust sampling hyper‑parameters to control output diversity and repetition. Typical knobs include: temperature (e.g., 0.7 → 0.5 to reduce randomness) top_p (nucleus sampling cutoff) repetition_penalty (e.g., 1.2 to penalize repeated n‑grams)

These settings can alleviate echoing or “repeater” behavior.

Prompt engineering : Use Retrieval‑Augmented Generation (RAG) to inject up‑to‑date external knowledge, thereby reducing hallucinations. Apply chain‑of‑thought (CoT) prompting or tool‑use agents to guide the model through structured reasoning and external API calls.

Pre‑ and Post‑Processing Safeguards

Runtime filters add an extra safety layer.

Pre‑processing : Analyze incoming user prompts, assign a risk score, and optionally reject or rewrite the prompt via a system instruction.

Post‑processing : Scan model outputs for policy violations or unsafe content. If a violation is detected, replace the response with a predefined safe fallback. Note that streaming generation may introduce latency for such checks.

Key Takeaways

Quick fixes—parameter tweaks, prompt adjustments, and post‑processing filters—are effective for isolated symptoms but do not address the underlying model deficiencies. Comprehensive improvement requires targeted data augmentation, alignment fine‑tuning, or even a new base model, each of which entails higher computational cost and engineering effort.