企业官网建设流程全解析

在本地跑大模型的场景，这几年真的从“极客玩具”变成了“生产力工具”。我最早接触 DeepSeek 是在 2023 年底，当时只是图新鲜，在命令行里聊几句。后来因为工作里要频繁查资料、整理文档，发现很多时间都浪费在“找文件、翻记录、重新理解上下文”上，于是干脆做了一个尝试：把 DeepSeek 接入我自己的知识库，做成一个本地部署的 AI 助手。整个过程走下来，踩了不少坑，也总结出了一套相对稳定的实践方法。

这篇博文就围绕这个项目来写，讲讲我是怎么从零开始搭建的，包括本地模型选型、知识库构建、向量检索（RAG）的完整落地，以及最后如何把 DeepSeek 和我的文档体系打通。无论你是技术探索者、经常和文档打交道的知识工作者，还是对数据隐私比较敏感的用户，这套方案都能给你一个直接可参考的路径。我尽量把步骤拆细，把原理讲清楚，每个环节也会附上我在实际使用中的偏好和取舍。

1. 一次真实的“文档焦虑”引发的项目

1.1 起因：明明存了，却“找不到、用不上”

事情得从我手头的一个技术团队说起。团队里维护着大量的产品文档、项目复盘、接口说明、客户反馈，甚至还有几十个版本的培训材料。这些东西散落在各种网盘、Wiki、聊天记录里。真到用的时候，最痛苦的不是“没有资料”，而是“资料太多，不知道去哪找，找到了又不知道哪份是有效的”。

举个例子，有一次我在梳理某个历史项目的技术选型，印象里团队在半年前讨论过一个很类似的方案，但具体结论、最终的取舍原因，我完全记不清了。翻聊天记录翻了两个小时，最后还是从同事的只言片语里拼凑出来的。这种体验太糟糕了。

所以我当时的想法很简单：能不能有一个助手，我直接问它“咱们之前讨论数据库分库方案时，最后为什么没选中间件，而是用业务拆分”，它能基于团队自己的文档，给我一个有依据的答案？

1.2 为什么选择本地部署，而不是直接用云端 API

一开始我也考虑过直接调用 DeepSeek 的云端 API。说实话，注册即用、按量付费、模型能力还强，确实省事。但我最终选择本地部署，原因有三个。

第一是隐私，团队内部文档里有大量客户数据和未公开的业务规划，走云端 API 意味着这些内容会离开本地环境，这在合规上是有风险的。第二是成本，团队里好几个同学都在高频使用 AI 辅助，按 token 计费的方式按年算下来并不便宜，而本地部署只要硬件够，边际成本几乎为零。第三是定制化和稳定性，云端服务有版本更新、限流、故障的可能，本地部署则完全可控，还可以随时针对特定文档场景做调优。

说实话，如果你是一个人用、资料不敏感，直接用云端 API 也没问题。但如果是团队场景、内容敏感、高频使用，本地部署是更稳妥的路线。

1.3 整体方案：DeepSeek + 本地推理 + 向量知识库

我的目标不是做一个“聊天机器人”，而是做一个“能回答私域知识问题的助手”。它的核心逻辑可以概括成三步：先把你所有的文档灌进一个“知识仓库”，当你提问时，系统先从仓库里找到和问题最相关的若干片段，再把这些片段连同问题一起交给大模型，让模型基于这些片段生成答案。这个流程在行业里叫 RAG（Retrieval-Augmented Generation，检索增强生成），也是整个项目的灵魂。

具体到技术选型，我用的是这样的组合：

• 模型推理框架：Ollama，用来加载和运行 DeepSeek 系列模型。
• 基础模型：DeepSeek-R1 系列蒸馏版 / DeepSeek-V3（视硬件情况选择，后面会细说）。
• 知识库索引：用 Python 脚本扫描本地 Markdown、TXT、PDF、Word 文档，进行清洗、分块。
• 向量化与检索：先通过嵌入模型把文本块转成向量，再用向量数据库做相似度检索。
• 编排框架：LangChain 负责把“检索 + 提示词 + 模型生成”串成完整链路。

简单画一下流程就是：文档 → 清洗切分 → 向量化 → 存入向量库 → 用户提问 → 向量检索 → 拼接上下文 → 送进大模型 → 输出答案。后续我会一步步拆开讲。

2. 环境准备：硬件、模型与工具有哪些讲究

2.1 硬件到底要什么配置

很多朋友一听到“本地部署大模型”，第一反应是“是不是要好几张显卡”。其实真不一定。DeepSeek 官方有多个尺寸的模型，不同版本对硬件的要求差异很大。

我自己在项目初期先用的是 CPU 推理，跑的是 7B 参数的量化版模型，16GB 内存的 MacBook Pro 就能带起来。虽然生成速度不算快，但作为验证用途已经足够。后来正式给团队用，我上了两台 GPU 工作站，跑 14B 和 32B 的版本，体验才算是真正流畅。

如果你的预算和硬件有限，我把经验整理成一个参考表：

还有一个容易被忽略的点：内存带宽和磁盘 IO 也很重要。加载大模型动辄几个 GB 甚至十几个 GB，如果硬盘是机械盘，加载时间会非常感人。强烈建议把模型放在 SSD 上，同时预留足够的 RAM 做缓存。

2.2 模型选型：DeepSeek 家族怎么挑

DeepSeek 系列有几个版本，我身边不少朋友刚开始容易懵。我按用途帮你梳理一下。

如果你追求通用问答、文本总结、信息抽取，选 DeepSeek-V3 系列。它是标准的对话/生成模型，回答自然，指令跟随能力强。如果是做复杂推理、逻辑题、代码分析这类任务，DeepSeek-R1 系列会更强。R1 有一个特点，它在回答时会先思考和推理，这也意味着它的输出会更长，延迟稍高。

另外，R1 系列还提供了蒸馏版本，尺寸比较小，更适合本地部署。我自己实际体验下来，R1-Distill-Qwen-7B 在中文问答上表现不错，14B 版本会更稳定，适合对答案质量有要求的场景。

还有一点得提醒你，模型不是越大越好。大模型对显存的需求是几何级增长的，而且生成速度会变慢。如果团队只是做文档问答，拿一个 7B 或 14B 的蒸馏版本，配合一套好的知识库检索，效果很多时候比硬上 70B 但检索混乱还要好。

2.3 安装 Ollama：五分钟就跑起来

如果之前没接触过 Ollama，这里补一句：它就是一个本地大模型运行工具，帮你省去了大量配置 Python 环境、CUDA、模型转换的麻烦。它支持 macOS、Linux、Windows，我建议 Linux 上跑生产环境，稳定性更好。

安装非常简单，官方一行命令（以 Linux 为例）：

curl -fsSL https://ollama.com/install.sh | sh

装完之后，拉取一个 DeepSeek 模型试试：

ollama pull deepseek-r1:7b

然后就能在命令行里直接对话了：

ollama run deepseek-r1:7b

这一步如果顺利，说明你的本地环境已经具备大模型推理能力了。接下来要做的就是教它看懂你的文档。

3. 知识库构建：从一堆散文件到高质量的知识仓库

3.1 知识库不是“文件复制粘贴”

很多人理解的知识库，就是把 PDF、Word 一股脑塞进某个软件里。但真正到了 RAG 阶段，你会发现，文档的“信息密度”和“组织方式”直接决定检索的质量。

我最早踩过一个坑：把一个两百页的产品手册直接整本丢进去，结果问什么它都答不准。为什么？因为 RAG 在检索时，是先把文档切成小块，再对每块做向量化，找到相似的块，然后送给模型。如果块太大，一块里塞了太多不相关内容，检索到的块相关性就低；如果块太小，语义可能被截断，也影响效果。

所以第一步，要做文本预处理。

3.2 文本清洗：把“垃圾”赶出去

文档来源五花八门，导出之后常有大量噪音。比如 PDF 里的页眉页脚、页眉里的章节名、扫描件的乱码、表格转文本后的错位、重复的水印字等。这些噪音如果不处理，会严重影响向量化质量。

我对文本清洗做的具体操作包括：

• 统一编码：全部转成 UTF-8 格式，避免中文乱码。
• 去噪：用正则把多余的空格、换行压缩掉，去掉页眉页脚特征（如“第 X 页”、“公司名称”）。
• 内容抽取：PDF 用 PyMuPDF 或 pdfplumber 处理，Word 用 python-docx 处理，Markdown 直接读源文件。
• 注释保留：代码类文档里的注释、TODO 信息往往很有价值，不要一刀切删掉。

清洗过后，我会做一次人工抽检。拿一两篇有代表性的文档，看看抽取出来的文本是不是“人能读的”。如果这一步抽检发现乱码严重，后面的向量化也不会好。

3.3 分块策略：怎么切才能让检索更准

分块是 RAG 里最微妙的一环。切大了，语义全但噪声多；切小了，精确但上下文缺失。我用的策略是“按结构切块 + 重叠窗口”。

按结构切块的意思，就是文档本身的章节结构切。比如 Markdown 可以按二级标题、三级标题作为边界，PDF 可以按段落切。这样切出来的块天然是“一个完整意思”，不会把一句话劈成两半。

重叠窗口的意思是，相邻两个块之间保留一定的重叠内容，避免语义在边界处断裂。比如每块 500 个字符，相邻块重叠 50 个字符。这样即使一句话跨到了下一块，检索时也能在两个块里都找到它。

我常用的参数是 chunk_size=500, chunk_overlap=50，具体可以根据文档类型微调。代码类文档可以切短一些，因为逻辑碎片化；技术手册可以切长一些，因为上下文依赖强。

3.4 向量化：用嵌入模型把文本变成“语义坐标”

向量化是 RAG 的另一个关键。简单理解，嵌入模型会把你输入的文本转换成一串数字向量，这个向量能体悟文本的语义。语义相近的文本，它们的向量在空间里会离得近。

嵌入模型的选择，我推荐 bge-large-zh（中文效果好）或 nomic-embed-text（通用多语言）。在 Ollama 里可以直接拉取：

ollama pull bge-m3

这个模型是 BAAI 推出的多语言嵌入模型，中文效果不错，368 维向量，兼顾效率和精度。把每段文本传入，得到向量之后，就可以入库了。

3.5 向量数据库：Chroma 还是 FAISS

向量数据库用来存向量，并提供相似度检索。我试过 Chroma 和 FAISS，个人更推荐 Chroma，因为它简单、纯 Python 实现，适合中小规模知识库（几万条向量以内），而且支持持久化存储，重启不丢数据。

FAISS 则在超大规模场景下性能更优，更适合生产级系统。但如果你只是搭一个“能用的知识库”，Chroma 足够，而且社区资料多，碰到问题好查。

我实际存储的结构类似这样：

import chromadb from chromadb.utils import embedding_functions client = chromadb.PersistentClient(path="./kb_store") collection = client.get_or_create_collection( name="team_docs", embedding_function=embedding_functions.OllamaEmbeddingFunction( url="http://localhost:11434/api/embeddings", model_name="bge-m3" ) ) # 添加文档 collection.add( ids=["doc_001_chunk_1", "doc_001_chunk_2"], documents=["文本块1的内容", "文本块2的内容"], metadatas=[{"source": "产品手册", "page": 1}, {"source": "产品手册", "page": 2}] )

4. RAG 完整链路：用 LangChain 把“检索 + 生成”串起来

4.1 从“问问题”到“出答案”，中间发生了什么

很多人误以为“大模型接入知识库”就是装个软件，然后把文档喂给它。其实贫瘠的真相是，大模型本身的记忆是有限的，上下文再长，也没法把所有文档都塞进去。RAG 的核心思路是：按需取用。

当你提一个问题，系统会先把问题转成向量，再去向量库里找到最相关的几段文本，然后把“你的问题 + 这几段文本”拼成一条新的提示词，发送给大模型。大模型会根据这几段文本的内容来回答，并且还可以附上引用来源。这样既避免了“模型胡编”，又让答案有据可查。

整个链路我用 LangChain 来编排。下面是一个简化版的实现思路。

4.2 核心代码：DeepSeek 本地模型的接入

首先，需要把 Ollama 上的 DeepSeek 接入 LangChain：

from langchain_community.llms import Ollama llm = Ollama( model="deepseek-r1:14b", base_url="http://localhost:11434", temperature=0.3 )

temperature 参数我设成 0.3，这是为了在“创造性”和“准确性”之间取平衡。做知识库问答时，我们更希望模型忠于材料，不要太放飞自我。如果设成 0，答案往往显得刻板；如果超过 0.7，就可能开始自由发挥了。

4.3 定义检索器：从向量库中找到最相关内容

然后是检索部分。我封装了一个函数，从 Chroma 里做相似度搜索，返回 top_k 个最相关的文档片段。

def retrieve_context(query, top_k=5): # 查询向量库，这里实际会调用 embedding 模型生成 query 的向量 results = collection.query(query_texts=[query], n_results=top_k) docs = results["documents"][0] metadatas = results["metadatas"][0] return docs, metadatas

top_k 设成 5，是我反复试出的一个经验值。取太少，可能漏关键信息；取太多，拼接的上下文会很长，既浪费 token，也可能把无关信息带进来。

4.4 组装提示词：让模型“有据可依”

最关键的其实是提示词的设计。我的思路是做一个“角色设定 + 任务要求 + 检索片段 + 问题”的四段式结构。

prompt_template = """ 你是一名熟悉我们团队内部资料的智能助理。请基于以下资料回答问题。 资料片段： {context} 请严格遵循以下要求： 1. 只基于上面提供的资料进行回答，不要编造。 2. 如果资料无法回答该问题，请明确说“根据现有资料无法回答”。 3. 在答案末尾列出你参考的资料标题或来源。 4. 回答使用中文，保持简洁、结构化。 用户问题：{question} """

这个提示词模板看起来简单，但每一句话都有用。“只基于提供的资料回答”是从源头抑制幻觉；“无法回答时说明”是给模型一个体面的失败方案；“列出参考来源”是提高可信度，让使用的人能回溯验证。这些细节是后面实际体验差距的重要来源。

4.5 完整问答函数

最后把上面几个部分串起来：

def ask_kb_question(question): docs, metadatas = retrieve_context(question) context = "\n\n".join(docs) prompt = prompt_template.format(context=context, question=question) answer = llm.invoke(prompt) return answer

到这里，一个可以交互的本地知识库助手已经成型。你在命令行里输入“我们之前项目复盘里提到的最大的三个风险是什么”，它就会去你的知识库里找相关内容并给出答案。第一次跑通这个功能的时候，我整个人是有点兴奋的——因为我真的从一个“文件搜索者”变成了“知识提问者”。

5. 让效果更好：调优的经验与注意细节

5.1 检索效果的“三把筛子”

实际使用中，检索不全准。有些明显的问题甚至检索到的文档相关性比较差，结果答案自然就偏了。我加了三道筛子来优化。

第一是关键词过滤。向量检索擅长语义匹配，但有时字面术语更关键。比如你搜“MySQL 索引优化”，向量库里可能返回了很多讲“数据库性能优化”的段落，反而没有提到“索引”。所以我会在检索结果里再做一次关键词过滤，把包含强关键词的结果优先排序。

第二是相似度阈值。给相似度分数设一个下限（比如 0.75），低于这个分数的不进上下文。这样可以避免把完全不相关的内容塞给模型。

第三是 rerank（重排）。简单的向量相似度有时不够准，我后来引入了 rerank 模型，对检索出的候选结果再做一次精细排序。这个策略会让答案质量有明显提升，但也会多消耗一点时间。

5.2 提示词细节：防止幻觉的技巧

大模型的幻觉问题，在 RAG 场景里会稍微好一些，但不是完全消失。我遇到过模型明明检索到的资料里没有那层意思，它硬是靠常识脑补了一段，看起来还挺自然。后来我在提示词里加了一条“原文没有的内容不要补充”，并且要求答案里引用资料的编号。一旦模型需要“把话和来源绑定”，它就会更谨慎。

另外一个心得是，同一篇文档我会保留“原文引用”和“摘要改写”两个版本。当用户提问需要精确数据时，优先返回原文片段；当用户提问需要概括时，则引导模型基于摘要改写。这样兼顾了准确性和可读性。

5.3 性能优化：别让回答来得太慢

本地模型最直观的痛点就是慢。回答一个问题要等十几秒甚至半分钟，团队里的同学用着用着就失去耐心了。我做了几件事来优化体验。

第一是限制上下文长度。一次检索进来的片段不要无脑全塞进去，设一个最大字符数，超出部分砍掉。这能显著减少模型要处理的内容量。第二是做缓存。对于类似的问题（比如“某模块的权限配置步骤”），我把答案缓存下来，同一问题直接命中缓存返回。第三是异步处理。我写了个简单的 FastAPI 服务，把“检索 + 生成”放到后台线程，前端先展示“正在检索资料”，然后再流式输出答案，体感会好很多。

5.4 文档更新的问题

知识库最怕的是过期。团队文档每周都在变，但向量库里的旧数据不会自动失效。我的做法是给每个文档块打上“版本号”或“更新时间”的元数据。定期重跑一遍索引，剔除旧版本。另外，团队约定“重要资料统一放到指定目录，AI 定时扫描”，这样整个知识库的更新就自动多了。

6. 踩坑实录与故障排查

6.1 模型加载后答非所问

这个坑大概率是 Ollama 模型和 LangChain 版本不兼容，或者模型上下文被截断。解决方式两步走：先确认 Ollama 服务正常：ollama ps看看模型是否真的加载了；再试一试用原生命令行直接问同样的问题，如果原生也好，那就是你封装和提示词的问题。

6.2 向量库里中文乱码

中文乱码一般出在 PDF 或 Word 解析上。有些 PDF 的文字编码是非标准的，提取出来“能看但怪”。我后来统一加了一个自动化筛查脚本，对每一段文本做简繁判断和字符集检测，发现乱码率超过阈值的文本直接不纳入索引。

6.3 Ollama 网络连接失败

这是个常见问题。排查步骤：先确认服务端口11434是否被占用或监听；再看看是否有防火墙拦截；最后确认 LangChain 里base_url是不是真的填对了，别用成了https。

6.4 回答过于冗长

本地模型有时候话痨，尤其是 DeepSeek-R1 推理模式，它会先把推理过程吐出来再给结论。如果你不需要那么长的思考过程，可以在提示词里加一句“直接给出答案，不要输出推理过程”。另外，设置max_tokens也能硬性限制长度。R1 这类的推理模型在正式知识库问答里，我其实更推荐关闭它的推理模式或者用非推理版本，延迟更低，回答也更紧凑。

7. 一些关于“本地知识库”的后话

项目跑通之后，我现在每天的工作习惯已经离不开这个助手了。写方案、查旧文档、回顾决策记录、整理客户反馈，都会先问一句知识库。它不完美，偶尔也会给不到最理想的答案，但“有一个懂你上下文、且愿意随时陪你检索文档的本地助手”，这个体验和靠人力翻资料完全不一样。

如果你也想自己搭一套，我建议从小做起。先用一台普通的开发机，装好 Ollama，拉一个 7B 小模型，再找几十篇自己的文档把它跑通。不用一上来就追求多好的性能，先把链路走通，再逐步优化模型大小、检索策略和交互体验。

最后分享一个小技巧：给知识库里的每份文档写一段“文档摘要”并单独建索引。在检索时，如果查询意图偏“概述类”，先匹配摘要；如果意图偏“细节类”，再去匹配原文块。这个“二级索引”的思路虽然看起来多余，但对提高答案准确度帮助特别大。我做了一轮之后，团队里普遍反馈“比原来好几个档位”。如果你也在折腾本地知识库，欢迎试试这个思路，有问题也可以一起交流。