Ölçekte Belge Parçalama: Erişim Kalitesi Burada Kazanılır

Parçalama Bir Ön İşleme Adımı Değildir

Çoğu ekip parçalamayı tesisat işi gibi görür. Biri bir eğitim yazısı öyle dediği için 50 token örtüşmeyle 512 token seçer, canlıya alır ve sonraki üç ayı, aslında veri alımı sırasında yaratılmış sorunları düzeltmek için promptları ayarlayarak ve embedding modelleri değiştirerek geçirir. Bu tersten bir yaklaşımdır. Parça, sonraki her şeyin atomik birimidir: embedding'i alınan, sıralanan, bağlam penceresine giren ve sonunda kullanıcıya alıntı olarak gösterilen şey odur. Bir hükmü koşulundan veya bir değeri sütun başlığından ayıran bir parça, piyasadaki hiçbir modelle kurtarılamaz. Aynı şekilde bir tabloyu satır grubunun ortasından bölen bir parça da, ne kadar iyi bir yeniden sıralama modeli kullanırsanız kullanın kurtarılamaz.

Küçük ölçekte hasar görünmez. İki bin temiz belgede neredeyse her parçalama stratejisi kabul edilebilir sonuç üretir, çünkü korpus, doğru belgenin nasılsa yüzeye çıkacağı kadar küçüktür. Strateji, elli bin belge civarında önem kazanmaya başlar ve birkaç yüz binin ötesinde belirleyici hale gelir; çünkü makul görünen yakın eşleşmelerin sayısı korpusla birlikte büyürken bağlam penceresindeki yuva sayısı büyümez. İki milyon parçada, bir yuva için üç rakibi olacak bir sorgunun artık üç yüz rakibi vardır ve doğru olanı tepede tutan tek şey kesin parça sınırları ile iyi metadata'dır. Bu yüzden parçalama stratejisini pilot korpusta değil, hedeflediğiniz nihai ölçekten alınmış temsili bir örneklem üzerinde değerlendirmek gerekir.

Bir de fatura gelene kadar göz ardı edilen bir maliyet argümanı vardır. Parça boyutu parça sayısını, parça sayısı ise embedding maliyetini, indeks büyüklüğünü, bellek ayak izini ve sorgu gecikmesini belirler. Parça boyutunu yarıya indirmek vektör sayısını ikiye katlar; bu da kabaca indeks belleğini ikiye katlar ve her yaklaşık en yakın komşu aramasına ölçülebilir gecikme ekler. Bir milyon belgelik bir korpusta, ortalama 300 token'lık parça ile 800 token'lık parça arasındaki fark, tek makinede rahatça bellekte tutabildiğiniz bir indeks ile parçalama, çoğaltma ve bir operasyon konuşması gerektiren bir indeks arasındaki farktır. Bu karar veri alımında verilir ve geri döndürmesi pahalıdır.

Önce Ayrıştır: Yerleşim Farkındalıklı Çıkarım ve OCR Kapıları

Herhangi bir şeyi parçalayabilmeniz için önce dosyayı metne çevirmeniz gerekir ve gerçek korpusların çoğu, erişilebilir kalitesinin büyük kısmını tam da burada kaybeder. Basit bir PDF metin çıkarıcı iki sütunlu bir sayfayı tek akış olarak okur, sol ve sağ sütunları satır satır birbirine geçirir ve dilbilgisi açısından imkânsız bir metin üretir. Üst ve alt bilgileri gövdeye bırakır, böylece bir sayfa numarası ile belge başlığı cümlenin ortasında belirir. Dipnotları satır içine yerleştirir, tireyle bölünmüş satır sonlarını yanlış birleştirir ve aslında görüntü olan sayfalar için sessizce boş metin döndürür. Bu hataların her biri, hiçbir parçalama mantığı çalışmadan önce parçayı zehirler.

Çözüm, ham karakter akışı yerine okuma sırasını, blok türlerini ve belge hiyerarşisini geri kazanan bir ayrıştırıcı kullanmak anlamına gelen yerleşim farkındalıklı çıkarımdır. Ayrıştırıcıdan istediğiniz şey yapılandırılmış bir ağaçtır: başlık, iç içe geçme düzeyleriyle bölüm başlıkları, paragraflar, liste öğeleri, tablo olarak tablolar, altyazılarıyla şekiller ve bağlandıkları yere iliştirilmiş dipnotlar. Sonradan yapı farkındalıklı parçalamayı mümkün kılan şey bu ağaçtır. Ayrıca size, bir parçaya ekleyeceğiniz en değerli metadata alanı olan bölüm yolunu verir. Buna gerçek zaman ayırın: karma bir korpusta ayrıştırma ve çıkarım çalışması düzenli olarak toplam veri alımı mühendislik eforunun yüzde 30 ila 50'sini oluşturur.

Taranmış belgeler yalnızca bir OCR geçişine değil bir kalite kapısına ihtiyaç duyar. OCR'ı çalıştırın, sonra her sayfayı puanlayın ve yönlendirin. Biz motorun kendi ortalama karakter güven skorunu, beklenen dile ait bir sözlükte geçen token oranını ve satır uzunluklarının makul olup olmadığı gibi basit yapısal akıl sağlığı kontrollerini birlikte kullanıyoruz. İyi puan alan sayfalar doğrudan geçer. Orta bantta kalan sayfalar işaretlenir ve düşük güven etiketiyle indekslenir, böylece onlardan getirilen her şey bir çekince ile sunulabilir. Tabanın altındaki sayfalar sessizce indekslenmemelidir, çünkü bir sayfa dolusu OCR çöpü eksik bir sayfadan kötüdür: dürüst bir boşluk yerine kendinden emin saçmalık üretir.

Kapıyı geçemeyen sayfalara ne olacağına açıkça karar verin. Seçenekler şunlardır: farklı bir motorla ikinci bir OCR geçişi veya eğrilik düzeltme ve kontrast normalizasyonu gibi ön işleme, fiziksel belgenin sahibine yönlendirilen bir yeniden tarama talebi, ya da bu sayfanın sisteme açık olmadığını söyleyen bir istisna kaydı. 1990'lar ve 2000'lerden kalma taranmış Türkçe belge korpuslarında sayfaların yüzde 3 ila 8'inin makul bir kalite kapısını geçemediğini düzenli olarak görüyoruz, en kötü arşivlerde ise çok daha fazlasını. Bu sayıyı paydaşlara erkenden bildirmek, altı ay sonra yanlış cevaplar üzerinden kapsama boşluklarını keşfetmelerine izin vermekten çok daha iyidir.

Tablolar, Şekiller ve PDF'lerin Size Yaptıkları

Tablolar, belge tabanlı RAG'de kendinden emin yanlış cevapların en yaygın tek nedenidir ve gerekçesi mekaniktir. Metne düzleştirilen bir tablo, hücre ile sütun başlığı arasındaki ilişkiyi kaybeder. Düzleştirilmiş bir akışta 12.500 olarak okunan bir satır bir fiyat, bir adet, bir eşik veya bir yıl olabilir ve model çevredeki düz metne bakarak tahmin yürütür. Daha kötüsü, tablolar sıklıkla sayfalar arasında bölünür; başlık satırı dördüncü sayfada bir kez görünür ve beşinci sayfadaki devam satırları hiçbir başlık olmadan gelir. Tablonun ortasından bölen bir parçalayıcı, tek tek anlamsız ama tek tek erişilebilir parçalar üretir ki bu en kötü bileşimdir.

İşleyen kalıp, tabloyu metin değil nesne olarak ele almaktır. Onu yapılandırılmış satırlar olarak çıkarın, sonra parçanın içine başlık ilişkisini koruyan bir biçimde işleyin; örneğin her satırın sütun adlarını tekrarladığı markdown benzeri veya anahtar-değer bir serileştirmeyle. Sığdığı sürece tabloyu tek parçada bütün tutun, sığmadığında satır gruplarına bölün ve başlık bloğunu her parçada tekrarlayın. Altyazıyı ve çevresindeki paragrafı önek olarak ekleyin, çünkü tablolar neredeyse hiçbir zaman kendini açıklamaz; ayrıca parçayı tablosal olarak işaretleyen bir metadata bayrağı koyun ki tablolardaki erişim kalitesini düz metinden ayrı ölçebilesiniz. Tablosal parçalar için ayrı bir değerlendirme alt kümesi tutmak, bu işlemenin gerçekten çalışıp çalışmadığını görmenin tek pratik yoludur.

Şekiller varsayılan değil bir karar gerektirir. Altyazısı olan bir görsel en azından altyazısı artı çevresindeki metinle indekslenmelidir. Düz metinde bulunmayan bilgi taşıyan diyagramlar, grafikler ve şemalar için bir görüntü modeli veri alımı sırasında metin açıklaması üretebilir ve bu açıklama diğer parçalar gibi embedding'e girer. Ölçekte bunun gerçek bir maliyeti vardır, dolayısıyla kapıya bağlayın: şekilleri yalnızca şekillerin önem taşıdığı belge sınıflarında, örneğin teknik şartnamelerde ve mühendislik çizimlerinde açıklayın, dekoratif görselleri tamamen atlayın. Ne seçerseniz seçin kayda geçirin, çünkü bir yıl sonra biri sistemin dokuzuncu sayfadaki süreç diyagramı hakkındaki soruları neden cevaplayamadığını soracaktır.

Dört Parçalama Stratejisi ve Hangisi Ne Zaman Kazanır?

Sabit boyutlu parçalama, yapıyı tamamen göz ardı ederek bir token sayısında örtüşmeyle böler. Hızlıdır, kolayca paralelleşir, maliyeti öngörülebilirdir ve anlama tamamen kayıtsızdır. Sohbet dökümleri, serbest metin notları ve yapısal olarak güvenilmeyecek kadar gürültülü OCR çıktısı gibi gerçekten yapısız metinler için doğru seçimdir. Başlıkları, hükümleri veya tabloları olan hiçbir şey için, yani kurumsal içeriğin çoğu için, yanlış seçimdir. Özyinelemeli parçalama makul varsayılandır: öncelikli bir ayırıcı listesinde bölün, önce paragraf sonları, sonra cümle sınırları, sonra boşluk; boyut sınırına ulaşana kadar metni paketleyin. Neredeyse ek maliyeti yoktur ve en bariz cümle ortası kesimleri önler.

Yapı farkındalıklı parçalama, ayrıştırıcınızdan gelen belge ağacını kullanır ve gerçek sınırlarda böler: bir madde, bir fıkra, bir bölüm, numaralı bir kalem. Bir insanın birim olarak tanıyacağı parçalar üretir; bu da atıfları güvenilir ve hata ayıklamayı anlaşılır kılar. Mevzuat, sözleşme, standart, politika ve teknik kılavuzlar için açık ara en iyi seçenektir ve Türkçe hukuk verisiyle RAG yazısında anlatılan madde düzeyindeki işlemenin arkasındaki yaklaşımdır. Bedeli, tamamen ayrıştırma kalitesine bağlı olması ve çok değişken parça boyutları üretmesidir; bu yüzden minik bölümler için bir birleştirme, devasa olanlar için bir bölme geçişine ihtiyacınız olur. Bu yüzden yapı farkındalıklı parçalamayı her zaman bir boyut normalizasyon geçişiyle birlikte kuruyoruz.

Anlamsal parçalama, ardışık cümleler için embedding hesaplar ve komşular arasındaki benzerlik bir eşiğin altına düştüğünde keser; dayanak, konu değişiminin doğal bir sınır olduğudur. Kulağa ikna edici gelir ve uzun yapısız düz metinde bazen işe yarar. Pratikte pahalıdır, çünkü korpusun embedding'ini iki kez alırsınız; kimsenin nasıl ayarlanacağını bilmediği bir eşiğe duyarlıdır; ve yapılandırılmış belgelerde genellikle yazarın sizin için zaten yazmış olduğu başlıklardan bölmenin gerisinde kalır. Bizim duruşumuz, içeriğin gerçekten kullanılabilir bir yapısı yoksa ve özyinelemeli parçalama ölçülüp yetersiz bulunmuşsa buna başvurmaktır. Ürettiği sınırlar insan tarafından denetlenemediği için hata ayıklamayı da belirgin biçimde zorlaştırır.

Canlıda bunlar birbirini dışlamaz. Gerçekçi bir veri hattı belge sınıfına göre yönlendirir: sözleşmeler ve mevzuat için yapı farkındalıklı, hesap tabloları ve mali raporlar için tablo nesnesi işleme, web sayfaları ve kurum içi wiki içeriği için özyinelemeli, dökümler için sabit boyutlu; sonunda da hangi yol üretmiş olursa olsun nihai parça boyutu dağılımının kontrollü olması için bir birleştir-ve-böl normalizasyon geçişi. Yönlendirme kararı genellikle dosya türü artı ilk sayfa üzerinde çalışan hafif bir sınıflandırıcıdan verilir ve kurmanın aldığı iki üç güne kesinlikle değer. Yönlendirme kararını ve her belge sınıfının hangi stratejiye gittiğini belgeleyin, çünkü bu tablo altı ay sonra hata ayıklarken ilk bakacağınız yer olacak.

Parça Boyutu ve Örtüşme Sabit Değil Ayarlanabilir Değerlerdir

Doğru bir parça boyutu yoktur; yalnızca sizin korpusunuz, sizin soru dağılımınız ve sizin embedding modeliniz için doğru olan bir boyut vardır. Taranmaya değer aralıklar kabaca şöyledir: cevabın bir iki cümlede durduğu yoğun olgusal aramalar için 200 ila 400 token, genel belge soru cevaplama için 400 ila 800 token, cevabın bir olgudan çok bir muhakeme gerektirdiği anlatısal veya analitik içerik için 800 ila 1.500 token. Parça boyutunun yüzde 10 ila 20'si kadar örtüşme olağan banttır. Yüzde 25'in üzerindeki her şey çoğunlukla indeksinizi ve embedding faturanızı şişirir, recall'ı ölçülebilir biçimde iyileştirmez. Bu aralıkların dışına çıkmadan önce, sorunun gerçekten boyut olup olmadığını görmek için erişim ayrıştırmasını çalıştırmakta fayda var.

Bunları bir karar değil bir parametre taraması olarak ele alın. Önce RAG değerlendirme metrikleri yazısında anlatılan değerlendirme kümesini kurun, sonra aynı korpusu üç dört boyut ve örtüşme kombinasyonuyla indeksleyin ve her biri için recall@k ile bağlam recall'ını ölçün. Yüz bin belgelik bir korpusta bu bir günlük hesaplama ve birkaç yüz liralık embedding harcamasıdır ve recall'ı düzenli olarak beş ila on beş puan hareket ettirir. Bu, çoğu model yükseltmesinin sağladığından daha büyük bir iyileşmedir ve eforun çok küçük bir kısmını gerektirir; bir eğitim yazısının varsayılanıyla kurulmuş sistemlerde bulduğumuz en yaygın bedava kalite kaynağıdır.

Yalnızca ortalamayı değil dağılımı izleyin. Ortalama parça boyutu 500 token olan bir korpus, parçalarının dörtte biri 50 token'ın altındaysa yine de patolojik olabilir; kısa başlıklar ve tek satırlık hükümlerle dolu belgelerde yapı farkındalıklı bölme bunu sürekli üretir. Çok kısa parçaların embedding'i kötüdür çünkü içlerinde yeterli sinyal yoktur ve sıralamada esaslı parçaların yerini kaparlar, çünkü kısa metin dar bir sorguda yüksek benzerlik puanı alabilir. Kabaca 80 ila 120 token'lık bir taban belirleyin ve altındaki her şeyi komşusuyla birleştirin; bir de tavan koyup bölme zorunlu olduğunda bölüm yolunu her iki yarıda da koruyun.

Küçükten Büyüğe: Bağlamsal ve Üst Belge Erişimi

İyi erişilen parça boyutu ile iyi cevaplayan parça boyutu arasında gerçek bir gerilim vardır. Küçük parçaların anlamı yoğunlaşmıştır ve bu nedenle sorgularla kesin eşleşirler, ama modelin eksiksiz bir cevap üretmek için ihtiyaç duyduğu çevre bağlamından çoğu zaman yoksundurlar. Büyük parçalar iyi cevaplar ama kötü erişilir, çünkü embedding'leri birkaç konunun ortalamasıdır ve hiçbir şeyle keskin eşleşmez. Küçükten büyüğe erişim bunu ikisini birbirinden ayırarak çözer: eşleştirme için küçük parçaları indeksleyin, ancak bir küçük parça getirildiğinde modele onun daha büyük üst parçasını verin. Bu ayrım, aynı korpustan hem kesin eşleşme hem eksiksiz cevap elde etmenin bilinen en ucuz yoludur.

Üst belge kalıbı bunun en dolaysız uygulamasıdır. Her belgeyi bir hiyerarşi olarak saklayın: tüm belge, bölümler ve 200 ila 400 token'lık alt parçalar. Yalnızca alt parçaların embedding'ini alın. Sorgu anında alt parçaları getirin, onları üstlerine eşleyin, birden fazla alt parçanın işaret ettiği üstleri tekilleştirin ve üst bölümleri bağlam penceresine geçirin. Dikkat edilmesi gereken temel şey bağlam bütçesidir, çünkü tek bir üst bölüm birkaç bin token olabilir ve bunlardan üç tanesi geri kalan her şeyin yerini kapar. Üst sayısını sınırlayın ve bir üst belirli bir boyutu aştığında alt parçaya geri düşün.

Bağlamsal parça zenginleştirmesi aynı soruna diğer taraftan saldırır. Embedding almadan önce her parçanın başına onu konumlandıran kısa bir üretilmiş veya şablonlanmış bağlam satırı ekleyin: belge başlığı, bölüm yolu, yürürlük tarihi ve bu parçanın belgenin bütünü içinde ne hakkında olduğunu anlatan tek cümlelik bir özet. Bu, yalıtılmış bir hükmü, hükmün kendi kelime dağarcığını tekrarlamadan belgeyi veya konuyu adlandıran sorgularla erişilebilir kılar. Bu bağlam satırlarını bir dil modeliyle üretmek veri alımında parça başına ucuz bir çağrı demektir; bir milyon parçada bu gerçek bir bütçe kalemidir, dolayısıyla ayrıştırılmış bölüm yolundan kurulan şablonlu bir sürüm faydanın büyük kısmını fiilen sıfır maliyetle yakalar.

Metadata Tasarımı: Çoğu Zaman Embedding'den Değerlidir

Bir RAG veri hattının en az yatırım alan parçası metadata şemasıdır ve çoğu zaman getirisi en yüksek parça da odur. Güncel harcama politikasını soran bir kullanıcı, 2019 baskısıyla anlamsal olarak mükemmel bir eşleşme istemez. Hiçbir embedding modeli hangi sürümün güncel olduğunu bilemez; bunu ancak bir alan bilir. Şemayı veri alımından önce tasarlayın ve zorunlu kılın: kaynak sistem ve belge kimliği, belge türü, başlık, bölüm yolu, sayfa veya madde numarası, yürürlük ve yürürlükten kalkma tarihi, sürüm kimliği ve yerine geçen sürüm işaretçisi, dil, OCR kapısından gelen güven bayrakları ve erişim yetkisi etiketleri.

Erişim yetkisi etiketleri özellikle vurgulanmayı hak eder, çünkü sonradan eklenmeleri hem zahmetli hem tehlikelidir. Her parça, onu görmeye yetkili grupların kimliklerini taşımalı ve filtreleme sıralamadan sonra değil erişim sorgusunun içinde gerçekleşmelidir. Sonradan filtrelemek kaliteyi sessizce bozar, çünkü ilk beş sonucun üçüne erişim yetkisi olmayan bir kullanıcı, erişimin budandığına dair hiçbir işaret olmadan kalan ikisinden kurulmuş bir cevap alır. Ayrıca biri filtrelenmemiş aday listesini loglar loglamaz bir sızıntı riskidir. Etiketleri birinci günden indekse koyun ve aynı sorunun farklı yetkilere sahip iki kullanıcı tarafından sorulduğu bir yetki farklılığı değerlendirme kümesiyle test edin.

Metadata üç ayrı biçimde karşılığını verir. Kullanıcının sorduğu tarihte yürürlükte olan belgelerle sınırlamak gibi, bütün yanlış cevap sınıflarını eleyen sert filtreler mümkün kılar. Birleştirme sırasında güncel veya yetkili bir belgeye puan çarpanı verilen yükseltmeyi mümkün kılar; bu konu hibrit arama ve yeniden sıralama yazısında ayrıntılanıyor. Ve atıfları kullanışlı kılar, çünkü belgeyi, bölümü ve yürürlük tarihini adlandıran bir atıf bir insan tarafından saniyeler içinde doğrulanabilirken 48213 numaralı parça diyen bir atıf doğrulanamaz. Mühendislik zamanınız sınırlıysa, metadata'yı iyileştirmek çoğu zaman embedding modelini değiştirmekten daha çok kazandırır. Bu üç fayda birlikte, metadata şemasına ayrılan birkaç günlük tasarım çalışmasını kolayca amorti eder.

Tekilleştirme, Sürümler ve Yürürlükten Kalkmış Belgeler

Büyük korpuslar yakın kopyalarla doludur ve bunlar, birebir kopyaların olmadığı bir biçimde aşındırıcıdır. Aynı politika bir Word dosyası, bir PDF çıktısı ve bir intranet sayfası olarak var olur. Bir sözleşme şablonu doksan müşteri klasöründe yalnızca isimler değiştirilerek görünür. Bir mevzuat hükmü on iki kurum içi yazının içinde tam metin alıntılanır. Bir sorgu bu içerikle eşleştiğinde ilk beş sonuç aynı pasajın beş kopyası olur, erişim çeşitliliği çöker ve model beş olgu yerine tek bir olgunun beş tekrarını alır. Kullanıcı, ezici bir desteğe sahipmiş gibi görünen tek bir kaynak üzerine kurulmuş kendinden emin bir cevap alır.

Tekilleştirmeyi iki aşamada yapın. Birebir kopyalar önce, normalizasyon sonrası hesaplanan bir içerik özetiyle gider; bu ucuzdur ve çoklu dışa aktarım durumunu yakalar. Yakın kopyalar benzerlik tespiti gerektirir: on milyonlarca parçada ölçeklenebilir seçenek, kısa dizi parçaları üzerinde MinHash veya SimHash'tir; daha küçük kümelerde kabaca 0,95'in üzerinde embedding kosinüs benzerliği kontrolü daha pahalı bir incelik olarak eklenebilir. Eşleşenleri silmek yerine kümeleyin, kaynak otoritesi ve güncelliğe göre bir kanonik parça seçin ve diğerlerini kanonik olana bağlı tutun ki metnin başka nerelerde geçtiğini hâlâ raporlayabilesiniz. Sonra sorgu anında da çeşitlilik uygulayın ve tek bir belgeden kaç parçanın nihai bağlamı işgal edebileceğini sınırlayın.

Sürümleme daha zor problemdir ve belge tabanlı RAG'in kimsenin fark etmediği biçimde yanlış cevaplar ürettiği başlıca yerdir. Her belgenin bir yürürlük tarihine, isteğe bağlı bir yürürlükten kalkma tarihine ve onu değiştiren sürüme işaret eden açık bir işaretçiye ihtiyacı vardır. Erişim katmanının ardından bir varsayılan zaman politikasına ihtiyacı olur: genellikle hâlen yürürlükte olan belgelerle sınırlama, gerçekten tarihsel olan sorular için de açık bir belirli tarih itibarıyla modu. Yürürlükten kalkmış parçalar silinmek yerine işaretlenmelidir, çünkü kuralın eskiden ne olduğuna dair denetim soruları meşrudur ve özellikle düzenlemeye tabi sektörlerde yaygındır. Bunları sessizce silinmiş bir indeksten cevaplamak imkânsızdır; işaretlenmemiş bir indeksten cevaplamak ise daha kötüdür.

Türkçeye Özgü Konular ve Karma Korpuslar

Türkçe eklemeli bir dildir, dolayısıyla tek bir kök çok sayıda yüzey biçimi üretir ve bu biçimleri ilişkisiz token'lar gibi ele alan sözlüksel erişim belgeleri düpedüz kaçırır. Embedding modeli gerçekten Türkçe görmüşse yoğun erişim bunu makul ölçüde idare eder, ama her hibrit sistemin sözlüksel yarısı yardıma ihtiyaç duyar: düzgün gövdeleme veya kök bulma yapan bir Türkçe çözümleyici, noktalı ve noktasız i'nin doğru ele alınması ve Türkçe metni İngilizce yerel ayarıyla küçük harfe çevirmenin metni bozduğunun bilinmesi. Bu, sonuçları boyutunun çok üstünde olan bir yapılandırma ayrıntısıdır ve mevcut bir Türkçe arama indeksini incelerken bulduğumuz en yaygın kusurlardan biridir.

İkinci tuzak cümle bölütlemedir. Türkçe sıra sayılarında, 12.03.2026 biçiminde yazılan tarihlerde, vb. ve Av. gibi kısaltmalarda ve hukuki atıflarda nokta kullanır; dolayısıyla basit bir cümle bölücü metni tam da anlamın en yoğun olduğu noktalardan parçalar. Özyinelemeli ve anlamsal parçalamanın ikisi de cümle sınırlarına bağlı olduğundan, kötü bir bölütleyici hatalarını doğrudan parça sınırlarına yayar. Türkçe kısaltma listesi ve sayısal bağlam kuralları olan bir bölütleyici kullanın ve bir milyon belgede ona güvenmeden önce birkaç yüz bölme noktasını elle örnekleyerek doğrulayın. Bölütleyiciyi değiştirdiğinizde parça sınırları da değişir, dolayısıyla bunu bir yeniden indeksleme tetikleyicisi olarak listeleyin.

Karma korpuslar istisna değil normal durumdur. Türk kurumları düzenli olarak İngilizce teknik terimler içeren Türkçe metinleri, Türkçe ekleri olan İngilizce sözleşmeleri ve başlıkları İngilizce, değerleri Türkçe olan tabloları bir arada tutar. Dili belge başına değil parça başına tespit edin, metadata olarak saklayın ve embedding modelinizin iki dili dile göre kümelemek yerine ortak bir uzayda ele aldığını doğrulayın; bazı modeller dile göre kümeler ve bu, diller arası erişimi sessizce yok eder. Pratikte en çok önem taşıyan durumu açıkça test edin: İngilizce bir pasajı getirmesi gereken Türkçe bir soru ve tersi. Vektör veritabanı ve anlamsal arama katmanınızın bu testteki davranışını canlıya çıktıktan sonra değil önce bilmek gerekir.

Artımlı Yeniden İndeksleme ve Bunu Ölçekte Nasıl Yürütüyoruz?

Korpuslar değişir ve yalnızca sıfırdan yeniden kurulabilen bir veri hattı bir süre sonra hiç yeniden kurulmaz. Artımlı güncellemeleri baştan tasarlayın: yeniden yüklemeyi atlatan kalıcı bir belge kimliği, değişmemiş içeriğin atlanabilmesi için belge ve parça başına bir içerik özeti ve tam dizin taraması gerektirmek yerine oluşturma, güncelleme ve silme olaylarını taşıyan bir değişim akışı. Bir belge değiştiğinde onu yeniden ayrıştırın, yeniden parçalayın, parça özetlerini karşılaştırın ve yalnızca gerçekten değişeni yazın. Tipik bir kurumsal korpusta günlük fark belgelerin yüzde birinden çok azına dokunur, dolayısıyla artımlı veri alımı sekiz saatlik bir yeniden kurmayı dakikalar içinde biten bir işe çevirir.

Bazı değişiklikler yine de tam yeniden embedding'i zorunlu kılar ve bunların hangileri olduğunu bilmelisiniz. Embedding modelini, parça boyutunu, örtüşmeyi veya bağlamsal önek şablonunu değiştirmek indeksteki her vektörü geçersiz kılar. Bunu mavi-yeşil kalıbıyla planlayın: yeni indeksi eskisinin yanında kurun, değerlendirme paketini ikisine karşı da koşun, yeni indeks kazandığında okumaları oraya alın ve geri dönüş penceresi için eskisini bir süre tutun. Bir milyon belgelik korpusta tam yeniden embedding, makul paralellikle tipik olarak birkaç saatlik duvar saati süresidir, dolayısıyla kısıt genellikle hesaplama değil maliyet ve hız sınırlarıdır. Bunu yinelenen bir olay olarak bütçeleyin, çünkü ilk yılda iki üç kez yapacaksınız.

Kendi pratiğimiz, kimse parça boyutunu tartışmaya başlamadan önce ayrıştırıcıyı ölçmekle başlar. Yeni bir korpusta belge sınıflarına yayılmış 50 ila 100 sayfa örnekliyor, bunları çıkarıyor ve çıktıyı elle okuyoruz; kulağa ilkel geliyor ama denediğimiz her otomatik kontrolden saat başına daha çok kusur buluyor. Sonra değerlendirme kümesini kuruyor, ardından parça parametrelerini ona karşı tarıyoruz. caseon.ai ve DiligenceAI'ın arkasındaki belge yoğun çalışmalarda örüntü tutarlı oldu: ayrıştırma ve metadata çalışması, model değişikliklerinden daha büyük ve daha kalıcı kalite kazanımı üretti ve iyi yaşlanan sistemler, yürürlükten kalkmış sürümlerin silinmek yerine işaretlendiği sistemler oldu. Bu sıralama tesadüf değil: parametre taraması ancak ayrıştırıcı güvenilir olduğunda anlamlı bir sinyal üretir.

Açıkça söylenmesi gereken takas şudur: bu iş gösterişsizdir ve takvim aslında buraya gider. 50.000 ila 200.000 belgelik bir korpusta, erişim kalitesi eğrisi düzleşmeye başlamadan önce tipik olarak iki ila dört haftayı ayrıştırma, çıkarım, OCR kapılama ve parça parametresi ayarına harcıyoruz ve bu, değerlendirme düzeneği baştan sona çalışırken oluyor. Bunu atlayan ekipler zamandan tasarruf etmiyor; onu daha sonra işe yaramayacak prompt mühendisliğine ve uzun bağlam mı RAG mı yazısında incelenen uzun bağlam cazibesine harcıyor. Büyük bir belge varlığı üzerine inşa ediyorsanız, RAG ve anlamsal arama çözümlerimiz veri alımını asıl mühendislik problemi olarak ele alır, çünkü ölçekte öyledir.