RAG mı kullanmalı, tool mu yazmalı?

Veri yapılandırılmışsa tool yaz. Bakiye, işlem listesi, hacim gibi sorularda doğru cevap bir sorgudan gelir; bunu vektör aramasına yaptırmak hem yanlış hem pahalıdır. RAG, yapılandırılmamış metin içindir: politika dokümanları, prosedürler, sözleşme maddeleri, eski karar kayıtları. Pratik bir ayrım şudur: cevabı bir SQL sorgusu verebiliyorsa tool, cevabı bir insanın doküman okuyup yorumlaması gerekiyorsa RAG. İkisini karıştırmak, bizim ilk sürümümüzde en çok hataya yol açan karardı.

RAG'da chunk sınırı nasıl belirlenir?

Sabit karakter sayısıyla değil, dokümanın kendi yapısıyla. Biz başlık düzeyinde bölüyoruz: her bölüm bir chunk, çok uzunsa alt başlıktan bölünüyor, hedef 300-800 token. Başlık yolu ayrı bir alanda tutuluyor ama embedding alınmadan önce metnin başına ekleniyor; yoksa parça bağlamsız kalıyor ve model hangi kuraldan bahsettiğini anlamıyor. Chunk'ın yanında metadata da duruyor: doküman kimliği, sürüm, son güncelleme tarihi ve kimin görebileceği. Tarih olmadan tazelik ölçülemiyor, yetki etiketi olmadan da filtreleme yapılamıyor.

RAG'da modele 'bilmiyorum' nasıl dedirtilir?

İki kuralla. Birincisi eşik: getirilen parçaların benzerlik puanı eşiğin altındaysa modele hiç sorulmaz, doğrudan 'bu konuda dokümanım yok' denir. İkincisi alıntı zorunluluğu: cevaptaki her iddia bir parçaya bağlanır, bağlanamayan cümle cevaptan çıkar. Bu ikisi birlikte uydurmayı ciddi biçimde azalttı; model çıktısındaki kaynaksız iddia oranı yüzde 14'ten yüzde 2'ye indi. Bedeli de var: eşiği sıkılaştırınca dokümanda cevabı olan 30 sorudan 2'si gereksiz yere reddedildi. Ayrıca cevabın altında kaynak adı ve dokümanın son güncelleme tarihi gösteriliyor, böylece kullanıcı eski bir kuralı fark edebiliyor.

Ana sayfa → Teknik

RAG: Arama Değil, Bağlam Kurmak

28 Temmuz, destekten gelen bir soru: “Günlük çekim limiti kuralı ne?” Agent cevap verdi: net, gerekçeli, kaynaklı. Model eski kâğıdı doğru okudu; cevap yine de yanlıştı. Limit politikası 14 Temmuz’da güncellenmişti; doküman yenilenmiş, index yenilenmemişti. Model uydurmadı — ona 14 gün eski kâğıdı biz verdik. RAG’ın zor kısmı arama değil, modelin önüne hangi metnin konduğu.

Sertaç Yıldırım · 22 Eylül 2026, 11:30 · 15 dk okuma

Özet

Önce karar: RAG mı, tool mu? Cevabı bir SQL sorgusu veriyorsa tool; cevabı bir insanın doküman okuyup yorumlaması gerekiyorsa RAG. İlk sürümümüzün en büyük hatası bu ayrımı yapmamaktı.
Chunk sınırı dokümanın yapısıdır, sabit karakter sayısı değil. Bölüm başlığı embedding’e katılmazsa parça bağlamsız kalır.
Tazelik bir özellik değil, bir taahhüttür. Index güncellemesi durduğunda sistem hata vermiyor, eski cevap veriyor; kullanıcı bunu göremiyorsa yanılır.
Retrieval ayrı ölçülür, cevap ayrı. Doğru parça ilk 5’te mi? Bizde recall@5 21/30 (%70) idi; reranking ve anahtar kelime aramasıyla birlikte 27/30 (%90) oldu.
“Bilmiyorum” öğretilir: benzerlik eşiği + alıntı zorunluluğu. Kaynaksız iddia oranı %14’ten %2’ye indi — bedeli, 30 sorudan 2’sinin gereksiz yere reddedilmesi oldu.
Yetki index’te durur. Her chunk’ta kimin görebileceği yazılı; filtreleme arama anında yapılır, cevap üretildikten sonra değil.

Asıl karar: RAG mı, tool mu?

İlk sürümde bütün soruları aynı yoldan geçirdik: soruyu al, dokümanlarda ara, bulduğunu modele ver. “Bugün kaç dolar para yatırıldı?” sorusu da o yoldan geçti ve dokümanlardan “para yatırma süreçleri” sayfasını getirdi. Cevap güzel bir paragraftı ve içinde rakam yoktu.

Soru	Doğru yol	Neden
“Bugün kaç dolar para yatırıldı?”	Tool	Cevap bir sorgudan gelir, kesindir
“Günlük çekim limiti kuralı ne?”	RAG	Cevap bir politika dokümanında, yorum gerektirir
“Bu müşteri limiti aşmış mı?”	İkisi	Kural RAG’dan, rakam tool’dan; karşılaştırma kodda
“Geçen yıl bu kararı neden aldık?”	RAG	Karar kayıtları, toplantı notları
“KYC’de kaç başvuru bekliyor?”	Tool	Sayı; vektör araması burada yanlış araç

Üçüncü satır en sık gelen tip ve en öğretici olanı: kuralı RAG getiriyor, rakamı tool getiriyor, karşılaştırmayı kod yapıyor. Modele “bu müşteri limiti aşmış mı” diye sorup hem kuralı hem rakamı onun kafasında birleştirmesini beklemek, üç hatanın kapısını birden açmak.

RAG bir arama özelliği değil, modelin önüne konan kâğıdı seçme işidir. Yanlış kâğıt, kusursuz bir modelle bile yanlış cevaptır.

Chunk: sınırı doküman çizer

İlk denememizde 1.000 karakterde bölmüştük. Sonuç: bir limit kuralının başı bir chunk’ta, istisnası diğerinde. Model istisnayı hiç görmedi ve kuralı eksik anlattı.

Chunk ve metadata (bugünkü hâli)

{
  "id": "politika-cekim-v8#gunluk-limit",
  "baslik_yolu": "Cekim Politikasi > Limitler > Gunluk limit",
  "metin": "Gunluk cekim limiti ... (bolumun tamami, 420 token)",
  "kaynak": "politika/cekim.md",
  "surum": 8,
  "guncelleme": "2026-09-08",
  "yetki": ["destek", "risk", "yonetim"],
  "komsu": ["politika-cekim-v8#istisnalar"]
}

# embedding alinirken metin tek basina gomulmez:
#   gomulecek = baslik_yolu + "\n" + metin
# JSON'da ayri alanlar; vektore giderken birlesiyorlar.

Başlık yolu embedding’e katılır. JSON’da ayrı bir alanda duruyor ama vektör alınmadan önce metnin başına ekleniyor. Model “hangi politikanın hangi bölümü” olduğunu ancak böyle biliyor; tek başına paragraf, bağlamsız bir cümle yığını.
Hedef 300–800 token. Kısa olursa kural parçalanır, uzun olursa alakasız metin pencereyi yer.
Komşu bağlantısı. “İstisnalar” bölümü ayrı bir chunk ama komşu olarak işaretli; kural geldiğinde istisnası da geliyor. Bu tek ayar, eksik cevapların çoğunu bitirdi. Komşular ilk 5’in içinden sayılmıyor, üstüne ekleniyor; modele giden parça sayısı 5 ile 8 arasında değişiyor. recall@5 ölçümünde ise yalnızca sıralamadan gelen ilk 5 sayılıyor — komşu yoluyla gelen chunk o sayıya katılmıyor, yoksa ölçü kendi kendini şişirir.
Yetki etiketi. Arama sırasında filtreleniyor. Cevap üretildikten sonra filtrelemek, veriyi zaten modele göstermiş olmak demektir.
Sürüm alanı. Yalnızca bilgi için değil: yeni sürüm geldiğinde eskisinin silinmesi bu alana bağlı — aşağıda.

Tazelik: bizim 14 günümüz

Zaman çizelgesi

12 Tem   gecelik index isi sessizce oldu (bagimlilik yukseltmesi)
14 Tem   cekim politikasi v7 yayimlandi  -> dokuman guncel, index degil
28 Tem   OLAY: agent 14 gun eski kurali dogru okudu
~2 hafta "model uyduruyor" tartismasi
Agustos  uc haftalik duzeltme turu (yonlendirici / komsu chunk / webhook + alarm)
 8 Eylul politika v8 cikti -> v7 chunk'lari index'te duruyordu; silme adimi eklendi

Giriş paragrafındaki olayın sebebi basitti: index’i gecelik bir iş güncelliyordu ve o iş 12 Temmuz’da sessizce ölmüştü — politikanın 14 Temmuz’daki güncellenmesiyle ilgisi yoktu, bir bağımlılık yükseltmesinden sonra durmuştu. Kimse fark etmedi, çünkü sistem cevap vermeye devam ediyordu. Bozuk bir RAG sessizce çalışır; eski cevap, hata mesajı gibi görünmez.

Üç değişiklik yaptık:

Doküman değişince index güncellenir (webhook), gecelik iş yedek olarak kaldı.
Her cevabın altında kaynak ve tarih var: “Kaynak: Çekim Politikası v8, güncelleme 8 Eylül 2026”. Kullanıcı eski bir tarih görürse itiraz edebiliyor.
Tazelik alarmı: her doküman için kaynaktaki son değişiklik ile index’teki sürümün tarihi arasındaki fark hesaplanıyor; bu farkın maksimumu 24 saati geçerse alarm çalıyor. (İlk yazdığımız alarm “index’teki en eski doküman”a bakıyordu ve işe yaramıyordu: bir doküman meşru olarak iki yıldır değişmemiş olabilir. Ölçülmesi gereken yaş değil, gecikme.) Böylece iş bir daha sessizce ölemez.

Eski sürümü silmek: 14 günün kardeşi

Tazeliğin ikinci yarısını aşağıdaki üç haftalık turda hiç fark etmedik; turun bitiminden üç hafta sonra, 8 Eylül’de politikanın v8’i çıkınca anladık. Chunk id’sinde sürüm var: politika-cekim-v8#gunluk-limit. v8 yayımlandığında yeni chunk’lar eklendi — peki v7’ninkiler çıktı mı?

İlk kurulumda çıkmadı. Sonuç, eski cevap vermekten daha kötü bir şey: model iki çelişen kuralı aynı anda görüyor ve hangisinin geçerli olduğuna kendi karar veriyor. Üstelik ikisi de “kaynaklı” olduğu için alıntı kontrolü bunu yakalamıyor.

Şimdi index’e yazma işi iki adımlı: yeni sürümün chunk’ları yazılır, sonra aynı kaynak alanına sahip eski sürümlerin hepsi silinir. Silme adımı ayrı ve idempotent; yarıda kalırsa tekrar çalıştığında tamamlıyor. Kaynak dokümanın kendisi silindiğinde de aynı yol işliyor — dokümanın silinmesi, index’ten çıkması demek.

Bozuk bir RAG hata vermez, eski cevap verir. Bu yüzden tazelik, ölçülmediği sürece yoktur.

İsabeti ölçmek: iki ayrı sayı

“RAG iyi çalışıyor mu?” tek soru değil, iki soru: doğru parçayı getirdi mi, ve o parçadan doğru cevabı üretti mi? İkisi ayrı ölçülür, çünkü çözümleri farklı.

Ölçüm	Nasıl	Bizde
recall@5 (retrieval)	30 soru, her birinin doğru chunk’ı elle işaretli; ilk 5’te var mı?	21/30 (%70) → 27/30 (%90)
Cevap doğruluğu	Aynı 30 soru, doğru chunk elle verilerek	28/30 (%93)
Kaynaksız iddia oranı	Modelin ürettiği iddiaların kaçı hiçbir parçaya bağlanamıyor — filtre çalışmadan önce ölçülüyor	%14 → %2
Gereksiz red	Dokümanda cevabı olan 30 sorudan kaçı eşiğin altında kalıp reddedildi	0/30 → 2/30 (başlangıçtaki 0 ölçüm değil: eşik yokken red de yoktu)
“Bilmiyorum” isabeti	Dokümanda olmayan 10 soru; kaçında doğru şekilde reddetti?	6/10 → 10/10

Kaynaksız iddia satırının neden filtreden önce ölçüldüğünü açalım: kod zaten kaynaksız cümleleri cevaptan çıkarıyor, dolayısıyla kullanıcıya giden metinde bu oran sıfıra yakın. Ama bu, modelin uydurmayı bıraktığı anlamına gelmiyor — sadece uydurduğunun kullanıcıya ulaşmadığı. %14 ile %2, modelin denediği oranı gösteriyor ve asıl izlenmesi gereken sayı bu; yükselirse retrieval bozulmuş demektir. Filtre bir güvenlik ağı, bir ölçü değil.

Gereksiz red satırı, kaynaksız iddia satırının faturası. Burada bir ayrım şart: recall@5 27/30, yani üç soruda doğru parça zaten ilk 5’e girmiyor — o sorularda gelen bir red eşiğin değil retrieval’ın sonucu olurdu ve aslında doğru davranıştır. Saydığımız 2 red o üçle kesişmiyor: ikisinde de doğru parça ilk 5’teydi, puanı eşiğin altında kaldı. Yani bunlar gerçekten eşiğin faturası. Bedeli bilerek ödüyoruz — yanlış cevaptan iyi — ama ölçmeden kabul etmek olmaz: eşik ayarı her zaman iki yönlü bir pazarlık.

Cevap doğruluğu satırı ise sorunun nerede olduğunu söylüyordu: doğru parça verildiğinde cevap doğruluğu zaten 28/30’du. Yani sorunumuz model değil, retrieval’dı. Model değiştirmek bu tabloyu düzeltmezdi; iyileştirme gereken yeri ancak iki sayıyı ayırdığımızda gördük.

Örneklem çekincesi: 30 soruluk bir sette tek bir soru ~3,3 puan ediyor; “bilmiyorum” seti ise sadece 10 soru. Bu sayılar bizde yönü doğru gösterdi ama 3–4 puanlık farkları gürültü sayıyoruz ve öyle saymanı öneririm. Sabit set küçük olduğu sürece ondalıklı iyileştirme iddiası yapılmaz.

Yetki filtresi bu sayıları da değiştiriyor

Yetki filtresi arama anında çalışıyor, yani aday havuzunu daraltıyor. Dar yetkili bir kullanıcıda aynı soru için daha az aday var; doğru parçanın ilk 5’e girme şansı mekanik olarak değişiyor. Bizim 27/30’u tek bir profille — kataloğun tamamını görebilen, en geniş erişimli profille — ölçtük; yani o sayı bir üst sınır. (Chunk’taki yetki listesi bir hiyerarşi değil: destek, risk ve yonetim farklı doküman kümelerini görüyor, biri diğerini kapsamıyor.) Dar profillerde ayrıca ölçmek lazım ve biz bunu henüz düzenli yapmıyoruz.

İkinci etki kullanıcı tarafında ve daha sinsi: yetkisi olmadığı için “dokümanım yok” cevabını alan kişi bunu “böyle bir doküman yok” diye anlıyor. Davranış doğru, izlenim yanlış. Mesajı ayırdık: “bu konuda dokümanım yok” ile “bu konuda senin görebileceğin bir doküman yok” aynı cümle değil. İkincisi dokümanın varlığını sızdırıyor; bazı ortamlarda bu kabul edilebilir, bazen değil. Kararı bilerek ver, varsayılana bırakma. Biz ayırmayı seçtik: bu bir iç araç ve politika kataloğunun varlığını zaten herkes biliyor, dolayısıyla sızan bilgi yok denecek kadar az; buna karşılık “sistemde yok” yanılgısı destek ekibine gerçek zaman kaybettiriyordu. Müşteriye dönük bir yüzeyde aynı kararı vermezdik.

recall@5’i ne yükseltti?

Reranking. Vektör araması 20 aday getiriyor, küçük bir sıralayıcı model bunları soruya göre yeniden sıralıyor, ilk 5 modele gidiyor (komşularıyla birlikte 5–8 parça). Tek başına en büyük katkı: 21/30 → 25/30 (%70 → %83).
Anahtar kelime ile birleştirme (hibrit arama). Sadece vektör araması “IBAN”, “MT103”, “v8” gibi tam eşleşmeleri kaçırıyor. Klasik metin araması ile birleştirince 25/30 → 27/30 (%83 → %90).
Başlık yolunu embedding’e katmak. Küçük ama bedava: aynı kelimenin hangi politikada geçtiğini ayırt ediyor.

Reranking bedava değil

20 adayı yeniden sıralamak soru başına ortalama ~180 ms ekledi (p95’te ~310 ms) ve soru başına toplam model maliyetini — embedding, sıralayıcı ve cevabı üreten model birlikte — kabaca %15 artırdı. (Sıralayıcının kendisi ucuz; bedeli, her soruda 20 aday için çalışmasından geliyor.) Bizim kullanım biçimimizde — destek ekibinin sorduğu, insanın okuduğu sorular — bu takas kolay: yarım saniye kimseyi rahatsız etmiyor, yanlış kural ediyor. Sıcak yolda, kullanıcı beklerken çalışan bir agent’ta aynı hesap başka çıkabilir. Bu takası görev başına maliyet üzerinden kurmayı bir sonraki yazıda ayrıca anlatıyorum.

Türkçenin kendine has sorunu

Yukarıdaki “hibrit arama” maddesi Türkçede İngilizcedekinden daha önemli, çünkü anahtar kelime tarafı ekler yüzünden kolayca ıskalıyor: limit, limiti, limitinin, limitler klasik bir metin aramasında dört ayrı terim.

Gövdeleme (stemming) şart. Arama motorunun Türkçe çözümleyicisini açtık; sorgu ve doküman aynı gövdeye indiriliyor. Bunu yapmadan önce hibrit aramanın katkısı neredeyse yoktu — anahtar kelime tarafı zaten bulamıyordu.
Embedding modelinin Türkçesi daha zayıf. Aynı modelin İngilizce metinde verdiği isabeti Türkçede vermiyor; bu yüzden bizde hibrit aramanın anahtar kelime ayağı, İngilizce kurulumlara göre daha ağır basıyor. Çok dilli bir embedding modeli seçerken Türkçe örneklerle kendi setinizde ölçün; ilan edilen genel skorlar yanıltıyor.
Terimleri çevirmeyin. Dokümanda “chargeback” geçiyorsa chunk’ta da öyle kalsın; kullanıcı da öyle arıyor.

“Bilmiyorum” demeyi öğretmek

En tehlikeli cevap yanlış cevap değil, kaynaksız ama emin cevap. İki kural koyduk:

İki kural

# 1) Esik: getirilen parcalar yeterince benzemiyorsa modele hic sorma
if en_iyi_puan < ESIK:
    return MESAJ_DOKUMAN_YOK   # "Bu konuda dokumanim yok.
                               #  Politika ekibine sorabilirim."

# 1b) Yetki filtresi butun adaylari eledi ise AYRI mesaj:
#     (bkz. yukaridaki yetki bolumu - biz ayirmayi sectik)
if aday_sayisi_filtre_oncesi > 0 and aday_sayisi == 0:
    return MESAJ_YETKI_YOK     # "Bu konuda gorebilecegin bir dokuman yok."

# 2) Alinti zorunlulugu: her iddia bir parcaya baglanir
#    cevap uretildikten sonra kod kontrol eder:
for cumle in cevap.iddialar():
    if not cumle.kaynak_id:
        cevaptan_cikar(cumle)      # kaynaksiz cumle cevapta kalmaz

(Kod bloğundaki metinler ASCII; gerçek sistemde kullanıcıya dönen mesaj elbette Türkçe karakterli: “Bu konuda dokümanım yok.”)

İkinci kural cevabı bazen kısaltıyor ve bu iyi bir şey. Kullanıcıya giden metnin altında kaynak listesi var; tıklayıp dokümanın kendisini açabiliyor. Ölçtüğümüz en güzel yan etki: kullanıcılar artık cevabı doğrulayabildikleri için sisteme daha çok güveniyor — güven, emin görünmekten değil, gösterilebilir kaynaktan geliyor.

Alıntının varlığı, doğruluğu değildir

Yukarıdaki kod yalnızca kaynak_id var mı diye bakıyor. Yakalamadığı iki şey var: model doğru chunk’ı getirip yanlış olana atıf yapabilir, ya da chunk’ta hiç geçmeyen bir ayrıntıyı ona bağlayabilir. İkisi de “kaynaklı” göründüğü için filtre geçiyor.

Bizim şu anki çözümümüz tam değil: sekiz haftadır haftada 20 cevabı elle denetliyoruz; toplam 160 cevabın 6’sında yanlış atıf bulduk (~%4). Paydayı karıştırma: bu oran cevap başına; tablodaki kaynaksız iddia oranı ise iddia başına. İkisi doğrudan karşılaştırılamaz. Otomatik doğrulama (her iddiayı kaynak metne karşı ayrı bir modelle sınamak) denenmeye değer ama maliyeti iki katına çıkarıyor; bizde henüz kalıcı değil. Bunu çözülmüş bir konu gibi anlatmak yanlış olur.

Sahadan: üç hafta, üç düzeltme

Sıralamayı biz seçmedik. Tazelik en sona kaldı, çünkü sebebini en son anladık: ilk iki hafta “model uyduruyor” diye konuştuk ve yanlış yerde arandık. Üstelik tazeliğin yarısını o turda hiç görmedik: eski sürümlerin index’te kalması turdan üç hafta sonra, 8 Eylül’de v8 çıkınca ortaya çıktı.

Hafta	Sorun	Düzeltme	Sonuç
1	Rakam soruları dokümanlardan cevaplanıyor	Yönlendirici: rakam → tool, metin → RAG	12 sorunun 12’si doğru yola gitti
2	Kural geliyor, istisnası gelmiyor	Komşu chunk bağlantısı	30 soruda eksik cevap 9 → 1
3	Index’i besleyen iş ölmüş, kimse görmüyor	Webhook + tazelik alarmı + cevapta tarih	Tipik gecikme ~24 sa → ~2 dk; ve arıza artık sessiz değil

Üçüncü satırı dürüst okumak lazım: normal gecikmemiz hiçbir zaman 14 gün değildi, gecelik işte en fazla bir gündü. 14 gün, işin ölmesinden doğan bir arızaydı — webhook süreyi kısalttı, alarm ise arızayı görünür yaptı.

Yapılacaklar

Soruyu önce yönlendir: tool mu, RAG mı?
Chunk’ı başlık düzeyinde böl, başlık yolunu embedding’e kat.
Metadata tut: sürüm, tarih, yetki, komşu.
Yeni sürüm yazılınca eskisini index’ten sil.
Türkçe için gövdeleme aç, hibrit arama kur.
recall ve cevap doğruluğunu ayrı ölç; gereksiz reddi de say.
Eşik + alıntı zorunluluğu; cevapta kaynak ve tarih göster.

Yapılmayacaklar

Rakam sorularını vektör aramasına sordurmak.
Sabit karakter sayısıyla bölmek.
Index güncellemesini gecelik bir işe bırakıp izlememek.
Tazeliği “en eski doküman”la ölçmek — ölçülecek olan yaş değil, gecikme.
“Model uyduruyor” deyip model değiştirmek — önce recall’a bak.
Alıntının varlığını doğruluğu sanmak.
Cevabı üretip sonra yetkiye göre gizlemek.

Ne izlemeli?

recall@5. Haftalık; 30 soruluk sabit set. Düşerse doküman yapısı değişmiştir.
Index tazeliği. Doküman başına “kaynaktaki son değişiklik − index’teki sürüm” farkının p95’i ve maksimumu. Alarm maksimuma bakar.
Kalıntı sürüm sayısı. Index’te, kaynağın güncel sürümünden eski chunk kalmamalı; sayı sıfır değilse silme adımı çalışmıyor.
“Dokümanım yok” oranı ve gereksiz red. Birlikte bakılır: birincisi düşerse uyduruyor, ikincisi yükselirse işe yaramıyor.
Kaynaksız iddia oranı (filtre öncesi). Filtre sonrası sıfıra yakın olacak; izlenmesi gereken öncesi.
Yanlış atıf oranı. Örneklemle, elle. Otomatik ölçemiyorsan bile sayıyı bil.
Chunk başına çağrılma sayısı. Hiç getirilmeyen dokümanlar: ya gereksiz ya da kötü bölünmüş.
Yetki profiline göre recall. Tek profille ölçülen recall bir üst sınırdır; dar yetkili bir profille de ölç.
Yetki filtresi isabeti. Bir kullanıcının görmemesi gereken chunk, sonuçlara hiç girmemeli; test setiyle ölç.

Kontrol listesi

RAG kurmadan önce

Bu soru tipinin cevabı yapılandırılmış veride mi, metinde mi?
Yönlendirici var mı: rakam sorusu tool’a gidiyor mu?
Chunk sınırını ne belirliyor: başlık mı, karakter sayısı mı?
Başlık yolu embedding’e katılıyor mu?
Metadata’da sürüm, tarih ve yetki var mı?
Index ne zaman güncelleniyor? Gecikme doküman başına ölçülüyor mu?
Yeni sürüm gelince eskisinin chunk’ları siliniyor mu? Silinen doküman index’ten çıkıyor mu?
Türkçe için gövdeleme açık mı? Embedding modelinin Türkçe isabetini kendi setinde ölçtün mü?
recall@k ölçülüyor mu? Kaç soruluk set — ve tek soru kaç puan ediyor?
Komşu chunk’lar ilk 5’in içinde mi sayılıyor, üstüne mi ekleniyor — ve recall ölçümüne giriyorlar mı?
recall’ı kaç yetki profiliyle ölçtün? Dar yetkili kullanıcıda da ölçtün mü?
Reranking var mı? Eklediği gecikme ve maliyet ölçüldü mü?
Eşik altında ne oluyor: uyduruyor mu, “bilmiyorum” mu diyor? Gereksiz red oranı ne?
Alıntının varlığını mı kontrol ediyorsun, doğruluğunu mu?
Cevapta kaynak ve tarih görünüyor mu?
Yetki filtresi arama anında mı çalışıyor?

Sonuç

Agent o gün eski kâğıdı doğru okudu; cevap yine de yanlıştı. Sonraki iki hafta boyunca “model uyduruyor” diye konuştuk, oysa model önüne konanı düzgünce özetlemişti. İki sayıyı ayırıp retrieval’i ayrı ölçtüğümüzde iş on dakikada netleşti: doğru parça verildiğinde cevap doğruluğu zaten 28/30’du, doğru parçayı getirme oranı ise 21/30.

Bugün soru önce yönlendiriliyor, parçalar başlık düzeyinde bölünüyor, sonuçlar yeniden sıralanıyor, eski sürümler index’ten siliniyor, eşik altında “dokümanım yok” deniyor ve her cevabın altında kaynağın adı ile tarihi duruyor. Gecikme bir günden iki dakikaya indi — ama asıl kazanç, geciktiği gün bunu bilecek olmamız. 14 günü üreten şey yavaşlık değildi, sessizlikti.

Akılda kalacak cümle: RAG’da model son adımdır; kalite ondan önceki adımlarda belirlenir. Yanlış kâğıdı iyi özetleyen bir sistem, güvenilir görünen bir yanlış üretir.