SIGNAL ARCHIVE

NEO Blog

Deep Read

Embeddings 向量化

#AI#RAG#Embeddings
目录+

Embeddings 是 RAG 的基础设施之一。它解决的核心问题很简单：如何把人类语言转换成机器可以计算“语义距离”的数字表示。

它对应 Naive RAG 概述Naive RAG 讲解RAG，全称 Retrieval-Augmented Generation（检索增强生成），是过去两年大模型应用落地里最重要的工程方案之一。 如果把大模型比作一个"很聪明但记忆固定的学生"，那么 RAG 做的事情就是：先去外部资料里找答案，再带着资料回答问题。 而 Naive RAG，可以理解为最基础、最原始、也是最容易落地的一代 RAG 方案。它的结构并不复杂，但已经足够解决很多实际问题，比如企业知识库问答、内部文档检索、客服机器人、私有数据接入大模型等。 一、为什么需要 RAG 大语言模型能力很强，但存在三类核心局限。 1. 时效性有限 模型知识来自训练数据，而训练数据有截止时间。最新政策、财报、内部 SOP、个人知识库文档——这些如果没被放进训练数据，模型就无法直接回答。 2. 知识覆盖不完整 即使训练了海量语料，也不可能覆盖所有垂直领域和每家企业的内部资料。医疗、法律、金融等高门槛领域，以及内部文档、合同、产品手册、私有接口说明——模型可能"懂一点"，但不够深、不够准。 3. 幻觉问题 大模型在不知道答案时，仍可能生成一个看起来很像答案的内容——语气自信，内 离线流程里的"向量化"一步——文档被 分块RAG 分块策略详解分块（Chunking）是 RAG 离线建库的核心一步：把长文档切成大小合适、语义完整的小块，再去向量化、入库、检索。它看似简单，却几乎决定了整个系统的效果上限——本篇专门把"怎么分"讲透。 RAG 的整体流程、为什么要分块等背景，见 [[Naive RAG 概述]]；这里默认你已了解基本范式，直接聚焦分块策略本身。 一、为什么分块质量决定 RAG 上限 即使用最强的大模型、最精心的 Prompt，分块不当依然会让问答系统出现： - 上下文缺失、关键信息被切散； - 事实性错误、拼接不连贯； - 检索到无关片段，进而诱发幻觉或错误引用。 根因往往是同一个误区：按固定长度硬切，无视标题、段落、列表、表格等语义边界。一个定义、一个条件、一段因果，被拦腰截断后，向量化和检索都会失真。 因此，高质量分块要同时照顾三件事： 贴合自然语义 / 结构边界**，不在句子或语义中间硬切； 设置适度重叠（overlap）**，缓解块与块之间的断裂； 保留元数据（metadata）**，如章节路径、块类型，以支持可追溯性与重排。 一句话目标：在"上下文完整性"与"信息密度"之间取得动态平衡—之后，正是靠 Embedding 转成向量才得以检索。

一、Embeddings 向量化是什么

在数学里，向量（Vector）是一个由多个数值组成的有序数组，可以理解为一个点在高维空间中的坐标。

在 RAG 场景中，向量化就是把一句话、一个段落，甚至一个文档切片，转换成一个固定维度的数值数组。一个文本块对应一个向量，例如：

  • [0.8, -0.3, 0.5, 0.34, 0.12, 1.78, 9.12, 2.34, -0.23, 0.5]（10 维）
  • [5, 9, ..., -0.23, 0.5]（1024 维）

维度越高，通常能表达更丰富的语义特征，但也意味着更高的存储和计算成本。

image.png

这些向量由 Embedding 模型（嵌入模型） 生成。它和大语言模型一样，底层通常基于 Transformer 架构，但目标不同：

  • 大语言模型侧重“生成下一个 token”
  • Embedding 模型侧重“压缩并表达整段文本的语义特征”

文本输入模型后，会经过分词、编码和多层特征提取，最终输出一个固定维度的句向量。这个向量本质上不是在表示“字面内容”，而是在表示语义位置：语义越接近的文本，在向量空间中的距离通常越近。

image.png

维度选择怎么理解

维度可以理解为“语义描述的精细度”：

  • 维度更高：信息承载更多，检索精度通常更好
  • 维度更低：计算更快、存储更省，但表达能力可能下降
  • 实际选择：本质是精度、延迟、成本三者之间的权衡

还有一个很关键的工程约束：

查询时使用的 Embedding 模型、向量维度，必须与建库时保持一致。

如果知识库是用某个模型生成的 1024 维向量，而查询时换成另一个模型或换成 768 维向量，那么相似度计算就会失真，检索结果也会明显变差。

二、向量相似度如何计算

文本被向量化之后，下一步就是比较“谁和谁更像”。本质上，就是在高维空间中衡量两个向量之间的距离或方向关系。

常见的三种计算方式如下：

  • 余弦相似度（Cosine Similarity）
    比较两个向量夹角的余弦值。夹角越小，方向越一致，相似度越高。
    适合关注“语义方向”而不太关心向量长度的场景，是 RAG 中最常见的方法。

  • 欧式距离（L2 Distance）
    直接计算两个向量在空间中的直线距离。距离越小，说明越相似。
    更强调绝对位置差异。

  • 点积（Dot Product）
    计算两个向量逐维相乘后的和。若向量已做归一化处理，点积和余弦相似度通常非常接近。
    在一些高性能检索系统中比较常见。

image.png

可以简单记忆为：

  • 看方向：余弦相似度
  • 看距离：欧式距离
  • 看计算效率与工程适配：点积

三、为什么 RAG 需要向量数据库

RAG 的两个核心阶段——索引 和 检索——都离不开向量：

  • 索引阶段：把大量文档切片向量化后，需要存起来
  • 检索阶段：把用户问题也向量化，再去库里找到最相似的内容

如果只靠传统数据库做精确匹配，很难高效完成大规模语义搜索。因此，向量数据库的职责就是：

  • 存储海量向量数据
  • 建立高效索引
  • 支持近似最近邻搜索（ANN）
  • 在可接受延迟下返回最相关结果

也就是说，向量数据库本质上是 RAG 的“语义检索引擎”。

image.png

四、主流向量数据库对比

特性PineconeMilvusChromaFaiss
核心亮点托管服务完善、开箱即用大规模分布式、性能强轻量易用、开发友好高性能向量检索库、索引丰富
开源否是是是
典型场景商业化生产环境、少运维团队企业级大规模部署本地实验、原型开发、中小项目图像检索、推荐系统、研究场景
使用形态云服务数据库/集群嵌入式向量库算法库

1. Pinecone

  • 主打托管式向量检索服务，几乎不用自己维护底层基础设施
  • 适合希望快速上线、弱化运维复杂度的团队
  • 优点是易用，缺点是闭源且成本相对更高

2. Milvus

  • 由 Zilliz 主导，面向大规模向量检索场景
  • 支持分布式部署、混合搜索和高吞吐检索
  • 更适合企业级生产环境，尤其是数据量大、并发高的场景

3. Chroma

  • 轻量、简单，和 LangChain、LlamaIndex 等生态集成较顺手
  • 很适合做本地知识库、小型 RAG Demo、快速原型验证
  • 优点是上手快，缺点是在超大规模场景下能力有限

4. Faiss

  • Meta 开源的高性能相似度搜索库
  • 强项在于大规模稠密向量搜索、索引压缩与高效近邻检索
  • 严格来说它更像“向量检索引擎/算法库”，而不是完整的数据库产品
  • 很多上层向量系统的底层能力都建立在 Faiss 之上

五、怎么选更合适

如果只做一个简单判断，可以这样理解：

  • 想快速上线、少管基础设施：Pinecone
  • 想做企业级、海量数据、分布式部署：Milvus
  • 想快速实验、本地跑通 RAG：Chroma
  • 想自己掌控底层检索能力或做研究优化：Faiss

选型时重点看四件事：

  • 数据规模有多大
  • 延迟要求有多高
  • 是否需要分布式和高可用
  • 团队更偏“业务开发”还是“底层基础设施掌控”

六、总结

Embeddings 的本质，是把文本映射到高维语义空间，让机器能够计算“语义相近”。

整个 RAG 链路可以概括为：

  1. 文本切片
  2. Embedding 向量化
  3. 向量入库建索引
  4. 查询向量化
  5. 相似度检索
  6. 召回结果交给大模型生成答案

所以，Embedding 决定“语义表达质量”，相似度算法决定“匹配方式”，向量数据库决定“检索效率与工程可落地性”。

这三者一起，构成了 RAG 检索层的核心能力。

相关笔记：Naive RAG 概述Naive RAG 讲解RAG，全称 Retrieval-Augmented Generation（检索增强生成），是过去两年大模型应用落地里最重要的工程方案之一。 如果把大模型比作一个"很聪明但记忆固定的学生"，那么 RAG 做的事情就是：先去外部资料里找答案，再带着资料回答问题。 而 Naive RAG，可以理解为最基础、最原始、也是最容易落地的一代 RAG 方案。它的结构并不复杂，但已经足够解决很多实际问题，比如企业知识库问答、内部文档检索、客服机器人、私有数据接入大模型等。 一、为什么需要 RAG 大语言模型能力很强，但存在三类核心局限。 1. 时效性有限 模型知识来自训练数据，而训练数据有截止时间。最新政策、财报、内部 SOP、个人知识库文档——这些如果没被放进训练数据，模型就无法直接回答。 2. 知识覆盖不完整 即使训练了海量语料，也不可能覆盖所有垂直领域和每家企业的内部资料。医疗、法律、金融等高门槛领域，以及内部文档、合同、产品手册、私有接口说明——模型可能"懂一点"，但不够深、不够准。 3. 幻觉问题 大模型在不知道答案时，仍可能生成一个看起来很像答案的内容——语气自信，内 · RAG 分块策略详解RAG 分块策略详解分块（Chunking）是 RAG 离线建库的核心一步：把长文档切成大小合适、语义完整的小块，再去向量化、入库、检索。它看似简单，却几乎决定了整个系统的效果上限——本篇专门把"怎么分"讲透。 RAG 的整体流程、为什么要分块等背景，见 [[Naive RAG 概述]]；这里默认你已了解基本范式，直接聚焦分块策略本身。 一、为什么分块质量决定 RAG 上限 即使用最强的大模型、最精心的 Prompt，分块不当依然会让问答系统出现： - 上下文缺失、关键信息被切散； - 事实性错误、拼接不连贯； - 检索到无关片段，进而诱发幻觉或错误引用。 根因往往是同一个误区：按固定长度硬切，无视标题、段落、列表、表格等语义边界。一个定义、一个条件、一段因果，被拦腰截断后，向量化和检索都会失真。 因此，高质量分块要同时照顾三件事： 贴合自然语义 / 结构边界**，不在句子或语义中间硬切； 设置适度重叠（overlap）**，缓解块与块之间的断裂； 保留元数据（metadata）**，如章节路径、块类型，以支持可追溯性与重排。 一句话目标：在"上下文完整性"与"信息密度"之间取得动态平衡—