Bir RAG (Retrieval-Augmented Generation) hattını dört ay boyunca bir Jupyter notebook'tan canlı bir servise taşımaktan sonra, yazar, gösterişli bir demoyu kullanıcıların gerçekten güvenebileceği bir sisteme dönüştüren beş somut seçimi belirledi. Fark rakamlarda kendini gösteriyor: metin bölme yöntemindeki basit bir değişiklik, getirme başarı oranını %61'den %83'e çıkardı ve 200 gerçek sorgudan oluşan mütevazı bir değerlendirme seti, artık çoğu regresyonu müşterilere ulaşmadan yakalıyor.
Neden Önemli
RAG demoları etkileyici görünür; bir pasaj bulurlar ve saniyeler içinde makul bir cevap üretirler. Üretim ortamında ise aynı yaklaşım genellikle güncelliğini yitirmiş gerçekleri, kaçırılan hata kodlarını veya bozuk cümleleri döndürerek kullanıcı güvenini sarsar. Darboğaz nadiren dil modelidir; asıl mesele içeriğin nasıl alındığı, indekslendiği ve sunulduğudur. Hattı doğru kurmak, değer katan bir ürün ile yük haline gelen bir ürün arasındaki farkı belirleyebilir.
1. Sabit boyutlu parçalar (chunks) kullanmayı bırakın
Birçok prototip, her belgeyi 512 token'lık bloklara böler. Bu yöntem kısa metinler için işe yarar ancak teknik kılavuzları, destek yazışmalarını ve kod parçacıklarını paramparça eder. Cümleler bölünür, başlıklar kaybolur ve getirme motoru kullanıcının beklediği bağlamla eşleşemez.
Anlamsal birimleri korumak için yapı duyarlı parçalamaya (structure-aware chunking) geçin; yani bölme işlemini başlıklarda, konuşma sınırlarında veya kod bloklarında yapın. Yazarın sisteminde, sadece bu değişiklik bile ilgili bir pasaj bulan sorgu oranını %61'den %83'e çıkardı. Bu iyileşme bir veri formatı değişikliğinden kaynaklanmaktadır; alttaki model aynı kalmıştır.
2. Hibrit arama kullanın
Saf vektör araması (embedding tabanlı benzerlik), aynı anlama gelen pasajları bulmada mükemmeldir ancak hata kodları, sürüm numaraları veya tescilli terminoloji gibi tam eşleşme gerektiren tanımlayıcılarda tökezler. "ERR-XXXX" gibi bir hata kodunu arayan bir kullanıcı, içinde kodun hiç geçmediği ancak anlamsal olarak benzer bir paragraf alabilir.
Hibrit arama, yoğun bir vektör indeksini geleneksel bir BM25 indeksi (terim frekansı tabanlı) ile birleştirir. Sistem, iki skoru ağırlıklandırarak hem anlamsal olarak yakın hem de kullanıcının yazdığı tam terimleri içeren öğeleri getirir. Üretim ortamı için hibrit arama bir "olsa iyi olur" eklentisi değil, temel bir gerekliliktir.
3. Güncelliğini yitirmiş verileri yönetin
Güncelliğini yitirmiş fiyat tabloları, politika belgeleri veya donanım yazılımı sürüm notları güvenilirliği hızla yok eder. İndeksi taze tutmak için üç pratik adım şunlardır:
- Her belgeyi bir sürüm damgası veya zaman damgası ile etiketleyin.
- Puanlama sırasında bir güncellik artışı (recency boost) uygulayın, böylece yeni öğeler eski kopyaların önüne geçsin.
- Kaynak sistemlerdeki değişiklikleri çekmek için her gece artımlı yeniden indeksleme (incremental re-indexing) çalıştırın.
Bu korumalar, sistemin geçen çeyrekte geçerli olan bir fiyatı veya halihazırda yürürlükten kalkmış bir politikayı sunmasını engeller.
4. Modelleri yükseltmek yerine yeniden sıralama (rerank) yapın
Bir embedding modelini yükseltmek yalnızca küçük bir kalite artışı sağlar, oysa bir cross-encoder yeniden sıralayıcı (reranker) eklemek, daha düşük maliyetle çok daha büyük bir sıçrama sağlar.
Üretim akışı, hibrit arama kullanarak 20 ucuz aday getirir, ardından en iyi beşini seçmek için bunları yeniden sıralayıcıdan geçirir. Bu iki aşamalı yaklaşım, tam bir model yükseltme maliyetinin çok küçük bir kısmıyla çok daha büyük bir kalite artışı sağlar.
5. Gerçek bir değerlendirme seti oluşturun
Ölçemediğiniz şeyi geliştiremezsiniz. Yazar, her biri uzman elinden çıkmış bir cevapla eşleştirilmiş 200 gerçek kullanıcı sorgusundan oluşan bir test paketi hazırladı. Her kod değişikliği bu paket üzerinde çalıştırılır; böylece herhangi bir regresyon dağıtım öncesinde yakalanır.
Bir kullanıcı kötü bir cevap bildirdiğinde, bu sorguyu hemen değerlendirme setine ekleyerek gerçek dünyadaki hataları gelecekteki koruma mekanizmalarına dönüştürün. Her üretilen cevabın sürekli olarak günlüğe kaydedilmesi (logging), değerlendirme döngüsünü besleyerek sistemin gerçek kullanım ile uyumlu kalmasını sağlar.
Pratikte üretim hattı
- Veri Alımı (Ingest): Yapı duyarlı parçalama; başlıkları, kod bloklarını ve konuşma akışlarını korur.
- İndeksleme (Index): Hem yoğun embedding'leri hem de BM25 terim istatistiklerini saklar.
- Getirme (Retrieve): Hibrit arama, anlamsal benzerlik ile tam terim eşleşmelerini dengeleyerek 20 aday getirir.
- Yeniden Sıralama (Rerank): Bir cross-encoder, listeyi en umut verici beş pasajla sınırlar.
- Üretme (Generate): LLM, nihai cevabı oluşturmak için bu en iyi parçaları ve meta verilerini alır.
- Değerlendirme (Evaluate): Her yanıt günlüğe kaydedilir; hatalar 200 sorguluk test setine geri beslenir.
Riskler ve ödünleşimler
İyi yapılandırılmış bir pipeline, halüsinasyonları azaltır, cevap alakasını artırır ve aşırı kapasiteli modellerin maliyetini düşürür. Bunun avantajı, daha yüksek kullanıcı memnuniyeti ve daha düşük destek yüküdür. Bu adımların göz ardı edilmesi, marka güvenini zedeleyen ve maliyetli kriz yönetimine (firefighting) zorlayan kırılgan bir hizmete yol açar.
Sırada ne var
Açık kaynaklı embedding'ler ve vektör veritabanları olgunlaştıkça, "yoğun" (dense) ve "seyrek" (sparse) geri çağırma (retrieval) arasındaki çizgi bulanıklaşacak, ancak anlamsal (semantic) ve tam eşleştirme (exact matching) yöntemlerini birleştirme ilkesi geçerliliğini koruyacaktır.
Özetle: Bir RAG sisteminde dil modeli nadiren darboğazdır. Asıl iş, temel içeriği nasıl dilimlediğiniz, indekslediğiniz ve sunduğunuzda yatar. Bu kararları doğru vermek, gösterişli bir demoyu güvenilir bir ürüne dönüştürür.