AI दस्तावेज़ assistant के लिए RAG के विकल्प के रूप में virtual filesystem का निर्माण

 (mintlify.com)
3 पॉइंट द्वारा GN⁺ 27 일 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • मौजूदा 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)

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.