1990s：我们用上了 B+ 树和倒排索引，世界上已经没有什么几秒钟查不出来的东西了。 2010s：我们推广了分布式全文搜索引擎，几十亿条日志毫秒级命中。 2025：我们把所有文档切成稀碎的 chunk，烧掉了不知道多少算力把它们向量化后扔进向量数据库，最后把搜出来的垃圾拼成几万字 prompt 塞进大模型，然后开始祈祷它别出现幻觉。 2026：大模型告诉我们，这个 find，还有这个 grep 工具真好用。

一句话看懂：X 用户 @__soragoto__ 用一条时间线调侃检索技术的四十年：从 B+ 树、倒排索引、分布式全文搜索，到向量数据库加 RAG，最后大模型反而觉得 find、grep 这类命令行工具好用。这条帖子 174.9 万次浏览，戳中了 RAG 落地中真实存在的效率疑问。

事件核心：发生了什么

2026 年 9 月 19 日，X 用户 @__soragoto__（空言）发帖，把检索技术的演化压缩成四句话：1990 年代，B+ 树和倒排索引让“几秒钟查不出东西”成为过去；2010 年代，分布式全文搜索引擎把几十亿条日志的命中压到毫秒级；2025 年，文档被切成一堆 chunk，烧算力向量化后塞进向量数据库，再把检索结果拼成几万字的 prompt 交给大模型，然后祈祷别出现幻觉；2026 年，大模型自己告诉开发者，find 和 grep 这类基础工具好用。该帖获得 174.9K 浏览、2.4K 点赞。

为什么重要

这不是技术倒退，而是成本结构的重新算账。RAG 链路里的向量化、存储和长上下文推理都要消耗算力和显存，而问题在于很多查询本质是关键词匹配或结构查找，倒排索引、grep 在这些场景下延迟更低、结果更确定。目前公开信息显示，包括 Claude Code、Cursor 在内的主流编程智能体，已在文件检索中大量使用 ripgrep 等命令行工具做初筛，再把命中的片段交给模型推理，而不是一次性喂入整个代码库的向量索引。这对向量数据库厂商和 RAG 框架是一个提醒：混合检索里，关键词路线的权重可能被重新评估。

对用户/开发者/创作者的影响

对开发者，搭建检索链路时不必默认“先上向量库”，可以先用全文索引加 grep 满足大部分精确查询，只在语义模糊、同义表达多的场景引入 embedding，能省下可观的推理算力。对企业采购，向量数据库和全文搜索引擎不是二选一，主流方案已转向混合检索，评估重点应放在召回率与单次查询成本上，而非索引规模。对普通用户和创作者，这类讨论短期不改变产品体验，但会影响 AI 搜索、知识库问答类工具的价格和响应速度，工具越依赖廉价精确检索，订阅成本越有下降空间。