Interpretable embeddings: semantic search that can explain itself

Embeddings are the workhorse of modern semantic search: turn text into a vector, compare vectors, and suddenly your system understands that a post about payroll deadlines is relevant to a question about paying staff, even though they share no keywords. The catch is that the similarity score is a bare number. Ask why two things matched and the honest answer is a shrug: the cosine similarity was 0.83.

For the AI infrastructure we built at Business111.com, a shrug was not acceptable. Editors needed to see why the system proposed distributing an article to a particular professional community. So we built semantic matching that explains itself — and the technique is general enough to reuse anywhere embeddings are used.

What an embedding is, in plain English

An embedding model reads a piece of text and produces a long list of numbers — a point in a high-dimensional space — positioned so that texts with similar meaning end up close together. Modern embedding models produce vectors of about 1,500 dimensions. None of those dimensions means anything a human can name. That is precisely the interpretability problem.

Two vectors per document

Our approach stores two vectors for every piece of content:

• The raw embedding — the full-dimensional vector straight from the embedding model. This is what powers fast ranking: Elasticsearch kNN (k-nearest-neighbours) search finds the closest candidates in milliseconds.
• The concept projection — the same embedding projected onto a hand-curated vocabulary of roughly 380 named business concepts: VAT, payroll, hiring, funding, AI ethics, founder burnout, and so on. Each concept in the vocabulary has its own embedding, computed once and cached. Projecting means taking the similarity between the content vector and every concept vector, producing a new vector where every component has a name.

The result: the raw vector answers how similar two things are, and the concept projection answers in what way they are similar.

How matching works in practice

Matching runs in two stages, and neither involves a model call at match time — it is pure vector arithmetic on precomputed embeddings:

Stage 1 — Candidate retrieval. Elasticsearch kNN over the raw embeddings finds the nearest candidates quickly, with ordinary metadata filters applied alongside.

Stage 2 — Explainable re-scoring. Each candidate is re-scored using the concept projections, and the top mutually strong concepts are surfaced by name. Instead of a bare score, the editor sees: these two matched because both are strongly about payroll, hiring, and small-business compliance.

The named concepts are not decoration. They are the actual mathematics of the re-score, read out in human terms.

Why interpretability earns its keep

• Trust. People accept automated suggestions far more readily when the system shows its reasoning. An explained match gets reviewed; an opaque one gets ignored.
• Debugging. When a match looks wrong, the shared concepts show why it happened — usually a vocabulary gap or an over-broad concept — and that tells you exactly what to fix.
• Tunability. The vocabulary is a curated, versioned artefact. Adding, renaming, or splitting concepts reshapes the semantic space deliberately, with judgement, rather than by retraining a black box.
• Stability. The vocabulary is embedded once and cached with content-hash checks, so rebuilding is cheap and reproducible, and reprojection after a vocabulary edit requires no new model calls for existing content.

The awkward cases are the real engineering

The real engineering in a production pipeline happens at the edges:

• Over-long content. Embedding models cap input length. Rather than truncating blindly, an inexpensive model compresses the text first — keeping topical and audience signals, dropping boilerplate — and the compressed text is embedded instead.
• Content changes. Embeddings regenerate when the text that produced them changes, and a backfill sweep catches anything that slipped through, so the vector store never silently drifts out of date.
• Failure isolation. An embedding failure never blocks saving or publishing content. The error is recorded, the content ships, and the sweep retries later.

Where this applies

Any system that matches content to people, products to queries, or documents to documents can use this pattern: raw embeddings for speed, concept projections for explanations. We built it for content distribution at Business111.com; the same design fits recommendation, deduplication, routing, and tagging problems anywhere.

DevNest designs and ships production AI systems — see what we build at devnest.ro/ai, or read the Business111 case study under Our Work.