Replies: 1 comment 1 reply
-
|
damn sounds like you hit a really large website 😁 yeah maybe there should be a limit to this, or truncating websites or similar. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
well it was mostly PDFs which tend to be large. Also when the pdf -> text conversion includes e.g. creating image descriptions that can further make it slow. Not sure if that is happening. |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Check Existing Issues
Installation Method
Docker
Open WebUI Version
0.6.31
Ollama Version (if applicable)
No response
Operating System
Ubuntu 24.04
Browser (if applicable)
Chrome 140.0.7339.208
Confirmation
README.md.Expected Behavior
Response should take a relatively short amount of time, say <1 min. If a web page is long, unneccessary stuff like javascript code, b64 encodings etc needs to be stripped so only text is used. If it's still long, it needs to be shortened or rejected.
Actual Behavior
reponse took 8 minutes with 15971 created embeddings
Steps to Reproduce
probably not easy to reproduce, but the web search that triggered this behaviour was ('google_pse', ['HELM Sycon competitor biostimulants comparison 2025', 'biostimulant product comparison amino acid phosphite seaweed extracts
row crops', 'Sycon HELM independent trial results vs competitor biologicals corn soybean'])
Logs & Screenshots
Additional Information
Apparently all the top 3 results were long pdfs, of which two failed to fetch and the last one triggered this long embedding creation. There should be some way to exclude pdfs or very long documents and focus on shorter ones. Or a fast way to handle extracting the relevant info.
Beta Was this translation helpful? Give feedback.
All reactions