Manticore Search, uzun belgelerde vector search sorununu çözmek için yerleşik chunking özelliği ekledi

Sessiz kesme sorunu

Manticore Search, vector search özelliğine otomatik belge chunking yeteneği ekledi; normalde harici bir ingest pipeline'ında yaşanan işleri — belgeleri bölme, her parçayı gömme (embedding) ve eşleşen parçaları üst belgelerine geri birleştirme — veritabanının tablo tanımının içine taşıdı. Hacker News'in ana sayfasına ulaşan şirket blog yazısına göre bu değişiklik, gözden kaçması kolay bir başarısızlık modunu hedefliyor: uzun belgelerin içeriğinin büyük kısmının, embedding modelinin girdi penceresi tarafından sessizce kaybedilmesi.

Yazı tipik bir kurulumu anlatıyor: otomatik embedding yapılan bir tablo, buraya metin eklemek modeli tetikliyor ve vector sütunu sizin için dolduruluyor. Örnek model olan Xenova/all-MiniLM-L6-v2, 512 tokenlik bir girdi penceresine sahip. 4.000 kelimelik bir belge — yaklaşık 5.000 token — yüklediğinizde insert başarılı oluyor ve aramalar çalışıyor gibi görünüyor. Ama model yalnızca ilk 380 kelimeyi okudu; sonrası hiçbir zaman geri getirilemez ve hiçbir yerde uyarı görünmez. Ortaya çıkan vector belgenin bütününü de temsil etmeyebilir. Yazı bunu, TLS sertifikasının replication portunda rotasyonunu anlatan son bölümü pencerenin çok ötesinde kalan bir yedekleme-geri yükleme runbook'u örneğiyle gösteriyor; belge tamamen indekslenmiş görünse de bu bölüm geri getirilemezdi.

Tablo tanımında chunking

Çözüm, model destekli vector sütunlarında yeni chunk_strategy ayarı:

sql CREATE TABLE docs ( title text, content text, chunks float_vector_array knn_type='hnsw' hnsw_similarity='cosine' model_name='Xenova/all-MiniLM-L6-v2' from='title,content' chunk_strategy='sentence' max_tokens='256' overlap_tokens='32' );

Bu ayar devredeyken Manticore her belgeyi bölüyor, her parçayı gömüyor ve tüm parçalar arasında arama yapıyor. Beş strateji sunuluyor: truncate (eski varsayılan), mean, fixed, recursive ve sentence. Truncate ve mean belge başına tek vector üretir ve float_vector sütununa uyar; fixed, recursive ve sentence çok sayıda vector üretir ve float_vector_array sütunu gerektirir. Ayarlanabilir parametreler şunlar: parça boyutu için max_tokens, komşu parçaların paylaştığı tokenlar için overlap_tokens ve belge başına üst sınır olarak max_chunks.

İki tasarım kararı öne çıkıyor. Bir belge tek bir arama sonucu olarak kalıyor: parçalar tek tek yarışıyor ama Manticore belgeyi bir kez döndürüyor, knn_dist() en yakın parçaya olan mesafeyi bildiriyor ve k parametresi belgeleri sayıyor, parçaları değil. Sorgular ise hiçbir zaman parçalanmıyor — bütün olarak gömülecek kadar kısalıklar ve yalnızca depolanan belgeler bölünüyor.

Ölçülen kazançlar ve maliyetler

Yazı, özelliği Manticore'ün kendi kılavuzu üzerinde benchmark'lıyor: 189 sayfa ve yaklaşık 298.000 kelime. Modelin girdi penceresinin ötesindeki içerik için recall@5 %55,1'den %83,3'e yükseldi ve MRR 0,44'ten 0,70'e iyileşti. Maliyetler somut: her parça kendi embedding'ini aldığı için RAM yaklaşık 2,5 kat, ingest süresi ise kabaca dört kat artıyor.

Neden önemli

Chunking, iç dokümantasyon üzerinden retrieval sistemi kurmanın en uğraştırıcı parçalarından biri — rehberler, runbook'lar, postmortem'ler, tam da Manticore'ün örnek verdiği külliyat. Çoğu uygulama bunu bir splitter kütüphanesi, parçalar için ayrı bir tablo ve parça eşleşmelerini belge düzeyinde sonuçlara birleştiren aggregation mantığıyla hallediyor. Tüm bunları tek bir sütun tanımına katmak bütün bir pipeline'ı tek bir CREATE TABLE ifadesine indiriyor ve birçok dağıtımın farkında olmadığı bir kesme varsayılanını düzeltiyor. Ödünler gerçek — bellek ve indeksleme süresi katlanıyor — ama uzun belge külliyatlarındaki recall farkı büyük ve yayımlanan benchmark ekiplere hem kazançlar hem de bedel konusunda somut bir beklenti veriyor.