Verilerim Nereye Gitti? Veri Hattı Dedektifi Olarak LLM'leri Kıyaslamak

Neyi Kıyasladım?#

Her veri mühendisi bu destek talebini en az bir kez almıştır: Satış ekibinden biri "Umbrella Corp" kaydının CRM'de olduğunu ancak panoda (dashboard) görünmediğini yazar ve gün sonuna kadar nereye gittiğini kontrol etmenizi ister. CRM ile pano arasında veriyi alan, şirket adını çıkaran, kopyaları birleştiren ve bazılarını filtreleyen bir veri hattı (pipeline) bulunur. Kayıt bu adımların herhangi birinde kaybolmuş olabilir.

Logları incelediğinizde, bir kısmının geçen hafta silindiğini görürsünüz ve son tabloda "Umbrella Corporation Inc" kaydına rastlarsınız. İyi bir araştırmacı kanıt varsa "filtrelendi, işte log satırı" der ya da izler silinmişse "bilemiyorum" yanıtını verir. Kötü bir araştırmacı ise "muhtemelen budur" diyerek benzer ismi seçer ve talebi kapatır; iki hafta sonra panonun tamamen farklı bir şirketin verilerini gösterdiği anlaşılır.

Günümüzde herkes bu görevleri Büyük Dil Modellerine (LLM) devretmek istiyor. Herhangi bir LLM son tablodaki isim benzerliğini yakalayabilir; peki ya eldeki loglar kaydın nereye gittiğini kanıtlamak için yetersiz olduğunda bunu fark edebilir mi?

Bunu test etmek için Where Did My Data Go? kıyaslamasını geliştirdim. 15 küçük veri hattı senaryosu simüle ettim ve her birinde bir şirket kaydına gerçekte ne olduğuna karar verdim. Sistem gerçek bir veri hattı gibi log üretir, ardından bu logların bir kısmını (bazen hiçbirini, bazen birkaçını, bazen neredeyse tamamını) silerim. Model kalan logları inceler ve sonuca varır. Değerlendirme aşamasında başka bir LLM (LLM-as-a-Judge) yerine doğrudan standart kod kullanılır. Kod, gizli gerçeği değil, kalan logların neyi kanıtladığını kontrol eder. Kanıt silindiyse, tahmin şans eseri doğru olsa bile tek doğru yanıt "bilinemiyor" (can't tell) seçeneğidir.

Her araştırma sonucunda model şu altı karardan birini verir:

• Hiç yüklenmedi (Never loaded): Partiye hiç gelemedi; kayıt sisteme hiç girmedi.
• İsim okunamadı (Name couldn't be read): İçeri girdi ama kimse yaka kartını okuyamadı; şirket adı ayrıştırılamadı.
• Filtrelendi (Filtered out): Görevli tarafından dışarı atıldı; bir kural kaydı eledi.
• Yanlış birleştirme (Wrong merge): Kimlik hırsızlığı; kayıt yanlışlıkla farklı bir şirketle birleştirildi.
• Farklı bir ID altında (Under a different id): Hayatta ve iyi durumda; takma adla (farklı bir kimlikle) tabloda yer alıyor.
• Bilinemiyor (Can't tell): Faili meçhul vaka; kalan loglar kesin bir kanıt sunmuyor.

Ayrıca son tabloda genellikle yanıltıcı bir benzer kayıt bulunur. Hatta birebir aynı loglara sahip ikiz vakalar tasarladım: Birinde benzer kayıt gerçekten aranan şirketken diğerinde sadece isim benzerliği olan farklı bir şirkettir; dolayısıyla her iki durum için de tek dürüst yanıt "bilinemiyor" olmalıdır. Her senaryo hem düz bir soru olarak hem de "tahmin yürütme ve kanıtlayan log satırını göster" diyen kısa bir kural setiyle iki farklı modda soruldu.

Test Edilen Modeller ve Mühendislik Çıkarımları#

Gerçek bir üretim ortamında bu kontrol her gece her destek talebi için çalışacağından, döngüye en pahalı modelleri koymak gerçekçi değildir. Bu nedenle her laboratuvarın uygun maliyetli katmanlarını ve kendi sunucunuzda barındırabileceğiniz açık ağırlıklı modelleri seçtim.

Yazılım geliştirme ve Production'da Agent Güvenilirliği açısından bu çalışmadan çıkarılabilecek temel dersler şunlardır:

• Deterministik Değerlendirme: Üretimde AI Test Stratejileri kurgularken, kanıt tabanlı görevlerde LLM hakemleri yerine deterministik kod kontrolleri kullanmak halüsinasyonları ölçmenin en güvenilir yoludur.
• Temel Prompt Teknikleri Etkisi: Modele yalnızca birkaç satırlık "tahmin etme, log satırını kanıt göster" kuralı eklemek, modelin belirsizlik karşısındaki güvenilirliğini doğrudan değiştirir.
• Maliyet ve Model Seçimi: Modeller: Hangisi, Ne Zaman? sorusuna yanıt ararken, yüksek hacimli arka plan görevlerinde açık ağırlıklı ve ucuz katmanlı modellerin sınırlarını bilmek kritik önem taşır.