Skip to main content

Metadata

Every entry in a store has two halves: a key (the vector) and a value. That value is the entry's metadata — a set of named fields describing it, stored in a StoreValue.

Where the vector captures meaning, metadata captures facts: who wrote it, what category it belongs to, when it was created, the original text or image. It's how you keep the human-readable context next to the vector.

[0.12, 0.98, …]Key🧾 Value — metadataFieldValueTypeauthor"Asimov"stringgenre"SciFi"stringtags"epic, space"stringcover‹image bytes›binary
Metadata is the entry's value — named fields describing it, used to filter and enrich results.

Fields and values

Metadata is a map from field names to values:

Text
{ author: "Asimov", genre: "SciFi", tags: "epic, space" }
  • Field name — a label you choose (author, genre, category, …).
  • Value — the data for that field. Values can be text (raw_string) or binary such as an image (raw_binary).

You decide the shape of your metadata; Ahnlich doesn't impose a fixed schema on the fields inside a value.

What metadata is for

Metadata earns its place in three ways:

  1. Context on results — search returns the vector and its metadata, so you get back the author, title, or original text — not just an opaque list of numbers.
  2. Filtering — select entries by their fields with Get by predicate (e.g. every entry where author = "Asimov"). A predicate is simply a condition over metadata; see the predicates reference for the full grammar.
  3. Narrowing similarity search — pass a predicate as the condition on Similarity search to rank only the vectors that also match the metadata — "nearest neighbours where genre = SciFi".
genre = SciFiTitlegenreDuneSciFiEmmaRomanceFoundationSciFiHamletDrama
A predicate is a condition over metadata — it selects the entries whose fields match.

Making metadata fast

Filtering scans metadata, which slows down on large stores. Tell Ahnlich which fields you filter on so it can index them:

An index turns a full scan into a direct lookup.