Büyük dil modellerinde under-trained token’ları otomatik tespit etme tekniği

• LLM’lerde tokenizer oluşturma ile model eğitimi birbirinden ayrı olduğu için, _SolidGoldMagikarp gibi belirli token’lar beklenmedik davranışlara yol açabilir
• Sorunun özü, tokenizer sözlüğünde bulunmasına rağmen eğitim sırasında neredeyse hiç ya da hiç görülmeyen under-trained tokens’tır; bunlar sıklıkla ‘glitch tokens’ olarak adlandırılır
• Araştırma, tokenizer analizi, model embedding ağırlık göstergeleri ve prompting tekniklerini birleştirerek bu tür token’ları otomatik olarak bulma yöntemi öneriyor
• Bu token’lar sabit boyutlu tokenizer’ın sözlük kapasitesini boşa harcar ve girdi/çıktı uzunluğunu, çıkarım maliyetini, halüsinasyonları veya bozuk çıktıları etkileyebilir
• Harici verileri arayıp işleyen araç kullanımı ve ajan ortamlarında, under-trained token tespiti ve iyileştirmesi dağıtımdaki modellerin güvenliği ve sağlamlığıyla doğrudan bağlantılıdır

---

Tokenizer ile model eğitimi arasındaki uyumsuzluk

• Çoğu LLM bileşeni büyük ölçekli veriler üzerinde gözetimsiz şekilde eğitilirken, tokenizer genellikle ayrı bir algoritma ve daha küçük bir veri kümesiyle bağımsız olarak eğitilir
• GPT-2, günümüzde Transformer tabanlı dil modellemesinin birçok temelini oluşturdu ve byte-pair encoding (BPE) tabanlı tokenizasyon çerçevesi de geniş ölçüde benimsendi
• BPE tokenizasyonu, girdi metnini alt sözcük token dizilerine dönüştürür ve sabit birleştirme kurallarına göre yan yana iki token’ı tekrar tekrar birleştirir
• Birleştirme kuralları, LLM eğitim verisini temsil etmesi gereken daha küçük bir veri kümesi üzerinde açgözlü bir öğrenme algoritmasıyla öğrenilir

Glitch token’ların ortaya çıkma yapısı

• Tokenizer ile model eğitimi ayrıldığında, bazı token’ların model eğitimi sırasında neredeyse hiç ya da hiç görünmediği bir durum oluşabilir
• Bu tür token’lar girdiye dahil edildiğinde halüsinasyonlar veya bozuk çıktılar gibi beklenmedik davranışlar tetikleyebilir
• Araştırma, bu token’ları under-trained tokens veya untrained tokens olarak ayırıyor
  • untrained, yalnızca belirli bir token’ın model eğitim verisinde yer almadığına dair açık işaretler olduğunda kullanılır
  • Genel olarak bunlar ‘glitch tokens’ adıyla da anılır
• Temsili örnek olarak _SolidGoldMagikarp token’ından söz ediliyor

Mevcut tokenizasyon yöntemlerinin sınırları ve alternatifler

• Son araştırmalar, tokenizasyonu kaldırıp ham bayt girdisine geçme yaklaşımını da ele aldı; ancak bu tercih genellikle çıkarım hızı maliyeti yaratır
• Bu hız maliyeti, ilk ve son katmanlardaki özel mimariler veya ara katmanlardaki değişken hesaplama ile telafi edilebilir
• Bu yaklaşım henüz yaygın biçimde benimsenmiş değil ve modern modellerin çoğu hâlâ alt sözcük tokenizasyonuna dayanıyor
• BPE’nin başlıca alternatifi Unigram yöntemidir; BPE’den daha iyi olabileceğini gösteren çalışmalar olsa da genel olarak yaygın kullanılmıyor

Under-trained token’ların pratikte yarattığı sorunlar

• under-trained token’lar, sabit boyutlu tokenizer’da daha sık görülen token’ların kullanabileceği sözlük kapasitesini işgal eder
  • Bu da ortalama girdi/çıktı uzunluğunu ve çıkarım maliyetini azaltma fırsatının kaçırılmasına neden olabilir
• Bu token’lar girdi verisine kasıtlı ya da tesadüfi olarak dahil edildiğinde, istenmeyen model çıktıları üretebilir ve downstream uygulamaları bozabilir
• LLM’lerin araç kullanımı ve ajanların harici verileri arayıp işlemesi yaygınlaştıkça, beklenmedik veya kötü niyetli girdilere karşı sağlamlık daha önemli hale geliyor
• Model eğitim dağılımının dışına itildiğinde, bu token’ların guardrail atlatmak için kötüye kullanılma ihtimali de var

Otomatik tespit yaklaşımı ve açık araçlar

• Daha önce de model ve tokenizer analizleriyle bu tür token’ları bulmaya yönelik çalışmalar vardı; ancak farklı modellerde tutarlı biçimde çalışan güvenilir otomatik yöntemler eksikti
• Araştırma, sorunlu token’ları belirlemek için üç yöntemi birleştiriyor
  • tokenizer analizi
  • model embedding ağırlıklarına dayalı göstergeler
  • prompting teknikleri
• Bu yöntemler, popüler ve yakın zamanda yayımlanmış çeşitli açık ağırlıklı modeller üzerinde uygulandı; ayrıca kapalı modellere genişletme yöntemi de kısaca incelendi
• Hugging Face modelleriyle uyumlu genel analiz aracı ve modele özel ayrıntılı sonuçlar da yayımlandı
  • cohere-ai/magikarp

[GN⁺]

Hacker News yorumları

• 1 yıl önceki Computerphile'ın glitch token videosu iyiydi: https://www.youtube.com/watch?v=WO2X3oZEJOA

  • Bu video nedense makalenin ön baskısından daha ilgi çekici görünüyor

• Yalnızca yetersiz eğitilmiş token'ları bulmakla kalmamalıyız; token'lar fiilen sinir ağının ilk katmanı olduğundan, diğer tüm katmanlardaki tüm ağırlıklarda da eğitim verisi dengesizliğini aramak gerekir
  Böyle ağırlıkları bulursak, içinden neredeyse hiç veri akmayan ağırlıkları silmek daha iyi olabilir; bu da modeli küçültebilir veya genellemeye yardımcı olabilir

  • Bence model distillation bunu yapıyor. SparseGPT bunun büyük bir örneğiydi ve yanlış hatırlamıyorsam doğruluğu ciddi biçimde düşürmeden parametrelerin %50'sini kaldırmıştı
    Son dönemde SparseGPT'yi referans alan ve seyreklik oranını %70-80 civarına çıkaran makaleler de gördüm; oldukça etkileyiciydi
  • “İçinden neredeyse hiç veri akmayan ağırlıkları silmek” zaten seyrek sinir ağları fikri değil mi?
  • Zaten dense modeller sıkıştırılabiliyor veya birleştirilebiliyor

• Kanadalı bir şirketin modelinde hokeyle ilgili yetersiz eğitilmiş token'lar bulunmuş olması inanması zor bir şey, Almanca olsa bile
  Şaka bir yana, oldukça hoş bir çalışma ve tokenization'ın model üzerindeki etkisine dair anlayışımızın daha da gelişmesini umuyorum. Özellikle ilk dönem açık kaynak modellerin önemli bir kısmının carriage return konusunda sorun yaşadığının ortaya çıkması dikkat çekici; veri kaynağına bağlı olarak carriage return o kadar da nadir olmayabiliyor

• Ağırlık korelasyon matrisinin spektral yoğunluğunu kullanan, rastgele matris teorisine dayalı bir eğitim tanılama yöntemi var
  Her katmanın spektral yoğunluğu kesilmiş bir kuvvet yasasına uyduruluyor ve kuvvet yasası üssü alfa 2'den biraz büyükse iyi eğitilmiş kabul ediliyor
  https://jmlr.org/beta/papers/v22/20-410.html

• Çözüm basitçe tokenizer'ı LLM ile aynı korpus üzerinde eğitmek değil mi? Tokenizer yeniden kullanımı neden bu kadar yaygın, pek anlamıyorum. Bilen var mı?

  • Başkalarının söylediklerine ek olarak, tokenizer'ı eğitim veri kümesiyle tamamen aynı veride eğitseniz bile bu sorunların hepsi ortadan kalkmaz
    BPE yaklaşımında bazı token'lar diğerleriyle birleştikçe çok nadir token'lar ortaya çıkabilir. Diyelim ki X ve Y token'ları var ve neredeyse her X'in ardından Y geliyor; BPE süreci yeni bir XY token'ı oluşturur ama mevcut X token'ını kaldırmaz, böylece X yetersiz eğitilmiş hale gelir
    Bunu çözmek için açgözlü birleştirmeden daha sofistike bir birleştirme algoritması gerekebilir
  • Tokenizer'ın yeniden kullanılmasının iki nedeni aklıma geliyor
    Birincisi, sıfırdan başlamak yerine modelin ön eğitimini sürdürmek istemek. Ancak bazıları, yeni bir tokenizer ile eğitim yapsanız bile model ağırlıklarını oldukça kolay şekilde yeniden kullanabileceğinizi bilmiyor olabilir. Bunun yöntemini anlatan bir yazı yazdım: https://umarbutler.com/how-to-reuse-model-weights-when-train...
    İkincisi ise son kullanıcı için kolaylık. Çok büyük bir korpusu token'lara ayırıp parçalara bölmek zaman alabilir; veriyi bir kez GPT2 tokenizer ile işleyip ardından aynı veri üzerinde birden çok modeli eğitebiliyorsanız, her şeyi baştan token'lara ayırmak zorunda kalmamak güzel olur
  • Özete bakılırsa bu tür teknikler, korpusa erişimin olmadığı durumlarda faydalı görünüyor. Örneğin açık kaynak ağırlıkları indirilebiliyor ama korpus gizli tutuluyor
    Aksi halde korpusun istatistiksel bir örnekleminden token histogramını hesaplamak yeterli olmaz mı diye düşünüyorum
  • Genelde işe tokenizer ve LLM için aynı korpusu kullanarak başlanır, ama tokenizer eğitildikten sonra LLM'yi test etme sürecinde korpusun bir kısmının işe yaramaz ıvır zıvır olduğu fark edilir
    counting subreddit'te emek veren SolidGoldMagikarp'a kötü bir niyet atfetmiyorum ama bu tür şeyler daha sonraki eğitimlerden çıkarılır. Fakat o noktada tokenizer zaten API'nin bir parçası haline gelmiştir; yeni bir sürüme geçmek başka şeyleri bozacağından gereksiz token'lar sözlükte kalır
  • Mümkün, ama korpus çok büyükse pratikte zor

• Makalenin başlığı gerçekten harika

  • Tam başlık şu: “Fishing for Magikarp: Automatically Detecting Under-trained Tokens in Large Language Models”