1、向量检索概述：什么是向量检索、为什么需要向量检索、向量检索的核心挑战

大家好，我是这次课程的主讲。在正式开始之前，我想先聊聊我自己的经历。

几年前我接手过一个推荐系统项目。用户量一上来，基于关键词的召回就开始「卡脖子」——用户搜「红色跑鞋」，结果里全是标题带「红色」和「跑鞋」的商品，但那些「酒红色复古慢跑鞋」反而排到了后面。说白了，传统检索只能做字面匹配，它理解不了语义。

后来我们换成了向量检索。效果立竿见影。但随之而来的是另一个头疼的问题：延迟上去了，服务器成本也上去了。嗯，这就是我们今天要聊的核心——精准度与延迟的平衡。

什么是向量检索

向量检索，本质上是一种基于语义的搜索方式。

它先把文本、图片、音频这些非结构化数据，通过深度学习模型转换成一组浮点数——也就是「向量」。然后，检索过程就变成了在向量空间里找「最近邻」。

举个例子：

# 一个简单的文本向量化示意（非真实模型输出）
文本A: "我今天心情很好"  →  [0.12, 0.87, -0.34, 0.56, ...]
文本B: "我今日情绪不错"  →  [0.11, 0.88, -0.33, 0.55, ...]
文本C: "今天天气很差"    →  [-0.45, 0.23, 0.78, -0.12, ...]

你看，A和B的向量很接近，因为它们语义相似。C就离得远。向量检索做的就是：给定一个查询向量，从海量向量中快速找到最相似的K个。

为什么需要向量检索

传统检索的瓶颈，我在项目里体会太深了。

关键词搜索只能处理精确匹配。你搜「苹果」，它不会给你「iPhone」或「MacBook」。模糊查询？正则？那都是治标不治本。

向量检索解决了三个关键问题：

• 语义理解：能搜出「同义词」和「近义表达」
• 多模态支持：图片搜图片、文字搜图片、语音搜视频，都能统一成向量
• 跨语言检索：中文搜英文，英文搜日文，只要向量空间对齐就行

我记得有一次，用户上传了一张模糊的沙发照片，想找同款。传统方法根本没法做。但用向量检索，我们把图片和商品图都映射到同一个向量空间，直接命中。用户反馈说「太神奇了」。

向量检索的核心挑战：精准度与延迟

好，重点来了。为什么说向量检索「好用但不好伺候」？

原因就两个词：精准度和延迟。它们是一对天生的冤家。

精准度（Recall & Precision）

精准度衡量的是「搜得准不准」。最理想的情况是暴力搜索——把库里所有向量跟查询向量算一遍距离，取Top-K。这肯定最准，但代价呢？

假设你有1000万个512维的向量。暴力搜索一次，要算1000万次余弦距离。每次距离计算是512次浮点运算。加起来就是——512亿次浮点运算。单机扛不住，延迟直接飙到秒级。

检索方式	精准度（Recall@10）	延迟（单次查询）	适用场景
暴力搜索（精确）	100%	~500ms - 2s	小数据集、离线验证
近似最近邻（ANN）	85% - 99%	~5ms - 50ms	在线服务、大规模系统

你看，暴力搜索虽然准，但延迟太高。线上业务根本没法用。所以实际生产环境里，我们用的都是近似最近邻（ANN）算法。

延迟（Latency）

延迟就是「搜得多快」。用户可没耐心等。业内有个不成文的规矩：搜索类接口，P99延迟最好控制在50ms以内。

但问题来了——你越想快，就越要牺牲精准度。为什么呢？

因为ANN算法的核心思路是「不走完全程」。它通过建立索引结构（比如树、图、哈希表），提前剪枝，只搜索一部分候选向量。剪枝越多，速度越快，但漏掉正确答案的概率也越大。

精准度与延迟的平衡：一张图看懂

下面这张图，是我自己总结的向量检索核心权衡逻辑。你可以把它当作整门课程的「导航图」。

你想想看，左边是精准度，右边是延迟。你往左走，召回率上去了，但用户等得着急。你往右走，响应快了，但搜出来的东西可能不对。

我个人习惯把这个问题拆成三个层面来思考：

1. 算法层面：选IVF、HNSW还是PQ？每种算法在精度和速度上的取舍不同。
2. 工程层面：索引怎么分片？要不要用GPU？内存够不够？
3. 业务层面：用户能接受多长的等待？召回率低于多少算「不可用」？

这三个层面，后面的章节会一个一个展开讲。今天先让大家有个整体认知。

本章小结

好，我们来捋一下今天的内容：

• 向量检索是把数据映射成向量，通过计算距离来做语义搜索
• 为什么需要它——传统检索搞不定语义、多模态、跨语言
• 核心挑战——精准度和延迟是一对矛盾，工程上必须做权衡

嗯，第一章就到这里。内容不多，但都是基础。后面的章节，我们会深入每一种算法、每一种优化手段。到时候你会发现，今天讲的这个「权衡」，会贯穿整个课程。