企业官网建设流程全解析

简介：这份PDF资料面向希望搭建个人AI知识库的AI技术爱好者与有一定计算机操作基础的用户，围绕满血版DeepSeek R1展开，兼顾官方API与本地部署两条路线。内容先对比本地部署与官方API的优劣，指出多数人更适合API方案，算力充足或数据涉密者可选本地部署；随后讲解通过Cherry Studio配置R1模型API的完整流程，涵盖注册、获取密钥、配置对话与嵌入模型、创建知识库及文件向量化，并给出Ollama本地运行模型、接入Cherry Studio作为UI界面的操作要点，还涉及提问技巧与复杂PDF解析的配合工具建议。资源包为1个PDF文件，大小约6.48MB，结构紧凑便于通读。目前已有399人学习，适合想借助AI知识库提升工作效率、辅助决策并学习正确与AI交互的读者参考。

1. 从一份 PDF 标题说起：5 分钟用 DeepSeek + R1 搭个人知识库到底靠不靠谱

看到「DeepSeek本地部署-教你5分钟用DeepSeek+R1+搭建个人知识库.pdf」这个标题，我第一反应是：又一份把三件事揉在一起的教程。DeepSeek 是模型，R1 是推理增强版本，个人知识库是应用形态，本地部署是交付方式。四样东西叠在一起，5 分钟能不能跑通，取决于你把哪一步算作「跑通」。如果只是让 Ollama 拉下一个模型、在终端里问一句「你好」，那 5 分钟绰绰有余；如果要让模型读你自己的 PDF、Markdown、会议纪要，还能带出处回答，那 5 分钟只够把环境装完，剩下的是检索链路和提示词工程。

这篇不吹 5 分钟，也不劝你放弃。我按一线落地的顺序，把 DeepSeek 本地部署、Ollama 拉模型、R1 推理模型选型、个人知识库的检索层怎么搭、参数怎么调、坑在哪，一层层拆开。适合两类人：一类是手里有几十到几百份私有文档、不想上传到公有云、想在自己电脑或一台小主机上跑问答的工程师；另一类是已经用过在线 DeepSeek，想搞清楚本地版和在线版差在哪、值不值得迁移的人。读完你应该能判断：你的硬件能不能扛、该选哪个尺寸的模型、知识库的检索层用什么方案、以及最容易翻车的三个环节在哪。

2. 先把选型定下来：Ollama、DeepSeek 与 R1 各自扮演什么角色

2.1 为什么本地部署优先选 Ollama 而不是自己编译推理框架

本地跑大模型，常见做法有三条路：直接用 llama.cpp 编译、用 vLLM 起服务、用 Ollama 做封装。llama.cpp 最轻但参数要自己调，vLLM 吞吐高但吃显存、对个人电脑不友好，Ollama 把模型下载、量化格式、推理参数、API 服务都包好了，一条ollama run就能对话，还自带 OpenAI 兼容接口，后面接知识库检索层最省事。

对个人知识库这个场景，吞吐不是第一诉求，稳定和可维护才是。你一天可能就问几十次，Ollama 的常驻模型加载策略足够。它的模型库直接支持 DeepSeek 系列，拉取命令简单，国内网络环境下也能通过配置镜像源加速。这就是我一般会推荐 Ollama 作为本地部署底座的原因：不是它最快，而是它把「能跑起来」这件事的变量压到最少。

需要说清楚的是，Ollama 只是运行时，它不负责知识库。知识库的检索、切分、向量化、拼 prompt，是另一层的事。很多人把这两件事混为一谈，以为装了 Ollama 就有知识库了，这是第一个认知坑。

2.2 DeepSeek 与 R1 的关系：别把推理模型当通用对话模型用

DeepSeek 是一个模型家族，R1 是其中偏推理的版本。R1 的特点是会在回答前生成一段思维链，适合数学、逻辑、多步推理类问题。但用在个人知识库问答上，R1 不一定是最优解：它的思维链会拉长响应时间，对「从文档里找一段话并总结」这种任务，普通对话模型更快也更省资源。

我的选型习惯是：知识库问答主模型用 DeepSeek 的通用对话版本，遇到需要跨文档推理、对比、计算的查询，再切到 R1。Ollama 支持同时拉多个模型，用不同的 model name 调用即可。下面这张表是我在不同硬件上实际跑过的组合，供你对照：

提示：显存不够时 Ollama 会自动把部分层放到内存，速度会掉一个量级。别只看「能不能加载」，要看「每秒出几个字」。

2.3 个人知识库的最小可行架构

把链路拆开，一个能用的本地知识库只有四段：文档摄入、切分与向量化、检索、拼 prompt 交给模型。Ollama 负责最后一段，前三段要你自己搭。常见做法是用 Python 写一个脚本，把 PDF、Markdown、TXT 读进来，按固定长度切块，用 embedding 模型转成向量存到本地向量库，查询时先检索 top-k 块，再拼进 prompt。

这套架构不依赖任何云服务，全部本地跑。代价是你要自己处理 PDF 解析的脏数据、切分边界、检索召回率。下面几章就按这个顺序落地。

3. 动手：用 Ollama 把 DeepSeek 拉起来并跑通第一条命令

3.1 安装 Ollama 与配置国内镜像源

Ollama 的安装包在官网直接下载对应系统版本即可。国内网络环境下，模型拉取慢是高频问题，解决办法是配置镜像源。Ollama 支持通过环境变量指定模型仓库地址，Linux 和 macOS 下在 shell 配置里加一行，Windows 下在系统环境变量里加。

# Linux / macOS：写入 shell 配置，重启终端生效 export OLLAMA_HOST=127.0.0.1:11434 export OLLAMA_MODELS=/data/ollama/models # 如果使用镜像加速，设置模型拉取源（按你实际可用的镜像地址填） export OLLAMA_REGISTRY=https://your-mirror.example.com

OLLAMA_HOST决定 API 监听地址，默认 11434，本地知识库脚本要连这个端口。OLLAMA_MODELS决定模型文件存放路径，默认在用户目录下，模型动辄几个 GB，建议改到大盘。镜像源这一项不是所有版本都支持同名变量，如果你的版本不认，就改用代理式镜像或手动导入离线包，别硬套。

安装完成后验证：

ollama --version ollama list

ollama list为空是正常的，说明还没拉模型。如果这条命令报连接错误，说明服务没起来，Linux 下用systemctl status ollama看，macOS 下看菜单栏图标。

3.2 拉取 DeepSeek 模型并区分对话版与 R1

拉模型就一条命令，关键是选对 tag。Ollama 的模型名格式是模型名:参数尺寸，比如deepseek-r1:7b。尺寸越大越吃资源，先从 7B 起步验证链路，跑通再换大。

# 拉取 DeepSeek 对话模型（按你实际可用的 tag 调整） ollama pull deepseek-r1:7b # 拉取完成后查看本地模型列表 ollama list # 直接对话测试 ollama run deepseek-r1:7b "用一句话解释什么是向量检索"

ollama pull会显示下载进度，卡住不动多半是网络问题，换镜像源或改用离线包导入。ollama run进入交互模式，输入/bye退出。第一次加载模型会慢，之后常驻内存就快了。

注意：R1 系列默认会输出思维链，终端里会看到大段推理过程。如果你只想看最终答案，可以在 prompt 里要求「只输出结论」，或在 API 调用时限制输出格式。

3.3 用 API 方式调用，为知识库脚本做准备

知识库脚本不会用交互模式，而是走 HTTP API。Ollama 提供 OpenAI 兼容接口，用 requests 或 openai SDK 都能调。

import requests # Ollama 默认 API 地址，与 OLLAMA_HOST 一致 url = "http://127.0.0.1:11434/api/chat" payload = { "model": "deepseek-r1:7b", "messages": [ {"role": "system", "content": "你是一个严谨的知识库助手，只根据给定资料回答。"}, {"role": "user", "content": "什么是向量检索？"} ], "stream": False, # 关闭流式，方便脚本处理 "options": { "temperature": 0.2, # 知识库问答调低，减少发挥 "num_ctx": 4096 # 上下文窗口，按显存调整 } } resp = requests.post(url, json=payload, timeout=120) print(resp.json()["message"]["content"])

temperature是知识库场景最关键的参数，默认 0.8 会让模型自由发挥，问答场景建议 0.1～0.3。num_ctx决定模型能看多长的上下文，调大更吃显存，4096 是 7B 模型的稳妥值。stream关掉是为了脚本里一次性拿到完整结果，做流式输出时再打开。

这段跑通，说明模型层就绪，接下来才是知识库真正的活。

4. 知识库的检索层：文档切分、向量化与召回怎么做才不翻车

4.1 文档摄入与切分：PDF 解析是第一个脏活

个人知识库的文档来源通常是 PDF、Markdown、Word、TXT。PDF 最麻烦，扫描版要 OCR，文字版也可能有分栏、页眉页脚、表格错位。常见做法是用pymupdf或pdfplumber抽文本，抽完做一轮清洗：去页眉页脚、合并断行、去掉连续空行。

切分策略直接决定召回质量。按固定字符数切最简单，但会把一句话拦腰截断。我一般用「按段落切 + 超长段落再按句号切」的组合，块大小控制在 300～500 字，块之间留 50 字重叠，避免边界信息丢失。

import fitz # pymupdf import re def extract_pdf(path): doc = fitz.open(path) text = [] for page in doc: t = page.get_text() # 去掉页码行和多余空行 t = re.sub(r"\n\s*\d+\s*\n", "\n", t) t = re.sub(r"\n{3,}", "\n\n", t) text.append(t) return "\n".join(text) def split_chunks(text, size=400, overlap=50): paras = [p.strip() for p in text.split("\n\n") if p.strip()] chunks, buf = [], "" for p in paras: if len(buf) + len(p) <= size: buf += p + "\n" else: if buf: chunks.append(buf.strip()) # 保留重叠，缓解边界丢信息 buf = buf[-overlap:] + p + "\n" if buf else p + "\n" if buf: chunks.append(buf.strip()) return chunks

size和overlap是最需要按语料调的两个参数。技术文档句子长，size 可以到 500；会议纪要短句多，300 就够。overlap 太小边界问题明显，太大则检索结果重复。切完块建议人工抽看 10 条，确认没有把标题和正文切散。

4.2 向量化与本地向量库选型

切好的块要转成向量才能检索。embedding 模型同样可以本地跑，Ollama 支持 embedding 类模型，也可以用 sentence-transformers。向量库选型上，个人知识库规模通常在几千到几万块，不需要上重型数据库。常见做法是用chromadb或faiss，前者自带持久化和元数据，后者更轻但要多写几行。

import chromadb import requests client = chromadb.PersistentClient(path="./kb_db") col = client.get_or_create_collection("my_docs") def embed(text): # 调用本地 embedding 服务，按你实际部署的模型名调整 r = requests.post("http://127.0.0.1:11434/api/embeddings", json={"model": "nomic-embed-text", "prompt": text}) return r.json()["embedding"] chunks = split_chunks(extract_pdf("manual.pdf")) for i, c in enumerate(chunks): col.add(ids=[f"chunk-{i}"], documents=[c], embeddings=[embed(c)])

PersistentClient的 path 是本地目录，重启不丢数据。ids必须唯一，用文件名加序号最稳。embedding 模型和对话模型是两回事，别用对话模型去算向量，效果差且慢。

提示：向量维度和模型绑定，换 embedding 模型必须重建整个库，否则检索结果会乱。这是最容易被忽略的后悔药问题。

4.3 检索与拼 prompt：top-k 和重排怎么设

查询时先把问题向量化，在库里找最相似的 k 个块，拼进 prompt 让模型基于这些块回答。k 太小召回不足，k 太大噪声多还吃上下文。我一般先取 5，再看效果调到 3 或 8。

def ask(question, k=5): qv = embed(question) res = col.query(query_embeddings=[qv], n_results=k) context = "\n---\n".join(res["documents"][0]) prompt = f"""仅根据以下资料回答问题，资料中没有的信息不要编造。 资料： {context} 问题：{question} """ r = requests.post("http://127.0.0.1:11434/api/chat", json={ "model": "deepseek-r1:7b", "messages": [{"role": "user", "content": prompt}], "stream": False, "options": {"temperature": 0.2, "num_ctx": 4096} }, timeout=180) return r.json()["message"]["content"]

prompt 里那句「资料中没有的信息不要编造」是抑制幻觉的关键，但模型不一定完全遵守，所以检索质量才是根本。如果回答经常答非所问，先查检索结果对不对，再怪模型。有条件的话加一层重排模型，对 top-k 结果重新打分，召回准确率能明显提升。

5. 避坑与排查：本地知识库最容易翻车的五个地方

5.1 模型加载成功但回答极慢

现象：ollama run能出字，但每秒只有一两个 token，知识库问答等半分钟。原因：显存不足，Ollama 把部分层卸载到内存甚至 CPU，推理速度断崖式下降。解决：换更小尺寸或更高量化的模型，比如从 14B 降到 7B，或把 Q4 换成 Q4_K_M 以下；同时用ollama ps看模型实际占用，确认是否全部在显存。

5.2 检索结果和问题完全不相关

现象：问「报销流程」，召回的是「考勤制度」。原因：切分把语义单元切碎，或 embedding 模型不适合中文。解决：先人工看召回块内容，确认切分是否合理；中文场景换用对中文更友好的 embedding 模型；把块大小调大，让每块包含完整语义。

5.3 PDF 抽出来全是乱码或空白

现象：extract_pdf返回空字符串或一堆符号。原因：扫描版 PDF 没有文字层，或字体编码异常。解决：扫描版必须走 OCR，常见做法是先用pymupdf渲染成图片再送 OCR 引擎；字体异常的 PDF 换pdfplumber试，两个库的解析逻辑不同，经常一个不行另一个行。

5.4 模型无视资料自己编答案

现象：资料里没有的内容，模型也能说得头头是道。原因：temperature 太高，或 prompt 没有约束，或检索没召回到相关内容。解决：temperature 降到 0.1～0.2，prompt 明确要求「仅根据资料回答」，并在检索为空时直接返回「未找到相关资料」而不是硬答。

5.5 换 embedding 模型后检索全乱

现象：换了 embedding 模型，检索结果毫无相关性。原因：向量库里的旧向量和新查询向量不在同一空间，维度也可能不同。解决：换 embedding 模型必须清库重建，把PersistentClient的目录删掉重新摄入。这个坑没有捷径，只能重建。

6. 进阶：把知识库问答质量再抬一档的两个具体技巧

第一个技巧是查询改写。用户问「这个项目的验收标准是啥」，直接拿这句话去检索，可能因为口语化而召回不准。做法是先让模型把问题改写成几个检索友好的关键词组合，再分别检索、合并结果。这一步用同一个小模型就能做，成本低但召回提升明显。

def rewrite_query(question): r = requests.post("http://127.0.0.1:11434/api/chat", json={ "model": "deepseek-r1:7b", "messages": [{"role": "user", "content": f"把下面的问题改写成3个适合检索的关键词短语，每行一个，不要解释：\n{question}"}], "stream": False, "options": {"temperature": 0.3} }, timeout=60) return [l.strip() for l in r.json()["message"]["content"].split("\n") if l.strip()]

拿到多个查询后分别检索，把结果按块 id 去重再拼 prompt。注意改写本身也可能跑偏，所以原始问题也要保留一路检索，三路合并比单路稳。

第二个技巧是给每个块带上来源元数据，回答时要求模型标注出处。做法是在col.add时把文件名、页码写进metadatas，检索后把来源拼进 context，prompt 里要求「回答末尾列出引用的资料名」。这样你验证答案时有据可查，也能快速定位是哪份文档质量差拖累了整体效果。

这几个技巧不用全上，按你实际翻车的地方挑。我自己的习惯是先把分块和 temperature 调稳，再考虑查询改写，最后才上重排。顺序反了容易在噪声里调参，越调越乱。本地知识库这件事，模型只是其中一环，检索链路的质量往往比换更大的模型更管用。希望帮到你。

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