目录

• • 前言：RAG 学习的必经之路
  • 一、 RAG 四大核心基石
    • 1. 1. 向量数据库选型与部署
      2. 2. ETL 数据管道
      3. 3. 向量化模型
      4. 4. 检索与上下文注入
  • 二、 揭秘“心脏”：向量数据库与核心引擎
    • 1. 1. 向量维度的本质与业界标准
      2. 2. 核心检索引擎：从 B+ 树到 HNSW
      3. 3. 企业级向量数据库选型图谱
      4. 4. 关于向量数据库的底层真相
      5. 5. 选型实战：Redis Stack vs Elasticsearch 8.x
  • 三、 “庖丁解牛”：文档切片（Chunking）的艺术
    • 1. 1. 核心参数的“黄金法则”
      2. 2. 三大主流切片策略选型
      3. 3. 进阶：向量维度与切片大小的“隐藏匹配公式”
  • 四、 空间魔术师：Embedding 模型深度解析
    • 1. 1. 相似度度量算法大盘点
      2. 2. 对称 vs 非对称检索
      3. 3. 超越纯 Embedding：混合检索
  • 五、 最后一公里：在线检索与生成的标准 Pipeline
    • 1. 第一关：提问预处理引擎
      2. 第二关：向量粗排检索
      3. 第三关：模型精排提纯
      4. 第四关：上下文注入与生成

在尝试为大语言模型接入企业私有知识库时，RAG（检索增强生成）是目前最主流且有效的方案。但对于刚接触 RAG 的开发者来说，往往会被海量的新概念（如 Embedding、HNSW、Chunking、重排等）淹没。

为了帮助大家快速建立系统性的认知，本文将对 RAG 架构中的前置知识和核心概念进行一次全面的梳理与原理解析。无论你是准备技术选型，还是想深入了解底层机制，这篇“硬核”指南都能为你扫清障碍。

一、 RAG 四大核心基石

在搭建一个完整的 RAG 系统前，得先弄明白支撑它的四个核心组件。

1. 向量数据库选型与部署

传统的 MySQL 和 Redis 只能做精确的文本匹配（比如 like '%...%'），而 AI 搜索需要的是“语义相似度匹配”。为此，必须引入向量数据库。

• 主流技术栈：Milvus（企业级标配）、PgVector（基于 PostgreSQL，适合中小型项目）、Redis Stack（适合对 Redis 极度熟悉的团队），以及本系列前文提到的 Elasticsearch 8.x 等。对于本地初步测试，也可以使用基于内存的 SimpleVectorStore。

2. ETL 数据管道（文档加载与切片）

总不能把一本 500 页的 PDF 直接塞给数据库或大模型吧？

• 核心流程：需要借助工具（如 Spring AI 的 DocumentReader）去读取文件，然后用文本切片器（TokenTextSplitter）把文章切成一小段一小段的“知识块（Chunks）”，最后存入向量数据库。
• 核心难点（切片策略）：切得太大，容易超出大模型的上下文限制；切得太小，又会丢失段落前后的连贯逻辑。

3. 向量化模型

大模型本身“看不懂”汉字，它只认识数字。

• 核心作用：需要使用 Embedding 模型（例如阿里云的 text-embedding-v4 或本地部署的 BGE 模型），把几十万字的业务文档，转换为一串串多维度的浮点数数组（即向量）。

4. 检索与上下文注入

当用户提问（比如：“我们公司的退款重试机制是怎么样的？”）时，系统会执行以下标准动作：

• 第一步：将用户的问题也通过 Embedding 模型转为向量。
• 第二步：去向量数据库里查出与该问题“余弦相似度”最高的 3 段文档切片（相当于寻找私有知识的“小抄”）。
• 第三步：扩充原本的 System Prompt，拼接成类似：“你是一个技术助手，请严格基于以下【私有文档参考】来回答用户问题。参考内容：[刚才查出来的 3 段切片]”。

二、 揭秘“心脏”：向量数据库与核心引擎

1. 向量维度的本质与业界标准

在机器的视角里，自然语言最终都会被 Embedding 模型转换为高维浮点数数组。这个数组的长度就是“维度”。（在 Ja va 中，它体现为 List 或 float[]）。维度越高，对语义（情感、时态、逻辑差异）的捕捉越精确，但存储和计算成本也呈线性增长。

• 768 维（开源基准线）：由 Google BERT-base 确立的经典标准。绝大多数本地化部署、开源 Embedding 模型（如 BGE-m3、m3e-base，Ollama 的 nomic-embed-text）默认都是 768 维。适合企业内部常规知识库。
• 1024 / 2048 维（大参数模型衍生）：通常是较新的高精度开源模型使用的维度。
• 1536 维（商用 API 标杆）：由 OpenAI 确立的标准。调用云厂商 API 时最常见的维度，精度极高，但对数据库的存储空间要求也会翻倍。

2. 核心检索引擎：从 B+ 树到 HNSW

传统的 MySQL 依赖 B+ 树进行精确匹配，但这在动辄 700 多维的浮点数空间中完全失效。向量检索必须使用 ANN（近似最近邻）算法，目前业界的绝对主流是 HNSW（分层可导航小世界）。

• 运行原理：将所有向量点构建成一张“多层级的复杂图网络”。底层节点最密，越往上层节点越稀疏（类似高速公路与乡间小路）。检索时从顶层快速定位大致区域，再逐层向下精准锁定距离最近的 Top-K 个点。
• ⚠️ 避坑指南：HNSW 极其消耗 RAM（内存）！为了保证检索的毫秒级响应，这张庞大的图网络必须常驻内存。在生产环境部署向量数据库时，内存的优先级远远高于 CPU 和硬盘。

3. 企业级向量数据库选型图谱

• 流派一：传统数据库的向量化扩展（复用度高，主推）
  • pgvector：目前中小型企业极其优秀的解法。作为 PostgreSQL 插件，继承了 ACID 事务，支持“标量+向量”的混合查询。
  • Elasticsearch / Redis Stack：如果公司已有高可用的集群，直接利用其较新版本内置的向量索引能力，运维成本极低。ES 更是目前混合检索的“王者”。
• 流派二：纯血原生向量数据库（海量数据首选）
  • Milvus：全球开源标杆，采用计算与存储分离的微服务设计，适合亿级乃至百亿级的超大规模场景。但部署过重，不适合小微项目。
  • Qdrant / Chroma：近两年崛起的新锐，轻量且易于容器化部署。
• 流派三：全托管 Serverless 云服务（敏捷开发首选）
  • 阿里云 DashVector 等：无需关注底层扩容和 HNSW 内存调优，按调用量付费。适合有预算、追求极速上线的企业。

4. 关于向量数据库的底层真相

• 真相一：RAG 里的向量数据，并非“核心资产”
  初学者常把向量数据库当成 MySQL（丢了数据公司就完蛋），但实际上它的定位更像是一个 Elasticsearch（搜索引擎）。真正的唯一真实数据源（Source of Truth）是存在 OSS 或 Git 仓库里的原文件。向量数据只是“衍生索引”。就算向量库完全崩溃数据丢失，只要写个脚本重新拉取原文件过一遍切片流水线（Re-indexing），数据就能全部恢复。
• 真相二：为什么海量数据不用 Redis 做向量库？
  致命伤在于“内存成本”。Redis 底层是全内存运行，HNSW 索引加上高维浮点数极其庞大。如果文档量级达到数百万字，Redis 会迅速吃干物理内存。而像 Milvus、ES 等专门或成熟的数据库采用了 MMap（内存映射）技术，将海量向量存放在廉价的 SSD 上，仅把图索引放入内存，从而以较低成本支撑海量检索。

5. 选型实战：Redis Stack vs Elasticsearch 8.x

对于大多数 Ja va 开发者而言，在不希望额外部署全新纯向量数据库（如 Milvus）增加运维负担的前提下，直接复用生态内早已普及的 Redis Stack 或 Elasticsearch 是非常务实且合适的选择。以下是它们作为企业级向量数据库的核心维度对决：

结论：在中小规模或只追求极致低延迟的场景，Redis Stack 是个不错的轻量选择；但对于真正的企业级海量文档库，尤其是需要应对专有名词、合同编号检索时，Elasticsearch 天生支持的“向量 + BM25 混合检索”绝对是降维打击。

三、 “庖丁解牛”：文档切片（Chunking）的艺术

切片是连接“非结构化文档”与“高维向量空间”的桥梁。如果段落过长，多个知识点会被压缩进同一个向量中导致特征模糊；如果太短，又会断章取义。

1. 核心参数的“黄金法则”

• 切片大小 (Chunk Size)：
  • 通用标准：500 ~ 1000 Tokens 是业界最常用的黄金区间。
  • 短切片 (<500)：适合 FAQ、单条规则，检索极准。
  • 长切片 (>1000)：适合包含大量长程逻辑推理的复杂报告。
• 重叠区大小 (Chunk Overlap)：
  • 核心作用：像“盖瓦片”一样，用前一个切片的尾部作为后一个切片的头部，防止逻辑（如“否则”、“前提是”）在切割边界处断裂。
  • 通用标准：设定为 Chunk Size 的 10% ~ 25%。

2. 三大主流切片策略选型

1. 固定长度切片 (TokenTextSplitter)：严格按 Token 数“一刀切”。速度极快，但容易斩断核心句子，强依赖 Overlap 兜底。适合毫无格式的纯文本。
2. 结构化感知切片 (RecursiveCharacterTextSplitter -