坏掉的放大镜。图片由作者提供。
向量搜索纸面上看起来很简单------把一些嵌入丢进数据库,查询一下,砰,结果就出来了。但一旦你从玩票项目跳进真实应用,你会很快发现这种"魔法"变成了一个充满地雷的战场------云费用爆炸、莫名其妙的幻觉、还有完全偏离目标的搜索。我见过团队在"优化"流程上耗上好几周,结果还是被同样的问题埋伏:延迟飙升、不相关的片段、还有高得不划算的成本。
下面我会分享我反复看到的八个坑------特别是在那些没有计划就扩展向量搜索的团队中。我也会给你一些实用策略帮你绕开这些坑,好让你节省时间、省下钱,还少掉点头发。
1. 从一开始就忽略评估
你搭了一个看起来很炫的嵌入搜索系统,但很快就发现有些查询有效、有些却不行------而你不知道为啥。这就是你在没有建立评估框架(eval)的前提下贸然进入向量搜索的典型后果。你无法修正你无法衡量的东西。
该怎么做
- 建一个小而可靠的评估集:就算只有50到100条带标签的查询,也足以暴露巨大漏洞。
- 用标准指标:NDCG、MRR、recall------随便哪个都行。先从一个开始,然后慢慢精炼。
- 监控改进:每次你修改 chunking 或切换嵌入模型时,再跑一遍评估。
很多团队会对各种先进的 chunking 技术、"上下文检索"或者知识图谱之类感到兴奋,但根本不知道这些改动到底有没有帮助。评估能让你跳出瞎猜。
2. 忽略混合搜索(Hybrid Search)
单靠嵌入相似度容易错过明显的关键词匹配。如果你的嵌入没有做过领域微调------或者用户查询了一个冷门词汇------系统可能就挂了。与此同时,标准关键词搜索(比如 BM25)本来可以命中的。
该怎么做
- 把嵌入+关键词搜索结合起来:"混合搜索"是向量和关键词结果的合体。
- 提升召回率:很多向量数据库都可以轻松实现这个(比如 KDB.AI 可以在同一张表里同时存 BM25 和向量索引)。
- 对合并结果重新排序:从两边拿到 Top N 的结果,然后交给 reranker 来决定排序。
现在越来越多团队直接跳向嵌入搜索,然后纳闷为啥一些简单查询没匹配上。没做微调的嵌入模型,在非标准数据集上经常还不如 BM25 的关键词搜索。这时候混合搜索就派上用场了------把嵌入和关键词一起用,可以在不牺牲延迟的前提下大幅提高召回率。这应该是优化向量搜索流程的第一步。
下面是混合搜索的一个示意图:
混合搜索图解。图片由作者提供。
3. 过度优化(尤其是没有评估的情况下)
你很容易被某种闪亮的新检索技术吸引------而没有先建立一个明确的基线。如果你无法衡量效果,你根本不知道它到底有没有起作用。
该怎么做
- 先定一个基线:很好的起点通常是混合搜索 + 一个小型 reranker。
- 做评估:用你那套带标签的数据评估它。
- 一步步引入变更:看看改动之后性能是否真的提升了。
如果你的流程特别复杂(用像 LlamaIndex 这种工具非常容易搞复杂),你可能反而该从零写一个简单的 RAG 流程。
看看 LlamaIndex 上这么多 retriever!没评估你根本不知道它们到底有没有提升你的搜索效果。
Llamaindex 检索器。图片来源:Composable Objects - LlamaIndex
就连 late-chunking 这种简单技巧,常常只需要一点点工作量就能提升性能,也可能会让结果变得更差。但最糟糕的是:你花了好几天搞复杂方法(我常看到有人一看到新论文就说"我得试试这个"),最后发现效果还不如第一天,无论是延迟还是召回。
一定要评估,不确定的时候就简化。
4. 不对嵌入进行量化
3k 维的嵌入模型在小规模时表现不错,但当你有几千万条数据时,内存成本就炸了。维度太高的嵌入还会让查询变慢,云账单更是吓人。
该怎么做
- 用量化技术:像 Matryoshka 表示学习(MRL)或者二进制量化可以在几乎无损的前提下大幅缩小嵌入。
- 试试 64D 或 128D:特别是当你有 2--3M 以上向量时。你可能几乎感受不到召回下降------但一定能看到成本下降。
- 借助 re-ranking:第一阶段的召回只需要"还行",用更准的方法对 Top N 结果再排序即可。
- 考虑二进制量化:这种技术跟 MRL 等别的方法搭配起来效果也不错,但要确保你模型兼容!
我跟一些开发者聊过,他们每月花超过 100 美元养一个只有 1M 个 1536 维向量的无服务数据库。我也遇到过工程师认为搜索 PDF 就"必须"用 3000 维的嵌入。我可以跟你保证:你真的不需要。换成 64D 或 128D 后,存储和 CPU 用量少得几乎免费。如果再加上二进制量化,你能把嵌入占用的空间再减少 32 倍。
还是那句话,我们要靠评估来判断量化到什么程度不会严重掉召回。
5. 大规模下不使用磁盘索引
当你有 5--10M+ 向量时,全放在内存里就太贵了。你可能不得不升硬件等级,或者切换到更贵的托管数据库层,仅仅是为了能把嵌入放进内存。
该怎么做
- 用磁盘索引:像 KDB.AI 里的 qHNSW 就能把向量存进磁盘,大幅降低内存使用。
- 核算你的规模:如果你预计会扩展到五千万、一亿向量,就该规划磁盘方案了。
- 监控延迟:现代磁盘索引意外地快,你可能几乎感受不到差别------但一定要测。比如 KDB.AI 的 qHNSW 索引吞吐量比默认 HNSW 高 3 倍,延迟还差不多。
6. 不对嵌入或 reranker 做微调
开箱即用的嵌入(比如 OpenAI、Cohere 提供的)对于通用查询还行,但遇到专业领域就可能掉链子------比如医学术语、化学物质、或某些品牌专属词汇。
该怎么做
- 微调嵌入:哪怕只有 1000 条带标签的对,也能有显著提升。
- 微调 reranker:像 cross-encoder 或别的 reranker 往往只需要几百条例子就能发挥作用,当然越多越好。
- 用你的评估集:先测试一遍,再训练,训练完再测试。看看到底提升了多少。
只用一小批领域内训练样本就提升 15--25% 的召回率其实很常见。如果领域内容很重要,不做微调就是白白浪费准确率。现在微调嵌入模型和 reranker 已经越来越容易了。
这里有一篇很棒的嵌入训练博客:huggingface.co/blog/train-...
7. 把向量搜索误当成真正的向量数据库
你很容易就把 Faiss 或 Annoy 下载下来,拼拼凑凑出一个近邻搜索,然后就觉得搞定了。但真正的生产级数据库处理的远不止原始向量查找------还包括混合搜索、并发、元数据过滤、分区等等。大多数内存向量库甚至不支持在插入数据时还能搜索。
该怎么做
- 选一个真正的向量数据库:像 KDB.AI 这种工具能解决数据库层面的问题,比如事务、扩展能力、高级查询。
- 确保支持混合搜索:现在混合搜索已经成了文本检索的标准,对实际应用场景至关重要。
- 支持元数据过滤:真实查询通常像是"找出这个向量附近、但必须是过去7天创建的文档。"确保你的数据库能做到这些。KDB.AI 还支持基于元数据的分区,如果你的数据与时间相关,可以大幅减少延迟!
每次数据一变就得重建索引,那根本不是事儿------但这正是你单靠 Faiss 索引时的噩梦。
8. 不敢看、也不敢动你的数据
太多团队把他们的 chunks 或嵌入当成黑箱------"这是 AI 的活,不该管。"结果他们又总在疑惑为啥某些查询出问题,或者吐出来的结果跟鬼话一样。
该怎么做
- 看看你的 chunks:看看文本是怎么被切的。是不是把句子切一半了?某个关键词是不是被截断了?
- 手动修问题区域:如果某个 chunk 表现差,不要怕手动加个关键词或者改下描述。如果用户查询返回不了正确结果,可能你就得手动调调 chunk 的内容。
- 用真实反馈迭代:如果某个查询很热门但总是挂,赶紧改一下让相关 chunk 把关键词提上去。有时候最简单的办法就是直接改数据。
关键点
向量数据库不是啥神秘黑箱。就像你会调索引、重构关系型数据库表,你也完全可以改 chunk 文本、重命名字段、给某些部分加注释。是的,这是"手动"的,但能迅速修复很多真实问题。
最后的想法
向量搜索可以为语义查询插上翅膀,但如果你忽略了这八个坑,它也能把你炸得稀巴烂。无论你是用一百万向量做推荐系统,还是要扩展到一亿向量搭企业知识库,记住这些错误------还有应对方法:
- 尽早加入评估,这样才能跟踪真实进展。
- 用混合搜索,兼顾语义和精确匹配。
- 别在没有数据支撑的情况下乱搞高级 RAG 或 chunking 优化。
- 做量化,控制内存和账单。
- 大规模就该用磁盘索引------内存太贵了。
- 如果你的领域有特殊性,就微调嵌入或 reranker。
- 选完整的向量数据库,不要凑合用库。
- 看看你的数据------发现问题就勇敢地手动修 chunk。
直面这些问题,你就能打造一个稳定、靠谱、不炸钱包的向量搜索流程。如果你向量少于 5M,基本可以用 64D 嵌入存磁盘,压进免费的 KDB.AI 云套餐里,还能保持 <200ms 延迟。要是某个查询出问题了,改改 chunk 可能一秒钟就搞定了。
祝你搜索愉快!