1、向量数据库概述
大家好，我是你们这门课的老朋友。今天咱们聊聊向量数据库——这个在AI时代几乎绕不开的基础设施。
说实话，我第一次接触向量数据库是在2019年。当时一个推荐系统项目遇到了瓶颈：用户行为数据量上来了，但传统的协同过滤算法越来越慢，准确率也卡住了。我记得当时团队里有人提了一嘴“试试向量检索”，结果一查资料，发现市面上连像样的产品都没几个。嗯，现在回头看，那会儿真是向量数据库的蛮荒时代。
什么是向量数据库
向量数据库，说白了就是专门用来存储和检索“向量”的数据库。
那什么是向量？你可以把它理解为一串数字，比如 [0.23, -0.45, 0.67, ...]。这串数字是AI模型（比如BERT、ResNet）把原始数据——文本、图片、音频——压缩成的“数学指纹”。
举个例子：
- “猫坐在垫子上” → 模型 →
[0.12, -0.34, 0.56, ...] - “一只猫在睡觉” → 模型 →
[0.11, -0.33, 0.55, ...]
你看，这两句话的向量很接近。向量数据库的核心能力，就是快速找到“最接近”的向量——也就是语义上最相似的内容。
核心定义：向量数据库是一种专门为高维向量数据设计的数据库系统，它通过近似最近邻（ANN）算法实现毫秒级的语义检索，而不是传统的关键词精确匹配。
为什么需要向量数据库
你可能会问：传统数据库不也能存数组吗？我直接存个 FLOAT[] 不就行了？
嗯，这里有个坑。传统数据库的索引结构（B+树、哈希索引）在高维空间下会失效——这就是著名的“维度灾难”。当向量维度超过几十维（实际应用中通常是128维、768维甚至更高），传统索引的检索效率会急剧下降，甚至比全表扫描还慢。
我在项目中遇到过这个情况：用PostgreSQL存了100万条128维向量，写了个自定义函数算余弦相似度。结果呢？一次查询要跑3秒多。用户反馈说“你们这个推荐按钮是不是坏了？”——用户体验直接崩了。
向量数据库专门解决了这个问题。它使用了一系列优化技术：
- 近似最近邻（ANN）算法：比如HNSW、IVF、PQ，牺牲一点点精度换取数量级的性能提升
- 量化压缩：把高维向量压缩成更小的存储格式
- 分布式分片：把数据分散到多台机器上并行检索
- GPU加速：利用GPU的并行计算能力加速向量运算
我的经验：在选型时，别只看QPS（每秒查询数）。要关注“召回率@TopK”——也就是前K个结果里真正相关的比例。我曾经被一个号称百万QPS的产品坑过，结果召回率只有60%，业务方直接投诉“推荐的东西完全不相关”。
与传统数据库的对比
为了让你更直观地理解差异，我整理了一张对比表：
| 维度 | 传统数据库（MySQL/PostgreSQL） | 向量数据库（Milvus/Qdrant） |
|---|---|---|
| 数据模型 | 结构化数据（行、列、表） | 向量 + 标量属性（metadata） |
| 索引结构 | B+树、哈希索引 | HNSW、IVF、DiskANN |
| 查询方式 | 精确匹配、范围查询、JOIN | 近似最近邻（ANN）搜索 |
| 相似度度量 | 不支持（需自定义函数） | 余弦相似度、欧氏距离、内积 |
| 高维性能 | 维度灾难，>10维性能骤降 | 支持128~1024维，毫秒级响应 |
| 典型场景 | 用户表、订单、交易记录 | 语义搜索、推荐、图像检索 |
你想想看，传统数据库擅长的是“精确查找”——比如“找到用户ID=12345的记录”。但向量数据库擅长的是“模糊查找”——比如“找到和这张图片最像的10张图片”。这是两种完全不同的思维方式。
避坑指南：不要试图用向量数据库替代传统数据库。它们不是竞争关系，而是互补关系。我见过有人把所有数据都塞进向量数据库，结果连个简单的“按时间排序”都做不好——因为向量数据库对标量过滤的支持通常很弱。正确的做法是：向量数据库做语义检索，传统数据库做事务管理，两者通过ID关联。
核心应用场景
聊了这么多理论，咱们看看实际中向量数据库都在哪用。我挑三个最典型的场景说说。
RAG（检索增强生成）
这是目前最火的方向。大语言模型（LLM）有个硬伤：知识截止于训练数据，而且容易“幻觉”。RAG的解决思路是：先把企业文档切碎、向量化存入向量数据库；用户提问时，先检索最相关的文档片段，再把这些片段作为上下文喂给LLM。
我在做一个企业知识库项目时，就用了这个方案。客户有10万份技术文档，直接问的话，它根本不知道客户内部的产品细节。但通过向量数据库检索相关段落，准确率从40%提升到了92%。
流程大概是这样的：
- 文档 → 切片（chunking） → 向量化（embedding） → 存入向量数据库
- 用户提问 → 向量化 → 向量数据库检索Top-K → 返回相关文档片段
- 文档片段 + 原始问题 → 拼接成Prompt → 调用LLM → 生成回答
推荐系统
传统的推荐系统依赖协同过滤或内容标签，但有个问题：冷启动。新用户没有行为数据，新物品没有标签，推荐效果就很差。
向量数据库的解法是：把用户画像和物品属性都映射到同一个向量空间。比如：
- 用户浏览历史 → 用户向量
- 商品标题/图片 → 商品向量
- 推荐 = 找到与用户向量最接近的商品向量
我记得有个电商客户，用了向量数据库做“猜你喜欢”，冷启动阶段的点击率提升了3倍。原因很简单：即使没有用户行为，也能通过商品本身的语义信息做匹配。
图像检索
这个场景最直观。以图搜图——你上传一张图片，系统找到最相似的图片。背后的原理是：用卷积神经网络（CNN）把图片压缩成向量，然后去向量数据库里找邻居。
我在一个版权图片平台做过这个功能。用户上传一张截图，系统就能找到原图。当时数据量是5000万张图片，用向量数据库做检索，平均响应时间在50毫秒以内。如果用传统方法——先提取颜色直方图再比对——同样的数据量要跑几十秒。
下面这张图展示了向量数据库在三个核心场景中的位置：
这三个场景其实有一个共同点：它们都在做“语义匹配”。不管是文本、图片还是用户行为，最终都被抽象成了向量。向量数据库就是那个让“语义”变得可计算、可检索的引擎。
一句话总结：向量数据库不是银弹，但在需要“理解语义”的场景下，它是目前最高效的解决方案。选型之前，先想清楚你的业务到底需不需要语义检索——如果只是简单的标签匹配，传统数据库加个倒排索引可能更合适。