Panel discussion

Building Search for the Modern Age

A Vespa.ai Live panel on conversational, multimodal, and agentic search, covering personalization, evaluation, hybrid retrieval, and modern search architecture.
Ravindra Harige·Vespa.ai Live·10 September 2026·London, United Kingdom

Resources

Watch the recording

Written version

At Vespa.ai Live in London, Charlie Hull moderated a discussion with Jon Bratseth of Vespa.ai, Andrius Jokubauskas of Vinted, Atita Arora, and Ravindra Harige of Searchplex. This is a lightly edited version of the panel: the original questions, answers, and speaker attribution are retained, while greetings, repetition, and conversational filler have been removed.

Andrius Jokubauskas, Atita Arora, Jon Bratseth, Charlie Hull, and Ravindra Harige discussing Building Search for the Modern Age at Vespa.ai Live in London.

Introductions

Charlie Hull: Briefly introduce yourselves.

Andrius Jokubauskas: I'm from Vinted and work in the search team. My colleagues work on relevance, and I'm here to ruin it with all my promotions, business objectives, and so on.

Atita Arora: I have worked in search and information retrieval for the last two decades. I'm a PMC member of Apache OpenNLP and continue my work in search.

Jon Bratseth: I'm the CEO of Vespa. I was the architect of the platform during the 20 years we spent building it inside Yahoo before I became CEO. I still work technically, at least after business hours every day.

Ravindra Harige: I'm the founder of Searchplex, a search and retrieval consulting company. I have worked on search for more than 10 years, building solutions for different verticals and industries. I have used different stacks along the way—from Lucene to Solr, Elasticsearch, and more recently Vespa.

What is different about search today?

Charlie Hull: How have users and queries changed from a few years ago?

Atita Arora: Search has changed significantly from the query perspective. We have moved from token or keyword searches to phrases, sentences, and now almost to a conversation.

There is also a much greater sense of context. Before retrieving or giving an answer to a query—which may now be part of a conversation—you may have to retrieve context from several applications. That was not present before.

Another major difference is modality. Apart from text search, we have moved toward voice, video, and image search.

Ravindra Harige: The evolution of search is largely driven by what users have been exposed to. ChatGPT showed that you can interact with information conversationally, and Perplexity was an early entrant in bringing that experience into search. That is mostly the consumer-facing side.

Another change is who is searching. It is not only humans anymore; agents increasingly query search systems too. I see it as a two-part change: the interaction model has changed, and the consumer of search is changing.

There is an important qualification. It depends heavily on the vertical. In some areas, search has not changed nearly as much and can be quite resistant to change. Patent search and financial search are examples where keywords and Boolean search still rule. Those areas will not necessarily change drastically just because consumer search has.

Andrius Jokubauskas: If we are talking specifically about queries at Vinted, they are not changing that much yet. I think we are still on the verge of that transformation.

What I do see is that users are becoming more demanding of search systems. Improvements happen more rapidly now. Once users see one system that is substantially better, they begin expecting that level everywhere and become more willing to switch systems. That can benefit startups and new businesses, and it also applies when we expand into new markets. People feel the improvements in recommendation and search systems, then expect everyone else to remain at the leading edge.

Jon Bratseth: When we started, everything was keyword-based. OR search was too costly, so you essentially had to match all the keywords.

Most changes before large language models were driven by Google changing people's expectations: first toward OR-style search, and then toward typing whatever comes to mind and expecting the system to figure it out.

That works reasonably well because search is also personalized. For a typical consumer query, you often do not have to specify exactly what you mean. From your context, location, and other information, the system can mostly figure it out. A keyword might refer to both a famous band and a nearby café, for example, and the system will usually guess correctly.

People therefore do not need to type as much information to get what they want. That is particularly important on mobile phones, where input contains typos and approximations. Personalization and contextual interpretation are at the heart of modern consumer search.

What must a modern search platform handle?

Charlie Hull: Is the defining requirement scale, flexibility, speed, or something else?

Ravindra Harige: Search today should be viewed as a composition of multiple subsystems. You have query understanding, different representations and retrieval approaches—lexical, semantic, and even multi-vector—and then ranking and reranking.

Each subsystem has its own inputs and outputs. A modern search engine should expose those inputs and outputs and give developers enough levers across the layers. That gives agents, and developers generally, the ability to try different things and build a better experience for humans as well as agents.

Atita Arora: Most modern platforms already optimize for speed and scale. One thing I think they are missing is evaluation. Evaluation has always been fundamental to search, and with agentic search it has become even more important. Modern search platforms need to optimize for it.

Andrius Jokubauskas: The bar is very high. Embeddings, hybrid search, and many other capabilities are already expected. The questions then become: how good are you at personalization, and how well can you scale to cover more documents?

Our users at Vinted are very quick to buy things. We ran experiments that delayed certain behavior by even one hour for business reasons, and engagement decreased. If something that should have sold in the first hour does not sell, users are already unhappy. People are highly engaged in these systems and have high expectations. Freshness and responsiveness matter.

Jon Bratseth: The one thing a modern platform needs to handle is the combination of scale, quality, and performance. Optimizing one of them can be difficult, but delivering all three simultaneously is much harder.

When people talk about scale, they usually mean data volume and query volume. There is a third dimension: complexity. A solution may start simply, but the platform must support the team as it grows into more use cases, runs many experiments in parallel, adds more developers, and perhaps has both people and agents working with the system.

You want abstractions that scale gracefully. They should let you start simply without hitting a wall when you need more complicated behavior, parallel experiments, or additional control. Great solutions are not always simple, so ease of use cannot mean hiding everything that matters.

What do search platforms still struggle with?

Charlie Hull: Where are today's search platforms still falling short?

Jon Bratseth: Modern engines such as Vespa have most of the basic capabilities covered. Progress is no longer about doing one big thing that suddenly makes everything ten times better.

It is more like an industrial problem: improving in many directions at the same time. You simplify things, automate things, and gradually move abstractions upward without moving them so far that people lose the control they need. It is continual improvement across many fronts rather than one missing feature that fixes everything.

Atita Arora: From both the product and implementation perspectives, search engines lag behind the speed of innovation. So many theories, models, and techniques appear that platforms struggle to support them quickly enough.

ColPali is one example. It changed how we could handle multimodal data, especially images, and addressed an important enterprise-content problem. But by the time one technique is implemented, better methods may already be available for the same problem. It feels like a never-ending race between innovation and implementation.

Andrius Jokubauskas: Many of these systems are already powerful. As the same methods become available across platforms, my choice comes down to two things: flexibility—how many techniques I can try, choose, and combine—and how easy they are to use.

The number of available features can be overwhelming. You might decide to start with semantic search and discover that even this involves a lot. I would like abstractions to move upward far enough that simpler use cases can begin with a good baseline search system while retaining the flexibility underneath it.

Ravindra Harige: Different search engines started with particular architectural beliefs. We have keyword-first engines and many vector-first engines, each optimized for different workloads.

Where we are landing is closer to what Jon described: we need multiple capabilities within the same engine, and developers need access to them so they can support different workloads. Today's workloads differ significantly from those of 10 years ago. Providing that flexibility while performing gracefully and efficiently is difficult, especially when the underlying architecture is heavily skewed toward one class of workload.

What will search teams be discussing in twelve months?

Charlie Hull: Will agents still dominate the discussion, or will attention move elsewhere?

Andrius Jokubauskas: Today, each of us is fighting inside our own product to give users the best relevance possible. Eventually, we may converge toward agents that use information from across the world to provide results.

At that point, platforms may start competing with other platforms for ranking positions inside those agents. We may need separate APIs or search interfaces that agents can use, and the system providing the best result may be the one those agents choose. You could call it “agent SEO.” Businesses will have to think about how their information and products are discovered and ranked by agents, not only by users visiting their search interface directly.

Jon Bratseth: Hopefully we will still be talking about agents. The word agent is used too loosely today because we are jumping the gun. An agent acts in the world, while much of what we currently call an agent is an LLM harnessed with a loop. Some of it could still be called deep research rather than agency.

The real endgame is software that can act, although today's systems generally should not have unrestricted access to production databases, bank accounts, and similar systems. Another concern is what happens as agents increasingly cooperate with other agents rather than people. Hopefully we are still discussing agents in a year; the alternative may be that we are discussing swarms.

Ravindra Harige: Semantic search and hybrid search have been part of the conversation for at least two years, yet I still see customers struggling with hybrid search in production. I have relatively little hope that everything will change drastically within 12 months. We will probably still be working on scaling and getting hybrid search right in production.

Looking further ahead, we may move from reactive search toward proactive search. Today I have a need, I search, and engines compete to provide an answer. But consider how ChatGPT can remember the things I have discussed over several months. At some point a system might say: “You are travelling to London. You probably need these things. Here are the products—approve them and I will arrange delivery.” The system begins anticipating the information or products you need instead of waiting for you to formulate a search.

Atita Arora: When vector search first became popular, everybody discussed it. Now it has become much more commoditized. Even many non-technical founders understand semantic and natural-language search. Something similar may happen with agents.

The discussion may stop being “this uses an agent” and become “that agent retrieves terrible data; let us fix the retrieval so it has the right documents.” Attention will return to the fundamentals. People can create multiple agents and models, but none of them work seamlessly unless the foundation underneath them is sound.

Can search systems support physical AI?

Charlie Hull: Robotics and autonomous systems continuously produce data from many sensors. Can search systems handle those volumes, dimensions, and time ranges?

Jon Bratseth: We do not yet have a broad view on physical AI because it has been outside our immediate horizon. One exception is self-driving cars, where we have some experience using Vespa.

These systems often need the ability to represent data as higher-rank tensors and then index, search, and transform those tensors. Efficiently indexing higher-dimensional tensors remains interesting work because it may not be solvable in one universal way. One direction is for the application to provide the tensor and describe which transformations must be fast. The engine can then build indexes designed for those transformations.

Atita Arora: This feels like exactly the right kind of case for tensors. Robotics captures data from many perspectives. When I tried a Waymo self-driving car, it was striking to see how many cameras and systems operated simultaneously and to consider how the system balances those perspectives. Tensors can represent those multiple dimensions of information and support changing the next action based on the surroundings.

Additional technical response: Some related patterns have existed for a long time. Vespa has tensor-based storage for numerical information, but it also has streaming search, which can organize and search large amounts of data in a per-entity context.

Yahoo Mail was given as an example: millions of users, with each user's email stored and searched within that user's context. The response also noted that Vespa can work with data on disk, in memory, or in a combination of both, which may be useful for high-volume, entity-oriented workloads.

Charlie Hull: Based on the discussion, what should practitioners expect next?

Andrius Jokubauskas: I am a little more positive than some of the other panelists. We do not have the resources that OpenAI has today, and probably will not within the next 12 months. I think we will still be using BM25 in 12 months. The future is interesting, to say the least.

Jon Bratseth: We are moving into what sounds like a “world of abundance”—the precise wording was partly unclear in the transcript. That connects to Ravi's point about proactive search.

One thing still in short supply is agency. Proactive search begins to address that. Why should I have to think about what is good for me and what I should do? That could become a service provided to me. The next challenge for people working on search may be systems that anticipate useful choices instead of requiring the user to select everything manually.

Atita Arora: Different sets of innovation are happening in different communities. One is developing around vector search, while another comes from the Solr and Lucene search community.

I would like to see those communities come together. People have solved extremely complicated search problems over many years with established technologies, and we now also have newer techniques. Combining those worlds could be powerful: deep traditional search expertise alongside newer methods.

Ravindra Harige: Two things will continue to be true in the near future. First, BM25 will still rule for the most part. It generalizes well across the board, so I am curious to see what genuinely succeeds in competing with it.

Second, there is justified enthusiasm around the capabilities of large language models, but using large models extensively is not practical for most people or companies. A direction that may develop more naturally is smaller models specialized for particular tasks, with search engines becoming more accommodating and able to work with those models across different layers of the search stack.

Next steps

Explore the technical foundation behind modern retrieval systems

Searchplex's retrieval foundation explains the roles of content preparation, retrieval, ranking, evaluation, and operations in production search.

See also

Conference talk

Patterns from Shipped Migrations

Practical patterns from shipped migrations to Vespa, covering schema design, query logic, ranking, validation, and migration automation.
Conference talk

The Three-Body Problem of Inverse Hybrid Search

A practical case study of migrating Elasticsearch Percolator to Vespa to power image-search alerts, combining vector similarity, boolean filters, and fetch-all retrieval at production scale.