Geliştirici, 4 saniyelik RAG sorgularını pgvector HNSW kilit çekişmesine ve normalize edilmemiş embeddinglere dayandırdı

Duvara toslayan bir RAG bellek katmanı

RAGFlow'u — retrieval ile agent yeteneklerini birleştiren açık kaynak bir engine'u — sistemine entegre eden bir geliştirici, vektör aramanın sistemin darboğazı haline geldiği bir production olayının firsthand anlatısını yayımladı. dev.to'da yazan Samuel Oakley'ye göre agent bellek hattı saniyede yaklaşık 50 eşzamanlı doküman eklemesinde tıkanıyor, sorgu gecikmesi 80 milisaniyeden dört saniyenin üzerine çıkıyor ve recall yaklaşık yüzde 30 düşüyordu. Altındaki veri deposu, pgvector extension'ı kurulmuş PostgreSQL'di.

Teşhis, iki bağımsız nedene işaret etti: yoğun yazma sırasında HNSW graph index'i üzerindeki çekişme ve normalizasyon yapılmadan saklanan embeddingler.

HNSW kilitleri eşzamanlı yazmaları boğdu

Gönderiye göre pgvector'ın HNSW index'i yüksek eşzamanlılıkta yazmayı iyi karşılamıyor. Toplu ingestion sırasında INSERT ifadeleri birbirini bloke etmeye başladı; sıraya giren yazmalar üst üste biriktiği ve gecikme katlandığı bir konvoy etkisi oluştu.

Ekip bağlantı ayarlamaya yönelmek yerine index yapısını yeniden düzenledi. 100 list sayısıyla oluşturulmuş bir IVFFlat index, eklemeleri aynı bloklama davranışı olmadan karşılıyor; ayrı ayarlanmış bir HNSW index'i (m = 16, ef_construction = 64) okuma sorgularına hizmet veriyor. HNSW index'i, düşük trafik pencerelerinde concurrent reindex ile asenkron olarak yeniden oluşturuluyor; böylece bakım hiçbir zaman yazma yolunu durdurmuyor. Ödün, iki index'in aynı tabloda yaşaması: okuma ve yazma yollarını ayırma karşılığında depolama ve yazma amplifikasyonu ekleniyor.

Normalize edilmemiş embeddingler sessizce recall'ü vurdu

İkinci sorun daha sinsi sebebi sistem çalışmaya devam ediyordu. Pipeline, OpenAI API'sinden gelen ham embeddingleri olduğu gibi saklıyordu. pgvector'daki cosine similarity birim vektörler varsayar; değişken büyüklükler, anlamsal olarak benzer parçaların olması gerektiğinden daha kötü sıralanmasına yol açıyordu — sonuçlar gelmeye devam ediyordu, sadece daha kalitesiz olanları.

Çare, yazma anında L2 normalizasyonu oldu: her embedding vektörü eklenmeden önce normuna bölünüyor. Değişiklikten sonra yazarın test setinde recall@10 değeri 0.68'den 0.91'e yükseldi.

Tam eşleşmeler için hibrit arama

Gecikme ve recall dengelenince ekip kalan bir zayıflığa el attı: saf vektör araması tam anahtar kelime eşleşmelerini kaçırıyor. pgvector benzerlik aramasını PostgreSQL'ün native tam metin aramasıyla yan yana çalıştıran, sonra iki sıralı listeyi geleneksel 60 sabitiyle reciprocal rank fusion kullanarak birleştiren bir hibrit retrieval uyguladılar. Gönderiye göre A/B testlerinde hibrit kurulum cevap ilginçliğini yüzde 23 artırdı.

Ölçülen sonuç

Tüm değişikliklerden sonra gönderi şunları raporluyor:

• Insert throughput: saniyede 50'den 180'e
• Sorgu p95 gecikmesi: 4.2 saniyeden 120 milisaniyeye
• Recall@10: 0.68'den 0.91'e

Neden önemli

Bir RAG sistemi kötü ya da yavaş cevap verdiğinde içgüdü çoğu zaman modeli suçlamaktır. Bu olay yararlı bir karşı örnek: retrieval katmanı — index seçimi, eşzamanlılık altındaki davranışı ve temel embedding hijyeni — hem gecikmeyi hem cevap kalitesini domine etti. pgvector üzerinde agent belleği kurlayan ekipler için gönderi somut bir rehber sunuyor: yazma ve okuma index'lerini ayırın, embeddingler veritabanına ulaşmadan önce normalize edin ve vektör aramasını tek başına birine bel bağlamak yerine anahtar kelime aramasıyla eşleştirin. Oakley'nin kapanış tavsiyesi, bellek katmanını erken stres testinden geçirmek; çünkü index stratejisi ve embedding hijyeni, sonuç üzerinde model seçiminden daha belirleyiciydi.