8个向量搜索的常见错误

向量搜索在纸上看起来很简单——将一些嵌入放入数据库，查询它们，然后就得到了结果。但一旦你从爱好项目跃升到实际应用，你会发现“魔法”变成了一个充满爆炸性云账单、奇怪幻觉和完全错失目标的雷区。我见过团队在“优化”的管道上花费数周时间，最终却被同样的问题埋伏：延迟飙升、不相关的片段和成本高得无法证明其合理性。

以下是我反复看到的八个陷阱——特别是那些没有计划就扩展向量搜索的团队。我还将给你实用策略来避开这些陷阱，这样你就可以节省时间、金钱和大量的压力。

1、一开始就忽略评估

为什么这是个问题

你设置了一个花哨的嵌入搜索，但很快发现有些查询失败了，而另一些则成功了——而且你不知道原因。这正是当你跳入向量搜索时没有一个适当的评估框架所发生的情况。你无法修复你无法测量的东西。

应该怎么做

• 创建一个小而可靠的评估集：即使只有50-100个带标签的查询也足以揭示巨大的差距。
• 使用标准指标：NDCG、MRR、召回率——随便什么。先从某样东西开始，然后逐步完善它。
• 监控改进情况：每次调整分块或切换嵌入时，再次运行评估。

许多团队对高级分块技术或“上下文检索”，甚至知识图谱等感到兴奋，但对这些更改是否真的有帮助一无所知。评估可以让你摆脱猜测。

2、忽略混合搜索

为什么这是个问题

仅依赖嵌入相似性可能会错过明显的关键词匹配。如果你的嵌入未针对特定领域进行调优——或者用户查询的是罕见术语——系统可能会失败。与此同时，标准的关键词搜索（如BM25）本可以捕捉到这些内容。

应该怎么做

• 结合嵌入和关键词搜索：混合搜索将基于向量和基于关键词的结果合并。
• 提高召回率：这种方法在许多向量数据库中很容易实现（例如，KDB.AI 可以在同一张表中存储 BM25 和向量索引）。
• 重新排序组合结果：返回两种方法的顶级结果，并让重排序器决定最终结果。

越来越多的团队只使用嵌入，却想知道为什么简单的查询被忽略了。未经微调的嵌入通常在非标准数据集上的表现比简单的 BM25 关键词搜索更差。这就是混合搜索发挥作用的地方——通过结合嵌入和关键词搜索，你可以大幅提高召回率而不牺牲延迟。这是改进向量搜索管道的第一步。

下面是一个混合搜索实际应用的例子：

3、过度优化（尤其是在没有评估的情况下）

为什么这是个问题

在建立明确基准之前，很容易被某些炫目的新检索技术吸引。如果你无法衡量影响，你就不会知道它是否有效。

应该怎么做

1. 设定基准：一个好的起点通常是混合搜索加上一个小的重排序器。
2. 衡量效果：在你的标注集合上进行评估。
3. 逐步引入变化：看看性能是否真正有所改善。

如果您的管道非常复杂（使用像 LlamaIndex 这样的工具很容易创建复杂的管道），您可能最好从头开始构建一个简单的 RAG 管道。

看看 LlamaIndex 中的所有检索器！如果没有评估，你永远不知道它们是否真的在工作（改善你的搜索结果）。

即使是晚分块这样的简单技术，通常可以在几乎没有工作的情况下提高性能，但也可能降低结果质量。但最糟糕的事情是你花了几天时间在复杂的方法上（我经常看到人们看到新的研究后认为“我需要尝试这个”），却发现他们的性能比第一天还差，无论是延迟还是召回率。

始终进行衡量，当不确定时，简化。

4、不量化嵌入

为什么这是个问题

3000维的嵌入在开始时可能很好用，但一旦达到数千万个嵌入，内存成本就会飙升。过度的嵌入也会减慢查询速度并增加你的云账单。

应该怎么做

• 使用量化：像 Matryoshka 表征学习（MRL）或二进制量化这样的技术可以将嵌入缩小，而损失最小。
• 尝试 64D 或 128D：特别是如果你有超过 2-3 百万个向量。你可能几乎察觉不到召回率的下降，但你会明显看到成本的下降。
• 依靠重排序：第一阶段的检索可以“足够好”，如果你用更准确的方法对前 N 个结果进行重排序。
• 考虑二进制量化：二进制量化通常与其他技术（如 MRL）很好地结合，但要确保你的模型能很好地与之配合！

我曾与开发人员交谈过，他们每月支付 100 多美元用于一个只能容纳 100 万个 1536 维向量的无服务器数据库。我还与工程师交谈过，他们认为他们需要 3000 维才能在 PDF 上获得良好的搜索。我可以向你保证，你不需要这样做。将维度切换为 64D 或 128D 可以大大减少存储和 CPU 使用量，使其变得几乎免费。如果你在此基础上使用二进制量化，你可以将嵌入使用的空间减少 32 倍。

再一次，我们的评估告诉我们我们可以量化多少而不失去太多召回率。

5、在更大规模时不使用磁盘索引

为什么这是个问题

一旦达到 5-10 百万个向量，将它们全部存储在内存中往往太昂贵。你可能被迫进入更昂贵的硬件层或更大的托管数据库层，只是为了在内存中保存你的嵌入。

应该怎么做

• 磁盘索引：像 KDB.AI 中的 qHNSW 这样的索引允许你在磁盘上存储向量，极大地减少了内存使用。
• 检查你的规模：如果你发现自己接近 50 百万或 1 亿个向量，计划使用磁盘解决方案。
• 注意延迟：现代磁盘索引出奇地快，所以你可能几乎察觉不到区别——但总是要进行测量。例如，KDB.AI 的 qHNSW 索引实际上达到了 3 倍于默认 HNSW 索引的吞吐量，同时保持了类似的延迟。

6、跳过微调（无论是嵌入还是重排序器）

为什么这是个问题

现成的嵌入（如来自 OpenAI、Cohere 的）对于通用查询非常好，但可能会错过特定领域的细微差别——比如医学术语、化学化合物或专业品牌引用。

应该怎么做

• 微调嵌入：即使只有 1000 个带标签的配对也可以产生影响。
• 微调重排序器：交叉编码器或其他重排序器通常需要的示例比你想象的要少。即使几百个配对也能产生影响，但越多越好。
• 使用你的评估集：训练前测试，训练后测试。跟踪微调带来的帮助。

使用少量特定领域的训练样本，15-25% 的召回率提升并不罕见。如果领域很重要，忽略微调就是在丢掉准确性。微调嵌入模型和重排序器正变得越来越容易。

这是一个关于训练嵌入的优秀博客：https://huggingface.co/blog/train-sentence-transformers

7、将向量搜索与完整的向量数据库混淆

为什么这是个问题

很容易下载 Faiss 或 Annoy，拼凑一个近似最近邻搜索，然后称之为结束。但生产数据库处理的远不止原始向量查找——比如混合搜索、并发、元数据过滤、分区等。大多数内存中的向量库甚至不支持在添加新数据时进行搜索。

应该怎么做

• 选择一个向量数据库：工具如 KDB.AI 解决了数据库级别的问题，如事务、扩展和高级查询。
• 确保混合搜索是选项之一：混合搜索现在是文本检索的标准，对于现实世界的应用至关重要。
• 元数据过滤：真实的查询通常会说“找到所有接近这个向量的文档，但也要在过去 7 天内创建的”。确保你的数据库能做到这一点。KDB.AI 还支持基于元数据的分区，因此如果你的数据与时间相关，你可以大大减少延迟！

每次数据发生变化时都重建索引并不是一件有趣的事——但如果你只依赖原始 Faiss 索引，这就是你面对的问题。

8、害怕查看（并编辑）你的数据

为什么这是个问题

很多团队把他们的分块或嵌入视为黑盒子——“这只是 AI 的工作。”然后他们会疑惑为什么某些查询失败或产生胡言乱语。

应该怎么做

• 检查你的分块：看看文本是如何分割的。你是否切分了句子？关键短语是否被截断？
• 手动修复问题区域：如果某个分块表现不佳，不要害怕添加关键词或改进其描述方式。如果用户的查询没有返回预期结果，也许你需要手动调整该分块的文本。
• 根据真实反馈迭代：如果一个查询很受欢迎并且不断失败，快速更新一下，使该分块突出显示正确的关键词。有时最简单的修复就是对原始数据进行小的调整。

关键见解

向量数据库不是神秘的黑盒子。就像你可以调整索引或重组关系型数据库表一样，你完全可以修改分块文本、重命名字段或注释某些部分。是的，这可能是“手动”的，但它可以快速解决实际问题。

9、结束语

向量搜索可以大幅提升语义查询，但如果忽视这八个陷阱，它也可能让你陷入困境。无论你是构建一个包含 100 万个向量的推荐系统，还是为大型企业知识库扩展到 1 亿个向量，记住这些错误和修复措施：

1. 尽早添加评估，以便跟踪实际进展。
2. 使用混合搜索，以捕捉语义和精确匹配。
3. 不要过度优化，在没有数据支持的情况下引入复杂的 RAG 或分块。
4. 量化，以控制内存和账单。
5. 使用磁盘索引，如果你正在大规模扩展——内存是昂贵的。
6. 如果领域特定性重要，微调嵌入或重排序器。
7. 采用完整的向量数据库，而不是基础库。
8. 查看你的数据——并且不要害怕手动修复分块问题。

直面这些问题，你就能迈向一个能够持续提供相关结果的向量搜索管道——而不必耗尽你的钱包。如果你的向量数量低于约 500 万个，你通常可以在磁盘上以 64D 存储嵌入，保持所有内容在免费的 KDB.AI 云层下，并且仍然获得 <200 毫秒的延迟。如果你确实看到某个查询有问题，一个简单的分块编辑可能就是解决问题所需的一切。

愉快地查询吧！

原文链接：8 Common Mistakes in Vector Search (and How to Avoid Them)

汇智网翻译整理，转载请标明出处