Projects

Selected work

A mix of applied AI tooling, academic research, and data-science work. Tap any card to dig in.

AI Tooling · Claude Code · MCP

AI Feature Request Triage

336 feature requests actioned in 5 hours. A Claude Code toolkit + MCP server, co-built with one partner as our two-person initiative, that turns a months-long marketplace cleanup into a single sitting, with explicit human approval before any write.

GitHub →

Marketplace boards collect thousands of open feature requests: duplicates, support questions in disguise, requests already fulfilled by a shipped release, and items years old with no remaining interest.

Five detection passes run in sequence, each waiting for your approval before writing back:

/detect-completed: already fulfilled by a shipped release or documented feature
/detect-duplicates: covers the same ground as another open request
/detect-spam: promotional links, gibberish, off-topic
/detect-support-requests: troubleshooting questions filed as features
/detect-stale: older than three years with two or fewer votes

Engineering decisions

Disk-backed working set so Claude’s context never holds hundreds of items at once.
Per-phase subagents that chunk internally and return only a compact flagged list, keeping the main thread light.
Resumable per request. Every write is logged immediately, so disconnects, machine crashes, or context compaction can pick up exactly where they stopped.
Two-mode duplicate detection. Fast TF-IDF for a first pass; in-depth uses bi-encoder embeddings + cross-encoder rerank for precision.

Stack: Claude Code · MCP · Python (scikit-learn, sentence-transformers) · WooCommerce REST API

Master’s thesis · Deep learning · Hasselt

A standardised benchmark for activation-based CNN pruning

14 pruning methods × 3 ratios = 42 runs under one fair protocol. A custom evaluation framework, an interactive visualisation suite I designed (architecture walkthrough, results dashboard, per-filter explorer), and new local-budget variants (NISP-L, AOFP-L) that isolate scoring quality from cross-layer budget allocation.

GitHub → Interactive architecture → Interactive results → Pruning explorer →

Comparing structured-pruning methods across the literature is hard because published numbers conflate the scoring criterion with each paper’s bespoke fine-tuning recipe. I designed a single, method-independent protocol (one-shot pruning, ten fine-tuning epochs, three ratios r ∈ {0.3, 0.5, 0.7} on VGG-16 / CIFAR-10) and ran every method through it identically.

My contribution

The framework. A reusable benchmark harness: shared data loaders, calibration set, training/fine-tuning protocol, and metric reporting so any new method can drop in and be evaluated under identical conditions.
Local-budget adaptations. I extended NISP and AOFP into local-budget variants (NISP-L, AOFP-L) so the contribution of the scoring criterion can be measured separately from the cross-layer budget allocation.
Cross-method consensus analysis. A new lens for evaluating pruning methods: how much does each method’s filter selection deviate from the cross-method consensus, and how does that correlate with final accuracy?

The twelve methods I implemented

Each one re-implemented from the paper to plug into the shared harness:

ApoZ (Hu et al. 2016) – prune channels with highest % zeros post-ReLU
DropNet (Tan & Motani 2020) – mean absolute post-ReLU activation
Entropy (Luo & Wu 2017) – Shannon entropy of activations
HRank (Lin et al. 2020) – average rank of feature maps (SVD)
CHIP (Sui et al. 2021) – channel independence (nuclear norm)
LRMF (Zhang et al. 2023) – DCT low-frequency pairwise distance
NISP (Yu et al. 2018) – propagated importance from final response layer + my NISP-L local variant
ThiNet (Luo, Wu & Lin 2017) – next-layer reconstruction, greedy
GFS (Ye et al. 2020) – single-filter loss contribution
AOFP (Ding et al. 2019) – damage isolation (ablation + next-layer deviation) + my AOFP-L local variant
DCP (Zhuang et al. 2018) – class discriminability
REPrune (Park et al. 2024) – representative filter selection

The architecture I pruned

VGG-16 (ImageNet-pretrained, adapted to CIFAR-10). Thirteen conv layers, width-sized below to show the filter-count profile of 64 → 128 → 256 → 512:

C164

C264

C3128

C4128

C5256

C6256

C7256

C8512

C9512

C10512

C11512

C12512

C13512

Interactive architecture → Interactive results → Pruning explorer →

Cross-method consensus heatmap at r = 0.5 across the 13 conv layers of VGG-16. Red = every method prunes a filter, blue = every method keeps it, white = methods disagree. — Cross-method consensus at r = 0.5: one of the lenses the framework enables. Middle layers (C5 to C7) show high agreement; the final conv layer (C13) is the most disputed.

Stack: Python · PyTorch · CIFAR-10 · VGG-16 · 12 re-implemented pruning criteria + 2 local-budget variants

Industry collaboration · Data engineering + ML

SmartChain: predicting missed sales for Febelco

Recall 0.82 · F1 0.78 · ROC AUC 0.73 on a real-world missed-sales classifier built for Belgium’s largest pharmaceutical distributor. We organised messy transactional data across three distribution units, designed a clean schema, trained an XGBoost model, and shipped a Streamlit demo the business could actually click through.

In partnership with Febelco (Belgium’s pharmaceutical distribution leader), our MSc team picked up a real operational problem: orders that get flagged as “missed sales” when inventory runs out or fulfilment slips. The questions were practical: can we predict which orders will miss before they happen, and what drives those misses?

What we built

A data layer. Cleaned and organised raw transactional data across multiple distribution units (Zolder, Brugge, Kortenberg), imputed missing values with K-means in parallel chunks, and designed a schema the dashboards and models could share.
A missed-sales classifier. An XGBoost model predicting whether an incoming order will be flagged as a missed sale, with feature engineering on time-based and product-quota features. Random Forest evaluated as a baseline.
Two Streamlit dashboards. A missed-sales overview across units, plus a per-product drill-down for the supply-chain team.
A live demo the business team could click through to score a hypothetical order in real time.

Screenshot of the SmartChain XGBoost Order Classification Demo built for Febelco. Input fields for product key, quantity, customer number, quota product, prices, customer type, and order type, with a Predict button and XGBoost metrics shown beneath (accuracy, precision, recall, F1, ROC AUC). — The XGBoost Order Classification demo: predict whether an incoming order will be flagged as a missed sale, complete with metrics for the trained model. Recall of 0.82 means we catch most missed sales in the held-out set.

Stack: Python · XGBoost · scikit-learn · pandas · Streamlit · R (data cleaning + imputation)

More

More on my GitHub. Team and personal experiments, smaller tools, and exploratory notebooks.

github.com/IliaDi → · ← back home