Repository navigation
bug(vector_stores/valkey): search score hardcoded for cosine, breaks L2 ranking #7229
Description
Description
Same class of bug as #6546 / #6547, but in the Valkey vector store.
ValkeyDB._process_search_results hardcodes:
score = max(0.0, 1.0 - raw_distance)That mapping is only correct for COSINE (and IP after Redis/Valkey's 1/(1+IP) transform). For L2, distance is unbounded, so any hit with distance > 1 collapses to 0.0 and ranking / score thresholds break.
Additionally:
_create_indexalways creates the index with hardcoded"COSINE", ignoring any configured metric.create_col(..., distance="L2"|"IP")already accepts a metric forFT.CREATE, but does not persist it onself, so subsequent search still scores as cosine.
Steps to Reproduce
- Create a Valkey collection with L2:
store.create_col(name="demo", vector_size=768, distance="L2")
- Insert vectors and search.
- Observe returned scores: distant neighbors with L2 distance
> 1become0.0under1 - distance.
Expected Behavior
- Index creation uses the configured distance metric.
- Search scores convert distance → similarity in a metric-aware way (same approach as fix(vector_stores/s3_vectors): make search score metric-aware #6547):
- COSINE / IP:
max(0, 1 - d) - L2:
1 / (1 + d)so scores stay in(0, 1]and preserve ordering
- COSINE / IP:
Additional Context
- Sibling of S3 Vectors search score is hardcoded for cosine, breaks euclidean ranking #6546 (S3 Vectors). Happy to open a PR mirroring fix(vector_stores/s3_vectors): make search score metric-aware #6547 once this has the
acceptedlabel. - Also worth a follow-up on
vertex_ai_vector_search.py, which still hardcodes1 - distancein three places.
Activity
ktz03 commentedon Sep 5, 2026
Hi maintainers — this is the Valkey sibling of #6546. Could you please add the
acceptedlabel so a PR can be reviewed? PR incoming that mirrors #6547.ktz03 commentedon Sep 5, 2026
Hi @kartik-mem0 — this is the Valkey sibling of #6546 / #6547 (same hardcoded
1 - distancecollapsing L2 scores).Could you please add the
acceptedlabel when you have a moment? PR #7230 is ready and will auto-reopen once the issue is accepted.ktz03 commentedon Sep 5, 2026
Also noting a third sibling in the same family: Vertex AI Vector Search still hardcodes
1 - distancein three places (_parse_output/search/get). Filed as a follow-up — will keep PRs sequential so review stays small.ktz03 commentedon Sep 8, 2026
Friendly follow-up on the Valkey sibling of the already-traced S3 case.
1 - distancecollapsing L2/euclidean ranking.distanceon config/store + metric-aware_distance_to_score+ regressions). Branch is still clean vsmain(1 commit ahead, 0 behind).When you have a moment, could you add
acceptedhere so #7230 can auto-reopen into the review queue? Happy to rebase or adjust anything needed.fix(vector_stores/redis): make search score metric-aware
fix(vector_stores/weaviate): make search score metric-aware
fix(vector_stores/redis): make search score metric-aware
fix(vector_stores/weaviate): make search score metric-aware
blazingretinol commentedon Sep 25, 2026
Confirmed. Pointing collection_name at an existing Valkey index built with L2 (or calling create_col with distance L2) still scores with the cosine formula, so a real match with distance over 1 collapses to a score of 0 and gets silently dropped by the default search threshold.
Cause is in mem0/vector_stores/valkey.py: _create_index (line 196) reuses an existing index without checking its metric, and _process_search_results (line 400) always applies max(0, 1 - distance), which only holds for cosine. Reproduced against a real Valkey Search container.
PR #7230 persists a declared distance metric, so create_col with an explicit metric now scores correctly. An index reused without anyone explicitly declaring its metric still scores wrong after that fix.