github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-06-04 07:47:12 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

[GH-ISSUE #23495] issue: Web Search silently returns stale results when Query Generation rewrites bad queries (no failure indication) #123312

New Issue
Closed
opened 2026-05-21 02:36:28 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-05-21 02:36:28 -05:00
Owner
Copy Link

Originally created by @nidhi-singh02 on GitHub (Apr 8, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/23495

Check Existing Issues

  • I have searched for any existing and/or related issues.
  • I have searched for any existing and/or related discussions.
  • I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
  • I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

latest (main Docker image, pulled April 2026)

Docker Desktop Version

4.43.2 (199162)

Ollama Version (if applicable)

latest

Operating System

macOS (M4 Pro, 48GB RAM)

Browser (if applicable)

Brave (latest)

Confirmation

  • I have read and followed all instructions in README.md.
  • I am using the latest version of both Open WebUI and Ollama.
  • I have included the browser console logs.
  • I have included the Docker container logs.
  • I have provided every relevant configuration, setting, and environment variable used in my setup.
  • I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
  • I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation.

Expected Behavior

When web search is enabled and the UI displays "searching for results on the web", the model should return answers based on actual live web results. If search query generation fails or produces a bad query, the user should be informed.

Actual Behavior

With Web Search Query Generation enabled (the default), local models like Gemma 4 31B generate poor/mangled search queries. The UI still shows "searching for results on the web" with a spinner, giving the user full confidence that search is working. However, the answers returned are clearly from training data (2024 knowledge cutoff), not from any actual web search.

There is zero indication to the user that:

  • The query was rewritten by the model before being sent to the search engine
  • The rewritten query produced bad/irrelevant results
  • The search results never made it into the context properly

Turning off Web Search Query Generation immediately fixes everything. Same exact questions, fresh answers with real sources. DuckDuckGo was working fine the entire time.

Steps to Reproduce

  1. Install Open WebUI via Docker: 
    docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main
  2. Pull Gemma 4 31B via Ollama: ollama pull gemma4:31b
  3. Open WebUI at http://localhost:3000
  4. Go to Admin Panel > Settings > Web Search, enable web search, set engine to DDGS (DuckDuckGo, no API key needed)
  5. Confirm that Web Search Query Generation is ON under Admin Panel > Settings > Interface (this is the default)
  6. Start a new chat with Gemma 4 31B
  7. Ask a question about a recent event (e.g., "What happened in AI news this week?")
  8. Observe: UI shows "searching for results on the web" spinner
  9. Observe: The response contains only information from the model's training data (2024), not live web results
  10. Now go to Admin Panel > Settings > Interface and turn OFF Web Search Query Generation
  11. Ask the same question again
  12. Observe: The response now contains fresh, sourced web results

Logs & Screenshots

The UI displays "searching for results on the web" in both cases (step 8 and step 11), but only step 11 (with Query Generation OFF) actually returns live web data.

Full debugging writeup with screenshots: https://x.com/nidhisinghattri/status/2041546230585815368

Additional Information

Why this is different from #22329:
#22329 was about native vs default tool calling mode and which model generates the query. That was closed as expected behavior. This issue is about the UX failure: the system gives the user no signal that query rewriting is happening, no signal when it fails, and actively misleads with a "searching" spinner.

Suggested improvements:

  1. Move the setting: Move "Web Search Query Generation" from Admin Panel > Settings > Interface to Admin Panel > Settings > Web Search where users would actually look for search-related settings
  2. Show the generated query: Display the rewritten search query in the UI (e.g., a small "Searched for: ..." label) so users can see what was actually sent to the search engine
  3. Consider defaulting to OFF: Or at minimum, show a warning that this feature depends heavily on model quality. Small/local models consistently produce bad queries (also noted in #15459)
  4. Fail visibly: If search results appear low quality or empty, surface that to the user instead of silently falling back to training data

Related issues:

  • #22329 — Query Generation not functional (closed, different root cause)
  • #15459 — Settings to specify separate models for title, retrieval, web search (open, 8 upvotes, same underlying pain)
Originally created by @nidhi-singh02 on GitHub (Apr 8, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/23495 ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!). - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version latest (main Docker image, pulled April 2026) ### Docker Desktop Version 4.43.2 (199162) ### Ollama Version (if applicable) latest ### Operating System macOS (M4 Pro, 48GB RAM) ### Browser (if applicable) Brave (latest) ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [ ] I have included the browser console logs. - [ ] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. ### Expected Behavior When web search is enabled and the UI displays "searching for results on the web", the model should return answers based on actual live web results. If search query generation fails or produces a bad query, the user should be informed. ### Actual Behavior With **Web Search Query Generation** enabled (the default), local models like Gemma 4 31B generate poor/mangled search queries. The UI still shows "searching for results on the web" with a spinner, giving the user full confidence that search is working. However, the answers returned are clearly from training data (2024 knowledge cutoff), not from any actual web search. There is zero indication to the user that: - The query was rewritten by the model before being sent to the search engine - The rewritten query produced bad/irrelevant results - The search results never made it into the context properly Turning off **Web Search Query Generation** immediately fixes everything. Same exact questions, fresh answers with real sources. DuckDuckGo was working fine the entire time. ### Steps to Reproduce 1. Install Open WebUI via Docker: ```bash docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main ``` 2. Pull Gemma 4 31B via Ollama: `ollama pull gemma4:31b` 3. Open WebUI at `http://localhost:3000` 4. Go to **Admin Panel > Settings > Web Search**, enable web search, set engine to **DDGS** (DuckDuckGo, no API key needed) 5. Confirm that **Web Search Query Generation** is ON under **Admin Panel > Settings > Interface** (this is the default) 6. Start a new chat with Gemma 4 31B 7. Ask a question about a recent event (e.g., "What happened in AI news this week?") 8. Observe: UI shows "searching for results on the web" spinner 9. Observe: The response contains only information from the model's training data (2024), not live web results 10. Now go to **Admin Panel > Settings > Interface** and turn OFF **Web Search Query Generation** 11. Ask the same question again 12. Observe: The response now contains fresh, sourced web results ### Logs & Screenshots The UI displays "searching for results on the web" in both cases (step 8 and step 11), but only step 11 (with Query Generation OFF) actually returns live web data. Full debugging writeup with screenshots: https://x.com/nidhisinghattri/status/2041546230585815368 ### Additional Information **Why this is different from #22329:** #22329 was about native vs default tool calling mode and which model generates the query. That was closed as expected behavior. This issue is about the **UX failure**: the system gives the user no signal that query rewriting is happening, no signal when it fails, and actively misleads with a "searching" spinner. **Suggested improvements:** 1. **Move the setting**: Move "Web Search Query Generation" from `Admin Panel > Settings > Interface` to `Admin Panel > Settings > Web Search` where users would actually look for search-related settings 2. **Show the generated query**: Display the rewritten search query in the UI (e.g., a small "Searched for: ..." label) so users can see what was actually sent to the search engine 3. **Consider defaulting to OFF**: Or at minimum, show a warning that this feature depends heavily on model quality. Small/local models consistently produce bad queries (also noted in #15459) 4. **Fail visibly**: If search results appear low quality or empty, surface that to the user instead of silently falling back to training data **Related issues:** - #22329 — Query Generation not functional (closed, different root cause) - #15459 — Settings to specify separate models for title, retrieval, web search (open, 8 upvotes, same underlying pain)
GiteaMirror commented 2026-05-21 02:36:32 -05:00
Author
Owner
Copy Link

@nidhi-singh02 commented on GitHub (Apr 8, 2026):

I would love to contribute by raising PRs, if the suggested improvements seems good

<!-- gh-comment-id:4203876607 --> @nidhi-singh02 commented on GitHub (Apr 8, 2026): I would love to contribute by raising PRs, if the suggested improvements seems good
GiteaMirror commented 2026-05-21 02:36:33 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Apr 8, 2026):

with default tool calling, you definitely should see "no search queries generated in the UI" for at least a second.

You also see that no sources have been added underneath the message indicating that... no sources are present.

Did you modify the query generation prompt? It's been battle tested and should work fine even with tiny 4B models - you are using a 31b model. Did you modify the prompt from it's default?

Did you try using native tool calling too?

The UI displays "searching for results on the web" in both cases (step 8 and step 11), but only step 11 (with Query Generation OFF) actually returns live web data.
Full debugging writeup with screenshots

I do not see those screenshots with step 8 and step 11 there nor with "searching for results on the web".

Go to Admin Panel > Settings > Web Search, enable web search, set engine to DDGS (DuckDuckGo, no API key needed)

How did you set up DDGS? Btw: DDGS is not DuckDuckGo Search, it's Dux Distributed Global Search and has to be configured. Did you configure your web search provider? Did you install DDGS? You need to install it separately. The installation and configuration is not noted in your steps to reproduce.

Observe: UI shows "searching for results on the web" spinner
Observe: The response contains only information from the model's training data (2024), not live web results
Now go to Admin Panel > Settings > Interface and turn OFF Web Search Query Generation
Ask the same question again
Observe: The response now contains fresh, sourced web results

This would indicate the query generation prompt might have been altered, as when you turn it off, it will use the user provided message as web search input

Regardless of all of that, I also recommend using native tool calling as here the model itself is writing the tool call and the search query into the tool parameter. - Default tool calling is also considered legacy today.

<!-- gh-comment-id:4204690537 --> @Classic298 commented on GitHub (Apr 8, 2026): with default tool calling, you definitely should see "no search queries generated in the UI" for at least a second. You also see that no sources have been added underneath the message indicating that... no sources are present. Did you modify the query generation prompt? It's been battle tested and should work fine even with tiny 4B models - you are using a 31b model. Did you modify the prompt from it's default? Did you try using native tool calling too? > The UI displays "searching for results on the web" in both cases (step 8 and step 11), but only step 11 (with Query Generation OFF) actually returns live web data. > Full debugging writeup with screenshots I do not see those screenshots with step 8 and step 11 there nor with "searching for results on the web". > Go to Admin Panel > Settings > Web Search, enable web search, set engine to DDGS (DuckDuckGo, no API key needed) How did you set up DDGS? Btw: DDGS is not DuckDuckGo Search, it's Dux Distributed Global Search and has to be configured. Did you configure your web search provider? Did you install DDGS? You need to install it separately. The installation and configuration is not noted in your steps to reproduce. > Observe: UI shows "searching for results on the web" spinner > Observe: The response contains only information from the model's training data (2024), not live web results > Now go to Admin Panel > Settings > Interface and turn OFF Web Search Query Generation > Ask the same question again > Observe: The response now contains fresh, sourced web results This would indicate the query generation prompt might have been altered, as when you turn it off, it will use the user provided message as web search input Regardless of all of that, I also recommend using native tool calling as here the model itself is writing the tool call and the search query into the tool parameter. - Default tool calling is also considered legacy today.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#123312
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?