Hyperspace Docs
Hyperspace Homepage
  • Getting started
    • Overview
      • Hyperspace Advantages
      • Hyperspace Search
    • Quick Start
  • flows
    • Setting Up
      • Installing the Hyperspace API Client
      • Connecting to the Hyperspace Server
      • Creating a Database Schema Configuration File
        • Vector Similarity Metrics
        • Index Type Methods
      • Creating a Collection
      • Uploading Data to a Collection
      • Building and Running Queries
        • Building a Lexical Search Query
        • Building a Vector Search Query
        • Building a Hybrid Search Query
      • Retrieving Results
    • Data Collections
      • Uploading Data
      • Accessing Data
      • Supported Data Types
    • Queries
      • DSL Query interface
        • Aggregations
        • Bool Query
        • Candidate Generation and Metadata Filtering
        • Scoring and Ranking
  • Reference
    • Hyperspace Query Flow
    • Features and Benefits
    • Search Processing Unit (SPU)
    • Hyperspace Document Prototype
  • API Documentation
    • Hyperspace Client
      • add_batch
      • add_document
      • async_req
      • clear_collection
      • collections_info
      • commit
      • create_collection
      • delete_collection
      • delete_by_query
      • dsl_search
      • get_schema
      • get_document
      • reset_password
      • search
      • update_by_query
      • update_document
    • DSL Query Framework
      • Aggregations
        • Cardinality Aggregation
        • Date Histogram
        • Metric Aggregations
        • Terms Aggregation
      • Bool Queries
        • Free Text Search
        • 'match' Clause
        • 'filter' Clause
        • 'must' Clause
        • 'must_not' Clause
        • 'should' Clause
        • 'should_not' Clause
      • Candidate Generation and Metadata Filtering
        • Geo Coordinates Match
        • Range Match
        • Term Match
      • Scoring and Ranking
        • Boost
        • 'dis_max'
        • Function Score
        • Rarity Score (TF-IDF)
  • Releases
    • 2024 Releases
Powered by GitBook
On this page
  1. API Documentation
  2. DSL Query Framework
  3. Bool Queries

'should_not' Clause

The should_not clause within a bool query specifies conditions that are optional for a document to be considered a match, in a similar manner to 'should' clause. The should_not clause decreases the document score. The should clause is often used for expressing optional or desirable conditions.

'should_not' Clause Score

In the 'should_not' clause, each condition is associated with a designated score, and the overall score for the clause is determined by substracting these individual scores. If not explicitly specified otherwise, scoring follows the TF-IDF scoring model. The 'should_not' clause enables documents to be a lesser match if they meet any of the specified conditions.

The combined score is a subtraction of the individual scores

Score = -score1 - score2 - score3...

Example -

Copy

{
  "query": {
    "bool": {
      "must": { "Bird": "Asian Koel" }
      "should_not": [
        { "term": { "Country": "India" } },
        { "term": { "Color": "Black" } }
      ]
    }
  }
}

In the above example, all candidates must satisfy the condition -

  • exact match over the 'bird' field, with score equals TF-IDF score for { "Bird": "Asian Koel" }

In addition, any documents that satisfy the following conditions -

  • exact match over the 'Country' field, with score equals TF-IDF score for { "Bird": "Asian Koel" }

  • exact match over "Color" field, with score equals TF-IDF score for { "In Stock": "true" }

Will receive lower score. The overall score will be a sum of the individual scores.

Previous'should' ClauseNextCandidate Generation and Metadata Filtering

Last updated 10 months ago