别再迷信向量数据库了，90%的RAG系统都在过度工程化
60%的RAG系统，根本不需要向量数据库。
这话听着刺耳，但却是无数工程师拿真金白银砸出来的血泪教训。
现在搞AI检索，大家似乎都患上了一种火力不足恐惧症。一上来就堆Embedding、向量数据库、重排序流水线。
但说实话，你的用户可能只是想搜一句怎么重置密码。
用最复杂的架构，解决最简单的问题，这就是当下RAG圈最大的黑色幽默。
被严重低估的老古董
个人觉得，现在的开发者太迷信语义理解了。
一提到搜索，脑子里全是高维向量。但那个诞生在Embedding成为动词之前的BM25全文检索，其实被严重低估。
零API成本，延迟不到10毫秒，不用纠结分块策略，更不用管模型废弃。
很多所谓的语义搜索翻车，其实是因为用户的查询词写得太烂，模型背了黑锅。
这时候，你只需要加一层智能体查询重写。
用LLM把口语化的废话过滤掉，把怎么修bug翻译成调试，把内部黑话Atlas精准匹配。
成本每次查询只要0.001美元。不用重新索引，改改Prompt就能立刻见效。
老实讲，这招能解决大部分痛点。跳过这一步直接上向量，纯属给自己找不痛快。
向量数据库的隐形大坑
有意思的是，全量预Embedding听起来像是个完美的终局方案。
把几百万文档提前算好向量，存进数据库，查询延迟低于50毫秒。
但这背后藏着一个足以让运维人员崩溃的噩梦：模型废弃。
当OpenAI把旧版Embedding模型下架时，如果你用了全量预计算，恭喜你。
你需要重新计算几百万个文档，更新向量库，跑回归测试，处理API变更。
算力成本直接飙升到上万美元，系统还要面临停机降级。
相比之下，那些采用实时Embedding或者冷热分层的团队，只需要改一行代码，或者只重新计算20%的热点文档。
这点我不太认同那些盲目追求全量预计算的架构师，为了极致的50毫秒延迟，背上几万美元的重构成本，真的值吗？
高阶玩家的降本魔法
当然，遇到真正复杂的场景，高级玩法确实能秀操作。
比如用户问怎么读CSV、清洗数据然后画图。
这是一个包含三个意图的复杂查询。如果直接扔给大模型去重写再搜，成本高昂且效果稀烂。
Perplexity等现代Agentic RAG系统的做法，是拆解。
把复杂查询拆成三个子任务，简单的用BM25，复杂的用LLM重写。
并行处理，总成本从0.03美元直接降到0.002美元。
便宜了15倍，质量还更好。
这才是智能体检索真正该发力的地方：好钢用在刀刃上，拒绝无脑堆算力。
别做脱裤子放屁的冤大头
行业里多的是反面案例。
我见过不少团队，花了几个月时间死磕向量数据库的调优，纠结512还是1024的分块大小。
最后发现，加个查询重写就能解决90%的问题。
技术讨论的热度，远远超出了实际业务的需求。
素材里那个80/20法则非常残酷，但也极其清醒：
60%的系统停在全文检索加查询重写就够了。25%需要混合搜索。只有10%需要全量预Embedding。
别做那个为5%的问题，去构建5%解决方案的冤大头。
回归常识，选择合适的工具，才是工程学的最高境界。
当所有人都在卷更复杂的模型时，敢不敢退一步，用最简单的BM25把产品先跑通？
【锐评】：用最贵的算力搜最基础的文档，当代AI工程师的火力不足恐惧症，该治治了。
参考链接：
https://www.lighthousenewsletter.com/p/rag-is-simpler-than-you-think