Embedding 与向量数据库原理

前言

很多开发者开始做 AI 项目时，最先接触的是聊天接口。

最简单的架构通常是：

用户输入
↓
后端接口
↓
大模型 API
↓
返回答案

这种方式适合普通问答，但一旦项目涉及私有知识库、文档问答、企业资料检索、客服系统、代码库分析，就会遇到一个核心问题：

模型本身并不知道你的私有数据。

例如：

• 公司内部文档
• 产品说明书
• 用户手册
• 历史工单
• 项目代码
• 数据库说明
• 业务 SOP

这些内容不在模型训练数据里，即使模型能力很强，也无法凭空知道。

这时就需要 Embedding 和向量数据库。

它们的作用不是让模型“变聪明”，而是让系统能够从外部知识中找到与用户问题最相关的内容，再交给模型回答。

什么是 Embedding？

Embedding 可以理解为：

把文本转换成一组数字。

例如一句话：

Docker 是什么？

经过 Embedding 模型处理后，会变成类似这样的向量：

[0.012, -0.253, 0.887, ...]

这组数字本身人类看不懂，但模型可以通过它表达文本含义。

也就是说，Embedding 的核心价值是：

把自然语言变成机器可以计算的语义表示。

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

传统搜索主要依赖关键词。

例如用户搜索：

如何部署 Node.js 项目？

如果文档标题是：

使用 PM2 和 Nginx 发布后端服务

关键词可能对不上。

传统搜索可能认为这两者相关性不高。

但从语义上看，它们其实很接近：

• 部署
• Node.js
• PM2
• Nginx
• 后端服务

Embedding 的优势就在这里。

它不是只看字面关键词，而是计算语义相似度。

因此：

如何部署 Node.js 项目？

和：

使用 PM2 和 Nginx 发布后端服务

在向量空间中会比较接近。

向量空间是什么意思？

可以把向量空间想象成一个巨大的坐标系。

每一段文本都会被放到这个空间里的某个位置。

语义相近的文本，位置更接近。

语义无关的文本，距离更远。

例如：

Docker 如何部署应用？

和：

Docker Compose 如何启动服务？

距离较近。

而：

如何做番茄炒蛋？

距离就很远。

向量数据库的工作，就是在这个空间里快速找到距离用户问题最近的内容。

向量数据库是什么？

向量数据库是专门用来存储和检索向量的数据库。

它主要解决一个问题：

当你有几十万、几百万甚至上千万条文本向量时，如何快速找到最相似的几条？

普通数据库擅长：

• 精确查询
• 条件过滤
• 排序
• 聚合统计

例如：

select * from articles where id = 1;

但普通数据库并不擅长：

找出语义最接近这句话的 10 段文本

向量数据库擅长的正是这个任务。

Embedding + 向量数据库的基本流程

一个典型流程如下：

原始文档
↓
文本切分
↓
生成 Embedding
↓
写入向量数据库
↓
用户提问
↓
问题生成 Embedding
↓
向量检索
↓
取回相关片段
↓
交给大模型回答

这就是很多知识库问答系统的基础。

第一步：文档切分

不能把一整本文档直接丢给 Embedding。

原因有两个：

第一，文本太长会超出模型限制。

第二，长文本会降低检索精度。

例如一篇 8000 字文章里只有一段内容与问题相关，如果整篇文章作为一个向量存储，检索出来之后会包含大量无关内容。

更合理的方式是将文档切成小块。

常见切分单位：

• 按标题切分
• 按段落切分
• 按固定字数切分
• 按语义边界切分

例如：

chunk 1：Docker 的基本概念
chunk 2：Dockerfile 的作用
chunk 3：Docker Compose 的使用方式
chunk 4：生产环境部署注意事项

用户问 Docker Compose 时，系统只需要召回 chunk 3 和 chunk 4，而不是整篇文章。

第二步：生成向量

每个 chunk 都会被送入 Embedding 模型。

生成类似这样的数据：

{
  "id": "doc_001_chunk_003",
  "content": "Docker Compose 用于管理多个容器服务...",
  "embedding": [0.12, -0.08, 0.31, ...],
  "metadata": {
    "title": "Docker Compose 实战",
    "source": "article",
    "url": "/docker-compose-guide"
  }
}

其中 metadata 非常重要。

它可以保存：

• 文档标题
• 原文链接
• 作者
• 创建时间
• 分类
• 权限信息
• 版本号

后期做检索、过滤、溯源都离不开 metadata。

第三步：写入向量数据库

常见向量数据库包括：

• Pinecone
• Milvus
• Qdrant
• Weaviate
• Chroma
• PostgreSQL + pgvector

对于个人项目或中小型项目，pgvector 是一个非常实用的选择。

因为它可以直接在 PostgreSQL 中同时存储：

• 业务数据
• 文档内容
• 向量数据
• metadata

系统复杂度较低。

如果数据规模很大，或者需要更强检索性能，可以考虑专门的向量数据库。

第四步：用户提问并检索

当用户输入：

Docker Compose 部署 Node.js 项目需要注意什么？

系统会先将这个问题也转换成向量。

然后在向量数据库里查找最相似的内容。

返回结果可能是：

chunk 12：Docker Compose 服务编排
chunk 19：Node.js 容器部署注意事项
chunk 25：MySQL 与 Redis 数据持久化

这些内容会作为上下文提供给大模型。

第五步：交给大模型生成答案

最终 Prompt 可能类似：

你是一个技术助手。

请根据以下资料回答用户问题。

资料：
1. Docker Compose 可以通过 docker-compose.yml 管理多个服务...
2. Node.js 服务不要直接使用 localhost 连接 MySQL，而应使用服务名...
3. MySQL 数据必须使用 volume 持久化...

用户问题：
Docker Compose 部署 Node.js 项目需要注意什么？

这样模型回答时就有依据，而不是凭空生成。

相似度是如何计算的？

常见方式包括：

• Cosine Similarity
• Dot Product
• Euclidean Distance

最常见的是余弦相似度。

它关心两个向量方向是否接近，而不是绝对大小。

简单理解：

两个文本语义越接近，向量夹角越小，相似度越高。

开发者不一定需要手写这些算法，因为向量数据库通常已经封装好了。

但理解这个原理很重要。

否则很容易误以为向量数据库是“神奇搜索引擎”。

实际上它只是根据向量相似度返回最接近的内容。

Embedding 系统最容易踩的坑

1. Chunk 太大

如果一个 chunk 太大，就会包含太多主题。

结果是：

• 检索不精准
• 上下文浪费
• 回答容易跑偏

例如一个 chunk 同时包含 Docker、Nginx、Redis、MySQL，用户只问 Redis，模型却看到大量无关内容。

2. Chunk 太小

太小也有问题。

例如只按一句话切分：

Redis 可以用来缓存。

这句话缺少上下文，模型很难判断它是在说什么业务场景。

因此 chunk 需要在“完整语义”和“足够精准”之间平衡。

3. 只做向量检索，不做关键词检索

向量检索擅长语义匹配，但不一定擅长精确匹配。

例如：

错误码 E1027 是什么意思？

这种问题更适合关键词搜索。

因此更成熟的系统会采用混合检索：

向量检索
+
关键词检索
+
排序重排

4. 不保存原始文本

有些开发者只保存向量，不保存原文。

这是错误设计。

向量用于检索，真正给模型看的仍然是原始文本。

因此必须保存：

• 原文内容
• 文档来源
• chunk id
• metadata

5. 忽略权限控制

企业知识库尤其要注意。

不是所有用户都能访问所有文档。

如果向量检索时没有权限过滤，可能出现严重数据泄露。

正确做法是在 metadata 中加入权限信息。

例如：

department: engineering
visibility: internal
tenant_id: xxx

检索时先过滤权限，再做相似度搜索。

向量数据库不是万能的

向量数据库解决的是“找到相关内容”。

它不负责：

• 判断内容是否正确
• 生成最终答案
• 理解业务规则
• 替代数据库查询
• 替代权限系统

很多人把向量数据库想得太强。

实际上，一个可靠 AI 系统通常需要：

向量数据库
+
关系型数据库
+
缓存
+
权限系统
+
日志系统
+
模型调用层

它只是其中一个组件。

什么时候需要向量数据库？

适合使用向量数据库的场景：

• 文档问答
• 企业知识库
• 客服机器人
• 代码搜索
• 商品语义搜索
• 长文本检索
• RAG 系统

不一定需要的场景：

• 简单聊天机器人
• 固定菜单客服
• 纯结构化数据查询
• 少量静态 FAQ

如果只有几十条 FAQ，直接用数据库和关键词搜索可能就够了。

不要为了技术而引入技术。

推荐架构

一个较完整的知识库系统可以这样设计：

文档上传
↓
文本解析
↓
文档清洗
↓
Chunk 切分
↓
Embedding 生成
↓
向量数据库
↓
用户提问
↓
混合检索
↓
重排序
↓
上下文拼接
↓
大模型生成
↓
答案引用来源

这里每一步都影响最终效果。

很多 RAG 系统效果不好，不是模型差，而是前面的文档处理和检索质量太差。

总结

Embedding 的本质是将文本转换成可计算的语义向量。

向量数据库的本质是快速找到语义相似的内容。

它们共同解决了 AI 系统中的一个核心问题：

如何让模型使用外部知识回答问题。

但真正优秀的 AI 知识库系统，不只是把文档塞进向量数据库。

还需要考虑：

• 文档清洗
• Chunk 策略
• metadata 设计
• 权限过滤
• 混合检索
• 重排序
• 成本控制
• 答案溯源

只有把这些环节串起来，Embedding 和向量数据库才能真正发挥价值。