The Hard Part Isn't the Model, It's the Data

While designing TarımGöz I spent my first weeks on the wrong question: which model? The right question, it turns out, was this — what will this model actually see out in the field?

TarımGöz is an R&D project of mine that aims to diagnose plant disease from a photo of a leaf. I have not written a single line of code yet; I am still in the design and feasibility stage. But it is exactly at this stage that I realized the most critical decision in the project is not the choice of model, it is the data.

My initial plan was simple: there are labeled open datasets for plant diseases online, I train on those, then shrink the result down to a small model that runs on the device. The first half of that plan works. The second half — whether the model will actually work in a real field — is an entirely different problem.

The photo in the open dataset is not the photo a farmer takes

Most of the images in open datasets were collected under controlled conditions. The leaf has been picked, laid on a flat surface, lit evenly, and framed dead center. That is not because it makes a good dataset — it is because that is the cheapest way to collect data.

The photo that will come in from the field looks more like this: midday sun, half the leaf in shadow, soil and other plants in the background, slightly blurry because it was shot handheld, three leaves in frame at once, and one of them running off the edge.

I did not derive this table from theory. On 2.El Bilet, users uploaded photos of the tickets they were holding. That is where I saw how different incoming images can get: shot upside down, half covered by a finger, photographed off another screen. People do not take the photo the way you expect them to; they take it quickly, with the phone in their hand, wherever they happen to be standing.

The model learns the easiest cue, not the one you meant to teach

Here is the insidious part: the model can score very high on the open dataset without ever having learned the disease itself.

Say the photos of one disease class were mostly taken on the same day, on the same greenhouse table. The model may learn to tell that disease apart by the color of the table in the background rather than by the texture of the leaf. And because the validation set comes from those same conditions, the mistake stays invisible. Then, out in the field, on a leaf lying on soil, the model falls apart.

What transfer learning solves, and what it doesn't

Transfer learning is an indispensable part of the design. The data and the hardware needed to train an image model from scratch are not available at my scale. Teaching my own classes on top of a model already pre-trained on general images is far more realistic.

But transfer learning is not a fix for a data problem, it is a starting point. What it solves: I do not have to teach basic visual features like edges, textures and color gradients from zero. What it does not solve: whatever photos you showed your final layer, those are the kinds of photos the model will work on in the field. A pre-trained backbone does not turn a bad dataset into a good one.

Data augmentation: imitating the field, knowing its limits

When you only have a limited number of field photos, data augmentation is a sensible interim solution. The transforms I planned in the TarımGöz design came straight out of the table above:

• Random rotation and mirroring — nobody holds the leaf in the same orientation every time.
• Brightness and contrast jitter — to imitate midday sun and overcast weather.
• Partial shadow overlays — darkening one section of the leaf.
• Mild blur and noise — handheld shots and low light.
• Aggressive JPEG compression — images that have been through a messaging app.
• Random cropping — leaves running off the edge of the frame.

The limit here: augmentation does not produce diversity, it stretches the diversity you already have. If all you have are leaves of a single variety from a single region, you can rotate and darken every one of them and the model still will not have seen a leaf of another variety. Augmentation hides missing data; it does not replace it.

Staged data collection: accumulating data in a loop, not in one go

The "let me collect a big dataset first, then start" plan does not work on this project, because you only learn which photos are missing once the model starts getting things wrong. The loop I set up in the design goes like this:

1. A first version model trained on the open dataset. Low on claims, meant for learning.
2. Field use with a limited group of users. Every prediction asks a question: is this right?
3. Prioritizing the photos where the model hesitated or got it wrong.
4. Labeling those photos with expert verification and extending the set.
5. Retraining and comparing against the same evaluation set.

Collecting a hundred photos from the places where the model struggles is worth more than collecting a thousand at random. And for that, the model has to tell you where it is struggling — which brings us to the last piece.

A model that can say “I'm not sure”

A classification model produces an answer no matter what you show it. Hand it a photo of a shoe instead of a leaf and it will name the closest disease. For the user that is worse than a wrong answer: it is a wrong answer that looks confident.

So I built TarımGöz's decision flow not on a single prediction, but on a three-stage check:

karar(fotograf):
    kalite = bulaniklik_ve_isik_kontrolu(fotograf)
    eger kalite dusukse:
        -> "Bu fotoğrafı değerlendiremedim"
        -> nasıl çekileceğine dair yönerge göster
        dur

    tahminler = model(fotograf)      # one score per class
    en_iyi  = tahminler[0]
    ikinci  = tahminler[1]

    eger en_iyi.skor < ESIK:
        -> "Emin değilim"
        -> en olası iki seçeneği göster, uzmana yönlendir

    degilse eger (en_iyi.skor - ikinci.skor) < FARK_ESIGI:
        -> "İki olasılık birbirine çok yakın"
        -> ikisini de göster

    degilse:
        -> teşhis + güven seviyesi + doğrulama sorusu

ESIK and FARK_ESIGI are not fixed values; they are parameters to be tuned as field data accumulates. And these thresholds do not have to be the same for every class either.

Where the design landed

TarımGöz has not been written yet. But at the end of this design round I have a clear order of priorities, and the model is not at the top of it:

• First the data collection flow and the labeling discipline.
• Then a pre-check that assesses photo quality at the moment of capture.
• Then the decision logic and the interface that make an “I'm not sure” answer possible.
• The model last — because the model is the cheapest piece to swap out as the data changes.

This is exactly where the difference between building a demo and building a product lies in an AI project. A demo works with the clean photo you already have. A product has to work with the photo the user took in a hurry, in the shade. And what closes the distance between the two is not a bigger model, it is data that looks like that photo.

• R&D
• Artificial Intelligence
• Dataset
• Image Processing
• TarımGöz