Qdrant

And that’s a wrap of Vector Space Stream! 🎉 We spent 4+ hours going deep into vector search, from token-native storage and vector compression to robotics, new embedding geometries, dual encoders, adaptive hybrid search, billion-scale evaluation, and compute/storage separation. And we loved having you with us throughout the entire stream. Thank you to everyone who joined, asked questions, shared their thoughts, and stuck around for the whole thing. If you missed it live, the recording is now available: https://lnkd.in/ghPKegu7 And if you want to continue the conversations, ask questions, or dive deeper into any of the sessions, join our Discord community and let’s keep the discussion going, https://discord.gg/qdrant We’ll definitely try to do more streams like this. Thanks to our speakers: Kumar Shivendu Ivan Pleshkov Jonas Schulz Clelia Astra Bertelli Sasha Denisov Chadha Sridi John Kupchanko Matin Mahmood Dylan Couzon Andrey Vasnetsov Andrei Cristea Evgeniya Sukhodolskaya Seth Ockerman Nathan LeRoy and to our amazing host Neil Kanungo Until then, thanks for spending 4+ hours with us! 🫶

Let's dig deeper into some of the research topics the Qdrant team is looking at. We start with the 𝗦𝘂𝗽𝗲𝗿𝗽𝗼𝘄𝗲𝗿𝘀 𝗼𝗳 𝗛𝘆𝗽𝗲𝗿𝗯𝗼𝗹𝗶𝗰 𝗘𝗺𝗯𝗲𝗱𝗱𝗶𝗻𝗴𝘀. Nobody picks their embedding geometry. It comes bundled with the model, right? Most embeddings sit on a sphere, measured with cosine similarity, which breaks once your data is a tree, not a disk. Flat space grows as r^d. A tree grows exponentially, crowding deeper hierarchies together. Hyperbolic space doesn't have that problem. A 5-dim Poincaré embedding on WordNet achieved 0.823 MAP (mean average precision), compared to 0.168 for a 200-dim Euclidean embedding, using 40x fewer dimensions. On the Google Product Taxonomy, 5-dim Poincaré hit 0.905 MAP against 0.658 for 50-dim Euclidean. However, getting the embedding right is the easy half. Converting hyperbolic distance to an inner product and running it through HNSW dropped recall from 0.986 under brute-force to 0.020. Not a typo. Vector norms spread across a 600x range, and HNSW can't handle that. The fix: store the Poincaré coordinates as an ordinary vector, keep the squared norm in payload, prefetch with HNSW, then rescore with the hyperbolic distance via a Formula Query. => Recall 0.920 Full write-up: https://lnkd.in/dJczHBSW by John Kupchanko 🙌 Video stream https://lnkd.in/dpySMwPq with Matin Mahmood 👏

We do a lot of research at Qdrant: about embeddings, storage, quantization, and information retrieval in general. And we want to share our research topics with the community. Eight sessions today, eight actual engineering problems: ▪️Token Native Storage: cutting the tokenization overhead most storage engines never bothered to address. ▪️Vector Compression Stack: TurboQuant and the turbo4 data type, squeezing more vectors into less RAM without sacrificing recall. ▪️Robotic Reachy (by Hugging Face) & Qdrant.to/Edge: running vector search on the robot itself, not in a data center three hops away. ▪️New Geometries, New Embeddings: hyperbolic and spherical spaces instead of defaulting to Euclidean because that's what the library ships with. ▪️Zero-Compute Dual Encoders: asymmetric encoding built for hardware that doesn't have a GPU to spare. ▪️Autofusion for Adaptive Hybrid Search: picking a fusion strategy automatically instead of hand-tuning weights forever. ▪️Supernova: a framework for evaluating embeddings at a billion scale, where most benchmarks quietly stop being honest. ▪️Compute-Storage Separation: the infrastructure decision that determines whether your search bill scales with your data or your query volume. Vector Space lifestream: https://lnkd.in/dDGrHbBr

When financial search needs both meaning and precision, hybrid search becomes interesting. That’s the challenge Satyam Sahu explored in a recent project using Qdrant for financial intelligence. The system combines dense embeddings, BM25, and SPLADE to handle both semantic concepts and exact financial terminology, then uses RRF and reranking to improve the final results. The project works with 47 SEC filings from 10 technology companies, turning them into 8,609 contextual chunks. What’s interesting is the comparison between different retrieval approaches and seeing where each one works, and where it falls short. Read the full write-up: https://lnkd.in/gsZEjHYD

Your retrieval metrics can look flawless even while the agent confidently delivers incorrect information. In a test series with Future AGI, context relevance stood at 0.92 out of 1.00—yet 40% of the answers were wrong. The problem lay neither with the prompt nor with the model. The five results the agent read were largely copies of one another, supplemented by an outdated dataset. Repeated ingestion had increased the number of individual data points from 8,416 to 22,946. After deleting the 14,530 duplicates, the number of queries containing a duplicate in the top-5 results dropped from 36 to 2 (out of 37 total queries), and accuracy rose from 0.57 to 0.76. The model and prompts remained identical; the agent simply received five distinct text segments (chunks) rather than the same one repeated five times. Scaling doesn't cause this problem; it just makes you pay a heavy price. Even with a collection of just 1,314 data points, duplicates accounted for 44% of the top-5 slots. With 22,946 points, that figure hit 52%, while recall plummeted from 67% to 39%. The chunk utilization metric remained at 0.85 both before and after deduplication, even though accuracy shifted by 0.19. Five copies of the same chunk yield the same value as five distinct chunks; consequently, if this figure appears on your dashboard, it is merely window dressing. Full write-up, including why hybrid search improved every ranking metric and made the answers worse: https://lnkd.in/dQ8VV3ZF

A research agent that gets better from its own run history. At n8n in the loop 2026, Clelia Astra Bertelli, DevRel Engineer at Qdrant, will show how to build a self-healing research agent that learns from its own run history, without fine-tuning. The setup is simple: → The agent runs research and produces an answer. → A Discord user gives it a human verdict. → That verdict is stored back in the same vector store the agent retrieves from. → On the next run, the agent retrieves both past successes and failures to understand what worked and what didn’t. The same collection becomes the agent’s run history, evaluation set, and training signal, with the human in the loop acting as the writer. Date: October 13–14, 2026 Get your ticket now: https://n8n.io/intheloop/

The agenda for Vector Space Stream is now live. 8 technical talks. 4+ hours. One deep dive into what’s happening in vector search. On September 17, we’re bringing together Qdrant engineers, researchers, and community experts to explore some of the problems we’re working on across vector search. Here’s what’s on the agenda: → A Look into Token Native Storage: storing model token IDs instead of UTF-8 text, and what that means for storage and agent workloads by Kumar Shivendu → The Modern Vector Compression Stack: the research behind TurboQuant and `turbo4`, including applications to multivector search Ivan Pleshkov, Jonas Schulz, Clelia Astra Bertelli → Robotic Reachy and Qdrant Edge: giving a robot memory that runs entirely on its own hardware, without the cloud by Chadha Sridi, Sasha Denisov -> And more.. Please find the full agenda attached. Just research, engineering, experiments, and the problems behind building vector search at scale. Time: 10:00 AM ET / 7:00 AM PT / 4:00 PM CET Register here: https://lnkd.in/gEJZG-zJ

You upload a few millions of embeddings to a collection in your vector search engine, and suddenly your pod gets OOM-killed. So you switch vendors, but now your tail latency grows to seconds instead of the occasional 200ms you were seeing before. In both cases, you should ask yourself a simple question: "Where do my vectors live?" Qdrant, as of v1.19, has introduced memory tiering: now you can choose whether your vectors are pre-warmed into RAM, left cold on disk to populate the cache only when a query touches them, or pinned in non-evictable heap memory (only available for quantized vectors and other data structures). And you can do the same for other data as well (HNSW index, payloads, payload indexes...)! I wrote an article about it, but here's a TL;DR: - If you have more disk than RAM and predict that most queries will focus on a few "hot" vectors, store everything cold on disk. But beware of tail latency: a disk read can occasionally cause many page faults during HNSW graph traversal, so, to avoid that, add quantization. Quantized vectors are smaller and more of them can be packed in the same disk read, requiring less roundtrips and speeding up the process. - If you have lots of RAM, pre-warm your vectors: this will make tail latency predictable and your search faster, but under memory pressure vectors can be evicted and cause a sharp increase in latency - For predictable memory footprint and fast search, pin quantized vectors to non-evictable heap memory: this lands in the efficient corner, saves you some space, but is not applicable to non-quantized vectors Read the full breakdown here: https://lnkd.in/eSzt6YzU