A few weeks ago I was in São Paulo, Brazil. I went to a local grocery store and picked up some chocolates. The ingredients list was in Portuguese, a language I do not know. I took a picture, sent it to an LLM, and said: translate this. Five seconds later, done.
Recently I was revising slides for a patent disclosure. I had a list of changes that would have taken hours to make manually. I prompted the LLM with what I needed, went through a few iterations, and finished before my coffee got cold.
The point is not that I am clever. The point is that LLMs have become a commodity. We all use them for dozens of things every day.
But here is what I actually want to tell you.
When you have a business problem. When you need to get deep analytics from your data. When someone asks you to build something that will run in production and make decisions that matter. Is an LLM always the right tool?
The answer is no. And treating an LLM like a Swiss Army knife, something you reach for by default no matter the task, is the fastest way to build something that breaks.
The IKEA toolbox
About 12 years ago I walked into an IKEA in Canada and bought a toolbox. It had a hammer, a set of screwdrivers, pliers, the usual. One box, many tools.
Here is the thing about that toolbox. You do not use the hammer for everything. If you need to unscrew something and you grab the hammer, it is not going to do the job. It is going to push it in harder. You need a screwdriver.
That is how a lot of people are using LLMs right now. They have a problem, they know LLMs are powerful, so they reach for the LLM. Sometimes it works. Sometimes it kind of works but takes ten times the effort it should. And sometimes it fails in ways they do not even notice because the output sounds confident enough.
An LLM is one tool. A powerful one. But it is not the only tool, and it is not always the right one for the task in front of you.
The real skill is knowing what set of tools you have access to, and which one is likely to be the best fit. Then making a judgment call and starting there.
What is a model, anyway?
Most of the AI models in use today are created from data. You collect data. You run it through a learning algorithm, of which there are many. The algorithm, paired with the data, produces a model. That model becomes a reusable tool. You feed it new data and it gives you output.
If the training data changes, you retrain or refresh the model. Simple enough.
The models I want to walk through today fall into two broad camps. The dividing line is what kind of data you are dealing with.
The two data worlds
The data around us can be split into two categories.
Structured data. This is the kind you store in a database like Db2. It has a fixed schema. Rows and columns. You know exactly what each column holds: employee name, employee age, department, hire date. It can also live in a CSV file or a spreadsheet. But the shape is defined and consistent.
Unstructured data. PDFs, emails, web articles, videos, images. No fixed schema. You can store a PDF in a database column, sure. But you are just storing it. You cannot query into it. You cannot ask the database to find the paragraph that answers a specific question. The data has no shape the database can reason about.
Different data, different models.
For structured data, there are well established model families. Classification. Regression. Clustering. These have been around for decades.
For unstructured data, we lean on pre-trained models. These are the ones big tech companies have spent millions of dollars training on massive volumes of internet data. Some live behind paywalls, like the models from Anthropic or OpenAI. Many others are available on Hugging Face. You can download them, run them locally, build on top of them.
And because these pre-trained language models are so powerful and freely available, they are starting to blur some lines. We are seeing applications of these models even for structured data problems. You will see an example of that in a minute.
The structured data toolbox
If your data lives in rows and columns, three model families cover most of the problems you will face.
Classification. You have data coming in, and you want to put it in the right bucket. Your email inbox does this every day. Incoming emails get classified as spam or not spam. A customer list gets split into tiers. High risk of churn versus low risk. Classification works when there is a predefined set of categories and your job is to assign each row to the right one.
Regression. You want to predict a number. House prices. Stock prices. How much a customer is likely to spend on their next visit. You have a set of features about each record and you want to predict a numerical value.
Clustering. What if you have the features but no labels? Nobody has told you what the categories are. You just want to know if there are natural groupings in the data. Maybe you have a stack of books and you are deciding how to organize them. By topic? By publication year? By technical versus non-technical? There is no single correct answer.
Classification and regression are both supervised learning. You give the model inputs and the known outputs, and it learns to produce more accurate outputs over time. Clustering is unsupervised. You give it only the inputs and ask it to find the patterns.
An example regression model
Let me make this concrete.
A few weeks ago I built a demo for a talk. I had a table of 48,000 customer records. For each customer, I had some attributes: age, gender, a few other details. And for a large subset of those customers, I also had their spending amount.
The goal was simple. Train a model that could predict how much a customer would spend, given only their attributes.
I did the entire thing inside Db2. Create a table. Call six stored procedures. That is it. The model trained, evaluated itself against a held-out portion of the data, and gave me an accuracy of about 92%. It was off by roughly $10 in either direction.
Watch this demo of a regression model I built using SQL.
When keywords are not enough
Let me shift to unstructured data, because this is where things get interesting.
Imagine you are back in university. You walk into an exam. The professor hands you a ten-page article, maybe 50 paragraphs total, and a list of questions. It is an open-book exam and you have tight time. What do you do?
You read each question. You pick out some keywords. You hit Control-F and search the document for those keywords. You find the matching passages, read them, and write your answer.
That is how text retrieval has worked for decades. Keyword search. It is precise. It can do exact matching, synonym expansion, all of that. But it has a fundamental limitation: it sees parts, not the whole. It is looking at individual words and phrases. It does not understand what a paragraph is about overall.
Now imagine the questions use words that do not appear in any of the paragraphs. Yet the answers are definitely in there. Keyword search fails completely. You would have to read every paragraph, make sense of each one, and find the answer yourself. That takes real thinking.
This is where embedding models come in.
How embeddings see the whole paragraph
An embedding model is a language model that has been trained on a massive volume of text. Its job is different from an LLM. Instead of generating a response, it converts text into numbers. A numerical fingerprint.
What it does is take an entire paragraph, as an example, look at it as a whole, and compress all the information it can into a fixed set of numbers. That numerical fingerprint captures the overall meaning of the paragraph. The topic, the theme, the concept. Not the individual words. The global sense of it.
Now take your exam question. Feed it to the same embedding model. It maps the question into the same numerical space. Then you do some vector math. In that vector space, which of the paragraph vectors is closest to your question vector? That is likely where your answer lives.
Think of the embedding model as an interpreter. When I travel and do not speak the local language, I use Google Translate. It takes what I say and projects it into a space the other person can understand. The embedding model does the same thing. It projects paragraphs and questions into a shared numerical space and looks for matches.
Here is the tradeoff. Keyword search sees parts but not the whole. Embeddings see the whole but not the parts. The real power comes when you combine both. Do a keyword search for precision, do a vector search for semantic understanding, and merge the results. That is what modern search applications do.
Product recommendations with vectors and SQL
This blurring I mentioned earlier, where pre-trained language models start solving structured data problems. Here is an example.
Say you have a database table of shoes. Each row has attributes: material, color, style, a few other details. You want to build a recommendation engine. When a customer looks at a particular shoe, show them similar ones.
The traditional approach would take a data science team months. They would need to design a specialized model, figure out the right formula, tune it, test it.
But now we have access to pre-trained language models. You can take all the attributes of a shoe, combine them into a single text description, and send it to an embedding model. The model gives you back a vector for that shoe. Do that for every shoe in your catalog. Store the vectors alongside the relational data. Now, when someone looks at a shoe, you search for other shoes whose vectors are closest to it.
The beautiful part is you can also apply relational filters before you search. Only show me shoes available in a specific store. Only show me shoes in a particular size. Filter first, then search the vectors. That is the advantage of doing this inside a relational database.
Which model when?
You do not need to memorize a taxonomy. You need a simple decision process.
If your question is about individual rows and columns and you want to find a category: start with classification.
If you want to predict a numerical value from a row: start with regression.
If you have rows of data and you want to find natural groupings, with no predefined labels: start with clustering.
If you are dealing with text or images and you want to find similarity matches: try embeddings.
If you have text and you want to generate content: that is where text generation models, the LLMs we all know, come in.
These are starting points. Not rigid rules. As you dig into a problem, you might find that combining techniques works better. But this framework gives you a place to begin.
The skill is knowing the toolbox
LLMs are one tool. A powerful tool. I use them every day, and you do too.
But the skill is not about knowing one tool really well. The skill is understanding the full set of tools you have, and making a judgment call about which one fits the problem in front of you.
The next time someone tells you to solve a problem with an LLM, ask yourself: am I holding a hammer when I need a screwdriver?
Start with the data. Look at what kind of answer you need. Then pick the model family that matches.