RAG 为什么需要向量数据库？它和传统数据库有什么区别？
这道题考的是 RAG 场景下语义检索的刚需，以及向量数据库与传统数据库的本质差异。面试官想看你能不能说清楚"大模型为什么不能光靠关键词找答案"。
我从四个方面来讲：RAG 为什么非向量不可、向量数据库的核心原理、向量数据库 vs 传统数据库对比、生产选型与趋势。
一、RAG 为什么非向量不可
先说一个场景。
用户搜"怎么退货"，知识库里有一篇文档叫"商品返还流程"。字面上一个相同字都没有，但意思完全一样。
关键词匹配行吗？ 不行。传统方案搜"退货"就只找带"退货"字样的文档，"返还"两个字直接被无视。
这暴露了 RAG 的核心需求：做语义检索，不是关键词匹配。
人类语言太灵活了。同一件事有一百种说法：
- "关闭账号" 和 "注销账户"
- "看不懂" 和 "意思不明确"
- "太贵了" 和 "价格偏高"
你没法把所有同义词、近义词都枚举完。枚举不完的。
向量数据库解决的就是这个问题。它不看你写的什么字，而是理解你表达的意思。"怎么退货"和"商品返还流程"在语义空间中距离很近，向量数据库一把就能捞出来。
这是 RAG 必须用向量数据库的第一个原因。
第二个原因：向量检索能处理语义模糊性。
用户说"手机发烫"，他想找的可能是一篇"电池过热处理指南"，也可能是一篇"CPU 性能调优"。两个意思完全不一样，但都和"手机发烫"有关。
关键词搜"发烫"只能把文档全返回，让大模型自己判断。向量检索可以根据语义相似度排序，把最相关的几篇排在前面，减少大模型的幻觉。
总结一下这节的核心：RAG 做的是语义检索，传统关键词方案覆盖不全，向量数据库靠理解"意思相近"而不是"字面一样"来解决问题。
二、向量数据库的核心原理
这一节讲技术原理，你得能说出来向量是怎么工作的。
第一步：Embedding，把文本变成向量。
文本通过一个 Embedding 模型（比如 Text2Vec、OpenAI Embedding、BGE），会被编码成一个高维向量。这个向量可以理解为一个点。
举个例子，"手机发烫"可能变成 [0.23, -0.45, 0.89, ...]，一串几百维的数字。语义相近的句子，在向量空间中距离很近；语义相差大的，距离很远。
把向量空间想象成一片海洋。每个文档是一个小岛，相关文档的岛靠在一起，不相关的离得远。检索就是给你一个坐标点，然后找最近的几个岛。
第二步：向量距离怎么算？
常用三种度量方式：
- 余弦相似度（最常用）：衡量两个向量的方向是否一致，不管长度。适合文本语义相似度场景。
- 欧氏距离：直接算两点之间的直线距离。适合几何意义明确的场景。
- 内积：结合方向和长度，适合需要考虑向量模长的场景。
RAG 场景下一般用余弦相似度，因为语义相似度主要看方向。
第三步：ANN 索引，亿级数据毫秒检索。
问题来了：暴力遍历所有向量算距离，1000 万条数据得算到天荒地老。
这时候需要 ANN（近似最近邻）索引算法。常用的是 HNSW（Hierarchical Navigable Small World）。
HNSW 的核心思想：分层 + 贪心搜索。
想象一座写字楼，有很多层。最上面几层是粗略索引，每层之间有电梯连接。你要找"商品返还流程"这篇文档：
- 从顶层出发，看哪部电梯能把你送到更接近目标的位置
- 坐电梯到下一层，继续找更近的电梯
- 一直降到最底层，精确定位
这样做的好处是：不需要遍历所有文档，从顶层粗筛到下层精找，搜索复杂度从 O(n) 降到 O(log n)。
实际场景中，HNSW 能在 1 亿条向量中做到毫秒级响应。
总结一下这节的核心：向量数据库通过 Embedding 把文本变成高维向量，用 ANN 索引实现高效检索，余弦相似度是 RAG 最常用的度量方式。
三、向量数据库 vs 传统数据库对比
这一节是重点，你得能说清楚 MySQL、Elasticsearch、向量数据库三者的区别。
MySQL / PostgreSQL：精确匹配选手
这类关系型数据库擅长的是精确查找。你有 ID、有条件，直接定位到某一行。
支持模糊匹配吗？支持。用 LIKE 或者全文索引能做一些扩展，但本质上还是基于字面匹配。
搜"退货"找不到"返还"，因为字不一样。它不理解语义。
适合场景：用户 ID 查订单、商品 ID 查库存。这种场景向量数据库反而做不了。
Elasticsearch：倒排索引 + BM25
ES 靠倒排索引加速关键词查找。文档里的每个词建立一个索引，搜"退货"就去找包含"退货"的文档。
BM25 是对 TF-IDF 的优化，能算词频和文档频率的相关性，比简单的字符串匹配智能一点。
但本质上还是数你出现了几次某个词。搜"手机发烫"，ES 会找包含"手机"和"发烫"的文档。
问题是：语义相近但措辞不同的文档，比如"电池过热"，直接被漏掉了。
ES 2023 年加了 kNN 向量检索功能，开始支持向量搜索。但它的向量能力是后来加的，不如专业向量数据库成熟。
向量数据库：语义检索专家
专门为高维向量优化的数据库。核心能力是语义相似度检索。
你把"商品返还流程"存进去，向量化。检索"怎么退货"的时候，不看字面，找的是语义最接近的文档。
同时支持向量 CRUD、过滤条件、分片副本这些工程化能力。
一句话总结区别：
MySQL 靠书号找书，ES 靠目录索引翻书，向量数据库靠理解内容找书。
四、生产选型与趋势
这一节考察工程经验，你得能根据场景给建议。
选型规模阈值
不是所有人都需要 Milvus。小团队用 pgvector 验证 MVP 完全够用。
具体怎么选：
- **数据量 10亿 → Pinecone
生产环境最佳实践：双路融合 + Rerank
现在的趋势是向量检索 + 关键词检索双路并行。
向量检索找语义相关的，关键词检索找字面匹配的。两路结果合并，再经过一个 Rerank 模型重新排序。
这样做的好处是：字面匹配的文档不会漏，语义相关的文档排前面。
很多大厂的实际方案是：向量数据库（Milvus）+ Elasticsearch + Rerank 模型。
2025-2026 趋势
传统数据库正在疯狂融合向量能力。
- PostgreSQL 靠 pgvector 已经站稳脚跟
- Elasticsearch 原生支持 kNN
- Redis 出了向量搜索模块
- MySQL 也在跟进
未来可能是这样的格局：专业向量数据库做大规模语义检索，传统数据库顺手支持小规模向量需求。
面试怎么答
基础版（直接背）
RAG 需要语义检索，关键词匹配处理不了"同一意思不同表达"的问题。向量数据库通过 Embedding 把文本编码成高维向量，计算向量距离判断相似度。传统数据库里，MySQL 做精确匹配，ES 用倒排索引和 BM25 做关键词检索，都不支持语义理解。向量数据库用 ANN 索引实现亿级毫秒检索，HNSW 是最常用的算法，余弦相似度是 RAG 最常用的距离度量。
加分版（加这些内容）
能画出示意图解释 Embedding 到向量检索的完整流程。说出来 HNSW 的分层搜索思想和 IVF 的聚类思路的区别。能根据数据规模给具体选型建议：百万以下用 pgvector，千万到亿级用 Milvus，超大规模用 Pinecone。提到生产环境向量数据库 + Elasticsearch 双路融合 + Rerank 的最佳实践。了解 2025-2026 年传统数据库融合向量能力的大趋势。
一句话总结
RAG 需要向量数据库，因为语义检索靠理解"意思相近"而非"字面一样"，传统数据库的精确匹配和倒排索引都做不到这一点。