What machine learning is
Machine learning is a way of building a program by showing it examples instead of writing every rule by hand. You give an algorithm data, it adjusts internal parameters to fit patterns in that data, and the result is a model that can make predictions on new inputs.
For an engineer, a useful way to think about a model is as a function fitted to data. It maps inputs (sensor readings, image pixels, process settings) to an output (a category or a number). It is closely related to fitting a curve through measurements, only with many more inputs and far more flexible shapes. It is a tool for certain kinds of problem, not a general replacement for engineering understanding.
Supervised learning
In supervised learning, each training example comes with the correct answer, called a label. The model learns to predict the label from the inputs.
- Classification predicts a category, for example whether a part is acceptable or defective.
- Regression predicts a number, for example the remaining time before a component is likely to need replacement, or the expected temperature of a system under a given load.
The labels have to come from somewhere, and getting them is often the expensive part. Someone may need to inspect hundreds of parts and record the outcome. If the labels are inconsistent or wrong, the model learns those errors.
Unsupervised learning
In unsupervised learning there are no labels. The algorithm looks for structure in the data on its own.
- Clustering groups similar records. An engineer might use it to see whether machine logs fall into a few distinct operating patterns.
- Anomaly detection flags records that look unlike the rest, which can help with spotting unusual behaviour in equipment.
- Dimension reduction compresses many measurements into a few summary variables so they are easier to inspect.
The output needs interpretation. A cluster is only a statistical grouping; whether it reflects something physically meaningful is a question for a person with domain knowledge.
Training data and test data
The goal is a model that works on new data, not one that merely remembers the data it was given. To check this, the available data is split into separate sets.
- Training set: used to fit the model.
- Test set: held back and used only at the end to estimate how well the model handles unseen examples.
Often a third validation set is used while tuning settings, so the test set stays untouched until the final check.
An illustration: with 100 labelled examples, you might train on 80 and keep 20 for testing. Suppose the model gets 19 of the 20 test examples right. That is 95 percent on the test set, but with only 20 examples the estimate is rough, and a different split could give a noticeably different figure. Small datasets give shaky conclusions.
A common mistake is data leakage, where information from the test set sneaks into training, for example by normalising all the data together before splitting, or by including near-identical readings from the same machine in both sets. The model then looks better than it will be in service.
Overfitting
Overfitting happens when a model learns the noise and quirks of the training data rather than the underlying pattern. It scores very well on training data and noticeably worse on new data.
Think of fitting a curve to eight measurements. A very flexible curve can pass through every point exactly, but it may swing wildly between them and give poor predictions at new values. A simpler curve that misses some points slightly often generalises better.
Signs of overfitting include a large gap between training and test performance and results that change a lot when the data is reshuffled. Typical remedies are collecting more data, using a simpler model, limiting model flexibility and checking performance with repeated splits of the data. The opposite problem, underfitting, occurs when the model is too simple to capture the pattern at all.
Judging whether a model is good
A single accuracy figure can mislead. If only a small fraction of parts are defective, a model that labels everything “fine” can score a high accuracy and still be useless. Look at the kinds of error separately: missed defects and false alarms often have very different costs. Also compare against a simple baseline, such as predicting the average value or using an existing rule of thumb. If a complicated model barely beats the baseline, the added complexity may not be worth it.
When not to use machine learning
Machine learning is often the wrong choice. Consider other approaches when:
- A known physical law or formula already describes the system. A model built from physics can be checked and explained, and it behaves sensibly outside the range of past data. Engineering simulation is often a better fit.
- There is little data, or the data is poor quality or unrepresentative.
- Decisions must be explained and audited, and you cannot justify a black-box output.
- Errors are costly or unsafe and the model cannot be validated thoroughly. Safety-related uses need qualified engineers and the standards that apply in your country and industry.
- The conditions will change and the training data will no longer represent them.
- A simple rule or a threshold works. A few lines of logic are easier to test and maintain.
Even where a model is suitable, it should be treated like any other component: tested, documented and monitored. The broader process of framing questions, preparing data and building predictive models is described under data science, and models are also used in vision tasks such as computer vision. Predictions from any model remain uncertain, and results can degrade when real conditions differ from the data used to build it.