文章介绍了团队如何为AI助手构建虚拟文件系统。原有RAG技术存在检索局限，无法跨页面获取完整答案。受论文启发，团队将文档页面模拟为文件系统，使助手能像浏览代码库一样探索文档。相比传统沙箱方案（创建会话需46秒且成本高昂），虚拟文件系统显著提升了响应速度和经济效益。该系统每月支持85万次对话，解决了实时文档访问的延迟和成本问题。

我们如何为助手构建虚拟文件系统

背景与挑战

传统的检索增强生成（RAG）技术存在局限性：当答案分散在多页文档中，或用户需要精确语法但未出现在搜索结果前列时，助手无法有效响应。我们希望通过类似浏览代码库的方式探索文档。

研究发现，文件系统已成为智能代理的主流交互界面（如grep、cat等命令）。若将文档页面映射为文件、章节作为目录，代理可自主检索、阅读和遍历结构。但传统方案面临两大问题：
1. 延迟高：创建沙箱环境（含克隆仓库等）需约46秒，无法满足实时前端助手需求。
2. 成本昂贵：每月85万次会话下，微虚拟机方案年成本超7万美元（基于Daytona定价）。

解决方案：ChromaFs虚拟文件系统

我们放弃真实文件系统，转而构建ChromaFs——一个拦截UNIX命令并将其转换为数据库查询的虚拟层。其核心优势：
- 性能：会话创建时间从46秒降至100毫秒。
- 零边际成本：复用现有Chroma数据库基础设施。

| 指标 | 沙箱方案 | ChromaFs |
|--------------|----------------|-------------------|
| P90启动时间 | 46秒 | 100毫秒 |
| 单次计算成本 | 0.0137美元 | 0美元（复用数据库）|
| 搜索机制 | 磁盘线性扫描 | 数据库元数据查询 |

关键技术实现

1. 目录树构建

   • 将全量文件路径以压缩JSON（__path_tree__）存储于Chroma集合，启动时加载至内存。
   • ls/cd等命令通过本地缓存解析，无需网络请求。

2. 权限控制

   • 根据用户会话令牌动态过滤路径树（如isPublic和groups字段）。
   • 相比传统沙箱的Linux权限管理，仅需几行代码实现精细化访问控制。

3. 内容重组与优化

   • cat命令：合并同一页面的所有文本块，按chunk_index排序后返回完整内容。
   • grep -r优化：先通过Chroma粗筛潜在文件，预取至Redis缓存，再由内存执行精细匹配。
   • 写操作直接返回EROFS错误，确保系统无状态且安全。

成果

ChromaFs已支持每日3万+会话，为数十万用户提供即时文档辅助，同时节省了基础设施成本。

（注：原文中的技术细节如just-bash实现、OpenAPI懒加载等予以保留，冗余定价计算和部分代码示例已精简。）

以下是评论内容的总结，平衡呈现不同观点并保留关键引用：

1. 文件系统搜索的复兴

   • 观点：基于文件系统的语义搜索（非嵌入检索）重新受到关注，因其更易被AI代理理解。
   • 引用：
     "The real thing I think people are rediscovering... is that there’s a type of semantic search that’s not embedding based retrieval." (评论1)
     "We’re rediscovering forms in search we’ve known about for decades." (评论1)

2. 对RAG（检索增强生成）的质疑

   • 观点：RAG在结构混乱的数据中效果有限，文件系统的层级结构可能更优。
   • 引用：
     "getting RAG to work well in places... where the structure is far from hierarchical is a very hard task." (评论4)
     "The problem with traditional RAG is that chunking destroys the structure that actually matters." (评论21)

3. 技术实现的争议

   • 支持方：虚拟文件系统（如ChromaFs）能显著降低成本并提升速度。
     • 引用："Session creation dropped from ~46 seconds to ~100 milliseconds... the marginal cost is zero." (评论14)
   • 反对方：现有技术（如RAM磁盘、Postgres全文搜索）可能更高效。
     • 引用："why not a simple full text search in Postgres?" (评论18)
       "SQLite is notoriously 35% faster than the filesystem." (评论17)

4. 对LLM工具链的讨论

   • 观点：直接提供Unix工具（如grep、ls）给LLM比模拟bash更简单。
   • 引用：
     "I dont understand the additional complexity of mocking bash when they could just provide grep, ls..." (评论11)
     "If grep and ls do the trick, then sure you don’t need RAG/embeddings." (评论10)

5. 多元化信息检索的倡导

   • 观点：不同任务需要不同检索方式（如关系数据库、图数据库），单一方案无法通用。
   • 引用：
     "finding the right information is not one task... there will not be one architecture for LLMs." (评论23)
     "Different ways to find context are welcome, we have a long way to go!" (评论13)

6. 成本与实用性质疑

   • 观点：部分方案（如沙盒定价）成本过高，可能不切实际。
   • 引用：
     "$70k? how about if we round off one zero? Give us $7000." (评论5)
     "But you also don’t need an LLM: a full text search... will be a lot more performant." (评论10)

关键争议点：
- 文件系统 vs 数据库检索的效率对比（评论14 vs 17/18）
- RAG的局限性是否被夸大（评论4/21 vs 19）
- LLM是否需要复杂工具链（评论11/16 vs 14）