Manticore Search, vektör aramasındaki sessiz kesme sorununu çözmek için yerleşik chunking özelliği ekledi

Manticore Search chunking işlemini veritabanına taşıdı

Manticore Search, otomatik vektör araması için yerleşik chunking özelliği ekleyerek uzun belgelerin embedding öncesi sessizce kesilmesi sorununu çözdü. dev.to'da yeniden yayınlanan bir Manticore Search blog yazısına göre, model destekli vektör sütunlarına eklenen yeni chunk_strategy seçeneği her belgeyi INSERT aşamasında parçalara ayırıyor, her parçayı ayrı ayrı embed ediyor ve tüm parçalar arasında arama yapıyor — harici bir splitter kütüphanesi, ingest hattı veya parçaları tutmak için ayrı bir tablo gerekmeden.

Çözülen sorun neydi

Embedding modelleri sabit sayıda girdi token'ı kabul eder; bu sayı çoğunlukla 512 civarındadır ve limiti aşan her şey yok sayılır. Manticore sorunu 5.000 token'lık bir belgenin 512 token'lık bir modele verilmesiyle örneklendiriyor: yaklaşık 380 kelime okunuyor, geri kalan 3.600 kelime atılıyor ve insert yine de başarıyla tamamlanıyor. Arama çalışıyor gibi görünür, ancak belgenin ilerleyen bölümlerindeki hiçbir içerik asla geri getirilemez ve ortaya çıkan vektör belgenin bütününü temsil etmeyebilir.

Şimdiye kadar bilinen standart geçici çözüm, bölme işlemini uygulama kodunda halletmekti: belgeleri yukarı akışta parçalara ayırmak, her parçayı embed etmek ve parça düzeyindeki sonuçları sorgu düzeyinde bir aggregation ile belge sonuçlarında birleştirmek.

Beş strateji, iki sütun tipi

Özellik bir hattan çok tablo tanımında yapılandırılıyor. Embedding modeli bağlı bir vektör sütununa chunk_strategy eklemek davranışı etkinleştiriyor; yanında max_tokens (parça boyutu), overlap_tokens (komşu parçaların paylaştığı token'lar) ve max_chunks (belge başına üst sınır) seçenekleri bulunuyor.

Beş strateji var:

• truncate — önceki varsayılan; tek bir vektör tutar ve model penceresinin ötesindeki metni atar
• mean — tüm parçaların embedding'lerinin ortalamasını alan tek bir vektör
• fixed, recursive ve sentence — belge başına çok sayıda vektör saklayan, parça farkında olan stratejiler

Yazıya göre truncate ve mean belge başına tek vektör üretiyor ve float_vector sütununda çalışıyor; diğer üçü ise float_vector_array sütunu gerektiriyor.

Önemli bir tasarım kararı, bir belgenin tek bir arama sonucu olarak kalması. Bireysel parçalar indeks içinde rekabet eder, ancak Manticore belgeyi yalnızca bir kez döndürür; knn_dist() en yakın parçaya olan uzaklığı bildirir ve k parametresi parçaları değil belgeleri sayar. Sorguların kendisi asla parçalanmaz çünkü bütün halinde embed edilecek kadar kısadırlar.

Ölçülen kazançlar ve ölçülen maliyetler

Manticore ekibi özelliği kendi kılavuzları üzerinde benchmark'a tabi tuttu: 189 sayfa ve yaklaşık 298.000 kelime. Yanıtları modelin girdi penceresinin ötesinde bulunan sorular için recall@5 %55,1'den %83,3'e yükseldi ve MRR 0,44'ten 0,70'e iyileşti. Ödünleşim ise kaynak kullanımı: her parça HNSW indeksine kendi vektörünü eklediği için RAM yaklaşık 2,5 kat, ingest süresi yaklaşık dört kat artıyor.

Neden önemli

Sessiz kesme, retrieval destekli sistemlerde fark edilmesi en zor hata türlerinden biri: hiçbir şey hata vermez, arama makul sonuçlar döndürür ve modelin token penceresinin ötesindeki her şey görünmez kalır. Buna karşı korunmak, uygulama kodunda bir chunking hattına ve sonuç birleştirme mantığına sahip olmayı gerektiriyordu. Chunking işlemini motora taşıyarak — embedding modelini çalıştırmayı daha önce yaptığı gibi — Manticore bu yapıyı ortadan kaldırıyor; bedeli olan RAM ve ingest hızındaki kayıp artık açık ve ayarlanabilir durumda. Runbook, rehber ve postmortem gibi uzun iç belgeler üzerinde semantik arama çalıştıran ekipler için benchmark, önceden asla bulunamayan içerikte önemli bir recall iyileşmesine işaret ediyor.