向量检索与 Embedding

为什么需要向量

人类说「这段话和那段话意思相近」，计算机无法直接「理解」文字。常见做法是：用模型把文本（或图像等）映射成一个固定长度的浮点数组，即 Embedding（嵌入向量）。

• 语义相近的内容，向量在空间里距离更近（在某种距离定义下）。
• 检索时：把查询也变成向量，在库中找距离最小 / 相似度最高的点。

因此：Qdrant 存的是向量 + 可选元数据；向量一般由外部模型生成。

Embedding 从哪来

常见来源包括：

• 开源模型：如 sentence-transformers（Python）等，输出维度由模型决定（如 384、768）。
• 云 API：各厂商的文本/多模态 Embedding 接口。
• 自训模型：需与入库时同一模型、同一维度，否则无法与已有向量比较。

重要约定：同一 Collection 内，所有向量的维度必须一致，且应与建 Collection 时指定的 size 一致。

向量检索在流水线中的位置

原始数据（文档/图片…）
    → 切块/预处理
    → Embedding 模型 → 向量
    → 写入 Qdrant（可带 Payload：文件名、chunk_id…）

查询时：

用户问题 → Embedding → 查询向量 → Qdrant 搜索 top_k → 得到 Payload / 文本 → 下游（如 LLM）

新手易错点

1. 维度不一致：换模型后维度变了，必须新建 Collection 或统一维度。
2. 不同模型混用：A 模型向量与 B 模型向量不可混在同一语义空间比较。
3. 只做关键词匹配：传统 LIKE 搜不到「同义不同字」；向量检索补的是语义这一层。

下一节我们把这些落到 Qdrant 的术语上：Collection、Point、Payload。