ChromaFs от Mintlify: виртуальная файловая система для AI-ассистентов

Mintlify столкнулись со стандартной проблемой в работе своего ассистента по документации: традиционный RAG возвращает только фрагменты, совпавшие с запросом, поэтому он пасует, когда ответ размазан по нескольким страницам или когда нужный пользователю синтаксис не попадает в top-K результатов. Первое решение - клонировать репозитории в песочницы, чтобы агент мог просматривать реальные файлы, - работало, но оказалось медленным (P90 создания сессии около 46 секунд) и дорогим (более $70K в год при 850K диалогов в месяц).

Их решение, ChromaFs, - это виртуальная файловая система, представляющая векторную базу данных Chroma как дерево каталогов UNIX. Агент выполняет обычные команды оболочки (ls, cat, grep, find, cd), а ChromaFs транслирует каждый вызов в запрос к базе данных. При этом реальных файлов на диске нет.

Как это устроено

ChromaFs опирается на just-bash от Vercel Labs - реализацию основных команд оболочки на TypeScript с подключаемым интерфейсом IFileSystem. just-bash отвечает за парсинг, а ChromaFs - за хранение.

Дерево каталогов. Все пути и их метаданные (видимость, права групп) хранятся в виде сжатого gzip'ом JSON. При старте сессии этот JSON распаковывается в две структуры в оперативной памяти: множество путей и отображение каталогов на их дочерние элементы. Команды вроде ls, cd и find работают целиком в памяти без сетевых запросов.

Контроль доступа. Каждая запись пути содержит поля isPublic и groups. До того как агент увидит дерево, ChromaFs фильтрует его по сессионному токену пользователя. Запрещённые пути отсекаются полностью - агент в принципе не может сослаться на файлы, которые ему не положено видеть. Это заменяет привычное для Linux управление правами через chmod и группы одной проверкой метаданных.

Содержимое файлов (cat). Страницы документации хранятся в Chroma по фрагментам (чанками). Когда агент вызывает cat для файла, ChromaFs запрашивает все фрагменты для slug'а этой страницы, сортирует их по chunk_index и склеивает. Результаты кэшируются, поэтому повторные чтения (обычные при работе с grep) в базу повторно не обращаются. Для больших спецификаций OpenAPI, лежащих в пользовательских бакетах S3, используются ленивые файловые указатели: они отображаются в списках файлов, но загружаются только при обращении.

Grep. Рекурсивный grep использует двухэтапную фильтрацию. Сначала операторы $contains (для фиксированных строк) или $regex в Chroma сужают набор кандидатов. Затем совпавшие фрагменты предварительно загружаются в Redis, и just-bash выполняет настоящее регулярное выражение в памяти только по этим файлам. Это удерживает задержку grep в пределах миллисекунд даже на больших массивах документации.

Запись. Все операции записи возвращают EROFS (Read-Only File System). Файловая система не хранит состояние (stateless), и агент не может ничего изменить.

Результаты

Время создания сессии сократилось с ~46 секунд до ~100 миллисекунд. Предельные вычислительные затраты упали практически до нуля, так как решение переиспользует существующую инфраструктуру баз данных. Система обрабатывает более 30 000 диалогов в день для сотен тысяч пользователей.

В чём интерес подхода

Основная мысль в том, что LLM-агентам не нужны настоящие файловые системы - им нужно то, что ведёт себя как файловая система. Виртуальная файловая система поверх базы данных даёт контроль доступа, кэширование и оптимизацию поиска, которые было бы гораздо сложнее прикрутить к реальному вводу-выводу файлов. Кроме того, система остаётся stateless и read-only, что устраняет целый класс проблем с безопасностью агентов.