Machine learning basics start with one idea: computers learn rules from data instead of being explicitly programmed. Define the prediction you need, gather representative data, and keep separate data aside for a final test before trusting any result.
| Phase | What happens | Planning use |
|---|---|---|
| Frame the task | Decide what the model should predict or reveal, and whether labeled examples exist | Settle supervised or unsupervised learning before collecting anything |
| Prepare data | Gather training data, convert inputs to numeric form and refine the features | Spend the most effort here, because model quality follows data quality |
| Split data | Separate training, validation and test sets | Do this before experimenting so the test set stays untouched |
| Train and tune | Learn patterns from training data and compare candidate models on validation data | Change settings freely here, never by watching the test set |
| Test | Estimate accuracy on data the model has never seen | Treat the result as a final reading, not a tuning tool |
| Run and maintain | Put the model to work and keep checking that it still performs | Budget for upkeep and ownership, not just the initial build |
The phases above follow Harvard’s TinyML course material and the MLU-Explain guide to train, test and validation data, and they set the order for these machine learning basics.
If you are weighing machine learning basics against a business decision, the enterprise ai guide covers the organisational side, and ai tools for business compares what is available to buy.
What machine learning is and where it sits
Machine learning is a way of building software that learns from examples. Harvard’s TinyML material describes the idea as computers learning the rules for themselves, with a few hints from people. In ordinary software a developer writes every rule by hand. In machine learning the developer supplies data, a goal and some guidance, and the computer works out the rules that connect inputs to outputs.
That shift moves the effort. Less time goes into writing rules and more goes into collecting, checking and shaping data, which is why much of this guide concerns data rather than algorithms. The step-by-step explainer on how does machine learning work follows a project from raw data to a working prediction.
Machine learning and artificial intelligence
Dataquest describes machine learning as a subset of artificial intelligence that lets a computer system make predictions or decisions automatically, without being explicitly programmed. The practical consequence is a useful question for any product pitch. Ask whether the system learned its behaviour from data or whether people wrote its rules, because the two need very different maintenance.
Machine learning and deep learning
The same Dataquest article describes deep learning as a subset of machine learning that uses artificial neural networks. Think of deep learning as one family of tools inside the wider field, not a replacement for it. Whether it is the right family for a given problem is a separate question, and the comparison of machine learning vs deep learning sets out what differs and when each approach earns its place.
Framing the task and choosing a learning style
The first decision is what you want the model to do, and the answer usually narrows the approach before any data is touched. Two broad learning styles cover most beginner projects. The difference between them is whether the examples come with answers attached.
According to Dataquest, a supervised model learns from labeled data, while an unsupervised model learns from unlabeled data. The scikit-learn statistical learning tutorial puts the same split in task terms. Supervised learning means predicting an output variable from high-dimensional observations, and unsupervised learning means seeking representations of the data. Put plainly, supervised learning answers “given this input, what is the output?” and unsupervised learning asks “what structure is hiding in these records?”
When supervised learning suits
Choose supervised learning when you already hold examples whose outcomes are known and you want predictions for new cases. The cost is the labels. Someone must have recorded the outcomes, and the quality of those records sets a ceiling on what the model can learn. If labels already exist as part of normal business records, this is the natural starting point for a beginner, because success is easy to define and easy to measure.
When unsupervised learning suits
Choose unsupervised learning when no outcome has been recorded and the aim is to explore, group or summarise. With no answer key, the results need human interpretation, so involve someone who understands the subject matter. It also works as a scouting step before supervised work, because it can show how the data is shaped before you commit to a prediction target. The comparison of supervised vs unsupervised learning places the two side by side with further examples.
Actions for this phase
- Write the goal as a sentence. Name the output you want, such as a category, a value or a grouping, so the task has a clear finish line.
- Check what you already hold. Records with the outcome attached point to supervised learning. Records without outcomes point to unsupervised learning, or to a labelling effort first.
- Define useful before you train. Decide what result would change a real decision, so you do not tune toward a number that nobody needs.
Gathering data and preparing features
Data preparation is where machine learning projects are won or lost. Harvard’s TinyML material states that a model is only as good as its training data, so a modest model on well-chosen data usually beats an impressive model on careless data. Treat collection as a design task, not a chore.
Making inputs usable
Models work on numbers, and raw records rarely arrive in that form. Dataquest notes that a machine learning model would not accept string data as input, so text-based columns must be converted into numeric values before training. Harvard’s material makes a related point about image-style inputs: they are flattened and filtered to help pick out the important features. In both cases the model receives a prepared representation of the data, not the original files.
Shaping the features
Dataquest calls the modification of features of the data feature engineering, and it is a main lever for improving results in classical machine learning. The same article says deep learning models do not usually require human intervention for feature engineering, which is one reason people associate that family with raw, unstructured inputs. For a beginner working with tidy records, hand-shaped features are usually the more accessible route. The guide on what is feature engineering goes further into practical techniques.
Actions for this phase
- Inspect the raw columns. List which are already numeric and which hold text, categories or free-form notes.
- Convert what the model cannot read. Turn text-based fields into numeric forms that preserve their meaning.
- Adjust or combine features. Reshape fields so the pattern you care about is easier to see, and keep a written record of each change so it can be repeated on new data.
- Look for gaps in coverage. Ask which kinds of cases are missing from the data before moving on, because a model can only learn from what it is shown.
Neural networks in plain terms
Neural networks are one family of models, and they are the engine behind deep learning. Harvard’s TinyML material notes that neurons and neural networks are used in machine learning models, so the idea sits at the core of much modern work. The beginner-friendly explanation in what is a neural network covers the building blocks in more depth.
A simple mental picture helps. A neural network is a stack of layers of small calculating units. Inputs enter at one end, each layer transforms what it receives, and a prediction emerges at the other end. The layers between input and output are called hidden layers. Dataquest explains that the depth in deep learning corresponds to the number of hidden layers a model could have, which is where the name comes from.
Choosing whether you need one
A neural network is not automatically the right choice. If your data is organised in rows and columns with understandable fields, begin with a plainer model and judge it on validation data. Move toward deeper networks when the inputs are rich and unstructured, or when hand-built features stop improving results. Starting simple gives you a baseline, and a baseline is what tells you whether added complexity is worth its cost.
Splitting data into training, validation and test sets
The MLU-Explain guide says best practice recommends splitting your data into three independent sets: training, validation and test. Each set answers a different question, and mixing their roles is the most common way beginners fool themselves. The article comparing training data vs test data adds further examples.
| Data set | Role | Planning use |
|---|---|---|
| Training | The dataset used to train the model and learn underlying patterns | Let the model see this data as often as it needs to |
| Validation | An independent, unbiased dataset for comparing the performance of different algorithms | Use it to choose between candidates and settings |
| Test | The dataset used to approximate the model’s unbiased accuracy in the wild | Keep it sealed until the final check |
The roles in this table are taken from the MLU-Explain train, test and validation guide.
The word independent matters. If the sets overlap, or if information from one leaks into another, the measurements stop reflecting how the model will behave on genuinely new cases. Make the split once, near the start, before you begin experimenting, so later choices cannot quietly bend it.
Actions for this phase
- Split before exploring. Set the test portion aside first and do not look at it again until the end.
- Keep the sets independent. Make sure no record or near-copy of a record appears in more than one set.
- Record how you split. Write down the method so the same division can be reproduced when you retrain.
Training and tuning the model
Training is the phase where the model learns from the training set. Everything it knows about the world comes from that data, which links back to the earlier point that a model is only as good as its training data. Tuning is the follow-on work of trying alternatives and settings to see what performs best.
The important rule is about where tuning feedback comes from. The MLU-Explain guide warns that if the same data is used for both training and tuning, the model will overfit and will not generalize well. That is why the validation set exists. It gives you an independent place to compare different algorithms without borrowing from the data the model has already learned from.
Actions for this phase
- Train a baseline. Fit a simple model on the training set so you have a reference point.
- Compare on validation data. Try alternative algorithms and settings, and judge each only on the validation set.
- Change one thing at a time. Alter a single feature or setting per attempt so you know what caused any improvement.
- Stop when gains flatten. Once extra effort stops improving validation results, freeze the choice and move on to testing.
Testing and the problem of overfitting
Testing is the single honest measurement in the workflow. The test set approximates how the model will perform in the wild, so its value depends entirely on the model never having influenced it. A careful reading here tells you whether the project is ready for real use or needs another round of work.
Overfitting is the main threat to that reading. Harvard’s TinyML material warns about overtraining, where the model only becomes good at identifying the inputs it has already seen. A model in that state can look excellent on its own training data and still disappoint on anything new. The article on what is overfitting in machine learning explains the mechanics in more detail.
The MLU-Explain guide adds a subtler warning: peeking at test set performance ahead of time is a form of overfitting. Each glance at the test score that influences a decision leaks information from the test set into the model. After enough glances, the score no longer measures anything independent.
Reading the result sensibly
Treat the test result as a single reading rather than a target to chase. If it is disappointing, return to the data and features, since those usually explain more than the choice of algorithm. Do not adjust the model until the test score looks acceptable, because that converts the test set into a second validation set and removes your last independent check. If you need a fresh unbiased estimate after heavy iteration, collect or reserve new unseen data.
Running models in production
A model that passes its test is not finished. Real-world data shifts, the people using the system change their behaviour, and the connections between the model and other software need looking after. Teams that treat deployment as an afterthought often find that a good prototype degrades quietly once it meets live inputs.
The discipline that deals with this is usually called MLOps, and the guide on what is mlops explains how organisations run machine learning reliably. For a beginner the lesson is about planning. Decide who owns the model after launch, how its performance will be watched, and how it will be retrained or retired. Those decisions cost little at the start and a great deal when ignored.
Choosing your starting point
Readers arrive at machine learning from different directions, and the sensible first move depends on which direction yours is.
- Business decision-makers: Focus on the data you hold, the decision a prediction would change and who will own the model afterward. Technical depth can come later, and the organisational guidance linked near the top of this page gives the wider context.
- Hands-on beginners: Pick a small supervised problem with labels already in hand, build a plain baseline and practise the three-way data split on it. Finishing one complete cycle teaches more than sampling many methods.
- Team leads and managers: Learn enough to ask pointed questions, such as how the data was split, what the baseline was and how the result will be monitored. Those questions expose most weak projects early.
Troubleshooting common problems
Strong training results but weak results on new data
This pattern points toward overtraining. Compare performance on the training set with performance on the validation set, and treat a wide gap as a warning. Simplify the model, widen the variety of training examples, or reduce the number of features, then compare again on validation data only.
Test results look too good to be true
Suspiciously high accuracy often means information has leaked. Audit whether duplicate or near-duplicate records appear on both sides of the split, and whether any preparation step was fitted using the full dataset before dividing it. If leakage is found, rebuild the split and repeat the evaluation.
The model rejects some of the data
Error messages that mention unexpected types usually mean a text-based column slipped through. Check the column types, convert the offending fields as described in the data preparation section, and rerun.
Predictions seem unfair to some groups
Harvard’s TinyML material cautions that if the data does not represent the people a system will serve, the system could have bias, which is not fair to some people. Examine who and what the training data covers, and review results separately for the groups affected. If a group is thinly represented, the remedy lies in better data rather than in more tuning.
Frequently asked questions
Does machine learning always need labeled data?
Show answer
No. Supervised learning needs labeled examples, but unsupervised learning works from unlabeled data and looks for structure instead of predicting a known outcome.
Can the same data be used to train and to judge a model?
Show answer
It should not be. Judging a model on data it has already learned from gives a flattering picture and hides overfitting, so keep separate validation and test data.
Is more data or better data the priority?
Show answer
Quality and representativeness come first. A model is only as good as its training data, so fix gaps and errors before collecting more of the same.
Where should a complete beginner start?
Show answer
Start with a small supervised problem where outcomes are already recorded, build a simple baseline, and complete the whole cycle from data preparation to a single final test.
