Semantic code search için üretim ölçeğinde RAG pipeline'ı: JetBrains notları
JetBrains, kod araması için geliştirdiği Air Context sisteminin ikinci bölümünde vektörlerin nasıl saklandığını ve milisaniyeler içinde nasıl getirildiğini anlatıyor. Yazı, filtreli ANN aramasının tuzaklarını, Git ile senkron kalan artımlı indekslemeyi ve retrieval işini bir alt ajana devretmenin maliyet faydasını somut olarak gösteriyor.
Kilit noktalar
- HNSW gibi ANN indeksleri hızlıdır ama recall garantisi vermez; küçük aday kümesi üzerinde exact arama ile birleştirilen hibrit yaklaşım dengeyi sağlıyor.
- Filtre + ANN birlikte zordur: HNSW grafiği predicate ile sınırlandığında kopabilir; pre-filter yüzde 100 recall verir ama indeks avantajını kaybeder.
- pgvector'ün iterative-scan modu post-filtering'in zayıflığını azaltır, ancak gecikme maliyeti ve öngörülemezlik getirir.
- Artımlı indeksleme için dizin ağacını yansıtan Merkle ağacı ve chunk içerik hash'i ile deduplikasyon kullanılıyor.
- HNSW build'leri snapshot tamamen yazıldıktan sonra shard başına en fazla bir tane olacak şekilde asenkron çalıştırılıyor.
- Retrieval, read-only araçlarla sınırlı ve daha ucuz bir modelde çalışabilen bir sub-agent'a devredilerek ana ajanın context'i korunuyor.
JetBrains, kod araması için geliştirdiği Air Context adlı RAG sisteminin ikinci yazısında depolama ve getirme katmanına odaklanıyor. Yaklaşık en yakın komşu (ANN) indeksleri tek başına yetmiyor: depo, klasör izinleri gibi filtreler HNSW grafiğinin gezintisini bozabildiği için pre-filter, indekse gömülü metadata ve post-filter stratejileri karşılaştırılıyor; Qdrant ve turbopuffer gibi çözümler filtreyi indeksin bir parçası sayarken pgvector'ün iterative-scan modu gecikme bedeliyle dengeyi kuruyor. Yazı, ucuz bir ANN geçişinin ardından küçük aday kümesi üzerinde exact arama yapılan hibrit yaklaşımın iyi sonuç verdiğini aktarıyor.
İndeksleme tarafında çözüm, dizin yapısını yansıtan Merkle ağacı ve chunk hash'i ile tekrar eden vektörleri eleyip yalnızca değişen kümeleri işlemek; HNSW kurulumu ise snapshot tamamen yazıldıktan sonra shard başına tek build ile arka planda çalışıyor. Arama sonuçları reranker ile birleştiriliyor, retrieval adımı read-only bir sub-agent'a devredilerek ana ajanın context'i küçük tutuluyor. Kendi ajan araçlarını yazan ekipler için somut bir mimari referans.
Gerçek dünyada kullanımı
- Kendi kod tabanınız üzerinde çalışan bir kod arama aracı veya MCP server'ı yazarken filtreli vektör aramasını doğru kurgulamak
- Çok kiracılı bir geliştirici platformunda depo ve klasör bazlı yetki filtrelerini vektör aramasına zarar vermeden uygulamak
- Sürekli commit gelen büyük monorepo'larda tüm kodu yeniden indekslemeden arama indeksini güncel tutmak
- Claude Code gibi bir asistanda kod keşfini ayrı bir sub-agent'a vererek token maliyetini ve ana context kirliliğini azaltmak
Neden önemli
Kod asistanlarının kalitesi büyük ölçüde doğru bağlamı bulmasına bağlı; bu yazı, retrieval katmanını üretim ölçeğinde kurarken hangi ödünleşimlerin gerçekten acıttığını gösteriyor.