LLM·3 dk okuma·

Uzun Belgeler İçin Daha İyi Vektör Arama: Manticore Search ile Otomatik Parçalama (Chunking)

Paylaş
LLMEdumints Blog

Ekip içi dokümantasyonunuz (kılavuzlar, runbook'lar, postmortem raporları) üzerinde anlamsal arama geliştirirken otomatik embedding özellikleri büyük kolaylık sağlar. Bir metin eklersiniz, veritabanı modeli arka planda çalıştırır ve vektör sütununu doldurur. Ancak 4.000 kelimelik (~5.000 token) uzun bir belge yüklediğinizde ve modelinizin giriş penceresi 512 token ile sınırlıysa kritik bir sorun ortaya çıkar: Model yalnızca ilk 380 kelimeyi işler ve kalan 3.600 kelimeyi sessizce göz ardı eder. Bu eşikten sonraki içerikler aramalarda asla bulunamaz ve sistem geliştiriciye hiçbir hata bildirimi yapmaz.

Geleneksel mimarilerde geliştiriciler bu problemi aşmak için belgeleri harici metin bölücülerle parçalara ayırır, her parça için ayrı embedding üretir ve belge düzeyinde arama yapabilmek için sonuçları birleştiren karmaşık ETL mantıkları kurardı. Manticore Search, bu süreci doğrudan tablo tanımı düzeyine indirgemektedir. CREATE TABLE ifadesinde vektör sütununa chunk_strategy ekleyerek; harici veri işleme boru hattı, bölücü kütüphane, parçalar için ikinci bir tablo veya GROUP BY sorguları olmadan otomatik parçalama ve arama yapabilirsiniz.

Temel Özellikler ve Özet (TL;DR)

  • Beş Strateji: Model destekli vektör sütunlarında chunk_strategy ile belirlenebilen truncate (eski varsayılan), mean, fixed, recursive ve sentence stratejileri sunulur.
  • Vektör Sütun Tipleri: Belge başına tek vektör üreten truncate ve mean yöntemleri float_vector sütununu kullanırken; birden çok vektör üreten fixed, recursive ve sentence stratejileri float_vector_array sütununa ihtiyaç duyar.
  • Belge Odaklı Sonuç: Parçalar bağımsız olarak yarışsa da Manticore belgeyi tek bir arama sonucu olarak döndürür; knn_dist() en yakın parçaya olan mesafeyi verir ve k değeri parçaları değil belgeleri sayar.
  • İnce Ayar Parametreleri: Parça boyutunu yöneten max_tokens, komşu parçalar arasındaki örtüşmeyi belirleyen overlap_tokens ve belge başına üst sınır koyan max_chunks parametreleri mevcuttur.
  • Ölçülen Başarım: Manticore kılavuzu (189 sayfa, ~298 bin kelime) üzerinde model penceresini aşan içeriklerde recall@5 değeri %55.1'den %83.3'e, MRR ise 0.44'ten 0.70'e yükselmiştir (~2.5 kat RAM ve ~4 kat ingest süresi maliyetiyle).
  • Sorgu Davranışı: Saklanan belgeler parçalanırken kullanıcı sorguları bütün olarak embed edilebilecek kadar kısa olduğundan asla parçalanmaz.

Küçük Bir Örnekle Problem Senaryosu

Karşılaştırma amacıyla şu dört belge ele alınır:

  • Yedekleme ve Geri Yükleme Runbook'u: Yaklaşık 700 kelime (~900 token). Son bölümünde replikasyon portu TLS sertifikasının nasıl yenileneceğini açıklar.
  • İzleme ve Uyarı Rehberi: Konuyla ilgisiz genel doküman.
  • CLI Başlangıç Rehberi: Konuyla ilgisiz genel doküman.
  • HTTP API TLS ve Sertifikaları: Yalnızca sertifikaları anlatan; rotasyon veya replikasyondan bahsetmeyen kısa bir sayfa.

Aynı kaynak metne ve strateji başına bir vektör sütununa sahip tek bir tabloya yapılan tek INSERT, tüm karşılaştırma koşullarını özdeş tutar.

Yazılım Geliştirme ve Mimari Açısından Çıkarımlar

Manticore Search'ün veritabanı içi parçalama özelliği, RAG ve arama mimarilerinde dış kütüphane bağımlılıklarını ve veri senkronizasyon risklerini ortadan kaldırır. Geliştiriciler açısından sessiz veri kaybı hatasını engelleyerek bilgi getirme başarımını ciddi oranda artırır; karşılığında gerektirdiği ek bellek ve indeksleme süresi, sağladığı güvenilirlik ve operasyonel sadelik karşısında makul bir mühendislik ödünleşimidir (trade-off).

Orijinal kaynağa buradan ulaşabilirsiniz.

Paylaş

Bu konuyu daha derinlemesine öğrenmek ister misin?

Edumints'teki ücretsiz kursları incele ve bugün başla.

Kurslara Göz At →