@Al_Grigor: 不要默认从一开始就在RAG项目中使用向量搜索。先使用文本搜索。更简单：- 无需嵌入模型 ……

不要默认从向量搜索开始一个 RAG 项目。

先从文本搜索开始。

它更简单：

• 不需要嵌入模型
• 不需要向量数据库
• 不需要额外的查询时编码步骤
• 依赖更少
• 调试更容易

向量搜索在用户用不同词语表达相同含义时很有用。

例如：

“Can I still join the course?” 或 “Can I still enroll in the program?”

这些句子在语义上很接近，但词汇搜索可能因为词语不重叠而漏掉关联。

这正是嵌入能帮助的地方，但它们也带来了额外开销。

你需要对数据集进行编码、存储向量、对每个查询进行编码、选择搜索后端，并评估改进是否值得。

我的原则：

1. 先用文本搜索构建版本 1
2. 然后评估
   • 如果向量搜索带来了有意义的改进，再加入它。
   • 如果改进很小，那么增加的复杂性可能不值得。

→ 查看我的研讨会录制，了解向量搜索如何融入 RAG：https://youtube.com/watch?v=BC3NsRUNEIg&t=714s

想从 LLM 基础到生产就绪的 AI 助手，只需 10 周？加入我免费的 LLM Zoomcamp，6 月 8 日开始：https://github.com/DataTalksClub/llm-zoomcamp

TL;DR

不要在你的 RAG 项目中默认使用向量搜索。先从简单的文本搜索(如 BM25)开始,只有在文本搜索无法满足需求时再引入向量搜索。

背景:LLM Zoom 课程与 RAG 实战

本次研讨是 LLM Zoom 课程的第二场活动,聚焦于 RAG(检索增强生成)的第二个模块——从文本搜索转向向量搜索。课程旨在帮助开发者构建实用的 LLM 应用,涵盖 RAG、AI Agent、部署与监控等主题。本场研讨独立成篇,即使你没有观看第一场也能理解核心概念。

课程配套代码仓库在 GitHub 上,鼓励观看者点星支持。实践环境基于 CodeSpace,已配置好 OpenAI API 密钥和 Jupyter Notebook。如果你需要从头搭建环境,可参考第一场的文档。

为什么推荐先从文本搜索开始?

向量搜索通常比文本搜索更好,但它会带来大量运维复杂性。我的建议是:永远不要从向量搜索开始,而是从文本搜索开始。

文本搜索(如 BM25、TF-IDF)基于词汇匹配:将查询分解为有意义的词,然后在文档中查找包含这些词的条目。如果用户的问题与 FAQ 文档的用词完全不同,文本搜索就会失效。例如:

• 用户查询:“我刚发现这个项目,还能注册吗?”
• FAQ 文档:“我刚发现这门课,还能加入吗?”

虽然语义完全相同,但用词完全不同(“发现” vs “发现”,“项目” vs “课程”,“注册” vs “加入”)。文本搜索无法匹配这种词汇差异,但它实现简单、资源消耗低,适合作为起点。

向量搜索(语义搜索)能解决上述问题,但需要引入嵌入模型、向量存储等额外组件,增加了开发和运维成本。因此,先以文本搜索起步,当发现明显的语义缺口时,再逐步迁移到向量搜索。

文本搜索 vs 向量搜索

在 RAG 流程中,用户问题先被发送到搜索引擎(文本或向量),返回最相关的文档(如 top-5),然后与问题一起构造 prompt 发送给 LLM,最终生成答案。

向量搜索的原理:嵌入与语义相似性

向量搜索的核心是 嵌入(Embedding)——将文本(词、句子、文档)映射为高维空间中的一组数字(向量)。语义相近的文本,其向量在空间中距离更近。

从 Word2Vec 到句子嵌入

Word2Vec 是经典示例:词“enroll”和“join”的向量在空间中的距离很小,而与“docker”的距离很远。对于句子,我们使用 句子嵌入模型(如 Sentence Transformers)将整个句子转换为一个向量。

例如:

• Q1:“我刚发现这门课,还能加入吗?”
• Q2:“我刚发现这个项目,还能注册吗?”

这两个句子的向量在空间中非常接近,而“如何在 Windows 上运行 Docker?”的向量则远离它们。

搜索过程

1. 将 FAQ 中的每个文档通过嵌入模型转换为向量,存入向量索引。
2. 用户提问时,将问题也转为向量。
3. 在向量索引中找出与问题向量最接近的文档(如 top-5),返回作为候选。

这就是语义搜索的基本思想。它不关心具体的词汇,而是关注含义。

如何实现向量搜索:环境与工具

环境搭建

在课程中,我们为本次模块单独创建了一个 CodeSpace,因为向量搜索需要安装较重的依赖。基本步骤:

1. 克隆仓库,创建 CodeSpace。
2. 安装依赖:首先安装 uv(Python 包管理器),然后执行 uv add sentence-transformers。这个命令会下载 PyTorch、CUDA 等库,总大小超过 0.5GB。这是因为 Sentence Transformers 底层依赖于 PyTorch 运行神经网络。
3. 如果你希望更轻量,可以在生产环境中使用更小的模型或优化部署(后文会提及)。

使用 Sentence Transformers

我们选择了一个小型模型(约 80MB),以便在实验环境中快速运行。导入并加载模型:

from sentence_transformers import SentenceTransformer
model = SentenceTransformer('all-MiniLM-L6-v2')  # 小模型,速度快

将文档和查询转换为向量的方法很简单:

documents = [
    "我刚发现这门课,还能加入吗?",
    "如何在 Windows 上运行 Docker?"
]
doc_embeddings = model.encode(documents)
query = "我刚发现这个项目,还能注册吗?"
query_embedding = model.encode(query)

然后通过余弦相似度等指标找到最匹配的文档。

下一步:在生产中轻量化

虽然 Sentence Transformers 及其依赖很重,但你可以通过以下方式减小生产环境体积:

• 使用 ONNX 转换后的模型。
• 利用专门的计算服务(如托管嵌入 API)。
• 使用更小的模型(例如只有几十 MB)。

实践建议

1. 从文本搜索开始:搭建 BM25 或 TF-IDF 搜索引擎,确保基本功能正常。
2. 评估不足之处:收集用户提问,观察是否有大量语义相同但词汇不同的情况。
3. 逐步引入向量搜索:先在小范围数据上测试,确认效果提升后再迁移。
4. 选型模型:在性能与速度之间平衡,小模型(80MB)足以应对常见语义匹配,大模型(如 500MB+)可能精度更高但速度更慢。
5. 关注运维成本:向量搜索需要额外的索引维护、模型部署和 GPU 资源,在团队规模较小时尤其要谨慎。

记住:向量搜索不是万能的,文本搜索也远未过时。混合搜索(combining lexical and semantic)往往是最佳实践,但启动时请保持简单。

Source

Video: @Al_Grigor: Don’t start a RAG project with vector search by default (https://www.youtube.com/watch?v=BC3NsRUNEIg&t=714s)