大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



过去两年，AI行业探索的 RAG 范式，可能是一条狭窄的技术岔路。我们正在目睹一场从“向量蛮力”到“结构化探索”的回调。

最近，Mintlify 分享了一篇《用虚拟文件系统替代 RAG》的文章，从内部工程实践，分享了他们如何改变“分块-向量化-相似度搜索”的简单 RAG。

这并非否定 RAG 的价值，而是指出行业对 RAG 的普遍理解和实现，在很大程度上是一种认知上的懒惰和路径依赖。我们错误地将“检索（Retrieval）”这个广义概念，等同于“向量搜索”这一具体实现。现在，是时候重新审视问题了。

Mintlify 做的是一个 AI 文档助手，初衷是让用户能通过对话快速找到文档中的答案。他们最初也采用了 RAG 的做法。

具体来说，就是把所有文档打碎成小文本块（chunks），用模型计算出每个文本块的向量嵌入（embeddings），存入 Chroma 等向量数据库。当用户提问时，将问题也转换成向量，然后在数据库里寻找语义最相似的 K 个文本块，把这些文本块和原始问题一起打包喂给大语言模型，最后生成答案。

这个流程听起来很好，在很多场景下也确实有效。但当答案散落在多个不同的文档页面，或者用户需要一个精确的代码语法，而这个语法片段又没有幸运地出现在相似度排名前 K 的结果里时，系统就失灵了。

这暴露了“标准 RAG”的两个核心问题：

第一，信息结构的丢失。文档、代码库、知识库，它们本身具有强大的内在结构。目录、章节、文件路径、模块依赖，这些都不是无意义的装饰，而是人类专家精心组织的知识图谱。将这一切扁平化、碎片化地打成一堆无差别的文本块，再用向量来表示，恰恰是一种信息熵增的过程。我们为了所谓的“语义相似”，摧毁了最有价值的上下文结构。

第二，精确性的牺牲。向量搜索擅长处理模糊和开放性的查询，能找到“意思差不多”的内容。但对于需要精确匹配的场景，比如查找一个特定的函数名、一个配置项、一段错误代码，向量相似度就显得力不从心了。它可能会返回一个功能类似但名字错误的函数，或者因为共享了某些关键词而拉取一堆不相干的代码片段。这对于开发者来说是灾难。grep 在这种场景下的价值，远胜于任何花哨的向量算法。

Mintlify 想要的，是让 AI 像一个经验丰富的开发者那样去“探索”文档，而不是像一个只会模式匹配的搜索引擎。一个开发者会用 ls 查看目录结构，用 find 寻找文件，用 grep 搜索关键词，用 cat 阅读完整文件。这些工具共同构成了一个高效、精确、可控的信息获取工作流。

面对问题，最直接的解决方案是给 AI Agent 一个真实的沙箱环境，克隆一份文档代码库进去，让它自己操作。但这个方案在工程上是不可行的。

Mintlify 分析后发现，仅仅是启动一个沙箱、克隆仓库并完成准备工作，耗时高达 46 秒。对于一个需要即时响应的前端助手来说，用户早就等不及了。更不用提成本，他们估算每个月 85 万次对话，每年将产生超过 7 万美元的基础设施费用。

于是，Mintlify 自己做出了 ChromaFs。Agent 并不需要一个真实的物理文件系统，它只需要一个看起来像文件系统的“接口”。

Mintlify 并未抛弃已经建好的 Chroma 向量数据库，而是在它之上构建了一个虚拟文件系统层。这个虚拟系统拦截所有 Agent 发出的类 UNIX 命令，比如 ls, cat, grep, find, cd，然后将这些命令动态翻译成对底层 Chroma 数据库的查询。

具体实现上，他们利用了 Vercel Labs 的一个 TypeScript 实现的 bash 解释器 just-bash。这个库提供了一个可插拔的文件系统接口 IFileSystem。Mintlify 要做的，就是实现这个接口，把文件操作映射到数据库操作上。

启动与目录树：系统启动时，它会从 Chroma 中取出一个预先存储的、代表整个文档目录结构的 gzipped JSON 文件。在内存中迅速构建起文件路径集合和目录映射关系。这样一来，ls, cd, find 这类不涉及文件内容的命令，完全在内存中完成，没有任何网络开销。会话创建时间从 46 秒降到 100 毫秒。

文件读取：当 Agent 执行 cat /auth/oauth.mdx 时，ChromaFs 会去数据库里查询所有属于这个文件路径的文本块，按顺序拼接起来，还原成完整的文档。

搜索优化：如果粗暴地把每个文件都通过网络拉到本地再执行 grep，性能会极差。Mintlify 的做法是“两阶段过滤”。首先，将 grep 的查询字符串或正则表达式翻译成 Chroma 的元数据查询（\(contains 或 \)regex），在数据库层面进行一次粗筛，快速找出可能包含匹配内容的文件列表。然后，只预取这些匹配文件的相关文本块到缓存，再把 grep 命令交给 just-bash 在内存中进行精筛。这个过程将一个可能耗时巨大的全量网络扫描，变成了一个高效的数据库索引查询加一次性的内存操作。

权限与成本：由于是虚拟文件系统，权限控制变得异常简单，只需在构建内存目录树时根据用户身份过滤掉无权访问的路径即可。而且，整个系统复用了现有的数据库基础设施，边际计算成本几乎为零。

ChromaFs 用 Shell 命令，替换掉了那个对 Agent 而言过于抽象和不可控的“向量检索”黑盒。它提供了一个稳定、可预测、结构化的操作，让 Agent 的智能得以在探索和推理上发挥，而不是浪费在猜测“哪个向量最相关”上。

Mintlify 的实践之所以在社区引发共鸣，因为它触及了一个更深层次的行业趋势。我们正从对 AI 的盲目崇拜，回归到对信息科学和软件工程基本原则的尊重。

第一，重新发现“文件结构”的价值。

目录层级本身就是一个由人类精心构建的知识图谱。我们只是因为对向量数据库太过兴奋而忘记了这一点。

无论是文件系统的目录结构、代码库的模块划分、数据库的表结构，还是图书的章节目录，这些都是领域专家耗费心血提炼出的知识体系。它本身就蕴含了丰富的语义关系，比如“包含”、“依赖”、“顺序”等。LLM 的预训练数据中包含了海量的代码、文档和 shell 操作记录，这使得它对这种结构化信息的理解能力远超我们的想象。

第二，我们厘清了 RAG 的真正含义。

RAG 中的“R”代表“Retrieval”（检索），而检索是一个极其宽泛的概念。它可以是向量搜索，也可以是关键词搜索（如 ElasticSearch 的 BM25 算法），可以是数据库查询（SQL），可以是图遍历，当然也可以是 grep。

行业在过去几年，几乎将 RAG 与“向量数据库 + 文本分块”画上了等号。但这更像是一次偶然，很大程度上是因为 LLM 兴起时，搜索领域的主流研究恰好聚焦在基于向量的问答系统上。于是，这个特定的架构被打包命名，并随着资本和媒体的炒作成为了“唯一正确”的范式。这是一种典型的“技术锤子”思维——手里拿着向量这把新锤子，看所有问题都像是钉子。

第三，确认了 Agentic Workflow（智能体式工作流）是未来的方向。

传统的 RAG 是一个线性的、单向的流水线：Query -> Retrieve -> Augment -> Generate。这个过程是刚性的，缺乏反馈和迭代。而 Mintlify 的方案则是一个 Agentic Workflow：Agent 拥有一个工具集（ls, grep 等），它可以根据任务目标，自主地、多步骤地与环境（虚拟文件系统）交互，观察结果，并根据观察调整下一步行动。

这是一个从“单次问答”到“持续探索”的根本转变。Agent 从一个被动的信息消费者，变成了一个主动的信息发现者。它可以在这个过程中进行推理、规划和纠错。这种闭环的、自我引导的搜索循环，其能力是传统 RAG 中那些“重排（reranking）”等优化手段的超集。

Mintlify 的启示是，我们与 AI 协作的模式正在发生根本性转变：从被动地为 LLM “喂养”经过预处理的上下文，转向主动地为 AI Agent “赋能”，赋予其探索和操作信息环境的能力。

“喂养”模式的核心是 RAG 1.0，我们假设 LLM 是一个需要精心呵护的婴儿，必须把知识嚼碎了（分块、向量化）才能喂给它。这种模式下，人的工作重点在于优化“嚼碎”和“喂养”的过程，比如研究更好的分块策略、更强的嵌入模型、更快的向量检索。但其天花板是显而易见的，因为信息在预处理阶段已经失真。

“赋能”模式的核心是 Agentic Workflow，我们视 LLM 为一个聪明的、有行动能力的代理。我们的工作重点，不再是预处理数据本身，而是为这个代理设计和提供强大、稳定、易于理解的工具和接口。虚拟文件系统就是这样一个完美的接口。

这个转变具有深远的积极价值：

它让我们把注意力重新放回到了信息架构（Information Architecture）这一经典领域。与其投入大量资源去优化向量模型的微小指标，不如花更多时间去设计和维护一个结构良好、逻辑清晰的知识库。一个好的目录结构、一套规范的命名约定，其价值可能远超一个更先进的嵌入模型。

未来成功的 AI 应用，其检索模块不会是单一的向量数据库，而是一个融合了多种检索工具的“瑞士军刀”。向量搜索依然是处理语义模糊性的一把好手，但它会与用于精确匹配的全文搜索引擎、用于结构化数据查询的 SQL 接口、用于关系探索的图数据库等工具并存。Agent 将根据任务需求，智能地选择和组合使用这些工具。

最终，这会构建出更加稳健、可解释和强大的 AI 系统。因为每一步操作都是明确和可追溯的，我们更容易调试和理解系统的行为，而不是面对一个难以解释的“最相似向量”列表束手无策。

总而言之，Mintlify 的故事并不是一个关于“杀死”某项技术的故事。它是一个关于“回归”和“成熟”的故事。它标志着我们正在走出对单一技术（向量搜索）的盲目迷信，开始以一种更系统、更工程化的思维来构建 AI 应用。

技术浪潮褪去后，被重新发现的往往是那些最古老、最坚固的基石。文件系统，这个诞生于半个多世纪前的古老抽象，正在 AI 时代以一种意想不到的方式，再次证明其价值。

参考来源：We replaced RAG with a virtual filesystem for our AI documentation assistant