- मौजूदा RAG-आधारित search की सीमाओं को पार करने के लिए, दस्तावेज़ों को फ़ाइल और directory से बनी virtual filesystem संरचना में बदला गया
- वास्तविक फ़ाइलों की कॉपी किए बिना Chroma database के आधार पर
grep, cat, ls, find कमांड चलाने वाला ChromaFs लागू किया गया
- इस तरीके से session creation time 46 सेकंड से घटकर 100 मिलीसेकंड हो गया, और अतिरिक्त compute cost लगभग 0 डॉलर तक कम हो गई
- access control को फ़ाइल path metadata की RBAC filtering से संभाला गया, जिससे अलग container या user group management की ज़रूरत नहीं रही
- नतीजतन, Mintlify document assistant को तुरंत response, कम लागत, और stateless architecture के साथ बड़े पैमाने की service के रूप में चलाया जा सकता है
RAG की सीमाओं से आगे virtual filesystem दृष्टिकोण
- मौजूदा RAG-आधारित document search केवल query से मेल खाने वाले text chunks लौटाता था, इसलिए कई पेजों में फैले जवाब या सटीक phrase search मुश्किल थे
- इसे हल करने के लिए document structure को filesystem की तरह navigate किए जा सकने वाले रूप में बदला गया, जहाँ हर document page को file और section को directory से map किया गया
- agent
grep, cat, ls, find कमांड के ज़रिए दस्तावेज़ों को सीधे explore कर सकता है, इसलिए इसे इस तरह डिज़ाइन किया गया कि डेवलपर जैसे codebase संभालते हैं, वैसे ही documents search कर सकें
Container bottleneck समस्या
- आम तरीका यह है कि agent को वास्तविक filesystem देने के लिए isolated sandbox environment बनाया जाए और repository clone की जाए
- लेकिन frontend assistant में session creation latency बहुत गंभीर थी, और p90 session creation time लगभग 46 सेकंड तक पहुँच जाता था
- महीने में 8.5 लाख conversations के आधार पर, न्यूनतम configuration (1 vCPU, 2GiB RAM, 5 मिनट session retention) में भी सालाना 70,000 डॉलर से अधिक infrastructure cost आती थी
- इस bottleneck को हटाने के लिए तुरंत प्रतिक्रिया देने वाला और कम लागत पर चलने वाला virtual filesystem चाहिए था
Virtual shell implementation — ChromaFs
- वास्तविक filesystem की जगह केवल virtual filesystem का illusion दिया गया
- मौजूदा document data पहले से Chroma database में index था, इसलिए उसी के आधार पर ChromaFs बनाया गया
- ChromaFs UNIX commands को intercept करके उन्हें Chroma queries में बदलता है
- नतीजतन, session creation time 46 सेकंड से घटकर 100 मिलीसेकंड हो गया, और अतिरिक्त compute cost लगभग 0 डॉलर तक कम हो गई
| Metric |
Sandbox |
ChromaFs |
| P90 Boot Time |
~46 सेकंड |
~100ms |
| Marginal Compute Cost |
~$0.0137/प्रति बातचीत |
~$0 |
| Search Mechanism |
डिस्क स्कैन |
DB metadata query |
| Infrastructure |
Daytona जैसे external sandbox |
मौजूदा DB का पुन: उपयोग |
- यह just-bash (Vercel Labs) पर आधारित है और
grep, cat, ls, find, cd कमांड को support करता है
- just-bash के
IFileSystem interface का उपयोग करके, pipe processing और flag logic को जस का तस रखते हुए file access calls को Chroma queries में बदला गया
Directory tree bootstrapping
- ChromaFs को चलने से पहले यह जानना होता है कि कौन-सी files मौजूद हैं, इसलिए पूरे file tree को compressed JSON(
__path_tree__) के रूप में Chroma collection में store किया गया
- server initialization के समय इसे लाकर दो memory structures में restore किया जाता है
- file paths का
Set<string>
- हर directory के children की सूची का
Map<string, string[]>
- इसके बाद
ls, cd, find कमांड network call के बिना local memory में तुरंत process होते हैं, और उसी site के बाद के sessions cached tree का फिर से उपयोग करते हैं
Access control
- path tree में
isPublic और groups fields शामिल हैं, और user session token के आधार पर केवल access योग्य files छोड़ी जाती हैं
- जिन files की permission नहीं है, उन्हें tree से पूरी तरह हटा दिया जाता है, इसलिए agent उन paths को पहचान ही नहीं पाता
- पुराने sandbox में इसके लिए Linux user groups,
chmod, container isolation आदि संभालने पड़ते थे, लेकिन ChromaFs में सिर्फ सरल filtering logic से RBAC लागू हो गया
| Path |
Access |
Visible |
| /auth/oauth.mdx |
public |
✓ |
| /auth/api-keys.mdx |
public |
✓ |
| /internal/billing.mdx |
admin, billing |
✗ |
| /api-reference/users.mdx |
public |
✓ |
| /api-reference/payments.mdx |
billing |
✗ |
Document chunk reassembly
- Chroma में store किए गए documents को embedding के लिए कई chunks में split किया गया था
cat /auth/oauth.mdx चलाने पर, समान page slug वाले सभी chunks लाए जाते हैं, फिर chunk_index क्रम में sort करके merge किए जाते हैं- परिणाम cache किया जाता है, इसलिए दोहराए गए
grep workflows में DB को फिर से query नहीं करना पड़ता
- बड़े OpenAPI spec आदि को lazy file pointer के रूप में register किया जाता है, और access होने पर ही S3 से लाया जाता है
- सभी write operations
EROFS (read-only filesystem) error लौटाते हैं, जिससे बिना session state वाला (stateless) सुरक्षित ढाँचा बना रहता है
Grep optimization
grep -r कमांड साधारण network scan में बहुत धीमा होता है, इसलिए इसे दो-स्तरीय filtering structure से optimize किया गया
- चरण 1: Chroma query (
$contains, $regex) का उपयोग करके candidate files चुनी जाती हैं
- चरण 2: उन्हें पहले Redis cache में लाकर,
just-bash में in-memory precise filtering की जाती है
- इससे बड़े recursive searches भी मिलीसेकंड स्तर पर पूरी की जा सकती हैं
निष्कर्ष
- ChromaFs हर दिन 30,000 से अधिक requests और लाखों users द्वारा इस्तेमाल किए जाने वाले Mintlify document assistant को चलाता है
- sandbox को बदलकर तुरंत session creation, 0 के करीब अतिरिक्त लागत, built-in RBAC, और stateless architecture हासिल की गई
- इसे Mintlify की सभी document sites में सीधे इस्तेमाल किया जा सकता है (mintlify.com/docs)
1 टिप्पणियां
Hacker News की राय
फ़ाइल सिस्टम-आधारित सर्च पर फिर से ध्यान जाने की वजह यह है कि हम embedding-based नहीं बल्कि semantic search के एक रूप को फिर से खोज रहे हैं
जैसे लाइब्रेरी का लाइब्रेरियन विषय के हिसाब से किताबों को शेल्फ़ पर सजाता है, वैसे ही फ़ाइलों को डोमेन के हिसाब से व्यवस्थित करना ज़्यादा interpretible है
यह सर्च का बहुत पुराना तरीका है, लेकिन अब जाकर हम इसकी अहमियत फिर समझ रहे हैं
संबंधित ब्लॉग पोस्ट
Pixar की Ralph Wrecks The Internet में भी यह कॉन्सेप्ट अच्छी तरह दिखाया गया था
संदर्भ ट्वीट1, संदर्भ ट्वीट2
इसके बजाय जब agent को directory tree सीधे explore करने दिया, तो उसने 30 सेकंड में module structure समझ लिया और सही फ़ाइलें माँगनी शुरू कर दीं
हम यह भूल गए थे कि directory hierarchy खुद ही इंसानों द्वारा बनाया गया एक knowledge graph थी
यह Google के inverted index जैसा ही कॉन्सेप्ट है, यानी वास्तव में यह पूरी तरह नया नहीं है
RAG ने मुझे कंटेंट को सीधे पढ़ने का तरीका नहीं दिया
इसलिए अब मैं Markdown-based static pages में ज्ञान को समेकित करता हूँ, फिर बदलाव के बाद JSON फ़ाइलें build करता हूँ ताकि agent इसी source से query करे
विवरण लिंक
यह दावा कि फ़ाइल सिस्टम सर्च RAG से बेहतर है, उलझन पैदा करता है
grep जैसी keyword search पुरानी पद्धति है, और RAG vector search का इस्तेमाल करता है
लेकिन database में कंटेंट को hierarchy, tags, arbitrary structure से index किया जा सकता है
सर्च keyword, vector, tf-idf, BM25 जैसी कई विधियों के संयोजन से हो सकती है
फ़ाइल सिस्टम की ओर लौटना 1960 के दशक की तकनीक की तरफ़ वापसी जैसा लगता है
CLI-आधारित coding agents फ़ाइल access मिलने पर काफ़ी ज़्यादा समझदारी से व्यवहार करते हैं
असली बात यह है कि agent खुद कई तरह की ad-hoc queries चला सके
embedding और full-text search दोनों को support करने वाले DB में agent को खुलकर query करने दी जाए तो वह काफ़ी agentic हो जाता है
फ़ाइल सिस्टम को DB की तरह इस्तेमाल करना कोई नई बात नहीं है
यह गणना अजीब लगती है कि महीने में 8.5 लाख conversations पर सालाना 70,000 डॉलर से ज़्यादा खर्च आएगा
मैं सोच रहा था कि इतना CPU और memory कहाँ खर्च हो रहा है, और वजह निकली Vercel Labs का just-bash आधारित ChromaFs
मैं CLI applications के पुनर्जागरण काल का आनंद ले रहा हूँ
मैंने FUSE से Mac के असली फ़ाइल सिस्टम को mirror करने वाला एक virtual file system बनाया है, ताकि agent को सिर्फ़ उसी tree के भीतर सीमित रखा जाए
हर repo के लिए एक long-running agent रखा जाता है, और permissions virtual file system से नियंत्रित की जाती हैं
project bashguard
हम virtual file system (VFS) और RAG दोनों का इस्तेमाल करते हैं
RAG का मूल डेटा की गुणवत्ता में है, जहाँ documents को अर्थपूर्ण इकाइयों में बाँटा जाता है और metadata और links बनाए जाते हैं
voyage contextual embedding के साथ हर chunk को document समेत embed किया जाता है
retrieval के समय agent links follow कर सकता है या original text का analysis कर सकता है
reranking quality का performance पर बड़ा असर पड़ता है
यह grep, bm25, jq, preview tools आदि को support करता है, और Pydantic AI के ऊपर चलता है
POSIX shell को TypeScript में emulate करके hierarchical search करना over-engineering जैसा लगता है
हर बार ls या grep चलाने पर reasoning cycle बढ़ जाती है, जिससे latency बढ़ती है
मुझे tech stack की पूरी जानकारी नहीं, लेकिन यह सवाल ज़रूर था कि नकली shell बनाने की ज़रूरत ही क्यों पड़ी
FUSE solution ज़्यादा natural लगता है
पूरी POSIX compatibility की ज़रूरत नहीं थी, सिर्फ़ read-only document exploration चाहिए था
इसलिए bash commands के सिर्फ़ कुछ हिस्सों को support करने वाला तरीका ज़्यादा सरल था
documents को file system tools से accessible बनाने के संदर्भ में, Vercel का AI SDK दिलचस्प है
npm package root में .mdx documents शामिल किए जाते हैं, ताकि agent पहले local docs में grep करे
SKILL.md उदाहरण
Mintlify जैसे startup के लिए यह अच्छी approach है, लेकिन जटिल organizations में इसकी उपयोगिता कम हो सकती है
जहाँ structure non-hierarchical हो या documents मिश्रित हों, वहाँ RAG ज़्यादा उपयोगी हो सकता है
RAG कोई सर्व-उपयोगी समाधान नहीं है, और Claude code team भी इसी निष्कर्ष पर पहुँची