在本地部署一个具备联网搜索能力的聊天助手，这件事实际上相当有技术价值和趣味性。DeepSeek 的服务近期广受关注，其网页版和 App 版均支持“深度思考 + 联网搜索”，实际体验确实出色。但免费服务自然存在排队机制——从春节前后开始，DeepSeek 的服务就频繁出现不可用状况，年后的网络搜索功能更是时常中断。

那么，这个联网搜索能力究竟是模型原生具备的，还是需要额外开发的附加功能？趁着用国补入手的 Mac Mini 刚到位，正好逐步搭建一个基于本地 DeepSeek R1 32b 的网页搜索服务。

0x1 本地大模型环境搭建指南

在 Mac Mini 上运行模型其实非常简便，直接利用 Ollama 即可搭建本地 LLM 运行环境，同时将 DeepSeek R1 32b 下载到本地。

当然，使用 LM Studio 也是可行的选择。但根据个人使用体验，Ollama 对系统资源的占用更少——毕竟它没有图形界面。后续我们只调用本地大模型的 API 接口，无谓的 GUI 会占用内存，能省则省。当模型启动后，多腾出一些内存就能多容纳几轮对话的历史记录，何乐而不为呢？

成功启动大模型的 API 之后，还需要安装一个 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 为主模型，并为其赋予联网搜索能力。

0x2 搜索能力构建

判断是否需要搜索

DeepSeek 的客户端和网页，在用户手动开启联网搜索的情况下，都会先对用户输入的内容进行判断。如果模型已有的知识足以回答，就没有必要浪费资源去搜索网络。比如用户只说了一句“你好”，却还去搜索一堆无意义的网页并汇总，确实显得不够智能。

因此，在接收用户输入之后，先让模型判断是否需要发起网络请求：

这里通过 SYSTEM 信息为模型赋予角色，将用户输入用指令包装后喂给模型，并规定模型的反馈格式。后续的条件分支中，根据模型的返回值选择不同的路径。如果不需要搜索，直接将用户输入喂给模型，让它返回结果。

如果模型判断自身知识不足以回答用户的问题，那么就需要执行搜索。

生成搜索关键词

要进行搜索，就必须有一个关键词。当然，可以直接把用户输入作为关键词丢给搜索引擎，但大多数搜索引擎并不具备大模型那样的理解能力。因此，需要先让模型根据用户输入整理出一个合适的搜索关键词：

一般来说，根据用户输入都能总结出一个搜索关键词。但用户的输入可能包含多个问题，比如“今天天气如何？去东方明珠是否合适？”这就需要查询上海天气和东方明珠票务情况。如果混成一个关键词，可能无法搜到正确的网页。比较合理的做法是将两个需求拆分为两个搜索关键词。当然，这里为了简便，只生成一个关键词并进行一次搜索。

执行搜索

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

Google 搜索需要到谷歌后台生成搜索 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 则忽略。

格式化输入并让模型返回

有了相关网页内容的数组，还需要组织最终输入给模型的内容，让模型知道自己进行了搜索，并且有这些结果，然后根据搜索结果提供的信息来反馈用户最初的输入。

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

0x3 测试聊天助手

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

通过这两个测试结果可以发现，按照这一套流程运行下来，模型确实掌握了一些其内部原本不存在的知识，并且能够利用新增的知识进行总结输出。不过，输出似乎仍然包含一些不太准确的信息。回溯整个执行流程可以发现，在最后一次输入时，由于缺乏足够的格式化，模型并没有完全理解搜索结果是作为补充信息提供的。

当然，还有一个问题是模型全部在本地运行，因此网页提取和模型运行的时间都非常长。不过，搜索结果的返回速度倒是出乎意料地快。

0x4 优化方向

整套流程跑下来，可以看到其中还有许多可以优化的地方。如果不再纠结于本地运行模型，或者增加性能更强的模型运行设备，相信模型调用的耗时能减少一个数量级。

流程中的主要缺陷，是前面提到的搜索关键词生成以及进行多次搜索的部分。不过，该流程最大的问题还是最后一次投喂时网页内容过多。上面的两个例子中，由于网页下载失败和提取问题，最终的 Token 数量并不多。但在优化完那部分处理之后，最终可能会有数十个网页，这些网页的文字内容加起来，可能导致最后输入的 Token 超过模型的承载能力。

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

0x5 总结

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