：RAG 数据入库与向量数据库)
📚 本文收录于「流浪」的系列专栏
| 🐧Linux系统 | ⚙️C++ |
| 📊数据结构与算法 | 🐍Python |
| 🔗LangChain & LangGraph | 🗄️MySQL 数据库 |
| 🌿Git 工具 | 🌐计算机网络 |
| 🤖LLM | 💯大厂面试、八股 |
| 📚学习筑基专栏 |
🏠 博客主页：流浪 ｜ 📝 原创首发于 CSDN
上一篇我们把嵌入这件事讲透了：文本被转成一列数字，语义相近的对象在向量空间里靠得更近，相似度用什么距离算、模型怎么选，都是那一篇的事。向量算出来之后还面临一个很现实的问题——它得有地方放。放内存里进程一重启就没了，放普通数据库里又查不动，因为「找出最相似的十条」这种问题，传统数据库的索引结构根本答不上来。本篇接着讲知识库构建的最后一环：数据入库，也就是向量存到哪、一条记录里到底要存哪些东西。
一、数据库与数据库管理系统
1.1 数据库是存放数据的仓库，DBMS 是管理这个仓库的软件
- 数据库（Database）是存放数据的仓库，它的存储空间很大，可以存放百万条、千万条、上亿条数据，但这些数据并不是随意堆放的，存放得有规则，否则查询效率会很低。
- 数据库管理系统（DBMS）是用于管理数据库的软件，通过接口或者 SQL 这类语言来实现数据的增删改查（CRUD）。
- 两者的关系可以拿手机通讯录来对照：通讯录里实际保存的所有联系人信息（姓名、电话、地址），就像一本写满了记录的本子，这就是数据库；而手机上那个用来管理通讯录的软件（iOS 的通讯录 App 或者 Android 的联系人应用），就是 DBMS。
- 增删改查对应的就是通过这个 App 对通讯录做的四种操作：新建联系人是增，删掉过时联系人是删，把张三的号码改成新号码是改，搜索「张三」找到他的电话是查。
数据库管的是数据本身，DBMS 管的是怎么存取这些数据，两者是「仓库」和「仓库管理系统」的关系。
1.2 传统数据库擅长精确匹配，回答不了语义相似
- 传统数据库擅长的是精确匹配和范围查询，比如找出 id 等于 123 的那条记录、找出价格低于 50 的商品，支撑这些查询的是 B 树、哈希这类索引结构。
- 但「找出跟这个向量最相似的十条记录」这类问题它回答不了：语义相似没有精确边界，只能算出距离再排序，而 B 树、哈希索引不是为这种查询设计的。
- 普通数据库当然也能把向量存进去，问题在于存进去之后没法高效地做近似最近邻搜索，数据量一大就只能遍历全表算距离。
数据库擅长的是「等于」「大于」这类确定性判断，而检索要的是「最像谁」这个排序问题，两者压根不是同一类查询。
二、向量数据库是什么
2.1 向量数据库专为高维向量的存储、索引和查询而设计
- 向量数据库是一种专为高效存储、索引和查询高维向量数据而设计的数据库系统，它通过将非结构化数据（文本、图像、音频、视频）转化为数值向量，实现基于语义相似性的快速查找，而非传统的关键字匹配。
- 简单说，它就是存放向量的数据库，是支撑大模型和语义搜索的核心基础设施。
- 它和传统数据库的差别不在「能不能存」，而在「能不能查得动」：向量数据库内置了专门面向向量的索引结构，这是普通数据库没有的东西。
向量数据库的专用性体现在索引上，能不能在千万、亿级向量里毫秒级返回 Top-K，全看这层索引。
三、向量数据入库
3.1 入库是把向量连同原文和元数据一起存进向量库
- 向量数据入库，指的是把非结构化数据（文本、图像等）转化成的固定长度浮点数数组，连同原始数据、元数据一起存储到向量数据库中。
- 注意这里存的不只是向量：
向量是给机器算距离用的，人要看和大模型要读的是原始文本，两者必须一起落库。
入库不是把一堆数字塞进去，是把「可计算的向量」和「可读的原文」绑成一条记录存下来。
3.2 入库首先解决的是检索效率问题
- 高效检索是最直接的原因：普通数据库无法对向量做近似最近邻搜索，而向量数据库内置了 HNSW、IVF 这类专门的索引，能在百万、亿级向量中快速找到最相似的 Top-K 个结果。
- 这个差别可以拿一件具体的事来看：警察局有一张模糊的嫌疑人照片，需要从全市 1000 万人的身份证照片库里找出最相似的 10 张脸。
- 如果这些人脸数据放在表格里，用「眼睛颜色=棕色」「鼻子高度=2.5cm」这种字段去匹配，那么另外一些长得像、但字段不完全对上的脸根本匹配不出来，因为你没法把「像」写成一条等值条件。
- 向量数据库提前把每张人脸照片转换成一个几百个数字的特征向量，输入模糊照片时也转成向量，就能在秒级内找出最相似的 Top-10，即使库里有上千万张也很快。
结构化字段只能回答「是不是」，向量才能回答「像不像」，人脸比对、语义召回这类模糊匹配天生就是向量的活。
3.3 入库还解决持久化与重复计算的问题
- 持久化管理是第二个理由：入库之后数据被持久化保存，避免每次查询都重新对所有文档做一遍 Embedding，同时还能支持增删改查和版本管理。
- 这一点可以拿手机相册来对照：照片拍完只要不删除，它就一直在，下次打开相册直接就能看，不用重新拍一遍。
- 反过来说，如果不入库，每次提问都要把整个知识库重新算一遍向量，算力成本和响应延迟都扛不住，重复 embedding 是 RAG 里最典型的浪费之一。
入库把「一次算好的向量」固化成资产，之后每次检索只需要给查询算一次向量，而不是给整个库重算。
四、入库时的典型数据结构
4.1 一条入库记录包含四个部分
一条典型的入库数据包含下面四类内容：
| 字段 | 说明 | 示例 |
|---|---|---|
| 唯一 ID | 用于快速定位和更新记录的标识符 | doc_12345_chunk_3 |
| 向量 | Embedding 模型输出的数值数组（如 768 维或 1536 维 float 列表） | [0.01015, -0.06574, -0.01490, -0.06823, …] |
| 原始文本块 | 向量对应的原文片段，最终送给大模型生成答案 | 向量数据库是一种专门存储向量并支持相似性搜索的数据库 |
| 元数据 | 来源文件、页码、时间戳、作者等，用于过滤或展示 | file 为 RAG 指南，page 为 42，author 为张三，timestamp 为 2025-03-20 |
4.2 四个字段各管一件事，少一个都会出问题
- 唯一 ID 管定位：没有它，要更新或者删除某一条就变成全表扫描，检索结果也没法稳定地对回原文档的某一块。
- 向量管检索：它是唯一参与相似度计算的部分，维度和度量方式必须和查询侧用的是同一套，否则算出来的分数没有意义。
- 原始文本块管生成：向量本身不可读，最终要喂给大模型的是原文，检索命中的是向量、真正用到的却是这段文本。
- 元数据管过滤和溯源：按部门、按时间、按文档类型缩小检索范围靠它，回答时给出处、告诉用户这条来自哪份文件第几页也靠它。
四段里向量决定能不能被检索到，原文决定能不能生成答案，元数据决定检索范围能不能收窄，缺哪一段这条记录都不完整。
五、常见的向量数据库
5.1 十款常见向量数据库一览
| 数据库 | 简介 | 官网 |
|---|---|---|
| Milvus | 为大规模相似性搜索设计的云原生向量数据库，支持 CPU/GPU 异构计算，可扩展至数十亿向量，是生产级应用的热门选择 | milvus.io |
| 腾讯云向量数据库（Tencent Cloud VectorDB） | 腾讯自研的企业级分布式向量数据库服务，可处理十亿级向量，满足毫秒级实时更新，并提供全套 AI 集成方案 | 腾讯云 |
| 火山引擎向量数据库（VikingDB） | 字节跳动旗下的高性能向量数据库，支持多模态向量化存储与检索，可实现百亿级向量的毫秒级检索 | 火山引擎 |
| 向量检索服务 DashVector | 基于阿里自研引擎 Proxima 的全托管云原生向量数据库，专为大模型、多模态检索等场景设计，可与通义千问等 AI 服务无缝集成 | 阿里云 |
| 向量检索服务 Milvus 版 | 全托管、兼容开源 Milvus 的云服务，在开源版基础上增强了稳定性和可扩展性，方便自建集群迁移上云 | 阿里云 |
| Zilliz Cloud | 由 Milvus 原厂打造的全托管 SaaS 及 BYOC 服务，提供开箱即用、深度优化的 Milvus 体验，并具备智能运维能力 | Zilliz |
| Pinecone | 全托管的无服务器向量数据库，以易用性、高性能和自动扩展能力著称，是快速上线生产应用的流行选择 | Pinecone |
| Elasticsearch | 老牌分布式搜索引擎，通过插件支持向量检索，可实现「关键词 + 语义」的混合搜索 | Elastic |
| PGVector | PostgreSQL 的开源扩展，使其原生支持向量数据类型和相似性搜索，适合希望统一操作型数据和向量数据的团队 | GitHub |
| Redis | 通过 RediSearch 模块支持向量检索，可利用其内存存储实现亚毫秒级低延迟搜索，适合高吞吐、实时性要求高的场景 | Redis |
5.2 选型看的是数据规模、运维方式与既有技术栈
- 数据规模是第一道分水岭：百万到千万级用 PostgreSQL 加 PGVector 这类扩展就够用，量级再往上、尤其是要支撑亿级向量时，就得考虑 Milvus 这类原生分布式方案。
- 运维方式是第二道：不想自己维护集群就选全托管服务（Pinecone、Zilliz Cloud 以及各家云的向量检索服务），要私有化部署就选自建开源方案（Milvus、PGVector、Redis）。
- 既有技术栈往往起决定作用：已经在用 PostgreSQL 的团队直接上 PGVector 最省事，已经在用 Elasticsearch 的直接用它的向量能力做「关键词 + 语义」混合检索，比单独再引进一套库划算。
- 还要留意索引能力的差别，专用向量库提供 HNSW、IVF 等索引和参数调优空间，扩展型方案在超大规模下的内存和延迟表现会先遇到瓶颈。
选型不是在挑「最好的库」，是在挑规模扛得住、运维接得住、和现有技术栈接得上的那一个。
六、本篇小结
- 入库是知识库构建的最后一环，前面加载、分块、嵌入三步的产出，到这一步才真正变成可检索、可持久化的资产。
- 一条入库记录里，向量管检索、原文管生成、元数据管过滤、唯一 ID 管定位，四段各司其职，少一段都不完整。
- 存进去之后就轮到用的时候了：用户提问、查询向量化、向量检索、提示词增强、大模型生成，这套流程是下一节的内容。
构建阶段到这里收尾，向量已经落库，接下来要解决的是「用户一句话进来，怎么把最相关的那几块捞出来并变成答案」。
七、文末面试题（全真题）
- RAG 为什么需要向量数据库？它和传统数据库有什么区别？
答: 核心原因是传统关系型数据库无法高效处理高维向量的相似性搜索，而检索环节恰恰要的就是这个能力。
- 传统数据库擅长精确匹配（等号、LIKE、范围查询），索引是 B 树、哈希这类结构，回答不了「跟这个向量最相似的十条是什么」。
- 向量数据库用 HNSW、IVF 等 ANN 索引，能在千万甚至亿级向量里快速返回 Top-K，复杂度远低于全表遍历。
- 除此之外它还承担了向量的增删改查、元数据存储与过滤、横向扩展和副本容错这些工程能力。
【真题·转述自 RAG 为什么需要向量数据库？它和传统数据库有什么区别？（面试鸭）】
- 入库的一条记录里要存哪些内容？为什么必须把原文一起存进去？
答: 一条记录通常包含原始文本块、它的向量、以及来源文件、页码、时间、作者这类元数据，向量本身是不可读的。
- 向量只负责相似度计算，检索命中的是向量，但要送给大模型生成答案的是可读的原文，所以原文必须一起落库。
- 元数据用于缩小检索范围和回答时给出处，比如「只在 2024 年的技术文档里检索」这种条件就靠它。
- 建库是一次性的（文档变更时增量更新），查询是每次都要做的，所以存下来的东西要同时满足检索和生成两个环节。
【真题·转述自 Vector Databases Explained: How RAG Gives AI a Memory（RAG pipeline 端到端一节）】
- HNSW 和 IVF 两种索引有什么区别？亿级规模下该选哪个？
答: HNSW 是分层可导航小世界图，查询时从上层稀疏图开始逐层收窄，召回率高、速度快；IVF 先把向量聚类分桶，查询时只搜最相关的几个桶。
- HNSW 的关键参数是 M（每个节点的邻居数，通常 16–32）和 ef（搜索时考察的候选集大小），精度高但内存开销大。
- IVF 的关键参数是 nlist（聚类数量）和 nprobe（搜索几个桶），内存占用小、适合超大规模，但精度略低于 HNSW。
- 到了亿级规模，HNSW 的内存消耗可能扛不住，这时候用 IVF 拿聚类换内存是更现实的选择。
【真题·转述自 我如何通过向量数据库实现 RAG 应用的完整解决方案（核心索引算法 HNSW 与 IVF 一节）】
- 检索时加元数据过滤，前置过滤和后置过滤有什么坑？
答: 生产环境很少做纯向量检索，通常要把 ANN 和元数据条件组合起来，而过滤放在检索前还是检索后，效果差别很大。
- 前置过滤（先按元数据筛再向量检索）会缩小候选集，导致召回率下降，该找回来的可能压根不在候选里。
- 后置过滤（先全库 ANN 再筛结果）会浪费算力，很多算出来的结果最后被直接丢掉，还会出现返回条数不足的情况。
- 成熟的向量库普遍实现了带过滤的 HNSW，把元数据约束直接嵌进图遍历过程，这是三者里更合理的做法。
【真题·转述自 Vector Database（Metadata Filtering 一节）】
- 什么规模下用 PGVector 就够了？什么时候必须上专用向量数据库？
答: PGVector 在 768 维、约 200 万向量以内配合 HNSW 索引，表现是够用的，P99 延迟可以控制在 50 毫秒以内。
- 选它的理由是团队本来就在跑 PostgreSQL，向量和关系型数据的事务一致性是白送的，运维复杂度不会增加。
- 超过 500 万向量，或者在负载下有严格延迟要求时，专用向量数据库的表现会稳定超过它。
- 判断标准不是「能不能跑」，而是规模、延迟指标和运维成本三者一起权衡。
【真题·转述自 Vector Database（When to Use pgvector Instead 一节）】
- 向量数据库怎么选？Milvus、Pinecone、PGVector 各自适合什么场景？
答: 选型看三个维度：部署形态（自建还是托管）、数据规模、以及现有技术栈。
- Milvus 开源且功能强大，支持分布式部署，适合数据量大、要求自主可控的大规模应用。
- Pinecone 是云服务，开箱即用、不需要自己运维，但要付费，适合想快速上线的团队。
- PGVector、Redis 这类是传统数据库的向量扩展，适合数据量不大、又希望在现有数据库上直接增加向量能力的场景。
【真题·转述自 RAG 为什么需要向量数据库？它和传统数据库有什么区别？（面试鸭·扩展知识：主流向量数据库的选择）】
💬 入库这一环看着只是「存进去」，实际决定了检索能不能快、答案有没有出处。你项目里用的是哪种向量库、踩过哪些索引或过滤的坑，评论区聊聊。
