semantic_text — one-field semantic search

semantic_text — one-field semantic search #

Semantic search used to mean wiring two fields: a text field for the source, a dense_vector field with vector_options pointing back at it. The semantic_text field type collapses all of that into one declaration:

PUT /my-collection
{
  "schema": {
    "properties": {
      "body": {
        "type": "semantic_text",
        "service": "zai",
        "model": "GLM-4.6V",
        "dims": 3072
      }
    }
  }
}

From there everything derives. Writes carry plain text — the vector is embedded server-side at write time, in bulk and after partial updates alike. Search needs no field names and no vectors:

Vector query (kNN)

Vector query (kNN) #

Finds the k nearest neighbors of a query vector — similarity search over dense_vector / sparse_vector fields. The query vector can be supplied directly, or as natural-language text that the serving layer embeds with the field’s configured model (schema-driven semantic search).

How it works #

Execution depends on where the documents live:

• Realtime (not yet flushed) — an exact brute-force scan over the mutable store: every vector is scored, a size-k min-heap keeps the best, and a filter (see below) is tested before any distance is computed.
• Flushed segments — the field’s index_type decides: flat scans the stored f32 vectors (exact, O(N·dims)); the graph types (hnsw_flat, turbo_quant_hnsw, bbq_hnsw) traverse the persisted HNSW graph with distances computed on the flat vectors — scores stay exact and only an ef-bounded neighborhood is evaluated; the quantized scans (turbo_quant, bbq_flat) score compact codes for a k × oversampling candidate pool and rescore it with full precision (approximate). The per-type breakdown is in Index types.

Scores follow the field’s similarity (overridable per query, but it must match the schema): cosine is the cosine similarity in [-1.0, 1.0]; dot_product the raw dot product; l2 scores as the negated squared Euclidean distance — 0 means identical vectors. Higher is always more similar, so one top-k heap serves all three.

Semantic query

Semantic query #

Semantic search with zero field knowledge: the vector field and the embedding model resolve from the collection schema, and the request is plain text — the retrieval question asked without naming a field, a model, or a vector.

Examples #

POST /my-collection/_search
{"query": {"semantic": "find documents about search engines"}}

The clause composes inside bool like any other leaf — the text is embedded and the clause rewritten before execution: