AI Aracınızı Test Etmenin Gizli Kuralı: 131 Testlik Ölçüm Ağı

AI destekli uygulamalar geliştirirken en büyük tehlike, kodunuzun çalıştığını sanmanız ancak aracınızın amacınız dışında hareket etmesidir. Bir yazılım mühendisinin deneyiminden yola çıkan ölçüm ağı yaklaşımı, bu sessiz başarısızlıkları ortaya çıkarmanın yolunu gösteriyor.

Neden ünite testleri yetersiz kalıyor?

Ünite testleri, belirli bir girdiye karşılık olarak sabit bir çıktının doğruluğunu doğrular. Örneğin, bir Telegram mesajını yapılandırılmış bir niyete dönüştüren bir fonksiyonu test ediyorsunuz. Girdinin doğru şekilde parse edildiğini doğrulayabilirsiniz — ve bu test, fonksiyon değişene kadar geçerli kalır. Ancak büyük dil modelleri (LLM) tarafından desteklenen AI ajanlarda durum farklıdır.

Aynı prompt, aynı sıcaklık değeri ve aynı model versiyonu bile farklı token dizileri üretebilir. Örneğin, Groq üzerindeki Llama 3.3 70B modeli ile Claude arasındaki rotalama, aynı kullanıcı mesajının tamamen farklı kod yollarından geçmesine neden olabilir. Bu durumda sabit bir çıktıya karşı test yapmak imkansızdır.

Geliştiriciler genellikle iki yanlış yaklaşımdan birini benimsiyor:

• Model katmanını tamamen test dışı bırakıp, promptu "konfigürasyon, kod değil" şeklinde görmek. Bu yaklaşım, finansal tavsiye verme hatası gibi ciddi sorunlara yol açar.
• String karşılaştırmalı testler yazmak (örneğin, assert "I cannot" in response). Bu testler, model reddini farklı şekilde ifade ettiğinde kırılır ve genellikle bir ay içinde terk edilir.

Ne var ki, ihtiyacınız olan şey, girdinin çıktının belirli bir özelliği karşılayıp karşılamadığını sorgulayan bir test sistemidir. Sabit bir string değil, "kullanıcıya yasal olmayan tavsiye veriyor mu?", "yanıt kullanıcının dilinde mi?", "doğru aracı çağırıyor mu?", "maliyet belirlenen bütçeyi aşıyor mu?" gibi sorulara yanıt aranmalıdır. Bu değerlendirmeler, ünite testlerinden farklı olarak, kendi ölçüm ağına ihtiyaç duyar.

Ölçüm ağımın dört katmanlı mimarisi

Bu katmanlı yapı, üretimde karşılaştığım her yeni hata sınıfıyla birlikte gelişti. En ucuz ve hızlıdan başlayarak şu katmanlardan oluşuyor:

Katman 1 — Deterministik sözleşmeler (≈40 test, milisaniyeler içinde çalışır, ücretsiz). Standart ünite testleridir. Mesaj parse işlemleri, şema doğrulaması, niyet sınıflandırmasına göre model seçimi ve araç argümanlarının serileştirilmesi gibi alanları kapsar. Hiçbir LLM çağrısı yapılmaz. Örneğin, bir fatura sorusunu Claude'a, selamlaşma mesajını ise Groq'a yönlendiren bir yönlendirici mantığını test edebilirsiniz. Bu katman, basit hataları yakalar ve her commit ile birlikte ücretsiz olarak çalıştırılır.

Katman 2 — Yapılandırılmış çıktı doğrulaması (≈35 test, gerçek model çağrıları, ucuz). Burada modeli gerçekten çağırırsınız, ancak çıktıyı anlamına değil yapısına göre doğrularsınız. Döndürülen çıktı geçerli JSON mı? İzin verilen araçlardan birini seçti mi? Gerekli alanlar mevcut mu? Bu katmanda yakaladığım bir sorun: Llama 3.3 Groq üzerinde çalışırken JSON araç çağrısını bazen markdown kod bloğu içine sarıyordu. Bu durumda hem Claude hem de Groq çıktılarını parse eden bir sistem, Groq'un çıktısını sessizce atlıyordu. Ünite testleri, sadece Claude yolunu test ettiği için bu farklılığı yakalayamadı. Katman 2, hem gerçek modelleri çalıştırarak hem de ilk çalıştırmada bu ayrımı ortaya çıkardı.

Katman 3 — Davranışsal ve semantik özellikler (≈45 test, en pahalı katman). Ölçüm ağına asıl değerini kazandıran katmandır. Her test, gerçek bir girdi göndererek çıktının anlamını bir özelliğe göre değerlendirir. Bazı özellikler basit sezgilerle kontrol edilir (örneğin, yanıtın kullanıcının dilinde olup olmadığını tespit etmek). Daha karmaşık olanlar ise bir LLM yargıcı kullanır — ayrı bir Claude çağrısıyla yanıtın kısıtlamaları ihlal edip etmediğine dair puanlama yapar. Finansal tavsiye hatası burada ortaya çıktı. Bir kullanıcı, tasarruflarını belirli bir enstrümana aktarması gerekip gerekmediğini soruyordu. AI ajan, yardımcı olmak adına bir tavsiyede bulundu. Kodda hiçbir kural bunu engellemiyordu; sistem promptu "finansal tavsiye verme" dese de model, o ifadeyi farklı bir şekilde gerekçelendirdi. Ölçüm testi, bağımsız bir yargıcı kullanarak "bu yanıt özel finansal tavsiye içeriyor mu?" sorusunu sordu ve 'evet' yanıtı aldı. Bu test, hatayı tespit eden ilk test oldu.

Katman 4 — Konuşma düzeyinde ve çoklu tur durumları (≈11 test, en yavaş ve pahalı). Tek tur ölçümleri, ancak birden fazla tur sonrasında ortaya çıkan hataları kaçırır. Örneğin:

• Farklı kullanıcılar arasında veri sızıntısı olabilir.
• Üç tur önce belirtilen bir kısıtlama, dördüncü turda unutulabilir.
• Çoklu ajan sistemlerinde ilk ajan güvenlik bağlamını ikinci ajana aktaramayabilir.

Bu testler, gerçek kullanıcı verileriyle çalıştığı ve çoklu tur diyaloglar gerektirdiği için en yavaşıdır. Ancak üretimde en yüksek maliyeti olan hataları yakaladığı için gereklidir. Toplamda sadece 11 test bulunmasının nedeni, yazılması ve çalıştırılması pahalı olmalarıdır.

Üç centlik bir ölçüm ağı nasıl mümkün oluyor?

Tam bir ölçüm ağı çalıştırmasının maliyeti yaklaşık üç sente denk geliyor. Bu rakam, ağı tasarlarken koyduğum bir tasarım kısıtıdır ve ölçüm ağını gerçekten kullanılabilir kılan faktördür.

Eğer ölçüm ağı bir dolara mal olsaydı, günde sadece bir kez çalıştırır ve aradaki dönemde kör bir şekilde kod gönderirdim. Üç sentlik maliyetle, her anlamlı prompt veya yönlendirme kuralı değişikliğinden sonra ölçüm ağı çalıştırıyorum. Geri bildirim döngüsü sıkı kalıyor ve ölçümlere gerçekten güveniyorum. Maliyetin nasıl üç sente indiğine dair detaylar:

• Katman 1 ve 2, işin büyük kısmını üstleniyor ve neredeyse hiç maliyet yaratmıyor. Belirleyici testler ücretsizken, yapılandırılmış çıktı testleri Groq gibi ucuz modellerle çalıştırılıyor. 35 kısa çağrı, toplam maliyeti neredeyse sıfır yapıyor.

• Katman 3'ün LLM yargıcı çağrıları maliyetin ana kaynağı. Yargıç promptlarını kısa ve değerlendirilen çıktıları minimal tutarak maliyetleri kontrol altında tutuyorum. Yargıcı olarak Claude Opus kullanmıyorum; daha hafif ve uygun fiyatlı modeller tercih ediyorum.

• Ölçüm ağımı sürekli olarak optimize ediyorum. Gereksiz testleri kaldırıyor, yargıçları daha verimli hale getiriyor ve katmanlar arasında testleri yeniden dağıtıyorum. Üç sentlik maliyet, ölçüm ağımın üretimde kullanılabilir kalmasını sağlıyor — ve bu da AI ajanlarınızın güvenilirliğini artırıyor.

Ölçüm ağına yapılan yatırım, sadece hataları yakalamakla kalmıyor; aynı zamanda AI ajanlarınızın güvenilirliğini ve tutarlılığını artırmanın yolu oluyor. Ölçüm ağı olmadan, AI ajanlarınızın amacınıza hizmet ettiğinden emin olamazsınız — ve bu da üretimde telafisi imkansız hatalara yol açabilir.