fix(chroma): forward filter/where_document in _similarity_search_with_relevance_scores

[devffex]

Ensure chroma parameters are properly passed in _similarity_search_with_relevance_scores

What this PR fixes

Fixes parameter forwarding in _similarity_search_with_relevance_scores so chroma-specific filter and where_document are correctly passed, and the custom relevance_score_fn is applied.

Bug explanation

The base implementation forwards all parameters via **kwargs. Chroma's similarity_search_with_score explicitly accepts filter and where_document. When these are passed to similarity_search_with_relevance_scores, extracting them explicitly ensures correct forwarding and preserves compatibility with chroma's filtering.

How to reproduce

from langchain_chroma import Chroma
from langchain_openai import OpenAIEmbeddings

# Create Chroma instance with custom relevance_score_fn
vector_store = Chroma.from_texts(
    texts=["foo", "bar", "baz"],
    embedding=OpenAIEmbeddings(),
    relevance_score_fn=lambda d: d * 2 + 100
)

# Call similarity_search_with_relevance_scores with filter
results = vector_store.similarity_search_with_relevance_scores(
    "query",
    k=3,
    filter={"key": "value"},  # Chroma-specific parameter
    where_document={"$contains": "text"}  # chroma parameter
)

# Bug: Filter and where_document may not be properly forwarded
# Expected: Custom relevance_score_fn is applied AND filters work correctly

Solution

Override _similarity_search_with_relevance_scores to explicitly extract filter and where_document and pass them to similarity_search_with_score. This:

1. Ensures chroma parameters are forwarded
2. Preserves the relevance score transformation logic
3. Maintains backward compatibility with **kwargs usage

The override follows the same pattern as the base implementation, with explicit parameter extraction for chroma's API.

ChromaDB repository dependency

This PR depends on chromaDB's Collection.query method (defined at chromadb/api/models/Collection.py, lines 189-226), which accepts where and where_document parameters.

Test coverage

Five new test cases verify the fix works correctly and maintains backward compatibility:

1. test_chroma_similarity_search_with_relevance_scores_with_filter: Verifies that when you pass a filter parameter explicitly (like filter={"first_letter": "f"}), the filtering works correctly and the custom relevance_score_fn is still applied to transform the scores.

2. test_chroma_similarity_search_with_relevance_scores_with_filter_kwargs: Tests backward compatibility by passing filter inside **kwargs (like **{"filter": {"first_letter": "b"}}). This ensures old code that passes filters via kwargs continues to work correctly.

3. test_chroma_similarity_search_with_relevance_scores_with_where_document: Verifies that the where_document parameter (used to filter by document content, like {"$contains": "there"}) is properly forwarded and works together with the relevance score transformation.

4. test_chroma_similarity_search_with_relevance_scores_with_other_kwargs: Ensures that when filter is passed via kwargs through the public API (simulating how the base class calls the method), our override correctly extracts it from kwargs and uses it. This maintains backward compatibility with existing code that doesn't use explicit parameters.

5. test_chroma_similarity_search_with_relevance_scores_both_params: Tests the combination scenario where both filter and where_document are used together, verifying that both parameters are correctly forwarded and the relevance score transformation still works.

[codspeed-hq]

CodSpeed Performance Report

Merging this PR will not alter performance

_{Comparing devffex:fix/libs/partners/chromadb/forward-chroma-params-in-relevance-score-search (c6d9ccd) with master (8e3c6b1)¹}

Summary

✅ 1 untouched benchmark
⏩ 33 skipped benchmarks²

Footnotes

1. No successful run was found on master (5e9765d) during the generation of this report, so 8e3c6b1 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

2. 33 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩