Deep learning papers can look daunting to read, especially if you don't have a strong
theoretical background in machine or deep learning. Some paper can be so dense
with jargon, formula and magical looking results that you might feel you
are missing ten years worth of background to even start to look at the title.
In this video, I'll show you how I read most deep learning paper easily,
even for new deep learning subfield to start out, there are two ways
to read a paper depending on your goals. The first way is to kind of
understand what was done, but not in depth, usually to use the results
of the research or to understand another paper using these results.
This way of reading rely heavily on trusting that the paper is right. It's not
too difficult to do. If you read the abstract and conclusion of a paper,
you can get the gist of it. It's a bit like knowing roughly what react
is doing, but being more interested in using it than understanding how it's implementing.
Like a shadow dom the second way to read the paper is where people get
lost. The goal is to understand a research project so deeply that you
can reproduce these results. In that setup, there is little trust and you actually need
to understand the paper methods. This way of reading paper is what I'll
be covering today. Before we start, let me preface
it with a warning about deep learning research in general. It's a highly empirical
field, meaning a lot of things get discovered just because they were tried.
It also means that whenever reading a deep learning paper, you need to understand the
context in which it was written. Most of the stuff used within
can be slightly wrong, or at least the reasoning for why they worked
is wrong. Be acutely aware of that. You will see it's easier
to see it with very old deep learning paper with the knowledge that we
have currently. Okay, so the full method I use looks somewhat like this.
There's like seven steps. I involve like multiple read tree
of them, which is very normal for any research paper. Paper in general are
not linear, they are kind of a structure with like a lot of interdependency.
The first step to read a paper is to have enough contextual information
about it to be able to orient yourself properly. Going into a new field
is highly disorienting. If you don't have context,
you will get lost. Researchers with lots of experience within
the field already have the context, so this is why they can grasp a paper
easily. My favorite technique to absorb all the context before reading a
paper quickly is the following. I find like two or three blog posts summarizing
the main finding in the paper, they don't have to be well written or write.
It will just help me orient myself with the nomenclature and stuff like
that. After that I find like five or ten diverse videos on the paper.
Main findings again, you are going for a diverse set of opinions
about what is important in the paper. I will suggest here to vary the length
of so between like six to 60 minutes is good. The first material you will
ingest on the paper subject will fail disorienting. However, after a few you
will start to notice patterns that will tell you where the real focus of the
paper lies and where the strength are. This will also mean that as
you read more paper in the field, it will get easier and easier to absorb
the context faster. Now that you have the context in your head, you can open
up the paper for first casual read I first start with
a linear read from end to end where I note down on a separate sheet
every element that I don't understand. Everything I understand is all fine. Usually I
keep reading over it. I don't research things I don't understand
deeply while I'm doing my first read, I just make note of them. There are
usually five things in a paper that I take note of that make it harder
to understand. These are unknowns I need to somewhat categorize and
elucidate to make sense of the whole research. The first category
of unknowns are critical elements of the paper that aren't explained by
the others and implied to be understood. The second type are critical topics
that are explained in the paper but need some work to grasp fully. The third
type of unknown are elements that the author didnt understand fully, so they
kind of waved it away. This type of unknown is usually very hard to get
an answer for and is a core target for criticism in later years following
publication. The fourth type is surprisingly stuff that the authors
got wrong. It does happen. It doesnt mean the paper is garbage though sometimes
things work out anyway. The fifth type is element of the paper that
the reviewers wanted to be added before publication but provided no value
whatsoever to the paper. These usually sticks out of the paper.
Once you are done with noting down all of the unknowns you are ready to
start to fill some gaps. Try to categorize the stuff you didnt understand
into these five categories. Only tackle the external unknown for now,
research whatever you dont understand and make sure you come back to the
paper with a better understanding. Dont get too lost here. If its a specific method
the paper makes use of leverage. The first way of reading a paper which is
to superficially understand the intuition behind or better yet,
just read a blog that contains the technical information that you need. Now comes
the second read through. The whole purpose is to reduce
the number of internal unknown to the minimum. In that read, I like
to do the start with the abstract and the introduction to understand what is a
setup in the paper. Try to understand the paper's motivation because
it will help with understanding why the methods are the way they are. Then you
jump to the discussion and conclusions section at the end of the paper to see
the end point of this experiment. It's important that you understand deeply what the
author got out of the research. Generally, the conclusion will follow the
motivation of the start in a connected fashion. Since the paper was not written,
introduction first, and then six months after that they got to the conclusion.
It was all written together in a recursive fashion.
Finally, I take each of the figures out and I try to
understand what everything in the figure means, the axis, what the
graphs are highlighting, the units, all of this stuff.
At this point I feel a very deep connection with the whole research.
I used the introduction and the conclusions as anchor and tried to fit
in the result shown in the figures in a sort of like logical timeline.
If there is something that feels disconnected, it's a hint that there is maybe
something else that I didn't understand apart from their specific method or
result the other got. Now there are two ways to finish up the second read
through reading through the technical details slowly and making sure you understand
each step conceptually, including the formulas. Or you
open up the code base for the paper first if it's provided and start
mapping out each of the sections. I like the second way because as a
software engineer it will give you confidence that this stuff is not magic.
At the end of the day, it's code that was written up and ran to
generate whatever results. Do a good pass on the code base until you feel
kind of comfortable about where things are and that you cross reference some of
the name in the code with those in the paper. Disclaimer though research code is
usually very messy and doesn't have a standardized structure, keep that
in mind. Once done with the code, you are ready to check out the methods
result section in depth. Go slowly and carefully and
understand the methodology behind the paper step by step.
There are a few repeating elements in a deep learning experiment that are
mostly always there. Understand that structure helps a lot in knowing
how to navigate the method section. First, there is the data that is fed
to the deep learning model. The data has a specific structure that dictates the architecture
choice for the model. As you dive into a specific field, you will see
the same kind of dataset used over and over again. Then there is the architecture
of the model per se. Here is the layer used, the connection with instead
layer, and all this. There might be a lot of different sub elements in an
architecture that you don't necessarily understand at first, and it's okay after that
is the type of gradient descent optimizer and training regiment used.
There are a lot of empirical details usually hidden here, so it's
fine if the why isn't always 100% clear in the training.
Finally, there is the pipeline from the raw data to whatever result is generated.
Sometimes paper will combine multiple architecture in specific ways, like with
an ensemble method. In any given research, there are usually only a few
tweaks that understand the core. As you read more paper, you will
start to spot them easily. Break each of the steps from the method down and
try to understand the logical flow. If something feels weird or surprising,
check the code or other resources for reasons why the author did it
the way they did. Finally, go slowly through the results section and
fill in a blank in your timeline between the introduction and the conclusion with the
numerical or qualitative result. And once done, I usually like to do a
final read from start to finish and look at my note to ensure I
understand completely the flow again, if there is something that feels weird
during that read, it might be that I still dont understand something explained within
the paper, or that the author didnt explain something fully for a
literal lack of knowledge, or that the author was flat out wrong,
or that a reviewer asked to add some superfluous garbage information
which feels disjointed anyway, in all cases, after this third
read, you should understand the paper enough to take on a reproducibility
effort if needs be. I hope you enjoyed the video. Don't forget
to like if this was the case and leave a comment if you have any
question. I'm here to help. Have a great week everyone, and see you in the
next video.