Building AI Products That Actually Work — Ben Hylak (Raindrop), Sid Bendre (Oleve)

My name is Ben Hylak, and also just feeling really grateful to be with all of you guys today. It's pretty exciting. And we're here to talk about building AI products that actually work. I'll introduce this guy in a second, sorry I wasn't theright order.

So I tweeted last night, I was kind of like, what should we talk about today? And the overwhelming response I got was like, please no more evals. Apparently there's a lot of eval tracks. We'll touch on evals still, just a little bit, but mainly we're going to be focusing on how to iterate on AI products.

And so I think iteration is actually one of the most important parts of building AI products that actually work. So again, just a little bit about us. So I'm the CTO of a company called Raindrop, and Raindrop helps companies find and fix issues in their AI products.

Before that, I was actually kind of a weird background, but I used to be really into robotics. I did avionics at SpaceX for a little bit. And then most recently, I was an engineer and then on the design team at Apple for almost four years.

And we also have Sid. So in the spirit of sharing how to build things that actually work, I brought Sid, who actually knows how to build products that actually work. So I think Sid is like the co-founder of a company called Oleve.

With just four people, they grew a suite of viral apps to over 6 million ARR. So Sid is going to share, again, how to build products that actually work.

I think it's actually a really exciting time for AI products. And I say it's an exciting time because in the last year, we've seen that it's possible to really focus on a use case, really focus on something, and make that thing exceptional.

Like really, really crack it. We've seen that it's possible to train small models, really, really tiny models, to just be exceptional at specific tasks if you focus on a specific use case. And we're also seeing that increasingly providers are actually focusing on launching those sort of products, which is, you know, that might be the scary part.

But deep research is a great example, where ChatGPT just focused on how do we collect a data set, how do we train something to just be exceptionally good at searching the web. And they were, I think, is one of the best products that they've released.

But even OpenAI is not immune to shipping not-so-great products,right? I think, to me, I don't know what your guys' experience is, but I think that I've actually had a lot of trouble with codecs, and I don't know that it's exceptionally better than other things that exist.

This is kind of a funny one. I was like, write some tests, and it actually correctly generated this hash for the word "hello." But it's like, I'm not sure this is like when I think about writing tests for my backend, I'm not sure that this is what I wanted,right?

And it's not just OpenAI. I think that increasingly, in the last year, AI products still, even in the last couple months, couple weeks, there's all these weird issues. Like, yeah, this is a funny one,right? So Virgin Money, their chatbot was threatening to cut off their customers for using the word "virgin."

So just the other day, I was using Google Cloud, and I asked it where my credits are, and it was like, are you talking about Azure credits or Roblox credits? And I was like, how is this possible? It's funny because I tweeted this, and it's like, this isn't just a one-off thing,right?

Someone's like, oh yeah, this exact same thing happened to me.

Just a few weeks ago, Grok had this crazy thing where people were asking, in this case, about enterprise software, and it's like, oh, by the way, let's talk about the claims of white genocide in South Africa. Just completely off the rails here.

And we only caught something like this, only kind of entered the public awareness because Grok is public and because you can kind of see everything. Funny enough, I actually tweet a lot about, if you follow me, you know I tweet a lot about AI products and where they fail.

And so last night, when I was rushing to get this presentation, my part of hit done, I asked it to find tweets of mine about AI failures, and it says, I don't have access to your personal Twitter. I can't search tweets.

I was like, I think I can. So I doubled down. I'm like, you are literally Grok. This is what you're made for. And it's like, oh, you'reright. I can. I just don't have your username. So it's absurd. And I actually, this is yesterday.

This is still a bug that they have. So I feel really lucky to be, like I mentioned, I'm a CTO, co-founder of a company called Raindrop. And we're in this really cool position where we get to work with some of the coolest, fastest growing companies in the world and just a huge range of companies.

So it's everything from apps like Sid, which he'll share about, to things like Clay.com, which is like a sales sort of outreach tool, to alien companion apps, to coding assistants. It's just this insane range of products. And so I think we get to see so much of what works, what doesn't work.

We are also, it's not just all secondhand. We also have a massive AI pipeline where every single event that we receive is being analyzed, is being kind of divvied up in some way. And we're kind of like, we have this product.

We're also kind of this stealth frontier lab of some sort of where we are kind of shipping some of the coolest AI features I've ever seen. We have tools like Deep Search that allows people to go really deep into the production data and build just classifiers from just a few examples.

So it's been cool to sort of build this intuition both from firsthand, from our customers, and kind of merge that. And I think we have a pretty good intuition of what actually worksright now. One question I get a lot is, will it get easier to make AI products?

How much of this is just a moment in time? I think this is a very, very interesting question. And I think the answer is actually twofold. So the first answer is yes. Yes, it will get easier. And we know this because we've seen it.

A year ago, you had to threaten to kill your GPT-4 in order to get it to output JSON. It was like you had to threaten to kill its firstborn or something. And now it's just like a parameter in the API.

You're just like, in fact, here's the exact schema I want you to output, and it just works. So those sort of things will get easier. But I think the second part of this answer is actually no. In a lot of ways, it's not going to get easier.

And I think that comes from the fact that communication is hard. Communication is a hard thing. What do I mean by this? I actually am a big Paul Graham fan. I'm sure a lot of us are. But I actually really, really disagree with this.

And the reason why is, so he says, it seems to me AGI would mean the end of prompt engineering. Moderately intelligent humans can figure out what you want without elaborate prompts. I don't think that's true. I think that if you can think of all the times your partner has told you something and you've gotten it wrong.

You completely misinterpreted what they wanted, what their goal was. Think about onboarding a new hire. You told them to do something, and they come back, what the hell is this? I think it's really, really hard to communicate what you want to someone, especially someone that doesn't have a lot of context.

So yes, I think this is wrong. The other reason why I'm not sure it's going to get that much easier in a lot of ways is that as these models, as our products become more capable, there's just more undefined behavior.

There's more edge cases you didn't think about. And this is only becoming more true as our products have to start integrating with other tools through MCP, for example. There's going to be new data formats, new ways of doing things.

So I think that as our products become more capable, as these models get more intelligent, it's a little bit we're kind of stuck in the same situation. So this is how I like to think about it. I think you can't define the entire scope of your product's behavior upfront anymore.

You can't just say, here's the PRD, here's the document of everything I want my product to do. You actually have to iterate on it. You have to kind of ship it, see what it does, and then iterate on it.

So I think evals are a very, very important part of this, actually. But I also think there's a lot of confusion. I use the word lie as a little spicy, but I think there's a lot of misinformation around evals.

So I'm not going to share, I'm not going to rehash what evals are, I'm not going to kind of go into all the details. But I will talk about, I think, some common misconceptions I've seen around evals. So one is that this idea that evals are going to tell you how good your product is.

They're not. They're really not. If you're not familiar with Goodhart's Law, it's kind of the reason for this. The evals that you collect are only the things you already know of. It's going to be easy to saturate them.

If you look at recent model launches, a lot of them are actually performing lower on evals than previous ones, but they're just way better in real-world use. So it's not going to do this.

The other lie is this idea that, oh, OK, well, if you have a sort of imagine you have something like, how funny is my joke that my app is generating. This is the example I always hear used. You'll just ask an LLM to judge how funny your joke is.

This doesn't work. It largely does not work.

They're tempting because these LLM judges take text as an input, and they output a score, or they output a decision, whatever it is.

Largely, the best companies are not doing this. The best companies are using highly curated data sets. They're using auto-gradable evals, auto-gradable here, meaning there's some way of, in some deterministic way, figuring out if the model passed or not.

They're not really using LLM as judges. There's some edge cases here, but just largely, this is not the thing you should reach for. The last one I see, which also really confuses me, which I don't think is real, is evals on production data.

There's this idea that you should just move your offline evals online. You use the same judges, the same scoring. Largely doesn't work either. I think that, A, it could be very expensive, especially if you have some sort of judge that requires the model to be a lot smarter.

So either it's really expensive, or you're only doing a small percentage of production traffic. It's really hard to set up accurately. You're not really getting the patterns that are emerging. It's often limited to what you already know. Even OpenAI talks about this.

So they have this kind of really weird behavioral issue with ChatGPT recently. And they talk about this in their postmortem. They're like, our evals aren't going to catch everything. The evals are catching things we already knew. And real-world use is what helps us spot problems.

And so to build reliable AI apps, you really need signals. If you think about issues in an app like Sentry, you have what the issue is, but then you have how many times it happened and how many users it affected.

But for AI apps, there is no concrete error. There's no exception being thrown. And that's why I think signals are really the thing you need to be looking at.

And signals I define as, at Raindrop, we call them ground truthy indicators of your app's performance. And so the anatomy of an AI issue looks like some combination of signals, implicit and explicit, and then intents, which are what the users are trying to do.

And there's this process of essentially defining these signals, exploring these signals, and refining them. So briefly, let's talk about defining signals. There's explicit signals, which is almost like an analytics event your app can send. And then there's implicit data that's sort of hiding in your data.

Sorry, implicit signals. So a common explicit signal is thumbs up, thumbs down. But there really are way more signals than that. So ChatGPT themselves actually track what portion of a message you copy out of ChatGPT. That's something that they track.

That's a signal that they're tracking. They do preference data. You may have seen this sort of A/B, which response do you prefer? There's a whole host of possible both positive and negative signals, everything from errors to regenerating, to syntax errors if you're a coding assistant, to copy, sharing, suggesting.

We actually use this. So we have a flow where users can search for data, and we actually look at how many were marked correct, how many were marked wrong. And we can use that to figure out an RL and improve the quality of our searches.

So super interesting signal. But there's also implicit signals, which are like essentially detecting rather than judging. So we detect things like refusals, task failure, user frustration. And if you think about the Grok example, when you cluster them, it gets very interesting.

So we can look at and say, OK, there's this cluster of user frustration, and it's all around people trying to search for tweets. And that's where exploring comes in. So just like you can explore tags in Sentry, you need some way of exploring tags and metadata.

For us, that's like properties, models, et cetera, keywords, and intents. Because like I just said, the intent really changes what the actual issue is. So again, that's why we talk about the anatomy of an AI issue being the signal with the intent.

Just parting thoughts here, you really need a constant IV of your app's data. We send Slack notifications. You can do whatever you want, but you need to be looking at your data, whether that's searching it, et cetera. And then you really need to just refine and define new issues, which means you find these patterns, you look at your data, talk to your users, find new definitions of issues you weren't expecting, and then start tracking them.

So I'm going to cut this part. If you want to know how to fix these things, I'm happy to talk about some of the advancements in SFT and things I've seen work. But let's move over to Sid.

Cool. Thanks, Ben. Hey, everybody. I'm Sid. I'm the co-founder of Oleve, and we're building a portfolio of consumer products with the aim of building products that are fulfilling and productive for people's lives. We're a tiny team based out of New York that successfully scaled viral products around $6 million an hour profitably and generated about half a billion views on socials.

Today, I'm going to talk about the framework that drives the success, which is powered by Raindrop. There are two features of a viral AI product for it to be successful. The first part is a wow factor for virality, and the second part is reliable, consistent user experiences.

The problem is AI is chaotic and nondeterministic. And this begs for a structure and approach that allows us to create some sort of scaling system that still caters to the AI magic that is nondeterministic.

The idea is that we want to have a systematic approach for continuously improving our AI experiences so that we can scale to millions of users worldwide and keep experiences reliable without taking away the magic of AI that people fall in love with.

We need some way to guide the chaos instead of eliminating it. This is why we came up with Trellis. Trellis is our framework for continuously refining our AI experiences so that we can systematically improve the user experiences across our AI products at scale, designed specifically around our virality engine.

There are three core axioms to Trellis. One is discretization, where we take the infinite output space and break it down into specific buckets of focus. Then we prioritize. This involves ranking those bucket spaces by what will drive the most impact for your business.

And finally, recursive refinement. We repeat this process within those buckets of output spaces so that we can continue to create structure and order within the chaotic output plane. There are effectively six steps to Trellis. A lot of this has been shared by Ben in terms of the grounding principles of it.

The first is you want to initialize an output space by launching an MVP agent that is informed by some product priors and some product expectations. But the goal is really to collect a lot of user data. The second step is once you have all this user data, you want to correctly classify these into intents based on usage patterns.

The goal is you want to understand exactly why people are sticking to your product and what they're using in your product, especially when it's a conversational, open-ended AI agent experience. The third step is converting these intents into dedicated, semi-deterministic workflows.

A workflow is a predefined set of steps that allows you to achieve a certain output. The goal is you want these workflows to be broad enough to be useful for many possibilities, but narrow enough to be reliable. After you have your workflows, you want to prioritize them by some scoring mechanism.

This has to be something that's tied to your company's KPIs. And finally, you want to analyze these workflows from within. You want to understand the failure patterns within them. You want to understand the sub-intents, and you want to keep recursing from there, which is what step six involves.

A quick note on prioritization. There is a simple and naive way to do it, which is volume only. This involves focusing on the workflows that have the most volume. However, this leaves a lot of room on the table for improving general satisfaction across your product.

A more recommended approach is volume times negative sentiment score. In this, we try to score the expected lift we'd like to get by focusing on a workflow that might be generating a lot of negative satisfaction on your product.

An even more informed score is negative sentiment times volume times estimated achievable delta times some strategic relevance. The idea of estimated achievable delta comes down to you coming up with a way to score the actual achievable delta you can gain from working on that workflow and improving the product.

If you're going to need to train a foundational model to improve something, its achievable delta is probably near zero, depending on the kind of company you are. All in all, the goal is once you have these intents identified, you can build structured workflows where each workflow is self-attributable, deterministic, and is self-bound, which allows your teams to move much more quickly.

Because when you improve a specific workflow, all those changes are contained and self-accountable to that one workflow instead of spilling over into other workflows. This allows your team to move more reliably. And while we have a few more seconds, you can continue to further refine this process, going deeper and deeper into all your workflows.

And at the end of the day, you create magic, which is engineered, repeatable, testable, and attributable, but not accidental. If you'd like to read more about this, feel free to scan this QR code to read about our blog post on the Trellis framework.

Thank you for having me.