Skip to content

Context'in 6 Katmanı: Bir LLM Çağrısının Anatomisi

Production LLM uygulamalarında context 6 standart katmandan oluşur: system, tools, RAG, history, user query, output schema. Bu derste her katmanın amacını, token bütçesini ve caching açısından önemini öğreneceksin.

Şükrü Yusuf KAYA
14 min read
Intermediate

Context'in 6 Katmanı

Bir LLM çağrısının context'i kaotik bir bilgi yığını değil; mühendis tasarımıyla 6 katmanlı yapı. Her katmanın amacı, davranışı ve caching karakteristiği farklı.

Katman 1 — System Prompt#

Amacı: Modelin kim olduğunu ve nasıl davranacağını söyler.
İçerir:
  • Persona ("Sen bir bankacılık asistanısın")
  • Tone of voice ("Resmi ve net konuş")
  • Domain kuralları ("KVKK kapsamında PII açıklama")
  • Output format genel kuralları ("Markdown kullan")
  • Knowledge base (bazı mimarilerde burada)
Boyut: 500 token - 50K token (KB dahilse büyür)
Değişim hızı: Haftalık (instructions) veya aylık (KB)
Caching: Mutlak gerekli. En statik katman.
Türkçe örnek:
Sen XYZ Bankası'nın müşteri hizmetleri asistanısın.
Görevin müşterilere bankacılık sorularında yardım etmek.

Kurallar:
1. PII (TCKN, hesap no) doğrulamadan paylaşma
2. Türkçe yanıt ver
3. Net ve saygılı ol
4. Şüpheli işlem → escalate_to_human tool'u çağır

Katman 2 — Tools (Function Definitions)#

Amacı: Modelin dış dünyaya erişim kapısı.
İçerir:
  • Tool isimleri (
    search_orders
    ,
    track_shipment
    )
  • Tool description'ları (modele ne için kullanacağını anlatır)
  • Input schemas (JSON Schema formatında parametre tanımları)
Boyut: 1K - 30K token (5-50 tool)
Değişim hızı: Aylık-3 aylık (kod release'le)
Caching: Mutlak gerekli. Modül 4 Ders 28'de detaylandık.
Önemli: Tools her zaman tüm liste; sub-setting yapılırsa cache miss kalır.

Katman 3 — RAG Context (Retrieved Documents)#

Amacı: Sorguya dinamik bilgi sağlama.
İçerir:
  • Vector DB'den retrieve edilmiş alakalı doc'lar
  • Her doc 200-2000 token civarı
  • Genelde 3-10 doc
Boyut: 2K - 50K token
Değişim hızı: Her sorguda farklı
Caching: Çok zor (her sorgu farklı). Çözüm:
  • Statik kısımları cache, dinamik retrieval ayrı (Modül 7'de detaylı)
  • Veya: top-K cache (en sık kullanılan doc'lar)
  • Veya: cache yok, retrieval direct
Modül 7 Hatırlatma
RAG katmanı en çok tartışılan. Modül 7'yi tamamen bu kısma ayırdık.

Katman 4 — Conversation History#

Amacı: Multi-turn diyalogda geçmiş bağlam.
İçerir:
  • User mesajları + assistant cevapları
  • Tool çağrıları + tool sonuçları
  • N-turn'lük geçmiş
Boyut: 0 - 100K token (uzun konuşmada büyür)
Değişim hızı: Her turn yeni ekleme
Caching: Incremental — her turn'de cache prefix uzar. Modül 8'de.
Önemli kural: Eski mesajları silme; summarize et. Truncation cache'i kırar.

Katman 5 — User Query#

Amacı: Aktif kullanıcı isteği.
İçerir:
  • Kullanıcının şu anki mesajı
  • Bazen attach edilmiş dosyalar
  • Mode/locale belirteçleri
Boyut: 10 token - 5K token (genelde küçük)
Değişim hızı: Her istek farklı
Caching: ASLA cache. Bu zaten dinamik kısım.
Pattern: Statik kısımdan SONRA gelecek. Prompt'un en sonunda.

Katman 6 — Output Schema#

Amacı: Modelin nasıl cevap vereceğini kısıtlama.
İçerir:
  • JSON schema (structured output)
  • Format örnekleri
  • "Sadece şu alanları doldur" kısıtlamaları
Boyut: 100 - 2K token
Değişim hızı: Sabit (kod release'le)
Caching: Genelde system'in parçası olarak cache; ayrı katman olmasa da output validation için önemli.
Modern alternatif: Provider'ın native structured output API'leri (OpenAI's response_format, Anthropic's tool_use as structured output). Bunlar context'e token eklemeden tipini zorlar.

6 Katman Birarada — Token Budget Örnek#

Tipik bir production asistanın context yapısı (200K Claude için):
KatmanToken% BütçeCaching
System (KB dahil)50.00025%✅ 1h TTL
Tools15.0007.5%✅ 1h TTL
RAG10.0005%⚠️ kısmen
History30.00015%✅ 5m TTL
User query2000.1%❌
Output schema5000.25%✅ system'le
Kullanılan105.70053%—
Output rezerv64.00032%—
Tampon30.00015%—
Total199.700100%—
Sağlıklı Bütçe
Bu tablo "sağlıklı bir 200K context budget'ı". Senin uygulaman bambaşka oranlarda olabilir — örnek: code asistanı %80 codebase + %5 history + %15 query/output. Önemli olan: bilinçli bütçe kararı.

✓ Pekiştir#

Bir Sonraki Derste#

Token budget allocation'ın detayına gireceğiz: hangi katmana ne kadar tahsis, neden, ve trade-off'lar.

Frequently Asked Questions

Evet, özelleştirebilirsiniz: 'cache breakpoint markers' ayrı bir katman olabilir, 'memory long-term' Vermillion gibi mimarilerde ayrı katman. Ama 6 katman 'standart' kabul ediliyor — çoğu sistem buna oturuyor.

Yorumlar & Soru-Cevap

(0)
Yorum yazmak için giriş yap.
Yorumlar yükleniyor...

Related Content

1. Temeller — Context Penceresi Ekonomisi

Bu Eğitim Hakkında ve Prompt Caching Neden Önemli?

Start Learning
1. Temeller — Context Penceresi Ekonomisi

Token Ekonomisi 101: Input vs Output Cost Asimetrisi

Start Learning
1. Temeller — Context Penceresi Ekonomisi

Context Window Evrimi: 4K'dan 1M'a 5 Yılda Ne Oldu?

Start Learning

Connected pillar topics

Pillar topics this article maps to

Pillar Topic

RAG (Retrieval-Augmented Generation) Architecture

RAG (Retrieval-Augmented Generation) is an architecture that grounds large-language-model answers in chunks retrieved from the organization's own documents or data sources, providing both freshness and citations.