Many-Shot In-Context Learning: Uzun Bağlam Çağında Few-Shot'un Evrimi

TL;DR — Yıllarca prompt'a bir-iki örnek koyup modele "işte böyle yap" derdik; buna few-shot öğrenme diyorduk. Uzun bağlam pencerelerinin patlamasıyla artık onlarca, yüzlerce, hatta binlerce örneği prompt'a sığdırabiliyoruz — buna many-shot in-context learning deniyor. Ve bu, oyunu değiştiriyor: birçok görevde, fine-tuning yapmadan, sadece örnek sayısını artırarak fine-tuning'e yakın sonuçlar alınabiliyor. Bu yazıda few-shot'tan many-shot'a geçişin ne getirdiğini, ne zaman fine-tuning yerine tercih edeceğinizi, maliyeti prompt caching ile nasıl yöneteceğinizi, örnek seçimi ve sıralamasının inceliklerini ve Türkçe görevlerdeki pratikleri sahadan anlatıyorum.

Prompt mühendisliğinin klasik araçlarından biri few-shot öğrenmeydi. Fikir basit: modele görevi anlatmak yerine, ona birkaç örnek gösterirsiniz. "İşte girdi, işte istediğim çıktı" biçiminde üç-beş örnek, modelin ne yapması gerektiğini kavramasını sağlar. Bu, yıllarca çok işe yaradı ve hâlâ da yarıyor.

Ama few-shot'un bir sınırı vardı: bağlam penceresi. Modele ne kadar örnek verebileceğiniz, prompt'a sığdırabildiğiniz kadardı ve bu pencereler eskiden dardı. Birkaç örnekten fazlasını koyamıyordunuz. Uzun bağlam pencerelerinin gelişiyle bu sınır kalktı. Artık yüz binlerce, hatta milyonlarca token'lık pencerelerle çalışabiliyoruz — ve bu, prompt'a onlarca, yüzlerce, binlerce örnek koyabilmek demek. İşte many-shot in-context learning tam bu: few-shot'un, örnek sayısı radikal biçimde arttırılmış hali.

Bu niceliksel değişim, niteliksel bir sıçramaya yol açıyor. Az sayıda örnekle model görevin genel fikrini kavrarken, çok sayıda örnekle görevin inceliklerini, istisnalarını, kenar durumlarını da öğreniyor. Sahada gördüğüm kadarıyla, doğru kurulduğunda many-shot, bazı görevlerde fine-tuning'e rakip olacak kalitede sonuç verebiliyor — ve bunu, model ağırlıklarına hiç dokunmadan, sadece prompt'la yapıyor. Bu, kurumlar için müthiş bir esneklik.

Bu yazıda amacım, many-shot'u bir "moda terim" olmaktan çıkarıp elinizde kullanabileceğiniz pratik bir araca dönüştürmek. Hangi görevlerde işe yarar, hangilerinde gereksiz, maliyeti nasıl kontrol edersiniz, örnekleri nasıl seçer ve sıralarsınız, fine-tuning'e ne zaman geçersiniz — bunların hepsini somut olarak ele alacağım. Çünkü many-shot, doğru kullanıldığında elinizdeki modelden çok daha fazlasını çıkaran güçlü bir kaldıraç; ama yanlış kullanıldığında sadece token ve para yakan bir alışkanlık. Aradaki farkı bilmek, sahadaki gerçek beceridir.

Many-shot'un neden bu kadar etkili olduğunu anlamak, onu doğru kullanmanın anahtarı. Birkaç mekanizma bir arada çalışıyor.

Birincisi, örüntü öğrenme derinliği. Üç örnekle model, "sanırım şöyle bir şey istiyor" diye tahmin eder. Üç yüz örnekle, görevin gerçek dağılımını görür: hangi durumlar sık, hangileri nadir, istisnalar nasıl ele alınır. Bu, tahminden bilgiye geçiştir. Model artık görevi "sezmiyor", örneklerden "öğreniyor".

İkincisi, format ve ton tutarlılığı. Çok sayıda örnek, modele istediğiniz çıktının tam olarak nasıl görünmesi gerektiğini gösterir. Format, uzunluk, ton, terminoloji — bunların hepsi çok sayıda örnekle çok daha tutarlı biçimde kavranır. Az örnekle model formatı bazen kaçırırken, çok örnekle neredeyse hiç kaçırmaz.

Üçüncüsü, kenar durumların kapsanması. Gerçek görevlerin zorluğu genellikle nadir, tuhaf durumlarda. Az örnekle bu kenar durumları modele gösteremezsiniz; çok örnekle gösterebilirsiniz. Model, "bu tuhaf durumda ne yapmalı" sorusunun cevabını örneklerde görür. Bu, üretim kalitesi için kritik, çünkü sistemler genellikle tam da bu kenar durumlarda çöker.

"

Sahadan gözlem: Many-shot'un en güzel yanı, öğretebilir olması. Bir görevi kelimelerle tarif etmek zor olduğunda — "istediğim tonu anlatamıyorum ama örnek görünce anlarsın" durumları — örnekler dilden çok daha güçlü. İyi bir örnek kümesi, uzun bir talimat listesinden çok daha net iletişim kurar.

İşte en pratik soru. Elimde etiketli örnekler var; bunları prompt'a mı koyayım (many-shot), yoksa modeli mi eğiteyim (fine-tuning)? İkisi de "örneklerden öğrenme" ama çok farklı takaslarla geliyor.

Many-shot'un avantajları: hemen çalışır (eğitim süreci yok), esnektir (örnekleri anında değiştirebilirsiniz), ve model-agnostiktir (aynı örnek kümesini farklı modellerde deneyebilirsiniz). Dezavantajı: her istekte örnekler prompt'a girdiği için token maliyeti ve gecikme artar; ve çok büyük örnek kümelerinde bağlam penceresi sınırına ulaşabilirsiniz.

Fine-tuning'in avantajları: örnekler modele "kalıcı" olarak işlendiği için, her istekte tekrar göndermeniz gerekmez — bu, çıkarımda daha ucuz ve hızlıdır; ve çok büyük veri kümelerini (binlerce, on binlerce örnek) işleyebilir. Dezavantajı: bir eğitim süreci gerektirir (zaman, uzmanlık, maliyet), esnek değildir (bir şey değişince yeniden eğitmek gerekir), ve belirli bir modele bağlıdır.

Benim sahada uyguladığım karar kuralı şu: önce many-shot deneyin. Hızlı, esnek ve çoğu zaman yeterli. Eğer many-shot ile kabul edilebilir kaliteye ulaşıyorsanız, fine-tuning'in karmaşıklığına hiç girmenize gerek yok. Fine-tuning'e ancak şu durumlarda geçin: many-shot yeterli kaliteyi vermiyorsa, örnek sayınız bağlam penceresine sığmayacak kadar büyükse, ya da çıkarım maliyeti/gecikme kritik ve örnekleri her seferinde göndermek istemiyorsanız. Yani fine-tuning bir başlangıç değil, many-shot'un yetmediği yerde başvurulan bir sonraki adım.

Boyut	Many-shot	Fine-tuning
Başlangıç hızı	Anında	Eğitim süreci gerekir
Esneklik	Örnekleri anında değiştir	Değişiklik = yeniden eğitim
Çıkarım maliyeti	Yüksek (her istekte örnekler)	Düşük (örnekler modele işlenmiş)
Örnek kapasitesi	Bağlam penceresiyle sınırlı	Çok büyük veri işlenebilir
Model bağımlılığı	Model-agnostik	Belirli modele bağlı

Many-shot'un en büyük pratik engeli maliyet. Yüzlerce örneği her istekte prompt'a koyarsanız, her istek için o örneklerin token'larını tekrar tekrar ödersiniz. Yüksek hacimli bir sistemde bu, faturayı hızla şişirir. Ama iyi haber: bu problemin zarif bir çözümü var — prompt caching (önek önbellekleme).

Fikir şu: many-shot prompt'unuzda örnek kümesi genellikle sabittir; değişen sadece asıl sorudur. Yani "işte 300 örnek + [kullanıcının sorusu]" yapısında, ilk 300 örnek her istekte aynı. Prompt caching, bu sabit öneki bir kez işleyip önbelleğe alır; sonraki isteklerde o örnekleri yeniden işlemek yerine önbellekten kaldığı yerden devam eder. Bu, hem maliyeti hem gecikmeyi dramatik biçimde düşürür.

Prompt caching'in many-shot'u ekonomik kıldığını söylemek abartı olmaz. Caching olmadan, yüzlerce örnekli bir prompt'u yüksek hacimde kullanmak çoğu zaman ekonomik değil. Caching ile, sabit örnek kümesinin maliyeti neredeyse bir kereye iner ve marjinal istek maliyeti sadece değişken kısma (asıl soruya) düşer. Bu yüzden many-shot kullanacaksanız, prompt caching'i baştan mimariye gömün; bu ikisi birlikte çalışır ve ayrı düşünülmemeli.

Many-shot'ta "daha çok örnek her zaman daha iyi" mi? Hayır, o kadar basit değil. Örneklerin sayısı kadar kalitesi ve çeşitliliği de önemli, hatta bazen daha önemli.

Örnek seçiminde birkaç ilke var. Birincisi, temsil edicilik: örnekleriniz, gerçek görevin dağılımını yansıtmalı. Sadece kolay durumları koyarsanız, model zor durumlarda zorlanır. Örnek kümesi, sık durumları da nadir kenar durumları da içermeli. İkincisi, çeşitlilik: birbirine çok benzeyen yüz örnek, birbirinden farklı yirmi örnekten daha az öğretir. Çeşitlilik, modele görevin genişliğini gösterir. Üçüncüsü, kalite: her örnek doğru olmalı. Yanlış ya da tutarsız bir örnek, modeli yanlış yönlendirir — hatta birkaç kötü örnek, çok sayıda iyi örneğin etkisini bozabilir.

İleri bir teknik, dinamik örnek seçimi: sabit bir örnek kümesi yerine, gelen her soruya en benzer örnekleri bir arama mekanizmasıyla seçip prompt'a koymak. Bu, RAG mantığının many-shot'a uygulanması. Böylece her soru, kendisine en alakalı örneklerle desteklenir. Bu daha karmaşık bir mimari ama zor görevlerde belirgin fark yaratabilir. Basit görevlerde sabit iyi bir küme yeterli; karmaşık ve çeşitli görevlerde dinamik seçim değerli.

Many-shot'ta az bilinen ama önemli bir konu, örneklerin sırası. Modeller, uzun bağlamda bilgiyi eşit iyilikte kullanmaz; genellikle baştaki ve sondaki bilgiyi ortadakinden daha iyi hatırlar. Buna "ortada kaybolma" (lost in the middle) sorunu deniyor ve many-shot'ta doğrudan etkili.

Pratik sonuç şu: en önemli, en temsil edici örnekleri prompt'un başına ve sonuna koyun; ortaya daha az kritik olanları yerleştirin. Ayrıca asıl soruyu, örneklerden hemen sonra, prompt'un sonuna koymak genellikle en iyi sonucu verir çünkü model en son gördüğü şeye daha çok dikkat eder. Bu ince ayarlar, aynı örnek kümesiyle bile fark yaratabilir.

Bir de örnek sayısını sonsuza kadar artırmanın getirisinin azaldığını unutmayın. Belli bir noktadan sonra, daha fazla örnek eklemek kaliteyi artırmaz ama maliyeti ve "ortada kaybolma" riskini artırır. Her görev için optimal örnek sayısı farklıdır ve bunu ölçerek bulmanız gerekir. "Daha çok her zaman daha iyi" değil; "yeterince çok, doğru seçilmiş ve iyi sıralanmış" en iyisidir.

Somut olsun diye tipik bir many-shot kurulumunu adım adım anlatayım. Diyelim ki bir müşteri hizmetleri ekibi için, gelen şikayetleri belirli kategorilere ayıran ve her birine markanın sesiyle bir taslak yanıt üreten bir sistem kuruyorsunuz. Bu, few-shot'un zorlandığı ama many-shot'un parladığı türden bir görev: hem sınıflandırma hem üretim, hem de çok belirli bir ton gerektiriyor.

Önce, geçmiş şikayet-yanıt çiftlerinden temsili bir örnek kümesi topluyorsunuz — farklı kategorilerden, farklı zorluk seviyelerinden, markanın sesini iyi yansıtan gerçek örnekler. Diyelim 150 örnek. Bunları prompt'a koyuyorsunuz, ama gelişigüzel değil: en temsil edici ve en zor örnekleri başa ve sona, ortadakileri araya yerleştiriyorsunuz. Örnek kümesini prompt caching ile önbelleğe alıyorsunuz ki her istekte tekrar işlenmesin. Gelen her yeni şikayet, örneklerden sonra, prompt'un sonuna ekleniyor.

Sonra bir altın küme (diyelim 40 gerçek şikayet ve ideal yanıtları) ile sistemi ölçüyorsunuz. Sınıflandırma doğru mu? Yanıtın tonu markaya uygun mu? Format tutarlı mı? Zayıf olduğu yerleri buluyor, o durumları temsil eden yeni örnekler ekliyor, tekrar ölçüyorsunuz. Birkaç iterasyonda, fine-tuning yapmadan, sadece örneklerle üretim kalitesine ulaşıyorsunuz. Ve en güzeli: marka sesi değiştiğinde ya da yeni bir şikayet tipi ortaya çıktığında, modeli yeniden eğitmek yerine sadece örnek kümesini güncelliyorsunuz. Bu esneklik, many-shot'un kurumsal cazibesinin özü.

Many-shot, bağlam penceresini yoğun kullanır ve bu, dikkat gerektirir. Pencereyi örneklerle doldururken, asıl göreve, ilgili bilgiye ve modelin "düşünme" alanına da yer bırakmanız gerekir. Pencereyi tamamen örneklerle tıkarsanız, model asıl soruya odaklanacak alan bulamayabilir ya da uzun bağlamda kalite düşebilir.

Bu yüzden "bütçe" mantığıyla düşünün: bağlam pencereniz sınırlı bir kaynak ve onu örnekler, talimatlar, ilgili bilgi ve çıktı arasında paylaştırıyorsunuz. Her örnek pencerede yer kaplar ve bir maliyeti vardır. Amaç, en az örnekle en çok öğretmek — yani her örneğin gerçekten katkı sağladığından emin olmak. Katkısı olmayan, tekrar eden örnekler sadece pencereyi ve bütçeyi tüketir.

Uzun bağlamın bir başka gerçeği: pencere büyüdükçe, modelin o pencerenin tamamını eşit iyilikte kullanma yeteneği her zaman aynı oranda artmaz. Bir milyon token'lık pencereniz olması, modelin o bir milyon token'ı mükemmel kullanacağı anlamına gelmez. Bu yüzden "pencereyi doldurabildiğim kadar dolduray" değil, "bu görev için gerçekten gereken kadar örnek koyayım" yaklaşımı doğru. Pencere kapasitesi bir tavan, hedef değil.

Son bir stratejik gözlem. Many-shot'un yükselişi, fine-tuning'i tümüyle gereksiz kılmıyor; ama onun alanını belirgin biçimde daraltıyor. Bir zamanlar "bu görevi iyi yapmak için fine-tuning şart" dediğimiz birçok senaryoda, artık many-shot yeterli oluyor. Bu, kurumlar için büyük bir kolaylık, çünkü fine-tuning ciddi bir yatırım: veri hazırlama, eğitim altyapısı, uzmanlık, ve her değişiklikte yeniden eğitim.

Fine-tuning hâlâ belirli yerlerde vazgeçilmez: örnek sayınız bağlam penceresine sığmayacak kadar büyükse, çıkarım maliyeti/gecikme kritikse ve örnekleri her seferinde göndermek istemiyorsanız, ya da modelin davranışında çok derin bir değişiklik gerekiyorsa. Ama bu senaryolar, eskisine göre daha nadir. Çoğu kurumsal görev için, doğru kurulmuş bir many-shot, fine-tuning'in karmaşıklığına girmeden yeterli kaliteyi veriyor.

Benim önerim, bunu bir "önce hangisi" sırası olarak düşünmek: sıfır örnek → birkaç örnek → many-shot → (gerekirse) fine-tuning. Bu merdivende mümkün olduğunca aşağıda kalın; sadece bir alt basamak yetmediğinde bir üste çıkın. Bu disiplin, hem maliyeti hem karmaşıklığı minimumda tutar ve size her seviyede net bir kalite ölçümü verir. En pahalı ve en karmaşık çözümle başlamak, çoğu zaman gereksizdir.

Türkçe içerikle çalışırken many-shot özellikle değerli, ama birkaç incelik var. Birincisi, Türkçe örnekler kullanın. Modele İngilizce örnekler verip Türkçe çıktı beklemek, tutarsızlığa yol açar. Görev Türkçe ise, örnekler de Türkçe olmalı ki model istediğiniz Türkçe tonu, terminolojiyi ve akışı kavrasın.

İkincisi, Türkçe'nin nüansları — resmi/samimi ton ayrımı, deyimler, kültürel bağlam — kelimelerle anlatmak zordur ama örneklerle çok net iletilir. Bu, many-shot'un Türkçe'de özellikle güçlü olduğu yer: "işte markamızın sesi böyle konuşur" demenin en iyi yolu, o sesle yazılmış çok sayıda örnek göstermek. Bir talimat listesi "sıcak ve samimi ol" diyebilir, ama on örnek bunu gerçekten öğretir.

Üçüncüsü, Türkçe token açısından İngilizce'den daha "pahalı" olabilir; aynı içerik Türkçe'de bazen daha fazla token tutar. Bu, many-shot maliyetini biraz artırır ve prompt caching'i daha da önemli kılar. Türkçe many-shot kullanıyorsanız, caching'i mutlaka devreye alın ki maliyet sürdürülebilir kalsın.

2026'nın en ilginç gözlemlerinden biri, many-shot'un muhakeme (reasoning) modelleriyle nasıl etkileşdiği. Muhakeme modelleri, cevap vermeden önce adım adım "düşünen" modeller. Bu modellerle many-shot kullanırken, örneklerinizin sadece "girdi-çıktı" değil, "girdi-düşünme adımları-çıktı" biçiminde olması genellikle daha güçlü sonuç verir. Yani modele sadece doğru cevabı değil, o cevaba nasıl ulaşıldığını da gösterirsiniz.

Bu, chain-of-thought (düşünce zinciri) ile many-shot'un birleşmesi. Örneklerinizde muhakemeyi açıkça gösterdiğinizde, model sadece "ne" değil "nasıl" düşüneceğini de öğrenir. Karmaşık analiz, çok adımlı problem çözme, hukuki ya da finansal muhakeme gibi görevlerde bu fark büyük olabiliyor. Az sayıda ama muhakemesi tam gösterilmiş örnek, bazen çok sayıda ama sadece cevap içeren örnekten daha etkili.

Ama bir denge var: muhakeme modelleri zaten kendi başlarına "düşündüğü" için, bazı basit görevlerde çok fazla örnek gereksiz hatta zararlı olabilir — model, örneklerdeki belirli bir düşünme kalıbına aşırı bağlanıp kendi muhakemesini kısıtlayabilir. Bu yüzden muhakeme modelleriyle çalışırken, örnek sayısını ve türünü görev karmaşıklığına göre dikkatle ayarlayın. Bazen az ama kaliteli örnek, çok ama sınırlayıcı örnekten iyidir.

Many-shot güçlü ama her görev many-shot gerektirmez. Bazı görevler için birkaç örnek — hatta sıfır örnek (zero-shot) — fazlasıyla yeterli. Aşırıya kaçıp her göreve yüzlerce örnek koymak, gereksiz maliyet ve karmaşıklık demek. Doğru soru: bu görev gerçekten çok örnek gerektiriyor mu?

Basit, iyi tanımlı, modelin zaten iyi bildiği görevlerde az örnek yeter. Örneğin bir metni özetlemek ya da bir duyguyu sınıflandırmak gibi görevleri modern modeller sıfır ya da birkaç örnekle zaten iyi yapar. Buralarda many-shot'a yatırım yapmak israftır. Many-shot'un asıl değeri, görev özgün, niş, ya da çok belirli bir format/ton gerektirdiğinde ortaya çıkar — yani modelin eğitiminde pek görmediği, sizin işinize özgü görevlerde.

Pratik yaklaşım: her zaman en azdan başlayın. Önce sıfır örnekle deneyin. Yetmezse birkaç örnek ekleyin. Hâlâ yetmezse many-shot'a çıkın. Bu kademeli yaklaşım, her göreve gereğinden fazla örnek yüklemekten korur ve size her seviyede maliyet-kalite dengesini görme fırsatı verir. En pahalı çözümle başlamak, çoğu zaman gereksiz mühendisliktir.

İki güçlü tekniği birleştirmek, çoğu zaman her birinden daha iyidir. Many-shot ve RAG'ı birlikte düşünmek, özellikle karmaşık kurumsal görevlerde çok değerli. Fikir şu: dinamik örnek seçimi aslında bir RAG problemidir — gelen soruya en alakalı örnekleri bir örnek havuzundan getirip prompt'a koymak.

Bu birleşik yaklaşımda, bir yanda bilgi getirme (klasik RAG: soruyla ilgili belgeleri getir), diğer yanda örnek getirme (soruyla benzer çözülmüş örnekleri getir) çalışır. Model hem ilgili bilgiye hem de benzer örneklere aynı anda erişir. Bu, özellikle "hem bilgi hem format" gerektiren görevlerde — örneğin bir müşteri sorusunu, hem ilgili politika belgesine hem de benzer geçmiş yanıtlara dayanarak cevaplamak — güçlü sonuç verir.

Bu mimariyi kurarken, örnek havuzunuzu ayrı bir indeks olarak tutun ve her soru için en alakalı örnekleri getirin. Böylece prompt'unuz her zaman o soruya en uygun örneklerle dolar, gereksiz örneklerle şişmez. Bu, hem kaliteyi artırır hem token maliyetini kontrol altında tutar — çünkü sabit yüzlerce örnek yerine, o soruya özel seçilmiş az sayıda çok-alakalı örnek kullanırsınız. Zeki bir birleşim, iki tekniğin de zayıflığını kapatır.

Bu alanda sıkça gördüğüm hataları toparlayayım. Birincisi, kalitesiz örnek kullanmak: tutarsız, yanlış ya da özensiz örnekler, çok sayıda olsalar bile modeli yanlış yönlendirir. Birkaç kötü örnek, sürünün tamamını bozabilir. İkincisi, prompt caching'i atlamak: many-shot'u caching olmadan yüksek hacimde kullanmak, faturayı gereksiz yere şişirir; ikisi birlikte düşünülmeli. Üçüncüsü, körlemesine örnek yığmak: "daha çok her zaman daha iyi" varsayımıyla gereksiz yere yüzlerce örnek koymak, maliyeti ve "ortada kaybolma" riskini artırır ama kaliteyi artırmaz.

Dördüncüsü, sıralamayı önemsememek: örneklerin sırası kaliteyi etkiler; en önemlileri başa-sona koymamak, aynı örneklerle daha kötü sonuç almak demek. Beşincisi, Türkçe görevde İngilizce örnek kullanmak: dil tutarsızlığı, çıktı kalitesini bozar. Altıncısı, ölçmeden karar vermek: "sanırım daha iyi oldu" hissiyle iterasyon yapmak, çoğu zaman yanıltıcıdır; altın küme olmadan gerçek ilerlemeyi göremezsiniz. Bu hataların ortak dersi, many-shot'un düşünmeden uygulanacak bir "sihir" değil, disiplin gerektiren bir teknik olduğu.

Many-shot'un az konuşulan bir boyutu, örneklerin güvenliği. Prompt'a koyduğunuz örnekler genellikle gerçek verilerden gelir — gerçek müşteri soruları, gerçek belgeler, gerçek yanıtlar. Bu, iki risk doğurur ve ikisini de baştan yönetmek gerekir.

Birincisi, KVKK. Örnekleriniz kişisel veri içeriyorsa (müşteri adı, iletişim bilgisi, hassas detay), bunları bir modele göndermek bir veri işleme faaliyetidir. Yurt dışı bir API kullanıyorsanız, bu bir yurt dışı aktarımdır. Bu yüzden örneklerinizi prompt'a koymadan önce anonimleştirin ya da hassas bilgileri temizleyin. Gerçek bir müşteri örneğini olduğu gibi prompt'a gömmek, farkında olmadan kişisel veriyi ifşa etmek olabilir. Anonimleştirilmiş ama yine de öğretici örnekler kullanmak, hem KVKK'yı hem kaliteyi korur.

İkincisi, örnek zehirleme (example poisoning) riski. Eğer örnek kümeniz otomatik olarak, denetimsiz kaynaklardan besleniyorsa, kötü niyetli ya da hatalı örnekler kümeye sızabilir ve modelin davranışını bozabilir. Özellikle dinamik örnek seçimi kullanıyorsanız (örnekleri bir havuzdan getiriyorsanız), o havuzun güvenliği kritik. Örnek havuzunuzu denetlenmiş, güvenilir kaynaklardan besleyin ve düzenli olarak gözden geçirin. Birkaç zehirli örnek, tüm sistemin kalitesini ve güvenliğini bozabilir.

Bu iki riski yönetmek zor değil ama ihmal edilmemeli. Örnekleri anonimleştirin, örnek havuzunu güvenli tutun ve düzenli denetleyin. Many-shot güçlü bir teknik; ama gücü, kullandığı örneklerin kalitesi ve güvenliği kadar. Çöp örnekler, çöp çıktı; güvensiz örnekler, güvensiz sistem.

Many-shot'u bir kez kurup unutmayın; onu ölçüp iyileştirin. Bir altın küme (test görevleri ve doğru cevapları) oluşturun ve many-shot promptunuzu bu kümeye karşı ölçün. Örnek sayısını, seçimini ve sıralamasını değiştirdiğinizde kalite nasıl değişiyor? Bu ölçüm olmadan, "sanırım daha iyi oldu" hissiyle karar verirsiniz ki bu genellikle yanıltıcıdır.

İterasyon süreci şöyle işler: temel bir örnek kümesiyle başlayın, altın kümede ölçün, modelin başarısız olduğu görev tiplerini bulun, o tipleri temsil eden örnekler ekleyin, tekrar ölçün. Bu döngü, örnek kümenizi zamanla keskinleştirir. Genellikle, hedeflenmiş birkaç iyi örnek eklemek, gelişigüzel yüz örnek eklemekten çok daha etkilidir. Nicelik değil, doğru nicelik önemli.

Son bir hatırlatma: many-shot'u bir "her derde deva" olarak görmeyin. O, prompt mühendisliği araç setinizdeki güçlü ama tek bir araç. Bazı görevlerde sıfır örnek yeterken, bazılarında many-shot parlar, bazılarında ise fine-tuning gerekir. Ustalık, her göreve doğru aracı eşleştirmekte. Bir marangoz nasıl her işe çekiçle vurmazsa, siz de her göreve yüzlerce örnek yığmayın; görevin gerçekten ne gerektirdiğini ölçün ve ona göre karar verin. Bu farkındalık, sizi hem daha ekonomik hem daha kaliteli sonuçlara götürür ve elinizdeki her aracı tam yerinde kullanmanızı sağlar.

Toparlarsak: many-shot in-context learning, uzun bağlam çağının bize verdiği güçlü bir araç. Fine-tuning'in karmaşıklığına girmeden, sadece örneklerle fine-tuning'e yakın kalite alabilmek, kurumlar için müthiş bir esneklik. Doğru kullanmanın yolu şu: önce many-shot deneyin, prompt caching ile maliyeti yönetin, örnekleri temsil edici ve çeşitli seçin, en önemlilerini başa-sona koyun, Türkçe görevlerde Türkçe örnekler kullanın ve her şeyi bir altın kümeyle ölçüp iyileştirin. Bu disiplinle, few-shot'un basit gücünü, uzun bağlamın ölçeğiyle birleştirir ve elinizdeki modelden çok daha fazlasını çıkarırsınız.