Prompt Engineering, Ölçülünce: Çıktıyı Ne Değiştirir

Ölçümlerden önce, aşağıdakilerin yarısını sessizce açıklayan bir gerçek.

Modelin hafızası yoktur. İki çağrı arasında hiçbir şeyi tutmaz — son sorunu, kendi son cevabını, eklediğin dosyayı, hatta ona zaten iki kez sorduğun gerçeğini bile. Her çağrı boş bir makineden başlar ve o makinenin bildiği tek şey, ona az önce verdiğin token dizisidir.

Bir chat arayüzünde hafıza gibi görünen şey, client’ının tüm konuşmayı, her turn’ü, baştan itibaren yeniden göndermesidir. Model her seferinde hepsini sıfırdan tekrar okur. Bölüm 13 bu yeniden okumanın bir forward pass içinde neye mal olduğunu ölçtü; Bölüm 16 bunu faturadaki bir satıra dönüştürüyor. Burada tasarım açısından önemli olan sonuç şu: prompt, state’i olan bir sisteme gönderilen bir mesaj değildir. State’in kendisidir.

Bu, bir grup kafa karışıklığını emekliye ayırır. “Model ona söylediğimi unuttu” genellikle bunun hiç gönderilmediği anlamına gelir. “Önceki talimatımı görmezden geldi” genellikle geçmiş kırpıldığında talimatın window dışına düştüğü anlamına gelir. “Production’da farklı davrandı” genellikle production’ın test ettiğinden farklı bir prompt birleştirdiği anlamına gelir. Bunların hiçbiri model problemi değildir ve hiçbiri bir şeyi yeniden ifade ederek çözülmez.

“Bu prompt daha iyi” iddiası bir dağılım hakkındaki iddiadır ve tek bir çıktıya bakarak bir dağılım göremezsin. İhtiyacın olan şey sıkıcıdır: bilinen cevapları olan vakalar, N varyant ve bir aralık.

Harness, Bölüm 14’teki client ile aynı şekle sahip elli satırlık TypeScript’tir — bir request, bir deadline, biraz concurrency, bir sayım. Bölüm 19’da bir retriever’ı değerlendirmek için ve Bölüm 29’da golden set olarak tekrar ortaya çıkar.

export type Case = { input: string; expected: string };
export type Variant = { name: string; build: (c: Case) => ChatMessage[] };

async function pooled<T, R>(xs: T[], n: number, f: (x: T) => Promise<R>) {
  const out: R[] = new Array(xs.length);
  let i = 0;
  await Promise.all(
    Array.from({ length: n }, async () => {
      while (i < xs.length) {
        const k = i++;
        out[k] = await f(xs[k]);
      }
    }),
  );
  return out;
}

export async function runVariant(v: Variant, cases: Case[], concurrency = 6) {
  const hits = await pooled(cases, concurrency, async (c) => {
    const answer = await complete(v.build(c));      
    return answer.trim().toLowerCase() === c.expected;
  });
  return { name: v.name, hits, k: hits.filter(Boolean).length, n: cases.length };
}

Geri dönen sayı sonuç değildir. Sonuç budur:

/** 95 % Wilson score interval for a proportion. Chapter 4 derives it. */
export function wilson(k: number, n: number, z = 1.96) {
  const p = k / n;
  const d = 1 + (z * z) / n;
  const centre = (p + (z * z) / (2 * n)) / d;
  const half = (z * Math.sqrt((p * (1 - p)) / n + (z * z) / (4 * n * n))) / d;
  return [Math.max(0, centre - half), Math.min(1, centre + half)] as const;
}

Bölüm 4 argümanı kurdu, bu bölüm de onu tahsil ediyor. Yirmide on yedi doğru %85’tir ve %95 aralığı %64’ten %95’e uzanır. 20’de 13 alan bir varyant — %65, açıkça daha kötü hissettirir — %43 ile %82 arasında bir aralığa sahiptir. Bu iki aralık neredeyse tüm uzunlukları boyunca çakışır. Yirmi vaka iyi bir prompt’u orta halli olandan ayıramaz ve yayımlanmış prompt tavsiyelerinin çoğu daha azıyla doğrulanmıştır.

Bu bölümün kullandığı altmış vaka hâlâ çok değildir. Büyük etkileri görmek için yeterlidir ve küçük etkileri göremediğinde bunu kabul edecek kadar dürüsttür — aşağıda bunu birkaç kez yapacak.

Üç blok — kurallar R, ticket T, talimat I — tek bir user message içine birleştirildi. Altı permütasyonun tamamı, byte düzeyinde özdeş içerik, her biri altmış vaka.

En iyiden en kötüye fark 28,3 puan ve aralıklar çakışmıyor; yani bu, gürültüyle ilgili bir hikâye değil. Her arm aynı altmış item üzerinde skorlandığı için daha keskin soru paired olandır: iki arm’ın anlaşamadığı vakalarda bölünme ne kadar tek taraflı? En kötü sıradan en iyi sıraya geçiş 21 vakayı doğruya, 4 vakayı yanlışa çevirdi — exact paired probability 0,0009.³

Tabloyu kazananı için değil, şekli için oku. En iyi iki satır da ticket ile bitiyor; en kötü iki satır talimatı ya ortaya gömüyor ya da veriden sonra sürüklüyor. Bu, Liu ve arkadaşlarının Lost in the Middle adını verdiği fenomenin aynısıdır: bir prompt’un kenarlarındaki materyal, merkezdeki materyalden daha güvenilir kullanılır.⁴ Bölüm 16 window’un fiyatını çıkarıyor; Bölüm 24 ise etkiyi uzunlukta düzgün biçimde ölçüyor: orada orta kısım tarif edildiği gibi çöküyor ve en sondaki toparlanma yeniden görünmüyor. Burada pratik kural kendiliğinden çıkıyor: görev üstte, veri altta, ortada önemli hiçbir şey yok.

Şimdi aynı kelimeleri turn’ler arasında taşı. Bölüm 11, chat template’in modelin etrafındaki dekorasyon değil, onun bir parçası olduğunu ortaya koydu — <|im_start|>system ve <|im_start|>user, modelin fine-tuning sırasında tam da bu pozisyonlarda milyonlarca kez gördüğü gerçek token’lar. Bu yüzden talimatının bu marker’ların hangi tarafına düştüğü önemli olmalı; ve oluyor:

Kuralları ve talimatı template sınırının öbür tarafına taşımak 21,7 puan kazandırdı — 19 vaka kazanıldı, 6 kaybedildi, paired probability 0,0146 — üstelik tek bir karakter değiştirmeden. System prompt versus user prompt sorusunun somut cevabı budur: bunlar aynı şeyi söylemenin iki yolu değildir. Modelin üzerinde eğitildiği bir yapıda iki farklı token pozisyonudur ve system pozisyonu, tüm konuşmaya uygulanacak talimatların ait olduğu yerdir.

Üçüncü satıra da dikkat et. Ticket’tan sonra talimatı tekrarlamak — yaygın önerilen bir taktik — onu bir kez söylemenin altında skor aldı. Bu modelde, bu görevde, iki kez söylemek bir kez söylemekten kötüydü.

Aynı prompt, en iyi yerleşim, altmış vaka. Değişen tek şey ticket metninin etrafında ne olduğudur.

Noktalama işaretinden on sekiz puanlık yayılım. Ama iki uç aralığa bak: [73,9, 91,9] ve [54,1, 77,3]. Çakışıyorlar. Kaba okumaya göre — hata çubuklarını karşılaştır, değiyorlarsa hiçbir şey söyleme — bu tablo hiçbir şeyi kanıtlamaz.

Kaba okuma burada yanlış ve nedenini anlamak tablodan daha değerlidir. Her varyant aynı altmış ticket üzerinde skorlandı; yani iki ölçüm bağımsız örneklem değildir, paired’dır. Her aralığın genişliğinin çoğu, iki arm’ın paylaştığı bir belirsizlik kaynağından gelir — bu altmış ticket’ın temsil edici olup olmadığı — ve onları birbirleriyle karşılaştırdığında bu kaynak iptal olur. Bunun yerine paired soruyu sor ve cevap keskindir: çift tırnaktan XML tag’e geçmek 12 vakayı doğruya, 1 vakayı yanlışa çevirdi; paired probability 0,0034. Bu gerçek bir farktır.

Sonra aynı test manşeti söndürür. XML tag, düz Ticket: label’ını 8,3 puan geçti; bir blog yazısının başlığına koyacağı sayı budur. Paired: 6 kazanım, 1 kayıp, probability 0,1250. Kanıtlanmış değil. O ünlü iyileştirmenin dayandığı şey yedi vakadır.

Yani iki farklı soru ve iki farklı araç var; bunları karıştırmak prompt tavsiyesinin aynı anda iki yönde de yanlış gitmesine yol açar:

Genel bulgu — modellerin semantik içerik taşımayan biçimlendirme seçimlerine güçlü ve öngörülemez biçimde duyarlı olduğu — yeni değil. Sclar ve arkadaşları düzinelerce görevde sadece ayırıcıları, boşlukları ve büyük-küçük harfi değiştirdi ve doğruluk yayılımlarının yayımlanmış model sıralamalarını tersine çevirecek kadar geniş olduğunu buldu.⁵ Pratik sonuç “XML tag kullan” değildir. Sonuç şudur: formatting bir hyperparameter’dır, sweep etmenin maliyeti yoktur ve tek bir formatı sabitleyen iki model karşılaştırması, modeller kadar formatları da karşılaştırır.

In-context learning — modele prompt içinde çalışılmış örnekler göstermek ve herhangi bir weight update olmadan onlardan genelleme yapmasını sağlamak — GPT-3’ü ünlü yapan kabiliyettir.⁶ Pratik soru hiçbir zaman çalışıp çalışmadığı değildir. Kaç örnek için ödeme yapmaya değeceğidir.

Örnekler, template’in üzerinde eğitildiği yapı bu olduğu için, gerçek prior turn’ler olarak, user ve assistant dönüşümlü biçimde girer. Her k, on altı etiketli ticket’tan oluşan ayrık bir havuzdan beş farklı random draw ile çalıştırıldı:

İki örnek yedi puan kazandırdı. Sonraki altı örnek ölçülebilir hiçbir şey kazandırmadı — 83,7, sonra 81,7, sonra 83,7; kendi gürültüsü içinde dolaşan bir dizi. On altı örnek bir beş buçuk puan daha kazandırdı. Eğri pürüzsüz bir tırmanış değil; bir basamak, bir plato ve bir basamak.

En önemli sütun son sütundur. k = 8 seviyesinde, tesadüfen hangi sekiz örneği seçtiğin doğruluğu 10 puan oynattı — iki örnekten sekize çıkmanın tüm kazancından büyük. En alt satır bunun en keskin versiyonudur: k = 16 seviyesinde havuz tükenir; yani beş run’ın tamamı tam olarak aynı on altı örneği içerir, yalnızca göründükleri sıra farklıdır. Sadece sıra doğruluğu 8,3 puan oynattı.

Lu ve arkadaşlarının raporladığı sonuç budur ve arandığı her yerde hayatta kalır: örnek sıralaması, etkisi örnek sayısıyla kıyaslanabilir gerçek bir hyperparameter’dır.⁷ Bu yüzden few-shot prompting hakkındaki dürüst tavsiye bir sayı değildir. Şudur:

Şimdi folklor. Bunların her biri, bunun dışında özdeş olan bir system prompt’un başına eklenen tek bir cümledir; aynı altmış vaka üzerinde.

Beşin dördü hiçbir şey yapmadı. “Biraz yaptı” değil; altmış paired vakanın görebileceği hiçbir şey yapmadı. Uzman persona’sı ve rüşvet, dokunulmamış baseline’ın altında skor aldı; o düşüşler bile paired test’i geçemiyor — aşağı yönü işaret eden gürültüler.

Üzerinde durulacak satır üçüncüsü. “Bu kariyerim için çok önemli” tam olarak aynı doğruluğu üretti, 60’ta 46 — ve altmış cevabın onu değişti, beşi her yönde. Özet istatistik aynıydı, davranış aynı değildi. Değerlendirmen küçük bir set üzerindeki tek bir sayıysa, çıktılarının altıda birini yeniden yazan bir değişiklik hiçbir şey yapmamış gibi görünebilir ve bunu bedava olduğuna inanarak ship edersin.

Sonra tehdit var; iğneyi oynatan tek cümle bu ve onu 35 puan aşağı oynattı, 24 vakayı doğrudan yanlışa çevirdi. Bu bir yuvarlama artefact’ı değil; farklı bir model davranışı. Ders “bir modeli asla tehdit etme” değildir. Ders, duygusal çerçevenin inert olmadığıdır. Dağılımı kaydırır, bazen sert biçimde; üstelik cümleyi okuyarak kimsenin tahmin edemeyeceği bir yöne. Tam da bu yüzden hakkında akıl yürütülmek yerine ölçülmelidir.

Bu bölümün sana borçlu olduğu bir caveat: Bu beş cümle tek bir küçük modelde ve tek bir görevde test edildi. Bazılarının başka yerlerde yayımlanmış desteği var — “derin bir nefes al” yüksek skor alan talimatları icat etmek yerine onları arayan bir makaleden çıktı; bu, sonradan dolaşıma giren iddiadan farklı ve daha iyi bir iddiadır.⁸ Genelleşen şey cümleler değil. Blog yazılarında hayatta kalan liste ile ölçümde hayatta kalan listenin iki farklı liste olmasıdır; hangisini tuttuğunu bilmenin tek yolu bench’i çalıştırmaktır.

Herkesin tekrarladığı bir kural — ne istemediğini değil, ne istediğini söyle — ve her zamanki gibi yanında sayı yok. İşte sayı. Aynı format gereksinimi, üç farklı biçimde yazıldı; modelin serbest üretmesine izin verildi ki uyum gözlemlenebilsin:

Üç yasak, tek bir talimattan kötü performans gösterdi ve modele beş kat daha fazla metin yazdırdı — üçünün de aynı anda tam tersi. Pozitif cümleyi geri eklemek bunu %68’e kurtardı.

Mekanizma Bölüm 8’i hatırladığında gizemli değildir. Model, kendinden önceki her şeye koşullanmış bir dağılımdan next token seçer ve bir yasak, yasaklanan şeyi bu koşullamanın içine koyar. Negation için bir operator yoktur; artık bir kelimenin göründüğü bir context vardır.

Bu doğrudan ölçülebilir. Baseline prompt’u al ve bir satır ekle: Do not use the shipping queue for software problems. Sonra yalnızca shipping ticket’ı olmayan kırk beş ticket’a bak:

Bir kuyruğu elemek için adını söylemek, modelin onu üç kat daha sık seçmesine neden oldu, ona atadığı probability mass’i neredeyse üçe katladı ve genel doğruluktan 25 puan götürdü — 16 vaka kaybedildi, 1 kazanıldı, paired probability 0,0003.

Bir fili düşünme, ölçülmüş hali. Rewrite her zaman aynıdır: yasağı gereksiz kılan pozitif kuralla değiştir. “Software problemleri için shipping kullanma” değil; “shipping’i yalnızca fiziksel bir paket söz konusu olduğunda kullan”.

Bölüm 12 chain of thought’u düzgün inşa etti — önce bir prompting tekniği olarak,⁹¹⁰ sonra doğrulanabilir ödüllerle eğitilmiş bir şey olarak — ve bu bölüme ertelediği bir uyarıyla bitti: bir modele adım adım düşünmesini söylemek, model kendi başına akıl yürütmeye başladığında yardımcı olmayı bırakır ve zarar verebilir. İşte o uyarı, altında bir tabloyla; daha fazla düşünmenin daha iyi olması gerektiğini varsaymanın kolay olduğu bir görevde.

İki arm da aynı instrument ile aynı pozisyonda okunur. Tek fark, modelin kendisinin yazdığı bir chain of thought’un önce context içinde durup durmamasıdır.

Doğruluk düştü, maliyet arttı; ve bu bölümün kendi kuralı kendi sonucuna da uygulanır: düşüş 7 vaka kazanıma karşı 10 kayıp, paired probability 0,629; yani kanıtlanmış değil. Kanıtlanmış olan şey, çağrı başına doksan sekiz ekstra output token ürettiği ve ölçülebilir hiçbir şey satın almadığıdır. Belirsizlik tamamen fayda tarafındadır. Fatura kesindir.

Başarısız olan bir chain, çalışan bir chain’den daha öğreticidir. “Slack integration’ın Salı gününden sonra mesaj göndermeyi bıraktı” hakkında akıl yürütmesi istendiğinde model şunu yazdı:

1. Check if the issue persists on Monday.
2. Verify if there are any updates or changes in your Slack setup that
   might affect message posting.
3. If no update has been made since Tuesday, check for any recent system
   restarts or downtime affecting Slack functionality.
4. If you have recently installed new software or updated your
   environment, ensure it's compatible with Slack version.
5. Contact Slack support for further assistance or troubleshooting steps.

Bu yetkin troubleshooting tavsiyesidir ve görev bu değildir. Düşünmesi istendiğinde model, eğitim verilerinde “bu destek ticket’ı hakkında adım adım düşün” ifadesinin en çok benzediği türe kaydı — sonra bir sınıflandırma sorusunu kendi context’i içinde beş yüz karakterlik alakasız akıl yürütmeyle cevapladı. Chain of thought, hesaplanmaya değer ara state içeren problemlerde yardımcı olur: aritmetik, multi-hop lookup’lar, constraint satisfaction. Bir cümleyi dört bucket’tan birine yönlendirmede ara state yoktur. Chain’in tutacağı hiçbir şey yoktur; bu yüzden yaptığı tek şey, nihai kararın sonra içinden sağ çıkması gereken makul metin eklemektir.

İki pratik sonuç. Birincisi, akıl yürütmek üzere eğitilmiş bir model için — Bölüm 12’nin RLVR modelleri — talimat gereksiz olmaktan kötüdür: modelin üreteceği uzun chain’i kısa, prompt şekilli bir chain ile değiştirebilir. Ve self-consistency’nin yaptığı gibi birkaç chain örnekleyip oylamak,¹¹ üzerinde anlaşmazlık olacak hiçbir şey bulunmayan bir görevi kurtaramaz: olmayan beraberlikleri bozmak için maliyeti sample sayısıyla çarpar. Bölüm 12 bu trade’i geçerli olduğu yerde ölçtü. İkincisi, karşılaştırma scaffold’unun kendisinin neye mal olduğuna dikkat et. Cevabı bir Final queue: satırına zorlamak, no-reasoning arm’ı %76,7’den %61,7’ye düşürdü. On beş puan, iki arm’ı karşılaştırılabilir yapmak için ödendi. Senin kolaylığın için var olan yapı da bedava değildir.

Son bir ölçüm; çünkü ilk şaşırtıcı sonuçtan sonra herkesin sorduğu soru bu. Altmış prompt, greedy decoding, tekrar tekrar çalıştırıldı:

• Aynı çağrı, her şey sabit tutulup tekrarlandığında bit-identical olasılıklar döndürdü. Deterministic.
• Aynı çağrı farklı komşularla batch’lendiğinde — batch size 1, 4, 12, 30 ve 60 — olasılıklar 0,0128’e kadar farklılaştı. Seçilen label 60 vakanın 0’ında değişti.

Label hayatta kaldı çünkü alanı vardı: altmış vaka genelinde en yüksek iki kuyruk arasındaki en dar gap 0,0459 idi, drift’in üç buçuk katı. Stabilite algoritmanın bir özelliği değildi. Bir margin’di ve margin’ler tükenir. Bölüm 17, aritmetik nedenin yaşadığı ve o gap’leri genişletip daraltan sampling knob’larının parçalara ayrıldığı yerdir. Bunu buraya dikmenin nedeni, herhangi bir prompt ölçümünün ne anlama gelebileceğini sınırlamasıdır: bench, yalnızca bir toleransa kadar yeniden üretilebilir olan bir sistemi ölçer ve varyantlar arasındaki iki puanlık fark kötü bir günde o toleransın içindedir.

Yukarıdaki her şey, bir insanın varyant seçmesi ve bir makinenin onu puanlamasıdır. Bariz sonraki adım, varyantları da makinenin seçmesine izin vermektir.

APE tam olarak bunu yapar: bir model aday talimatlar önerir, bunlar held-out örneklerde skorlanır ve en iyiler hayatta kalır.⁸ Bulduğu talimatlar çoğu zaman hiçbir insanın yazmayacağı şeylerdir; amaç da budur — arama, profesyonel duyulana değil, skor alana yapılır.

DSPy daha ileri gider ve bir ürün için daha kullanışlı fikirdir.¹² Bir pipeline’ın her adımının ne aldığı ve ne döndürdüğünü bildirirsin; framework bunu prompt’lara compile eder, demonstration’ları seçer ve talimatları metriğine göre optimize eder. Model değiştirince yeniden yazmak yerine recompile edersin. Prompt, birinin elle tune ettiği source code olmaktan çıkar ve bir metriğe karşı üretilmiş artefact haline gelir; en başından beri olması gereken de buydu.

Hiçbiri bench ihtiyacını ortadan kaldırmaz. İkisi de bench’i ihtiyacın olan tek şey yapar; çünkü metriği olmayan bir optimizer hiçbir şeyi optimize etmez.

Geriye discipline kalıyor. Prompt’lar version control’de, dosyalarda, onları gönderen kodun yanında olmalıdır — birinin Salı günü düzenlediği database satırında değil. Ürettikleri her output’un yanında saklanan bir version identifier’a ihtiyaçları var; yoksa bir şey regresse ettiğinde neyin değiştiğini bulamazsın. Continuous integration içinde bench’e ihtiyaçları var; çünkü prompt, sisteminin bir vendor tarafından yeni bir model deploy edilerek sessizce geçersiz kılınabilecek tek parçasıdır. Ve vakalara ihtiyaçları var: yüz tane zeki vaka değil, geçen çeyrekte kırılan sıkıcı yirmi vaka; sonsuza kadar saklanmalı. Teslimat bench’tir. Prompt onun yan ürünüdür.

Bu bölümdeki her şey doğrulukla ölçüldü. O varyantların her birinin bir fiyatı da var.

21,7 puan kazandıran system prompt her çağrıda, sonsuza kadar gönderilir. Yedi puan kazandıran iki örnek her çağrıda, sonsuza kadar gönderilir. On iki puan kazandıran on altı örnek her çağrıda, sonsuza kadar gönderilir ve kullanıcının gerçekten sorduğu sorunun yaklaşık on katı uzunluğundadır. Hiçbir şey kazandırmayan chain of thought, request başına doksan sekiz ekstra token üretti ve output token’lar pahalı olan türdür.

Bunların hiçbiri doğruluk tablolarında görünmez ve hepsi faturada görünür.

Bölüm 16, bu kararların gerçekte denominated olduğu birim hakkındadır. Billing unit olarak token, hafıza değil budget olarak context window, kırk turn’lük bir konuşmanın neden ilk turn’ün kırk katından çok daha pahalı olduğu, prompt caching’in neyi ödediği ve neyi ödemediği, prompt’unun sırasının cache hit olup olmayacağını neden belirlediği — bunun stable materyali başa, variable materyali sona koymak için ikinci, tamamen ekonomik bir neden olduğu ortaya çıkar.

Bench ve her tablo greedy decoding altında Qwen/Qwen2.5-0.5B-Instruct ile üretildi; bu yüzden tam olarak yeniden üretilirler. Hugging Face’in chat template dokümantasyonu, Bölüm 11’deki template marker’larının gerçekte neye expand ettiğine ve yanlış template ile ship edilen bir modelin gerçek ve tekrarlayan bir failure olduğuna dair referanstır. Laboratory scale yerine production scale’de position ve format effect’leri için yukarıdaki atıflar primary source’lardır; vendor prompting guide’ları örnekleri açısından faydalıdır ve hiçbirinin bir aralık yayımlamadığı bilinerek okunmalıdır.