@Al_Grigor: Don't start a RAG project with vector search by default. Start with a text search. It is simpler: - No embedding model …

Don’t start a RAG project with vector search by default.

Start with a text search.

It is simpler:

• No embedding model
• No vector database
• No extra query-time encoding step
• Fewer dependencies
• Easier debugging

Vector search is useful when users ask the same thing with different words.

For example:

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

These are semantically close, but a lexical search may miss the connection if the words don’t overlap.

That’s where embeddings help, but they also add overhead.

You need to encode the dataset, store the vectors, encode each query, choose a search backend, and evaluate whether the improvement is worth it.

My rule:

1. Build version 1 with text search
2. Then evaluate

• If vector search gives a meaningful improvement, add it.
• If the improvement is marginal, the complexity may not be worth it.

-> Use my workshop recording to learn how vector search fits into RAG: https://youtube.com/watch?v=BC3NsRUNEIg&t=714s…

Want to go from LLM basics to a production-ready AI assistant in 10 weeks? Join my free LLM Zoomcamp that starts on June 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