E. AJALA / ML SYSTEMS

Open to ML systems engineering roles

I design reproducible experiments to understand ML systems.

I help ML engineers and AI research teams test engineering choices, measure trade-offs, and decide what works.

If your team makes engineering decisions from evidence rather than intuition, I'd like to contribute.

View my Investigations →
RAG Benchmark — latency vs. quality16 configs
MEDIAN LATENCY (ms) →QUALITY →F — selected

Controlled: reranker, generator count, query expansion. Measured: 432 x 3 runs across 16 configurations — full case study below.

Question

Start falsifiable

Every benchmark opens with a claim precise enough to be proven wrong.

Control

Isolate variables

Hold everything constant except the one factor under test.

Measure

Report the trade-off

Results show what to give up, not just what improved.

Investigations

Multi-Agent RAG System

Reducing hallucination in retrieval-augmented generation

Built a 7-agent pipeline stacking every known technique — HyDE, multi-query, reranking, parallel generation, consensus, verification. Then benchmarked 16 configurations, replicated three times and pooled into 1,296 runs, and found half of it wasn't earning its place — including one effect that looked huge on the first pass and mostly disappeared on replication. The winning setup is smaller than what I built.

  • Reranker
  • HyDE
  • RAGAS eval
  • 1,296-run benchmark
View full write-up →View repository ↗

Questions about this approach? Get in touch →

Scatter plot of median latency vs quality with a Pareto frontier line connecting non-dominated configs.

Pareto-optimal configs: P (fastest), D (middle ground), F (highest quality).

Early, but evidence-first

I'm early in my move into ML systems engineering. Before this, I worked as a technical content writer — which meant my job was taking complex systems and making them clear enough that someone else could reason about them, act on them, trust them.

That instinct carried straight over. I don't have years of production ML experience to point to yet, so I built my own evidence instead: benchmarks, failure analysis, and case studies that show how I think under constraints, not just what I've read about. Years of explaining other people's engineering decisions made me want to make my own — and be able to defend them the same way: with something measured, not just argued.

This portfolio is that habit, made visible. I'd rather show you a benchmark that overturned four of my own assumptions than tell you I'm passionate about AI.

Get in touch →
ResumeGitHubLinkedIn

Currently digging into

  • Distributed Training and Inferencing
  • Inference Optimization (Quantization)
  • Retrieval Systems (RAGs)

Tools I use

  • Python
  • PyTorch
  • TensorFlow
  • HuggingFace Transformer
  • Docker

Let's talk trade-offs

If your team makes engineering decisions from evidence rather than intuition, I'd like to hear what you're working on.