Embedding 与向量检索：从语义表示到混合搜索

Embedding 模型不负责聊天。它的核心任务是把文本、图片或其他对象映射为一组数字，使语义相近的内容在向量空间中更接近。

在 RAG 中，Embedding 负责帮助系统“找到可能相关的资料”，生成模型才负责“阅读资料并回答”。

从一句话变成向量

1
2
3

“北京出差住宿上限是多少”
→ Embedding 模型
→ [0.18, -0.42, 0.77, ...]

另一句话“员工在北京住酒店最多报销多少”虽然关键词不完全相同，但语义接近，向量也可能更接近。系统可以通过余弦相似度、点积或欧氏距离寻找邻近向量。

需要注意：向量中的单个数字通常没有可直接解释的业务含义，真正有用的是向量之间的相对位置。

文档和问题必须使用兼容模型

建立索引时，文档片段会被向量化；查询时，用户问题也要进入同一个向量空间：

1
2
3

文档片段 → Embedding 模型 A → 文档向量
用户问题 → Embedding 模型 A → 查询向量
查询向量与文档向量比较距离

不同模型可能具有不同维度和空间分布。更换 Embedding 模型后，通常需要重新生成全部文档向量，不能把两套不兼容的向量直接混合比较。

向量索引保存什么

实际记录通常不只有向量：

{
  "id": "travel-policy-12-3",
  "text": "一线城市住宿标准为每人每天 800 元",
  "vector": [0.18, -0.42, 0.77],
  "metadata": {
    "documentId": "travel-policy-2025",
    "page": 12,
    "tenantId": "company-a",
    "effectiveAt": "2025-01-01"
  }
}

text 用于交给模型阅读，metadata 用于权限、时间、类型和租户过滤，vector 用于相似度搜索。只保存向量而丢失原文与来源，后续无法生成可靠引用。

关键词、向量与混合搜索

方式	擅长	容易失败的情况
关键词检索	产品编号、错误码、专有名词、精确短语	同义表达和自然语言改写
向量检索	语义相近、表达不同的问题	精确编号、非常短的关键词
混合搜索	同时利用精确词和语义	需要调权重、去重和统一评分
Reranker 重排序	对候选片段做更精细相关性判断	增加延迟和推理成本

企业知识库通常同时包含“退款政策”这类语义问题和 ERR_1042 这类精确标识，因此混合检索通常比只使用一种方式更稳。

典型流程是：

问题
→ 关键词召回 Top K
→ 向量召回 Top K
→ 合并、去重、权限过滤
→ Reranker 重排序
→ 选取少量高质量片段
→ 交给生成模型

向量数据库和搜索引擎是什么关系

“向量数据库”常被宽泛使用。工程上可以分成几类：

类型	代表方案	适合场景
专用向量系统	Qdrant、Milvus、Weaviate	大量向量、专门的相似度检索
搜索引擎兼任	Elasticsearch、OpenSearch、Infinity	关键词、过滤、向量与聚合并存
关系数据库扩展	PostgreSQL + pgvector	已有 PostgreSQL，数据规模和检索要求适中
本地或嵌入式方案	LanceDB、Chroma	学习、原型和单机应用
托管服务	Pinecone 等	希望减少基础设施运维

它们是存储和检索组件，不是完整 RAG。文档解析、切片、权限、同步、引用、评测和生成仍要由上层系统负责。

选型时优先问现有技术栈、数据规模、过滤条件、写入更新频率、延迟、可用性和运维能力，不要只比较向量数量上限。

相关官方资料：Elasticsearch 向量搜索、OpenSearch 向量搜索、pgvector。

检索质量怎么排查

当答案错误时，不要直接认定“模型不行”。先拆开链路：

文档是否被正确解析，表格和标题是否丢失。
切片是否过大、过小或切断关键上下文。
查询是否需要改写、补充同义词或拆成多个子问题。
权限和元数据过滤是否错误地排除了正确文档。
召回结果中是否已经包含答案。
重排序是否把正确片段放到了后面。
Context 是否被截断，生成模型是否忠于证据。

最重要的评测不是“向量距离看起来不错”，而是准备一批真实问题，标注正确证据，并测量 Top K 召回率、引用正确性和最终答案质量。

一句话记忆

1 2	Embedding 把语义变成坐标，向量索引寻找邻居，混合检索扩大可靠召回，Reranker 再把候选排好顺序。