Bağlam Mühendisliği (Context Engineering) Nedir?

Bağlam mühendisliği (context engineering), bir dil modelinin cevap verirken gördüğü her şeye karar verme işidir: sadece yazdığın soruya değil, etrafındaki talimatlara, içine eklenen belgelere ve araç sonuçlarına, kullanıcı hakkında kayıtlı hafızaya ve o ana kadarki sohbete. Hepsi tek bir bağlam penceresini paylaşır ve model o metinden cevap verir, başka hiçbir şeyden değil. Terim 2025'te, daha fazla yapay zekâ ürünü bağlamının çoğunu otomatik olarak bir araya getiren ajanlara dönüştükçe yaygınlaştı.

Prompt mühendisliği çoğunlukla bir isteğin nasıl ifade edileceğiyle ilgilidir. Bağlam mühendisliği ise her çağrıda modelin önünde neyin, hangi sırayla olması gerektiğiyle ilgilidir.

Bir prompttan bir bağlama

Bir sohbet uygulamasında bağlamın çoğunu kendin yazarsın: uygulama bir sistem promptu ve geçmişi ekler, gerisini sen eklersin. Bir uygulamada denge tersine döner. Kullanıcı tek bir cümle yazar ve modelin etrafındaki kod talimatları, bir kullanıcı profilini, aramayla bulunmuş üç yardım makalesini, kullanılabilir araçların listesini ve son araç çağrısının çıktısını ekler. Kullanıcının cümlesi modelin okuduğu şeyin küçük bir kısmı olabilir.

Böyle bir sistem kötü cevap verdiğinde çözüm nadiren ifadededir. Olağan sebep, modelin elinde yanlış malzeme olmasıdır: eksik bir bilgi, güncelliğini yitirmiş bir araç sonucu, aramaya ilgili görünen ama alakasız bir belge.

Bağlam penceresine neler girer

Bir yapay zekâ uygulamasındaki tipik bir çağrı bunların bir kısmını ya da hepsini, kabaca şu sırayla içerir:

• Sistem talimatları: rol, kurallar ve çıktı biçimi, genellikle bütün uygulama için sabit. Bkz. sistem promptu.
• Araç tanımları: modelin çağırabileceği araçların adları, açıklamaları ve parametreleri.
• Örnekler: beklenen davranışı gösteren birkaç örnek girdi ve çıktı.
• Hafıza: kullanıcının planı, dili ya da tercihleri gibi önceki oturumlardan kaydedilmiş bilgiler.
• Getirilen belgeler: bu soru için bir bilgi tabanında arama yapılarak bulunan pasajlar (retrieval-augmented generation, yani RAG).
• Sohbet geçmişi: önceki turlar, ya kelimesi kelimesine ya da özetlenmiş.
• Araç sonuçları: bu görev sırasında yapılan aramaların, kod çalıştırmaların ya da API çağrılarının çıktısı, bir ReAct döngüsündeki gibi.
• Mevcut mesaj: kullanıcının az önce sorduğu şey.

Aşağıdaki blok bir destek asistanı için bir araya getirilmiş bir bağlam. Parçaları tek tek kapat. Bağlam parçası olmadan model müşterinin planını bilemez; girdi parçası olmadan ürün bilgisi yoktur ve kısıtları ona tahmin etmek yerine bunu söylemesini söyler.

Bir destek asistanı için bağlam

EditCopy

PartsRoleConstraintsContextInputFormatTask

Role

Not alma uygulaması Acme Notes'un destek asistanısın.

Constraints

Sadece aşağıdaki belgelerden cevap ver. Belgeler soruyu kapsamıyorsa bunu söyle ve müşteriyi bir insanla görüştürmeyi teklif et. Özellikler ya da fiyatlar hakkında asla tahmin yürütme.

Context

Müşteri hafızası: adı Deniz, Free plan, Android uygulamasını kullanıyor.

Input

<document source="help/offline-mode"> Çevrimdışı mod Pro planda mevcuttur. Çevrimdışıyken oluşturulan notlar cihaz yeniden bağlandığında senkronize olur. 20 MB'tan büyük ekler çevrimdışı kullanılamaz. </document> <document source="help/plans"> Free plan: en fazla 3 cihaz. Pro plan: sınırsız cihaz, çevrimdışı mod, 30 günlük sürüm geçmişi. </document>

Format

Sade bir dille iki ile dört cümle. Müşteriye adıyla hitap et.

Task

Müşterinin sorusu: Uygulamayı uçakta internetsiz kullanabilir miyim?

Try it

Example replyReplies vary between models and runs.

Merhaba Deniz, çevrimdışı mod Pro planın bir parçası ve hesabın şu anda Free planda olduğu için bu özellik şu an senin için kullanılabilir değil. Pro ile uçuş sırasında oluşturduğun notlar telefonun yeniden bağlandığında otomatik olarak senkronize olur. Bilmen gereken bir sınır var: 20 MB'tan büyük ekler çevrimdışı kullanılamaz.

Doğru cevabın iki kaynağı birleştirmeye bağlı olduğuna dikkat et: hafıza (Free plan) ve bir belge (çevrimdışı mod sadece Pro'da). İkisi de tek başına yetmez ve bu tipiktir. Bağlam mühendisliğinin büyük kısmı, birbirine ihtiyaç duyan parçaların birlikte gelmesini sağlamaktır.

Bir bağlamın ters gitmesinin dört yolu

1. Eksik bilgi. Model boşlukları makul tahminlerle doldurur; birçok halüsinasyonun geldiği yer burasıdır. Bilgiyi ekle ya da modele bir bilgi eksik olduğunda ne yapacağını söyle.
2. Fazla malzeme. Alakasız her paragraf token harcar ve dikkat için yarışır. Liu ve arkadaşlarının 2023 tarihli "Lost in the Middle: How Language Models Use Long Contexts" makalesi, test ettikleri modellerin uzun bir girdinin başındaki ya da sonundaki bilgiyi ortasındakinden daha güvenilir şekilde kullandığını buldu. Yeni modeller uzun girdileri daha iyi işliyor, ama soruyu cevaplayan birkaç pasajı göndermek hâlâ bütün kılavuzu yapıştırmaktan daha ucuz ve modelin kullanması için daha kolay.
3. Bayat bilgi. On adım önceki bir araç sonucu o zamandan beri değişmiş bir dosyayı ya da bakiyeyi tarif ediyor olabilir. Model iki sürümü de görürse eskisini kullanabilir.
4. Çelişkiler. İki belge birbiriyle çelişir ya da hafıza bir şey, kullanıcı başka bir şey söyler. Modele hangi kaynağın kazandığını söyle, örneğin "kullanıcının son mesajı kayıtlı hafızanın önüne geçer".

Bağlamı sıralamak

Sıra hem sonuçları hem maliyeti değiştirir.

• Önce sabit kısımlar. Sistem talimatları, araç tanımları ve sabit referans malzemesi çağrılar arasında nadiren değişir. Birçok API sağlayıcısı, girdinin aynı başlangıcının işlenmesini yeniden kullanan prompt caching sunar, bu yüzden değişmeyen bir önek tekrarlanan çağrıları daha ucuz ve hızlı yapar.
• Sorudan önce uzun malzeme. Uzun bir belge ya da büyük bir pasaj seti için malzemeyi başa, soruyu ve son talimatları ondan sonraya koy. Örneğin Anthropic'in prompt rehberi uzun girdiler için soru modelin yazmaya başlamasından hemen önce olacak şekilde bu sırayı öneriyor.
• Her parçayı etiketle. Her kaynağı bir kaynak adıyla birlikte <document>, <memory> ya da <tool_result> gibi etiketlere sar. Etiketler modelin veriyi talimatlardan ayırmasını sağlar ve ondan bir cevabın nereden geldiğini belirtmesini istemene imkân verir. Biçimleri ayırıcılar ve XML etiketleri anlatır.

Uzun bir bağlamı kırpmak

Bir sohbetin her turu bütün geçmişi yeniden gönderir, bu yüzden uzun oturumlar bir şeyin gitmesi gerekene kadar büyür. Uygulamaya göre eski mesajları özetleyebilir, atabilir ya da yeni bir sohbet başlatmanı isteyebilir. Bilinçli olarak kırparsan daha iyi sonuç alırsın.

• Son birkaç turu kelimesi kelimesine tut, eskilerini bir özetle değiştir.
• Bir araç sonucu kullanıldıktan sonra onu neyi gösterdiğini anlatan tek satırlık bir notla değiştir.
• Her özette kesin tanımlayıcıları koru: dosya adları, fonksiyon adları, ID'ler, hata mesajları ve sayılar. Geçmişin settings.prod.yaml dediği yerde "yapılandırma dosyası" diyen bir özet, önemli olan tek ayrıntıyı kaybeder.
• Bir sohbet uygulamasında konuşma dağıldığında bir devir notuyla yeni bir sohbet başlat. Aşağıdaki prompt bir devir notu yazıyor.

Uzun bir sohbeti yeni bir başlangıca sıkıştır

EditCopy

Fill inprojekelime

Bu sohbet uzamaya başladı. Yeni bir sohbete yapıştırabileceğim, işin geçmiş olmadan devam etmesini sağlayacak bir devir notu yaz. Şunları dahil et: 1. Kayıt formunun yeniden düzenlenmesinin amacı, tek cümleyle. 2. Aldığımız kararlar ve her birinin nedeni. 3. Mevcut durum: ne çalışıyor, ne yarım kaldı. 4. Önemli olan kesin adlar: dosyalar, fonksiyonlar, hata mesajları, sayılar. Onları birebir kopyala. 5. Açık sorular ve sıradaki adım. Bir kararı açıklamıyorlarsa çıkmaz sokakları dışarıda bırak. En fazla 200 kelime.

Try it

Example replyReplies vary between models and runs.

Amaç: kayıt formundaki elle yazılmış kontrolleri hem tarayıcının hem sunucunun kullandığı tek bir ortak doğrulama şemasıyla değiştirmek.

Kararlar

1. SignupForm.tsx ve api/signup.ts tarafından import edilen tek bir şema dosyası, signupSchema.ts; böylece iki kural seti birbirinden kopamaz.
2. Hata mesajları kelimesi kelimesine aynı kalıyor, çünkü yardım merkezi onları alıntılıyor.

Mevcut durum

1. Tarayıcı doğrulaması şemayı kullanıyor ve SignupForm.test.tsx geçiyor.
2. Sunucu hâlâ api/signup.ts içindeki eski validateSignup() fonksiyonunu çağırıyor.

Kesin ayrıntılar: şifreler en az 8 karakter ve bir rakam içermeli. E-posta hata metni: "Please enter a valid email address."

Sıradaki adım: validateSignup() fonksiyonunu şemayla değiştirmek ve API testlerini çalıştırmak.

Açık soru: zaten kayıtlı bir e-posta 409 mu yoksa 400 mü döndürmeli?

Oturumlar arası hafıza

Hafıza, bir sohbetten daha uzun yaşayan bağlamdır: bir oturumun sonunda depolamaya yazılan ve bir sonrakine yüklenen bilgiler. Sohbet uygulamaları bunun kayıtlı hafızalar ya da bir projedeki her sohbete eklenen proje talimatları gibi sürümlerini sunar. Kendi uygulamanda hafıza, kodunun okuyup eklediği bir tablo ya da not dosyasıdır. İki kural onu faydalı tutar: dökümleri değil, doğru kalan bilgileri sakla (plan, dil, tercih edilen teknoloji yığını); ve sadece mevcut görevle ilgili olanı yükle, çünkü hafıza diğer her şeyle aynı alan için yarışır.

Bağlamı kodda bir araya getirmek

Bir uygulamada bağlam mühendisliği sıradan koddur. Anthropic Python SDK'sıyla yazılmış bu taslak sabit kuralları ve hafızayı sistem promptuna koyuyor, sadece yakın geçmişi tutuyor ve etiketli belgeleri sorudan önce yerleştiriyor.

import anthropic

client = anthropic.Anthropic()
MODEL = "your-model-id"  # e.g. from your provider's model list

def build_context(question, docs, history, memory, max_messages=6):
    documents = "\n".join(
        f'<document source="{d["source"]}">\n{d["text"]}\n</document>' for d in docs
    )
    system = (
        "You are the support assistant for Acme Notes. Answer only from the documents. "
        "If they do not cover the question, say so.\n"
        f"<memory>\n{memory}\n</memory>"
    )
    # history holds complete user/assistant pairs, so an even slice starts with a user turn
    recent = history[-max_messages:]
    user = f"<documents>\n{documents}\n</documents>\n\n{question}"
    return system, recent + [{"role": "user", "content": user}]

# question, docs, history and memory come from your application
system, messages = build_context(question, docs, history, memory)
response = client.messages.create(model=MODEL, max_tokens=1024, system=system, messages=messages)
print(response.content[0].text)

O fonksiyondaki her karar (hangi belgeler, kaç mesaj, hafızanın nereye gittiği) bir bağlam mühendisliği seçimidir ve her biri, ifadedeki bir değişikliği test edeceğin şekilde gerçek sorularla test edilmeye değer.