The ML Concepts Behind LLMs

I Why This Matters

You've sat in a meeting where someone said "we'll just fine-tune it" like they were ordering lunch. Or watched a vendor demo a 98% accuracy number that crumbled the moment it touched real data. These moments happen when builders don't speak ML — and they happen constantly.

You don't need to train models. You do need to call bluffs. The five concepts in this article — supervised learning, overfitting, train/test splits, fine-tuning, embeddings — are the vocabulary that separates builders who evaluate AI products from builders who just applaud demos.

II Supervised vs. Unsupervised Learning

Supervised learningmeans labeled examples. "Here are 10,000 emails. These are spam. These aren't. Learn the difference." The model sees inputs and correct answers, adjusts until it can predict labels on new examples. Your spam filter, your Netflix recommendations, your credit card fraud alerts — all supervised.

Unsupervised learningmeans no labels. You hand the model a pile of data and say "surprise me." Clustering customers by behavior, spotting anomalies in server logs. Useful when you don't even know what you're looking for yet.

LLMs pulled off an elegant heist: self-supervised learning. Take a massive text corpus, hide the next word, and train the model to predict it. The "labels" are baked into the text — no human annotation needed. That's how you train on trillions of tokens without labeling a single one.

III Overfitting & Generalization

Overfittingis the A+ student who memorized the textbook but can't answer a question that wasn't in it. The model aces its training data and falls apart on anything new. It didn't learn the pattern — it learned the answers. This is the single most common way ML projects fail quietly.

Generalizationis what you're actually paying for: a model that learned the pattern well enough to handle data it's never seen. A spam filter that catches novel spam. A sentiment model that works on yourcustomers' messy writing, not just the pristine training set.

There's also the opposite problem: underfitting. A model that's too simple to capture the pattern at all. A straight line trying to fit curved data. It fails on both training data and new data.

See the difference for yourself:

IV The Train/Test Split

If overfitting is the disease, the train/test split is how you catch it. Before training, you divide your data into three sets — and you guard that separation like a secret:

• Training set (~70-80%) — the model learns from this.
• Validation set (~10-15%) — used during training to catch overfitting early. Never trained on directly.
• Test set (~10-15%) — the final exam. Used once after training to estimate real-world performance.

Data contaminationis when the test set leaks into training — the ML equivalent of stealing the final exam. Scores look great. They mean nothing. And this isn't hypothetical: if an LLM's training data included your benchmark questions, every benchmark score it published is a lie.

V Fine-Tuning vs. Prompting

You have a pre-trained LLM and want it to do something specific for your product. You've got two levers, and most teams reach for the wrong one first.

Promptingis giving the model instructions at inference time — system prompt, examples, output format. No weights change. It's fast (minutes to iterate), cheap (no training compute), and fully reversible. But it has a ceiling: context window constraints, fragile complex instructions, and some tasks — matching your brand's exact tone, learning domain jargon — simply resist even the most clever prompts.

Fine-tuningis additional training on your data. Feed the model examples of the behavior you want and let it adjust its weights. It costs real money and real time. But a fine-tuned model doesn't follow instructions about how to sound — it actually sounds that way.

The tradeoff isn't always obvious. Test your intuition:

VI Embeddings & Similarity

Computers work with numbers. Text is stubbornly not numbers. Embeddingssolve this — they're a list of numbers that represent the meaningof text, not the characters. Similar meanings land close together in this number space. "Happy" and "joyful" are neighbors. "Happy" and "carburetor" are strangers.

You'll encounter embeddings everywhere, even if nobody calls them that:

• Semantic search— finding documents by meaning, not keywords. "How do I cancel my subscription" matches "Ending your plan" even though they share no words.
• RAG— grounding LLM responses in your data. Embeddings power the retrieval step. (More in the Grounding & Guardrails series.)
• Classification — sorting inputs by meaning. Cluster feedback into topics. Route tickets to the right team.

Explore how similarity works:

VII What's Next

You now speak ML well enough to be dangerous in a vendor meeting. Part 2 teaches what happens when you actually press "send" — how LLMs generate text one token at a time, and why that single mechanism explains everything these models can and can't do.