- CoRT (Chain of Recursive Thoughts), bir yapay zeka modelinin yanıtı tek seferde kesinleştirmek yerine, kendi kendine birden çok kez alternatif üretip bunları değerlendirerek nihai yanıtı seçtiği bir proje
- Çalışma akışı; ilk yanıtın üretilmesi, gerekli düşünme turu sayısının belirlenmesi, her tur için 3 alternatif oluşturulması, tüm yanıtların değerlendirilmesi ve en iyi yanıtın seçilmesinden oluşuyor
- Mistral 3.1 24B ile test edildiğinde, özellikle programlama görevlerinde, küçük model ölçütünde yanıt kalitesinin belirgin biçimde arttığı belirtiliyor
- Web UI hâlâ erken geliştirme aşamasında ve Windows'ta
start_recthink.bat, Linux'ta ise pip, npm, recthink_web.py çalıştırma akışı kullanılıyor
- Temel bileşenler öz değerlendirme, rekabetçi alternatif üretimi, yinelemeli iyileştirme ve dinamik düşünme derinliği; proje MIT lisansı ile açık olarak sunuluyor
CoRT ne yapıyor?
- CoRT, bir yapay zeka modelinin kendi yanıtlarını özyinelemeli olarak gözden geçirmesini, alternatifler üretmesini ve ardından en iyi yanıtı seçmesini sağlayan bir yaklaşım
- Amaç, yapay zekanın ilk verdiği yanıtı olduğu gibi kullanmak yerine, kendinden şüphe edip yeniden deneme sürecini tekrar etmesini sağlamak
- README bunu bir “AI battle royale” gibi tanımlıyor; birden çok aday yanıt arasından ayakta kalan yanıt nihai sonuç olarak kullanılıyor
Yanıt üretim biçimi
- İşleme akışı şu adımlardan oluşuyor
- Yapay zeka ilk yanıtı üretir
- Yapay zeka gerekli düşünme turu sayısını belirler
- Her turda 3 alternatif yanıt üretir
- Tüm yanıtları değerlendirir
- En iyi yanıtı seçer
- Nihai yanıt, tekrar eden alternatif üretimi ve değerlendirme sürecinden geçerek seçilen sonuçtur
Testler ve örnekler
- CoRT, Mistral 3.1 24B üzerinde uygulanarak test edildi
- README, CoRT uygulanan sürümün uygulanmayan sürüme göre özellikle programlama görevlerinde daha iyi sonuç verdiğini belirtiyor
- Örnek olarak Mistral 3.1 24B + CoRT ile Mistral 3.1 24B non CoRT sonuç görselleri yer alıyor
Çalıştırma yöntemi
- Web UI hâlâ erken geliştirme aşamasında
- Windows'ta
start_recthink.bat açılıp bağımlılıkların kurulmasının tamamlanması bekleniyor
- Linux çalıştırma adımları ise şöyle
pip install -r requirements.txt
cd frontend && npm install
cd ..
python ./recthink_web.py
- Yeni bir shell içinde frontend çalıştırılıyor
cd frontend
npm start
Doğrudan çalıştırma ve bileşenler
- Doğrudan çalıştırmak için bağımlılıkları kurup
OPENROUTER_API_KEY ayarladıktan sonra Python betiği çalıştırılıyor
pip install -r requirements.txt
export OPENROUTER_API_KEY="your-key-here"
python recursive-thinking-ai.py
- Projenin vurguladığı dört temel unsur şunlar
-
Self-evaluation
- Competitive alternative generation
- Iterative refinement
- Dynamic thinking depth
- Katkılar PR ile kabul ediliyor ve lisans MIT
1 yorum
Hacker News yorumları
Birden fazla modeli birbirine karşı yarıştırınca ya da sürü hâlinde çalıştırınca kolektif zekânın sihirli biçimde ortaya çıkacağı yönünde çok akım görüyorum; ancak kendi deneylerim ve ASU/Microsoft Research çalışmasını gördükten sonra daha basit bir sonuca vardım: LLM’ler başka LLM’ler için berbat doğrulayıcılardır
Subbarao Kambhampati’nin “(How) Do LLMs Reason/Plan?” sunumunda GPT-4, sembolik bir SAT çözücü hakem olarak devreye girene kadar, kanıtlanabilir biçimde yanlış olan bir grafik boyama ispatını kendinden emin şekilde üretiyor https://www.youtube.com/watch?v=0u2hdSpNS2o
Stechly ve diğerlerinin makalesi, GPT-4’ten kendi yanıtını eleştirmesi istendiğinde doğruluğun aksine düştüğünü; dışarıdan sound bir doğrulayıcı eklendiğinde ise planlama ve bulmaca görevleri genelinde yaklaşık 30 yüzde puanlık iyileşme sağlandığını nicel olarak gösteriyor https://arxiv.org/abs/2402.08115
Yani mevcut otoregresif modeller için doğrulama, üretimden daha zor; derleyiciler, linter’lar, SAT çözücüler, doğru yanıt veri kümeleri gibi dünya hakkında gerçekten akıl yürüten denetleyicilere ihtiyaç var
Bu yüzden birden çok LLM’i üst üste koymak çoğu zaman pek işe yaramıyor. “LLM-Modulo” pozisyon makalesi de otoregresif modellerin kendi doğrulamalarını ya da uzun vadeli planlamayı kendi başlarına yapamayacağını; bunların yüksek hatırlama oranına sahip fikir üreticileri olarak ele alınıp tek ve sound bir doğrulayıcıyla sarılması gerektiğini savunuyor https://arxiv.org/abs/2402.01817
Kendi testlerimde, 5 modelli bir tartışmayı tek bir güçlü model ve bir doğrulayıcıyla değiştirmek, aynı ya da daha iyi yanıtlar verdi; gecikme ve orkestrasyon yükü ise çok daha düşüktü
Kitaplar ve filmler iyi bir örnek: bir karakterin sığ olduğunu söylemek kolaydır, ama derinlikli ve ilgi çekici bir karakter yaratmak şaşırtıcı derecede zordur
Yazılım mühendisliğinde de benzer; güvenlik açığı bulma prompt’u verilen bir LLM, üretilen kodda zayıf olabilecek noktaları işaret edebilir
Ama başka bir LLM’den matematik ispatındaki akıl yürütme hatasını bulmasını beklerseniz, fiilen tüm akıl yürütmeyi baştan yapması gerekir; bu yüzden anlamlı bir performans artışı olup olmayacağı şüpheli
LangChain veya LlamaIndex gibi framework’lerde de RAG pipeline değerlendirmesinin içine derinlemesine girmiş durumda https://arxiv.org/abs/2411.15594
LLM’e ürettiği kod için birim testleri de yazdırıp ardından mevcut uygulamanın tüm birim testlerini de çalıştırmak nasıl olur, merak ediyorum
Kodun derlenip derlenmediğini, birim testlerinin geçip geçmediğini kontrol etmek bir ölçüde dayanaklı doğrulama sağlayabilir; yapay zeka da test sonuçlarını okuyup kendi hatalarını düzeltmek için kullanabilir
Derlem verisiyle eğitim tek haneli ölçekte sıçramalar yaratabilir; ama gözlemleyip uyum sağlayabilen bir OODA döngüsüne sahip etkileşim verisiyle eğitim çok daha güçlüdür
Ben yapay zeka üzerinde çalışıyor olsaydım muhtemelen böyle yapardım. Gerçekte ise BrowserBox geliştiriyorum
Üret-ve-test et (generate-and-test), güvenilir, nispeten hızlı ve bellek açısından verimli bir test algoritması gerektirir; yalnızca doğru yanıtları üreten kesin bir üretim algoritması yavaş olduğunda veya çok bellek kullandığında özellikle yararlıdır
Burada üretici LLM, test edici ya da “doğrulayıcı” ise derleyici, linter, SAT çözücü, doğru yanıt veri kümesi vb. oluyor
Üret-ve-test etme, deneme-yanılmayla da ilişkilidir; deneme-yanılma da muhtemelen Paleolitik Çağ’dan beri vardır
Ara sıra kullandığım yöntem şu: Önce yapay zeka sohbet modelinin probleme bir yanıt vermesini sağlıyorum; sonra bu yanıtın neden doğru olduğunu, başlangıçtaki problemi ya da teknik alanı bilmeyen bir kişinin veya bir yapay zekanın bile anlayabileceği şekilde bir rapor olarak yazdırıyorum.
Ardından problemi bilmeyen ikinci bir yapay zeka modeline raporu puanlatıyor, ilk modelin sunmadığı açıklamaları istemesini ya da mantıktaki tutarsızlıkları işaret eden bir rapor yazmasını sağlıyorum.
Bu raporu ilk modele geri verip gerekli bilgileri veya düzeltmeleri yansıtan yanıtı yeniden yazdırıyorum; sonra ikinci model ikna olana ya da ilk model tüm değişiklik isteklerini yansıtana kadar bunu tekrarlıyorum.
Çok kaba bir yöntem ama denediğim durumlarda oldukça iyi sonuç verdi.
Nihai plan genelde çok daha dengeli ve üzerinde düşünülmüş bir hâl alıyor.
İlginç şekilde bu teknik insanın kendisine uygulandığında da iyi çalışıyor. Planı yeniden gözden geçirmeden önce kusurları aramak gerçekten yardımcı oluyor.
Örneğin biri teknik odaklı, biri pazarlama odaklı, bir diğeri de kişisel hedeflerle ilgili bağlam taşıyor.
Aynı soruyu farklı bağlamlardaki sohbetlere koymak, aynı soruna birden çok açıdan bakmaya benziyor; sonuçlar da bağlama göre epey değişebiliyor.
Oldukça iyi bir fikir gibi görünüyordu ama token kullanımını ciddi şekilde artıracak gibi.
Ayrıca hakem olarak kullanılan LLM baştan yeterince iyi yanıtlar üretemiyorsa, doğru şekilde puanlamakta da zorlanabileceği endişesini taşıyorum.
Böyle bir şeyi daha büyük ölçekte, sürekli açık bir tartışma senatosu biçiminde denemek istiyorum.
Prompt’lara anlık yanıt vermek yerine, teslim tarihi de olabilecek bir görev listesi verip senatonun bunun üzerinde çalışmasını; alt görevler için gruplara ayrılmasını, sonuçlara meydan okumasını ve öneriler üretmesini sağlamak gibi.
Daha da ileri gidip, üst düğümün alt analizleri özellikle içgörülü bulduğu durumlarda önerileri yukarı taşıyan bir analist ağacı kurulabilir.
Modele bir soruna belirli bir bakış açısından yaklaşmasını söylemenin sonuçları iyileştirebildiğini veya kötüleştirebildiğini kesin olarak gördüm. Çeşitli bakış açılarıyla birlikte bunların sonuçlarına yönelik eleştirel analiz üretmek etkileyici sonuçlar verebilir.
Bu yöntem muazzam sayıda token üretir ama token başına maliyet bunu mümkün kılacak yönde ilerliyor. Herkesin kendi modelini bağlayabileceği, ortak tartışma alanı gibi kullanılacak yapay zekaya özel bir IRC sunucusu oluşturma olasılığı da var.
Zaman harcayıp deneyince takılıp geri döndüğümde, “Evet, doğru bulmuşsunuz! Neredeyse geldiniz! Sonraki adım X ve Y” diye hafifçe söyleyip, öncekiyle aynı ayrıntılı öğreticiyi sunuyor ve sadece hatalı bayrak gibi yerleri azıcık değiştiriyor.
İşini kontrol etmeden ortaya atan aşırı hevesli bir stajyerle uğraşıyormuşum gibi hissettiriyor; ilk botun karşısına ikinci bir bot oturtup “Bundan gerçekten emin misin?” diye sordurmak bunu epey iyileştirecek gibi.
Civilization II’deki danışmanlar kavramını örnek alarak yaptım; oldukça iyi çalıştı ama tek bir LLM olan Mistral’a bağlı olması bir ölçüde sınırlayıcıydı.
Bir de bilgisayarımı yakacak kadar ağırdı.
Yeterli zaman ve token verilirse ne üreteceğini görmek ilginç olurdu.
Sık kullandığım, çok daha basit ve sınırlı bir strateji, mesajın sonuna “Yanıtlamadan önce etiketlerin içinde bir kez düşün, etiketlerin içinde bir kez öz eleştiri yap, son olarak nihai yanıtı yaz” eklemek.
Oldukça iyi çalışıyor. Benzer şekilde yalnızca “önerideki en büyük 5 sorunu bul” demek de fena değil; ama 5 tane zorunlu tutulunca, çoğu pek alakalı olmasa bile bir şeyler buluyor.
Sık sorduğum diğer sorular “Neyi kaçırdık?”, “Performans, güvenlik, hukuk, maliyet açısından dikkate alınması gerekenler neler?” gibi şeyler.
“Başka var mı?” türü yönlendirici prompt’ları da birkaç kez tekrarlayabiliyorsun; özellikle ele alınacak konuları göstermek iyi oluyor. Her seferinde bittiğinde, bu değerlendirmeleri yansıtarak planı güncelletiyorum.
Başlıktan beklediğimden biraz farklı. Açıkça karşıtlık içeren bir prosedür olacağını sanmıştım
Bunu doğrudan denemedim ve çalışıp çalışmayacağını da bilmiyorum. Ama ChatGPT'ye ayrı prompt'larla “XYZ doğrudur, nedenini açıkla” ve “XYZ yanlıştır, nedenini açıkla” diye ayrı ayrı sorup hangisinin daha ikna edici olduğuna bakmak faydalı oluyor
https://github.com/evalstate/fast-agent
Birinin bunu neden yeni sandığını bilmiyorum. HN'nin durumunu gösteriyor da olabilir
Yaklaşımın kendisi iyi görünüyor ama asla doğrudan “sen yanılıyorsun” diye ima etmemek gerek. Genelde sadece kendisinin yanıldığını varsayıveriyor
Hatta böyle yapıldığında gerçekten karşı çıkıp kendini savunduğu zamanlar etkileyici oluyor
Bu tür deneyler epey eğlenceli olduğu için, insanların böyle iş akışları tasarlayabileceği Unreal Engine blueprint tarzı bir grafik düzenleyici yapıyorum
Kullanıcı prompt'u bir ajana girip ilk denemeyi üretiyor; sonra o konuşma geçmişi, farklı bir sistem prompt'una sahip bir “ajan”a aktarılıp sert bir eleştirmen oluyor, geçme/kalma sinyali veriyor ve eleştirmen geçtiğine karar verene kadar döngü dönüp ardından çıktı kullanıcıya sunuluyor
Kendi LLM endpoint'ini çağırabilen ve iş akışı grafiğini kaydedip yüklemeye ve paylaşmaya izin veren küçük bir web sitesi ideal olurdu
Mistral Small 3.1 ve Gemma 3, yerelde çalıştırılabilen ilk yarı yarıya yetkin modeller gibi hissettiriyor; ama bu yetkinlik sadece bir tohum ve onu sürekli yörüngede tutacak bir framework gerekiyor
Yineleme döngüsünün içinde Python çalıştırma yetkisi verip dünyayı keşfetmesini söylerseniz, haberler gibi şeyleri indirip okumaya başlıyor
Örneğin GPT'ye kaba davranması talimatını verince, Gemini'nin saçmalıkları veya zayıf akıl yürütmeyi yakalama becerisini GPT'de bir ölçüde taklit edebildim. Nezaket, değerli birçok şeyi filtreliyor gibi
Ama çıktı okunması rahatsız edici hale geliyor. Gemini bunu eğitimde iki aşamada ele alıp ilk aşamayı gizli “düşünce” yaparak çözmüş gibi görünüyor
Bu yüzden gereken şeyin, o “kaba” çıktıyı biraz daha insani hale getiren iki aşamalı bir yaklaşım olduğunu düşünüyorum. Bu şekilde çalışınca kısa süreden fazlası epey yorucu oluyor
Farklı LLM kişiliklerinin olduğu bir grup sohbeti arayüzü de çok değerli olabilir. Mesaj nesnesi biçimi, her mesaja ad koyması gibi, birden çok kullanıcı ve birden çok AI düşünülerek tasarlanmış gibi duruyor; ama henüz böyle bir arayüz görmedim
Birden fazla sağlayıcıyı desteklerse daha da iyi olur. Güçlü yönleri farklı olduğu için ikinci bir görüş almak gibi
consortium aynı prompt'u birden fazla modele paralel gönderiyor ve tüm yanıtları değerlendirmesi için bir moderatör modele iletiyor. Moderatör daha fazla yineleme gerekip gerekmediğine karar veriyor
Güven eşiğine ya da minimum yineleme sayısına ulaşılana kadar daha fazla yinelemeyi zorunlu kılmak da mümkün
llm-openrouter'a yaptığım PR'ı kullanırsanız, birden fazla model seçeneği içeren model takma adları kaydedebilirsiniz. Örneğin
llm openrouter save -m qwen3 -o online -o temperature 0, system "research prompt" --name qwen-researchergibi çevrimiçi araştırma uzmanı oluşturabilirsinizBaşka bir üye JSON modunda nesne çıkarımı yapabilir, bir diğeri kör taslak yazabilir. Moderatör tüm bunlardan yararlanarak iyi bir yanıt sentezler
Bu GPU'ları hızlıca yeşil enerjiyle çalıştırmanın yolunu bulmamız gerekiyor. Yoksa AI'lar tic-tac-toe için en iyi çözüm üzerine kendi aralarında tartışırken dünyayı eritecek
Çok küçük bir işi bitirmenin en kolay yolu olduğu zamanlar da var; ama backend maliyeti farkı epey büyük olmak zorunda. Kullanıcı sonunda bunu hiç umursamaz hale geliyor. Çünkü gerçeklik hissi yok
AI'ın kendi kendisine karşı sürekli çalıştırılması gerektiği zaten gerçek kabul ediliyor
Makine öğrenimi modellerine yeni fikirler ürettirmenin yolunun bu olduğunu düşünüyorum
Öz-tartışma yoluyla, zaten denenip atılmış tüm fikirler üzerinden diagonalization yapmak, ama belirli tutarlılık kısıtlarını korumak. Elbette söylemesi yapmasından çok daha kolay
Conway'in Game of Life'ı gibi; ama kurallı renkli kareler yerine, belirli ağırlıklara sahip LLM'lerin birbirleriyle durmadan konuştuğu ve bir yerlerden söz ya da eylem olarak yüzeye çıktığı bir biçim
https://news.ycombinator.com/item?id=43835798
Bu nereye kadar gider? Birkaç saatte bir stand-up toplantısı yapan bir AI agent scrum ekibi mi ortaya çıkar?
Bütün gün bir konuyu tartışıp en iyi görüşü bulmaya çalışan agent’larla devlet bürokrasisini mi kopyalayacağız?
Farklı rollere sahip AI agent’lar bir scrum ekibi yürütüyordu; her agent’ın prompt’u, herkese karşı çıkacak ya da kendi bakış açısını çok eleştirel biçimde sunacak şekilde ayarlanmıştı ve nihai kararı bir arabulucunun verdiği söyleniyordu
Sunumu yapan kişi, bunun kendilerinde iyi çalıştığını iddia etmişti
İnsanların farklı deneyimleri ve bakış açıları var; LLM’lerde bu o kadar güçlü olmasa da. Yine de bazen farklı bir şapka takmak yeterli olur. Örneğin code reviewer ile coder arasındaki fark gibi
Bir noktada etkinin düzleştiği bir yer olacak; o noktayı belirlemek için de bir AI komitesi kurulur herhalde
Sonuçta okyanusu kaynatmak istemezsiniz
Bunu kolayca fork edip kurcalamaya uygun hale getirmeleri güzel
Ben de daha yeni Nash Equilibrium ekleyip “prompt engineering”i çoklu agent müzakeresi olarak yeniden çerçeveleyen kendi iterasyonuma başladım. Başkalarının ne düşündüğünü merak ediyorum
https://github.com/faramarz/NECoRT/
Kurumsal LLM’lerin ek hesaplama maliyetiyle büyük bir sorunu olmayacağını ve karmaşık finansal yapıları birden fazla modelleme optimizasyonuyla ayarlamayı daha çok tercih edeceğini düşünüyorum
Açık depolara ve katkı süreçlerine pek alışkın değilim; yanlış yapıyorsam birinin işaret etmesi iyi olur
Niyetim, teoriyi test etmek için orijinal codebase’i fork etmek ve sonunda bunu PR olarak göndermek