AI Listening Notes: The Three Types of Information I Lose in English Online Seminars
Last fall there was a cross-time-zone online seminar that started at 1 a.m. Beijing time, with six talks over two hours. I listened with a cup of coffee and took half a page of notes. When I looked back the next day, the only parts I could piece together completely were the opening remarks of three talks.
The information I lost wasn't random; it followed a pattern. Later I lined up that half page of notes with the recording and found that I consistently lose things in three places. This post is about those three types and how I now make up for them.
Type 1: The background setup in the first thirty seconds
Speakers generally use the first thirty seconds to cover three things: whose work this follows, which specific problem it solves, and why it is being done now. These three sentences have the fastest speech and the densest terminology; on the first listen I basically can't catch them, and what I can write down is instead the understandable details that come later.
My current approach is: record the whole session, then go back and use MuchSci's AI Listening Notes to go over the opening segment again, listening and translating at the same time, and first use the translation to match these three things. If there are terms I'm unsure about, I then use MuchSci's Paper Translation to check whether the same term is rendered consistently throughout the translation.
But there is one part I must go back to the original audio for: dataset names, reference numbers, and model names. These kinds of strings are most easily distorted by machine translation, so I don't use the translation directly.
Type 2: Transitional sentences in the middle of a talk
Sentences like "Now let me turn to…" and "That's why we…" — I used to skip them directly in my notes because they seemed to carry no information. Later I realized that the argument structure of the whole talk is hidden in these sentences: which part is background, which part is the speaker's own work, and which part is the next-step plan — all divided by transitional sentences.
My revised approach is: first look at the automatic segmented summary provided by MuchSci's AI Listening Notes. I don't rush to read the content of each segment; I first look at how the segments are split and what relationship they have to one another. Once the structure is clear, I decide which segments need close reading
There is a boundary to make clear here: the segmented summary tells you "what this segment is talking about," not "how important this segment is." It can't rank importance for me; I can only mark that myself according to my research topic.
Type 3: The final Q&A section
The Q&A section is the easiest to lose entirely. Questioners speak fast, the microphone is far away, and accents are heavy; I often can't even hear the questions clearly.
The standard I now set for myself is: I don't require completeness in the Q&A section, only knowing "which point someone challenged." Specifically, I pick out this section and listen to it again, first looking at the several questions listed in the translation, then going back to the original audio to hear how the speaker responded. As for the detailed arguments in the responses, unless they are directly related to my research topic, I generally don't pursue them further.
Why I no longer chase "understanding everything"
For a 1 a.m. meeting, understanding every sentence is unrealistic; the result of chasing that is being unable to do anything the next day. I now set my goals at three things: after the meeting, I can say what problem this talk is solving, roughly which path the method takes, and which point was challenged. Achieving these three is enough.
This is also how I understand the place of this kind of graduate-student AI assistant — it helps me fish back what I missed, but it doesn't make judgments for me.
What I don't give it, what must be checked against the original, and the cost
· Not given to it: I don't share paragraphs involving others' unpublished data; for original sentences I plan to quote directly, I always go back to the original audio to confirm; for methods and parameters, I only use the translation to locate things, not to draw conclusions.
· Must be checked against the original: numbers, units, reference numbers, dataset and tool names.
· The recording itself: when other people are present at the meeting, I say "I'm taking notes" before it starts, and I don't record without confirmation.
· Cost: listening notes are consumed by credits; a two-hour meeting is okay, but three meetings in one day is noticeably tight. My approach is to split long meetings into two recordings and process the segment I need most first. The 3,960 credits given as a first-time bonus ran out by the time I got to my third meeting, and after that I buy them by tier.
· After organizing, I put things into MuchSci's Personal Knowledge Base, stored by topic; for outlines that actually need to be handed over, I use MuchSci's Office Assistant Agent to arrange them into an editable document. My meeting workflow now has only three steps: before the meeting, don't expect to understand everything; during the meeting, only mark anchors; after the meeting, fill in the gaps according to the three types of loss points.