LLM386: 1990’lardan Esinlenen LLM Bağlam Yönetimi Çözümü

1989 yılında DOS’un geleneksel bellek sınırı sadece 640 KB idi. Bu sınırın ötesine geçmek için geliştirilen EMM386, 80386 işlemcisinin adres çevirme yeteneklerini kullanarak, sınırlı pencereyi geniş bir bellek alanına bağlayan bir sayfalama sistemi sundu. Programlar, yalnızca o anki işlem için gerekli olan parçaları pencereye taşıyarak sınırsız belleğe erişebiliyordu. Bugün, büyük dil modellerinde (LLM) benzer bir sorunla karşı karşıyayız: bağlam penceresi ne kadar geniş olursa olsun, sürekli büyüyen veri kümeleriyle başa çıkmak zorlaşıyor. LLM386, bu yetmişli yıllık fikri modern LLM’lere uyarlayarak, bellek yönetiminin yeni bir yolunu açıyor.

Bağlam Penceresi Sorunu ve Çözümün Temeli

Büyük dil modellerinin çıktısı, f(context) → output denklemiyle özetlenebilir. Bu denklemde model, tamamen stateless bir fonksiyon olarak çalışır: ne hafızaya sahiptir, ne kalıcı duruma sahiptir, ne de ardı ardına yapılan çağrılar arasında bağlantı kurar. Bu durumda, tüm süreklilik, her çağrıda yeniden inşa edilmek zorundadır. Peki, bu nasıl bir sorun yaratır?

• İzlenebilirlik kaybı: Modelin cevabı, hangi bilgilerden etkilendiğini açıklayamaz. İki farklı çağrıda aynı soruya farklı yanıtlar alınabilir, ancak nedeni kaydedilmez.
• Verimsizlik: Gereksiz verilerle doldurulan bağlam penceresi, token maliyetini artırır ve performansı düşürür.
• Dağınık durum yönetimi: Gelişmiş ajan sistemlerinde, kalıcı durumun nerede ve nasıl saklandığına dair net bir model bulunmaz.

LLM386, bu sorunları çözmek için EMM386’ın mantığını modern LLM’lere uyarlıyor. Modelin girdi bütçesini dikkate alarak, yalnızca gerekli olan verileri pencereye taşıyan bir sayfalama sistemi sunuyor. Bu sayede, model her çağrıda sadece ilgili bağlamı görür ve yanıtı daha tutarlı, daha izlenebilir hale gelir.

LLM386’ın Mimarisi: Nasıl Çalışır?

LLM386, birden fazla bileşenden oluşan açık kaynaklı bir çalışma zamanı (runtime) olarak tasarlanmıştır. Bu bileşenler, modelin girdi sınırlamalarına uygun olarak bağlamı dinamik olarak yönetir ve sürekliliği sağlar. Temel bileşenleri şunlardır:

• Kalıcı blok deposu: LMDB tabanlı, içerik adresli ve hash’e göre verileri sıkıştıran bir depolama alanı. Bu depo, modelin ihtiyaç duyacağı tüm verileri saklar.
• Sayfalama motoru: Modelin girdi bütçesine uygun olarak hangi blokların pencereye alınacağını belirler. Çoklu sorgulama sistemleriyle çalışır:
• Yenilik: En son eklenen verileri önceliklendirir.
• BM25: Anahtar kelime benzerliğine dayalı sıralama yapar.
• Gömülü ANN: Anlamsal benzerlik arar.
• Özel sorgular: Kullanıcı tanımlı mantıklara göre sıralama yapar.
• Paketleyici: Seçilen blokları, modelin anlayacağı şekilde belirleyici bir dizeye (prompt) veya sohbet mesajı listesine dönüştürür.
• İzleyici: Modelin hangi verileri gördüğünü ve nedenlerini kaydeder. Bu kayıtlar, byte düzeyinde hash’lerle korunur ve yeniden oynatılabilir.
• Azaltıcı: Model çıktısını, kalıcı duruma dönüştürülebilir olaylara çevirir.
• Tip kontrollü kenar grafiği: Bağımlı blokları birbirine bağlar. Örneğin, bir aracın çağrıldığı mesajla sonuçları aynı anda saklanır.
• Fark katmanı: İki iz kayıt arasındaki değişiklikleri karşılaştırır.

LLM386, Rust kütüphanesi, Python SDK (PyO3 yerel uzantısı) ve CLI aracı olarak sunuluyor. Apache 2.0 lisansı altında yayınlanmakta olup, 1.0.0-alpha sürümündedir. Proje, henüz dağıtımlı depolama desteği sunmasa da, gelecekteki versiyonlarda bu özelliği eklemeyi planlıyor.

Kullanılmaması Gereken Durumlar

LLM386, her senaryo için uygun olmayabilir. Aşağıdaki durumlarda kullanımı önerilmez:

• Basit sohbet botları: Eğer projenizde yalnızca kısa, statik yanıtlar üreten bir bot geliştiriyorsanız, standart bir sohbet motoru yeterli olacaktır.
• Hızlı prototipler: Beş dakika içinde çalışır hale getirmeniz gereken demo projelerinde, LLM386’ın ek yükü gereksiz olabilir. Bu durumlarda, daha basit çözümler tercih edilmelidir.

Ancak, gelişmiş ajan sistemlerinde ve karmaşık sohbet geçmişlerine sahip uygulamalarda, LLM386 büyük bir avantaj sunar. Örneğin:

• Geliştirme ortamında çalışan ajanlar, ancak kodda hangi bilgilerin kullanıldığına dair net bir iz bulunamıyorsa.
• Model değiştirme gereksinimi: Farklı modeller arasında geçiş yaparken, bağlam yönetimini yeniden yazmak zorunda kalmadan devam etmek isteyenler.
• Araç bütünlüğü: Araç çağrıları ve sonuçları arasındaki bağımlılıkların net bir şekilde takip edilmesi gereken sistemler.

Beş Dakikada Çalıştırmak

LLM386’ı denemek isteyenler için hızlı bir kılavuz:

git clone 
cd llm386
export ANTHROPIC_API_KEY=sk-ant-...
docker compose -f examples/langgraph-agent/docker-compose.yml run --rm agent

Bu komutlar, iki basit araçla (hesap makinesi ve kullanıcı profili sorgulama) çalışan küçük bir sohbet botunu çalıştırır. Konuşma geçmişi, Docker hacmi olarak saklandığından, konteyner yeniden başlatıldığında bile devam eder. Model, önceki konuşmaları tümüyle runtime tarafından sağlanan bağlamla hatırlar; LangGraph’un kendisi ise her çağrı arasında statik kalır.

Gelecekteki Yönelimler ve Değerlendirme

LLM386, EMM386’ın bellek yönetimi mantığını modern LLM’lere uyarlayarak, bağlam penceresi sorununa yenilikçi bir bakış açısı getiriyor. Proje, açık kaynaklı ve topluluk odaklı olarak geliştirilmeye devam ediyor. Gelecekte, dağıtımlı depolama desteği ve öğrenilmiş bileşenlerin eklenmesi gibi özelliklerin eklenmesi planlanıyor. Ancak, bu eklemelerin izlenebilirlik ve deterministik çalışma prensiplerini bozmaması gerektiği vurgulanıyor.

Eğer projelerinizde bağlam yönetimi karmaşıklaşmaya başladıysa ve hangi verilerin modelin yanıtını etkilediğini takip etmek zorlaşıyorsa, LLM386 denenmeye değer bir araç olabilir. Bellek yönetiminin geleceği, bu tür yenilikçi yaklaşımlarla şekillenmeye devam edecek.