Çoğu ekip, ilk geri çağırma (retrieval) boru hattını hâlâ aynı şekilde kuruyor. Sabit bir token sınırı seçiyorlar, belki 512, belgeleri tek tip bloklara bölüyorlar ve bu blokları bir vektör veritabanına besliyorlar. Basit soruların olduğu küçük bir veri setinde bu yöntem sihirli görünüyor. Ancak üretim ortamında (production) her şey çöküyor.
Bir madde cümlenin ortasından bölündüğünde, hukuki sözleşmeler anlamsız parçalara ayrılıyor. Tek bir parça (chunk) birbiriyle ilgisiz üç fonksiyonu yutarsa, API dokümantasyonu gürültülü bir karmaşaya dönüşüyor. Müşteri destek talepleri, segmentler arasında örtüşme (overlap) olmadığında tüm anlatı akışını kaybediyor. Sonuç öngörülebilir: şişkin gecikme süreleri (latency), zayıf geri çağırma (recall) ve üreticiyi (generator) halüsinasyon görmeye zorlayan yanıtlar.
Geri çağırma katmanımızı tamamen yıktık ve yeniden inşa ettik. Sonuç; geri çağırmada (recall) yüzde 78'den yüzde 95'e bir sıçrama, gecikme süresinde yüzde 62'lik bir azalma ve nihayetinde bir hafta sonu yaması gibi değil, gerçek bir altyapı gibi davranan bir boru hattı oldu. İşte gerçekten işe yarayanlar.
Akıllı Parçalama (Smart Chunking): Tokenlar Yerine Yapı
İlk hata, her belgenin aynı dili konuştuğunu varsaymaktır. 512 tokenlık bir parça, anlatısal metinler için mantıklıdır ve başka neredeyse hiçbir şey için değildir. Kaynağın anatomisine saygı duyan bir stratejiye geçtik.
Hukuki belgeler için özyinelemeli (recursive) parçalama kullanıyoruz. Algoritma önce bölümler ve maddeler gibi üst düzey sınırlar üzerinden bölmeye çalışır. Eğer bir bölüm hâlâ çok uzunsa, alt bölümlere, ardından paragraflara ve sonra cümlelere bakar. Bu, maddelerin mantıksal iç içe geçmişliğini korur. Bir rekabet etmeme sözleşmesi bozulmadan kalır. Tanımlar, tazminat şartlarıyla birbirine karışmaz.
API dokümantasyonu, yapı duyarlı (structure-aware) parçalama gerektirir. Bir fonksiyon imzası, parametre tablosu ve örnek isteği bir arada bulunmalıdır. Sabit bir token sayısından sonra bölmek, parametreleri bir parçada, örnekleri ise başka bir parçada bırakır. Bunun yerine belge nesnesine (document object) göre parçalıyoruz. Bir parça, tam bir uç noktayı (endpoint) veya tek bir fonksiyonu içerir. Böylece geri çağıran (retriever), soruyu gerçekten yanıtlayan, kendi kendine yeten bir referans döndürebilir.
Destek talepleri doğal olarak anlamsal (semantic) parçalamaya uygundur. Token sınırından kesmek yerine, konunun nerede değiştiğini tespit ediyoruz. Bir giriş şikayetiyle başlayıp faturalandırma sorusuna dönen bir talep, iki tutarlı parçaya bölünür. Her parça ihtiyacı olan meta veriyi taşır ve model artık kullanıcının gerçekte hangi sorunla ilgilendiğini tahmin etmek zorunda kalmaz.
Şirket içi wikiler daha karmaşıktır. Metinleri, tabloları, diyagramları ve gömülü tartışmaları karıştırırlar. Bunlar için ajan tabanlı (agentic) parçalama kullanıyoruz. Küçük bir dil modeli metni önceden okur ve tematik olarak tamamlanmış bir birimin nerede bittiğine karar verir. Veri alımı (ingestion) sırasında biraz daha maliyetlidir ancak her yeni sayfa formatı için kuralları elle ayarlama şeklindeki insan emeği gerektiren iş yükünü ortadan kaldırır.
Hibrit Geri Çağırma (Hybrid Retrieval): Her Yönü Kapsayın
Vektör araması, bulanık (fuzzy) anlamları yakalamada mükemmeldir. Yavaş yüklemeler hakkında soru sorduğunuzda, gecikme ve bant genişliği hakkındaki paragrafları memnuniyetle döndürecektir. Ancak tam eşleşmeleri bozmasıyla ünlüdür. Eğer bir geliştirici ERR_CONNECTION_REFUSED hata kodunu aratırsa, yoğun gömmeler (dense embeddings) bunu genellikle genel bir gürültü olarak algılar.
Klasik anahtar kelime algoritması olan BM25 ise bunun tam tersini yapar. Kesin dizeleri ve nadir terimleri tam isabetle bulur, ancak anlamsal nüansları kaçırır. Sözleşmenin imzalanmasıyla ilgili bir sorgu, "sözleşmenin yürütülmesi" (executing the contract) olarak etiketlenmiş içeriği asla yüzeye çıkaramayabilir.