Your Database Schema Is Not Your Semantic Schema

Engineers burn weeks on the wrong question — OpenAI or BGE, 1024 dimensions or 3072, cosine or dot product.

But most retrieval failures are decided long before any of that, by how you choose to shape the data. Get the shape wrong and the best embedding model on earth won't save you. Get it right and a mediocre one feels like magic.

There are two shapes, and they are not interchangeable.

Show Image

Model A — single embedding + late fusion. Fuse every field into one enriched description, embed it once, search that vector, then apply hard filters and boosts after retrieval. One vector, one scan.

Model B — one embedding per column (ColBERT-style). Title, summary, and skills each get their own vector. The query is split the same way, and the final score is a weighted sum of per-field similarities — so you control exactly how much each signal counts.

More vectors isn't automatically better. The choice comes down to one question.

When attributes combine into a single idea, blend them. When they're independent axes, keep them apart.

A dress that's black, silk, elegant, and made for a gala isn't four facts — it's one concept, an elegant black silk gown, and the meaning lives in the combination. Pull the fields apart and you destroy it. This is fashion, streaming catalogs, media discovery: people type a sentence, not a field-by-field query, the embedding only needs to capture the vibe while metadata handles exact constraints, and one vector means one scan — latency stays low.

Where it breaks: search "Python developer" against a profile whose title says Python but whose skills are Java and Scala. The blend averages everything, Python gets buried, and a real match slips. When one attribute needed to dominate, blending drowned it.

A recruiter searching "Senior Python Engineer" isn't describing one concept — they're stacking independent requirements, where skills ≠ title ≠ industry. Here a query for "Python" hits the skill embedding hard instead of averaging across everything, and you can reweight per intent without retraining: boost skills for an IC search, boost title and level for an executive one. You also get interpretability — you can see which dimension caused the match. This is B2B people search, recruiter tools, and academic retrieval, where title, abstract, and citations each matter differently.

Where it breaks: search "elegant dress for a garden wedding." The title embedding catches "elegant dress," but no column owns elegance as a vibe, and "garden wedding" only partly matches occasion. The concept lives across columns, and a rigid per-column structure can't blend it back.

Two fast tie-breakers: structured metadata for exact matching favors A (embedding handles vibe, metadata handles precision). Needing to explain why something ranked where it did favors B.

Don't treat the way you stored your data as the way users think about it. Separate columns don't mean people search separately, and a holistic experience doesn't mean you should throw structure away. Your database schema is not your semantic schema.

Before you benchmark a single model, answer the only question that sets the architecture: correlated, or independent? Most of the design follows from there.