Why LLMs Make Unreliable Data Cleaners: What Engineering Leaders Must Understand Before Deploying Them in Data Pipelines

The case for using LLMs in data cleaning pipelines is superficially compelling: they handle freeform text, they generalise across error types, and they post strong numbers on public benchmarks. The problem is that those benchmark numbers may be telling you something different from what you think they are. Before you embed an LLM into a production ETL workflow, you need to understand the mechanism behind those scores, because it has direct consequences for how the system will behave on data the model has never encountered.

The Knowledge-Dependence Problem

LLMs are not pure reasoning engines. They are trained on vast corpora that include structured and semi-structured data about real-world entities, and that knowledge does not disappear when you ask them to clean a table.

When a model is asked to correct a hospital name, a film release year, or a journal title, it can draw on two distinct sources: the evidence in the table itself, and its parametric memory of the entity in question. On familiar entities, those two sources often agree, and the model produces a correct repair. The difficulty is that you cannot easily tell which source the model actually used.

This matters because in a production data pipeline, your data is almost never the kind of data that appears in public benchmarks. It is proprietary, domain-specific, and populated with entities the model has limited or no prior knowledge of.

What the CoRE Protocol Reveals

Research from Yang et al. (arXiv 2026) formalises this problem with a controlled experimental design called CoRE (Cleaning or Recalling). The protocol replaces real entity names in benchmark tables with surrogate names built from English words or syllables, preserving error positions and non-identity values while stripping the model's ability to recall the original entity.

The results are stark. On the Movies benchmark, replacing entity names with word-based surrogates drops DeepSeek-V4-Pro's year-repair accuracy from 91% to 18%. That is not a marginal degradation. It is a near-complete collapse in a capability that looked reliable on the original benchmark.

Equally important is the finding that commercial models score higher on fresh real records than on word-based surrogates (Yang et al., arXiv 2026). This confirms that part of what public benchmarks are measuring is entity familiarity, not generalised repair capability.

Benchmark Inflation and What It Hides

The implication for how you evaluate LLM-based cleaning tools is significant. A vendor presenting benchmark accuracy figures is, in many cases, presenting a number that reflects the intersection of their model's training data and the benchmark's entity population. That number does not transfer cleanly to your data.

There is also a subtler failure mode: familiar facts can actively conflict with the cleaning task. Even when given explicit instructions to use table evidence, commercial models rewrite assigned directors at non-trivial rates on well-known films (Yang et al., arXiv 2026). The model's prior knowledge overrides the task instruction. In a pipeline processing proprietary records, this means the model may silently substitute its own beliefs for the values in your data.

Reference scoring in standard benchmarks compounds the problem. A correction that is factually accurate against an external authoritative source may receive no credit if it does not match the benchmark's reference answer, while a transformation that reproduces a reference date pattern scores full credit regardless of factual accuracy.

Architectural Implications for Production Pipelines

Understanding this failure mode should change how you architect LLM-based cleaning, not necessarily whether you use LLMs at all.

The first implication is that entity familiarity needs to be treated as a pipeline variable, not a constant. If your dataset contains entities the model is unlikely to know, repair performance on standard benchmarks is not a reliable prior. You need evaluation against surrogate or masked versions of your own data before committing to a production deployment.

The second implication concerns the role of table-grounding. Prompting strategies that force the model to cite specific cell values as evidence for each repair are preferable to open-ended correction prompts. This does not eliminate knowledge bleed, but it creates an audit trail that makes the failure mode detectable rather than silent.

The third implication is about pipeline position. LLMs are better placed as a second-pass enrichment layer operating on records that have already passed rule-based or schema-level validation, rather than as a first-pass cleaner with broad authority over raw input data. Narrow scope limits the blast radius when knowledge-dependent errors occur.

Evaluating Your Exposure

If you are currently running LLM-based cleaning in production, the practical question is how familiar your data's entities are to the models you are using.

A reasonable diagnostic is to construct a small surrogate version of a representative sample of your data, following the CoRE methodology, and compare repair accuracy against the original. A large gap indicates significant knowledge dependence and should prompt a review of where in your pipeline the LLM sits and what fallback logic exists when it produces a confident but incorrect repair.

The broader principle is that confidence and accuracy are not the same thing in a knowledge-dependent system. LLMs do not flag uncertainty when they are recalling a memorised fact that happens to conflict with the data in front of them. That asymmetry is the core architectural risk, and it is one that benchmark scores, as currently constructed, do not surface.