TurboPuffer 与桥水基金：为企业级 AI 分析师构建带权限隔离的向量检索

Here.

Now, this is a very oversimplified view of how you would go about building an AI analyst, but it is meant to capture an important dimension around permissions.

So, in this diagram, you're user interacting with this AI agent, you start with a question, maybe something like, "Why have token prices come down so much in the last month?" And you feed that question into an LLM, which will begin thinking about that question, investigating, researching.

And as it does that investigation, it's going to search for facts to ground its information, to lead its investigation. Some of those facts might come from the public web, but other facts might come from private documents in your organization. Now, the public web is on one dimension much easier to search than the information that's private to your organization. By definition, the public web is public. Everyone in your organization can see exactly the same documents. So, there's no permission issue there. Every public web document can be immediately fed into the AI analyst, no matter who's asking the question.

But the information internal to your organization looks very different. Every email, every meeting note, every report might have a completely different set of permissions attached to it, belonging to different groups, maybe individual permissions assignments on those docs.

And you can see here, we've got different colors here reflecting the fact that every document in that private data set has a different set of permissions. And this is a classically hard problem in information retrieval, and it's something we explicitly designed Turbo Puffer to solve.

But before I get into that, I'm going to hand it over to Aaron to talk about why this private information is so important to Bridgewater's AI analyst.

So, for the past 50 years, we at Bridgewater have pursued the best understanding of how markets and economies work. We then encode that systematically with logic into a system that we can then stress test over time.

What you see here are on the on the left with the yellow legal pad, that is our bond system from 1980. It's a set of if-then statements that we used to trade bonds back then.

Over the next few decades, we've evolved that process from a yellow legal pad to Excel to eventually Scala and now Python um to to a different learning process with humans at the center.

This five This research circle, as what we call it, has five steps. Perception, that's seeing what's going on the outside world. Hypothesis, which is coming up with ideas of why that might be true. Investigation, which is the research of seeing is that thing true. If it is true, we then systematize and integrate it with our system and industrialize and run that every day and trade on that. That's been our learning process. I've been at Bridgewater for about 20 years. That's been what we've been doing doing for 20 years with humans at the center.

We're now moving towards putting machines at the center and running that process.

In order for even you know, for both humans and machines, in order for that to work well, we need access to high-quality data.

We need both time series data, which we spent decades uh decades creating a great bi-temporal time macro time series database, which we call Delorean.

And more recently, we've been creating a unstructured database, which we call the Vault.

And so, what is the Vault?

Um today, it's about 100 million documents, which we index, organize, and secure that we think represents some of the best third-party and extra third-party external research, and also our internal research. So, we've sourced with 135 different external sources, which is a huge deal for both legal and our data team to actually nego- negotiate and get them in. And all of all of those sources have um some sorts of permissions around it where it might not be open to everyone at Bridgewater.

And then, of course, we also have our inter- internal sources of unstructured data. That's our own writing, our meeting recordings, and and our internal reports, as well.

And both that those all go into the Vault, and then both humans investors and our AI agents read out of the Vault.

What I haven't shown here is actually it circles back. So, the investors and and the agents will create new new content that goes back into the Vault.

So, it's constantly improving.

And so, here's a very high-level view of what permissions in the Vault look like.

So, I have a user we'll just say their ID is user one. They're in groups B and C. This is incre- incredibly simplified, unfortunately.

Um and there's a set of all of our documents where it could be either um uh permission to them via groups or directly.

And then, here we have the actual code of us going ahead and creating a query to try to look for some data with whatever that query vector was that matches the viewers and groups. And so, this is simple in one way. And actually, when we first implemented this without Turbo Buffer, we thought it worked fine. Um but then, pretty quickly, as we started to add more and more documents to the vault, it fell over um tremendously. And so, what I did then was I looked for other possible providers.

We found Turbo Buffer, tested them out, and they had a solution which Nikhil is going to go over right now.

Let me very quickly talk about what Turbo Buffer is. We are an extremely fast, extremely scalable, extremely cheap search engine built entirely on top of object storage. And what that means is we write directly to S3 or GCS or Azure Blob storage, whatever your hyperscaler provides.

And that gives us S3 economics. So, by default, your data is inert, cold on S3. Only when you start querying it do we pull it into more expensive storage mediums, like SSD or memory. And this is really powerful because once a query is hot, once the data query is accessing is in the cache, it's fast.

But if you're not accessing a particular namespace or a particular region of a namespace, that data can just hang out on object storage where you pay rock-bottom prices for it. So, this architecture allows Turbo Buffer to scale cheaply to terabytes of data, which would cost tens of millions of dollars in in other systems, and we can often do it at a tenth of the cost at performance that's comparable once you get the data hot uh to what you get with traditional disk-based search systems.

And we support all types of search. We support keyword search. We support regex search. And what Aaron was showing earlier, vector search.

Um so we're really not uh opinionated about how you search your data in Turbo Puffer. We want to do search generically.

But for the rest of this talk, I'm going to focus on vector search because uh it's it's good to zoom in and go deep on one particular type of search.

Let's do a little bit of napkin math. That's something we love to do at Turbo Puffer. It helps us anchor in the simplest possible solution. We never want to introduce complexity to Turbo Puffer that's not justified. One of the justifications for taking on complexity is if you need it for performance.

The absolute simplest way to do search is to put everything in a list and every time somebody shows up saying, "I want queries that match this. I want documents that match this query." You look at every single piece of data.

Let's conservatively say that every document that you store in Turbo Puffer is 1 kilobyte. This is incredibly conservative. A vector embedding is often 1,024 dimensions. So if you're using just a byte per dimension, that's a kilobyte right there. Uh in practice, documents are often larger than this. But for the sake of example, let's say it's a kilobyte per doc.

Even if you had all of that data resident in memory and you were ripping through it as fast as you possibly could, which on modern hardware is about 20 gigabytes a second.

Once you get up to 100 million docs, that's going to take 5 seconds. And for most search workloads, that's way too slow. What we see in practice is most people want their search results to be about 100 milliseconds. [clears throat]

So the naive solution here does not work. If you've only got 10K docs, great. That's going to take half a millisecond. Turbo Puffer can do literally anything and it will be fast enough. But as you get to scale, once you're at 10 million or 100 million, you really need to start thinking about how you represent your data so that you're not crunching through all of that.

And of course, I gave you the the numbers for memory here. That's only if the cache is hot. If that data's on S3, you're looking at a minute or more to pull that data off S3. So, this just isn't viable at the scale that Bridgewater operates.

Vector embeddings, if you're not familiar, are the internal numeric representation of concepts in LLM space. And we like to use this example of red shoes and maroon sandals. You as a human know that these are very similar concepts and much more similar to one another than concrete block is. And maybe you're thinking about shape and size and texture and and weight.

The LLM can translate that into this numeric vector. Here, I've only got two dimensions shown so that we can think two-dimensionally, but in practice, there's often thousands of dimension. 1024 dimensions is a very common size. Thinking multi-dimensionally like that is very hard. So, for the sake of example, we're just going to imagine that there are two dimensions here.

Now, we don't actually know what those dimensions represent, but again, you can think of it as like size and color. And then you can plot that on a coordinate system. So, red shoes might be at the top left along with maroon sandals, and then concrete block is going to be down at the bottom right.

So, if we were just doing similarity search, great. We look in our two-dimensional coordinate grid, we find some nearby vectors, we return them, and life is good.

And this saves us a lot of time. We don't have to search the whole vector space. We can zoom right in to the documents that are going to be relevant to the query. So, that napkin math from earlier, we can we can ignore. We're maybe only looking at 10,000 vectors here, and we know we can do that in a millisecond or two.

So, our vector index is not immediately helpful to us. And we've invested a lot of time and energy at Turbo Puffer into solving this problem.

Naively, you might try a post-filtering strategy.

And the way that works is the query comes in, you get maybe the 10,000 closest vectors, and then you throw away all the ones that don't match.

This does not work very well because it doesn't provide the results that you're looking for. If I'm the user that only has access to that data in the bottom right, and I search for Q, I still want to see the documents that were closest to Q from my perspective, that include the results that I can see.

But when you do post-filtering, you kind of spiral outwards, and then at some point you have to give up because it's been a couple seconds and you haven't found any docs that match, or you haven't found the top 100 docs that match. Maybe you were only able to find 40. And this makes users unhappy because they might know that a doc exists with maroon sandals, and they were searching for red shoes, and you don't turn it up. So, you have very poor recall.

So, instead of starting with the vector index, what if we start with the filters?

Turbo Puffer builds an index of all of the documents that match the filters. So, Aaron can show up and say, "Hey, show me all of the documents that I have access to."

And then Turbopuffer can scan over all of those documents and see which of them are closest to the query vector.

But what if Aaron has access to 50 million out of the 100 million documents in the vault? Now we're back to square one. We're back in that napkin math problem where it's going to take multiple seconds, if not minutes, to get through all of that data. We're not actually using the vector index. If you look here, you can see we're just finding all the docs that match the filters and then scanning through them sequentially. So, this also doesn't work very well.

So, Turbopuffer's vector index automatically clusters similar vectors. So, you can see there's a group of documents here that are similar labeled five and another group labeled zero and another group labeled one.

And when we build these permissions indexes, we say, "Well, Aaron has access to documents in cluster five and maybe cluster two, but he doesn't have access to any documents in cluster three or any documents in cluster zero." So, we can just throw those clusters out. We don't have to consider them at all.

So, first we find all of the clusters that Aaron has access to, uh i.e. he has access to at least one doc in those clusters, and then we search the closest clusters, and then we just scan sequentially inside those clusters. And in Turbopuffer right now, the clusters have about 200 documents. This is something we're always tuning. Over time, we'll probably increase that number to to maximize throughput. But this basic strategy fundamentally makes search at scale with permissions possible.

And the trick is to combine pre- and post-filtering into what we we native filtering.

And this is the result.

Across 450 million vectors, those 100 million documents turn into 400 million vectors, TurboPuffer is able to get 120 millisecond searches. That's the P90 latency across all of those namespaces. By employing this sophisticated native filtering strategy.

So, with TurboPuffer, you show up with your permissions logic and your conceptual model, and you do what I think is a very simple translation of those permissions into TurboPuffer filter language. And hopefully, you can directly map this code sample here, viewers contains ones viewers contains one groups contains any BC. Hopefully, you can see how you would project that onto your organization's own permission structure.

And that turns into this very complicated systems engineering challenge under the hood, but TurboPuffer hides that all away from you.

So that you don't have to think about it. You can just express the logical filters that represent your permissions in a fairly direct way.

And we handle the complicated query planning under the hood to make that search come back in 1 to 200 milliseconds even at 100 million documents scale.

Now, we're engineers at TurboPuffer, so there are some limitations here. In particular, when you have nested groups, things get tricky. I'm not going to have time to go into that in too much detail, but if you have problems that look like that, please come talk to us. Uh we have a lot of experience working through these, and we're always looking for ways to improve the product so that stuff is handled more automatically.

So, permission filters are really just the tip of the iceberg in TurboPuffer. We're trying to build an isolation native search engine. That means whether you have fine-grained permissions within namespaces, whether you have security, regulatory compliance obligations that force you to regionally lock data, keep that data in your own VPC, encrypt that data potentially not just with an encryption key you control, but that your own customers control.

Turbo Buffer has solutions for all of those levels of isolation. So, permission filtering is just one piece of the puzzle in building isolation-aware search in Turbo Buffer.

So, that's all we got. That's how Turbo Buffer and Bridgewater work together to do fast isolation-native search at 100 million scale.

Thank you, everyone.