用户想找的东西可能就是一句"如何重置密码",工程师却搭了一整套embedding加向量数据库加重排序的三件套去接它。这不是段子,是Lighthouse Newsletter作者Rafael Pierre在一篇讲RAG架构分级的文章里,给整个行业开的第一刀:大多数团队根本不需要走到向量检索那一步,先把BM25跑起来,再用数据决定要不要往上加复杂度。
五个变量,先问自己再问架构
数据新鲜度、语料稳不稳定、用户怎么提问、每天有多少查询、团队里有没有ML人手——这五件事,决定了你该停在哪一级,而不是默认往复杂那头走。
原文给出的判断线很具体:语料日变动超过10%,别碰全量预嵌入;每天查询量在1000次以下,简单方案就够;只有超过10000次/天,才值得为速度做全量优化。这三条阈值不是拍脑袋,后面每一级架构的取舍都从这里长出来。
六级架构:复杂度往上走,延迟不一定跟着涨
BM25全文检索排在第一级,延迟通常在10毫秒以内,零ML依赖,能处理"invoice #12345"这种关键词式查询,却认不出"如何优化我的代码"这种带意图的提问。第二级是查询重写:用便宜的LLM(原文用GPT-4o-mini,大约每次查询0.001美元)把用户口语化的问题改写成关键词再喂给BM25,检索部分延迟能压到50毫秒以内。
再往上是混合搜索——BM25先捞出50到100篇候选,再用embedding做重排,延迟跳到100到500毫秒,只有当你有数据证明前两级不够用,才值得往这走。
原文只讲到混合搜索的开头,完整的后三级是这样的:即时embedding现查现算,延迟200到500毫秒,适合语料变动快、想随时换模型的场景;热冷分层把常访问的文档预嵌入、长尾文档现算,延迟能压到50到100毫秒,适合十万级以上文档且访问分布高度集中;全量预嵌入全部提前算好存进向量库,延迟能到50毫秒以下,但前提是语料月变动率低于5%,查询量要撑到每天万次以上才划得来。
- 结论.架构越往后越"重",延迟却不是单调上升的——热冷分层和全量预嵌入反而比混合搜索、即时embedding更快,因为后两者本质是拿新鲜度换速度,不是拿钱换速度。
"Atlas"这个词,通用embedding会找错
原文举了个例子:假设公司内部框架叫"Atlas"。通用embedding模型在互联网语料上训练,看到"Atlas"第一反应是希腊神话或地图,和真正讲数据处理的文档算出的相似度只有0.15,基本等于没命中。换成查询重写就简单得多——用一句系统提示告诉LLM"Atlas"是内部框架,它直接把问题改写成能精确匹配的关键词,零重新训练,零重新嵌入。
这也是查询重写最被低估的地方:embedding效果不好,要重新想chunk大小、重新嵌入整个语料库、跑一遍回归测试;查询重写效果不好,改一行系统提示,当场就能测。
复杂度买来的不是效果,是回头改的成本
两周基线,比选架构更重要
原文的落地建议很朴素:没有搜索先上BM25,有了搜索先跑两到四周收集真实反馈,用户抱怨"明明有这份文档却找不到",才加查询重写;反馈是"结果凑合但不够准",才去A/B测混合搜索。每一步升级都要先拿到数据,不是先拿到预算。
这套框架的漏洞也在这里。通篇的"in my experience"没有配失败案例或对照实验,10%变动率、1000次查询这类阈值看起来精确,来源终究是一个人的经验总结,不是跨团队的复现。原文也没提一件更麻烦的事:要拿到"用户满不满意"这个数据,本身需要一套评估体系,这套体系怎么搭,比选BM25还是选向量库更难,这篇文章完全没碰。
- 风险.这套分级框架建立在纯文本、英语语境的经验之上,多语言、图表混排的检索场景是否成立,原文没有给出答案。
向量数据库和embedding API这几年被讲成RAG的标准配置,某种程度上是厂商教育市场的结果——就像当年每个人都被告知"上云"是唯一正确答案,后来才发现自建机房在很多场景下更便宜。BM25不性感,但它便宜、可解释、不会因为模型下线而逼你重跑千万级重新嵌入。这才是真正的成本,不是API账单上那几美元。
回到那句"如何重置密码"——它从头到尾都不需要一个向量数据库,只需要一个愿意先测两周再决定加什么的工程师。