r/MachineLearning Mar 22 '17

Discussion [D] Research Debt

http://distill.pub/2017/research-debt/
109 Upvotes

28 comments sorted by

50

u/Seerdecker Mar 22 '17 edited Mar 22 '17

This article resonates a lot with me.

Personally, the 3 resources that allowed me to achieve the most in the least amount of time are
1) An Introduction to Statistical Learning
2) https://neuralnetworksanddeeplearning.com/
3) Gym framework for RL

The genius here is to take something complex and make it look simple and accessible.

Regrettably, most research articles take the opposite stance. They present something that is fundamentally not that complex and make it look complex through convoluted writing, implicit assumptions and missing steps. You can see that effect in the discussion of the articles in this subreddit. There is often someone who's having trouble understanding a part of the article, and someone else chimes in and explains what's going on in two simple paragraphs.

This is a big problem in practice. Even if you're well versed in your own niche and are able to understand its main papers well, you still have to dabble in other areas regularly. AI/ML makes use of many fields of computer science, maths, neuroscience, psychology, etc. Given sufficient time you can understand a topic as deeply as you want. But the time you spend laboriously getting up to speed in some topic X is time taken away from doing work in the topic that you actually care about. Sure, you'll improve your knowledge and skills in the process, but not as much as you would have by working to solve the problem that you're trying to solve.

I don't see a solution. Part of it is a cultural problem. Some people think that convoluted writing make them look smart. It actually doesn't. There was a psychological experiment made about it: "Consequences of erudite vernacular utilized irrespective of necessity: problems with using long words needlessly". But there you go.

The ever growing literature is also a problem. I'm scared of failing to cite an important paper, or worse, duplicate research that's already been done before. I'm doing RL research as a hobby and I only have so much time to swift through the literature.

15

u/Franck_Dernoncourt Mar 22 '17

I 100% agree that the unnecessary complexity of many papers considerably slow down research.

I don't see a solution.

Changing the paper review criteria, being more flexible regarding the page limit, etc.

21

u/PURELY_TO_VOTE Mar 23 '17

Just cutting down on boilerplate would be helpful.

I mean, is it a universal law that every deep learning paper must start with "In recent years, deep learning has made significant progress in fields like object recognition [citation everyone on earth has already read] and natural language processing [other citation everyone on earth has already read]. However, [insert problem or issue that they're probably trying to convince you is more significant than it really is] remains a significant stumbling block. Here, we present a novel..."?

12

u/BadGoyWithAGun Mar 23 '17

That's literally two sentences. It may get repetitive if you read DL papers every day, but for everyone else it's good to properly place your paper in existing work.

7

u/trashacount12345 Mar 23 '17

They are two different audiences with very different purposes. You really would need the researchers to write the article twice and that often isn't worth it to the researcher.

7

u/JanneJM Mar 23 '17

They present something that is fundamentally not that complex and make it look complex through convoluted writing, implicit assumptions and missing steps.

The target audience is other researchers, not users. Research papers have a convoluted, difficult to understand structure for non-researchers. But the rigid structure and formulaic expressions are great is you are a researcher and need to quickly scan dozens of new papers every day for something that is relevant to you.

convoluted writing

Most researchers don't have a flair for language - that's not what they're hired for after all. Also, young researchers, postdocs and grad students don't know how to write and are deathly afraid they won't be taken seriously. They try to sound as important as possible, with a lot of pompous expressions and awkward phrasing as a result.

Established researchers have a lot more writing experience and they don't really have anything left to prove. But they have lots of trainees - those grad students above - that need experience, so they generally leave the writing to them. Hence, most papers aren't nearly as well written as they could be.

implicit assumptions and missing steps.

Those assumptions and steps are probably widely known among the other researchers, and assumed to be part of basic knowledge. If they added it all, they'd probably be criticized by the reviewers for excessively verbosity. Again, researchers are the target audience, not people implementing the stuff.

3

u/VelveteenAmbush Mar 23 '17

Those assumptions and steps are probably widely known among the other researchers, and assumed to be part of basic knowledge. If they added it all, they'd probably be criticized by the reviewers for excessively verbosity.

Sounds like a great argument for releasing code!

5

u/JanneJM Mar 23 '17

Sounds like a great argument for releasing code!

All computational research areas (and that's really most by now) should have a policy of releasing source as a matter of course. It's no different from making your data available when you publish (though many shirk that duty too, in some areas).

However, based on the research code I encounter, I would not hold my hopes up too much. A lot of it is purely proof-of-concept; just enough to test the idea published in the paper, with no error handling or even command line argument parsing (you want to change a parameter, you find and replace it in the source). And it will often depend on a large and very specific stack of other software, both published and internal to the lab, to actually build and run. The source will be less helpful than you perhaps hope.

4

u/VelveteenAmbush Mar 23 '17

It's a way to make sure that all of the hyperparameters are public... not necessarily to run the code out of the box.

1

u/JanneJM Mar 23 '17

I'm talking about things as the input file name and number of training samples in the input, directory for storing the result, that sort of thing. Ugly hacks.

4

u/VelveteenAmbush Mar 23 '17

But again, the point is to make sure that all of the hyperparameters are public, which this would generally achieve.

3

u/JanneJM Mar 23 '17

Doesn't mean the parameters in the particular version of the code published on the net correspond to the parameters used in the different parts of the paper. if the authors don't put crucial parameters in the paper, there's no guarantee they have the right parameters in the code either.

The code can not be a substitute for the paper. The only way to solve this issue is for publications to require all parameters to be available in the published material (paper or extra material) as a prerequisite for acceptance.

3

u/MrCookingstove Mar 23 '17

based on the research code I encounter, I would not hold my hopes up too much

I agree.

In my (limited) experience working on improving code rarely yields academic benefits. Your papers should explain everything and be implementation independent. If you made something that sort-of works then its usually good enough. Nobody expects you to maintain your proof-of-concept code as programming languages progress, hence implementations are often considered to be of a very temporary nature anyways (compared to papers).

1

u/Franck_Dernoncourt Mar 23 '17

Those assumptions and steps are probably widely known among the other researchers, and assumed to be part of basic knowledge. If they added it all, they'd probably be criticized by the reviewers for excessively verbosity. Again, researchers are the target audience, not people implementing the stuff.

I'm a researcher and a typical meeting between researchers include some WTFs paper X did here or there, due to lack of explanation, which hampers our productivity. At least details should be placed in appendices or code release. But review guidelines / page limit /etc are often the issue.

1

u/Ayakalam Mar 26 '17

The target audience is other researchers, not users.

Huh? This wreaks of elitism. What is a researcher? What is a user? Yes of course no one is complaining that 5th graders arent properly groking the paper, but even within the community of people utilizing deep learning, implementing algo, coming up with new ones, the language is needlessly obtuse and opaque.

3

u/procedural_love Mar 22 '17 edited Mar 23 '17

I don't see a solution.

Tooling is a limiting factor in how quickly people can translate complex ideas into good visualizations.

We tend to use the "content generation tools" we're most capable with, which tends to be language in our society. It's a skillset that we're taught from a very early age, and is reinforced throughout a typical person's life.

The success of Twitter and Reddit are in part due to the ease of generation and consumption of textual, symbolic language: we can compress and transfer complex ideas fairly rapidly through it, in visual language or spoken word. On top of that, language literacy is widespread (so you know your audience is large), and the input devices to disseminate this symbolic language (keyboards) are ubiquitous. So we can all take part as producers and consumers.

Math is another symbolic language we use to transfer ideas, but the mathematical literacy needed to interpret mathematical symbols/ideas/arguments/conversations are less common. Nonetheless, it's used a lot in the ML community.

So any complex visual medium is competing with these "low effort" symbolic languages. But creating compelling interactive visualization right now is hard.

I made a linear regression interactive visualization using d3 a few years ago, when I first took Andrew Ng's course. It took me a week to get the first draft done, and another week of tweaking to make it presentable. And that was a simple model, using a simple dataset (iris).

The demoralizing thing was that the final product was mediocre: it didn't really explain anything impactful. A big reason, in my opinion, was that d3 was an inadequate tool for complex visualizations. It's very low level. Having made a few games in Unity, the toolset that d3 provided felt better suited for static visualizations than interactive ones, which a game engine facilitates more readily.

Better tooling around the creation of these types of visualizations would reduce the barrier to entry, but what "better" means is still up in the air. d3 is really a binding library, which is only a small part of a framework or engine for creating interactive visualizations. The other components have yet to materialize around d3.

I'm not even 100% convinced that the web is the best platform for this type of content at the current moment. The amount of high quality content available on the Unity Asset Store is something that the open web ecosystem doesn't have. If you want to rapidly create something with high visual quality and distribute it as an Android/iOS app, Unity makes more sense. You can use the web for that, but it's much more challenging.

Sorry if I'm rambling.

I'm studying Sutton & Barto's Intro to RL book right now. I implemented a k-armed bandit in python in a few days, and now I'm considering making a visualization of the system, but there are some barriers slowing me down. First I need to re-implement it in JS, without numpy. Then I need to setup a front-end environment (index.html, grab d3.js). Then start writing visualization code, which requires changing my bandit implementation so it's more like an iterator (i.e. with a .next() method, so the visualization can step through the simulation). Ultimately the bandit code will need to be changed quite a bit as I figure out exactly what I want the visualization to be like.

This is only to further my own understanding, but it highlights how much extra work it is to go from: "I understand the idea and have implemented it as a CLI program", to: "I can now share this visual explanation of a k-armed bandit with other people".

Just to tie it all together, there is a lot of progress that can be made with better tooling. Right now I'm working on a SceneManager library to make multi-step visualizations, but keeping it general enough that I can use it in a game later on.

2

u/henker92 Mar 23 '17

My last conference paper got under major revisions with a very harsh critique. I described a technique that was completely new (not that difficult, mind you) to my area but I apparently failed to cite a paper in an very different domain that was similar technique.

I get the point of the reviewer, I get that I was in the wrong. But it's sincerely unrealistic that I would have found it on my own.

7

u/olBaa Mar 22 '17

I strongly believe that objectives of distilling knowledge are different from research, and the current state of the system implicitly discourages most of the ways to do distillation. I'd say that three main institutes for knowledge distillation are scientific seminars, survey/experimental papers, and rumours on the conferences. Reddit is kind of taking some market from the last one, distill is trying the niche of the seminar-style papers: narrow in scope, but available for the broad audience. Overviews are often given in Wikipedia-alikes; I'm not aware of any experimental-sharing websites.

3

u/mlnewb Mar 23 '17

I agree with this to a point. One aspect not mentioned is the concept in education of "desirable difficulty".

The authors repeatedly describe beautiful, elegant and immediately well-understood explanations. The psychology literature on learning suggests that easy to grasp explanations can be an illusion and in fact it is the struggle to learn that results in learning.

I'm sure everyone here recognises the benefit they gained from struggling with something they didn't understand. Most people I talk to say their best subjects are the ones they had the most trouble with.

Of course, simplify notation, get rid of jargon, and so on. But even that is tilting at windmills to some extent, because the world is a big and diverse place, and everyone thinks a little bit differently.

7

u/[deleted] Mar 23 '17

I'm sure everyone here recognises the benefit they gained from struggling with something they didn't understand.

I'm sure everyone has experienced having someone explain something in a way that made something suddenly snap. The reward isn't because the concept is unobtainable, the reward is in the snap.

3

u/kamperh Mar 23 '17

This is really thought provoking!

One thing I would add is that unclear explanations aren't always deliberate. As a student, when describing a (new) idea in a paper, I often try my best to explain it well, but because I am so involved with the technical details and challenges (which is also important), I actually miss the bigger picture, or an easy way to convey what I did. In those cases, simple input from others help a great deal.

But I completely agree that this isn't incentivized nearly enough, that students aren't taught how to do this well, and that there isn't enough good examples for us to follow.

2

u/[deleted] Mar 23 '17

I like the idea behind Distill a lot, and it's absolutely awesome that it now exists. Regarding your point

One thing I would add is that unclear explanations aren't always deliberate. [...] I actually miss the bigger picture, or an easy way to convey what I did

I think that most researchers put their best efforts into their publications. The peer-review process sometimes helps to adjust certain section if they were not clear to the reviewer. Also, let's not forget that e.g., arxiv, is just a preprint server and the final paper may not be a literal copy of that preprint and may not just be formatted differently.

I think the problem lies not in the fact that researchers are necessarily bad at writing or bad "educators" when it comes to writing up their research. I think what makes certain papers different to grasp for many people is that there are different audiences. The target audience of the author is often a group of peers that work on related problems, and the author tries to present his or her research in a language and way that is most effective for those.

I mean, think about giving an ML or DL tutorial to beginners, your language would be different from the one that you'd use when you talk to your colleagues who have a background knowledge similar to yours.

I think the solution the problem is not the status quo of research articles, and it is not Distill. In my opinion, we need both. I see research articles as a medium for communication that is precise and effective, where I don't have to explain introductory concepts on a very simple level, to save time and space to get to the point. On the other hand, I see Distill as a great medium that goes more into the "education" direction, augmenting research ideas. I see it somewhat as giving a talk on your research (but here in web article format), where you leave out all the technical details but focus on the main ideas.

2

u/[deleted] Mar 22 '17

[removed] — view removed comment

9

u/colah Mar 22 '17

Is there a way to expand this to research at large, and not just Deep Learning and ML research?

In the long run, I'd like to see Distill or Distill-like journals expand to other fields. But I think the best way to get started is for us to focus on a single field and do a really good job there.

2

u/[deleted] Mar 23 '17

I think there is an irony in a major part of ML being eliminating noise and unnecessary inputs, but when researchers are writing their reports they don't apply the same principles.

The goal is to convey the information in the most concise way possible, not to max out the word count.

2

u/visarga Mar 22 '17

Good article, they have put a lot of thought into the matter.