mirror of
https://github.com/open-webui/open-webui.git
synced 2026-06-04 07:47:12 -05:00
[GH-ISSUE #23495] issue: Web Search silently returns stale results when Query Generation rewrites bad queries (no failure indication) #74604
Reference in New Issue
Block a user
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?
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
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
README.md.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:
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
ollama pull gemma4:31bhttp://localhost:3000Logs & 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:
Admin Panel > Settings > InterfacetoAdmin Panel > Settings > Web Searchwhere users would actually look for search-related settingsRelated issues:
@nidhi-singh02 commented on GitHub (Apr 8, 2026):
I would love to contribute by raising PRs, if the suggested improvements seems good
@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?
I do not see those screenshots with step 8 and step 11 there nor with "searching for results on the web".
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.
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.