Hybrid Sparse-Dense Search

## What a hybrid record looks like in Pinecone Pinecone does hybrid search by letting a single record carry two vectors at once: the usual dense embedding in `values`, and a sparse vector in `sparse_values`, given as `{"indices": [...], "values": [...]}`. The sparse side is a bag of term weights — each index is an integer id for a token in some vocabulary, each value is that token's weight. At query time you pass both `vector=` and `sparse_vector=` to `index.query(...)`, and Pinecone returns one ranked list with one `score` per match, computed over both parts together. ## The metric is chosen at creation and is immutable `create_index` takes `dimension`, `metric` and a `spec` (for example `ServerlessSpec(cloud=..., region=...)`). The metric may be `cosine`, `dotproduct` or `euclidean`. Sparse-dense records are supported **only** on `dotproduct`. Trying to upsert a record with `sparse_values` into a cosine index fails, and there is no ALTER-style operation to change a metric afterwards: the fix is to create a fresh index with `metric="dotproduct"` and re-upsert the whole corpus. That is why this shows up in interviews — it is a design decision you must make before you write a single vector, and getting it wrong is a full rebuild. ## Why dot product is the mathematically necessary choice A dot product is linear in the query: score(q, d) = q · d, so score(alpha·q, d) = alpha · (q · d). That linearity is the whole trick. If you scale the dense query by alpha and the sparse query by (1 - alpha) before sending them, Pinecone's internal score becomes alpha · (dense_q · dense_d) + (1 - alpha) · (sparse_q · sparse_d) which is exactly a convex blend of a semantic score and a lexical score — produced by the engine, in one query, with no client-side merging of two result lists. Pinecone exposes no server-side `alpha` parameter; this scaling is how the weighting is expressed. ## Why cosine and euclidean cannot do this Cosine similarity divides by the norms of both vectors. Any positive scalar multiple of the query gives an identical cosine score, so multiplying the query by alpha would change nothing — the weighting knob would silently do nothing at all. Euclidean is a distance: lower is better, the opposite polarity from a similarity, and over a very high-dimensional mostly-zero sparse vector the distance is dominated by the dimensions both vectors leave at zero, which carries almost no signal. Neither combines sensibly with a dense similarity into one orderable number. ## What choosing dotproduct costs you Dot product is unnormalised, so a vector with a larger magnitude scores higher regardless of direction. Most sentence-embedding models emit vectors of roughly unit norm, and if yours does, dot product and cosine produce the *same ranking* — you lose nothing. If your model does not, L2-normalise the dense vectors yourself before upserting and before querying; otherwise long or high-energy documents will float to the top for reasons that have nothing to do with relevance. This is the single most common surprise for teams migrating an existing cosine index over to hybrid. ## Failure modes to name in an interview - **Built the index on cosine first.** Discovered at hybrid-integration time; requires a new index and a full re-upsert, plus a cutover plan. - **Forgot the sparse vector on the query.** A record can carry sparse values while the query passes only `vector=`; the query then scores purely on the dense side and nobody gets an error. Hybrid quietly degrades to semantic-only. - **Un-normalised dense vectors.** Ranking drifts toward high-magnitude documents once you leave cosine. - **Assuming the metric is per-query.** It is per-index, set once, immutable. ## Related index shape Pinecone also supports sparse-only indexes, created with `vector_type="sparse"`, and those likewise use `dotproduct` — the lexical score is a dot product of term weights either way. With that shape you run a dense query and a sparse query separately and merge the two result lists yourself, rather than getting one blended score from one index. Knowing both shapes exist, and that dot product is the common thread, is a good signal of having actually built this.