拓冰网站定制 
简介本资源是一份面向AI应用开发初学者与个人知识库搭建者的完整部署教程文档围绕ollama、deepseek、docker与Dify四款工具的协同使用展开帮助读者在本地Windows环境下搭建可检索、可问答的个人知识库系统。压缩包内共1个doc文件约5.19MB以图文步骤形式记录从环境准备到知识库上线的全过程。教程内容覆盖ollama安装与环境变量配置、deepseek-r1模型下载与命令行运行、docker-desktop部署、Dify项目源码拉取与容器启动以及知识库创建、分词配置、聊天应用接入ollama接口等关键环节并附有端口填写与模型选择等实操细节。目前已有3387人学习适合希望低成本整合本地大模型与知识检索能力的开发者参考也可作为排查部署问题的对照手册。1. 从零搭一套本地知识库ollamadeepseekdockerDify 到底解决什么问题很多人第一次听到「本地知识库」这四个字脑子里浮现的是把公司几百份 PDF 丢进某个网页然后就能对着文档提问。真动手才发现卡点根本不在模型而在链路模型跑在哪、向量库放哪、编排层怎么调、前端怎么接。这套 ollamadeepseekdockerDify 的组合本质是把「模型推理」和「应用编排」拆成两层——ollama 负责在本地把 deepseek 这类模型跑起来Docker 负责把 Dify 及其依赖Postgres、Redis、向量库打包成可复现的容器Dify 负责把知识库检索、提示词、工作流串成一条流水线。它适合两类人一类是数据不能出内网的团队另一类是想把 RAG 流程摸透、不想被云服务黑匣子挡住的工程师。下面按「先跑通、再调优、最后避坑」的顺序讲每一步都给可抄的命令和参数。2. 环境准备Docker、ollama 与 deepseek 模型的三件套落地2.1 Docker Desktop 安装与 virtualization 报错处理Windows 上装 Docker Desktop最常见的翻车不是下载慢而是启动时弹virtualization support not detected或docker desktop failed to start because virtualization support is not enabled。这不是 Docker 的锅是主板 BIOS 里 Intel VT-x / AMD-V 没开或者被 Hyper-V、WSL2 的嵌套虚拟化挡住了。处理顺序我一般这么走# 1. 确认 WSL2 是否就绪Windows 管理员 PowerShell wsl --status wsl --update # 2. 确认虚拟化已开启返回 True 才算过 (Get-CimInstance Win32_Processor).VirtualizationFirmwareEnabled # 3. 若为 False进 BIOS 打开 Intel VT-x / AMD-V再重启逻辑说明wsl --status看默认版本是不是 2Docker Desktop 现在默认走 WSL2 后端VirtualizationFirmwareEnabled为 False 时任何软件层操作都白搭必须进 BIOS。参数上WSL2 建议在.wslconfig里限制内存避免 Docker 把宿主吃满# 用户目录下新建 .wslconfig [wsl2] memory8GB processors4 swap2GBmemory按宿主物理内存的 1/4 到 1/3 给processors别超过物理核数的一半否则模型推理和容器会互相抢。Linux 用户直接apt install docker.io docker-compose-plugin即可注意把当前用户加进 docker 组否则每条命令都要 sudo。2.2 ollama 安装、国内镜像源与模型存放盘迁移ollama 下载慢是高频吐槽点。官方安装脚本走的是境外源国内环境经常卡在几十 KB/s。常见做法是手动下载对应平台的安装包或者配置镜像源。Linux 下可以用环境变量指定# Linux 安装后把模型目录迁到数据盘避免系统盘爆掉 sudo mkdir -p /data/ollama/models sudo chown -R $USER:$USER /data/ollama export OLLAMA_MODELS/data/ollama/models # 写入 systemd 服务保证重启后仍生效 sudo systemctl edit ollama.service # 在 [Service] 段加入 # EnvironmentOLLAMA_MODELS/data/ollama/models # EnvironmentOLLAMA_HOST0.0.0.0:11434 sudo systemctl daemon-reload sudo systemctl restart ollama逻辑说明OLLAMA_MODELS决定模型权重落盘位置deepseek 系列动辄几个 GB放系统盘迟早满OLLAMA_HOST0.0.0.0:11434是为了让 Docker 容器内的 Dify 能通过宿主机地址访问到 ollama只监听 127.0.0.1 时容器是连不上的。Windows 下对应在「环境变量」里加OLLAMA_MODELS然后重启 ollama 托盘程序。拉模型时按显存选规格别一上来就冲最大参数ollama pull deepseek-r1:7b # 约 4.7GB8GB 显存可跑 ollama pull deepseek-r1:14b # 约 9GB建议 12GB 以上显存 ollama pull nomic-embed-text # 向量化模型知识库检索必需deepseek-r1是推理型模型回答质量好但速度慢如果只是做知识库问答7b 或 14b 在消费级显卡上更实用。nomic-embed-text是嵌入模型Dify 建知识库时要用它把文档切块转成向量这一步不能省。2.3 验证 ollama 服务与模型可用性装完别急着上 Dify先用 curl 确认服务活着# 列出已拉取模型 ollama list # 直接对话测试确认推理链路通 curl http://localhost:11434/api/generate -d { model: deepseek-r1:7b, prompt: 用一句话说明什么是向量检索, stream: false }逻辑说明/api/generate是 ollama 的原生接口stream: false让它一次性返回完整结果方便脚本判断。如果这里返回连接拒绝说明 ollama 没起或端口不对如果返回模型不存在说明 pull 没成功。这一步过了再进 Dify 配置才不会两头排查。3. Dify 容器化部署docker compose 起服务与关键配置3.1 拉取 Dify 源码与 .env 必改项Dify 官方推荐用 docker compose 部署。先把仓库拉下来进 docker 目录git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env.env里有几个参数不改后面必踩坑参数默认值建议值作用EXPOSE_NGINX_PORT808080前端访问端口80 常被占CONSOLE_API_URL空http://localhost:8080控制台 API 地址CONSOLE_WEB_URL空http://localhost:8080控制台前端地址DB_PASSWORDdifyai123456自定义强密码Postgres 密码REDIS_PASSWORDdifyai123456自定义强密码Redis 密码逻辑说明EXPOSE_NGINX_PORT改成 8080 是因为很多机器 80 端口被 IIS 或其它服务占了起不来会报端口冲突CONSOLE_API_URL和CONSOLE_WEB_URL不填登录后可能白屏或接口 404这是 Dify 部署里最隐蔽的坑之一。密码类参数改完要同步改 compose 文件里引用否则容器间连不上。3.2 docker compose up 启动与容器健康检查# 启动全部服务-d 后台运行 docker compose up -d # 查看容器状态重点看 api、worker、db、redis 是否 healthy docker compose ps # 跟踪 api 日志排查启动失败 docker compose logs -f api逻辑说明Dify 的 compose 里包含 api、worker、web、db、redis、weaviate或其它向量库等多个服务。docker compose ps里如果某个容器一直restarting基本是环境变量或依赖没就绪。api容器负责后端逻辑它起不来前端一定打不开。常见报错an error occurred during credentials validation多半是数据库密码和.env不一致或者 db 容器还没初始化完 api 就抢连了等一两分钟再docker compose restart api往往能过。3.3 首次登录与模型供应商接入 ollama浏览器打开http://localhost:8080首次进入要设管理员账号。登录后进「设置 → 模型供应商」选 Ollama# 填写的 Base URL 分两种情况 # Dify 容器内访问宿主机 ollama http://host.docker.internal:11434 # Linux 下 host.docker.internal 可能不解析改用宿主机内网 IP http://192.168.1.100:11434逻辑说明host.docker.internal是 Docker Desktop 提供的宿主机别名Windows/Mac 可用Linux 原生 Docker 默认没有这个别名要么在 compose 里加extra_hosts: - host.docker.internal:host-gateway要么直接写宿主机局域网 IP。模型名称填deepseek-r1:7b要和ollama list里完全一致大小写和冒号都不能错。嵌入模型单独配nomic-embed-text知识库检索依赖它。4. 知识库流水线文档切块、向量化与检索参数调优4.1 建知识库与文档上传的切块策略进「知识库 → 创建知识库」上传 PDF、Markdown、TXT 等。关键在切块设置参数建议值说明分段模式自定义通用模式对技术文档不够细分段标识符\n\n按段落切保留语义最大分段长度500中文技术文档 300-800 较稳分段重叠长度50防止跨段语义被切断逻辑说明切块太大检索命中后塞给模型的上下文里噪音多deepseek 容易被无关内容带偏切块太小一个完整概念被拆散检索召回率下降。分段重叠长度是后悔药让相邻块有交集避免关键句正好落在切割线上。技术文档我一般用 500 长度 50 重叠起步再根据问答效果微调。4.2 向量化与索引构建上传后 Dify 会调用配置好的嵌入模型做向量化。这一步慢是正常的几百页文档跑十几分钟不奇怪。构建完成后可以在知识库「召回测试」里验证# 召回测试输入一个文档里明确出现过的问题 # 看返回的片段是否包含答案所在段落 # Top K 先设 3Score 阈值设 0.5 起步逻辑说明Top K是返回多少个最相似片段设太大上下文超长设太小可能漏掉答案Score 阈值过滤低相似度结果太低会引入噪音太高会召回为空。这两个参数没有万能值取决于文档质量和嵌入模型建议先用几个已知答案的问题做基准测试。4.3 应用编排把知识库接进对话流新建「聊天助手」应用在「上下文」里关联刚建的知识库。提示词里要明确约束你是一个基于知识库回答的助手。 仅根据提供的上下文回答问题上下文没有的信息不要编造。 如果上下文中没有答案直接说「知识库中未找到相关内容」。 回答时引用来源文档名称。逻辑说明不写这段约束deepseek 会用自己的预训练知识「脑补」知识库就白建了。引用来源让回答可追溯方便验证检索是否命中正确文档。如果发现回答总是「未找到」先回召回测试看检索结果再决定是调切块还是调 Top K。5. 避坑与排查部署 Dify 知识库最常见的 5 个翻车点5.1 现象Dify 登录报 credentials validation 错误原因.env里数据库密码改了但 compose 文件或已初始化的 db 卷里还是旧密码api 连不上库。解决docker compose down -v清掉数据卷重新up或者进 db 容器手动改密码。生产环境别用-v会丢数据要单独改库密码并同步.env。5.2 现象ollama 在宿主机能跑Dify 里测试连接失败原因Dify 容器内localhost指向容器自己不是宿主机。解决Windows/Mac 用host.docker.internalLinux 用宿主机内网 IP或在 compose 里加extra_hosts映射。改完docker compose restart api。5.3 现象知识库检索结果答非所问原因切块长度过大导致单块混入多个主题或嵌入模型和文档语言不匹配。解决把最大分段长度从 1000 降到 500 左右重叠设 50确认嵌入模型支持中文nomic-embed-text对中英文都还行纯中文场景可以换 bge 系列。5.4 现象对话上下文超长模型开始胡言乱语原因Top K 设太大或历史对话没做截断上下文窗口被塞满。解决Top K 降到 3-5在应用编排里开启「上下文轮数限制」一般保留最近 3-5 轮deepseek-r1 的上下文窗口有限超了会截断或报错。5.5 现象docker compose up 卡在拉镜像或容器反复重启原因镜像源慢或内存不足导致 OOM。解决配置 Docker 镜像加速器给 WSL2 或 Docker 分配足够内存建议 8GB 起docker compose logs看具体哪个容器挂逐个排查依赖顺序。6. 进阶技巧用工作流把知识库问答做成可复用流水线跑通基础问答后真正拉开差距的是工作流。Dify 的「工作流」可以把「问题改写 → 知识库检索 → 模型生成 → 结果格式化」串成节点比单轮聊天助手可控得多。一个实用技巧是加「问题改写」节点用户问「这个怎么配」直接检索大概率召回不准先让 deepseek 把问题改写成「Docker 部署 Dify 时环境变量怎么配置」再拿去检索命中率明显提升。工作流节点顺序 1. 开始节点接收用户输入 query 2. LLM 节点问题改写把 query 改写成适合检索的完整问句 3. 知识库检索节点用改写后的问题检索Top K4 4. LLM 节点生成拼接检索结果和原始问题生成回答 5. 结束节点输出回答和引用来源参数上问题改写节点的提示词要明确「只输出改写后的问句不要解释」检索节点和生成节点用不同模型也可以改写用 7b 够快生成用 14b 质量更好。验证方法很简单准备 10 个真实用户会问的模糊问题对比加改写节点前后的召回命中率一般能提升两到三成。我自己的习惯是每次调完切块或 Top K都固定用同一组测试问题跑一遍把命中情况记在表格里不然改着改着就忘了哪版效果最好。本地知识库这东西模型只是下限检索质量才是上限。希望帮到你。本文还有配套的精品资源点击获取 本地知识库搭建实战：ollama+deepseek+docker+Dify全流程指南
简介本资源是一份面向AI应用开发初学者与个人知识库搭建者的完整部署教程文档围绕ollama、deepseek、docker与Dify四款工具的协同使用展开帮助读者在本地Windows环境下搭建可检索、可问答的个人知识库系统。压缩包内共1个doc文件约5.19MB以图文步骤形式记录从环境准备到知识库上线的全过程。教程内容覆盖ollama安装与环境变量配置、deepseek-r1模型下载与命令行运行、docker-desktop部署、Dify项目源码拉取与容器启动以及知识库创建、分词配置、聊天应用接入ollama接口等关键环节并附有端口填写与模型选择等实操细节。目前已有3387人学习适合希望低成本整合本地大模型与知识检索能力的开发者参考也可作为排查部署问题的对照手册。1. 从零搭一套本地知识库ollamadeepseekdockerDify 到底解决什么问题很多人第一次听到「本地知识库」这四个字脑子里浮现的是把公司几百份 PDF 丢进某个网页然后就能对着文档提问。真动手才发现卡点根本不在模型而在链路模型跑在哪、向量库放哪、编排层怎么调、前端怎么接。这套 ollamadeepseekdockerDify 的组合本质是把「模型推理」和「应用编排」拆成两层——ollama 负责在本地把 deepseek 这类模型跑起来Docker 负责把 Dify 及其依赖Postgres、Redis、向量库打包成可复现的容器Dify 负责把知识库检索、提示词、工作流串成一条流水线。它适合两类人一类是数据不能出内网的团队另一类是想把 RAG 流程摸透、不想被云服务黑匣子挡住的工程师。下面按「先跑通、再调优、最后避坑」的顺序讲每一步都给可抄的命令和参数。2. 环境准备Docker、ollama 与 deepseek 模型的三件套落地2.1 Docker Desktop 安装与 virtualization 报错处理Windows 上装 Docker Desktop最常见的翻车不是下载慢而是启动时弹virtualization support not detected或docker desktop failed to start because virtualization support is not enabled。这不是 Docker 的锅是主板 BIOS 里 Intel VT-x / AMD-V 没开或者被 Hyper-V、WSL2 的嵌套虚拟化挡住了。处理顺序我一般这么走# 1. 确认 WSL2 是否就绪Windows 管理员 PowerShell wsl --status wsl --update # 2. 确认虚拟化已开启返回 True 才算过 (Get-CimInstance Win32_Processor).VirtualizationFirmwareEnabled # 3. 若为 False进 BIOS 打开 Intel VT-x / AMD-V再重启逻辑说明wsl --status看默认版本是不是 2Docker Desktop 现在默认走 WSL2 后端VirtualizationFirmwareEnabled为 False 时任何软件层操作都白搭必须进 BIOS。参数上WSL2 建议在.wslconfig里限制内存避免 Docker 把宿主吃满# 用户目录下新建 .wslconfig [wsl2] memory8GB processors4 swap2GBmemory按宿主物理内存的 1/4 到 1/3 给processors别超过物理核数的一半否则模型推理和容器会互相抢。Linux 用户直接apt install docker.io docker-compose-plugin即可注意把当前用户加进 docker 组否则每条命令都要 sudo。2.2 ollama 安装、国内镜像源与模型存放盘迁移ollama 下载慢是高频吐槽点。官方安装脚本走的是境外源国内环境经常卡在几十 KB/s。常见做法是手动下载对应平台的安装包或者配置镜像源。Linux 下可以用环境变量指定# Linux 安装后把模型目录迁到数据盘避免系统盘爆掉 sudo mkdir -p /data/ollama/models sudo chown -R $USER:$USER /data/ollama export OLLAMA_MODELS/data/ollama/models # 写入 systemd 服务保证重启后仍生效 sudo systemctl edit ollama.service # 在 [Service] 段加入 # EnvironmentOLLAMA_MODELS/data/ollama/models # EnvironmentOLLAMA_HOST0.0.0.0:11434 sudo systemctl daemon-reload sudo systemctl restart ollama逻辑说明OLLAMA_MODELS决定模型权重落盘位置deepseek 系列动辄几个 GB放系统盘迟早满OLLAMA_HOST0.0.0.0:11434是为了让 Docker 容器内的 Dify 能通过宿主机地址访问到 ollama只监听 127.0.0.1 时容器是连不上的。Windows 下对应在「环境变量」里加OLLAMA_MODELS然后重启 ollama 托盘程序。拉模型时按显存选规格别一上来就冲最大参数ollama pull deepseek-r1:7b # 约 4.7GB8GB 显存可跑 ollama pull deepseek-r1:14b # 约 9GB建议 12GB 以上显存 ollama pull nomic-embed-text # 向量化模型知识库检索必需deepseek-r1是推理型模型回答质量好但速度慢如果只是做知识库问答7b 或 14b 在消费级显卡上更实用。nomic-embed-text是嵌入模型Dify 建知识库时要用它把文档切块转成向量这一步不能省。2.3 验证 ollama 服务与模型可用性装完别急着上 Dify先用 curl 确认服务活着# 列出已拉取模型 ollama list # 直接对话测试确认推理链路通 curl http://localhost:11434/api/generate -d { model: deepseek-r1:7b, prompt: 用一句话说明什么是向量检索, stream: false }逻辑说明/api/generate是 ollama 的原生接口stream: false让它一次性返回完整结果方便脚本判断。如果这里返回连接拒绝说明 ollama 没起或端口不对如果返回模型不存在说明 pull 没成功。这一步过了再进 Dify 配置才不会两头排查。3. Dify 容器化部署docker compose 起服务与关键配置3.1 拉取 Dify 源码与 .env 必改项Dify 官方推荐用 docker compose 部署。先把仓库拉下来进 docker 目录git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env.env里有几个参数不改后面必踩坑参数默认值建议值作用EXPOSE_NGINX_PORT808080前端访问端口80 常被占CONSOLE_API_URL空http://localhost:8080控制台 API 地址CONSOLE_WEB_URL空http://localhost:8080控制台前端地址DB_PASSWORDdifyai123456自定义强密码Postgres 密码REDIS_PASSWORDdifyai123456自定义强密码Redis 密码逻辑说明EXPOSE_NGINX_PORT改成 8080 是因为很多机器 80 端口被 IIS 或其它服务占了起不来会报端口冲突CONSOLE_API_URL和CONSOLE_WEB_URL不填登录后可能白屏或接口 404这是 Dify 部署里最隐蔽的坑之一。密码类参数改完要同步改 compose 文件里引用否则容器间连不上。3.2 docker compose up 启动与容器健康检查# 启动全部服务-d 后台运行 docker compose up -d # 查看容器状态重点看 api、worker、db、redis 是否 healthy docker compose ps # 跟踪 api 日志排查启动失败 docker compose logs -f api逻辑说明Dify 的 compose 里包含 api、worker、web、db、redis、weaviate或其它向量库等多个服务。docker compose ps里如果某个容器一直restarting基本是环境变量或依赖没就绪。api容器负责后端逻辑它起不来前端一定打不开。常见报错an error occurred during credentials validation多半是数据库密码和.env不一致或者 db 容器还没初始化完 api 就抢连了等一两分钟再docker compose restart api往往能过。3.3 首次登录与模型供应商接入 ollama浏览器打开http://localhost:8080首次进入要设管理员账号。登录后进「设置 → 模型供应商」选 Ollama# 填写的 Base URL 分两种情况 # Dify 容器内访问宿主机 ollama http://host.docker.internal:11434 # Linux 下 host.docker.internal 可能不解析改用宿主机内网 IP http://192.168.1.100:11434逻辑说明host.docker.internal是 Docker Desktop 提供的宿主机别名Windows/Mac 可用Linux 原生 Docker 默认没有这个别名要么在 compose 里加extra_hosts: - host.docker.internal:host-gateway要么直接写宿主机局域网 IP。模型名称填deepseek-r1:7b要和ollama list里完全一致大小写和冒号都不能错。嵌入模型单独配nomic-embed-text知识库检索依赖它。4. 知识库流水线文档切块、向量化与检索参数调优4.1 建知识库与文档上传的切块策略进「知识库 → 创建知识库」上传 PDF、Markdown、TXT 等。关键在切块设置参数建议值说明分段模式自定义通用模式对技术文档不够细分段标识符\n\n按段落切保留语义最大分段长度500中文技术文档 300-800 较稳分段重叠长度50防止跨段语义被切断逻辑说明切块太大检索命中后塞给模型的上下文里噪音多deepseek 容易被无关内容带偏切块太小一个完整概念被拆散检索召回率下降。分段重叠长度是后悔药让相邻块有交集避免关键句正好落在切割线上。技术文档我一般用 500 长度 50 重叠起步再根据问答效果微调。4.2 向量化与索引构建上传后 Dify 会调用配置好的嵌入模型做向量化。这一步慢是正常的几百页文档跑十几分钟不奇怪。构建完成后可以在知识库「召回测试」里验证# 召回测试输入一个文档里明确出现过的问题 # 看返回的片段是否包含答案所在段落 # Top K 先设 3Score 阈值设 0.5 起步逻辑说明Top K是返回多少个最相似片段设太大上下文超长设太小可能漏掉答案Score 阈值过滤低相似度结果太低会引入噪音太高会召回为空。这两个参数没有万能值取决于文档质量和嵌入模型建议先用几个已知答案的问题做基准测试。4.3 应用编排把知识库接进对话流新建「聊天助手」应用在「上下文」里关联刚建的知识库。提示词里要明确约束你是一个基于知识库回答的助手。 仅根据提供的上下文回答问题上下文没有的信息不要编造。 如果上下文中没有答案直接说「知识库中未找到相关内容」。 回答时引用来源文档名称。逻辑说明不写这段约束deepseek 会用自己的预训练知识「脑补」知识库就白建了。引用来源让回答可追溯方便验证检索是否命中正确文档。如果发现回答总是「未找到」先回召回测试看检索结果再决定是调切块还是调 Top K。5. 避坑与排查部署 Dify 知识库最常见的 5 个翻车点5.1 现象Dify 登录报 credentials validation 错误原因.env里数据库密码改了但 compose 文件或已初始化的 db 卷里还是旧密码api 连不上库。解决docker compose down -v清掉数据卷重新up或者进 db 容器手动改密码。生产环境别用-v会丢数据要单独改库密码并同步.env。5.2 现象ollama 在宿主机能跑Dify 里测试连接失败原因Dify 容器内localhost指向容器自己不是宿主机。解决Windows/Mac 用host.docker.internalLinux 用宿主机内网 IP或在 compose 里加extra_hosts映射。改完docker compose restart api。5.3 现象知识库检索结果答非所问原因切块长度过大导致单块混入多个主题或嵌入模型和文档语言不匹配。解决把最大分段长度从 1000 降到 500 左右重叠设 50确认嵌入模型支持中文nomic-embed-text对中英文都还行纯中文场景可以换 bge 系列。5.4 现象对话上下文超长模型开始胡言乱语原因Top K 设太大或历史对话没做截断上下文窗口被塞满。解决Top K 降到 3-5在应用编排里开启「上下文轮数限制」一般保留最近 3-5 轮deepseek-r1 的上下文窗口有限超了会截断或报错。5.5 现象docker compose up 卡在拉镜像或容器反复重启原因镜像源慢或内存不足导致 OOM。解决配置 Docker 镜像加速器给 WSL2 或 Docker 分配足够内存建议 8GB 起docker compose logs看具体哪个容器挂逐个排查依赖顺序。6. 进阶技巧用工作流把知识库问答做成可复用流水线跑通基础问答后真正拉开差距的是工作流。Dify 的「工作流」可以把「问题改写 → 知识库检索 → 模型生成 → 结果格式化」串成节点比单轮聊天助手可控得多。一个实用技巧是加「问题改写」节点用户问「这个怎么配」直接检索大概率召回不准先让 deepseek 把问题改写成「Docker 部署 Dify 时环境变量怎么配置」再拿去检索命中率明显提升。工作流节点顺序 1. 开始节点接收用户输入 query 2. LLM 节点问题改写把 query 改写成适合检索的完整问句 3. 知识库检索节点用改写后的问题检索Top K4 4. LLM 节点生成拼接检索结果和原始问题生成回答 5. 结束节点输出回答和引用来源参数上问题改写节点的提示词要明确「只输出改写后的问句不要解释」检索节点和生成节点用不同模型也可以改写用 7b 够快生成用 14b 质量更好。验证方法很简单准备 10 个真实用户会问的模糊问题对比加改写节点前后的召回命中率一般能提升两到三成。我自己的习惯是每次调完切块或 Top K都固定用同一组测试问题跑一遍把命中情况记在表格里不然改着改着就忘了哪版效果最好。本地知识库这东西模型只是下限检索质量才是上限。希望帮到你。本文还有配套的精品资源点击获取