[PR #11876] [MERGED] Fix: wrong citation order for chromadb, wrong order for hybrid search #9608

New Issue

GiteaMirror · 2025-11-11T18:26:51-06:00

GiteaMirror commented

2025-11-11 18:26:51 -06:00

📋 Pull Request Information

Original PR: https://github.com/open-webui/open-webui/pull/11876
Author: @mahenning
Created: 3/19/2025
Status: ✅ Merged
Merged: 3/21/2025
Merged by: @tjbck

Base: dev ← Head: fix--rag-sorting

📝 Commits (1)

ec8fc72 Fix wrong order for chromadb

📊 Changes

1 file changed (+20 additions, -11 deletions)

View changed files

📝 backend/open_webui/retrieval/utils.py (+20 -11)

📄 Description

Pull Request Checklist

Note to first-time contributors: Please open a discussion post in Discussions and describe your changes before submitting a pull request.

Before submitting, make sure you've checked the following:

Target branch: Please verify that the pull request targets the dev branch.
Description: Provide a concise description of the changes made in this pull request.
Changelog: Ensure a changelog entry following the format of Keep a Changelog is added at the bottom of the PR description.
Documentation: Have you updated relevant documentation Open WebUI Docs, or other documentation sources?
Dependencies: Are there any new dependencies? Have you updated the dependency versions in the documentation?
Testing: Have you written and run sufficient tests for validating the changes?
Code review: Have you performed a self-review of your code, addressing any coding standard issues and ensuring adherence to the project's coding standards?
Prefix: To cleary categorize this pull request, prefix the pull request title, using one of the following:
- BREAKING CHANGE: Significant changes that may affect compatibility
- build: Changes that affect the build system or external dependencies
- ci: Changes to our continuous integration processes or workflows
- chore: Refactor, cleanup, or other non-functional code changes
- docs: Documentation update or addition
- feat: Introduces a new feature or enhancement to the codebase
- fix: Bug fix or error correction
- i18n: Internationalization or localization changes
- perf: Performance improvement
- refactor: Code restructuring for better maintainability, readability, or scalability
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)
- test: Adding missing tests or correcting existing tests
- WIP: Work in progress, a temporary label for incomplete or ongoing work

Changelog Entry

Description

This PR fixes multiple embedding distance related issues with chromadb.

Fixed

Fix wrong order of citations in non-hybrid search when using chromadb
Fix wrong ordering of documents when merging and picking the k best docs in hybrid search with chromadb
Now picks best score for a document when it has multiple scores from different queries

Additional Information

Fix 1: Chromadb gives the actual distance (instead of a score) in [0, 2] with 0 distance as the best. While this is handled in merging the queries and picking the best k, the citations are ordered by "Relevance", which assumes 0 is worst and 1 is best. Chroma distance is 0 (best), 1 (unrelated) and 2 (worst). This resulted in the worst distance being at the top of citations. After picking the k best results, now transforms the [0, 2] distance into [-1, 1], where 1 is best.
Fix 2: In hybrid search, it still switched the reverse parameter in merge_and_sort_query_results when chromadb is used. But the results of the hybrid search uses scores of the reranker, which are already correctly ordered (0 is worst, 1 is best). This led to picking the k worst results instead of the best ones.
Fix 3: When merging documents, a set of hashes was used to check if a document was already added. This led to a "first comes first serves" scenario, where a document with distance x was inserted, but when the same doc with distance y from a different query comes in later in the loop, it isn't inserted even if score y > score x. It now checks if the new distance is better and overwrites the entry in that case, leading to the best score for this document chunk remaining.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/open-webui/open-webui/pull/11876 **Author:** [@mahenning](https://github.com/mahenning) **Created:** 3/19/2025 **Status:** ✅ Merged **Merged:** 3/21/2025 **Merged by:** [@tjbck](https://github.com/tjbck) **Base:** `dev` ← **Head:** `fix--rag-sorting` --- ### 📝 Commits (1) - [`ec8fc72`](https://github.com/open-webui/open-webui/commit/ec8fc727b825df04d40614a04942c50d003ecaef) Fix wrong order for chromadb ### 📊 Changes **1 file changed** (+20 additions, -11 deletions) <details> <summary>View changed files</summary> 📝 `backend/open_webui/retrieval/utils.py` (+20 -11) </details> ### 📄 Description # Pull Request Checklist ### Note to first-time contributors: Please open a discussion post in [Discussions](https://github.com/open-webui/open-webui/discussions) and describe your changes before submitting a pull request. **Before submitting, make sure you've checked the following:** - [x] **Target branch:** Please verify that the pull request targets the `dev` branch. - [x] **Description:** Provide a concise description of the changes made in this pull request. - [x] **Changelog:** Ensure a changelog entry following the format of [Keep a Changelog](https://keepachangelog.com/) is added at the bottom of the PR description. - [x] **Documentation:** Have you updated relevant documentation [Open WebUI Docs](https://github.com/open-webui/docs), or other documentation sources? - [x] **Dependencies:** Are there any new dependencies? Have you updated the dependency versions in the documentation? - [x] **Testing:** Have you written and run sufficient tests for validating the changes? - [x] **Code review:** Have you performed a self-review of your code, addressing any coding standard issues and ensuring adherence to the project's coding standards? - [x] **Prefix:** To cleary categorize this pull request, prefix the pull request title, using one of the following: - **BREAKING CHANGE**: Significant changes that may affect compatibility - **build**: Changes that affect the build system or external dependencies - **ci**: Changes to our continuous integration processes or workflows - **chore**: Refactor, cleanup, or other non-functional code changes - **docs**: Documentation update or addition - **feat**: Introduces a new feature or enhancement to the codebase - **fix**: Bug fix or error correction - **i18n**: Internationalization or localization changes - **perf**: Performance improvement - **refactor**: Code restructuring for better maintainability, readability, or scalability - **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.) - **test**: Adding missing tests or correcting existing tests - **WIP**: Work in progress, a temporary label for incomplete or ongoing work # Changelog Entry ### Description This PR fixes multiple embedding distance related issues with chromadb. ### Fixed - Fix wrong order of citations in non-hybrid search when using chromadb - Fix wrong ordering of documents when merging and picking the k best docs in hybrid search with chromadb - Now picks best score for a document when it has multiple scores from different queries --- ### Additional Information - Fix 1: Chromadb gives the actual distance (instead of a score) in [0, 2] with 0 distance as the best. While this is handled in merging the queries and picking the best k, the citations are ordered by "Relevance", which assumes 0 is worst and 1 is best. Chroma distance is 0 (best), 1 (unrelated) and 2 (worst). This resulted in the worst distance being at the top of citations. After picking the k best results, now transforms the [0, 2] distance into [-1, 1], where 1 is best. - Fix 2: In hybrid search, it still switched the `reverse` parameter in `merge_and_sort_query_results` when chromadb is used. But the results of the hybrid search uses scores of the reranker, which are already correctly ordered (0 is worst, 1 is best). This led to picking the k worst results instead of the best ones. - Fix 3: When merging documents, a set of hashes was used to check if a document was already added. This led to a "first comes first serves" scenario, where a document with distance x was inserted, but when the same doc with distance y from a different query comes in later in the loop, it isn't inserted even if score y > score x. It now checks if the new distance is better and overwrites the entry in that case, leading to the best score for this document chunk remaining. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

GiteaMirror added the pull-request label 2025-11-11 18:26:51 -06:00

GiteaMirror closed this issue

2025-11-11 18:26:51 -06:00

GiteaMirror referenced this issue

2026-04-19 21:45:00 -05:00

[GH-ISSUE #9608] Vector Dimension Mismatch Error with mxbai-embed-large:335m in Qdrant Integration #15579

GiteaMirror referenced this issue

2026-04-25 05:11:26 -05:00

[GH-ISSUE #9608] Vector Dimension Mismatch Error with mxbai-embed-large:335m in Qdrant Integration #31107

GiteaMirror referenced this issue

2026-05-05 16:01:41 -05:00

[GH-ISSUE #9608] Vector Dimension Mismatch Error with mxbai-embed-large:335m in Qdrant Integration #54244