Türkçe RAG Nasıl Test Edilir? Ekim 2026 Araçları ve 5 Adımlı Rehber

Kurumsal Türkçe RAG (retrieval-augmented generation) projelerinin büyük çoğunluğu canlıya çıktığı ikinci haftada aynı ölçülebilir nedenden dolayı güven kaybeder: ekipler prototipi temiz paragraflardan seçilmiş on kolay soruyla doğrular, ardından sistemi yanıtların önemli bir bölümünün birleştirilmiş hücreli PDF tablolarında, tarife cetvellerinde, taranmış formlarda ve sondan eklemeli Türkçe mevzuat maddelerinde yaşadığı gerçek kurum arşivine bağlar. Asistan yanlış komisyon oranı verdiğinde veya alakasız sözleşme maddesine atıf yaptığında ekipler haftalarca üretici LLM değiştirmeye çalışır; oysa hata iki adım önce PDF ayrıştırma ve erişim (retrieval) katmanında gerçekleşmiştir.

Ekim 2026’da yayınlanan üç açık kaynak çalışma, mühendislik ekiplerine bu kör noktaları rakamla yakalayacak çok net araçlar sundu: Google’ın 27 Ekim’de makalesini yayınladığı EmbeddingGemma 2, Microsoft’un görsel yoğun PDF kıyaslama seti SynthDocQA ve Qwen’in çok dilli bankacılık erişim derlemi içeren 23 dilli BabelArena veri seti. Etkileşimli RAG yanıtları nasıl bulur rehberimiz ve 44. Hafta Kurumsal Yapay Zeka Bültenimiz üzerine kurduğumuz bu yazıda, Türkçe RAG sistemlerini canlıya çıkmadan önce sistematik test etmenin beş adımlı mühendislik metodolojisini paylaşıyoruz.

• Ekim 2026 RAG test araçları: EmbeddingGemma 2, Microsoft SynthDocQA ve Qwen BabelArena’nın kurumsal RAG hattındaki üç ayrı arıza katmanını nasıl ölçtüğü.
• Kritik çalışma zamanı ve Türkçe tuzakları: EmbeddingGemma 2’de float16 kullanımının vektörleri neden sessizce bozduğu, düz metin testlerinin SynthDocQA karmaşıklığının %94,9’unu neden kaçırdığı ve Türkçe ek yapısının tek başına vektör aramasını nerede yanılttığı.
• 5 adımlı CI kalite kapısı: 120 soruluk katmanlı Türkçe altın test seti kurgusu, erişim metriklerini (Recall@5, nDCG@10) kaynak sadakatinden ayırma ve geç etkileşimli (late-interaction) yeniden sıralama.

Ekim ayında öne çıkan üç açık kaynaklı araç birbirini tekrar etmek yerine RAG mimarisinin üç ayrı katmanını sınar: embedding modeli, PDF sayfa/tablo ayrıştırıcısı ve çok dilli sektörel erişim.

6 Ekim’de duyurulan ve teknik ayrıntıları 27 Ekim tarihli makalesinde paylaşılan EmbeddingGemma 2; metin, görsel, ses ve videoyu aynı 768 boyutlu vektör uzayında buluştururken yalnızca metin modunda çalıştırıldığında 8.192 token penceresiyle sadece 270M parametre tüketiyor. Matryoshka Temsil Öğrenimi (MRL) desteği sayesinde vektör boyutunu 768’den 512, 256 veya 128’e indirerek vektör veritabanı bellek maliyetini kontrollü bir ödünleşimle 3 ila 6 kat küçültebiliyorsunuz.

Ancak üretim ortamında EmbeddingGemma 2 kullanırken iki mühendislik gerçeğini gözden kaçırmamak gerekir:

• Kesinlikle float16 (FP16) ile canlıya almayın: Pek çok hazır konteyner şablonu bellek kazanmak için varsayılan olarak --dtype half (float16) açar. Gemma ailesinin aktivasyon aralığında float16 sayısal taşmaya ve vektör temsillerinin sessizce bozulmasına yol açar. Hem toplu indeksleme işlerinde hem de canlı sorgu servisinde açıkça bfloat16 veya float32 zorunlu tutun.
• Genel çok dilli embedding modelleri fine-tuning (ince ayar) olmadan Türkçe uzmanlık maddelerinde zorlanır: 270M parametreli genel bir çok dilli model konunun “kira sözleşmesi” olduğunu kolayca anlar; ancak Türk Borçlar Kanunu kapsamındaki tahliye bildirim süresiyle ticari kira artış üst sınırını anlatan komşu maddeleri vektör uzayında birbirine fazla yakın düşürebilir. Etkileşimli doğru maddeyi bulmak yazımızda canlı gösterdiğimiz üzere, EmbeddingGemma 2 üzerine Türkçe mevzuat ve içtihatla ince ayar yaptığımız Kenning Turkish Legal modeli tam olarak bu yakın madde ayrımını keskinleştirmek için geliştirilmiştir.

İndeksleme betiğiniz ile canlı sorgu mikroservisinizi hemen kontrol edin: Gece çalışan indeksleme işi CPU üzerinde float32 koşarken canlı API sunucunuz GPU’da varsayılan float16 ile açıldıysa, kosinüs benzerliği skorlarınız daha ilk adımda sessizce kaymıştır.

Microsoft SynthDocQA veri setindeki 9.798 sorunun sayfa bileşenlerine dağılımına dikkatle bakın: soruların %40,4’ü tablolardan, %29,6’sı şekillerden, %15,3’ü yapılandırılmış formlardan, %9,6’sı ek açıklamalardan gelirken yalnızca %5,1’i düz metin bloklarından geliyor.

SynthDocQA önizleme sürümü İngilizce olsa da doküman yerleşim dağılımı Türkiye’deki şirket arşivleriyle (KAP ve BDDK finansal dipnot tabloları, sigorta poliçe özel şart cetvelleri, teknik ihale birim fiyat ekleri, İK yan hak matrisleri) birebir örtüşür. PDF tablo geometrisi ve OCR ayrıştırma başarısı dilden büyük ölçüde bağımsız olduğu için, mevcut doküman okuma hattınıza SynthDocQA içinden 500 tablo ve form sorusu verdiğinizde ayrıştırıcınızın birleştirilmiş sütun başlıklarını koruyup korumadığını bir öğleden sonra içinde ölçebilirsiniz.

Sisteminiz %5,1’lik düz metin diliminde %90 alırken %40,4’lük tablo diliminde %38’e düşüyorsa üretici LLM değiştirmek zaman kaybıdır. Önce veri giriş hattını düzeltin: tabloları sütun başlıkları her parçada tekrarlanacak şekilde yapılandırılmış HTML/Markdown olarak saklayın, her tablo parçasına üst bölüm başlığını üst veri (metadata) olarak ekleyin ve grafik yoğun sayfalarda görsel sayfa gömmesi veya VLM tabanlı tablo özeti üretin.

PDF ayrıştırıcınız tabloları sağlam çıkardıktan sonra ikinci sınav Türkçe erişim kalitesidir. Qwen BabelArena, Türkçeyi orta kaynaklı (medium-resource) dil sınıfında değerlendiren 23 dilli yapısıyla ve 698 dokümanlık çok dilli bankacılık erişim derlemiyle hazır bir referans ölçeği sunar. Qwen veri setini 22 Ekim’de yayımladı; setin dayandığı makale ise 20 Eylül’de çıkmıştı. Tek ve kesin kural: BabelArena yalnızca test (evaluation-only) amaçlıdır; ölçüm güvenilirliğini bozmamak için hiçbir zaman ince ayar verisine karıştırılmamalıdır.

Türkçe finans, hukuk ve ERP dokümanlarında yalnızca tek vektörlü yoğun (dense) arama kullandığınızda iki sorgu tipi sürekli kaçar:

1. Tam madde/tebliğ kodları ve çekim ekli teknik terimler: “2026/4 sayılı tebliğin 12’nci maddesindeki gecikme faizi istisnası” gibi sorgularda hem anlamsal yakınlık hem tam kelime/numara eşleşmesi gerekir. Yoğun vektör aramasını Türkçe kök/ek duyarlı BM25 ile Reciprocal Rank Fusion (RRF) üzerinden hibrit çalıştırın.
2. Uzun cümle içindeki olumsuzluk ve şart ekleri: 600 tokenlık bir sözleşme maddesini tek bir 768 boyutlu vektöre sıkıştırdığınızda “yazılı muvafakat alınmaksızın devredilemez” ile “yazılı bildirimle devredilebilir” arasındaki kritik fark bulanıklaşır. İlk aşama hibrit aramadan gelen ilk 50 adayı, üretici LLM’e vermeden önce RuneLab’ın Apache 2.0 açık ağırlıklı Vor-LateEmbed-TR-0.6B-v1 modeli gibi ColBERT tarzı token düzeyinde geç etkileşimli (late-interaction) bir reranker’dan geçirmek en doğru 5–8 pasajı yukarı taşır.

İster sıfırdan kendi kurum içi RAG servisinizi geliştirin ister RuneBox üzerinde anahtar teslim kaynak doğrulamalı RuneDesk çalıştırın, canlıya geçişten önce şu beş kalite kapısını otomatikleştirin:

1. 120 soruluk katmanlı kurum içi Türkçe altın veri seti kurun: Geliştiricilerin yalnızca kolay paragraf soruları yazmasına izin vermeyin. Soruları beş zorunlu dilime bölün: %35 tablo ve rakam okuma, %20 birden fazla maddeyi birleştiren sentez, %20 tam madde/ürün kodu/tarih sorgusu, %15 dokümanlarda cevabı olmayan tuzak sorular (asistanın mutlaka “bu bilgi kaynaklarda yer almıyor” demesi gereken durumlar) ve %10 Türkçe karakter eksikliği veya yazım hatası içeren günlük çalışan soruları (“kidem tazminati tavani”, İngilizce kısaltmalı aramalar).
2. Erişim hatası ile üretim hatasını birbirinden ayırın: Recall@5 ve nDCG@10 skorlarını her zaman LLM yanıtından bağımsız kaydedin. Doğru kaynak pasaj ilk 5 parça arasına hiç giremiyorsa LLM istemini değiştirmek modeli yalnızca daha ikna edici tahmin yürütmeye zorlar.
3. Genel ortalamaya değil, en zayıf dilime göre onay verin: Genel skor %1 artarken Tablo dilimi veya Kaynak Dışı Ret dilimi %8 düşüyorsa sürümü engelleyin.
4. Matryoshka boyut küçültmeyi Türkçe üzerinde ayrıca doğrulayın: EmbeddingGemma 2 (veya türevi) vektörlerini 768 boyuttan 256 boyuta indirmeden önce altın test setinizi iki boyutta da çalıştırıp Türkçe yakın madde ayrımında Recall@5 kaybının 1,5 puanın altında kaldığını teyit edin.
5. Her kod değişikliğinde otomatik regresyon koşun: Parçalayıcı (chunker) veya indeks ayarlarındaki her pull request’te saniyeler süren erişim testini, her gece ise kurum içi yerel hakem model üzerinde kaynak sadakati testini çalıştırın.

Kurumsal bir RAG test setindeki en kritik %15’lik dilim, belgede cevabı olmayan tuzak sorulardır. Henüz yayınlanmamış bir şirket prosedürü sorulduğunda kaynak yok uyarısı vermek yerine mantıklı görünen bir paragraf uyduran asistana çalışan güveni bir günde sıfırlanır.

Mühendislik ekibinizin tablo duyarlı ayrıştırma, hibrit arama, yeniden sıralama ve otomatik CI değerlendirme hattını kendi verileriniz üzerinde uygulamalı olarak kurmasını isterseniz 10 modüllü Kurumsal RAG Eğitimi programımızı (ve rol bazlı yol haritası için Kurumsal Yapay Zeka Eğitimi Rehberimizi) inceleyebilir, hazır kaynak doğrulamalı doküman ve veritabanı asistanı için RuneDesk sayfasına göz atabilir veya mevcut RAG mimarinizin denetimi için RuneLab NexTech ekibiyle iletişime geçebilirsiniz.

Finans, hukuk, sigorta ve üretim şirketlerinde beklenen doğruluğu veremeyen RAG kurulumlarını incelediğimizde sorun nadiren üretici LLM’in “yeterince büyük olmamasından” kaynaklanır. Katmanlı bir Türkçe test paketi koşulduğunda neredeyse her zaman erişim ve ayrıştırma katmanındaki şu üç hatadan biri ortaya çıkar.

16 satırlık Türkçe bir harcırah limit tablosunun veya komisyon tarifesinin sabit 500 token sınırından körlemesine ikiye bölündüğünü düşünün. İlk 7 satır sütun başlıklarıyla (Kademe, Yurt İçi Günlük Limit (TL), Onay Makamı) aynı parçada kalırken, 8 ile 16. satırlar sütun etiketlerini kaybetmiş çıplak rakamlar olarak ikinci parçaya düşer.

Çalışan 12. satırdaki bir limiti sorduğunda ya arama motoru başlıksız parçayı hiç getiremez ya da LLM hangi rakamın hangi para birimi sütununa ait olduğunu tahmin etmeye çalışır.

Belge ayrıştırıcıyı bölünen her alt tablonun başına ana Markdown/HTML sütun başlıklarını ve belge adını otomatik tekrarlayacak şekilde güncellemek, üretici modele hiç dokunmadan %35’lik tablo test diliminde hemen belirgin bir artış sağlar.

Türkçe sözleşme ve mevzuat dilinde tek bir yapım veya çekim eki hukuki anlamı 180 derece tersine çevirirken cümlenin geri kalan kelimelerinin %95’i aynı kalır; örneğin “yazılı bildirimle devredilebilir” ifadesi ile “önceden yazılı muvafakat alınmaksızın devredilemez” şartı arasındaki fark tek bir vektör uzayında kolayca bulanıklaşır.

Tek vektörlü genel çok dilli bi-encoder modeller, ana kural maddesi ile onun istisnasını oluşturan fıkraya birbirine çok yakın kosinüs benzerliği atayarak istisna maddesini ilk 5 sonucun hemen altına itebilir.

İlk 50 adayı yoğun vektör + Türkçe kök/ek duyarlı BM25 hibrit aramasıyla toplayıp ikinci aşamada Vor-LateEmbed-TR-0.6B-v1 gibi token düzeyinde geç etkileşimli (late-interaction) bir reranker’dan geçirmek, olumsuzluk eklerini doğrudan yakalayarak doğru istisna fıkrasını 1. veya 2. sıraya taşır.

Kurumsal ortak klasörlerde ve SharePoint dizinlerinde neredeyse hiçbir zaman yalnızca güncel belgeler bulunmaz; 2023_Politika_v1.pdf, 2025_Ek_Karar.pdf ve 2026_Guncel_Prosedur.pdf aynı klasörde yan yana durur.

Salt anlamsal benzerlik aramasının “yürürlük tarihi” kavramı yoktur: 2023 tarihli eski genelgenin cümle yapısı çalışanın sorusuna 2026 revizyonundan bir miktar daha çok benziyorsa vektör arama tereddüt etmeden geçerliliğini yitirmiş limiti kaynak gösterir.

İndeksleme sırasında belgelere zorunlu yaşam döngüsü üst verisi (status=active, effective_date, supersedes_id) işlemek ve CI altın test setine 10 adet sürüm çakışması sorusu eklemek, eski mevzuat yanıtlarını canlıya çıkmadan yakalamanızı sağlar.

Canlı kurumsal PDF’lerin büyük bölümü düz paragraf değil; birleştirilmiş hücreli tablolar, grafikler, formlar ve sondan eklemeli Türkçe teknik maddelerden oluşur. Microsoft SynthDocQA veri setinde soruların %40,4’ü tablolardan ve %29,6’sı şekillerden gelirken yalnızca %5,1’i düz metin bloklarından geliyor; standart metin bölücüler tablo satır-sütun bağlamını kopardığı için LLM yanlış rakam üretir.

Google’ın teknik dokümantasyonuna göre EmbeddingGemma 2 kesinlikle float16 (FP16) hassasiyetinde çalıştırılmamalıdır; sayısal taşma ve kararsızlığı önlemek için çıkarım katmanında bfloat16 (BF16) veya float32 (FP32) kullanılmalıdır.

BabelArena, Türkçenin orta kaynaklı dil kategorisinde yer aldığı 23 dilli bir değerlendirme setidir ve 698 dokümanlık çok dilli bankacılık erişim derlemi içerir. Yalnızca değerlendirme (evaluation-only) amaçlı kullanılmalı, kesinlikle ince ayar veya eğitim verisine dahil edilmemelidir.

Başlangıç için 100 ila 150 soruluk katmanlı bir altın veri seti yeterlidir; ancak soruların en az %35’i tablo ve sayısal okuma, %20’si çok maddeli sentez, %20’si tam madde/kod eşleşmesi, %15’i belgede yanıtı olmayan (reddedilmesi gereken) tuzak sorular ve %10’u yazım hatalı günlük çalışan sorgularından oluşmalıdır.