Weaviate Essentials

This post answers 'why bother?' The honest case for a vector database isn't raw speed — Postgres can be fast too. It's that Weaviate lets people find things by intent, which fundamentally changes what search can do. The cover sets up the tension we resolve through the post: semantic search is powerful, but on its own it has real blind spots, and Weaviate's hybrid approach is the synthesis.

We'll walk through where keyword search fails, what semantic search unlocks, why pure vectors aren't enough either, how hybrid fusion combines them, and the costs you must budget for.

Keyword search is exact-token matching. BM25, SQL LIKE, and most search bars score documents by the words they literally contain. That works beautifully for names, SKUs, and error codes, but it falls apart whenever the user and the document use different words for the same thing.

The insidious part is invisibility: when 'car won't start' fails to match 'engine fails to crank', the user simply sees no results and assumes the content doesn't exist. You never get an error and your logs look clean, so the recall problem hides in plain sight until someone measures it.

There are genuinely two retrieval philosophies, and each is strong exactly where the other is weak. Keyword search excels at precise, rare tokens — part numbers, proper nouns, exact phrases — where you want literal matches. Semantic search excels at meaning — synonyms, paraphrase, related concepts, even cross-language — where literal overlap is missing.

The practical conclusion that the rest of the post builds toward: real applications need both. Choosing one means accepting a known failure mode. Hybrid search exists precisely so you don't have to choose.

These bars are illustrative, not benchmark numbers, but the shape is real and consistently reported: keyword-only and vector-only each leave meaningful recall on the table, and hybrid typically beats both. Keyword loses the paraphrased and synonymous matches; vector loses the exact-identifier matches.

The reason hybrid wins is that the two methods fail on different queries. Their errors are partly uncorrelated, so fusing their rankings recovers hits that either method alone would miss. That's why the hybrid bar sits clearly above both — combining complementary signals beats optimizing either one in isolation.

Semantic search works by embedding text into a high-dimensional space where distance encodes meaning. Similar concepts land near each other regardless of exact wording, so a query vector falls close to relevant objects even with zero shared tokens. This is the mechanism behind typo tolerance, synonym handling, and multilingual matching.

For users it feels like the system finally understands them. For builders it means you stop maintaining brittle synonym lists and keyword expansions; the embedding model has effectively learned those relationships from its training data. That's the unlock that makes the infrastructure worth it.

This is the deliberate counterweight so the post isn't hype. Pure vector search has clear weaknesses. Exact strings — a part number like 'A1502' or a rare surname — get smeared into the embedding's notion of 'similar', so the literal match you wanted may rank below conceptually-related but wrong results. Embeddings are about gist, and gist is the enemy of exactness.

Vectors also can't natively express structured constraints like 'price < 50' or 'status = open'. You need keyword matching for precision and metadata filters for structure. Recognizing these limits is what motivates hybrid search rather than treating vectors as a silver bullet.

Hybrid search is Weaviate's resolution of the tension. It runs the vector (ANN) search and the BM25 keyword search in parallel, then fuses their result lists into one ranking. Two fusion strategies exist: rankedFusion combines by rank position, while relativeScore (often the better default) combines normalized scores so strong matches in either branch carry weight.

The alpha parameter controls the blend: alpha=0 is pure keyword, alpha=1 is pure vector, and 0.5 weights them evenly. Tuning alpha on your own data is one of the highest-leverage things you can do — it lets you dial in exactly how much you trust meaning versus literal matching for your domain.

This snippet shows how little code the synthesis takes. A single hybrid() call accepts the query text, an alpha to balance the two branches, and a fusion_type. Weaviate handles vectorizing the query, running both searches, fusing, and returning ranked objects.

RELATIVE_SCORE fusion is chosen here because it tends to produce more intuitive rankings than rank-based fusion when the two branches disagree in confidence. In practice you'd run a small evaluation set across a few alpha values and fusion types and pick the combination that maximizes your retrieval metric — but the API stays this simple throughout.

These are the concrete business outcomes that justify the project to stakeholders. Higher recall on support and documentation search means users self-serve instead of opening tickets. Fewer 'no results' dead ends means less frustration and abandonment. Cross-lingual matching means a single index can serve users querying in different languages without a translation layer.

For RAG specifically, retrieval quality is the ceiling on answer quality: if the right chunk isn't retrieved, no amount of LLM cleverness recovers it. Hybrid retrieval directly raises that ceiling, which is why it has become the default recommendation for production RAG.

Every benefit has a bill, and naming the costs up front builds trust and prevents nasty surprises. Embedding API calls cost money per token and add network latency to both import and query unless you self-host the model. The HNSW index lives in RAM, so memory scales with object count and dimensionality — this is often the real cost driver.

Changing your embedding model forces a full re-embed of the corpus, which is expensive and operationally annoying, so model choice is somewhat sticky. And filters, if not planned for, can interact poorly with ANN. Budgeting for these — money, RAM, and re-embedding — is part of adopting the technology responsibly.

This compare diagram pins down hybrid mechanically. The left branch is the vector path: the query becomes an embedding, ANN search walks the HNSW graph, and results are ranked by vector similarity. The right branch is the keyword path: the query is tokenized, BM25 scores documents using the inverted index, and results are ranked by term match.

Seeing the two branches side by side clarifies that they are genuinely independent computations over different data structures, joined only at the fusion step. That independence is exactly why combining them adds value — they bring different evidence to the same question.

The teaser points to Day 88's How It Works post. Having argued why hybrid retrieval matters, the next logical step is to open the hood and see the actual machinery — the HNSW graph, the inverted index, and the lifecycle of a single query — so the abstractions here become concrete engineering.