Yapay Zeka Modellerinde Bağlam Mühendisliğinin Evrimi: Veri Bilimciler İçin Ne Anlama Geliyor?

Son zamanlarda, Claude gibi sistemlerin sunduğu olumlu yönler saymakla bitmiyor. Tekrarlayan kodlama işlemleri otomatikleşiyor, araştırma daha hızlı yapılıyor ve hata ayıklama kolaylaşıyor. Genel olarak, yazılım alanındaki profesyoneller için üretkenlik artıyor ve ekiplerin daha fazla şey geliştirmesine olanak tanınıyor.

Ancak, Claude gibi araçları kullanmanın küçük bir dezavantajı, bu sistemlerin kontrol altında tutulması gerektiğidir.

Bu sadece geride kalmamak ve güncel olmayan teknolojileri kullanmaktan kaçınmakla ilgili değil. Aynı zamanda, yeni modellerin önceki modellere göre biraz farklı çalıştığı için de önemlidir.

Sonuç olarak, kendinizi “Bugün Claude’da bir sorun var mı? Neden düzgün çalışmıyor?” sorusunu sormuş bulabilirsiniz, ancak aslında Claude’u doğru şekilde kullanmadığınızı fark etmeyebilirsiniz.

Bu nedenle, Anthropic gibi şirketler sadece yeni modellerin bazı ölçütlere göre objektif olarak daha iyi olduğunu göstermekle kalmaz, aynı zamanda kullanıcıların onlarla nasıl etkileşimde bulunmaları gerektiğini de açıklar.

Yaklaşık bir ay önce, Anthropic “Claude 5 nesil modelleri için bağlam mühendisliğinin yeni kuralları” başlıklı bir rapor yayınladı.

Bu raporda, modellerin nasıl değiştiği ayrıntılı olarak açıklanıyor ve istem mühendisliğinin artık anahtar rol oynamadığı, bunun yerine büyük dil modellerinin (LLM’ler) sorulara cevap vermek veya istekleri tamamlamak için kullandığı tüm kaynakları içeren “bağlam mühendisliği”nin ön plana çıktığı belirtiliyor.

Özellikle bu rapor, veri bilimcilerinden bahsediyor ve şu soruyu yanıtlamaya çalışıyor:

“Bağlam mühendisliğinin yeni kuralları, günlük iş akışımızı nasıl değiştiriyor?”

Ancak başlamadan önce, “bağlam mühendisliği” tam olarak nedir?

Anthropic modellerini kullanmanın iki temel yolu vardır: API çağrıları ve Claude Code.

API çağrıları, girdinin tek seferlik bir şekilde işlenmesidir. Metniniz (girdi sıra dizesi), LLM tarafından işlenir ve çıktı sıra dizesi üretilir. LLM’nin sahibi olmadığınız için bu işlem çevrimiçi olarak gerçekleşir ve girdi ile çıktı tokenleri için ödeme yaparsınız. Bu kadar basit.

Claude Code (veya Codex) gibi sistemler ise, büyük dil modelini kullanarak daha fazlasını yapar. Bu durumda, büyük dil modeli hala API çağrıları aracılığıyla kullanılır, ancak sadece girdiyi okumaktan çok daha fazlasını yapar. Birçok API çağrısı yürütülür ve her bir API çağrısının farklı bir sorumluluğu vardır (örneğin, akıl yürütme, kodlama, çıktıyı üretme vb.). Sonuç olarak, tüm bu işlemlerin sonucunda elde edilen nihai sonuç görüntülenir.

(1) İstem mühendisliği: Belirli bir görevi yerine getirmek için gereken tüm bilgiler istemde bulunur ve güvenilir ve doğrulanabilir bir cevap beklenir.
(2) Ajan kullanımı: Bu durumda, istem mühendisliği daha az önemlidir. Çünkü ajanlar sezgisel, kullanımı kolay ve genellikle dahili sistemleri kullanarak daha güçlüdür.

Ancak bu, Claude’un zihni okuyabileceği anlamına gelmez.

Claude’un iyi bir iş çıkarması için gereken tüm bilgiler, “bağlam” olarak adlandırılan bir dizi belgede, talimat dosyasında ve ayarda bulunmalıdır. Bu bağlamın, büyük dil modelinin optimal şekilde kullanabilmesi için “mühendislik” edilmesi gerekir. Anthropic, bunu nasıl yapacağımıza dair yönergeler sunar.

Şimdi, bu yönergeleri bir veri bilimci bakış açısıyla inceleyelim.

İlk olarak, Claude Code’un başlatıldığında oluşturduğu “CLAUDE.md” dosyasından bahsediliyor. [Eğer kaybolmuş hissediyorsanız, okumaya devam etmeden önce buna göz atmanız önerilir].

Anthropic ekibi, “Claude’a çok fazla talimat vermeyi bırakın; sadece kafasını karıştırıyorsunuz” diyor. Yeni modellerin boşlukları doldurabileceğini ve aşırı bilgi eklemenin bu bilginin birbiriyle çelişmesine neden olabileceğini belirtiyorlar.

Bu, “CLAUDE.md” dosyasına klasörün bir EDA (keşifsel veri analizi) klasörü, bir araştırma klasörü veya “üretimde teslim edilecek kod” klasörü olup olmadığını yazabileceğinizi gösteriyor.

Böylece Claude, belirli bir özelliğin üretimde kullanılacaksa dikkatli olması gerektiğini ve .py dosyalarının kullanılması gerektiği, ancak EDA klasöründe bunun tersinin geçerli olduğu gibi bilgileri anlayabilir.

Daha sonra, Claude’un becerilerden yararlanabileceği belirtiliyor. Bir beceri, zamandan tasarruf sağlayan bir şeydir: aynı şeyi tekrar tekrar yaptığınızda, bu bilgiyi ayrı bir dosyada saklarsınız ve her seferinde açıklamaya gerek kalmadan doğrudan o dosyaya yönlendirirsiniz.

Örneğin, not defterleriyle çalışmak için bir “notdefteri.md” becerisi oluşturabilirsiniz. Bu beceri, Claude’un hangi kütüphaneleri kullanması gerektiğini, grafiklerin renklerini nasıl ayarlaması gerektiğini vb. belirleyecektir.

Anthropic, “Claude’un her şeyi tek uzun beceride toplarsanız kafası karışır” diyor. Başka bir deyişle, belirli olmamız gerektiğini söylüyorlar.

Bu konsepti veri bilimi açısından düşünelim. Farklı görevleri yerine getirmemiz gerekir ve bunlar birbirinden farklıdır. Bazen veriyi yükleriz, bazen sadece keşfederiz, bazen Databricks’i kurarız, bazen bir model eğitiriz. Her mikro görevin kendi becerisi olmalıdır. Sonuç olarak, küçük ama özel rutinlerden oluşan bir “beceri ağacı” oluşturacağız. Örneğin:

Veriyi yüklemek, kalitesini kontrol etmek ve dönüştürmek için ayrı bir dosya olan “veri.md” dosyası yerine, Claude’un veriyi nasıl yükleyeceğini belirleyen daha kısa bir dosya kullanabilirsiniz.

Son olarak, Anthropic, Claude’un tercihlerinizi hatırlayabildiğini belirtiyor. Örneğin, ön işleme adımlarının çok agresifse (örneğin, NaN değerlerini keşfetmeden tamamen filtrelemek), bu adımları değiştirmek için Claude’u yönlendirebilirsiniz.

Ayrıca, hiperparametreleri içeren bir “hiperparametre.json” dosyası varsa ve bunun eğitim sürecinde kullanılacağını belirtirseniz, Claude bu dosyanın analiz edilmesini ve gerektiğinde kullanılmasını sağlayacaktır.

Sonuç olarak, modelin başarısız olmasının nedeni genellikle yanlış bilgilere sahip olmasıdır. En iyi sonuçları elde etmek için bağlam mühendisliği önemlidir.

Pratikte şunları yapmalıyız:
Claude’a genel bir yönlendirme vermeliyiz, ancak aşırı spesifik bilgiler vermekten kaçınmalıyız.
Küçük ve özel rutinlerden oluşan beceriler oluşturmalıyız.
Claude’un kendi kendini güncelleyebilme özelliğinden yararlanmalı ve her oturumda becerileri iyileştirmeliyiz.
Sonuçları görselleştirmek için zengin HTML dosyalarını kullanmalıyız.

Bu, Claude ile ilgili olsa da, diğer sağlayıcılar için de aynı trend geçerlidir. Bu nedenle, bağlam mühendisliğinin önemi her zaman devam edecektir.

Umarım bu bilgiler faydalı olmuştur. Ben Piero Paialunga’yım ve LinkedIn’de tüm hikayelerimi yayınlıyorum: [LinkedIn bağlantısı]. Ayrıca GitHub’da tüm kodumu bulabilirsiniz: [GitHub bağlantısı]. Sorularınız için bana e-posta gönderebilirsiniz: [E-posta adresi].

“Timeoutlar, kesme işlemleri ve sonuç sanitizasyonu ile Cypher çıktılarını LLM uyumlu hale getirme”
“Veri bilimciler için pratik bir LangChain eğitimi: CSV dosyalarını inceleme”
“İyi modeller kötü mimarileri kurtaramaz ve çoğu ekip bunu zor yoldan öğrenir”
“Microsoft Fabric veri aracısının ne olduğunu ve nasıl çalıştığını basit bir şekilde açıklama”
“Git worktrees, paralel ajanlı kodlama oturumları ve bilmeniz gereken kurulum maliyeti”
“2021 AWS Machine Learning Summit ana konuşmalarından çıkarımlar”
“Makine öğrenimini zor yoldan öğrendikten sonra bilmem gerekenler”
“Kodlama ajanlarını tüm bilgisayarınızdaki görevlere nasıl uygulayabilirsiniz?”