Çok turlu konuşmalarda LLM yönünü kaybediyor

 (arxiv.org)
4 puan yazan GN⁺ 2025-05-16 | 1 yorum | WhatsApp'ta paylaş
  • Büyük dil modelleri (LLM), çok turlu konuşmalarda performans düşüşü ve güvenilirlik azalması gösteriyor
  • Tek turlu duruma kıyasla çok turlu senaryolarda ortalama %39 performans düşüşü deneysel olarak doğrulandı
  • Başlıca nedenler, küçük bir yetenek azalması ve çok daha büyük bir güvenilirlik kaybı, yani sonuçlarda tutarlılık eksikliği
  • LLM'ler erken aşamada yanlış varsayımlar kurma ya da nihai cevabı fazla erken deneme eğiliminde
  • Sonuç olarak, LLM konuşmanın başında hata yaptığında toparlanamayıp konuşmanın yönünü kaybettiği görüldü

ABSTRACT

  • Büyük dil modelleri (LLM), kullanıcı isteklerini tam olarak ifade edemediğinde bile çok turlu konuşmalar yoluyla gereksinimleri kademeli olarak tanımlama, keşfetme ve düzeltmeye yardımcı olabilecek etkileşimli arayüzlerdir
  • Ancak LLM değerlendirmelerinin çoğu yalnızca tek turlu, tam belirtimli talimat ortamlarına odaklanırken, gerçek konuşma günlüklerinin analizi yetersiz belirtim (underspecification) olgusunun sık görüldüğünü gösteriyor
  • Bu çalışma, tek turlu ve çok turlu (yetersiz belirtilmiş) ortamlarda LLM performansını büyük ölçekte simüle ederek karşılaştırıyor
  • Sonuçta, 15 büyük LLM'in tamamında çok turlu konuşmalarda ortalama %39 performans düşüşü gözlendi; bunun hafif yetenek kaybı ve keskin güvenilirlik düşüşü ile açıklanabildiği bulundu
  • LLM erken aşamada yanlış bir yol seçtiğinde daha sonra toparlanamayıp yönünü kaybederek oyalanma eğilimi gösterdiği saptandı

Introduction

  • Güncel LLM'ler (ör. ChatGPT, Gemini, Claude vb.) çok turlu konuşmayı destekleyen arayüzlerdir
  • Kullanıcı en başta tüm gereksinimleri açıkça tanımlamasa bile, yinelemeli soru-cevap süreciyle (underspecified → refined) istekler kademeli olarak netleştirilebilir
  • Gerçekte birçok kullanıcı konuşmanın başında belirsiz istekler sunmasına rağmen, değerlendirmelerin çoğu yalnızca tek turlu tam belirtimli ortamda yapılmaktadır
  • Bazı önceki çalışmalar çok turlu değerlendirme denese de, konuşmanın her turunu bağımsız bir bölüm gibi ele aldıkları için gerçek insan konuşmalarında yaygın olan belirsizliğin etkisini olduğundan az değerlendiriyorlar
  • Bu çalışma bu boşluğu kapatmak için, sharded simulation (bilgiyi birden fazla parçaya bölüp her turda yalnızca bir parçayı açığa çıkarma) adlı bir ortam önererek çok turlu, belirsiz talimat durumlarını ayrıntılı biçimde simüle ediyor

Başlıca araştırma bulgularının özeti

  • LLM, tek turda tüm talimatı bir kerede aldığında %90 performans gösterirken, çok turlu ve belirsiz talimat durumunda bu oran %65'e düştü (ortalama 25 puan kayıp)
  • Bu olgu yalnızca iki konuşma turu sonrasında bile ortaya çıkıyor ve açık/kapalı, büyük/küçük tüm LLM'lerde ortak biçimde gözleniyor
  • Performans düşüşünün neden analizi, (1) yetenek kaybı (aptitude loss) ve (2) güvenilirlikte (unreliability) keskin artış olduğunu gösteriyor
    • Tek turda yeteneği yüksek modellerin güvenilirliği de yüksekken, çok turda güvenilirlik yetenekten bağımsız olarak düşük
    • Yani LLM çok turlu konuşma sırasında yanlış bir yöne girdiğinde geri dönemiyor — bu durum “lost in conversation” olarak adlandırılıyor
  • Başlıca nedenler
    • Gereğinden uzun yanıtlar ve nihai cevaba aceleyle ulaşma girişimi
    • Belirsiz bilgi üzerine yanlış varsayımlar
    • Önceki yanlış denemelere aşırı bağımlılık
  • Gerçek LLM kullanım sahası ile model değerlendirme biçimi arasında büyük bir boşluk bulunuyor
    • Özellikle acemi kullanıcılar başlangıçta eksik talimat verme eğiliminde olduğundan, bu olgu gerçek dünyadaki uygulamaları zorlaştıran başlıca nedenlerden biri
  • Makalenin yapısı: önceki çalışmaların özeti, simülasyon ortamının açıklaması, 6 üretim görevi ve değerlendirme ölçütleri, 15 LLM ile büyük ölçekli deneyler ve sonuçlar ile iş/pratik ve ürün uygulamalarına yönelik çıkarımlar ve somut öneriler

Background and Related Work

  • Önceki nesil dil modelleri (ör. BART, GPT-2, T5), gerçekte çok turlu konuşmalara uygun olmadıkları için çoğunlukla tek tur odaklı değerlendirildi
  • ChatGPT'nin ortaya çıkışından sonra çok turlu değerlendirmeye ilgi arttı ve MT-bench gibi crowdsourcing tabanlı değerlendirmeler yapıldı
  • Ancak değerlendirme çerçevelerinin çoğu bölümsel konuşma düzeyinde kaldığından (her turun ayrı değerlendirilmesi), gerçek belirsiz konuşmaların sürekliliği hesaba katılmıyor
  • Gerçekte insanlar “en az çaba ilkesi” gereği sık sık belirsiz talimatlar verir (a.k.a. underspecification); LLM'ler de bilgi eksikliğinde erken sonuca varma ve yetersiz uyum sağlama gibi nedenlerle performans kaybı yaşıyor
  • Bu çalışma, belirsizliğin merkezde olduğu gerçek ortamlara daha yakın bir değerlendirme hedefiyle tasarlandı

Simulating Underspecified, Multi-Turn Conversation

3.1 Sharding Process

  • Başlangıçtaki tam belirtimli talimat, birden fazla shard'a (bilgi parçası) bölünüyor
    • Örnek: Tüm koşulları tek bir cümlede vermek yerine, her turda tek bir bilgi (durum tanımı, sayısal değer, koşul vb.) açığa çıkarılıyor
  • İlk shard her zaman talimatın üst düzey amacını açıklar; sonraki shard'lar ise ek bilgileri (bağlam, koşullar vb.) her turda kademeli olarak sunar
  • Bu sharding süreci, LLM (GPT-4o) önerisi+doğrulaması ve manuel tamamlamayla yüksek kaliteli çok turlu talimat veri kümesi oluşturmak için kullanıldı
  • Her görev için 90–120 adet sharded instruction üretildi (saatler süren manuel inceleme ile)

3.2 Simulating Sharded Conversations

  • Konuşma simülasyonu üç rolden oluşuyor: değerlendirilen LLM (assistant), tüm shard'ları bilen user simulator ve yanıt sınıflandırma/puanlama sistemi
  • İlk turda user simulator yalnızca ilk shard'ı assistant'a verir → assistant yanıt verir → stratejisi (netleştirme, soru sorma, doğru cevabı deneme vb.) sınıflandırılır ve yanıt çıkarılır → doğruluk değerlendirilir
  • Sonraki turlarda kalan shard'lardan yalnızca biri ek olarak açığa çıkarılır ve süreç tekrarlanır / assistant her turda serbestçe yanıt verebilir
  • Konuşmanın bitişi: (1) değerlendirici doğru cevabı onayladığında veya (2) verilecek shard kalmadığında
  • User simulator, doğal shard sunumu ve otomatik yeniden ifade etme yeteneğine sahip bir LLM (GPT-4o-mini) ile uygulanmıştır
  • Tüm deneylerde yardımcı LLM'in yanlış sınıflandırma ve çıkarım hataları %5'in altında, assistant aleyhine olan durumlar ise %2'nin altında kaldı
  • Assistant, bu ortama dair özel bir bilgi verilmeden varsayılan durumda değerlendirildi (gerçek kullanıma benzer şekilde senaryo bilgisi ayrıca sağlanmadı)

3.3 Simulation Types

  • FULLY-SPECIFIED (FULL): Tüm talimatın tek turda verilmesi, temel performansı ölçmek için
  • SHARDED: Her turda yalnızca bir bilgi parçasının açığa çıkması; çalışmanın çok turlu belirsiz konuşmaya yönelik temel deneyi
  • CONCAT: Tüm sharded instruction'ın bir kerede madde işaretli olarak verilmesi; yalnızca talimat bilgisindeki kaybı değerlendirmek için
  • RECAP: Sharded konuşmadan sonra son aşamada tüm shard'ların özetlenip yeniden verilmesi; basit bir agent benzeri müdahale denemesi
  • SNOWBALL: Her turda yeni shard eklenirken daha önce açığa çıkan tüm shard'ların da tekrar edilmesi; assistant'ın bilgiyi kaçırmamasını sağlamak için yinelenen hatırlatma (bellek güçlendirme deneyi)

Task and Metric Selection

4.1 Task Selection

  • Toplam 6 görev: programlama (Code), veritabanı (SQL üretimi), API function calling (Actions), matematik (Math), tablo→metin (Data-to-Text), soru-cevap tabanlı özetleme (Summary)
    • Örnekler: Python fonksiyonu yazma, doğal dil → SQL sorgusu dönüştürme vb.
  • Her görev için yüksek kaliteli benchmark'lardan 90–120 talimat seçildi; sharding sonrasında manuel doğrulama yapıldı
  • Altı görevin tamamı programlama/programlama dışı alanları kapsayan temsil gücü yüksek görevlerdir ve Summary gibi long context gerektiren çeşitli senaryoları içerir

4.2 Metric Selection

  • Değerlendirme ölçütleri
    • Ortalama performans (P): birden çok simülasyondan elde edilen ortalama skor (0~100)
    • Yetenek (A90): simülasyon sonuçlarının üst %10'luk değeri (90th percentile, best-case)
    • Güvenilirlik (U90_10): üst %90 ile alt %10 skorları arasındaki fark (sonuç tutarlılığı/değişkenliği ölçümü)
  • Örneğin bir box-plot'ta en üst kısım yeteneği, üst-alt aralığı ise güvenilirliği gösterir
  • Altı görevin tamamında tutarlı ölçütlerle puanlama yapıldı (doğruluk/benzerlik/BLEU vb.)
  • Tüm deney parametreleri, örnekler, sampling gibi ayrıntılı yöntemler ve kodlar eklerde/Appendix'te de yer alıyor

Simulation Scale and Parameters

  • Toplam 600 instruction, 6 görev için oluşturuldu ve FULL/CONCAT/SHARDED senaryolarında deneyler yapıldı
  • 15 LLM (GPT-4, Claude, Gemini vb.) için her kombinasyon 10 kez simüle edilerek 200 binden fazla deney verisi üretildi
  • Tüm deneyler temperature 1 (sampling) ile yürütüldü; ek deneylerde (7.2) temperature etkisi de analiz edildi
  • Bu büyük simülasyon veri kümesi sayesinde LLM'lerin çok turlu, yetersiz belirtilmiş konuşmalardaki davranış kalıpları ve performans düşüşünün ana nedenleri ile türleri belirlenebildi

Lost in Conversation Experiment

  • Devamında makale, deney kurulumu, tek tek model sonuçları, performans düşüşü nedenlerinin analizi, iyileştirme teknikleri (RECAP/SNOWBALL) denemeleri ile pratik çıkarımlar ve somut önerileri ayrıntılı biçimde açıklıyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-05-16
Hacker News görüşü

  • LLM araçlarını gerçekten kullanmış olan herkesin ampirik olarak zaten bildiği şeyi doğrulayan bir makale görmek sevindirici. “Sohbet” kavramı ürün arayüzünün ürettiği bir şey. Bağlamı temiz tutmak önemli. Bağlam kirlendiğinde toparlanmıyor; bu yüzden yeni bir sohbetle yeniden başlamak gerekiyor

    • Benim deneyimim de bu gözleme benziyor ama biraz farklı yönleri vardı. 2 hafta boyunca Gemini ile bir IPSEC sorununu debug ettim. Başta OPNsense ve pfSense’in IPSEC dokümantasyonunu okutup genel bağlamı verdim. Sonra yapılandırma bilgilerini paylaştım, soru-cevap şeklinde devam ettik. En sonunda LLM’in dağılması daha az oldu; hatta bazen forum yazıları ya da SO gönderileri eklediğimde LLM “bu şu anda gördüğümüz belirtiyle farklı” diyebiliyordu. Bütün çıkmaz yolları mantıksal olarak eledik; LLM düşünmeye yardımcı oldu ama kararı insanın vermesi gerekiyordu. Sonuçta sorunun kök nedenini buldum ve başkalarının da dediği gibi LLM’ler karmaşık bilgiyi sadeleştirmede güçlü ama basit kavramları karmaşıklaştırıp genişletmede zayıf. Girdi, çıktıya göre daha karmaşık ya da daha uzunsa sonuçlardan daha memnun kalıyorum. LLM olmadan da yapabilirdim ama bağlamı hatırlayamayan ya da hızlıca yeniden üretemeyen şeyleri saklaması faydalı oldu. Büyük log yığınlarında zaman örüntülerini bulmaya da yardım etti. Birçok ayarı da iyileştirdim. Sadece sorunu çözmedim, çok şey öğrendim. Durum değerlendirmesi bazen yanlıştı ama bunu kendim düzeltmek kolaydı. Yani hedefinizi biliyor ve onu araç olarak kullanıyorsanız faydalı; ama kararları ona bırakır ya da yanlış yöne çekilirsiniz etkili olmuyor. 350 bin token (yaklaşık 300 bin kelime) kullandım. Bununla ilgili bir blog yazım da var. wireguard önerisine gerek yok
    • Deneyimim tamamen aynı. “Kirlenmiş” ifadesi tam oturuyor. Bir şey yanlış giderse ondan sonraki tüm yanıtlar kötüleşmeye başlıyor. Bu yüzden ChatGPT’nin memory özelliğini sevmiyorum. Büyük bir sorun yaşamadım ama bağlam kirliliğinin tam olarak nasıl oluştuğunu anlamadığım için huzursuzum
    • Verebileceğim en iyi tavsiye, ChatGPT ve Claude’daki çok küçük ve gizli duran “düzenle” düğmesini aktif kullanmanız. Kötü bir yanıt gelirse öylece devam etmeyin; durup düzeltin ve sonra daha iyi bir yanıt alın. Yoksa karmaşa büyüyerek çoğalıyor
    • Sürekli sohbeti fork’layıp farklı yönleri denemek istiyorum. Umut vadeden bir akışta geri döndürülemez kirlilik oluşmasını önlemek isterdim. ChatGPT’de bunu kullanamıyorum; bunu sunan bir servis var mı diye merak ediyorum
    • Bu sorunun ilginç bir örneği de ilk prompt. Fiilen kalıcı ve gizli bir bağlam. Twitter’daki Grok botunun son dönemde sık sık “White Genocide” demesi, birinin prompt’u o konuya uyacak şekilde değiştirmiş olmasından kaynaklanıyor. Kusursuz bir chatbot başka konularda bundan etkilenmemeli ama gerçekte etkileniyor. Sonuçta bağlam değişti ve o konuya durmadan takılı kalıyor
    • Bu yüzden FileKitty’yi yaptım. Birden çok kaynak kod dosyasını hızlıca Markdown biçiminde birleştiren bir araç. Yazılım geliştirirken LLM’den destek alıyorsanız, kod tabanı aramasını LLM’e bırakmak hata olasılığını artırıyor. Bağlam sıkıştırmasının kayıplı olması nedeniyle çıktı da sulanabiliyor. En iyi sonuçlar için belirli bağlamı baştan netleştirmek ve sohbet sırasında ara ara yenilemek gerekiyor. Yine de sohbet uzunluğuna dikkat etmek şart. Bağlamı iyi yakalayıp yeni oturuma taşıyan prompt’lar da var. Hangi dosyaların dahil edileceğini seçip yeni prompt’a ekleyebiliyorsunuz. Bununla ilgili tartışmalar HN’de başka bir başlıkta da var
    • Bu artık iş akışımın yerleşik bir parçası oldu. Bazen LLM’e “İyi ilerliyoruz, bir sonraki adıma geçmek istiyorum; buna bu sohbette devam etmek mantıklı mı yoksa yeniden mi başlamalıyız?” diye soruyorum. Model yeni başlamanın daha iyi olacağını söylerse iyi bir özet prompt’u hazırlıyor; bazen de devam etmenin sorun olmadığını söylüyor. “İleride keşfedilecek başlangıç noktaları” gibi notlar da tutuyorum. RL tabanlı post-training süreçleri gibi nedenlerle chatbot’ların sohbeti sürdürme eğilimi var. RL’de post-training, gerçek RL’den farklı olarak yalnızca tek seferlik tercih tabanlı mekanizmalar kullanıyor. Uzun vadeli tercih ya da konuşmaların hesaplama karmaşıklığı geometrik olarak arttığı için bu konuda fazla araştırma yok
    • Sohbet geçmişini “toparlayan” bir arayüz uygulanmış mı merak ediyorum. Sohbet içindeki ölü yolları ya da alakasız kısımları temizleyen bir özellik. Tüm geçmiş korunur ama konu akışına göre gereksiz bölümler budanıp düzenlenir. Özetten ziyade organik bir düzenleme gibi
    • LLM’leri sadece otomatik tamamlama için kullanıyorum ama LLM sohbet arayüzüne bir “mesajı sil” düğmesi ya da seçeneği eklenirse bunun çözülebileceğini düşünüyorum. Son LLM mesajını silerseniz yeni bir yanıt alabilirsiniz. Özellikle yüksek rastgelelikli (temperature) LLM’lerde çok faydalı olur. Başka mesajlar silindiğinde de sonraki yanıtların etkilenebilmesi için bağlam güncellenir. Bu, kullanıcıların LLM’in zeki olduğuna dair yanılgısını da düzeltmeye yardımcı olur. Bunun zaten standart olup olmadığını bilmiyorum. Değilse bu fikri public domain’e bırakıyorum. Bir diğer pratik yaklaşım da bir “alt bağlam LLM’i” kullanıp ana bağlamı ona yönettirmek. Yani yanıt çok uzun ya da çok kapsamlı olduğunda alt LLM özetleyip düzenleyerek genel sohbet bağlamını toparlar. Ya da daha basit biçimde bir “mesaj düzenle” düğmesi olur, insan doğrudan temizler
    • Bağlam kirlendiğinde toparlamak zor. LLM’in belirli bölümlerini periyodik olarak sıfırlamak ya da temizlemek mümkün olsaydı iyileşebilirdi. Ama hangi kısmın temizleneceği ve temel bilgilerin kaybolup kaybolmayacağı ayrı bir sorun. Daha akıllı bağlam yönetimi uzun sohbetlerde tutarlılığı korumaya yardımcı olabilir ama dengeyi tutturmak zor. Belki bunu başka bir ajan otomatikleştirebilir
    • AI chatbot’larda chain-of-thought tarzı prompt’ların da aynı nedenle sınırları ortaya çıkıyor
    • “Sohbet”in yalnızca ürün arayüzünün bir ürünü olduğu fikrine dair: RL’nin multi-turn değerlendirme veri kümeleriyle eğitilmesi bu akışı değiştirdi. Context window her seferinde yeni olsa da her prompt’u daha uzun bir konuşmanın parçası olarak yorumlama eğilimi arttı. Kamusal tarafta multi-turn post-training henüz ölçeklenmiş değil ama uzun vadede daha fazla hedef başarmak için bunun devreye gireceğini düşünüyorum
    • Kod yazarken de sohbeti sürdürmek yerine sık sık yeni sohbet açıp mevcut kodu tekrar açıklayarak ilerliyorum. Bu, tek bir sohbette sürekli zorlamaktan daha iyi sonuç verdiği oluyor. Modele özetleme ve unutmayı açıkça belirten manuel komutlarla bu sorun çözülebilir gibi. Bu, insanın çalışma biçimiyle de kısmen örtüşüyor (çalışma belleği vs anlatısal/episodik bellek)
    • ChatGPT’nin en sinir bozucu özelliklerinden biri “memory”. Sohbet kirliliği sohbetler arasında da taşınabiliyor
    • “Kirlenmiş” gerçekten çok isabetli bir terim. Sohbet/API tarafında “sürüm kontrolü” olsa, önceki bir duruma rollback yapabilsek ya da yeni sohbete klonlayabilsek keşke. Hatta yazım hataları ya da mesaj düzenlemeleri bile sonraki yanıtlarda ince bir önyargı yaratabildiği için bu daha da önemli
    • zed’in sohbet UX’ini gerçekten seviyorum. Tüm sohbet geçmişini bir metin dosyası gibi düzenleyebiliyorsunuz; istemediğiniz kısımları temizleyip silebiliyor, düzeltebiliyor ve ardından çok daha temiz ve ilgili bir bağlamla sohbete devam edebiliyorsunuz. Bu yüzden zed’i programlama dışı işler için bile LLM sohbetinde ana arayüzlerimden biri olarak kullanıyorum
    • Kirlilik, alakasız sorular veya yanıtlar ile tekrar eden “seyrelme” yüzünden de oluşuyor. İçerik üretirken de başlangıçta net olan talimatların zamanla bozulduğunu sık görüyorum
    • “Sohbet yalnızca ürün arayüzünün bir ürünü” fikrini hep akılda tutmaya çalışıyorum ama pratikte türlü “sohbetimsi” ipuçları yüzünden bu kolay olmuyor
    • Memory’yi açık bıraktığıma pişman oldum. Gereksiz bilgiler yüzünden sohbet kirlendi
    • Asıl şaşırtıcı olan, modelin ne kadar erken yanlış varsayımlar yapıp onlara saplanabildiği
    • Düşününce insanlarda da bu çok oluyor
    • Artık ChatGPT “memory” ile eski sohbetlere de erişebildiği için kirlilik kalıcı hâle gelebiliyor. Bir kez yanlış bir fikre tutunursa, kullanıcı olarak bunu bir daha asla anma diye kaç kez vurgulasanız da yanıtlarına tekrar tekrar sokabiliyor. Hatta iç prompt’u (“kullanıcı çok rahatsız, xyz çıkarılmalı”) yanlışlıkla dışarı verip sonra yine xyz’ye odaklanması gibi komik durumlar olabiliyor

  • Bu, LLM’lerin iyi bilinen aşırı özgüven eğilimi, öz değerlendirme eksikliği ve daha fazla bilgi istemesi gerektiğini fark edememesinden kaynaklanan bir olgu. Akıl yürütme modeli çıktılarına bakınca, kafa karıştırıcı durumlarda LLM’in ek açıklama istemek yerine kullanıcının ne demek istediğini tahmin etmeye devam ettiğini görüyorsunuz. Bu da insan programcıların yerini alma fikrinin pratik sınırlarını gösteriyor. Çünkü asıl zor kısım, belirsiz gereksinimleri netleştiren “paydaş etkileşimi”

    • Öz değerlendirememesi meselesiyle ilgili olarak, LLM’de gerçek bir özne yok; kullanıcı bir tür “inancı sürdürme hikâyesi”ne kapılıyor. Siz bir film senaryosundaki kullanıcı rolü için metin giriyorsunuz, LLM de chatbot rolündeki eksik olay örgüsünü otomatik tamamlıyor. Örneğin DraculaBot ile yapılan bir röportajda öz değerlendirme, sadece “kana susamak” ya da “yarasa bulutuna dönüşmek” gibi yüzeysel taklitlerle karşımıza çıkıyor
    • LLM’lerin bilginin belirsiz olduğu açık uçlu problem durumlarında, özellikle paradokslarda, net biçimde ek açıklama isteyememesine ben de aynı şekilde hayal kırıklığıyla bakıyorum. Bunu DeepSeek-R1 ve Claude-3.7-Sonnet üzerinde test ettim; bununla ilgili bir deney blog yazım da var
    • Gemini 2.5 Pro ve ChatGPT-o3 ise görevi yürütmeden önce sık sık ek bilgi istiyor. Gemini bazen birden fazla seçenek de sunup benden giriş talep ediyor
    • Gerçek programcılar aslında zamanlarının çoğunu gereksinimleri netleştirmeye harcar. LLM’ler ise hâlâ tahmin yürütmeyi başlı başına bir özellik gibi görüyor
    • İronik biçimde acemi geliştiricilerle çalışırken de benzerini yaşıyoruz. Onlara iş verdiğinizde, çoğu zaman sadece dümdüz ilerleyip varsayımlarla hareket ediyorlar; hiç soru sormadan kendilerini öyle derin bir ormanda buluyorlar ki gidip kurtarmak gerekiyor
    • Bunun oldukça kolay değiştirilebileceğini düşünüyorum. Nasıl chain-of-thought prompt’ları son token’ı “hmm” gibi bir şeye çevirebiliyorsa, LLM “muhtemelen şöyledir” demeye başladığı anda token’ı “önce ek açıklama isteyeceğim”e çevirmek yeterli
    • Ek bilgi isteme ya da öz değerlendirme de, istenirse aslında gayet iyi yapılabiliyor

  • Şimdiye kadarki tartışmayı kısa bir prompt biçiminde özetletip sonra bunu kendim değiştirip düzenleyerek yeni bir sohbet başlatma tekniğini sık kullanıyorum. Bu yöntem benim için epey etkili oldu; yakında otomatikleşeceğini düşünüyorum

    • Cursor bunu otomatik yapmayı denedi ama (geniş bağlamlı bir model kullanmadığınız sürece) özet çok fazla ayrıntı kaçırdığı için pratikte pek işe yaramadı
    • Claude Code’da, konuşmayı özetleyip token kullanımını azaltan /compact komutu var

  • TSCE’yi (Two-Step Contextual Enrichment) bizzat geliştirdim. GPT-35-turbo ile 300 görevde kullanınca performans +30 puan arttı. Açık bir framework olarak serbestçe kullanılabiliyor. gpt-4.1 ile 300 ek deney daha yaptım. Baseline, em-dash kaldırma görevinde 300 denemenin 149’unda başarısız olurken TSCE yalnızca 18’inde başarısız oldu. Tüm veri ve script’ler de açık

    • Basit bir find and replace işi için kilovat-saatler boşa gidiyor. text.replace("—", "-") gibi bir şey denedin mi merak ediyorum
    • Baseline prompt’u biraz değiştirince GPT-4.1’de %100 başarı aldım. Ek çağrı, ek token harcaması ya da karmaşık teknikler olmadan da mümkün

  • İki sistemle (LMM + otomatik curator) problem çözdüğüm oldu. Biri LLM’in kendisi, diğeri de bağlamın bazı parçalarını dinamik olarak değiştirip yöneten bir “düşünce küratörü”. Katı kurallardan çok LLM’in boşluk doldurma yeteneğine dayanıyor. Problemi küçük parçalara bölerek çözmeye yardım ediyor ve bu parçaların sonuçları birleşip nihai hedefe ulaşıyor

    • Harika fikir. Şu an yaptığınız şey sohbet RAG’ine benziyor. Gelecekte bellek katmanları (eğitim verisi / mevcut bağlam / RAG) daha net ayrılacaktır
    • İlginç bir fikir bence. Basit hâliyle bile dünyayla paylaşsanız, birçok kişi onu geliştirir ve topluluk kendi kendine büyütür
    • Bu, Emotion Machine’de anlatılan içsel eleştiri sistemine benziyor
    • Üzerinde çalıştığınız proje hakkında daha fazla bilgi duymak isterdim. İlginç görünüyor
    • Yani sonuçta buna bir tür Map-Reduce-of-Thought denebilir

  • Ana sohbet araçlarında branching/forking’in temel özellik olmaması şaşırtıcı. Yanıtı düzenleyebiliyorsunuz ama o zaman da başka birçok bağlam kayboluyor. Benim iş akışım: 1. planla 2. inşa et 3. dallandır 4. yinele. Prompt budama/dallandırma, LLM kullanımının temel araçlarından biri olmalı diye düşünüyorum

    • Google AI Studio’da en azından bu özellik var. Ama uygulaması kafa karıştırıcıydı; belki de daha yaygın olmamasının nedeni budur
    • Uzun zamandır kendim böyle bir şey yapmak istiyordum. BetterChatGPT’de en azından geçmiş silme arayüzü iyi ama bence bir sonraki adım dallanma

  • LLM arayüzü tek turlu konuşma mantığıyla tasarlanırsa sorun çıkıyor. Çoğu kullanıcı doğrusal bir sohbet bekliyor. Bu yüzden LLM için evrensel bir UI olarak Telegram botu experai_bot’u yaptım ve “yanıt değilse yeni sohbet” yaklaşımını kullandım. Bağlamı korumak için mutlaka yanıt ağacı yapısında ilerlemek gerekiyor. Uzman olmayan kullanıcılar bunu anlamakta zorlanıyor. Ayrıca OpenAI modellerinde (3.5 ve 4o itibarıyla) aynı soru tekrarlandıkça boşluklar ya da seçenekler kısalıyor ve sonuçlar giderek daha hatalı oluyor. Sistem mesajlarını minimumda tutunca sonuç nispeten korunuyor. Gerekirse seçenek olarak sistem mesajı da eklenebiliyor

  • promptdown’u yapmamın ana nedeni, tüm sohbet geçmişinin her turda tamamen düzenlenebilmesini istememdi. Standart arayüzlerin append-only yapısı bunu zorlaştırıyor

  • Şu an LLM alanında herkesin aynı sorunları tekrar tekrar çözdüğü hissi var

    • Multi-turn sohbetlerdeki LLM’ler gibi, herkes aynı problemi tekrar tekrar yaşıyor
    • Bu “öğrenme” değil, daha çok “kedi gütme” ama bazı iş akışları için uygun
    • Herkes kendi prompt engineering becerisini sergilemek istiyor

  • LLM gerçekten de şişedeki cin gibi. Üç soruya kadar cevap veriyor, ondan sonra ise saçmalamaya başlıyor