A feature engineering experiment from my garden

Can AI tell good Ajvar from bad Ajvar?

This year, I grew vegetables, again.

Nothing particularly revolutionary about that.

Mostly peppers, and a few other things.

Then came the inevitable question: What do you actually do with all of it?

The answer, at least in this part of Europe, is obvious: Make ajvar.

But while standing by the fire pit, surrounded by roasted peppers, eggplants, oil, salt and several hours of work, I had another thought:

Could we build an AI system that tells us whether an ajvar is actually good?

Not whether the label looks premium.

Not whether the manufacturer claims it is “traditional”.

Not whether it costs €2.99 or €8.99.

I mean actually good.

And suddenly, a perfectly innocent jar of ajvar became a machine-learning problem.


Step 1: Define the problem

Every ML project starts with a deceptively simple question:

What are we trying to predict?

In this case:

Given a sample of ajvar, predict its quality.

Simple enough.

But immediately we have a problem.

What exactly is quality?

Is it:

  • taste?
  • texture?
  • smell?
  • color?
  • ingredients?
  • consistency?
  • smokiness?
  • sweetness?
  • saltiness?
  • how much bread disappears while testing it?

The last one might actually be the most reliable metric.

So let’s define a target variable.

Ajvar Quality Score

Let’s say our human experts rate every sample from 1 to 5:

ScoreClassification
1Why did you make this?
2Technically ajvar
3Quite acceptable
4Very good
5Hide the jar from everyone else

And because this is machine learning, we obviously need a metric.

Accuracy?

Precision?

Recall?

F1?

No.

I propose:

Grandma Approval Rate — GAR

GAR = percentage of samples approved by the most experienced ajvar expert available.

The methodology is still under peer review.


Step 2: Collect the data

Now we need training data.

And this is where things get complicated.

We could collect hundreds or thousands of ajvar samples from:

  • supermarkets
  • local producers
  • restaurants
  • family kitchens
  • farmers’ markets
  • industrial producers

And for every sample, collect the characteristics.

For example:

Sample_ID
Pepper_Sweetness
Pepper_Ripeness
Eggplant_Ratio
Roasting_Level
Smoke_Intensity
Oil_Ratio
Salt_Level
Acidity
Texture
Color
Cooking_Time
Ingredient_Quality
Human_Rating

Congratulations.

We have just turned ajvar into a dataset.


Step 3: Feature engineering

This is where things become interesting.

A machine-learning model doesn’t understand:

“This tastes like the ajvar my grandmother used to make.”

It needs numbers.

So we need to transform our real-world characteristics into measurable features.

Color

We could photograph every sample under controlled lighting and extract RGB or HSV values.

For example:

Red = 145
Green = 48
Blue = 22

We could potentially derive a Roasted Pepper Color Index.

Very scientific.

Probably.

Texture

Texture is more difficult.

We could measure viscosity or use image analysis.

Maybe:

Texture_Smoothness = 0.82

Although anyone who has ever argued about whether ajvar should be smooth or chunky knows that we have just opened another can of worms.

Ingredients

We could encode the recipe:

Pepper_Ratio = 0.72
Eggplant_Ratio = 0.18
Oil_Ratio = 0.08
Other = 0.02

And suddenly we have something the model can work with.

Roasting

This might be particularly interesting.

Roasting changes flavor significantly, but “perfectly roasted” is not exactly a binary variable.

So we might create:

Roasting_Level = 0–10

Where:

  • 0 = basically raw
  • 5 = properly roasted
  • 10 = carbon archaeology

Again, completely scientific.


Step 4: The problem with human judgement

And here we reach one of the biggest challenges in the entire project.

Who decides whether an ajvar is good?

Humans.

Which means our labels are subjective.

Imagine we have three experts.

Expert A prefers very smoky ajvar.

Expert B prefers sweeter ajvar.

Expert C thinks eggplant should barely be detectable.

We give them the same jar.

They return:

Expert A: 5
Expert B: 3
Expert C: 4

What’s the correct label?

4?

3.67?

Majority vote?

Weighted average?

Or should we simply remove Expert B from the dataset?

Probably not.

This is the same problem we encounter in many real-world AI systems.

The model is only as objective as the data and labels we give it.

If the underlying concept is subjective, the model isn’t magically going to make it objective.

It will learn our definition of “good”.


Step 5: Beware of data leakage

Now let’s introduce another classic ML problem.

Imagine our dataset contains:

Producer_Name
Region
Price
Packaging_Quality
Human_Rating

And it turns out that a particular producer consistently makes excellent ajvar.

Our model might learn:

“Producer X = good.”

Rather than actually learning anything about the ajvar itself.

Even worse, suppose our human reviewers know the producer.

They might subconsciously rate the product differently.

Now our model has discovered a fascinating new feature:

Brand Reputation

And suddenly we’re no longer measuring ajvar quality.

We’re measuring everything around ajvar quality.

That’s data leakage.

And it happens in real AI projects far more easily than we like to admit.


Step 6: Train the model

Once we have enough data, we can train a model.

Perhaps we start with something simple:

  • Logistic Regression
  • Decision Tree
  • Random Forest
  • Gradient Boosting

We don’t necessarily need a neural network.

In fact, using a neural network just because we can would probably be a great example of another common mistake:

Using a more complicated model doesn’t automatically make the solution better.

Our first model might look something like this:

Input
  ↓
Ingredient features
  ↓
Roasting features
  ↓
Texture features
  ↓
Color features
  ↓
Taste / sensory features
  ↓
ML Model
  ↓
Ajvar Quality Score

The output:

Quality Score: 4.6 / 5
Confidence: 87%
Classification: Excellent

Perfect.

We’ve solved ajvar.

Except we haven’t.


Step 7: Overfitting

Imagine we train our model using 500 samples produced by 20 families in Croatia and Macedonia.

The model achieves:

99.8% accuracy.

Amazing.

We deploy it.

Then somebody gives it a jar made in another country.

The model says:

Quality: 12%.

What happened?

Our model learned the training data extremely well.

It may have learned:

  • regional preferences
  • specific recipes
  • particular ingredient combinations
  • local roasting styles
  • even the characteristics of specific producers

Instead of learning the general concept of quality.

That’s overfitting.

And suddenly our beautiful 99.8% accuracy doesn’t mean very much.

This is why a good ML model needs to be tested on data it hasn’t seen before.

Preferably data from people who don’t know what our model was trained on.

And preferably ajvar that wasn’t made by my mother.

Because that introduces another serious statistical problem.

Family bias.


Step 8: Feature importance

Suppose our model eventually tells us:

Feature                    Importance

Pepper quality             31%
Roasting level             22%
Texture                    15%
Smoke intensity            11%
Salt level                  8%
Oil ratio                   6%
Color                       4%
Eggplant ratio              3%

This is actually useful.

It tells us something about what drives the prediction.

And perhaps we discover something surprising.

Maybe color doesn’t matter much.

Maybe roasting matters a lot.

Maybe the ingredient ratios we assumed were critical aren’t.

Maybe the most important variable is something we didn’t even think about measuring.

That is one of the interesting things about data-driven approaches.

They can challenge our assumptions.


Step 9: And then reality happens

After all this work, we finally test our model.

We put three jars in front of it.

Jar A:

Beautiful color.

Perfect texture.

Excellent ingredient ratios.

Model prediction:

4.8 / 5

Jar B:

Slightly darker.

A little more rustic.

Model prediction:

4.1 / 5

Jar C:

Something completely unexpected.

The model:

3.7 / 5

Then we taste them.

And everyone immediately agrees that Jar C is the best.

What happened?

Maybe the model doesn’t understand aroma.

Maybe our measurements are incomplete.

Maybe our labels were inconsistent.

Maybe the training data wasn’t representative.

Maybe there is a feature we haven’t discovered.

Or maybe…

we simply don’t know how to measure what humans are good at sensing.

And that is where this silly little ajvar experiment becomes much more interesting.


AI doesn’t eliminate the need to understand the problem

One of the biggest misconceptions around AI is that once we have enough data and a sufficiently powerful model, the system will figure everything out.

Sometimes it does.

Often it doesn’t.

Before we build the model, we need to understand:

What is the actual problem?

What does success mean?

What data do we need?

How do we measure the relevant characteristics?

How do we create reliable labels?

What biases exist in the data?

What could cause leakage?

How do we know whether the model generalizes?

What happens when the model is wrong?

These questions are not particularly exciting.

There is no impressive AI demo for them.

But they are often much more important than the model itself.


And what about the actual ajvar?

After all this analysis, I still had to make the ajvar.

Which involved:

🌶️ Growing the peppers.

🔥 Roasting them.

🫑 Cleaning them.

🍆 Preparing the eggplants.

🥄 Cooking everything for what felt like an eternity.

🧂 Adjusting the seasoning.

🫒 Adding oil.

👃 Tasting.

👅 Tasting again.

🥖 Testing with bread.

And eventually:

🫙 Filling the jars.

No machine learning model was involved.

At least not yet.


The real lesson

There is something strangely appropriate about using ajvar to explain machine learning.

You start with raw ingredients.

You transform them.

You measure things.

You make decisions.

You combine inputs.

You apply a process.

And eventually you get a product.

But the quality of the final product depends on much more than the individual ingredients.

The process matters.

The measurements matter.

The experience matters.

And perhaps most importantly:

You need to know what “good” actually means before you try to build a machine that predicts it.

That’s true for ajvar.

And it’s also true for AI products.

So, if anyone wants to fund the next phase of this research, I am currently looking for:

  • 1,000 jars of ajvar
  • a sensory evaluation laboratory
  • several machine-learning engineers
  • a data scientist
  • controlled lighting equipment
  • and approximately 47 volunteers willing to eat ajvar for science.

The last requirement shouldn’t be difficult.

Dataset collection starts next week.

Grandma Approval Rate™ will be the primary KPI.


So, what’s your favorite ajvar recipe?

Share this:

Leave a Reply

Your email address will not be published. Required fields are marked *