D2 Portfolio Demo - Superlinked

Daniel Svonava 10:13

All right, well, thanks everybody for joining. It's a pleasure to be able to talk to you about what we're doing. I delivered a very similar presentation. I'll reuse my deck from yesterday where index ventures put me in front of Jensen at Nvidia. And the idea there is a partnership angle. So let's check out those slides. And I think they touch some of the technical aspects. They also touch some of the business aspects. So we can use that. I think it would be useful if you, once I start to lose you, if you can give me feedback on, okay, let's dive deeper into that. Or, yeah, if we can make it interactive, I think that would be fantastic.

Maybe I'll just start by a couple of sentences about myself. So one of these sort of eastern european technical people got out of eastern Europe through coding competitions. So I started in high school with that, converted that into Google and IBM research internships, moved to Switzerland, started my first company there. We did e commerce plus computer vision. We made it easy to create products from photos and then worked with printing companies on the fulfillment. We used a few undocumented features of the Macromedia flash runtime for the folks in the room that remembered it because of the user experience. So we exploited some features there, had a lot of fan running that learned the tone afterwards, went back to Google and stayed for six years. And that time around. Building MLMFrap for YouTube ads and specifically the problem of predicting the ad performance. So given the campaign that maybe runs tomorrow or in nine months, what will the campaign achieve? And then people look at those forecasts, tweak the campaign and buy it eventually. I was a tech lead for the system that produces those forecasts. And by the time I left in 2018, we powered pretty much all of YouTube ad buying, which back then was about $10 billion a year. And, you know, I was sort of like the engineering tech lead, working with the researchers on the modeling side and with the engineers and kind of pulling it together.

And since then, you know, I've been on my kind of second startup journey, explored a bunch of stuff, went through a recommender system phase for a couple of years. And last year we kind of crystallized the underlying technical solution out of that. That also applies to other problems, and generally it applies to working with vector search across various information retrieval tasks. Recommender systems is kind of one of the applications. There are other applications, and I can, like, let's look at a couple slides and I'll walk you through what's going on. But then, yeah, if you have any questions, please ask. All right, can you guys see my screen? Okay, yeah. Cool. Yeah, I can still kind of see you. So not all of you, though. So if you verbalize the feedback, don't just wave at me.

Okay, so basically, the idea is that in machine learning, we use these vector embeddings to encode information. And in enterprise data, landscape information is not encoded into vectors to draw out the patterns to compress the insights. And so that seems like missed opportunity. Right. And that's the opportunity we want to address. So basically, we want to help companies make embeddings of all the entities they care about. You know, customers, transactions, network nodes, whatever the entity is, the signals of that entity can be encoded into a vector, and then you can do all kinds of stuff on top of those embeddings. If they're up to date, if they're very descriptive, you can build all kinds of useful stuff on top. And while you are doing that, you charge people for compute. Right. So that's the, that's what the business does, basically.

Okay, so let's talk about, like, how all that works. One way I like to get into the conversation is I like to point out a flaw within language models, because a lot of people think that language models are kind of the be all, end all. They'll solve all our problems. But it turns out that actually a lot of what drives business goes beyond just language data, beyond strings. So if you look at these sort of queries or questions, the highlighted parts are referring to numerical features or properties of the data. And that's just one example. There's all kinds of other data besides numbers and strings. And language models are really good at dealing with strings, basically. And one thing you can kind of do yourself to get some intuition for what happens when you put the number into the prompt of the language model. Like what's the internal representation the model uses to kind of represent the number?

You can basically, this chart is you take integers from zero to 99, you stringify them, because that's what happens when you want to feed language models and data, right? You have to turn it into a string. So you stringify those numbers individually, you have 100 strings, you go to OpenAI and call their best model that turns that number into a vector, just like a coordinate point in some, let's say, 700 dimensional space. And you would hope that the way that this happens results in the numbers being represented accurately. And one way to explore how that works is basically you can take the vector representing the number 50 and calculate its distance with all the other vectors representing all the other numbers. And what you would hope to see is that the cosine similarity of 50 monotonically drops as it goes away from 50. You would hope to see the orange line basically. That way you would get some intuition for, okay, the model is kind of thinking about the number correctly. It's thinking that 49 and 48 are kind of next to 50 and so on, right?

And what you actually get is the blank line. You get kind of noise, right? So in the latent space of the language model, the numbers are kind of scattered around. They are not kind of ordered on the line, let's say. Let's say that's one way to put it, because nobody coded in arithmetic, nobody coded it into the language model. And that's fundamentally a problem of how the model eats the input and what it does with it internally. And so anything that you are building on language models that involves numbers, for example, or any other more complicated, structured, let's say, data type, will be by definition super noisy. And also it's like a very inefficient thing to do. And this you can replicate with 20 lines of python against the OpenAI API. You should possibly all just try to do this.

Okay. And so given that language models can't deal with numbers, how do you address this shortcoming? Right? Because we want to build systems that do retrieval from realistic data sets that contain numbers, that contain strings, that contain timestamps. Click data. Right, depending on the use case and the way to address that. This is the Nvidia reference architecture that doesn't address it. That's what I told Jensen yesterday. But the way we did it, we do it the way we solve the problem of how do you represent a real world dataset, real world entity in these vectors so that you can do all the different use cases we do it by. There are basically two options.

You can train a custom vector embedding model that eats all the different signals and produces an embedding for your user, for your transaction, for your piece of knowledge within your knowledge base. Or you can do it and that's difficult. Or you can do it our way, which is our framework, helps you construct these models from pre trained parts. So think about it as kind of legos for vector embedding models. And this is just a simple example where we have a use case that's a search use case and it's search over news articles and we want to run query that says popular recent news about risk. How do you do this? Because popular is a reference to some kind of click data, recent is a reference to a timestamp, news is a reference to a category of the content piece. And risk is reference to a topic within the article.

Right. Somehow you need to ingest your articles in a way that encodes those different aspects of the data, most of which is not textual. And then you need to be able to break the query down to something compatible with that encoding. And so Superlink framework helps you use a number of different encoders to eat different parts of your clicks. You have your news database with all the different metadata. It produces a data vector that encodes all of that information and puts it into a vector database. We partner with MongoDB and Redis, so we have signed partnerships with them. We do co marketing. They publish tutorials of how to use their stuff with superlinks. They put us into events and so on.

So we provide that kind of compute interface between the data and the vector database. And then also we provide the query interface where, for example, we can get a natural language query that looks like this, break it into the input of all the same encoders to produce an aligned query vector that encodes all those different objectives of the query. And then the underlying vector database does the matching. And finds the right answer and kind of like system design diagram, where do we sit in the stack? It's basically this. So on the left side you have your data sources, your data warehouse databases, document stores if you want. And on the right side you have the use cases. This is the stuff you want to build. Data powered products rag. So retrieval for language, model use cases, recommender systems or personalization. There is search, of course, and we also say analytics. And that's where you are, for example, clustering the vectors, or you are using the vectors as features into any other modeling task.

So you have the data on the left, use cases on the right. Superlink sits in between and takes all the data in. That's the pipeline aspect, does the modeling and all these Lego blocks I described to produce customer vectors and vectors for all the entities you care about and then gives you a way to put up API endpoints to build all of those use cases on top. And two kind of relevant partnerships are top and bottom of the picture. So we work with the vector database folks for the storage, we only want to do compute. We don't want to. There is 44 vector databases on the market. Some are existing providers that added the functionality, some are folks who built a database around the concept of vector search. We pretty much have a relationship with all of them because we have a marketing, we have a marketing asset which, let's see, I don't think I have it here, but I can share it afterwards. It's a table that compares 44 different vector databases across about 40 features. It's crowdsourced, it's open source, and vendors send us pull requests into the table when they launch new features. So that's sort of like the watering hole for the storage side of the problem. And we are kind of the compute provider that sits on top. So that's important.

And then the models, we are basically working with a bunch of open source models and starting to build relationship with the proprietary model providers as well. So basically this is it, right? Like there is like there are some pipelines and then there is some way to solve the modeling problem and we combine it together, we put nice kind of developer experience around it. And for the database partners, we are kind of a go to market partner because they can close accounts, or at least that's the hypothesis. We are still trying to prove that because we feel in the missing capability that most companies can't make these vectors properly. Right. And so for the, the database is like us because we can help them sell more vector search, which is really hard because it's bottlenecked by companies being able to figure out the modeling right in terms of traction.

I think this is interesting for the group. We think about progress on three axis, basically. So we need to show that we can deliver some tech and so we need to work directly with customers. We have our first kind of fully rolled out customer. It started as an e commerce recommender system deployment, but now it's also scaling into analytics and some of the surrounding use cases. That customer saw 15 million of incremental revenue by working with us and it's a UK based like fashion e commerce firm. And that's one hundred thirty k per year contract for like a limited set of applications within the business. I think there is maybe like another hundred Appsell we can do there. And we have two more companies in kind of scoping out stage which are very similar to that. So we should be sort of good to go on three reference projects in the recommender system use case.

But I mentioned some other use cases. So I'll just highlight paid PoC where we do rag with a private equity firm over hundreds of PDF's. And I'll also highlight another paid pilot with pharma, publicly traded pharma in Japan out of all the places. And that's basically semantic search over tabular data. That's one way to think about that pilot. So our strategy is to prove that we can, you know, that these use cases can be built on top of the platform. We work hand in hand with those customers to actually do it. The idea is that once our cloud product hits the market, we'll be able to scale those customers and kind of go from there.

We need to prove that we can work with partners because we focus on a specific set of functionality. Right? You can read quotes in the fundraising announcement with index ventures, we have four different partner quotes on how different large companies are working with us on this type of functionality. And finally, we need to do some kind of market education because we are saying, hey, this vector compute is sort of market within ML compute, and it's its own thing and it should have its own abstraction. So we do a lot of activity on social and we go to events. I spoke at the databricks summit and I moved to SF to kind of be closer to the ecosystem and basically do all that a little bit on the theme.

We are 18-19 folks. My co founder, Ben, his background is actually also software engineering, but then he went to London Business School, and McKinsey, he's based out of London, but grew up in Israel. We have been working together for three plus years, so we've kind of figured out how to do that. Chief architect, this ex Mastercard guy who built the credit card fraud scoring model there. We work with Ellie in Tel Aviv, also super senior. And our first ML engineer hire here in San Francisco is Andrea. Twelve years of information retrieval at a bunch of different companies. I did 40 interviews to find Andrea in San Francisco before we gave an offer to somebody. We have a high bar, let's say.

Okay, we have about 20-19 months of cash in the bank, some cool people on the cap table, lots of cool execs among our investors from partner companies, some big tech, and that's pretty much it. So, just to summarize, we give you a software engineer friendly, so you don't have to have a PhD in data science. Interface over vector compute abstraction that helps you build across a number of use cases, because that's what companies want. They don't want just a chatbot or just a personalization of one specific page or just a way to find outliers. Ideally, you can have this as a platform that you can build on and have a strategy.

Our goal is to improve retrieval quality by feeding more information into the embedding through this kind of Lego blocks. This way we, for example, don't have to re rank because we can express a lot of those objectives in the underlying search. So it's much more efficient. And you can do partial updates because you can run individual encoders within that kind of ensemble. So when a new piece of information comes up, you can only recompute a part of the vector, which is much more efficient. Our go to market is we have an open source framework out there. You can go on GitHub, check it out, and we are building a cloud product that we want to bring to market later this year. We are running individual deployments of the cloud product with these first customers that I talked about a little bit, and that's pretty much, let's say, first passed.

This is my notes for, like, what I want out of Nvidia. Maybe there are questions, maybe I should pause here and sort of let you guys ask questions.

Adam Murray 29:38

Okay, I'll hop in. So you mentioned having a spreadsheet of 44 competitors. I'm just curious, how do you distinguish yourself among such an intense rivalry?

Daniel Svonava 29:53

Okay, this is a very good question because it highlights an important concept. Vector databases are not our competitors. So I mentioned that we ran on top of the storage. We partnered there. And then we do the compute on top. Right, let me show you. So all the vector databases out there are potential partners for us.

And can you see this? Okay, that's the table. It's a bit zoomed out and it has a horizontal scroll. But basically these are the databases that offer vector search. There is mongo and single store and data stacks and some of the big guys. And then there is, you know, Timecone and Chroma and VBA, some of the more specific ones. Right. None of those companies is a model company. Right. And so they have a hard time figuring out the modeling problem. And that's the piece that we fill into the stack. Yeah, make sense.

Adam Murray 31:01

It sounds like you might need to make a lot of connectors to allow multi ingest from any potential source.

Daniel Svonava 31:10

Yeah. So let's talk about that for a second. Okay. That's pretty much the same picture we had before.

Daniel Svonava 31:22

Yeah. The way to think about this, we have two kinds of connectors, right? We have the connectors for the underlying storage layer. Right? So you use Superlink, let's say with Redis vector search. So that's the compute plus storage. Yes. We need integrations with these partners. It's pretty deep work. We don't need 44. Right. You don't like. We want to cover sort of majority of the market and it's power load distribution. So we need to work with six or seven of these providers.

The other set of connectors is for ingestion of the data into the system. Right. That's your trainer and youre confluent connect. Right. So one of the reasons that I went after confluent and we signed the partnership and we are kind of added to, we are on a track to get into the confluent connect, which is like their way in their cloud offering to add destinations for the Kafka streams. We want to make it as easy as possible to ingest all this data, to turn it into a vector.

Because let's say your customer, there is all kinds of different signals about your customer. Some of it is batch data. That's why we have a spark ingestion engine. That's one of the things that are proprietary for the cloud offering. We open source, the server can run it on one node. You can work with data up to let's say 1 million objects. If it's a big node, then you can pull it off. But to then go to scale, you'll need some proprietary pieces that we hold back and we only deliver it through the cloud product like a spark compiler so with the same specification that you control the server, you can take that, compile it into a spare job, and run, let's say, like a backfill or. Batch computation.

So that tells you. That explains a little bit more what I mean by open core. We open source the server, the SDK, people can get familiar, there's million titan notebooks as examples and so on. But then to go to scale, you need some of these proprietary bits that we sell through the cloud offering, of course, and then all the make it easier to manage and the usual kind of cloud value props.

But yeah, on the ingestion it's Trino. So that's why we announced the Starburst collaboration. They're the Trino company and also the confluent relationship just to make it easy to ingest all this stuff.

Alon Levi 33:53

I have a question about the e commerce customer that you mentioned. What was the state of their, I kind of like ML integration or sort of how much was this like a brand new thing or just changing the way that they did it?

Daniel Svonava 34:06

So this is a little bit more about the customer.

Daniel Svonava 34:12

Basically they have Algolia based search and they did some quite basic heuristic algorithm for when you sign in, what do you actually see see within the website? And they were just, it wasn't really sophisticated, it wasn't really ML powered. And we competed there with Algolia. Algolia also has a kind of Algolia recommend product, but the one thing they don't do is real time updates.

And so because of real time updates, the inventory comes in and out, the user clicks on things. How quickly can you use that data to show more personalized results? In our case, the end to end update latency for the system in this deployment is sub 5 seconds. So when the user clicks on something and then they scroll, the stuff they see immediately basically reflects that previous click.

And then we A/B tested the solution that sort of we provided with the basic thing they had before. And yeah, we basically saw actually quite a little bit more than twice the average order value for the exposed sessions and eventually from the rollout, not only at the feed, but also like similar product page and let's say in basket complimentary recommendations or like category pages, but personalized. So you look at jackets and it doesn't show jackets that you don't like.

Basically it was very easy to deploy across those different surfaces because it's a horizontal platform. We can put up API endpoints and then the cool thing there is the merchandising team that wants to make product bundles because they want to bundle products and put the discount on it and sell that way. They were doing basically. Like, all up queries into event database to figure out, okay, which skirt sells in which geography. And then the people who bought that skirt, they try to piece it together with a bunch of queries.

But of course, using embeddings as a foundation for those bundles is way more powerful because it encodes the descriptions of these products, the images and the behavioral data and the pricing information and all of that. And to integrate all those different sources, you can't just use like an open source embedding model because those are all, as I said, text in, vector out. Right. To integrate all of that product information, you need a bunch of different encoders and a framework that stitches it together for you.

Samir Naik 36:55

Maybe just building off of that, if you don't mind, is your ideal customer somebody that already has like a machine learning team that just needs to be sort of like superpowered via the platform? Or is it like, it seems like in this case, you were actually, like, sweats were able to do work that maybe an ML team would do because of the higher level abstractions? Like, I guess. How do you think about that, just from, you know, my perspective as a buyer? Like, how would you kind of, like, what's the pitch there?

Daniel Svonava 37:23

Yeah, yeah, the pitches. There is this new Persona that emerged on the back of the language models that people call AI engineer. These are software engineers that sort of played with language models, and they sort of dabble with machine learning, let's say, or AI through that.

I would say that's at least initially for the next year, that would be the lowest end of sophistication. So I wouldn't want to kind of go after completely from scratch software engineers that haven't looked at anything. I would at least want to work with somebody who tried some of the kind of, you know, they tried lunching, they tried Lamindex, or they tried some personalization, kind of maybe more vertically integrated solution. They want more control. They want more, you know, get more into actually kind of building it. And then that's the low end.

And the high end is, yeah, you have a data science team. Maybe you have, you know, 30 different embeddings. You are thinking about ways to update these models, and then do you have to recompute all the embeddings in the database? That's where having two different encoders and being able to sideload an encoder for new signal to your existing encoder and then run these things like partial updates.

There is a whole sort of new approach to how you manage vector embedding projects, basically, and historically, this hasn't been sort of as a separate category. These happened within ML projects like full stack. You go from raw data all the way to the end result, but then your projects look like this. This is a sophisticated organization that throws ML data engineering team at. Project and then just, okay, we need to build this recommender system. Okay, let's go to all the sources. Feature engineer all the data, build the embeddings, build the models, train that thing. That's why it takes six months to do it. Right, because you have this like crisscross pattern of everybody reading the raw stuff. Right.

And that's what we are saying is if for the sophisticated buyer, everybody can start with fresh embeddings of all the entities they care about. The data scientist who is supposed to predict lifetime value of a user doesn't have to go to query logs and to click logs and actually start to feature engineer a user. They can just pick up within a couple of seconds up to date user embedding and build a predictive model on top of that.

So that gives you some flavor of when I qualify you and you are at the start of the journey, I'll talk to you and I'll walk you through how this thing works. And it's like super easy to use and software engineer can do it. It kind of looks like an orm for a vector database. You define your data schemas and define your spaces where we hide the encoders. And you define your index by combining the spaces. Right. And then you define your queries and it all sort of looks like a software engineering project. Right. But under the hood, you know, everything that I was talking about sort of applies.

That's how I would talk to kind of somewhat sophisticated software engineer. And then to like a data scientist, I would use kind of those kind of more sophisticated points of how do you, you know, how do you manage those encoders? And do you have to train a new one every time or can you combine them and so on? We have time for one.

Mark Dhillon 40:44

One more question and then we have to jump to our internal combo. Anyone else?

Roger Luo 40:50

Yeah, I asked this.

Shadi Rostami 40:51

No, go ahead, Roger.

Roger Luo 40:54

Yeah, so, yeah, Alice, question before. So I know the answer, but I'm particularly excited when I hear Daniel answer that. So what's the term, what's the market opportunity for Superlink?

Daniel Svonava 41:04

Right. So this is, you know, the question is how to approach that calculation. The way I like to think about that is we basically productize representation learning.

And what does that mean? Well, it means training and inferring embedding models, which depending on how you slice it, how much compute is that from the whole ML compute PI. How big of a fraction this problem of turning data into embeddings represents.

One thing you can do is you can go scrape hugging phase, you can look at the NLP models over there, and you can classify them into like generative, let's say sentiment classification models and embedding models. And you can compare how often different kinds of models are downloaded, and the embeddings are about 20% of all the downloads.

Of course, this doesn't fully map to how much they're running, how much data they're running on, and so. On. But as a rule of thumb, based on this kind of data, and based on me being in YouTube working with vectors for six years and having lots of friends in various other companies, actually something like 20% I think is a good ballpark for the time out of the total ML compute money spent on chips and electricity represents.

Because basically any project starts with, hey, we need to turn some data into vectors here and then we do retrieval or we do modeling on top of those vectors.

Mark Dhillon 42:45

Great, we'll keep running with questions. We'll do the committee vote of async because we kind of messed up the invite in this one, so we'll keep going. Anyone else have questions?

Shadi Rostami 42:54

Yeah, I have one quick question, I think, Daniel, you almost answered that, but can you walk me through the adoption of this solution at different companies that you have taken? How long does it take? What are the success of story and what are the not so success full stories that you've had?

Daniel Svonava 43:08

Yeah, I mean, so we are pretty early and generally there are two types of stories. We support couple companies in their usage of our open source product there.

I think one of the success stories is a company called Ro. They just came out of YC, they raised a couple million dollars. They're building Snowflake for unstructured data. And those guys have been playing with the open source system and they want to basically build their next query engine around Superlink.

So at the core of their product there is a couple other builders that we support in using the open source platform. We put it on GitHub a couple of months ago. We have 450 stars. We don't really market it. So that's one category of stories.

And then the other one is with chosen companies that we want to develop into reference customers and also kind of lounge partners for the cloud. We do these hands on engagements and that's where this success story was.

This took actually months of work to get into that account and figure out where the data is. We had to do a lot of the heavy lifting, but then we got to the results to prove that, for example, you can do this without re ranking, which is basically unheard of in the world of recommender systems. No two tower network, no re ranking.

This sort of set of concepts that I talked about, our next couple of reference projects will kind of look like that. Maybe it's not going to be months, maybe it will be a couple of weeks, because the underlying platform is improving and we don't have to fill in quite as many gaps for each project.

But the whole point of this year is develop a set of reference customers across the use cases we target so that when the cloud product comes to market. They can all go on stage and say, hey, we are a manufacturing company. We turned a bunch of data into vectors. We saved as much on service costs. Or we have a pharma company and we have all these complicated trials data. This japanese pharma I mentioned, we use Superlink to sift through all of that, answer our questions, saved this much money or reduce risk.

So this year is not really about scaling that out, is more about proving that actually this picture is possible that you can in fact productize, vector compute and make it a box and build things on top.

Shadi Rostami 45:49

Yes. Awesome. Perfect.

Surabhi Gupta 45:52

I have a question just on the technology advantage, because I think there's always going to be this layer elasticsearch earlier Goliath. It's a crowded space because everybody wants to do search for their products. And so, you know, you mentioned two problem areas, right? Numbers and then categorizing the content. And so what is, do you feel like the technology advantage that you have here is in these two categories? And like, what? Maybe just especially on the, on the categorization, like, what are you doing that's kind of helping the retrieval.

Daniel Svonava 46:26

Yeah. So I think there are two parts of the question. So how do we differentiate from more full stack providers like hebia or Algolia? The differentiation is that we are a tool to build your own stuff. We are a platform where you don't just want the pretty search box because you realize that, okay, we need recommendations, we need to send personalized emails. There is a whole bunch of use cases, and each company is a little bit different. We want to power the builders, right? We want to be the compute engine to build your own customized solutions.

Therefore, we don't, for example, provide the front end component and we don't get sucked into front end customization like Algolia does. By the way, Algolia CTO is one of our angels. So that's just kind of random. So that's the difference between like, build versus buying, right. We want to be the build option, but then still kind of sell you a compute product. Right.

If that makes sense in terms of the technical advantage. I think the idea is that we'll be cranking out these encoders. The categorical encoder is actually super simple. It's just you have like a multi hot encoded set of categories that go directly into the embedding, as opposed to trying to eat a list of stringified categories through with the language encoder, which is, if it's category ids, then that's not going to work. It's just a way to organize the work.

Basically, then the individual encoders, we can work with open source, we can work with proprietary models, we fill in our own encoders where those two sources don't have a good solution yet. So for example, for the timestamp encoder, you want to encode timestamps in a way that maybe day of week similarity matters, not just timestamp distance in milliseconds. So we filled that in because there is no open source timestamp embedding encoder because you don't really need it if you don't have a framework to combine it with all the other stuff.

Basically we are trying to create a category of how you work with embeddings, do the inference to make money and organize the workflow for a team of data scientists and software engineers coming together and working on this stuff.

And we can kind of benefit from people launching models because we can combine those models with other models to give that team building a system the foundation for it. Also make it easy to switch between vector databases, which, you know, that sounds like simple and sort of like not super exciting, but actually because there is 44 vector database solutions, the market is evolving. It's crazy.

You don't want to get stuck in any one particular deal. Or maybe you want to start with open search because you are on AWS and you don't want to be benchmarking that against five other things to choose upfront, which one you want to use. Start on open search with superlink switch when it doesn't scale anymore, for example, each of these databases, by the way, has a different interface. So the fact that we can aggregate them in one abstraction is actually quite valuable.

Mark Dhillon 49:44

Any more questions?

Rolf Njor Jensen 49:45

So for the. Thank you for a great presentation so far for the public cloud providers, the big ones, AWS, Google Cloud, Azure and so forth, for them to create a vendor login situation around both ingestion and the search. And of course that you run the Baxter DB on their infrastructure must be super important, right? So what's to keep them from building superlink?

Daniel Svonava 50:20

Basically, I mean each of these, for example, you can look at bedrock from AWS. That's a solution to be able to build drag, to have vector database under the hood to bundle in some of the modeling. So they have an offering in the market called bedrock that you can go check out. All of that is organized around language models, language encoders for the vectors, language models for the generation. Of course of the responses, I think we have another maybe like six or nine months before people realize that that's just not enough and you need something else. And one way to get that is partnerships, right? Because at the end of the day I think what the. Cloud providers care about is that whatever they run, it runs on their infra, right? And so if we can do a partnership with AWS and put in some kind of clause that makes us not make their users switch to other providers, what they care about is, are those encoders at the end of the day at the bottom of the Matrioshka doll running within AWS cloud as well as the Azure providers. Actually for the launch of the cloud product, that was my motivation yesterday with Jensen. I have a call with 20 people at Microsoft tomorrow and I'm chatting with intel. And actually I want to make one of those kind of the main launch partner for the cloud product for them to differentiate, be at the forefront. I don't need all three of them. I probably want to make one of those feel a bit also like GCP is in the game because I'm a googler. We have been a GCP shop since the beginning. So I want to pick one of them and be kind of a little bit more friends to kick off and get the initial traction. And after that we'll kind of see what happens.

Mark Dhillon 52:21

All right, final question. Daniel, everyone has to ask you questions, so maybe we can set up one on ones. But anyone else have a question before we do internal sync?

Mark Dhillon 52:34

No one. Come on, one more. No one.

Dan Dancescu 52:41

So are you, I guess near to midterm? Are you looking more for these partnerships or are you looking for direct clients? Because I. I just. And then a related question is you mentioned with the recommendation system e commerce client you had 130,000 yearly contract. How do you determine those contracts with the size of those contracts as well? So.

Daniel Svonava 53:19

Got it. We do a bit of both now, which you could say it's like we are distracting ourselves, but basically we try to work directly with this kind of set of reference companies because we feel that if we work with the company directly, we are learning much faster of how to actually get this thing to work.

But for the distribution, I want to be the default vector compute solution MongodB recommends to use with their vector database. They have lots of sales folks, their prospects. Ask them about the modeling side of vector search. I want them to answer, okay, go use superlinks because the sales guy knows that they'll be able to close the deal faster.

So I would like to lean on the partners for the distribution, but not necessarily for the reference customers. That we want to work directly, have that relationship, really hear from them the feedback. Also like talk to prospects, see which value props resonate. If you do that through partners from the get go, you get this kind of secondhand information sometimes.

And so, yeah, we try to kind of be diligent on the direct. We have a bunch of inbound, we actually just onboarded the account execs from weights and biases to help us go through the inbound qualified, get on calls and convert those to this kind of, we deliver projects while I spend a lot of time with the partners aligning so that once the cloud is out there, the distribution can kick in because they just sort of bundle us. Because there is those 44 databases that need the compute part of the story. So that's the kind of go to market to us.

The second one was pricing. Okay, not very scientific. So basically I thought, okay, these guys are doing, let's say something over $100 million in revenue. We'll work with them. They'll, let's say, make like four or 5 million more. And so I started with 200k. Let's say it's like less than 10%, more than ten x roi, right?

So I said, okay, let's do 200. Then they negotiated me down to 130. But I said, okay, but it's only the feed, not the personalized emails, which they send 107 million of every month. So that will be a separate contract. And also I know that they have a sister site in France. And so I said, okay, 130, but it's English only. Even though the features that we actually extract from the product catalog are mainly behavioral and images. So it doesn't really actually have to do with the language. But that's how they thought it makes sense.

So I said, okay, fine, there's going to be a separate contract. Let's step out of that zoomed in place. And basically I'll say we want to sell compute, that kind of value based margin. So instead of being sort of like a language model serving provider, where you just switch API endpoints, you switch to another one, the margins die. That's not what we want. We want to be deeply entrenched in your enterprise data landscape. That's like what this picture is. We want to be in there. We're defining where the data is coming from to make these vectors. That makes it sticky.

And so then we can price based on the value. Ok, you'll be sort of unlocking all this business value because we make it easy to build all the boxes on the right. So that's our basically plan for actually having margin.

Mark Dhillon 57:00

Awesome.

Dan Dancescu 57:00

Thank you.

Mark Dhillon 57:00

Thank you, Daniel. Okay, that concludes it. Daniel, thank you so much for this pitch. We got to do an internal combo. And apologies again for not sending you the invite. We can't really have this. But Jerry, Roger and I will follow up afterwards. We talk with the committee and get some votes in, but also we'll see you next week at the conference.

Daniel Svonava 57:20

Sounds good. Thanks, everybody. And, you know, this was like a demonstration of my pitch out of a blue. So, you know, it's, let's say it's even better if, you know, I have like a ten minute leap time. You would maybe even, like, see slides from the same deck the whole time, but otherwise, yeah, super nice to chat with you. Thanks for the great questions. Yeah, the angel rounds within the scope of which this conversation is happening. We filled eight hundred k of that in two weeks out of the million. We are not super fast about the million. Let's say. Maybe we can push that a bit further. So, yeah, I'm definitely leaving out space for us to potentially do a deal. So I'm curious how that shakes out. But, yeah, that's it for me.

Mark Dhillon 58:18

Thanks, Daniel.