A survey maps how large models enter battery diagnostics

Estimating how much life a battery has left still depends, in most labs, on real degradation data: cells cycled for months or years until they fail. That requirement, known as run-to-failure, is one of the bottlenecks the field has carried for more than a decade, and it is the first one a review published on 29 August on arXiv flags as a candidate to fall.

The paper is titled Large Models for Battery Prognostics and Health Management: A Review and Future Roadmap and presents itself as the first complete survey of large models applied to BPHM, the discipline that estimates state of health and remaining useful life of batteries in electric vehicles, stationary storage and consumer electronics. It does not propose a new model: it organises a field that had been advancing through scattered papers and marks where the gaps still are.

What breaks in the classical approach

The authors start from two established families. Physics-based models are accurate but expensive to parameterise: every chemistry, every cell format and every usage profile forces a recalibration. Task-centric deep learning avoids that calibration, but it works well inside the domain it was trained on and degrades outside it. The review groups the shared limitations into four fronts: computational efficiency and parameterisation, cross-domain generalisation, dependence on large volumes of labelled run-to-failure data, and model interpretability.

That third point is the most expensive one in practice. Producing a complete degradation dataset means destroying cells in a controlled way over months, and the result only covers the specific chemistry that was tested.

What large models bring here

The paper argues that Transformer architectures combined with self-supervised pretraining allow the usual order to be inverted. Instead of training one model per task and per chemistry, you pretrain on large volumes of unlabelled cycling data and adapt afterwards to the specific task. The review identifies four enabling technologies: Transformer architectures, self-supervised learning, large-scale multimodal datasets and PEFT techniques (parameter-efficient fine-tuning), the family that includes LoRA and adapters and that lets you specialise a model by touching a minimal fraction of its parameters.

With that material, the paper classifies recent progress along four dimensions. The first three are mitigating data scarcity, improving generalisation and robustness, and integrating domain knowledge. The abstract published in the arXiv feed cuts off right there, so the fourth has to be looked up in the PDF.

Who it is useful for

For battery teams the interest is direct: the survey works as a map of which techniques have been tried and with what data. For anyone building LLM integrations outside text, the value is different. BPHM is a good case study of how a pattern born in language, pretrain big and adapt cheap, moves to industrial time series with scarce data and safety consequences. The problems that show up when you connect a model to production data, meaning validation, traceability and adaptation cost, repeat here with one nuance: a false negative in a battery diagnosis is not a badly written paragraph.

What a survey does not prove

It is worth reading for what it is. A review collects published results, it does not reproduce them or put them through a common protocol, so the figures it cites have to be traced back to each original paper. Interpretability is still listed as an open problem, and in a sector where certification weighs as much as accuracy that point is not minor. The roadmap that closes the paper describes, like almost every survey roadmap, the agenda of its authors more than the real state of industrial deployment.

We find the inventory of limitations more interesting than the promise of a battery foundation model. If self-supervised pretraining really cuts the dependence on run-to-failure data, the saving in lab time will be the argument that moves the industry, well before any decimal improvement in error metrics.