> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 8个向量搜索的常见错误 - URL: https://www.hubwiz.com/blog/top8-mistakes-in-vector-search/ - Published: 2025-02-16T07:05:57.000Z - Updated: 2025-02-27T10:47:34.000Z - Description: 向量搜索在纸上看起来很简单——将一些嵌入放入数据库，查询它们，然后就得到了结果。但一旦你从爱好项目跃升到实际应用，就会发现一切都变了。 - Author: admin - Tags: APPLICATION, VECTOR DATABASE, #Import 2026-10-14 14:41 向量搜索在纸上看起来很简单——将一些嵌入放入数据库，查询它们，然后就得到了结果。但一旦你从爱好项目跃升到实际应用，你会发现“魔法”变成了一个充满爆炸性云账单、奇怪幻觉和完全错失目标的雷区。我见过团队在“优化”的管道上花费数周时间，最终却被同样的问题埋伏：延迟飙升、不相关的片段和成本高得无法证明其合理性。 以下是我反复看到的八个陷阱——特别是那些没有计划就扩展向量搜索的团队。我还将给你实用策略来避开这些陷阱，这样你就可以节省时间、金钱和大量的压力。 ## 1、一开始就忽略评估 **为什么这是个问题** 你设置了一个花哨的嵌入搜索，但很快发现有些查询失败了，而另一些则成功了——而且你不知道原因。这正是当你跳入向量搜索时没有一个适当的评估框架所发生的情况。你无法修复你无法测量的东西。 **应该怎么做** - **创建一个小而可靠的评估集**：即使只有50-100个带标签的查询也足以揭示巨大的差距。 - **使用标准指标**：NDCG、MRR、召回率——随便什么。先从某样东西开始，然后逐步完善它。 - **监控改进情况**：每次调整分块或切换嵌入时，再次运行评估。 许多团队对高级分块技术或“上下文检索”，甚至知识图谱等感到兴奋，但对这些更改是否真的有帮助一无所知。评估可以让你摆脱猜测。 ## 2、忽略混合搜索 **为什么这是个问题** 仅依赖嵌入相似性可能会错过明显的关键词匹配。如果你的嵌入未针对特定领域进行调优——或者用户查询的是罕见术语——系统可能会失败。与此同时，标准的关键词搜索（如BM25）本可以捕捉到这些内容。 **应该怎么做** - **结合嵌入和关键词搜索**：混合搜索将基于向量和基于关键词的结果合并。 - **提高召回率**：这种方法在许多向量数据库中很容易实现（例如，[KDB.AI](http://kdb.ai/?ref=hubwiz.com) 可以在同一张表中存储 BM25 和向量索引）。 - **重新排序组合结果**：返回两种方法的顶级结果，并让重排序器决定最终结果。 越来越多的团队只使用嵌入，却想知道为什么简单的查询被忽略了。未经微调的嵌入通常在非标准数据集上的表现比简单的 BM25 关键词搜索更差。这就是混合搜索发挥作用的地方——通过结合嵌入和关键词搜索，你可以大幅提高召回率而不牺牲延迟。这是改进向量搜索管道的第一步。 下面是一个混合搜索实际应用的例子： ![](https://www.hubwiz.com/blog/content/images/2025/02/image-667.png) 混合搜索示意图 ## 3、过度优化（尤其是在没有评估的情况下） **为什么这是个问题** 在建立明确基准之前，很容易被某些炫目的新检索技术吸引。如果你无法衡量影响，你就不会知道它是否有效。 **应该怎么做** 1. **设定基准**：一个好的起点通常是混合搜索加上一个小的重排序器。 2. **衡量效果**：在你的标注集合上进行评估。 3. **逐步引入变化**：看看性能是否真正有所改善。 如果您的管道非常复杂（使用像 LlamaIndex 这样的工具很容易创建复杂的管道），您可能最好从头开始构建一个简单的 RAG 管道。 看看 LlamaIndex 中的所有检索器！如果没有评估，你永远不知道它们是否真的在工作（改善你的搜索结果）。 ![](https://www.hubwiz.com/blog/content/images/2025/02/image-668.png) 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](http://kdb.ai/?ref=hubwiz.com) 中的 qHNSW 这样的索引允许你在磁盘上存储向量，极大地减少了内存使用。 - **检查你的规模**：如果你发现自己接近 50 百万或 1 亿个向量，计划使用磁盘解决方案。 - **注意延迟**：现代磁盘索引出奇地快，所以你可能几乎察觉不到区别——但总是要进行测量。例如，[KDB.AI](http://kdb.ai/?ref=hubwiz.com) 的 qHNSW 索引实际上达到了 3 倍于默认 HNSW 索引的吞吐量，同时保持了类似的延迟。 ## 6、跳过微调（无论是嵌入还是重排序器） **为什么这是个问题** 现成的嵌入（如来自 OpenAI、Cohere 的）对于通用查询非常好，但可能会错过特定领域的细微差别——比如医学术语、化学化合物或专业品牌引用。 **应该怎么做** - **微调嵌入**：即使只有 1000 个带标签的配对也可以产生影响。 - **微调重排序器**：交叉编码器或其他重排序器通常需要的示例比你想象的要少。即使几百个配对也能产生影响，但越多越好。 - **使用你的评估集**：训练前测试，训练后测试。跟踪微调带来的帮助。 使用少量特定领域的训练样本，15-25% 的召回率提升并不罕见。如果领域很重要，忽略微调就是在丢掉准确性。微调嵌入模型和重排序器正变得越来越容易。 这是一个关于训练嵌入的优秀博客：[https://huggingface.co/blog/train-sentence-transformers](https://huggingface.co/blog/train-sentence-transformers?ref=hubwiz.com) ## 7、将向量搜索与完整的向量数据库混淆 **为什么这是个问题** 很容易下载 Faiss 或 Annoy，拼凑一个近似最近邻搜索，然后称之为结束。但生产数据库处理的远不止原始向量查找——比如混合搜索、并发、元数据过滤、分区等。大多数内存中的向量库甚至不支持在添加新数据时进行搜索。 **应该怎么做** - **选择一个向量数据库**：工具如 [KDB.AI](http://kdb.ai/?ref=hubwiz.com) 解决了数据库级别的问题，如事务、扩展和高级查询。 - **确保混合搜索是选项之一**：混合搜索现在是文本检索的标准，对于现实世界的应用至关重要。 - **元数据过滤**：真实的查询通常会说“找到所有接近这个向量的文档，但也要在过去 7 天内创建的”。确保你的数据库能做到这一点。[KDB.AI](http://kdb.ai/?ref=hubwiz.com) 还支持基于元数据的分区，因此如果你的数据与时间相关，你可以大大减少延迟！ 每次数据发生变化时都重建索引并不是一件有趣的事——但如果你只依赖原始 Faiss 索引，这就是你面对的问题。 ## 8、害怕查看（并编辑）你的数据 **为什么这是个问题** 很多团队把他们的分块或嵌入视为黑盒子——“这只是 AI 的工作。”然后他们会疑惑为什么某些查询失败或产生胡言乱语。 **应该怎么做** - **检查你的分块**：看看文本是如何分割的。你是否切分了句子？关键短语是否被截断？ - **手动修复问题区域**：如果某个分块表现不佳，不要害怕添加关键词或改进其描述方式。如果用户的查询没有返回预期结果，也许你需要手动调整该分块的文本。 - **根据真实反馈迭代**：如果一个查询很受欢迎并且不断失败，快速更新一下，使该分块突出显示正确的关键词。有时最简单的修复就是对原始数据进行小的调整。 **关键见解** 向量数据库不是神秘的黑盒子。就像你可以调整索引或重组关系型数据库表一样，你完全可以修改分块文本、重命名字段或注释某些部分。是的，这可能是“手动”的，但它可以快速解决实际问题。 ## 9、结束语 向量搜索可以大幅提升语义查询，但如果忽视这八个陷阱，它也可能让你陷入困境。无论你是构建一个包含 100 万个向量的推荐系统，还是为大型企业知识库扩展到 1 亿个向量，记住这些错误和修复措施： 1. **尽早添加评估**，以便跟踪实际进展。 2. **使用混合搜索**，以捕捉语义和精确匹配。 3. **不要过度优化**，在没有数据支持的情况下引入复杂的 RAG 或分块。 4. **量化**，以控制内存和账单。 5. **使用磁盘索引**，如果你正在大规模扩展——内存是昂贵的。 6. **如果领域特定性重要，微调嵌入或重排序器**。 7. **采用完整的向量数据库**，而不是基础库。 8. **查看你的数据**——并且不要害怕手动修复分块问题。 直面这些问题，你就能迈向一个能够持续提供相关结果的向量搜索管道——而不必耗尽你的钱包。如果你的向量数量低于约 500 万个，你通常可以在磁盘上以 64D 存储嵌入，保持所有内容在免费的 [KDB.AI](http://kdb.ai/?ref=hubwiz.com) 云层下，并且仍然获得 <200 毫秒的延迟。如果你确实看到某个查询有问题，一个简单的分块编辑可能就是解决问题所需的一切。 **愉快地查询吧！** --- 原文链接：[8 Common Mistakes in Vector Search (and How to Avoid Them)](https://ai.gopubby.com/8-common-mistakes-in-vector-search-and-how-to-avoid-them-e48d849c23f8?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处