Ölçeklenebilir Üretim Ortamında RAG: Günlük 10.000'den Fazla İlan Deneyiminden Çıkarılan Dersler
Bir iş ilanı platformu için bir RAG pipeline'ı kurdum. Staging ortamında çalışıyordu ancak gerçek yük altında zorlandı. Günlük binlerce ilanı işlemek, iyi bir vektör deposundan (vector store) daha fazlasını gerektirir. Sistemin nerede kırıldığını anlamanız gerekir.
İşte chunking, embedding, maliyetler ve gözlemlenebilirlik (observability) üzerine derslerim.
1. Chunking stratejinizi tahmin etmeyin
Çoğu eğitim rehberi, chunking işlemini basit bir ayar gibi ele alır. Üretim ortamında ise stratejiniz, doğruluğu ve maliyeti belirler.
İş ilanları için üç yöntemi test ettim:
- Sabit boyutlu chunklar (Fixed-size chunks): Bunlar başarısız oldu. "gereksinimler" ve "yan haklar" gibi bölümleri rastgele noktalardan böldüler. Bu da gürültülü bir retrieval (geri çağırma) süreci yarattı.
- Semantik chunking (Semantic chunking): Bu daha iyiydi ancak tutarsızdı. Bazı chunklar çok uzun, bazıları ise çok kısaydı.
- Örtüşmeli özyinelemeli karakter bölme (Recursive character splitting with overlap): En iyi sonuç veren bu oldu. Yeni satırlardan ve cümlelerden böldüm. 50 token'lık bir örtüşme (overlap) ile 400 token boyutunu kullandım. Bu, iki chunk'a yayılan cümlelerin bağlantılı kalmasını sağlar.
Profesyonel ipucu: Chunking yapmadan önce verilerinizi normalize edin. Greenhouse veya Lever gibi farklı kaynaklar farklı formatlar döndürür. Chunker'ınızın tutarlı bir yapı görmesi için önce metni temizleyin.
2. Embeddingler: Maliyet vs. Doğruluk
Ollama aracılığıyla Llama 3.1'i, OpenAI text-embedding-3-small ile kıyaslayarak test ettim.
Yerel model ücretsizdi ancak "equity compensation" (hisse senedi tazminatı) gibi alana özgü terimlerde zorlandı. Gürültülü sonuçlar üretti.
OpenAI daha maliyetliydi ancak doğru eşleşmeler sağladı. OpenAI'ı seçtim çünkü kötü bir retrieval, daha sonraki LLM çağrılarında daha yüksek maliyete yol açar.
Zaman kazanmak için isteklerimi toplu (batch) halde gönderiyorum. Tek bir çağrıda 100 chunk'a kadar gönderim yapıyorum. Bu, gecikmeyi (latency) azaltıyor ve pipeline'ın hızlı kalmasını sağlıyor.
3. Vektör Deposu Dengesi (Trade-off)
Prototipleme için kurulumu hızlı olduğu için Pinecone kullandım. Ancak ölçek büyüdükçe maliyetler çok yükseldi.
PostgreSQL içindeki pgvector'a geçiş yaptım.
- Kurulumu daha fazla iş gerektirdi.
- Muazzam miktarda para tasarrufu sağladı.
- İşlemsel tutarlılık (transactional consistency) sağladı.
Embeddingler iş verileriyle aynı veritabanında yaşadığı için tek bir doğruluk kaynağına (source of truth) sahip oluyorsunuz. İki farklı sistemi senkronize etmenize gerek kalmıyor.
4. LLM Maliyetlerini Kontrol Etmek
Her ilanı GPT-4o ile puanlamak pahalıdır. Maliyetleri düşürmek için üç taktik kullandım:
- OpenAI Batch API: Puanlama işlerini gece boyunca işliyorum. Bu, büyük bir indirim sağlıyor.
- Önbelleğe alma (Caching): Tekrarlanan aday profilleri için sonuçları önbelleğe alıyorum.
- Model katmanlandırma (Model tiering): "Sales Representative" gibi yaygın roller için GPT-4o-mini kullanıyorum. GPT-4o'yu ise yalnızca hassasiyetin hayati önem taşıdığı niş roller için kullanıyorum.
5. Önce Gözlemlenebilirliği İnşa Edin
Pipeline'ım bir keresinde sessizce hata verdi. Hatalı veriler boş chunk'lara neden oldu ve sistem bunları hata vermeden atladı.
Bunu, bir korelasyon kimliği (correlation ID) ile yapılandırılmış günlükleme (structured logging) ekleyerek düzelttim. Bu, bir ilanı veri alımından (ingestion) puanlamaya kadar takip etmemi sağladı. Sonunda hangi veri kaynaklarının hatalara neden olduğunu görebildim.
En büyük ders: Çoğu sorun yapay zekadan değil, düzensiz verilerden kaynaklanır. Önce veri tesisatınızı (data plumbing) düzeltin.
Optional learning community: https://t.me/GyaanSetuAi