“猫”和”狗”在语义上很接近，但”猫”和”汽车”就差很远。人类凭直觉就能判断，计算机怎么做到？答案是把所有东西都变成一串数字——向量。
一、用猫品种理解”向量”
先不看枯燥的数学定义，我们用一个直观的例子来理解。
1.1 第一步：一个特征
假设你面前有下面这些猫，需要区分它们的品种：
你会怎么区分？最自然的想法可能是”看体型大小”。
如果我们用一个水平轴来表示体型，不同品种的猫就落在了不同的坐标点上：
光靠体型，布偶猫和缅因猫能分出来了，但缅因猫、奶牛猫和折耳猫挤在一起——一个维度不够。
1.2 第二步：再加一个特征
我们再引入毛发长短，建立一条垂直轴。现在每只猫有了两个坐标（体型 + 毛发），变成了二维空间中的一个点：
现在能区分的品种更多了：长毛 + 大块头 = 缅因猫，短毛 + 中体型 = 奶牛猫。
但还是有一些品种挤在一起。比如美国短毛猫和折耳猫，它们体型和毛发长度相近。
1.3 第三步：三维……甚至更多
再加一个维度——腿的长短。现在变成了三维空间，每个品种都是一个三维坐标点：
不断加特征：眼睛大小、尾巴长短、毛发颜色、声音大小、耳朵形状……当我们有几十甚至几百个特征维度时，几乎每个品种都能被唯一地区分出来。
1.4 从”猫”到”一切”
人类是三维生物，想象不了四维以上的空间，但我们完全可以用一串数字来表示多维特征：
这串数字，就是向量（Vector）。
核心认知：不只猫可以——一个字、一个词、一句话、一篇文档、甚至一张图片，都可以用向量记录特征。维度只是模型设计的一部分；检索质量还取决于训练数据、任务、语种和评测结果，维度更高不等于一定更好。
二、Embedding：把文字变成向量
什么是 Embedding？
Embedding（嵌入） 就是”把文字变成向量”的过程。负责这个转换的工具叫嵌入模型（Embedding Model）。
举个例子（简化版）：
输入文本: "如何预防流感？"
经过 Embedding 模型 → [0.12, -0.34, 0.78, ..., 0.05] (768 维向量)在这个 768 维空间里：
- “如何预防流感”和”流感疫苗怎么打”的向量距离很近——它们语义相关
- “如何预防流感”和”今天天气不错”的向量距离很远——它们语义不相关
这就是 RAG 检索的核心原理：把用户问题和知识库文档都向量化，然后找距离最近的。
常用 Embedding 模型
| 模型 | 特点 | 维度 | 适用场景 |
|---|---|---|---|
| OpenAI text-embedding-3-small | 托管 API，易于集成 | 1536（可缩短） | 通用原型与托管方案 |
| BGE-M3（BAAI） | 多语言、支持最长 8192 token 输入 | 1024 | 需要本地部署或多语言检索时 |
| M3E-base | 中文轻量级 | 768 | 轻量级中文应用 |
| all-MiniLM-L6-v2 | 开源轻量，本地可跑 | 384 | 快速原型开发 |
选型建议：先用你的真实查询和文档建立小型评测集，再比较召回率、延迟、成本和部署约束。中文语料可把 BGE-M3、M3E 和托管模型一起纳入候选；不要仅凭模型维度或通用排名选型。
三、向量数据库：海量向量的搜索引擎
为什么需要专门的数据库？
当向量量级增大后，逐一精确计算距离会变慢。是否需要专门的向量数据库取决于数据量、延迟目标和运维约束；已有 PostgreSQL 时，pgvector 等扩展也可能足够。
向量检索系统会使用 HNSW、IVF 等索引，在召回质量、延迟和成本之间做权衡；“毫秒级”需要结合规模、索引参数和硬件实测。
主流向量数据库速览
| 数据库 | 类型 | 适合 |
|---|---|---|
| Chroma | 轻量开源 | 快速原型、小项目、学习入门 |
| Milvus | 高性能开源 | 大规模生产环境 |
| Pinecone | 云托管 | 不想管运维的团队 |
| Qdrant | 开源，Rust 编写 | 性能敏感场景 |
| pgvector | PostgreSQL 扩展 | 已有 PG 的项目，不想引入新数据库 |
| FAISS | Meta 开源库 | 需要 GPU 加速的极致性能场景 |
入门推荐：Chroma——Python 原生调用，无需单独部署服务端，三行代码就能跑起来。
向量检索 = 相似度计算
判断两个向量是否”相似”，本质是计算它们之间的距离。常用方法：
- 余弦相似度（Cosine Similarity）：最常用，衡量方向的接近程度，值越大越相似
- 欧氏距离（Euclidean Distance）：衡量空间距离，值越小越相似
四、回到 RAG：向量如何让检索变聪明
现在我们把整条链路串起来：
准备阶段（离线）
─────────────────
① 把知识库文档切分成小段（Chunking）
② 每段用 Embedding 模型转为向量
③ 存入向量数据库
查询阶段（在线）
─────────────────
用户提问 "公司年假怎么申请？"
↓
① Embedding 模型将问题转为向量
↓
② 向量数据库搜索最接近的 Top-K 个文档向量
↓
③ 取出对应的原文片段：
- 片段 1: "员工每年享有 5 天带薪年假，需提前 3 天在 OA 系统提交申请..."
- 片段 2: "年假未休完可顺延至次年 3 月 31 日前使用..."
↓
④ 将片段 + 原问题拼接成 Prompt，发给 LLM 生成最终答案② 是关键环节之一：检索不相关会显著拉低回答质量，但分块、重排、上下文组织、模型遵循性和来源校验也同样影响最终结果。
小结
- 向量 = 一串记录特征的数字，文字、图片都可以用向量表示。
- Embedding 模型负责”文字→向量”的转换，是 RAG 的核心引擎。
- 向量数据库让海量向量的相似度搜索变得飞快。
- RAG 检索的本质是找到与用户问题向量最接近的知识库向量。
下一篇，我们进入实战——RAG 系统的核心组件清单、文本分块策略、Prompt 模板设计，以及遇到问题时怎么排查。