Section 1: Understanding Why Real-World Data Is Imperfect
Machine learning models are often developed under the assumption that the training data is accurate, complete, consistently structured, and representative of the environment where the model will eventually operate. Real-world datasets rarely satisfy all of these conditions.
Data is produced by people, software systems, sensors, operational workflows, and business processes. Each source can introduce imperfections. A customer may leave an important field blank. A sensor may record an incorrect measurement. A logging system may change its schema. Two systems may use different definitions for the same business concept. Human annotators may disagree about the correct label.
These imperfections are not unusual exceptions. They are a normal characteristic of production data.
The engineering challenge is therefore not to wait for perfect data. It is to understand which imperfections can be corrected, which require specialized modeling approaches, and which actually contain useful information about the real environment.
Where Imperfect Data Comes From
Machine learning datasets can inherit problems from almost every stage of the data-generation process.
Manual entry is one common source of error. Humans may enter incorrect values, use inconsistent formats, omit required information, or interpret business fields differently.
Sensors introduce another category of problems. Measurements can contain noise, temporary failures, calibration errors, or unusual values caused by real environmental conditions.
Application logs may also be inconsistent. Software updates can change event names, field structures, or logging behavior. A model trained on several months of historical logs may therefore encounter a different data structure after an application release.
Business systems frequently contain historical inconsistencies. A field that appears to represent one concept may have been calculated differently across departments, products, or time periods.
External data sources can introduce additional uncertainty. Third-party datasets may have different definitions, update frequencies, coverage levels, and quality standards.
This means that data imperfections should always be interpreted in context.
An unusual value is not automatically an error. A sudden change in a feature may indicate corrupted data, but it could also represent a genuine change in customer behavior.
The first question should therefore be:
Is this observation wrong, unusual, or simply different from what we expected?
Missing and Incomplete Data
Missing values are among the most common problems in real-world datasets.
A field may be missing because information was never collected, because a user chose not to provide it, because a system failed, or because the field was simply not relevant to that particular observation.
These causes matter because missingness can itself contain information.
For example, suppose a customer provides an optional field only when a particular type of transaction occurs. The absence of that value may reveal something about the transaction rather than representing random data loss.
This is why blindly replacing every missing value with a fixed statistic can sometimes remove useful information.
Sparse records create a related challenge. Some observations may contain rich information while others have only a small subset of fields available.
Partial observations are especially common in event-driven systems. A user may begin a workflow but leave before completing it, resulting in an incomplete record.
The missingness mechanism also matters. Data may be missing completely at random, related to other observed variables, or associated with the unobserved value itself.
The last case can be particularly challenging because the missingness process is connected to the underlying phenomenon being modeled.
ML engineers therefore need to understand why information is missing before deciding how to handle it.
Noise, Errors, and Outliers
Real-world data often contains noise.
Measurement systems can produce small inaccuracies, users can make mistakes, and automated processes can generate inconsistent records.
Noise can make it harder for a model to distinguish meaningful patterns from random variation.
Duplicate data can also distort training. If the same event appears multiple times, the model may effectively give that observation more influence than intended.
Corrupted records represent another problem. A system failure might produce impossible values or malformed records that should not enter the training process.
Then there are outliers.
An outlier is an observation that differs substantially from the majority of the dataset. But being unusual does not necessarily mean being incorrect.
A transaction that is ten times larger than the average may be a data error—or it may represent a legitimate high-value customer.
A sensor reading that appears extreme may indicate a faulty instrument—or an actual equipment failure.
This distinction is especially important because some ML applications exist specifically to detect rare events.
If engineers remove every extreme observation during preprocessing, they may accidentally eliminate the very cases the production system needs to recognize.
The correct approach is therefore to investigate the origin and meaning of outliers rather than treating rarity as proof of error.
Label Problems and Data Bias
Even when input features are reliable, supervised learning can fail because of label problems.
Labels may be incorrect, inconsistent, delayed, or based on different interpretations of the target.
Human annotation introduces another source of variation. Two reviewers may disagree about whether a document belongs to a category or whether an image represents a particular condition.
Annotation disagreement does not necessarily mean that one reviewer is wrong. It may reveal that the underlying classification task is ambiguous or that the label definitions need to be clarified.
Historical business processes can also create sampling bias.
Suppose a company historically investigated only a particular category of customers. The resulting dataset may contain detailed information about those customers while providing little evidence about everyone else.
Likewise, a fraud dataset based entirely on previously flagged transactions may not represent the full transaction population.
This creates a distinction between the data the organization has collected and the data it would ideally need to model the broader environment.
Historical process bias can therefore become embedded in the training dataset.
The challenge is that machine learning models learn patterns from the information provided to them. If those patterns reflect incomplete or biased processes, the model can reproduce them very effectively.
This is why data quality cannot be reduced to checking whether every field has a valid type or value.
Engineers also need to understand how the data was generated, what populations it represents, which observations are missing, and how labels were produced.
The broader dataset lifecycle is important here. "The Journey of a Dataset: From Raw Data to Production ML" explores how raw information moves through collection, validation, transformation, feature engineering, training, deployment, and continuous monitoring and why the quality of that journey matters as much as the final model.
Key Takeaway
Real-world ML data is imperfect because it is generated by people, sensors, software systems, business processes, and external sources, each of which can introduce missing values, noise, duplicates, outliers, labeling errors, and bias. Strong ML teams do not automatically remove every unusual observation or fill every missing value using a generic rule. They first determine why the imperfection exists and whether it represents harmful data quality or meaningful information about the real environment.
Section 2: Strategies for Training With Imperfect Data
Once an ML team recognizes that real-world data will rarely be complete or perfectly accurate, the next challenge is deciding how to train models without allowing those imperfections to dominate the learning process. The objective is not to eliminate every irregularity from a dataset. Instead, engineers need to determine which problems materially affect model performance, which can be tolerated by the model, and which require changes to the data-generation or labeling process.
This distinction is important because aggressive preprocessing can be just as harmful as inadequate preprocessing. Removing too many observations can reduce coverage, replacing missing values without understanding their meaning can introduce artificial patterns, and filtering unusual examples can eliminate rare cases that matter in production. Effective machine learning therefore treats data preparation as an engineering and modeling problem rather than a simple cleaning exercise.
Handling Missing Values
Missing data is often the first imperfection engineers encounter during model development. A straightforward approach is to remove rows containing missing values, but this can become problematic when missingness is widespread. Eliminating large portions of the training set reduces the amount of information available to the model and may disproportionately remove particular customer groups, events, or operating conditions.
A more common strategy is imputation, where missing values are replaced with estimated values. Numerical features may use statistics such as the median or mean, while categorical variables may use a dedicated category representing an unknown or missing state. The appropriate strategy depends heavily on the distribution of the feature and the meaning of the missing value.
For some systems, it is useful to explicitly preserve missingness as information. An additional indicator feature can tell the model whether the original value was absent. This allows the model to distinguish between an observed value and an imputed one.
More sophisticated approaches can estimate missing values using relationships among other variables. However, greater sophistication does not automatically mean better results. A complex imputation method can introduce assumptions and leakage if it is not carefully designed around the training and inference process.
The key principle is that missing-value handling should reflect how the production system generates incomplete observations. The preprocessing logic applied during training should remain reproducible when the same conditions appear in production.
Working With Noisy Data
Noise is inevitable in many ML datasets, but not all noise should be removed.
For numerical features, engineers may identify implausible measurements using domain constraints, distribution analysis, or statistical techniques. For example, a negative value for a quantity that cannot physically be negative may indicate a data-generation problem. In contrast, a large but valid value should generally remain in the dataset simply because it is uncommon.
Noise can also occur in textual, image, audio, or event-stream data. In these settings, normalization and validation can reduce irrelevant variation before model training.
Another important strategy is choosing algorithms and loss functions that are less sensitive to problematic observations. Some models are naturally more robust than others, and robust statistical techniques can reduce the influence of extreme observations without deleting them completely.
The goal is therefore not simply to make the dataset look clean. It is to create a training process in which legitimate variation remains visible while clearly harmful corruption has limited influence.
This requires collaboration between data engineers, ML engineers, and domain experts. A domain expert may recognize that what looks like an outlier to a statistical pipeline is actually an important business event. That context can prevent automated preprocessing from destroying valuable training information.
Improving Label Quality
In supervised learning, the target label is often more important than any individual input feature because the model is directly optimized to reproduce the relationship encoded by those labels.
A model trained on systematically incorrect labels can achieve strong training performance while learning the wrong behavior.
One strategy for improving label quality is to establish clear annotation guidelines. When multiple people or systems produce labels, consistent definitions help reduce disagreement and ambiguity. Samples that generate frequent disagreement can be reviewed separately because they may expose unclear category boundaries or weaknesses in the labeling process.
Another approach is label auditing. Instead of manually checking every training example, teams can prioritize suspicious cases, such as examples where the model is highly confident but consistently disagrees with the recorded label. These examples can then be reviewed to determine whether the model or the dataset is incorrect.
This naturally connects to active learning, where the ML system helps identify which examples would provide the greatest value from additional human labeling. Rather than spending equal effort on every observation, teams focus labeling capacity on ambiguous, informative, or underrepresented examples.
Active Learning: Making Machine Learning More Efficient With Less Labeled Data provides a useful perspective on this strategy, particularly when high-quality labels are expensive to obtain. The underlying idea is that better datasets do not always require labeling more data indiscriminately; they often require identifying the right data to label.
Label quality should also be monitored over time. Production systems can introduce new categories, new user behaviors, or new edge cases that were not represented when the original training dataset was created. A labeling process that was reliable six months ago may become inadequate as the application evolves.
Key Takeaway
Training with imperfect data requires more than cleaning rows and filling missing values. Effective ML teams combine appropriate imputation, noise-aware preprocessing, label-quality controls, targeted labeling, and representative data collection while preserving legitimate variation. The goal is to build a training dataset that reflects the real problem rather than an artificially sanitized version of it.
Section 3: Building Models That Tolerate Imperfect Data
Improving the dataset is only one part of building reliable machine learning systems. Even after careful preprocessing, models will encounter missing information, measurement noise, unusual observations, changing feature distributions, and examples that do not perfectly resemble the training data. A production model therefore needs to tolerate a reasonable level of imperfection rather than assuming that preprocessing has eliminated every problem.
This is where model design becomes closely connected to data quality. The choice of features, algorithm, validation strategy, and evaluation metrics can determine whether a model remains useful when the input data differs from the idealized training dataset.
Robust Feature Engineering
Feature engineering is often treated as a process of transforming raw variables into signals that are easier for a model to learn from. With imperfect data, it also becomes a mechanism for improving model robustness.
A useful feature should capture meaningful structure without becoming unnecessarily sensitive to small errors in the underlying data. For example, a raw transaction amount might fluctuate because of minor recording differences, while a carefully designed aggregated or normalized feature may capture the broader customer behavior more reliably.
Feature transformations can also reduce the influence of extreme values. Log transformations, normalization, clipping, and carefully designed aggregation can prevent a small number of unusual observations from disproportionately affecting a model. However, these transformations need to be chosen based on the characteristics of the underlying problem rather than applied mechanically.
Another important consideration is feature dependency. A model may appear robust during training because several features provide overlapping information, but if those features originate from the same unreliable source, the apparent redundancy may be misleading. A production failure in that source could cause multiple features to degrade simultaneously.
Feature engineering should therefore consider not only predictive power but also data provenance, availability, stability, and failure behavior.
A feature that produces excellent offline performance but is frequently missing in production may be less valuable than a slightly weaker feature that is consistently available.
Choosing Models for Data Quality Conditions
Different model families respond differently to imperfect data.
Some algorithms are relatively tolerant of nonlinear relationships and complex feature interactions, while others can be highly sensitive to scaling, outliers, or irrelevant variables. Model selection should therefore consider the characteristics of the available data rather than focusing exclusively on benchmark accuracy.
For example, tree-based methods can capture nonlinear relationships without requiring the same degree of feature scaling that many distance-based or gradient-based approaches require. Linear models can be attractive when interpretability and stability are important, particularly when the underlying relationships are reasonably well understood.
The right choice depends on the operational environment.
A highly sophisticated model is not automatically the most reliable model. When input quality varies significantly, a simpler model with predictable behavior may outperform a more complex model whose performance depends on assumptions that are difficult to maintain in production.
This is closely related to the idea explored in "Why Simpler Machine Learning Models Sometimes Win in Production" Model complexity should ultimately be justified by the value it creates, especially when additional complexity increases sensitivity to data quality, operational dependencies, or distribution changes.
Robustness can also be improved through ensemble methods, regularization, data augmentation, or model architectures specifically designed to handle certain types of missing or noisy information. These approaches are valuable when they address a known failure mode rather than simply adding complexity to the pipeline.
Validation With Imperfect Datasets
A model trained on imperfect data can appear highly successful if the validation strategy reproduces the same limitations found in the training data.
This makes validation design critical.
A random train-test split may be appropriate for some problems, but it can produce overly optimistic results when data contains temporal dependencies, repeated users, related transactions, or other forms of correlation. The validation set may accidentally resemble the training set much more closely than the production environment will.
A stronger validation strategy attempts to recreate the conditions under which the model will actually operate.
For a system exposed to changing customer behavior, temporal validation may be more informative than a random split. For a model deployed across multiple geographic or business segments, evaluation should test whether performance remains consistent across those populations.
Engineers should also deliberately evaluate imperfect cases.
Instead of measuring only aggregate performance, they can analyze model behavior when features are missing, values are extreme, input distributions shift, or labels are uncertain. This exposes weaknesses that overall metrics may hide.
For example, a model can maintain 95% overall accuracy while failing disproportionately on the subset of records containing missing information. From a business perspective, that may be unacceptable even though the headline metric looks strong.
Validation should therefore answer a more useful question than "How accurate is the model on the test set?"
The better question is:
How does the model behave under the conditions it will encounter after deployment?
Measuring Generalization Under Real Conditions
Generalization is the ability of a model to perform well beyond the exact examples used during training. With imperfect data, this concept becomes particularly important because production data will almost always differ from historical training data to some degree.
A robust evaluation process should examine performance across different data conditions, including common cases, rare cases, missing fields, noisy observations, and potentially changing distributions.
This can involve evaluating multiple metrics rather than relying on a single score. Precision, recall, calibration, ranking metrics, regression error, or business-specific measures may reveal different aspects of model behavior.
For imbalanced problems, for example, overall accuracy can conceal poor performance on the minority class. For ranking systems, a conventional classification metric may provide little insight into whether the highest-value results are actually appearing at the top of the ranked list.
The evaluation dataset itself also needs scrutiny. If it contains the same collection biases as the training data, strong performance may simply demonstrate that the model has learned to reproduce those biases.
One useful principle is to maintain challenging evaluation slices that represent important production scenarios. These slices should be tracked over time so that teams can determine whether the model is becoming more or less reliable as the environment changes.
This shifts model evaluation from a one-time gate before deployment to an ongoing engineering discipline.
A model should not be considered robust merely because it achieves a strong validation score. Robustness means that the model continues to produce useful outputs when faced with the imperfect, variable, and sometimes unexpected data that exists outside the training environment.
Key Takeaway
Building models for imperfect data requires robustness at multiple levels: features must remain useful when inputs are incomplete or noisy, model choices should match the quality and structure of the available data, validation should reflect production conditions, and evaluation must test important edge cases rather than relying only on aggregate metrics. The strongest models are not those that perform perfectly on idealized datasets, but those that remain dependable when reality is less predictable.
Section 4: Managing Data Quality in Production
Training a machine learning model with imperfect data is only the beginning. Once the model is deployed, the characteristics of its inputs can change continuously. New users may behave differently, products may evolve, business processes may change, sensors may degrade, and upstream applications may introduce new data formats. A dataset that was sufficiently reliable during model development can therefore become unsuitable over time.
For production ML systems, data quality is not a one-time preprocessing task. It is an operational capability that must be monitored, measured, and maintained alongside model performance.
Continuous Data Monitoring
A production ML system should continuously observe the data entering the model.
This does not mean checking only whether a pipeline successfully completed. A pipeline can execute without errors while delivering data that is technically valid but operationally wrong. For example, a feature may suddenly contain an unusually high percentage of null values, a categorical field may begin receiving previously unseen values, or a numerical feature may shift substantially from its historical distribution.
These changes can indicate upstream failures or genuine changes in the environment.
Effective monitoring therefore examines data completeness, validity, freshness, distribution, and consistency. Monitoring can include null rates, value ranges, category frequencies, schema changes, feature distributions, and relationships between important variables.
Distribution monitoring is particularly important. A model may have been trained on one population but gradually begin receiving observations from another. This is commonly described as data drift or distribution shift.
Importantly, detecting drift does not automatically mean that a model should be retrained. A change may be temporary, harmless, or even beneficial. The monitoring system should provide enough context for engineers to determine whether a change represents a genuine risk to model quality.
Data Quality and Model Reliability
Data quality and model performance are tightly coupled.
A prediction is only as reliable as the information available to produce it. When critical features become unreliable, model performance can deteriorate even when the model itself has not changed.
This creates an important operational distinction between model degradation and data degradation.
Suppose a recommendation model suddenly produces weaker results. The problem may not be the model weights. An upstream service could have stopped sending an important behavioral feature, an event-tracking change could have altered feature distributions, or a new product workflow could have changed the meaning of an existing field.
Without data-quality monitoring, engineers may respond by retraining the model, tuning hyperparameters, or changing the architecture when the real issue exists upstream.
Production systems therefore benefit from connecting data metrics with model metrics. Changes in feature availability can be analyzed alongside changes in prediction quality, conversion, ranking performance, false-positive rates, or other application-level outcomes.
This approach makes diagnosis faster and helps prevent unnecessary model changes.
It also reinforces a broader lesson explored in "The Hidden Engineering Work Behind Every Successful Machine Learning Product" Model development is only one part of a production ML system; reliable data pipelines, monitoring, deployment processes, and operational controls are equally important to sustaining performance.
Building Resilient ML Pipelines
A reliable production pipeline should assume that upstream data will occasionally fail.
This means that pipelines need mechanisms for detecting schema changes, handling unexpected values, validating incoming records, and preventing obviously corrupted data from silently propagating into downstream systems.
Validation should happen at multiple stages. Raw inputs can be checked for structural correctness, transformed features can be checked for expected ranges and distributions, and model-ready datasets can be tested for critical assumptions before inference or retraining begins.
Resilience also involves failure containment.
When an upstream dependency fails, the system should have defined behavior rather than allowing invalid data to flow through the entire ML stack. Depending on the application, this might involve fallback features, cached values, safe defaults, degraded functionality, or temporarily stopping predictions.
These decisions should be made before the failure occurs.
A mature ML system therefore treats data-quality conditions as operational states that need corresponding responses. Minor deviations may trigger logging, larger anomalies may trigger alerts, and severe failures may require blocking model execution until the data issue is resolved.
The pipeline should also maintain traceability so engineers can determine where a problematic value originated and which downstream models or decisions were affected.
Key Takeaway
Production machine learning requires continuous data-quality management, not just careful preprocessing during training. Monitoring feature distributions, completeness, freshness, and validity helps teams distinguish data problems from model problems, while resilient pipelines and clear ownership prevent upstream failures from silently degrading predictions. Ultimately, reliable ML systems emerge when data quality is treated as an ongoing engineering discipline shared across the organization.
Conclusion
Machine learning in production rarely operates on clean, complete, perfectly labeled datasets. Real-world data is generated by complex systems involving users, applications, sensors, business processes, third-party sources, and human decisions. As a result, missing values, noisy observations, outliers, inconsistent records, label errors, and biased samples are not unusual exceptions. They are fundamental characteristics of many production ML environments.
The central lesson is that machine learning without perfect data is not only possible but often necessary. The objective is not to transform every dataset into an artificial version of perfection. Instead, ML engineers need to understand where imperfections originate, determine which ones can materially affect model behavior, and design data and modeling strategies that remain reliable under realistic conditions.
That starts with understanding the data-generation process. Missing values should be interpreted according to why the information is absent rather than automatically replaced or deleted. Outliers should be investigated instead of being assumed to be errors. Noisy observations need to be distinguished from legitimate rare events, particularly in systems where anomaly detection or fraud identification is part of the objective. Similarly, label quality deserves significant attention because a sophisticated model cannot compensate for systematically incorrect or ambiguous targets.
Model development must then account for the limitations of the available data. Robust feature engineering can reduce unnecessary sensitivity to noise and extreme values, while model selection should reflect the actual quality, structure, and availability of the inputs. Validation must move beyond a convenient random train-test split when that split does not represent production conditions. Evaluating important population segments, edge cases, missing-data scenarios, and changing distributions provides a much clearer picture of how a system will behave after deployment.
Frequently Asked Questions
1. Can machine learning models work effectively with imperfect data?
Yes. Most production ML systems operate with some degree of missing, noisy, inconsistent, or biased data. The important consideration is whether the imperfections materially affect the learning problem and whether the system has strategies to manage them. Appropriate preprocessing, robust features, suitable model selection, realistic validation, and production monitoring can allow models to remain effective despite imperfect inputs.
2. Should all missing values be replaced with the mean or median?
No. Mean or median imputation can be useful in some situations, but the appropriate strategy depends on why the value is missing and how the feature behaves. Missingness may itself contain useful information, and some datasets require separate missing indicators, categorical "unknown" states, or more specialized imputation approaches.
3. Should outliers always be removed before training?
No. An outlier may be a data error, but it may also represent a legitimate and important event. Removing every unusual observation can eliminate precisely the examples that matter for applications such as fraud detection, anomaly detection, risk modeling, or failure prediction. Engineers should investigate the origin and meaning of extreme observations before deciding whether to remove or transform them.
4. What is the difference between noisy data and incorrect data?
Noisy data contains variation or measurement uncertainty that may obscure the underlying signal, while incorrect data represents observations that are fundamentally wrong or invalid. The distinction is important because some noise can be tolerated by robust models, whereas clearly invalid values may need to be corrected or excluded.
5. Why is label quality so important in supervised learning?
Supervised learning models optimize their behavior based on the target labels provided during training. If those labels are systematically incorrect, inconsistent, or ambiguous, the model can learn the wrong relationship even when the input features are high quality. Improving labels can therefore produce greater gains than simply increasing model complexity.
6. What is data bias in machine learning?
Data bias occurs when the training data does not adequately represent the population, conditions, or processes relevant to the intended application. Bias can result from historical decisions, sampling procedures, incomplete coverage, selective data collection, or differences in how information is recorded. A model trained on biased data may reproduce those limitations in its predictions.
7. How can ML teams work with limited training data?
Teams can improve limited datasets by prioritizing high-value examples, using targeted data collection, applying appropriate sampling strategies, improving label quality, and in some cases using data augmentation or synthetic data. The objective is to improve the information content and coverage of the dataset rather than simply increasing its size.
8. What is active learning, and how does it help with imperfect data?
Active learning is an approach in which the ML system helps identify which examples should receive additional human labeling. Instead of labeling every available observation equally, teams can focus on ambiguous, informative, or underrepresented examples. This can improve label quality and make more efficient use of limited annotation resources.
9. How does feature engineering improve robustness?
Good feature engineering can produce signals that are less sensitive to irrelevant variation, extreme values, and unreliable raw measurements. Normalization, aggregation, carefully chosen transformations, and features based on stable business or behavioral relationships can improve model reliability. Feature availability and data provenance should also be considered because a powerful feature is not useful if it is frequently unavailable in production.
10. How should models be evaluated when the training data is imperfect?
Evaluation should reflect the conditions the model is expected to encounter in production. In addition to aggregate metrics, teams should examine performance across meaningful data slices, rare cases, missing-feature scenarios, temporal periods, and other challenging conditions. The evaluation strategy should minimize the gap between the test environment and the real deployment environment.
11. Why can a model perform well during testing but fail in production?
A model can perform well offline because the test dataset may be cleaner, more representative, or more similar to the training data than production data. Production can introduce distribution shift, missing features, upstream pipeline failures, new user behavior, or changes in business processes. A strong test score therefore does not guarantee production reliability.
12. What should ML teams monitor for data quality in production?
Important signals include feature completeness, null rates, value ranges, schema changes, freshness, category distributions, feature distributions, and unexpected changes in relationships among variables. These data-quality indicators should be monitored alongside model metrics and business outcomes so that engineers can identify the source of degradation.
13. Does data drift always mean the model needs to be retrained?
No. Drift simply indicates that the characteristics of incoming data have changed. Some changes are temporary or harmless, while others can significantly affect model performance. Retraining should be driven by evidence that the change creates a meaningful performance or business problem, not by the existence of drift alone.
14. Who should be responsible for data quality in an ML system?
Data quality is typically a shared responsibility. Data engineers manage pipelines and sources, ML engineers understand which data characteristics affect model behavior, application teams control many upstream events and schemas, and domain experts provide context about whether unusual observations are legitimate. Clear ownership is essential, but reliable ML generally requires collaboration across these groups.
15. What is the most important principle when building ML systems with imperfect data?
The most important principle is to understand the source and meaning of the imperfection before deciding how to handle it. Missing values, noise, outliers, and unusual observations can represent either harmful data quality problems or valuable information about the real environment. The goal is not to make the dataset look perfect; it is to build a model and production system that remain reliable under realistic conditions.
