Prompt yönetimi olan bir gateway'de cevaplanması gereken bir sıralama sorusu var: şablon ne zaman giydirilecek?
İki seçenek var ve ikisi de makul görünüyor.
Seçenek A: Politika önce çalışsın, şablon sonra giydirilsin. Politika kararını verir, sonra prompt oluşturulur ve sağlayıcıya gider.
Seçenek B: Şablon önce giydirilsin, politika sonra çalışsın. Prompt tam hâliyle oluşur, politika onu görerek karar verir.
Seçenek A ilk bakışta daha temiz duruyor: karar önce, iş sonra. Ama yanlış.
PII değişkenlerin içinden geliyor
Bir prompt şablonu şuna benziyor:
Müşteri {{customer_name}} ({{customer_tckn}}) için
kredi limiti değerlendirmesi yap. Mevcut limit: {{current_limit}}.
Şablonun kendisinde hiçbir kişisel veri yok. Şablon repo'da duruyor, versiyonlanmış, denetlenmiş, tamamen zararsız.
Kişisel veri, çağrı anında gelen değişkenlerin içinde:
{ "customer_name": "Ayşe Yılmaz", "customer_tckn": "10000000146" }
Şimdi Seçenek A'yı düşünün. Politika çalıştığında elinde ne var? Şablon ve değişkenler ayrı ayrı. Guardrail hattı prompt'u taramak istiyor — hangi metni tarayacak? Şablonu taramak anlamsız, çünkü orada PII yok. Değişkenleri ayrı ayrı taramak mümkün ama bağlamdan kopuk.
Substitution'dan önce tarama yapan her tasarım, yanlış string'i tarıyor.
O yüzden: hydration, politikadan önce
Modelion'daki sıralama şu:
- Auth ve rate limit
- Prompt hydration — şablon ve değişkenler birleşir
- Signal hydration — guardrail hattı gerçek metni okur, sinyalleri yazar
- Politika değerlendirmesi — sinyalleri tüketir, kararı verir
- Routing — kararın kısıtı aday listesiyle kesişir
- Yürütme
Guardrail hattı 3. adımda çalıştığında elinde tam metin var: Müşteri Ayşe Yılmaz (10000000146) için.... TCKN doğrulama algoritması çalışıyor, sinyal doğuyor, politika onu görüyor.
Ama rendering routing'den sonra
Burada ince bir ayrım var. Hydration politikadan önce, ama nihai rendering — yani sağlayıcıya gidecek son metnin oluşması — routing'den sonra.
Sebep: maskeleme bir yükümlülük. Politika "tespit edilen türleri maskele" dediğinde, sağlayıcıya giden metin maskelenmiş hâli olmalı. Eğer son metni politikadan önce dondurursanız, maskelemeyi uygulamak için metni yeniden üretmeniz gerekir.
Ve bunu tersine çevirmenin ikinci bir maliyeti var: şablonu politikadan sonra giydirmek, her istekte politika motorunu iki kez koşturmayı zorunlu kılıyor — bir kez karar için, bir kez maskelenmiş metnin yeni sinyallerini değerlendirmek için.
Özetle
Sıralama estetik bir tercih değil. Yanlış sıralama önce doğruluğu bozuyor: tarayıcı yanlış metni tarıyor, PII sinyali hiç doğmuyor, politikanın maskeleyecek bir şeyi olmuyor. Sonra latency'yi bozuyor: PDP iki kez çalışıyor.
Bu tür kararlarda genelde bir tarafın "daha temiz" görünmesi yanıltıcı oluyor. Belirleyici olan şey, verinin sisteme hangi kapıdan girdiği.