HALLUCINATIONS.lecture Hallucinations

Before understanding hallucinations, we must understand how LLMs produce code token by token. The autoregressive generation process — where each token conditions on all previous tokens — is the root cause of many hallucination patterns. The model: (1) receives the prompt as input tokens, (2) computes a probability distribution over its vocabulary for the next token, (3) samples a token using temperature, top-k, or top-p, (4) appends and repeats.

Tian et al. (AAAI 2025) propose a systematic taxonomy of code hallucinations based on execution-based verification, dividing them into four categories. Understanding this taxonomy enables precise classification and targeted mitigation.

API hallucinations — where the model generates calls to methods, classes, or modules that do not exist in the target library — are the most common form of code hallucination. Parameter hallucinations, where the model calls a real method but with non-existent or incorrect arguments, are subtler but equally dangerous.

Practice identifying hallucinations by examining real code examples. The key is recognizing that hallucinations often look plausible — they follow naming conventions and patterns you would expect in real APIs.

Hallucinations are not random errors — they emerge systematically from how transformers learn and generate code.

No single detection method catches all hallucinations. Effective detection requires multiple complementary strategies layered into a comprehensive pipeline.

Retrieval-Augmented Generation (RAG) is a foundational technique for reducing hallucinations. Instead of relying on the model's parametric memory alone, RAG retrieves relevant documentation at query time to ground the generation in factual data.

Eghbali & Pradel (2024) introduce De-Hallucinator, an iterative grounding approach that retrieves relevant API documentation to reduce hallucinations. Unlike single-pass RAG, De-Hallucinator iterates — extracting APIs from generated code, retrieving documentation for those specific APIs, and re-querying the model with verified documentation.

Careful prompt design is one of the simplest and most effective ways to reduce hallucinations. These techniques require no infrastructure changes — just better prompts.

Tool-augmented generation gives LLMs access to external tools that verify code in real time, dramatically reducing hallucinations by providing ground truth feedback during the generation process.

Code hallucinations are not hypothetical — they have all happened in production. Every case shows why code outputs from LLMs must be treated as untrusted input requiring verification.

A practical framework you can apply to production systems and course projects. This workflow layers multiple mitigation strategies for increasing levels of protection.

Quantifying code hallucinations requires specialized benchmarks and metrics. The CodeHaluEval benchmark provides a rigorous framework.

Code hallucinations are a critical challenge in AI-assisted software development. Understanding their mechanisms, taxonomies, and mitigation strategies is essential for safely deploying LLM-generated code in production systems.