企业官网建设流程全解析

如果你使用过大模型，一定遇到过一个非常头疼的问题：

模型回答得非常流畅，但就是不对。

尤其是在企业内部场景。

例如公司有一套自己的技术规范：

生产环境服务器不能直接使用 root 登录 Redis 必须开启密码认证 数据库备份每天凌晨 2 点执行 Java 项目统一使用 JDK 21 内部 API 必须经过网关

你把这些资料交给大模型，然后问：

生产环境服务器可以直接使用 root 登录吗？

如果没有额外的知识库，大模型很可能根据自己训练过程中学到的通用知识进行回答。

问题就在这里：

大模型知道很多东西，但它不知道你公司的“内部规则”。

这时候就轮到 RAG 出场了。

RAG，全称：

Retrieval-Augmented Generation，检索增强生成。

它的核心思想并不复杂：

用户问题 ↓ 检索知识库 ↓ 找到相关资料 ↓ 把资料交给大模型 ↓ 生成答案

与其让模型“猜”，不如先给它找到正确的资料。

本文我们不讨论复杂的 Agent Framework，而是直接从工程落地的角度，拆解一个基于本地大模型的 RAG 系统应该怎么设计。

一、RAG 到底解决了什么问题？

先看传统大模型：

用户问题 ↓ LLM ↓ 回答

问题是：

LLM 的知识并不等于你的知识。

比如：

企业内部技术文档 公司安全规范 产品说明书 项目 API 文档 运维手册 员工知识库 内部 Wiki

这些内容通常不在模型训练数据中。

即使模型本身能力非常强，也不可能凭空知道。

所以我们增加一个知识库：

企业文档 │ ▼ 文档处理 │ ▼ 文档分块 │ ▼ Embedding │ ▼ 向量数据库 │ │ 用户问题 ────────→ 检索 │ ▼ 相关文档 │ ▼ LLM │ ▼ 答案

这就是 RAG。

二、RAG 的核心工作流

一个完整的 RAG 系统，可以拆成两个阶段：

第一阶段：建立知识库

原始文档 ↓ 文本解析 ↓ Document Chunking ↓ Embedding ↓ Vector Database

第二阶段：用户查询

用户问题 ↓ Query Embedding ↓ 向量检索 ↓ Top-K 文档 ↓ Prompt 拼接 ↓ 本地 LLM ↓ 最终回答

因此 RAG 最重要的三个环节就是：

1. 文档分块

2. 向量化 Embedding

3. 检索匹配

接下来逐个拆。

三、第一步：文档分块

假设公司有一个 100 页的 PDF：

企业服务器安全管理规范.pdf

如果直接把整个 PDF 转成一个向量：

100 页 ↓ 1 个 Vector

效果通常不会很好。

原因是：

一个向量包含的信息太多了。

比如第 5 页讲：

SSH 登录规范

第 50 页讲：

数据库备份

第 90 页讲：

日志审计

这些内容混在一起，很难实现精准检索。

因此第一步就是：

Chunking —— 文档分块。

例如：

原始文档 第 1～5 页 ↓ Chunk 1 第 6～10 页 ↓ Chunk 2 第 11～15 页 ↓ Chunk 3

更常见的做法不是简单按照页码切，而是按照：

标题 段落 句子 Token 数量 语义边界

进行切分。

四、Chunk 到底应该切多大？

这是 RAG 实际落地时非常重要的问题。

如果 Chunk 太大：

Chunk = 5000 tokens

那么一次检索可能塞进大量无关信息。

如果 Chunk 太小：

Chunk = 50 tokens

又容易出现上下文不完整。

例如：

Chunk A： Redis 生产环境部署时需要...... Chunk B： 同时必须开启密码认证......

如果刚好被切开，检索到 A 时就可能缺少 B 的关键内容。

因此通常需要设置：

Chunk Size + Chunk Overlap

例如：

Chunk Size = 500 tokens Overlap = 100 tokens

示意：

Chunk 1 ████████████████████ █████ ↓ Chunk 2 ████████████████████ █████ ↓ Chunk 3 ███████████████████

这种重叠区域可以降低语义被硬切断的问题。

五、第二步：Embedding

完成文档切分之后，下一步就是：

把文本转换成向量。

例如：

Redis 必须开启认证

经过 Embedding 模型后：

[ 0.123, -0.421, 0.782, ... ]

假设最终得到 768 维向量：

768 个数字

这个向量就可以代表这段文字的语义特征。

六、为什么不能直接使用关键词搜索？

假设知识库中存在：

生产环境 Redis 必须开启身份认证。

用户问：

线上 Redis 要不要设置密码？

如果使用传统关键词搜索：

"Redis" + "密码"

可能还能找到。

但如果用户问：

正式环境的缓存服务如何进行访问控制？

关键词完全不同。

但是从语义上看：

Redis 缓存服务 密码 访问控制 生产环境 正式环境

它们表达的是非常接近的意思。

这就是向量检索的优势。

七、第三步：向量检索

用户提出问题：

生产环境 Redis 如何进行安全配置？

系统首先把这个问题也进行 Embedding：

Query ↓ Embedding ↓ Query Vector

然后拿 Query Vector 和知识库中的所有向量计算相似度。

最常见的方法之一就是：

Cosine Similarity，余弦相似度。

公式：

A · B similarity = ------- |A||B|

简单理解：

越接近 1 ↓ 语义越相似

例如：

Chunk A → 0.92 Chunk B → 0.84 Chunk C → 0.37 Chunk D → 0.21

系统就可以选择：

Top-K = 3

最终拿到：

Chunk A Chunk B Chunk C

然后把这些内容交给大模型。

八、一个完整的 RAG Pipeline

现在把整个过程串起来。

假设企业内部存在：

docs/ ├── 网络安全规范.md ├── Linux 运维手册.md ├── Redis 部署规范.md └── API 开发规范.md

首先：

Documents ↓ Loader ↓ Text ↓ Chunker ↓ Chunks ↓ Embedding ↓ Vector DB

用户提问：

生产环境 Redis 应该怎么配置？

然后：

Query ↓ Embedding ↓ Vector Search ↓ Top-K Chunks ↓ Context ↓ Prompt ↓ Local LLM ↓ Answer

这就是完整的 RAG。

九、直接用 Python 写一个最小 RAG

为了理解底层原理，我们先不用复杂框架。

直接使用：

Python Sentence Transformers NumPy

实现一个简化版本。

首先安装：

pip install sentence-transformers numpy

然后创建：

rag_demo.py

代码如下：

from sentence_transformers import SentenceTransformer import numpy as np class SimpleRAG: def __init__(self): self.model = SentenceTransformer( "BAAI/bge-small-zh-v1.5" ) self.documents = [] self.vectors = [] def add_document(self, text): vector = self.model.encode(text) self.documents.append(text) self.vectors.append(vector) def similarity(self, query_vector, doc_vector): query_norm = np.linalg.norm(query_vector) doc_norm = np.linalg.norm(doc_vector) if query_norm == 0 or doc_norm == 0: return 0.0 return np.dot( query_vector, doc_vector ) / ( query_norm * doc_norm ) def search(self, query, top_k=3): query_vector = self.model.encode(query) scores = [] for index, vector in enumerate( self.vectors ): score = self.similarity( query_vector, vector ) scores.append( (index, score) ) scores.sort( key=lambda x: x[1], reverse=True ) results = [] for index, score in scores[:top_k]: results.append({ "content": self.documents[index], "score": float(score) }) return results if __name__ == "__main__": rag = SimpleRAG() rag.add_document( "生产环境 Redis 必须开启身份认证，" "禁止使用默认配置直接暴露服务。" ) rag.add_document( "Linux 服务器必须关闭不必要的网络服务，" "并定期更新系统安全补丁。" ) rag.add_document( "公司 API 必须经过统一网关，" "禁止直接暴露内部服务端口。" ) query = "Redis 线上环境需要设置密码吗？" results = rag.search( query, top_k=2 ) for result in results: print( f"相似度：{result['score']:.4f}" ) print( f"内容：{result['content']}" ) print("-" * 50)

这段代码虽然非常简单，但是已经把 RAG 最核心的逻辑跑通了：

Document ↓ Embedding ↓ Vector ↓ Query ↓ Similarity ↓ Top-K

十、为什么这个 Demo 还不能算真正的 RAG？

因为现在只有：

Retrieval

还缺少：

Generation

真正的 RAG 应该是：

Retrieval + Generation

也就是：

检索 + 大模型生成

假设检索出来：

生产环境 Redis 必须开启身份认证。 禁止使用默认配置直接暴露服务。

接下来需要构造 Prompt：

你是企业内部技术助手。 请严格根据下面的知识库内容回答问题。 如果知识库没有相关信息，请明确告诉用户： “知识库中没有找到相关信息”， 不要自行编造。 知识库： 生产环境 Redis 必须开启身份认证。 禁止使用默认配置直接暴露服务。 用户问题： Redis 线上环境需要设置密码吗？

然后交给本地大模型。

十一、本地大模型在 RAG 中负责什么？

这里有一个非常容易被误解的地方：

Embedding 模型 ≠ LLM。

两者职责完全不同。

Embedding：

文本 ↓ 向量

主要负责：

理解文本之间的语义关系。

LLM：

Context + Question ↓ Answer

主要负责：

根据上下文组织自然语言答案。

因此：

RAG │ ┌─────────┴─────────┐ │ │ Embedding Model LLM │ │ 负责检索 负责生成

这是整个 RAG 系统非常重要的知识点。

十二、为什么推荐本地大模型？

企业内部知识库通常包含：

源代码 API 文档 架构设计 服务器配置 业务流程 内部制度 客户资料

这些数据可能不能直接上传到公网模型。

因此可以使用：

本地 Embedding + 本地 Vector DB + 本地 LLM

形成：

企业内部服务器 │ ┌───────────┼───────────┐ │ │ │ Embedding Vector DB Local LLM │ │ │ └───────────┴───────────┘ │ ▼ RAG

整个知识流转过程都可以控制在企业自己的基础设施中。

十三、企业内部技术文档问答案例

假设现在有一家互联网公司。

内部拥有：

Linux 运维手册 MySQL 数据库规范 Redis 部署规范 Kubernetes 文档 网络安全规范 API 开发规范

员工每天都会问：

Redis 密码在哪里配置？ MySQL 备份什么时候执行？ 生产环境 SSH 有什么要求？ Kubernetes 镜像应该从哪里拉取？ API 为什么必须经过网关？

传统解决方案：

员工 ↓ 搜索内部 Wiki ↓ 打开几十个页面 ↓ 寻找答案

效率很低。

使用 RAG：

员工 ↓ AI 技术助手 ↓ Vector Search ↓ 内部文档 ↓ Local LLM ↓ 答案

最终可以实现：

员工： 生产环境 Redis 是否必须开启密码？ AI： 是。 根据《Redis 生产部署规范》， 生产环境 Redis 必须启用身份认证， 禁止直接使用默认配置暴露服务。

这里的关键不是模型有多聪明。

而是：

模型回答的时候拿到了正确的企业内部资料。

十四、RAG 最大的坑：检索到了不代表正确

很多人第一次做 RAG，会发现：

向量库有数据 Embedding 也正常 但是回答还是不准确

为什么？

因为：

RAG 的效果上限，很大程度取决于 Retrieval。

如果检索阶段拿错资料：

Query ↓ 错误 Chunk ↓ LLM ↓ 错误答案

即使模型能力再强，也很难得到正确结果。

所以调 RAG，不能只盯着 LLM。

应该重点观察：

Chunking Embedding Retrieval Reranking Prompt Generation

十五、Top-K 不是越大越好

例如：

Top-K = 3

可能得到：

相关 相关 相关

但是如果：

Top-K = 20

可能变成：

相关 相关 一般 一般 无关 无关 无关 ...

然后把这 20 个 Chunk 全部塞进 Prompt。

结果就是：

上下文污染。

所以实际系统中经常需要：

Vector Search ↓ Top 20 ↓ Reranker ↓ Top 5 ↓ LLM

也就是：

先粗排，再精排。

十六、RAG 的进阶架构

一个稍微成熟的企业 RAG，可以设计成：

用户问题 │ ▼ Query Processing │ ▼ Embedding │ ▼ Vector Search │ ▼ Top-K │ ▼ Reranker │ ▼ Context Filter │ ▼ Prompt Builder │ ▼ Local LLM │ ▼ Answer

知识库建立过程：

PDF / Word / Markdown │ ▼ Document Loader │ ▼ Cleaning │ ▼ Chunking │ ▼ Embedding │ ▼ Vector Database

这两个 Pipeline 共同构成完整 RAG 系统。

十七、Vector Database 应该怎么选？

常见方案包括：

Qdrant Milvus pgvector Weaviate Chroma

如果是个人项目：

Chroma

就足够开始学习。

如果准备做企业项目：

Qdrant Milvus pgvector

都可以重点研究。

其中：

PostgreSQL + pgvector

特别适合已经大量使用 PostgreSQL 的团队。

而独立向量数据库则更适合：

大规模向量检索 高并发 复杂检索场景

最终选择并不是看“哪个最火”，而是看你的：

数据规模 查询量 部署环境 团队技术栈 运维能力

十八、一个真正可落地的企业 RAG 架构

如果准备把这个项目继续扩展，可以设计成：

Web UI │ ▼ FastAPI │ ▼ RAG Service │ ┌────────────┼────────────┐ │ │ │ Retriever Reranker Prompt │ │ ▼ ▼ Vector DB Local LLM │ │ └────────────┬────────────┘ │ ▼ Answer

知识库侧：

Documents │ ▼ Document Parser │ ▼ Chunk │ ▼ Embedding │ ▼ Vector DB

如果使用 Docker，可以进一步拆成：

docker-compose │ ├── rag-api ├── vector-db ├── embedding-service ├── llm-service └── frontend

最终形成一个完全本地化的知识库问答系统。

十九、RAG 不等于“给 AI 加个数据库”

这是最后非常重要的一点。

很多人会把 RAG 理解成：

数据库 + 大模型

实际上并不是。

RAG 真正的核心是：

Knowledge ↓ Representation ↓ Retrieval ↓ Context ↓ Generation

也就是：

知识如何组织、如何表示、如何检索、如何筛选，以及如何交给模型使用。

其中任何一个环节出问题，都可能导致最终回答质量下降。

二十、总结：真正理解 RAG，只需要抓住这条链路

如果你准备自己实现 RAG，先不要急着上 LangChain。

先把下面这条链路彻底搞明白：

原始文档 │ ▼ 文档解析 Loader │ ▼ Chunking │ ▼ Embedding │ ▼ Vector Database │ │ 用户问题 ──────────────┘ │ ▼ Query Embedding │ ▼ Vector Search │ ▼ Top-K │ ▼ Reranker │ ▼ Context │ ▼ Prompt Builder │ ▼ Local LLM │ ▼ Answer

真正的 RAG，不是简单的：

“把 PDF 上传给 AI。”

而是一整套从文档 → 向量 → 检索 → 上下文 → 大模型生成的工程系统。

如果你准备自己做一个企业内部知识库，建议按照下面的顺序学习：

第一阶段： 理解 Embedding 第二阶段： 手写 Cosine Similarity 第三阶段： 实现基础 Vector Search 第四阶段： 学习 Chunking 第五阶段： 接入 Qdrant / Milvus / pgvector 第六阶段： 接入本地 Embedding 模型 第七阶段： 接入本地 LLM 第八阶段： 加入 Reranker 第九阶段： 加入权限、用户隔离和日志 第十阶段： Docker 化部署

做到这里，你基本就已经从“调用 RAG 框架”进入了真正的RAG 工程实践。

后续如果继续往前走，还可以进一步研究：

Hybrid Search Query Rewrite Reranker Multi-Query Retrieval Parent-Child Chunk Metadata Filter Knowledge Graph Agentic RAG Graph RAG RAG Evaluation

这些才是 RAG 从 Demo 走向生产环境之后真正值得研究的方向。

本教程配套的离线知识库测试语料和环境配置指南也可以一起获取，方便大家直接搭建本地环境进行测试。