Chroma backend search score is metric-blind and not comparable across backends

[thorwhalen]

ChromaCollection.search (vd/backends/chroma.py) converts every distance to a score with:

score = 1.0 / (1.0 + distance)

regardless of the collection's distance metric. The inline comment even notes that for cosine ChromaDB returns 1 - cosine — so for a cosine collection the reported score is 1 / (2 - cosine_sim), a monotonic but non-standard, non-interpretable number. The code never reads the collection's actual configured metric (hnsw:space).

Impact: ranking is preserved (the transform is monotonic), so results are not mis-ordered. But:

• Scores are not comparable across backends — the memory backend returns cosine similarity directly in [-1, 1].
• Scores are not interpretable — a "0.5" means nothing consistent.
• vd's own reciprocal_rank_fusion / deduplicate_results / multi_query_search helpers and ef's SearchHit.score all consume these values.

Proposal:

• Read the collection's configured metric and convert to a single documented canonical score (suggest: cosine similarity in [-1, 1], or a documented similarity = 1 - distance for cosine / -distance for L2).
• Document the score semantics in the Collection.search contract in base.py, so every backend (memory, chroma, future) agrees on what score means.

[thorwhalen]

Closed by #21 (merged).

The headline bug — Chroma's metric-blind 1/(1+distance) score — was fixed earlier when the Chroma adapter moved to score_from_distance(distance, metric). #21 closes the rest: the cross-backend score contract is now documented in vd/base.py ("Score semantics": higher-is-better, per-metric — cosine ∈ [-1, 1], dot = raw inner product, l2 = 1/(1+d) ∈ (0, 1]) and referenced from Collection.search; score_from_distance documents which adapters route through it vs pass a native score (ES / Atlas / Pinecone); FAISS L2 now routes through the helper; Qdrant L2 annotated; regression tests pin the contract on the in-memory reference adapter.