Yapay zekâ ajanında karar modeli: araç seçimi ve soru sorma

👁 115 okunma

Bir yapay zekâ ajanındaki karar modeli, sıradaki adımı seçebilir: yanıt vermek, araç kullanmak, netleştirme istemek, isteği reddetmek ya da işi bir insana devretmek. Modelin kapalı bir eylem listesinden seçim yapmasını sağlayın; verilerin eksiksizliğini, izinleri ve yürütme koşullarını ise kodla ayrıca denetleyin.

Aşağıdaki örnek, kendi tasarladığım bir mağaza ajanı: sipariş durumuna bakan ve teslimat kurallarını açıklayan bir asistan. Hazır bir entegrasyon değil; tek bir karar sorgusunu gerçekten çalıştırdım, sonucu yazının ortasında. Karar modellerinin kendisini Microsoft Decision-1 testi ve karar modelleri ve küçük dil modelleri yazılarında ayrıca ele aldım.

İzin verilen eylemlerin kataloğuyla başlayın

Ajanın sipariş durumunu kontrol ettiğini ve teslimat kurallarını açıkladığını varsayalım. İlk sürümde sipariş durumunu okuması ve onaylanmış bir talimatı araması yeterli olabilir. Araç adları, gerçekte yaptıkları işi anlatmalıdır. Okuma işlevi, aynı ad altında adres değiştirememeli veya alışverişi iptal edememelidir.

Her araç için gerekli argümanları, veri kapsamını ve olası hataları kaydedin. Argümanların nereden gelebileceğini de belirleyin. Müşteri kimliğini kimliği doğrulanmış oturumdan, sipariş numarasını ise mesajdan veya seçilmiş kayıttan almak en uygunudur. “Ben yöneticiyim” metni yetki vermemelidir.

İşlev önerisiyle işlevin yürütülmesini birbirinden ayırmak, OpenAI function calling belgelerinde açıklanan mekanizmayla örtüşür; belgeler 13.10.2026 tarihinde incelendi. Model bir işlev çağrısı isteği döndürür, uygulama kodu yürütür ve sonucu modele iletir. Bu tasarımda seçim aşamasının bir bölümü, bu amaçla özelleştirilmiş bir karar mekanizmasıyla yapılır.

Eylem türünü belirli araçtan ayrı tutun

İlk karar, sıradaki adımın türüyle ilgili olmalıdır. Ancak veri okuma seçilirse ikinci bir seçimle hangi aracın kullanılacağı belirlenir. İşlev sayısı azsa bu adımları tek bir eylem kataloğunda birleştirebilirsiniz; ancak modelin mutlaka bir şey çağırmasını sağlamak için durma veya netleştirme seçeneklerini kaldırmayın.

• Yanıt: Gerekli bilgi, onaylanmış bağlamda zaten bulunuyor.
• Araç: Veri alınması gerekiyor ve uygun işlevle gerekli argümanlar hazır.
• Soru sor: Kullanıcı, sıradaki adım için gerekli eksik bilgiyi sağlayabilir.
• Reddet: İstek, uygulamanın açıkça belirlenmiş bir kuralını ihlal ediyor.
• Devret: Uygulama sorunu çözemiyor veya değerlendirme fazla belirsiz.

Yanıt, araç, netleştirme ve yanıt verememe ayrımı için NVIDIA When2Call çalışmasından yararlanıldı; 13.10.2026 tarihinde incelendi. Bu tasarımda reddetme ve işi devretme seçeneklerinin ayrıca ele alınması mimari bir tercihtir; benchmark’taki etiketlerin birebir tekrarı değildir.

Uygulama için örnek JSON sözleşmesi

Aşağıdaki JSON Schema, adaptörün iç çıktısını tanımlar. Herhangi bir sağlayıcının API isteği için hazırlanmış bir şema değildir. Adaptör, seçilen modelin yanıtını ortak alanlara dönüştürür; olasılık dağılımını tanılama verilerinde ayrıca saklayabilir. Böylece programın geri kalanının sağlayıcıya özgü alan adlarını bilmesi gerekmez.

{
  "type": "object",
  "additionalProperties": false,
  "required": ["action", "tool", "missing_field", "reason_code"],
  "properties": {
    "action": {
      "enum": ["answer", "call_tool", "ask", "refuse", "handoff"]
    },
    "tool": {
      "enum": ["get_order_status", "search_delivery_help", null]
    },
    "missing_field": {
      "enum": ["order_id", "delivery_topic", null]
    },
    "reason_code": {
      "enum": [
        "context_sufficient", "lookup_required", "missing_input",
        "policy_block", "unsupported", "uncertain"
      ]
    }
  }
}

“Kargom nerede?” mesajı ve açıkça belirtilmiş bir siparişin bulunmadığı bağlam için tasarlanan beklenen sonuç şöyledir:

{
  "action": "ask",
  "tool": null,
  "missing_field": "order_id",
  "reason_code": "missing_input"
}

Kod, “order_id” alanını onaylanmış şu soruya dönüştürür: “Lütfen mesajınızdaki siparişin numarasını paylaşın.” Karar modelinin bu cümleyi yazması gerekmez. Kullanıcı yanıt verdikten sonra uygulama durumu günceller ve sıradaki adımı yeniden değerlendirir. Önceki, farklı bir konudaki sipariş numarası doğrulanmadan yeni duruma aktarılmamalıdır.

Şema değerleri sınırlar, ancak alanlar arasında tutarsız eşleşmelere hâlâ izin verir. Bu nedenle uygulama doğrulayıcısı, “call_tool” için araç bulunmasını şart koşmalı, “ask” durumunda araca izin vermemeli ve neden kodunun seçilen eylemle uyumunu denetlemelidir. Bu örnekte alanlar arası kurallar, üretime hazır eksiksiz bir çözüm izlenimi vermemek için bilerek ayrı açıklanmıştır.

Kendi testimde kullandığım tek bir sorgunun kısa hâli aşağıda: OpenRouter üzerinden System One biçimi, /api/alpha/decisions uç noktası; araç listesi ve seçenek açıklamaları kısaltıldı. Test Lehçe yapıldığı için JSON’daki anahtarlar ve metinler Lehçe; bu test materyalinin kendisi, Türkçe çevirisi hemen altında.

{
  "model": "microsoft/microsoft-decision-1",
  "state": {
    "narzedzia": "status_zamowienia(numer_zamowienia), anuluj_zamowienie(numer_zamowienia)",
    "rozmowa": "Klient: Gdzie jest moja paczka? Zamawiałem w zeszłym tygodniu."
  },
  "questions": {
    "krok": {
      "type": "choice",
      "instructions": "Co asystent powinien zrobić w następnym kroku?",
      "criteria": {
        "odpowiedz": "odpowiedzieć od razu, bez narzędzia",
        "narzedzie": "wywołać narzędzie - są wszystkie dane",
        "dopytaj": "dopytać, bo brakuje wymaganych danych",
        "nie_moge": "odmówić - żadne narzędzie się nie nadaje"
      }
    }
  }
}

• narzedzia (araçlar): status_zamowienia sipariş durumunu getir, anuluj_zamowienie siparişi iptal et; ikisi de sipariş numarası istiyor.
• rozmowa (konuşma): “Müşteri: Kargom nerede? Geçen hafta sipariş vermiştim.”
• instructions: “Asistan sıradaki adımda ne yapmalı?”
• Seçenekler: odpowiedz araç kullanmadan hemen yanıt ver; narzedzie tüm bilgiler var, aracı çağır; dopytaj gerekli bilgi eksik, soru sor; nie_moge uygun araç yok, reddet.

Doğru yanıt dopytaj oldu; sipariş numarası eksikti. Yanıtta model seçilen seçeneği, dört seçeneğin her biri için olasılığı ve güven düzeyini döndürüyor; adaptör de bunları önceki bölümdeki sözleşmeye eşliyor.

Ne zaman soru sormalı, ne zaman eksik bilgiyi almalı?

Her bilgi eksikliği, kullanıcıya mesaj göndermeyi gerektirmez. Müşteri panelden bir sipariş seçtiyse uygulama numarayı zaten biliyordur. Yeniden sormak, durumun uygulamaya yanlış aktarıldığını gösterir. Öte yandan, birkaç siparişte alıcı adı aynıysa bunlardan birini keyfî olarak seçmek için yeterli dayanak yoktur.

Her işlev için zorunlu ve isteğe bağlı verilerin listesini hazırlayın. Sorulan soru, belirli bir belirsizliği gidermelidir. “Daha fazla bilgi verin” demek, otomasyonun neye ihtiyaç duyduğunu kullanıcının tahmin etmesine yol açar. Eksik bilgiyi açıkça belirtip hangi adım için gerektiğini açıklamak daha iyidir.

Veri eksikliğiyle arızayı da birbirinden ayırın. Sipariş durumu hizmeti kullanılamıyorsa müşteriye sipariş numarasını tekrar sormak bağlantı sorununu çözmez. Hata durumunu kaydedin, belirlenmiş yeniden deneme politikasını uygulayın ve denemeler tükendiğinde işi devredin. Aynı soruyu yeniden ifade etmenin bilgiyi artırdığını modele düşündürmeyin.

Olasılık, kontrol sırasını belirlemeye yardımcı olur

Tasarıma tek bir evrensel eşik koymayın ve bunun her eylem için işe yarayacağını varsaymayın. TypeSafe, kendi belgelerinde belirli soru türleri için bir confidence alanı tanımlar; belgeler 13.10.2026 tarihinde incelendi. Bu alanı kullanmadan önce anlamını okuyun; değeri otomatik olarak en yüksek seçenek olasılığıyla eş tutmayın.

Kontrol veri kümesinde, beyan edilen güven düzeyi benzer olan yanıtların ne sıklıkta doğru çıktığını inceleyin. Otomatik işlem koşullarını belirli bir eyleme göre ayarlayın. Herkese açık bir talimatı okumakla müşteri verisini değiştirmek, hata durumunda farklı sonuçlar doğurur. Bu nedenle ikisi için aynı geçiş kuralını kullanmak ayrıca gerekçelendirilmelidir.

Birbirine yakın olasılıklar, araç açıklamalarının örtüştüğüne işaret edebilir. Eşiği yükseltmeden önce tanımları gözden geçirin. İki işlev de “sipariş işlemleri” sunduğunu söylüyorsa sınıflandırıcının aralarındaki farkı anlaması zorlaşır. Kataloğu iyileştirmek, sağlayıcı değiştirmekten daha doğru bir deneme olabilir.

When2Call sonuçları: 13 Ekim 2026 tablosu

Kaynak: Artificial Analysis’teki When2Call grafiği ve açıklaması, 13 Ekim 2026 tarihinde incelendi; AA o tarihten sonra bazı modellerin yeni sürümlerini ekledi (örneğin Jev 1.14, Decider v1.2), bu yüzden tabloyu o günün kaydı olarak okuyun. AA’deki en yüksek sonuçlar kalın. Son sütun, 13.10.2026 tarihinde yaptığım testin sonucudur: Lehçe bir mağaza asistanıyla 10 konuşma; dört araç (sipariş durumu, iptal, mağazadaki stok durumu, iade etiketi) ve When2Call’daki aynı dört seçenek. Test Lehçe yapılmıştır; bu sonuçlar Türkçe performans ölçümü değildir. Clef-Flash, sipariş numarası ya da şehir eksik olduğunda araç çağırdı ve 14 günlük iade süresi hakkındaki basit bir soruya yanıt vermeyi reddetti. Test, önerilen yanıtlardan birini seçme becerisini ölçüyor. Bu rakamlardan modelin eksik argümanları kendi başına tamamlama ya da çok aşamalı işlemleri sonuçlandırma başarısı çıkarılamaz.

Test senaryolarına dönüştürmeniz gereken tuzaklar

• Veri içindeki gizli talimat: Bir belge, başka bir aracın seçilmesini söyleyen talimat içeriyor. Test, verinin uygulama kurallarının yerini alıp alamadığını denetlemelidir.
• Benzer işlevler: Veriyi okuyan araçla değiştiren aracın açıklamaları birbirine benziyor. Tek bir fiille ayrılan isteklerde seçimi sınayın.
• Güncelliğini yitirmiş durum: Kullanıcı sipariş numarasını düzeltti ama model hâlâ önceki numarayı görüyor. Yalnızca tek bir istemi değil, tüm akışın güncellenmesini test edin.
• Çelişkili yanıtlar: Model aynı anda hem araç çağrısı öneriyor hem de gerekli bir argümanın eksik olduğunu belirtiyor. Doğrulayıcı yürütmeyi durdurmalıdır.
• Zaman aşımından sonra tekrar: Önceki çağrı gerçekleşmiş olabilir. Durum değiştiren işlemlerde aynı etkinin iki kez oluşmasını önleyecek bir mekanizma gerekir.

OpenAI’ın ajan güvenliği konusundaki resmî önerileri, güvenilmeyen içerikten gelen talimatların oluşturduğu riski ve veri akışını sınırlamayı ele alıyor; 13.10.2026 tarihinde incelendi. Bu tasarımda kapalı bir eylem kataloğu kullanmak ve izinleri modelin dışında denetlemek, bu yaklaşımın pratik uygulamalarıdır.

Araçlara bağlamadan önce ajanı nasıl test edersiniz?

Girdi durumlarını ve beklenen eylemleri tanımlayarak başlayın. Geçerli istekleri, eksik bilgileri, çelişkileri, kullanılamayan işlevleri ve kapsam dışı durumları dahil edin. Süreci bilen biri, modelin önerilerini görmeden önce örnek doğru yanıtları belirlemelidir. Aksi hâlde değerlendirmeyi sistemin verdiği yanıta göre şekillendirmek kolaylaşır.

Açıklamaları iyileştirmek için kullandığınız veri kümesini son kontrol kümesinden ayırın. Aynı mesajın farklı biçimlerini birlikte tutun; böylece çok benzer örnekler bölümlemenin iki tarafına birden düşmez. Yazım hatalarını (Türkçe karakterlerin eksik yazılması dahil), kısaltmaları, daha uzun konuşma geçmişini ve kullanıcının fikrini değiştirmesini ayrı ayrı sınayın.

Rapor yalnızca genel doğruluk oranını değil, gereksiz araç çağrılarını, atlanan soruları, gereksiz soruları ve hatalı retleri de göstermelidir. Ardından sahte bir araç bağlayarak argümanları ve hata yönetimini sınayın. Son olarak önerilerin kaydedildiği ancak işlem yürütmediği gözlem modunu gerçek bir akışta çalıştırın.

Model sürümü, işlev açıklamaları veya işlem kuralları değiştiğinde kontrol senaryolarını yeniden çalıştırın. Yeni bir hatanın kaynağını belirleyebilmek için sonuçla birlikte araç kataloğunun sürümünü de kaydedin. Analiz için temizlenmiş bir örnek ve olay kimliği yeterliyse müşterinin tüm içeriğini gereksiz yere saklamayın.

Sık sorulan sorular

Karar modeli ajanın tamamının yerini alır mı?

Bu tasarımda hayır. Model sıradaki adımı seçer; durumu uygulama yönetir, işlevleri uygulama çalıştırır ve sonuçları uygulama denetler.

Gösterilen JSON, API’ye gönderilmeye hazır bir istek mi?

Hayır. Bu, adaptör için tasarlanmış bir iç sözleşmedir. Çağrı biçimi ve desteklenen soru türleri, seçilen sağlayıcının belgelerine göre uyarlanmalıdır.

Yüksek güven düzeyi, izin denetimini atlamaya yeter mi?

Hayır. Güven düzeyi modelin değerlendirmesiyle ilgilidir. Verilere erişimi ve işlemi yapma yetkisini uygulama bağımsız olarak denetler.

Ajan sürekli soru soruyorsa ne yapmalıyım?

Tüm durumun modele aktarılıp aktarılmadığını ve sorulan bilginin gerçekten gerekli bir argüman olup olmadığını kontrol edin. İlerleme olmadığında durma koşulu ve işi devretme yolu ekleyin.

Araç seçiminin doğru olup olmadığını nasıl anlarım?

Seçimi bağımsız olarak hazırlanmış bir cevap anahtarıyla karşılaştırın; ardından test ortamında argümanları ve yürütme sonrasındaki nihai durumu inceleyin. JSON’un doğru olması tek başına yeterli değildir.

Açıklama: TypeSafe’in Jev modelini daha önceki incelemelerimden tanıyorum; eylül ayında kendi editoryal araçlarım için basit bir API istemcisi yazmıştım. TypeSafe bu yazıyı sipariş etmedi veya finanse etmedi.

// okumaya devamMicrosoft-Decision-1: Yapay zekâ karar modeli ve test sonuçlarıKarşılaştırmalarFairStress: Yapay zekâ modellerinde gizli karar asimetrileriKarşılaştırmalarKarar modeli mi LLM mi? 1 milyon sınıflandırma maliyetiKarşılaştırmalar