企业官网建设流程全解析

简介：本资源为DeepSeek本地化部署与RAG案例实操完整技术资料，面向希望将大模型落地到企业知识库场景的技术人员与AI应用开发者。内容系统讲解DeepSeek的本地部署路径，涵盖LM Studio、HuggingFace与魔搭社区等模型获取方式，并给出从1.5B到671B不同参数规模下的推荐与最低硬件配置，帮助读者根据设备条件选择合适方案。资料还对比微调与RAG两条让大模型成为领域专家的技术路线，从成本、准确性、更新速度、数据需求等维度分析各自优劣势。在实操部分，完整演示基于AnythingLLM、RAGFlow、QAnything等工具搭建本地知识库的流程，包括创建知识库、导入语料、关联大模型与助手等关键步骤，并结合房抵贷业务、产品手册问答等场景说明落地应用价值。资源为1个PDF文件，约4.91MB，页面以图文结合形式组织，目录结构清晰，便于按章节学习和快速查阅，适合初步接触DeepSeek本地部署及RAG应用的技术人员参考实践。已有345人学习下载。

1. 为什么把DeepSeek装进内网：本地化部署和RAG知识库的适用场景

很多人拿到《DeepSeek本地化部署和案例实操-基于RAG搭建本地知识库》这类资料时，第一反应是先找API key，第二反应才是为什么要本地部署。其实本地部署解决的是两件事：数据不出内网，以及知识库检索可控。当你把公司制度、技术文档、售后记录交给云端模型时，光数据合规这一关就能堵死大多数场景。RAG的作用则是给模型装一个外挂记忆，让它回答问题前先查本地向量库，而不是凭世界知识瞎编。适合这个方案的人，是手里有大量私有文档、需要离线问答、又不想把资料交给第三方接口的技术团队或个人开发者。下面这条链路，就是我反复跑过很多遍的落地路径。

2. 本地化部署DeepSeek：Ollama还是vLLM，选型与最小跑通命令

本地化部署这一步决定后面的RAG到底跑得稳不稳。很多人上来就问用哪个框架，实际上应该先问自己三个问题：显卡显存多少，并发请求多大，需不需要和外部客户端（比如Codex、企业微信）集成。这些问题想清楚，选型就是顺理成章的事。

2.1 先看显存和量化：7B/14B/32B/70B怎么选

DeepSeek的开源模型有好几个尺寸，但本地跑得动才是硬道理。显存不够，再大的模型也只是黑匣子。常见的做法是先用量化模型跑通，再根据效果决定要不要上更大的。以Q4_K_M量化位宽为例，14B模型大概需要9GB左右显存，32B需要20GB上下，70B至少要40GB，而且这只是模型权重，还要留出KV Cache和推理临时空间。如果你的显卡只有8GB，老老实实从7B开始；如果手头是24GB的4090或3090，14B是甜点，响应速度和回答质量相对均衡；超过32B，要么双卡，要么考虑vLLM做张量并行。这里有个血泪经验：不要在显存边缘试探，Ollama在显存不够时会用内存硬撑，速度会掉到不忍直视。选型号之前，先跑一次nvidia-smi看空闲显存。

量化位宽不用盲目追求低。Q8效果最好但显存翻倍，Q4_K_M是大部分人验证过的均衡点，Q2和Q3会出现明显的逻辑混乱，做知识库这种需要准确引用的场景基本没法用。如果你打算把DeepSeek接到企业微信这类需要长期驻留的场景，建议直接上14B以上的量化模型，7B在复杂制度问答里经常答非所问，用户的耐心可撑不过三次。

2.2 Ollama一步部署：拉取模型、起服务、改端口

Ollama是最适合起步的工具，安装完就自带OpenAI兼容的API，不需要额外写FastAPI包装。先拉模型：

# 拉取适合自己显卡的模型，deepseek-r1是社区常用的标签，数字代表参数量 ollama pull deepseek-r1:14b # 启动服务，默认端口11434，监听本机回环地址 ollama serve

服务起来后，另一个终端用curl验证：

curl http://localhost:11434/api/chat \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-r1:14b", "messages": [{"role": "user", "content": "用一句话介绍你自己"}], "stream": false }'

看到返回的choices里的content就说明部署通了。注意stream: false是为了让响应一次性返回，调试时省事；正式接入知识库时建议改成true，这样流式输出能给用户正在思考的反馈。ollama serve有几个环境变量值得提前设：OLLAMA_HOST=0.0.0.0，让局域网内其他机器也能访问；OLLAMA_CONTEXT_LENGTH=4096，控制上下文长度，默认是4096，但你想把多段检索结果喂给模型，建议提到8192，前提是显存够；OLLAMA_KEEP_ALIVE控制模型驻留内存的时间，默认5分钟，频繁调用不想每次重新加载，可以设成24h。这些参数都在Ollama的官方文档里写着，但很多人直到翻车才回去看。

Ollama的OpenAI兼容接口路径是/v1/chat/completions，这意味着LangChain、LlamaIndex甚至一些桌面客户端都能直接把base_url指到本机。我习惯在部署完以后第一时间用Python requests跑一次，确认CORS、超时设置都没问题，再往RAG工程里接。这一步别看简单，能帮你把部署问题和知识库代码问题隔离开，后续排错会省很多时间。

2.3 vLLM部署DeepSeek：吞吐优先的进阶路径

如果知识库要同时服务几十个人，或者要接企业微信、Codex这类外部客户端，Ollama的并发能力会吃紧。这时候常见做法是用vLLM，它的核心价值是连续批处理和PagedAttention，同样的显卡吞吐量能高出好几倍。部署命令如下：

# 建议用独立conda环境，避免系统Python冲突 conda create -n vllm python=3.11 -y conda activate vllm # 安装vllm，GPU版本会自动带上CUDA依赖 pip install vllm # 启动OpenAI兼容服务 python -m vllm.entrypoints.openai.api_server \ --model /data/models/deepseek-r1-14b \ --served-model-name deepseek-r1 \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9

注意--model参数指向你下载好的模型目录，而不是Ollama的懒加载方式。如果你只有量化后的GGUF文件，vLLM并不直接支持，常见做法是先用Ollama跑通，再把模型用官方脚本导成HF格式给vLLM，也就是社区常说的deepseek导出流程。--gpu-memory-utilization默认值是0.9，意思是预留10%显存给CUDA context和中间张量，如果还要在同一张卡上跑Embedding模型，这个值要降到0.5以下，否则两个任务抢显存会互相把对方挤爆。--max-model-len设8192基本够用，设太大不仅显存要求高，还会拉长首token延迟。启动完用curl调http://localhost:8000/v1/chat/completions验证。我的习惯是单机个人用Ollama，多人和服务化用vLLM，别一上来就上K8s，那属于给麻雀造航空母舰。

部署完成之后，社区里常提到的deepseek harness、codex接入这类工具，本质都是把模型API包装成更适合编程或其他专业的交互界面，它们和RAG不冲突，反而经常一起用。你完全可以先按本文把知识库跑通，再做这些界面层定制。选型对比可以用一张表记住：Ollama胜在零配置，vLLM胜在高并发，LM Studio更偏桌面演示，真正做产品级知识库服务，主流还是前两者。

3. RAG知识库的数据准备：从PDF/Word/Markdown到干净语料

RAG的瓶颈经常不在模型，而在脏数据。很多人把一堆PDF直接塞进向量库，检索出来的文本乱码、表格错位、段落断层，模型再聪明也只能答错。数据准备的核心就一句话：把文档变成结构清晰、可溯源、长度适中的文本片段。这一步通常占整个落地周期的一半时间。

3.1 文档解析：格式杂、扫描件、表格怎么处理

本地知识库最常见的输入是PDF和Word。PDF解析有很多坑：有些是文字版，有些是扫描件，还有双层PDF。文字版直接用pdfplumber提取，表格用extract_tables，扫描件就只能走OCR。下面是一个最小解析函数：

from pathlib import Path import pdfplumber def parse_pdf(path: str): text_parts = [] tables = [] with pdfplumber.open(path) as pdf: for page in pdf.pages: page_text = page.extract_text() or "" text_parts.append(page_text) # 表格单独提取，后面可以改写成Markdown形式保留结构 for tbl in page.extract_tables(): tables.append(tbl) return "\n".join(text_parts), tables

逻辑说明：pdfplumber的extract_text对文字版PDF表现很好，但遇到扫描页会返回None，所以需要加or ""占位。后续判断如果某页文本长度小于10，就视为图片页，丢给PaddleOCR或Tesseract识别。听上去简单，实际处理时扫描件识别错别字是必然的，并列出现多个版本文本时，我一般让OCR结果保持原样，不做过多的纠错，因为向量检索对个别错字不敏感，真正的坑是把表格识别成一堆无意义字符。

Word文档用python-docx提取段落和表格，Markdown直接读原文。这里有个常见误区：不要直接复制合并整个文本。先把文档标题、章节标题、页码都记录下来，后面做元数据要用。PPT和txt相对简单，按页和标题拆分即可。凡是提取失败的页面，宁可跳过也不要让它带着一堆换行符进向量库。

3.2 切分策略：固定窗口、递归切分与语义切分的取舍

切分是RAG里最容易被低估的环节。切得太碎，检索到的片段缺少上下文；切得太长，向量无法聚焦。常见做法是递归字符切分，让程序按标题、段落、句子这样的优先级逐步切开。用LangChain的RecursiveCharacterTextSplitter可以这样配：

from langchain_text_splitters import RecursiveCharacterTextSplitter splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=80, separators=["\n\n", "\n", "。", "！", "？", ".", "! ", "? ", "；", ";", "，", ","], keep_separator=True, ) chunks = splitter.split_text(text)

参数说明：chunk_size这里单位是字符，中文字符大约1.5到2个token，所以500字符对14B模型大概是800到1000个token，正好落在4K上下文允许范围内。chunk_overlap保留80字符的重叠，防止重要信息刚好卡在切分边界。separators列表是优先级，\n\n切不下去就按句子序号切，尽量不在一个完整句子的中间断掉。keep_separator=True可以让标题留在片段里，这样检索时能看到这段文字属于哪一节。

不要盲目迷信固定窗口切分。如果文档本身有清晰的Markdown标题，就按标题切，一个H2下所有内容作为一个chunk，这样语义最完整。如果文档是条文型制度，一个条款就是一个chunk。纯粹按固定窗口切的长篇合同，经常把同一个约定切开，导致答案只有前半句。语义切分（就是先embedding再检测话题突变）听起来很美好，实际线上不稳定，我一般把它当进阶方案，而不是默认。

3.3 元数据设计：来源、页码、标题是检索的暗号

元数据是RAG知识库最容易漏的一环。没有元数据，模型回答完你都不知道依据在哪，做知识库基本等于白做。每一条chunk至少要有source、page、title这三个字段，代码里用Document对象承载：

from langchain_core.documents import Document documents = [ Document( page_content=chunk, metadata={ "source": str(path), "page": page_num, "title": title_text, } ) for chunk in chunks ]

逻辑说明：page_content是真正发给向量模型编码的文本，metadata不参与向量编码，但会跟着检索结果一起返回。你可以在组装提示词时把source和page拼成“根据《考勤制度》第3页”这样的引用前缀，让回答可溯源。一个小技巧：如果同一个主题出现在多份文档里，metadata里再加一个doc_type字段，比如“制度/流程/FAQ”，检索时可以做过滤，避免跨类干扰。这些字段在设计阶段定好，后面比临时补救便宜得多。

4. 向量化与检索：Embedding选型、向量库对比、重排序

这一章解决的是“怎么从知识库里找出该给模型看的片段”。RAG的瓶颈往往在这里，而不是模型本身。向量化选错模型、向量库配错距离函数、检索后不重排，都会导致回答质量断崖式下跌。做好这三个环节，知识库才真正可用。

4.1 Embedding模型：bge-m3还是text2vec，中文场景的差异

既然要做本地化部署，Embedding也必须本地化，否则每次检索都要把文本发到公网，等于没本地部署。中文场景里BAAI/bge-m3是当前比较稳的选择，支持中英双语，输出1024维向量。text2vec体积更小，老机器友好，但语义匹配上限低一些。加载示例如下：

from sentence_transformers import SentenceTransformer embedder = SentenceTransformer("BAAI/bge-m3", device="cuda") vector = embedder.encode( "公司年假制度怎么规定的", normalize_embeddings=True, )

逻辑说明：normalize_embeddings=True会把向量归一化到单位长度，后续计算点积相似度就等于余弦相似度，这样设置阈值比较方便。bge系列有一个增加检索效果的写法：在query前面加“为这个句子生成表示以用于检索相关文章”这样的指令前缀，具体要看模型卡的说明，不能想当然。很多人翻车在这一点：query和文档都裸编码，导致召回率偏低。实际上文档和query的编码方式可以不一样，query加指令，文档不加，效果往往更好。

还要注意Embedding模型的显存占用不大，但也不能忽略。bge-m3跑在CPU上也能用，只是慢，建议和DeepSeek共用GPU时把gpu-memory-utilization调低，或者给Embedding单独分一个小显存队列。数据量大时，可以先批量算好向量，落盘后再启动服务，避免启动时一遍遍重复编码。

4.2 向量库选型：Chroma还是FAISS还是Milvus

轻量场景选Chroma，零配置，单机够用；FAISS是高性能库，适合对检索延迟有要求、愿意写代码控制细节的人；Milvus是服务化方案，适合数据量到百万级、需要多人协作和动态过滤的场景。本地知识库从0到1，我一般先用Chroma。以下用Chroma写入：

import chromadb from chromadb.utils.embedding_function import DefaultEmbeddingFunction client = chromadb.PersistentClient(path="./kb_store") collection = client.get_or_create_collection( name="company_docs", metadata={"hnsw:space": "cosine"} ) collection.add( ids=[str(i) for i in range(len(chunks))], documents=[doc.page_content for doc in documents], metadatas=[doc.metadata for doc in documents] )

逻辑说明：Chroma是一个持久化目录，下次启动直接读本地文件，不用重复写入。metadata={"hnsw:space": "cosine"}指定距离函数，注意默认是l2平方距离，中文知识库用cosine更符合语义相似度的直觉。Chroma默认的embedding_function是all-MiniLM，中文效果很差，这里只作占位，实际使用应该传入你自己加载的bge-m3。否则你会发现检索出来的结果和关键词毫无关系。

FAISS的优势是快，没有服务端概念，直接加载内存，适合把向量全部载入后暴力检索。Milvus适合多人多服务，但运维成本高，本地知识库阶段通常不需要。我的经验是：数据在十万条以下，Chroma足够；超过十万条，再评估FAISS或Milvus，不要一上来就上重武器。

4.3 混合检索与重排序：向量相似度加Rerank才不跑偏

纯向量检索在关键词精准匹配时容易漏。比如用户问“请假流程”，如果文档里写的是“事假申请”，embedding模型未必能把这两者对齐。常见做法是向量检索加BM25关键词检索做混合，再把两边结果合并，交给Rerank模型重新排序。Rerank实现示例：

from FlagEmbedding import FlagReranker reranker = FlagReranker("BAAI/bge-reranker-v2-m3", use_fp16=True) query = "请事假要提前几天" candidates = ["公司规定请事假需提前3个工作日", "年假申请流程如下"] pairs = [[query, doc] for doc in candidates] scores = reranker.compute_score(pairs, normalize=True) print(scores)

逻辑说明：Rerank的计算方式是拿query和每一条候选文本拼接后跑一个分类模型，输出相关性分数。它比向量检索更精准，因为能看到query和文档之间的细粒度交互。计算量不大，一般只对向量检索召回的top 20做重排，最后取top 5给大模型。加了Rerank以后，知识库回答的准确率会明显提升，这是投入产出比很高的一个环节。

在实际链路里，我习惯把向量检索和BM25各取20条，去重后统一交给Rerank重排。这个组合能同时处理语义模糊和关键词精确匹配两种场景。RAG瓶颈如果出现在这里，先别急着换大模型，调整混合检索和Rerank往往立竿见影。

5. 避坑指南：本地知识库常见的五个翻车点

这部分是我自己踩过的坑集合。每一条都按现象、原因、解决三步讲，你可以拿着日志和现象对照排查。

5.1 Embedding还在调公网API，数据裸奔

现象：DeepSeek已经本地部署，但知识库一跑起来就报警告，甚至超时。原因：代码或配置文件里仍然写的是OpenAI或者云端Embedding服务的API Key，本地文档内容全被送到公网去了。解决：全局搜索代码里的embedding接口地址，统一替换成本地bge-m3的sentence-transformers服务。检查方法是在Embedding调用处打日志，确认请求目标是localhost或内网IP。这一步没有商量余地，只要数据合规要求未满足，本地部署等于没做。

5.2 召回为空或答非所问，先查切分和召回而不是换模型

现象：用户问“年假几天”，模型回答“我不知道”。原因：相关段落没有被召回，常见原因是切分粒度太粗，或者chunk_size设置太大导致一条向量混合了多个主题。解决：写一个临时测试脚本，直接把query丢给retriever，打印返回的前3条chunk。如果返回的chunk确实不含年假内容，就调小chunk_size、增加chunk_overlap，或者改成按标题切分。我见过最多的情况是切分单位搞错，把500个token理解成500个字符，导致实际片段长得离谱。

5.3 模型引用了文档里不存在的内容

现象：回答看起来流畅，但引用页码和原文对不上。原因：提示词没有刚性约束模型只能基于检索结果回答。DeepSeek本身知识丰富，会把训练时的记忆混进答案，造成幻觉引用。解决：在提示词里明确写“如果检索内容不足以回答问题，请直接说不知道”，并且把检索片段用固定分隔符包起来，让模型清楚区分。还需要在提示词最后加上“请结合检索片段逐句回答，不要补充外部知识”。这一步是知识库能不能被信赖的底线。

5.4 上下文长度不够，检索结果被截断

现象：提示词里放了5条chunk后，接口直接报context length exceeded，或者回复被截断。原因：Ollama启动时的OLLAMA_CONTEXT_LENGTH没有调大，默认4K上下文容纳不了多段检索结果。解决：在启动Ollama前设置环境变量OLLAMA_CONTEXT_LENGTH=8192，同时检查chunk_size总量。如果显存有限，就把检索返回条数从5降到3，并缩小chunk_size。也可以按token重新估算一下：3条chunk加问题加提示词，控制在3500 token以内最稳。

5.5 并发一高就OOM或者响应慢

现象：团队里几个人同时用知识库，服务直接卡死，甚至显存溢出。原因：Ollama默认并发能力有限，且模型如果频繁换入换出会反复加载。解决：单机个人用就调大KEEP_ALIVE；多人并发就换vLLM，并把gpu-memory-utilization降到0.8以下，给并发请求留缓冲。数据量大时还建议在vLLM前面加一层简单的请求队列，避免所有请求同时打进来。这个坑通常在测试阶段不会出现，上线后突然暴露，所以最好提前做压力测试。

6. 案例实操：从部署到验收的完整链路与进阶方向

最后一章不重复前面的搭建步骤，重点讲怎么把链路串起来，以及如何用测试集验收，而不是靠感觉说效果不错。

6.1 最小串联：把检索结果交给DeepSeek

用LangChain做最小串联，核心是把向量检索结果放进提示词。示例代码：

from langchain_huggingface import HuggingFaceEmbeddings from langchain_chroma import Chroma from langchain_core.prompts import ChatPromptTemplate from langchain_ollama import ChatOllama embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-m3") vectorstore = Chroma(persist_directory="./kb_store", embedding_function=embeddings) retriever = vectorstore.as_retriever(search_kwargs={"k": 5}) llm = ChatOllama( model="deepseek-r1:14b", base_url="http://localhost:11434", temperature=0.1, ) prompt = ChatPromptTemplate.from_template( "你是知识库助手。只有检索到相关内容才能回答，否则说不知道。\n\n" "检索内容：{context}\n问题：{question}\n回答：" )

逻辑说明：temperature要调低，知识库问答追求稳定和忠实，0.1是合理的起始值。k=5表示召回5条chunk，如果上下文窗口有限，可以减少到3。实际运行时需要用RunnablePassthrough来组织流程，把question同时传给retriever和prompt，这里为了可读性做了简化。

6.2 用测试集验收而不是靠感觉

给自己准备20到30个真实问答对，每个问题标注期望命中的文档来源文件名。然后用retriever查询，检查前5条里有没有期望来源。脚本循环跑完，计算命中率。如果命中率低于80%，优先调切分和重排序，不要动模型。我最初做RAG就输在自认为效果不错，后来才发现抽查和全量测试差得远。这个测试集习惯帮我避掉了大部分返工，希望也能帮到你。

6.3 进阶：向量RAG遇到关联关系时，考虑KG知识库

当文档中的实体关系密集，比如“部门—人员—审批流”，向量检索回答不了“谁审批三天以上的事假”这种多跳问题。这时候可以从RAG知识库走向KG知识库，先抽取实体和关系，把三元组存进图数据库，再把路径查询结果拼进提示词。RAG知识库和结构知识库的区别就在这里：一个适合文本段落问答，一个适合结构逻辑查询。等文本问答稳定后，再决定要不要投入图谱建设。

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