Research update: The paper is taking longer than I thought...
Ram Rachum
Hi everyone!
Retrospective on goals for last month
In last month's update I outlined a list of goals. Here's my update on these goals:
Finish the dominance hierarchies paper: LOL No 😶🌫️
Last month I confidently wrote "August is the month in which I finish this paper." I underestimated how much work that's going to be. I did do a lot of work though. The first three pages are in pretty good shape: Abstract, Introduction, Background and most of the Definitions section. I've detailed some of the obstacles I went through below.
Splitting the paper to two papers
As I was refining the abstract for this paper (meme), I was putting an emphasis on giving the motivation for my research and making it clear exactly why I'm doing what I'm doing. We've all seen academic papers that immediately dive into the technicalities of their work before it's clear to the readers why should we even care about this.
I wrote about citing AI Safety, AI Explainability and AI Corrigibility as my motivation in the abstract, and when my co-authors reviewed my paper, they told me that it looks really surprising and not clear. After some discussion and thinking, I realized that I had non-trivial things to say about the connection between dominance hierarchies and the eventual goals of AI Safety. As I was starting to write out my long-term research plan, it became apparent to me that I should split this paper into two papers: One paper about dominance hierarchies and one position paper about my plan for AI Safety.
It makes sense to separate these stories for several reasons:
The dominance hierarchies research involves a series of actual experiments and analyzing quantitative data, while the long-term plan is more of a position paper.
The dominance hierarchies research doesn't require the reader to know or care about AI Safety at all. This is important, because I might be submitting it to a venue like AAMAS, where AI Safety is a niche topic, and where the terminology of the AI Safety world might be considered less rooted. I can keep all the AI Safety terminology on the AI Safety paper.
Splitting the paper to two means that each paper will be shorter, allowing me to iterate faster on learning how to write papers.
I'm going to work only on the dominance hierarchy paper now, because it's important for me to present a serious, full-length paper as soon as possible, to prove that I'm a legitimate researcher with interesting things to say. I'll leave the position paper for later.
What I learned about academic writing
I've been doing rounds of reviews with my co-authors and mentors, whose academic writing experience levels range from "having 2-3 years more experience in academic writing than me" to "have published research in peer-reviewed journals back in the 1970s, while my parents were in junior high." After a few rounds of reviews (meme), I've distilled a few lessons about academic writing that I'm now sharing with you:
I need to be careful not to offend other researchers. This is a subtle point; the challenge is understanding what could be offensive. It isn't like I was calling out specific papers, or God forbid, researchers, for not being good enough. What I did do when I wrote the first versions of my paper is this: I set a premise that we don't understand MARL cooperation well enough, or in other words, that we haven't succeeded in getting MARL agents to cooperate except by using intrinsic rewards which are problematic. I was presenting my research as a possible direction to a solution to this difficult problem. The issue with this story is that there are various researchers out there who have done research on MARL cooperation and presented some results that they are proud of. They could have a different understanding of what it means to succeed at getting MARL agents to cooperate. Maybe they feel like the work that they and their peers have been publishing is a success. These researchers might be very offended to read my paper, where I am arguably dismissing their research. If any of these researchers were to be chosen as my reviewers, it could lead to an instant rejection. Even if they weren't, it would still be bad karma. Because of this lesson I chose to look for a different motivation for my research. I found a more positive one, which I won't reveal here, but which you could read in my intro, hopefully in a month from now.
A to B, B to C, C to D. There's one mistake I've been doing which is a by-product of the formal, high-brow writing style of academic papers. Sometimes I would write a sentence that is accurate and well-phrased, but when my reviewer would read it, it would take them a bit more time to parse it out and understand how they related to what we've established in the previous sentence. They would understand it after a few seconds... But these pauses are disorienting, and I would like to avoid them. I wish I had an example but my examples are too awkward to share. This happens when a sentence is phrased in a passive voice, or any other kind of overly-formal writing. Typically the part of the sentence that makes it clear how it relates to the previous sentence is at the end of the sentence, while it should be at the start. You can call this rule "A to B, B to C, C to D". The bad pattern could be described as "A to B, then C because of B, then D as a result of C." Every sentence that builds on the previous sentence should first pick out the part of the previous sentence that it builds on as a premise, and only then add the new content. Many people will tell you to avoid overly-long sentences because they're awkward, and this is mostly true. But if you look closer, you'll find that the "C because of B" pattern is actually a major cause of awkwardness in sentences. When you write your sentences "flat", you can make them longer than usual while still providing a smooth reading experience.
Some words have particular meaning to some people. In one of my earlier drafts, I was using the word "team" a lot when describing a group of agents working together. The problem with using the word "team" is that it's a word often used in MARL research with fully-cooperative environments. In a fully-cooperative environment all the agents get an identical reward signal, which is something I find less interesting because the agents work together as a hivemind rather than individuals. The environments I'm interested in are mixed-motive, meaning that agents have some shared interests but also some conflicts of interest. If I were to use the word "team" I would be attracting reviewers and readers who are interested in fully-cooperative environments rather than mixed-motive environments. The bigger lesson here is not about the word "team" specifically, but that some words have become "code words" that signal belonging to a certain group, and I need to be aware that the meaning that these words have to some groups of people is different than the meaning that they have to me. I think that word "team" is actually a good word for describing mixed-motive groups of agents, because even in human teams there are conflicts of interests between individuals. But when a word becomes a code word, you have to put all of that aside and conform to its accepted usage.
My goals for this month
Finish 80% of the dominance hierarchies paper.
So I'm going to be smarter this time and I won't say "September is the month in which I finish this paper". But I will say that the deadline for submitting a paper to AAMAS is 2023-10-09, and I really want to submit my paper to AAMAS.
That's it for now. See you next month!
Ram.