DeepSeek本地部署实战：Ollama+Dify搭建私有知识库全流程指南

最近这段时间DeepSeek的出镜率实在太高了。很多人第一反应是打开网页版或者直接调用API但真正到了自己电脑上部署一个本地模型、再配一套知识库做私有问答操作层面还是有不少坑。我前几天在一台有24GB显存的Linux工作站上把DeepSeek用Ollama跑了起来同时用Dify搭了一套本地知识库把几十篇Markdown文档变成可以检索问答的私有知识源。整个过程不算难但很琐碎尤其是模型下载、容器网络、向量化这几个环节稍不注意就会被卡住。这篇文章就把我的完整实操记录放出来包括硬件参数、Ollama部署、知识库流水线搭建以及最后整理出3个典型报错和解决思路帮你少走一点弯路。这套内容适合谁如果你有基本的Linux和Docker操作基础想在自己的电脑上完整跑通“私有模型私有知识库”那这篇应该能直接照着做。如果你只是好奇想体验一下我建议先准备一台至少16GB内存的电脑显卡有没有没关系效果好坏另说流程是完整的。1. 为什么选择“Ollama DeepSeek Dify”这套组合1.1 本地部署DeepSeek的三条路线为什么Ollama最稳本地跑大模型方案其实不少我先帮你把三条主流路线摆在一起看再解释我为什么选Ollama。部署方案上手难度推理性能适用场景Ollama低一条命令装好中等个人和小并发足够本地体验、私有知识库、中小团队内网服务vLLM高依赖Python环境和CUDA配置高吞吐量强生产级多并发服务需要精细调优TransformersHugging Face中写代码才能跑中低单请求推理偏慢研究、调试模型内部逻辑、做微调llama.cpp中高需要编译和手动管理中嵌入式设备、纯CPU推理、自定义量化我看到不少人一上来就上vLLM结果光环境就折腾了两天。其实vLLM的优势在并发吞吐个人电脑上就一个人用这个优势完全发挥不出来反而把部署复杂度拉满了。Ollama的核心优势在于把模型管理变成了像Docker一样的东西拉取模型、启动服务、暴露API都是标准操作而且自带GGUF量化支持。DeepSeek官方发布的模型权重通常量级较大Ollama官方仓库里有现成的量化版本比如deepseek-r1:7b、deepseek-r1:14b这些一条命令就能拉下来不需要自己处理权重转换。这对普通使用者来说省掉的不只是时间还有一堆隐性的坑。另外还有一点很关键Ollama对外提供HTTP API接口风格和OpenAI兼容这意味着后面接知识库工具、接聊天应用、接自动化脚本都很顺整个生态是通的。1.2 知识库的本质不是把文档塞进模型而是外挂一套检索系统很多人第一次听说“给DeepSeek建知识库”第一反应是“把文档喂给模型训练”。这里必须澄清一下这不是微调也不是训练而是RAG检索增强生成。用生活类比来说你给模型配了一个专属资料室和一名图书管理员。每次有人提问管理员先根据问题去资料室里翻出几段最相关的原文再把“问题原文片段”一起递给模型让模型基于这些原文来回答。这样一来模型不需要真的“记住”你的文档内容它只需要在回答时参考这些检索结果就行。这条流水线的标准链路是解析原始文档PDF、Markdown、Word等把文档切分成小块每一块称为一个chunk用Embedding模型把每个chunk转成向量向量写入向量数据库用户提问时把问题也转成向量在库里做相似度检索取回TopK个最相关的chunk连同问题一起组装成Prompt交给大模型生成回答所以知识库方案选型的关键不在于大模型本身而在于中间这几层工具怎么搭配。文档解析能力、切分策略、向量检索精度、Prompt组装方式每一个环节都会直接影响最终回答质量。2. 部署前的准备工作硬件评估与Ollama安装2.1 先搞清楚你的电脑能跑多大模型在动手之前我建议你花五分钟看一下自己机器的硬件情况免得模型拉下来跑不动再回头折腾。主要是三个指标显存、内存、磁盘剩余空间。DeepSeek开源模型里普通人最常用的是蒸馏版系列也就是DeepSeek-R1-Distill-Qwen系列在Ollama上对应deepseek-r1仓库的多个尺寸。不同尺寸对硬件的要求差别很大模型尺寸量化格式模型文件大小推理时实际占用推荐硬件1.5BQ4_K_M约1.1GB2GB左右显存/内存纯CPU也能跑体验可用7BQ4_K_M约4.7GB6-8GB显存8GB显存起步16GB内存14BQ4_K_M约9GB12-14GB显存16GB显存32GB内存32BQ4_K_M约20GB22-24GB显存24GB显存最好48GB内存70BQ4_K_M约42GB48GB以上显存多卡或纯CPU长推理有个粗略的计算方法如果模型文件是4.7GB7B的Q4_K_M推理时除了把权重载入显存还需要额外一部分空间做KV Cache用来缓存对话历史。上下文长度越长KV Cache占的显存越多。所以如果你只有8GB显存跑7B模型时建议把上下文长度控制在4096以内不然很容易触发显存不足。内存方面也要注意即使你用的是显卡加速Ollama启动时也会把模型文件映射到内存所以机器内存建议是模型文件大小的两倍以上避免系统内存吃紧触发OOM。磁盘就更直接了拉一个32B模型要20GB空闲空间64GB的硬盘没两天就满了。2.2 安装Ollama以及把模型下载速度提上去的办法Ollama的安装本身很简单。Linux上一条命令curl -fsSL https://ollama.com/install.sh | sh如果你不想用脚本安装也可以用Docker跑docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollamaWindows和macOS用户直接去官网下载安装包就行没有特别复杂的地方。比较麻烦的是模型下载。Ollama官方模型仓库的下载速度在不同网络环境下很不稳定很多人卡在这一步ollama pull跑到一半就断了。这里分享两个我实测下来比较稳的土办法。第一个把模型目录挪到空间足够、IO性能好的磁盘上。Ollama默认把模型存在用户目录下如果你系统盘快满了拉大模型很容易失败。通过环境变量指定目录export OLLAMA_MODELS/data/ollama/models然后重启Ollama服务再执行ollama pull。第二个办法绕开默认下载链路直接从开源模型文件托管平台获取GGUF文件再手动导入Ollama。GGUF就是Ollama底层支持的模型格式只要把文件下载到本地写一个Modelfile就能通过ollama create导入。Modelfile的写法很直接FROM ./deepseek-r1-7b-q4_k_m.gguf TEMPLATE {{- if .System }}|im_start|system {{ .System }}|im_end| {{- end }}|im_start|user {{ .Prompt }}|im_end| |im_start|assistant PARAMETER temperature 0.6 PARAMETER num_ctx 8192然后在同一个目录下执行ollama create deepseek-r1 -f Modelfile用这招的好处是下载可以断点续传配合aria2这类多线程下载工具速度比直接拉Ollama仓库稳定很多。下载完成后一定要校验文件完整性比如对比SHA256哈希否则导入后运行会出莫名其妙的错误。这个在后面的报错章节会提到。2.3 拉取DeepSeek模型并掌握日常管理命令如果你的网络环境没问题其实一条命令就能拉模型ollama pull deepseek-r1:7b拉完之后先跑起来验证一下ollama run deepseek-r1:7b进去后随便问一个问题比如“11等于几”确认模型有回复再退出。这一步是排除基础故障的关键很多人都跳过了结果最后知识库调不通不知道是模型问题还是别的环节问题。平时管理Ollama这几个命令必须熟ollama list # 查看本机已有的模型 ollama ps # 查看当前正在运行的模型进程 ollama stop model-name # 停止某个模型 ollama rm model-name # 删除某个模型释放磁盘空间 ollama serve # 前台启动API服务默认端口11434如果你需要让Ollama接受来自其他机器或Docker容器的请求记得设置监听地址export OLLAMA_HOST0.0.0.0默认情况下Ollama只监听127.0.0.1后面对接Dify容器时如果你不做处理容器里的服务访问不到宿主机上的Ollama这一步就是坑。3. 知识库构建从一堆混乱文档到一个可检索的向量仓库3.1 RAG工具怎么选Dify、RagFlow、AnythingLLM还是自研知识库工具的选择直接决定了你的开发效率和后期维护成本。我把我接触过的几个方案拉了一张表你按自己的场景挑。工具定位优点缺点合适场景Dify可视化LLM应用平台流水线完整知识库Agent工作流都有社区活跃部署稍重需要Docker全家桶做完整业务应用、接多个模型、团队协作RagFlow深度文档解析引擎对复杂PDF、表格、扫描件的解析能力强界面和配置项偏专业上手曲线略陡文档格式混乱、需要高质量解析AnythingLLM轻量桌面/私有工具开箱即用单机部署简单扩展性弱不适合做复杂业务集成个人笔记、本地文件问答自研LangChain脚本代码层面逐环节控制最灵活完全可控开发量大所有环节自己造轮子研究、评估、特殊格式处理这篇教程我推荐Dify。原因有三个第一Dify本身就把RAG流水线封装好了不需要自己写向量检索代码第二它能直接对接Ollama模型管理不用另做一套第三它自带后台界面后续调整提示词、测试效果都比纯脚本直观得多。后面第4章我会完整演示Dify的配置过程。如果你的文档特别复杂比如大量扫描件、复杂表格那RagFlow的解析能力确实更强。但普通人的Markdown、PDF文章Dify自带的解析足够用没必要人为增加复杂度。3.2 文档切分策略为什么无脑按字数切效果反而更差RAG里最影响回答质量的一环其实是文档切分。切得太小单个chunk承载的上下文信息不足模型拿到片段也答不清楚切得太大向量检索的精度下降而且超过模型上下文长度后还会被截断。我自己习惯的做法是优先按章节和语义边界切而不是按固定字数硬切。比如对Markdown文档二级标题就是一个天然的分割点。工具层面我推荐用LangChain的RecursiveCharacterTextSplitter它支持按分隔符优先级递归切分。from langchain_text_splitters import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , , , , ] ) chunks splitter.split_text(document_content)这里有两个参数值得细说chunk_size500每个chunk大约500个字符。这个数值不是拍脑袋定的太短会导致信息碎片化太长则会让向量检索的精度下降。500左右对中文文档比较平衡。chunk_overlap50相邻chunk重叠50个字符。为什么要重叠因为用户的问题可能恰好横跨两个chunk的边界如果没有任何重叠这段关键信息就会被切成两半检索时两边都搜不全。50个字符相当于一两句话的长度能有效缓解边界断裂问题。分隔符的优先级顺序也很重要。我的经验是段落边界\n\n最优先其次是换行再往下是句子标点。这样切出来chunk基本能保持语义完整而不是把一段话从中间劈开。实际测试中我发现如果把chunk_size调成2000检索结果经常出现大段不相关内容调成100又会漏信息。所以500起步根据文档类型再做微调是一个比较稳妥的思路。3.3 Embedding模型与向量库选型把文本转成向量是RAG的核心环节这里有两个选择要做一是Embedding模型二是向量数据库。Embedding模型我推荐用本地模型比如智源的bge-m3或者Ollama仓库里的nomic-embed-text。为什么要本地因为知识库里的文档经常涉及隐私内容如果用在线Embedding API等于把文档内容发到外部服务隐私风险不可控。当然如果你对隐私没要求在线API的效果通常更好比如OpenAI的text-embedding-3-small检索精度更高。本地Embedding模型照样可以通过Ollama跑起来命令如下ollama pull bge-m3然后配合Ollama的Embedding接口使用。在LangChain里的写法是这样from langchain_community.embeddings import OllamaEmbeddings embeddings OllamaEmbeddings( modelbge-m3, base_urlhttp://localhost:11434 )向量数据库方面开发调试阶段用Chroma最方便它是纯本地嵌入式库不需要单独起服务from langchain_chroma import Chroma vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db )生产环境再考虑Qdrant或Milvus。Dify自带了对向量数据库的集成默认用的是Weaviate安装Dify时容器会一并启动不需要额外配置。检索时还有一个关键参数相似度阈值。向量检索返回的每条结果都会带有相似度分数如果阈值设得太低一堆不相关内容会被塞进Prompt设得太高又会漏掉能回答问题的片段。不同模型对相似度的度量方式不一样bge-m3默认的余弦相似度阈值在0.5左右比较合理。实际调的时候建议多看测试样例找到自己的平衡点。3.4 检索结果如何放进Prompt模板与兜底策略模型最终的回答质量很大程度取决于Prompt怎么组织。我用的系统Prompt模板是这样的你是一位严谨的智能客服。回答用户问题时必须优先依据给定的知识库片段。 如果片段中没有相关信息请直接回答“当前知识库中没有找到相关信息”不要编造。 引用片段内容时尽量在回答末尾注明来源文档。 参考片段 {context} 用户问题 {query}这里有两个关键设计其一强制要求“片段中没有就直说没有”这是为了压制大模型的幻觉。没有这个约束模型在面对检索不到的问题时也会强撑着编一个答案这对知识库应用是致命的。其二{context}和{query}是占位符实际应用时会被检索到的chunk和用户问题替换。在Dify里你不需要手动写这段模板界面中有系统提示词编辑框直接把模板填进去然后在编排页面把知识检索的结果变量关联到context位置就行。检索参数里最常用的两个是TopK和Score阈值。TopK决定取回几条相关片段我一般设4。片段太少信息不全片段太多Prompt过长模型容易抓不住重点。Score阈值设置为0.5低于这个相似度的片段直接丢弃避免噪音干扰。4. Dify全流程实操把DeepSeek和知识库串起来4.1 Dify安装并打通与Ollama的网络Dify的官方部署方式是Docker Compose。先把项目克隆到服务器上git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d第一次启动会拉很多镜像需要耐心等一会儿。启动完成后浏览器访问http://localhost按引导设置管理员账号然后进入主界面。这里有一个极其常见的坑Dify跑在Docker容器里Ollama跑在宿主机上容器内默认访问不到宿主机。具体表现就是你在Dify配置模型时填了http://localhost:11434但一直连接失败。解决思路有两个。第一个在Dify容器里用host.docker.internal这个特殊域名指向宿主机API Base URL: http://host.docker.internal:11434Windows、macOS的Docker Desktop默认支持这个域名。Linux上如果没生效需要给容器加extra_hosts配置extra_hosts: - host.docker.internal:host-gateway第二个思路把Ollama也塞进Docker网络用容器名通信。先创建网络再启动Ollama容器docker network create dify-network docker run -d --name ollama --network dify-network \ -v ollama:/root/.ollama -p 11434:11434 \ ollama/ollama然后在Dify里填http://ollama:11434就行。这种方式对Linux环境最省事也是我个人推荐的做法。4.2 在Dify中添加Ollama模型并创建数据集进入Dify控制台后先点右上角头像进入“设置”找到“模型供应商”选择Ollama填入API Base URL。模型名填deepseek-r1:7b上下文长度建议填8192最大Token设置2048温度可以设0.3。推理温度在知识库问答场景里要低一点因为你可以让模型更“保守”、更贴近原文而不是天马行空。模型配置完成后接下来创建数据集。点击“知识库”页面的“创建知识库”填写名称上传你的文档。上传后关键的一步是分段设置Dify提供了“自动分段”和“自定义分段”两种模式自动分段Dify会按段落边界自动切分适合格式规整的Markdown。自定义分段手动指定分段标识符、分段长度和重叠长度。我用的是分段标识符\n\n最大分段长度500字符分段重叠50字符。索引方式选择“高质量”Embedding模型选bge-m3。保存后Dify会跑一批索引任务等进度条走完右上角可以看到每个文档的状态。跑完后随便点开一个文档预览一下切分结果看看有没有把一句话拦腰截断这一步很值得做。4.3 创建聊天应用完成“检索生成”的闭环回到控制台首页创建“聊天助手”应用。在编排页面左侧先把刚才创建的知识库通过“上下文”功能关联进来。然后编辑系统提示词把3.4节那个模板填进去。在变量关联区域把知识检索的结果映射到{context}位置。右侧的调试框现在可以测试了。问一个问题看返回结果的同时点击回答下方的“引用”标签能看到模型到底参考了哪些文档片段。这一步是验证RAG有没有生效的关键如果引用片段和你问的问题明显不搭说明切分或检索参数有问题如果引用很合理但回答不对那问题多半出在Prompt模板上。我第一次配置时测试“什么是链式调用”这个问题模型回复了一段似是而非的话点开引用发现它把“链式调用”和“线性表”的片段混在一起了。后来把Score阈值从0.3调到0.5并稍微调整了检索模式为“混合检索”也就是关键词检索和向量检索同时跑再合并排序结果才正常。混搜对技术文档尤其有用因为很多术语在词面上和向量相似度上可能不对齐两种方式互为补充。5. 3个高频报错排查实录5.1 报错一拉取模型时提示request failed或unexpected EOF这个报错出现在执行ollama pull时现象是Error: pull model manifest: unexpected EOF或者更常见的长任务中断Error: request failed: client write exception: broken pipe我排查这个问题的经验是三步走。第一步先df -h检查磁盘空间模型文件超过4GB时很多临时目录不够大的机器会在下载中途直接失败。如果磁盘满了先ollama list看看有没有不用的模型ollama rm清掉再说。第二步是检查磁盘剩余空间但这里的“剩余空间”不只是模型文件的大小。因为下载过程里Ollama先把文件写入临时文件再原子性地移动到模型目录所以临时目录也需要一倍文件大小的剩余空间。如果你自定义了OLLAMA_MODELS目录还要检查那个目录所在分区的空间。第三步如果磁盘没问题基本可以判定是网络传输不稳定。这种情况我不建议反复重试ollama pull比较可靠的是前面2.2节提到的手动下载GGUF文件导入法。用支持断点续传的下载工具把模型完整拉下来核对哈希后写Modelfile导入。这个办法能把“下载中断”这个问题彻底绕开因为你已经拿到一份真实的模型文件了。5.2 报错二ollama run时报500错误提示llama-server process这个报错很经典现象是输入ollama run deepseek-r1:7b后模型刚开始加载几秒钟内直接断开返回Error: 500 Internal Server Error: llama-server process我见过很多人都卡在这里而且一脸懵因为500错误只告诉你服务端处理失败了完全没有具体原因。排查思路要自己拆解。首要怀疑对象是显存不足。7B模型Q4量化后约4.7GB看起来8GB显存能装下但Ollama加载模型时还要额外分配KV Cache和计算缓冲区所以实际占用经常比模型文件大30%以上。如果在加载模型的同时还有其他程序占用显存很容易触发OOM。先执行nvidia-smi看一眼显存使用量如果快满了关掉其他GPU进程再来一次。第二个可能原因是模型文件损坏。如果你用了手动导入GGUF的方式但是没有校验哈希或者下载工具在中断后没做完整性检查文件损坏的概率很高。Ollama检测不到文件损坏但加载时能崩。解决方法是删除重新导入导入前务必比对SHA256。第三个原因比较隐蔽模型在加载时Ollama需要启动llama-server子进程如果系统的文件描述符限制太低或者内存不足这个子进程会启动失败。可以临时调高文件描述符限制ulimit -n 65535然后把Ollama服务的前台日志打开具体看报错在哪个阶段ollama serve前台运行能把错误日志直接打到终端。如果想看已有的服务日志可以用journalctl -u ollama -f。日志里如果出现CUDA相关的out of memory那就坐实是显存问题如果是mmap failed则是内存不足或磁盘映射失败。定位到具体原因再动手盲试只会浪费时间。5.3 报错三知识库后台执行SQL时报MySQL 1064语法错误这个报错严格来说不是Ollama或DeepSeek的但凡是涉及Dify、RagFlow这类平台的人十有八九在维护后台时会把MySQL翻出来看一眼然后一执行就撞上1064。典型现象mysql SELECT id, title FROM dataset WHERE status正常 LIMIT 10; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version很多人的第一反应是“我的SQL哪里写错了明明很简单”但实际上1064报错的引发点可能很隐蔽我整理了三个最容易触发的原因。第一个也是最常见的SQL里用了中文引号或中文标点。比如正常被输入成了‘正常’MySQL解析器直接懵了。这个问题的根源是输入法自动把英文引号转换成了中文全角引号。解决方法是在SQL客户端里关闭自动校正或者养成就地检查引号类型的习惯。第二个原因是关键字冲突。dataset、status、order这些词在MySQL里可能是保留字或未来保留字直接当表名或字段名用在某些版本和模式下会报语法错误。解决办法是给表名和字段名加反引号SELECT id, title FROM dataset WHERE status正常 LIMIT 10;第三个原因是字符集不对。如果某张表的字符集是latin1而你要写入中文内容在特定SQL模式下也会被解析成异常格式表现为1064或者相近的字符集报错。检查表的字符集设置统一改为utf8mb4比较好ALTER TABLE dataset CONVERT TO CHARACTER SET utf8mb4;另外还有个小建议如果你是在Dify源码里手动改数据库或者执行自己写的初始化脚本最好先关闭事务自动提交测试无误后再提交免得半路报错留下半成品数据。对知识库平台而言后台直接操作数据库永远是最后手段能用界面上配置解决的就不该动SQL。6. 部署后的性能调优与运维建议6.1 用环境变量控制并发与显存模型跑起来只是第一步真正日常用的时候性能和稳定性的平衡才是关键。Ollama暴露了几个很有用的环境变量OLLAMA_NUM_PARALLEL单个模型允许同时处理的请求数。默认值是1也就是串行处理。如果你的显存余量够大可以调成2或4提升并发吞吐能力。但每增加一个并发KV Cache会翻倍显存压力陡增。OLLAMA_MAX_LOADED_MODELS同时加载到内存/显存的模型数量。默认没做限制但如果你有多个模型全部加载会让显存瞬间爆炸。建议显存小于24GB的机器设成1。OLLAMA_KEEP_ALIVE模型在完成请求后驻留内存的时间默认5分钟。如果频繁调用可以调长减少重复加载的开销如果内存紧张可以调短甚至设为0。这些环境变量可以在启动Ollama前设置也可以写进systemd服务配置里[Service] EnvironmentOLLAMA_HOST0.0.0.0 EnvironmentOLLAMA_NUM_PARALLEL2 EnvironmentOLLAMA_MAX_LOADED_MODELS1 EnvironmentOLLAMA_KEEP_ALIVE15m设置完后重启Ollama服务生效systemctl daemon-reload systemctl restart ollama6.2 让Ollama以系统服务方式常驻用官方安装脚本装的Ollama通常已经注册了systemd服务但如果你是用Docker方式部署或者手动安装的服务可能需要自己配。下面是完整的systemd单元文件[Unit] DescriptionOllama REST API Service Afternetwork-online.target [Service] ExecStart/usr/local/bin/ollama serve Useryour_username Restartalways RestartSec5 EnvironmentOLLAMA_HOST0.0.0.0 EnvironmentOLLAMA_MODELS/data/ollama/models [Install] WantedBydefault.target把your_username换成本机用户路径换成你实际的Ollama二进制位置。然后sudo systemctl daemon-reload sudo systemctl enable --now ollama这样即使机器重启Ollama也会自动拉起来。我实际工作中吃过不少亏机器重启后模型没了或者API服务没起来前端应用全部报错所以这一步不要漏掉。6.3 无GPU设备和边缘设备的补充思路如果你的机器没有独立显卡或者目标是Jetson Orin这类边缘设备部署逻辑其实一样只是模型选择要更保守。纯CPU推理建议选1.5B或7B量化模型Q4_K_M级别。7B模型在主流桌面CPU上大约每秒8到12个token用来做离线问答够用但做流式交互就明显卡了。内存一定要给够7B Q4加载进内存就是4.7GB起步加上运行开销16GB内存是底线。Jetson Orin这类设备由于显存和内存统一且算力相对有限建议优先考虑1.5B或7B的量化模型。如果要做知识库BGE系列Embedding模型也可以跑但检索量大的时候同样吃算力建议控制知识库规模文档总量不要超过几千个chunk否则每次查询的向量化耗时会让体验明显变差。真正用到边缘设备生产环境的场景我更推荐用官方提供的TensorRT优化方案或者本地量化后再做精度校准这个方向比较深这里先不作展开。核心思路是模型规模不是越大越好而是刚好放在你的内存和算力里才算好。这套“Ollama DeepSeek Dify”组合跑通之后我的真实感受是本地大模型并没有想象中那么遥远整个流程只要每个环节都搞清楚为什么这样做遇到报错就不会慌。尤其是知识库这部分RAG的链路很长任何一个环节的默认参数都可能不适合你的文档调试时要有耐心一个变量一个变量地改。最后再分享一个小技巧每次调整完切分参数或检索阈值后用同一组测试问题去验证固定变量否则你根本不知道是哪一步让效果变好或者变差。