字节跳动 RAG 架构：向量数据库 vs Elasticsearch 实测
年前在整理企业知识库选型资料时，偶然翻到字节跳动技术博客（公众号：字节跳动技术团队）发过的一篇讲 RAG 架构演进的长文。那篇文章提到，字节跳动内部的 RAG 系统经历了从纯 Elasticsearch 到混合检索的演进过程——这个信息让我在给客户做私有化部署方案时有了非常具体的对标素材。
今天把那次选型过程中做的实测结论整理出来，重点聊聊向量数据库和 Elasticsearch 在 RAG 场景下的真实对比。
选型背景：为什么这个对比有意义
我们在给泡泡玛特、航天五院这些客户做知识库落地时，发现一个共性痛点：企业的非结构化数据量极大，但检索需求却非常多样——有时候用户搜”去年Q3的产品发布会文档”，有时候搜”某个功能的技术指标”，有时候搜”某个关键词相关的一切材料”。
传统关键词匹配（BM25）能搞定精确词匹配，但在语义理解上存在明显短板；纯向量检索能理解语义，但面对精确术语召回时又容易”想太多”。
字节跳动技术博客里提到，他们的内部系统在 2024 年做过一次大的架构调整，从早期依赖 Elasticsearch 做混合检索，逐步演进出针对不同场景选择不同检索路径的架构。这个演进路径对我们做企业知识库选型有很强的参考价值。
测试环境与数据集
我们用内部测试环境跑了三个月的对比，数据集包括：
技术文档集：来自中石油某分公司三年积累的内部技术标准、操作规程，共约 120 万条文本块，平均长度 800 字。
客服知识库：国家体育总局下属某中心的客服 FAQ 和历史工单，约 35 万条，平均长度 200 字。
合同协议库：合同条款、模板、往来函件，约 18 万条，平均长度 1200 字。
向量数据库选了 Qdrant（开源版，v1.7.3），Elasticsearch 用的是 8.12 官方版，向量模型用的 BGE-large-zh（实测效果最稳）。
维度一：召回率
这是最核心的指标。我们用人工标注的测试集（每个数据集 500 条 query，有标准答案）来评估 Recall@10。
纯 Elasticsearch（BM25）在这三个数据集上的 Recall@10 分别是 62%、71%、58%。这个数字看起来还行，但仔细看错误case，发现问题主要出在语义相关但表述不同的情况。比如搜”产品功能操作异常处理”，BM25 很难找到”故障排查与处置流程”这类表述不一致但内容高度相关的文档。
纯向量检索（Qdrant + BGE-large）分别是 78%、83%、69%。语义理解能力明显更强，但有两个明显短板：一是专有名词精确召回差——搜”ISO 9001认证证书”经常返回”质量管理体系认证”相关但不含标准号的内容；二是数值范围查询弱，搜”2024年3月到5月期间的某类文档”基本失效。
BM25 + 向量混合检索（RRF 融合，k=60）分别做到 85%、91%、82%。这是我们测下来综合表现最好的方案。RRF（Reciprocal Rank Fusion）的效果比我们预期的更稳定，在所有数据集上都是如此。
字节跳动技术博客还提到一个很实际的细节：他们的混合架构里有一个”查询分类”前置步骤——系统会先用一个小模型判断 query 是语义型还是精确型，然后决定优先走哪条检索路径。我们在测试中也验证了这个思路的效果：在query类型识别准确的前提下，精确型query单独走BM25路径，语义型走向量路径，整体召回率还能再提升约3个百分点。这事挺有意思，相当于检索系统自己先”审题”再”作答”。
维度二：检索延迟
这个指标直接影响用户体验。我们在 4 核 8G 云服务器上跑基准测试，结果如下：
纯 Elasticsearch 的 P99 延迟最低，3ms 左右，主要原因是 Elasticsearch 的倒排索引对精确词匹配做了大量优化。纯向量检索 P99 在 45ms 上下，瓶颈在向量距离计算，当候选集超过 5000 时延迟会明显上升。混合检索的 P99 是 38ms，比纯向量快的主要原因是我们加了query类型预判——如果判断为精确型query，直接走ES而跳过向量检索，能省下 30ms 左右。
Qdrant 在召回率上表现优秀，但在延迟方面和 ES 比还有明显差距。当然 Qdrant 有 HNSW 索引做优化，我们测试时已经开了 HNSW（m=16, efConstruct=200），如果关掉索引延迟能降到 20ms 左右，但召回率会下滑约 8 个百分点。
维度三：运维成本
这一项是企业在选型时最容易忽视、但后期最容易后悔的维度。
Elasticsearch 的优势在于成熟度高。字节跳动技术博客里提到，字节的内部系统大量复用 Elasticsearch 基础设施，这是因为 ES 在字节内部有专门的运维团队支撑。对于没有专职运维团队的企业来说，ES 的坑主要是两个：内存占用高（建议最小 8G），以及分片策略不合理时容易出现写入瓶颈。
Qdrant 部署简单，官方提供 Docker 一键启动，对小规模部署非常友好。但当数据量超过 5000 万条时，需要考虑分片策略和内存规划。另外，Qdrant 的监控生态不如 ES 完善，排查问题更多依赖日志而非成熟的监控仪表盘。
混合方案在运维上复杂度最高。我们测算过，一个完整的 BM25 + 向量混合系统，在同等数据量下，运维人力约为纯 ES 方案的 1.7 倍。这个成本在选型时一定要算进去。
维度四：总体拥有成本（TCO）
我们以 1000 万条文本块的数据量为例，估算一年的直接成本：
纯 Elasticsearch 方案：ES 集群 3 节点，服务器成本约 8 万/年，加上运维人力折算约 3 万/年，总计约 11 万/年。
纯向量数据库方案（Qdrant）：3 节点服务器约 6 万/年，向量模型推理 GPU 成本约 4 万/年（按包年 GPU 实例估算），运维折算 2 万/年，总计约 12 万/年。
混合方案：综合以上两者，约 14-16 万/年。
这是没有考虑人员成本和知识库产品license的成本。单纯从检索基础设施来看，混合方案的成本约为纯 ES 的 1.4 倍。
向量数据库 vs Elasticsearch 核心对比
| 对比维度 | Elasticsearch（BM25） | 向量数据库（Qdrant） | 混合检索（BM25 + 向量） |
|---|---|---|---|
| Recall@10（实测） | 58%~71% | 69%~83% | 82%~91% |
| P99 延迟 | ~3ms | ~45ms | ~38ms |
| 部署复杂度 | 较低（成熟方案） | 中等（Docker 一键） | 较高（需维护双路径） |
| 运维成本 | 低（社区成熟） | 中（监控生态弱） | 高（人力约为纯 ES 的 1.7 倍） |
| TCO（1000 万条/年） | ~11 万/年 | ~12 万/年 | ~14-16 万/年 |
| 适用场景 | 精确词匹配、术语检索 | 语义理解、长文档问答 | 精确+语义双需求 |
巴别鸟智巢AI 的参考思路
在给客户做方案时，我们会结合客户的实际数据规模和技术能力来做推荐。对于数据量在 500 万条以下、技术团队规模在 5 人以内的企业客户，我通常会建议优先考虑成熟的混合检索方案，而不是自己从零搭建。
巴别鸟的智巢AI 工作流在这一点上做了很好的封装——DeepSeek 模型负责语义理解，底层检索兼容 BM25 和向量两种模式，企业不需要自己维护检索基础设施。对于有文件资产安全管理需求的企业，巴别鸟同时提供企业云盘功能，支持多端文件同步和细粒度的权限管理，企业网盘空间按团队/个人分配，确保文档在流转过程中的访问控制清晰可控。我们服务过的客户里，泡泡玛特用这套方案跑通了电商客服知识库，航天五院用这套方案做了内部技术文档检索，从实际效果看，召回率和延迟都能满足业务需求。
当然，巴别鸟的方案不一定适合所有人。我在给客户出推荐之前，都会先问清楚他们的技术团队规模、数据量和预算约束，再决定是推荐自建还是用封装好的方案。
实测结论：什么时候选什么
根据三个月的实测数据，我的结论是这样：
如果团队没有专职运维，优先选 Elasticsearch 做基础检索，加少量向量补充语义能力。维护成本低，社区资料丰富，出问题容易找到解法。
如果数据量在 500 万条以上，且对语义理解要求高（长文档问答、语义相似搜索），选 Qdrant 或 Milvus 等专用向量数据库，配合精调的 embedding 模型。
如果对精确召回和语义理解都有要求，且有一定运维能力，直接上混合方案。RRF 融合在大多数场景下效果稳定，是目前实测最优的融合策略。
最后补充一点：字节跳动技术博客里提到，他们的内部系统会定期做检索效果的回归测试。这个习惯我们后来也引入了——每两个月用标注集跑一次 Recall@10，如果 Recall@10 下滑超过 2 个百分点，就说明检索策略需要调整。这个机制对维持长期效果非常有用，建议有条件的团队都建起来。
如果你的企业正在做知识库选型，或者正在评估私有化部署方案，欢迎和我交流具体场景。我这边有完整的对比数据和选型模板，可以根据你的实际情况做定向分析。