Bir LLM çağrısının etrafındaki kararların çoğu model seçimiyle ilgili değil. "Bu prompt'ta TCKN var mı", "bu müşteri hangi katmanda", "bu isteği önbelleğe yazabilir miyiz", "bu veri sınıfı için hangi bölge uygun" — bunların hepsi karar. Ve bunlar tipik olarak uygulama kodunun içinde, birbirinden bağımsız if blokları hâlinde yaşıyor.
Bu dağınıklığın iki maliyeti var ve ikisi aynı anda ortaya çıkıyor.
Birinci maliyet: değişim hızı
Bir mevzuat yorumu değiştiğinde ya da yeni bir veri sınıfı eklendiğinde, değişiklik release pipeline'ına giriyor. Kod değişikliği, review, test, dağıtım. Bunun iyi bir ekipte iki hafta sürdüğünü görüyoruz. Kötü olan şey sürenin uzunluğu değil — kötü olan, bu sürenin uyumluluk değişikliği için ödenmesi. Uyumluluk kararları, ürün özellikleriyle aynı hızda değişmiyor; genelde daha hızlı ve daha az öngörülebilir değişiyorlar.
İkinci maliyet: açıklanamayan karar
Bir denetçi "bu cevap neden bu modelden geldi" diye sorduğunda, cevabın kodun üç ayrı yerine dağılmış koşullardan yeniden inşa edilmesi gerekiyor. Uygulamada bu şu demek: cevap verilemiyor. Log'larda model adı var, belki kural adı da var, ama kararın gerekçesi yok.
Bu ikisi birlikte, kuralları yazmaktan kaçınmaya yol açıyor. Ekip riskli olduğu için kuralı yazmıyor, kural olmadığı için de risk büyüyor.
Kararı tek bir yere taşımak
Modelion'da bu kararlar OPA/Rego ile yazılıyor, WASM'e derleniyor ve gateway'in içinde, isteğin sıcak yolunda değerlendiriliyor. Ölçtüğümüz değerler p50 154µs, p99 222µs — yani karar, isteğin toplam süresinde görünmüyor.
Önemli olan hız değil ama. Önemli olan şu: karar tek bir yerde veriliyor ve o yer bir kural seti, kod değil.
- name: tckn-tespit-yerli-model
when:
match: all
clauses:
- field: signals.pii.types
operator: containsAny
values: [tckn_tr]
then:
effect: route
route:
candidates: [gpt-4o-mini]
fallbackToOriginal: false
obligations:
redactTypes: detected
cache: { mode: off }
auditTags: [kvkk_pii_detected]
Bu kural yürürlüğe girdiğinde uygulama kodunda hiçbir şey değişmiyor. Uygulama hâlâ combo/production-chat diye bir model adı gönderiyor; hangi modele gideceğini politika belirliyor.
Beş eksen, tek karar
Karar tek değerli bir şey değil. Politika beş eksende birden konuşuyor:
- route — hangi modele gitsin
- constrain — aday havuzu nasıl daralsın
- deny — istek reddedilsin mi
- redact — prompt'ta ne maskelensin
- cache — önbellek nasıl davransın
Bu eksenlerin birleşme kuralları önemli: kısıtlar kesişir, yükümlülükler birleşir. Yani platform tabanında yazılmış bir kısıtı, altındaki bir organizasyon kuralı gevşetemez. Bir ekip kendi kural setine yurt dışı bir model ekleyemez — combo'da tanımlı olsa bile çalışmaz.
Bu, tek bir cümleyle, çok kiracılı bir üründe yönetişimin çalışmasını sağlayan şey.
Shadow mod
Kuralı yazmak yeterli değil; uygulamaya almadan önce ne yapacağını bilmek gerekiyor. Shadow modda kural seti her istek için değerlendiriliyor ama sonucu uygulanmıyor — yalnızca kaydediliyor. Bir hafta sonra elinizde şu var: kaç istekte mevcut davranışla uyuştu, kaç istekte ayrıştı, ayrışanlar neydi.
Sapmayı ölçmeden uygulamaya alınan bir kural seti, üretimde öğrenilen bir kural setidir.
Kaybeden kurallar da kayıtlı
Karar izinde yalnızca kazanan kural yok. Eşleşip kaybeden kurallar da listelenir. Bu ilk bakışta ayrıntı gibi duruyor ama denetimde en çok işe yarayan şey oluyor: "bu istekte KVKK kuralı devreye girdi mi" sorusunun cevabı "evet, eşleşti ama daha spesifik bir kural kazandı" olabiliyor — ve bu, "hayır, eşleşmedi"den tamamen farklı bir cevap.