AI Destekli Yazılım Geliştirmede LLM Yanıt Önbelleği Tasarımı

AI destekli yazılım geliştirme için önbellek sınırını belirlemek

Bir LLM çağrısını cache'lemek, sadece aynı prompt tekrarlandığında güvenlidir varsayımıyla başlatılmamalıdır. Cache anahtarı en az tenant_id, model kimliği, sistem promptu sürümü, araç çıktılarının özeti, çıktı şeması ve sıcaklık bileşenlerini kapsamalıdır. Örneğin sıcaklık 0.7 ile üretilen yaratıcı metni, sıcaklık 0 ile çalışan bir sınıflandırma akışına taşımak cevap dağılımını değiştirir. Generative AI servislerinde cache'i önce yalnızca idempotent, salt-okunur görevlerde açın: doküman özetleme, embedding üretimi, sabit bilgi tabanından soru yanıtlama ve yapılandırılmış etiketleme buna uygundur; güncel stok, yetki, ödeme ve kişiselleştirilmiş fiyat gibi araç çağrısı içeren akışlar değildir.

Uygulanabilir başlangıç kuralı olarak endpoint bazında bir allowlist kullanın ve cache yazımını JSON Schema doğrulamasından sonraya koyun. Bu, modelin eksik alanlı veya hatalı biçimli bir cevabının sonraki isteklerde tekrar edilmesini engeller. Python tarafında Pydantic ile doğrulama başarısız olduğunda Redis'e hiç yazmayın:

from pydantic import BaseModel, Field

class Classification(BaseModel):
    category: str = Field(pattern="^(bug|feature|question)$")
    confidence: float = Field(ge=0, le=1)

def cacheable(route: str, payload: dict) -> bool:
    return route in {"/classify", "/summarize"} and not payload.get("tools")

result = Classification.model_validate(llm_json)
if cacheable(route, request_payload):
    redis.setex(cache_key, 900, result.model_dump_json())

Bu ayrım, yapay zeka eğitimi veya llm eğitimi sırasında sıklıkla atlanan bir üretim detayıdır: LLM cache'i HTTP response cache'i değildir. Prompt'a eklenen kullanıcı profili, RAG kaynak sürümü ya da araç sonucu anahtara katılmazsa farklı bağlamdaki cevaplar birbirine sızar. Her cache kaydına kaynak dokümanların content hash listesini eklemek ve indeks yeniden oluşturulduğunda bu sürümü değiştirmek, RAG cache invalidation için zaman aşımından daha güvenilir bir sınır verir.

LLM eğitimi pratiği: deterministik anahtar ve semantik cache

Tam eşleşme cache'i için JSON gövdesini doğrudan hash'lemeyin. JSON alan sırası, gereksiz boşluklar ve varsayılan parametrelerin istemciden istemciye farklı gönderilmesi aynı mantıksal isteğin cache'i kaçırmasına yol açar. Kanonikleştirilmiş gövdeyi, tenant ve prompt şemasıyla birlikte SHA-256 üzerinden üretin. Model sağlayıcısının takma adı yerine dağıtımda kullandığınız değişmez model kimliğini ekleyin; aksi halde sağlayıcı tarafındaki yönlendirme değişikliği eski cevapları döndürebilir.

import hashlib
import json

def exact_cache_key(tenant_id, model_id, prompt_version, schema_version, body):
    normalized = json.dumps(body, sort_keys=True, separators=(",", ":"), ensure_ascii=False)
    material = "|".join([
        tenant_id, model_id, prompt_version, schema_version, normalized
    ])
    digest = hashlib.sha256(material.encode("utf-8")).hexdigest()
    return f"llm:exact:{tenant_id}:{digest}"

key = exact_cache_key(
    tenant_id="acme",
    model_id="provider-model-deployment-2026-01",
    prompt_version="support-v12",
    schema_version="classification-v3",
    body={"text": "Fatura PDF'i açılamıyor", "language": "tr"},
)

Semantik cache, embedding yakınlığıyla benzer soruyu bulur; ancak yanlış pozitif maliyeti yüksek olduğundan serbest metin üretiminde körlemesine kullanılmamalıdır. Redis Stack üzerinde tenant, model ve şema için TAG filtresi koyup yalnızca aynı sözleşmede KNN araması yapın. Aşağıdaki indeks, 1536 boyutlu embedding saklar; kendi embedding modeliniz farklı boyut üretiyorsa DIM değeri tam olarak onunla eşleşmelidir. Boyut uyumsuzluğu bazı istemcilerde sessizce sorgu hatasına dönüşür.

redis-cli FT.CREATE llmcache ON HASH PREFIX 1 cache: SCHEMA   tenant TAG   model TAG   schema TAG   prompt VECTOR HNSW 6 TYPE FLOAT32 DIM 1536 DISTANCE_METRIC COSINE

redis-cli FT.SEARCH llmcache   '(@tenant:{acme} @model:{provider-model-deployment-2026-01} @schema:{classification-v3})=>[KNN 1 @prompt $vec AS score]'   PARAMS 2 vec "$QUERY_VECTOR" SORTBY score DIALECT 2

KNN sonucunu sadece mesafe eşiğinin altında ise kabul edin ve eşiği görev türüne göre kalibre edin. Örneğin 10.000 etiketlenmiş geçmiş istek üzerinde 0.08, 0.12 ve 0.16 cosine distance eşiklerini deneyin; her eşik için yanlış cache hit oranını ve LLM çağrısı tasarrufunu ölçün. Sınıflandırma için 0.08 güvenli olabilirken özetleme için aynı eşik kaynak metindeki küçük bir değişikliği saklayabilir. Bu deney, vibe coding eğitimi veya vibe coding kursu projelerinde de otomatik üretilen cache katmanının değerlendirme veri seti olmadan canlıya alınmaması gerektiğini gösterir.

Önce-sonra profil ile cache gecikmesini doğrulamak

Cache ekledikten sonra yalnızca hit ratio raporlamak yeterli değildir. OpenTelemetry ile her LLM isteğine `llm.cache.status`, `llm.model`, `llm.prompt_version` ve `llm.input_tokens` özniteliklerini ekleyin; Prometheus'ta cache hit ve miss için ayrı histogramlar üretin. Amaç, cache hit p95'inin Redis ağ gecikmesi ve JSON ayrıştırma nedeniyle beklenmedik biçimde büyümediğini, miss p95'inin de ek embedding çağrısı yüzünden kötüleşmediğini görmektir.

from opentelemetry import trace
from time import perf_counter

tracer = trace.get_tracer("assistant.cache")

with tracer.start_as_current_span("llm.answer") as span:
    started = perf_counter()
    value = redis.get(key)
    span.set_attribute("llm.cache.status", "hit" if value else "miss")
    if value:
        answer = value
    else:
        answer = call_model(request_payload)
        redis.setex(key, 900, answer)
    span.set_attribute("llm.cache.elapsed_ms", (perf_counter() - started) * 1000)

Önce-sonra karşılaştırmasını aynı trafik dağılımında yapın. Örneğin cache kapalı 30 dakikalık p50, p95, hata oranı, input-output token sayısı ve istek başına embedding süresini kaydedin. Ardından cache'i yalnızca trafiğin yüzde 10'unda feature flag ile açın ve aynı metrikleri route ve tenant bazında karşılaştırın. PromQL tarafında hit gecikmesini şu şekilde ayırabilirsiniz: histogram_quantile(0.95, sum by (le) (rate(http_server_request_duration_seconds_bucket{cache_status="hit"}[10m]))). Bir hit'in p95'i miss p95'inden düşük olsa bile, semantik embedding çağrısı her istekte yapılıyorsa düşük trafikte net kazanç negatif olabilir.

Bu ölçüm yaklaşımı devops eğitimi kapsamında özellikle önemlidir: tracing olmadan Redis bağlantı havuzu doygunluğu, embedding sağlayıcısı gecikmesi ve model çağrısı aynı span içinde kaybolur. Redis için `redis-cli --latency-history` çalıştırın, uygulama havuzundaki bekleme süresini ayrı metrik olarak izleyin ve `max_connections` değerini load test ile belirleyin. Yaygın hata, HTTP worker sayısını artırıp Redis bağlantı sayısını sınırsız bırakmaktır; kısa süreli trafik patlamasında connection churn, cache hit yolunu model çağrısından pahalı hale getirebilir.

Cloud native mimari içinde izolasyon ve dağıtım kuralları

Cloud native mimari için cache katmanını uygulama pod'undan ayrı ölçekleyin ve `tenant` filtresini sadece uygulama koduna emanet etmeyin. Redis ACL ile uygulamanın yalnızca kendi anahtar öneklerine erişmesini sınırlayın; Kubernetes NetworkPolicy ile API pod'larının Redis portuna erişimini namespace ve label üzerinden kısıtlayın. Container orchestration kullanan ekiplerde bu ikinci sınır, yanlış yapılandırılmış bir worker'ın başka bir ortamın cache verisini taramasını engeller.

Kubernetes eğitimi laboratuvarında minikube üzerinde önce aynı manifesti yerelde doğrulayın: `minikube start`, ardından `kubectl apply -f cache-api.yaml` ve `kubectl port-forward svc/cache-api 8080:8080`. Pod'a kaynak sınırı koymadan benchmark yapmak yanıltıcıdır; CPU throttling altında embedding serileştirme süresi p95'i etkiler. Aşağıdaki kaynaklar, uygulama için tekrarlanabilir bir başlangıç sınırı sağlar ve HPA kararını CPU yerine ayrıca dış metrik olan queue depth ile vermeniz gerektiğini görünür kılar.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm-cache-api
spec:
  template:
    spec:
      containers:
      - name: api
        image: registry.example/llm-cache-api:sha-abc123
        resources:
          requests:
            cpu: "250m"
            memory: "512Mi"
          limits:
            cpu: "1"
            memory: "1Gi"
        env:
        - name: CACHE_TTL_SECONDS
          value: "900"

docker eğitimi ile başlayan ekipler için kritik geçiş noktası şudur: Docker Compose'taki tek Redis konteyneri, production eviction davranışını temsil etmez. `maxmemory-policy allkeys-lfu` seçimi sık erişilen kısa cevapları koruyabilir ama tenant adaleti sağlamaz. Büyük tenant'ların anahtarları küçük tenant'ların cache'ini silebileceğinden, tenant başına kota veya ayrı logical cache düşünün. AWS eğitimi ya da google cloud eğitimi bağlamında yönetilen Redis hizmeti seçilse bile, failover anında cache miss fırtınası oluşacağını varsayın; model sağlayıcısına yönelik concurrency limiter uygulamada kalmalıdır.

CI CD pipeline ile cache sözleşmesini ve altyapıyı test etmek

Bir ci cd pipeline, cache anahtarını unit test ile ve Redis indeks şemasını entegrasyon testiyle kilitlemelidir. Testcontainers kullanarak geçici Redis Stack başlatın, aynı payload'ın alan sırası değiştiğinde aynı anahtarı verdiğini, `tenant_id` değiştiğinde ise farklı anahtar verdiğini doğrulayın. Ayrıca prompt sürümü değiştiğinde eski verinin kullanılmadığını test edin. Bu testler, kod incelemesinde görünmeyen fakat deploy sonrası yüksek hit oranıyla veri sızıntısına dönüşebilen regresyonları yakalar.

Infrastructure as code yaklaşımında TTL, bellek sınırı, güvenlik grubu ve alarm eşiklerini elle konsoldan değiştirmeyin. Terraform planında Redis parametre grubunu ve p95 alarmını birlikte gözden geçirin. Örnek olarak `terraform plan -out=cache.plan` ürettikten sonra planı onaylı CI aşamasında uygulayın; üretimde doğrudan `terraform apply` çalıştırmayın.

resource "aws_cloudwatch_metric_alarm" "llm_cache_hit_latency" {
  alarm_name          = "llm-cache-hit-p95-high"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 3
  metric_name         = "cache_hit_p95_ms"
  namespace           = "Assistant"
  period              = 60
  statistic           = "Maximum"
  threshold           = 150
}

Bu çalışma, yazılım eğitimi ve teknoloji eğitimi içeriklerinde tek başına LLM API çağrısı öğretmenin neden eksik kaldığını somutlaştırır. Yapay zeka kursu içeriğinde model çağrısından önce cache anahtarı testi, llm eğitimi modülünde semantik eşik kalibrasyonu, devops eğitimi modülünde OpenTelemetry dashboard'u, docker eğitimi ve kubernetes eğitimi modüllerinde yerel minikube senaryosu birlikte kurulmalıdır. Böyle bir akışta yapay zeka eğitimi, vibe coding eğitimi ve vibe coding kursu katılımcıları üretilen kodu sadece çalıştırmaz; yanlış cache hit, pod kaynak limiti ve Terraform drift gibi üretim arızalarını da yeniden üretir.

Sık Sorulan Sorular

AI destekli yazılım geliştirme projelerinde LLM cache anahtarına ne eklenmeli?

En az tenant_id, değişmez model dağıtım kimliği, sistem promptu sürümü, çıktı şeması sürümü, sıcaklık ve kanonikleştirilmiş istek gövdesini ekleyin. RAG kullanılıyorsa kaynak chunk content hash listesini veya retrieval indeks sürümünü de katın. Yalnızca prompt metnini hash'lemek, farklı kullanıcı bağlamlarının aynı cevabı paylaşmasına neden olur.

LLM eğitimi için semantik cache eşiği nasıl ölçülür?

Etiketlenmiş en az birkaç bin gerçek istekte embedding mesafesi ile cevap eşdeğerliğini karşılaştırın. 0.08, 0.12 ve 0.16 gibi eşikler için yanlış hit oranı, hit ratio ve p95 gecikmeyi tabloya yazın. Eşiği genel bir sabit olarak değil, sınıflandırma, özetleme ve RAG soru-cevap gibi görevler için ayrı seçin.

Kubernetes eğitimi sırasında minikube ile LLM cache nasıl test edilir?

Minikube'da API ve Redis'i ayrı Deployment olarak çalıştırın, `kubectl top pods` ile CPU ve bellek tüketimini izleyin, sonra `kubectl scale deployment llm-cache-api --replicas=3` uygulayın. Aynı tenant için hit oranını ve Redis bağlantı sayısını Prometheus'ta karşılaştırın. Pod sayısı artarken bağlantı havuzu sınırlandırılmamışsa cache katmanında bağlantı patlamasını gözlemleyebilirsiniz.

Terraform ve infrastructure as code ile LLM cache alarmı nasıl yönetilir?

Redis bellek politikası, private network erişimi, alarm eşiği ve dashboard tanımını aynı Terraform modülünde sürümleyin. CI aşamasında `terraform fmt -check`, `terraform validate` ve plan incelemesi çalıştırın. Cache hit p95 için alarmı model çağrısı p95 alarmından ayrı tutun; aksi halde Redis sorunu ile model sağlayıcısı gecikmesi tek alarmda birleşir.