Yapay zeka doküman asistanı için RAG yerine sanal dosya sistemi kurmak

 (mintlify.com)
3 puan yazan GN⁺ 25 일 전 | 1 yorum | WhatsApp'ta paylaş
  • Mevcut RAG tabanlı arama yaklaşımının sınırlarını aşmak için, dokümanlar dosya ve dizinlerden oluşan bir sanal dosya sistemi yapısına dönüştürüldü
  • Gerçek dosya kopyalamadan, Chroma veritabanı üzerinde grep, cat, ls, find komutlarını çalıştırabilen ChromaFs hayata geçirildi
  • Bu yaklaşımla oturum oluşturma süresi 46 saniyeden 100 milisaniyeye indi, ek işlem maliyeti ise yaklaşık 0 dolar seviyesine düştü
  • Erişim denetimi, dosya yolu metaverilerindeki RBAC filtrelemesi ile sağlanıyor; böylece ayrı container veya kullanıcı grubu yönetimi gerekmiyor
  • Sonuç olarak Mintlify doküman asistanı, anında yanıt veren, düşük maliyetli, stateless bir mimariyle büyük ölçekte işletilebilir hale geldi

RAG'in sınırlarını aşan sanal dosya sistemi yaklaşımı

  • Geleneksel RAG tabanlı doküman araması, yalnızca sorguyla eşleşen metin parçalarını döndürdüğü için birden fazla sayfaya yayılan yanıtlar veya hassas ifade aramaları zordu
  • Bunu çözmek için doküman yapısı, dosya sistemi gibi gezilebilen bir forma dönüştürüldü; her doküman sayfası bir dosyaya, bölümler ise dizinlere eşlendi
  • Ajan, grep, cat, ls, find komutlarıyla dokümanları doğrudan gezebiliyor; böylece geliştiricilerin bir kod tabanını ele alması gibi dokümanları arayabildiği bir yapı tasarlandı

Container darboğazı sorunu

  • Yaygın yaklaşım, ajana gerçek bir dosya sistemi sunmak için izole edilmiş sandbox ortamı oluşturmak ve depoyu kopyalamak
  • Ancak frontend asistanında oturum oluşturma gecikmesi ciddi hale geliyor ve p90 oturum oluşturma süresi yaklaşık 46 saniyeye ulaşıyor
  • Aylık 850 bin görüşme baz alındığında, en düşük yapılandırmada bile (1 vCPU, 2GiB RAM, 5 dakikalık oturum süresi) yıllık 70 bin doların üzerinde altyapı maliyeti oluşuyor
  • Bu darboğazı kaldırmak için anında tepki veren ve düşük maliyetli çalışan bir sanal dosya sistemi gerekiyordu

Sanal kabuk uygulaması — ChromaFs

  • Gerçek bir dosya sistemi yerine yalnızca sanal bir dosya sistemi illüzyonu sunuluyor
  • Mevcut doküman verileri zaten Chroma veritabanında indekslenmiş olduğundan, bunun üzerine ChromaFs kuruldu
  • ChromaFs, UNIX komutlarını yakalayıp Chroma sorgularına dönüştürüyor
  • Sonuç olarak oturum oluşturma süresi 46 saniyeden 100 milisaniyeye düştü, ek işlem maliyeti ise yaklaşık 0 dolar oldu
Metric Sandbox ChromaFs
P90 Boot Time ~46 saniye ~100ms
Marginal Compute Cost ~$0.0137/görüşme ~$0
Search Mechanism disk taraması DB metaveri sorgusu
Infrastructure Daytona gibi harici sandbox'lar mevcut DB'nin yeniden kullanımı
  • just-bash (Vercel Labs) tabanlı olarak geliştirildi ve grep, cat, ls, find, cd komutlarını destekliyor
  • just-bash'in IFileSystem arayüzü kullanılarak, boru hattı işleme ve flag mantığı korunurken dosya erişim çağrıları Chroma sorgularına dönüştürülüyor

Dizin ağacını bootstrap etme

  • ChromaFs'in çalışmadan önce hangi dosyaların var olduğunu bilmesi gerektiğinden, tüm dosya ağacı Chroma koleksiyonunda sıkıştırılmış JSON(__path_tree__) biçiminde saklanıyor
  • Sunucu başlatılırken bu veri alınıp iki bellek yapısına geri yükleniyor
    • dosya yolları için Set<string>
    • her dizinin çocuk listesi için Map<string, string[]>
  • Sonrasında ls, cd, find komutları ağ çağrısı olmadan yerel bellekte anında işleniyor ve aynı site için sonraki oturumlarda önbelleğe alınmış ağaç yeniden kullanılıyor

Erişim denetimi

  • Yol ağacında isPublic ve groups alanları bulunuyor; kullanıcı oturum token'ına göre yalnızca erişilebilen dosyalar bırakılıyor
  • Erişim yetkisi olmayan dosyalar ağaçtan tamamen çıkarılıyor; böylece ajan bu yolların varlığından haberdar olmuyor
  • Mevcut sandbox yaklaşımında bunun için Linux kullanıcı grupları, chmod, container ayrımı gibi unsurlar yönetilmek zorundaydı; ChromaFs'te ise yalnızca basit filtreleme mantığıyla RBAC uygulanıyor
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 ✗

Doküman parçalarını yeniden birleştirme

  • Chroma'da saklanan dokümanlar, embedding için birden fazla parçaya bölünmüş durumda
  • cat /auth/oauth.mdx çalıştırıldığında, aynı page slug'ına sahip tüm parçalar alınarak chunk_index sırasına göre sıralanıp birleştiriliyor
  • Sonuç önbelleğe alınıyor; böylece tekrarlanan grep iş akışlarında veritabanına yeniden sorgu gönderilmiyor
  • Büyük OpenAPI spesifikasyonları gibi içerikler lazy file pointer olarak kaydediliyor ve yalnızca erişildiğinde S3'ten getiriliyor
  • Tüm yazma işlemleri EROFS (salt okunur dosya sistemi) hatası döndürerek stateless ve güvenli yapıyı koruyor

Grep optimizasyonu

  • grep -r komutu basit ağ taramalarında çok yavaş olduğundan, iki aşamalı filtreleme yapısıyla optimize edildi
      1. aşama: Chroma sorguları ($contains, $regex) ile aday dosyalar seçiliyor
      1. aşama: Bu dosyalar Redis önbelleğine önceden çekilip, just-bash içinde bellek içi hassas filtreleme yapılıyor
  • Böylece büyük ölçekli recursive aramalar bile milisaniyeler içinde tamamlanabiliyor

Sonuç

  • ChromaFs, günde 30 binden fazla isteği ve yüz binlerce kullanıcıyı barındıran Mintlify doküman asistanını çalıştırıyor
  • Sandbox'ların yerini alarak anında oturum oluşturma, 0'a yakın ek maliyet, yerleşik RBAC ve stateless mimari sağlıyor
  • Mintlify'nin tüm doküman sitelerinde doğrudan kullanılabiliyor (mintlify.com/docs)

İlgili okumalar

1 yorum

 
GN⁺ 25 일 전
Hacker News görüşleri

  • Dosya sistemi tabanlı aramaya yeniden ilgi gösterilmesinin nedeni, embedding tabanlı olmayan anlamsal arama biçimini yeniden keşfediyor olmamız
    Bir kütüphane görevlisinin kitapları konuya göre raflara dizmesi gibi, dosyaları alan bazında düzenlemek daha yorumlanabilir
    Bu arama yöntemi çok eskiden beri vardı, ama değerini ancak şimdi yeniden fark ediyoruz
    İlgili blog yazısı

    • Geleneksel kütüphanecilik bilgi mimarisindeki derin kalıpları zaten yakalamıştı
      Pixar'ın Ralph Wrecks The Internet filminde de bu kavram iyi ifade edilmişti
      İlgili tweet 1, İlgili tweet 2
    • 400'den fazla Python dosyası olan bir kod tabanında çalışıyorum ve embedding tabanlı RAG sık sık kelimeleri benzer olan alakası olmayan kod parçalarını getiriyordu
      Bunun yerine ajanı doğrudan dizin ağacını keşfetmeye yönlendirdiğimde, 30 saniye içinde modül yapısını anlayıp doğru dosyaları istemeye başladı
      Dizin hiyerarşisinin başlı başına insanlar tarafından oluşturulmuş bir bilgi grafiği olduğunu unutmuştuk
    • LLM arama sistemi geliştirirken sonunda yeniden ters dizin (concordance) icat etmiş oldum
      Bu, Google'ın inverted index kavramıyla aynı şey; yani aslında tamamen yeni değil
    • Birileri RAG'in mutlaka vektör araması kullanması gerektiğini varsaydı ve herkes de sanki o akışı takip etti
    • AI asistanları sonuçta LLM'in otomatik tamamlama yaptığı sanal karakterler olduğundan, insan dilsel etkileşimi gibi yorumlanabilir mekanizmalar daha avantajlı

  • RAG bana içeriği doğrudan okuma imkanı vermedi
    Bu yüzden artık bilgiyi Markdown tabanlı statik sayfalarda birleştiriyor, düzenledikten sonra bir JSON dosyası oluşturup ajanın bu kaynağı sorgulamasını sağlıyorum
    Açıklama bağlantısı

  • Dosya sistemi aramasının RAG'den daha iyi olduğu iddiası kafa karıştırıcı
    grep gibi anahtar kelime aramaları eski yöntemler, RAG ise vektör araması kullanıyor
    Ama veritabanlarında içerik hiyerarşi, etiketler ve keyfi yapılarla indekslenebilir
    Arama da anahtar kelime, vektör, tf-idf, BM25 gibi farklı kombinasyonlarla yapılabilir
    Dosya sistemine geri dönmek, 60'ların teknolojisine dönüyormuşuz gibi hissettiriyor

    • Doğru ama pratikte ajan dosya tabanlı çalıştığında performans daha iyi oluyor
      CLI tabanlı kodlama ajanları dosyalara erişirken çok daha akıllı davranıyor
    • Ben veritabanı tabanlı agentic search ile iyi sonuçlar aldım
      Buradaki kilit nokta, ajanın çeşitli ad-hoc sorguları doğrudan çalıştırabilmesi
      Embedding ve tam metin aramasını birlikte destekleyen bir DB'de ajan özgürce sorgu çalıştırabiliyorsa bu yeterince agentic oluyor
    • Aslında çoğu dosya sistemi de içeride veritabanı yapıları kullanıyor
      Dosya sistemini DB gibi kullanmak yeni bir şey değil
    • Sanırım yazıda anlatılan yaklaşım da sonuçta bu
    • Ajanın birden fazla veri kaynağını doğrudan keşfetmesini sağlamanın daha iyi olduğunu düşünüyorum

  • Aylık 850 bin görüşmenin yılda 70 bin dolardan fazlaya mal olduğu hesabı tuhaf geldi
    CPU ve belleğin nereye gittiğini merak etmiştim; sebep Vercel Labs'ın just-bash tabanlı ChromaFs imiş

    • Her ajana izole bir container verirseniz, hiçbir şey yapmasa bile bellek işgal etmeye devam eder ve maliyet büyür

  • CLI uygulamalarının yeniden yükselişe geçtiği bir dönemin tadını çıkarıyorum
    FUSE ile Mac'in gerçek dosya sistemini yansıtan bir sanal dosya sistemi kurup ajanı yalnızca o ağaçla sınırlıyorum
    Her repo için uzun süre çalışan bir ajan var ve yetkiler sanal dosya sistemi üzerinden kontrol ediliyor
    bashguard projesi

  • Biz hem sanal dosya sistemi (VFS) hem de RAG kullanıyoruz
    RAG'in özünde veri kalitesi var; belgeleri anlamsal birimlere bölüp metadata ve linkler üretiyoruz
    voyage contextual embedding ile her parçayı belgeyle birlikte embedding'e dönüştürüyoruz
    Arama sırasında ajan bağlantıları takip edebiliyor veya orijinal metni analiz edebiliyor
    reranking kalitesi performansı ciddi biçimde etkiliyor

    • Bizim VFS'miz Postgres tabanlı ve dosya/dizin biçiminde projekte ediliyor
      grep, bm25, jq, önizleme araçları gibi şeyleri destekliyor ve Pydantic AI üzerinde çalışıyor

  • POSIX shell'i TypeScript ile emüle ederek hiyerarşik arama yapmak aşırı mühendislik gibi görünüyor
    Her seferinde ls ya da grep çalıştırıldığında çıkarım döngüsü arttığı için gecikme (latency) yükseliyor

    • Eğer yaklaşım chunk'ların üstüne FUSE koymak ise shell emülasyonuna gerek olmayabilir

  • Teknik yığını tam bilmiyorum ama neden özellikle sahte bir shell yaptıklarını merak ettim
    FUSE çözümü daha doğal görünüyor

    • Aslında FUSE adaptörü düşünülmüş ama çok yavaşmış
      Tam POSIX uyumluluğu gerekmiyordu; yalnızca salt okunur belge keşfi gerekiyordu
      Bu yüzden yalnızca bazı bash komutlarını destekleyen bir yaklaşım daha basitti

  • Belgeleri dosya sistemi araçlarıyla erişilebilir kılma bağlamında, Vercel'in AI SDK yaklaşımı ilginç
    npm paketinin köküne .mdx belgeleri ekleyip ajanın önce yerel belgelerde grep yapmasını teşvik ediyor
    SKILL.md örneği

  • Mintlify gibi startup'lar için iyi bir yaklaşım olabilir ama karmaşık organizasyonlarda pratikliği düşebilir
    Yapının hiyerarşik olmadığı ya da belgelerin birbirine karıştığı ortamlarda RAG daha faydalı olabilir

    • Burada kod araması gibi net bir use case olduğu için iş daha basit
      RAG her işe uyan sihirli çözüm değil ve Claude Code ekibi de aynı sonuca varmış
    • OCR teknolojisi yeterince geliştiği için, belgeler OCR ile işlenebiliyorsa bu yaklaşım da genellenebilir
    • Karmaşık belge organizasyonunun üstüne VFS eklemek sonuçta sadece indeksleyicinin bir türevi olur ve erişim kontrolü yoksa güvenlik sorunları doğar