Speaker unverified: commitment

Transcript context

…ofits build software factories that can scale not just outputs, but business outcomes. You probably know that the majority of enterprise AI projects fail in general. That's because leadership fails to realize that AI isn't like traditional software that you can just buy and install. On the contrary, if you want AI to amplify your business's unique DNA, you'll need to make a sustained effort to record, understand, simulate, and optimize your business processes. Building these skills by trial and error takes years. But your business problems can't afford to wait. So, here's how diffusion can help. You identify your most important business problem. Fly to Silicon Valley for an intense week of problem solving with the diffusion team. And by the time you leave, you'll have not only cracked a critical challenge, but built the core skills needed to do it over and over again from home. Cognitive Revolution listeners receive a 25% service credit on their first engagement with diffusion. So, visit diffusion.io/tcr to learn more about how customuilt software factories can scale critical outcomes for your business. That's diffusion.io/tcr. io/tcr. Today's episode is brought to you by Granola, the AI powered notepad built for the way real people actually meet. Here's how it works. You take rough notes like you normally would. And in the background, Granola securely transcribes the meeting. Then it turns everything into clean, structured, actually useful notes when the meeting ends. And the best part, Granola works through your devices audio, which means it integrates seamlessly into the video conferencing tools you already use. No setup and no awkward bots. It's just your normal meeting with superpowers. You get to actually listen instead of frantically typing every word and still walk away knowing exactly what was decided, who's doing what, and what comes next. When I had Granola co-founder Sam Stevenson on the show earlier this year, he explained how Granola aims to provide a calming experience for people with crazy work days. And as a user of the app myself, I have been struck by how streamlined, even minimalist, the Granola product experience is that takes real discipline, but the result is a product that works not just for AI early adopters, but diverse teams of people who just want to get things done more efficiently and effectively. Listen to my full episode with Granola co-founder Sam Stevenson for a master class in designing AI products for mass market adoption and try Granola for free at granola.ai/tcr. That's granola.ai/tcr. Sure. So, let me So, first let me push back on one thing you just said. Most people think that we're schemalists and that's not actually true. It's not that we're schemalists. It's that we're schema flexible that you can change the schema more easily over time because more of the data is denormalized and therefore centralized in a way it's not a strict requirement unless you specifically say so that every document in a collection so we don't have tables and rows right we have a think of a JSON wad as a document and you have multiple JSON wads put together into a collection not every document in collection ument in a collection so we don't have tables and rows right we have a think of a JSON wad as a document and you have multiple JSON wads put together into a collection not every document in collection necessarily has to have the same shape. You can have different shaped documents in the same collection. So because the schemas are flexible and because you can have different docu different document shapes in the same collection, that's why people assume that we're schemalist. But what it does is it gives us the ability to be malleable in a way that a traditional SQL schema is less malleable. I won't say not malleable at all because it depends on how you're laying out the data, but anybody who's ever had to change a SQL schema that's already in production and the cascading effect that has on multiple tables knows the pain of what I'm talking about that if you had some of that data denormalized, it's far easier to add attributes to a document that's already there and do so selectively in a way that isn't possible nearly to the same extent in the SQL world. And this is where how we've implemented like the history of how we've implemented vector search and the impact that has on application architectures for agents ends up like the details matter here. So if you'll allow me I'd like to talk a little bit about that history. Does that sound okay? >> Yeah please. Okay. So for us it really started with an an unusual place and that is with lexical search. So in 2020 we noticed that a common use case for MongoDB was for people to stand up their own Apache lucine servers co-located with wherever their their MongoDB clusters might be. And the reason they were doing that is they wanted to be able to point that lucine cluster to different text fields in a document and be able to do keyword retrieval off of them. Perfectly reasonable thing. So we thought well as you might know there's there's three different versions of MongoDB. There's community which is you're responsible for the support and you're responsible for the operations. There's enterprise advanced which most customers are using on prem where you're responsible for the operations but we're responsible for the support. And then there's Atlas which is our managed service version of it which you could deploy your instances on any cloud hyperscaler data center you'd like amongst Amazon, Google and Azure with and in that form factor we will do the support and we'll do the operations. So those are the different choices you have when you deploy MongoDB and regardless of which one you choose. Like I said, we noticed people standing up lucine server so that they could get keyword retrieval on what they have. So in 2020 we introduced what's now known as Atlas search which is on the managed version the managed version of MongoDB you automatically just you just get it as part of the instance that that there's a a lower priced tier where you just point it to attributes some text attributes that you already have in your data will automatically index them. You can do keyword retrieval search on those. Then the next logical thing was a couple years later, well, if you're going to ttributes that you already have in your data will automatically index them. You can do keyword retrieval search on those. Then the next logical thing was a couple years later, well, if you're going to have lexical search, you might as well also have vector search. So think about this. What's a vector? At the end of the day, a vector is an array of floats, right? You take some piece of data and whether that piece of data is text or an image or audio or video, you pass it to an embedding model of your choosing and what you get back is an array of floats. So to us an array of floats is just an additional attribute to a document you already have. So for us to implement vector search was just add an additional attribute to the flexible schemas that we already have and now build a vector index on top of that array of floats and that's your vector search. And what it created was this notion of being able to do these powerful hybrid searches as well. So if you think about the sort of the trivial example that most people learn MongoDB off of is suppose you have a book and a book might have a text field for the title and it might have a text field that is a URL that points to the cover of that book. You might have an integer that's the number of pages. You might have an integer that's the year of publish and you might have a text field that's the synopsis. So if that's a standard record for a book in if that's a standard document for a book in MongoDB and that's put in a collection. Suppose now I want to create a vector index off of the synopsis. I could take that text synopsis text. I could pass it through an embedding model of my choice and I then store the array of floats that come back from that embedding model. And if I wanted to, suppose I had 10,000 records. I had 10,000 documents in my collection. Maybe I only want to do a vector search on the top thousand. Maybe I don't want to do it on all of them. Because of the flexibility of the schemas, because you can have different shapes, MongoDB not only allows that, but thrives on it really well. So we had lexical search, we had vector search, and then that enabled us to do this notion of hybrid search. So suppose I wanted to do combine a lexical search of the title of the book with this now vector search that I have on the synopsis. And what if I also wanted to prefilter because I've got some integer fields in here. Suppose I want to do a search there where I do a lexical search on the subject and a lex and a vector search on the synopsis. But I want to eliminate any documents any books that weren't published after the that were publish I only want to see books in my data set that were published after the year 2000. So now I have these three levers of query power that together are give me lots of interesting ways to now query my data that I combine this sort of prefiltering based on the metadata with the lexical search with the with the vector search. So once we had that in play by like 2023, we thought, well, this works with any embedding model you want, but could we make this easier to develop if we had an embedding model that was part of it? And that's why we purchased Voyage in 2025 was to…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.