Where Does the Accuracy of LLM-Based Root-Cause Analysis Come From? An Empirical Study on Microservice Benchmarks
This empirical study reveals that the accuracy of LLM-based root-cause analysis in microservices is primarily driven by the quality of evidence extracted by its underlying pipeline rather than the model itself, while highlighting the system's significant vulnerability to misleading text and timing errors.
Original paper licensed under CC BY 4.0 (https://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
In the vast, invisible cities of modern software, where thousands of tiny programs called microservices work together to run everything from online shopping to banking, things occasionally break. When a failure occurs, engineers need to find the single broken piece quickly to fix it. This process is called root-cause analysis. For years, the standard way to do this has been to use automated detectors that watch for strange numbers in the system's data—like a sudden spike in memory use or a delay in a message—and then count which service is acting up the most. Recently, a new idea has emerged: instead of just counting, we can feed the data to a large language model, a type of artificial intelligence that can read and reason, and ask it to name the culprit. The hope is that these models can understand the story behind the numbers better than a simple counter can. But a critical question remains: if the model gets the answer right, is it because it is truly smart, or is it simply reading the clues that the automated detectors handed to it?
A team of researchers set out to answer this by building a controlled experiment using a real-world software system and a public collection of 360 simulated failures. They took an existing system where detectors summarize the data into a short text report and then pass it to an artificial intelligence model to make a diagnosis. Their goal was to peel back the layers and see exactly where the accuracy came from. They wanted to know if the model was adding any real value, or if the answer was already hidden in the text the detectors wrote. To find out, they ran the same model through different versions of the test. In some runs, they removed the interpretive sentences the detectors added. In others, they swapped the real service names for neutral labels. They even planted a false clue, telling the model that a specific service was the problem when it was actually innocent, to see if the model would blindly follow that suggestion.
The results revealed a surprising truth about how these systems work. When the researchers tested the model on a set of 270 failures involving network and resource issues, the model was actually less accurate than the simple count of detectors that fired. The detectors, which just counted how many alarms went off for each service, got the right answer 60% of the time, while the model got it right only 44% of the time. This suggests that on these types of problems, the model was not improving the diagnosis; it was sometimes getting in the way. The researchers found that the model's performance was heavily dependent on the text the pipeline wrote for it. When they removed the interpretive notes that the system added to explain the data, the model's accuracy dropped significantly. Even more telling, when they planted a false note claiming a specific service was the cause, the model followed that lie in nearly half of the cases, naming the innocent service as the culprit. This showed that the model was highly sensitive to the narrative it was given, often prioritizing the text's assertion over the actual evidence.
However, the story changed when the researchers looked at a different set of 90 failures that involved errors deep inside the computer code. Here, the model performed better than the simple detector count, getting the right answer 60% of the time compared to the detectors' 38%. The researchers discovered that this improvement came almost entirely from the raw log text—the actual error messages written by the software—which the model could read and understand, whereas the detectors could only count them. When they removed this raw text from the model's input, its accuracy fell back down to the level of the simple detectors. This indicates that the model's "intelligence" in this scenario was not a general reasoning ability, but a specific skill in reading the raw error logs that the detectors had summarized into numbers.
The study also tested how these systems handle uncertainty about when a failure started. They found that the most powerful statistical methods, which rely on comparing data before and after a known failure time, collapsed when the researchers shifted the start time by just two minutes. The model was slightly more robust to this error, but it still struggled. When the researchers built a completely different, simpler pipeline that just presented the data without the complex interpretive notes, the same model achieved a much higher accuracy of 87%. This proved that the model itself was capable of high performance, but only when the evidence was presented clearly and without misleading interpretive text. In the original system, the interpretive notes were acting like a filter that sometimes obscured the truth.
Ultimately, the research concludes that the accuracy of these artificial intelligence agents is not a property of the model alone. It is a mix of what the detectors extract, how the text is written, and the model's reaction to that text. In the case of the system they studied, the model often did less work than the simple detectors it was supposed to replace. The interpretive sentences added by the pipeline were powerful levers that could pull the answer in the right direction or, just as easily, toward a wrong one. The researchers argue that to truly understand these systems, we must stop treating the model as a black box that magically solves problems. Instead, we must test the text it reads just as rigorously as we test the code, checking whether the model is reasoning or simply following the lead of the text it was given. The findings suggest that for these tools to be reliable, the way we feed them information needs to be as carefully designed as the models themselves.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.