企业官网建设流程全解析

简介：围绕DeepSeek本地化部署与基于RAG搭建本地知识库，一份PDF课件完整呈现了从模型选型、硬件配置到知识库落地实践的案例实操。内容按本地部署、领域专家、搭建知识库、更多场景四部分展开，梳理LM Studio、HuggingFace、魔搭社区等下载渠道，给出1.5B至671B不同参数模型的推荐配置与最低硬件要求，并对比微调与岗前培训两种领域化方法的适用性与成本差异。RAG部分重点拆解检索增强生成的低成本、自定义性强、门槛低、准确性高等优势，同时说明数据隔离、上下文限制等局限；随后演示创建知识库、导入语料、创建助手并关联知识库与大模型的完整流程，覆盖产品手册库、房抵贷知识库等实际场景，帮助读者快速建立本地问答能力。全包仅1个PDF文件，约4.91MB，适合希望让大模型掌握特定领域知识、搭建本地问答系统的开发者与爱好者。已有344人学习下载，可作为本地化部署与RAG落地的高密度参考手册。

1. DeepSeek本地化部署与RAG搭建：模型跑起来只是开始，知识库才是重点

DeepSeek本地化部署这两年热度一直很高，但大多数人卡住的点不是模型下不下来，而是模型跑起来之后答不了业务问题。这份PDF把两件事串在了一起：先用 LM Studio、Ollama、vLLM 把 DeepSeek-R1 跑起来，再通过 RAG 把产品手册、制度文档、案例报告变成外挂知识库，让模型“带资料上岗”。它解决的是企业内部数据不出本机、又要做智能问答的最常见诉求。适合想给团队做内部知识助手、又还没决定从哪起步的开发者和实施工程师；如果你手里有一堆 PDF 却不知道怎么让大模型读，这份材料能让你少走很多弯路。

2. 本地部署先选型：LM Studio、Ollama、vLLM 的边界与硬件账

2.1 三个推理框架的定位差异：从 GUI 到服务化

先说结论：LM Studio、Ollama、vLLM 不是同一层级的竞品，它们分别对应“验证模型、跑通流程、服务化上线”三个阶段，选错阶段用错工具才是最常见的翻车原因。

LM Studio 是图形界面工具，下载模型、加载模型、聊天都在窗口里点几下就能完成，还能直观看到 token 生成速度和显存占用，适合第一次接触本地模型的人。它的模型目录配置有点绕，下载的 GGUF 文件放错位置就加载不出来，这一点我们放到第 5 章细说。

Ollama 是命令行工具，一条命令拉模型、一条命令启动服务，而且默认提供 OpenAI 兼容接口。本地知识库项目里，Ollama + AnythingLLM 是最常见的组合，因为 AnythingLLM 只需要填一个 API 地址和一个模型名就能接上，几乎没有适配成本。

vLLM 是服务化推理框架，主打高吞吐和 PagedAttention，适合模型调通之后做成 API 服务给多个人并发调用。代价是配置参数更多，需要理解 KV cache、显存利用率和并发度之间的关系。个人的做法是：先 Ollama 跑通流程，确认知识库效果达标后，再决定要不要换 vLLM 承接高并发。

三种工具的侧重点整理成一张表，方便你对号入座：

2.2 模型参数怎么定：先算显存，再看内存和硬盘

PDF 里给了一张很务实的硬件配置表，把 1.5B 到 671B 各档模型的 CPU、内存、显存、硬盘要求列得很清楚。我复述几个关键档位：

这里的“推荐档”意思是能顺畅对话的配置，“最低档”只是能跑起来、不代表体验好。选型时先算显存再做其他判断：量化后的模型权重大约是参数量的 0.5～0.6 倍，例如 7B 模型用 Q4 量化后权重约 4～5GB，再加上上下文缓存（KV cache）和推理余量，8GB 显存能跑但偏紧，16GB 就比较从容。

内存也是常见的隐形瓶颈。模型加载进显存的同时，CPU 内存还需要承载系统、浏览器和 RAG 应用的向量库，32GB 内存对 8B 以上模型是舒适区，16GB 跑 7B 模型会出现整机卡顿。

另外注意，纯 CPU 部署不是不能跑，而是体验差异极大。1.5B 模型在纯 CPU 上能接受，7B 模型纯 CPU 回答一个问题可能要半分钟以上，只适合验证流程，不适合实际给业务用。如果只是测试 RAG 链路，可以先用 1.5B 跑通，再换大模型。

2.3 部署完成后别急着建知识库：先跑三个验证问题

模型下载完后，先用命令行确认服务正常。以 Ollama 为例，最常见的操作是：

# 拉取 DeepSeek-R1 的 7B 蒸馏版本，GGUF 分片会自动下载 ollama pull deepseek-r1:7b # 启动交互式对话，验证模型能正常回复 ollama run deepseek-r1:7b

pull子命令负责下载模型文件到本地模型目录，run会启动模型并进入对话界面。如果之前已经 pull 过，run直接复用本地文件，不会重复下载。这一步跑通后，再确认模型是否真的加载到了显卡：

# 查看模型进程、加载状态和 GPU 占用情况 ollama ps

输出里能看到模型名称、拥有的显存大小和处理器类型。如果你有独立显卡但显示 processor 是 CPU，说明驱动或 CUDA 环境没配好，需要先解决这个再往下走。这也是后面所有 RAG 实验的性能基础。

如果你打算走服务化路线，vLLM 的启动命令示例是：

# 启动一个本地 API 服务，监听 8000 端口 vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --served-model-name deepseek-r1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9

--served-model-name是给 API 调用方看的模型别名，--max-model-len控制上下文最大长度，直接决定 KV cache 占用，显存不够就把它调小到 4096；--gpu-memory-utilization表示允许 vLLM 使用 90% 显存，剩下 10% 留给其他进程和 RAG 应用的 embedding 计算。

模型能回复之后，用三个问题快速摸底：第一，问一道数学或逻辑题，确认推理能力正常；第二，问一个需要时效性信息的问题，看模型是否坦承不知道，而不是硬编；第三，问一段专业领域知识，观察它的答案风格。这三个问题分别对应模型能力、幻觉倾向和领域知识基础，都过关了再进入 RAG 环节。

3. 微调与 RAG 不是二选一：先分清“重塑大脑”和“带资料上岗”

3.1 微调：用专业数据重塑模型的能力边界

PDF 里用了一个很准的比喻：微调是“岗前培训”，RAG 是“带资料上岗”。微调的原理是在预训练模型基础上，用特定领域数据做再训练，让模型本身学会这个领域的知识表达。原文举的例子是给 AI 输入大量法律案例，经过训练后它能按法律语料的风格和逻辑解答问题。

微调的效果确实最彻底，但代价也是硬性的。需要准备规模大、质量高的领域数据集，需要至少 3 天以上的专业设备训练周期，还需要懂训练脚本、参数调优和过拟合判断的人。做完一次微调后，知识就固化在模型权重里，如果领域资料每个月都在变，你就得重新准备数据集、重新训练。

所以微调的真实适用场景是：知识相对稳定、回答风格需要严格统一、且你有持续训练和维护能力的团队。比如一个律所沉淀了十年的案例库，内容基本不再变化，微调后的模型可以作为固定能力长期复用。

3.2 RAG 拆开看是四步流水线：导入、分块、向量化、检索生成

RAG 的核心思路是把知识存放在模型外部，回答问题时先检索再生成。具体来说是一条四步流水线：先把文档语料导入知识库，把长文档切分成小块，对每一块做向量化存入向量数据库，用户提问时在向量库里检索最相关的若干块，把它们连同问题一起交给大模型生成答案。

这里最影响效果的是分块参数，也就是 chunk_size 和 chunk_overlap。我一般会用递归字符分割器，起始参数是这样设的：

from langchain_text_splitters import RecursiveCharacterTextSplitter text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, # 单块目标长度，中文按字符数计算 chunk_overlap=50, # 相邻块重叠长度，防止语义被切断 separators=["\n\n", "\n", "。", "，", " ", ""] # 切分优先级 ) chunks = text_splitter.split_text(long_doc) print(f"共切分 {len(chunks)} 块，每块约 {len(long_doc) // len(chunks)} 字")

chunk_size=500表示每块大约 500 字，这个大小对中文章节、制度条款、产品参数表都相对稳妥；块太大，检索命中后塞给大模型的上下文过宽，容易稀释关键信息；块太小，单块语义不完整，检索到的内容往往答不到点上。chunk_overlap=50让相邻块保留 50 字重叠，避免一句话被拦腰切断后两边都失去语境。separators定义了优先在段落、换行、句号处切分，尽量减少语义割裂。

分块完成后，每块文本会经过 embedding 模型转成向量。常见做法是本地用 nomic-embed-text 这类小模型，768 维向量，占用显存很小。向量化存储之后，查询阶段会把用户问题也转成向量，在库里做相似度检索，取 TopK 个块交给大模型。整个链路里，embedding 模型选型和分块参数是两条最值得反复调的东西。

3.3 用一张对比表对号入座：成本、更新、门槛与适用场景

从 PDF 的表格能看出，微调的优势在准确性和模型能力内化，劣势在更新速度和成本；RAG 的优势在成本低、更新快、可自定义和门槛低，劣势在系统复杂、上下文受限于检索窗口。所以绝大多数内部知识库场景，第一选择都应该是 RAG。

什么时候考虑微调？当你连续使用 RAG 一段时间后，发现检索质量已经调到很好了，但模型对特定术语的理解、回答风格仍然不满意，这时候才值得把精力投向微调。更进阶的做法是微调和 RAG 混合，用微调强化模型的表达风格，用 RAG 提供事实资料，但那是第二步的事，第一步先把手头的检索链路跑通。

4. AnythingLLM 搭建本地知识库：从语料到助手关联的完整操作

4.1 RAG 应用三选一：AnythingLLM、RAGFlow、QAnything

PDF 里列了三款本地 RAG 应用：AnythingLLM、RAGFlow、QAnything。三款都能实现“知识库 + 大模型”的组合问答，差异主要在文档解析能力和上手成本上。

AnythingLLM 是三者里对新手最友好的，安装后浏览器访问本地端口，通过图形界面完成知识库创建、文档导入、嵌入向量化和助手关联。文档解析能力够用，但遇到复杂版式会吃力。RAGFlow 的文档解析更强，支持表格、版式还原和深度文档理解，适合材料里图表多、排版复杂的场景。QAnything 是网易有道开源的项目，对学术论文和垂直领域文档有优化。如果你的语料主要是标准 PDF 和 Word，AnythingLLM 就够了；如果有一大批扫描件和复杂表格，优先考虑 RAGFlow。

4.2 关键配置：聊天模型和嵌入模型要分开设置

用 AnythingLLM 搭建时，最容易忽略的一点是：它需要配置两个模型，一个是聊天模型（Chat Model），负责最终生成答案；另一个是嵌入模型（Embedding Model），负责把语料文本转成向量。很多人只配了聊天模型就直接传文档，结果知识库一直无法向量化，或者建好了也检索不到内容。

在 AnythingLLM 的设置界面里，聊天模型提供商选择 Ollama，基础地址填http://localhost:11434，模型名填deepseek-r1:7b。嵌入模型提供商同样选择 Ollama，模型名填nomic-embed-text，向量维度 768。注意，嵌入模型需要额外下载一次，别把它当成聊天模型的附属品。

配置完成后，创建 Workspace（工作区），在文档上传区域把准备好的语料拖进去，点保存并嵌入。嵌入过程会在后台把每块文本向量化并写入本地向量库，文档越多耗时越长。这一步完成后，工作区左侧会显示文档列表和块数量，块数量为 0 说明嵌入失败，需要回头检查嵌入模型配置。

4.3 语料准备和助手创建：先把 PDF 批量转成干净文本

在动手搭建之前，我一般会先把语料归一化成 txt 或 Markdown。因为 PDF 直接导入不是不行，但 PDF 的文本抽取质量参差不齐，表格、页眉页脚、扫描件都会污染检索效果。直接用下面的脚本批量把 PDF 转成 txt：

# 把 PDF 语料批量转成 txt，供 AnythingLLM 导入 from pypdf import PdfReader from pathlib import Path src_dir = Path("./raw_pdf") # 原始 PDF 存放目录 out_dir = Path("./corpus_txt") # 输出 txt 目录 out_dir.mkdir(exist_ok=True) for pdf in src_dir.glob("*.pdf"): reader = PdfReader(str(pdf)) text = "\n".join(page.extract_text() for page in reader.pages) out_path = out_dir / f"{pdf.stem}.txt" out_path.write_text(text, encoding="utf-8") print(f"converted: {pdf.name} -> {len(text)} chars")

src_dir指向你放 PDF 的文件夹，out_dir会自动创建并存放同名 txt 文件。PdfReader逐页调用extract_text()抽取文本层，最后按页拼接。转换后在 AnythingLLM 的 Workspace 里直接导入这些 txt，检索稳定性和命中率会比直接导入 PDF 高不少，因为避开了 PDF 内嵌字体和页眉页脚的干扰。

导入语料后创建助手，工作流如下：新建助手，选择聊天模型为deepseek-r1:7b，在关联知识库的选项里选中刚才建好的 Workspace，再给助手写一段系统提示词。提示词直接影响回答质量，我惯用的模板是：

你是一名企业内部知识助手。 请只根据知识库中的资料回答问题，不要使用通用知识补充。 如果资料里没有相关内容，请直接回答“知识库中未找到相关资料”。 回答时优先引用原文关键信息。

这段提示词的作用是把模型的回答范围锁死在知识库内。“不要使用通用知识补充”是抑制幻觉最有效的一句话，我们见过太多知识库问答翻车案例，根源都是模型在资料不足时脑补答案，而提示词里根本没有约定“资料不足怎么办”这个分支。

4.4 同一套流程能复用到哪些场景

这套“本地 DeepSeek + 知识库”组合的场景弹性很大。产品手册库可以直接答复客户咨询，把退货周期、保修条款、售后政策整进知识库，客服问一句模型答一句；财务和人事可以把报销制度、考勤规则、假期规定做成员工自助问答；法务可以把合同模板和常用法律条文分门别类导入，审核时先让模型检索到关联条款再人工复核。核心逻辑都一样：语料换成什么领域的文档，模型就回答什么领域的问题，不需要重新训练，只换资料、调提示词。

5. 常见问题与避坑：部署到问答全过程踩过的五个坑

5.1 连接与加载阶段

坑一：AnythingLLM 一直提示连接失败，但 Ollama 明明在运行。

现象：Ollama 模型能正常对话，AnythingLLM 设置里填了localhost:11434仍然连不上。原因：Ollama 服务默认只监听本机回环地址，而 AnythingLLM 在部分系统上被当做独立进程访问时地址解析异常；另一个常见原因是 Ollama 服务没常驻，只在命令行对话时临时启动。解决：先执行ollama serve让服务常驻，再在 AnythingLLM 里把地址写成http://localhost:11434，不要漏掉http://前缀，确认端口没有被占用后再保存测试连接。

坑二：LM Studio 下拉模型一直卡在 loading。

现象：模型文件下载完成后点加载，进度条一直转，或者提示路径错误。原因：模型目录没有配置到下载文件的真实位置。LM Studio 默认模型目录在用户目录下，如果你手动把 GGUF 文件拷贝到了其他盘中，软件找不到文件自然加载失败。解决：在 LM Studio 设置里把模型目录改到实际的存放路径，并确保目录中只保留完整的 GGUF 文件，不要混入半截的多分片文件。如果是从魔搭社区下载的模型，注意文件名是否被二次修改过，LM Studio 会读 manifest 文件识别模型结构。

5.2 语料与检索阶段

坑三：扫描版 PDF 导入后检索命中率几乎为零。

现象：文档明明导入了，向量化也显示成功，但问什么都检索不到，模型回答里完全没有文档内容。原因：扫描版 PDF 本质是图片，没有文本层，extract_text()抽不出任何文字，向量库索引的是空白内容。我在第 4.3 节的脚本转换 PDF 时，如果输出 txt 文件接近 0 字符，基本可以断定是扫描件。解决：先用 OCR 工具（如 PaddleOCR 或 Tesseract）把图片转成文字，再清洗、再导入，不要试图让 RAG 应用替你完成 OCR。

坑四：产品手册里的价格表、参数表导入后问不出来。

现象：整份 PDF 都入库了，但问“某型号的单价是多少”，模型答非所问。原因：PDF 文本抽取时表格被拆成无规律的散行，分块后表格语义断裂，检索阶段根本匹配不上“型号 + 单价”这种关联查询。解决：把表格单独抽取出来，转成 Markdown 或 CSV 格式作为一个独立语料文件导入，甚至可以在单元格前后补上表头字段名。表格型语料和正文型语料分开管理，是我做过知识库项目里最值得坚持的做法。另外，图片型内容（产品图、截图）没法直接被向量检索，要么 OCR 出文字，要么把图片的描述写进文本再入库。

5.3 推理性能阶段

坑五：7B 模型在 8GB 显存上动不动就内存溢出。

现象：问几个简短问题正常，一上传长文档或者连续对话时间一长，Ollama 进程报显存不足退出。原因：上下文长度设置过大，KV cache 随着对话长度增长吃满显存。很多工具默认把 context window 开到 8k 甚至 16k，在 8GB 显存上这是跑不满的。解决：把上下文长度降到 4k 或 2k，对话一段时间就清理上下文。另一个容易被忽略的点是，AnythingLLM 的嵌入模型也会占一部分显存，检查ollama ps确认两个模型同时在显存里的占用总和，超过总显存就要给嵌入模型换更小的，或者强制它跑 CPU。

坑六：纯 CPU 推理慢到没法用。

现象：7B 模型回答一个普通问题要 40 秒以上，界面像卡死。原因：模型权重和推理计算全部在 CPU 上执行，没有 GPU 加速。PDF 里最低配置一栏允许纯 CPU，但那只代表能运行、不代表能用。解决：要么给机器加一块支持 CUDA 的显卡，要么先用 1.5B 模型把 RAG 流程整体打通，验证检索和回答质量后再投入算力升级。建议在首次部署时直接确认ollama ps输出里的 processor 列，如果是 CPU，趁早调整硬件或模型档位，别等项目做了一半才回头改。

6. 验证知识库效果的三个技巧：别让业务部门替你验收

知识库系统交付给业务方之前，我会强制自己做一轮“验收三问”测试。这三个问题专门用来拆穿那些看起来能用、实际上全在吃模型通用知识的系统。

第一组是边界测试问题，比如问“我们的退货周期是几天”。如果不挂知识库的模型对这个问题的回答是通用电商常识，挂上知识库后回答变成了你手册里独有的条款数字，说明检索链路真的在起作用。反过来，如果挂不挂知识库答案一样，那就要检查提示词是否限制了模型，或者知识库压根没被查出来。

第二组是引用追踪。AnythingLLM 在回答时会标注引用来源，把回答涉及的文档片段列出来。我会点开这些引用逐条核对，确认引用的确实是导入的资料原文，而不是模型自己生成的内容。这一步能筛掉大量“看起来合理但实际是幻觉”的回答，也能发现分块不当导致的引用错位问题。

第三组是对比测试，同一问题分别问不挂知识库的裸模型和挂了知识库的助手，然后对比两者的答案差异。PDF 里贴了一张对比图，公网 DeepSeek 的回答和本地 DeepSeek + 知识库的回答面对同一个问题时给出的是完全不同的答案维度，前者泛泛而谈，后者直接引用本地资料的具体条款。这种对比是最直观的效果验收方式。

我还会把测试问题整理成一张固定表格，每次更换语料或升级模型后逐条重跑：

从那以后，我每次换语料、换模型版本，都会先拿这张表从头到尾跑一遍，确认每一行回答都能在知识库里找到对应来源，再交付给业务方用。这个习惯替我省去了大量“事后救火”的时间，也让你搭建的知识库真正成为能问、能查、能追溯的干活工具。希望帮到你。

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