Webinar

Vespa Now: 2026 Fall Product Update

In Vespa Now: Fall 2026 Product Update, we explore the latest capabilities for building and operating retrieval and ranking systems at scale.

See how to set explicit latency budgets for ANN search, gain finer control over ranking with labeled query terms and subqueries, and use new rank features to better understand and customize BM25. We’ll also cover new tensor capabilities, more resilient cloud provisioning, and OpenTelemetry-based telemetry export and more.

You asked, we answered

Thanks to everyone who joined us live and sent in questions. Here’s a roundup of what you wanted to know about this fall’s updates.
If I set an ANN time budget, how do I know whether a query was actually cut short?
Run the query with tracing enabled. The query trace shows whether the nearest neighbor search stopped because the time budget ran out.
I’m building RAG over long documents. Which of today’s features should I look at first?
Start with the RAG blueprint, which covers the core features for RAG applications. From this update, the most relevant are the chunked Hamming MaxSim optimization, which speeds up finding the best-matching chunk, and tensor_from_labels_with_offset, which lets you keep metadata (like the section a chunk came from) aligned with your chunks and use it in ranking.
View the RAG Blueprint
Is OpenTelemetry export available on all of Vespa Cloud, and does it replace the Prometheus API?
For now, it’s available on Vespa Cloud Enclave only. It doesn’t replace the Prometheus API, which still works. It adds a push option for sending metrics and logs to up to three backends.
Why would I hash the document ID instead of just sorting by it?
In the example, the hash is a tiebreaker: results still sort by timestamp, and the hash decides order only when timestamps match. That keeps results deterministic without biasing them toward the structure of the IDs. A 64-bit hash is also cheaper to sort on than a long ID string, and you can use it to bucket documents for A/B testing.
How is labeled different from adding a boost in my rank profile?
A traditional boost usually means storing boost terms in a separate document field and matching against it in your rank profile, which is still valid. With labeled, you define boost subexpressions directly in the query, based on existing fields, and weight or combine them however you like during ranking. It’s a more flexible way to boost.
What happens if a query has more than one nearest neighbor operator?
The query timeout is split across the operators, but the time budget isn’t: each nearest neighbor operator gets the full budget you specified.