4.2向量检索基础
本课只解决一个主问题:本单元只解决一个主问题:RAG 系统是怎么从一堆文档里找到“可能相关”的资料的?
学习目标
学完本单元后,学习者应该能够:
- 解释 Embedding 是什么。
- 理解为什么向量能表示语义相似性。
- 解释 Chunk、Top-k、相似度搜索和元数据过滤。
- 判断向量检索为什么会找错资料。
- 理解向量检索只是 RAG 的一部分。
先给直觉
传统关键词搜索更像找“字面上出现了什么词”。
向量检索更像找“意思上接近什么内容”。
比如用户问:
员工看病能报销吗?
文档里可能写的是:
医疗费用可按照公司福利政策申请 reimbursement。
关键词搜索不一定能匹配“看病”和“医疗费用”、也不一定能处理中英混合表达。
向量检索的目标是:把问题和文档片段都变成数字向量,然后比较它们在语义空间里的距离。
Embedding 是什么
Embedding 是把文本、图片或其他内容转换成一串数字。
例如一段文本可能被转换成:
[0.12, -0.08, 0.44, ...]
真实向量通常有很多维。每个数字本身不容易直接解释,但整体向量可以表示语义特征。
直觉上:
- 意思接近的文本,向量距离更近。
- 意思不相关的文本,向量距离更远。
注意:这是模型学出来的表示,不是人手写的标签。
语义空间的直觉
可以想象一个很高维的地图。
在这个地图里:
- “报销制度”和“费用申请”可能比较近。
- “Transformer Attention”和“语言模型架构”可能比较近。
- “午餐吃什么”和“向量数据库”可能比较远。
向量检索就是在这个地图里找离用户问题最近的文档片段。
类比边界:真实向量空间不是二维地图,也不是每个方向都有清楚的人类含义。地图只是帮助建立直觉。
RAG 中的向量检索流程
一个常见流程:
文档
↓
清洗
↓
切分成 Chunk
↓
生成 Embedding
↓
存入向量数据库或向量索引
用户问题
↓
生成问题 Embedding
↓
相似度搜索
↓
返回 Top-k 相关 Chunk
↓
交给 LLM 生成回答
Chunk 是什么
Chunk 是把长文档切成较小片段。
为什么要切?
因为:
- 模型上下文有限。
- 检索需要精确定位相关内容。
- 太长的文档会带来噪音。
- 太短的片段可能缺少上下文。
Chunk 切分很重要。
切得太大:
- 召回内容可能包含很多无关信息。
- 输入成本更高。
- 模型更容易被噪音干扰。
切得太小:
- 片段缺少上下文。
- 重要信息被拆散。
- 模型看不懂完整条件。
好的切分通常要尊重文档结构,比如标题、段落、条款、列表和代码块。
相似度搜索
当用户问题变成向量后,系统会找与它最接近的文档向量。
常见相似度度量包括:
- 余弦相似度
- 点积
- 欧氏距离
入门阶段不需要背公式。你只需要理解:系统在比较问题和文档片段的向量接近程度。
Top-k 是什么
Top-k 表示返回最相关的 k 个结果。
例如 Top-5:
返回相似度最高的 5 个 Chunk。
k 太小:
- 可能漏掉重要资料。
k 太大:
- 可能引入噪音。
- 成本更高。
- 模型更难判断重点。
Top-k 不是越大越好。它要结合文档质量、问题类型、重排策略和上下文预算调试。
元数据过滤
元数据是文档片段附带的信息。
例如:
- 文档类型
- 创建时间
- 作者
- 部门
- 权限级别
- 课程模块
- 语言
- 标签
元数据过滤可以先缩小搜索范围。
例子:
用户问:
请解释课程里 RAG 和微调的区别。
系统可以优先检索:
course_module = RAGcontent_type = lessonlanguage = zh
这样比在所有资料里盲搜更稳。
关键词检索还有用吗
有用。
向量检索擅长语义相似,关键词检索擅长精确匹配。
关键词检索更适合:
- 人名
- 产品型号
- 错误码
- 法条编号
- 文件名
- 精确术语
向量检索更适合:
- 语义近似问题
- 自然语言问答
- 表述不一致的资料
- 概念相关内容
很多系统会使用混合检索:关键词检索 + 向量检索 + 重排。
向量检索为什么会找错
1. 问题表达模糊
用户问:
这个怎么处理?
没有上下文,系统很难知道“这个”是什么。
2. Chunk 切分不好
答案被拆成几段,单个 Chunk 看起来不完整。
3. Embedding 模型不适合领域
通用 Embedding 未必能很好处理专业术语、代码、法律文本或多语言混合资料。
4. 文档质量差
资料本身混乱、重复、过期、互相矛盾,检索再好也会受影响。
5. Top-k 设置不合适
返回太少会漏,返回太多会乱。
6. 缺少权限过滤
系统可能检索到用户不该看的内容。这不是技术小问题,是产品事故预备役。
案例:课程知识库检索
用户问:
为什么说 Prompt 不是咒语?
系统可能执行:
- 把问题转成向量。
- 在课程文档中搜索语义相关 Chunk。
- 找到
03_prompting_collaboration/01_prompt_basics/lesson.md中相关段落。 - 同时根据元数据确认这是课程讲义。
- 返回前 3 个相关片段。
- LLM 根据片段回答,并引用课程位置。
如果只靠关键词,“咒语”可能能搜到;但如果用户问的是:
为什么提示词不是魔法?
向量检索更可能找到相同含义的内容。
常见误区
误区 1:Embedding 是把文本压缩成摘要
不是。Embedding 是向量表示,不是人类可读摘要。
误区 2:向量检索一定比关键词搜索好
不一定。精确编号、人名、错误码等场景,关键词可能更可靠。
误区 3:Top-k 越大越好
不是。更多结果也可能带来更多噪音。
误区 4:向量数据库等于 RAG
向量数据库只是存储和检索向量的组件。RAG 还需要清洗、切分、生成、引用和评估。
误区 5:找到相似内容就等于找到正确答案
相似不等于正确。检索结果还要经过重排、上下文判断和回答评估。
动手练习
拿一篇课程文档,尝试手工切分 Chunk。
要求:
- 每个 Chunk 尽量围绕一个小主题。
- 不要把标题和正文拆散。
- 不要把一个完整条件拆成两半。
- 给每个 Chunk 添加元数据:
- 模块
- 单元
- 主题
- 难度
然后思考:
- 用户会怎么问到这个 Chunk?
- 哪些关键词需要保留?
- 哪些 Chunk 容易被误检索?
检查题(自测)
- Embedding 在 RAG 中起什么作用?
- Chunk 太大和太小分别有什么问题?
- 为什么很多系统会同时使用关键词检索和向量检索?
参考答案
- Embedding 把文本转成向量,让语义相近的文本在向量空间里距离更近,从而支持"按意思找资料"的语义检索。
- Chunk 太大:一个片段混入太多无关内容,检索精度下降,还浪费上下文;太小:语义被切断,片段缺少上下文,模型难以理解。需要按文档结构切分。
- 关键词检索擅长精确匹配(术语、编号、专有名词),向量检索擅长语义相似;混合检索互补,能显著提高召回质量。
Takeaway
向量检索让 RAG 能根据语义找到相关资料,但它不是自动正确。Embedding、Chunk、Top-k、元数据和混合检索都会影响结果。RAG 的质量,往往先输赢在“找资料”这一步。