Yapay Zekada Ücretsiz Katman Politikası Nasıl Yönetilir?

Yapay Zekada Ücretsiz Katman Politikası Nasıl Yönetilir?

Ücretsiz yapay zeka katmanlarında maliyetleri düşüren, sürümlenebilir istek düzeyi aranmayacaklar listesi (Do-Not-Call List) mimarisini ve pratik adımlarını keşfedin.

Yapay zeka odaklı modern yazılımlarda kullanıcı tabanını hızla büyütmenin en bilinen yolu cömert bir ücretsiz katman (free tier) sunmaktır. Ancak fatura günü geldiğinde OpenAI, Anthropic veya Google Cloud faturalarıyla karşılaşan mühendislik ekipleri büyük bir şok yaşar. Kullanıcıların girdiği anlamsız girdiler, tekrarlayan selamlaşmalar ya da bot ağlarının tetiklediği otomatik sorgular, şirket bütçesini sessizce tüketir. İşte bu noktada geleneksel hız sınırlandırma (rate limiting) yaklaşımları yetersiz kalmaktadır. Geliştiricilerin istek içeriğini dinamik biçimde değerlendiren ve modele hiç gitmemesi gereken durumları kod gibi sürümleyen (versioning) bir istek düzeyi politikasına ihtiyacı vardır.

Bu makalede, ücretsiz yapay zeka katmanları için “aranmayacaklar listesi” (Do-Not-Call List) kurgusunun ne olduğunu, büyük dil modellerine (LLM) giden trafiğin istek seviyesinde nasıl filtreleneceğini ve bu kuralların GitOps prensipleriyle nasıl sürümleneceğini derinlemesine inceleyeceğiz.

Ücretsiz Yapay Zeka Katmanlarında Maliyet Krizi Neden Doğar?

Yazılım dünyasında SaaS (Hizmet Olarak Yazılım) modelleri uzun yıllardır marjinal maliyeti sıfıra yakın çalışan altyapılara dayandı. Klasik bir veritabanı okuma veya yazma işleminin maliyeti kuruşların binde biri seviyesindedir. Bundan dolayı, kullanıcılara sınırsız deneme imkanları sunmak geçmişte finansal bir intihar anlamına gelmiyordu. Ne var ki, üretken yapay zeka (generative AI) modelleri sahneye çıktığında bu ekonomik denklem kökten değişti. Her bir model çağrısı; girdi belirteçleri (input tokens), çıktı belirteçleri (output tokens) ve yoğun grafik işlemci (GPU) hesaplama gücü gerektirir.

Özellikle Türkiye gibi döviz kuru dalgalanmalarının maliyetleri doğrudan etkilediği pazarlarda, dolar bazlı API harcamaları yerel girişimlerin karlılığını doğrudan tehdit eder. Ücretsiz katman kullanan bir ziyaretçi platformunuza gelip “merhaba”, “oradalar mı?”, “test 1 2 3” gibi içerikler yazdığında, arka planda en gelişmiş modelleri tetikliyorsanız her sorguda para kaybedersiniz. Üstelik bu kullanıcıların ücretli aboneliğe geçme ihtimali çoğu zaman son derece düşüktür.

Buna ek olarak, kötü niyetli aktörlerin ücretsiz katmanları suistimal etmesi yaygın bir problemdir. Rakipler sisteminizi yavaşlatmak veya API kotanızı tüketmek için basit otomasyon betikleriyle platformunuza anlamsız istekler gönderebilir. Salt IP bazlı hız sınırlandırması bu problemi çözemez; çünkü dağıtık ağlar veya mobil proxy servisleri bu engelleri rahatlıkla aşar. Bu nedenle çözüm, ağ katmanından uygulama ve semantik mantık katmanına inmelidir.

Aranmayacaklar Listesi (Do-Not-Call List) Nedir ve Nasıl Çalışır?

Telekomünikasyon sektöründe “aranmayacaklar listesi”, pazarlamacıların aramaması gereken telefon numaralarını barındıran yasal bir veri tabanıdır. Yapay zeka mimarisinde ise bu kavram; bir isteğin temel modele (foundation model) hiç ulaştırılmadan reddedilmesini, önbellekten yanıtlanmasını ya da çok ucuz alternatiflerle karşılanmasını sağlayan istek düzeyi filtreleme protokolünü temsil eder.

Bu mimaride gelen her istek, LLM ağ geçidine (gateway) varmadan önce bir dizi karar filtresinden geçer. Bu filtreler şunları denetler:

• Semantik Değersizlik: Kullanıcı sadece “günaydın”, “teşekkürler” veya rastgele klavye vuruşları mı gönderiyor?
• Soru Dışı İstekler: Ürününüz bir e-ticaret analiz aracı iken kullanıcı sisteminize felsefi şiirler mi yazdırıyor?
• Yinelenen İstekler (Exact & Semantic Cache): Bu sorunun harfi harfine veya anlamsal olarak aynısı son bir saat içinde başka bir kullanıcı tarafından soruldu mu?
• Kötü Amaçlı Enjeksiyonlar (Prompt Injection): İstek, sistem talimatlarını aşmaya yönelik zararlı kalıplar barındırıyor mu?

Eğer gelen istek bu kurallardan birine takılırsa, sistem “Do-Not-Call” bayrağını aktif hale getirir. Sonuç olarak pahalı model çağrısı iptal edilir. Kullanıcıya statik bir yanıt döndürülür, yerel bir kural tabanlı sistem işletilir veya çok küçük bir açık kaynak model (SLM – Small Language Model) devreye sokulur. Böylelikle temel modelin maliyet ve kaynak tüketimi engellenmiş olur.

İstek Düzeyi Politikaları (Request-Level Policies) Nasıl Sürümlenir?

Filtreleme kurallarını uygulama kodunun içerisine sabit (hard-coded) olarak yazmak yapılan en yaygın hatadır. Bir kuralı güncellemek için tüm uygulamayı yeniden derlemek ve dağıtmak (deploy) operasyonel çevikliği yok eder. İstek düzeyi politikalar tıpkı veritabanı şemaları veya API kontratları gibi bağımsız birer varlık olarak ele alınmalı ve sürümlenmelidir (versioned).

Sürümlenebilir bir politika motoru oluşturmak için GitOps prensiplerinden faydalanılır. Kurallar bildirimsel (declarative) formatlarda, örneğin YAML veya JSON şemalarıyla tanımlanır. Aşağıdaki maddeler sürümlenebilir politikanın temel adımlarını oluşturur:

1. Versiyon Kontrolü (Git): Her politika değişikliği bir “commit” ile izlenir; kimin hangi regex ifadesini veya benzerlik eşiğini neden değiştirdiği şeffaf hale gelir.
2. Anlamsal Sürümleme (SemVer): Politikalara v1.2.0 gibi etiketler verilir. Geriye dönük uyumsuz kural setleri büyük sürüm (major) artışıyla ayrıştırılır.
3. Çalışma Zamanı Dinamik Yükleme: Politika motoru, kuralları Redis, etcd veya Cloudflare KV gibi dağıtık bir yapılandırma merkezinden anlık okur; kod dağıtımı gerekmez.
4. Hızlı Geri Alma (Rollback): Yeni eklenen bir kural seti meşru kullanıcı isteklerini yanlışlıkla engellerse (false-positive), tek bir komutla önceki sürüme dönülür.

Böyle bir mimari sayesinde, ürün yöneticileri ve makine öğrenimi mühendisleri üretim ortamındaki kodu bozma riski olmadan engelleme kurallarını hassaslaştırabilir.

Adım Adım Sürümlenebilir Politika Motoru Nasıl Kurulur?

Pratik bir senaryo üzerinden ilerleyelim. Python ve FastAPI kullanarak gelen istekleri karşılayan, kuralları bir JSON şemasından dinamik yükleyen ve LLM çağrısını engelleyen bir ara yazılım (middleware) kurgulayalım. İlk olarak politika konfigürasyonumuzu hazırlamamız gerekir.

Aşağıdaki JSON bloğu, v1.1.0 sürümüne sahip basit bir “Do-Not-Call” politika dosyasını temsil etmektedir:

{
  "policy_version": "1.1.0",
  "environment": "production",
  "rules": {
    "block_exact_phrases": [
      "merhaba",
      "selam",
      "test",
      "oradamısın",
      "teşekkürler"
    ],
    "max_token_length_for_free_tier": 500,
    "min_character_length": 5,
    "reject_regex_patterns": [
      "^(.)\\1+$",
      "(?i)(ignore previous instructions|promptu unut)"
    ]
  },
  "fallbacks": {
    "default_rejection_message": "Talebiniz ücretsiz katman kapsamı dışındadır veya anlamsız veri içermektedir."
  }
}

Şimdi bu kural dosyasını okuyan ve kullanıcı isteklerini denetleyen ara yazılım kodunu geliştirelim. Bu kod, gelen isteğin politikalara takılıp takılmadığını denetleyecek ve gerekirse pahalı modele gitmeden isteği sonlandıracaktır:

import re
import json
from fastapi import FastAPI, HTTPException, Request

app = FastAPI()

# Sürümlenmiş politika belgesini yükleme
with open("dnc_policy_v1.1.0.json", "r", encoding="utf-8") as f:
    active_policy = json.load(f)

def evaluate_do_not_call_policy(user_input: str, user_tier: str) -> tuple[bool, str]:
    if user_tier != "free":
        return False, "Kural işletilmedi (Ücretli Katman)"

    rules = active_policy["rules"]
    cleaned_input = user_input.strip().lower()

    # 1. Kural: Minimum karakter denetimi
    if len(cleaned_input) < rules["min_character_length"]:
        return True, "Girdi uzunluğu yetersiz."

    # 2. Kural: Tam eşleşen anlamsız ifadeler
    if cleaned_input in rules["block_exact_phrases"]:
        return True, "Temel model çağrısı gerektirmeyen selamlama/kısa ifade."

    # 3. Kural: Regex bazlı denetimler (tekrarlayan harfler ve jailbreak)
    for pattern in rules["reject_regex_patterns"]:
        if re.search(pattern, cleaned_input):
            return True, "Geçersiz içerik veya politika ihlali tespit edildi."

    return False, "Onaylandı"

@app.post("/v1/chat")
async def chat_endpoint(request: Request):
    data = await request.json()
    prompt = data.get("prompt", "")
    user_tier = data.get("tier", "free")

    should_block, reason = evaluate_do_not_call_policy(prompt, user_tier)

    if should_block:
        return {
            "policy_version": active_policy["policy_version"],
            "model_called": False,
            "blocked_by_dnc": True,
            "reason": reason,
            "response": active_policy["fallbacks"]["default_rejection_message"]
        }

    # Model çağırma simülasyonu
    # response = call_expensive_llm(prompt)
    return {
        "policy_version": active_policy["policy_version"],
        "model_called": True,
        "response": "Yapay zeka modelinin ürettiği başarılı yanıt."
    }

Yukarıdaki örnekte görüldüğü gibi, basit bir selamlama veya istismar girişimi yapıldığında sistem saniyeler içerisinde ve sıfır API maliyetiyle kullanıcıyı yanıtlar. Böylece pahalı LLM modelleri gereksiz iş yükünden korunur.

Geleneksel Hız Sınırlama ile İstek Düzeyi Politika Farkları Nelerdir?

Birçok sistem mimarı, Do-Not-Call yaklaşımı ile geleneksel API hız sınırlama mekanizmalarını (Rate Limiting) birbiriyle karıştırmaktadır. Ancak bu iki yaklaşım farklı katmanlarda çalışır ve birbirini tamamlar. Aşağıdaki karşılaştırma tablosu bu iki konsept arasındaki temel farkları açıkça ortaya koymaktadır:

Görüldüğü üzere, sadece hız sınırlamasına güvenmek arka plandaki modelin boşuna çalıştırılmasını önlemez. Kullanıcı kotası dahilinde kalarak sisteme anlamsız ya da pahalı 5 istek gönderdiğinde bile bütçenizi aşındırabilir.

Yerli Bir SaaS Girişiminde Başarı Hikayesi: Vaka Analizi

Konunun somutlaşması için Türkiye pazarında faaliyet gösteren bulut tabanlı bir müşteri destek platformunu inceleyelim. Bu girişim, e-ticaret sitelerine gelen müşteri mesajlarını yapay zeka ile otomatik yanıtlayan bir SaaS ürünü sunuyordu. Büyümeyi hızlandırmak adına kullanıcılara aylık 250 mesaja kadar ücretsiz bir deneme paketi tanımladılar.

İlk üç ayın sonunda platforma 4.000 aktif mağaza kaydoldu. Ancak şirket yönetimi beklenmedik bir fatura kriziyle yüzleşti. Mağazalara gelen mesajların %42’si “kargom nerede?”, “merhaba”, “fiyat nedir?”, “iade var mı?” gibi son derece standart kalıplardan oluşuyordu. Girişimin yazılımı ise bu soruların her biri için OpenAI GPT-4o modeline 2.000 belirteçlik sistem bağlamı (context) ile çağrı yapıyordu. Fatura ayda 6.000 doları aştı ve bu durum ücretsiz katmanın sürdürülemez olduğunu gösterdi.

Mühendislik ekibi, üçüncü ayın sonunda sürümlenebilir bir Do-Not-Call motoru geliştirdi. dnc-rules-v1.0 adıyla yayına alınan ilk sürümde, sık tekrarlanan 15 soru tipi belirlendi ve yerel bir vektör veritabanı üzerinden anlamsal önbelleğe (semantic cache) yönlendirildi. Ayrıca tek kelimelik mesajlar kural motoruyla doğrudan filtrelendi. Sonuçlar çarpıcıydı:

• Temel modele giden istek hacmi %64 oranında azaldı.
• Ücretsiz katmanın aylık toplam model maliyeti 6.200 dolardan 1.850 dolara geriledi.
• Sık sorulan sorular anında yanıtlandığı için sistemin ortalama yanıt süresi 2.8 saniyeden 120 milisaniyeye düştü.
• Yanlış engellenen talepler tespit edildikçe politika dnc-rules-v1.4 sürümüne güncellendi ve geriye dönük doğruluk sağlandı.

Bu vaka analizi, istek seviyesinde alınan akılcı kararların bir girişimin finansal geleceğini nasıl kurtarabileceğini açıkça ispatlamaktadır.

İleri Düzey Optimizasyonlar ve Güvenlik Önlemleri Nelerdir?

Aranmayacaklar listenizi temel metin karşılaştırmalarının ötesine taşımak istediğinizde daha gelişmiş teknikler uygulamanız gerekir. Başarılı bir politika motoru mimarisi, kuralları sadece statik tutmaz; onları dinamik analiz katmanlarıyla birleştirir.

İlk olarak, anlamsal benzerlik (semantic similarity) filtrelerini devreye sokabilirsiniz. Kullanıcıların girdiği metinleri küçük bir gömme (embedding) modelinden geçirerek, daha önce yanıtlanmış sorularla kosinüs benzerliğini (cosine similarity) ölçebilirsiniz. Eşik değer %92’nin üzerindeyse, pahalı modeli hiç çağırmadan önbellekteki yanıtı döndürmek maliyeti neredeyse sıfırlar.

İkinci olarak, uç ağ geçitleri (Edge Gateways) üzerinde politika işletimi sağlayabilirsiniz. Cloudflare Workers, Fastly Compute@Edge veya AWS Lambda@Edge üzerinde Do-Not-Call kurallarınızı çalıştırırsanız, geçersiz istekler ana sunucularınıza dahi ulaşmadan dünyanın en yakın noktasında sonlandırılır. Bu durum hem bant genişliği tasarrufu sağlar hem de sunucu altyapınızın CPU tüketimini azaltır.

Son olarak, politika sürümleme döngünüze “gölge mod” (shadow mode) testleri eklemelisiniz. Yeni bir kural setini (örneğin v2.0.0) doğrudan devreye almak yerine, gelen gerçek istekler üzerinde sessizce çalıştırın. Yeni kuralın neleri engelleyeceğini sadece loglayın. Yanlış pozitif (false positive) oranı kabul edilebilir bir sınırın altındaysa, politikayı resmi olarak canlı trafiğe açın.

Sıkça Sorulan Sorular

Do-Not-Call politikası meşru kullanıcıları engellerse ne yapılmalıdır?

Politikalar sürümlenebilir yapıda tasarlandığı için geriye dönük dönüşler anında gerçekleştirilebilir. Hatalı engelleme tespit edildiğinde, ilgili kural JSON dosyasından çıkarılarak yeni bir alt sürüm (patch version) yayınlanır veya sistem bir önceki kararlı sürüme saniyeler içinde geri çekilir.

Bu filtreleme mekanizması yanıt sürelerini olumsuz etkiler mi?

Tam aksine, yanıt sürelerini dramatik biçimde hızlandırır. Karmaşık bir dil modelini çağırmak 1 ila 5 saniye arasında sürerken; regex, önbellek ve kural kontrolleri genellikle 5 ila 25 milisaniye içinde tamamlanır. Bu durum engellenen isteklerde kullanıcı deneyimini iyileştirir.

Semantic Caching (Anlamsal Önbellekleme) bir DNC kuralı sayılır mı?

Evet, anlamsal önbellekleme Do-Not-Call stratejisinin en güçlü bileşenlerinden biridir. Eğer bir istek daha önce yanıtlanmış bir girdiye anlamsal olarak çok yakınsa, ana modele yapılan çağrı iptal edilir ve önbellekten yanıt üretilir. Bu da aranmayacaklar listesinin temel prensibidir.

Ücretsiz katman dışındaki ücretli kullanıcılar için bu kurallar uygulanmalı mıdır?

Genellikle ücretli katmandaki kullanıcılara katı kurallar uygulanmaz; çünkü bu kullanıcılar model maliyetini abonelik ücretleriyle karşılarlar. Ancak kötü amaçlı enjeksiyon (prompt injection) ve sistem güvenliğini tehdit eden kurallar katmandan bağımsız olarak tüm kullanıcılara uygulanmalıdır.

#YapayZeka #MaliyetOptimizasyonu #SaaS #YazilimMimarisi #DevOps