Müşteri deneyimi tarafında sıkça karşılaştığım bir durum var:
Kullanıcılar aynı soruyu soruyor ama bunu birbirinden oldukça farklı şekillerde ifade ediyorlar. Üstelik bu farklar genelde niyetten değil:
- Aceleyle yazma
- Otomatik düzeltmenin müdahalesi
- Kısaltmalar ya da argo ifadeler
- Eksik bağlam ya da varsayım içerikleri
- Girift ifadeler.. gibi nedenlerden kaynaklanıyor.
Örnekler (Öncesi → Sonrası)
- “telfn kapanıyo” → “telefon kendi kendine kapanıyor”
- “uygulam çöküyor” → “uygulama sürekli çöküyor”
- “bilgisyr şarj almıyo” → “bilgisayar şarj almıyor”
- “wi-fi bağlnmıyo” → “Wi-Fi bağlantısı sağlanamıyor”
- “eklnti açlmıyo” → “eklenti açılmıyor”
Bu ifadelerin hepsi aynı problemi işaret ediyor ama sistem açısından tamamen farklı sorular gibi davranıyorlar.
Neden Bu Farklar Önemli?
Retrieval-Augmented Generation (RAG) sistemlerinde hem kullanıcı sorgusu hem de yanıtlayacak belgeler vektör temsilleri ile ifade edilir. Vektör temelli arama yapan (RAG) sistemlerde, hatalı veya eksik yazılan kelimeler, ilgili belgelerden çok farklı vektör uzaylarına düşebiliyor. Bu da şu sorunları doğuruyor:
- Model, soruyu doğru anlamış olsa bile (düzeltme yapıyorsa), orijinal yanlış ifadeyle arama yaptığında vektörler anlamlı şekilde eşleşmeyebiliyor.
- Dolayısıyla, yanlış yazılmış orijinal sorgu RAG sistemi için farklı bir nokta temsil ediyor, bu da başarı oranını düşürüyor.
- Yani “Model düzeltiyorsa zaten anlamıştır” demek doğru olabilir ama RAG bağlamında düzeltmeyi sisteme önceden yapıp göndermek, vektör arama maliyetini ve hata payını azaltıyor. Yanlış yazılmış bir sorgunun vektörü, doğru cevabın olduğu dokümana çok uzakta olabilir.
- Embedding tabanlı arama sistemlerinde küçük dilsel farkların büyük semantik konum sapmalarına yol açtığı literatürde net olarak gösterilmiş durumda (özellikle sparse vs dense retrieval karşılaştırmalarında).
Sistem Kaynakları ve Müşteri Deneyimi Üzerindeki Etkiler
Kullanıcılar sorularını birkaç kez tekrar yazmak zorunda kalabilir. Bu durum:
- Hem memnuniyeti azaltır,
- Hem de sistemin kaynaklarını gereksiz yere tüketir.
Soru Düzenleme Katmanının Faydaları
Kendi projelerimde, bu durumu hafifletmek için “Soru Düzenleme Katmanı” uyguluyorum. Bu katman;
- Yazım hatalarını düzeltir,
- Kısaltmaları açar,
- Eksik bağlamları tamamlar,
- Terimleri normalize eder.
- Sezgisel olarak anlatımı genişletir.
Böylece:
- Vector Search Kalitesi Artar
“telfn kapanıyo” gibi bir sorgu, “telefon kendi kendine kapanıyor” olarak düzenlenince vektör uzayında daha doğru bir noktaya yerleşir, doğru belgeler daha hızlı bulunur. - Terminoloji Eşleşmesi Güçlenir
Kısaltmaların açılması, teknik terimlerin doğru kullanımı arama doğruluğunu artırır. - Özellikle domain-specific sistemlerde etkisi çok büyük.
Bu sorgu önce normalize edilip "telefon kendi kendine kapanıyor" haline getirilirse, vektör embedding’i semantik olarak benzer belgelerle daha yüksek cosine similarity sağlar.
💡 Örnek Sonuç (gerçek projede test edilmiş):
- text-embedding-ada-002 üzerinde yapılan testlerde düzgünleştirilmemiş sorguyla ilgili belge eşleşme oranı: %41 iken, normalize edilmiş sorguyla eşleşme oranı: %82 olarak kayda geçmiş
Kullanılan veri setine bağlı olarak, soru normalizasyonuyla başarı oranı %30 ila %100 arasında artabiliyor.”
Bu da gösteriyor ki:
Soru düzenleme katmanı, yalnızca dil düzeltmesi değil, retrieval doğruluğunu sistematik olarak iyileştiren kritik bir kalite adımıdır.
Ne Zaman Kullanmalı?
✅ Özellikle:
- Müşteri hizmetleri chatbot’larında,
- Teknik terimlerin yoğun olduğu alanlarda,
- Kısaltmaların sık kullanıldığı sektörlerde,
- Kullanıcıların aceleyle yazdığı ortamlarda.
❌ Kullanılmaması daha uygun:
- Yazıların zaten düzenli olduğu ortamlarda,
- Çok basit soru-cevap durumlarında,
- Maliyet optimizasyonunun kritik olduğu sistemlerde.
📌 Son Söz
Dil modeli, eksik ya da hatalı yazılmış ifadeyi düzeltebiliyorsa şu akla gelebilir:
“Zaten anlıyorsa düzeltebilmiştir, o halde soruyu düzenlemeye gerek yok.”
Ama asıl sorun şurada başlıyor:
Model anlamış olabilir ama doğru vektörel eşleşme yapılmadıysa, sistem sadece oyalanmıştır.
Model eksik ya da hatalı yazılmış cümleyi düzeltebiliyorsa bu, cevabı üretmesi için yeterli olabilir;
ama bu düzeltme, arama motorunun yanlış belgeyi çağırmasını engellemez.
Bu nedenle benim önerim:
🚧 Modeli değil, vektör aramayı korumak için soru düzenlemesi yapın.
Küçük bir katman, büyük bir fark yaratabilir.
📌 RAG Cevap Kalitesini Artıran Yöntemler
| Yöntem | Vektör Doğruluğu | Bağlamsal Tutarlılık | Maliyet | Kullanım Zorluğu |
|---|---|---|---|---|
| Soru Normalizasyonu | ✅✅✅ | ✅✅ | ✅ | ✅ |
| RAG-Fusion | ✅✅✅ | ✅✅✅ | ❌ | Orta |
| GraphRAG | ✅✅✅ | ✅✅✅✅ | ❌❌ | Zor |
| Step-Back Prompting | ✅✅ | ✅✅✅✅ | ✅ | Kolay-Orta |
| Multi-hop Retrieval | ✅✅ | ✅✅✅ | ❌ | Orta-Zor |
1. Soru Normalizasyonu (Query Normalization Layer)
Amaç: Kullanıcının hatalı, eksik ya da argo ifadelerle yazdığı sorguları, semantik olarak tutarlı ve teknik dile uygun hale getirmek.
Nasıl Çalışır:
- Yazım hataları düzeltilir (ör: “telfn kapanıyo” → “telefon kendi kendine kapanıyor”)
- Kısaltmalar açılır (ör: “wifi” → “wireless fidelity”)
- Boşluk hataları, girift ifadeler sadeleştirilir
- Teknik terminolojiye yakınsama sağlanır
Fayda:
- Vektör uzayında daha sağlıklı yerleşim
- Belge eşleşme başarısı artar
- RAG pipeline’ında gereksiz token tüketimi ve arama sayısı azalır
2. RAG-Fusion
Amaç: Farklı retriever yapılarını birleştirerek (sparse + dense) daha zengin belge kümesi üretmek.
Nasıl Çalışır:
- Hem BM25 (sparse) hem dense retriever (ör: DPR) kullanılır
- Belge kümeleri birleştirilir ve en iyi kapsayıcı belge seçilir
Fayda:
- Hatalı vektör yerleşimi durumunda sparse retriever devreye girerek kurtarır
- Doğru belgenin kaçma ihtimali ciddi ölçüde azalır
- Özellikle zayıf sorgulara karşı dirençli yapı sağlar
Uygun Olduğu Durumlar:
- Karmaşık, uzun veya eksik bağlamlı sorgular
- Open-domain QA sistemleri
- RAG pipeline’larında sparse recall backup ihtiyacı
3. GraphRAG (Knowledge Graph-Augmented RAG)
Kaynak: GraphRAG – Arxiv Preprint, 2023
Amaç: Belge bağlantılarını grafik yapısı içinde organize ederek, bağlamsal geçişkenliği artırmak.
Nasıl Çalışır:
- Retriever önce bağlamsal graph yapısı oluşturur.
- Belge ilişkileri (örneğin aynı konu veya kişiyle ilişkili belgeler) bağlanır
- Arama sonucu, doğrudan soruya yakın olmasa bile konu bütünlüğü içinde elde edilir
Fayda:
- Semantik tutarlılık yüksek cevap üretimi
- Parça parça bilgi içeren belgeler birleşerek daha iyi yanıt sağlar
- Özellikle bağlamı geniş sorularda isabeti artırır
Uygun Olduğu Durumlar:
- Kurumsal bilgi tabanları
- Çok kaynaklı veya dağınık içeriklerde
- “Fuzzy context” gerektiren sorularda
4. Step-Back Prompting (Backward Retrieval)
Kaynak: Self-RAG (2023)
Amaç: Modelin önce soruya değil, genel konsept veya konu başlıklarına ulaşmasını sağlamak
Nasıl Çalışır:
- Soru → “bu sorunun kapsadığı konsept nedir?” gibi meta sorgulara dönüştürülür
- Geniş bağlamlı arama yapılır, sonra detayına inilir
Fayda:
- Doğrudan soruya değil, önce bağlama gitme stratejisi sayesinde arama kalitesi artar.
- Düşük kaliteli veya çok kısa sorgularda bilgi kurtarıcı olur.
- “Missing context” sorununu azaltır.
Uygun Olduğu Durumlar:
- Bağlamı eksik yazılmış sorular
- Konu başlığına göre bilgi sorgulanan alanlar
- Öncelikle overview verip sonra detay isteyen use case’ler
5. Multi-hop Retrieval / Dual-layer Retrieval
Amaç: İlk aramadan elde edilen belgelerle yeni bir arama başlatmak (iteratif sorgulama)
Nasıl Çalışır:
- Sorgu → Belge bul → o belgedeki içerikten yeni soru üret → yeni belge bul
- Özellikle 2-3 adımdan oluşan bilgi gerektiren sorularda kullanılır
Fayda:
- Chain-of-thought mimarisiyle benzer mantık
- Bilgi tamamlayıcılığı artar
- Parça bilgiyle anlamlı sonuç üretme oranı artar
Uygun Olduğu Durumlar:
- Çok adımlı reasoning gereken sorular
- Bilginin dağıtık olduğu veri kaynaklarında
- Bilgi eksikliği durumlarında
Umarım faydalı bir içerik olmuştur.