Most AI projects fail not on the technology but on a wrong turn taken right at the start: the wrong kind of method gets thrown at the problem. Classification where a rule would have done. An expensive language model where a simple regression would have been more accurate. This guide reverses the order: understand the problem first, then choose the method. And because that choice breaks down into a handful of simple decisions, you can answer it yourself below.
1. Find your method — in under a minute
Work through a few simple questions. At the end you’ll land on the method category that fits your goal, with a jump into the matching section further down. If you’d rather see the whole map at once, the button opens the complete decision tree.
Which method fits your problem?
Answer a few simple questions — you'll land on the method category that fits your goal, with a jump straight to the matching section.
Orientation, not a substitute for a real data analysis. In practice you often combine several methods.
Each question leads through simple choices to a method. Click a method to jump straight to the matching section.
The rest of the article explains each category in plain language: when it fits, an example, the most common pitfall — and, for those who want the detail, a short technical note for each.
2. Do you even need machine learning?
The most valuable question first, because it is the one most often skipped. Machine learning makes sense when a relationship lives in the data that cannot be written down as a manageable set of fixed rules. If it can, a rule engine is almost always better: ready immediately, no training, no data required, and anyone can see why it decides the way it does.
Example: “Invoices over €10,000 need a second approval” is a rule, not an ML problem. “Which invoices are likely to be wrong?” however is — that lives in patterns no human can fully write down.
Pitfall: deploying ML as a prestige project where ten if conditions would have solved it more robustly and transparently. More in Why AI projects fail.
For the technically minded: business rules, decision tables or a BPM/workflow tool. ML enters only once the rule set explodes or the edge cases turn fuzzy.
3. Predicting something (supervised learning)
You have historical examples where the right outcome is already known, and you want to predict that outcome for new cases. This is supervised learning — the best-understood and most-used ML family. Which of the four methods it becomes depends on what you predict.
Classification — predicting a category
Assigns each case to one of several known categories, or answers a yes/no question. Will this customer churn? Is this email spam? Which fault class does this defect belong to?
Pitfall: imbalanced classes. If only 1% of cases are “fraud”, a model that always says “no fraud” reaches 99% accuracy — and is still useless. Here precision and recall matter, not accuracy.
For the technically minded: gradient boosting (XGBoost, LightGBM) or random forest for tabular data; for text with few examples, often an LLM-based classifier rather than a classic model.
Regression — predicting a number
Predicts a continuous number instead of a category. What price will this property fetch? How high is demand next week? How long will this machine run before failure?
Pitfall: blurring the line with classification. Rule of thumb: if the answer can be meaningfully averaged, it’s regression; if it can only be counted, it’s classification.
For the technically minded: linear or regularized regression as an honest baseline, gradient boosting for nonlinear relationships. Always express the error in business units (euros, units), not just an abstract metric.
Time-series forecasting — future values over time
A special case of number prediction where temporal order is decisive: trend, seasonality and dependence on the recent past. Sales per week, server load per hour, stock per day.
Pitfall: treating time series with ordinary regression and ignoring the time structure — or “peeking” from the future into the past when testing.
For the technically minded: statistical models (Prophet, ARIMA, ETS) to start; for many series, gradient boosting on lag features or neural models. Always validate in time order (no random train/test split).
Anomaly & fraud detection — finding the rare
Here the point is not to sort into known classes but to spot the unusual — especially when there are barely any labeled examples of it. Suspected fraud, machine defects, unusual access.
Pitfall: too many false alarms. An anomaly system that cries wolf constantly gets ignored — the threshold must be tuned to the real cost per alert.
For the technically minded: isolation forest, one-class models or autoencoders when no labels exist; once enough fraud examples accumulate, a cost-sensitive classifier.
4. Finding structure in data (unsupervised learning)
You have data but no known outcomes — no labels. Instead of predicting something, you want to reveal the hidden structure. This is unsupervised learning.
Clustering & segmentation — groups without labels
Bundles similar cases into groups with no predefined categories. What natural customer segments exist? Which products are bought together?
Pitfall: clusters are a hypothesis, not a finding. The groups the algorithm finds must be interpreted by domain experts — otherwise you’ve segmented noise.
For the technically minded: k-means to start, HDBSCAN for irregularly shaped clusters; often better on embeddings than on raw data. You validate the number of clusters, you don’t guess it.
Recommender systems — what fits this user?
Suggests the most fitting products, content or actions per user or context. “Others also bought …”, personalized home pages, next-best-action.
Pitfall: the cold start. For new users or new products there is no history — you need a fallback, or the system recommends nothing or always the same thing.
For the technically minded: collaborative filtering and matrix factorization as the classics; modern variants via embedding-based similarity search.
Dimensionality reduction — condensing many variables
Condenses many variables into a few meaningful ones — to visualize, denoise, or as a preprocessing step for other methods. More of a tool than an end goal.
Pitfall: taking the reduced axes at face value. A pretty 2D map of high-dimensional data is a projection, not a truth — distances within it can mislead.
For the technically minded: PCA for linear structure, UMAP or t-SNE to visualize high-dimensional data. Often used as preprocessing before clustering.
5. Working with language & content (GenAI)
As soon as the material is text, images or audio rather than clean tables, generative AI comes into play — pre-trained models that understand language and content, often without any training data of your own.
Text understanding & extraction — sort and pull out
Classify documents or pull out structured fields — even when barely any labeled examples exist. Extract invoice line items, sort tickets by topic, search contracts for clauses.
Pitfall: relying on the LLM output without checking it against a fixed schema. Extraction needs validation, or plausible-looking but wrong values creep in.
For the technically minded: an LLM with clear prompts and a target schema; with many examples, a smaller fine-tuned model that runs faster and cheaper.
Generation, summarizing & chat
Produces new text, summarizes, or holds conversations — drawing on general language ability. Email drafts, summaries, a chat assistant.
Pitfall: generation without grounding. A language model phrases things fluently even when it’s wrong — where correctness matters, a knowledge source belongs alongside it (see RAG).
For the technically minded: a language model with clean prompting; on-premise when the data must not leave the building — which today even runs entirely in the browser.
RAG — questions over your own data
Lets a language model answer based on your own documents, without retraining it. The relevant passages are retrieved at runtime and handed to the model. Internal knowledge assistant, search across contracts and policies, customer service over your own docs.
Pitfall: most RAG problems lie not with the model but with the retrieval in front of it — poor chunking, missing re-ranking. More in RAG explained simply.
For the technically minded: retrieval-augmented generation — embeddings, vector search and re-ranking in front of the LLM. For knowledge questions, almost always a better first step than fine-tuning.
Image, audio & multimodal
Processes images, audio or video rather than text — recognizing, describing, transcribing or searching. Check goods-inwards photos, transcribe meetings, open up documents via OCR.
Pitfall: underestimating data quality. Blurry photos, background noise or poor scans hurt accuracy more than the choice of model.
For the technically minded: vision-language models, OCR pipelines, speech-to-text (e.g. Whisper) depending on the modality. More in Multimodal AI.
6. Actions & decisions
The final group predicts nothing and sorts nothing — it acts or decides. Here we even partly leave machine learning behind.
Agents & automation
Lets a model call tools and chain several steps to actually get tasks done, rather than just answering. Take in a request, look it up in the system, create an entry, send a reply.
Pitfall: giving an agent too much autonomy without guardrails. The more it may do on its own, the more clear limits and a human at critical points matter.
For the technically minded: tool / function calling, increasingly via MCP, with guardrails and approvals. Fundamentals in What is an AI agent?.
Optimization & reinforcement learning
When it’s about the best decision under constraints, often no ML models are needed at all. For a one-off optimal solution — routes, allocations, shift schedules — classic optimization (operations research) is the right tool. For ongoing control that learns from feedback, reinforcement learning comes into play.
Pitfall: reinforcement learning is powerful but expensive and delicate. Without a reliable simulation or plenty of feedback, a well-built heuristic beats the effort almost every time.
For the technically minded: linear/integer programming or constraint solvers for optimization; RL only when a simulation environment or a clear reward signal exists.
7. In practice you combine
The decision tree leads you to the dominant method — the one your project revolves around. But real systems usually consist of several building blocks: a document workflow combines extraction, RAG and an LLM. A forecasting system is backstopped by anomaly detection. A recommender uses clustering and classification under the hood.
More important than the perfect method choice on the first try is to start in the right main direction and to honestly check whether ML is needed at all. The rest you build iteratively. And if you’re unsure where your problem sits on this map: that placement is the first step of every good AI project — and a good reason for a conversation.
Frequently asked questions.
/ 01When do I use classification and when regression?
Both are supervised learning (you have examples with known outcomes). The only difference is what you predict: classification returns a category or a yes/no (spam or not, churn or not), regression returns a continuous number (price, demand, remaining lifetime). Rule of thumb: if the answer can be meaningfully averaged, it's regression; if it can only be counted, it's classification.
/ 02What is the difference between classic machine learning and GenAI?
Classic ML learns a tightly scoped prediction or pattern model from your structured data (classification, regression, clustering). Generative AI (LLMs, image models) is pre-trained on vast general data and produces new content or understands language and images, often with no training data of your own. For structured tabular data classic ML is usually more accurate and cheaper; for language, documents and images GenAI plays to its strengths.
/ 03Do I always need machine learning for an AI project?
No. If your decision can be written as clear, stable rules, a rule engine or a simple algorithm is almost always the better choice: faster, cheaper, transparent and needing no training data. Machine learning only pays off once the relationships are too complex or too fuzzy for fixed rules.
/ 04When do I use RAG instead of fine-tuning?
RAG (retrieval-augmented generation) feeds a language model the relevant passages from your documents at runtime — ideal for factual knowledge that changes. Fine-tuning adapts the model permanently and suits style, format and tone. For questions over your own data, RAG is almost always the first step.
/ 05Can I combine several methods?
Yes, and in practice that is the norm. A recommender uses clustering and classification under the hood, a document pipeline combines extraction, RAG and an LLM, a forecasting system is backstopped by anomaly detection. The decision tree helps you start with the dominant method — the others often follow as supporting building blocks.