Qdrant 1.20, BM25 anahtar kelime sıralamasını doğrudan tam metin indeksine ekliyor

BM25 puanlaması tam metin indeksine taşınıyor

Açık kaynak vektör veritabanı Qdrant 1.20 sürümünü yayınladı; öne çıkan değişiklik, anahtar kelime eşleşmelerinin artık payload alanlarında zaten saklanan metin kullanılarak tam metin indeksinin kendisinde BM25 ile puanlanması. Sürüm yazısını özetleyen dev.to'ya göre sürüm 22 Ekim 2026'da çıktı.

Şimdiye kadar Qdrant'ta BM25, bir yan süreç anlamına geliyordu: belgeler sparse vektörler üretmek için bir embedding modelinden geçiriliyor, bunlar yoğun vektörlerin yanında saklanıyor ve derlem her değiştiğinde yeniden kodlanması gerekiyordu. Ortalama belge uzunluğu dahil puanlama istatistikleri saklanan vektörlere gömülüyordu, dolayısıyla koleksiyon ilerledikçe eskidiyorlardı.

Sürüm 1.20 bu istatistikleri koleksiyonun kendisinden türetiyor; bu da puanlamanın ilk sorgudan itibaren ve belgeler geldikçe ya da değiştikçe doğru kalmasını sağlıyor. Sparse-vektör yolu hâlâ destekleniyor ve sürümde anlatılan geçiş veriyi yerinde tutuyor: bm25 puanlama tipiyle bir tam metin indeksi oluşturun, sparse modelin kullandığı metin işleme ayarlarını yapılandırın, ardından sparse sorguları metin sorgularıyla değiştirin.

Sorgu yüzeyi normal Query API içinde yer alıyor, böylece bir metin sorgusu hibrit kurulumlarda yoğun vektör aramasıyla birleşebiliyor ve başka bir sorgunun getirdiği noktaları yeniden puanlayabiliyor. BM25 k ve b parametreleri indekse gömülmek yerine sorgu başına belirleniyor, bu yüzden uzunluk normalizasyonunu ayarlamak yeniden inşa gerektirmiyor ve tek bir indeks birkaç sorgu profiline hizmet edebiliyor.

Kaynak kodu için bir tokenizer

Varsayılan kelime tokenizer'ı metni boşluk ve noktalama işaretlerinden bölüyor; bu düz yazıya uygun ama tanımlayıcılarda başarısız: getUserName tek bir token oluyor, bu yüzden user name araması hiçbir şey bulamıyor. Yeni kod tokenizer'ı tanımlayıcıları alt çizgi ve harf durumu sınırlarından, kısaltmalar dahil, bölüyor; aynı zamanda tanımlayıcının tamamını da indeksliyor. Sürüme göre getUserName, get_user_name ve user name artık birbirine ulaşıyor ve hashmap sorgusu HashMap'i buluyor. Tam metin indeksinde BM25 ile birlikte kullanıldığında, payload metninden doğrudan sıralı kod araması mümkün oluyor; bu, kendi sunucunuzda barındırılan bir dokümantasyon veya depo arama kutusu için bir seçenek.

İç içe filtreler için eleman başına indeksler

İç içe filtreler belge depolarında sorunlu durumdur: bir payload nesne dizisi tutar ve filtre, tek bir elemanın aynı anda birkaç koşulu sağlayıp sağlamadığını sorar; örneğin tek bir teklifin hem belirli bir mağazayı hem fiyatı taşıması. Tek tek alanlardaki indeksler yalnızca aday listesini kısaltabiliyordu; Qdrant eşleşmeyi doğrulamak için her aday payload'ı, çoğu zaman diskten, yüklemek zorundaydı.

Sürüm 1.20, payload indeks tiplerine bir nested parametresi ekleyerek her dizi elemanını ayrı ayrı saklayan eleman başına bir indeks üretiyor. İç içe bir filtredeki her koşul, aynı dizide eleman başına indeksi olan bir alanı hedeflediğinde filtre yalnızca indekslerden yanıtlanıyor. Qdrant'ın kendi ölçümleri, payload'lar zaten bellekteyken 100.000 nokta üzerinde üç iç içe filtrede 7 ila 38 kat daha hızlı yürütme gösteriyor; bellekte olmadıklarında farkın daha da büyümesi bekleniyor.

Turbo16 ve Turbo8

İki yeni veri tipi vektör depolamayı sıkıştırıyor. turbo16 önce TurboQuant rotasyonunu uygulayıp değerleri koordinatlara yayıyor, ardından her vektörü 16 bitlik tamsayı ızgarasında saklıyor: boyut başına 2 bayt, Qdrant'ın ölçümüne göre 13 veri setinde float16'ya göre 7,5 kat daha düşük yeniden yapılandırma hatası ve 12 arama kıyas veri setinin tamamında float32'ye göre 0,001 içinde recall@10. turbo8 her boyutu tek bir baytta saklıyor; 11 veri setlik bir kıyasta aramalar float16'ya göre 1,1 ila 2,4 kat daha hızlı tamamlandı, recall yarı boyutta float16'ya yakın geldi ve turbo4'e göre kazanç en düşük boyutlarda en büyüktü. 8 bit kodlama bits8 üzerinden quantization olarak da mevcut; yaklaşık dört kat sıkıştırma sağlıyor (bits4 sekiz kat sağlıyor ve varsayılan olarak kalıyor).

Yükseltme notları

dev.to'ya göre iki değişiklik, yükseltmeden sonra küme davranışını değiştiriyor: dahili kimlik doğrulama peer gRPC portunu varsayılan olarak güvenli hale getiriyor ve inline storage, HNSW indeksinin bellek katmanını devralıyor. Yalnızca salt okunur bir anahtarla yapılandırılmış kümeler yükseltme sırasında bir karar vermek zorunda; bu yüzden yükseltme planı okunacak ilk belge olmalı. Sürüm ayrıca GCS ve Azure Blob Storage üzerinde snapshot'lar, stdout veya stderr'e yazılan audit log'lar, koleksiyon oluşturma zamanları, daha güvenli replika kaldırma, yerel saatli log zaman damgaları ve substring eşleştirme içeriyor.

Neden önemli

Anahtar kelime sıralaması genellikle vektör aramasının içinde değil yanında yaşadı; kurulacak, eşitlenecek ve yeniden kodlanacak bir sparse-vektör hattıyla. BM25'i Qdrant'ın zaten bakımını yaptığı tam metin indeksine taşımak bu yükü ortadan kaldırıyor ve hibrit aramayı bir entegrasyon projesinden yerel bir sorguya dönüştürüyor. Vektörlerin içinde donmuş halde durmak yerine koleksiyonu izleyen istatistikler, değişen derlemelerde sıralama kalitesinin korunması anlamına geliyor; sorgu zamanı k ve b ayarı da operasyonlardan bir yeniden inşayı daha çıkarıyor. Daha önce disk okumalarına zorlayan iç içe filtre durumları için eleman başına indeksleri ve ayak izinin küçük bir bölümünde recall'ı float32'ye yakın tutan sıkıştırılmış vektör tiplerini ekleyin; Qdrant kendini daha da genel bir erişim motoruna doğru yatırıyor — üstelik açık kaynak ve kendi sunucunuzda barındırılabilir kalmaya devam eden bir tane.