LLM’ler çok turlu konuşmalarda yolunu kaybediyor

 (arxiv.org)
4 puan yazan GN⁺ 2025-05-16 | 1 yorum | WhatsApp'ta paylaş
  • Kullanıcının gereksinimleri tek seferde eksiksiz yazamadığı durumlarda, 15 LLM’in çok turlu ve eksik yönergeler altındaki performansı, tek turlu ve eksiksiz yönergelere kıyasla belirgin biçimde düşerek 6 üretim görevinin ortalamasında %90’dan %65’e indi
  • Deney, mevcut tek turlu benchmark yönergelerini birden fazla parçaya ayıran sharding yöntemiyle kurgulandı; böylece konuşma ilerledikçe koşullar ve bağlam aşamalı olarak ortaya çıktı
  • Performans düşüşünde, basit bir yetenek eksikliğinden çok istikrarsızlığın artması etkili oldu; 200.000’den fazla konuşmada modeller erken varsayımlara ve erken nihai yanıt verme girişimlerine aşırı bağımlı kaldı
  • Test edilen modeller Llama3.1-8B-Instruct’tan Gemini 2.5 Pro’ya kadar uzanıyordu; Code, Database, Actions, Math, Data-to-Text, Summary gibi programlama ve doğal dil üretimi görevleri birlikte kullanıldı
  • Gerçek insan-AI konuşmalarının basitleştirilmiş bir simülasyonu olsa da tüm konuşmalar görevi çözmek için yeterli bilgiyle bitecek şekilde tasarlandığından, gözlenen düşüş gerçek eksik çok turlu konuşmalardakinden daha küçük olabilir

Tek turlu değerlendirme ile gerçek konuşma kullanımı arasındaki fark

  • LLM’ler ChatGPT, Gemini, Claude gibi konuşma arayüzleri üzerinden kullanılır; kullanıcılar gereksinimlerini baştan tamamen belirtemese bile birden fazla tur boyunca isteklerini tanımlayabilir, keşfedebilir ve değiştirebilir
  • Mevcut LLM değerlendirmeleri çoğunlukla tek turlu ve eksiksiz yönerge ortamlarına odaklanırken, LLM konuşma kayıtlarında kullanıcı talimatlarının eksik olması yaygındır
  • Mevcut çok turlu değerlendirmelerin çoğu, konuşmayı bağımsız olarak değerlendirilebilen alt görevler dizisi gibi ele alan episodic yaklaşıma yakındır
    • Turlar arasında bağlamı anlamayı kısmen gerektirir, ancak eksik kullanıcı talimatlarından bilgiyi aktif biçimde birleştirme durumundan farklıdır
    • Bu tür görevler, çok turlu konuşmalarda LLM performansını olduğundan yüksek gösterebilir

Sharding ile oluşturulan eksik çok turlu konuşmalar

  • Deney, yüksek kaliteli tek turlu benchmark’ların eksiksiz yönergelerini sharded instruction biçimine dönüştürdü
    • İlk shard, görevin üst düzey amacını sunar
    • Sonraki shard’lar, özgün yönergedeki ek koşulları veya bağlamı tek tek sağlar
    • Tüm shard’lar birleştirildiğinde özgün eksiksiz yönergeyle aynı bilgiyi içerir
  • Örneğin GSM8K’daki kartopu problemi, tek bir metinde “saatte 20 adet üretme”, “15 dakikada bir 2 adet kaydetme”, “toplam 60 adet gerekli” gibi koşulların tümünü verirken, sharded sürüm bunları birden fazla turda parça parça açıklar
  • Sharding süreci yarı otomatik yürütüldü; GPT-4o adayları oluşturup doğruladıktan sonra araştırmacılar bunları gözden geçirip düzeltti

Konuşma simülasyonu yapısı

  • Çok turlu simülasyonda üç özne vardır
    • Değerlendirilen assistant: performansı ölçülecek LLM
    • user simulator: tüm sharded instruction’ı bilir ve her turda bir sonraki shard’ı açıklar
    • system: assistant yanıtını sınıflandıran ve yanıt girişimini değerlendiren bileşen
  • İlk turda user simulator yalnızca ilk shard’ı açıklar, assistant ise serbest metinle yanıt verir
  • Assistant yanıtı 7 stratejiden biri olarak sınıflandırılır
    • clarification
    • refusal
    • hedging
    • interrogation
    • discussion
    • missing
    • answer attempt
  • Yanıt answer attempt olarak sınıflandırılırsa answer extractor, kod parçacığı, sayı, SQL vb. değerlendirme için gereken yanıt aralığını çıkarır ve göreve özel evaluator puan verir
  • Konuşma iki koşuldan birinde sona erer
    • Assistant’ın yanıt girişimi doğru olarak değerlendirilir
    • Yeni tur başlarken açıklanacak başka shard kalmamıştır
  • User simulator, strategy classifier ve answer extractor, prompt tabanlı GPT-4o-mini ile uygulanmıştır
  • Yüzlerce konuşmaya elle etiketleme yapıldığında, user simulator, classifier ve extractor hataları incelenen konuşmaların %5’inden azında görüldü; assistant modellerinin aleyhine işleyen hatalar ise %2’nin altındaydı

Karşılaştırılan beş simülasyon türü

  • FULL, özgün eksiksiz yönergeyi ilk turda veren tek turlu simülasyondur ve temel performans referansı olarak kullanılır
  • SHARDED, shard’ların birden fazla turda açıklandığı çok turlu ve eksik konuşmadır; ana değerlendirme ortamıdır
  • CONCAT, shard’ları tek turda madde işaretli bir yönerge olarak birleştirip sunar
    • FULL gibi eksiklik ortadan kalkar
    • SHARDED gibi sharding sürecinde oluşan yeniden ifade korunur
    • FULL ve CONCAT’te başarılı olup SHARDED’da başarısız olunursa, neden bilgi kaybından çok çok turluluk ve eksikliğin kendisi olabilir
  • RECAP, SHARDED konuşmanın ardından en sonda tüm shard’ları tek seferde yeniden sunarak LLM’e son yanıt fırsatı verir
  • SNOWBALL, her turda yeni shard ile o ana kadar açıklanan tüm shard’ları birlikte tekrar söyleyerek her turda kümülatif bir özet sağlar

Kullanılan görevler ve benchmark’lar

  • Deney, hem programlama hem de doğal dil üretimi kullanım senaryolarını kapsayan 6 üretim görevinden oluşur
  • Her görev için 90-120 sharded instruction hazırlandı; toplamda 600 instruction bulunur
  • Görev yapısı:
    • Code: HumanEval ve LiveCodeBench tabanlı Python fonksiyonu yazma
    • Database: Spider tabanlı text-to-SQL üretimi
    • Actions: Berkeley Function Calling Leaderboard tabanlı API fonksiyon çağrısı üretimi
    • Math: GSM8K tabanlı ilkokul düzeyi matematik sözel problemleri çözme
    • Data-to-Text: ToTTo tabanlı tablo verisi açıklama cümlesi üretimi
    • Summary: Summary of a Haystack tabanlı belge kümelerini özetleme ve alıntı üretimi
  • Değerlendirme ölçütleri özgün benchmark’ların ölçütlerini yeniden kullanır
    • Code ve Database için çalıştırma tabanlı doğruluk
    • Actions ve Math için referans yanıtla anlamsal eşdeğerlik veya sayısal doğru yanıt
    • Data-to-Text için BLEU
    • Summary için bilgi kapsayıcılığını ve kaynak atfı doğruluğunu ölçen LLM-as-a-judge “Joint Score”
  • İkili doğruluk da 0-100 aralığına eşlenerek tüm görev puanları aynı ölçekte toplandı

Performans, yetenek ve istikrarsızlık ölçümü

  • LLM çıktıları olasılıksal olduğundan aynı instruction ve simülasyon türü için N=10 kez tekrar çalıştırıldı
  • Her çalıştırma 0-100 aralığında bir puanla değerlendirildi
  • Üç metrik kullanıldı
    • Ortalama performans P: tekrar çalıştırma puanlarının ortalaması
    • aptitude A90: puanların 90. yüzdelik dilimi; en iyi %10 çalıştırmadaki best-case performans tahmini
    • unreliability U90-10: 90. yüzdelik dilim ile 10. yüzdelik dilim arasındaki fark; best-case ile worst-case arasındaki uçurumu ölçer
  • Tek turda aptitude’u yüksek modellerin daha güvenilir olma eğilimi de vardı; ancak çok turda aptitude’dan bağımsız olarak tüm LLM’lerde yüksek unreliability görüldü

Büyük ölçekli deney sonuçları

  • Ana deney 600 instruction, 3 simülasyon türü (FULL, CONCAT, SHARDED) ve 15 LLM üzerinde yürütüldü
  • Her kombinasyon 10 kez tekrarlanarak 200.000’den fazla konuşma simüle edildi
  • Tüm simülasyonlar varsayılan temperature T=1 ile yapıldı; temperature’ın aptitude ve reliability üzerindeki etkisi ayrı bir yardımcı deneyde ele alındı
  • Genel olarak çok turlu ve eksik konuşmaların ortalama performansı %65 oldu; bu, tüm yönergeyi baştan alan tek turlu performans olan %90’dan 25 puan daha düşük
  • Küçük open-weight modellerden en yeni modellere kadar çok turlu performans düşüşü ortak biçimde görüldü
    • Test edilenler arasında Llama3.1-8B-Instruct gibi küçük open-weight modeller ve Gemini 2.5 Pro gibi en yeni modeller yer aldı
    • Figure 1’de Claude 3.7 Sonnet, Deepseek-R1, o3, GPT-4.1, Gemini 2.5 Pro örnek olarak gösteriliyor
  • 6 üretim görevi genelinde ortalama performans düşüşü %39; Figure 1 çok turlu ayarda yaklaşık -%35 performans düşüşü gösteriyor

Neden yolunu kaybediyor?

  • Performans düşüşü iki unsura ayrılır
    • aptitude azalması: best-case performansın kendisi bir miktar düşer
    • unreliability artışı: çalıştırmalar arasındaki kalite farkı büyük ölçüde artar
  • Figure 1’e göre çok turda aptitude -%15 düşerken unreliability +%112 artar
  • Modeller, yalnızca eksik ilk bilgilere bakarak yanlış varsayımlar üretme ve konuşmanın başlarında nihai yanıt vermeye çalışma eğilimi gösterir
  • Sonradan yeni bilgiler verilse bile daha önceki hatalı yanıt girişimlerine aşırı bağımlı kalıp yön değiştirmekte başarısız olurlar
  • Çok turlu eksik konuşmada bir kez yanlış yöne girildiğinde toparlanamama olgusu lost in conversation olarak tanımlanır

Sınırlar ve pratik sonuçlar

  • Tamamen otomatik simülasyonlar gerçek insan-AI konuşmalarını birebir temsil etmez
  • Deney ortamı basitleştirilmiş ve idealleştirilmiştir
    • Konuşmanın, görevi çözmeye yetecek bilgiyle biteceği garanti edilir
    • Gerçek ortamda ortaya çıkabilecek konuşmadan sapma gibi beklenmedik davranışlar sınırlanır
  • Bu tasarım nedeniyle gözlenen performans düşüşü, gerçek eksik çok turlu insan-AI konuşmalarında yaşanan düşüşü olduğundan düşük gösterebilir
  • LLM tabanlı konuşma ürünleri geliştiren kuruluşlar ve son kullanıcılar, çok turlu güvenilirliği tek turlu yetenekle birlikte değerlendirmelidir
  • Eksik gereksinimleri baştan eksiksiz yazmakta zorlanan acemi kullanıcılar için çok turlu performans düşüşü, AI sistemlerinin kullanım yayılımını azaltan bir neden olabilir

İlgili okumalar

1 yorum

 
GN⁺ 2025-05-16
Hacker News yorumları

  • LLM araçlarını kullanmış olan herkesin sezgisel olarak zaten bildiği şeyi bir makalenin doğrulaması sevindirici. Temiz bağlamı korumak önemli; “sohbet” yalnızca ürün arayüzünün yarattığı bir yapı ve LLM’in kendi yanıt kalitesine zarar veriyor. Bağlam bir kez kirlendiğinde toparlanmıyor; yeni bir sohbetle yeniden başlamak gerekiyor

    • Benim deneyimim de bir ölçüde bu gözlemle örtüşüyor, ama farklı durumlar da oldu. Gemini ile IPSEC sorununu 2 hafta boyunca debug ettim; en başta OPNsense ve pfSense’in IPSEC belgelerinin tamamını koyup çalışma bağlamını anlattım, ardından iki taraftaki ayarları hassas bilgileri temizledikten sonra ekledim. Sonrasında logları yükleyip soru sorup yanıt aldığım uzun bir geri bildirim döngüsü yürüttüm
      2 haftanın sonuna doğru LLM çok daha az dağınık hale geldi; forum başlıklarının ya da Stack Overflow yazılarının tamamını koyduğumda bile “burada gördüğümüz olgu bu değil. Nedeni [önceki bağlam veya bulgu]” diye ayırt edebiliyordu. Çıkmaz yolları mantıksal olarak benim elemem ve ona bildirmem gerekti, ama sonunda nedeni bulduk
      LLM’lerin karmaşık bilgiyi basite indirgemede güçlü, basit bir fikri karmaşık bir şeye genişletmede ise zayıf olduğu sözüyle de uyumlu görünüyor. Girdi çıktından daha büyük veya karmaşık olduğunda sonuçtan memnun kaldım
      Bunu LLM olmadan da yapabilirdim, ama baştan koyduğum gerçekleri unuttuğumda ya da yeni bağlamda hızlıca hatırlayamadığımda bir depo gibi yardımcı oldu; büyük log dosyalarında zaman örüntülerini bulmakta da işe yaradı. Yalnızca tek bir sorunu düzeltmekle kalmadım, çeşitli ayarları da optimize ettim ve epey şey öğrendim. Mevcut parametre durumunu ara sıra yanlış hatırladı ama düzeltmesi kolaydı. Nereye gittiğinizi biliyor ve onu bir araç olarak kullanıyorsanız yardımcı oluyor; fakat karar vermeyi ona devretmemek veya sizi yanlış yöne sürüklemesine izin vermemek gerekiyor
      Toplam kullanım yaklaşık 350k token idi. İlgili blog yazısı https://du.nkel.dev/blog/2021-11-19_pfsense_opnsense_ipsec_cgnat/ adresinde; bu belirli sorunla doğrudan örtüşmüyor. WireGuard önerilerini istemiyorum
    • Benim deneyimime birebir uyuyor. “Kirlenme” ifadesi iyi. Bir kez bir şey yanlış gidince sonraki tüm yanıtlar kötüleşiyor gibi geliyor; bu yüzden ChatGPT’nin bellek özelliğine de kararsız bakıyorum. Büyük bir sorun çıkardığını pek hissetmiyorum ama bağlamı benim tam anlayamadığım bir şekilde kirletmesi hoşuma gitmiyor
    • Uzun zamandır sohbet çatallama özelliğinin olmasını istediğimi söylüyorum. Umut vadeden bir akışı geri döndürülemez biçimde kirletmeden, konuşmanın hangi yöne gideceğini denemek istiyorum. ChatGPT’de bu yok; bunu sunan bir yer var mı merak ediyorum
    • Öğrettiğim bir numaralı ipucu, ChatGPT ve Claude’daki çok küçük, neredeyse gizli “düzenle” düğmesini aktif biçimde kullanmak. Kötü bir yanıt çıkarsa üstüne yazmaya devam etmeyin; durup düzenleyerek daha iyi bir yanıt alın ki çöp çöpü çoğaltmasın
    • Bu sorunun ilginç küçük bir örneği ilk prompt. Çünkü fiilen silinemeyen, kalıcı ve gizli bir bağlam. Şu anda Twitter’daki “Grok” botunun son zamanlarda sık sık “White Genocide”dan bahsetmeye başlaması oldukça tuhaf
      Birinin yakın zamanda prompt’u ayarlayıp beyazların soykırımı hakkında bir bakış açısı belirlemiş olması büyük olasılık; mükemmel bir sohbet botu olsaydı başka bir konu sorulduğunda bunun önemi olmazdı, ama gerçekte önemi var. Bu artık bağlamın bir parçası olduğu için bundan bahsetmeye başlıyor

  • Bu, iyi bilinen aşırı özgüven ve öz-yansıtma beceriksizliğinin bir yönü gibi görünüyor. Önsel olasılık çok düşükse daha ayrıntılı bilgi istemesi gerektiğini fark etmiyor. Akıl yürütme modellerinin çıktısına bakınca, açıklayıcı soru sorması gerektiği fikri neredeyse hiç ortaya çıkmıyor; kafası karıştığında ise kullanıcının ne demek istemiş olabileceğine dair bitmek bilmeyen tahminler yapıyor
    Bunun “insan programcıların yerini alma” fikrinin ne kadar akıllıca olduğuna dair de sonuçları var. Çünkü bu işin zor kısımlarından biri, paydaşlarla etkileşime girerek belirsiz ve çoğu zaman kafa karıştırıcı fikirleri kesin şartnamelere dönüştürmektir

    • “Öz-yansıtma beceriksizliği” konusunda, LLM’lerle çalışırken temel püf noktasının ortada gerçek bir özne olmadığını ve kullanıcının inançsızlığın askıya alınması anlatısına kapıldığını fark etmek olduğunu düşünüyorum
      Çoğu durumda kullanıcı, bir film senaryosu belgesindeki User karakterinin repliklerini yazıyor; LLM algoritması da periyodik olarak Chatbot karakterinin tamamlanmamış repliklerini otomatik tamamlıyor
      DraculaBot adlı bir vampirle röportaj yapabilirsiniz, ama o karakter yalnızca “kana susamak” ya da “yarasa sürüsüne dönüşmek” gibi yüzeysel ve kurgusal biçimlerde “öz-yansıtma” yapabilir
    • LLM’in açıklayıcı soru soramaması, muğlak biçimde tarif edilmiş açık uçlu problemleri test ederken tam olarak karşılaştığım kusurdu. Paradoksal durumları DeepSeek-R1 ve Claude-3.7-Sonnet ile denediğim bağlamdaydı; deney yazısı https://pankajpansari.github.io/posts/paradoxes/ adresinde
    • Gerçek programcılar insanların gerçekten ne istediğini anlamak için muazzam zaman harcar. LLM hâlâ tahmin etmeyi bir özellikmiş gibi ele alıyor
    • Bunu okuyunca, zeki insanların daha iyi bir Emacs doctor’a kandığı bir sahneyi izliyormuş gibi hissediyorum. LLM ne iç gözlem yapıyor ne de özgüven sahibi. “Sadece” metin otomatik tamamlama öneriyor
      Bu yüzden otomatik tamamlama kötüleşmeye başladığında yeniden başlamak gerekir. Hiçbir kavram yok; yalnızca eğitim metinlerinin gösterdiği kelimeler ve olası devam metinlerinden oluşan devasa bir yığın var
    • “İnsan programcıların yerini alma” fikriyle ilgili ironik biçimde, junior geliştiricilerle çalışmak da buna epey benziyor. İşi verdikten sonra daha sonra köpek ve el feneriyle derin ormanda aramaya gitmeniz gerekiyor. Çünkü öylece ilerliyor, varsayıyor, soru sormuyor ve sonra yolunu kaybediyor

  • Sık sık LLM’den o ana kadarki tartışmayı prompt biçiminde kısa bir özet haline getirmesini istiyorum. Bunu uygun şekilde düzenleyip yükü olmayan yeni bir konuşma başlatmak için kullanınca çok etkili oldu. Muhtemelen yakında otomatikleşir

    • Cursor bunu otomatik olarak denedi. Gemini 2.5 Pro gibi büyük bağlamlı modeller kullanmıyorsanız hâlâ böyle olabilir. Ama özetlerde atlanan ayrıntı çok fazla olduğu için olduğu gibi kullanmak zordu
    • Claude Code’da, o ana kadarki konuşmayı özetleyip bağlam token’larından tasarruf etmeyi sağlayan /compact komutu var

  • Bu yüzden TSCE’yi (Two-Step Contextual Enrichment) geliştirdim. GPT-35-turbo ile 300 görevi karıştırarak test ettiğimizde +30 yüzde puanlık iyileşme gördük.
    Ücretsiz ve açık bir framework; depoda doğrudan deneyebilirsiniz: https://github.com/AutomationOptimization/tsce_demo
    İnsanların sevmediği göze batan “em-dash”leri kaldırma göreviyle gpt-4.1 üzerinde yeniden 300 kez test ettik. Tek geçişli temel çizgi ile TSCE’yi aynı talimat ve “Remove the em-dashes from my linkedin post. . .” prompt’u ile karşılaştırdık.
    300 denemede temel çizgi 149/300 kez em-dash kaldırmada başarısız oldu; TSCE ise 18/300 kez başarısız oldu. Çalışıyor ve tüm veriler ile test script’lerinin tamamı depoda mevcut.

    • Bul-değiştir işi için fazla fazla kilovatsaat harcamışsınız gibi. text.replace("—", "-") diye bir şey duydunuz mu merak ettim.
    • Em dash temel çizgi örneğini çok az değiştirince, ek çağrı, token maliyeti ya da teknik gösteriş olmadan GPT-4.1’de %100 başarı oranı elde edildi.
      Sistem prompt’u: "Remove every em-dash (—) from the following text while leaving other characters unchanged.\n\nReturn only the cleaned text."
      Kullanıcı prompt’u:
      Temperature: 0.0

  • Bu problemi çözme üzerinde epey başarılı şekilde çalışıyorum ve yakında daha fazlasını paylaşacağım. İki sistem var; ilki LLM’in kendisi, diğeri de bir tür düşünce küratörü gibi davranıyor.
    Bağlamın bazı kısımlarını dinamik olarak ekleyip çıkarıyor; açık tanımlara değil, LLM’in “boşlukları doldurma” becerisine dayanıyor. Bu sistem, LLM’in problemi küçük işlere bölmesine yardımcı oluyor; o küçük işler de sonunda tüm işe toparlanıyor.

    • İyi fikir. Esasen sohbetin üzerinde yapılan retrieval-augmented generation (RAG).
      İleride bu tür bellek katmanı ayrımlarının daha netleşeceğini düşünüyorum. Eğitim verisinin birincil belleği, bağlamın ikincil belleği, RAG’in üçüncül belleği gibi ayrılabilir.
    • İlginç bir fikir gibi geliyor. Elinizdeki şey sadece birkaç prompt düzeyinde olsa bile bunu dünyaya açmanızı öneririm. İnsanlar görüp iyileştirebilir; iyi bir fikirse benimsenir, başkaları üzerinde çalışır ve kendi yaşamını kazanabilir.
    • Bu, Emotion Machine’deki zihinsel eleştirmen sınıfına giriyor.
    • O zaman bu Map-Reduce-of-Thought mu oluyor?

  • Başlıca sohbet araçlarında branch/fork’un temel bir özellik olmaması şaşırtıcı. Yanıt düzenleme mümkün ama bunu yapınca başka birçok bağlam kayboluyor.
    Benim akışım kabaca 1) planlama 2) uygulama 3) branch alma (özellik ya da tuhaf bağımlılık sorunu nedeniyle) 4) 2. adıma dönme. Prompt budama ve branch alma, her türlü LLM kullanımında birinci sınıf araçlar olmalı.

    • Google AI Studio’da en azından bu özellik var. Ama uygulaması epey kafa karıştırıcıydı; bu da daha “tüketici odaklı” araçlara pek girmemesinin nedeni olabilir.
    • Bir süre böyle bir şey yapmayı düşündüm. BetterChatGPT en azından geçmiş silme kullanılabilirliği açısından fena değil. Ama bir sonraki adımın branch alma olduğuna katılıyorum.

  • LLM arayüzlerini tek turlu konuşma merkezli tasarlayınca göze çarpan bir sorun var. Çoğu insan doğrusal konuşma bekliyor.
    LLM’ler için genel amaçlı bir UI olarak Telegram botu http://t.me/experai_bot yaptım; özellikleri biraz azalttım ve “yanıt olmayan mesaj yeni konuşmadır” fikri etrafında tasarladım. Bağlamı korumak istiyorsanız botun yanıtlarına yanıt vermeye devam etmeniz yeterli. İleri seviye kullanıcı olmayanlar bu fikri zor buluyor.
    OpenAI modellerinin aynı soruya yanıt verirken, çok küçük bir sistem mesajı olsa bile performansının kötüleştiğini de gördüm. Örneğin yanıttaki seçenek listesi kısalıyordu. 3.5 ve 4o’da böyleydi; en yeni modelleri bilmiyorum. Bu yüzden varsayılan olarak sistem mesajı koymamaya karar verdim. Yine de gerekirse eklenebiliyor, açıp kapatıp kombinlenebiliyor.

  • Şu an LLM alanı, aynı problemi tekrar tekrar çözen insanlarla doluymuş gibi geliyor.

    • Bazı workflow’larda sorun değil ama bu “öğrenme”den çok kedi gütmeye benziyor.
    • Herkes kendi harika prompt engineering katkısını eklemek istiyor.

  • promptdown’u yapmamın başlıca nedeni buydu. Her turda tüm sohbet geçmişini düzenleyebilmek istiyordum; sadece ekleme yapılan standart sohbet arayüzünde bunu yapmak kolay değil.
    https://github.com/t-kalinowski/promptdown

  • “Prompt engineering” terimiyle dalga geçilmesinin bir nedeni de, insanların ilk promptun önemini abartıp devam eden bağlam yönetiminin önemini hafife alması diye hep düşünmüşümdür.
    Deneyimle modeli nasıl yönlendireceğinize, ne zaman yeni bir konuşma başlatacağınıza dair bir sezgi kazanıyorsunuz. Sistem prompt’u ya da ilk prompt da önemli ama konuşmayı safça fazla uzatırsanız hiçbir şey sizi kurtaramaz.

    • Evet. Prompt engineering, mükemmel ilk cümleyi yazmaktan ibaret değil; daha çok konuşma yönetimi. Akışın ne zaman raydan çıktığını ve ne zaman sıfırlamak gerektiğini sezerek öğreniyorsunuz.