Bağlam Mühendisliği Nedir? Prompt Mühendisliğinin Ötesi

Bağlam mühendisliği nedir?

Bağlam mühendisliği, bir yapay zeka modelinin her adımda gördüğü bilgiyi, yani talimatı, konuşma geçmişini, araç sonuçlarını, getirilen belgeleri ve belleği bilinçli biçimde seçip düzenleme disiplinidir. Amaç, modele doğru bilgiyi doğru zamanda ve mümkün olan en az gürültüyle vermektir.

Peki bağlam mühendisliği nedir sorusunu günlük dille nasıl anlatırız? Modeli, önüne her seferinde yeni bir dosya konan bir uzman gibi düşünün. Dosyaya ne koyarsanız uzman onunla çalışır. Eksik koyarsanız tahmin yürütür, fazla ve dağınık koyarsanız asıl bilgiyi kaçırır.

Bu yüzden terim, tek bir cümlelik istemin çok ötesine geçer. Konu, modelin penceresine giren her şeydir: kurallar, önceki mesajlar, arama sonuçları, araç çıktıları ve kayıtlı notlar. Ekibimiz bu işi bir yazı sanatı olarak değil, bir tasarım ve mühendislik işi olarak görür.

Terim, ajanlar yaygınlaştıkça öne çıktı. Model tek soruya cevap vermek yerine uzun görevleri yürütmeye başlayınca asıl iş değişti. Artık mesele cümleyi güzel yazmak değil, her turda pencereye ne gireceğini yönetmektir. Bu kayma, çalışan bir demo ile güvenilir bir ürün arasındaki farkın büyük kısmını oluşturur.

Bu yazıda kavramı sade bir dille açıyoruz. Önce bileşenlere, sonra ajanlardaki rolüne, en sonda da bir işletme chatbotu için kontrol listesine bakıyoruz.

Bağlam mühendisliği nedir ve prompt mühendisliğinden farkı nedir?

Prompt mühendisliği, modele verdiğiniz yazılı talimatı iyi kurmaya odaklanır. Bağlam mühendisliği ise bu talimatı da içine alan daha geniş bir sorudur: modelin bu adımda hangi bilgi yapılandırmasıyla en doğru davranışı göstereceği. Anthropic mühendislik ekibinin ajan bağlamı üzerine yazdığı belge iki kavramı tam olarak böyle ayırır.

Kısacası prompt mühendisliği bir bileşendir, bağlam mühendisliği ise bütün sistemdir. Yazım tekniklerini merak ediyorsanız prompt mühendisliği rehberimize bakabilirsiniz. Bu yazıda o teknikleri tekrar anlatmıyoruz.

Başka bir deyişle bağlam mühendisliği nedir sorusunun kısa cevabı şudur: modelin ne gördüğünü tasarlamak. Prompt mühendisliği bu tasarımın yalnızca yazı kısmını üstlenir. Veri akışı, bellek ve araçlar ise ayrı mühendislik kararları ister.

Bu tabloya bakınca bir şey netleşir. İyi yazılmış bir talimat, kötü seçilmiş bir bağlamı kurtarmaz. Tersine, iyi düzenlenmiş bir bağlam, vasat bir talimatı bile çoğu zaman taşır.

Bağlam mühendisliğinin bileşenleri nelerdir?

Bir modelin penceresine giren bilgiyi beş ana katmana ayırabilirsiniz. Her katmanın kendi ömrü, kendi riski ve kendi bakım yöntemi vardır. Bu ayrım, hata ararken size sistematik bir harita verir.

• Sistem talimatı: Modelin rolünü, sınırlarını ve ton kurallarını tanımlar.
• Konuşma geçmişi ve kısa süreli bellek: Oturum içinde söylenenleri taşır.
• Uzun süreli bellek: Oturumlar arasında saklanan kullanıcı tercihlerini veya notları taşır.
• Getirilen belgeler: RAG gibi yöntemlerle dışarıdan çekilen parçalardır.
• Araç çıktıları ve yapılandırılmış durum: Bir API yanıtı, bir sorgu sonucu veya görevin o anki durum kaydıdır.

Katmanların ömrü birbirinden farklıdır. Sistem talimatı haftalarca aynı kalabilir, konuşma geçmişi ise her mesajda uzar. Araç çıktısı bir adım için anlamlıdır ve sonra çöpe dönüşebilir. Örneğin bir sipariş sorgusunun ham yanıtı, cevap verildikten sonra pencerede yer tutmaktan başka işe yaramaz.

Ayrıca bu katmanların hepsi aynı pencereyi paylaşır. Dolayısıyla birine yer açmak, diğerinden yer almak demektir. Bağlam mühendisliği bu paylaşımı bilinçli yönetme işidir.

Sistem talimatı bağlamda nasıl bir rol oynar?

Sistem talimatı, bağlamın en kalıcı parçasıdır. Modelin kim olduğunu, neyi yapıp neyi yapmayacağını ve hangi kaynaklara güveneceğini söyler. Her adımda yeniden okunduğu için kısa, net ve çelişkisiz olması gerekir.

Çok uzun bir talimat iki sorun üretir. Birincisi, kuralların birbiriyle çatışma ihtimali artar. İkincisi, modelin dikkati önemsiz ayrıntılara dağılır. Anthropic'in belgesi de talimatın aşırı ayrıntılı ve kırılgan olmaması, ama belirsiz de kalmaması gerektiğini vurgular.

Talimatta olumsuz kural yığmak da riskli bir alışkanlıktır. "Şunu yapma" listesi uzadıkça model neyin serbest olduğunu çıkarmakta zorlanır. Bunun yerine istenen davranışı olumlu cümlelerle tarif edin ve sınırları kısa tutun.

Pratikte şu yaklaşımı öneriyoruz: Talimatı bölümlere ayırın, her bölüme tek bir iş verin. Örneğin rol, sınırlar, ton ve çıktı biçimi ayrı başlıklar olsun. Böylece bir kuralı değiştirdiğinizde diğerlerini bozmazsınız.

Kısa ve uzun süreli bellek bağlamda nasıl çalışır?

Kısa süreli bellek, o anki konuşmanın geçmişidir. Model aslında önceki mesajları kendiliğinden hatırlamaz. Uygulamanız her istekte geçmişi yeniden gönderir. OpenAI'ın konuşma durumu belgesi bu yaklaşımı ve alternatiflerini anlatır.

Uzun süreli bellek ise oturumlar arası bilgiyi saklar. Örneğin kullanıcının tercih ettiği dil ya da önceki sipariş notu bu katmanda durur. Google'ın ajan geliştirme kitinin belgeleri de durum, bellek ve dosya referanslarını ayrı kavramlar olarak ele alır.

Bellek kayıtları zamanla yanlış da olabilir. Kullanıcı adresini değiştirdiyse eski adres hâlâ bellekte duruyorsa, model eski bilgiyi güvenle kullanır. Bu nedenle bellekte güncelleme ve silme mantığı da tasarlamanız gerekir.

Burada kritik karar, neyin belleğe yazılacağıdır. Her şeyi saklarsanız bellek de şişer. Bu nedenle yalnızca ileride gerçekten işe yarayacak bilgiyi, açık bir kuralla kaydedin. Kişisel veri içeren notlarda saklama süresini ve silme yolunu baştan düşünün.

Getirilen belgeler ve araç çıktıları bağlama nasıl girer?

Şirket belgeleri, ürün kataloğu ya da yardım makaleleri modelin eğitiminde yoktur. Bu yüzden uygulamanız ilgili parçaları bulup bağlama ekler. Bu işin ana yöntemi RAG (retrieval augmented generation) yaklaşımıdır. Belgeleri nasıl parçalayacağınız ise chunking yazımızın konusudur.

Araç çıktıları da aynı şekilde pencereye girer. Model bir araç çağırdığında, dönen sonuç sonraki adımın girdisi olur. Function calling bu mekanizmayı anlatır. Uzun bir tablo ya da ham JSON döndüren araç, bağlamı hızla doldurur.

Belge parçalarının sayısı da bir karardır. Örneğin her soruya çok sayıda parça eklemek güvenli görünür, ama çoğu zaman gürültü getirir. Birkaç alakalı parça, çok sayıda yarı alakalı parçadan daha iyi sonuç verir. Bu dengeyi kendi verinizle deneyerek bulursunuz.

Bu nedenle araç çıktısını mümkün olduğunca sadeleştirin. Modelin ihtiyaç duymadığı alanları kesin, uzun listelerde yalnızca ilk sonuçları ya da özet alanları döndürün. Ayrıca yapılandırılmış çıktı kullanırsanız her adımın girdisini öngörülebilir tutarsınız.

Bağlam mühendisliği nedir, ajanlarda neden kritik hale gelir?

Tek soru, tek cevap düzeninde bağlam küçüktür ve yönetmesi kolaydır. Ajanlar ise bir hedefe ulaşmak için birçok adım atar. Her adımda araç çağırır, sonuç okur, plan değiştirir. Dolayısıyla bağlam her turda büyür.

Bu büyüme kontrol edilmezse üç şey olur. Önce eski ve işe yaramayan çıktılar pencerede yer kaplar. Sonra model, yeni görevle ilgisiz ayrıntılara dikkat harcar. En sonunda maliyet ve gecikme artar, çünkü her tur daha fazla girdi işler.

Ajanların birbiriyle nasıl konuştuğu da bağlam kararlarını etkiler. A2A protokolü yazımızda bu iletişimin standardını anlattık. Bir ajan diğerine görev devrederken ne kadar bilgi aktaracağı, tam olarak bir bağlam mühendisliği sorusudur.

Bağlam mühendisliği nedir sorusuna ajan gözüyle bakarsanız cevap şudur: her turda modele hangi bilginin gideceğini planlamak. Plan yoksa pencere kendiliğinden dolar ve kalite düşer. Planı olan sistem ise uzun görevlerde bile tutarlı kalır.

Bir ajanın hatasını incelerken sık görülen bir tablo vardır. İlk üç adım düzgün gider, onuncu adımda ajan hedefi unutur. Çoğu zaman model bozulmamıştır. Pencere, eski denemelerin ve gereksiz çıktıların yığınıyla dolmuştur.

Ajan geliştirme işi yapıyorsanız AI agent geliştirme çözümümüz bu tür tasarım kararlarını kapsar.

Bağlam şişmesi ve alakasız bilgi neden sorun yaratır?

Bağlam şişmesi, pencerenin gereğinden fazla ve düşük değerli bilgiyle dolmasıdır. Anthropic'in belgesi buna bağlı bir olguyu anlatır: pencere büyüdükçe modelin bilgiyi geri çağırma başarısı düşebilir. Belge bunu modelin sınırlı bir dikkat bütçesi olmasıyla açıklar.

Alakasız bilgi ayrıca yanıltıcı olabilir. Örneğin kullanıcı kargo sorarken pencerede iade politikasının uzun bir metni varsa, model yanlış belgeden cevap üretebilir. Bu tür hatalar çoğu zaman halüsinasyon olarak görünür ama kök neden bağlamdır.

Dikkati dağıtan bilgi her zaman yanlış olmak zorunda değildir. Doğru ama o anki soruyla ilgisiz bilgi de modeli saptırabilir. Yani sorun içeriğin kalitesi kadar, yerinde olup olmamasıdır.

Çelişkili bilgi de aynı ailedendir. Eski ve yeni fiyat listesi aynı anda pencerede duruyorsa model hangisine güveneceğini bilemez. Çözüm basit ama disiplin ister: eskiyen bilgiyi pencereden çıkarın ve her belgeye bir güncellik etiketi koyun.

• Aynı bilgiyi birden fazla yerde tekrar etmeyin.
• Eskimiş araç çıktılarını sonraki turlarda silin ya da özetleyin.
• Çelişkili kaynakları pencereye birlikte koymayın.
• Her belge parçasına kaynak ve tarih bilgisi ekleyin.

"Lost in the Middle" bulgusu bağlam mühendisliğine ne söyler?

Stanford ve diğer kurumlardan araştırmacıların yazdığı "Lost in the Middle" makalesi, uzun girdilerde modellerin bilgiyi nasıl kullandığını inceler. Makalenin özeti, ilgili bilginin girdinin başında ya da sonunda olduğunda performansın genellikle daha yüksek olduğunu söyler. Ortada kalan bilgi ise daha zor kullanılır.

Bu bulgu, uzun pencereli modellerde bile yerleşimin önemli olduğunu gösterir. Sonuçlar belirli modellerle ve belirli görevlerle ölçüldü. Bu yüzden bugünkü bir modelin davranışını aynen bu makaleye bağlamak doğru olmaz. Yine de yönü işe yarar bir ipucudur.

Pratik çıkarım şudur: En kritik kuralı ve en önemli kanıtı pencerenin başına ya da sonuna yaklaştırın. Çok sayıda belgeyi sıradan yığmak yerine, en alakalı olanları önde tutun. Sıralama için reranker yazımıza göz atabilirsiniz.

Uzun bir belgeyi tek parça halinde vermek yerine, bölümlere ayırıp ilgili olanı öne almak da işe yarar. Böylece hem yerleşim sorununu hafifletir hem de modelin okuyacağı metni kısaltırsınız.

Her zaman kendi verinizle deneyin. Aynı soruyu, kanıtın farklı konumlarda olduğu iki düzenle sorun ve sonucu karşılaştırın.

Statik ve dinamik bağlam arasındaki fark nedir?

Statik bağlam, işe başlamadan pencereye koyduğunuz bilgidir. Sistem talimatı ve sabit kurallar buna girer. Dinamik bağlam ise görev ilerledikçe ihtiyaç duyulduğunda çekilen bilgidir. Anthropic'in belgesi bu yaklaşıma tam zamanında getirme (just-in-time retrieval) der.

Fikir basittir: her şeyi baştan yüklemek yerine hafif tanımlayıcılar tutarsınız. Bunlar dosya yolu, bağlantı ya da kayıtlı sorgu olabilir. Model gerekince ilgili veriyi kendisi çağırır. Böylece pencere yalnızca o anki işin ihtiyacını taşır.

Bunun bir bedeli vardır. Dinamik getirme ek adım ve ek gecikme demektir. Ayrıca modelin doğru aracı ve doğru sorguyu seçebilmesi gerekir. Bu yüzden iki yaklaşımı çoğu zaman birlikte kullanırsınız: kritik kurallar statik, ayrıntılı veriler dinamik olur.

Hangisini seçeceğinize veri hacmi ve cevap süresi beklentisi karar verir. Küçük ve sabit bir yardım merkezinde statik yükleme yeterli olabilir. Büyük ve sık değişen bir katalogda dinamik getirme daha mantıklıdır.

Gerçek bir müşteri destek senaryosunda bağlam mühendisliği nasıl görünür?

Aşağıdaki durum bir örnek senaryodur, gerçek bir müşteri vakası değildir. Bir e-ticaret firmasının chatbotu iade soruları yanıtlıyor olsun. İlk sürümde tüm politika belgeleri, tüm sipariş geçmişi ve uzun bir talimat her mesajla birlikte pencereye giriyor.

Sonuç tahmin edilebilir. Cevaplar yavaşlıyor, maliyet artıyor ve model bazen eski iade koşulunu söylüyor. Ekip sorunu modelde arıyor, oysa sorun pencerenin düzenindedir.

İkinci sürümde ekip üç değişiklik yapıyor:

1. Talimat dört kısa bölüme ayrılıyor ve çelişkili kurallar siliniyor.
2. Politika belgeleri yalnızca soruyla ilgili parçalar olarak getiriliyor.
3. Sipariş aracı yalnızca durum, tarih ve ürün adı alanlarını döndürüyor.

Bu değişikliklerden sonra pencere küçülür ve cevaplar daha tutarlı hale gelir. Yine de bunu varsayım olarak değil, sabit bir test setiyle doğrulamak gerekir. Her işletmenin verisi farklıdır, bu yüzden sonuçlar değişebilir.

Özetleme ve sıkıştırma bağlamı nasıl hafifletir?

Uzun bir görevde pencere dolmaya yaklaşınca iki temel seçeneğiniz vardır. Ya eski adımları atarsınız ya da özetlersiniz. Anthropic'in belgesi bu fikre sıkıştırma (compaction) der: konuşmayı özetleyip özetle yeni bir pencere başlatmak.

İyi bir özet neyi korur? Alınan kararları, çözülmemiş sorunları ve kullanıcının açık isteklerini. Neyi atar? Tekrarlayan araç çıktılarını ve çıkmaz yola girmiş denemeleri. Özetin kalitesi düşükse model kritik bir ayrıntıyı sessizce kaybedebilir.

İkinci yöntem yapılandırılmış not tutmaktır. Ajan, ilerlemesini pencerenin dışında bir not alanına yazar ve gerektiğinde geri okur. Üçüncü yöntem ise alt ajanlardır: her biri temiz bir pencerede çalışır ve yalnızca kısa bir sonuç döndürür.

1. Pencere doluluğunu ölçün ve bir eşik belirleyin.
2. Eşik aşılınca özet üretin ve özeti kendi kontrol sorularınızla test edin.
3. Kritik kararları ve kullanıcı taleplerini özetin başına koyun.
4. Ham çıktıyı kaybetmek istemiyorsanız dışarıda saklayın ve gerektiğinde yeniden çağırın.

Bağlam mühendisliği bağlam penceresi ile nasıl ilişkilidir?

Modelin tek bir istekte işleyebildiği toplam bilgi sınırına bağlam penceresi denir. Bağlam mühendisliği ise bu sınırın içine neyi koyacağınıza karar verme işidir. Yani pencere kap, bağlam mühendisliği içindekilerin seçimidir. Kavramın kendisi için bağlam penceresi yazımıza bakabilirsiniz.

OpenAI'ın belgesi, pencerenin girdi, çıktı ve akıl yürütme belirteçlerinin toplamını kapsadığını söyler. Dolayısıyla pencereyi tamamen girdiyle doldurursanız cevaba yer kalmaz. Belirteç hesabını token yazımızda ayrıntılı anlattık.

Pencerenin büyük olması, bağlamı umursamamanız için bir gerekçe değildir. Büyük pencere daha fazla alan sağlar, ama dikkat dağılması ve maliyet sorunlarını ortadan kaldırmaz. Güncel pencere boyutunu sağlayıcının resmi belgesinden kontrol edin.

Bağlam mühendisliği ile prompt caching arasında nasıl bir bağ var?

Prompt caching, istekler arasında değişmeyen girdi parçasını yeniden işlemek yerine önbellekten kullanma yaklaşımıdır. Ayrıntıları prompt caching yazımızda bulabilirsiniz. Önbellekten yararlanmanın şartı, bağlamın kararlı bir düzende kurulmasıdır.

Maliyet konusunda dikkat edilecek bir nokta daha var. Girdi ne kadar büyükse her tur o kadar pahalıdır. Bağlamı sadeleştirmek hem hız hem bütçe kazandırır. Böylece kalite ve maliyet çoğu zaman aynı yönde iyileşir.

Bu nedenle bağlam tasarımı doğrudan maliyeti etkiler. Değişmeyen parçaları, yani sistem talimatını ve sabit referansları başa koyarsınız. Sık değişen parçaları, yani kullanıcı mesajını ve yeni araç sonuçlarını sona eklersiniz. Sıra sürekli değişirse önbellek faydası azalır.

Ayrıntı sağlayıcıya göre değişir. Hangi parçanın, ne kadar süreyle ve hangi koşulda önbelleğe alındığını sağlayıcının resmi belgesinden kontrol edin. Burada rakam vermiyoruz, çünkü bu değerler zamanla değişir.

Bağlam mühendisliği RAG, MCP ve function calling ile nasıl karşılaştırılır?

Bu terimler sık karıştırılır, çünkü hepsi modele bilgi taşımayla ilgilidir. Fark şudur: bağlam mühendisliği hepsini yöneten üst çerçevedir. Diğerleri bu çerçevenin içindeki mekanizmalardır.

Bağlantı standardı için MCP yazımızı, arama altyapısı için embedding yazımızı okuyabilirsiniz. Bu yazıda onları yalnızca bağlamla ilişkileri kadarıyla andık.

Bağlam mühendisliği ne zaman gerekir?

Basit, tek adımlı bir görevde dikkatli bir talimat çoğu zaman yeter. Örneğin bir metni özetlemek ya da bir e-postayı yeniden yazmak için ayrı bir bağlam tasarımı yapmazsınız. Ancak sistem büyüdükçe ihtiyaç belirginleşir.

Şu işaretler bağlam mühendisliği zamanının geldiğini gösterir:

• Chatbotunuz uzun konuşmalarda ilk söylenenleri unutuyor veya birbirine karıştırıyor.
• Aynı soruya farklı gün farklı kalitede cevap alıyorsunuz.
• Ajanınız birkaç adım sonra hedeften sapıyor.
• API maliyetiniz kullanım artışından hızlı büyüyor.
• Şirket belgelerinden yanıt verirken yanlış belgeyi kaynak gösteriyor.

Ayrıca birden fazla araç ve veri kaynağı bağladığınızda ihtiyaç hızla artar. Örneğin hem takvime, hem stok sistemine, hem belgelere erişen bir asistan, her kaynaktan gelen çıktıyı yönetmek zorundadır.

Bu belirtilerden ikisi veya daha fazlası varsa modeli değiştirmeden önce bağlamı inceleyin. Çoğu zaman sorun modelde değil, modele verdiğiniz bilgidedir.

İşletme chatbotu için bağlam mühendisliği kontrol listesi nedir?

Bir müşteri destek chatbotu veya şirket içi bilgi asistanı kuruyorsanız aşağıdaki listeyi başlangıç noktası olarak kullanabilirsiniz. Bu liste bir örnek çerçevedir. Sektörünüze ve veri yapınıza göre uyarlamanız gerekir.

1. Sistem talimatını bölümlere ayırın ve çelişkili kuralları temizleyin.
2. Chatbotun cevap vermeyeceği konuları ve devir kuralını açıkça yazın.
3. Hangi bilginin oturum belleğinde, hangisinin kalıcı bellekte duracağına karar verin.
4. Kişisel veri içeren notlar için saklama süresi ve silme yolu belirleyin.
5. Belge kaynaklarını güncellik etiketiyle işaretleyin ve eskiyenleri çıkarın.
6. Her cevaba kaynak belgeyi iliştirin, böylece denetim kolaylaşır.
7. Araç çıktılarını sadeleştirin, yalnızca gerekli alanları döndürün.
8. Uzun konuşmalar için özetleme eşiği ve özet testi tanımlayın.
9. Her adımın girdi büyüklüğünü ve maliyetini kaydedin.
10. Gerçek soru örnekleriyle düzenli test yapın ve sonuçları karşılaştırın.

Chatbot projesi planlıyorsanız AI chatbot geliştirme çözümümüz bu tür bir kurulumu kapsar.

Bağlam mühendisliğinde sık yapılan hatalar nelerdir?

Ekiplerin en sık düştüğü hata, "daha çok bilgi daha iyi cevap demektir" varsayımıdır. Oysa fazla bilgi dikkati dağıtır ve maliyeti artırır. Bu yüzden pencereyi doldurmak değil, ihtiyacı karşılayan en küçük bilgi kümesini bulmak hedeftir.

İkinci hata, bağlamı bir kez kurup unutmaktır. Ürün kataloğu, politika metni ve fiyatlar değişir. Bağlam kaynakları değişmezse model eski bilgiyle cevap vermeye devam eder.

• Talimatı sürekli büyütüp kuralları birbirine karıştırmak.
• Araçtan dönen ham çıktıyı olduğu gibi pencereye basmak.
• Konuşma geçmişini hiç özetlemeden uzatmak.
• Hangi bilginin hangi katmandan geldiğini kaydetmemek.
• Test etmeden yeni bir belge kaynağı eklemek.

Bir diğer hata, farklı kullanıcıların verisini aynı bağlamda karıştırmaktır. Oturum sınırlarını net çizmezseniz bir müşterinin bilgisi diğerinin cevabında görünebilir. Bu hem kalite hem gizlilik sorunudur.

Son olarak, hata ayıklarken yalnızca çıktıya bakmak yetmez. Modelin o adımda tam olarak ne gördüğünü kaydetmeniz gerekir. Girdiyi görmeden nedenini bulmak neredeyse imkânsızdır.

Bağlam kalitesini nasıl test eder ve ölçersiniz?

Bağlam değişikliklerini sezgiyle değil, sabit bir test setiyle değerlendirin. Gerçek müşteri sorularından oluşan kısa bir liste hazırlayın ve beklenen cevabın özelliklerini yazın. Her değişiklikten sonra aynı listeyi çalıştırın.

Değerlendirme yöntemleri için LLM evals yazımıza bakabilirsiniz. Orada otomatik ve model destekli değerlendirmenin sınırlarını da anlattık.

Ayrıca üç göstergeyi izlemenizi öneririz. Birincisi doğruluk, yani cevabın kaynağa uyup uymadığı. İkincisi tutarlılık, yani aynı soruya benzer cevap verip vermediği. Üçüncüsü verimlilik, yani cevap başına girdi büyüklüğü ve gecikme.

Test setine zor örnekler de ekleyin. Belirsiz sorular, çelişkili belgeler ve kapsam dışı istekler bağlam hatalarını en çabuk ortaya çıkarır. Yalnızca kolay sorularla yapılan test sizi yanıltır.

Böylece bir iyileştirmenin gerçekten iyileştirme olup olmadığını görürsünüz. Örneğin bağlamı küçülttüğünüzde maliyet düşerken doğruluk da düşüyorsa, kestiğiniz parça işe yarıyormuş demektir.

Bağlam mühendisliğinin riskleri ve sınırları nelerdir?

Birinci risk güvenliktir. Dışarıdan çekilen bir belge ya da web sayfası, modele talimat gibi görünen metin taşıyabilir. Bu sorun prompt injection yazımızın konusudur. Bağlama giren dış içeriği her zaman güvenilmez veri olarak ele alın.

İkinci risk gizliliktir. Bellekte ve bağlamda müşteri verisi dolaşıyorsa, bunun kimin görebileceğini ve ne kadar süre saklanacağını belirlemeniz gerekir. Kişisel veri ve telif konularında bu yazı hukuki danışmanlık değildir. Kendi durumunuz için uzmana danışın.

Üçüncü sınır, bağlam mühendisliğinin sihirli bir çözüm olmamasıdır. İyi düzenlenmiş bağlam hataları azaltır ama sıfırlamaz. Model yine de yanılabilir. Bu yüzden kritik kararlarda insan onayı ve koruma katmanları gerekir.

Bağlam mühendisliğine ekibinizle nereden başlarsınız?

Önce hedefi netleştirin. Chatbot hangi soruları cevaplamalı, hangilerini insana devretmeli? Bu sınır belli değilse hangi bilginin pencereye gireceğine de karar veremezsiniz. Sınırı yazılı hale getirmek, bağlam tasarımının ilk adımıdır.

Küçük başlayın. Tek bir kullanım senaryosu seçin, örneğin müşteri destek chatbotu. Mevcut durumda modelin her adımda ne gördüğünü kaydedin. Çoğu ekip bu kaydı ilk kez gördüğünde şaşırır, çünkü pencerede beklemediği kadar çok gereksiz bilgi bulur.

Sonra sorunları sıraya koyun. Örneğin önce şişmiş araç çıktılarını sadeleştirin, ardından belge güncelliğini düzeltin, en sonda özetleme ekleyin. Her adımda aynı test setini çalıştırın.

Bu işi kurumsal ölçekte yapmak istiyorsanız Talha Aslan ve ekibi olarak yapay zeka danışmanlığı ve entegrasyonu konusunda destek veriyoruz. Yapay zeka danışmanlığı sayfamızdan ayrıntıya ulaşabilirsiniz.

Özetle bağlam mühendisliği nedir sorusunu bir kez cevapladıktan sonra, onu bir süreç olarak işletmeniz gerekir. Kaynakları sahiplenin, değişiklikleri test edin ve pencere büyüklüğünü düzenli izleyin. Bu üç alışkanlık, çoğu projede en büyük farkı yaratır.

Bu süreçte ekip içi bir rol de belirlemek faydalıdır. Bağlam kaynaklarının sahibi kim, belgeleri kim güncelliyor, test sonuçlarını kim okuyor? Sahibi olmayan bağlam zamanla çürür.

Güncel model, pencere ve fiyat bilgilerini her zaman sağlayıcının resmi belgesinden kontrol edin. Bu yazı kavramı anlatır, sürüme bağlı rakam vermez.