向量检索和关键词检索成本对比

很多人一开始只算了检索那一下的钱，上线后才发现账单大头在别处：文档切分、嵌入生成、索引常驻、重排、还有为了召回率反复调参的重复调用。这篇不给你一个固定结论，而是给一套把两种检索方式放在同一张表上对比的算法，让你用自己业务的数字去算，并说清什么情况下这套算法不适用。

很多人算检索成本时，只看检索那一下花了多少，等上线看账单才发现大头在别处：文档切分、嵌入生成、索引常驻、重排，还有为了把召回率提上去反复调参带来的重复调用。这篇不给固定结论，因为不同团队的数据量和查询量差别太大，固定结论搬过去必错。

下面给一套把向量检索和关键词检索放进同一张表的口径：先把花费拆成可换算的几块，再按自己的数字分层算，最后用真实查询跑一遍对照。这套算法也有不适用的时候，每个小节会点出来。

先把两边的花费拆成同一套科目

关键词检索的花费主要落在三处：索引存储、查询时的 CPU 和内存、维护词典与分词规则的人力。向量检索在这三处之外，还多出嵌入生成、向量存储与内存常驻、相似度计算。两边都有一次性建设和每次查询两类开销，混在一起算永远算不清，建议分两栏记。

延迟和成本是绑在一起的。向量检索想压延迟，常见做法是加内存或换更强的机器，这笔钱要算进检索成本，不要塞进服务器预算里假装看不见。团队里两个人算的不是同一件事，是最常见的对不上账的原因，可以到 /ai-dict/category/infra 把索引、召回、重排这些词的边界先对齐。

低查询量阶段，两边的固定成本占大头，谁的索引放得下、谁的机器起得来，谁就便宜，跟算法本身关系不大。查询量上来之后变动成本开始说话：关键词检索基本是纯计算，向量检索每次查询还要带上把用户问题转成向量的那一次调用。

第一笔是嵌入生成的重跑。换切分方式、换嵌入模型、补历史数据，都要把全量文档重算一遍，这笔钱跟查询量无关，只跟文档量有关。当前有哪些嵌入口径可选，到 /embeddings 看，估的时候按自己的文档量乘调用次数。

第二笔是调参成本。召回率不够时，常见做法是加一路检索、加重排、扩大候选集，每一步都是额外调用。第三笔是重排模型，它常常比检索本身还贵，很多人把它当成检索的附属品没单独立账。把这三笔单列出来，再来比两种检索方式才公平。

这三笔要不要摊进单次查询，取决于你的数据形态：文档几乎不变、查询模式固定，基本只付一次，可以不摊；文档每天在变，就必须按月摊，否则单次成本会被严重低估。

前面的拆分和分层都是准备，真正下结论要靠自己的一批真实查询。别用造的查询，造的查询分布跟线上差太远，算出来的单价没有参考价值。

取真实查询样本从线上抽样一批查询，覆盖高频和长尾，记录每条查询在两种方案下的耗时与调用次数
乘单价把调用次数乘以当时的单价，单价到 /official-api 和 /tools/model-cost-calculator 按当前数字算，不要用记忆里的价格
留余量两边都留出两到三成余量给召回补救和重试，再对比总价，并记录余量是怎么估的
存档并复算把结论写成一页表存档，隔一段时间用 /price-watch 看价格有没有变，变了就重算

这套流程和任务级成本对比的思路一致，更通用的版本可以在 /guides/task-level-cost-compare 看到。区别在于检索系统多出索引常驻和重排这两块，套通用模板时别忘了补上。

向量检索一定比关键词检索贵吗？

不一定。贵的是「加了多少东西」：如果只是小文档量加本地向量库，可能比维护一套关键词索引加词典更省事也更省钱。真正拉开差距的是嵌入重跑和重排调用这两笔，跟检索方式本身没有必然关系。判断标准是自己的文档量、变更频率和查询量，别照搬别人的结论。

只算每次查询的钱够不够？

不够。每次查询的钱只反映变动成本，建设期的一次性开销（嵌入生成、索引搭建）和常驻开销（内存、最低配置机器）经常是大头。做预算时至少分成三块：一次性、每月固定、每次查询。具体单价去站内按当时数字取，别用旧数据。

混合检索是不是一定更贵？

通常更贵，因为它把两边的成本叠在一起，还多了一次合并和可能的 rerank。但混合检索往往能减少「召回不到就重问」的次数，实际总花费未必更高。判断方法是看补救调用的占比：如果补救调用很多，混合反而可能更便宜；如果召回本来就够，混合就是纯加钱。