OpenWebUI 联网搜索慢的罪魁祸首找到了

我是自己部署的 OpenWebUI(v0.5.12),使用的模型是 Deepseek R1,在对话中打开了『联网搜索』,发现每次问答都非常慢
根据我的观察,每次对话的时间,随着『联网搜索』配置项中的『搜索结果数量』增加而增加,当我把数量增加到 30,时间要到5分钟以上了,这是反直觉的
经过一系列排查,发现这是由两个问题导致:

  1. 生成搜索词过程慢:默认使用 Deepseek R1(本模型)去生成给搜索引擎用的搜索词(『管理员面板 → 设置 → 界面 → 设置任务模型 → 外部模型』改为使用 Deepseek v3),改了之后快了不少,但把结果数设为30,依然还是慢
  2. 获取搜索结果慢:比如设置了30个结果,搜索引擎返回一个 url 列表之后,它是一个一个去串行获取的。。(一口老槽不知道怎么吐),发现已经有人提交 PR 修复了,估计等下个版本就好了 feat: websearch support async docs load

联网搜索的过程:
当提交问题后

  1. 收到问题,加上下文,扔给 LLM 生成给搜索引擎的问题(这里的模型可以另外配置,这里的 prompt 可以自定义)
  2. 提交给搜索引擎,获取到搜索结果的 url 列表
  3. 根据 url 列表获取文档内容(问题在这里,串行获取)
  4. 获取到的文档内容下来,批量 embedding 后存到向量数据库 chroma(批量可以在后台设置,这里的批量是串行的,一批处理完后处理下一批)
  5. 回答时引用搜索到的文档作为知识库,走 RAG 的逻辑
21 个赞

没想到是这原因,因为搜索太慢直接把搜索功能给关了

这整得有点复杂了,应该也比较消耗token

学习了,他这个确实太慢了

openwebui好慢啊

学习了,搜索功能确实太慢了

确实,业界的最佳实践都差不多,基本都是这个路子吧

openwebui这个优化一下,应该不会这么慢,我用chatbot和pageassitant都抓取50个网页,速度也没有明显慢,不知道他这个啥时候把pr合并进去

@yangtb2024 学会了吗

2 个赞

原来如此

1 个赞

确实慢,我搜索过几次要等好久 就再也没用过了

1 个赞

原来这样

1 个赞

已经合并进去了,下个版本应该就好了

1 个赞

等待5.13的发布

1 个赞

但是我发现如果任务模型不设置为当前模型, 他去判断调用函数的时候就不会带上设定的提示词了

1 个赞

确实是这样 刚好昨天我也整理了一下

  1. 首先通过任务模型(可以自己设置,默认为当前模型)根据用户的提问生成一个搜索的词

    ### Task:
    Analyze the chat history to determine the necessity of generating search queries, in the given language. By default, **prioritize generating 1-3 broad and relevant search queries** unless it is absolutely certain that no additional information is required. The aim is to retrieve comprehensive, updated, and valuable information even with minimal uncertainty. If no search is unequivocally needed, return an empty list.
    
    ### Guidelines:
    - Respond **EXCLUSIVELY** with a JSON object. Any form of extra commentary, explanation, or additional text is strictly prohibited.
    - When generating search queries, respond in the format: { "queries": ["query1", "query2"] }, ensuring each query is distinct, concise, and relevant to the topic.
    - If and only if it is entirely certain that no useful results can be retrieved by a search, return: { "queries": [] }.
    - Err on the side of suggesting search queries if there is **any chance** they might provide useful or updated information.
    - Be concise and focused on composing high-quality search queries, avoiding unnecessary elaboration, commentary, or assumptions.
    - Today's date is: 2025-02-16.
    - Always prioritize providing actionable and broad queries that maximize informational coverage.
    
    ### Output:
    Strictly return in JSON format: 
    {
      "queries": ["query1", "query2"]
    }
    
    ### Chat History:
    <chat_history>
    USER: 英雄联盟 faker 的成就
    </chat_history>
    
    
  2. 通过搜索引擎搜索关键词 得到n个相关URL

  3. 通过代码获取网页中的信息,转换为文档

  4. 将文档向量化,存到数据库中

  5. 再通过用户的提问进行检索,选出最相关的n个片段

  6. 连同片段与提问一起输入模型 等待回复

其中我认为影响效果的几个地方:

1.搜索引擎提供url的相关性 2. url转为文档是否完整 3. 文档向量化与检索的效果

1 个赞

相当于搜索结果一直一个个在单线程处理吗


看了一眼源码 好像还真是单线程处理的

1 个赞

对的,url 列表,一个一个按顺序,第一个拉取完了,再拉第二个,第二个完了,再拉第三个。。。

这里是指的相关性和准确性,我倒不是觉得不是相关不相关的问题,问题是太慢了。。