Does data-centric ML mean models do not matter?

No. Data and modeling choices both affect performance.

Is correcting labels always straightforward?

No. Some disagreements reveal ambiguous tasks that require clarification rather than a single obvious answer.

Can adding features make performance worse?

Yes. Irrelevant, unstable, leaked, or poorly maintained features can harm evaluation or deployment behavior.

AI Glossary / MLOps and deployment / Intermediate

Data-Centric ML

Definition

Data-centric ML is an approach to improving machine-learning systems through systematic work on the data they use. This can include better labels, more relevant examples, improved feature definitions, consistent measurement, and clearer dataset documentation. Its focus is making data more suitable for the intended task rather than treating the training dataset as a fixed input throughout development.

What it means

A model learns from the examples and signals it receives. If those signals are inconsistent, incomplete, or mismatched to the intended use, changing the model architecture may leave the underlying problem unresolved.
Data-centric work asks which data change would address a specific observed weakness. A team might clarify a label definition, collect examples of an underrepresented condition, or remove a feature that accidentally reveals the answer.
The approach complements model development. Holding a model configuration steady during a data experiment can make the effect of a data change easier to interpret, but it does not mean the model must remain unchanged forever. The goal is a better functioning system, not loyalty to one category of intervention.

How it works

Start with an evaluation that reflects the intended task and inspect meaningful groups of errors. Form a concrete hypothesis about the data, such as inconsistent handling of ambiguous examples or inadequate coverage of a deployment condition.
Revise the relevant data process and record what changed. This may require annotation guidance, expert review, revised sampling, additional collection, or a feature transformation with a clear definition.
Train and evaluate using appropriate separation between development and final assessment. Compare overall behavior and relevant subgroups, not merely the training score. Retain dataset versions, labeling rules, and transformation history so that an apparent improvement can be investigated and reproduced rather than attributed to an undocumented cleanup.

Three practical examples

A text classifier can improve annotation consistency by defining how requests containing both a complaint and a question should be labeled.
A visual-inspection system can collect representative examples from a lighting condition that was rare in its original training set.
A forecasting team can correct inconsistent units and align timestamps before experimenting with more complicated model architectures.

Think of it this way

Think of teaching from a set of practice exercises. Clear questions, correct answers, and coverage of relevant situations can matter as much as the teaching method. Adding more copies of ambiguous exercises is unlikely to solve the ambiguity. The analogy is limited because machine-learning systems optimize numerical objectives and may exploit patterns that a human teacher would not consider meaningful.

Worked example

Consider an invented support-request dataset with 1,000 training examples. Two annotators interpret the label urgent differently: one uses it for explicit deadlines, while the other also includes strongly worded complaints. The team identifies 120 examples affected by this disagreement and writes a clearer labeling rule.
It reviews those examples and produces training dataset version D2. The baseline version is D1. Both are used with the same model family, training settings, and evaluation procedure for a controlled comparison.
On a separate, consistently labeled development set of 200 examples, model A trained on D1 gets 166 correct: 166/200 = 83%. Model B trained on D2 gets 176 correct: 176/200 = 88%. The illustrative observed difference is five percentage points, not a five-percent relative increase.
The team also examines 40 deadline-related examples within that set. A gets 24 correct and B gets 32 correct, corresponding to 60% and 80%. This slice helps assess whether the hypothesized problem improved rather than relying only on the aggregate score.
These invented counts illustrate an evaluation process, not proof that label revision will produce those gains. Repeated trials, uncertainty, other slices, and a final assessment on data not repeatedly used for decisions still matter. The team must also check whether the clearer definition matches the actual operational task.

Illustrative case study

In a fictional product-catalog project, a team tries several larger classifiers without resolving frequent category errors. Error review shows that different suppliers use incompatible category definitions.
The team agrees on a common taxonomy, preserves the original supplier labels, and records how each is mapped to the new definitions. It evaluates the revised process separately for suppliers with ambiguous mappings.
The case illustrates that data work can require a business decision about meaning, not just automated cleaning. A consistent label that represents the wrong business concept would still be unsuitable.

Common misconceptions and mistakes

Do not equate data-centric ML with collecting as much data as possible. Relevance, consistency, coverage, and appropriate use matter as well as volume.
Do not automatically delete difficult examples as noise. They may represent important operating conditions or genuine ambiguity that the system should handle.
Do not change evaluation labels simply to agree with model predictions. Corrections need defensible evidence and a documented procedure.
Do not allow repeated inspection of the final test set to guide data changes without recognizing evaluation leakage. Also, adding a predictive feature is not enough: it must be available at prediction time and appropriate for the intended use.

Business use

Data-centric ML gives teams a practical way to connect model errors with data ownership and improvement costs. Prioritize interventions according to the problem they address, the affected users or workflows, and the evidence needed to judge success.
Budget for ongoing maintenance of data definitions and feature pipelines. Reusing an existing feature can reduce work, but it is not automatically cost-free: compatibility, freshness, access, and monitoring still require attention. A useful improvement record links each dataset change to its rationale and measured effects, including regressions.

Check your understanding

A team doubles its dataset by copying the same ambiguous labels. Has it necessarily solved a data-quality problem?

Answer: No. More examples do not resolve inconsistent definitions. The team must diagnose and address the specific source of ambiguity.

Related terms

Data Quality
Feature engineering
Data leakage
Active learning
labeling
error analysis
dataset versioning
and model-centric ML

Learn next

Select a small error group, state a testable data-quality hypothesis, and design one targeted intervention. Record the dataset change and evaluate it with a stable procedure, while preserving a separate final assessment.

Data Quality

Sources

Sources: Hopsworks dictionary, data-centric ML and feature-data practices: https://www.hopsworks.ai/dictionary/data-centric-ml Data-centric AI Resource Hub, definition and topic scope: https://www.datacentricai.org/

Previous: Data-centric computing Next: Data-centric programming language