Time to Celebrate! First Place in Vector Search at the SISAP 2026 Indexing Challenge

Search is the part of our platform that everything else leans on, so the index behind it is never finished. We keep looking for ways to make it answer faster, stay accurate on harder data, and hold up while a catalog changes underneath it. Some of that work happens on customer data. The rest happens in the open, in the research community that works on the same problem. That community has a meeting point: SISAP, the International Conference on Similarity Search and Applications, which has brought this field together every year for nineteen years and meets in Brno this October.

A Conference About One Question

The question is easy to state and hard to answer: given a large collection and one item, find the entries most similar to it without comparing against all of them. It is how a photo archive finds pictures that look alike and how a shop finds products that belong together, and it is the same question that sits under every vector database, every recommendation engine, and every chatbot that looks something up before it answers. Everything at SISAP follows from it, from the theory down to systems that have to answer in milliseconds.

A good deal of what the industry runs on today started in that room. Graph indexes dominate vector search, and the line that produced the one almost all of them use, HNSW, starts with a paper Yury Malkov and colleagues presented at SISAP in 2012; he gave the 2023 keynote on how it spread from there. The year after, the keynote came from Piotr Indyk of MIT, who shares the Kanellakis Award for locality-sensitive hashing, which is the other classic answer to the same question. And the people who have to run all of it at scale bring back what they learn: Sanjiv Kumar, Google Fellow and VP at Google Research, was on the same programme, Facebook’s search team in an earlier year.

The Indexing Challenge

Since 2023 the conference has not only discussed indexes but measured them. Its Indexing Challenge runs the systems of research groups and companies on the same data, under the same conditions, and publishes the results next to each other. Every task also sets a minimum accuracy that an entry has to reach before its time is counted at all, so nobody can buy speed by returning worse answers.

The entrants come from four continents — Europe, North and South America, Asia — and from both sides of the field, universities and industrial labs. The submission that won the construction task came from the University of Maryland and Google Research: a university and an industry lab, the same mix behind both of our submissions.

Our Index came in First Place in the Vector Search Task Task 2 stores 256,921 vectors taken from inside Llama-3-8B and asks, for each query, for the 30 stored vectors with the largest inner product. The index is built once and then only answers, so only the time to answer is scored. We came first at 26,743 queries per second — more than two times faster than the second-placed submission and 5.4 times the organizers’ reference, in a field of eight teams.

Our index ranks by Euclidean distance rather than by inner product, and on these unnormalized vectors the two disagree. Putting the problem back into the geometry our index is built for, and then laying the vectors out for the memory system, is what produced the gap — the long version is a different geometry, and a better memory layout. (We will publish a dedicated blog article with the technical deep dive on the Vector Search task).

Our Index Ranked Third Place in Index Construction

Task 1 asks for the 15 nearest neighbors of every one of 6.4 million Wikipedia passages. Here the time to build the index counts toward the score as well, which makes construction most of the work. We finished third at 320 seconds, seven times faster than the organizers’ reference, in a field of fourteen teams that spans from 188 seconds to more than five hours.

The lever was to make a single distance computation eight times smaller while the graph is being built, and then to buy back the accuracy that costs with a reranking pass — the long version is two bits per dimension, and why we still rerank. (We will publish a dedicated blog article with the technical deep dive on the Indexing task, too.)

Focussing on Our Strengths: High-Dimensional Dense Embeddings

The third task searches 2.68 million documents of the Natural Questions collection, encoded with SPLADE-v3 into 30,522 sparse dimensions, of which about 223 carry a weight in a typical document. That asymmetry is what inverted indexes are built for: they keep one short list per dimension and never touch the empty cells. A proximity graph earns its advantage in the opposite case, when every dimension carries a signal, as in the dense embeddings we work with in our customers’ commerce catalog environments. So we left this task to the systems built for it.

Key Takeaways: Pushing the Boundaries of Search for Our Customers

The results speak for themselves: First place in the search task, and third where the index has to be built as well — against a field of specialists, every result produced under the same conditions and published side by side. We are proud of that, thanks to the whole team at vviinn and our research partners who continue to keep us positioned at the top of the field.

What we keep is how we got there: task 2 was a geometry problem, solved with a transformation and a memory layout rather than a new index; task 1 produced a quantization step that makes construction cheaper, exactly the cost that grows when a catalog grows; and passing on the third task was the same kind of decision, putting the effort where our customers’ data is. All three keep our platform fast and affordable as catalogs grow. Benchmarks are a fantastic proof; the real test is our customers’ own data, where the question is not who is fastest at the challenge’s accuracy bar but what a customer notices. Measuring these two changes against our own embeddings and our own metrics is our next step, and an upcoming post.

References

• Our submission paper: Hezel, Barthel, Schilling, Schall, Moelle and Jung, Fast and Efficient Approximate Nearest Neighbor Search for High-Dimensional LLM Embeddings (arXiv:2607.20957), with the full method and all measurements.

• Our code: Visual-Computing/sisap26-deglib, the submissions for both tasks.

• The challenge: SISAP 2026 Indexing Challenge, tasks and datasets, and the leaderboard with every team’s results.

• The index itself: our earlier post Dynamic Exploration Graph: Fast Search in Evolving Catalogs.

• The conference: SISAP 2026, the 19th International Conference on Similarity Search and Applications, Brno, 14–16 October 2026.