News for hackers. Stuff that matters.
Re:Bad numbers in the “gzip beats BERT” paper? by AbrahamParangi on Monday July 17, 2023 @10:30AM (#36758678)
Probably disappointing to the authors but an excellent rebuttal.

This is the sort of mistake that's awfully easy to make in ML. The unfortunate thing about the field is that subtle methodological errors often cause subtle failures rather than catastrophic failures as we're used to in many other branches of engineering or science. You can easily make a system slightly worse or slightly better by contaminating your training set with bad data or accidentally leaking some information about your target and the ML system will take it in stride (but with slightly contaminated results).

This result makes sense to me because as much as I would like it to be true, applying existing compression algorithms to ML feels like too much of a "free lunch". If there was any special magic happening in compression algorithms we'd use compression algorithms as encoders instead of using transformers as compressors.

Re:Bad numbers in the “gzip beats BERT” paper? by iamflimflam1 on Monday July 17, 2023 @11:13AM (#36759244)
It's true in many experiments. The desire to get the result you want can often overwhelm the need to validate what you are getting.

Especially true when the results confirm any pre-existing thinking you may have.

Re:Bad numbers in the “gzip beats BERT” paper? by mattsan on Monday July 17, 2023 @12:19PM (#36760088)
Yep, confirmation bias. Luckily helped with peer review!
Re:Bad numbers in the “gzip beats BERT” paper? by catgary on Monday July 17, 2023 @12:44PM (#36760505)
Hasn’t this paper made it through peer review?
Re:Bad numbers in the “gzip beats BERT” paper? by thomasahle on Monday July 17, 2023 @12:52PM (#36760623)
Yeah it was published at ACL ( https://aclanthology.org/2023.findings-acl.426/ ) which is one of the most prestigious conferences in NLP. So kinda disappointing.

But paper reviewers are usually not supposed to look at the actual source code of the papers, and definitely don't try to reproduce the results. They just read the paper itself, which of course doesn't talk about the error.

Not sure what the best solution is, other than having the most "hyped" papers double verified by researchers on Twitter.

Re:Bad numbers in the “gzip beats BERT” paper? by catgary on Monday July 17, 2023 @01:30PM (#36761231)
Yeah, it’s not (entirely) the students’ faults that this slipped through peer review. I don’t envy the whiplash they’re going to experience over the next few weeks.

If I was the graduate chair of their department I might schedule a meeting with their supervisor to sort out how this happened.

Re:Bad numbers in the “gzip beats BERT” paper? by westurner on Monday July 17, 2023 @02:43PM (#36762279)
What about the difference in CPU cost, RAM cost, and GPU training hours, though? What about the comparative Big-E's of the models?

Great topic: Model minification and algorithmic omplexity

Re:Bad numbers in the “gzip beats BERT” paper? by thomasahle on Monday July 17, 2023 @09:31PM (#36766633)
These are good research topics, but then you really need to be comparing to other models in the same class.

The only other super cheap model they compare with is FastText, and FastText beat them quite substantially.

Re:Bad numbers in the “gzip beats BERT” paper? by westurner on Wednesday July 19, 2023 @01:36PM (#36790189)
Gzip fails at audio and video compression IIRC?

Are time-domain signals better compressed with A/V codecs (compression-decompression); and does this gzip finding suggest that other compression algorithms likely to outperform LLMs at certain tasks like computational complexity, at least?

Re:Bad numbers in the “gzip beats BERT” paper? by godelski on Monday July 17, 2023 @02:55PM (#36762435)
> paper reviewers are usually not supposed to look at the actual source code of the papers

Wait what? I haven't reviewed for ACL but most conferences don't say "don't look at the source code." They will say that reviewers are not required to look at it (as well as the appendix). But generally it just isn't uploaded. I do always look at the main method when it is there but talking to my peers and advisor, this is very uncommon[0]. My experience is that most reviewers do not spend more than an hour on a work and make an opinion within 15 minutes.

> Not sure what the best solution is, other than having the most "hyped" papers double verified by researchers on Twitter.

I'd say (as a start):

1) Get rid of the conference system. A zero-shot (maybe 1-shot if "rebuttal" is allowed) zero-sum system is just disastrous, especially at scale. There's high incentives to actually reject works you review for. A conference system has a binary outcome and the purpose is to reject 80% of papers based on a rather noisy metric of "top tier." A journal system is a back and forth where reviewers are trying to improve the paper. The purpose of the reviewers here is to determine if the idea is indeed good, and then if the paper meets the requirements or not and must explicitly state what needs to be changed for acceptance.

1.5) An actual rebuttal system could help alleviate some of these issues. Using OpenReview for a conversation between authors and reviewers is critical. A singular 1 page response (the norm) is not adequate to respond to 4 different people who often have low similarities in responses. Reviewers are allowed (though breaks guidelines) to respond in one sentence.

2) ACs need to do a better job at validating reviewers. The number of inane and absolutely unacceptable level of reviews I have gotten is astounding (>25%). I've also seen reviewers often break guidelines and have nothing happen. Examples are comments such as those claiming lack of novelty with no explanation or asking authors to compare to concurrent works (I've had this happen for a work that was put out _after_ submission deadlines. Not mine, but here's an example[1] of this being done publicly). If the reviewer is pushed to update their comment then the authors have no ability to respond to their update without the conversation aspect. If there is high variance in response -- not just scores, but what the critiques are about -- then the ACs need to look closer as something is going wrong. We're in a crisis for reviewers but we also have an undisclosed crisis in quality of reviewers. Benchmarkism is on the rise but benchmarks are extremely limiting for evaluation. There's a certain irony given our frequent discussion of Goodhart's Law or Reward Hacking. I'll even make the claim that the quality crisis influences the quantity crisis as I have seen many peers stop reviewing because it isn't worth their time and they aren't getting a fair shot in return. On a personal note, there is a journal I will no longer review for because in-actionable and unreasonable responses, but I also won't submit to them either.

3) Either get rid of double-blind, or actually do it. Everything is published on arxiv these days, which in general is great for the community as it allows things to move fast. But with this it is incredibly easy to de-anonymize authors. Though for big labs, they de-anonymize themselves actively[2]. In a very noisy process even a very slight edge becomes a significant edge[3]. These biases can even come unconsciously given that we're all reading arxiv papers constantly and it isn't unlikely that we come across some of the works we end up reviewing (yet to knowingly happen to me fwiw). But certain labs do have keywords that they use that can be identified.

I think one of the major problems comes down to this: in a small community we have a certain level of accountability, as we all end up knowing one another through minimal connections. But in a large community there is little to no accountability and what depends on good faith can no longer be trusted. This encourages bad actors, especially when the system is highly competitive (see 1)), and creates bad science/evaluation creep. (e.g. now standard to tune HPs on test data results -- this is information leakage. If you don't, you likely can't compete).

======

[0] Here's a prominent researcher explicitly saying they don't read the appendix, calling it trash, and a poll showing most people don't look at it https://twitter.com/david_picard/status/1660293648796340226

[1] Here's a prominent researcher criticizing a paper for "not citing his work". I linked the top response which is telling him the submission date was 2 months prior to his arxiv release. This is someone who published >250 papers vs someone with <50. For added reference, paper 2 (prominent researcher) was _published_ June 26th in TMLR, but they did cite the other work (gotta give credit for that) https://twitter.com/RinonGal/status/1667943354670170118

[2] We have 2 scenarios here: either reviewers do not know Chinchila == DeepMind, where I'd argue that they are unfit for reviewing given the prominence of that model or 2) they do know, and thus know this is a DeepMind work, and we have an ethics problem. Neither sound great. https://openreview.net/forum?id=OpzV3lp3IMC&noteId=HXmrWV3ln...

[3] The conclusion in this analysis of consistency experiment is that even a small amount of inconsistency leads to a lot of noise given a highly selective standard. Which means that paper acceptance itself is highly stochastic: (2014 experiment) https://inverseprobability.com/talks/notes/the-neurips-exper...

[3.1] A shorter version: https://blog.mrtz.org/2014/12/15/the-nips-experiment.html

[3.2] A follow-up on the 2014 experiment tdlr: reviewers are good at identifying bad papers, but not good at identifying good papers (i.e. bias to reject): https://arxiv.org/abs/2109.09774

[3.3] A follow-up 2021 experiment (consistent with 2014 experiment): https://blog.neurips.cc/2021/12/08/the-neurips-2021-consiste...

[3.4] Video form https://www.youtube.com/watch?v=19Q-vMd9bYg

Re:Bad numbers in the “gzip beats BERT” paper? by YeGoblynQueenne on Monday July 17, 2023 @04:59PM (#36763991)
I try not to submit to conferences if I can avoid it. It's like you say, reviewers are looking for a reason to reject. I don't understand what makes the difference since it's usually the same people reviewing in both conferences and journals, but somehow journal reviewers do a much better job. Some journals have a fast turnaround even, and still the quality of reviewing is considerably better.

My second journal paper got rejected with encouragement to resubmit. Half the reason for that was because the reviewer had, I think, genuinely misunderstood the description of an experiment, so I re-wrote it in painstaking detail. I had a long section where I hammered out a proof of complexity spanning three pages, with four lemmas and a theorem, and the reviewer waded through all that like a hero, and caught errors and made recommendations for improvement. They made a new round of recommendations when I resubmitted. That paper took three rounds of revisions to publish (reject, resubmit, accept with minor revisions) but it got 80% better every time I had to revise it. I wish there was another couple of rounds! It was exhausting, and I bet much more so to the reviewer, but it was 100% worth it.

And yeah, I absolutely do my best to review like that myself. Even in conferences, which probably seems really weird to authors. But, hey, be the change you want to see.

Re:Bad numbers in the “gzip beats BERT” paper? by godelski on Monday July 17, 2023 @05:38PM (#36764450)
Yeah, honestly the only reason I submit to conferences now is because my advisor asks me to. If it was up to me I would submit exclusively to journals or just to arxiv/open review directly. I think I'll do this when I graduate (soon).

As for the reason why it happens in conferences, I think it may actually be a different set of reviewers. While journal reviewers are going to be conference reviewers, I don't think the other way around is true. I think conferences tend to just have a larger number of shitty reviewers (as well as more shitty submissions). And as you note, it is quite easy to misunderstand a work, doubly so when you're reading under a time constraint. It just makes for a noisy process, especially when reviewers view their job as to reject (not improve). I just think it is a bad system with a bad premise that can't really be fixed. For conference reviewing, I always try to write what would change my mind and if I think the authors should resubmit to another venue. But even reviewing I don't feel authors get a fair shot at responding. They can't address all my comments while addressing others in a single page.

Re:Bad numbers in the “gzip beats BERT” paper? by thomasahle on Monday July 17, 2023 @09:37PM (#36766668)
>> paper reviewers are usually not supposed to look at the actual source code of the papers

> Wait what? I haven't reviewed for ACL but most conferences don't say "don't look at the source code." They will say that reviewers are not required to look at it (as well as the appendix). But generally it just isn't uploaded.

Sorry, I formulated that badly. I meant what you say, that are usually not presented with the source code, and aren't expected to go hunting for it online. If they do anyway, they are going above and beyond.

Re:Bad numbers in the “gzip beats BERT” paper? by godelski on Tuesday July 18, 2023 @12:27AM (#36767808)
If they do go hunting for it, then that would be a ethics violation as they break double blind. But it's not like that exists, at least for big labs.
Re:Bad numbers in the “gzip beats BERT” paper? by CJefferson on Monday July 17, 2023 @09:45PM (#36766718)
In terms of “getting rid of the conference system”, I would suggest what I see in maths, which is split into two types of talks:

* talks about already peer reviewers conference papers.

* talks about active research. Here you only submit an extended abstract, and you don’t get to “claim credit” for giving the talk. People tend to only talk about things where they genuinely want to hear feedback, maybe even new collaborators.

Re:Bad numbers in the “gzip beats BERT” paper? by Der_Einzige on Monday July 17, 2023 @08:51PM (#36766327)
To be clear, ACL is the top conference in NlP
Re:Bad numbers in the “gzip beats BERT” paper? by scrum-treats on Monday July 17, 2023 @11:21PM (#36767421)
It's customary to use OSF (https://osf.io/) on papers this "groundbreaking," as it encourages scientists to validate and replicate the work.

It's also weird that at this stage there are not validation checks in place, exactly like those the author performed. There was so much talk of needing this post-"replication crisis."

Re:Bad numbers in the “gzip beats BERT” paper? by thomasahle on Tuesday July 18, 2023 @02:55AM (#36768793)
I don't think it's "customary" to use OSF in machine learning. At least I had never heard of it. It looks great though, I'm glad other fields are figuring this out. Hopefully it will be taken up by the ML field too.
Re:Bad numbers in the “gzip beats BERT” paper? by scrum-treats on Tuesday July 18, 2023 @11:49AM (#36774414)
Really? Perhaps it was just my department (interdisciplinary). We were strongly encouraged to put our work up for review via OSF, including ML. This promotes transparency, collaboration, and verifiable replication.

Why? You can't trust "peer review" from a journal or a conference alone for the verified stamp of "correctness." Why? Bias and ego; humans are human. So, open it up to the hive, encourage people to swarm.

Re:Bad numbers in the “gzip beats BERT” paper? by Karellen on Monday July 17, 2023 @01:07PM (#36760870)
I suspect GP commenter meant "replication study" rather than "peer review".

;-)

(Peer review doesn't check if your data is correct. They check your data collection methods make sense given the hypothesis you're testing, and that your conclusions are supported by the data you collected.)

Re:Bad numbers in the “gzip beats BERT” paper? by mananaysiempre on Monday July 17, 2023 @02:22PM (#36761992)
One particular example that I remember from an introductory particle physics class is the History Plots section[1] of the biennial particle physics review.

Knowing these quantities is important, but their particular values largely aren’t; nobody’s funding or career really depended on them being equal to one thing or another. Yet look at all the jumps, where the measurements after the initial very rough ones got stuck in the completely wrong place until the jump to the right value—when it happened—was of a completely implausible magnitude, like four, six, or ten sigma.

[1] https://pdg.lbl.gov/2023/reviews/rpp2022-rev-history-plots.p...

Re:Bad numbers in the “gzip beats BERT” paper? by godelski on Monday July 17, 2023 @03:31PM (#36762858)
What's also good to see here is that the post '90 numbers usually don't even fall within the error bars of the pre '90 numbers. While uncertainty is great, it isn't the end all. I think a lot of people forget how difficult evaluation actually is. Usually we just look at one or two metrics and judge based on that, but such an evaluation is incredibly naive. Metrics and measures are only guides, they do not provide certainty nor targets.
Re:Bad numbers in the “gzip beats BERT” paper? by BSEdlMMldESB on Monday July 17, 2023 @01:21PM (#36761070)
now shift fields such that the subtle methodological errors don't come to light in 20 years.

which field are you on now? economics!? haahha

Re:Bad numbers in the “gzip beats BERT” paper? by godelski on Monday July 17, 2023 @03:04PM (#36762539)
> This is the sort of mistake that's awfully easy to make in ML.

It is important to remember this! Mistakes are common because they are easy to make. Science is a noisy process, but there is signal there and what we see here is exactly what peer review is about. I tend to argue that open publications are a better form of peer review than conferences/journals because of exactly this. Peer review is about your peers reviewing your work, less about whatever random and noisy standard a conference/journal puts forward. Remember that this was the way things happened for most of our history and that our modern notion of peer review is very recent (mid 70's). Older journals were more about accomplishing the mission that arxiv accomplishes today: disseminating works.

https://mitcommlab.mit.edu/broad/commkit/peer-review-a-histo...

[side note] another reason I'd advocate for the abolishment of conferences/journals is that through this we can actively advocate for reproduction papers, failure papers, and many other important aspects since we would not be held to the "novelty" criteria (almost everything is incremental). "Publishing" is about communicating your work to your peers and having them validate or invalidate your results.

[edit] I think conferences are good in the fact that they bring people together and that encourages collaboration. That's great. But I should clarify that I'm specifically talking about using these platforms as a means to judge the validity of works. If a conference system wants to just invite works and the community, then I'm totally cool with that. I do also like journals in theory given that there's a conversation happening between authors and reviewers, but I believe this also could just easily be accomplished through arxiv + github or OpenReview (preferred).

Re:Bad numbers in the “gzip beats BERT” paper? by jsight on Monday July 17, 2023 @03:27PM (#36762807)
> The unfortunate thing about the field is that subtle methodological errors often cause subtle failures rather than catastrophic failures as we're used to in many other branches of engineering or science.

I've been doing a lot of studying in the ML field lately, and I'm seeing this a lot. It is just another thing that feels like the polar opposite of everything else that I've done as a software engineer.

Miss a semicolon? Instant error.

Miscalculate some grads on one out of three layers? Every now and then it might even work! But the results will be weird.

Re:Bad numbers in the “gzip beats BERT” paper? by godelski on Monday July 17, 2023 @03:34PM (#36762886)
How about this one: tune your hyper-parameters based on the results on your test data.

This is prolific, even the norm, but it is a form of information leakage. You're passing information about the test dataset to the model. The solution to this is to use 3 partitions: train, validation, test. Validation is for HP tuning (you can do cross-validation btw) and test is a single shot.

Re:Bad numbers in the “gzip beats BERT” paper? by jsight on Monday July 17, 2023 @03:51PM (#36763135)
Yep, I've been guilty of that one lately. That and solving problems by simply overfitting a neural net to the data in the problem domain.

I mean, it works, but the result is less interesting than what I should have done. :)

Re:Bad numbers in the “gzip beats BERT” paper? by godelski on Monday July 17, 2023 @04:04PM (#36763289)
Definitely. Problem is that doing this helps you get published, not hurts. I think this is why there's often confusion when industry tries to use academic models, as they don't generalize well due to this overfitting. But also, evaluation is fucking hard, and there's just no way around that. Trying to make it easy (i.e. benchmarkism) just adds up creating more noise instead of the intended decrease.
Re:Bad numbers in the “gzip beats BERT” paper? by eyegor on Monday July 17, 2023 @06:09PM (#36764745)
What about: add more dropout or noise layers and train an ensemble of models. Submit the best one. Is this considered dirty?
Re:Bad numbers in the “gzip beats BERT” paper? by godelski on Wednesday July 19, 2023 @09:07PM (#36795715)
It is unclear what you are actually saying. An ensemble of models combines the prediction of multiple models, so I'm not sure how you submit "the best one." But what is standard practice is to do some hyper-parameter search and submit the best one. It is status quo that "the best one" is determined by test performance rather than validation performance (proper, no information leakage). These hyper-parameters do also include the number of dropout layers and the dropout percentage. For "noise layer" I'm also not sure what you mean. Noise injection? I don't actually see this common in practice though it definitely is a useful training technique.

But if in general, you're talking about trying multiple configurations and parameters and submitting the best one, then no that's not dirty and it is standard practice. Realistically, I'm not sure how else you could do this because that's indistinguishable from having a new architecture anyways. People should put variance on values but this can also be computationally expensive and so I definitely understand why it doesn't happen.

Re:Bad numbers in the “gzip beats BERT” paper? by Der_Einzige on Monday July 17, 2023 @08:50PM (#36766324)
They banged cross validation into our heads in school and then no one in NlP uses it and I just can’t even understand why not.
Re:Bad numbers in the “gzip beats BERT” paper? by godelski on Monday July 17, 2023 @09:21PM (#36766564)
Not only that, but I've argued with people substantially, where people claim that it isn't information leakage. The other thing I've significantly argued about is random sampling. You wonder why "random samples" in generative model papers are so good, especially compared to samples you get? Because a significant number of people believe that as long as you don't hand select individual images it is a "random sample." Like they generate a batch of samples, don't like it, so generate a new batch until they do. That's definitely not a random sample. You're just re-rolling the dice until you get a good outcome. But if you don't do this, and do an actual random sample, reviewers will criticize you on this even if your curated ones are good and all your benchmarks beat others. Ask me how I know...
Re:Bad numbers in the “gzip beats BERT” paper? by sghael on Wednesday July 19, 2023 @05:26PM (#36793668)
The convention should be to use 1337 as your seed, and disclose that in your publication.
Re:Bad numbers in the “gzip beats BERT” paper? by godelski on Wednesday July 19, 2023 @08:49PM (#36795595)
This is never going to happen given the need to SOTA chase. Need because reviewers care a lot about this (rather, they are looking for any reason to reject and lack of SOTA is a common reason). Fwiw, the checkpoints I release with my works include a substantial about of information, including the random seed and rng_state. My current project tracks a lot more. The reason I do this is both selfish as well as for promoting good science though, because it is not uncommon to forget what arguments or parameters you had in a particular run and the checkpoint serves as a great place to store that information, ensuring it is always tied to the model and can never be lost.

You could also use the deterministic mode in pytorch to create a standard. But I actually don't believe that we should do this. The solution space is quite large and it would be unsurprising that certain seeds make certain models perform really well while it causes others to fail. Ironically a standardization of seeds can increase the noise in our ability to evaluate! Instead I think we should evaluate multiple times and place some standard error (variance) on the results. This depends on the metric of course, but especially metrics that take subsets (such as FID or other sampling based measurements) should have these. Unfortunately, it is not standard to report these and doing so can also result in reviewer critique. It can also be computationally expensive (especially if we're talking about training parameters) so I wouldn't require this but it is definitely helpful. Everyone reports the best result, just like they tend to show off the best samples. I don't think there is inherently a problem showing off the best samples because in practice we would select these, but I think it is problematic that reviewers make substantial evaluations based on these as it is highly biased.

Noise is inherent to ML, and rather than getting rid of it, I'd rather we embrace it. It is good to know how stable your network is to random seeds. It is good to know how good it can get. It is good to have metrics. But all these evaluations are guides, not measures. Evaluation is fucking hard, and there's no way around this. Getting lazy in evaluation just results in reward hacking/Goodhart's Law. The irony is that the laziness is built on the over-reliance of metrics, in an attempt to create meritocratic and less subjective evaluations, but this ends up actually introducing more noise than if we had just used metrics as a guide. There is no absolute metric, all metrics have biases and limitations, and metrics are not always perfectly aligned with our goals.

We should be clear that starting seed isn't related to what I'm talking about in the previous comment. The previous comment was exclusively about sampling and not training.

Re:Bad numbers in the “gzip beats BERT” paper? by TX81Z on Monday July 17, 2023 @05:06PM (#36764075)
Academic research code is largely dogshit written as quickly as possible by amateurs, barely tested whatsoever, and the primary intended output of all such code is accumulating paper citations.

A world with half as many scientific papers and twice as much care would produce far more value but the whole enterprise is hopelessly gamified.

Re:Bad numbers in the “gzip beats BERT” paper? by achileas on Monday July 17, 2023 @07:03PM (#36765294)
Having worked in other sciences (neuroscience for me), I’m not sure what catastrophic obvious errors you’re used to seeing. The vast majority IME are like this, except with even longer feedback loops (on the order of several months).
Re:Bad numbers in the “gzip beats BERT” paper? by AbrahamParangi on Tuesday July 18, 2023 @08:39AM (#36771249)
Well, biology is probably a lot closer to ML in this way. My experience in chemistry or material science is that 99% of the time if you do anything wrong it totally doesn't work at all.

This is fairly typical in software as well.

Re:Bad numbers in the “gzip beats BERT” paper? by mindesc on Sunday July 30, 2023 @04:57AM (#36929270)
Those are used. Search for minimum description principle and entropy based classifier. The performance is poor, but it is definitely there and really easy to deploy. I have seen gzip being used for plagiarism detection as similar text tends to compress better. Use the compression ratio as weights on spring model then for visualisation. Also works with network communication metadata ...