Welcome to the latest edition of the Vespa newsletter. In the previous update, we announced Vespa Cloud operability features like Backup and Dashboards together with new Matching and Ranking features, and more.

This month, we’re shipping updates that give you time-constrained ANN search, sub-query ranking support, flexible provisioning, new rank features and telemetry export.

Let’s dive into what’s new.

Calling All Vespians: Vespa.ai Live Has Landed

As more teams build with Vespa, bringing the community closer together has become a major focus for us. Earlier this year, we ran our first virtual meetups, extending our Slack community and were joined by more than 100 Vespians from around the world - from the US and Ukraine to Singapore, Australia, Kazakhstan, Egypt, and beyond. But while virtual events are great, nothing quite compares to meeting in person - learning from peers, exchanging ideas, and continuing the conversation over coffee, beer, or wine. That’s why we’re excited to announce our first in-person community meetup: Vespa.ai Live!

Vespa.ai Live brings together the engineers, architects, researchers, and practitioners building modern retrieval and ranking systems. The event includes technical sessions, real-world user stories, expert panels, interactive unconference discussions, and plenty of opportunities to connect with others building in this space. Leading authors Trey Grainger and Doug Turnbull will also be in the lineup, sharing their perspectives on where the industry is heading. Optional pre-event training the day before includes beginner and advanced tracks to help attendees sharpen their Vespa skills before the main event.

Most of all, Vespa.ai Live is intended to be community-driven - where Vespians share lessons learned and boldly go beyond the frontier of modern search.

Learn more about Vespa Live!

Product updates

Meet latency targets more easily with time-bounded vector search

The standard HNSW algorithm for vector search explores the graph to find the closest vector matches, using exploration parameters like targetHits and filterFirstExploration to determine how extensively it searches. You often need to tune these parameters to achieve a particular latency budget, which can be challenging.

What’s new: Vespa now provides a simpler alternative where you set the latency budget and let the algorithm find the best matches within that time and then return.

To use it, set the new ranking.matching.anntimebudget query parameter to the amount of time you want to allow for ANN search. Vespa will stop searching when it reaches that limit, eliminating the need to tune exploration parameters to indirectly meet a latency target.

Pro-tip: Use the new query_approximate_nns_time metric to track the time spent on ANN. Because this metric only counts queries that actually perform ANN searches, its count dimension gives you the precise number of queries that performed ANN searches! This way, you can monitor how many queries actually perform ANN searches and how many fall back to an exact search.

Keep clusters scaling when cloud providers’ capacity is limited with max-cost-factor

In Vespa Cloud, resource specifications configure settings like vCPU, memory and disk for a cluster. Example:

<resources vcpu="32" memory="64Gb" disk="1900Gb">

Cloud providers may not always have the instance types needed to match your resource specifications. When the required resources are unavailable, Vespa isn’t able to add the necessary capacity, which blocks deployment and autoscaling.

What’s new: Vespa Cloud now lets you prioritize availability over cost when your preferred instance type isn’t available. With the new max-cost-factor setting, you can configure Vespa to select larger instance types that meet your resource requirements instead of blocking cluster re-scaling.

E.g., with a max-cost-factor=2, an instance like

<resources vcpu="64" memory="128Gb" disk="3800Gb">

matches the specification in the first example.

Note that auto migration to optimal instance types is enabled by default in Vespa Cloud for all applications, and runs in the maintenance window only, for off-peak configuration. This continuously migrates workloads to higher-performance nodes for a better cost/performance ratio, and automates the chore of optimizing your resource pool. So even if you have temporarily provisioned an oversized instance due to low availability, Vespa Cloud will move you back to the most cost efficient instance type when available.

Gain more control over how query signals affect ranking with labels

Not all parts of a query should contribute equally to ranking. Labels give you a way to identify those parts and score them independently. For example, you might want to add a smaller rank contribution for alternative forms. Labeling the parts lets you do this, and use the values in BM25 scoring, or in a general ranking expression using the raw scores.

What’s new: Vespa gives you more control over how each part of a query affects ranking. You can score BM25 for specific labeled terms, get separate BM25 scores per query-item label, or assign scores to labeled subqueries and use those scores in a ranking expression.

Scoring labeled parts of the query - bm25(field: name, label: label)

bm25(content) sums the contribution of every query term searching content. When a query is built from several parts, it is often useful to score those parts separately. This is done by attaching a label to the query items, using the YQL label annotation, and referring to that label from the rank profile:

select * from example where
  ({label:"must"}content contains "vespa") and
  ({label:"nice"}(content contains "ranking" or content contains "relevance"))

A label set on an operator enclosing others, as on the or above, is inherited by every term inside it, so a label can be given per clause instead of per term. The bm25(field: fieldname, label: label) rank feature scores only the terms carrying the given label:

rank-profile labeled {
  first-phase {
    expression: bm25(field: content, label: must) + 0.5 * bm25(field: content, label: nice)
  }
}

Since Vespa 8.738. Read more.

Scoring labeled parts of the query - bm25_for_labels(name)

Return a tensor<float>(label{}) holding one BM25 score per query item label in the indexed string field name. Each cell is labeled with the query item label and holds the sum of the BM25 scores of that label’s terms in name. This makes it possible to rank on the labeled parts of the query individually without adding one bm25(field, label) feature per label. A label gets a cell only if it actually scores, that is when at least one term carrying it searches name and matches the document.

Since Vespa 8.738. Read more.

The labeled() query operator - itemRawScore

Using labeled(subQuery, “mylabel”, 4.25) wraps an arbitrary sub-query with a label “mylabel” and score. If the sub-query matches a document, the score (4.25 in this example) can be picked up by ranking expressions using the itemRawScore rank feature. Typically used together with the rank operator:

where rank(title contains "running shoes",
  labeled(memberDiscountPercent >= 20 AND inStock > 0, "memberDiscount", 2.0),
  labeled(premiumBrand = true OR todaysFeaturedBrand = true, "premiumOrFeaturedBrand", 1.0))

A ranking profile example using the scores:

expression: bm25(title) + itemRawScore(memberDiscount) + 31.5 * itemRawScore(premiumOrFeaturedBrand)

This is similar to Lucene’s ConstantScoreQuery, often used in Elasticsearch/OpenSearch through function_score, or in Solr with ^= query syntax.

Since Vespa 8.748.3. Read more.

Build and debug custom ranking with more flexibility through new rank features

Building sophisticated ranking functions often requires working with data that isn’t readily available in the form you need, whether that means connecting values across parallel arrays or accessing the collection statistics used by text ranking algorithms like BM25.

What’s New: Vespa now has three new rank features:

• tensorFromLabelsWithOffset: constructs a tensor from an array attribute while preserving array positions. That tensor can then be used in ranking calculations.
• averageFieldLength: gives you the average length of an indexed field, which BM25 uses to normalize scores, so you can use it for debugging or custom text ranking formulas.
• queryTermDocumentFrequency: exposes the number of documents that contain each query term, which BM25 uses to calculate IDF, so you can use it for debugging or in custom ranking formulas.

These features give you more flexibility to work with structured data, understand how ranking scores are calculated, and build custom ranking logic.

tensorFromLabelsWithOffset

Creates a tensor<float> with one mapped dimension with labels from the given array attribute, and another mapped dimension where labels are constructed from the array index (offset) of that label. The cell values of the tensor are always 1.0 (suitable for multiplication). The attribute values must be integers or strings. The attribute is specified as the full feature name, attribute(name). The label-dimension parameter is required, using the same as the attribute name is common. The offset-dimension will get label value “0”, “1” and so on. This feature may be useful if there are several arrays populated in parallel, and the array index of a label is needed in order to correlate with a different array. Example: Given an attribute field myField containing the array value:

[v1, v2, v3]

tensorFromLabelsWithOffset(attribute(myField), dim, off) produces:

tensor<float>(dim{},off{}):{ {dim:v1,off:0}:1.0, {dim:v2,off:1}:1.0, {dim:v3,off:2}:1.0 }

averageFieldLength

The average length, in number of terms, of the indexed field name, as computed from the local content node index (in memory or on disk). This is the same index statistic that BM25 uses by default for field length normalization (the avg_field_len term), exposed here so it can be used for debugging and in custom text ranking formulas such as Bayesian BM25.

queryTermDocumentFrequency

A tensor<double>(term{}) holding the document frequency that BM25 would use for each query term that searches the index field name. The document frequency is the number of documents that contain the term; it is the input to the inverse document frequency (IDF) component of BM25. This feature is exposed for debugging and for use in custom text ranking formulas such as BM25F or Bayesian BM25.

Example: for a query where term 0 and term 2 search the content field (term 1 searches a different field), queryTermDocumentFrequency(content) is:

tensor<double>(term{}):{ {term:0}:1200.0, {term:2}:57.0 }

See the reference.

Represent more complex structured data in tensors with tensorFromStructs

When converting structured attribute data into tensors, you may need to represent values across more than one dimension.

What’s new: tensorFromStructs now supports multiple mapped dimensions, letting you use multiple fields as keys to represent these relationships in a tensor.

For example, use:

tensorFromStructs(attribute(items), name, region, price, float)

to get a tensor<float>(name{},region{}) for different prices in different regions.

This function lets you represent more complex relationships in structured data directly as tensors for use in ranking.

Send Vespa telemetry directly to your observability tools with telemetry export

Telemetry export lets you ship your application’s metrics and logs from Vespa Cloud directly to your own observability backend via standard OpenTelemetry export - a fully self-service, push-based alternative to the pull-based Prometheus metrics API. You declare one or more exporters in services.xml; Vespa Cloud then pushes the selected metrics and logs you configure to the backend(s) you configure, authenticated with credentials from your vault. Configure your vault and secrets using the Vespa secret store, grant infrastructure access, add the telemetry exporter configuration, deploy, and telemetry starts flowing in minutes.

Telemetry export is available for Vespa Cloud Enclave only.

Simplify search across Chinese language variants through Asia linguistics sample apps

Vespa offers several ways to handle Chinese text — Simplified, Traditional, and the mix you typically see across zh-CN, zh-TW, and zh-HK markets. linguistics-asia compares those options side by side. It ships eight runnable sub-applications — one per integration shape — over the same dataset and the same five compare-queries, so the trade-offs are observable, not just theoretical. The basic idea is to provide a complete solution for CJK characters / terms support, and how Vespa can handle different cases with minimal custom code / logic implementation.

Other new features

Documentid indexing expression: Allows using the documentid or parts of it in the indexing language, like documentid [part] - potential uses:

• Enabling searching over parts of the document ID, e.g. namespace. Removes the need to send the value explicitly, or writing a custom document processor.
• Creating a stable and properly randomized hash value to be used as a tie-breaker for iterating over many documents.

See the reference and examples. Many thanks to Dainius Jocas (@dainiusjocas) for the contribution!

Disk size re-sampling: For users of the Vespa Enterprise Image / Vespa OSS. For environments when the disk size can change dynamically, the proton process now re-checks the disk space. The (free) size is used to block writes when the disk is close to full.,

Optimized chunked Hamming MaxSim: The existing SumMaxInvHammingFunction optimizer introduced in #32320 recognizes Hamming MaxSim over a 2D document tensor. This change adds the corresponding 3D optimizer:

query:    tensor<int8>(qt{},x[N])
document: tensor<int8>(chunk{},t{},x[N])
max(chunk, sum(qt, max(t, 1 / (1 + sum(x, hamming(query, document))))))

Many thanks to Oskari Mantere (@oskrim) for the contribution!

What’s New on YouTube

• Simplifying Your Chunking Strategy (Short video)
• The Vespa Kubernetes Operator: A Better Way to Run Vespa on K8s (Short video)
• Tensor-Native Retrieval and Ranking, Explained (Short video)
• Vespa Now: Q2 Product Update ( Webinar)
• Vespa Operator Demo

Find more videos in the @vespaai channel.

Blogs and ebooks

• Re-autoresearching MSMARCO BM25, on Vespa
• The Human Context Advantage: Takeaways from the Ai4 Keynote with Andrew Ng, Geoffrey Hinton, and Fei-Fei Li
• Your agent wants to search like a 2010 quant

Upcoming events

Vespa.ai Live: London, 9 - 10 September

Join the Vespa and retrieval community in London for a full day dedicated to building better AI search and retrieval systems. The event brings together engineers, developers, and AI practitioners to share ideas, learn from real-world deployments, and connect with others shaping the future of AI-powered search.

Learn more about Vespa Live!

it DAGENE: Trondheim, 14 September

Vespa.ai will be attending itDAGENE 2026 at Realfagbygget, NTNU in Trondheim. The event brings IT students and businesses together for two days of company stands, professional sessions, and meaningful conversations about careers and technology.

Shoptalk Fall: Nashville, 29 September - 1 October

Vespa.ai is heading to Shoptalk Fall, the essential H2 event for retail leaders shaping what comes next. Join thousands of retail changemakers in Nashville to exchange ideas, build valuable connections, and explore the innovations helping businesses stay ahead in a fast-moving retail landscape.

👉 Follow us on LinkedIn to stay in the loop on upcoming events, blog posts, and announcements.

Thanks for joining us in exploring the frontiers of AI with Vespa. Ready to take your projects to the next level? Deploy your application for free on Vespa Cloud today.