"gzip beats BERT" पेपर के आंकड़े क्यों मेल नहीं खाए?

 (kenschutte.com)
1 पॉइंट द्वारा GN⁺ 2023-07-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Jiang et al. के “Low-Resource” Text Classification पेपर में चर्चा में आए gzip-आधारित kNN classifier का प्रदर्शन सामान्य kNN accuracy नहीं था, बल्कि संभव है कि k=2 पर top-2 के करीब तरीके से calculate किया गया था
  • आधिकारिक repository के experiments.py में calc_acc tie candidates में अगर सही label एक भी हो तो उसे सही मानता है, इसलिए दो नज़दीकी training samples में से सिर्फ एक सही होने पर भी इसे success के रूप में गिना जाता है
  • पहले 4 datasets के “Full” column को दोबारा calculate करने पर कई आंकड़े बदलते हैं, और KirundiNews में gzip method best performance से गिरकर worst performance पर आ जाता है
  • अलग reimplementation में official code का output हमेशा top2 जैसा था, और k=2 tie को closest sample priority से resolve करने पर नतीजा practically k=1 जैसा हो जाता है
  • rand==True option random.choice से tie तोड़ता है, लेकिन लगता है कि paper results में इसका उपयोग नहीं हुआ; SogouNews dataset size के कारण अभी run नहीं किया गया है

Paper results reproduce करते समय सामने आई accuracy calculation की समस्या

  • विषय Jiang et al. का “Low-Resource” Text Classification: A Parameter-Free Classification Method with Compressors है, जिसमें gzip-based method को कई neural-network-based methods से बेहतर performance दिखाने वाली table Twitter पर चर्चा में आई
  • आधिकारिक source code reproduce करने के दौरान यह पाया गया कि kNN classifier की accuracy calculation method सामान्य तरीके से अलग behave करती है
  • खासकर k=2 में यह normal kNN(k=2) accuracy के बजाय top-2 accuracy के करीब है, जिससे paper method का performance अधिक दिख सकता है

k=2 kNN में tie समस्या क्यों बनता है

  • Paper method kNN classifier का इस्तेमाल करता है, और Appendix C के अनुसार सभी experiments में k=2 use किया गया है
  • k=2 classification हर test sample के लिए 2 सबसे नज़दीकी training samples ढूंढता है, इसलिए label की स्थिति सरल होती है
    • अगर दोनों labels समान हैं, तो वही label predict होता है, और परिणामस्वरूप answer k=1 जैसा ही होता है
    • अगर दोनों labels अलग हैं, तो 1:1 tie बनता है, इसलिए closest sample priority जैसे अलग tie-breaking rule की जरूरत होती है
  • अगर tie random तरीके से तोड़ा जाए, तो 1:1 ties के आधे मामलों में दूर वाला sample चुना जाएगा, इसलिए k=1 से बेहतर होना मुश्किल है

calc_acc tie को कैसे handle करता है

  • समस्या वाला point experiments.py का calc_acc method है
  • Code flow में sorted_pred_lab में top-k samples के labels और counts collect किए जाते हैं, फिर labels के हिसाब से group करके count के आधार पर sort किया जाता है
  • सबसे ऊंचे count से tie करने वाले labels पर iterate करते हुए, उनमें से कोई एक भी test label जैसा हो तो if_right = 1 set कर दिया जाता है और उसे सही answer माना जाता है
  • k=2 में जब दो अलग labels को 1-1 vote मिलता है, तो यह बस check करता है कि दो candidates में से कोई एक correct है या नहीं
  • यह result ImageNet में कही जाने वाली top-k accuracy जैसा है, लेकिन फर्क यह है कि यहां selected k labels नहीं, बल्कि k training samples आधार बनते हैं
  • यह method arbitrary k लेता है, लेकिन हर k पर top-k calculate नहीं करता; k=2 पर सभी candidates के maximum count 1 में बंध जाने की special situation बनती है
  • calc_acc में rand flag है और rand==True में random.choice से tie तोड़ा जाता है, लेकिन लगता है कि paper results में इसका इस्तेमाल नहीं हुआ

Recalculated accuracy में बदलाव

  • पहले 4 datasets के “Full” column में paper numbers और corrected knn2d numbers इस प्रकार हैं
श्रेणी KinyarwandaNews KirundiNews DengueFilipino SwahiliNews
पेपर 0.891 0.905 0.998 0.927
corrected knn2d 0.835 0.858 0.999 0.850
  • पांचवां dataset SogouNews बड़ा होने के कारण अभी run नहीं किया गया है
  • इस अंतर से experiment interpretation काफी बदल जाती है, और KirundiNews में gzip method best performance से worst performance पर आ जाता है

अलग implementation से verify किए गए results

  • अलग implementation ने दो tie-breaking strategies का इस्तेमाल किया
    • r: random choice
    • d: tie खत्म होने तक k घटाना
  • Reimplementation results इस प्रकार हैं
तरीका kinnews kirnews filipino swahili विवरण
table5 0.891 0.905 0.998 0.927 paper table numbers
code 0.891 0.906 1.000 0.927 npc_gzip repository का इस्तेमाल
top2 0.891 0.906 1.000 0.927 top-2
knn1r 0.835 0.858 0.999 0.850 kNN, k=1, random tie
knn1d 0.835 0.858 0.999 0.850 kNN, k=1, tie पर k घटाना
knn2r 0.828 0.807 0.851 0.842 kNN, k=2, random tie
knn3r 0.838 0.791 0.851 0.881 kNN, k=3, random tie
knn2d 0.835 0.858 0.999 0.850 kNN, k=2, tie पर k घटाना
knn3d 0.843 0.794 0.904 0.883 kNN, k=3, tie पर k घटाना
  • Verification results दिखाते हैं कि official code ने क्या calculate किया
    • table5, code से 0.001 या 0.002 के भीतर close है, इसलिए paper numbers reproduce किए जा सकते हैं
    • code हमेशा top2 जैसा है, यानी official code result अलग implementation के top-2 result से match करता है
    • knn1r == knn1d है, और k=1 में tie नहीं होता
    • knn2d == knn1d है, और k=2 में tie को first sample से resolve करने पर यह k=1 जैसा हो जाता है
    • knn2r < knn2d है, और k=2 के 1:1 tie में random choice आधे मामलों में दूर वाला sample चुनती है

बाकी verification items

  • अधिक k values वाला नया reimplementation gzip-knn में है
  • DengueFilipino कुछ cases में 1.0 जैसा बहुत high क्यों है, इसे follow-up post Part 2 में cover किया गया है
  • table5 और code दो cases में थोड़ा अलग क्यों हैं, यह अभी verify किया जाना बाकी है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-07-18
Hacker News की राय

  • लेखकों के लिए यह निराशाजनक होगा, लेकिन मुझे यह एक शानदार खंडन लगता है
    मशीन लर्निंग में ऐसी गलतियाँ करना सचमुच बहुत आसान है, और इससे भी बुरी बात यह है कि सूक्ष्म methodology की त्रुटियाँ दूसरे engineering या science क्षेत्रों की तरह आम तौर पर किसी घातक failure के रूप में सामने नहीं आतीं, बल्कि performance में हल्के बदलाव के रूप में दिखती हैं
    अगर खराब data training set में मिल जाए या target value की जानकारी leak हो जाए, तब भी system किसी तरह चलता रहता है, और नतीजे बस थोड़ा दूषित हो जाते हैं
    मौजूदा compression algorithm को machine learning पर लागू करना, उम्मीद के उलट, कुछ ज़्यादा ही free lunch जैसा लगता है. अगर compression algorithm में कोई खास जादू होता, तो transformer को compressor की तरह इस्तेमाल करने के बजाय compression algorithm को encoder की तरह इस्तेमाल किया जाता

    • इस बात को ज़रूर याद रखना चाहिए. गलतियाँ करना आसान है इसलिए वे आम हैं, और science एक noisy process है, लेकिन उसके भीतर signal भी होता है, और अभी जो दिख रहा है वही peer review का असली स्वरूप है
      इसी वजह से मैं अक्सर कहता हूँ कि conference या journal की तुलना में public publishing, peer review का बेहतर रूप है. peer review का मतलब यह है कि peers मेरे काम की समीक्षा करें, न कि conference या journal के मनमाने और noisy standards ही उसका मूल हों
      इतिहास के ज़्यादातर हिस्से में यही तरीका था, और आधुनिक अर्थ में peer review 1970 के दशक के मध्य की काफी हाल की अवधारणा है. पुराने journal, आज के arxiv की तरह, research को वितरित करने के काम के कहीं अधिक करीब थे
      https://mitcommlab.mit.edu/broad/commkit/peer-review-a-histo...
      conference और journal को खत्म करने के पक्ष में एक और तर्क यह है कि तभी replication papers, failure papers जैसे महत्वपूर्ण काम को सक्रिय रूप से प्रोत्साहन दिया जा सकता है. “novelty” के मानदंड से बंधे रहने की ज़रूरत नहीं होगी, और सच तो यह है कि लगभग सारा research incremental होता है
      “publication” का मतलब है अपने काम को peers तक पहुँचाना, ताकि वे परिणामों की पुष्टि या खंडन कर सकें
      हाँ, conference लोगों को एक जगह लाते हैं और collaboration को बढ़ावा देते हैं, यह अच्छी बात है. यहाँ आलोचना इस बात की है कि conference या journal को research की वैधता तय करने के साधन के रूप में इस्तेमाल किया जाता है
      अगर conference system सिर्फ research और community के लिए आमंत्रण मंच हो, तो उसमें कोई समस्या नहीं. journal भी सिद्धांततः अच्छे हैं क्योंकि उनमें authors और reviewers के बीच संवाद होता है, लेकिन मेरे हिसाब से यह arxiv + github या OpenReview से भी आसानी से किया जा सकता है
    • ऐसा तरीका पहले से इस्तेमाल हो रहा है. minimum description length principle और entropy-based classifier खोजकर देखिए
      performance अच्छी नहीं है, लेकिन वे निश्चित रूप से मौजूद हैं और deploy करना भी बहुत आसान है. मिलते-जुलते text आम तौर पर बेहतर compress होते हैं, इसलिए मैंने gzip को plagiarism detection में इस्तेमाल होते देखा है
      compression ratio को spring model के weight की तरह इस्तेमाल करके visualization भी किया जा सकता है, और इसे network communication metadata पर भी लागू किया जा सकता है
    • कई experiments में यह सही बात है. मनचाहा result पाने की इच्छा, वास्तव में जो मिला है उसकी जाँच करने की ज़रूरत पर आसानी से भारी पड़ जाती है
      खासकर तब, जब result पहले से मौजूद धारणाओं की पुष्टि करता हो
    • मैं हाल में machine learning काफी पढ़ रहा हूँ और यह पैटर्न अक्सर देखता हूँ. software engineer के रूप में मैंने जो लगभग हर चीज की है, उससे यह बिल्कुल उलटा लगता है
      एक semicolon छूट जाए तो तुरंत error आ जाती है
      लेकिन अगर तीन layers में से एक layer का gradient calculation गलत हो, तब भी कभी-कभी चीज चल सकती है. बस नतीजे अजीब हो जाते हैं
    • अकादमिक research code ज़्यादातर amateur लोगों द्वारा जितनी जल्दी हो सके लिखी गई उलझी हुई codebase होती है, उसमें tests लगभग नहीं के बराबर होते हैं, और ऐसे code का मुख्य output होता है paper citations जमा करना
      अगर science papers आधे हो जाएँ और सावधानी दोगुनी हो जाए, तो दुनिया में कहीं अधिक value बनेगी, लेकिन पूरा system निराशाजनक रूप से gamified हो चुका है

  • यह blog post लिखने वाला मैं ही हूँ. यहाँ लिखी बातों को लेकर मुझे काफी भरोसा है, लेकिन अगर मुझसे कुछ छूटा है, तो शायद लेखकों को खुद आकर समझाना पड़े
    मैंने अभी GitHub पर एक issue दर्ज किया है: https://github.com/bazingagin/npc_gzip/issues/3

    • पोस्ट के सबसे ऊपर एक note जोड़ने पर विचार किया जा सकता है. बहुत से लोग शायद सिर्फ शीर्षक सरसरी तौर पर देखकर यह मान रहे हैं कि “gzip paper बेकार है और gzip approach भी खास नहीं है”, जबकि असल संदेश शायद “gzip approach deep neural network models से बेहतर नहीं है, लेकिन कुल मिलाकर प्रतिस्पर्धी है और चलाने की लागत बहुत कम है” के अधिक करीब है
      paper अपने आप में अब भी मजबूत है
    • मैं paper का first author हूँ और मैंने यह blog post पढ़ी है. k=2 चुनने की वजह यह थी कि n^{1/2} के इस्तेमाल की सिफारिश की गई थी, और मैं 5-shot setting के अनुरूप k चुनना चाहता था
      लेकिन यह कहना सही है कि यह चुनाव कुछ अजीब है. जैसा कि paper और Twitter पर कहा था, k की value बदलने पर result बदलते हैं, और हमने जो report किया वह प्राप्त किए जा सकने वाले अधिकतम result थे, इसलिए उसका मतलब एक ऐसी ideal स्थिति है जहाँ prediction हमेशा सही होती है
      W2V और SentBERT पर भी हमने वही strategy लागू की थी. लेकिन इसका मतलब यह नहीं है कि यह top-2 accuracy है. जहाँ तक मुझे पता है, top-2 accuracy का मतलब है कि predicted top 2 classes में से कोई एक सही हो तो score दिया जाए
      लेकिन जैसा आपने बताया, kNN में जब k=2 हो तो ऐसी स्थिति आ सकती है जहाँ दो सबसे नज़दीकी neighbors एक ही class की ओर इशारा करें, और ऐसे में अगर top-2 accuracy report की जाए तो दूसरी candidate class छूट जाएगी
      जब समय मिलेगा और मैं arxiv पर नया version अपलोड करूँगा, तो मैं दूसरी strategies और अलग-अलग k values के results भी जोड़ना चाहूँगा. blog में बताई गई decrement strategy वाकई अच्छी है, और अगर आप चाहें तो मैं उसे repository में जोड़ना चाहूँगा
      इस छोटे और देर से आए जवाब के लिए माफ़ी. मैं अभी तक repository देख नहीं पाया हूँ. कल paper review की तैयारी कर रहा हूँ, इसलिए उसके बाद issue पर जवाब देकर इसे सुलझाऊँगा
    • replication के लिए धन्यवाद, यह महत्वपूर्ण काम है
      मैं जानना चाहता हूँ कि क्या आपने दूसरी results table, यानी Table 3, को भी reproduce किया
      अगर मेरी समझ सही है, तो जब classes सिर्फ 2 हों तो top-2 accuracy 1 हो जाती है, लेकिन classes की संख्या बढ़ने पर औसतन “सामान्य” accuracy के साथ उसका अंतर धीरे-धीरे कम होता जाता है. इसलिए अगर dataset में classes बहुत हैं, तो Table 3 के results शायद इतने बड़े पैमाने पर नहीं बदलेंगे
      फिर भी, 20-newsgroups dataset पर top-2 accuracy 0.685, उस method के लिए काफ़ी प्रभावशाली है जो characters को characters की तरह भी नहीं देखता[1]. token, n-gram, embedding जैसे वे तमाम अच्छे tools तो अलग ही हैं, जिन पर NLP researchers ने वर्षों लगाए हैं
      [1] मेरी समझ में gzip सिर्फ bitstream को संभालता है, जो words यानी byte boundaries के साथ ज़रूरी नहीं कि aligned हों
    • क्या आपने इसे सार्वजनिक करने से पहले लेखकों से पहले संपर्क किया था?

  • Shopify में search relevance experiments करते समय मैंने भी बहुत गलतियाँ कीं, इसलिए मैं लेखकों से सहानुभूति रखता/रखती हूँ। मैंने भी सार्वजनिक रूप से शर्मिंदा करने वाली काफ़ी गलतियाँ की हैं
    Shopify में अपने आख़िरी दौर में मैंने सीखा कि अच्छे science के लिए अच्छी software engineering ज़रूरी है। क्योंकि stack के बहुत सारे बिंदुओं पर गलती होना आसान है
    इसी वजह से, numbers पर भरोसा किया जा सके और लोग एक-दूसरे के experiments को reproduce कर सकें, इसके लिए मैंने सख़्त, heavily tested, high-quality experimental software बनाने में बहुत समय लगाया
    मैंने one-off evaluation methods से बचने की कोशिश की, और जब भी कोई नया method बनाया, उसे evaluation toolkit में जोड़ने के बाद tests किए ताकि समझ सकूँ कि वह metric वास्तव में क्या बताता है
    यह बात साफ़-साफ़ obvious लगती है, लेकिन ऐसे experiments करने के मेरे अनुभव में दुर्भाग्य से यह उतना आम नहीं है जितना होना चाहिए। कंपनियाँ speed चाहती हैं, और statistical depth से सोचना या internal tools बनाना अक्सर ऊपर के management incentives के साथ मेल नहीं खाता

    • “अच्छे science के लिए अच्छी software engineering ज़रूरी है” — यह industrial research का एक सकारात्मक पक्ष है
      पहला, इसमें software engineering expertise का ज़्यादा उपयोग किया जा सकता है, और दूसरा, claims को बढ़ा-चढ़ाकर पेश करने की incentive कम होती है। क्योंकि अगर आप कहते हैं कि कुछ काम करता है, तो उम्मीद की जाती है कि उसे असली production environment में लगाया जाए

  • अच्छा लगा कि यह blog post सार्वजनिक की गई
    मैं भी ऐसे छोटे projects बहुत करता/करती हूँ, और paper की समस्या दिखाने वाला ऐसा काम भी अक्सर सामने नहीं आ पाता। आम तौर पर बस थोड़ी देर शोर होता है, फिर hard disk में दबा रह जाता है
    इसलिए इसे बाहर लाने के लिए धन्यवाद

    • आजकल मैंने Twitter को low-cost blog की तरह इस्तेमाल करना शुरू किया है
      ऐसे काम पर एक दिन लगाने के बाद आमतौर पर मुझमें पूरा blog post लिखने की ताकत नहीं बचती, इसलिए बुरा लगता है। फिर भी एक छोटा Twitter thread लिखना अक्सर संभव हो जाता है

  • यह नतीजा देखकर सच में खुशी हुई। kNN + classification task + pure text similarity आधारित classification ऐसा संयोजन है जिसमें favorable results इकट्ठे होना आसान है
    इस paper पर खुश होकर प्रतिक्रिया देना इस बात की गलतफ़हमी है कि embeddings में natural-language component क्यों मूलभूत रूप से महत्वपूर्ण है। जिन phrases में shared words होते हैं, वे classification में भी अच्छा करती हैं और GZIP में भी, इसलिए GZIP को एक वैकल्पिक classifier की तरह इस्तेमाल किया जा सकता है
    BERT या embeddings का चमत्कार इस बात में है कि shared words होना ज़रूरी नहीं है। उदाहरण के लिए, “what is my safe passcode?” का “my lockbox pin is 1234” से मज़बूत मेल है, लेकिन “my jewelry is stored safely in the safe” से नहीं
    LLM में भी यह बात महत्वपूर्ण है। बहुत लोग text similarity के लिए embeddings का इस्तेमाल करते हैं, जबकि वास्तव में उन्हें ऐसा SBERT model इस्तेमाल करना चाहिए जिसे इस तरह train किया गया हो कि question और उसके answer वाला document एक-दूसरे से correlate करें
    पूरा rabbit hole https://www.sbert.net/ पर देखा जा सकता है
    पिछली पोस्ट: Should you use OpenAI's embeddings? Probably not, and here's why. https://iamnotarobot.substack.com/p/should-you-use-openais-e...
    HN चर्चा: https://news.ycombinator.com/item?id=35377935

    • निष्पक्ष रूप से कहें तो, मूल task जानबूझकर ऐसी जगह चुना गया था जहाँ kNN+compression जैसी पद्धति के अच्छा काम करने की संभावना हो, यानी out-of-domain + low-resource environment
      ऐसी परिस्थितियों में training input इतना sparse हो सकता है कि बहुत सारे parameters वाले model के लिए अच्छे embeddings सीखना कठिन हो
      पारंपरिक in-domain large-data classification setting में compression जैसी non-parametric methods के learned representations को पछाड़ने की संभावना नहीं है

  • यह स्पष्ट नहीं था कि लेखकों ने classifier के रूप में kNN ही क्यों चुना। अगर उन्होंने distance matrix बनाई थी, तो multidimensional scaling से उस matrix को factors में बदलकर xgboost जैसे tree algorithm का इस्तेमाल किया जा सकता था, और तब kNN की तुलना में कहीं ज़्यादा information का उपयोग कर बहुत बेहतर results मिलने की अच्छी संभावना थी
    LZ परिवार के compressors की तुलना में कहीं बेहतर PAQ compression algorithm भी इस्तेमाल किया जा सकता था। संभव है कि इन विकल्पों से results काफ़ी सुधरते और वे मूल conclusion तक पहुँच जाते
    इस paper की अच्छी बात यह थी कि उसने compression algorithm को abstract किया, और इसी वजह से इसने मुझे p(x) ~ K^(-|x|) संबंध के तहत यह सोचने पर मजबूर किया कि compression से और क्या किया जा सकता है। यहाँ K alphabet size है, |x| string x की length है, और optimal coding माना गया है
    उदाहरण के लिए, यह विचार आया कि हर response के factors को अलग documents में बाँधकर, paper की तरह उस document को ढूँढा जाए जो अगले sample को सबसे अच्छी तरह compress करे, और उसी से class तय की जाए। यह compression algorithm का उपयोग करने वाला एक तरह का supervised classification है
    compressor उस dataset के optimal code के जितना करीब होगा, यह उतना बेहतर काम करेगा
    sequence prediction approach को implement करना भी उतना ही आसान है
    यह एक सुखद आश्चर्य था

  • क्या आप समझा सकते हैं कि कोई compression algorithm LLM को कैसे हरा सकता है? यह कुछ ऐसा सुनाई देता है जैसे graffiti से तुलना करके कहना कि speech बेहतर है
    लगता है जवाब कहीं न कहीं है, लेकिन मैं AI से इतना परिचित नहीं हूँ इसलिए बिल्कुल समझ नहीं आ रहा

    • सामान्य तौर पर compression = model + entropy coding होता है
      model का काम अगली आने वाली चीज़ का अनुमान लगाना है, और entropy coder का काम prediction और वास्तविक अगले value के बीच के अंतर को encode करना है, इस तरह कि जिन परिणामों की संभावना ज़्यादा हो वे जितना संभव हो उतने कम bits इस्तेमाल करें
      model जितना ज़्यादा सटीक होगा, वास्तविकता और prediction के बीच का अंतर उतना छोटा होगा, और entropy coder को उतने ही कम bits चाहिए होंगे, इसलिए compression बेहतर होगा
      साधारण compression algorithms के पास ऐसे simple models होते हैं जैसे “अगर वही byte 10 बार दिखा है, तो 11वीं बार भी वही होने की संभावना ज़्यादा है।” लेकिन LLM को भी model की तरह इस्तेमाल किया जा सकता है, क्योंकि सबसे संभावित शब्दों से text पूरा करना ही LLM का काम है
      यहाँ इसे उल्टा किया गया था। compression में model इस्तेमाल करने के बजाय, कुछ तरकीबों के साथ compression algorithm को ही model की तरह इस्तेमाल किया गया। जब compression algorithm किसी परिणाम को कम bits में encode करता है, तो उसे सबसे संभावित परिणाम माना जाता है
      मूल paper के लेखकों ने दिखाया था कि कुछ tasks में gzip से निकाला जा सकने वाला simple model कहीं अधिक जटिल LLM को हरा देता है
    • language model शब्दों के क्रम की probability P(w_1, ..., w_n), या समान रूप से P(word | context), का अनुमान लगाता है
      compression में जिन शब्द-क्रमों की probability ज़्यादा होती है उन्हें छोटे code दिए जाने चाहिए, इसलिए सीधा संबंध है। probability के आधार पर ऐसे code बनाने का एक प्रसिद्ध तरीका Huffman coding है
      यह चाहे statistical language model हो जो word frequency का उपयोग करता हो, या probability estimate के लिए LLM का उपयोग किया गया हो, बात सही रहती है। language model जितना बेहतर होगा, यानी perplexity जितनी कम होगी, compression result उतना छोटा होगा
      उल्टे, यह भी कहा जा सकता है कि compression algorithm code length के ज़रिए अप्रत्यक्ष रूप से एक language model परिभाषित करता है। उदाहरण के लिए, वह मानता है कि duplicate strings, random noise की तुलना में, अधिक संभावित हैं
    • gzip के तरीके की सहज समझ यह है
      ABC को compress करने पर वह X bytes का बनता है। उसके बाद ABCABC को compress करने पर वह 2X bytes का नहीं बनता। जोड़ी गई दो strings जितनी ज़्यादा मिलती-जुलती होंगी, उतने कम bytes चाहिए होंगे
      ABCABD, ABCABC से बड़ा होगा, लेकिन ABCXYZ से छोटा होगा
      हमें यह भी पता है कि आज के मानकों से BERT बहुत छोटा LLM है, और उसकी performance उन अरबों parameters वाले models से कमज़ोर है जिन्हें हम आजकल अक्सर देखते हैं
    • compression, intelligence के बराबर है
      https://mattmahoney.net/dc/rationale.html
    • यह बहुत सीमित task है। एक document लिया जाता है और उसे, मान लीजिए, लगभग 10 categories में से किसी एक में classify किया जाता है
      कुछ मामलों में किसी खास शब्द को detect करने जैसा तरीका भी काफ़ी अच्छा काम कर सकता है। जिन चीज़ों को अच्छी तरह compress किया जा सकता है, उनमें common substrings अक्सर दिखाई देते हैं

  • अगर यह सच है, तो मैं देखना चाहूँगा कि उस paper के बारे में बढ़ा-चढ़ाकर बोलने वाले लोग अब चुपचाप अपने निशान कैसे मिटाते हैं
    मेरी नज़र खास तौर पर LinkedIn और Twitter influencers पर है
    अगर यह सच नहीं हुआ तो मैं मूर्ख लगूँगा, लेकिन मैंने article बस ऊपर-ऊपर से ही देखा है

  • classifier के रूप में Gzip हैरान कर देने जितना अच्छा है, और इसे neural networks के लिए baseline की तरह इस्तेमाल किया जाना चाहिए

  • वैसे, लगता है कि blog 2022 में ही रुक गया है
    post की तारीख 17 जुलाई 2022 दिख रही है

    • धन्यवाद। यह जल्द ठीक कर दिया जाएगा। तारीखें हाथ से लिखने पर ऐसा ही होता है...