Belirsiz Yapay Zeka Ajanları Nasıl Test Edilir? (temperature=0 Yetersiz Kaldığında)

Sıcaklığı sıfıra ayarlayın ve bir yapay zeka ajanı yine de aynı metni döndürmez. Deterministik olmayan ajanları, tam dizeler üzerinde değil, yapı, şema ve aralıklar üzerinde doğrulama yaparak test edin.

Ashley Innocent

Ashley Innocent

20 July 2026

Belirsiz Yapay Zeka Ajanları Nasıl Test Edilir? (temperature=0 Yetersiz Kaldığında)

Kurumsal İçin Apidog

Şirket İçi (On-Premises) Dağıtım

SSO ve RBAC

SOC 2 Uyumlu

Apidog Enterprise'ı Keşfedin

Testiniz Pazartesi günü geçti. Aynı girdi, aynı kod, temperature=0. Salı günü başarısız oldu ve siz hiçbir şeyi değiştirmediniz. Onaylama tam bir dizeyi kontrol etti ve model aynı cevabı biraz farklı bir şekilde ifade etti. Test kırmızı, ajan iyi durumda ve şimdi ürününüz yerine test süitinizi hata ayıklıyorsunuz.

Bu, bir dil modelini çağıran her şeyi test etmenin bedelidir. Çıkış, siz istemeseniz bile değişir. Sıcaklığı sıfıra ayarlasanız bile çalıştırmalar arasında bayt-özdeş yanıtlar alamazsınız. Çoğu geliştirici bunu bir kez zor yoldan öğrenir ve sonra test etme şekillerini yeniden yazar. Bu kılavuz, altındaki metin sürekli değiştiğinde ayakta kalan onaylamaları nasıl yazacağınızı gösterir. Bu, yapay zeka ajanlarının üretimde neden bozulduğuna dair kılavuzumuzdaki üçüncü hata modunun derinlemesine incelenmesidir.

düğme

Neden temperature=0 belirleyici anlamına gelmez

Sıcaklık, modelin bir sonraki token'ı nasıl örneklediğini kontrol eder. Sıfırda, her seferinde en olası token'ı alır, bu da yeniden üretilebilir olması gerektiğini düşündürür. Ancak öyle değildir ve nedenleri modelin altında yatar.

Kayan noktalı matematik bir GPU'da ilişkilendirici değildir. Aynı sayıları farklı bir sırayla eklerseniz, son ondalık basamakta biraz farklı bir sonuç elde edersiniz. Bu küçük fark, hangi token'ın en yüksek sırayı alacağını değiştirebilir ve bir farklı token ondan sonra her şeyi değiştirir. Bu eklemelerin sırası, sağlayıcının isteğinizi diğer trafikle nasıl toplu işlediğine, hangi donanımın çalıştırdığına ve o gün hangi çekirdek sürümünün dağıtıldığına bağlıdır. Bunların hiçbirini siz kontrol etmezsiniz.

Sağlayıcılar kendi taraflarında da değişiklik yapar. GPU'ları değiştirir, çıkarım kütüphanelerini günceller, ağırlıkları yeniden niceler ve çağrınızı farklı bir bölgeye yönlendirirler. Uzun bir vLLM tartışması, sabit bir çekirdek ve temperature=0'ın neden bit düzeyinde yeniden üretilebilirlik için hala yeterli olmadığını açıklar. Kısa versiyonu: determinizm, isteğinizde ayarladığınız bir bayrak değil, tüm sunum yığınının bir özelliğidir.

Bu yüzden, özdeş çıktıyı temel kabul etmeyi bırakın. Model size aynı anlama gelen bir cevap verir, bu çalıştırmada nasıl ifade edilirse edilsin. Testlerinizin bunu kabul etmesi gerekir.

Tam dize onaylamaları test paketinizi kararsız hale getirir

İşte tuzağı. assert response == "Siparişinizin toplamı 42,00 $'dır." yazıyorsunuz çünkü ilk seferde bu geri döndü. Geçiyor. Sonra model "Toplamınız 42,00 $'a geliyor" döndürüyor ve test doğru bir cevapta başarısız oluyor.

Doğru bir cevapta başarısız olan bir test, hiç test olmamasından daha kötüdür. Ekip, bu paketin sürekli alarm verdiğini öğrenir. İnsanlar yeşil olana kadar tekrar çalıştırır, sonra hataları okumayı bırakırlar, sonra gürültüde saklı gerçek regresyonu kaçırırlar. Kararsız testler sadece zaman kaybetmekle kalmaz, tüm pakete olan güveni de aşındırır ve kararsız testlerin nedenleri ve neden yayıldıkları hakkında daha önce yazmıştık. Belirsiz çıktı, onları üretmenin en hızlı yollarından biridir.

İçgüdü, çıktıyı daha sıkı sabitlemektir: tam dizeyi yakalamak, anlık görüntü almak, ona göre fark almak. Bu, kararsızlığı daha da kötüleştirir, çünkü testinizi değişmesi garanti olan tek şeye bağlamış olursunuz. Tam tersi bir harekete ihtiyacınız var.

Yapıya ve anlama göre onaylayın, tam metne göre değil

Çıktı değişir, ancak altındaki sözleşme değişmemelidir. Bir destek ajanı bir geri ödeme onayını yüz farklı şekilde ifade edebilir, ancak her geçerli yanıt aynı gerçekleri taşır: bir geri ödeme miktarı, bir sipariş kimliği, bir durum. İfadesini değil, gerçekleri test edin.

Bütün değişim bu. "Model tam olarak bunu mu söyledi" diye sormayı bırakın ve "yanıt doğru şekle, doğru alanlara ve doğru aralıktaki değerlere sahip mi" diye sormaya başlayın. Bu özellikler yeniden ifade edilmeye dayanır. Gerçek bir regresyon, eksik bir alan, sınırlar dışındaki bir sayı, yanlış biçimlendirilmiş bir yük, hala onaylamayı tetikler. İşte bunu uygulamaya koyan stratejiler.

Yanıtı bir JSON şemasına göre doğrulayın

Eğer ajanınız yapılandırılmış veri döndürüyorsa, bunun için bir JSON şeması tanımlayın ve her yanıtı bu şemaya göre doğrulayın. Şema, belirli değerlerle ilgilenmeden türleri, gerekli alanları, izin verilen enum'ları ve formatları kontrol eder. Bir status alanı refunded, pending veya denied değerlerinden biri olmalıdır. Bir order_id kimlik kalıbınızla eşleşmelidir. Bir amount bir sayı olmalı, bir dize değil.

Bu, belirsiz bir yanıta karşı yazabileceğiniz en güçlü tekli onaylamadır, çünkü acı veren hataları yakalar: model bir alanı düşürdü, nesneyi yanlış iç içe koydu veya JSON beklediğiniz yerde düz yazı döndürdü. Yanıt şemanızı Apidog'a yükleyin ve ajanın canlı yanıtlarını buna göre doğrulayın. Bir eşleşmezlik, 400 karakterlik bir dize farkı değil, bozulan tam alanı adlandırır.

Araç çağrısının doğru şekle ve hedefe sahip olduğunu onaylayın

Ajanınız bir araç çağırmaya karar verdiğinde, ona yol açan cümleyi değil, çağrıyı test edin. Üç şeyi onaylayın: doğru aracı seçti, doğru hedefi hedefledi ve yük, aracın şemasıyla eşleşiyor. POST /reservations'ı çağıran bir rezervasyon ajanı, bu çağrıyı hangi doğal dil muhakemesinin ürettiğine bakılmaksızın, guests'i bir tamsayı olarak ve geçerli bir date göndermelidir.

Bu, bir yanıt gövdesini doğrulamakla aynı disiplindir, giden isteğe uygulanır. Gerekli parametrelerin varlığını, türlerin doğru olduğunu ve hiçbir icat edilmiş alanın sızmadığını kontrol edin. Bir ajanın API çağrılarını test etmeye yönelik uçtan uca yöntem, bu araç şemalarını yakalamayı ve onlara karşı onaylama yapmayı kapsar. Bir araç çağırma yükünün, etrafındaki kelimeler değişse bile bir sözleşmesi vardır.

Tam değerler yerine sayısal aralıklar kullanın

Modelin ürettiği veya geçirdiği herhangi bir sayı için, bir değer değil, bir aralık onaylayın. Bir alışveriş sepeti ajanı bir toplam hesaplar. Her çalıştırma, sepet ve vergi kuralı genelinde tam rakamı bilemezsiniz, ancak negatif olamayacağını ve sepet değeri artı maksimum nakliye ve vergiyi aşamayacağını bilirsiniz. Öyleyse bunu onaylayın: yanıt, 0 ile bu üst sınır arasında bir total içeriyor.

Bu tek sınır, önemli olan hataları yakalar (negatif bir toplam, on kat çok büyük bir toplam, dolu bir sepette sıfır toplam), ilgilenmediğiniz varyasyonları ise göz ardı eder. Aralıklar güven skorları, öğe sayıları, token kullanımı, gecikme bütçeleri ve herhangi bir türetilmiş rakam için çalışır. Gerçek bir hatada hala başarısız olan en geniş sınırı seçin.

Gerekli anahtarların varlığını ve yasaklı alanların yokluğunu kontrol edin

İki ucuz onaylama çok ağırlık taşır. Birincisi, güvendiğiniz anahtarların mevcut ve null olmamasıdır. İkincisi, asla görünmemesi gereken anahtarların olmamasıdır. Bir destek biletini işleyen bir ajan bir resolution döndürmeli ve asla bir internal_notes veya raw_prompt alanını müşteriye sızdırmamalıdır.

Varlık-yokluk kontrolleri, yanıtın içeriğini değil iskeletini test ettikleri için yeniden ifade edilmeye karşı bağışıktır. Ayrıca, modelin yardımcı bir şekilde gizli kalması gereken bir alanı dahil ettiği tüm gizlilik sızıntılarına karşı en ucuz korumanızdır.

Serbest metin için anlamsal ve eşik kontrolleri kullanın

Bazen yük düz yazıdır ve yine de test etmeniz gerekir. Tam eşleşme çalışmayacağı için bunun yerine özellikleri kontrol edin. Yanıt, girdiğiniz sipariş numarasını içeriyor mu? Bir uzunluk sınırının altında kalıyor mu? Bir kullanıcıya asla gönderilmemesini istediğiniz yasaklı ifadelerin listesinden kaçınıyor mu?

Gerçekten anlamı test etmeniz gerektiğinde, dizelerin eşleşmesini talep etmek yerine, bir referans cevaba karşı yerleştirme benzerliğine göre karşılaştırın ve skorun bir eşiği aştığını onaylayın. Bu anlamsal kontrolleri hassas bir kapı olarak değil, kaba bir kapı olarak ele alın. Konudan sapan bir yanıtı yakalarlar. İnce bir gerçek hatayı yakalamazlar, bu yüzden onları yukarıdaki yapısal onaylamalarla birlikte kullanın.

Tam anlık görüntüler değil, anlık görüntü aralıkları

Anlık görüntü testinin hala bir yeri vardır, yeter ki kararlı kısımların anlık görüntüsünü alasınız. Yanıtın şeklini, anahtar kümesini, türleri, enum değerlerini dondurun ve serbestçe akışkan alanların sınırlar içinde değişmesine izin verin. Pratikte anlık görüntünüz, tam metinle dondurulmuş bir blok yerine "bu yanıtın a, b, c anahtarları var, b bu aralıkta ve c bu kümeden" şeklinde bir kayıt tutar. Anlık görüntü bozulduğunda, bir eşanlamlıdan değil, incelenmeye değer yapısal bir değişiklikten dolayı bozulur.

Durum ve bellek bunu zorlaştırır

Yukarıdakilerin hepsi bir istek içeri, bir yanıt dışarı varsayar. Ajanlar bu şekilde çalışmaz. Dönüşler arasında bellek taşırlar ve bu durum varyasyon kaynaklarını çarpar.

Durumlu bir ajanın cevabı, neyi aldığına, daha önce neyi sakladığına ve önceki dönüşlerin hangi sırayla çalıştığına bağlıdır. Aynı konuşmanın iki çalışması, bir alma adımı belgeleri farklı sıraladığı için veya ikinci dönüşte yazılan bir özetin beşinci dönüşteki muhakemeyi şekillendirmesi nedeniyle farklılık gösterebilir. Şimdi çıktınız iki birleşik nedenden dolayı değişiyor: modelin kendi belirsizliği ve farklı bir başlangıç durumu. Yapay zeka ajanı belleğinin nasıl çalıştığına dair açıklayıcımız, bu durumun nerede yaşadığını ve nasıl oluşturulduğunu anlatır.

İki alışkanlık bunu test edilebilir kılar. Birincisi, kontrol edebildiğiniz durumu kontrol edin. Her testten önce ajanın belleğini bilinen bir başlangıç noktasına ayarlayın, böylece bir şeyi değil iki şeyi değiştirmiş olursunuz. İkincisi, yoldan bağımsız olarak geçerli olan değişmezleri onaylayın. Bir çalışan bakiye asla negatif olmamalıdır. Bir uçuş rezervasyonu yapan bir konuşma, kaç dönüş sürerse sürsün, tam olarak bir rezervasyonla bitmelidir. Yoldan bağımsız onaylamalar, durumlu, belirsiz bir ajanın hayatta kalmasını sağlayanlardır.

Bağımlılıkları taklit ederek testin tekrarlanmasını sağlayın

Canlı üçüncü taraf API'lerine karşı bunların hiçbirini prova yapamazsınız. Sizi hız limitine tabi tutarlar, verilerini değiştirirler ve modelin üzerine ikinci bir rastgelelik kaynağı eklerler. Tekrarlanabilir bir test elde etmek için, test ettiğiniz davranış dışındaki her şeyi sabitleyin.

Ajanın çağırdığı API'leri taklit edin ve sabit yanıtlar programlayın. Şimdi ödeme API'si her zaman aynı makbuzu döndürür, arama API'si her zaman aynı üç sonucu döndürür ve hareket eden tek şey, gözlemlemek istediğiniz ajanın kendi muhakemesidir. Taklit edilmiş bir bağımlılık, sağlıklı bir API'nin talep üzerine üretmeyeceği uç durumları zorlamanıza, ardından ajanın bunları ele aldığını onaylamanıza da olanak tanır. Apidog'u ajanın bağımlılıklarına yönlendirin, böylece kararlı, kontrol edilebilir gövdelerle bu taklitleri kurun ve bunları yukarıdaki şema onaylamalarıyla eşleştirin. Bu, taklit etme ve onaylamanın birlikte çalıştığı daha geniş ajanlı yapay zeka testi uygulaması içinde yer alır.

Apidog nerede uyar (ve nerede uymaz)

Aracın işi konusunda kesin olun. Apidog bir API tasarım, test ve taklit platformudur. Bir ajan çerçevesi, bir model barındırıcısı, bir ajan çalışma zamanı veya bir değerlendirme ve gözlemlenebilirlik platformu değildir. Ajanınızı inşa etmez, çalıştırmaz, adımlarını koordine etmez veya muhakemesini puanlamaz.

Sahip olduğu şey, ajanınızın konuştuğu API katmanıdır ve bu testler burada yaşar. İki dürüst uyum. Ajanın API yanıtları üzerinde (şema doğrulama, yanıt şekli, sayısal aralıklar, gerekli ve yasaklı anahtarlar, araç çağırma yükü şekli) belirsiz çıktıya dayanıklı onaylamalar yazarsınız. Ve ajanın bağımlılıklarını taklit edersiniz, böylece bir test iki kez aynı şekilde çalışır. Apidog'un doldurduğu boşluk budur: onları üreten model değil, istekler ve yanıtlar üzerindeki sözleşme.

Sözleşmeyi test edin, kelimeleri değil

Belirsizlik, yapılandırılarak ortadan kaldırılabilecek bir hata değildir. Bir dil modelini çalıştırmanın bir özelliğidir ve temperature=0 bunu kapatmaz. Güvenilir ajanlar gönderen ekipler bununla savaşmayı bıraktı. Sabit kalan şeyleri, şemayı, şekli, aralıkları, gerekli alanları test ederler ve kelimelerin değişmesine izin verirler. Bunu yaparsanız, paketiniz iyi anlamda sessizleşir: metin değişirken yeşil kalır ve sadece bir şeyler bozulduğunda kırmızıya döner.

Bu hafta paketinizdeki kararsız bir onaylamayı seçin ve onu bir şema ve aralık kontrolü olarak yeniden yazın. Ajanınızın yanıtlarını bir sözleşmeye göre doğrulamak ve testleri tekrarlanabilir kılan bağımlılıkları taklit etmek için Apidog'u indirin.

düğme

API Tasarım-Öncelikli Yaklaşımı Apidog'da Uygulayın

API'leri oluşturmanın ve kullanmanın daha kolay yolunu keşfedin