向量搜索中常见的8个错误（以及如何避免它们）

1.                                                       坏掉的放大镜。图片由作者提供。

复制代码

向量搜索纸面上看起来很简单——把一些嵌入丢进数据库，查询一下，砰，结果就出来了。但一旦你从玩票项目跳进真实应用，你会很快发现这种“魔法”变成了一个充满地雷的战场——云费用爆炸、莫名其妙的幻觉、还有完全偏离目标的搜索。我见过团队在“优化”流程上耗上好几周，结果还是被同样的问题埋伏：延迟飙升、不相关的片段、还有高得不划算的成本。
下面我会分享我反复看到的八个坑——特别是在那些没有计划就扩展向量搜索的团队中。我也会给你一些实用策略帮你绕开这些坑，好让你节省时间、省下钱，还少掉点头发。

• 从一开始就忽略评估
  

你搭了一个看起来很炫的嵌入搜索系统，但很快就发现有些查询有效、有些却不行——而你不知道为啥。这就是你在没有建立评估框架（eval）的前提下贸然进入向量搜索的典型后果。你无法修正你无法衡量的东西。
该怎么做
建一个小而可靠的评估集：就算只有50到100条带标签的查询，也足以暴露巨大漏洞。
用标准指标：NDCG、MRR、recall——随便哪个都行。先从一个开始，然后慢慢精炼。
监控改进：每次你修改 chunking 或切换嵌入模型时，再跑一遍评估。
很多团队会对各种先进的 chunking 技术、“上下文检索”或者知识图谱之类感到兴奋，但根本不知道这些改动到底有没有帮助。评估能让你跳出瞎猜。

• 忽略混合搜索（Hybrid Search）
  

单靠嵌入相似度容易错过明显的关键词匹配。如果你的嵌入没有做过领域微调——或者用户查询了一个冷门词汇——系统可能就挂了。与此同时，标准关键词搜索（比如 BM25）本来可以命中的。
该怎么做
把嵌入+关键词搜索结合起来：“混合搜索”是向量和关键词结果的合体。
提升召回率：很多向量数据库都可以轻松实现这个（比如 KDB.AI 可以在同一张表里同时存 BM25 和向量索引）。
对合并结果重新排序：从两边拿到 Top N 的结果，然后交给 reranker 来决定排序。
现在越来越多团队直接跳向嵌入搜索，然后纳闷为啥一些简单查询没匹配上。没做微调的嵌入模型，在非标准数据集上经常还不如 BM25 的关键词搜索。这时候混合搜索就派上用场了——把嵌入和关键词一起用，可以在不牺牲延迟的前提下大幅提高召回率。这应该是优化向量搜索流程的第一步。
下面是混合搜索的一个示意图：

1.                                                             混合搜索图解。图片由作者提供。

复制代码

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

你很容易被某种闪亮的新检索技术吸引——而没有先建立一个明确的基线。如果你无法衡量效果，你根本不知道它到底有没有起作用。
该怎么做
先定一个基线：很好的起点通常是混合搜索 + 一个小型 reranker。
做评估：用你那套带标签的数据评估它。
一步步引入变更：看看改动之后性能是否真的提升了。
如果你的流程特别复杂（用像 LlamaIndex 这种工具非常容易搞复杂），你可能反而该从零写一个简单的 RAG 流程。
看看 LlamaIndex 上这么多 retriever！没评估你根本不知道它们到底有没有提升你的搜索效果。

1.                                       Llamaindex 检索器。图片来源：Composable Objects - LlamaIndex

复制代码

就连 late-chunking 这种简单技巧，常常只需要一点点工作量就能提升性能，也可能会让结果变得更差。但最糟糕的是：你花了好几天搞复杂方法（我常看到有人一看到新论文就说“我得试试这个”），最后发现效果还不如第一天，无论是延迟还是召回。
一定要评估，不确定的时候就简化。

• 不对嵌入进行量化
  

3k 维的嵌入模型在小规模时表现不错，但当你有几千万条数据时，内存成本就炸了。维度太高的嵌入还会让查询变慢，云账单更是吓人。
该怎么做
用量化技术：像 Matryoshka 表示学习（MRL）或者二进制量化可以在几乎无损的前提下大幅缩小嵌入。
试试 64D 或 128D：特别是当你有 2–3M 以上向量时。你可能几乎感受不到召回下降——但一定能看到成本下降。
借助 re-ranking：第一阶段的召回只需要“还行”，用更准的方法对 Top N 结果再排序即可。
考虑二进制量化：这种技术跟 MRL 等别的方法搭配起来效果也不错，但要确保你模型兼容！
我跟一些开发者聊过，他们每月花超过 100 美元养一个只有 1M 个 1536 维向量的无服务数据库。我也遇到过工程师认为搜索 PDF 就“必须”用 3000 维的嵌入。我可以跟你保证：你真的不需要。换成 64D 或 128D 后，存储和 CPU 用量少得几乎免费。如果再加上二进制量化，你能把嵌入占用的空间再减少 32 倍。
还是那句话，我们要靠评估来判断量化到什么程度不会严重掉召回。

• 大规模下不使用磁盘索引
  

当你有 5–10M+ 向量时，全放在内存里就太贵了。你可能不得不升硬件等级，或者切换到更贵的托管数据库层，仅仅是为了能把嵌入放进内存。
该怎么做
用磁盘索引：像 KDB.AI 里的 qHNSW 就能把向量存进磁盘，大幅降低内存使用。
核算你的规模：如果你预计会扩展到五千万、一亿向量，就该规划磁盘方案了。
监控延迟：现代磁盘索引意外地快，你可能几乎感受不到差别——但一定要测。比如 KDB.AI 的 qHNSW 索引吞吐量比默认 HNSW 高 3 倍，延迟还差不多。

• 不对嵌入或 reranker 做微调
  

开箱即用的嵌入（比如 OpenAI、Cohere 提供的）对于通用查询还行，但遇到专业领域就可能掉链子——比如医学术语、化学物质、或某些品牌专属词汇。
该怎么做
微调嵌入：哪怕只有 1000 条带标签的对，也能有显著提升。
微调 reranker：像 cross-encoder 或别的 reranker 往往只需要几百条例子就能发挥作用，当然越多越好。
用你的评估集：先测试一遍，再训练，训练完再测试。看看到底提升了多少。
只用一小批领域内训练样本就提升 15–25% 的召回率其实很常见。如果领域内容很重要，不做微调就是白白浪费准确率。现在微调嵌入模型和 reranker 已经越来越容易了。
这里有一篇很棒的嵌入训练博客：https://huggingface.co/blog/train-sentence-transformers

• 把向量搜索误当成真正的向量数据库
  

你很容易就把 Faiss 或 Annoy 下载下来，拼拼凑凑出一个近邻搜索，然后就觉得搞定了。但真正的生产级数据库处理的远不止原始向量查找——还包括混合搜索、并发、元数据过滤、分区等等。大多数内存向量库甚至不支持在插入数据时还能搜索。
该怎么做
选一个真正的向量数据库：像 KDB.AI 这种工具能解决数据库层面的问题，比如事务、扩展能力、高级查询。
确保支持混合搜索：现在混合搜索已经成了文本检索的标准，对实际应用场景至关重要。
支持元数据过滤：真实查询通常像是“找出这个向量附近、但必须是过去7天创建的文档。”确保你的数据库能做到这些。KDB.AI 还支持基于元数据的分区，如果你的数据与时间相关，可以大幅减少延迟！
每次数据一变就得重建索引，那根本不是事儿——但这正是你单靠 Faiss 索引时的噩梦。

• 不敢看、也不敢动你的数据
  

太多团队把他们的 chunks 或嵌入当成黑箱——“这是 AI 的活，不该管。”结果他们又总在疑惑为啥某些查询出问题，或者吐出来的结果跟鬼话一样。
该怎么做
看看你的 chunks：看看文本是怎么被切的。是不是把句子切一半了？某个关键词是不是被截断了？
手动修问题区域：如果某个 chunk 表现差，不要怕手动加个关键词或者改下描述。如果用户查询返回不了正确结果，可能你就得手动调调 chunk 的内容。
用真实反馈迭代：如果某个查询很热门但总是挂，赶紧改一下让相关 chunk 把关键词提上去。有时候最简单的办法就是直接改数据。
关键点
向量数据库不是啥神秘黑箱。就像你会调索引、重构关系型数据库表，你也完全可以改 chunk 文本、重命名字段、给某些部分加注释。是的，这是“手动”的，但能迅速修复很多真实问题。
最后的想法
向量搜索可以为语义查询插上翅膀，但如果你忽略了这八个坑，它也能把你炸得稀巴烂。无论你是用一百万向量做推荐系统，还是要扩展到一亿向量搭企业知识库，记住这些错误——还有应对方法：
尽早加入评估，这样才能跟踪真实进展。
用混合搜索，兼顾语义和精确匹配。
别在没有数据支撑的情况下乱搞高级 RAG 或 chunking 优化。
做量化，控制内存和账单。
大规模就该用磁盘索引——内存太贵了。
如果你的领域有特殊性，就微调嵌入或 reranker。
选完整的向量数据库，不要凑合用库。
看看你的数据——发现问题就勇敢地手动修 chunk。

直面这些问题，你就能打造一个稳定、靠谱、不炸钱包的向量搜索流程。如果你向量少于 5M，基本可以用 64D 嵌入存磁盘，压进免费的 KDB.AI 云套餐里，还能保持