Yönetişimli GenAI Veri Ajanları ve LLM Değerlendirme

Problem

8.000 ofis çalışanı olan bir perakende ve tüketici ürünleri şirketi, ambarı üzerinde iki pilot sohbet botu çalıştırdı. Biri yönetim kurulu sunumuna yanlış bir ciro rakamı verdi. Diğeri bir tedarikçi sözleşmesinin özetini yanlış ekibe sızdırdı. CIO, ajanlar güvenle yayına alınabilene kadar tüm GenAI sürümlerini dondurdu. Şart: yalnızca yönetilen veri ve izlenebilir cevaplar. Her sürümden önce ölçülebilir bir değerlendirme gerekiyor. Altı ay sonra bir denetçiye cevabın nasıl üretildiği gösterilebilmeli. Kapsamda üç ajan var: bir analitik asistan, bir veri onboarding ajanı ve yeniden sipariş gibi eylemleri taslak olarak hazırlayan bir operasyon ajanı.

Yaklaşım

İki olayın kök nedeni aynı: pilotlar yönetilmeyen tablolara ham SQL yazdı ve belgeleri kendi servis hesabıyla okudu. Tasarım daha iyi bir model seçmek yerine ajanın dokunabildiği yüzeyi daraltıyor. Ajanlar şema doğrulamalı üç araç yüzeyini çağırıyor ve kimlik kullanıcıyla birlikte taşınıyor. İzsiz cevap yayınlanmıyor ve bir sürüm, CI’daki bir politika dosyasıyla kapıdan geçiyor.

Mimari

• Kimlik: APISIX ve Keycloak imzalı bir kullanıcı iddiası üretiyor ve her araç çağrısına iletiyor.
• Ajanlar: ajan başına araç izin listesi olan bir LangGraph çalışma zamanı. LiteLLM geçidi iki ticari sağlayıcıyı ve yerinde bir vLLM modelini tek arayüzde sunuyor.
• Araç yüzeyleri: sertifikalı tanımlar ve kullanıcıya göre politikası olan bir metrik API’si. OpenMetadata’da sözleşmeli veri ürünleri. Sıralamadan önce erişim hakkına göre süzen bir belge deposu.
• Karar noktası: bir Open Policy Agent sidecar’ı her araçta ajan, kullanıcı ve kaynak kararını veriyor.
• Kanıt: cevap, kanıt kümesi, araç çıktısı özetleri ile prompt ve model sürümü, bir outbox satırıyla aynı işlemde PostgreSQL’e yazılıyor; ardından iki yıl Iceberg’de arşivleniyor.
• Onaylar: Flowable her eylemi kimin onayladığını kaydediyor ve geri almayı destekliyor.

Kararlar ve ödünleşimler

• Hiç ham SQL aracı yok. Yönetim kurulu sunumundaki yanlış ciro rakamı, yönetilmeyen bir tabloya sorgu uyduran bir modelden geldi. Artık ajan metrik ve filtre seçiyor, SQL’i katman derliyor. Bilinmeyen metrik şema doğrulamasında düşüyor: ajan “tanımlı değil” diyor ve talebi kaydediyor. Daha iyi bir model yanlış rakamı çözmez; daha dar bir yüzey çözer. Bedeli, sertifikalı metriklerle sınırlı kapsam.
• Ajanın servis hesabı yok. Sözleşme özeti, ajanın sorandan fazla yetkisi olduğu için sızdı. Artık imzalı kullanıcı iddiasını çalışma zamanı, araçlar ve politika kararı doğruluyor. Cevaplar kullanıcılar arasında önbelleklenmiyor. Bedeli: ajan, kullanıcının kendi başına sorgulayamayacağı veride hiçbir zaman yardım edemez.
• Kanıtsız cevap yok. Kanıt satırı ve bir outbox satırı tek PostgreSQL işleminde yazılıyor; cevap ancak commit sonrası serbest kalıyor. Yeniden oynatma cevabı saklanan araç çıktılarından kuruyor, modeli tekrar çağırmıyor. Garanti “aynı kanıt, aynı kurulum”; “model bugün de aynısını söyler” değil. Bedeli, Langfuse’un yanında kendi kanıt depomu işletmek.
• Tasarım anı ile çalışma anı ayrı. LLM boru hattı kodu ve sözleşme taslağı çıkarabiliyor, birleştirmeyi bir insan yapıyor. Üretimdeki boru hatları LLM olmadan çalışıyor; aynı girdi aynı çıktıyı veriyor. Operasyon ajanı yalnızca taslak üretiyor; Flowable insan onayını kaydediyor. Bedeli, her değişiklikte bir inceleme adımı.
• Değerlendirme kapısı. Her ajan 300 soruluk altın set, araç sırası kontrolü, 200 injection vakası, 100 sızdırma vakası ve bir sağlayıcı tolerans testinden geçiyor. Eşikler sürümlü bir dosyada; regresyon boru hattını durduruyor, “bu seferlik” yok. Bedeli, kata tahminine göre koşu başına yaklaşık 20 dakika ve setleri güncel tutmak.
• Tek model geçidi, hedef olarak taşınabilirlik. Sırlar, kotalar ve maliyet etiketleri LiteLLM’de; sağlayıcı değişimi bir yönlendirme değişikliği. Değişim altın doğruluğu 2 puandan ya da araç sırası uyumunu %5’ten fazla düşürürse ajan mevcut modelde kalıyor. Kısıtlı belgeler yalnızca yerindeki modele gidebiliyor. Bedeli, her çağrının geçmek zorunda olduğu bir geçit.

Yeniden ele alacaklarım

• Metrik kapsamı. 400 sertifikalı metrik varsaydım. Soruların ne kadarı bunların dışında kalıyor; talepleri kim, ne kadar sürede işliyor?
• Belge etiketleri. Belge yönetim sistemindeki erişim listeleri ve sınıflar güvenilir mi? Etiketsiz belgeler varsayılan olarak dışarıda kalıyor.
• Sağlayıcı sözleşmeleri. Hangi veri sınıfları dış sağlayıcıya gidebilir; takma adlaştırma etki değerlendirmesi için yeterli mi?
• Tolerans eşikleri. 2 puan ve %5 varsaydım. İş sahipleri bunları kabul ediyor mu, yoksa her ajan kendi eşiğini mi istiyor?

Sonuç notları (tasarım varsayımları, ölçüm değil)

Bu bir tasarım çalışmasıdır, çalışan bir ajan platformu değildir. Çıktı: dört sayfalık diyagram seti, tek sayfalık beyaz tahta sürümü ve 16 sayfalık Türkçe PDF. PDF’te bir yapay zekâ yönetişim kaydı ve AB Yapay Zekâ Yasası eşlemesi var. Tolerans eşikleri (altın doğrulukta 2 puan, trajectory’de %5) iş sahiplerinin onayını bekleyen varsayımlardır.

Kaynaklar

• Mimari PDF (Türkçe, 16 sayfa).
• draw.io diyagramları (İngilizce etiketler): dört sayfalık set ve 30 dakikalık tek sayfa sürüm.