最近半年我陆陆续续做了好几个 RAG 相关的项目，其中一个本地知识库问答系统上线跑了一个多月才想起来盘底账，发现检索层用的根本不是向量数据库，而是纯 BM25 加倒排索引。一开始我也是"RAG 必须先选向量库"的信徒，后来被文档规模、召回质量、还有混合检索的反馈轮番教育，才意识到一个问题：RAG 的"R"只要求可靠地检索到上下文，至于上下文是不是靠向量匹配出来的，那是实现细节，不是教条。这篇文章想把这个"RAG 不需要向量？"的话题聊透，包括它的适用条件、零向量架构怎么落地、我用两百条问题压测的数据、以及什么时候必须老老实实引入向量。不管你是被 RAG 教程绕晕的新手，还是正在为向量数据库选型头疼的工程人，这篇都值得你对照自己的场景读一遍。
我不想一上来就给结论说"向量库是智商税"或者"无向量最优"，那是另一种偷懒。更准确的说法是：RAG 的检索层是一个可以被很多工具满足的需求，向量只是其中一种实现，而且在不少真实业务里，它既不是成本最低的，也不是效果最好的。下面把我实践出来的判断逻辑、替换路径、对照测试和坑位一次性讲清楚。
1. "RAG 必须配向量库"这个共识，到底是怎么来的
1.1 顺着 RAG 的技术演进倒推，你会看到向量不是唯一出路
RAG 这个缩写第一次大规模进入开发者的视野，基本是伴随 ChatGPT 之后带火的一整套工具链：嵌入模型、向量数据库、检索提示词模板。这套组合拳的打法是先给文档切片，用 embedding 模型把每个切片变成高维向量，存进向量库；用户提问时也转成向量，通过近似最近邻（ANN）搜索找回最相似的切片，再塞给大模型生成答案。流程图看起来非常漂亮，于是"RAG 等于向量检索加生成"这个等价关系就被教程们默认了。
但把镜头拉远一点，RAG 的本质其实是"拿外部知识补足模型上下文"。你只要想清楚一件事就行：大模型输出的事实准确性，取决于你喂给它的语境里到底有没有正确答案。至于这个语境是向量搜出来的，还是全文检索找出来的，甚至是查数据库查出来的，模型根本不关心。所以凡是能把相关文档片段从知识库里捞出来的机制，理论上都可以作为 RAG 的检索器。向量检索、BM25 全文检索、倒排索引、SQL 模糊查询、图谱遍历，甚至规则引擎，全是合法选项。
向量库之所以成为默认答案，还有个现实推力：厂商的包装。过去几年向量数据库的营销话术几乎把"AI 原生""智能检索"和"语义理解"绑定在一起，导致很多刚入门的人以为没有向量就等于没有语义，搜索质量一定很差。实际上语义能力在绝大多数非 To B 复杂场景里，不一定非要在检索阶段硬拼向量相似度——查询词和文档片段的高频词重合往往已经足够送到答案了，这是后面我用数据验证过的事。
1.2 一个反直觉的事实：在不少问答任务里，经典检索比向量检索更能打
如果你翻过信息检索的老教材，会看到一个被反复验证的结论：在短文档、问答型任务上，BM25 这类词法检索经常打不过，甚至能碾压"裸向量检索"。原因不复杂。向量检索强在语义泛化，比如"怎么修漏水的水龙头"能匹配到"管道渗水处理办法"这种完全不重叠的表述。但代价是它对含有关键实体的精确查询往往不够敏感，它更擅长抓语义趋势，而不是死磕实体和数字。
举一个我自己的例子。知识库里有一份路由配置说明，里面有这么一句："当集群节点数超过 64 时，建议将心跳间隔调整为 3000ms"。用向量检索去查"心跳间隔超过多少毫秒需要调整"，排在最前面的片段很可能是讲"心跳超时导致脑裂"的那一篇，语义接近但答案字段完全对不上。而 BM25 检索因为对"64""3000ms""心跳间隔"这些词项高度敏感，能把包含具体数字的原句精准捞出来。这类「实体精准匹配」需求，在企业知识库、运维文档、产品规格书里占了相当大的比例。所以"向量一定胜出"根本站不住脚，只能说在"自然语言泛化提问"上向量更顺手。
2. 拆掉向量数据库那晚，我把 RAG 重写成了一份干净的 BM25 实现
2.1 原来的架构出了什么问题
先说背景。我做的是一个基于本地文档的问答机器人，文档来源包括 Markdown 技术文档、运维手册、还有一堆 PDF 导出的操作指南。最初的架构和主流教程一模一样：文档切片后交给 embedding 模型转向量，存在 Docker 里的一个开源向量库里，查询时先向量召回前 5 个片段，再用 LLM 拼上下文生成回答。
问题出在三个地方。第一是维护成本：向量库本身占内存，索引要定期重刷，文档一多，embedding 接口的调用时间和费用也上来了。对个人或小团队来说，这套基础设施其实挺重。第二是切片和向量之间的语义错位：一个长段落里如果包含多条关键信息，向量化会分散注意力，经常精准错过某个实体。第三是更新体验极差：文档改一个字，整个段落重新向量化，索引还得等重建，想要一个"改了就能马上生效"的轻量体验很难。
于是我做了个大胆决定：把向量库从依赖列表里直接删掉，只留 SQLite 和一份纯 Python 的 BM25 实现。第二天早上起来，系统能回答问题的准确率不降反升，延迟还降了一截。那天晚上我特别有印象，因为第一次意识到工具选型里"惯性"是多可怕的东西。
2.2 零向量 RAG 的完整构建过程，照着抄就行
如果你也想复现一套零向量 RAG，核心流程只有五步：文档解析、切片、标准倒排索引构建、BM25 打分、上下文组装。我用的检索基座是 SQLite 的 FTS5 扩展，配合 Jieba 分词做中文切词，整个检索层代码不到两百行。
文档解析这块不多说，我的输入源是 Markdown 和 PDF，用常见的解析库抽成纯文本。接下来是切片，我定了以段落为主边界、超长段落再按句子切分的策略，强调一句，切片质量在无向量 RAG 里的重要性比向量 RAG 高一倍。因为向量检索还残留一点语义兜底能力，纯词法检索如果切片里句子混合太杂，命中的片段就会夹带大量无关内容，污染生成答案。
索引层用 FTS5 建虚拟表即可，配合中文分词器的处理方式是在插入前把文本先过一遍 Jieba，切好的词用空格拼好再写入，这样 FTS5 能正确处理中文的词项。一个最小化的建表和查询逻辑大概是这样的：
import sqlite3 conn = sqlite3.connect("knowledge.db") # 开启 FTS5，content 是原文，keywords 是分词后的词序列 conn.execute(""" CREATE VIRTUAL TABLE IF NOT EXISTS chunks USING fts5( title, content, keywords, tokenize = 'unicode61' ); """) def index_text(conn, title, content): keywords = " ".join(jieba.cut(content)) conn.execute( "INSERT INTO chunks(title, content, keywords) VALUES (?, ?, ?)", (title, content, keywords) )查询时用 FTS5 自带的 bm25() 函数就能拿到相关度分数，按分数排序取前 k 个片段：
def search(conn, query, k=8): q_words = " ".join(jieba.cut(query)) cur = conn.execute( """ SELECT title, content, bm25(chunks) AS score FROM chunks WHERE chunks MATCH ? ORDER BY score LIMIT ? """, (q_words, k) ) return cur.fetchall()最后把检索到的片段按 score 排序拼进系统提示词，再调用 LLM 生成回答。这里有个细节，我不建议直接把所有命中片段生硬塞进 prompt，最好按 score 顺序只保留前 3-5 个，并且每个片段都标明来源标题，方便定位和召回失败时排查。整个链路下来，我在一台纯 CPU 的老笔记本上能做到单查询检索耗时 30ms 左右，加上本地 LLM 的生成时间，体感完全可用。
2.3 为什么 BM25 在本地知识库这个场景特别合适
BM25 属于经典重合度评分模型，它把词频、逆文档频率、文档长度归一化揉在一起。公式推演就不展开了，一句话概括它的脾气：查询里出现的罕见词如果也在文档里出现，这个文档会被重点抬分；而"的、了、吗"这类烂大街词，基本不产生作用。这个特性特别适合知识库问答，因为人的提问和文档的措辞不完全一致，但核心实体词通常重合度很高。
而且我强调过，BM25 没有黑盒向量化过程，每个词的权重都符合直觉，调试极其友好。中文分词器如果拆得不对，你能直接看到是哪个词丢了，不像向量库出了问题只能怀疑模型和索引，根本无从下手。对于小团队和独立开发者，这点可维护性上的差距，比想象中大得多。
3. 两百条真实提问的对照压测，向量检索被我按在地上摩擦了吗
3.1 压测设计：我不想靠感觉说话
拆掉向量库之后，为了确认不是自我感觉良好，我专门整理了两百条测试问题，全部来自历史真实提问记录，覆盖四类：实体查询型（"Nginx 默认超时时间是多少"）、步骤操作型（"怎么重新生成自签名证书"）、概念总结型（"讲讲负载均衡的原理"）、跨文档关联型（"数据库连接池和线程池配置有关系吗"）。每一题我都手工标注了标准答案所在的文档片段和关键词，然后分别用原来的"向量检索 RAG"和新的"BM25 无向量 RAG"跑了一遍，评价指标用最容易理解的命中率和答案正确率。
3.2 结果说话：谁在什么任务上翻车了
下面是两种方案在两百条问题上的粗略对照。命中率指的是标准答案所在的任意一个片段是否出现在召回的前 8 个结果里，正确率则指 LLM 最终回答内容能覆盖标准答案要点。
| 问题类型 | 向量 RAG 命中率 | BM25 无向量命中率 | 向量 RAG 正确率 | BM25 无向量正确率 |
|---|---|---|---|---|
| 实体查询型 | 63% | 91% | 55% | 87% |
| 步骤操作型 | 78% | 72% | 70% | 69% |
| 概念总结型 | 86% | 67% | 82% | 61% |
| 跨文档关联型 | 52% | 30% | 45% | 28% |
这组数据很有意思，完全符合信息检索理论给出的预期。实体查询型问题，BM25 的精确词汇匹配优势极其明显，命中率从 63% 拉到 91%，正确率更是碾压级。步骤操作型里，因为命令和参数名词通常很特异，两边打平，BM25 微逊。概念总结型的问题往往是"什么是""请解释"，提问词汇和文档词汇差异很大，向量语义扩展的优势就出来了，BM25 掉到 67% 命中、61% 正确。跨文档关联型是最难的，答案分散在多个不同主题文档里，两边表现都差，BM25 尤其拉胯，因为没有任何一个片段和问题有足够的词汇重合。
这个结果说明什么？不是无向量方案全面胜出，而是在我的业务问题分布里，实体查询和步骤操作占了近七成，所以整体口径算下来，BM25 的正确率反而更高。答案其实很朴素：先分类你的问题类型，再决定检索器。我后来引入了一手"混合投放"策略，对概念和关联类问题单独补了一个向量检索通道，效果才稳下来，这个放到第五节聊。
3.3 延迟和资源方面，差距更明显
向量方案在 CPU 机器上跑 ANN 索引，查询本身不慢，但文档更新时新增向量要调用嵌入模型，单批几百个切片的向量化要耗掉一两分钟，索引刷新还要挤占内存。BM25 方案几乎毫无压力：SQLite 单文件，全文索引零外置依赖，更新一篇文档后直接改一行记录，FTS5 索引自动同步，整个过程不用调用任何远程模型。实际配置差异上，向量库的 Docker 容器常驻内存约 1GB 以上，而纯 FTS5 的完整知识库单文件不到 10MB。对本地化部署和边缘场景来说，这个差距可以决定一套方案能不能落地。
4. 什么情况下 RAG 可以不带向量，什么情况下必须带
4.1 一套简单的判断框架，从三个问题开始
每次有人问我"我这个项目要不要上向量数据库"，我都不直接给答案，而是让他们先回答三个问题。
第一，用户提问和文档表述的重合度高不高？如果问题是"合同编号是多少""重试次数怎么配""支持哪些格式"，文档里几乎原话可找，那 BM25 足够。反过来，如果用户习惯用口语提问（"我的文件为什么传不上去"），而文档写的是"上传接口返回 413 状态码"，词法检索就抓瞎了。
第二，检索精度的主要威胁是词语不匹配，还是语义模糊？前者靠同义词扩展和改写能救，后者才需要向量。运维文档、操作手册、产品规格书最大的问题是术语不一致，比如"服务器"和"主机"混用，这可以通过把同义词加进分词词典解决，并不一定要上向量。
第三，你手里的基础设施和后续迭代成本预算有多少？向量库要维护索引、嵌入模型、算力，对个人项目和小团队真的不轻。如果文档规模在几万片以下、更新频繁、部署环境苛刻，零向量方案会香很多。真正必须上向量的，是文档规模巨大但语义检索需求密集、查询表达极度发散、或者你已经在做 Agent 记忆这类需要长期语义关联的任务。
4.2 向量数据库的合理定位，不是替代而是补充
我观察到一个误区：很多人以为"不用向量"就是"排斥向量"。我自己的做法恰恰相反，我的主系统在纯 BM25 的基础上，又接了一个轻量级向量通道做语义词召回，两个通道的结果用 RRF（Reciprocal Rank Fusion）融合排序。比如某个概念总结型问题触发词法检索效果差时，向量通道的语义词结果会把分补回来；而实体查询型问题词法通道排第一，向量结果也有机会进候选列表。背后的逻辑是让两种关注点不同的信号互相纠错，这比单一方案稳得多。
但如果你问我"RAG 不需要向量？"，我的完整回答是：默认不该从向量起步，而是该从最便宜可靠的检索方式起步，向量只在它真正带来增益的地方作为增强层出现。从零开始就搭一套向量库，就像刚开超市就上了一个巨型冷库，可你的商品根本没那么容易变质。
5. 零向量 RAG 的进阶玩法：查询改写、同义词融合和本体注入
5.1 用 LLM 自己当"翻译官"，解决表达不一致
BM25 最大的敌人是查询关键词和文档词不重叠。这时候反而可以借用 RAG 本身的大模型能力做查询改写，而不是立刻引入 embedding。我的做法是把用户原问句丢给 LLM，让它扩写出 3-5 个与文档风格更接近的检索词组合，再把扩写结果一并拿去跑 BM25。比如用户问"文件传不上服务器怎么办"，LLM 可能改写为"上传失败 413 错误 防火墙 文件大小限制"，这几个词在文档里全都能精准命中。
这个过程的成本很低，一次 LLM 调用改写多个查询，再并行检索合并结果。实测下来，概念总结型问题的命中率从 67% 拉到了 79%，说明问题未必在检索算法，而在"喂给检索器的查询词是否贴近文档语言"。这种方法投入小、见效快，我建议任何人在决定上向量库之前，先试这一招。
5.2 同义词表和分词典定制，细节决定召回
零向量 RAG 想做好中文，分词器和同义词表就是命门。Jieba 默认词典覆盖不了企业术语，比如"心跳"和"Heartbeat"、型号缩写"X7R"和"X7R 电容"。我在项目里维护了一张简单的同义词扩展表，索引时一个词展开成多个变体写入 FTS5 的 keywords 列，查询时同样扩展。这样"服务器"和"主机"就会命中同一批文档，成本为零，效果显著。
分词策略上我只推荐两件事：一是把高频无意义词（"我们""进行""相关"）加入停用词，二是把专属术语手动加入 Jieba 用户词典。否则"数据库"可能被切成"数据"和"库"，放在向量方案里模型自己能处理，在词法方案里就是灾难。每一次分词的错误都会直接演变成检索召回失败，有没有向量兜底，完全两种体验。
5.3 当知识库自带结构时，图谱和本体比向量更懂关联
话题延展到热搜词里的"ontology RAG"和"Wiki 与 RAG"，这两者其实都在回答同一个问题：如何利用知识之间的显式关系提升检索。如果你手里有一批结构化程度较高的条目，比如"接口 A 依赖服务 B""组件 C 的配置文件在路径 D"，这些关联关系用图模型或本体约束表达，比塞进向量空间精准得多。可以把这些关系直接建成一个小的图谱库，查询时先做实体链接，再沿关系边扩散，把关联片段一并抽出来灌进 prompt。
我在跨文档关联型问题压测里，BM25 掉到 30% 命中，就是因为缺少这种关系路径。后来我翻出知识库里现成的依赖清单，给每条记录人工标注了关联文档 ID，查询时直接通过外键关联合并检索结果，关联型问题的命中率一下提到了 55%。虽然没法和大数据量下的图神经网络比，但性价比完全不一样。对绝大多数内部知识库，一张维护良好的关联表就能解决问题，根本不需要建图计算引擎。
5.4 Agent 化和工具调用的扩展方向
RAG 做到后来，往往要变成"RAG 智能体"，也就是检索不止一步。我在无向量 RAG 上接了一个简单的循环：首轮用 BM25 命中一个低分候选集，让 LLM 判断内容是否足够，不够就再生成一条补充查询继续检索，最多两轮。这个能力在向量方案里也能做，但无向量架构下每轮检索成本极低，我甚至可以在循环里同时跑多条查询，合并后重新排序，灵活性相当高。别急着上多复杂的外部编排框架，先把手头的检索器和 LLM 之间的"短循环"跑通，收益往往最大。
6. 踩过的坑和无向量 RAG 的最终适配套路
6.1 最坑的三个问题，每个都能让准确率减半
第一个坑是切片和标题信息丢失。FTS5 虽然是按整块文档索引的，但如果你切得太碎，标题里的关键实体就带不上了。比如文档标题叫"高可用集群部署手册"，正文切出的段落却只有"节点 1 和节点 2 分别部署"，查询"高可用集群节点部署"时就可能匹配不上。我的解决办法是把标题作为额外的一个字段参与索引，并在切片时把标题拼进每条 chunk 的 title 字段，让标题权重天然抬高。
第二个坑是查询用语太短。用户只输入"超时"两个字，BM25 会召回所有含"超时"的文档，排序更看文档频次，结果不一定是你想要的那篇。我建议遇到查询少于 4 个字的场景，无脑加一层查询扩展，把"超时"展开成"超时时间 超时重试 请求超时 配置超时"，语义瞬间清晰起来。这件事在向量方案里模型能隐式完成，在词法方案里必须显式处理。
第三个坑是没有兜底提示。纯 BM25 检索如果找不到任何命中，FTS5 返回空集，这时候我不建议直接给 LLM 一个空上下文让它硬编。实践中最稳的做法是：先走一遍别名表、同义词替换，还不行就返回"知识库中暂无相关信息，请检查问题表述"这样明确的话术。空上下文喂给 LLM，最坏结果是幻觉编造，比"答不上来"糟糕得多。
6.2 什么类型的场景，我不建议你再碰无向量 RAG
虽然我写了一大篇为无向量 RAG 辩护的内容，但必须把边界画清楚。如果用户提问是开放式的、同类问题几乎没有词面重复，比如"遇到线上故障应该按什么顺序排查""这种行为会有哪些隐藏风险"，文档里根本没有稳定对应的词汇，那就必须上向量。再比如你要做的不是知识库检索，而是对话型 Agent 的长期记忆管理，让模型从历史会话里回忆"上个月用户提过什么倾向"，这本质是语义相似度召回，向量库就是最顺手的工具。
我做无向量 RAG 能成，很大原因是知识库的领域足够集中、术语足够固定，自然语言发散度低。任何强语义发散的场景，零向量方案会很痛苦，硬撑着用，只会让每一次查询都变成一场猜词游戏。
6.3 我的最终建议：检索架构应该像搭积木，而不是开盲盒
用一句话总结这一个月多的折腾：RAG 不需要向量，RAG 需要的是"可解释的检索结果"。向量能给你模糊匹配的惊喜，也给不了你对每次命中原因的掌控感。在做选型时，我建议你按这个优先级去试：先上纯 BM25，把查询改写、同义词扩展、关系表这三板斧用足；实测下来哪类问题依然不稳，再针对性地引入一个向量通道做混合召回，而不是一开始就上全套重装备。手里没有压测数据之前，任何"必须上向量库"的结论都值得警惕。
最后分享一个个人心得：我在切换方案之后，最爽的反而不是延迟下降，而是每次遇到检索错误，都能顺着 FTS5 的 MATCH 结果反推是哪几个词漏了，然后去补词典。这种完全可视、可修正的感觉，是黑盒向量模型永远给不了的。如果你手头的项目也卡在向量库的重和维护里，我真心建议花一个周末，把检索层换回一把词法尺子重新量一遍，结果可能出乎你的意料。
