第三章 · 向量模型与向量数据库
本章定位：前两章把文档切成了块、贴上了元数据。但块还是「文本」，计算机没法直接对文本做语义比较——你不能问数据库「和这句话意思相近的块有哪些」。Embedding（向量化）就是把文本变成数字，让计算机能算「语义相似度」；而向量数据库就是存这些数字、并能快速找相似的引擎。这两样东西是 RAG 检索的基石。
本章分两部分：
- 上篇 · 概念与原理（科普）：为什么关键词检索不够用？向量到底是什么？Embedding 模型怎么选？向量数据库的核心算法（IVF/HNSW）是什么？主流向量库怎么选型？
- 下篇 · SparkX 源码落地（实践）：SparkX 怎么管理 Embedding 模型？批量向量化怎么做的？并发与性能优化有哪些精巧设计？向量怎么存进 pgvector？重新向量化怎么处理？
上篇 · 概念与原理
一、关键词检索的困境：为什么文本匹配不够用
1. 场景：电商客服知识库的检索难题
用户在客服系统里问「东西坏了能换吗」。知识库里有一条规则写的是「商品存在质量问题，可申请免费换货」。
用关键词检索（LIKE / 全文搜索）去匹配——「东西坏了」和「质量问题」一个字都对不上，结果这条规则检索不到。
2. 关键词匹配的三个致命问题
| 问题 | 举例 |
|---|---|
| 同义词 | 用户说「东西坏了」，文档写「质量问题」「损坏」「故障」——意思一样，字完全不同 |
| 一词多义 | 「苹果」既指水果也指手机品牌，关键词匹配分不清 |
| 上下文理解 | 「连续缺勤 3 天视为旷工」——关键词检索只看字面，不理解「连续缺勤」和「旷工」的因果关系 |
3. 我们需要的是「语义检索」而不是「文本匹配」
关键词检索只看「字面是否相同」，而我们要的是「意思是否相近」。这就需要一种能表示「语义」的数学形式——向量。
💡 SparkX 的做法是双索引互补：向量检索负责「语义相近」（解决上面的同义词问题），关键词检索（tsvector）负责「精确匹配」（专有名词、编号、型号）。两者混合融合，各取所长。这是第四章的内容。
二、向量：让计算机理解语义的方式
1. 什么是向量——用坐标来表示含义
向量就是一组数字（坐标）。比如二维向量 [0.8, 0.2] 可以想象成平面上的一个点。
把词语映射成向量后，意思相近的词，向量距离也近。经典例子：
"猫" → [0.8, 0.2]
"狗" → [0.7, 0.3] ← 和"猫"很近（都是宠物）
"汽车" → [0.1, 0.9] ← 和"猫"很远（毫无关系）
2. 从二维到高维：真实的文本向量长什么样
二维只是便于画图，真实的文本向量是几百到几千维的。比如：
"退货政策" → [0.023, -0.114, 0.887, 0.451, ..., -0.033] ← 1024 个数字
每个维度代表某种「语义特征」，但具体每个维度什么含义，人类看不懂——这是模型从海量语料里学出来的隐式表示。我们不需要理解每个维度，只需要知道：整体向量代表了这段文本的语义指纹。
3. 语义相近 = 向量相近：这就是 Embedding 的核心思想
把每段文本变成一个高维向量，然后比较向量距离——距离越近，语义越相似。这就是 Embedding（嵌入）的全部核心：
用户问题 "东西坏了能换吗" → 向量 A
知识库块 "商品质量问题可换货" → 向量 B
计算 A、B 的距离 → 很近！ → 检索命中
三、Embedding 模型：文本到向量的转换器
🔒 以上为本章部分预览（约 10%）
本章剩余 90% 内容包含：关键源码逐行拆解、设计细节与工程权衡、代码示例与生产实践要点。
💡 本次展示的仅为部分预览内容（约 10%）。完整的源码深度解析包含每一个技术点的完整实现细节。点击上方按钮扫码加入知识星球，解锁全部内容。
