Transformator tabanlı modellere etkileşimde bulunurken, büyük dil modelleri (LLM’ler) ve görsel-dil modelleri (VLM’ler) gibi sistemlerin yapılandırması, modelin çıktısını şekillendirir. Ancak, sorgular genellikle basit bir kullanıcı isteğinden daha fazlasıdır. Pratikte, yanıtı optimize etmek için sistem talimatları, bağlam verileri ve kullanıcı girişi gibi çeşitli kaynaklardan dinamik olarak veri birleştirirler.
Çoklu kiracı ortamlarında (multitenant environments), birden fazla kullanıcının aynı uygulama altyapısını paylaştığı durumlarda, bu dinamik prompt inşası beklenmedik güvenlik riskleri getirebilir. Bu risklerden biri, dikkatli bir şekilde ele alınmazsa kullanıcı sınırları arasında bilgi sızdırabilecek olan ön ek önbellekleme optimizasyonu‘dur.
Bu yazıda, prompt yapısı ve önbellekleme arasındaki kesişim alanını, ayrıca etkileşimlerinin LLM destekli uygulamalarda yarattığı ince güvenlik açıklarını inceleyeceğiz. Bu mekanizmaları anlamak, geliştiricilerin daha güvenli sistemler tasarlamasına yardımcı olabilir.
Uygulama promptları nasıl oluşturulur?
LLM’lerle daha önce sadece bir chatbot kullanıcıı olarak etkileşimde bulunduysanız, sizi ilgilendiren sorguyu şöyle düşünebilirsiniz:
Orlando için Ağustos ayında bir tatil itinereri oluşturmamı sağlar mısınız?
Ancak çoğu gerçek dünyada uygulama, bu kullanıcı sorgusu, uygulama promptu adı verilen daha büyük ve dinamik olarak oluşturulmuş bir girdinin sadece bir parçasıdır. Bu prompt, modelin yanıtını daha etkili bir şekilde şekillendirmek için tasarlanmış birçok bileşen içerir.
Örneğin, tatil itinereri istemi şöyle dönüştürülebilir:
Siz ihtiyacı olan bir seyahat asistanısınız. Nazik olun ve seyahat ve planlama ile ilgisi olmayan konulara girmeyin. İşte kullanıcının isteği:
Orlando için Ağustos ayında bir tatil itinereri oluşturmamı sağlar mısınız?
Bugünün tarihi 1 Mart 2025.
Orlando'da Ağustos ayında gerçekleşecek etkinlikler:
Maraton (1 Ağustos)
Rock Konseri (10 Ağustos)
Sessiz Disco (14 Ağustos)
Bu durum kodda şöyle görünebilir:
application_prompt = f”{system_prompt}n{user_prompt}n{date}n{context}”.
Arka planda uygulama, geçerli tarihi ve ilgili yerel etkinlikleri alıyor ve bunları dil modeli için tek bir prompt halinde birleştiriyor.
Bu örnekte, prompt bileşenleri n karakterleri ile birleştirilmiştir. Ancak birçok üretim uygulaması, farklı bölümleri ayırmak için <system>, <user>, <context> gibi açık etiketler kullanır. Basit bir birleştirme veya yapılandırılmış etiketler kullanılması durumunda, temel ilke aynıdır: uygulama, LLM için özel olarak hazırlanmış bir prompt oluşturmaktadır.
Neden KV önbelleği hızlıdır?
Ön ek önbellekleme, LLM hizmet sistemlerinde kullanılan güçlü bir performans optimizasyonudur. Bu yöntem, modelin iç durumunu tekrarlanan prompt ön ekleri için yeniden kullanarak sistemin gereksiz hesaplamaları atlamasını sağlar ve daha hızlı yanıtlar döndürür.
Bu, anahtar-değer (KV) önbelleği kullanılarak gerçekleştirilir. Model, giriş tokenlerini işlerken, modelin durumunu temsil eden geçici tensörler – anahtarlar ve değerler – oluşturur. Yeni bir prompt, önceki birinin ön eki ile aynı olursa, sistem bu önbelleklenmiş KV’leri yeniden kullanabilir ve yeniden hesaplamaktan kaçınabilir. Örneğin:
Hızlı kahverengi tilki tembeli köpeğin üzerinden atlar.
Ve yeni bir prompt geldiğinde:
Hızlı kahverengi tilki dereden geçiyor,
Sistem, ortak ön ek olan “Hızlı kahverengi tilki” için yeniden hesaplama yapmadan doğrudan “geçiyor” kelimesinden başlamayı tercih edebilir. Bu optimizasyon, sistem talimatları gibi sabit olan sistem istemleri için oldukça etkilidir.
Bununla birlikte, çoklu kiracı ortamlarında bu paylaşılan verimlilik, bir zamanlama yan kanalı haline gelebilir ve bir kullanıcının, diğer kullanıcıların promptları hakkında bazı detayları çıkarmasına olanak tanıyabilir.
Ön ek önbelleği ile bilgi sızıntıları
Ön ek önbelleği, LLM yanıt sürelerini artırmak için daha önce hesaplanmış iç durumların yeniden kullanılmasına olanak tanır. Ancak çoklu kiracı ortamlarında, bu optimizasyon, zamanlama tabanlı bilgi ifşasına yol açabilir.
İki prompt uzun bir öne sahip olduğunda, model, o ilk paylaşılan tokenleri yeniden hesaplamayı atlayabilir, bu da ikinci isteğin daha hızlı gerçekleşmesini sağlar. Bir saldırgan, girdileri titizlikle tasarlayarak ve yanıt gecikmelerini ölçerek, kendi promptlarının ilk bölümünün daha önce görüldüğünü çıkarabilir; bu durum, diğer kullanıcıların sorguları hakkında bazı bilgiler ifşa edebilir.
Örnek: Yer ve Tarih Çıkarımı
Örneğin bir seyahat asistanı durumunda, A Kullanıcısı şu promptu gönderiyor:
Orlando için Ağustos ayında bir tatil itinereri oluşturmamı sağlar mısınız?
Daha sonra B Kullanıcısı, bir saldırgan olarak, sistemi bir dizi benzer sorgu ile ölçüyor:
- “Atlanta için Haziran ayında bir tatil itinereri oluşturmamı sağlar mısınız?”
- “Orlando için Haziran ayında bir tatil itinereri oluşturmamı sağlar mısınız?” (Bu, A Kullanıcısının KVs için daha hızlıdır.)
- “Orlando için Temmuz ayında bir tatil itinereri oluşturmamı sağlar mısınız?”
- “Orlando için Ağustos ayında bir tatil itinereri oluşturmamı sağlar mısınız?” (Bu da A Kullanıcısından kaynaklanan KVs nedeniyle daha hızlıdır.)
Son hali önemli ölçüde daha hızlı dönerse, bu, önceden A Kullanıcısının isteğinden kaynaklanan bir önbelleğin olduğunu gösterir. Yeterli varyasyonlarla, bir saldırgan, doğrudan görmeden orijinal sorgunun içeriğini keşfedebilir.
Risk, kullanıcı sorgusu ile sınırlı değildir
Risk sadece kullanıcı tarafından girilen sorgularla sınırlı değildir. Birçok LLM uygulaması, dinamik olarak prompta ek veriler ekler. Bu eklemeler, kullanıcılar tarafından doğrudan kontrol edilmese de, zamanlama farklılıklarından gözlemlenebilir hale gelebilir.
Örneğin, B Kullanıcısı şu sorguyu girer:
Orlando için Ağustos ayında bir tatil itinereri oluşturmamı sağlar mısınız?nBugünün tarihi 28 Şubat.
ve
Orlando için Ağustos ayında bir tatil itinereri oluşturmamı sağlar mısınız?nBugünün tarihi 1 Mart.
İkinci sorgu bir önbellek vuruşu olduğu takdirde, B Kullanıcısı, başka bir kullanıcının isteğinin ne zaman gönderildiğini çıkarabilir. Kullanıcının sunduğu tarih, uygulama tarafından eklenmiş olmasına rağmen, bu durum önbellek alımını etkilemez.
Önbellek yapılandırmasının etkisi
Bir saldırgan, bu zamanlama yan kanalını, önbelleğin nasıl yapılandırıldığı hakkında sahip olduğu bilgi ile birleştirerek daha da geliştirebilir. Her sistem, KV önbellek için ne kadar depolama alanı tahsis edeceği konusunda karar vermelidir ve çoğu uygulama, en son kullanılan (LRU) bir silme politikası kullanır.
Bu yapılandırma, bir saldırganın sistem durumunu kontrol edip ölçmesine olanak tanır. Örneğin, hangi girdilerin önbellek vuruşlarının hala geçerli olduğunu sorgulayarak, bir promtun ne kadar süredir kullanıldığını veya ne sıklıkla erişildiğini çıkarabilir.
Gerçek dünya LLM sistemlerinin performansı birçok değişkenden etkilenmektedir:
- Ağ gecikmesi, önbellek davranışıyla ilgili olmayan gürültüyü getirebilir.
- Toplama, birden fazla isteği bir araya getirerek verimliliği artırır. Tekil isteklerin belirli bir zaman diliminde bekletilmesine neden olduğundan, ince zamanlama farklılıklarını gizleyebilir.
- API çağrıları gibi araç ve eklenti etkileşimleri, yanıt sürelerinin sistem yüküne, verinin karmaşıklığına veya ağ koşullarına göre değişmesine neden olabilir.
Tüm bu faktörler, bir yanıtın önbellek vuruşunun faydalandığı varsayımını doğrulamayı zorlaştırır.
Daha güvenli sistemler tasarlamak
Ön ek önbellekleme, LLM uygulamalarında önemli bir performans artışı sunarken, paylaşılan ortamlarda ince bilgi ifşası riskleri de getirebilir. Promptlar, kullanıcı girdileri, araç çıkışları ve bağlamsal verilerle dinamik olarak oluşturulduğunda, bu yapının, hem performans hem de güvenlik üzerinde etkili bir tasarım tercihi olduğunu unutmamak önemlidir.
Önerilen önlemler; önbellek kullanımını izole etmek, promptları dikkatlice yapılandırmak ve girdileri doğrulamaktır. Böylelikle geliştiriciler, performanstan taviz vermeden pozitif bir güvenlik durumu oluşturmaktan kaçınabilir.
