Sorun: Geçerli Metin, Güvenilir Veri Demek Değildir
Bir dil modeli okunabilir bir yanıt üretebilir; ancak bu yanıtın otomasyon, agent veya RAG akışı tarafından güvenle işlenebilmesi ayrı bir problemdir. Eksik alan, yanlış veri tipi, değişken tarih biçimi ya da JSON dışına eklenen açıklamalar; hatalı kayıt, yanlış bildirim ve yinelenen işlem oluşturabilir.
Üretimde hedef yalnızca daha iyi prompt yazmak olmamalıdır. Çıktı sözleşmesi, doğrulama, hata yönetimi, yetki sınırları ve gözlemlenebilirlik birlikte tasarlanmalıdır. Bir model sağlayıcısının yapılandırılmış çıktı veya JSON Schema desteği bulunuyorsa bile desteklenen şema kuralları, reddetme davranışı, iç içe nesne sınırlamaları ve sürüm uyumluluğu doğrulanmadan kesin varsayılmamalıdır. Sağlayıcı özelliği kullanılsa bile uygulama tarafında bağımsız doğrulama katmanı tutulmalıdır.
Küçük ve Açık Bir Çıktı Sözleşmesi Tasarlama
İlk adım, serbest biçimli yanıtı makinenin işleyebileceği açık bir veri sözleşmesine dönüştürmektir. Her alan için veri tipi, zorunluluk durumu, izin verilen değerler, uzunluk sınırı ve bilinmeyen durumunun nasıl temsil edileceği belirlenmelidir.
Örneğin bir destek talebi sınıflandırmasında şu alanlar yeterli olabilir:
İki Katmanlı Doğrulama ve Güvenli Fallback
İlk katmanda teknik biçim denetlenir: Yanıt ayrıştırılabiliyor mu, zorunlu alanlar mevcut mu, veri tipleri doğru mu, enum değerleri izin verilen kümede mi? İkinci katmanda iş kuralları uygulanır: Sayı makul aralıkta mı, tarih ilgili alan için geçerli mi, kullanıcı yetkisi bu işlemi destekliyor mu, RAG kaynağında kararı destekleyen kanıt bulunuyor mu?
Örnek akış:
Doğrulama başarısız olduğunda aynı isteği sınırsız biçimde yeniden göndermek yerine deneme sayısı ve zaman aşımı sınırlandırılmalıdır. Yeniden denemede hata özeti modele aktarılabilir; fakat yeni çıktı yine aynı doğrulama katmanından geçmelidir. Agent mimarisinde modelin ürettiği araç adı ve parametreleri doğrudan çalıştırılmamalı, yalnızca izin verilen araçlar, alanlar ve parametre aralıkları arasından seçilmelidir. Kritik durumda güvenli varsayılan davranış işlemi durdurmak ve insan incelemesine yönlendirmektir.
Yan Etkileri, Tekrarlı İşlemleri ve Yetkiyi Sınırlandırma
Model çağrısı ile dış sistemde yan etki oluşturan işlem aynı adımda birleştirilmemelidir. Modelin “e-posta gönder” kararı üretmesi, e-postanın gerçekten gönderileceği anlamına gelmemelidir. Arada politika, yetki, alıcı doğrulaması ve gerekirse insan onayı bulunmalıdır.
Ödeme, hesap kapatma, müşteri silme veya dış iletişim gibi işlemlerde şu kontroller değerlendirilebilir:
Ölçümleme, Test ve Sürümleme
Başarı oranı tek başına yeterli değildir. Üretim izleme için en az şu sinyaller takip edilebilir: şema doğrulama başarısızlık oranı, yeniden deneme oranı, insan incelemesine düşen kayıt yüzdesi, gecikme, token veya işlem maliyeti, yinelenen yan etki sayısı ve son kullanıcı düzeltmeleri. Agent akışlarında araç çağrısı başına hata, gereksiz adım sayısı ve döngüye giren görevler de ayrıca ölçülmelidir.
Test seti gerçek kullanım çeşitliliğini temsil edecek şekilde düzenli gözden geçirilmelidir. Boş alanlar, çelişkili talimatlar, uzun girdiler, farklı diller, bozuk belgeler, kaynakta bulunmayan sorular ve kötü niyetli içerikler ayrı senaryolar olarak denenmelidir. Prompt, şema, model veya RAG indeksindeki her değişiklikte önce sabit bir değerlendirme setiyle karşılaştırma yapılabilir; riskli akışlarda gölge çalıştırma ve sınırlı dağıtım tercih edilmelidir.
Sonuçta güvenilir LLM otomasyonu, modelin her zaman doğru cevap vermesine dayanmaz. Hatalı çıktıyı erken yakalayan, kanıt yokluğunu temsil eden, yetkiyi sınırlayan, yan etkileri engelleyen ve gerektiğinde insanı sürece dahil eden savunmalı mimari daha sürdürülebilirdir.
Bir dil modeli okunabilir bir yanıt üretebilir; ancak bu yanıtın otomasyon, agent veya RAG akışı tarafından güvenle işlenebilmesi ayrı bir problemdir. Eksik alan, yanlış veri tipi, değişken tarih biçimi ya da JSON dışına eklenen açıklamalar; hatalı kayıt, yanlış bildirim ve yinelenen işlem oluşturabilir.
Üretimde hedef yalnızca daha iyi prompt yazmak olmamalıdır. Çıktı sözleşmesi, doğrulama, hata yönetimi, yetki sınırları ve gözlemlenebilirlik birlikte tasarlanmalıdır. Bir model sağlayıcısının yapılandırılmış çıktı veya JSON Schema desteği bulunuyorsa bile desteklenen şema kuralları, reddetme davranışı, iç içe nesne sınırlamaları ve sürüm uyumluluğu doğrulanmadan kesin varsayılmamalıdır. Sağlayıcı özelliği kullanılsa bile uygulama tarafında bağımsız doğrulama katmanı tutulmalıdır.
Küçük ve Açık Bir Çıktı Sözleşmesi Tasarlama
İlk adım, serbest biçimli yanıtı makinenin işleyebileceği açık bir veri sözleşmesine dönüştürmektir. Her alan için veri tipi, zorunluluk durumu, izin verilen değerler, uzunluk sınırı ve bilinmeyen durumunun nasıl temsil edileceği belirlenmelidir.
Örneğin bir destek talebi sınıflandırmasında şu alanlar yeterli olabilir:
- category: Önceden tanımlanmış sınırlı bir değer kümesi.
- priority: low, medium veya high gibi kontrollü değerler.
- summary: Kullanıcı verisini gereksiz yere tekrarlamayan kısa açıklama.
- needs_human_review: Belirsiz veya riskli durumlar için boolean değer.
- confidence_note: Sayısal güven puanı yerine, belirsizliğin kısa gerekçesi.
İki Katmanlı Doğrulama ve Güvenli Fallback
İlk katmanda teknik biçim denetlenir: Yanıt ayrıştırılabiliyor mu, zorunlu alanlar mevcut mu, veri tipleri doğru mu, enum değerleri izin verilen kümede mi? İkinci katmanda iş kuralları uygulanır: Sayı makul aralıkta mı, tarih ilgili alan için geçerli mi, kullanıcı yetkisi bu işlemi destekliyor mu, RAG kaynağında kararı destekleyen kanıt bulunuyor mu?
Örnek akış:
model_response = call_model(input_data)
parsed = parse_json(model_response)
validated = validate_schema(parsed)
if not validated.ok or not business_rules_pass(parsed):
send_to_review(input_data, model_response, validated.errors)
else:
execute_next_step(parsed)
Doğrulama başarısız olduğunda aynı isteği sınırsız biçimde yeniden göndermek yerine deneme sayısı ve zaman aşımı sınırlandırılmalıdır. Yeniden denemede hata özeti modele aktarılabilir; fakat yeni çıktı yine aynı doğrulama katmanından geçmelidir. Agent mimarisinde modelin ürettiği araç adı ve parametreleri doğrudan çalıştırılmamalı, yalnızca izin verilen araçlar, alanlar ve parametre aralıkları arasından seçilmelidir. Kritik durumda güvenli varsayılan davranış işlemi durdurmak ve insan incelemesine yönlendirmektir.
Yan Etkileri, Tekrarlı İşlemleri ve Yetkiyi Sınırlandırma
Model çağrısı ile dış sistemde yan etki oluşturan işlem aynı adımda birleştirilmemelidir. Modelin “e-posta gönder” kararı üretmesi, e-postanın gerçekten gönderileceği anlamına gelmemelidir. Arada politika, yetki, alıcı doğrulaması ve gerekirse insan onayı bulunmalıdır.
Ödeme, hesap kapatma, müşteri silme veya dış iletişim gibi işlemlerde şu kontroller değerlendirilebilir:
- Her işlem için benzersiz bir idempotency anahtarı kullanılması.
- Aynı girdinin yeniden işlenmesinde ikinci yan etkinin engellenmesi.
- Yüksek riskli kararlar için açık insan onayı istenmesi.
- Araç çağrılarının izin verilen kaynak, kapsam ve parametrelerle sınırlandırılması.
- Prompt enjeksiyonuna karşı alınan metnin talimat değil, güvenilmeyen veri olarak işlenmesi.
Ölçümleme, Test ve Sürümleme
Başarı oranı tek başına yeterli değildir. Üretim izleme için en az şu sinyaller takip edilebilir: şema doğrulama başarısızlık oranı, yeniden deneme oranı, insan incelemesine düşen kayıt yüzdesi, gecikme, token veya işlem maliyeti, yinelenen yan etki sayısı ve son kullanıcı düzeltmeleri. Agent akışlarında araç çağrısı başına hata, gereksiz adım sayısı ve döngüye giren görevler de ayrıca ölçülmelidir.
Test seti gerçek kullanım çeşitliliğini temsil edecek şekilde düzenli gözden geçirilmelidir. Boş alanlar, çelişkili talimatlar, uzun girdiler, farklı diller, bozuk belgeler, kaynakta bulunmayan sorular ve kötü niyetli içerikler ayrı senaryolar olarak denenmelidir. Prompt, şema, model veya RAG indeksindeki her değişiklikte önce sabit bir değerlendirme setiyle karşılaştırma yapılabilir; riskli akışlarda gölge çalıştırma ve sınırlı dağıtım tercih edilmelidir.
Sonuçta güvenilir LLM otomasyonu, modelin her zaman doğru cevap vermesine dayanmaz. Hatalı çıktıyı erken yakalayan, kanıt yokluğunu temsil eden, yetkiyi sınırlayan, yan etkileri engelleyen ve gerektiğinde insanı sürece dahil eden savunmalı mimari daha sürdürülebilirdir.