"gzip beats BERT" makalesindeki sayılar neden tutmadı?

 (kenschutte.com)
1 puan yazan GN⁺ 2023-07-18 | 1 yorum | WhatsApp'ta paylaş
  • Jiang ve arkadaşlarının “Low-Resource” Text Classification makalesinde dikkat çeken gzip tabanlı kNN sınıflandırıcısının performansı, standart kNN doğruluğu olarak değil, k=2 için top-2'ye yakın bir yöntemle hesaplanmış olabilir
  • Resmi depodaki experiments.py içindeki calc_acc, eşit adaylar arasında doğru etiketlerden biri varsa doğru sayıyor; yani en yakın iki eğitim örneğinden yalnızca biri tutsa bile başarılı kabul ediliyor
  • İlk 4 veri kümesinin “Full” sütunu yeniden hesaplandığında çeşitli değerler değişiyor ve KirundiNews için gzip yöntemi en iyi performanstan en kötü performansa geriliyor
  • Ayrı bir yeniden uygulamada resmi kod çıktısı her zaman top2 ile aynı çıktı ve k=2 eşitliği yakın örneği önceleyerek çözülürse sonuç fiilen k=1 ile aynı oluyor
  • rand==True seçeneği eşitliği random.choice ile bozuyor, ancak makale sonuçlarında kullanılmadığı anlaşılıyor; SogouNews ise veri boyutu nedeniyle henüz çalıştırılamadı

Makale sonuçlarını yeniden üretirken ortaya çıkan doğruluk hesabı sorunu

  • Konu, Jiang ve arkadaşlarının “Low-Resource” Text Classification: A Parameter-Free Classification Method with Compressors çalışması; gzip tabanlı yöntemin birçok sinir ağı tabanlı yöntemden daha yüksek performans gösterdiği tablo Twitter'da ilgi gördü
  • Resmi kaynak kodunu yeniden üretme sürecinde, kNN sınıflandırıcısının doğruluk hesaplama biçiminin standart yaklaşımdan farklı çalıştığı bir nokta tespit edildi
  • Özellikle k=2 için bu, normal kNN(k=2) doğruluğundan ziyade top-2 doğruluğuna daha yakın; bu da makaledeki yöntemin performansını olduğundan yüksek gösterebilir

k=2 kNN'de eşitliğin neden sorun olduğu

  • Makaledeki yöntem bir kNN classifier kullanıyor ve Ek C'ye göre tüm deneylerde k=2 kullanılıyor
  • k=2 sınıflandırması, her test örneği için en yakın 2 eğitim örneğini bulduğu için etiket durumu basit
    • İki etiket aynıysa o etiket tahmin ediliyor; sonuç da fiilen k=1 ile aynı oluyor
    • İki etiket farklıysa 1:1 eşitlik oluşuyor; bu durumda yakın örneği önceleme gibi ayrı bir eşitlik bozma kuralı gerekiyor
  • Eşitlik rastgele bozulursa, 1:1 eşitliklerin yarısında daha uzak örnek seçileceği için k=1'den daha iyi sonuç vermesi zorlaşıyor

calc_acc eşitliği nasıl ele alıyor

  • Sorunlu nokta, experiments.py içindeki calc_acc metodu
  • Kod akışı, sorted_pred_lab içinde top-k örneklerin etiketlerini ve sayılarını topluyor, bunları etikete göre gruplayıp ardından sayı ölçütüne göre sıralıyor
  • En yüksek sayıyla eşit olan etiketler arasında dolaşırken, bunlardan biri bile test etiketiyle aynıysa if_right = 1 olarak ayarlanıp doğru kabul ediliyor
  • k=2'de iki farklı etiketin birer oy aldığı durumda, bu fiilen iki adaydan birinin doğru olup olmadığına bakmak anlamına geliyor
  • Bu sonuç, ImageNet'teki top-k doğruluğuna benziyor; ancak burada ölçüt seçilen k etiket değil, k eğitim örneği
  • Bu metod keyfi bir k değeri alıyor, ama her k için top-k hesaplamıyor; k=2 olduğunda tüm adayların en yüksek sayısının 1 olduğu özel bir durum ortaya çıkıyor
  • calc_acc içinde rand bayrağı da var ve rand==True olduğunda eşitlik random.choice ile bozuluyor, ancak bunun makale sonuçlarında kullanılmadığı görülüyor

Yeniden hesaplanan doğruluk değişimleri

  • İlk 4 veri kümesinin “Full” sütununda makaledeki değerler ile düzeltilmiş knn2d değerleri şöyle
Ayrım KinyarwandaNews KirundiNews DengueFilipino SwahiliNews
Makale 0.891 0.905 0.998 0.927
Düzeltilmiş knn2d 0.835 0.858 0.999 0.850
  • Beşinci veri kümesi olan SogouNews, büyük boyutu nedeniyle henüz çalıştırılmadı
  • Bu fark deneylerin yorumunu ciddi biçimde değiştiriyor; KirundiNews için gzip yöntemi en iyi performanstan en kötü performansa düşüyor

Ayrı uygulamayla doğrulanan sonuçlar

  • Ayrı uygulama iki farklı eşitlik bozma stratejisi kullandı
    • r: rastgele seçim
    • d: eşitlik kaybolana kadar k'yı azaltma
  • Yeniden uygulama sonuçları şöyle
Yöntem kinnews kirnews filipino swahili Açıklama
table5 0.891 0.905 0.998 0.927 Makaledeki tablo değerleri
code 0.891 0.906 1.000 0.927 npc_gzip deposu kullanıldı
top2 0.891 0.906 1.000 0.927 top-2
knn1r 0.835 0.858 0.999 0.850 kNN, k=1, eşitlikte rastgele
knn1d 0.835 0.858 0.999 0.850 kNN, k=1, eşitlikte k azaltma
knn2r 0.828 0.807 0.851 0.842 kNN, k=2, eşitlikte rastgele
knn3r 0.838 0.791 0.851 0.881 kNN, k=3, eşitlikte rastgele
knn2d 0.835 0.858 0.999 0.850 kNN, k=2, eşitlikte k azaltma
knn3d 0.843 0.794 0.904 0.883 kNN, k=3, eşitlikte k azaltma
  • Karşılaştırma sonuçları, resmi kodun ne hesapladığını gösteriyor
    • table5, code ile 0.001 veya 0.002 fark içinde; yani makaledeki değerler yeniden üretilebiliyor
    • code her zaman top2 ile aynı; yani resmi kod çıktısı, ayrı uygulamadaki top-2 sonucu ile örtüşüyor
    • knn1r == knn1d; k=1'de eşitlik oluşmuyor
    • knn2d == knn1d; k=2'de eşitlik ilk örnek lehine çözülürse sonuç k=1 ile aynı oluyor
    • knn2r < knn2d; çünkü k=2'de 1:1 eşitliklerde rastgele seçim vakaların yarısında daha uzak örneği seçiyor

Açık kalan noktalar

  • Daha fazla k değerini içeren yeni yeniden uygulama gzip-knn deposunda bulunuyor
  • DengueFilipino'nun bazı durumlarda 1.0 gibi çok yüksek çıkmasının nedeni sonraki yazı olan Part 2'de ele alınıyor
  • table5 ile codeun iki durumda neden hafif farklı olduğu ise hâlâ doğrulanması gereken bir konu

İlgili okumalar

1 yorum

 
GN⁺ 2023-07-18
Hacker News görüşleri

  • Yazarlar için hayal kırıklığı yaratıcı olabilir ama bunun harika bir çürütme olduğunu düşünüyorum
    Makine öğreniminde bu tür hataları yapmak gerçekten çok kolay ve daha da kötüsü, ince metodoloji hataları diğer mühendislik ve bilim alanlarında olduğu gibi genelde ölümcül bir başarısızlık olarak değil, ince performans değişimleri olarak ortaya çıkıyor
    Kötü veriler eğitim setine karışsa ya da hedef değer bilgisi sızsa bile sistem bir şekilde çalışmaya devam ediyor ve yalnızca sonuçlar hafifçe kirleniyor
    Mevcut sıkıştırma algoritmalarını makine öğrenimine uygulamak, umulduğunun aksine fazla bedava öğle yemeği gibi geliyor. Sıkıştırma algoritmalarında özel bir sihir olsaydı, transformer'ları sıkıştırıcı olarak kullanmak yerine sıkıştırma algoritmalarını encoder olarak kullanırdık

    • Bu noktayı mutlaka akılda tutmak gerekiyor. Hata yapmak kolay olduğu için yaygındır ve bilim gürültülü bir süreçtir ama içinde sinyal de vardır; şu anda gördüğümüz şey tam olarak akran değerlendirmesinin özü
      Bu yüzden sık sık, konferanslar ve dergilerden daha iyi akran değerlendirmesi biçiminin açık yayıncılık olduğunu savunuyorum. Akran değerlendirmesi, akranların benim çalışmamı değerlendirmesidir; konferans ya da dergilerin öne sürdüğü keyfi ve gürültülü standartlar işin özü değildir
      Tarihin büyük bölümünde sistem böyle işliyordu ve modern anlamdaki akran değerlendirmesi 1970'lerin ortalarına ait oldukça yeni bir kavram. Eski dergiler, bugün arxiv'in yaptığı gibi araştırmayı dağıtma görevine daha yakındı
      https://mitcommlab.mit.edu/broad/commkit/peer-review-a-histo...
      Konferans ve dergileri ortadan kaldırmayı savunmamın bir diğer nedeni de bunun, reprodüksiyon makaleleri ve başarısızlık makaleleri gibi önemli çalışmaları aktif biçimde teşvik edebilmesi. “Yenilik” ölçütüne bağlı kalmak gerekmez ve aslında neredeyse bütün araştırmalar artımlıdır
      “Yayınlamak”, çalışmamı akranlara iletmek ve onların sonuçları doğrulamasını ya da çürütmesini sağlamaktır
      Yine de konferansların insanları bir araya getirmesi ve iş birliğini teşvik etmesi iyi bir şey. Burada söylediğim, konferans ve dergilerin araştırmanın geçerliliğini değerlendirme aracı olarak kullanılmasına yönelik bir eleştiri
      Konferans sistemi yalnızca araştırma ve topluluğa davet eden bir alan olsaydı hiçbir sorun olmazdı. Dergiler de teoride yazarlarla hakemler arasında diyalog olması açısından iyi, ama bunun da arxiv + github ya da OpenReview ile kolayca yapılabileceğini düşünüyorum
    • Bu yaklaşım zaten kullanılıyor. Minimum açıklama uzunluğu ilkesi ve entropi tabanlı sınıflandırıcılara bakabilirsiniz
      Performansları kötü ama kesinlikle varlar ve dağıtımları da çok kolay. Benzer metinler daha iyi sıkışma eğiliminde olduğu için gzip'in intihal tespitinde kullanıldığını görmüştüm
      Sıkıştırma oranını yay modeli ağırlığı olarak kullanarak görselleştirme de yapılabiliyor ve ağ iletişimi meta verisine de uygulanabiliyor
    • Bu, birçok deneyde doğru. İstenen sonucu elde etme arzusu, gerçekte elde edileni doğrulama gereğini kolayca bastırıyor
      Özellikle de sonuç, mevcut düşünceleri doğruladığında daha da fazla
    • Son zamanlarda makine öğrenimini çok çalışıyorum ve bu örüntüyü sık görüyorum. Bir yazılım mühendisi olarak yaptığım neredeyse her şeyin tam tersi gibi hissettiren bir başka nokta bu
      Tek bir noktalı virgül eksik olsa anında hata alırsınız
      Ama üç katmandan birindeki gradyan hesaplamasını yanlış yapsanız bile bazen çalışabilir. Sadece sonuçlar tuhaflaşır
    • Akademik araştırma kodu çoğunlukla amatörler tarafından olabildiğince hızlı yazılmış dağınık koddur, neredeyse hiç testi yoktur ve bu kodun başlıca çıktısı makale atfı biriktirmektir
      Bilimsel makalelerin yarıya indiği ve özenin iki katına çıktığı bir dünya çok daha fazla değer üretirdi, ama tüm sistem umutsuz derecede oyunlaştırılmış durumda

  • Bu blog yazısını yazan kişi benim. Burada yazdıklarımdan oldukça eminim ama gözden kaçırdığım bir şey varsa yazarların bunu doğrudan açıklaması gerekebilir
    Az önce GitHub'da bir issue açtım: https://github.com/bazingagin/npc_gzip/issues/3

    • Yazının en üstüne bir not eklemeyi düşünebilirsiniz. Pek çok kişi sadece başlığı hızlıca tarayıp “gzip makalesi çöp ve gzip yaklaşımı kötü” sonucunu çıkarıyor gibi görünüyor, oysa gerçek tablo daha çok “gzip yaklaşımı derin sinir ağı modellerinden daha iyi değil ama genel olarak rekabetçi ve çalıştırma maliyeti çok daha düşük” şeklinde
      Makalenin kendisi hâlâ sağlam
    • Makalenin birinci yazarıyım ve blog yazısını okudum. k=2 seçmemizin nedeni n^{1/2} kullanımının önerilmesi ve 5-shot ayarıyla uyuşan bir k seçmek istememizdi
      Ama bu seçimin biraz tuhaf olduğu söylenirse hak veririm. Makalede ve Twitter'da söylediğim gibi, k değeri değişince sonuçlar da değişiyor ve raporladığımız şey elde edilebilecek en yüksek sonuçtu; yani tahminin her zaman doğru olduğu ideal bir durumu ifade ediyor
      W2V ve SentBERT için de aynı stratejiyi kullandık. Ama bu, top-2 doğruluğu anlamına gelmiyor. Bildiğim kadarıyla top-2 doğruluk, tahmin edilen en üst 2 sınıftan biri doğruysa puan verilmesi demek
      Ancak işaret edildiği gibi, kNN'de k=2 iken en yakın 2 komşunun aynı sınıfı işaret ettiği durumlar vardır ve bu durumda top-2 doğruluğu rapor ederseniz diğer bir sınıf adayını kaçırmış olursunuz
      Zaman bulup arxiv'e yeni bir sürüm yüklediğimde, farklı stratejiler ve farklı k değerleri için sonuçlar eklemek istiyorum. Blogda bahsettiğiniz decrement stratejisi gerçekten çok iyi ve isterseniz depoya eklemek isterim
      Kısa ve geç yanıt için kusura bakmayın. Depoya hâlâ bakamadım. Yarın makale değerlendirmesi için hazırlanıyorum; biter bitmez issue'ya yanıt verip çözeceğim
    • Bunu yeniden üretip paylaştığınız için teşekkürler, önemli bir çalışma
      Diğer sonuç tablosu olan Table 3'ü de yeniden üretip üretmediğinizi merak ediyorum
      Doğru anladıysam, yalnızca 2 sınıf olduğunda top-2 doğruluğu 1 olur ama sınıf sayısı arttıkça bunun “normal” doğrulukla arasındaki ortalama fark giderek azalır. Bu yüzden veri kümesinde çok sayıda sınıf varsa Table 3 sonuçları o kadar büyük değişmeyebilir
      Her hâlükârda, 20-newsgroups veri kümesinde top-2 doğruluğunun 0.685 olması, karakteri bile karakter olarak görmeyen bir yöntem için oldukça etkileyici[1]. Token'lar, n-gram'ler, embedding'ler gibi doğal dil işleme araştırmacılarının yıllardır emek verdiği iyi araçlardan hiç söz etmiyorum bile
      [1] Benim anladığım kadarıyla gzip yalnızca bit dizileriyle çalışıyor ve bu da sözcüklerle, yani bayt sınırlarıyla zorunlu olarak hizalı değil
    • Yayınlamadan önce yazarlara önce ulaşıp ulaşmadığınızı merak ediyorum

  • Shopify’de arama alaka düzeyi deneyleri yaparken ben de çok hata yaptım; bu yüzden yazarlara empati duyuyorum. Benim de kamuoyu önünde rezil olduğum epey hata oldu
    Shopify’de son dönemlerimde, iyi bilimin iyi yazılım mühendisliği gerektirdiğini öğrendim. Çünkü yığının çok fazla noktasında hata yapmak kolay
    Bu yüzden sayılara güvenebilmek ve birbirimizin deneylerini yeniden üretebilmek için, katı, bol testli ve yüksek kaliteli deney yazılımları geliştirmeye çok zaman harcadım
    Tek seferlik değerlendirme yöntemlerinden kaçınmaya çalıştım; yeni bir yöntem oluşturduğumda onu değerlendirme araç setine ekliyor, ardından bu metriğin ne anlama geldiğini anlamak için test ediyordum
    Kulağa bariz geliyor ama bu tür deneyler yapmış biri olarak deneyimime göre maalesef bu, olması gerektiği kadar yaygın değil. Şirketler hız istiyor ve istatistik üzerine derin düşünmek ya da iç araçlar geliştirmek çoğu zaman üst yönetimin çıkarlarıyla pek örtüşmüyor

    • “İyi bilim iyi yazılım mühendisliği gerektirir” sözü, endüstriyel araştırmanın olumlu yanlarından biri
      Birincisi, daha fazla yazılım mühendisliği uzmanlığı kullanılabiliyor; ikincisi de iddiaları abartmaya daha az teşvik var. Çünkü bir şeyin çalıştığını söylerseniz, onu gerçek üretim ortamına koymanız beklenecek

  • Bu blog yazısının yayımlanmış olmasına sevindim
    Ben de böyle küçük projeleri gerçekten çok yapıyorum; hatta bir makaledeki sorunu gösteren bu tür çalışmalar bile çoğu zaman gün yüzüne çıkmıyor. Genelde kısa bir çıkış yapılıyor, sonra da sabit diskte gömülü kalıp bitiyor
    O yüzden bunu paylaşmış olmalarına teşekkürler

    • Son zamanlarda Twitter’ı düşük maliyetli bir blog gibi kullanmaya başladım
      Böyle bir işe bir gün harcadıktan sonra genelde gerçekten bir blog yazısı yazacak enerjim kalmıyor; bu da boşa gitmiş gibi hissettiriyor. Yine de kısa bir Twitter flood’u yazmak çoğu zaman mümkün oluyor

  • Bu sonucu görmek gerçekten sevindirici. kNN + sınıflandırma görevi + saf metin benzerliğine dayalı sınıflandırma, sonuçların kolayca lehine yığılabildiği bir kombinasyon
    Bu makaleye sevinçle yaklaşan tepkiler, doğal dil bileşeninin embedding’lerde neden temel derecede önemli olduğunu yanlış anlıyor. Aynı kelimeleri paylaşan ifadeler hem sınıflandırmada iyi çalışır hem de GZIP’te iyi sıkışır; dolayısıyla GZIP bir yedek sınıflandırıcı olarak kullanılabilir
    BERT’in ya da embedding’lerin asıl mucizesi, ortak kelime paylaşımına ihtiyaç duymamalarıdır. Örneğin “what is my safe passcode?” ifadesi, “my lockbox pin is 1234” ile güçlü biçimde eşleşir; ama “my jewelry is stored safely in the safe” ile eşleşmez
    Bu nokta LLM’lerde de önemli. Birçok kişi metin benzerliği için embedding kullanıyor ama aslında soru ile cevabını içeren belgenin ilişkili olmasını öğrenecek şekilde eğitilmiş bir SBERT modeli kullanmak gerekiyor
    Tüm tavşan deliğini https://www.sbert.net/ adresinde görebilirsiniz
    Önceki yazı: Should you use OpenAI's embeddings? Probably not, and here's why. https://iamnotarobot.substack.com/p/should-you-use-openais-e...
    HN tartışması: https://news.ycombinator.com/item?id=35377935

    • Adil olmak gerekirse, asıl görev baştan kNN+compression gibi yöntemlerin iyi sonuç verme ihtimalinin olduğu bir alan olarak, yani alan dışı + düşük kaynaklı bir ortam için bilinçli biçimde seçilmişti
      Bu koşullarda eğitim girdisi fazla seyrek olduğundan, çok parametreli modellerin iyi embedding’ler öğrenmesi zor olabilir
      Geleneksel alan içi büyük veri sınıflandırma kurulumlarında, compression gibi parametrik olmayan yöntemlerin öğrenilmiş temsilleri geçme ihtimali yok

  • Yazarların neden sınıflandırıcı olarak kNN’i seçtiği net değildi. Bir uzaklık matrisi oluşturdularsa, matrisi çok boyutlu ölçekleme ile faktörlere dönüştürüp ardından xgboost gibi ağaç algoritmaları kullanılabilirdi; böylece kNN’den daha fazla bilgi kullanılıp çok daha iyi sonuçlar alınmış olma ihtimali yüksek
    LZ ailesi sıkıştırıcılardan çok daha iyi olan PAQ sıkıştırma algoritması da kullanılabilirdi. Bu seçimler sonuçları ciddi biçimde iyileştirip orijinal sonuca ulaştırmış olabilir
    Bu makalede hoşuma giden şey, sıkıştırma algoritmasını soyutlamış olmasıydı; bu da p(x) ~ K^(-|x|) ilişkisinden hareketle sıkıştırmayla başka neler yapılabileceğini düşündürüyor. Burada K alfabe boyutu, |x| ise x dizgesinin uzunluğu; optimal kodlama varsayılıyor
    Örneğin her yanıtın faktörlerini ayrı belgeler hâlinde gruplayıp, makaledekine benzer şekilde bir sonraki örneği en iyi sıkıştıran belgeyi bularak sınıfı belirleyen geleneksel bir sınıflandırma da yapılabilir diye düşündüm. Bu, bir tür sıkıştırma algoritması kullanan gözetimli sınıflandırma olurdu
    Sıkıştırıcı ilgili veri kümesinin optimal koduna ne kadar yakınsa, o kadar iyi çalışacaktır
    Sıralı tahmin yaklaşımını uygulamak da benzer şekilde basit
    Hoş bir sürprizdi

  • Bir sıkıştırma algoritmasının LLM'leri nasıl yenebildiğini açıklayabilir misiniz? Bu, konuşmanın grafitiden daha iyi olduğunu söylemek gibi geliyor
    Cevap bir yerlerde varmış gibi duruyor ama yapay zekaya aşina olmadığım için bir türlü anlayamıyorum

    • Genel olarak sıkıştırma = model + entropi kodlama demektir
      Modelin görevi sırada neyin geleceğini tahmin etmektir; entropi kodlayıcının görevi ise tahmin ile gerçek sonraki değer arasındaki farkı kodlamak ve daha olası sonuçların mümkün olduğunca az bit kullanmasını sağlamaktır
      Model ne kadar doğruysa gerçek ile tahmin arasındaki fark o kadar küçülür, entropi kodlayıcının ihtiyaç duyduğu bit sayısı da azalır; böylece sıkıştırma iyileşir
      Basit sıkıştırma algoritmaları, “aynı baytı 10 kez gördüysem 11'incinin de aynı olma olasılığı yüksektir” gibi basit modeller kullanır. Ama LLM'ler de model olarak kullanılabilir. Çünkü LLM'lerin yaptığı şey, metni en olası kelimeyle tamamlamaktır
      Burada ise bunun tersi yapılmış. Sıkıştırmada bir model kullanmak yerine, birkaç hileyle sıkıştırma algoritması model gibi kullanılmış. Sıkıştırma algoritması bir sonucu daha az bit ile kodladığında, bu onun en olası sonuç olduğu şeklinde yorumlanıyor
      Orijinal makalenin yazarları, bazı görevlerde gzip'ten çıkarılabilen basit modelin çok daha karmaşık LLM'leri geçtiğini göstermişti
    • Dil modeli, kelime dizisinin olasılığını P(w_1, ..., w_n) ya da eşdeğer olarak P(kelime | bağlam) şeklinde tahmin eder
      Sıkıştırmada, olasılığı yüksek kelime dizilerine daha kısa kodlar verilmesi gerektiğinden doğrudan bir ilişki vardır. Olasılığa dayalı böyle kodlar üretmenin iyi bilinen bir yolu Huffman kodlamadır
      Bu, ister kelime frekanslarını kullanan istatistiksel bir dil modeli olsun ister olasılık tahmini için bir LLM kullanılsın geçerlidir. Dil modeli ne kadar iyiyse, yani perplexity ne kadar düşükse, sıkıştırma sonucu o kadar kısa olur
      Tersinden bakarsak, bir sıkıştırma algoritmasının da kod uzunlukları üzerinden örtük biçimde bir dil modeli tanımladığı söylenebilir. Örneğin tekrar eden dizgilerin rastgele gürültüden daha olası olduğunu varsayar
    • gzip yaklaşımının sezgisi şöyledir
      ABC sıkıştırıldığında X bayt olur. Ardından ABCABC sıkıştırıldığında 2X bayt olmaz. Art arda eklenen iki dizgi ne kadar benzerse, gereken bayt sayısı o kadar azalır
      ABCABD, ABCABC'den daha büyük ama ABCXYZ'den daha küçük olacaktır
      Ayrıca BERT'in günümüz ölçütlerine göre çok küçük bir LLM olduğunu ve bugün sık gördüğümüz milyarlarca parametreli modellere kıyasla daha zayıf performans gösterdiğini de biliyoruz
    • Sıkıştırma, zekâ ile eşdeğerdir
      https://mattmahoney.net/dc/rationale.html
    • Bu çok sınırlı bir görev. Bir belge alıp onu örneğin 10 kadar kategoriden birine sınıflandırıyorsunuz
      Belirli kelimeleri tespit etmeye dayalı bir yöntem de bazı durumlarda oldukça iyi iş görebilir. İyi sıkıştırılan şeylerde ortak alt dizgiler sık görülür

  • Eğer bu doğruysa, o makale hakkında büyük büyük konuşan insanların şimdi nasıl sessizce izlerini sildiğini görmek isterim
    Özellikle LinkedIn ve Twitter fenomenlerini kastediyorum
    Doğru değilse aptal gibi görüneceğim ama makaleye sadece üstünkörü göz attım

  • Bir sınıflandırıcı olarak Gzip şaşırtıcı derecede iyi ve sinir ağları için bir baseline olarak kullanılmalı

  • Bu arada blog 2022'de kalmış gibi görünüyor
    Yazı tarihi 17 Temmuz 2022 olarak görünüyor

    • Teşekkürler. Yakında düzeltilecek. Tarihi elle yazınca böyle oluyor...