向量检索与 RAG
一、基础认知：什么是向量 & 向量检索
- 向量（Embedding）
- 语义的数学表示：一串浮点数数组
- 单向、有损编码，不可还原原文
- 意义：相近语义 → 空间距离近
- 向量检索 vs 传统搜索
- 传统：关键词精确匹配（SQL/ES）
- 向量：语义相似性搜索
- 核心计算：余弦相似度 / 欧氏距离
- 核心特点
- 理解意思，不看字面
- 支持近义词、意译、跨语言
- 无统一全球标准，模型决定空间
二、文档处理：从原始文件到可向量化文本
- 非纯文本文件解析
- docx/pptx/xlsx 本质是 zip 包
- 必须专用工具提取纯文本
- 丢弃格式、XML、样式、冗余信息
- 文本分块（Chunking）
- 错误方式：按物理行、固定字符硬切
- 问题：切断语义，导致检索失效
- 正确方式：语义分块
- 按段落、句子边界切分
- 保持语义完整
- 可使用滑动窗口微调
- 分块目标
- 不长不短，适合 LLM 输入
- 语义独立，便于精准召回
三、Embedding 模型：整个系统的基石
- 模型作用
- 文本 → 向量
- 图片 → 向量
- 多模态：文本↔图片同空间映射
- 模型尺寸差异（small/base/large）
- 小模型：语义粗糙、易混淆、空间混乱
- 大模型：细粒度区分强、专业领域更准
- 决定向量库质量与检索上限
- 向量空间规则
- 不同模型 = 不同空间，不可混用
- 入库模型 = 查询模型，必须一致
- 维度必须统一（512/768/1024）
- 主流模型类别
- 文本专用：BGE / GTE / E5 / OpenAI Embedding
- 多模态：CLIP（文搜图核心）
四、向量数据库：存储与检索结构
- 存储内容（三元组）
- 向量：用于相似度检索
- 文本片段 chunk：给 LLM 使用
- 元数据：来源、页码、行号、偏移
- 向量是否足够？
- 向量不能还原原文
- chunk 绝对不能删
- 原始文档可删（无需二次解析）
- 检索方式
- 粗检索：定位段落/行
- 细检索：定位半句/跨行/中间片段
- 混合检索：向量 + 关键词（精确到词）
- 数据量级与存储
- 向量本身极小（百万条仅几GB）
- 占空间的是文本 chunk
- 百万级文档约需 300GB~500GB 空间
五、检索深度能力：定位与可解释性
- 基础定位
- 定位到：文档、段落、页码、行数
- 依靠元数据实现
- 精细定位
- 行内：上半句 / 后半句 / 中间句
- 跨行：上下行拼接语义片段
- 方式：二次滑动窗口 + 细粒度匹配
- 为什么搜到这一段？（可解释性）
- 向量本身是黑盒，不自带依据
- 方案：Token 贡献度分析
- 遮词→相似度下降→判断核心词
- 支持近义词、语义关联归因
六、多模态检索：用文字搜图片原理
- 核心模型：CLIP 类多模态模型
- 两个编码器：文本编码器 + 图像编码器
- 同空间训练：语义对齐
- 建库流程
- 图片 → 图像向量 → 入库
- 查询流程
- 文字 → 文本向量 → 检索
- 原理与文本 RAG 完全一致
- 只是“chunk”从文本变成图片
- 无分块问题，一张图一个语义单元
七、RAG 完整工作流程（核心主线）
- 离线构建阶段
- 原始文档 → 提取纯文本
- 文本 → 语义分块 chunk
- chunk → Embedding 模型 → 向量
- 向量 + chunk + 元数据 → 向量库
- 在线问答阶段
- 用户问题 → 同一 Embedding 模型 → 查询向量
- 向量库检索 → 最相似文本片段
- 可做精细定位 + 归因分析
- 片段拼 Prompt → 送入 LLM
- LLM 生成有据可查的回答
八、关键误区与重要结论
- 误区
- 向量可以还原原文 ❌
- 不同模型向量可以混用 ❌
- 按行切分文本效果好 ❌
- 模型大小只影响速度和长度 ❌
- 核心结论
- Embedding 质量 = RAG 天花板
- 向量只负责检索，不负责存储内容
- 精细定位靠二次检索，不是向量自带
- 文搜图 = 多模态版 RAG，原理完全一致
附思维导图
向量检索与RAG全流程原理
基础认知：向量与向量检索
向量(Embedding)本质
语义的数学表示：浮点数数组
单向有损编码，不可还原原文
语义相近→空间距离相近
向量检索VS传统搜索
传统搜索：关键词精确匹配
向量检索：语义相似性搜索
核心计算：余弦相似度/欧氏距离
核心特性
理解语义而非字面
支持近义词、跨语言
无统一标准，模型决定向量空间
文档处理：原始文件到Chunk
非纯文本文档解析
docx/pptx/xlsx本质为zip压缩包
专用工具提取纯文本
丢弃格式、XML、冗余信息
文本分块(Chunking)
错误方式：按物理行、固定字符硬切
问题：语义断裂，检索失效
正确方式：语义分块
按段落、句子边界切分
保证语义完整
滑动窗口辅助优化
分块目标
适配LLM输入长度
语义独立，提升召回精度
Embedding模型：系统核心基石
模型核心作用
文本转向量
图片转向量
多模态：图文同空间映射
模型尺寸差异
小模型：语义粗糙、易混淆、空间混乱
大模型：细粒度区分强、专业领域精准
尺寸决定检索上限与向量库价值
向量空间铁律
不同模型=不同空间，禁止混用
入库模型=查询模型，必须一致
向量维度必须统一
主流模型分类
文本模型：BGE/GTE/E5/OpenAI Embedding
多模态模型：CLIP(文搜图核心)
向量数据库：存储与检索
存储三元结构
向量：用于相似度检索
文本Chunk：提供给LLM使用
元数据：来源、页码、行号、偏移量
存储关键说明
向量不可还原原文
Chunk禁止删除
原始文档可删除
检索方式
粗检索：定位段落、行
细检索：定位半句、跨行片段
混合检索：向量+关键词(精确到词)
数据存储量级
向量本身占用空间极小
空间占用主力为文本Chunk
百万级文档总空间300GB~500GB
检索深度能力：定位与可解释
基础定位
定位文档、段落、页码、行数
依靠元数据实现
精细定位
行内：上半句/下半句/中间句
跨行：上下行拼接语义片段
实现方式：二次滑动窗口+细粒度匹配
匹配可解释性
向量为黑盒，无自带依据
方案：Token贡献度分析
遮词对比相似度，定位核心词汇
支持近义词语义归因
多模态检索：文搜图原理
核心模型：CLIP
文本编码器+图像编码器
同源训练，共享向量空间
离线建库流程
图片→图像向量→存入向量库
在线查询流程
文字→文本向量→向量检索
与文本RAG关系
原理完全一致
图片天然为一个Chunk，无分块问题
RAG完整工作流程
离线构建阶段
原始文档→提取纯文本
纯文本→语义分块生成Chunk
Chunk→Embedding模型→向量
向量+Chunk+元数据→入库
在线问答阶段
用户问题→同一模型→查询向量
向量库相似度检索
精细定位+归因分析(可选)
Chunk拼接Prompt→送入LLM
LLM生成有据可依的回答
关键误区与核心结论
常见误区
向量可还原原文❌
不同模型向量可混用❌
按行切分效果更好❌
模型大小只影响速度长度❌
核心结论
Embedding质量=RAG系统天花板
向量仅负责检索，不负责内容存储
精细定位依靠二次检索实现
文搜图为多模态版本RAG，原理同源