Skip to content
Selected work

Case study

Automated Leukocyte Classification

I worked with the R&D arm of one of the largest medical-biology groups in Alsace — more than 40 laboratories — building an in-house deep-learning model that classifies white blood cells from blood-smear images, as a decision-support tool for the biologists who review them.

Role
Data preparation, modelling, benchmarking
Domain
Medical imaging · haematology
Core stack
PyTorch · YOLO-cls · SigLIP2 · DINOv2
95.8%
macro F1
96.3%
accuracy
12
cell classes
28.4M
parameters
120ms
per image

Context

A full blood count is one of the most commonly ordered tests in medicine. An automated haematology analyser counts the cell populations and produces a first differential. When the numbers are coherent and nothing is flagged, the file continues through the normal validation path.

When something is off — a quantitative anomaly, an analytical inconsistency, an alert raised by the analyser — the sample goes to morphological review. A drop of blood is spread on a slide and stained so that individual cells can be examined: the shape of the nucleus, the appearance of the cytoplasm, the presence of granulation.

That examination is genuinely hard, and not because the people doing it lack skill. White blood cells mature continuously rather than in discrete steps, so morphological features do not change abruptly between one stage and the next. Cells sit at intermediate appearances; disease, individual variation and artefacts from slide preparation all shift how a cell looks. The boundaries between certain categories are therefore a matter of judgement, especially for immature or atypical cells — which is why two qualified operators, or the same operator on two different days, can legitimately disagree.

The problem

The laboratories already use a digital system that photographs the cells and proposes a pre-classification. It does not remove the review step. Someone still has to look at every pre-classified image, catch the errors, and confirm the final distribution — and on a busy technical platform that can occupy roughly four biologists and specialist technicians at once.

The work demands sustained visual concentration. Reviewing large numbers of images invites attentional fatigue, and fatigue lets incorrect classifications survive. Working through the data, I found mislabelled and inconsistent entries among the existing labels — some from genuine morphological ambiguity, some from variable image quality, some from human error at initial validation. That noise has to be found and cleaned before it reaches a training set.

There is a second, structural problem. The commercial model is a black box: its performance, its cell categories and its capacity to adapt are all determined by the vendor, and improvements arrive as software upgrades with costs attached. A laboratory that wants to classify according to its own taxonomy, on images from its own equipment, cannot get there through a supplier.

What I built

An in-house classifier trained on the laboratory's own validated images, so that the cell taxonomy, the training procedure and the evaluation criteria all stay under the laboratory's control. Owning the pipeline also makes error analysis possible — you can see which cells the model gets wrong and why, which a vendor system does not let you do.

The framing throughout was decision support, not replacement. The goal is a more reliable and more consistent first pass, so that a qualified reviewer's attention concentrates on the difficult and clinically interesting cells rather than being spent uniformly across every image.

The data

No public dataset. Every image comes from the laboratories' own routine activity, and only images that had passed human validation were retained: 39,037 images in total.

The original classification distinguishes a large number of categories, several of which correspond to successive maturation stages of the same cell line, with few examples each and boundaries that are hard to draw. Keeping them as independent classes would have deepened the imbalance and made learning harder for no clinical gain. Working with the biologists, I defined an operational taxonomy of 12 target classes, balancing biological relevance, usefulness in the laboratory's workflow, and the amount of data actually available.

Choosing the model

The objective was never the highest possible score. It was the best balance of accuracy, compute cost and inference speed — a model light and fast enough to actually run inside a laboratory's workflow.

I benchmarked eight configurations on the same test split with the same metrics: a YOLO-based classifier, two large self-supervised and vision-language backbones, a very large foundation model, plus ensemble and test-time-augmentation variants.

The compact YOLO classifier gave the best macro F1 of any single-pass model, at a fraction of the parameters of the largest architectures. Scaling the model up did not improve results on this data — the 431M-parameter foundation model finished last.

ConfigurationParametersAccuracyMacro F1
Ensemble: YOLO-cls + SigLIP2-Base121.3M96.37%95.82%
YOLO-cls with TTA ×628.4M96.06%95.80%
YOLO-cls — selected28.4M96.32%95.77%
Stacked ensemble121.3M95.59%94.98%
DINOv2-large304M95.44%94.15%
SigLIP2-Base92.9M94.92%94.03%
SigLIP2-Base, second config92.9M94.66%93.39%
C-RADIOv4-SO400M431M93.36%91.82%
Architectures evaluated on the same test split, by macro F1

Benchmarking against a competition solution

Comparing against a public cytology data challenge's leaderboard would not have been rigorous — different dataset, different taxonomy, different evaluation protocol, and a final score that doesn't correspond to the metrics used here.

So instead of comparing numbers, I took the code of the solution that placed third in that challenge, kept its core training techniques, retrained it on the internal dataset, and evaluated it on the same test partition with the same metrics. That makes the comparison mean something: same data, same classes, same measurement.

It came out ahead by 2.18 points of accuracy and 1.76 points of macro F1. One adaptation and one training run each, so it is a directional result rather than a statistically established one — which is why the eight-architecture comparison above matters more.

ModelAccuracyMacro F1
Competition solution, 3rd place94.14%94.01%
This model96.32%95.77%
Both models trained and evaluated on the same internal split

Results

96.32% accuracy and 95.77% macro F1 across the twelve classes, on held-out real images.

Inference cost

Latency decides whether any of this is deployable, so all configurations were timed in the same environment.

The selected model is both the fastest single model and the best-scoring one — a rare and convenient result. The ensemble and the test-time-augmentation variant edge it out on macro F1 by 0.05 and 0.03 points respectively, and cost 3.5× and 6× the latency to do it. That is not a trade worth making for a laboratory workflow, so the single model was selected.

ConfigurationLatencyFactorMacro F1
YOLO-cls — selected120 ms×195.77%
SigLIP2-Base299 ms×2.594.03%
DINOv2-large703 ms×5.994.15%
Ensemble: YOLO-cls + SigLIP2419 ms×3.595.82%
YOLO-cls with TTA ×6720 ms×695.80%
Inference latency per image against macro F1

More projects

The rest of the work.

02

The Link

I worked with one of the largest residential landlords in Alsace, where every department held its own data, used it for its own tasks, and could not see past its own boundary — with basic reporting rented from outside vendors. Before any modelling was possible, I spent weeks mapping what each department held and what it needed, and joining those sources into one base covering the whole estate.

  • Python
  • pandas
  • SQL
  • Data integration
Read the case study
13
variables catalogued into one base
03

The Value

Chapter two of the same engagement: with the data finally joined, modelling what actually sets rent per square metre.

  • scikit-learn
  • SciPy
  • Web scraping
  • Forecasting
Project complete — write-up in progress
60%
of predictive weight in one financing rule
04

AI Assistant for Cross-Continental Freight

An AI chatbot for a large startup moving cargo between Europe and the Gulf states, built around the way freight actually gets booked, tracked and chased across two regions and several time zones.

  • LLMs
  • Conversational AI
  • Logistics
In progress
Report coming soon — the work is still running
Back to the homepage