Saf Vektör Benzerliğinin Öngörülebilir Kör Noktaları Vardır

Yoğun erişim, tasarlandığı işte gerçekten iyidir: sorguyla aynı anlama gelen ama farklı kelimeler kullanan metni bulmak. Bu gerçek bir yetenektir ve anlamsal aramanın pek çok üründe anahtar kelime aramasının yerini almasının nedeni de budur. Ancak bir embedding, bir pasajın birkaç yüz veya birkaç bin boyuta kayıplı biçimde sıkıştırılmasıdır ve sıkıştırma, eğitim hedefinin ödüllendirmediği her şeyi atar. Attığı şey de güvenilir biçimde nadir token'lardaki kesinliktir. Bir parça numarası, bir dosya esas numarası, bir vergi kodu, bir müşteri kimliği ve alışılmadık bir soyadı, hepsi yakın komşularıyla kabaca aynı bölgeye çöker, çünkü modelin bunları ayrı tutmak için hiçbir nedeni olmamıştır.

Hatayı yeniden üretmek kolaydır. Teknik bir korpusta belirli bir parça numarasını aratın; yoğun erişim size aynı bileşenin farklı bir revizyonunu, başka bir ürün hattından benzer bir parçayı ve o bileşen ailesine dair genel bölümü memnuniyetle döndürürken, birebir eşleşme on dördüncü sırada oturur. Hukuki bir korpusta belirli bir madde numarasını aratın; komşu maddeleri alırsınız, çünkü onlar hem sözlüksel hem anlamsal olarak bitişiktir. Kullanıcı benzer bir şey istemiyor. Tam olarak o dizgiyi istiyor ve erişim katmanının, burada önemli olanın tamlık olduğunu anlayacak hiçbir mekanizması yok. Bu davranış rastlantısal değil sistematiktir ve her nadir dizgi sorgusunda aynı biçimde tekrarlanır.

Olumsuzlama ve miktar ikinci hata ailesidir ve sessiz oldukları için daha kötüdür. Bir tedavinin önerildiğini söyleyen cümle ile önerilmediğini söyleyen cümlenin embedding'leri son derece yakındır. Aynı durum eşikler için de geçerlidir: 500.000 liranın üzerindeki sınırlardan bahseden metin ile altındaki sınırlardan bahseden metin yakın komşudur. Yoğun bir erişim katmanı ikisini de döndürür ve bağlam penceresine yalnızca biri girerse bu pekâlâ yanlış olan olabilir. Bu, üretim hatası gibi görünen bir erişim hatasıdır ve ekipler bunu düzeltmek için düzenli olarak haftalarca prompt yeniden yazar. Bu yüzden olumsuzlama içeren sorguları değerlendirme kümesinde ayrı bir katman olarak tutuyoruz.

Bunların hiçbiri yoğun erişimin yanlış olduğu anlamına gelmez. Yalnızca birkaç sinyalden biri olduğu anlamına gelir ve doğru mimari, onu bulanık olduğu yerde kesin olan bir sinyalle birleştirir. Henüz ilk vektör tabanlı sisteminizi kurmadıysanız, zemin vektör veritabanları ve anlamsal arama ile token, embedding ve vektör ilişkisi yazılarında anlatılıyor. Bu yazı, o sistemin var olduğunu, kabul edilebilir biçimde çalıştığını ve saf benzerliğin er ya da geç dayattığı tavana çarptığını varsayar. Başka bir deyişle mesele yoğun erişimi değiştirmek değil, onun yanına ne koyduğunuzu doğru seçmektir; bu yazının geri kalanı da tam olarak bu seçimin nasıl yapılacağını ve nasıl ölçüleceğini anlatıyor.

Sözlüksel Erişim (BM25) Gerçekte Neyde İyidir?

BM25, onlarca yıldır canlı arama sistemlerinde varsayılan olan bir terim frekansı sıralama fonksiyonudur ve yoğun erişimin çözemediği problemler için hâlâ elimizdeki en iyi cevaptır. Bir belgeyi, sorgu terimlerinin onda ne sıklıkta geçtiğine göre puanlar; tekrarın getirisi azalacak şekilde sönümler, her terimin korpus genelinde ne kadar nadir olduğuna göre ağırlıklandırır ve belge uzunluğuna göre normalleştirir. Bu son özellik, yani nadir terimlerin yüksek puan alması, tam olarak tanımlayıcılar için istediğiniz davranıştır. İki milyon belgenin üçünde geçen bir token muazzam ağırlık taşır ki bu, bir embedding'in o token'a yaptığının tam tersidir. Bu ters davranış, iki yöntemin neden birbirini tamamladığının en özlü açıklamasıdır.

Pratikte bu, BM25'in şu alanlarda kazandığı anlamına gelir: birebir tanımlayıcılar, tırnak içindeki ifadeler, nadir özel isimler, kod sembolleri, ürün stok kodları, mevzuat ve madde atıfları ve kullanıcının birebir görmeyi beklediği bir dizgi yazdığı her sorgu. Ayrıca korpus, embedding modelinin eğitim sırasında hiç görmediği bir kelime dağarcığı içerdiğinde de kazanır; kurum içi proje kod adları ve alan jargonuyla dolu bir Türk kurumsal korpusunda bu, ilginç sorguların hatırı sayılır bir kısmıdır. Ve maliyeti neredeyse sıfırdır: Elasticsearch, OpenSearch veya bir Postgres tam metin sütunundaki ters indeks, sorgu başına birkaç milisaniye ekler ve vektör indeksine kıyasla ihmal edilebilir bellek tüketir.

Yoğun erişimin icat edildiği her şeyde ise kaybeder. Personel seyahat masrafı iadesini soran bir kullanıcı, iş seyahatleri harcama politikası başlıklı bir belgeyle eşleşmez, çünkü ortak terimleri yoktur. Eş anlamlılar, başka sözcüklerle ifade etme ve diller arası sorgular onu yener. Bu tamamlayıcılık, hibrit erişimin tüm gerekçesidir: iki yöntem ayrık sorgu kümelerinde başarısız olur. Karma kurumsal korpuslardaki ölçümlerimizde, yalnızca yoğun erişimden düzgün birleştirilmiş bir hibrit yapıya geçmek recall@10 değerini tipik olarak beş ila on beş puan yükseltiyor ve kazancın neredeyse tamamı, yalnızca yoğun erişimin hiçbir işe yarar sonuç döndürmediği tanımlayıcı ve nadir terim sorgularında toplanıyor.

Türkçeye özgü bir yapılandırma uyarısı. BM25 token'lara ayırma ve normalizasyona bağlıdır, dolayısıyla Türkçe metin üzerinde varsayılan bir İngilizce çözümleyiciyle yapılandırılmış bir indeks, her çekimli yüzey biçimini ilişkisiz bir terim gibi ele alır ve bunları bağımsız puanlar. Gövdeleme yapan, noktalı ve noktasız i'yi doğru işleyen ve yerel ayara duyarlı bir küçük harf filtresi olan bir Türkçe çözümleyiciye ihtiyacınız var. Bu, Türkçe korpuslarda çift haneli recall farkına yol açtığını gördüğümüz beş satırlık bir yapılandırma değişikliğidir ve mevcut her Türkçe arama kurulumunda ilk bakılmaya değer şeylerden biridir. Aynı kontrol, kurum içi kısaltmaların ve proje kod adlarının indekste nasıl bölündüğünü de kapsamalıdır.

Birleştirme: Karşılıklı Sıra Birleştirmesi (RRF) ve Ağırlıklı Puanlar

İki erişim katmanı çalıştırdığınız anda iki sonuç listesini birleştirmeniz gerekir ve birleştirme stratejisi çoğu ekibin beklediğinden daha çok önem taşır. Sorun şu ki BM25 puanları ile kosinüs benzerlikleri karşılaştırılabilir değildir. BM25 sınırsızdır ve korpusa bağlıdır; kosinüs benzerliği ise makul her şey için çoğunlukla 0,6 ile 0,9 arasında dar bir bantta oturur. Bunları doğrudan toplamak anlamsızdır, çarpmak daha kötüdür. Ya ilkeli bir normalizasyona ya da puanları tamamen göz ardı eden bir yönteme ihtiyacınız vardır. İki listeyi birleştirme kararı aslında hangi sinyale ne kadar güveneceğinizi kodlayan bir tasarım kararıdır ve bu nedenle sezgiye değil ölçüme dayanmalıdır.

Karşılıklı sıra birleştirmesi puanları göz ardı eder ve yalnızca konumları kullanır. Her belge, her listedeki sırası ile bir sabitin toplamının tersi kadar katkı alır; sabit geleneksel olarak 60 seçilir ve katkılar toplanır. Üç nedenle doğru varsayılandır: hiç ayar gerektirmez, iki erişim katmanının uyumsuz puan dağılımlarına karşı tamamen dayanıklıdır ve bir erişim katmanı belirli bir sorguda çöp döndürdüğünde zarif biçimde bozulur. Zayıflığı, büyüklüğü atmasıdır; ezici bir sözlüksel eşleşme ile sınırda bir eşleşme, aynı sırayı işgal ediyorlarsa aynı miktarda katkı verir. Buna rağmen çoğu kurulum için doğru başlangıç noktası budur, çünkü yanlış ayarlanmış bir ağırlık şemasından çok daha az zarar verir.

Ağırlıklı puan harmanlaması büyüklüğü korur ama önce normalizasyon ister. Her sonuç listesini sorgu içinde sıfır-bir aralığına min-maks normalleştirin ya da o sorgunun adaylarının puan dağılımına karşı bir z-skoru kullanın, sonra bir ağırlıkla birleştirin. Genel belge korpusları için yoğun tarafta 0,6 ila 0,8, kalanı sözlüksel tarafta makul bir başlangıç noktasıdır; tanımlayıcı ve teknik atıf ağırlıklı korpuslarda ise sözlüksele doğru kayar. Normalizasyonu her zaman sorgu başına yapın, asla küresel yapmayın, çünkü puan dağılımları sorgudan sorguya muazzam değişir ve küresel bir normalizasyon yalnızca ortalama sorguyu kodlar. Ayrıca normalizasyonu hangi aday derinliğinde yaptığınızı sabitleyin, yoksa derinlik değiştiğinde ağırlıklar sessizce anlamını yitirir.

Ağırlıkları tartışarak değil tarayarak, ampirik olarak seçin. Değerlendirme kümenizi alın, yoğun ağırlığı 0,3'ten 0,9'a 0,1 adımlarla değiştirerek koşun ve her biri için recall@k çizin. Eğri genellikle ortada düzdür ve bir uçta belirgin bir uçurumu vardır; bu size hem en iyi değeri hem elinizde ne kadar pay olduğunu söyler. Taramayı toplamın yanı sıra sorgu türü bazında da yapın, çünkü tanımlayıcı sorguları için en iyi değer ile kavramsal sorular için en iyi değer gerçekten farklıdır ve bu ayrışma, sorguları ucuz bir sınıflandırıcıyla farklı ağırlıklara yönlendirmenin en güçlü gerekçesidir. Bu tarama tipik olarak birkaç saat sürer.

Geniş Getir, Sonra Yeniden Sırala: Derinlik ve Bedeli

Canlıdaki baskın kalıp iki aşamalıdır. Birinci aşama ucuz ve recall odaklıdır: her iki erişim katmanını çalıştırın, birleştirin ve geniş bir aday kümesi alın. İkinci aşama pahalı ve kesinlik odaklıdır: her adayı sorguya karşı çok daha güçlü bir modelle puanlayın ve bağlam penceresi için yalnızca en iyi birkaçını tutun. Bu işe yarar, çünkü birinci aşamanın tek yapması gereken doğru belgeyi aday kümesinin bir yerine sokmaktır ki bu, onu ilk beşe sokmaktan çok daha kolay bir problemdir; ikinci aşamanın tek yapması gereken ise küçük bir listeyi sıralamaktır ki bu da korpusu aramaktan çok daha ucuz bir problemdir.

Aday kümesi ne kadar geniş olmalı? Dürüst cevap, bunu ölçtüğünüzdür ve ölçüm dolaysızdır: birleştirilmiş erişim katmanınız için recall@k değerini k'ye karşı çizin ve eğrinin nerede düzleştiğini bulun. Çoğu kurumsal korpusta bu, 50 ila 200 aday arasında bir yerde gerçekleşir. 50'nin altında genellikle hâlâ masada recall bırakıyorsunuzdur; 200'ün üzerinde ek belgeler neredeyse hiç ilgili değildir ve boşuna yeniden sıralama maliyeti ödersiniz. recall@200 değeri recall@50'den zar zor iyiyse daha derine inmek size yardımcı olamaz ve darboğaz yukarıda, ayrıştırmada, parçalamada veya birleştirme ağırlıklarındadır. Ölçümü kendi korpusunuzda yapın, çünkü bu eşik korpusun büyüklüğüne ve tekrar oranına göre belirgin biçimde kayar.

Derinlik gecikme maliyeti doğurur ve mimarinin ürün gereksinimiyle buluştuğu yer burasıdır. İyi ayarlanmış bir indeks üzerinde birinci aşama erişim tipik olarak 10 ila 50 milisaniyedir. 50 adaylık bir kümeyi çapraz kodlayıcıyla yeniden sıralamak, model boyutuna, dizi uzunluğuna ve GPU mu CPU mu kullandığınıza bağlı olarak kabaca 100 ila 400 milisaniye ekler ve maliyet aday sayısıyla neredeyse doğrusal ölçeklenir, dolayısıyla 200 adaylık bir yeniden sıralama birkaç yüz milisaniyeden bir saniyeye varan bir ilave demektir. İlk token'dan önce bir saniyenin altını hedefleyen etkileşimli bir asistan için 50 adaylık yeniden sıralama genellikle karşılanabilir, 200 adaylık genellikle değildir.

İki teknik bu maliyetin çoğunu geri kazandırır. Aday puanlamasını ardışık çağrılar yerine toplu yapın; bu, GPU üzerinde doğrusal bir maliyeti yığın boyutuna kadar sabite çok daha yakın bir şeye çevirir. Ve kademelendirin: ilk 200'ü küçük ve hızlı bir modelle yeniden sıralayın, ilk 40'ı tutun, sonra onları pahalı modelle yeniden sıralayın. Bir kademe, derin yeniden sıralamanın kalitesinin çoğunu gecikmenin küçük bir kısmıyla düzenli olarak verir. Hangisini seçerseniz seçin ortalamayı değil p95'i ölçün, çünkü yeniden sıralama gecikmesinin ortalamaların gizlediği uzun bir kuyruğu vardır. Kademeyi eklerken her iki modelin sürümünü de kayıt altına alın.

Çapraz Kodlayıcılar (cross-encoder) ve İkili Kodlayıcılar

Yeniden sıralamanın işe yaramasının nedeni mimaridir. Vektör indeksinizin kullandığı şey olan ikili kodlayıcı, sorgu ile belgenin embedding'ini birbirinden bağımsız alır ve iki vektörü karşılaştırır. Bu bağımsızlık onu hızlı kılan şeydir, çünkü her belgenin embedding'i veri alımında bir kez alınabilir ve en yakın komşu aramasıyla taranabilir. Aynı bağımsızlık onu kesinlikten uzak kılan şeydir de: belge vektörü sorgudan hiç haberi olmadan üretilmiştir, dolayısıyla belirli bir sorunun cevabı değil pasajın genel amaçlı bir özeti olmak zorundadır. Bu nedenle ikili kodlayıcıyı bir sıralama modeli değil bir aday üretici olarak düşünmek gerekir; ondan beklenen şey kesinlik değil kapsamadır.

Çapraz kodlayıcı ise sorgu ile belgeyi modelden birlikte geçirir, böylece her katman ikisi arasında dikkat kurabilir. Bu nedenle sorgudaki olumsuzlamanın belgedeki iddiaya uygulandığını, sorgudaki tanımlayıcının pasajın üçüncü satırındakiyle eşleştiğini ve konu olarak kusursuz görünen bir pasajın aslında başka bir soruyu cevapladığını görebilir. Çapraz kodlayıcıların sıralama kalitesinde ikili kodlayıcıları belirgin biçimde geçmesinin nedeni bu ortak dikkattir. Aynı nedenle erişim için kullanılamazlar: puanlama sorgu-belge çifti başına bir ileri geçiş gerektirir, dolayısıyla bir milyon belgeyi aramak sorgu başına bir milyon ileri geçiş demek olurdu. Bu asimetri, iki aşamalı mimarinin neden bir tercih değil bir zorunluluk olduğunu açıklar.

Bu kısıt mimariyi belirler. İkili kodlayıcılar arar, çapraz kodlayıcılar sıralar ve aday kümesi ikisi arasındaki arayüzdür. Bir yeniden sıralama modeli seçerken önemli eksenler şunlardır: azami dizi uzunluğu, ki bu parça boyutunuzu rahatça aşmalıdır yoksa model her parçanın sonunu sessizce keser; korpusunuz saf İngilizce değilse çok dilli kapsama; ve aday derinliğinizdeki iş hacmi. Özellikle Türkçe kapsaması yeniden sıralama modelleri arasında büyük ölçüde değişir ve model kartından varsaymak yerine kendi değerlendirme kümenizde doğrudan test etmeye değer. Ayrıca yeniden sıralama modelinin ürettiği puanları loglayın; bu puanların dağılımı, aday derinliğini ilerideki ayarlarda hangi yöne çekeceğinizi söyler.

Bilinmeye değer üçüncü bir seçenek daha var: liste tabanlı yeniden sıralama; burada bir dil modeline sorgu ve numaralandırılmış bir aday listesi gösterilir ve onları sıraya koyması istenir. Özellikle yetenekli bir modelle çok güçlü olabilir ve özel bir yeniden sıralama modeli gerektirmez. Aynı zamanda daha yavaş, daha pahalı, sıcaklığı sıfıra sabitlemezseniz belirlenimsiz ve konum yanlılığına açıktır, dolayısıyla değerlendirirken aday sırasını koşumlar arasında karıştırmalısınız. Aday kümesi küçükken, kalite gecikmeye baskın geldiğinde veya alana özgü bir sıralama kuralını eğitmektense bir promptla ifade etmek daha kolay olduğunda buna başvuruyoruz. Belirlenimsizliği nedeniyle regresyon kapılarında kullanmadan önce tekrarlanabilirliğini ayrıca doğrulamak gerekir.

Sorgu Anlama (query understanding) ve Bedeli

Yukarıdaki her şey, sorgunun makul bir arama dizgisi olduğunu varsayar. Çoğu zaman değildir. Kullanıcılar parça yazar, yalnızca önceki tur bağlamında anlam taşıyan takip soruları yazar, üç soruyu tek cümleye sıkıştırır ve korpusun tam halini yazdığı kurum içi kısaltmaları kullanır. Sorgu anlama, kullanıcının metni ile erişim katmanları arasında duran dönüşümler kümesidir ve çoğu zaman tüm veri hattının en yüksek kaldıraçlı parçasıdır, çünkü hiçbir indeks ayarının erişemeyeceği sorunları düzeltir. Başka bir deyişle, erişim katmanını ne kadar iyi ayarlarsanız ayarlayın, kullanıcının yazdığı metin arama için uygun değilse aşamayacağınız bir tavan vardır ve bu tavanı yalnızca sorgu tarafındaki dönüşümler yükseltir.

Yeniden yazma en ucuz ve en değerli olanıdır. Sohbet arayüzlerinde, erişimden önce zamirleri ve eksiltili yapıları konuşma geçmişine karşı çözmek neredeyse zorunludur. Ayrıştırma, bileşik bir soruyu ayrı ayrı getirilen alt sorulara böler ki çok adımlı cevapları mümkün kılan şey budur. Çoklu sorgu genişletmesi üç ila beş yeniden ifade üretir ve sonuçlarının birleşimini alır; belirsiz ifade edilmiş sorularda anlamlı bir recall kazancı karşılığında erişim maliyetinin üç ila beş katını öder. HyDE daha ileri gider ve modelden varsayımsal bir cevap yazmasını ister, sonra soru yerine o cevabın embedding'ini alır, çünkü bir cevap bir soruya kıyasla gerçek cevaba daha çok benzer.

Bunların hepsi, erişim daha başlamadan bir dil modeli çağrısına mal olur; bu tipik olarak 200 ila 600 milisaniye ve her tek sorguda bir token faturasıdır. Bu, gecikme bütçesine ciddi bir ilavedir. Bizim kuralımız bunları seçici uygulamaktır: sohbet bağlamlarında her zaman yeniden yazın çünkü değerine göre neredeyse bedavadır, ayrıştırmayı yalnızca ucuz bir sınıflandırıcı bileşik soru tespit ettiğinde kullanın ve çoklu sorgu ile HyDE'yi gerçek bir kazanç ölçtüğünüz sorgu sınıfları için isteğe bağlı tutun. Koşulsuz uygulandıklarında zarar da verebilirler, çünkü genişletme kullanıcının hiç sormadığı terimleri devreye sokar ve kendinden emin biçimde alakasız sonuçlar çeker.

Bir güvenlik notu. Sorgu yeniden yazma, kullanıcı metninin bir modele verilip çıktısının erişimi sürüklemesi demektir; getirilen belgeler de bir modele verilip çıktısı cevabı sürükler. Her ikisi de enjeksiyon yüzeyidir ve filtreleri değiştirmeye veya kapsamı genişletmeye ikna edilebilen bir yeniden yazma adımı, teorik değil gerçek bir erişim yetkisi riskidir. İlgili saldırı örüntüleri ve önlemler yapay zeka güvenliği ve prompt enjeksiyonu yazısında ele alınıyor; buradaki asgari kural, bir yeniden yazıcının aramaya uygulanan erişim yetkisi filtrelerini asla değiştirememesidir. Yeniden yazma promptunu da sistem promptu gibi sürümleyin ve değişikliklerini regresyon kapısından geçirin. Bu kural pazarlık konusu değildir.

Filtreleme ve Erişim Yetkisi: Sıralamadan Önce mi Sonra mı?

Gerçek kurulumların çoğu filtreye ihtiyaç duyar: şu departman, şu tarih aralığı, şu belge türü, şu yetki grubu. Bunları nerede uyguladığınız hem doğruluğu hem kaliteyi değiştirir. Sonradan filtreleme, ilk k sonucu getirip kullanıcının göremeyeceklerini çıkarır; kurması basittir ve sessizce bozuktur. İlk beş sonuçtan dördü elenirse kullanıcı, kanıt tabanının budandığına dair hiçbir işaret olmadan tek bir belgeden kurulmuş bir cevap alır. Ayrıca filtrelenmemiş aday listesinin bellekte ve muhtemelen bir log kaydında var olduğu anlamına gelir ki bu tek başına bir ifşa riskidir. Bu nedenle filtreleme kararını bir performans ayrıntısı değil bir doğruluk kararı olarak ele alıyoruz.

Ön filtreleme, arama uzayını sıralamadan önce daraltır, böylece k sonuç her zaman k adet izin verilen sonuç olur. Bu doğrudur ve istediğiniz şeydir, ancak yaklaşık en yakın komşu indeksleriyle kötü etkileşir: HNSW gibi bir graf indeksi yakınlığa göre gezinir ve grafın çoğu bir filtreyle dışlanmışsa gezinme uygun olmayan düğümler arasında dolaşır ve recall çöker. Kabaca korpusun yüzde 95'inden fazlasını eleyen yüksek seçicilikli filtrelerin, naif ön filtrelemenin klasik başarısızlık vakası olmasının nedeni budur. Filtre seçiciliğini üretim verisinde ölçün, çünkü tasarım sırasında düşük seçicilikli sandığınız bir filtre gerçek dağılımda kolayca yüksek seçicilikli çıkabilir.

Pratik cevaplar seçiciliğe bağlıdır ve modern motorlar gereken araçları veriyor. Düşük seçicilikli filtreler için Qdrant gibi motorlarda uygulanan filtreli graf gezinmesi veya pgvector'da filtreli bir indeks taraması iyi çalışır. Yüksek seçicilikli filtreler için ise filtrelemek yerine bölümleyin: kiracı veya güvenlik alanı başına ayrı koleksiyonlar ya da ad alanları kurun, böylece filtre bir arama kısıtı değil bir yönlendirme kararı haline gelir. Özellikle erişim yetkisi için kiracı sınırında bölümlemeyi ve içeride indeksli etiket filtrelerini tercih ediyoruz; buna ek olarak aynı sorunun farklı yetkilere sahip kullanıcılarca sorulduğu ve cevapların farklı çıkmasının beklendiği bir yetki farklılığı test kümesi kuruyoruz.

İndeks Ayarı: HNSW Parametreleri ve Recall Takası

Yaklaşık en yakın komşu araması bilinçli olarak yaklaşıktır ve yaklaşıklığın miktarı sizin sahip olduğunuz bir parametredir. pgvector, Qdrant ile Elasticsearch ve OpenSearch'ün vektör özellikleri dahil çoğu vektör veritabanının arkasındaki graf indeksi olan HNSW'nin önem taşıyan üç ayarı vardır. M, her düğümün kaç komşu tuttuğunu belirler, tipik olarak 16 ila 64'tür ve bellek ayak izini ile kalite tavanını o kurar. Daha yüksek M daha iyi recall ve daha büyük bir indeks demektir. İndeks bir kez kurulduktan sonra M, yeniden kurmadan değiştirilemez. Bu üç ayarı belgelemeden canlıya çıkmak, altı ay sonra kimsenin bu değerlerin neden seçildiğini bilememesi demektir.

efConstruction, kurucunun her düğümü eklerken ne kadar sıkı arama yapacağını belirler, tipik olarak 100 ila 500'dür. Yükseltmek indeks kurulumunu yavaşlatır ama daha iyi bir graf üretir ve kurulum bir kez gerçekleştiği için genellikle cömert ayarlamaya değer. efSearch ise sorgu anında ayarladığınız parametredir: gezinmenin kaç adayı aynı anda takip edeceğini belirler, tipik olarak 40 ila 400'dür ve gecikmeyi doğrudan recall ile takas eder. Önemli özelliği, efSearch'ün bir çalışma zamanı parametresi olmasıdır, dolayısıyla eğriyi kendi verinizde ölçebilir ve hiçbir şeyi yeniden kurmadan sonradan fikrinizi değiştirebilirsiniz. Bu yüzden efSearch'ü yapılandırma dosyasında açıkça belirtiyor ve asla varsayılana bırakmıyoruz.

Ayar prosedürü mekaniktir ve bir öğleden sonra sürer. M ile efConstruction'ı sabitleyin, sonra efSearch'ü tarayın ve her değerde recall'ı gecikmeye karşı çizin; buradaki recall, cevap kalitesi değil aynı korpus üzerinde tam kapsamlı bir kesin aramayla uyumdur. Eğri önce dik yükselir sonra düzleşir ve doğru ayar dirseğin hemen ötesidir. Bunu atlayan ekipler neredeyse her zaman ya kullanamayacakları recall için gecikme israf eden ya da daha yaygın olarak, hiçbir alt katman yeniden sıralamasının kurtaramayacağı birkaç puan erişim kalitesini sessizce kaybeden varsayılanlarla çalışır; çünkü grafın hiç uğramadığı bir belge cevabın içine yeniden sıralanamaz.

Bununla birlikte gelen iki karar daha var. Nicemleme, ister skaler ister çarpımsal olsun, vektörleri belirgin biçimde küçültür ve aramayı hızlandırır, karşılığında bir miktar kesinlik alır; birkaç milyon vektörün üzerinde genellikle iyi bir takastır, özellikle bir yeniden sıralama aşaması sıralamayı sonradan onarabiliyorsa. Ve mesafe metriği, embedding modelinin nasıl eğitildiğiyle eşleşmelidir; çoğu modern model için bu, normalleştirilmiş vektörlerde kosinüs veya iç çarpım demektir. Buradaki bir uyuşmazlık hata fırlatmaz. Yalnızca sonsuza kadar sessizce daha kötü sonuçlar döndürür ve bu yüzden çözümleyici yapılandırmasıyla aynı kontrol listesine aittir. Her ikisini de indeks oluşturulurken kayıt altına alın ki sonraki karşılaştırmalar anlamlı olsun.

Sezgiyle Değil Değerlendirme Kümesiyle Ayarlayın

Bu yazıdaki her şey bir ayar düğmesidir ve artık bir ekibin kafasında tartabileceğinden fazla düğme var: birleştirme yöntemi, birleştirme ağırlıkları, aday derinliği, yeniden sıralama modeli seçimi, bağlama giren sonuç sayısı, sorgu dönüşümleri, filtre stratejisi, efSearch, parça boyutu. Kombinasyon sayısı, sezginin değersiz olacağı kadar büyüktür ve tek çıkış yolu ölçümdür. Bu da RAG değerlendirme metrikleri yazısında anlatılan değerlendirme kümesinin bu işin isteğe bağlı bir tamamlayıcısı değil ön koşulu olduğu anlamına gelir. O olmadan bu yazıdaki her değişiklik, yanına makul bir hikâye iliştirilmiş bir tahmindir. Ayrıca hangi düğmenin hangi metriği hareket ettirdiğini not edin.

Sabit bir sırayla ayarlayın, çünkü parametreler etkileşir ve rastgele bir sıra zaman israfıdır. Önce ayrıştırmayı ve parçalamayı sabitleyin, çünkü neyin erişilebilir olduğunu onlar belirler. Sonra birinci aşama erişimi ayarlayın; birleştirme ağırlıklarını ve aday derinliğini aday derinliğinizdeki recall'a karşı tarayın ve nihai cevabı tamamen göz ardı edin. Sonra yeniden sıralamayı ekleyip ayarlayın, nihai bağlam derinliğinizde recall ve NDCG ölçün. Sonra sorgu dönüşümlerini ayarlayın. Sonra, ve ancak o zaman, prompt üzerinde çalışın. Her aşama kendi metriğiyle ölçülür ve bir önceki aşama platoya ulaşmadan sonrakine geçmek, her şeyi daha sonra yeniden ayarlamak anlamına gelir.

Her kalite kazancının maliyetini, kazancın kendisiyle aynı tabloda ölçün. recall@5 değerini üç puan yükseltirken p95'te 400 milisaniye ekleyen ve sorgu başına maliyeti ikiye katlayan bir yapılandırma, bir durum tespiti iş akışı için meşru bir tercihtir ve müşteriye dönük bir sohbet bileşeni için apaçık kötü bir tercihtir. Test edilen her yapılandırma için recall@5, NDCG@5, sadakat, p50 ve p95 gecikmesi ve bin sorgu başına maliyeti tek bir sayfada tutuyoruz; karar da bir toplantıda mimari tercihi yeniden tartışarak değil bir satır okunarak veriliyor. Bu tablo aynı zamanda ürün ekibiyle mühendislik arasındaki tartışmayı tercih düzeyinden ölçüm düzeyine taşır.

HatsonTech'te Hibrit Erişimi Nasıl Kuruyoruz?

Varsayılan başlangıç mimarimiz kasıtlı olarak maceradan uzaktır: düzgün yapılandırılmış bir Türkçe çözümleyiciyle BM25, parçalanmış korpus üzerinde yoğun erişim, ikisi arasında karşılıklı sıra birleştirmesi, ilk 50 ila 100 aday üzerinde çapraz kodlayıcıyla yeniden sıralama ve sıralamadan önce uygulanan metadata filtreleriyle bağlam penceresine giren beş ila sekiz parça. Bu yapılandırma ne zekicedir ne yenidir ve incelememiz istenen saf vektör sistemlerinin çoğunu geride bırakır. Tam da sıkıcı olduğu için oradan başlıyoruz, sonra değerlendirme kümesine karşı ayarlıyoruz ve yalnızca gecikmesini hak eden bileşenleri ekliyoruz. Eklenen her bileşenin ölçülen kazancını ve eklediği gecikmeyi aynı satırda tutuyoruz.

Tekrar eden bulguları açıkça söylemekte fayda var. Yalnızca yoğun erişimli bir sisteme sözlüksel bir bacak eklemek, Türk kurumsal korpuslarında gördüğümüz en büyük tek sıçramayı üretiyor ve bu sıçramanın neredeyse tamamı, daha önce kullanılabilir hiçbir şey döndürmeyen tanımlayıcı ve nadir terim sorgularında yaşanıyor. Daha geniş bir aday kümesini yeniden sıralamak, işletme maliyetinin çok altında bir bedelle üreteci yükseltmeyi geçiyor. Ve kötü yapılandırılmış bir çözümleyici veya varsayılan bir efSearch, karşılaştığımız herhangi bir model tercihinden daha fazla Türkçe arama kurulumunu sessizce tavanlamış durumda. Bunların hiçbiri egzotik mühendislik değil; birinin gerçekten uygulaması gereken bir kontrol listesi.

caseon.ai ve DiligenceAI'ın arkasındaki çalışmada erişim kalitesi, kullanıcı şikayetlerinden çıkarsanan bir şey değil birinci sınıf bir ürün metriği olarak ölçülüyor ve yapılandırma değişiklikleri kodla aynı regresyon kapılarından geçerek yayına giriyor. Başka sözcüklerle ifade etmede iyi ama referans numaralarında kötü bir anlamsal arama sistemi çalıştırıyorsanız, bu çözülebilir ve iyi anlaşılmış bir problemdir ve genellikle aylar değil haftalar meselesidir. RAG ve anlamsal arama çözümlerimiz mevcut erişim katmanınızın nerede kaybettiğini ölçerek başlar, sonra aşamaları kazandıran sırayla düzeltir. Bu ölçüm genellikle ilk hafta içinde nerede kaybettiğinizi gösteren somut bir liste üretir ve iş sırasını da o liste belirler.