当多数开发者还在追捧向量数据库作为RAG标配时，一线实践者们却悄然转向。一份对126位开发者的调研揭示了惊人事实：85%的场景下，复杂的向量搜索并非必需。这不是技术倒退，而是回归问题本质的清醒选择，为技术选型提供了更具成本效益和确定性的新思路。
智能速览
一份对126位开发者的调研显示，85%的场景下向量搜索并非必需。
代码检索场景中，BM25与Trigram的组合在效果和速度上均优于向量搜索。
SQLite全家桶因其零依赖、高效和简单，能满足绝大多数中小规模需求。
混合检索结合BM25与向量搜索，并通过重排序，是当前公认的最佳实践。
技术选型的核心是匹配业务需求，而非追求最前沿的技术。
精华内容
当技术圈的焦点还在向量数据库时，一线高手却已悄然转身。这并非技术倒退，而是历经实战后对问题本质的深刻洞察与回归。真正的技术判断力，在于知道何时不需要复杂的方案。
向量数据库被高估
向量数据库的火热掩盖了其在特定场景下的短板。在代码搜索领域，这一点尤为明显。代码的函数名、变量名需要精确匹配，而embedding天生擅长模糊搜索而非精确匹配，导致“又慢又不准”。
其次，存在效率悖论。一个生产环境案例显示，团队在引入向量搜索后，发现数据中存在一个结构化字段与检索内容100%对应。他们调整策略为先匹配该字段，结果发现85%的请求根本无需动用向量搜索，大幅提升了效率。
此外，向量数据库还伴随着隐藏成本。内容更新需要重新计算embedding，消耗GPU或大量CPU资源；其黑盒特性导致调试困难；基础设施的复杂度也随之增加。很多人感叹，大多数时候是在“拿着锤子找钉子”。
简单方案的胜利
实战中，一系列简单高效的方案正被开发者重新推崇。首当其冲的是“SQLite全家桶”，即SQLite配合FTS5（全文搜索）和SQLiteVec（向量扩展），再结合本地LLM进行结果排序。这个组合被许多人评价为“surprisingly well”，因为它零外部依赖、响应在毫秒级、能处理数百万条数据，且开发极其简单，解决了开发者95%的需求。
另一个优选是Postgres+pgvector。对于生产环境，这一组合的优势在于团队能力复用。如果团队已经熟悉Postgres，那么运维、交接都极为便利，技术选型优先考虑的是团队的掌控力而非技术的新旧。
混合检索成最佳实践
当前，混合检索被公认为RAG的最佳实践范式。其公式是：先用BM25做关键词匹配，再用向量搜索做语义相似度补充，最后通过一个重排序模型整合结果，确保相关性和精准度。具体工具链可以是PostgreSQL+pgvector+ParadeDB，或开箱即用的Meilisearch，或是嵌入式方案LensDB。
一个清晰的决策树可以帮助开发者快速选择：数据量小于1万条，SQLite FTS5足矣；1万到100万条，可选用SQLiteVec或LensDB；超过100万条，再考虑Postgres+pgvector等重型方案。如果是搜索代码，直接用BM25+Trigram，避免Embedding；如果是自然语言文档，则采用混合检索。
场景化选型策略
不同的应用场景需要差异化的技术方案。在代码RAG领域，工具选择上Ripgrep备受推荐，其性能优异；Embedding策略上，对文件路径和函数签名做Embedding是有效的，但代码内容本身仍应交由BM25和Trigram处理。切记，不要对整个代码库做Embedding，那样效果往往很差。
例如，一个处理Markdown文档的场景，95%的文件都很小，开发者仅用一小时搭建SQLite FTS5，效果就非常好。另一个日活30万的企业级客服知识库，则采用了Embedding+全文检索+IVF HNSW的混合方案，因为其对延迟和准确率有极致要求。这些案例说明，没有万能的银弹，只有最合适的搭配。
关键评论
有开发者指出，Claude Code早已切换至全文检索方案。
另有观点认为，最简单的树形结构渐进式检索或许是更优解。
也有评论提醒，需区分代码检索与企业文档知识库等不同应用场景。
有人推荐关注PageIndex，这是一种无需向量的、基于推理的RAG方案。
