Artificial Intelligence vs Machine Learning vs Deep Learning
Understand the relationship between AI, machine learning and deep learning, and choose an appropriate approach for a real task.
No prior AI knowledge needed. Reading time is an estimate; allow extra time for practice.
What you’ll learn
- Explain how AI, machine learning and deep learning relate without treating them as interchangeable.
- Distinguish hand-written rules from parameters learned from examples.
- Use a support-ticket example to identify labels, ambiguity and model limitations.
- Compare candidate approaches using separate evaluation data and the consequences of mistakes.
- Choose a useful baseline and protect private information before experimenting.
On this page
Three terms, different scopes
Artificial intelligence is a broad field concerned with systems performing tasks such as reasoning, perception and language use. Machine learning is one approach within that field: instead of specifying every decision as a rule, we fit a model using examples or experience. Deep learning is a family of machine-learning methods built around neural networks with multiple processing layers. The terms overlap, but they are not interchangeable.
A search algorithm that plans a route can be part of an AI system without learning from examples. A small model that predicts delivery time from distance and traffic is machine learning without necessarily being deep learning. A neural network that recognizes objects in photographs is a common deep-learning application. None of these labels guarantees quality or human-like understanding.
Think of the relationship as nested scopes: deep learning belongs within machine learning, which belongs within AI. “AI” does not mean only chatbots. Nor does every automated if statement deserve the label. The useful question is how a particular system makes its decisions, not how its marketing describes it.
Start with a support-ticket task
Suppose you want to route support tickets to Billing or Technical Support. A rules baseline might look for the word “invoice”. A learned classifier instead uses previously labelled tickets to find useful patterns. A large language model could also classify a ticket from an instruction and examples, but its flexibility introduces costs and failure modes that a small classifier may avoid.
Write down what a correct result means before choosing an approach. If a ticket mentions an invoice page that crashes, which team should receive it? Ambiguous labels cannot be repaired merely by using a larger model. Resolve the routing policy with the people who will use the output, and keep an “uncertain” route for cases that need review.
function routeTicket(text) {
return /\binvoice\b/i.test(text) ? 'billing' : 'review';
}
// Fictional tickets and a policy agreed before checking the rule.
const cases = [
['Please resend my invoice', 'billing'],
['Please send a receipt', 'billing'],
['The invoice page crashes', 'technical'],
['Can you help?', 'review'],
];
let correct = 0;
for (const [text, expected] of cases) {
const actual = routeTicket(text);
if (actual === expected) correct += 1;
console.log({ text, expected, actual });
}
console.log(`${correct}/${cases.length} match the policy`);Run this in a browser console or Node.js; it makes no network requests. The result is 2/4. The receipt needs Billing but goes to review, and the crash needs Technical Support but goes to Billing. The regular expression checks for the English word “invoice”, ignoring case. It does not understand the request or learn when you add more examples.
What changes when a system learns?
For a supervised classifier, each training example pairs an input ticket with a label: the agreed destination. Features are the numerical inputs a model uses, such as word counts. Parameters are values fitted during training, such as weights that increase or decrease a category score. A training procedure adjusts those parameters to improve an objective. People still choose the task, data, labels and evaluation criteria.
A conventional text classifier might learn weights for words rather than rely on one manually chosen keyword. It can still learn a misleading shortcut: a signature used only by the old Billing team may correlate with the label without explaining the customer’s problem. Learning from examples is not the same as learning the intended policy.
Deep neural networks use multiple layers of learned transformations. For text, a system first represents input numerically, then combines those representations through layers. Nonlinear activation functions let networks represent relationships that a stack of linear operations alone cannot. You do not need to implement those calculations to compare candidate systems, but the layers do not guarantee understanding or correctness.
Supervised classification is our example, not the definition of all ML. Other learning setups can discover patterns without destination labels or learn from rewards. A pretrained language model has already learned parameters elsewhere; asking it to route a ticket normally uses those parameters at inference time. Supplying a new prompt is not itself retraining the model.
Compare on the work that matters
Collect a separate set of realistic tickets and their agreed destinations. Compare the rule and candidate models on the same set. Count expensive mistakes separately: routing an urgent account-security issue incorrectly may matter more than delaying a routine invoice request. Measure latency, operational cost and the proportion sent for human review as well as accuracy.
Include new wording, multiple languages if supported, short requests and conflicting details in the evaluation. Check whether mistakes cluster around a particular template or product area. A score on yesterday’s clean examples does not establish performance on tomorrow’s customers.
The four tickets above expose specific failures; they are too few to estimate production quality. Keep training examples separate from evaluation examples. Use a validation set while choosing rules or model settings, then a separate test set for the final comparison. If you keep changing the system to match the test tickets, they are no longer an independent final check. Avoid splitting copies of the same conversation across these sets.
Use the least complicated adequate system
Deep learning often helps with complex representations such as language or images, but it is not automatically the best answer for a small structured dataset. Consider rules, search, statistics and conventional software first. Learned systems bring data maintenance, evaluation and monitoring work alongside the implementation.
Ask what happens when the system is wrong. Suggestions that a person checks can tolerate different errors from actions that change an account. The surrounding product, its permissions and its fallback behaviour are as important as the model family.
For the ticket router, begin with suggestions a support agent can correct. Keep a review path for unclear tickets. Compare simpler rules, a small classifier and a larger model on the same agreed task before adding complexity. There is no universal amount of data, network depth or accuracy score that makes one approach best for every application.
Keep the experiment safe and useful
Support tickets can contain email addresses, account details, passwords or access tokens. Use fictional tickets for practice. For a real evaluation, minimise and sanitise the data, check permission to use it, and review any external provider’s processing and retention terms before sending it. Removing a name alone may not remove identifying details elsewhere in a message.
A destination prediction should not authorize a refund, reveal account data or change permissions. Enforce those rules in application code. If you use a language model, ticket text is untrusted data: a customer’s message must not gain authority by telling the model to ignore your instructions.
- Define the routing policy and examples before picking a model.
- Inspect the actual wrong destinations, not just an overall score.
- Test realistic new inputs and keep a useful human-review fallback.
Try it yourself
Design three ticket examples that defeat the invoice rule. Decide whether better rules, a trained classifier or human review would address each failure.
Show hint
Include a synonym, a mixed request and a request with too little information. A useful answer explains the trade-off rather than choosing deep learning for every case.
Check your understanding
4 questions to revisit the ideas. No score is saved, and you can retry. This is separate from Skill Quiz; it does not award XP or unlock guides.
Related programming documentation
Sources & further reading
Primary references for the concepts in this guide. Examples and exercises are illustrative; verify provider-specific behaviour against the version you use.