LLM 联网搜索，到底是咋回事？

近段时间 DeepSeek 的服务火遍了全网，无论是使用网页还是使用 App 都能享受到 深度思考 + 联网搜索 的至尊体验。奈何免费的东西往往是需要排队的，从年开始 DeepSeek 的服务就一度处于不可用状态，就算是年后，网络搜索也是经常处于不可用的状态。

所以这个和模型配套的网络搜索能力到底是什么东西呢？他是模型自带的？还是一种模型之外需要开发的附加功能呢？

趁着我国补的 Mac Mini 刚好到到货，接下来就跟随我的脚步来建立一个基于本地 DeepSeek R1 32b 的网页搜索服务。

在 Mac Mini 上运行模型是一件非常简单地事情，这里我们直接使用 Ollama 配置一套本地 LLM 模型运行环境，并且将 DeepSeek R1 32b 下载到本地。



当然，这里也可以使用 LM Studio 来建立本地的大模型环境，但就我个人的体验，Ollama 还是 对于系统的开销要稍微低一些，毕竟没有 UI 界面嘛。考虑到我们后面的访问实际上只会用到本地部署的大模型 API 接口，无谓的 GUI 对内存的占据还是能不要就不要，等大模型跑起来，多一点内存那就能多加几轮对话记忆了。

完成了大模型的运行 API 建设，接下来我们还需要建设一个 Docker 环境，接下来我们的网络服务配置都会用到 Docker。

Docker 的安装也非常简单，直接从官网下载 Docker 的应用安装即可。

有了 Docker 环境，接下来我们需要再本地配置最强自定义 LLM 工具——Dify。



这里非常推荐使用 Dify 官方提供的 docker compose 安装方法。不过在执行 compose 命令之前，我们需要打开docker-compose.yaml 对里面的参数做一些修改。



这里最好将 ARRAY 的最大值设置给大，并将超时时间也最好也加长，因为我们是在本地执行 LLM 大模型，不同于优化到极致的 API 服务，本地运行有模型加载时间，并且内存满了之后还会 Swap，使得模型输出结果时间被进一步延长，等之后本地完成调试换回网络 API 可以再把这个超时时间改回去。

调整完参数，接下来按照 Dify 官方文档进行部署。



完成部署的状态大概是这样，compose 会自动拉取最近的镜像并完成整个项目配置。然后我们就可以通过网页来访问 Dify 操作界面了。



打开 Dify 的第一件事情就是需要将我们之前部署的 Ollama 添加到 Dify 的模型配置中。



填写好 Ollama 服务器地址和模型的完整名字，这里就配置完成了。

至此，我们本地的大模型开发环境就假设完毕了，接下来我们会通过 Dify 创建一个聊天助手，并使用 Ollama 上的 DeepSeek R1 32b为主模型，建立一个具有联网搜索能力的聊天助手。



DeepSeek 的客户端和网页在用户手动开启了联网搜索的情况下，都是会识别用户输入，如果用户输入的内容仅通过模型已有的知识就可以回答，那么就不需要耗费资源去进行网络搜索，毕竟用户说个“你好”还给搜一排没意义的网页并汇总，也显得有点蠢。

所以在拿到用户的输入之后，我们先要让模型判断一下当前用户的输入是否需要进行网络请求：



这里我通过 SYSTEM 信息给模型赋予了角色，之后将用户输入通过指令包裹之后投喂给模型，并且规定了模型的反馈形式。

在后续的条件分支中，根据模型的返回我们可以选择不同的执行路径。

如果不需要进行搜索的话，那就直接把用户的输入喂给模型并让模型返回：



如果模型判断自身的知识不足以回答用户的问题，那么接下来我们就要进行搜索了。

要进行搜索，就需要有一个搜索关键词。当然我们可以将用户的输入直接当成关键词丢给搜索引擎，但现在大部分搜索引擎可没有大模型的理解能力，所以我们需要模型先根据用户输入整理一个适合的搜索关键词出来：



一般来说根据用户的输入，都能总结出一个搜索关键词，但用户的输入可能包含多个问题，比如说“今天天气如何？去东方明珠是否合适？”这里按照用户的问题，就需要查询当前上海的天气的情况和东方明珠的票务情况，这两个需要查询的内容如果混合成一个关键词可能无法搜索到正确的网页，比较合适的做法是将两个需要获取的信息拆分成两个搜索关键词。

这里我图方便就只生成一个关键词进行一次搜索。

Dify 作为一个非常强大的 LLM 工具，内置了多个搜索插件：



谷歌搜索这里需要再谷歌的后台生成搜索 API，并且 Dify 所在的环境需要科学上网能力；Bing 的后台我死活打不开，感觉被微软拉黑了；DuckDuckGo 是最友好的搜索，直接挂上就能用，搜索结果也很精确。至于我这里配置的 SEARXNG，是一个开源项目，这个项目会汇总数个平台搜索结果并整理成 JSON 返回给 Dify。

我本地刚好之前配置过 SEARXNG，所以这里直接选择，鉴于 SEARXNG 配置稍微有点复杂，动手能力强的同学可以参考我的配置。

完成搜索之后，我们会得到一个数组的网页 URL，也就是我们的搜索结果。如果直接把 URL 交给模型，模型可是不知道这 URL 对应的内容是什么的，毕竟模型只能通过概率和参数进行输入输出，并不具备访问网络能力。为了让模型知道这些搜索结果的 URL 对应的网页内容是什么，我们需要将网页下载下来并提取其中的重要内容。



由于搜索返回的是一个数组，所以我们需要一个迭代组件来对数组里面的内容循环处理。

这里下载网页我使用了 HTTP 请求而不是 Dify 提供的网页爬虫插件，因为在我实际操作下来，网页爬虫会直接将网页的文字内容通过 python 库直接脱离出来生成文本，可以说是基本在无解析的情况下直接将网页的文字全部输出，没有任何过滤和主次处理。为了减少后续模型的 Token 消耗，我们这里直接将原始的 HTML 源文件下载到本地，稍后通过一点手段来进行主要内容提取处理。

需要注意的是这里抓取网页的迭代我开启了并行模式，毕竟这里只有网页下载这一项功能，并行下载是一个正常操作。但如果一个迭代里面存在模型调用的话，考虑到模型并发时实际上还是按照队列执行，并且本地模型执行速度较慢，在这种情况下还是串行执行比较合适。



完成抓取之后，针对下载失败的页面需要进行一下筛选，再进入后面的流程。



网页内容提取这块流程大概是这样的，这里我使用了一个新的模型——Jina.ai 提供的 Reader-LLM-V2。经过我的测试，Reader-LLM-V2 对网页的提取效果非常好，可以通过简单的提示词很快将网页中的主要文字内容提取出来。并且这个模型只有 1.5b并支持 256k Token，所以可以将整个网页源码都作为输入喂给模型，占用的内存也在可以接受范围。

当然我们这里由于是本地模型，执行起来时间消耗还是比较高的，后面可以考虑使用 Jina.ai 提供的服务来进行网页内容提取。

提取完成之后，还需要交给模型，让模型分析一下提取出来的内容和用户一开始输入的关联性。只有减少无用的信息，才能保证最终模型在有限的 Token 输入下能得出最正确的结果。



这里我让模型根据网页内容和用户输入给出一个相关评分，如果相关评分大于 5 则加入最终的输入，如果小于 5 就忽略掉。

有了相关网页的内容数组，我们还需要组织一下最终输入给模型的内容，需要让模型知道我们进行了搜索，并且搜索有这么些结果，让模型根据搜索结果提供的信息对用户一开始的输入进行反馈。



这里我简单做了一个格式化，如果更加细化的话可以让模型根据引用的内容标注出对应的网页。

整个流程搭建完成，接下来就能进行测试了。





通过这两个测试结果可以发现，这么一套流程走下来，模型确实具有一些其内部不存在的知识，并能够通过添加的知识进行总结输出。

不过这个输出似乎还是包含了一些不太正确的信息。通过回溯整个执行流程，可以发现最后一次进行内容输入时，由于缺少足够的格式化，模型并没有完全理解搜索结果是作为被添加的信息提供的。

当然还有个问题就是由于模型都在本地运行，所以网页提取和模型运行时间都非常长，倒是搜索结果给出的速度快的有点出乎意料。

整套流程跑下来，我们可以看到其中还有不少的地方是可以优化的。

如果说不纠结于本地运行模型，或者说补充新的性能更强的模型运行设备，相信在模型调用耗时上能够减少一个数量级。

流程中的缺陷主要就是前面提到的搜索关键词生成和进行多次搜索那块。

这流程最大的问题，还是最后一次投喂时网页内容过多。上面的两个例子中，由于网页下载失败和提取问题，最终的 Token 数量并不是很多。但在优化完那部分处理之后，最后可能会有数十个网页，这些网页的文字内容加起来可能会导致最后输入的 Token 超过模型承载。

这里参考了一下 OpenWebUI 的实现，似乎可以建立一个由搜索结果网页内容组成的本地知识库，通过 RAG 的形式，将知识库内容进行 Embedding 之后传递给模型，来让模型可以使用网页里面相关的知识。

本文展示了如何从零开始搭建一个具备联网搜索能力的本地聊天助手，涵盖了模型部署、搜索逻辑设计、内容提取与整合等关键步骤。尽管存在一些性能和准确性上的挑战，但通过进一步优化（如引入 RAG 技术），这套系统有望成为一个高效的问答工具。