Unexpected Behavior with Field-Scoped Queries on Non-Searchable ID Field

Summary

I'm implementing a hybrid search solution where I calculate vector similarity scores separately (using a chunks index) and need to apply these as per-document boost values to my main search index. When I attempt to apply these boosts using field-scoped Lucene syntax on the id field (the key field), the document ranking changes unexpectedly in ways that don't align with the boost values I'm applying.

The core issue: My text search query returns documents in the correct order based on content relevance. However, when I add field-scoped ID boost clauses like (id:753100^2.2 OR id:752506^2.2 OR ...) to apply my externally-calculated vector boost scores, the document order flips unexpectedly.

Expected behavior: I expect each document to have a standardized base search score that I can then multiply by my boost values. If two documents both receive the same boost multiplier (e.g., ^2.2), their relative ranking should remain unchanged.

Actual behavior: Documents with identical boost values change their relative ranking, suggesting Azure Search is not applying boosts in a predictable, multiplicative manner.

Index Name

dev_sharath_nataraj_articles_v4

Index Configuration

Field: id Type: Edm.String Key: true Searchable: false ❌ Filterable: true Retrievable: true Sortable: true

Other Searchable Fields: title (searchable) contentPlainText (searchable)

Scoring Profile: Name: timeDecay Type: Freshness function on publishedDate field Boost: 50 Interpolation: Logarithmic

Observed Behavior

Step 1: Text Search Works Correctly

This text search query returns documents in the expected order based on content relevance:

{
  "search": "((title:us^1.5 OR contentPlainText:us) AND (title:seafood~1^1.5 OR contentPlainText:seafood~1) AND (title:market~1^1.5 OR contentPlainText:market~1) AND (title:update~1^1.5 OR contentPlainText:update~1))^1",
  "select": "id,title,publishedAt",
  "filter": "id eq '752506' or id eq '753100'",
  "queryType": "full",
  "searchMode": "all",
  "scoringProfile": "timeDecay",
  "top": 15
}

Results:

{
  "value": [
    {
      "@search.score": 553.4935,
      "id": "753100",
      "publishedAt": "2025-11-20T22:11:17.277Z",
      "title": "US Seafood Market Update"
    },
    {
      "@search.score": 487.40683,
      "id": "752506",
      "publishedAt": "2025-11-18T22:21:49.127Z",
      "title": "US Seafood Market Update"
    }
  ]
}

✅ Document order: 753100 (553.49) scores higher than 752506 (487.41) - this is correct based on text matching

Step 2: Adding Vector Boosts Causes Unexpected Order Flip

Context: I calculate vector similarity scores separately using a chunks index. Based on these vector scores, I want to boost specific documents. In this example:

Document 753100 should receive a boost of ^2.2

Document 752506 should receive a boost of ^2.2

Approximately 200 other documents also receive various boost values

I add these boosts using field-scoped syntax on the id field:

{
  "search": "((title:us^1.5 OR contentPlainText:us) AND (title:seafood~1^1.5 OR contentPlainText:seafood~1) AND (title:market~1^1.5 OR contentPlainText:market~1) AND (title:update~1^1.5 OR contentPlainText:update~1))^1 OR (id:757511^2.2 OR id:755664^2.2 OR id:755376^2.2 OR id:753100^2.2 OR id:752506^2.2 OR id:751651^2.2 OR id:751318^2.2 OR ... approximately 200 IDs with their respective boost values ...)",
  "select": "id,title,publishedAt",
  "filter": "id eq '752506' or id eq '753100'",
  "queryType": "full",
  "searchMode": "all",
  "scoringProfile": "timeDecay",
  "top": 15
}

Results:

{
  "value": [
    {
      "@search.score": 1408.0555,
      "id": "752506",
      "publishedAt": "2025-11-18T22:21:49.127Z",
      "title": "US Seafood Market Update"
    },
    {
      "@search.score": 1406.3658,
      "id": "753100",
      "publishedAt": "2025-11-20T22:11:17.277Z",
      "title": "US Seafood Market Update"
    }
  ]
}

❌ Document order: 752506 (1408.06) now scores higher than 753100 (1406.37) - ORDER FLIPPED

Analysis of the Problem

What I expected:

Document 753100 had original score: 553.49

Document 752506 had original score: 487.41

Both receive identical boost: ^2.2

Expected: Relative order should be preserved: 753100 * 2.2 > 752506 * 2.2

What actually happened:

After applying boosts, 752506 scores 1408.06

After applying boosts, 753100 scores 1406.37

The document that scored LOWER originally now scores HIGHER

This suggests boosts are not being applied multiplicatively to a base score.

Key observations:

Both documents received identical boost values (^2.2) in my query

The original text search clearly preferred 753100 (553.49 vs 487.41)

After adding boosts, the order reversed despite identical boost multipliers

Scores increased dramatically (from ~500 to ~1400)

The difference between published dates (Nov 18 vs Nov 20) affects the freshness scoring profile, but this alone doesn't explain the ranking flip

Questions

Question 1: Is using field-scoped queries on non-searchable fields supported?

The documentation states: "The field specified in fieldName:searchExpression must be a searchable field"

However:

My query with (id:753100^2.2 OR ...) does NOT throw an error (unlike boolean non-searchable fields which throw: "Illegal arguments in query request: [field] is not a searchable field")

The query executes and returns results, but with unpredictable scoring behavior

There is no documentation explaining what happens when this requirement is violated for string fields

Question: Is this supported or unsupported behavior? If unsupported, why doesn't it throw an error?

Question 2: What is Azure Search actually doing with field-scoped queries on non-searchable ID fields?

When I include (id:753100^2.2 OR id:752506^2.2 OR ...) in my query:

Is it searching for the literal ID values as text in my searchable fields (title, contentPlainText)?

Is it applying the boost values (^2.2)? If so, how and to what base score?

Why do documents with identical boost values change their relative ranking?

Why don't the boosts behave multiplicatively as expected?

Question 3: What provides the "base score" for boosting in Azure Search?

For term boosting to work predictably, there needs to be a consistent base score per document that can be multiplied by the boost factor.

When I use (id:753100^2.2), what base score is being boosted?

Is the base score from the text search portion of the query?

Is the base score from the scoring profile alone?

Why would two documents with identical boosts have their ranking order reverse?

Question 4: What is the recommended approach for applying externally-calculated per-document boost scores?