- LLM’lerin standart hedefi olan sonraki token tahmini, gelecekteki birden fazla token’ı aynı anda tahmin etmeye dönüştürüldüğünde, aynı veri ve hesaplama bütçesiyle bile kod ve doğal dil üretim performansı daha ileri taşınabiliyor
- Mimari, paylaşılan bir Transformer gövdesi üzerine birden fazla çıktı başlığı yerleştirme biçiminde; temel çıkarımda yalnızca sonraki token başlığı kullanılarak mevcut otoregresif üretim gibi çalışıyor
- Kod modellerinde 13B parametreli model, karşılaştırılabilir sonraki token modeline göre HumanEval’de %12, MBPP’de %17 daha fazla problemi çözdü; kazanım büyük modellerde daha belirgin
- Ek başlıklar öz-tahminli kod çözme için kullanılabiliyor; 4-token prediction modeli en fazla 3×, 8-byte prediction modeli ise 6,4× çıkarım hızı artışı gösterdi
- Sentetik görevlerde induction heads ve algoritmik akıl yürütme açısından avantaj sağladı; eğitimdeki teacher forcing ile üretimdeki otoregresif dağılım farkını azaltma etkisi olabilir
Çoklu token tahmini yöntemi
- Mevcut dil modelleme, her konumda tek bir sonraki token için çapraz entropi kaybını en aza indirir
- Çoklu token tahmini, eğitim hedefini her konumda sonraki n token’ı tek seferde tahmin edecek şekilde genişletir
- Model mimarisi üç bölüme ayrılır
- Paylaşılan Transformer gövdesi, gözlemlenen bağlamın gizil temsilini üretir
- n adet bağımsız çıktı başlığı, her bir gelecekteki token’ı paralel olarak tahmin eder
- Paylaşılan unembedding matrix, nihai token olasılıklarını hesaplar
- En basit çıkarım yöntemi, yalnızca sonraki token tahmin başlığını kullanan genel otoregresif tahmindir; diğer başlıklar atılabilir
- Ek çıktı başlıkları, blockwise parallel decoding veya Medusa-like tree attention gibi öz-tahminli kod çözme (self-speculative decoding) için kullanılabilir
Bellek açısından verimli uygulama
- Basit uygulamada her başlığın logit ve gradient değerlerinin tamamının belleğe alınması gerektiğinden GPU bellek kullanımı büyür
- Güncel LLM’lerde vocabulary boyutu V, gizil temsil boyutu d’den çok daha büyük olduğu için logit vector GPU belleğinde darboğaz oluşturur
- Önerilen uygulama, paylaşılan gövdenin forward pass’inden sonra her çıktı başlığının forward/backward işlemini sırayla yürütür
- Bir başlığın logit ve gradient değerleri, sonraki başlığa geçmeden önce serbest bırakılır
- Gövdede yalnızca birikimli gradient tutulur
- Bu yöntem, peak GPU bellek kullanımını O(nV + d) seviyesinden O(V + d) seviyesine düşürür ve çalışma zamanı maliyetini artırmaz
Kod modeli deney sonuçları
- Gerçek veri deneylerinde sonraki token tahmin modeli ile n-token prediction modeli aynı parametre sayısıyla karşılaştırıldı
- Gelecek tahmin başlıklarına n−1 katman eklendiğinde, paylaşılan gövdeden n−1 katman çıkarıldı
- 300M’den 13B’ye kadar altı farklı boyutta model, en az 91B code tokens ile sıfırdan eğitildi
- MBPP ve HumanEval değerlendirmelerinde küçük modeller temel modelden daha kötü olabilse de ölçek büyüdükçe çoklu token tahmini öne geçti
- 13B model, karşılaştırılabilir sonraki token modelinden daha fazla problemi çözdü
- HumanEval’de %12 daha fazla problem çözdü
- MBPP’de %17 daha fazla problem çözdü
- 200B code tokens ile eğitilen 7B model ablation’ında n=1, 2, 4, 6, 8 karşılaştırıldı
- n=4, HumanEval ve MBPP’de pass@1, pass@10, pass@100 için tutarlı biçimde en iyi sonuçları verdi
- APPS/Intro’da n=6 öne geçti
- En iyi window size, girdi veri dağılımına göre değişebilir
Çıkarım hızı ve byte-level model
- 7B 4-token prediction modeline greedy self-speculative decoding uygulandı ve eğitimde kullanılmayan kod ve doğal dil test istemlerinde kod çözme hızı ölçüldü
- Sonuçlar kodda 3,0×, metinde 2,7× hız artışı gösterdi
- Kodda, önerilen 3 token’dan ortalama 2,5’i kabul edilen token’dı
- 8-byte prediction modeli çıkarım hızında 6,4× artış kaydetti
- byte-level tokenization deneyinde 7B byte-level transformer, 314B bytes, yaklaşık 116B tokens karşılığı veriyle eğitildi
- 8-byte prediction modeli, next-byte prediction’a kıyasla daha fazla problemi çözdü
- MBPP pass@1’de %67 daha fazla problem çözdü
- HumanEval pass@1’de %20 daha fazla problem çözdü
- multi-byte prediction, byte-level modelleri daha verimli eğitmek için bir yol olabilir
Birden çok epoch, ince ayar ve doğal dil sonuçları
- Aynı veriyle birden çok epoch boyunca eğitim yapılsa da çoklu token tahmini, sonraki token tahminine göre bazı üstünlüklerini korudu
- MBPP pass@1 +%2,4
- HumanEval pass@100 +%3,2
- Diğer metrikler benzerdi
- CodeContests ince ayarında, 4-token prediction ile ön eğitim almış 7B model pass@k genelinde sonraki token temel modelinden daha başarılı oldu
- 4-token prediction modelini olduğu gibi n′=4 loss ile ince ayarlamak da temel modelden daha iyiydi
- Ek başlıkları kaldırıp next-token target ile ince ayar yapmak genel olarak en iyi sonucu verdi
- Doğal dilde, 7B model 200B tokens ile eğitilip 6 standart NLP benchmark’ında değerlendirildi
- 2-token prediction modeli sonraki token temel modeline benzerdi
- 4-token prediction modelinin performansı bir miktar düştü
- Daha büyük model boyutu gerekebilir
- Üretken doğal dil değerlendirmesi özetleme ve matematik görevleri olarak ikiye ayrıldı
- 8 summarization benchmark’ında n=2 ve n=4 modelleri, hem 200B hem 500B tokens eğitiminde ROUGE-L F1 açısından sonraki token temel modelinden yüksekti
- GSM8K 8-shot değerlendirmesinde 200B tokens’ta n=2 temel modeli geçti; ancak 500B tokens sonrasında örüntü tersine döndü ve n=4 genel olarak daha kötüydü
Sentetik görevlerde induction ve algoritmik akıl yürütme
- Induction, cümlede “AB” göründükten sonra daha sonra “A” tekrar geldiğinde devamında “B”yi tahmin etme örüntüsüdür
- children stories veri kümesiyle 1M~1B nonembedding parameters modeller eğitildi ve rastgele 2-token adlar eklenmiş test kümesiyle induction capability ölçüldü
- 30M ve altındaki küçük modellerde 2-token prediction loss, induction capability oluşumunu belirgin biçimde iyileştirdi
- 100M ve üzerinde bu avantaj kayboldu
- Polinom aritmetiği görevinde F7[X]/(X5) üzerinde unary negation, addition, multiplication, composition içeren ifadeler eğitilip değerlendirildi
- Çoklu token tahmini, task difficulty genelinde doğruluğu artırdı ve out-of-domain generalization’ı da mutlak değerler düşük olsa da belirgin biçimde iyileştirdi
- Modeli 30M’den 100M’ye büyütmektense next-token prediction’ı çoklu token tahminine dönüştürmenin etkisi daha büyük oldu
Neden işe yarayabilir?
- Çoklu token tahmini, teacher forcing eğitimi ile inference-time autoregressive generation arasındaki dağılım uyumsuzluğunu hafifletebilir
- Sonraki token tahmini, kısa aralıklı tahmine odaklanırken uzun aralıklı bağımlılıkları göz ardı edebilir
- Çoklu token tahmini, ardından gelen token’larla güçlü biçimde ilişkili token’lara daha büyük örtük ağırlık verir
- Bu, choice point güçlendirmesi olarak yorumlanabilir
- Yararlı metin üretiminin, choice point’lerde doğru kararları seçmeye bağlı olduğu düşünülür
- Bilgi kuramsal açılımda 2-token prediction, X ile Y arasındaki mutual information teriminin önemini next-token prediction’a göre daha fazla artıran bir biçimde görünür
Sınırlar ve maliyet
- Kalan konular, çoklu token tahmininde n’in otomatik seçilmesi, loss scale ve loss balancing kullanımı, vocabulary size ayarı ve embedding space’te çalışan yardımcı prediction loss geliştirilmesidir
- Tüm deney modellerinin eğitimi için toplam yaklaşık 500K GPU hours kullanıldı
- Donanım A100-80GB ve H100’dü
- Tahmini toplam emisyon yaklaşık 50 tCO2eq olup Meta’nın sustainability programı ile %100 offset edildi
- Amaç, dil modellerinin compute ve data efficiency’sini artırmak olsa da rebound effects’e dikkat edilmeli; LLM’lerin toplumsal yararları ve riskleri birlikte değerlendirilmelidir
1 yorum
Hacker News yorumları
Bu alanda çok fazla şey olup bitiyor
veri, ön eğitim, eğitim, çıkarım, uzman karışımı, RAG gibi terimlerin gerçek akış içinde ne zaman ortaya çıktığını fabrika turu gibi zaman sırasıyla anlatan bir kaynak olsa harika olurdu
Çoğu zaman büyük resimde bu terimlerin nereye oturduğunu bilmiyorum; ilk kez ön eğitimi gördüğümde, eğitimden önce veriyi işleme süreci sanmıştım ama aslında başka bir eğitim aşamasıymış
Bu alanda sinyal-gürültü oranı çok düşük ve Langchain gibi sektör liderlerinin dokümantasyonu bile şimdiden eskimiş ya da birbiriyle çelişiyor olabiliyor
Blockchain çılgınlığında da benzerdi; sanırım aşırı hype treninin bir özelliği bu
Özellikle RAG gibi son dönemde gelişimi çok hızlı olan alanlarda, bir süre güncelliğini koruyan bir başvuru kaynağı çıkarmak zor olduğu için nereden başlanacağını bilmek güç
Yine de LlamaIndex gibi daha üst seviye araçların dokümantasyonu, kavramın kendisini derinlemesine anlatmaktan çok büyük resimde nereye oturduğunu gösterdiği için başlangıç noktası olarak fena değil
YouTube ise her zaman olduğu gibi güncel modaya yaslanıp tıklama çekmeye çalışan uzman olmayan kişilerle dolu olduğundan, başlangıç noktası olarak pek iyi değil bence
Tabii bu her alanda biraz böyledir ama bunlara yama yapmaya çalışmak yerine, yakın gelecekte GPT-4'ten çok daha iyi bir şeyin çıkacağını varsayıp ürünleri bu varsayım üzerine farklılaştırarak tasarlamak daha mantıklı
Speculative decoding bilen biri için bu, temelde kendi kendine speculative decoding gibi
Tahmin edilen etiket dizisini yine otoregresif olarak ağa geri veriyor ve yalnızca eşleşen noktaya kadar olan tahminleri koruyorsunuz
Bu yüzden performans düşmüyor, sadece hız artıyor; burada en fazla 3 kat denmiş, speculative decoding için bu oldukça normal
Çoklu görev öğrenmesi sayesinde daha da iyi olabilir. Birkaç adım sonrasındaki hedefleri yardımcı kayıp olarak tahmin etme fikri zaten epey eski ve bu da iyi bir çalışma
Eğer speculative decoding planlama performansını da iyileştirirse, benimsenmesi daha kolay olur
Speculative decoding, model performansını çıktı doğruluğu ya da kalite açısından düşürmez
Matematiksel olarak, normal otoregresif decoding yapılsaydı örneklenen dağılımla değişen dağılım aynıdır; fark varsa bu sadece rastgelelikten kaynaklanır
Eğer performansı hız anlamında kullandıysanız, speculative decoding hızı düşürebilir; ama çoğu girdi ve uygun bir taslak model seçimi için böyle olmaması gerekir
LLM'ler dizi tahmininde, belirli bir çıktı uzunluğuna kadar mümkün olan tüm token kombinasyonlarının olasılık dağılımını hesaba katmıyor mu? Ben zaten bunu yaptıklarını sanıyordum
Öyle değilse, şu anki kadar iyi çalışmaları şaşırtıcı
Mesela 2 bitlik bir dizide olasılıklar ve ihtimaller 00: p=0.36, 01: p=0.04, 10: p=0.30, 11: p=0.30 ise en olası 2 bitlik dizi 00 olur
Ama sadece bir sonraki token'ı tahmin ederseniz 0: p=0.40, 1: p=0.60 olur; dolayısıyla sonraki bit 1 gibi görünür ve bu da bir sonraki biti tahmin ederken optimal olmayan bir başlangıç noktasına götürür
Uzun dizilerde, birleşik olasılık dağılımı marjinal dağılımlara ne kadar kötü ayrışıyorsa hata o kadar belirgin olur
Biraz daha düşününce, çapraz entropi kayıp fonksiyonunu eğitim verisinde yalnızca n'inci gelecekteki token'ı dikkate alacak şekilde değiştirip LLM performansıyla n arasındaki ilişkiyi çizen basit bir çalışma yapılabilir gibi geliyor
Mevcut tüm LLM'lerin n=1 olduğunu varsayarsak, sonraki 1'den n token'a kadar olan birleşik olasılık dağılımını tahmin etmek için gereken kaynak patlamasının büyük kısmını atlatmak mümkün olabilir diye düşünüyorum
Çünkü n'inci token'ı doğrudan tahmin etmek, örtük olarak daha iyi bir veri modeli gerektirir. En azından insan üretimi metinlerde böyledir; her veri türü için geçerli olmayabilir
LLM'ler, eğitim dağılımını izleyen metni örneklemek için tasarlanmıştır; ardından gelen “en olası” metni size söylemek için değil, zaten pratikte istediğimiz de bu değildir
Aksi halde çıktı çeşitliliği kaybolur
Verilen örnekte, bir sohbet uygulamasıysa %40 oranında 0 ve %60 oranında 1 örneklemek mantıklıdır
En olası cümlenin önemli olduğu soru yanıtlama gibi kullanım alanlarında, başkalarının da dediği gibi beam search yardımcı olur
Ayrıca modelin “ileriye bakıp” gelecekteki token'ları önceden hesaplayıp bunu mevcut token tahmininde kullanabildiğini de hesaba katmak gerekir
Nitekim [1] gibi çalışmalar bunu ele alıyor
Son olarak, bir seferde bir token tahmin etmek, insanların konuşurken yaptığı şeye benzer; yani yanlış bir yaklaşım değil. Biz de konuşmadan önce zihnimizde böyle bir “ileriye bakma” yapıyoruz
[1] https://arxiv.org/abs/2404.00859
Yanlış hatırlamıyorsam LLM çıktılarında tuhaf bir örüntü görülüyor; örneğin “an” çoğu zaman “a”dan daha düşük olasılıklı olduğu için beklenenden daha az sesli harfle başlayan isim üretiliyor
Yani bir dil modelini hangi dağılımla eğitir ve temperature 1 ile örneklerseniz, tam olarak aynı dağılımı elde edersiniz
Düşük temperature ile ya da greedy örnekleme yaparsanız, elbette farklı bir dağılım ortaya çıkar
Beam search gibi birden çok yerel optimizasyon odaklı örnekleme stratejisi var; speculative decoding gibi daha küresel örnekleme çalışmaları da çok yapıldı
Mevcut LLM’ler gerçekten her çıktı token’ı için en baştan mı başlıyor?
“Muzları sarı yapan nedir?” diye sorup “Bananas are yellow due to a pigment called bromelain.” diye yanıt verdiğini düşünelim; “a”yı üretirken sinir ağının içinde pigment ve bromelain kavramlarının zaten bir ölçüde etkinleşmiş olması bekleniyor gibi görünüyor
Artık fikrini değiştirip yanıtı “an optical illusion...” diye sürdüremez; yani bromelain adlı bir pigmentten söz etmeyi önceden planlamış gibi görünüyor
LLM, “a”yı üretirken yaptığı işi bir sonraki yanıtta kullanabilir mi? Sinir ağı durumu bir sonraki yanıt için korunabilir mi?
Başka bir açıdan bakarsak, GPT’den şu sonraki cümleyi tamamlamasını isteyebiliriz
“Bananas are yellow due to a” ve “Bananas are yellow due to an”
İlk durumda “Bananas are yellow due to a pigment called bromelain.” diye yanıt verebilir; ikincisinde ise “Bananas are yellow due to an organic compound called bromelain, which is a yellow pigment.” diyebilir
Her iki durumda da GPT, “a” ya da “an”ı seçmesinin yanıtın anlamını etkilememesi mümkündür
Uç bir yorumla, LLM’in “due to”dan sonra gelecek token için %55 “a”, %45 “an” gibi aptalca bir sezgisel kuralla hareket ettiğini bile düşünebilirsiniz
Elbette gerçekte durum daha sofistike, ama böyle sezgisel kurallar bile bu davranışı açıklamaya yeter
Ön eğitim verisine bromelain’le ilgili gerçekler eklenmemiş olsaydı, LLM gerçekten de “an optical illusion” gibi bir içerikle otomatik tamamlayabilirdi
GPT-3 bu tür olgusal hataları epey sık yapıyordu, ama “a” ve “an”ın dilbilgisi kurallarını öğrenmişti diye hatırlıyorum
Dediğiniz gibi, kavramların gerçekten önceden etkinleşmesi gerekmiyor gibi düşünüyorum; ama örtük ya da ortaya çıkan anlamda böyle bir ön etkinleşme yaşanıyor olabilir
Bir ölçüde attention, önceki token’ların hesaplamasını daha sonra işe yarar hale getiren mekanizmadır
KV cache’i, şimdiye kadarki metnin ve modele göre bu metin hakkında düşünülenlerin temsili olarak görebilirsiniz
Dil modeli tüm diziyi sonuna kadar öğrenir; bu yüzden böyle bir şeyin gerçekleşmesi olası görünüyor
Çoklu token tahmini bu davranışı açıkça teşvik eder, ama yalnızca tanımlanan küçük n token penceresi içinde
Öte yandan transformer dil modellerinde hesaplamayı daha verimli kullanmaya yönelik erken durdurma, depth mixing, SSM gibi yeni mimariler üzerine de çok çalışma var
LLM çıktısı genellikle en yüksek olasılıklı birkaç sonraki token/kelime arasından rastgele örneklenir, ama modelin kendisi örnekleyicinin hangi kelimeyi seçeceğini bilmez
Muhtemelen “a” ya da başka adaylardan sonra ne gelebileceğine dair kavramsal bir plan vardır, ama bu tür üst düzey öngörüler “a” üretildikten sonra yeniden sıfırdan değerlendirilir
Model yalnızca her kelime üretildikten sonra fikrini değiştirebilir değil, bunu yapmak zorundadır da
Bu yüzden bu tür “planlar” çok geçicidir; derin düşünüp yanıtı ve ifadeyi seçen bir insandan ziyade doğaçlama yapan bir freestyle rapçiye daha çok benzer
Şu yazı ilginç: https://clementneo.com/posts/2023/02/11/we-found-an-neuron
Çoğu LLM çıktısı olasısaldır
Çekirdek LLM, token’ları alır ve bir sonraki sırada gelebilecek token’ların sıralı bir kümesini ve bir “güven” değeri üretir
Sonrasında genellikle bir filtreleme ve arama aşaması gelir; bu aşamada sıralanan token’lar yeniden LLM’e verilir, daha fazla sıralı token elde edilir ve kısa bir olasılık ağacı oluşturulur
Örneğin en iyi N token yeniden verildiğinde, her biri kendi yeni en iyi N token kümesini üretir
Ardından bu ağaca bakıp toplam güveni en yüksek dalı, tekrar eden token’ı en az olan dalı ya da girdi token’larıyla eşleşen token’ı en az olan dalı seçmek gibi temel filtrelemeler yapılır; çoğu zaman bunların birleşimi ve toplam güvenle ağırlıklandırılmış rastgele seçim de eklenir
Bu yüzden ağırlıkları tamamen sabit bir LLM’e aynı girdiyi birden fazla kez verseniz bile farklı çıktılar alabilirsiniz
Yani sorunuza doğrudan yanıt vermek gerekirse, model “fikrini değiştirebilir”. Üretilen her token, olasısal çıktı filtresinin mümkün çıktı yolları arasından yeni bir yol seçmesi için bir fırsat yaratır
Bu çok naif bir soru olabilir ama, tüm cümlenin anlamını kodlayan bir vektör oluşturabildiğimizi varsayarsak neden LLM'leri tek bir kelime yerine bu cümle vektörünü tahmin edecek şekilde eğitemiyoruz?
Dil için otoenkoder eğitmek aslında görsel/video tarafına kıyasla metne gömülü bilgi miktarı daha az olduğu için oldukça kolay.
Zor kısım, tüm sinyal token uzayındaki tam eşleşmeden gelirken modeli anlamsal kısma odaklanmaya zorlamak.
Bu yüzden Yann LeCun'un ortak embedding tahmin mimarisi fikri ortaya çıkıyor.
Ayrıca yardımcı görevler daha fazla sinyal verir ama odağı kaydıran bir ödünleşim her zaman vardır.
Bizim durumumuzda, tahmin edilen token sayısı fazla olduğunda performans düşüşü gördük.
Dolayısıyla latent tahmin yöntemlerinin neyin faydalı olduğunu netleştirmesi gerekiyor.
Sorun şu ki, cevabı temsil eden vektörü elde ettikten sonra onu tekrar kelime temsiline çevirecek başka bir modele ihtiyaç duyarsınız.
Bu, metin için bir difüzyon modeli gibi bir şey olabilir.
Ayrıca bu difüzyon modelinin yaklaşıklandıracağı fonksiyon birebir olmayacaktır; en iyi ihtimalle örten, daha kötü ihtimalle matematiksel anlamda bir fonksiyon bile olmayabilir.
Çünkü tek bir embedding için birçok olası metin temsili vardır ve bunların çoğu dilbilgisel ya da anlamsal olarak geçerli olmayabilir.
Son olarak embedding, herhangi bir verinin kayıplı temsili olduğundan ters fonksiyon çok fazla nüans ve bağlam kaybına yol açar.
LLM'ler bu sorunu, sorgu ve önceki n token ile öz-tutarlılığı koruyarak sonraki token'ı, artık sonraki n token'ı tahmin ederek aşar; yaklaşıkladıkları fonksiyonların da büyük ölçüde örtene yakın olması gerekir.
Şu anda kabaca kelimelerle uğraştığı için yapay zeka yalnızca bildiği kelimeleri kullanabiliyor ama kelimelerle yeni cümleler sentezleyebiliyor.
Yapay zeka cümle düzeyinde çalışırsa, zaten gördüğü cümleleri tekrarlamaktan öteye geçemez gibi geliyor. O zaman yeni paragraflar sentezleyebilir ama yeni cümleler kuramaz.
İngilizcede cümlenin yapay zeka için faydalı bir soyutlama olduğundan emin değilim. İnsanlar için bile ancak kısmen faydalı.
Gündelik sohbetlere, e-postalara, YouTube yorumlarına bakınca bunların çoğu aslında cümle bile değil ya da noktalama kullanılmamış oluyor.
Cümlenin bir anlam birimine karşılık geldiğini düşünmüyorum.
Bir cümle yazara göre iki kelime de olabilir, İngilizce bir makalenin yarısı da; altı farklı fikri de kapsayabilir, yalnızca birini de.
Bir cümlenin nerede bittiği çoğunlukla anlamdan çok yazarın tarzına bağlıdır.
Bir cümleyi token'lara böldüğünüzde her token bir vektör temsili alıyor.
Cümle düzeyine çıkarsanız, tüm cümlelerin sözlüğü sonsuz hale gelir.
Bunu daha hızlı bir modelle yapabilirsiniz ama çıktı kalitesi muhtemelen düşer.
Makaleyi henüz çok ayrıntılı okumadım ama küçük bir editoryal yorumum var.
Ek L.2 tatmin ediciydi ama 5.2'deki sıkıştırılmış argüman bana biraz zayıf geldi.
Özellikle H(X) + H(Y) = H(X | Y) + 2I(X ; Y) + H(Y | X) eşitliğinde H(Y | X)'in “atılması” kısmı bana net gelmedi.
Üçüncü token Z'yi tahmin ediyorsak H(Y | X) örtük bağlam C'nin içinde olmalı; dolayısıyla bunu serbestçe atamayız, değil mi?
Ekte de bu argümanın daha netleştiğini düşünmedim.
Yine de bu, iddianın özünden şüphe duyacak kadar kafa karıştırıcı değildi; daha çok bir ifade biçimi meselesi.
O zaman 2 token'lık hedef H(X) + H(Y) içinde hangi kısım öğrenmeye yardımcı olan yardımcı bilgi, hangi kısım israf?
H(X | Y) ve I(X; Y) sonraki token üretimi için faydalı ama H(Y | X), tanımı gereği, sonraki token X ile ilgisiz bilgi miktarıdır.
Bu yüzden “çoklu token tahmini, H(Y)'nin faydalı bilgisi olan I(X; Y)'yi, H(Y | X) için yapılan boşa hesaplama ile takas eder” diyebiliriz.
Ancak H(Y | X)'in, önek (C, X) verildiğinde Y'yi tahmin etmenin sonraki-token entropisi olduğuna dikkat etmek gerekir.
Eğer attention mekanizması Y|X tahmini için zaten yaptığı hesabı sonraki adıma taşıyabiliyorsa, bu hesap aslında israf değil, önceden hesaplama olabilir.
LLM'lerin kelimenin tam anlamıyla dünyaya açılan yalnızca tek boyutlu bir pencereye sahip olduğunu söyleyen bir yazı okumuştum.
Her şey sadece token dizilerinden ibaret.
Belki bunun gibi çoklu tahminler o görüş alanını 1,1 boyuta kadar genişletebilir.
Her hâlükârda, o pencereyi bir şekilde 2 boyuta veya daha fazlasına genişletmek gerektiğine dair gerçek bir argüman var.
Örneğin FAIR düzeyinde kaynaklarınız varsa ve gerçekten iyi bir Java kodlama modeli eğitmek istiyorsanız, token yerine AST tahmin edecek şekilde eğitmek mantıklı olabilir.
Yorumları, tanımlayıcı adlarını vb. tahmin etmek için genel bir LLM ile birleşik bir yapıya hâlâ ihtiyaç olurdu ama programın kendisini token akışı olarak modellemezsiniz.
Bunun yerine “if bloğu ekle”, “4 parametreli metot çağrısı bloğu ekle” gibi şeyleri tahmin ettirebilirsiniz.
Ayrıca modeli, mevcut imlecin tür üyeleri gibi bilgiler için bağlam penceresinin belirli konumlarını ayıracak şekilde eğitebilir ve çıkarım döngüsünü IDE/LSP tarzı statik analizle entegre edebilirsiniz.
Böylece model, gerçek metinde bulunandan daha fazla bilgi görebilir.
Şu anda bu tür modelleri pek görmememizin nedeni, böyle araştırmaların pahalı olması ve yapay zeka tarafındaki insanların tamamen Python merkezli olması; Python da IDE'nin avantajlarından çok büyük fayda görmüyor.
Makine öğrenmesinde head kelimesi tutarlı biçimde kullanılmadığı için kafa karıştırıcı olabilir.
Bu makalede hem multihead attention hem de multiple output heads kavramları var.
Multihead attention, transformer mimarisinde girdinin farklı bölgelerine odaklanmayı ifade eder; buradaki biyolojik benzetme, merkezi işlem birimi olarak kafaya daha yakındır.
Output head ise sinir ağının son katmanını ifade eder ve aynı önceki katmanlara dayanarak farklı çıktılar üreten birden fazlası olabilir.
Bu da gevşek bir biyolojik benzetmedir ama CPU olarak kafa benzetmesinden çok, vücudun bir ucundaki kafa benzetmesine daha yakındır.
Hiçbiri, veri okuyan teyp kafasına yapılan bir benzetme değildir.
LLM'ler, kendi çıktısını yeniden girdi olarak besleme biçimi sayesinde önemli ölçüde “düşünüyormuş” gibi görünür; bu yüzden modeli sesli düşünmeye zorlamanın akıl yürütme kalitesini artırdığı sürekli olarak gözlemlenmiştir
Yani düşünce zinciriyle akıl yürütme, soruya doğrudan cevap vermekten farklı olarak, kendisinden ne istendiğini yeniden ifade etmesini, cevap verebilmek için hangi bilgilere ihtiyaç duyacağını üst düzey bir strateji olarak ortaya koymasını, bildiği bilgileri söylemesini ve bu bilgilerin ilk akıl yürütmesini nasıl etkileyeceğini açıklamasını sağlar
Ancak her anda birden fazla sonraki token'ı tahmin ettirme yaklaşımının özünde bunun tersine bir etki yaratmasından endişe ediliyor
Düşünce zinciri istemleri, modelin girdi olarak yalnızca n token'ı olduğundansa n + m token'ı olduğunda daha “zeki” olduğunu gösteriyor gibi görünüyor
Bu nedenle, verilen n için sonraki 5 token'ı almak, n'de sonraki 1 token'ı alıp ardından n+1'de sonraki 1 token'ı almak şeklindeki yaklaşımdan daha kötü sonuç verebilir
Bu özel yöntemin daha fazla token gerektirmesi önemli değildir
Ucuz bir model yoksa, LLM her zaman gerçek cevap yerine tahminle cevap verme eğiliminden etkilenecektir
Ayrıca çoğu speculative decoding stratejisi, modeli sıralı olarak çalıştırmakla aynı çıktıyı üretir
Tahmin yanlışsa ilgili token atılır ve sadece hız kazanımı ortadan kalkar
Token/kelime +1 ve +2 bağımsız olarak tahmin ediliyorsa, sonuç dilbilgisel olarak nasıl hâlâ anlamlı kalıyor? Sık sık bozulacakmış gibi duruyor?
Özette açık değil ama şekil 1 açıklamasında “çıkarım sırasında yalnızca sonraki token çıktı head'i kullanılır. İsteğe bağlı olarak diğer üç head, çıkarım süresini azaltmak için kullanılabilir” deniyor
En üst tahminlerin hepsi alınırsa üç head'in tamamı da kullanılabilir, ancak o durumda yaygın sampling stratejileri kullanılamaz
Benchmark dışındaki gerçek kullanımda temperature 0 ile LLM çalıştıran ne kadar kişi var bilmiyorum; sıcaklık uygulamaktan daha iyi bir şey yapılıyorsa durum yine farklı olabilir