Özyinelemeli Dil Modelleri (Recursive Language Models)

• Büyük dil modellerinin (LLM) çok uzun girdi istemlerini işleyebilmesini sağlayan yeni bir çıkarım stratejisi olan RLM (Recursive Language Model) öneriliyor
• RLM, uzun istemleri dış ortamın bir parçası olarak kabul ediyor ve modelin bunları programatik olarak keşfetmesine, parçalamasına ve özyinelemeli olarak çağırmasına olanak tanıyor
• Bu yaklaşım, mevcut bağlam penceresi sınırlarını aşarak on milyonlarca token ölçeğine kadar girdileri işliyor ve mevcut LLM'lere kıyasla kaliteyi belirgin biçimde artırıyor
• Deney sonuçlarına göre GPT-5 ve Qwen3-Coder tabanlı RLM, çeşitli uzun metin görevlerinde çift haneli performans artışı gösterirken maliyet benzer ya da daha düşük kalıyor
• Bunun, uzun bağlam işleme sınırlarını aşarak LLM'lerin çıkarım yeteneğini büyük ölçüde genişletebilecek genel bir yaklaşım olduğu değerlendiriliyor

---

RLM'ye genel bakış

• Recursive Language Model (RLM), LLM'nin uzun girdiyi doğrudan sinir ağına vermek yerine bunu dış ortamın bir değişkeni olarak ele alıp onunla etkileşime girecek şekilde tasarlanıyor
  • Girdi istemi P, Python REPL ortamındaki bir değişkene yükleniyor ve LLM'nin bunu kod aracılığıyla keşfetmesi, parçalaması ve özyinelemeli olarak çağırması sağlanıyor
  • LLM, REPL ortamının durumunu (ör. dizge uzunluğu) algılıyor, kod yürütmenin yan etkilerini gözlemliyor ve problemi kademeli olarak çözüyor
• Bu yapı, mevcut bağlam sıkıştırma (compaction) ya da özet tabanlı yaklaşımların ayrıntı kaybetme sorununu çözüyor
• RLM, hem girdi hem de çıktı uzunluğunu ölçekleyebilen genel bir çıkarım paradigması olarak sunuluyor

Mevcut yaklaşımların sınırları

• Mevcut LLM'ler, bağlam penceresi sınırı nedeniyle uzun girdilerde performansın hızla düştüğü context rot olgusunu gösteriyor
• Bağlam sıkıştırma (compaction) teknikleri belli bir uzunluğu aşınca özeti tekrar ediyor, ancak ince ayrıntılara erişim gerektiren görevler için uygun değil
• RLM, istemi dışsal bir nesne olarak ele alarak girdi boyutunu model sınırlarının ötesine genişletebiliyor

Deney düzeni

• Değerlendirilen modeller: GPT-5 (OpenAI, 2025) ve Qwen3-Coder-480B-A35B (Team, 2025)
• Karşılaştırma grubu:
  • Temel LLM'e doğrudan çağrı
  • Özet ajanı (Summary agent)
  • CodeAct + BM25 arama tabanlı ajan
  • RLM (REPL ortamı dahil) ve RLM (REPL, özyinelemeli çağrı yok)
• GPT-5 deneylerinde, özyinelemeli çağrılar için GPT-5-mini, kök model olarak ise GPT-5 kullanılarak performans ve maliyet dengesi sağlanıyor

Değerlendirme görevleri

• S-NIAH: Tek bir 'needle-in-a-haystack' problemi; girdi uzunluğundan bağımsız olarak sabit işlem maliyeti
• BrowseComp-Plus: Birden fazla belge arasında dolaşan çok adımlı soru-cevap görevi; 1000 belge içinde doğru yanıt yer alıyor
• OOLONG: Girdideki neredeyse tüm öğelerin anlamsal olarak dönüştürülüp bütünleştirilmesini gerektiren uzun bağlamlı çıkarım görevi; işlem maliyeti girdi uzunluğuyla doğrusal orantılı
• OOLONG-Pairs: OOLONG varyantı; çift bazlı bilgi birleştirme gerektiriyor ve işlem maliyeti girdi uzunluğunun karesiyle orantılı
• LongBench-v2 CodeQA: Kod deposu anlayışı gerektiren çoktan seçmeli görev; en yeni modeller için bile zor bir problem

Başlıca sonuçlar

• RLM, GPT-5'e kıyasla uzun bağlamlarda neredeyse hiç performans kaybı göstermiyor
  • GPT-5, girdi uzunluğu ve görev karmaşıklığı arttıkça performansta keskin düşüş yaşıyor
  • RLM, 272K token sınırını aşan girdileri (10M+ token'a kadar) da etkili biçimde işliyor
• Tüm uzun metin görevlerinde RLM, diğer yöntemlere kıyasla çift haneli performans artışı gösteriyor
• Maliyet verimliliği de korunuyor; sorgu başına maliyet mevcut yaklaşımlarla benzer ya da daha düşük kalıyor

Uzun metin görevlerinin karmaşıklık analizi

• LLM'lerin fiili bağlam penceresi, fiziksel sınırdan ziyade görev karmaşıklığına bağlı olarak daha kısa olabilir
  • Basit NIAH problemleri 1M+ token'da da çözülebiliyor
  • Karmaşık OOLONG türü görevlerde ise çok daha kısa uzunluklarda bile performans düşüşü ortaya çıkıyor
• Bu nedenle görevin bilgi yoğunluğu ile girdi uzunluğu arasındaki ilişkiyi birlikte değerlendirmek gerekiyor

Sonuç

• RLM, LLM'lerin çıkarım yeteneğini özyinelemeli olarak genişleterek mevcut modellerin işleyemediği aşırı uzun girdileri ele alabilmesini sağlıyor
• İstemi bir ortam nesnesi olarak ele alan tasarım temel yenilik olarak öne çıkıyor ve uzun metin işlemedeki yapısal sınırları çözüyor
• Farklı modeller ve görevlerde performans, maliyet ve ölçeklenebilirlik dengesini yakalayan genel bir çıkarım çerçevesi olarak sunuluyor

[GN⁺]

Hacker News yorumları

• Bu, yalnızca subagent kavramı gibi görünüyor
  Yani başka bir LLM çağırıp dosyaları okutmak ve gerekli bilgileri çıkarttırmak, böylece ana bağlamı gereksiz yere karmaşıklaştırmamak için kullanılan bir yöntem
  Fikir iyi ama tamamen yeni değil

  • Ben buna insan gibi kişileştirilmiş bir subagent'tan çok bir kontekst yönetimi aracı olarak bakıyorum
    Şu anda Scope projesinde, gözlemlenebilir subagent'lerin işleri özyinelemeli olarak parçalamasını deniyoruz
    Ancak bu planlama aşaması değerlendirmesini nasıl iyileştireceğimi bilmiyorum
    Heuristikleri Markdown dosyalarına kaydediyorum ama yapı gevşek olduğu için ölçmek zor
    İlgili literatür veya proje bilen varsa paylaşması harika olur
  • Makale bunu şöyle söylüyor
    RLM ne bir ajan ne de bir özetleme yöntemi
    Tek bir sistem içinde birden fazla LM çağrısı kullanmak yeni bir fikir değil; çoğu agentic scaffold zaten bunu yapıyor
    En benzer örnek olarak, problemi parçalayıp birden fazla sub-agent ile çözen ROMA agent gösterilebilir
    Ayrıca Cursor veya Claude Code gibi kod asistanları da bağlam uzadıkça özetleme ya da budama yapıyor
    Bu tür yaklaşımlar genelde işi görev birimlerine bölerken, RLM bağlam birimiyle parçalamayı vurguluyor ve bu seçimin LM tarafından kendiliğinden yapılması gerektiğini savunuyor
  • Başlığa bakınca tüm hesaplamanın differentiable olduğu ve tek bir model olarak eğitildiği izlenimi oluşuyor, ama pratikte yalnızca modeli tekrar tekrar çağırmaktan ibaret gibi görünüyor
  • Bir subagent başka bir subagent'i sonsuza kadar çağıramıyorsa buna özyinelemeli denemez
  • Aynı bağlama (dosya sistemi veya REPL değişkenleri) erişip onu manipüle eden sub-agent kavramından söz ediyor gibi görünüyor

• Temel içgörü, uzun prompt'ları doğrudan sinir ağına (Transformer) vermek yerine, bunları LLM'in sembolik olarak etkileşime girebildiği bir ortamın parçası olarak ele almak gerektiği
  Ancak bunun temelde RAG'den nasıl farklı olduğunu merak ediyorum
  Şekil 4'e bakınca fark, retrieval mekanizmasını insanın değil doğrudan LLM'in uygulaması gibi görünüyor

  • Bence iki fark var
    1️⃣ RAG daha çok bir workflow iken, bu yaklaşım daha agentic
    2️⃣ özyinelemeli bir yapıya sahip
    Workflow'da akışı adım adım insan tasarlar; agentic yaklaşımda ise ajan neyi arayacağını, kaç kez çağrı yapacağını ve ne zaman yanıt vereceğini kendi belirler
    Örneğin Claude Code veya Codex kod tabanını dolaşıp dosyalar okuyor ve ripgrep çalıştırıyor
    Bu tür özyinelemeli denemeler daha önce de vardı (ör. babyagi, 2023 civarı) ama o dönemde model performansı yetersiz olduğu için çok fazla glue code gerekiyordu
    Artık modeller yeterince güçlü olduğu için bu yapı gerçekten çalışıyor

• “T̶u̶r̶t̶l̶e̶s̶ LLMs all the way down” şakasında olduğu gibi, sonsuza kadar LLM'in LLM çağırdığı bir yapıyı ima ediyor

  • Bu, “attention is all you need” yaklaşımını yinelemeli biçimde uygulamak gibi; sonuçta peşinden gitmemiz gereken şey kesinlik (precision)

• Bunun daha okunabilir bir versiyonu var: alexzhang13 blog yazısı

• 2026 için umduğum şey, Anthropic veya OpenAI'ın CLI eklenti geliştiricilerine “compaction'ın nasıl çalıştığını” açıklaması
  Bu teknik, Claude Code içine gömülü işlevlerin yerini alabilir ama şu anda uygun hook'lar ya da özellikler açığa çıkarılmış değil

  • Codex açık kaynak değilse gidip kendin okuyamaz mısın?
    Ben Gemini kaynaklarını gördüm; bağlam penceresi dolduğunda her şeyi özetleyen basit bir prompt yapısıydı

• Bu makaleye benziyor: arXiv:2510.14826