Opus'tan Yardım İsteyebilen Bir Jev Modeli, 4 Kat Daha Düşük Maliyetle Opus Doğruluğu Sunuyor

Hızlı ve düşük maliyetli karar modellerinin (Jev ve GPT-6 Luna), kimlik çözümleme (identity resolution) sonuçlarını değerlendirmede sınır (frontier) LLM'ler kadar başarılı olup olamayacağını test ettik. Tek başlarına %88,8–%97,3 doğruluk oranına ulaşan bu modellerden Jev ile Claude Opus'u birleştiren hibrit bir mimari kurduğumuzda, 4 kat daha düşük maliyetle Opus seviyesinde doğruluğa ulaştığımızı gördük. Yazılım mühendisliği ve Modeller: Hangisi, Ne Zaman? ile LLM-as-a-Judge ve Braintrust yaklaşımları açısından temel bulgularımız şunlardır:

• Luna kutudan çıktığı haliyle Jev'den daha iyi performans gösterir, ancak zorlu vakalarda bu fark ortadan kalkar: Basit veri eşleştirmelerinde Luna önde olsa da karmaşık senaryolarda iki modelin tekil başarımı eşitlenir.
• Jev'in güven skoru (confidence) daha iyi kalibre edilmiştir: Jev'in yaptığı hataların çoğu düşük güven skoruyla gelirken, Luna hatalarını yüksek güvenle yapar. Bu kalibrasyon farkı, belirsiz vakaları üst modele yönlendiren hibrit bir mimaride (hybrid model harness) Jev'in Luna'dan çok daha verimli çalışmasını sağlar.
• Sınır (frontier) modeller hala karar modellerinden daha doğrudur: Karmaşık muhakeme gerektiren durumlarda büyük modeller doğruluk üstünlüğünü korur.
• Karar modelleri kutudan çıktığı haliyle 90 kata kadar daha ucuz ve 10 kattan fazla daha hızlıdır: 1.000 kimlik başına 0,05–0,10 $ maliyetle yaklaşık 0,15 saniyede yanıt verirler; ancak zorlu kıyaslamalarda (benchmarks) Opus doğruluğunun yaklaşık 6 puan gerisinde kalırlar.

Kimlik Çözümleme (Identity Resolution - IDR) Nedir?#

Kimlik çözümleme, dağınık veri kayıtlarını gerçek dünyadaki tekil kişilere eşleme sürecidir. Bir $D$ veri kümesindeki her $d \in D$ kaydını, gerçek dünyada tek bir kişiyi temsil eden $i \in I$ kimliğine ($m(D) \rightarrow I$) hatasız bağlamak; müşteri yaşam boyu değeri (LTV) analizi ve kişiselleştirme sistemlerinin temelidir. Örneğin Alice'e ait sadakat kartı, ev adresi, kargo adresi ve e-posta kayıtlarının tamamı tek bir Alice profilinde birleştirilmelidir.

Pratikte paylaşılan e-postalar, adres değişiklikleri ve veri kirliliği bu süreci zorlaştırır. Veri tabanlarında sıkça karşılaşılan 8 temel hata türü şunlardır:

• Yazım hatası (Typo): Valentino → Valentinp (Farklı bir soyadı gibi algılanabilir).
• Yanlış okunan karakter: Sam → 5am (Bozuk veri veya kullanıcı adı).
• Okunduğu gibi yazılma: Phillips → Filips (Farklı bir aile).
• Ay ve günün yer değiştirmesi: 02/17/2020 → 17/02/2020 (Ayrıştırılamayan doğum tarihi).
• Akrabadan kopyalanan değer: Ebeveynin doğum tarihiyle kaydedilen çocuk verisi.
• Takma ad (Nickname): Robert → Bob (İki farklı kardeş olma ihtimali).
• Yer tutucu (Placeholder) isim: Valentino → Female Child (Kullanışsız veri).
• Boş alan: Mendoza → (boş) (Herhangi biriyle eşleşebilir).

IDR süreçlerindeki en kritik sorun aşırı birleştirme (over-merging) hatasıdır; yani tek bir $i$ kimliğinin gerçek dünyadaki birden fazla farklı kişiye karşılık gelmesidir.

Aşırı Birleştirmeyi Tespit Etmek#

Canlı üretim (production) verisinde, kayıtları birleştirdikten sonra kontrol edebileceğimiz hazır bir cevap anahtarı yoktur. Olsaydı, doğrudan eşleştirme algoritmasında kullanırdık. Geliştiriciler için buradaki en pratik çıkarım, LLM-as-a-Judge (Yargıç olarak LLM) mimarisini kademeli yönlendirme (cascading routing) ile kurgulamaktır: Tüm trafiği pahalı bir sınır modele göndermek yerine, iyi kalibre edilmiş hızlı bir karar modelini (Jev) ön filtre olarak kullanmak ve yalnızca düşük güven skorlu sınır vakaları Claude Opus'a devretmek, üretim ortamında maliyet-performans optimizasyonunun anahtarıdır.