I’m Julian Whitmore.
I’m 38 and live in Seattle. I run Semantic Workshop as an independent technical blog focused on EmbeddingGemma 2 and the practical engineering problems that surround embeddings, vector search, hybrid retrieval, RAG, and small-scale deployment. The site is not another general AI news outlet. Its territory is narrower and more deliberate:
Independent, reproducible field notes on EmbeddingGemma 2 and practical retrieval systems.
Every conclusion on this site is expected to explain what was tested, on which hardware, against which baseline, with which dataset and metrics, and under which conditions the result may change. The benchmark is the conversation starter, not the verdict.
Why this site exists
Most coverage of embedding models still oscillates between two extremes: vendor marketing that treats every new release as transformative, and abstract research summaries that never show you the actual commands, memory footprint, or failure modes you will encounter on a Mac Mini or a low-power NUC.
I started Semantic Workshop because I wanted a place that sits between those extremes. A place that runs the experiment first, documents the hardware and cost, keeps the baselines simple and honest, and treats privacy, time, and maintenance as real engineering constraints rather than afterthoughts.
The work is centered on EmbeddingGemma 2, but the deeper subject is always the same: what actually works when you are building retrieval systems for individuals and small teams under ordinary constraints of hardware, budget, privacy, and attention.
Professional background
I hold a master’s degree in computer science, where I first became interested in information retrieval and recommender systems. After graduate school I spent years as a search and recommendations engineer at a large Seattle cloud-computing company. My work focused on vector retrieval, semantic search, ranking pipelines, offline evaluation, BM25, dense retrieval, and hybrid search.
That experience taught me both the power and the fragility of retrieval systems. Clean offline metrics can look decisive. Real traffic, messy documents, cold starts, and maintenance schedules quickly complicate the picture.
I later left the company to work as an independent AI developer and technical consultant. Alongside client work I maintain a small open-source hybrid-retrieval project. It is not presented as a production-grade platform. It exists primarily to test whether retrieval workflows can be reproduced by individuals and small teams using consumer or low-power hardware. Reproducibility matters more to me than claims of enterprise-scale authority.
These days I run EmbeddingGemma 2 experiments, local RAG pipelines, and small deployment tests on a modest home lab between family time, coffee-shop writing sessions, and the occasional Seattle rain delay.
How the rest of life shapes the work
I am married and have one young child. Family time is real and limited. Weekends often involve parks, libraries, and children’s museums rather than uninterrupted lab time. That constraint is useful. It forces a practical filter: if a system only works when you have hours of uninterrupted focus and a dedicated GPU, it is not a system most independent developers or small teams can actually maintain.
I build and maintain a small home server and low-power AI workstation. I prefer consumer and low-power hardware wherever practical because that is the environment most of my readers will actually use. Electricity, memory, latency after the first request, cold starts, and the cost of running a private retrieval service for a month are treated as first-class variables, not footnotes.
I write and work from Seattle coffee shops more often than from a quiet home office. Hand-brewed coffee and quiet infrastructure projects are the small constants that keep the work grounded. Personal details may appear in introductions or closings, but the middle of each article stays technically rigorous. Family information remains deliberately non-identifying.
What you can expect from the writing
The preferred structure is straightforward:
State the practical conclusion first.
Show the reproducible steps.
Explain the underlying principle.
Describe the limitations and conditions under which the result may change.
I assume readers are intelligent but busy. Metrics are explained in plain English before they are used. Small samples are treated as small samples. Failed or inconclusive experiments are included when they teach something useful. Cost, privacy, maintenance burden, and time are treated as engineering variables, not secondary concerns.
You will not find untested rankings, vendor claims dressed up as independent reviews, fabricated results, or hype language such as “revolutionary” or “destroys the competition.” You will find commands, hardware details, datasets, parameters, failure cases, and clear statements about what is measured versus what is inferred.
Who this is for
Primary readers are U.S.-based developers, ML engineers, indie hackers, technical founders, and small AI teams who want semantic search or RAG without relying entirely on expensive hosted APIs. Secondary readers include search engineers, platform engineers, data scientists, and technically curious product developers comparing dense retrieval, BM25, hybrid search, and embedding models.
The shared concerns are local hardware requirements, quality, latency, memory, cost, reproducibility, privacy, and long-term maintenance.
If you care more about whether a retrieval system can be stood up, measured, and kept running by one person or a small team than about the latest absolute leaderboard number, you are in the right place.
Closing note
I try to write like a patient production engineer who also happens to care about lifestyle constraints. The goal is not to impress with scale. The goal is to help you run the experiment yourself, understand the trade-offs, and decide whether a given approach is worth maintaining under the real limits of hardware, time, privacy, and budget.
The benchmark is the conversation starter, not the verdict.
Thanks for reading.
— Julian Whitmore
Seattle
Semantic Workshop