How to get started in research

Think of three things: finding questions worth asking, proposing explanations or solutions, and giving the resulting knowledge, methods, or products back to the community. Classes and competitions usually give you a fairly clear task. Research also asks you to decide what the question should be and what would count as a reliable answer.

You do not need to surround research with mystique. It is something you can try, then form your own opinion about.

Read, code, discuss ideas with more experienced students, follow new research, reports, and blogs, plan work, analyze results, write, and present. Sometimes an entire day goes into finding one bug. Sometimes a conversation reveals that the question itself needs to change.

The research workflow pages give concrete examples. There is ordinary life outside the work, too.

Yes. Curiosity, a problem you want to solve, graduate admission, work, or simply wanting to try can all be starting points. Your motives may change.

If your reason is further study or work, make it more specific: which programs or jobs interest you, and what do you hope to learn or do there? Research experience can show how you understand problems, run experiments, analyze results, and work with others. That can help when applying for research-related programs and roles. For development and applied work, projects and internships can also help you understand what the work requires.

If graduate admission is your immediate goal, ask what comes after it. Do you want to continue research, study more deeply, change environments, or improve your job prospects? Those aims affect your choice of field and supervisor, and what is worth trying now.

For me, the excitement of those first computer-vision demos and YOLO projects mattered. I found them fun and wanted to explore further. Later, working on LLMs and agents, encountering frontier research, meeting collaborators, and working through problems together opened up a wider world. Contributing some new knowledge or a useful method to the community is another reason I want to continue.

Research also has value in these concrete experiences: thinking a problem through, testing an idea yourself, learning to judge results, and finding people you want to work with. Through them, you learn whether you enjoy this kind of work and where you want to go next.

Interest can grow through trying things. Start with something that makes you curious, and notice what keeps you engaged. If seeing others join labs mainly makes you anxious, find out what they actually do each day before deciding how much time to invest. Having your own reasons makes it easier to stay interested.

Building foundations, surveying a field, choosing an idea, making solid progress, and organizing the writing and presentation all involve friction. You need to go through that process yourself to understand it.

Even with AI, research may be harder than you expect. Can you provide valuable human intervention and guidance? Can you use an agent to accelerate the work? Can you actually give the community new knowledge and insight? None of this is as simple as imagining it.

Yes. Reproducing small computer-vision demos and trying YOLO excited me. I later moved into LLMs and agents, but those early projects already told me that I enjoyed exploring these things.

Something you had only seen in a video becomes something you can run and modify yourself. That gives you a way to explore further. Notice whether you most enjoy building the application, or whether you keep asking why the model works, why it sometimes fails, and what experiment would help you understand it.

Try a small MNIST or YOLO project, then take your results and questions to someone you can talk to. The experience of making it work can help you decide what to explore next.

One gift of the AI era is that you can work from the top down. You do not have to finish mathematics, programming, LaTeX, machine learning, and deep learning, wait until your third year for an undergraduate project, and only explore research directions in graduate school.

There is no fixed template and no one needs to grant you permission to begin. If you want to do it, have strong motivation, and are willing to build the necessary foundations carefully as questions arise, you can start.

Starting early gives you more time to try and adjust, and possibly to accomplish more while young. Keep a sense of proportion: do not sell yourself as a rising star because of your age or become smug about a head start. Starting later does not mean falling behind. Research and learning at the frontier can last a lifetime; an individual success or failure is not the whole story.

If you need a starting point, try a small project.

Start with a question you can reach now. English, mathematics, and programming can improve through work. When a gap actually blocks progress, address it seriously.

Your institution and resources affect opportunities. Look for openings through local faculty, senior students, open-source projects, and public discussions. Use your current situation to decide your next move, rather than to declare yourself eligible or ineligible.

Learning is valuable because it helps you work and understand what you are doing. You do not have to finish all those subjects before contacting someone.

If your foundations are incomplete but you have seriously explored an area, know what people are doing, and have thought through how you will learn what is missing, reach out. Returning to study with a concrete question often deepens understanding.

A specific question needs less preparation than asking to join a project. For a project, explain your understanding, previous attempts, and practical skills. Help the other person see where you could begin and what guidance you need.

Contact senior students or instructors around you. You can also use AI to reproduce a paper or build a small demo. Choose a concrete question, read the relevant work properly, understand what has been done and what remains, and place your own attempt in that context.

Leave something others can inspect: a blog post, runnable code, or an analysis of a problem. It helps people find you and see that you are taking the work seriously. See contact and collaboration.

Choose a small project with visible results: image classification, a simple tool-using agent, or inspecting a robot demonstration dataset. Keep the code, results, and your own questions, then discuss them with someone.

Pick an entry from the hands-on routes.

Xiaohongshu, Zhihu, Bilibili, AI news outlets such as Xinzhiyuan, and GitHub awesome lists can all be entry points. Follow nearby AI discussions and frontier work. Use AI to explain unfamiliar concepts and help locate material.

When a demo or introduction interests you, follow it to the original paper, code, and authors. The directions overview connects the names; Lookout discusses keeping up.

Start with what a system is trying to accomplish. How would it enter everyday life? What does it do poorly? If it is not deployed yet, what is blocking it?

Then return to the paper: what problem does it identify, why does it arise, how does the method address it, and what happened? Let each paper add something concrete to your understanding.

Try doing some of the work. Understand how the demo was made, what was difficult, and whether any part makes you want to investigate further.

If it only works under narrow conditions, let it be a demo. Discovering that is also a way to understand the real problem.

In the AI era, I would put freedom to develop first. Interest sustains enthusiasm, good supervisors and collaborators make work enjoyable, and resources reduce the friction of turning ideas into experiments.

Difficulty may mean a high barrier to entry. A hot topic may be solved quickly or lose its hype. You cannot predict the future perfectly, so retain room to adjust and the ability to keep learning.

You are unlikely to get every condition right immediately. Look at the questions, support, and collaborations available now. Many interests only appear after you get involved.

A wider view helps you understand a field: its beliefs and schools of thought, current topics, bottlenecks, gaps, and what you might contribute. Staying open makes it harder to get trapped inside a small circle's information.

Papers, projects, and talks help build a network of connections between ideas. Notice how approaches evolve, where turning points occur, how a need is addressed, and which questions remain. Find starting points in Lookout.

Yes. First know why you want to contact them and learn a little about their work. Check whether someone you both know can introduce you. Communities, Xiaohongshu, and cold email are all possible routes.

Do not meet people merely to collect contacts. A conversation that resonates, mutual friends, and shared research questions are valuable. Put what you want to discuss and do first, instead of making networking the entire project.

Try social media, research groups, university and lab websites, and authors of papers you enjoy. Personal pages usually list email addresses. Following those pages and Google Scholar profiles also introduces you to collaborators and the wider community.

Undergraduates or junior researchers among the authors and lab members can be a clue. Look for student projects and open calls, or ask directly whether they mentor undergraduates.

Among the senior students I have met, polite and sincere questions often receive help. Whether someone has time to supervise a project or a suitable task is something to discuss specifically.

We often begin with a conversation about each other's plans, availability, and interests. You might ask about a point in a paper or whether there are tasks suitable for undergraduates.

If joining the lab is your aim, say so. Explain your interests, available time, and current abilities so the other person knows what the conversation needs to cover.

Say who you are, why you are writing, what research interests you, and what question or task you hope to work on. Attach a CV if you have one; do not invent filler.

Basic practical ability and a clear account of what you have tried are valuable. In our experience, first conversations with senior students are usually ordinary conversations. Interviews or trial tasks can be discussed later.

“I read your work on X, became interested in this question, tried Y, and would like to ask whether there is a task I could join” is already a clear purpose. See the short email example.

There may be no reply or a polite decline. There may also be a normal reply and a move to WeChat. In collaborations I have encountered, first conversations are often less frightening than expected, and not necessarily difficult examinations. Often the questions are: how would we guide you, how could you help us, and what do you hope to gain?

Some labs ask you to read, try a task, or attend a formal interview. Follow their process. If there is no reply, send one polite follow-up after a reasonable interval. If declined, learn what you can from the feedback and try other suitable people. One response is not a complete assessment of your ability.

Prepare a brief introduction, one or two things you have made or read, and your questions. The conversation may explore your understanding of the field and how you work; some include foundational questions.

Often both sides are establishing how they could work together: what guidance you need, what you can contribute, and what you want. Discuss the task, supervision, and time commitments clearly.

Be honest about what you do not know. If you know how to investigate it or plan to learn it, explain that too.

Ask whether they want understanding, a presentation, or a reproduction, and when you will discuss it again.

On a first pass, explain the problem, method, evidence, and what you did not understand. Then consider its place in the field, your understanding of the method, possible analyses or improvements, and what later work did.

You can also ask whether another field contains a similar insight and how the problems connect. Those connections are part of what reading gives you. See reading papers.

Ask about observing meetings, a short trial, or a bounded task. Clarify the work, feedback, time, resources, and expected contribution, then judge the fit.

Discuss formal membership, use of results, and authorship when collaboration starts. That is easier than doing it just before submission.

Ask directly: whom will I discuss daily work with, how often will we meet, whom should I ask when stuck, how do data and compute access work, and how much time does this task require?

Some labs rely mainly on doctoral or master's students for supervision; in others faculty are more involved. Confirm the actual arrangement and explain your coursework and schedule.

Consider whether you receive necessary feedback, whether expectations are reasonable, and whether you are learning. If something is wrong, first talk to the student directly supervising you and see what can change.

In practice, some informal collaborations also fade by mutual, unspoken understanding: contact and tasks become less frequent, and both sides know the work is not progressing. You can explore other opportunities and, once you know what you want and the timing is right, discuss next steps with your direct mentor. It does not have to become a confrontation.

If others are waiting for your work, explain the progress, code, and handover clearly. Do not leave them waiting indefinitely. Leaving a project need not end the relationship; future conversation and collaboration may still be possible.

Linear algebra, probability, information theory, and infrastructure are worth building over time. They deepen your understanding of principles, theory, and implementation and inform your own work. Calculus, optimization, programming, and computer fundamentals recur too.

Pretraining hyperparameters, post-training data mixtures, RL scaling, computer vision, and DDPM all have deeper questions behind them. Policy gradients involve probability and expectations; CNNs and Transformers involve linear algebra, tensors, and optimization; training and deploying models requires infrastructure.

You need not recognize every name now. When a concrete question arises, use the foundations page and gradually connect the ideas to your work.

Let projects give you questions, and courses and books connect the answers into a larger picture. Record where you got stuck, how you resolved it, and what made you curious.

If you have been preparing for a long time, pick a sufficiently small example today. Once you start, the reason to watch the next lecture often becomes clearer.

Ask whether the gap prevents you from understanding the current step or judging the result. If it does, stop and study. If it only blocks a deeper derivation, note it and walk through the overall process first.

When you return, test your understanding against the task. Do not let “learn later” remain forever in a notebook.

Compared with the pre-AI era, our greatest advantage and disadvantage are the same: learning has become very cheap. An agent can be both teacher and executor, patiently explaining and carrying out what you ask.

Why watch forty hours of lectures or struggle with documentation when AI can explain difficult theory and code smoothly? Let it run a demo, watch the loss fall, get digit recognition working, and everybody is happy. This is a comfortable prison: it is easy to feel that you have learned and mastered something before you have understood its depth.

Learning must not lose information. This does not mean morally condemning yourself as unfit for research because you cannot implement everything from memory or answer every interview drill. Those performances can be overfit too. Think, ask, discuss, dig deeper, and express your own ideas.

Take TRPO, PPO, and GRPO. AI can reduce them to smooth summaries: “TRPO uses a KL constraint; PPO uses clipping; GRPO compares a group of samples without a separate critic.” Hearing that is very different from asking why. Dig deeper and you meet sₜ and sₜ₊₁, policy sampling, how the objective J and advantage A are estimated, and how the constraint acts. You also start asking about stability and scaling.

Reproducing the method—seeing how it works and how it breaks—gives you observations of your own. Attention is similar. After an AI explanation and the paper, derive the mathematics, inspect the architecture, and read the implementation. Hyperparameters, initialization, and architectural choices contain much more theory and detail.

When you can explain a real run, predict the effect of a change, and revise your judgment from the result, you are learning more deeply. That experience changes how you approach the next problem.

Many mechanical skills may no longer require dedicated practice. But you need more than research taste: mentoring, organizing, expressing ideas, and how you think and judge all matter. Mathematics, models, computing, and experimental methods affect what you can understand and notice.

I need to speak up and explain things more, too—to give people more signals of who I am, rather than becoming someone who could simply be generated. What you have done, how you judge, whether you can explain the work, and how you collaborate help others get to know you.

Ask AI more and talk with it more; also ask humans more and talk with them more. Delegating execution does not automatically give you experience or understanding. When someone asks for your judgment or a detail, you cannot always stop to ask AI before continuing the conversation. Being solid and dependable is fundamental.

It depends on what you want from this reading. Do you want a quick overview of a field, or to understand what a paper looks like? Classics introduce important work and how research is presented. Surveys can orient you; let AI help trace the connections, then return to the originals. With an existing task, start with the most relevant or assigned work.

For agents, one route runs from the capabilities of LLMs through chain-of-thought and prompt engineering to ReAct by Shunyu Yao and colleagues: how do reasoning, action, tools, and environmental feedback combine? Then explore multi-agent systems, multimodal agents, agent RL, how harnesses and skills organize execution, and how loops and self-evolution use feedback. If recursive self-improvement interests you, investigate what improvement each work actually means.

These routes intersect; they are not successive generations replacing one another. Connect the problems, reasons for the methods, and relationships to earlier work. That is how an overview develops. Continue with paper entry points and the agents page.

For choosing reading depth, see how deeply to read a paper.

See Mu Li's paper readings. Begin with the abstract, introduction, key figures, and conclusion. Establish what was done, why, and how, then check how the experiments support it.

This also introduces the task, data, baselines, and metrics.

For locating evidence, see matching claims to figures.

First make the main sentences and concepts understandable. Ask AI about terminology while checking the original. Look for author talks, videos, and other readers' notes.

Read equations in layers: what do the quantities represent, and what does the step accomplish? Then inspect the derivation. If an equation is central to what you want to reproduce or change, work through it carefully.

Explaining the question, method, and main evidence is already a useful first reading. Reproduction or improvement requires deeper work on data, implementation, derivations, and evaluation.

Your purpose determines the depth of this pass. Keep important questions to verify later.

To practice explaining a method, try having AI question you.

Feishu, Notion, Zotero, and Obsidian can all work. Pick a comfortable tool and record your own questions and connections.

Organize papers around a shared question: what changed, how comparison conditions differ, and how one conclusion affects another. A few sentences of your own understanding are more useful than merely saving abstracts.

In Building your research workflow, irene shares how she uses Zotero and Obsidian, then compares and questions the notes with AI.

You do not need an elegant independent idea before participating. An existing project teaches how work progresses, experiments are checked, papers are organized, and people collaborate.

Notice what makes you curious while reading, using systems, and talking. Ideas often grow there.

A direction is a broad area, such as agents, embodied AI, or world models.

A research question is a specific uncertainty within it: why do agents fail on long tasks? An idea is your proposed explanation or solution. A method turns that idea into something you can run and examine.

Clarifying the question gives the modules and experiments a shared purpose.

Experience and familiarity with the field matter. Read the same paper with someone more experienced and compare what you noticed.

Investigate or run something that makes you curious. Asking one concrete question and checking it is an easier beginning than forcing yourself to critique the whole paper immediately.

Survey related work. Compare settings, motivations, and methodological details; keyword overlap alone cannot establish duplication.

You are part of the community. Your curiosity is a reason to explore. If the work also produces more general knowledge that helps others understand the problem, it is more valuable still.

Feasibility depends on motivation and resources: what data, tools, compute, time, and collaboration would verification require? A small experiment can help establish the conditions.

For searching from a specific question, see irene's targeted search process.

For well-known dead ends, first understand why others struggled. You do not have to force your way through them. If your attempt fails, distinguish an implementation problem from an ineffective idea under the current conditions, then investigate why.

Failure is information. If further analysis also fails to produce the expected result, that remains an observation under those conditions. Keep the setup, process, and findings; they may themselves be useful discoveries.

Stopping an attempt does not erase what you learned. You can narrow the question, try another explanation, or spend your effort elsewhere.

Work backward from the question: what do you want to establish, what evidence would support it, which experiments provide that evidence, and which data and baselines are missing?

An early stage often means reading the closest papers, running a reference method, understanding evaluation, and choosing one small question to test. Write daily tasks concretely enough to act on.

You need a reference against which your change can matter. Reproduction also makes data, metrics, and implementation details concrete.

Compare your setup and results with the paper. Check splits, evaluation, randomness, and leakage. Inspect actual outputs; a single aggregate score can hide errors.

Write the question, expected results, and how different outcomes would change your understanding. Check the process on a small scale before investing in a larger run.

To study one factor, control the others as far as possible. To study interactions, design combinations around that purpose. Keep each change traceable.

First inspect implementation, data splits, and evaluation. Then check fairness, including resources, configuration, and tuning effort.

Run more than once and report variation. If the gain is smaller than ordinary variation, the evidence may not support either a confident positive or negative conclusion. Use suitable ablations and sample analysis to test your explanation.

Narrow the problem. Check data, implementation, environment, and evaluation step by step. Organize what you tried and ask a senior student or the original authors.

Some work really is difficult to reproduce. Record conditions and discrepancies, then decide whether to investigate further or change reference methods. Remember to leave enough reproduction detail in your own work later.

If you have tried for half a day or a day and have no new approach, ask. First search, ask AI, read the error and documentation, and organize the attempts and observations.

A senior student might explain in one sentence what would take you a week. The project may also be waiting during that week, which creates more trouble for others. The time is a reference, not a rule requiring you to wait. Problems affecting collaborators or consuming major resources deserve earlier communication.

Cover four things: what you want to do, what you tried, what happened, and where you suspect the problem is. Include necessary environment details, key logs, or results.

Reduce it to something another person can understand without reconstructing everything. See the examples in contact and collaboration.

Explain what you did, what you learned, and what you plan next. Without a positive result, you can still report possibilities ruled out, the current obstacle, and help you need.

Bring one or two key results and the underlying records. Clear communication helps collaboration more than disappearing until you have an impressive number.

Ask during the discussion or note it for afterward. “I do not understand that term yet; could you explain it using this example?” is a normal question.

For a disagreement, explain your interpretation and evidence: “With that explanation I would expect A, but the experiment shows B. Could we look at it together?”

Discuss responsibilities, time commitments, goals, and how authorship will reflect contributions at the start. Update the discussion as work and contributions change.

Talk to the people involved first; a shared supervisor can help if necessary. Keep clear written agreements where possible.

For reading, ask it about concepts, equations, and background, then check the original evidence. For coding, use it to create scripts and investigate errors while understanding core computations and evaluation. For experiments, let it organize records, plot, and help analyze.

Discuss your questions with it, investigate related work, and challenge explanations. For writing, use it to improve structure and sentences while checking that each claim matches your evidence. See working with AI.

Ask for original records. If an experiment succeeded, inspect configuration, logs, outputs, and statistics. If a paper supports a claim, find the relevant passage.

A plausible plan still needs a test that distinguishes whether it is right. Keep unexpected observations open rather than immediately asking AI for another neat explanation.

You can explain the work, answer why a choice was made, say what the metric measures, anticipate problems, and adapt when conditions change.

That is not trivial. Even when AI executes the task, experience has to remain with you through your understanding of the process and its feedback.

Look back afterward: what did you expect, what happened, which judgment was wrong, and what would you check first next time? Keep a concrete example and revisit it later.

Writing a first paper with AI can still be painful. If the process teaches you more about experiments, writing, and organizing work, you have a reference point for next time.

Public papers, open-source code, and your own notes are usually easier to handle. Unpublished lab ideas, data and drafts, other people's code, and private or confidential material require checking permissions, team agreements, and the service's data policies.

For reviewing, check that year's venue rules separately. ICML 2026, for example, distinguishes two reviewing policies: follow the one assigned to you. Permitted assistance does not mean delegating judgment and evaluation to AI.

Check the target venue's writing rules too. Authors remain responsible for the content; AI cannot take on authorship responsibility. Follow the specific rules on disclosure and permitted use. Check every reference, particularly for fabricated citations. Official entry points are on the publication page.

Solid work supports its claims and methods with enough appropriate experiments and analysis to form a paper. Writing communicates those ideas, evidence, and methods to readers; presentation is part of that.

You can start before experiments finish. Draft the question, figures, and result notes early to see what is missing. A paragraph that is hard to explain may reflect a sentence problem—or unresolved thinking in the research itself. See writing and presentation.

Good research gives the community new insight and knowledge, sometimes changing how people understand a problem.

A new method is one form of contribution; an improved score is a signal. As for prestigious venues, unfortunately I think they are becoming less important in your era as a way to judge the work itself. What matters is the knowledge produced and the problem addressed. For institutional recognition and admission, you still need to understand the rules of your environment.

SCI/SCIE are citation indexes. The phrase “SCI journal” refers to inclusion in an index. Journal quartiles are another evaluation layer; do not conflate them.

CCF A comes from the China Computer Federation's recommended publication list, which groups conferences and journals into A, B, and C categories. Chinese institutions may use it for awards or graduate admission; check the particular program.

Top conference is an informal description of an important venue in a field. NeurIPS, ICML, ICLR, CVPR, and ACL are names common across AI areas. A field's view and the CCF list are not identical.

A workshop is a focused forum for discussion. Archival status, later submission of an extended version, and accepted work types depend on its rules. A suitable workshop can offer conversation and feedback.

A preprint shares work before or outside formal publication. arXiv is a common venue. Uploading there does not itself mean peer review; a preprint may later be formally published. Inspect the specific version and publication record. Find official links on the publication page.

Read this list again. Many questions you once had are now things you have experienced. That is progress.

Can you identify what a new paper does and where its problems may lie more quickly? Do you know where to investigate an error? How much of a lab discussion can you follow? Do you have your own views and questions about the area?

Those changes happened to you and do not disappear because you lack a paper for now. My freshman-year review includes my first rejection.

There is no standard answer; ultimately listen to yourself. Without papers or graduate admission, would you still want the answer? Are you tired because things recently went badly, or because you dislike the work? Is the problem the task, collaboration, resources, or the direction itself?

If it is a rough stretch, change the topic or collaboration, or rest and reconsider. If you dislike it, changing direction or stopping is legitimate. It is not a moral failure to leave.

When priorities conflict, health comes first. Physical and emotional problems make everything else difficult. How you arrange grades, friends, hobbies, and research depends on the life you want; someone else cannot rank them for you. Research is one possible part of university. Whatever you choose, let it be a decision you have thought through.

For the rest of life, return to a letter to new students and living well.