BM25加Seb挑战8B模型RAG：延迟成本双降，准确率不打折

为什么你的RAG管道又贵又慢

做文档检索或产品搜索，不少团队一上来就往技术栈里堆东西。常见组合是：摄入数据时用8B参数的嵌入模型把每个片段向量化，比如Qwen3-Embedding-8B或OpenAI embeddings，搜索时再拿它处理用户查询；向量数据库托管在外部，内存里常驻着数百兆乃至数吉字节的FP32/HNSW索引；最后再挂一个8B参数的交叉编码器重排序模型，比如Cohere Rerank，用来清洗候选结果。

这套架构跑一次查询要经历三次网络跳转。文档一有变动，向量索引就得持续维护。推理费用还要付给多家供应商，叠加起来就是所谓的“嵌入税”。

其实还有更简单的做法：候选检索交给普通的BM25，基于SQLite FTS5或Postgres FTS都行，亚毫秒级就能出结果；语义判断则交给Seb做一次校准后的单次评估。延迟和成本都能大幅下降，质量却能达到甚至超过密集检索。

Seb不走自回归的思维链生成，也不需要沉重的交叉编码器服务器。一次前向传播，它能评估多达10个类型的规则问题，返回校准后的概率分布。每百万输入令牌成本只有0.021美元，输出令牌不收费。

圣经 verses RAG 基准测试：简单方案对重型方案

为了验证这个假设，我们选了一个对措辞精确性、古语词汇和细微实体区分要求极高的语料库：31,102节钦定版（KJV）圣经经文。

测试设了两个工作负载。一个是160个圣经知识问答查询，看能否从结构化记录里找到确切支持并准确作答；另一个是直接索引并搜索31,102节原始经文，不做任何预总结。

零成本即时索引对8B嵌入税

先别管查询，看看索引这31,102节经文（约105万令牌）需要付出什么。

用简单的SQLite FTS5建BM25索引，墙钟时间只要77.0毫秒，CPU时间72.3毫秒，嵌入API令牌消耗为0，成本0美元。索引就是一个轻量级的磁盘SQLite表，每月基础设施成本0美元，嵌入式SQLite或现有Postgres都能用。第一阶段查找延迟中位数0.64毫秒。

换成Qwen3-Embedding-8B生成4096维向量再存进向量数据库，情况就不一样了：要跑数分钟的批量GPU或API嵌入调用，消耗约105万输入令牌。原始FP32向量加上HNSW图约占510MB内存。托管向量数据库Pod每月费用在25到70美元以上。第一阶段查找延迟通常在80到120毫秒之间，这里面包含8B查询嵌入API调用和向量近似最近邻搜索。

160个圣经问答查询的对决

160个问题的基准测试里，原始SQLite BM25只靠关键词匹配，把正确记录排在第一位的概率只有58.8%。也就是说，naive的顶部1关键词查找在超过40%的问题上会失败。不过BM25在100%的查询中都能把真实记录放进前5名，耗时仅0.012毫秒。

这说明找候选者用不着8B嵌入模型。你需要的只是一个快速、校准过的法官，让它读这5个检索到的候选者，挑出正确的那个。

单独用Simple SQLite BM25，顶部1准确率58.8%，查询延迟中位数0.012毫秒，成本为0。而Qwen3-Embedding-8B加向量数据库再加Qwen3-Reranker-8B的API估算方案，顶部1准确率能到100%，但查询延迟中位数估计在280到390毫秒之间，每1000次查询成本在0.060到0.200美元之间，向量数据库费用还得另付。

引入Seb之后，Simple SQLite BM25加Seb同样达到100%的顶部1准确率。查询延迟中位数46.9毫秒（基于Seb服务器报告的时间），每1000次查询成本仅0.00396美元。向量数据库不需要了。

重排序原始KJV圣经经文

直接搜索31,102节原始钦定版经文时，17世纪的古语表达如“shew”、“begat”撞上现代问题，情况就复杂了。

有52个查询，未词干化的BM25前五命中里包含指定KJV经文。在这些查询中，仅靠BM25把确切经文排在第一位的概率只有48.1%。加入Seb后，单次调用评估5个候选经文，排名第一的准确率提升到80.8%，相对提升68%。这一过程中位服务器时间44.5毫秒，每1000次查询成本0.0155美元。

案例研究：WhatsDo 如何从传统检索迁移到 Seb

基准测试是一回事，生产环境搜索得应付混乱的真实世界查询。WhatsDo 是一个本地发现及预订服务平台，覆盖餐厅、咖啡馆、酒吧、酒店、健身工作室、水疗中心和公园。

迁移前：关键词/标签检索加启发式评分的瓶颈

WhatsDo 原来的搜索管道分三个阶段。先解析查询，提取关键词、类别标签、地理半径和硬过滤条件；再通过PostgreSQL文本/标签加地理检索拉取候选场所；最后用加权启发式评分器排名，依据是标签重叠、文本匹配、星级评分、评论数量和距离的手动调整混合值。

碰上只有一个意图的查询，比如“布鲁克林的披萨”，启发式打分还能应付。一旦查询带上多重约束，偶尔冒出来的标签重叠就会把排名搅乱。

举个例子，搜“适合工作的安静户外座位咖啡馆”时，一家只有次要“咖啡馆”标签、评论数上千的吵闹深夜鸡尾酒酒吧，排名可能压过真正的社区咖啡店。搜“带健身房的商务酒店”，独立健身工作室和CrossFit健身房会凭主要类别标签命中“健身房”而挤到酒店前面。搜“参观公园”，描述里提到附近公园的活动策划者和派对场地，也可能排在真正的公共公园前面。

在219个保留的生产评估查询上，传统管道的平均nDCG@5为0.852，端到端搜索延迟中位数为921毫秒。

迁移后：保留快速 lexical 检索，用批量 Seb 判断替换启发式

WhatsDo 的做法不是把数据库围绕密集向量嵌入重新架构。他们留下了快速的PostgreSQL文本/标签加地理候选检索，只在顶部候选列表上加了一个批量的Seb选择重排序器。

具体操作是把最多10个候选场所塞进一次seb_decide调用。Seb会针对“strong”、“partial”、“wrong”三个选项，返回这10个候选者的校准概率分布。WhatsDo 拿这些概率直接算出平滑的预期相关性得分：P(strong)加上0.5乘以P(partial)。

算出的得分缓存在Redis里，_ttl_为7天。要是调用超时，服务就故障开放，退回到下层的 lexical 顺序，用户的请求不会被丢掉。

前后对比结果

同样这219个查询，迁移后平均nDCG@5从0.852升到0.973。逐条看胜负，新方案赢142次、平66次、只输11次，赢率是输率的12.9倍。

延迟上，Seb每处理10个场所一批的服务器时间中位数为153毫秒，摊到每个候选者15.3毫秒。此前全流程延迟是921毫秒，两相比较提升明显。

成本账也算得清：每1000次搜索的Seb API费用为0.048美元，折合每次搜索不到0.005美分，而且不用再付向量数据库的钱。

立即迁移你的 RAG 栈

搜索栈不必自己动手重写。要是你在用Claude Code、Codex、Cursor或Antigravity这类编码代理，可以交给它们去审计现有的RAG管道、搭好冻结的评估集、估算令牌成本、接上批量Seb调用，再生成一份前后对比基准报告。

迁移的关键步骤有这么几步：先审计当前管道，分清哪些阶段该留在确定性代码或SQL/BM25里（硬结构过滤、第一阶段 lexical 候选生成就属于这类），哪些该交给Seb（密集嵌入加交叉编码器重排序、LLM作为法官的路由器、容易被偶然关键词陷阱带偏的启发式评分器）。接着构建冻结的评估 harness，把基线立起来；再估算Seb的令牌体积、延迟和成本；然后实现带缓存和故障开放机制的批量Seb重排序；最后跑“之后”基准测试，把对比图表渲染出来。

按这套架构走，昂贵的向量数据库和复杂的嵌入管道都可以甩掉，语义检索照样做得质量不错，而且更简单、更便宜、也更快。