DeepSeek R1本地部署与知识库搭建：从Ollama到Dify实战指南

简介：PDF教程围绕DeepSeek R1的本地部署展开，面向想摆脱云端依赖、在个人电脑上运行大语言模型的开发者与普通用户。内容从安装Ollama入手，涵盖模型版本选择、命令行验证，再到Cherry-Studio界面化配置与密钥创建，最后讲解本地知识库的新建、文档添加及对话中调用。教程还针对不同内存容量的电脑给出了相应的模型选型建议，例如8GB内存可运行七十亿参数模型，16GB内存可运行一百三十亿参数模型，32GB内存可运行三百三十亿参数模型，方便用户按实际设备灵活选择。整份资源为单个PDF文件，约一点四六MB，目前已有两千零三十四人学习。对初次尝试本地部署的用户而言，这份教程最大价值在于把零散的官方文档整合为可直接跟做的完整流程，省去大量搜索与排错时间。

1. 先给 DeepSeek R1 本地部署泼盆冷水：单卡跑不动原版，知识库不是塞 PDF

DeepSeek R1 本地部署这个标题，十个人里八个是奔着“把 671B 原版塞进自己电脑”来的，但真跑过一遍就会明白，那个完整权重光下载就要几百 GB，显存需求更是直接劝退单卡用户。现实里绝大多数“本地部署 DeepSeek”教程，跑的是把 R1 蒸馏或量化过的版本，用 Ollama 这类运行时把模型拉起来，再配合一个简易本地 RAG 知识库，才让它真正能回答“我们自己的文档内容”。这套组合解决两类问题：一是数据不出内网，二是把一堆格式杂乱的资料变成能检索、能追问、能给出处的问答系统。

适合这篇文章的人也很具体：手上只有一张 8GB 到 48GB 显卡的个人开发者、需要在内网交付问答应用的实施工程师、以及被“PDF 太多找不到答案”折腾过的人。我不会从零讲大模型原理，而是按自己落地时的顺序来写：先算硬件和模型档位，跑通 Ollama，再讲知识库的切块与向量化，最后用 Dify 串成完整应用。新手能照着命令走，熟手可以直接跳第 5 章的避坑清单和第 6 章的参数调优。

2. 从硬件选型到模型拉取：跑通 DeepSeek R1 的最小命令

2.1 先算账：原版、蒸馏版和量化版怎么选

DeepSeek R1 的完整权重是 671B 参数的 MoE 模型，虽然每次生成只激活约 37B 参数，但要装下全部权重，模型文件就要占用 350GB 以上，推理时显存随手配到 80GB 起步，个人电脑基本不用想。这决定了本地部署大语言模型的通行路径：要么对原始权重做低比特量化，要么直接用官方蒸馏版。Ollama 生态里deepseek-r1系列把这两种形态都打好了标签，从 1.5B 到 70B 都有，这才是大多数教程里真正能落地的对象。

我把常见的档位整理成一张表，方便你对着自己的显卡估算。注意体量以拉取时的实际输出为准，下面是大致范围：

选型的核心原则是“先过内存线，再谈质量”。8B 档位适合第一次跑通流程；如果显卡在 16GB 以上，14B 的综合性价比最高；要拿去支撑团队知识库问答，32B 和 70B 的效果差距会在长文档、多轮对话里明显拉开。不要一上来就拉 70B，本地部署的翻车大部分发生在显存不够、服务被系统 OOM，以及后续知识库的向量索引抢占内存上。

还有一个很容易混淆的点：蒸馏版和量化版不是一回事。蒸馏版是拿 R1 的输出去微调小型模型，架构不同，但继承了推理风格；量化版是同一权重的低精度压缩，硬件要求低但回答质量会有折损。Ollama 的deepseek-r1:8b属于蒸馏版，真正写量化标签的版本通常要自己用 GGUF 转换工具处理。我建议普通知识库场景直接选 Ollama 的8b或14b，省事，坑少。

2.2 安装 Ollama 并拉取模型：最小可运行命令

Ollama 是当前本地部署 DeepSeek R1 最省事的运行时。Windows 和 macOS 直接装桌面版安装包，Linux 上常见做法是执行官方一键安装脚本，之后服务会自动注册成后台进程。装完先确认服务状态，终端里执行ollama serve会以前台方式启动，正常会看到监听地址127.0.0.1:11434的日志；如果服务已经在跑，这个命令会提示端口占用，那反而是好消息。

拉取和启动模型的命令如下：

# 拉取 8B 蒸馏版，模型文件会自动存到 OLLAMA_MODELS 目录 ollama pull deepseek-r1:8b # 启动交互式对话，本地没有时会先自动拉取 ollama run deepseek-r1:8b

第一次拉取会下载约 5GB 文件，取决于网速和磁盘。参数说明：8b是模型档位标签，想换 14B 就把命令里的8b改成14b；OLLAMA_MODELS环境变量可以改模型存储路径，建议设到大容量分区，避免默认盘被占满。启动后输入?可以看内置帮助，输入/bye退出。

如果你不想进交互界面，Ollama 自带 HTTP API，这也是后面 Dify 对接时真正会用到的方式。用一个简单的 curl 验证生成是否可用：

curl http://localhost:11434/api/generate -d '{ "model": "deepseek-r1:8b", "prompt": "用一句话说明什么是本地知识库", "stream": false }'

返回 JSON 里的response字段就是模型回答，total_duration可以看总耗时。注意stream: false表示等完整回答返回，方便快速判断模型有没有跑起来；Dify 实际调用会改成流式，让对话更跟手。

2.3 验证模型真的在工作：一次干净的手动调用

拉完模型后不要急着搭知识库，先用一组固定问题做冒烟测试。我会连续问三个不同类型的问题：事实型、逻辑型、开放型。对 DeepSeek R1 系列来说，回答里通常会出现一段reasoning_content，也就是模型先“思考”再给最终答案，这是 R1 家族的标志性行为，如果这个能看到，说明模型权重加载完整。

同时打开第二个终端窗口跑ollama ps，看模型是否真正常驻显存：

ollama ps

输出里NAME是模型名，SIZE是加载后的体积，PROCESSOR列会写100% GPU或GPU/CPU。这一步非常关键：如果你看到 CPU 占比很高、GPU 占比很低，后面推理一定慢，问题多半出在第 5 章要讲的num_gpu配置上。冒烟测试的另一层意义是先建立正确预期，8B 模型生成速度平时能到三五十 token 每秒，70B 在单卡上可能只有个位数 token 每秒，别拿不同档位互相比较。

2.4 临时对话界面：Open WebUI 或直接用 API

Ollama 的 CLI 够用但不适合给人点。常见做法是再起一个 Web 界面，最省事的是 Open WebUI，一条 docker 命令能带起来：

docker run -d --name open-webui \ --add-host=host.docker.internal:host-gateway \ -p 3000:8080 \ -v open-webui-data:/app/backend/data \ ghcr.io/open-webui/open-webui:main

镜像体积不小，磁盘紧张可以跳过，直接用第 2.2 节的 curl 验证就够。我现在一般先不装界面，直接进入知识库环节，因为后面 Dify 会统一接管对话入口。这里想说明的是：模型一旦能以 API 形式被 curl 调用，剩下所有工作都是在“召回文本”和“拼 Prompt”，DeepSeek R1 本身不再需要改动，这一步的长期收益是后面调试知识库时可以随时隔离模型问题。如果你需要局域网内其他设备访问，启动 Ollama 时把OLLAMA_HOST设为0.0.0.0:11434即可，但要注意这会带来无鉴权访问风险，个人用别长期开着。

3. 搭建本地知识库前先理解 RAG：让召回从玄学变可控

3.1 RAG 的完整链路：不是把 PDF 喂给模型

大模型不知道自己硬盘里那份 PDF 写了什么。要让 DeepSeek R1 基于本地材料回答，标准做法是 RAG（检索增强生成）。这条链路由五个环节组成：文档解析、文本切块、向量化、索引存储，最后是检索后的生成。很多人一上来就下载 Ollama 和模型，把 PDF 往 Dify 里一传，发现回答牛头不对马嘴，原因就是中间链路没有做可控的调校。

在整个链路里，召回环节决定了输出上限。模型只会看到你拼进 Prompt 的那几段文本，它不会自己翻文件。如果切块把表格拆散、把段落切在半句话上，或者嵌入模型把“报销流程”和“财务审批”算成不相似，那么后面模型生成得再流畅也是无米之炊。所以这一章我会用一套最小 Python 实现，把每个环节的参数空间讲清楚，避免知识库变成黑匣子。

3.2 文档解析与切块：PDF 转文本，再按 512/64 切块

文档解析是常被省略的一步。直接拿 PyPDF2 抽出来的文本，经常每行末尾带换行、表格字段乱序、代码块缩进丢失。我会先在本地把 PDF 转成 Markdown 再入库。工具链里 MinerU 是近期被验证过的方案，能让公式和表格保持结构；如果不想引入太重的东西，下面的 PyMuPDF 脚本能处理纯文本型 PDF：

import fitz # PyMuPDF def extract_pdf(path: str) -> str: doc = fitz.open(path) pages = [page.get_text("text") for page in doc] return "\n".join(pages) text = extract_pdf("manual.pdf") print(len(text), text[:200])

get_text("text")会把整页文字按阅读顺序取出，对多栏 PDF 的还原还不够好，但作为第一版够用。如果 PDF 是扫描图片，必须先用 OCR 组件抽文字，这一步不能省，否则后面向量化等于在给空白文档做索引。

拿到纯文本后就要切块。常用的最小参数是chunk_size=512字符、overlap=64字符，我习惯写一个简单的循环函数：

def chunk_text(text: str, chunk_size: int = 512, overlap: int = 64) -> list[str]: chunks = [] start = 0 while start < len(text): end = min(start + chunk_size, len(text)) chunks.append(text[start:end]) if end == len(text): break start = end - overlap return chunks chunks = chunk_text(text) print(len(chunks), [len(c) for c in chunks[:3]])

参数说明：chunk_size控制每块长度，512 字符大约能容纳一个完整小节；overlap让相邻块共享 64 字符，避免关键句子被拦腰切断后两边都不完整。中文场景建议按字符而不是 token 算，因为本地嵌入模型按字切更直观。实际工程里可以按 Markdown 标题先做结构切分，再把过长小节按上面参数二次切分。表头和数据行如果被切到不同块，检索时会漏掉上下文，所以我处理含表格的文档时会先把表格单独拆出，转成 Markdown 横向长句再入库。

3.3 向量化模型与索引存储：bge-m3 和 Chroma 的搭配

切好的块要转成向量。DeepSeek R1 本身不做嵌入，你必须单独准备一个 embedding 模型。选型上我推荐 bge-m3：中英文都支持、输出 1024 维向量，在本地部署大模型的知识库方案里出镜率最高。加载方式很多，最简单的是通过 sentence-transformers 读本地已下载的模型路径：

from sentence_transformers import SentenceTransformer model = SentenceTransformer("/models/bge-m3") # 替换为本地路径 vectors = model.encode(chunks, normalize_embeddings=True) print(vectors.shape) # (块数, 1024)

normalize_embeddings=True会把向量归一化，这样后续用余弦相似度时分数范围更稳定。编码完了需要落库，这里用 Chroma 的本地持久化模式：

import chromadb client = chromadb.PersistentClient(path="./kb_cache") collection = client.get_or_create_collection( name="local_kb", metadata={"hnsw:space": "cosine"}, ) collection.add( ids=[f"chunk-{i}" for i in range(len(chunks))], documents=chunks, embeddings=vectors.tolist(), ) print(collection.count())

参数说明：PersistentClient(path)表示数据写到磁盘目录，重启用不用重新导入；hnsw:space: cosine告诉 Chroma 用余弦距离建索引。如果你的文档量不大，这个方案足够；等到了几十万片段的规模，再考虑 Milvus 这类独立向量库。注意documents和embeddings必须同长度，缺一个都会在插入时报错。

3.4 检索与问答：把召回结果拼进 Prompt 交给 R1

向量库建好后，问答流程就剩两步：先按问题向量召回相关块，再把召回文本拼进 Prompt 调 Ollama。查询端的代码很直接：

query = "这个项目怎么配置环境变量？" q_vec = model.encode([query], normalize_embeddings=True)[0].tolist() results = collection.query( query_embeddings=[q_vec], n_results=5, ) context = "\n\n".join(results["documents"][0])

n_results=5是召回数量，这个值值得反复试。文档短就取 3，长文档取 5 到 8；取太少漏信息，取太多 Prompt 变长，推理会变慢，而且 R1 容易忽略夹在中间的低相关片段。接下来把 context 和问题拼成一个带约束的 Prompt：

prompt = f"""你是本地知识库助手。请只根据参考材料回答，不要编造。 如果材料不足以回答，就说“材料中没有相关说明”。 参考资料： {context} 问题：{query} 回答："""

然后把 Prompt 发给本地 Ollama：

import requests, json resp = requests.post( "http://localhost:11434/api/generate", json={ "model": "deepseek-r1:8b", "prompt": prompt, "stream": False, }, ) reply = json.loads(resp.text)["response"] print(reply)

这一步的意义是把知识库和大模型彻底解耦：先召回，再生成。这样排查问题时也很容易定位——如果返回的context里根本没有答案，问题出在解析或切块；如果context有答案但回答乱编，问题出在 Prompt 或模型档位太低。

4. 用 Dify 把 RAG 串成完整应用：Ollama 加 Dify 的本地知识库

4.1 Dify 安装与首次启动：docker compose 起服务

Python 脚本能做验证，但要给团队用，还是得有个界面。Dify 是目前把知识库、模型、应用编排串起来最常用的脚手架。它的部署方式和开源项目一致：先把官方仓库拉下来，进入 docker 目录，复制环境变量文件，然后启动。下面命令里的仓库地址需要替换成你拿到的官方地址：

git clone <Dify官方仓库地址> dify cd dify/docker cp .env.example .env docker compose up -d

docker compose up -d会在后台拉起 API、Worker、Web 前端，以及依赖的 PostgreSQL 和向量库。首次启动要拉一堆镜像，耗时和网络有关，不要一看到日志滚动就 Ctrl+C。启动完成后浏览器访问http://localhost，按页面提示设置管理员邮箱和密码；这一步不涉及模型，可以先建好账号。

4.2 接入 Ollama 模型：对话模型和嵌入模型各配一次

Dify 的模型供应商体系里，Ollama 作为供应商同时能提供 LLM 和 Embedding 两类模型，但不能只配一次。你需要分别在“对话模型”和“Embedding 模型”两类角色下各添加一个 Ollama 来源。右上角头像进入设置，找到模型供应商，选 Ollama，然后新增模型。

关键参数如下：API Base URL 在 Dify 跑在 Docker 容器内时不能填http://localhost:11434，那是容器的回环地址，会连到自己。Windows 和 macOS 的 Docker Desktop 一般写http://host.docker.internal:11434；Linux 下用http://172.17.0.1:11434，前提是把 Docker 的默认桥接网段保持原样。这个地址错了会表现为“添加成功但测试一直失败”，这是 Dify 本地部署教程里最常见的配置失误。

模型类型选LLM时，模型名填deepseek-r1:8b，上下文长度可以按模型能力填 8192 或更高；模型类型选Embedding时，模型名填bge-m3（需要先在 Ollama 里执行ollama pull bge-m3）。注意两类模型的模型名不能混，Dify 不会替你判断某个模型到底是对话模型还是嵌入模型，你选错角色它也会承认，但知识库向量化或对话生成时会报错。

4.3 创建知识库：分块参数、索引模式和召回范围设置

模型配好后进入“知识库”标签页新建知识库，上传第 2 章处理过的 Markdown，或直接传 PDF。Dify 自带文档解析和切块：分段模式一般选“通用”，最大分段长度按 token 计，我建议设 400 到 800，重叠设 50 到 100。这个范围比 Python 版的 512 字符略大，因为 Dify 内部按 token 切，中文一个 token 大约对应 0.6 到 1 个汉字，别被数字一致迷惑。

索引方式选“高质量”，这样 Dify 会真正调用 embedding 模型生成向量索引，而不是走内置的关键词倒排。创建完知识库，上传文档后状态会经历“解析中”“索引中”，直到显示可用。如果长时间停在“解析中”，优先去检查 Embedding 模型是否配好，以及 Ollama 是否还在跑，这比怀疑文档本身来得快。

召回设置在知识库详情或应用编排里都有：检索召回模式建议“向量检索”，文档少时足够；如果文档里有大量精确名词、编号，选“全文检索”或“混合检索”更好。Top K 设 3 到 5，Score 阈值设 0.3 到 0.5 之间。阈值设太高会把相关片段全部过滤，设太低则无关片段混进上下文，两个值都需要用真实问题去试。

4.4 编排应用：让 R1 只依据知识库内容回答

知识库建好后，进入“应用”新建聊天助手。第一步选模型，直接用刚配好的deepseek-r1:8b。第二步在编排页找到“上下文”组件，把它拖到提示词部分，并选择你刚建的知识库。第三步在系统提示词里写清楚约束：“仅根据上下文材料回答，上下文无关的信息一律回不知道”，这能明显减少编造。

完成这些后，页面右上角会有预览按钮，发一句你真实业务里会问的问题。注意看对话输入框下方是否出现了“召回片段来源”，如果来源为空，说明没有走到知识库检索，去检查上下文组件有没有接到对话模型上。DeepSeek R1 的思维链在这时候可能会把“思考”过程显示出来，Dify 里可以在模型参数区通过开关控制是否输出思考过程；内网演示时建议关掉，最终用户更关心答案，不想看一大段自我分析。

正式交付前，我建议把 Dify 的应用 API 打开。应用设置里会生成一个 API 密钥，这样外部系统可以把它当作一个 HTTP 接口来调用，知识库细节全部藏在 Dify 后面。这样做的好处是不用把 Ollama 的地址暴露给业务方，密钥在界面里可以随时重置，复盘时也能通过 Dify 的日志看每次请求命中了哪些知识库片段。日志入口在应用侧边的“日志”页，每条对话都带着检索到的上下文来源，这是后续调参的重要依据。

5. 避坑清单：本地部署 DeepSeek R1 和知识库的五个翻车点

本地部署这套东西，最贵的不是模型文件，而是排查问题的时间。下面五个翻车点来自我自己给团队做内网知识库时的真实血泪经验，每条按现象、原因、解决的顺序写。如果你照着第 2 到第 4 章跑完还是不对劲，先别急着换模型，按这个清单逐条对一遍，多半能找到根因。

5.1 拉模型一直“等待”，进度条纹丝不动

现象：ollama pull deepseek-r1:14b执行后长时间停在 Waiting 或 Received 0 B，网络带宽没跑满。原因：Ollama 拉模型默认做了分块校验，每块都要向仓库确认，如果网络不稳定或连接被限速，就会反复重试；另一个被忽略的原因是OLLAMA_MODELS所在分区空间不足，下载任务会一直等磁盘写入。解决：先确认磁盘容量df -h，如果满了，在启动服务前设环境变量OLLAMA_MODELS=/data/models并重启 Ollama，然后重新ollama pull。网络问题不要盲目等待，建议Ctrl+C中断再重试，Ollama 的下载任务支持断点续传，已下载的块不会白费。如果你在同一台机器上同时拉多个模型，把它们改成逐个拉取，并发下载会明显拖慢单个任务的进度。观察是否在下数据，最简单的办法是看模型目录体积有没有增长，比如du -sh $OLLAMA_MODELS每两分钟看一次，而不是只看屏幕上那个百分比。

5.2 显存明明够，推理却慢到以为死机

现象：运行 8B 模型时，显存占用不到一半，但生成速度只有每秒三四个 token，nvidia-smi 里 GPU 利用率也不高。原因：Ollama 默认按保守策略计算可用的 GPU 层数，当系统里其他程序占了一点显存，它就可能把部分层留在 CPU 上；CPU 推理单个 token 要几百毫秒到几秒，整体速度直接被拖垮。解决：在终端停下模型后设置环境变量OLLAMA_NUM_GPU=1，或者写一个 Modelfile 固化加载策略。这里把常见的 Modelfile 写法贴出来：

FROM deepseek-r1:8b PARAMETER num_gpu 999 PARAMETER num_ctx 4096

然后执行ollama create my-r1 -f Modelfile，之后ollama run my-r1。参数说明：num_gpu设成 999 表示有多少层就放多少层到 GPU，只要显存放得下；num_ctx同时影响显存和上下文长度，如果 8B 模型设 4096 后显存不够就降到 2048。注意这个参数必须在模型加载前决定，运行时修改只能通过环境变量重启服务。

5.3 知识库回答得像通灵，完全没引用材料

现象：问“项目启动命令是什么”，模型答出一段像模像样但文档里根本不存在的内容。原因：多半是召回环节没把正确段落捞上来，或捞上来的段落顺序颠倒；模型拿到含噪声的上下文后，倾向于把看起来顺的内容补全，这不是模型“坏”，是 Prompt 给了它发挥空间。解决：先在 Python 或 Dify 日志里打印实际召回的 documents，确认答案是否在里面。如果不在，把chunk_size从 800 降到 400，overlap从 50 提到 100，同时把 Score 阈值从 0.3 提到 0.5；如果在但回答不对，把 Prompt 的约束写成“只允许引用参考资料中的原句，参考资料没有的内容直接回答不知道”。还有一点经常踩：知识库索引用 bge-m3，后来为了测速度把 Embedding 模型换成别的，索引和查询的向量空间不一致，检索结果就完全失真。换嵌入模型一定要重建索引，不能只改配置。

5.4 Dify 里模型显示可用，测试却报 401/404

现象：在 Dify 模型供应商里添加 Ollama 后，点测试按钮立刻弹 401 或 404，日志里没有任何有效的模型响应。原因：最常见的是 API Base URL 写成了http://localhost:11434，但 Dify 的后端跑在容器里，这个 localhost 指向的是容器自己；另一个原因是模型名带了空格或写错版本，比如把deepseek-r1:8b写成deepseek-r1，Ollama 会把没有 tag 的请求解析成默认标签，如果没有默认标签就会 404。解决：把 URL 换成http://host.docker.internal:11434（Linux 是http://172.17.0.1:11434），用ollama list拿到准确模型名后回填。如果仍报 401，检查是否误开了 Ollama 的鉴权选项：本地 Ollama 默认没有鉴权，Dify 页面里的Enable Ollama Auth保持不勾即可。

5.5 同时跑多个模型，服务卡成死机

现象：知识库问答用着一个模型，后台又有人ollama run deepseek-r1:70b试机，几分钟后日常服务开始卡顿，甚至容器被 OOM kill。原因：Ollama 默认允许同时在显存里放多个模型，显存不够就把旧模型移到内存，然后重新加载，这个过程会产生严重的抖动。解决：设置OLLAMA_MAX_LOADED_MODELS=1强制只加载一个模型，并在不需要时执行ollama stop <model>释放显存。如果是通过 systemd 或 docker 运行的 Ollama，环境变量要写到对应的配置文件里，只在终端 export 只在当前终端有效。还要清理不再用的模型：ollama rm deepseek-r1:70b会删除模型文件，删除前先ollama list确认标签名，避免误删正在用的版本。Dify 侧的知识库向量索引也可能占几个 GB 磁盘，定期检查kb_cache目录体积，重建索引前先清掉旧 collection。

6. 把“能跑”调到“好用”：先调上下文，再调温度，最后做回归

当模型和知识库都跑通之后，收益最大的一件事是调整服务端参数。我给 DeepSeek R1 做本地部署时，第一优先是num_ctx。Ollama 默认上下文只有 2048 token，知识库召回 5 段文本加一段 Prompt 很容易超限，超出的内容会被截断，表现就是回答到一半断掉或漏信息。我习惯在 Modelfile 里显式写：

FROM deepseek-r1:8b PARAMETER num_ctx 8192 PARAMETER temperature 0.6

num_ctx不光影响生成长度，还直接决定显存占用；从 2048 提到 8192，显存消耗会增加不少，显存不足的机器不要硬提。temperature对 R1 这种已经内置思考链的模型尤其重要，知识库问答场景里 0.6 附近最稳，设太高会让它把思考过程写成小说，设太低又会让回答反复重复同一句。改了之后要重新ollama create一个新标签生效，直接ollama run改不了。

第二件值得做的是固定测试集。挑 10 到 15 个你在真实工作里会被问的问题，比如“报销上限是多少”“这个接口的鉴权方式是什么”，每次调完参数跑一遍，只记录“是否命中正确的知识库片段”和“回答是否依据片段”，不看文采。我的习惯是拿这个测试集同时打 Python 脚本和 Dify，两边结果不一致时优先怀疑 Dify 的重排或阈值配置。这样调参不是玄学，而是有反馈的回归。

第三个进阶动作是混合检索。单靠向量检索对精确编号不友好，Chroma 的collection.query只支持向量，我一般会额外用一个简单的关键词倒排扫描，把命中的文档 ID 加权合并后再排序。不用引用太重的东西，Python 里建一个collections.Counter统计词频就能在十秒内带来肉眼可见的改善。本地知识库和 DeepSeek R1 的价值就在这些细节里一点一点抠出来。

我自己踩过最深的坑是“模型换大了问题就自然解决”的错觉。知识库效果不好时，换 70B 只是让编造内容更流畅，真正决定成败的永远是文档解析和召回片段的质量。所以我现在的固定流程是：先跑通 8B，再上测试集，最后才去调模型和向量库参数。这篇方案讲到的做法，就是我自己每次重装环境时都会照着走一遍的路径，希望帮到你。

本文还有配套的精品资源，点击获取