- Tartışma, "prompt engineering"den bir adım ileri olan "context engineering"e kayıyor
- Context, yalnızca basit bir prompt cümlesi değil; LLM'in yanıt üretmeden önce görebildiği tüm bilgileri (talimatlar, konuşma geçmişi, uzun vadeli bellek, dış bilgi, kullanılabilir araçlar vb.) ifade eder
- Artık bir ajanının başarısı ya da başarısızlığı model performansından çok context kalitesine bağlı
- Gelişmiş ajanlar, kullanıcının takvimi, geçmiş e-postaları, kişileri ve benzeri çeşitli bağlamları birleştirerek gerçek problem çözümüne daha yakın yanıtlar üretir
- Context engineering, duruma özel dinamik sistem tasarımıdır; doğru bilgi ve araçların doğru anda LLM'e sunulması sürecidir
Context Engineering nedir?
- Son dönemde yapay zeka alanında "context engineering" terimi hızla yaygınlaşıyor
- Mevcut "prompt engineering" tek bir soru ya da komut cümlesi tasarlamaya odaklanırken, context engineering bundan daha geniş ve güçlü bir yaklaşım sunuyor
- Tobi Lutke bunu, "LLM'in bir işi güvenilir biçimde çözebilmesi için tüm context'i sağlama sanatı" olarak tanımlıyor
Context'in ana unsurları
- Bir ajan sisteminin başarılı çalışıp çalışmaması, büyük ölçüde çalışma belleğine (working memory) hangi bilgilerin dahil edildiğine bağlı
- Ajan başarısızlıklarının çoğu modelden değil, uygun context eksikliğinden kaynaklanıyor
Context'in bileşenleri
- Sistem promptu/talimatları: Modelin davranışını tanımlayan temel talimatlar, örnekler ve kurallar
- Kullanıcı promptu: Kullanıcının anlık isteği ya da sorusu
- Durum/konuşma geçmişi: O ana kadarki konuşma akışı ve bağlam bilgisi
- Uzun vadeli bellek: Çok adımlı önceki konuşmalar, kullanıcı tercihleri, geçmiş proje özetleri ve modelin uzun vadede hatırlaması için öğrenilmiş bilgiler kümesi
- RAG (arama tabanlı zenginleştirme): Harici belgeler, veritabanları, API'ler vb. kaynaklardan alınan güncel ve yüksek ilgili bilgi
- Kullanılabilir araçlar: Modelin çağırabileceği fonksiyonlar ve yerleşik araçların tanımları (
check_inventory, send_email vb.)
- Yapılandırılmış çıktı: Modelin uyması gereken yanıt biçiminin tanımı (ör. JSON)
Context neden önemlidir?
- Pratikte etkili yapay zeka ajanları oluşturmayı belirleyen unsur, karmaşık kod ya da model kalitesi değil, ne kadar uygun context sağlandığıdır
- Basit, "demo amaçlı" ajanlar yalnızca kullanıcı isteğini alıp temel yanıtlar verirken, "sihirli" ajanlar zengin context'i dikkate alarak çok daha faydalı ve insansı yanıtlar üretebilir
- Karşılaştırma
- Düşük kaliteli (demo) ajan: Yalnızca basit isteğe bakar ve kalıplaşmış yanıt üretir. Örn. "Yarın vaktiniz var mı?" e-postasına "Yarın uygunum. Saat kaç sizin için uygun?" gibi mekanik bir yanıt verir
- Yüksek kaliteli (sihirli) ajan: Kendi takvimini, geçmiş e-posta geçmişini, karşı tarafın kimlik bilgilerini ve gerekli araç çağırma seçeneklerini birlikte kullanarak doğal ve duruma uygun yanıt üretebilir. Örn. "Yarın takvimim dolu ama perşembe sabahı boşum, size bir davet gönderdim. Uygunsa haber verin"
- Yani burada önemli olan algoritma ya da modelin kendisi değil, işe uygun doğru context'in sağlanmasıdır
- Yapay zeka ajanlarının çoğu başarısızlığı, modelden değil context tasarımı başarısızlığından kaynaklanır
Prompt engineering'den context engineering'e evrim
- Prompt engineering tek satırlık metin talimatlarını optimize etmeye odaklanırken, context engineering çok daha geniş bir bilgi, araç ve yapısal tasarım alanını kapsar
- Context engineering, "gerekli bilgi ve araçları doğru biçimde ve doğru zamanda, LLM'in görevi yerine getirebilmesi için sistematik olarak sunmaya yönelik tasarım ve inşa uzmanlığı"dır
Context engineering'in özellikleri
- Uçtan uca sistem tasarımı: Context, basit bir prompt şablonu değil; LLM çağrısından önce çalışan tüm sistemin çıktısıdır
- Dinamik üretim: Göreve göre takvim/e-posta/web araması gibi farklı bilgiler gerçek zamanlı seçilir ve işlenir
- Doğru yerde doğru bilgi ve araç sunumu: "Garbage In, Garbage Out" ilkesi gereği modele gereksiz ya da eksik bilgi verilmemesi kritik önemdedir
- Biçim netliği önemlidir: Bilgiyi dağınık biçimde yüklemek yerine özetlemek ve yapılandırmak gerekir; araçların nasıl kullanılacağı da açık biçimde aktarılmalıdır
Sonuç
- Güçlü ve güvenilir yapay zeka ajanları geliştirmenin özü, "sihirli prompt'lar" ya da en yeni model değil, context engineering'dir (context'in tasarlanması ve sunulması)
- Bu, yalnızca teknik bir sorun değil; iş ihtiyaçlarına ve amaçlarına uygun bilgi, araç ve yapılandırılmış çıktı tanımı dahil olmak üzere kapsamlı sistem tasarımı yetkinliği gerektirir
- LLM'in görevi tamamlayabilmesi için, uygun bilgiyi doğru zamanda ve doğru formatta sunmak temel unsurdur
Kaynaklar
2 yorum
Sadece adı değişiyormuş gibi güçlü bir his veriyor.
Hacker News görüşleri
Kısa süre önce bu konu hakkında bir blog yazısı yazmıştım, bkz. yazım - Context Engineering
Drew Breunig’in yazılarının bu konuyu gerçekten harika ele aldığını düşünüyorum
Zamanlama tesadüfen “context engineering” memesinin dolaştığı döneme denk geldi ama aslında o meme ile ilgisiz bir çalışmaydı
How Long Contexts Fail - Uzun bağlamlar neden başarısız olur yazısında, uzun bağlamların nasıl sorun çıkardığı ve “context rot” denen şeyin nasıl oluştuğu çeşitli şekillerde anlatılıyor
How to Fix Your Context - Bağlamınızı nasıl düzeltirsiniz yazısında ise Tool Loadout, Context Quarantine, Context Pruning, Context Summarization, Context Offloading gibi çeşitli tekniklere isim verilip çözüm yolları sunuluyor
Drew Breunig’in yazılarını kesinlikle okumaya değer buluyorum
Bu sadece kendi ajanlarınızı geliştirirken değil, bugün ajan destekli kodlama kullanırken de gerçekten önemli
Bu sınırlamalar ve davranış biçimleri bir süre daha bizimle olacak gibi görünüyor
Context mühendisini otomatikleştiren bir Logic Core’u ilk kimin geliştireceğini merak ediyorum
Bunun da “bir aylık bir beceri” olduğunu düşünüyorum
Sonunda diğer pek çok moda akım gibi yakında kaybolup gidecek
Bu meseleler LLM araştırma dünyasında mevcut LLM’lerin bir ürünü olarak görülüyor
Aynı anda milyonlarca aracı kullanma ve kararlı uzun bağlamlar kullanma yöntemleri üzerine zaten araştırmalar sürüyor
İleride, başka sağlayıcılara bağlanmayı gerektiren özel durumlar dışında çoğu durumda tek bir ajan yeterli olacaktır
Mevcut LLM’lere bakarak geleceğin ajan sistemlerini tasarlayanlar muhtemelen LangChain örneğinde olduğu gibi geride kalacak
GPT-3 için yapılmış LangChain’in GPT-3.5 ile birlikte hızla demode kalmasına benzer bir durum
LLM kullanmış ya da LLM’lerin nasıl çalıştığını bilen herkes için oldukça bariz bir konu
“Prompt engineering” denen “becerinin” de geçici bir odak noktası olduğu ve uzun ömürlü olmayacağı belliydi
Temelde mesele, LLM’e girdi (bağlam) ve eylem (çıktı) vermek; bunu sağlamak için de ciddi miktarda pipeline işi gerekiyor
“Güçlü ve güvenilir AI ajanları üretmek, sihirli promptlar ya da model güncellemeleri bulmaktan uzaklaşıyor” sonucuna katılıyorum
“Doğru bilgi ve araçları, doğru formatta ve doğru zamanda sağlama işi olan context engineering’e” daha çok odaklanmak gerektiği doğru
Ama o “doğru format” ve “doğru zaman” özünde tanımlı değilse, hâlâ “sihirli çözüm” peşinde koşmuyor muyuz?
“Doğru bilgi”, “LLM’in yeterince doğru cevap vermesini sağlayan bilgi” anlamına geliyorsa, bunun prompt engineering’den özünde farklı olmadığını düşünüyorum
Bu tür deterministik olmayan makinelerde, “promptu dene ve sonucu gör” yaklaşımı dışında güvenilir sezgisel yöntem pek yok gibi geliyor
Sonuçta sonsuz bir sihirli düşünce döngüsü
Bugün buna “prompt engineering” yerine “context engineering” demek, yine belirsiz bir alanda işe yarayan bir şey bulmak için durmadan ayar kurcalamak anlamına geliyor
Özünde bu bir overfitting meselesi
Prompt engineering dediğimiz şeyin özü de bu zaten
Sorun, “doğru format, doğru zaman”ın özünde tanımlı olmaması
“AI’ı iyi kullanma” üzerine verilen tavsiyelerin çoğu da tam bu sorundan çıkıyor
Sonunda davul çalıp ritüel yapan bir şaman gibi hissettiriyor
Güncel teorik çerçevelerde bu süreç iki aşamaya ayrılıyor: keşif (Exploratory) ve bulgulama (Discovery)
Keşif aşamasını bir tür havaya madde püskürtme cihazı gibi düşünebilirsiniz
Kolay fark edilebilir işaretleyici bir maddeyi (genelde dışkı benzetmesiyle) yüksek hızla ortama veriyorsunuz
Bulgulama aşaması da bunun yayılma desenini analiz etmek olarak kavramsallaştırılıyor
Bu iki aşamanın özeti “bir dene bakalım”, ardından da “sonuca bak” şeklinde ifade edilebilir
Artık herkes “prompt engineering”in öyle büyük bir beceri olmadığını fark ettikçe, AI sektöründe başarı ölçütünün sürekli yer değiştirdiği hissi oluşuyor
Yeni beceri aslında yine “programlama”
Eski beceriyle aynı
Bunları anlamak için program yazmanız gerekiyor
LLM eğiten, inference çalıştıran ve davranışları analiz eden programlar yaza yaza daha çok şey anlıyorsunuz
Başta teorilerim ve beklediğim sonuçlar vardı ama LLM’leri çeşitli biçimlerde eğittikten sonra bambaşka sonuçlar ve kanaatler edindim
Aracı gerçekten uygulamaya koyma süreci belirleyici farkı yaratıyor
Benim de yalnızca orta düzeyde makine öğrenimi programlama deneyimim var ama orta ölçekli bir derleyiciyi bizzat yapmış olmanın, karmaşık sistemlerde iyi sonuç almanın anahtarı olduğunu düşünüyorum
Karpathy’nin bunu nasıl öğrendiğini sanıyorsunuz?
Cevap Karpathy’nin blogunda
Bu, derleyicileri anlamak için gidip bir derleyici yazın demeye benziyor
Teknik olarak doğru olabilir ama çoğu insan o kadar derine inmek istemiyor
Bu tartışma giderek WoW gibi oyun forumlarında oyuncuların strateji deneyip birbirleriyle garip bir grup diliyle tartışmasına benzemeye başladı
Sözde stratejiler neredeyse tamamen deneme-yanılmayla bulunuyor ve konuşulan dil de çoğunlukla sadece o grubun anladığı türden
Programlama da giderek oyunlaştırma çağına uyum sağlıyor
Power user’lar sahte stratejileri yeni başlayanlara ya da aşırı oyuncu kafasındaki yöneticilere pazarlıyor
Aslında önceki enterprise yazılım modalarında da aynı şeyler tekrar tekrar yaşanıyordu
Bu kez fark, o “power user güdümlü trend”in geliştiricilerin, yani üreticilerin sahip olduğu etki/kontrol/workflow alanına kadar derinlemesine sızmış olması
Bugün geliştiricilerin hissettikleri şey, geçmişte QA, SRE ya da CS rollerindekilerin “trend buymuş!” diye tooling ve pratikler dayatıldığında hissettiğinden çok farklı değildir herhalde
Sonuç:
“Güçlü ve güvenilir AI ajanları üretmekte önemli olan şey, sihirli promptlar ya da model güncellemeleri değil; iş ihtiyacına uygun doğru bilgi ve araçları doğru formatta ve doğru zamanda sunan context engineering’dir”
Aslında bu ilke insanlar için de aynen geçerli
İnsana da doğru bilgiyi doğru zamanda verirseniz sorunları daha iyi çözer
Bu tür yüzeysel makine öğrenimi-insan karşılaştırmalarından hoşlanmıyorum
Ne bir içgörü sağlıyor ne de çoğu zaman gerçekten doğru oluyor
Sonuçta yapılan şey, bir ortam içinde hedef düğmeyi etkili şekilde bulup basmak
Klasik yazılım mühendisliğinden çok da farklı değil
Sadece sonuçlar biraz daha deterministik değil
Ben UX ve ürün ekiplerinden her zaman “mockup, gereksinimler, kabul kriterleri, örnek input/output, bu özelliğin neden önemli olduğu” gibi şeyleri durmadan isterim
Beyin tarayıp isteneni çekip çıkaramadığımız sürece, ne istendiğini düzgün anlatmak pratikte şart
Sadece ‘hisse’ güvenilebilecek bir alan değil
Önemli olan daha fazla bağlam değil, daha iyi bağlam
(Klasik örnek: X-Y problem)
En yeni LLM’lere çok iyi bağlam verseniz bile yine de başarısız olabiliyorlar
Bizim şirket bunu iki yılı aşkın süredir derinlemesine inceliyor
“Cevap bağlamdır” görüşüne duyulan kör inanç gerçekten şaşırtıcı
Bir noktadan sonra işi AI’sız doğrudan yapmak daha hızlı geliyor
En azından ondan yararlı bir ders kalıyor; saatlerce LLM bağlamı üretmeye gömülmektense daha iyi
Yeterli bağlam verildiği hâlde LLM’in başarısız olduğu örnekleri merak ediyorum
Mümkünse somut örnekler paylaşmanızı isterim
Sihirli prompt arayışı aslında hiçbir zaman gerçekten “prompt engineering” olmadı
Özünde her zaman “context engineering”di
Pek çok sözde AI uzmanı bunu prompt engineering diye pazarladı ama aslında özünü pek anlamıyordu
RAG (retrieval-augmented generation) bu yıl bir anda ortaya çıkmış bir kavram değil
Embedding, vector DB, graph DB gibi karmaşık birikimi sarmalayan araçlar da giderek daha yaygın hâle geliyor
Büyük platformlar da ilgili araçları geliştirerek daha geniş ekosistemler sunuyor
Hep aynı sorunlara yeni kavramlar üretip sadece isim değiştiriyormuşuz gibi geliyor
Sonuçta yine ateş başında davul çalıp büyü mırıldanan şaman ritüellerine dönüyor
Sanki şeytan çağırıyormuşsunuz gibi; doğru büyüyü doğru kelimelerle söyleyip emrinize uymasını umuyorsunuz
İçimde, güvenilirlik, tekrarlanabilirlik ve güçlü test kapsamı isteyen mühendis tarafımla bugünün kontrol edilemeyen karmaşıklığı arasında bir gerilim var
Bu tür sistemlerle büyük ölçekli demo yapan insanlara gerçekten saygı duyuyorum
Bana eski güvenlik açığı araştırması demolarını hatırlatıyor
Ne kadar iyi hazırlanırsanız hazırlanın, sonuç sahnede her an ters köşe yapabilir; sunum sırasında ter döktüğüm günleri hatırlıyorum
Bu, benim deneyimimle de çok örtüşen bir bakış açısı
LLM’e bağlam verirken sık sık “bir insan sadece bu bilgiyle bu problemi çözebilir mi?” diye soruyorum
Geçmişte text2SQL ürünü geliştirirken model başarısız olduğunda, gerçek veri analistleri de “aa, o tablo eski tablo; artık şu tabloyu kullanıyoruz” gibi yanıtlar verirdi
Sonuçta mesele, ‘insan analistin’ ihtiyaç duyduğu bağlam eksikse LLM’in de hata yapması
Bu tartışmada eksik kalan bir şey varsa o da “değerlendirmeler (evaluations)”
AI projelerinde hâlâ değerlendirme olmadan ya da çok zayıf değerlendirmeyle ilerlendiğini görmek şaşırtıcı
Değerlendirme, geleneksel mühendislikteki testlerden bile daha önemli
Değerlendirme setinin çok büyük olması gerekmiyor; problem alanını iyi kapsaması yeterli
O yoksa geriye sadece “tahmin” kalıyor
Ayrıca ben de sık sık “bir insan yalnızca bu bilgiyle bunu çözebilir mi?” diye kendime soruyorum
İnsanların bile çözemeyeceği şeyleri LLM’lerin çözmesini beklediğim zamanlar olmuştu
Geleneksel bilgisayar programlama kuralı
“Programcıların İngilizce kod yazmasını sağlayalım derseniz, aslında programcıların İngilizceyi de düzgün yazamadığını keşfedersiniz”
Biraz şaka ama içinde ciddi bir doğruluk payı var
Çoğu doğal dil o kadar da net değil
Eğer İngilizceyle ne istediğinizi çok kesin ifade edebiliyorsanız, belki de bunu doğrudan makinenin yorumlayacağı bir dilde yazabilirdiniz
Evet/hayır sorusu sorarsanız %50 ihtimalle yanlış cevap alırsınız
Böyle bir özelliği var
Ben genelde modele işi gerçekten başlatmadan önce bu tür sorular sorduruyorum
Örneğin belirsiz noktalar varsa soru sorması ve mevcut kod kalıplarına örnek istemesi yönünde talimat veriyorum
Hâlihazırda kullanılan şablonları örnek alabilmesini teşvik ediyorum
Veri bilimci taklidi yapanlar değerlendirme istemez
Bu yüzden gerçekten para kazanan ürünler dışında neredeyse hiç değerlendirme yok
“Kral çıplak” demek para getirmediği için
Ama gerçek iş kullanımında gerekiyorsa değerlendirme mutlaka işin içinde olur