Video Transcript (English)

Hello! In this video, you will learn how to improve your search by assigning weights to different fields using the $compound operator, so that when a user searches on your application, the most important results return first.

To do this, we’ll create an aggregation pipeline in MongoDB Atlas with a $search stage, and then we’ll use the $compound operator to specify how the results should be ranked.

We can see in the Atlas interface that we already have a search index with dynamic mapping, which is the index that we will use to search with a compound operator. To start, I’ll give you an overview of how this works and then we’ll go through an example.

Atlas includes a built-in query tool to test basic operations of search indexes. To add customizations, we need to create a $search stage in the aggregation pipeline. If we were developing an app, we would use the MongoDB driver for our respective language to write code for an aggregation pipeline with a $search stage. For the purpose of this demonstration, we will use the aggregation pipeline tester in MongoDB Atlas.

In the $search stage, there are several components that we can configure: which search index to use, options about how much text to return with the search terms highlighted, number of total documents, and the compound operator, which includes its own set of options that are important for us to be able to customize how we determine which results come up. In this example, we will not use the optional fields, and only focus on the operator.

The $compound operator is nested in the $search stage, and it includes clauses that specify the weight that the different fields should have in the search ranking.

Those clauses are “Must” - which will include only results that match the clause. “must not” - the negation of “must”. And “should” - which will assign a weight to records that match the clause. You can also add a filter clause into the compound operator, which will eliminate any search results that do not match the clauses, but it does not affect the score.

Let’s say we are creating an app for birders that want to learn about different species, and we want to present those birders with birds with which they might be most familiar. We know that our users live in an area with a lot of grasslands, and it’s likely that they spotted birds that are larger because they are easier to see. We would like to surface birds that live in grasslands and have a large wingspan.

Let’s use a must clause and a should clause. All our search results *must* be birds that inhabit grasslands, and *should* have wingspan greater than 75 cm.

In Atlas, let’s create a $search stage in our aggregation pipeline.

First, we’ll click the aggregation tab.

Then, in this drop down menu, we’ll select $search.

Let’s delete the boilerplate example and write in our own.

I start by creating a compound operator and adding a must clause which includes the query for “grasslands” which is a value that we will find in the “habitat” field, so “habitat” will be our path.

Next, we’ll create a should clause to specify that we only want to show birds with a wingspan of greater than 75 cm and we will assign a score with a value of 5 to give records where the wingspan is greater than 75 cm a higher score and rank those results higher.

The documents in the aggregation results panel here show records returned in order based on the scores given to them. We can see that the first results are birds that live in grasslands, and that have a wingspan greater than 75cm, because those records have a higher score!

In fact, if you were curious, in the project stage you can see the scores that were assigned to each record. Here, we see that a value of 5 was added to the score for the first two records since the wingspan is greater than 75 cm, but not for the following 2, since the wingspan is not greater than 75 cm.

Wow! That’s pretty powerful customization. Now you know about how $search works as part of aggregation, and how you can use the compound operator to customize the way that results are returned to your user, you can imagine how we can get pretty creative with field weighting in the context of an application.