Embedding、向量
与语义检索基础

路线12章中的位置

E00在线语义检索的组件链路

用户问“鞋子不合适怎么退钱”时，常见 RAG 查询包含两类不同模型调用，职责不能混淆。

离线与在线：文档上传时批量做一次 Embedding；用户每次提问时只给“问题”做 Embedding。不是每次提问都重新向量化整套知识库。

E01Embedding 解决的核心问题

知识库里有一句：“商品签收后七日内可以申请退款。”用户却问：“东西不合适，怎么把钱退回来？”传统关键词搜索可能找不到，因为用户没有输入“申请退款”；但人知道“把钱退回来”和“退款”意思接近。

核心：Embedding不是生成答案，而是给文字制作“语义坐标”，让程序可以用数学方式比较两段文字是否接近。

E02Embedding在系统哪里、由谁调用

Embedding通常是一个专门的模型API。开发者的后端程序把文本发给Embedding模型，模型返回固定长度的数字数组。

embedding_response = Embedding客户端.创建(
    model = "某个 embedding 模型",
    input = "商品签收后七日内可以申请退款"
)

vector = embedding_response.vector

E02-AEmbedding 模型的工作对象

它是经过训练的神经网络模型，但任务与聊天模型不同：聊天模型接收文字后生成文字；Embedding模型接收文字后输出固定数量的小数。

输入：退款多久到账？
输出：通常三个工作日内到账。

输入：退款多久到账？
输出：[0.018, -0.227, 0.641, ...]

训练时，系统用大量相关和不相关文本调整网络参数，让意思相关的文本向量靠近，让不相关文本向量远离。这类思路常称为对比学习或相似度学习。

需要懂多深？高级AI应用工程师必须会选模型、调用、批处理、理解维度和相似度、保持文档与查询模型一致、做召回评测和处理迁移。初期不必推导全部矩阵公式，也不必从零训练模型。

E02-BEmbedding 调用过程

// 通用伪代码，实际名称按厂商SDK为准
client = 创建AI客户端(api_key = 服务器密钥)
result = client.embeddings.create(
  model = "某个embedding模型",
  input = ["退款将在三个工作日内返回", "七日内可申请退货"]
)
vector_1 = result.data[0].embedding

入库几万片段时通常批量调用。超时或429要有限重试和退避；文本过长先切块；批量任务要记录每批成功/失败并支持续跑。

E03向量的数据形态

[0.018, -0.227, 0.641, 0.093, -0.412, ...]

这串数字就是向量。真实Embedding可能有几百、上千甚至更多个数字。数字的个数叫“维度”。

不要逐位翻译：通常不能简单说第1个数字代表“退款”、第2个代表“情绪”。语义由整个高维向量的组合、方向和相对位置共同表达。

E04用二维地图想象高维空间

图中意思相近的句子落在相近区域。真实空间不是二维平面，而是人无法直接画出的高维空间；二维图只是帮助形成直觉。

E05文档和问题必须各做一次Embedding

先把“书”放到地图上　→　再把“问题”放到同一张地图　→　寻找附近的书

E06Embedding 模型兼容性

假设文档用模型A生成向量，查询却改用模型B。两种模型建立的坐标系可能完全不同，就像一个人使用北京地铁图，另一个人却拿纽约地铁坐标找站点。

文档向量：模型 A
查询向量：模型 B
直接比较

文档向量：模型 A
查询向量：模型 A
在同一向量空间比较

E07向量相似度计算

最常见的方式之一是余弦相似度。它重点比较两个向量的“方向是否接近”，而不只是比较长度。

文档向量 A = [0.2, 0.8, 0.1, ...]
查询向量 B = [0.18, 0.76, 0.12, ...]

cosine_similarity(A, B) → 0.93

分数越高通常代表语义越接近，但具体范围、距离定义和阈值要看Embedding模型与向量数据库配置。

E08从相似度到Top-k结果

向量数据库会给大量文档片段计算近邻，取最相似的前k条。top_k=3表示最多先取3个候选，不代表这3个一定正确。

相似度分数不是正确率。0.91不等于“91%肯定能回答”，也不能跨模型、跨数据集机械使用同一个阈值。

E09关键词检索与语义检索

高级RAG通常不会迷信单一路线。订单号用关键词非常可靠，而自然语言问题适合语义检索，两者结合更稳。

E10相似不等于正确

E10-A新旧政策不会由Embedding自动判断

新旧政策措辞通常很接近，所以向量也很接近。Embedding不知道今天日期、哪个版本已作废，也没有权限替公司决定使用哪份。

旧政策：退款7天到账
新政策：退款3个工作日到账
→ 两份一起检索，让大模型自己选

先按metadata过滤有效版本
→ 只在当前有效且有权限的资料中
进行向量搜索

{
  "policy_id": "refund-policy",
  "version": 3,
  "status": "active",
  "effective_at": "2026-09-01",
  "expires_at": null,
  "tenant_id": "company-a"
}

查询时先固定过滤：租户等于当前用户所属公司、状态为active、生效时间不晚于现在、失效时间为空或晚于现在；满足后才进行Top-k。

冲突保护：过滤后如果同一政策仍有两个有效版本或内容冲突，停止自动回答并报警/转人工，不能让模型猜。

E10-B检索与回答错误的处理

日志保存request_id、问题、Embedding模型版本、过滤条件、召回片段和政策版本、相似度、Rerank分数、最终引用与答案。修复后把错误案例永久加入评测集。

E10-C向量记录与 Metadata 的存储权衡

准确说法是：每个可检索文档片段通常是一条数据库记录，里面有一个向量和少量必要字段。不是向量里的每个小数都附一份信息，也不是每个片段复制整份原始文档。

{
  "chunk_id": "refund-v3-002",
  "vector": [0.018, -0.227, 0.641, ...],
  "text": "退款通常在三个工作日内原路返回。",
  "policy_id": "refund-policy",
  "version": 3,
  "status": "active",
  "tenant_id": "company-a",
  "source": "refund-policy.pdf#page=2"
}

举例：1536维向量如果每个数字按4字节保存，向量本体约6KB；几项短metadata常只是几百字节量级。这里只是帮助理解，真实大小取决于维度、数据类型、文本、索引和压缩。

1536 × 4字节 ≈ 6KB　｜　必要metadata通常只是额外的一小部分

为什么过滤还可能更快

常用metadata字段会建立标量索引或倒排索引，程序不是逐条读取再判断。预过滤先快速缩小范围，通常同时提升安全性、准确率和速度；不同数据库也可能采用搜索中融合过滤或搜索后过滤，需要真实压测。

真正的权衡：metadata不是越多越好；只保存过滤、追踪和审计所需字段，也只给经常过滤的字段建索引，因为索引会占空间并增加写入成本。

E10-D这是行业常规吗：不同数据库只是叫法不同

是主流做法，但不应说成“每个向量必须有一段说明”。更准确的数据模型是：一条记录有唯一ID、一个或多个向量，以及可选的结构化附加字段。

唯一ID
 向量（相似度搜索）
 可选字段（过滤、展示、追踪或回查原文）

附加字段并非强制都有。纯图片相似搜索可以只存image_id和vector；企业RAG通常需要租户、权限、来源和版本，否则难以安全上线。

没有绝对统一：正文同库存还是外部存，要看规模、一致性、延迟、权限和数据库能力；但“向量记录关联ID及必要业务字段”是常规设计。

官方参考：Qdrant · Milvus · Pinecone · Weaviate

E10-E文档数据库的职责与选型

先纠正：向量数据库和文档存储不一定分开。“文档数据库”在这里是泛称，指保存原始文件、正文片段、版本和权限等权威内容的地方，不是说必须使用某个名叫“文档数据库”的产品。

最容易理解的分工

documents表：
document_id, 文件名, 原始文件地址, 版本, 状态, 权限

chunks表：
chunk_id, document_id, 片段正文, 页码, 标题

向量记录：
chunk_id, vector, tenant_id, status

也可以完全不分开

为什么分开？不是因为技术规定，而是不同存储擅长不同任务：对象存储擅长放大文件，关系数据库擅长管理版本权限和事务，向量数据库擅长近邻搜索。

分开的代价：必须保证同步一致。删除文档时要同时处理原文件、片段和向量；因此需要稳定的document_id/chunk_id、任务状态、重试和对账。初学项目会优先使用较简单的一体化方案，理解后再拆分。

E10-F向量数据库的类型

“向量数据库”不是只有一种产品。以下分类比死记品牌更重要，因为同一个产品可能同时跨越两类。

E10-G常见向量数据库产品

E10-H企业客服数据库选型

选型不是“谁最火”　=　现有技术栈 + 数据规模 + 检索类型 + 权限过滤 + 运维能力 + 成本合规

E10-I用一份退款政策对比实际存法

knowledge_chunks表：
chunk_id
text
tenant_id
version
status
embedding vector

Point：
id = chunk_id
vector = embedding
payload = {
  text, tenant_id,
  version, status
}

Document：
text 字段做关键词搜索
dense_vector 做向量搜索
tenant/status 做过滤

向量库：chunk_id + vector
PostgreSQL：chunk_id + text
对象存储：原始PDF

我们的学习顺序：不会一上来同时搭七种数据库。先用一体化方案完成RAG全链路，再选择Qdrant做一次专用向量库迁移对比；这样既掌握原理，也能看懂不同产品。

官方参考：pgvector · Qdrant · Milvus · Weaviate · Elasticsearch · Redis

E10-JRedis 的定位与适用场景

Redis不是AI模型，也不是只为向量设计的数据库。它通常作为一个独立运行的高速数据服务，数据主要在内存中处理，所以读写很快。多台后端程序都可以通过Redis客户端访问同一份临时或热点数据。

最基础的Key-Value理解

写入：
SET session:user-10086 "logged-in"

读取：
GET session:user-10086

设置10分钟后自动过期：
SET verification:138xxxx "482913" EX 600

Key像储物柜编号，Value是柜子中的数据。TTL表示到期自动删除，适合验证码、临时会话和缓存。

Redis在AI客服里的位置

用户请求
├─ 限流：一分钟最多请求多少次
├─ 会话：当前对话ID和临时上下文
├─ 普通缓存：同一政策查询结果
├─ 语义缓存：意思相近的问题复用结果
├─ 任务状态：文档解析/Embedding进度
├─ Agent临时状态：工具执行到哪一步
└─ 向量搜索：可选能力，不是Redis唯一用途

普通缓存与语义缓存

“退款多久到账？”
= 完全相同
→ 复用答案

“退款多久到账？”
≈ “钱什么时候退回来？”
→ 可能复用

语义缓存有风险：用户身份、订单、政策版本或时间不同，即使问题相似也不能直接复用。缓存Key或过滤条件必须带tenant、权限、政策版本等信息；高风险个性化答案通常不应盲目缓存。

Redis会不会断电丢数据

Redis可以配置快照或追加日志做持久化，也能做复制和高可用，但它的核心优势仍是速度。是否会丢、能丢多少、恢复多快取决于持久化和集群配置。订单、余额等权威事实通常仍放PostgreSQL/MySQL等主数据库，Redis只保存缓存或可恢复状态。

Redis = 高速共享工作台　｜　主数据库 = 权威档案室

缓存失效：政策更新后必须删除或更换旧缓存版本，否则即使RAG知识库已经更新，Redis仍可能返回旧答案。真实系统通常使用TTL、版本号和主动失效共同控制。

E11Embedding 模型选型

不能只看排行榜：最终要用自己的文档、用户问法和正确答案做召回评测。通用排行榜高，不保证在你的公司缩写和业务术语上最好。

E12完整语义检索链路

文档侧：
文档 → 切成片段 → 调Embedding API → 得到向量 → 保存原文、向量、metadata

查询侧：
用户问题 → 调同类Embedding API → 查询向量 → 向量数据库近邻搜索
→ 权限/版本过滤 → Top-k候选 → Rerank → 交给大模型回答并引用

Embedding负责做坐标　｜　向量数据库负责找附近　｜　Rerank负责精排　｜　LLM负责阅读候选并回答

本章先建立坐标与检索直觉；下一章会把真实文档怎样采集、解析、切块、写入向量数据库和持续更新完整串起来。

下一章

第04课：RAG数据工程

从原始PDF、网页和数据库开始，详细讲文档采集、解析、清洗、切块、metadata设计、向量入库、增量更新、删除和版本管理。

专题Embedding 模型与 Milvus 实战

如果你想继续弄清“具体有哪些 Embedding 模型、Milvus 内部结构、Windows 如何部署、怎样用 Python 建库和带权限检索”，请先阅读这个专题，再进入第04章。

打开专题：Embedding 模型选型与 Milvus 从部署到检索 →