A support article has a title, body, screenshots, code snippets, and customer-ticket history. One embedding cannot represent all of that equally well. When every query hits the same vector, “reset MFA” and a screenshot of the MFA settings page compete inside one embedding space. Named vectors make the retrieval target explicit.

Short Version

Weaviate named vectors let one object carry multiple vector representations. A document can have a title vector, body vector, image vector, code vector, and support-ticket vector, each with its own configuration.

This improves retrieval control because the query can target the embedding space that matches intent. The tradeoff is schema and backfill complexity. Every new named vector is a new production data product: model choice, index settings, storage, backfill, monitoring, and query routing.

Situation

Many RAG systems flatten rich objects into chunks and embed everything the same way. That loses structure.

The Problem

  • Titles are short and navigational.
  • Bodies are explanatory.
  • Images need multimodal embeddings.
  • Code snippets need code-aware embeddings.
  • Support tickets reflect user language and symptoms.

If these representations are collapsed into one vector, retrieval becomes hard to control. A title-heavy query may retrieve a long body chunk. A code query may retrieve prose. An image query may be impossible. Can one object carry multiple embedding spaces without splitting the domain model apart?

How It Works

flowchart TD
    Object[support article object] --> Title[title vector]
    Object --> Body[body vector]
    Object --> Image[image vector]
    Object --> Code[code vector]
    Query[user query] --> Router[query intent router]
    Router --> Title
    Router --> Body
    Router --> Image
    Router --> Code
    Title --> Results[ranked objects]
    Body --> Results
    Image --> Results
    Code --> Results

Weaviate documentation describes collection vector configuration with multiple named vectors through vectorConfig, where each named vector can have its own vectorizer and index configuration. Exact client syntax (Python, TypeScript, or GraphQL) varies by client library version — confirm it against the deployed Weaviate version before writing collection-creation code, since named-vector configuration syntax has changed across major Weaviate releases.

Practical examples:

  • title_vector: navigational queries and known article names.
  • body_vector: conceptual or troubleshooting questions.
  • image_vector: screenshots, diagrams, product photos.
  • code_vector: stack traces, snippets, API examples.
  • ticket_vector: user symptom language from support cases.

The application query should specify which vector to target, or use a retrieval router that chooses.

Architecture and Operating Model

Schema design. Start with the object model. Decide what the object is: article, product, ticket, code example, policy document. Add named vectors only where they map to distinct retrieval intent.

Query routing. Named vectors are valuable only if queries target them intentionally. A query router can send “where is the reset button” to image or body vectors, while “MFA enrollment API error” may target code and body vectors.

Backfills. Adding a named vector to an existing collection requires embedding existing objects for that vector. That is a batch job with cost, latency, failure handling, and progress tracking.

Versioning. Each named vector should have model metadata. If body_vector moves to a new embedding model but title_vector does not, retrieval behavior changes unevenly.

Evaluation. Evaluate each vector space separately and in combination. A global “search quality improved” metric can hide a title regression or code regression.

In Practice

Named vectors are schema evolution. A database team would not add five large indexes without asking who owns them, how they are built, and how they are dropped. Treat named vectors the same way.

The platform should define:

  • Naming conventions.
  • Model ownership.
  • Backfill runbooks.
  • Storage and memory budgets.
  • Query routes that can use each vector.
  • Deletion and re-embedding behavior.
  • Rollback if a new vector space hurts relevance.

The dangerous pattern is “add one more vector” for every new feature. That creates invisible storage and operational cost.

Where It Breaks

Failure modeSymptomFix
Too many named vectorsStorage and query complexity growRequire a query use case for each vector
No routerQueries hit the wrong vector spaceAdd explicit target-vector routing
Backfill not plannedNew vector works only for new objectsTrack coverage before enabling
Model versions hiddenRelevance changes cannot be explainedStore model metadata
Object schema driftsVectors no longer match propertiesAdd schema review to ingestion changes

Security, Cost, Observability, and Failure Notes

Security applies at object and vector levels. If an image vector retrieves an object the user cannot see, the object filter must still block it. Named vectors do not replace authorization.

Cost grows linearly with additional embeddings and indexes, then again with backfills and query fanout. Multimodal embeddings (image, code) are typically priced differently from text embeddings by model providers — check current pricing from the specific provider before estimating a backfill budget, since per-token and per-image rates change independently of each other.

Observability should track vector coverage per named vector, backfill lag, query volume by target vector, latency by vector, empty-result rate, and relevance metrics by query class.

Failure modes include partially backfilled vectors, wrong query target, incompatible model dimensions, stale embeddings after object updates, and backup or migration procedures that miss vector-specific state.

Decision Checklist

  • Does the object have genuinely different retrieval surfaces?
  • Which user queries target each surface?
  • Is a separate named vector better than a separate collection?
  • Who owns the embedding model for each vector?
  • How will the backfill be throttled and monitored?
  • What happens when one vector model changes?
  • Are object-level filters applied after every vector search?
  • Is relevance measured per named vector?
  • Can a named vector be removed safely?

What to Do Next

Problem: Objects with genuinely different retrieval surfaces (title, body, image, code) get collapsed into one embedding, and queries retrieve the wrong kind of match because nothing distinguishes intent.

Solution: Add a named vector only where it maps to a distinct, nameable query route. Use them when query intent demands different embedding spaces; avoid them when one generic vector is sufficient or the team cannot operate the backfills and schema changes they imply.

Proof: Each named vector has a documented query route, a coverage metric showing backfill completeness, and a relevance measurement separate from the aggregate “search quality” metric.

Action: This week, for every existing or proposed named vector, write down the specific query route it serves — if no route can be named, treat the vector as speculative and do not ship it.

Operating Guardrails

Require a launch checklist for every new named vector. The checklist should include source properties, embedding model, vector dimension, target queries, backfill plan, coverage metric, query route, cost estimate, and rollback path. If the team cannot name the query route, the vector is probably speculative.

Keep object identity stable across vector changes. A named vector should improve how an object is found; it should not create a second object lifecycle. Deletes, tenant moves, source updates, and legal holds must apply to the object regardless of which vector retrieved it.

Prefer adding named vectors for durable retrieval modes, not temporary experiments. If a vector is only needed for a one-week evaluation, isolate it in a test collection or staging environment. Production named vectors should have monitoring and an owner.

That discipline prevents embedding experiments from becoming permanent indexes nobody budgets, validates, or knows how to remove.

Sources to Verify