向量数据库（Vector Database）是以向量存储、索引和相似度检索为核心能力的数据库。它能根据一个查询向量，查找距离较近的记录，并返回对应的原文或来源信息。
向量与 Embedding
向量是一组有顺序的数字。在文本检索中，Embedding 模型把文本转换成数值向量，使适合该模型任务的语义关系可以通过向量距离进行比较。
“我想养一只猫” → Embedding 模型 → [0.12, -0.38, 0.75, ...]
这里的数字仅作示意。单个维度通常不能直接解释成一个明确的词义；语义关系由整个向量共同表达。语义相近的文本，其向量通常较接近，但效果取决于模型、语言、领域和输入内容。
文档与查询必须使用兼容的嵌入空间，通常使用同一模型及其规定的文档、查询编码方式。两个模型即使输出维度相同，也不能直接混用。
如何检索
资料准备时，把文档切成适合检索的片段，生成向量，并保存片段 ID、原文或原文引用，以及标题、来源、更新时间等元数据。
查询时，把问题转换成向量，再按指定的距离度量查找最接近的若干条记录。常见度量包括余弦距离、欧氏距离和内积，应与模型的使用要求匹配。
资料 → 切分片段 → Embedding 模型 → 保存向量与来源
问题 → Embedding 模型 → 相似度检索 → 返回相关片段
例如，知识库包含以下资料：
- A：猫咪的日常喂养方法；
- B：汽车发动机维修指南；
- C：幼猫适合吃哪些食物。
搜索“刚领养的小猫怎么喂”时，语义检索可能召回 A 和 C，即使问题没有使用与标题完全相同的词。这是原理示例，不代表任何具体模型的实测结果。
为了加快大规模查询，系统可以使用近似最近邻索引，以一定的召回率换取速度。返回的 Top K 表示排名靠前的 K 条候选资料，不保证每条都相关，也不保证包含全部相关资料。
在 RAG 中的职责
在检索增强生成（RAG）中，向量数据库可以承担检索环节：
用户问题 → 检索相关资料 → 将资料和问题交给大语言模型 → 生成带来源的回答
| 组件 | 职责 |
|---|---|
| Embedding 模型 | 把文本转换成可比较的向量 |
| 向量数据库 | 保存向量和关联数据，检索候选资料 |
| 应用程序 | 处理过滤、重排、上下文组装和来源追踪 |
| 大语言模型 | 根据问题和资料组织回答 |
RAG 也可以使用全文检索、结构化查询或其他检索方式，不要求一定使用向量数据库。仅把文档存入向量数据库，还没有完成整个问答系统。
与其他查询方式的关系
| 需求 | 通常适合的查询方式 |
|---|---|
| 按订单 ID 查金额 | 结构化精确查询 |
| 统计某月全部订单数量 | 数据库聚合查询 |
| 查包含特定型号或术语的文档 | 关键词或全文检索 |
| 用不同说法寻找相近含义的资料 | 向量检索 |
| 同时考虑专有名词与语义相关性 | 关键词和向量相结合的混合检索 |
向量检索能力也可以加入既有数据库。例如 PostgreSQL 的 pgvector 扩展支持向量存储和相似度查询，因此使用向量检索不一定需要单独部署一种数据库产品。
常见产品与实现方式
向量检索既可以由专门的向量数据库提供，也可以集成在通用数据库或搜索引擎中。以下是常见产品概览，具体功能和部署支持应以所用版本的官方文档为准。
以向量检索为核心的数据库
| 产品 | 主要特点 |
|---|---|
| Chroma（官方文档） | 支持本地运行、自托管和云服务，可管理文档、向量和元数据，便于搭建检索原型。 |
| Qdrant | 支持丰富的元数据过滤、稠密与稀疏向量混合检索，可自托管或使用云服务。 |
| Milvus | 提供 Lite、Standalone 和 Distributed 部署形态，覆盖本地原型、单机服务和大规模分布式检索。 |
| Weaviate | 将对象数据和向量一起管理，支持关键词与向量混合检索及模型集成。 |
| Pinecone | 以全托管云服务为主，提供向量索引与检索，减少自行部署和维护数据库的工作。 |
现有数据库或搜索引擎的向量能力
| 产品 | 与向量检索的关系 |
|---|---|
| PostgreSQL + pgvector | pgvector 是 PostgreSQL 扩展，支持向量存储和精确、近似最近邻检索，可结合 SQL、关联查询和事务。 |
| Elasticsearch | 在全文搜索基础上提供向量检索，可结合关键词搜索构建混合检索。 |
| Redis | Redis Query Engine 提供向量搜索，也支持全文、地理位置等查询；应确认所用部署和版本具备对应能力。 |
FAISS 与数据库的区别
FAISS 是用于稠密向量相似度检索和聚类的库。它提供索引与搜索算法，但本身不提供完整数据库服务的记录管理、访问控制和多用户服务能力。应用可以使用 FAISS 构建检索系统，也需要自行补齐相应的数据管理和服务层。
如何选择
- 学习基本流程：可以从 Chroma 开始，跑通“存文档 → 生成向量 → 检索”的最小实验。
- 已有 PostgreSQL 项目：可以先评估 pgvector，利用现有数据、SQL 和运维体系。
- 需要独立检索服务：可以评估 Qdrant、Milvus、Weaviate 等，比较过滤、混合检索、扩容和运维需求。
- 希望使用托管服务：可以评估 Pinecone 或其他产品的云服务，结合数据位置、成本和服务限制选择。
- 已有全文搜索系统：可以先评估该系统的向量能力，判断是否能满足混合检索需求。
以上是评估起点，不是性能排名。实际选择应使用自己的数据、过滤条件和查询负载，测量召回率、延迟、更新成本和资源消耗。
使用边界
- 相似不等于正确：距离反映表示空间中的接近程度，不能直接当作事实正确率。
- 检索不是完整枚举：数量统计、全部记录和精确业务事实应使用能保证覆盖范围的查询。
- 来源需要保留：向量是派生表示，应关联到可读取、可追溯的原始资料。
- 内容更新需要同步：原文修改、删除或 Embedding 模型更换后，需要相应更新记录或重建向量。
- 权限需要落实到检索链路：应在资料进入模型上下文前执行访问控制，不能依靠模型自行忽略无权访问的内容。