🤖 AI

Empirical Analysis and Detection of Hallucinations in LLM-Generated Bug Report Summaries

This paper addresses the critical issue of hallucinations in LLM-generated bug report summaries by introducing a section-aware detection framework and a synthetic benchmark derived from the BugsRepo dataset, achieving strong performance in identifying, locating, and classifying hallucinated content to improve the reliability of automated software maintenance tools.

Original authors: Hinduja Nirujan, Shreyas Patil, Abdallah Ayoub, Ahmad Abdel Latif, Gouri Ginde

Published 2026-05-26

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Hinduja Nirujan, Shreyas Patil, Abdallah Ayoub, Ahmad Abdel Latif, Gouri Ginde

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you have a very smart, but occasionally daydreaming, assistant named "LLM" (Large Language Model). Your job is to have this assistant read messy, technical bug reports from software developers and rewrite them into neat, three-part summaries: How to make the bug happen, What actually goes wrong, and What should happen instead.

The problem is that this assistant sometimes "hallucinates." It doesn't just forget a detail; it confidently invents facts that weren't in the original report, like a storyteller who makes up a character's backstory that never happened. If a developer trusts this made-up story, they might waste hours looking for a problem that doesn't exist.

This paper is like a quality control inspection for that assistant. Here is what the researchers did, explained simply:

1. The "Daydream" Discovery

First, the researchers played a game of "spot the lie." They took 80 bug reports, asked the AI to summarize them, and then had humans check the results.

The Result: They found that nearly half of the summaries were missing key information, and about 12% contained completely made-up details.
The Analogy: It's like asking a tour guide to describe a museum, and they confidently tell you about a dinosaur exhibit that doesn't exist, while skipping the famous painting you actually wanted to see.

2. Why Does the AI Get Lost? (The "Spotlight" Test)

The researchers wanted to know why the AI makes these mistakes. They looked at how the AI's "brain" (a transformer model) pays attention to different parts of the text.

The Finding: The AI puts a bright "spotlight" on the Expected Behavior (what should happen) and a dimmer light on the Steps to Reproduce (how to make the bug happen).
The Analogy: Imagine a student taking notes in class. They are very focused on the teacher's conclusion (the "Expected Behavior") but are zoning out during the step-by-step instructions. Because they aren't paying attention to the steps, they are more likely to make up the steps later. The researchers found that the sections the AI ignores the most are the ones where it lies the most.

3. Building a "Fake News" Training Camp

Since there wasn't a big list of "AI lies" to study, the researchers had to build their own.

The Process: They took real bug reports and used a computer program to deliberately inject lies into them. They created three types of lies:
1. Addition: Inventing a step that wasn't there.
2. Removal: Deleting a crucial step.
3. Reordering: Mixing up the sequence of events.
The Filter: Before using these "fake" reports to train a detector, they had to make sure the AI didn't accidentally mess up the real ones while converting them. They used a special scoring system (called PARENT) to act like a strict editor, throwing out any summaries that didn't stick closely enough to the original facts.

4. The "Super-Detective" Model

Instead of just asking the AI, "Is this summary true or false?" (a simple Yes/No question), the researchers built a smarter "Super-Detective."

How it Works: This detective is trained to do three things at once:
1. Alert: "Hey, this summary has a lie!"
2. Locate: "The lie is in the 'Steps to Reproduce' section."
3. Identify: "The lie is an 'invention' (addition) or a 'missing piece' (removal)."
The Result: They tested this detective on several different AI models. The best one (a mid-sized model called Ministral-3B) was incredibly good at its job. It could spot the lies, find exactly where they were, and classify the type of lie with about 89% accuracy.

5. Where the Detective Still Struggles

Even the best detective has blind spots. The researchers found that the hardest lies to catch were Removals (when the AI deletes information).

The Analogy: It's easy to catch someone adding a fake ingredient to a recipe. It's much harder to catch them leaving out a crucial ingredient because the dish still looks like a dish, just a slightly different one. The AI often missed when the original report's details were simply gone.

The Bottom Line

This paper proves that we can't just trust AI summaries blindly. However, by teaching AI to pay attention to the structure of the document (knowing that "Steps" are different from "Results") and training it to spot specific types of lies, we can build much more reliable tools. The study provides a blueprint for a "lie detector" that doesn't just say "this is wrong," but tells you exactly where and how it went wrong, making software development safer and more efficient.

Technical Summary: Empirical Analysis and Detection of Hallucinations in LLM-Generated Bug Report Summaries

Problem Statement

Large Language Models (LLMs) are increasingly utilized to generate structured summaries of software bug reports, specifically extracting sections such as Steps-to-Reproduce (S2R), Actual Behavior (AB), and Expected Behavior (EB). However, these models frequently produce "hallucinations"—plausible-sounding but factually unsupported content. Existing hallucination detection methods typically evaluate outputs at the full-response level, treating hallucinations as a monolithic error class. This approach fails to account for the structural properties of technical documents, where different sections (e.g., procedural steps vs. declarative behaviors) play distinct semantic roles. Consequently, current methods overlook how hallucination patterns vary across sections and do not provide granular insights into the location or type of factual errors, limiting their utility in critical software engineering (SE) workflows.

Methodology

The authors propose a section-aware hallucination detection framework, validated through a three-phase methodology using the BugsRepo dataset (derived from Mozilla OSS projects).

1. Exploratory Analysis and Attention Modeling

Empirical Observation: An initial study on 80 LLM-generated summaries revealed that ~47.9% contained missing information and 12.3% included fabricated content.
Attention Analysis: The authors analyzed how transformer models (BERT, RoBERTa, SciBERT, DeBERTa, DistilBERT) distribute attention across S2R, AB, and EB sections. They found that Expected Behavior (EB) receives the highest attention, while Steps-to-Reproduce (S2R) receives the lowest, suggesting S2R is more susceptible to hallucination due to under-utilization of procedural information.

2. Synthetic Dataset Construction

Due to the lack of existing benchmarks for section-aware hallucinations, the authors constructed a synthetic dataset:

Structured-to-Unstructured Conversion: Structured bug reports were converted into unstructured narratives using Mistral-7B.
Quality Filtering: A modified PARENT metric (specifically PARENTtable), which prioritizes alignment with the source table over reference text, was used to filter low-quality conversions. This ensured the training data faithfully preserved structured information.
Hallucination Injection: A controlled pipeline injected synthetic hallucinations into specific sections. The hallucinations were categorized into three types: Addition (fabricated content), Removal (missing information), and Reordering (structural changes).

3. Section-Aware Detection Model

The authors proposed a multi-task learning approach built on a pretrained transformer encoder with parameter-efficient fine-tuning (LoRA). The model simultaneously performs three tasks:

Report-Level Detection: Binary classification of whether a summary contains hallucinations.
Section-Level Localization: Identifying which specific section (S2R, AB, or EB) is affected.
Type Classification: Categorizing the hallucination type (Add, Remove, Reorder).

The model is trained using a combined loss function: $L = L_{report} + \lambda_s L_{section} + \lambda_t L_{type}$ .

Key Contributions

Section-Aware Framework: A novel approach that explicitly models the semantic roles of S2R, AB, and EB to jointly detect hallucinations, localize affected sections, and classify error types, moving beyond monolithic detection.
Synthetic Benchmark: The development of a pipeline to convert structured bug reports into unstructured narratives and inject controlled hallucinations, creating a publicly available benchmark for section-level hallucination research.
Empirical Insights: Evidence demonstrating that hallucination sensitivity correlates with attention allocation (e.g., S2R is more vulnerable) and that removal-type hallucinations are significantly harder to detect than additions.

Results

Experiments were conducted on four pretrained models (Mini-LLaMA-1B, Ministral-3B, Mistral-7B, LLaMA-8B) using the constructed synthetic dataset.

Performance: Fine-tuned models significantly outperformed zero-shot, few-shot, and Chain-of-Thought (CoT) prompting baselines.
- The best-performing model, Ministral-3B, achieved a 0.891 Macro-F1 for report-level detection, 0.829 Macro-F1 for section-level localization, and 0.836 Macro-F1 for hallucination type classification.
- Mistral-7B and LLaMA-8B showed comparable performance, while smaller models (Mini-LLaMA) exhibited lower performance, indicating the need for sufficient representational capacity.
Section Localization: The model achieved the highest precision for S2R (F1=0.891) but lower recall for AB and EB. This suggests the model is conservative in flagging AB/EB hallucinations, often missing removal errors in these sections.
Type Classification: The model performed well on Addition (F1=0.976) and Reordering (F1=0.924) hallucinations. Removal hallucinations were the most challenging (F1=0.525), primarily because detecting missing information requires identifying the absence of source data rather than spotting unsupported text.
Error Analysis: Qualitative analysis of 163 incorrect predictions revealed that 44.8% of errors were due to "missing or implicit information hard to notice," particularly in removal cases within AB and EB sections.

Significance and Claims

The paper claims that incorporating document structure into hallucination analysis is crucial for improving the reliability of LLM-assisted bug report summarization. By shifting from a monolithic view to a section-aware perspective, the proposed approach provides:

Granular Diagnostics: The ability to pinpoint exactly where (which section) and what kind of error occurred, rather than just flagging a summary as "hallucinated."
Resource Efficiency: The finding that a mid-scale model (Ministral-3B) can achieve strong performance suggests that high-quality hallucination detection does not necessarily require massive computational resources.
Foundation for Mitigation: Understanding that different sections have different vulnerability profiles (e.g., S2R vs. EB) allows for the development of targeted detection and mitigation strategies in software maintenance workflows.

The authors maintain modesty regarding their claims, acknowledging that their synthetic dataset serves as an operational proxy and that future work is needed to validate these findings on manually annotated real-world datasets and across diverse enterprise bug tracking systems.