Ollama + DeepSeek + Dify，专属私人 AI 助手？

过年火的一个关键词“哪吒”，还有一个火的词“DeepSeek”，儿子学校的信息课上都也开始让他们试用DeepSeek了，然后chatGPT,Gemini开始免费，grok3号称最聪明的模型也发布了，反正目前看使用大模型越来越日常化了。

大型语言模型（LLM）、微调模型、RAG

大型语言模型LLM

LLM，新一代的人工智能系统，能免处理并生成类似人类的文本、图片等其它数据，主要通过对海量数据进行训练，然后吧啦吧啦里面深度的工作原理就不说了，能理解、处理生成人类语言（NLP），知识解答、文章生成、语言翻译等等一些使用场景。

用一个通俗的比喻，大模型就是博览群书的人，通过阅读图书馆里面所有的图书（训练），学习到了广泛的知识和语言能力，然后就可以对图书馆里面书本涉及的问题进行解答和回复了。也就是从图书馆的书本里面出题的考卷，他可以达到满分。但是如果我从其它更专业的私域信息出题呢？那他可能就会答非所问。

微调模型

核心思想是利用已经训练好的模型，通过对特定任务的数据，进行少量的再训练，进一步调整其参数，让其更好的适应特定任务。如果你有大量的数据的话，就不需要再进行微调模型了，直接从头开始训练。微调适合数据较少但又想要提高模型对这些知识的理解。

接上面的例子，微调就是刚刚那个图书馆博览群书的人，让他考我们公司内部的管理规定的题，肯定不会。于是我把公司管理规定的手册、章程，全部扔给他，让他把这些也阅读进去，这时候再让他考这些题，这样他就可以给出满意的答卷了。但是学习也是需要时间的，我昨天更新了手册，今天就要考试怎么办呢

RAG

检索增强生成（英语：Retrieval-augmented generation, RAG ) 是赋予生成式人工智能模型信息检索能力的技术

简要的说，就是先从知识库中检索相关的信息，然后将这些信息作为上下文输入给大模型，让其生成更准确和相关的内容。就是让大型语言模型能够在生成之前，可以引用训练数据来源之外的权威知识库。

同样再接上面的例子，把微调这个人回退，不需要再读公司内部管理手册、章程了。我们把考试改为开卷考试，考试的时候可以翻阅管理规定的手册和章程，然后再自己组织语言答题。这样，就算是我前一刻更新了手册和章程，我下一刻考试的时候也可以准确的完成题目。 当然为了更好更快的查阅我们会把手册和章程重新整理一下，这是后面的。

在大家都处于大型语言模型争霸赛的时候，perplexity走出了另一条路，根据用户提出的内容，分析处理去实时检索，然后把内容再接入大型语言模型输出给用户。其关键就是RAG技术。

这里只是想通俗的演变一下三者的区别，技术没有什么优劣之分，具体看你怎么用，扁担也能挑出水网密布，河流纵横的江苏水系。

因为想试用的方案是Dify，所以后面的是RAG的原理和Dify使用的一些内容

RAG的实现原理

定义：通过查找外部信息来给出更准确、更相关的回答。

需要完成这个过程，我们需要拆成几块。

• 准备知识库需要的文档，企业内部的一些原始资料。
• 将这些文档进行数据处理，进行分块，通过嵌入模型将文本数据向量化，存储到向量数据库中。这里会用到嵌入模型。
• 信息检索。将问题转化为嵌入向量，将问题向量与数据库中的向量进行比较，找到最相似的信息片段。通常使用语义搜索技术，确保检索到的信息不仅仅是关键词匹配，而是语义上最相关的内容。
• 生成回答。将检索到的信息片段与用户问题一起作为输入，放到一个提示词模板中（增强），让大型语言模型生成最终的答案。

当然如果有PDF、图片等文档资料的话，我们在前置条件那里增加上OCR/视觉大模型来进入文本提取过程。

不管理AnythingLLM、MaxKB还是Dify都是基于检索增强生成（RAG）技术的开源知识系统，所以不管你选择哪一个系统做为你的本地部署方案，都需要处理核心的数据问题。楼主是视觉动物，单纯的觉得Dify比其它的好看，所以直接拿了Dify来试试看。

Dify+DeepSeek 开工

• 安装Ollama
• 下载DeepSeek模型，下载Text Embedding模型
• 安装Docker
• 拉Dify仓库，运行它
• 配置

楼主环境：MacOS Sequoia

安装Ollama

打开官网，下载它，按照说明，安装它，最后在终端里面运行 ollama --version 看看是否成功就行。

如果没有成功则循环这一步，直到成功为止。

下载DeepSeek 下载Text Embedding

自己量力而行，选择个版本下载即可

我在终端里面运行 ollama pull deepseek-r1:8b

还有一个一起先拉下来，后面要用的 ollama pull mxbai-embed-large

此处，等嘛。。。。。。。。。。。。。。。。。。。。。。

然后你就可以 ollama run deepseek-r1:8b 在终端跟它先玩起来了

这里有一个配置，launchctl setenv OLLAMA_HOST "0.0.0.0" 如果后面在Dify里面配置模型的时候访问不到的话，0.0.0.0表示Ollama接收来自任何IP的请求，如不想那就改为你指定的IP地址即可，如192.168.x.x

安装Docker

同第一个一样，打开官网下载它，按照说明安装它。运行Docker的时候注不注册自己看着办。

安装Dify

理论上打开github，照着他的文档直接操作就妥。

git clone https://github.com/langgenius/dify.git
cd dify/docker  
cp .env.example .env  
docker compose up -d # 如果版本是 Docker Compose V1，使用以下命令：docker-compose up -d

运行命令后，你应该会看到所有容器的状态和端口映射。

Dify的界面相关

Dify 社区版默认使用 80 端口，点击链接 http://your_server_ip 然后你就可以愉快的访问了。

别的先不用管，点右上角的个人设置，先进行模型供应商的配置。

就是配置上面那个流程里面的大型语言模型和嵌入模理。Ollama默认的端口是11434

当然如果需要调用其它的在线模型，直接输入相关模型的API Key就行了。

创建知识库

界面自己点，也就是上传文件，选择配置，然后等系统给你进行处理。

通用模式与父子模式

大语言模型能否准确的回答，取决于系统检索相关的内容块的效率。这是知识库支持的两种分模式：

**通用模式：**内容被划分别独立的块，当用户提交查询时，系统会自动计算块与查询关键字之间的相关性，然后把排名靠前的块发送到大模型去处理回复。

**父子模式：**父块（如段落）充当较大的文本单元来提供上下文，子块则侧重于精确检索。所以系统会先检索子块来确保相关性，然后再获取相应的父块来提供完整的上下文，这样来保证最终的准确性和完整性。

所以通用模式适用于快速检索独立的信息块场景，简单高效，缺点缺乏上下文信息。

父子模式适用于提供完整上下文信息的场景，能够提高回答的准确和完整性，例如AI客服提供解决方案。缺点复杂一点。（选择了父子模式就只能用后面的高质量索引方式了）

通用模式里面有一个“使用Q&A分段”，是对通用模式里面分成的文本块，对于每一个分段，系统自动生成相应的问答，类似于我们常用的FAQ文档，当然是用自然语言和完整的语法结构写。如果没有这个，那我们就是“问题匹配段落”，使用了Q&A方式之后，就可以是“问题匹配问题”方式。这样的话匹配精度会更高，更准确的获取到用户需要的信息，如果有FAQ的文档直接放进来就更好了。

数据量大的小时慎点啊！让你电脑发热是真的！！！！！！！！！！！！

高质量与经济型

索引方法直接影响大模型检索效率和其对知识库内容的响应的准确性。也有两种模式：高质量和经济。

嵌入模型就是这里用的

高质量模式：Embedding 模型将文本块转换为数值向量，从而实现大量文本信息的高效压缩和存储。这可以使用户查询与文本之间的匹配更加精确。

经济模式：使用每个块 10 个关键字进行检索，不会消耗任何 token，但会降低检索准确率。对于检索出的块，仅提供倒排索引方法来选择最相关的块。

通俗的说就

高质量模式：我有高精度检索，提供多种检索方式，但我需要更多资源。

经济模式：虽然我准确率较低，但我节省资源啊

检索设置

知识库接收到用户查询后，会按照预设的检索方法搜索现有文档，并提取高度相关的内容块。

是用基于向量相似性的语义检索还是使用倒排索引的关键字匹配

向量检索：

将问题转换为向量，然后与知识裤中的文本向量进行比较，找到最相似的。

准。哪怕没有找到相关内容，也能够捕捉语义。

全文检索：

对文档中的关键字进行匹配，返回匹配用户关键字的文本片段。

快。天下武功，唯快不破。

混合检索：

顾名思义，两种方式的结合，你可以分配两种模式各种的权重，语义VS关键字

Rerank暂没发现免费的，我自己先跳过了

官方默认推荐的组合是：

父子分段+高质量+混合检索（按照他的来就行了）

添加完之后，那又到了我们等嘛的环节了，后期如果有新的文档更新在该知识库里面，添加新的文件就行了。

创建应用程度

Dify有五种类型的应用程序：

• 聊天助手：基于 LLM 构建的对话助手
• Agent：具有任务分解、推理、工具调用能力的对话式智能助手
• 文本生成应用：撰写故事、文本分类、翻译等文本生成任务的助手。
• Chatflow：具有记忆功能的多轮复杂对话任务的工作流编排
• 工作流：针对自动化、批处理等单轮任务的工作流编排

这里创建一个最简单的聊天助手。测试数据库文件是史蒂芬·巴克斯特的科幻小说《Xeelee》

提供了相应的服务端的访问API方便与其它系统的集成。

其它的应用程序，大家自己试吧，工作流感觉是高级点的COZE。

打完收工

打完收工，Q&A的分段的这个到现在还在处理中，本来打算Q&A和父子结构的做一个对比的。

回到知识库上面，对知识库的一个体验，不说工作流那部分，工作流如果有实际的场景，确实会有用得多。处理一个个人的知识库管理，如果平时有很多收集资料、代码片段或者其它碎片化信息的话，有一个这样的知识库管理，会让你更方便很多。但是如果对于自行产出的数据，而且结构清晰，这样的知识库可能帮助就会有限。

对于企业而言，在数据内容处理的达标的情况下，确实可以提高协作和沟通效率，知识库的内容是大家都认同的内容，沟通中很重要的一环就是理解一致。提高客户满意度，可以更快更准确更标准的为客户提供服务信息。重要的是知识库中的内容是重要的知识资产。

但是，关于企业知识库的建设就比个人的复杂多了，需要多个岗位或部门的互相协作，内容创建和管理又是知识库核心，所以搭一个知识库系统容易，重要是将知识库应用，使其有实用性和产生价值！