本地模型答不了今天的新闻、实时价格、刚发布的版本，很多人第一反应是换个更大的模型，其实缺的是联网这一步。这篇按自建 Open WebUI + Ollama 的场景，讲清联网搜索这条链路到底由谁负责搜索、谁负责总结，配置项该在哪一层动，以及搜不到、答不准、超时这几类问题怎么一步步排查。最后给一份上线前的检查清单。
本地模型答不了今天的新闻、实时价格、刚发布的版本，很多人第一反应是换个更大的模型，钱花了效果还是那样。其实缺的不是脑子，是联网这一步。这篇按自建 Open WebUI + Ollama 的场景，讲清联网搜索这条链路里谁负责搜索、谁负责总结，配置项该在哪一层动，以及搜不到、答不准、超时这几类问题怎么排。
先把预期摆正：联网搜索不是把知识灌进模型权重，每次提问都要重新检索一遍，所以它对搜索接口、网络出口、上下文长度都敏感。下面按「先分清职责 → 选后端 → 动手配 → 出问题排查 → 上线前过一遍」的顺序讲，照着做基本能自己走完一遍。
先分清：联网搜索不是 Ollama 干的活
Ollama 只负责把本地模型跑成一个接口，它本身没有联网能力，能查实时信息的是 WebUI 那一层。WebUI 的联网搜索走的是「先搜网页 → 把结果塞进上下文 → 让本地模型总结」这条链，本质是检索增强，不是模型自己长出了联网功能。所以配置项集中在 WebUI 的搜索设置、模型选择和工具开关三处，改 Ollama 的启动参数基本没用。
- Ollama
- 把本地模型跑起来并对外提供接口，不负责联网查资料
- WebUI
- 负责发起检索、拼上下文、把结果交给模型总结
- 检索增强
- 每次提问现搜现用，知识不写进模型权重
- 上下文窗口
- 能一次性塞进去的文本量，太小会导致检索结果被截断
还有一个容易忽略的点：如果模型上下文窗口偏小，搜回来的网页片段塞不进去，也会表现为「开了联网但没效果」。判断标准是看请求里实际带进去的文本长度，别只看开关状态。Token、上下文这类口径去 基础概念词典：Token、上下文、温度（/ai-dict/category/basics） 对照一下就清楚。
搜索后端选型：别只想着白嫖
常见做法是接一个搜索 API 作为检索源。商业搜索 API 结果质量稳定但要花钱，自建搜索引擎省接口费但要多养一台机器和运维。选型时别只看「能不能免费」，看三个硬指标：返回条数上限、单次查询延迟、是否需要信用卡和海外网络。三项里只要有一项卡住，上线后就会变成客服问题。
| 方案 | 适合谁 | 要盯的成本 | 什么时候不适用 |
|---|---|---|---|
| 商业搜索 API | 想快速上线、对结果质量有要求 | 按调用量计费，量大了要算账 | 内网或敏感场景，关键词外发不合规 |
| 自建搜索引擎 | 有运维能力、想控制数据流向 | 机器和运维人力，不是零成本 | 只有几个人用，运维比省下的接口费还贵 |
| 固定站点知识库 | 只查几个更新很慢的页面 | 建库和更新的人工 | 内容天天变，比如行情、新闻 |
对比不同方案的实际开销时，把「每千次问答里检索调用几次」折进去，比单看接口单价更接近真实账单，口径可以用 模型成本计算器（/tools/model-cost-calculator） 估。适用边界也写清楚：如果只是查一两个固定站点、内容更新很慢，与其上通用搜索，不如直接把那几个页面做成知识库，稳定性和可解释性都更好，做法参见 向量数据库目录（/stacks/vector-dbs）。
配置动作清单：从能搜到能用
配置分四步，顺序别乱。先让搜索通，再让对话用上，再调提示词，最后做对照测试。很多人跳过第一步直接去聊天，结果分不清是网络问题还是提示词问题。
- 开功能、填凭据在 WebUI 的管理设置里把搜索功能打开、填好检索源凭据，保存后用界面自带的测试按钮验证一次连通性，不要跳过这步直接去聊天。
- 在会话里真正启用在对话或模型层面开启联网开关，确认这次请求确实带上了检索。漏配最多的情况就是只开了全局功能、没在具体会话里启用。
- 调提示词明确要求「只基于检索到的内容回答，没找到就说没找到，并给出处」，否则本地模型很容易靠记忆编。
- 做对照测试同一个实时问题，关联网问一次、开联网问一次。两次答案都不引用来源就说明检索没生效，按下一节排查。
搜不到、答得飘、超时：排查顺序
按下面四步走，别跳步。前三步解决「搜不到」，第四步解决「答不准」，超时单独看延迟基线。每步都有明确的验证动作，做完能确定问题在哪一层。
- 第一步查凭据和额度：接口报鉴权失败或限流的一律先看密钥有效期和当日调用量，这一步能解掉大半问题；
- 第二步查网络出口：搜索接口在海外时，容器内能不能出网、DNS 通不通，比宿主机能上网更关键，用容器里执行一次请求来验证；
- 第三步查模型侧：本地模型上下文塞不下检索结果时会截断或答非所问，换个上下文更长的模型、或减少检索片段数量做对照；
- 第四步查渲染和引用：答案里没有来源链接，通常是提示词没要求或前端没开引用展示，跟网络无关。
性能问题单独看延迟基线。分别量模型首字延迟和搜索接口耗时，才能判断是模型慢还是搜索慢，方法参考 接口测速：先量出你的延迟基线（/tools/speed-test）。如果搜索慢但模型快，优先换检索源或降返回条数；反过来则先看模型大小和硬件。
上线前检查清单
自己用没问题，给别人用之前过一遍下面四类。前两类是功能和质量，后两类是成本和合规，缺哪一类上线后都会有人来问。
| 类别 | 检查项 | 不合格的表现 |
|---|---|---|
| 功能 | 全局开关、会话开关、检索源测试、引用展示 | 开关全开但答案永远不带来来源 |
| 质量 | 十个实时类问题，含有时效和无时效两类 | 检索为空时模型照样编得有模有样 |
| 成本 | 人均每日提问数 × 检索调用次数，落在哪个量级 | 月底账单比预估高一个数量级 |
| 权限 | 检索关键词会发给第三方，敏感场景先过合规 | 内网数据顺着搜索关键词泄露出去 |
成本这块别只看当下数字，检索单价会变，口径去 价格变动追踪（/price-watch） 看当时的记录。合规这块，如果检索会把关键词发给外部服务，就要先过一遍 安全与合规（/safety） 里的判断标准；不合适的场景就退回纯离线知识库方案，别硬上。
下一步把检索源凭据、会话开关、提示词这三样先配通，再用十个实时问题测一轮。配好之后顺路到站内核对一下接口延迟基线和成本口径，后面涨价或接口变更时你能第一时间察觉。→常见问题
本地 Ollama 模型开了联网搜索，回答里没有来源链接是怎么回事？
先分两件事：检索有没有真的发生，和结果有没有被展示。前者看后端日志里这次请求有没有带检索片段，后者看提示词里有没有要求输出出处、前端有没有开引用显示。多数情况是检索成功了但没要求模型标注来源，加上一句「必须给出可点击出处，找不到就说没找到」通常就能改善。
联网搜索会把我问的内容泄露出去吗？
会，检索这一步是把你的关键词发给搜索服务方，这跟本地推理不出网是两回事。判断标准是：问题里包含客户名、合同条款、内部代码这类内容，就不要走公网搜索，改用内网知识库检索；只有公开信息的查询才适合开联网。合规边界可以先看站内安全与合规页面的口径。
开了联网搜索但速度明显变慢，正常吗？
正常，链路上多了一次检索往返，还要把网页正文塞进上下文，输入变长首字延迟自然上升。判断是否可接受，要分别量搜索接口耗时和模型首字延迟，如果瓶颈在搜索就换低延迟的检索源或减少返回条数；如果瓶颈在模型，就往上下文更小的检索片段或更快的量化档位上调。
