deniz.in

Piyasalar

Hava durumu

Hava durumu yükleniyor

· kaynak dev.to (home feed)

AWS S3 Vectors, çok kiracılı RAG'da sessiz sonuç kaybını önlemek için metadata ön-filtrelemesi ekledi

AWS S3 Vectors artık metadata filtrelerini benzerlik aramasından önce çözümlüyor. Eski mod, seçici filtrelerle istenenden daha az veya daha kötü sonuçları sessizce döndürüyordu — çok kiracılı RAG hatlarında yaygın bir tuzak.

AWS S3 Vectors, çok kiracılı RAG'da sessiz sonuç kaybını önlemek için metadata ön-filtrelemesi ekledi

30 Eylül 2026'da AWS, S3 Vectors için metadata ön-filtrelemesini kullanıma sundu ve gözden kaçması kolay bir hata modunu düzeltti: sorguyu tek bir kiracıya sınırlandırma gibi seçici bir filtreyle servis, istenenden daha az sonuç döndürebiliyor ya da gerçek en yakın komşular olmayan sonuçları, hiçbir hata vermeden sunabiliyordu. Bir dev.to yazısına göre güncelleme, ek maliyet olmaksızın iki index modu, yeni bir prefix operatörü ve sorgu başına bir koşul limiti getiriyor.

Eski mod sonuçları nasıl kaybediyordu

Ölçekte vektör araması yaklaşiksaldır: motor, sorguyu her vektörle karşılaştırmak yerine umut verici adaylardan oluşan sınırlı bir havuzda arama yapar. AWS'nin artık CLASSIC mod dediği yapıda metadata filtreleri, bu arama sürerken değerlendiriliyordu. Filtre corpus'un büyük bir bölümüyle eşleştiğinde adayların çoğu ayakta kalır ve sonuçlar doğru görünür. Filtre yüksek oranda seçici olduğundaysa incelenen adayların çoğu elenir, arama bütçesi tükenir ve çağıran taraf istenen sayıdan daha az sonuç alır — ya da filtrelenmiş alt küme içindeki en iyi eşleşme olmayan, ama tam sayıda bir sonuç seti. Yazıda aktarılan AWS'nin kendi örneği şöyle: 8 milyon destek talebinde tek bir müşterinin 400 talebi varsa, ön-filtreleme o 400 kayıt içinde arama yapar; 8 milyonun tamamından çekilen adaylar yerine.

dev.to yazısı, AWS re:Post'taki bir ölçüme işaret ediyor: bir milyon sentetik vektörde recall@10, filtresiz durumda 0.86 iken yüzde 10 filtre seçiciliğinde 0.83'e, yüzde 1'de 0.42'ye ve yüzde 0.01'de 0.15'e düşüyor. Yaygın geçici çözüm, veriyi kiracı, dil veya bölge gibi düşük kardinaliteli alanlara göre ayrı index'lere bölmekti; bu yaklaşımın 15–31 recall puanı geri kazandırdığı, karşılığında çok daha fazla index işletme maliyeti getirdiği bildiriliyor. Yazı ilgili bir noktaya da dikkat çekiyor: sonuç sayısı hiçbir zaman kalite sinyali değildi. CLASSIC modda 10 sonuç almak, bunların en iyi 10 sonuç olduğunu hiç garantilemiyordu.

ENHANCED modu ve geçiş yolu

Yeni ENHANCED mod önce filtreyi çözümler, ardından benzerlik aramasını eşleşen alt küme üzerinde çalıştırır. AWS'ye göre bu, filtre seçici olduğunda yüzde 500'e kadar daha fazla eşleşen vektör döndürüyor. 30 Eylül 2026 veya sonrasında oluşturulan vektör bucket'ları yalnızca ENHANCED olabilir. Daha önce oluşturulan bucket'lar, açık bir UpdateIndexMode çağrısına kadar CLASSIC modda kalır ve verinin yeniden alınması gerekmez; CLI, SDK veya API üzerinden CLASSIC moduna dönmek mümkündür, ancak konsoldan değil. Ekipler ayrıca bir index'i değiştirmeden önce queryMode'u ENHANCED olarak ayarlayarak davranışı sorgu bazında deneyebilir; yazı, her iki modu gerçek verinin bir test kopyasında ölçmek için — index'li sonuçları vektörlerden doğrudan hesaplanan gerçek top-K ile karşılaştıran — bir brute-force recall test aracı da içeriyor.

Filtre değişiklikleri ve limitler

Filtre sözdizimi bu noktanın dışında değişmedi; tek ek, yalnızca ENHANCED index'lerde kullanılabilen ve yola göre düzenlenmiş koleksiyonlara uyan bir string-prefix operatörü olan $startsWith. ENHANCED index'ler ayrıca filtreleri değer başına sayılan 100 koşulla sınırlıyor — üç bölge içeren bir in-list üç koşul tüketiyor. Yazı, dinamik filtreleri uzun izin listelerinden — örneğin bir kullanıcının erişebildiği her projeden — oluşturan ekipleri uyarıyor: limiti aşmak doğrulama hatası ürettiği için geçiş öncesinde bu filtreleri denetlemek gerekiyor.

Vektör başına metadata limitleri değişmedi: vektör başına en fazla 40 KB metadata, bunun en fazla 2 KB'ı filtrelenebilir; en fazla 50 anahtar ve index oluşturulurken sabitlenen en fazla 10 filtrelenebilir olmayan anahtar. Öneri, filtre alanlarını kısa tutmak ve chunk metnini filtrelenebilir olmayan metadata'da saklamak — Bedrock Knowledge Bases'in ayrılmış anahtarlarla zaten izlediği bir örüntü.

Bir izin tuzağı

Bunu bir retrieval servisine entegre eden ekipler için yazı bir IAM detayına dikkat çekiyor: QueryVectors izni tek başına yalnızca filtresiz ve metadata döndürmeyen sorgularda çalışır. Bunlardan birini eklemek GetVectors iznini de gerektirir; aksi halde çağrı 403 ile başarısız olur.

Neden önemli

Sessiz kalite düşüşü, RAG sistemlerinde yakalanması en zor hatadır: hiçbir şey hata vermez, model sadece olması gerekenden daha az bağlamla yanıtlar; ve küçük kiracıları olan çok kiracılı kurulumlar, CLASSIC modun en çok bozulduğu yerler tam da burasıdır. S3 Vectors üzerinde RAG çalıştıran ekipler index modlarını kontrol etmeli, geçiş öncesi ve sonrası kendi verileri üzerinde recall'ı ölçmeli, dinamik olarak üretilen filtrelerin 100 koşulluk sığdığını doğrulamalı ve IAM politikalarını güncellemelidir. Özellik ek ücret taşımadığı ve S3 Vectors sunan tüm ticari bölgeler ile Çin bölgelerinde kullanılabilir olduğu için, benimsemenin ana maliyeti lisanslama değil, doğrulamadır.

  • #aws
  • #s3-vectors
  • #vector-search
  • #rag
  • #cloud

İlgili yazılar