Cameras are everywhere — in our homes, on our streets, in stores, at intersections, in care centers, in mobile devices and across the systems we rely on every day. Yet most of them are still just passive recordings: endless hours of footage that no one watches unless something has already gone wrong.

What if live video systems could do more than just record? What if they could understand context, reason over events, and alert only when something genuinely important happens? — even across thousands of hours of uneventful footage? Better yet, what if they could anticipate important events before they fully unfold?

A system like that could make streets safer, help elders live more independently, give parents greater peace of mind, and make homes more secure.

Vaan is a step in that direction. Its goal is to be a flexible, promptable system for monitoring live video streams and alerting users when important events of interests happen.

How it works

Problem

The core problem in live video understanding is sparsity. In most real-world streams, the events we care about are rare.

A fall, an accident, a theft, an abandoned item, or an unusual event may happen only once in thousands of hours of footage. In many streams, it may never happen at all. And yet the system has to stay ready, keep watching, and make the right call in real time. This makes the problem fundamentally different from the typical short-context perception tasks that multimodal LLMs have shown strong capabilities for.

Because of this, we cannot process the entire stream with multimodal LLMs in the traditional way (limitations: context windows , latency and the cost ). At the same time, we still want to leverage the world understanding and reasoning capabilities of multimodal LLMs and to have the flexibility of handling variety of events just with text based queries and not complex configuration or event specific pipelines.

Approach

Inspiration

If we squint a little, this problem looks very similar to the one faced by live voice assistants. Live voice assistants deal with a comparable challenge, though usually in a less extreme form. Where the signal of interest — user speech — is also sparse relative to the total duration of the stream.They must continuously determine when the user is speaking and when she is not.

This is why modern voice assistants built on top of general-purpose LLMs do not hand off transcript / raw audio continuously to the model. Instead, they use a staged pipeline that cheaply filters, segments, and validates candidate moments before escalating to a more capable and more expensive model.

Modern live voice assistant systems such as LiveKit Agents address this using a pipeline like the one shown below:

The key stages in that pipeline are:

• The audio stream is chunked and passed through a VAD (voice activity detection) model to determine whether the user is speaking, whether speech is ongoing, and whether the user has paused or finished speaking.
• Once a pause or end of speech is detected, the chunk is sent to a transcription model to generate text.
• A pause detected by VAD does not necessarily mean the user has completed their thought. For example: “I want to switch on the lights … (pause) in the dining room.” To avoid handing incomplete input to the LLM, an end-of-turn detection model is used to determine whether the transcript actually represents a complete user turn.
• Once the transcript is classified as complete and end-of-turn, it is passed to the LLM to generate a response.
• The response is then sent to a TTS (text-to-speech) model to produce audio output.

All of these steps are executed in a streaming manner to reduce both latency and context usage.

At a high level, the solution is to first use a cheap and fast mechanism to speculate whether an event of interest has occurred — in the voice assistant case, speech and turn detection — and then hand over only the relevant context to a more accurate but more expensive LLM for verification and response generation.

This is similar to what Vaan attempts to achieve for live video streams.

Solution

Vaan uses a relatively cheap and fast mechanism to speculate whether an event of interest may have occurred — using rerankers or embedding-based retrievers — and then accumulates the relevant context before passing it to a more accurate but more expensive LLM to verify the event and generate the required response.

Here is a high-level overview of the architecture:

The key stages in this pipeline are:

• Once a stream is submitted, it is picked up by a stream worker for processing.
• The stream worker continuously chunks the video stream and passes each chunk to a screener (reranker) model to determine whether it is relevant to the trigger queries.
• If a chunk is identified as relevant, it is passed — along with neighboring chunks and other relevant context — to an LLM worker.
• The LLM worker reasons over the context, verifies the event and generates , extracting the required information for the alert.

Demo

We’ve put together a few demos of Vaan in action across very different real-world scenarios on a demo UI ( scroll horizontally over the videos to see them all ):

• Alerting when a baby has fallen down or may have gotten hurt.
• Alerting when uninvited wildlife shows up to raid the cat food.
• Alerting when Santa places a gift. (yes — Santa can’t sneak past this one 😅)
• Alerting when a vehicle accident occurs at an intersection.
• Alerting when a customer completes a checkout and walks away leaving their items behind.
• Alerting when a person / elderly falls down.

Getting started

Follow the instructions in the README to setup and get started.

Current limitations

• The screener model uses Qwen3-VL-Reranker-2B to perform fast verification of chunks against the trigger queries. Out of the box, the model shows poor separability of classes: negative examples typically score below 53%, while positive examples are often only slightly higher, in the 55–57% range. This leaves little margin for reliable thresholding.

• We found that a threshold of 0.55 provides a good balance between precision and recall. However, the optimal threshold depends on the use case, so it may need to be adjusted based on your requirements. We recommend starting with 0.55 and calibrating it on your own data.

• Current frontier multimodal LLMs are reasonably good at understanding videos and detecting actions, but they still do not perform as well on video reasoning tasks as they do on text reasoning tasks. To illustrate this, here are two examples of false positives.

  1. In the first example, the model misinterprets overhead power lines on the street as fallen lines. It then combines this perception error with the presence of a police or emergency vehicle in the corner of the frame — likely from the aftermath of a different incident — and incorrectly classifies the scene as a car accident. The camera angle makes the power lines appear as though they are lying on the road, but for a human observer it is fairly obvious that this is not an accident scene.

  2. In the second example, the trigger query is: “a customer completes a checkout and walks away leaving their items behind.” Here, the model fails to distinguish between empty shopping bags placed at the end of the checkout aisle and the customer’s actual items. As a result, it incorrectly concludes that the customer has walked away and left their items behind.

This behavior is not specific to any one model. We observe similar failure modes across current frontier multimodal LLMs with native video support, including gemini-3.1-pro-preview, gemini-3-flash-preview, qwen3.5-plus-02-15, and glm-4.6v.

Future directions

The current limitations outlined above are exactly what make this such an interesting and valuable problem to solve.

Some of the most exciting future directions are:

• Improve the screener model to achieve better separation between positive and negative examples, while making it more robust to variations in query phrasing, camera angle, and real-world noise.
• Move the screener closer to the source. Today, the screener is designed to run on serverless infrastructure on Modal, but over time we want it to run nearer to the camera — and eventually on-device where possible.
• Build systems that are more robust to the messiness of the real world. Real-world environments are noisy, ambiguous, and highly variable, and we want both the screening pipeline and the LLM layer to handle these variations more reliably.
• Create / curate a benchmark relevant to this problem to reliably evaluate the performance of the systems and future LLMs.
• System that can anticipate / predict events before they happen.

Contributing

We understand that this is a highly sensitive problem, which is exactly why we believe in building it in public.If any of these directions are interesting to you, please feel free to contribute to the project or share your thoughts and feedback in github issues or join the discord channel here. You can find the code and documentation in the GitHub repository.

TLDR: I struggle with keeping pace with the latest AI research. My latest attempt at tackling this is to have an automated newsletter sent to me with the summaries of interesting research resources that I added to my reading list the day before. (Because apparently my coping mechanism is “add more automation,” not “read the papers.”)

An example newsletter. I detail my process in this post.

The problem

I have been maintaining a reading list in a Notion database (my first brain) for a few years now . I clip/add any resources that I want to read to this list from my browser/phone. The goal is to have a quick way to collect resources without getting distracted by going too deeply into any particular one.

This system works well if I read through all the resources I added the day before on the next day. But as you have guessed by now, this doesn’t always happen, and now I am in a situation where the reading list has 2000 resources to read.

Hi! from my reading list

I have two problems at hand (that I want to acknowledge): one is clearing the big, gigantic list that brings me anxiety and stares at me every day, and the other is having a more efficient system to clear the things that are added from now on. This post is about the latter. (The former and I have agreed to make eye contact but not talk about it; the big, gigantic list can wait for now!).

The Duct-Taped Workflow

In my usual end of the year urge to make atleast the next year better, I have a new extension to the system. (One more workflow duct-taped onto the same chaos).

I am experimenting with an automated single-person newsletter. The system takes the links I added to the list the day before, fetches the content from the resources, and summarises the content (see the prompt and format below) into a daily newsletter that gets sent to me in the morning.

I hope this will at least give me an overview of the list and help me cover its breadth. If something interests me further, I’ll sit down to read it properly / take a deep dive.

I wanted to keep it simple without requiring any babysitting and also to be cheaper to run. Here is a breakdown of the system:

simple sketch of the workflow

• The system is a repository on GitHub - Selfletter.
• A GitHub Action is scheduled on the repo to run every morning to fetch the content from the lists I added the day before and send the newsletter to my email as a single digest after the summarisation and collation are done.
• It has an initial list of data processors to fetch content from:
  • arXiv URLs - abstracts, PDFs → full paper
  • Hugging Face paper page -> full paper
  • Other resources → full content
• I use the Reader API from Jina.ai (r.jina.ai, Thanks Jina.ai!) to fetch the content for all the resources listed above.
• Pass it to an LLM (gpt-oss-120b) to summarize, and I use SMTP and Gmail with Google application passwords to send the email to myself.

Summary prompt

I follow Andrew Ng’s great advice on how and what to read from a paper. My summary prompt is based on that:

Summarize the following content:

Title: {title}
URL: {url}

CONTENT:
{content}

You should always create summaries capturing the below template as a markdown file (with accurate markdown formatting and structure), It is important to follow the template exactly without leaving any section empty:

## What did the author accomplish ?

 -  What

 -  Why

## What are the key elements of the approach ?

 -  How
    - How the approach is implemented
    - Embed one important image / diagram / code snippet from the content showing the approach (embed it in size suitable for email newsletter)

## What can you use yourself?
- important tools and resources from the content ( model links , dataset links , github links etc)
- recipies / methodologies discussed in the content
- hyperparameters / best practices discussed in the content
- other useful aspects that can be integrated into further research.

## Training compute:
- If the content discusses training compute - training hours , GPU used etc.

## References to further follow / read ?
- important references and links from the content

Using the repo

Feel free to try the repo and fork it to adapt to your needs. Keep in mind that this was created to suit my workflow ( and my chaos), if you like to adapt to yours - you can do it by fitting your workflow here

Repo: Selfletter

Acknowledgement and Gratitude:

• Thanks to Jina.ai for the free reader endpoint
• Thanks to Github Actions service for making this service simpler.
• Thanks to Andrew Ng’s advice. The prompt is based on the advice.
• This repo was mostly vibe coded with Blackbox Cli

Having said that, software development is complex and involves many aspects that LLMs still struggle with, like effectively solving repository level tasks, collaboration, using and integrating with our existing workflows and tooling.

Just as syntax highlighting , code completions , tool tips with code hints , linting in an IDE help improve coding efficiency for humans, interfaces purpose built for agents would help improve the coding success rate of LLMs. These interfaces decide how a code context or an execution output context can be shared with LLMs effectively for their usage. These interfaces are a step towards bridging the gap in current abilities of LLMs in completing SWE tasks.

In this blog post, we will explore some of the latest agent interfaces that have been used in state-of-the-art software engineering (SWE) agents

These interfaces can be broadly split into two high-level categories:

• Localization of the code to change ( Context retrieval )
• Patch generation ( Making the change required for a fix or new feature )

Localization of the code to change:

The first step in fixing or implementing a new feature to a repository is to understand the overall structure of the repository and locate the files and lines to be changed in the repository. Giving the context of a full repo is inefficient and impractical for moderately sized repos. Here we discuss some of the approaches to condense the repository structure and localize the location of code change to be done.

1. Repository tree structure:

   Agentless (Xia et al. 2024) and Repopilot create a high-level tree representation of the directory and files in the repository by recursively traversing from the root folder to each code file. This is fed to the LLM as an initial step for it to understand the repository and generate probable candidate files for it to start with the editing process.

   

   Example of a repository structure

2. Repository map:

   Aider uses a richer representation called repo map than the basic repository tree structure, to provide repository context to the LLMs. The repo map has a list of files in the repository along with the important symbols and their definition in each file. This is done by analysing the AST of the code files with tree-sitter .

   This context can also easily become very large for a repository with tens to hundreds of files. Aider cleverly addresses this challenge by using a graph ranking algorithm to include only the most relevant and important files within a context budget.

    aider/coders/base_coder.py:
    ⋮...
    │class Coder:
    │    abs_fnames = None
    ⋮...
    │    @classmethod
    │    def create(
    │        self,
    │        main_model,
    │        edit_format,
    │        io,
    │        skip_model_availabily_check=False,
    │        **kwargs,
    ⋮...
    │    def abs_root_path(self, path):
    ⋮...
    │    def run(self, with_message=None):
    ⋮...
   
    aider/commands.py:
    ⋮...
    │class Commands:
    │    voice = None
    │
    ⋮...
    │    def get_commands(self):
    ⋮...
    │    def get_command_completions(self, cmd_name, partial):
    ⋮...
    │    def run(self, inp):
    ⋮...
   
   

3. Search tools :

   SWE-agent (Yang et al. 2024) , OpenDevin (Wang et al. 2024) and AutoCodeRover (Zhang et al. 2024) use bash and python-based utilities as tools to let agents search through and understand the files. The utilities are used by agents to perform high-level searches like searching a directory with keyword , searching a file and more specific searches like searching for a class , method etc.

   

   This helps in reducing the context provided to the agents. Rather than us deciding the context to be fed to the agents, with the search tools the agents decide the context needed to perform an action.

   Yang et al. 2024 further control the context by restricting the search results to almost 50 results and if the results are not satisfactory, the model is prompted to search with a more specific query. The authors find that using these search tools improves the pass rate of tasks.

4. File context:

   Similar to repo context, It is inefficient to provide the full context of a file to the agent at once. SWE-Agent (Yang et al. 2024) and OpenDevin (Wang et al. 2024) use several utilities to control the context.

   1. Open: The file viewer presents a window of at most 100 lines of the file at a time
   2. scroll_down and scroll_up : Move the window up and down
   3. goto : access a specific line

   The code in the file viewer is enumerated with line numbers. This helps the model to use the correct line numbers while editing the file.

   The file viewer has important additional details like the full path of the open file, the total number of lines in the file, and the number of lines omitted before and after the current window. This helps the model to understand that there are more lines in the file and it can scroll up or down to access further context when needed.

   

5. Localisation from the repository to code location:

   • To localize the code lines to be changed from the repository level context Agentless (Xia et al. 2024) takes a multistep approach. They first pass the repository structure ( discussed above) to the model and ask it to generate the Top N most probable files that should be edited for a given feature or a fix.

     The skeleton ( important symbols and definition) of these shortlisted files is provided as context to further shortlist the specific list of classes and functions that should be edited. The complete code of these shortlisted locations is prompted to the model for editing.

   

   • Aider takes a more practical and human-in-the-loop approach to file localisation, The files to be edited are expected to be added to the Aider’s chat by the user. This workflow would avoid failure modes of the wrong file being edited or the model getting stuck in editing the wrong file.

6. Spectrum-based Fault Localization (SBFL):

   Autocoderover (Zhang et al. 2024) uses an external tool to suggest probable locations of fault using a method called Spectrum-based Fault Localization . Given a test suite containing passing and failing tests, SBFL considers control-flow differences in the passing and failing test executions and assigns a suspiciousness score to different program locations. These suspicious locations are fed to the LLM to further identify the most likely locations of errors

   

   SBFL from Autocoderover (Zhang et al. 2024))

Patch generation:

The next step after localisation is to generate a code change to fix or add a new feature. A trivial approach to this would be to generate the code file from scratch (as a whole) for every edit, but this is inefficient, time consuming and can be limited by the context. Let’s discuss more efficient alternatives for edit generation in this section.

1. Editing with line numbers :

   SWE-agent (Yang et al. 2024) ( and previously OpenDevin (Wang et al. 2024) ) uses line numbers to specify the range of lines that are to be edited. The line range in the file is replaced with the code specified in the command.

   

   Sample edit command from SWE-AGENT, the line 1475 in the code file is replaced with the code in the command

   This method is efficient in terms of token usage and could also lead to a higher success rate of edits getting executed. But it also leads to some of the common failure modes:

   • Models are bad at tracking line numbers: Even if the file context interface is always shown with line numbers, with consecutive edits throughout the task lifecycle the line numbers change often. This results in the model invoking the command with wrong line numbers resulting in incorrect edits and syntax errors.
   • Actions do not always match the intention: This is not only specific to this editing approach, but it is prevalent with this one. The model would intend to change a set of lines ( like an if block) but it would end up specifying the line range of just few lines of the block instead of the complete ones ( like just the if condition line ) leading to errors.

2. Line diff format:

   An alternate approach is to let the model generate edits in unified diff format , which is a standard way of displaying the changes between code files and the models are more likely to be familiar with this approach due to its familiarity during pretraining. However, this approach necessitates the model to generate several unchanged lines before and after the actual change lines.

   

   An example of Unified diff format from OctoPack: Instruction Tuning Code Large Language Models. Muennighoff et al. 2023

   Muennighoff et al. 2023 introduce a simplified diff format called line diff format. Requiring only the lines of change to be shown ( along with line numbers) instead of additional lines as in unidiff format. Muennighoff et al. 2023 show that fine-tuning models with this format perform better than the unidiff format on the zero-shot HumanEvalFix dataset.

   

   An example of line diff format from OctoPack: Instruction Tuning Code Large Language Models. Muennighoff et al. 2023

3. Search and replace diff string format:

   Aider uses another diff string-based edit format which is shown to perform the best in their code editing benchmark. The format uses a fenced code block that specifies the file name, and lines of code to be replaced followed by new code lines in the replace block.

   Even though this approach consumes a lot more tokens than the line number-based approach, it seems to handle the common failures better.

    # Here are the changes you requested to demo.py:
   
    demo.py
    <<<<<<< SEARCH
        print("hello")
    =======
        print("goodbye")
    >>>>>>> REPLACE
   

   But from my personal experience, this approach is also not perfect and also leads to some of the common failure modes:

   • Edit failures due to additional lines: When the models generate the code in the search block, it sometimes hallucinates additional lines which are not in the original file. This leads to edits not being applied because of a lack of exact match with the original code.
   • Edit failures due to missing lines: This is the opposite of the above case, the model sometimes fails to mention the empty new lines or comments from the original file leading to no exact match
   • Actions do not always match the intention: Even this approach has the issue of the model missing the full code block that it intends to change, mentioning only the partial lines.

4. Linting before applying edits:

   SWE-agent (Yang et al. 2024) study that linting the code to check for syntax errors before applying the code improves the overall pass rate by 3% on SWE-bench tasks.

   

   Examples with and without linting from SWE-agent (Yang et al. 2024)

   

5. Post edit:

   SWE-agent (Yang et al. 2024) and OpenDevin (Wang et al. 2024) show the edited location along with a window of a few top and bottom lines to the model after the edit is applied. This helps the model to look for any duplicates or mistakes that are introduced in the edit and rectify the same via the next actions

   

   Example of a file viewer shown after file edit with a prompt to followup with further actions on edit mistakes

Open challenges:

In conclusion, here are some of the open challenges or limiting factors for the models in handling SWE tasks:

• File edits are messy: With the current capabilities and existing interfaces ( more so) the file editing process is messy and inefficient compared to code generation from scratch. It goes through numerous iterations and with more tries the chances of the model getting stuck in a loop increases.
• Extending the context from programs to systems: The current approaches are more focussed on the models to work at a program/file level but the capabilities to interact and design at the system level and architect a software system are still missing.
• Leveraging human developer interfaces: With improving multi-modal abilities of the models and models entering our desktops ( this and this ). The agent interface could be just a transitioning phase till the models can truly leverage the years of dev tooling that have been honed by humans.

Citation

@article{umapathi2024agentinterfaces,
  title   = "Agent Interfaces: Bridging LLMs and Software Engineering",
  author  = "Umapathi, Logesh Kumar",
  journal = "logeshumapathi.com",
  year    = "2024",
  month   = "Aug",
  url     = "https://logeshumapathi.com/blog/2024/08/03/agent-interfaces.html"
}

References

• Xia et al. 2024. “Agentless: Demystifying LLM-based Software Engineering Agents”
• Gauthier, P. “Aider”.
• Muennighoff et al. (2023). “OctoPack: Instruction Tuning Code Large Language Models”
• Yang et al. 2024. “SWE-Agent: Agent-Computer Interfaces Enable Automated Software Engineering”
• Wang et al. 2024. “OpenDevin: An Open Platform for AI Software Developers as Generalist Agents.”
• Zhang et al. 2024. “AutoCodeRover: Autonomous Program Improvement”
• “RepoPilot: Multi-Agent Coding Assistant that Understand Your Codebase”

If the machine learning projects are icebergs, then the parts that are underwater are the labelling and other data efforts that go into the project. The good news is techniques like transfer learning and active learning could help in reducing the effort.

Active learning has been part of the toolbox of ML industry practitioners for a while but rarely covered in any of the data science / ML courses. Reading the book Human in the loop machine learning by Robert Munro, helped me formalise some ( and helped me learn many ) of the active learning concepts that I had been using intuitively for my ML projects.

The intent of this article is to introduce you to a simple active learning method called ‘Uncertainty sampling with entropy’ and demonstrate its usefulness with an example. For the demonstration, I have used Active learning to utilize only 23% of the actual training dataset ( ATIS intent classification dataset) to achieve the same result as training on 100% of the dataset.

Too curious? Jump straight to the demo. Want to first understand how it works? Read on.

What is active learning?

Active learning is about training our models preferentially on the labelled examples that could give the biggest bang for our buck rather than on the examples with very less “learning signal”. The estimation of an example’s learning signal is done using the feedback from the model.

This is akin to a teacher asking a student about the concepts that she is hazy about and giving preference to those concepts, rather than teaching all of the curricula.

Since active learning is an iterative process, you would have to go through multiple rounds of training. Steps involved in active learning are:

1. Identify and label your evaluation dataset.

It goes without saying that choosing an evaluation set is the most important step in any machine learning process. This becomes even more crucial when it comes to active learning since this will be our measure of how well our model performance improves during our iterative labelling process. Furthermore, it also helps us decide when to stop iterating.

The straight forward approach would be to randomly split the unlabelled dataset and pick your evaluation set from that split dataset. But based on the complexity or the business need, it is also good to have multiple evaluation sets. For example, If your business need dictates that a sentiment analysis model should handle sarcasm well, you could have two separate evaluation sets — one for generic sentiment analysis and other for sarcasm specific samples.

2. Identify and label your initial training dataset.

Now pick X% of the unlabeled dataset as the initial training dataset. The value of X could vary based on the model and the complexity of the approach. Pick a value that is quick enough for multiple iterations and also big enough for your models to train on initially. If you are going with a transfer learning approach and the distribution of the dataset is close to the pre-training dataset of the base model, then a lower value of X would be good enough to kick start the process.

It would also be a good practice to avoid class-imbalance in the initial training dataset. If it’s an NLP problem, you could consider a keyword-based search to identify samples from a particular class to label and maintain class balance.

3. Training Iteration

Now that we have the initial training and evaluation dataset, we can go ahead and do the first training iteration. Usually, one cannot infer much by evaluating the first model. But the results from the step could help us see how the predictions improve over the iterations. Use the model to predict labels of the remaining unlabelled samples.

4. Choose the subset of samples to be labelled from the previous step.

This is a crucial step where you select samples with the most learning signals for labelling processes. There are several ways to go about doing it (as explained in the book). In the interest of brevity, we will see the method that I felt to be most intuitive of all — Uncertainty sampling based on entropy.

Entropy-based Uncertainty Sampling :

Uncertainty sampling is a strategy to pick samples that the model is most uncertain/confused about. There are several ways to calculate the uncertainty. The most common way is to use the classification probability (softmax) values from the final layer of the neural network.

If there is no clear winner (i.e all the probabilities are almost the same), it means that the model is uncertain about the sample. Entropy exactly gives us a measure of that. If there is a tie between all the classes, entropy of the distribution will be high and if there is a clear winner amongst the classes, the entropy of the distribution will be low.

From the model’s predictions of the unlabelled dataset, we should sort the samples in descending order of entropy and pick some Y% of top samples to annotate.

5. Rinse & Repeat :

We need to append the training dataset from this iteration with the new samples that we labelled and repeat the process from step 3, until we reach the desired performance on our evaluation set or our evaluation performance plateaus.

Demo

For the sake of experiment and demonstration, we will use ATIS intent classification dataset. Let’s consider the training dataset as unlabelled. We start by taking a random 5% of the labelled training dataset for our first iteration. At the end of each iteration, we use entropy-based uncertainty sampling to pick top 10% of the samples and use their labels (simulating the annotation process in the real world) for training in the next iteration.

To evaluate our models during each iteration of active learning, we also take the test set from the dataset since the data in the test set is already labelled.

Demo and code is available in the notebook below: Google Colaboratory colab.research.google.com

References :

1. David D. Lewis and William A. Gale. 1994. A Sequential Algorithm for Training Text Classifiers. SIGIR’94, https://arxiv.org/pdf/cmp-lg/9407020.pdf

2. Human in the loop machine learning by Robert Munro

Thanks to Sriram Pasupathi for taking a greater effort in proofreading this article than what it took me to write this article 🙏

**P.S: I would be really glad to hear your feedback on this article, that would also push me to write the other articles in the series on “How to do more with less data” **👋

Photo by Katarzyna Pe on Unsplash

*Note: This content was part of my talk at Analytics Vidhya’s DataHack Summit 2019.*

There is a lot of buzz around NLP of late, especially after the advancement in transfer learning techniques and with the advent of architectures like transformers. As someone from the applied side of Machine learning, I feel that it is not only important to have models that can surpass the state of the art results in many benchmarks, It is also important to have models that are trustable, understandable and not a complete black box.

This post is an attempt to understand the learnings of BERT on task-specific training. Let’s start with how attention is implemented in a Transformer and how it can be leveraged for understanding the model ( Feel free to skip this section if you are already aware of it).

Attention! Attention!

Transformers use self-attention to encode the representation of its input sequences at each layer. With self-attention, All the words in the input sequence contribute to the representation ( encoding ) of the current token.

Let’s consider this example from Jalammar’s Blog ( I would highly recommend reading his blog post for a deeper understanding of transformers ). Here you could see that the representation of the word “Thinking” ( Z1 ) is formed by the contribution from other words in the sentence ( in this case “Machines”). The strength of the contribution of each word to the current word is determined by the attention scores ( Softmax scores ). It is similar to each word giving a part of itself to form a full representation of the current word.

Source: http://jalammar.github.io/illustrated-transformer/

The strength could be inferred as the semantic association of the words in the sentence to the current word. For example, the word “it” in the below visualization of an attention layer in a transformer, has a higher contribution from the words “The animal”. This could be inferred as a coreference resolution of the word “it”. This behaviour is what gives the transformers contextual representations/encodings.

Inferring association between tokens using attention. source: http://jalammar.github.io/illustrated-transformer/

These contribution strengths (attention scores) can be leveraged to understand the association between the tokens and thereby it can also be used to understand the learnings of the transformers. This is exactly what we are going to attempt in this post. We will try to understand the task-specific features learned by the transformer.

Task-specific features :

The paper — What does BERT look at ? (Clark et al., 2019) which got published earlier this year talks about the various linguistic and coreference patterns that are self-learned by a BERT model. Illustrating how syntax-sensitive behaviour can emerge from self-supervised training alone. This made me curious and wanted to try doing a similar study on task-specific features that BERT learn, after finetuning on a task.

Example of Aspect based sentiment analysis — Source: https://medium.com/seek-blog/your-guide-to-sentiment-analysis-344d43d225a7

The Task at hand :

The finetuning task that we would be using here is an Aspect-Based sentiment analysis task designed as a question answering / multi-class classification problem. This approach is inspired by this paper (Sun et al.,2019). With this approach of converting the sentiment dataset into question-answer pairs (as shown below ), the authors were able to achieve state of the art results on SEMEVAL dataset.

Aspect-based sentiment analysis as QA — https://arxiv.org/pdf/1903.09588v1.pdf

I have finetuned a BERT-base-uncased model on SEMEVAL 2014 dataset using huggingface’s transformers library and visualized the attention maps using bertviz.

Task-specific learnings :

Here I list a few of the interesting patterns that I observed by probing attention layers of the fine-tuned BERT model,

1. Aspect heads — Aspect word understanding :

I observed that head 9-8 mostly attends to the aspect related words in the review, that correspond to the aspect in the question ( word “service” in the below pictures gets a very high attention score from the word “waiter”). The aspect word in question (left side) in most cases have a higher contribution from the aspect word in the review ( right side ). So this could be considered to act as an aspect head.

2. Aspect-sentiment heads — Aspect word and related sentiment words understanding :

Here we can see examples of head 9-0 mostly focusing on aspects words that are related to the question and their corresponding sentiment words.

3. Phrase level attention to aspect and sentiments :

I also observed that there are heads that focus on the complete phrase in a review that talks about the relevant aspect in the question.

4. Attending to the opposite aspect :

Surprisingly, the head 10–3 was focussing mostly on the other aspect and their related words that are not available in the question. Here we can see when the aspect in question is “service”, head focuses on “food” related words and vice-versa.

5. Absence of the interested aspect in the review — No-OP:

When there is no mention of a given aspect in the review. Head focuses on [SEP] token. As a way of indicating the feature absence (No-Op), The heads that are designated to extract the absent feature focus on [SEP] token. This observation is in line with the findings of the paper — what does BERT look at? (Clark et al., 2019).

Further steps :

1. Even though the heads that we have seen till now attend to the specified features in most cases, there are also examples where the heads don’t attend to those expected features. So, it would be really interesting to do a more formal study ( by measuring the accuracy of individual heads, similar to Clark et al., 2019 ) on each head and their ability to attend to the hypothetical feature.

Code:

1. Task-Specific learnings — https://colab.research.google.com/drive/1P4HWHso-bV5vW8pKDSqPERet507KGlr3

2. Linguistic and syntactic learning — Replicating the results of Clark et al.2019 — https://colab.research.google.com/drive/1z5W-JGtYBFfbIWZbIO73z0oIWtEFZJYO

3. Slides of my talk at DHS 2019 — https://github.com/infinitylogesh/Interpretable-NLP-Talk

References :

1. Kevin Clark, Urvashi Khandelwal, Omer Levy and Christopher D. Manning, What Does BERT Look At? An Analysis of BERT’s Attention (2019).

2. The illustrated transformer

3. Huggingface’s transformer library

4. BertViz.

Problem:

Let’s say, your friend is trying to convince you that being rich does not make someone happy by quoting a reputed study, which says only 10% of happy people are rich. You being a logical person, you know that the actual statistic that would make sense here is the percentage of rich people that are happy and not the other way around. So you set out to find it out using Bayes rule.

Bayes rule:

P(Happy|Rich) = (P(Happy) X P(Rich|Happy))/ P(Rich)

Let us try to have a visual intuition of the above equation by considering that the probability of someone being happy is 40% and the probability of someone being rich is 5%

The green and yellow circles represent the probability distribution of people being happy and rich respectively. And we know from the study that 10% of Happy people are rich. That is the overlap area is 10% of the Happy circle. All this information can be visualized as below.

The data that we are interested in is the percentage of rich persons that are happy. This can be rephrased as the percentage area occupied by the overlap on the Rich circle (as shown below).

The overlap area can be calculated as :

  overlap area = P(Happy)  X  Percentage of overlap on P(Happy)
               = P(Happy)  X  P(Rich|Happy)

  overlap area = P(Happy)  X Percentage of overlap on P(Rich)
               = P(Rich)   X P(Happy|Rich) 

  combining the above two equations,

  P(Rich) X P(Happy|Rich) = P(Happy) X P(Rich|Happy)

  **P(Happy|Rich) = (P(Happy) X P(Rich|Happy)) / P(Rich)**
               =  40% X 10% / 5%
               =  0.4 X 0.1 / 0.05 = 0.8 = **80%**

So, 80% of Rich people are happy.

Caveats :

1. Why is the intersection of two probability distribution be considered as a conditional probability (P(Happy

   Rich)) rather than a joint probability (P(Happy, Rich))?

Yes, in a general setting intersection of two probability distribution is always a joint probability. But in our case, we are only interested in the condition of people being happy or rich and our distribution is not representative of other cases like not-rich or not-happy.

In other words, this is the probability that a person can be happy given that he is rich. So, the intersection should be considered as a conditional probability.

As a pre-requisite install the fastText library.

$ git clone https://github.com/facebookresearch/fastText.git
$ cd fastText
$ pip install .

Download the pre-trained model from here. The compressed version of the model is just a little shy of 1MB and supports 176 languages. Which is an amazing work by Fast text team.

Load the model in memory using the fastText library. Make sure the inputs are encoded in UTF-8. Model supports only UTF-8 as it was trained only on UTF-8 samples.

import fasttext
import sys
reload(sys)
sys.setdefaultencoding('UTF8') # default encoding to utf-8
lid_model = fastText.load_model("lid.176.ftz")

prediction using the loaded model.

lid_model.predict("மதியும் மடந்தை முகனு மறியா பதியிற் கலங்கிய மீன்.") 
#output - ((u'__label__ta',), array([0.99988115]))
# __label__ta - tamil

lid_model.predict("Incapaz de distinguir la luna y la cara de esta chica,Las estrellas se ponen nerviosas en el cielo.")
#output - ((u'__label__es',), array([0.93954092]))
# __label__es - spanish

lid_model.predict("Unable to tell apart the moon and this girl’s face,Stars are flustered up in the sky.")
#output - ((u'__label__en',), array([0.93129086]))
#__label__en - english

The output is a tuple of language label and prediction confidence. Language label is a string with “lable” followed by ISO 639 code of the language. Full code is here.

So after a day of fiddling with many AWS forum, Stackoverflow suggestions. I was lucky enough to find a working solution. I wanted to write this as a post. So that it will be a reference for my future self as well as it might help someone.

The problem :

By default AWS documentation and this claudia.js tutorial required me to send* “Access: image/png” *header in my GET request for it to be recognized as a binary data.

curl --request GET -H "Accept: image/png" https://XXXXXX.execute-api.us-XXXX-1.amazonaws.com/endpoint

But this wouldn’t suit my use case of accessing it from the browser. Even though the browser by default sends multiple headers and “image” being one of the header, this was not considered by AWS API Gateway.

Browser’s request header

Solution:

1. Ensure that you include the success parameter and isBase64Encoded as shown below in your API router.

api.get('/route', function (request) {

  /* .... Body of the router */

  return data.toString("base64") // 1. route body should return response in Base64 String format.
     
},{ // <-- 2. params required for binary response.
    success: 
            { 
                contentType: 'image/png', 
                contentHandling: 'CONVERT_TO_BINARY'
            },
"isBase64Encoded": true
});

1. Add Mime type “ */ ”* in the settings page of your API gateway console. This I guess enables API Gateway to consider browser’s multiple headers.

Configuration in API Gateway

1. Deploy the API.

One little quirk: Whenever you deploy an update via Claudia.js, the allowed mime types in API gateway seem to reset itself. So you may have to repeat from step 2, for each update.

I have included an example lambda service to resize an image on the fly, which demonstrates all these in detail. The complete code can be found here