Building AI Products That Actually Work

Talk transcript

1. 0:00

   [on hold music] Uh, my name's Ben Hylak, and, uh, also just feeling really grateful to be with all of you guys today.

2. 0:20

   Uh, it's pretty exciting. And we're here to talk about building AI products that actually work. Um, I'll introduce this guy in a second, so it wasn't- [clears throat] ... the right order.

3. 0:30

   Uh, so I tweeted last night, I was kinda like, "What should we, uh, what should we talk about today?" Uh, and the overwhelming response I got was like, "Please no more evals."

4. 0:39

   Uh, apparently there's a lot of eval tracks. We'll touch on evals still just a little bit, but mainly we're gonna be focusing on how to iterate on AI products.

5. 0:48

   And so I think iteration is actually one of the most important parts of building AI products that actually work.

6. 0:56

   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. Uh, before that, I was actually kind of a weird background, but I used to be really into robotics.

7. 1:09

   I did, uh, avionics at SpaceX for a little bit. Um, and then most recently, I was an engineer and then on the design team at Apple for almost four years.

8. 1:18

   And, uh, we also have Sid. So, uh, in the spirit of

9. 1:23

   sh- sharing how to build things that actually work, uh, I brought Sid, who actually knows how to build products that actually work. So I think Sid is like, uh, uh, the co-founder of a company called Oleve.

10. 1:34

    Um, with just four people, they grew a suite of viral apps to over six million ARR. So Sid is gonna share, again, how to build products that actually work.

11. 1:48

    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.

12. 2:04

    Um, we've seen that it's possible to train like small models, really, really tiny models, to just be exceptional at specific tasks if you focus on a specific use case.

13. 2:14

    And we're also seeing that increasingly providers, right, are actually focusing on, on launching those sort of products, which is, you know, that might be the scary part. Um, but deep research is a great example, right?

14. 2:26

    Where ChatGPT just focused on how do we, you know, how do we collect a data set? How do we train something to just be exceptionally good at searching the web?

15. 2:35

    And they were-- I think it's one of the best products that they've released.

16. 2:39

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

17. 2:55

    Like, this is kind of a funny one. I was like, "Write some tests," and it, it actually correctly generated this hash for the word hello, you know? But it's like, I'm not sure this is like, you know, when I'm thinking about writing tests for my back end, I'm not sure that this is what I wanted, right?

18. 3:07

    Um, and it's not just OpenAI, right? Like, I think that increasingly in the last year, AI products still, even in the last couple months, even couple weeks, like there's all these weird issues.

19. 3:20

    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, [chuckles] right? So, uh, just the other day, I was using, uh, uh, Google Cloud, and I asked it where my credits are, and it was like, "Are you talking about Azure credits or Roblox credits?"

20. 3:37

    You know? And I was like, "What? How is this possible?" It's funny 'cause I tweeted this, and it's like this isn't just a one-off thing, right? Like, someone's like, "Oh, yeah, th- this exact same thing happened to me," right?

21. 3:48

    Um, g- just a few weeks ago, Grok had this crazy thing, right? Where people were asking, in this case, about enterprise software, and it's like, "Oh, by the way, you know, let's talk about, uh, the, you know, claims of [REDACTED:origin] genocide in South Africa."

22. 4:01

    You know, just completely off, off the rails here. And we only see-- we only caught something like this, only kind of entered the public, you know, awareness because Grok is public and because you can kind of see everything.

23. 4:13

    Funny enough, um, I, 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, like, rushing to get this presentation, my part of it done, uh, I asked it to find tweets of mine about AI failures, and it says,

24. 4:27

    "I don't have access to your personal Twitter. I can't search tweets." I was like, "I think it can." So I to- I try-- I double down. I'm like, "You are literally Grok.

25. 4:33

    You know, like, this is what you're made for." And it's like, "Oh, you're right. I can. I just don't have your username," [chuckles] you know? So it's absurd. And I actually like, like this is, this is yesterday, right?

26. 4:42

    This is still a bug that they have.

27. 4:46

    So I feel really lucky to be, you know, like I, like I mentioned, I, I, 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.

28. 5:00

    So it's everything from, you know, apps like Sid's, which he'll share about, to things like clay.com, you know, which is like a sales sort of outreach tool, to like alien companion apps, to coding assistants.

29. 5:12

    It's just this insane range of products. And so I get-- I think we get to see so much of like what works, what doesn't work.

30. 5:21

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

31. 5:33

    And we're kind of like, you know, we, we have this product. We're also kind of this like stealth frontier lab of some sort of where we are kind of shipping some of the coolest AI features I've ever seen.

32. 5:42

    Um, we have like tools like Deep Search that allows people to go really deep into their 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've, we've-- have a pretty good intuition of

33. 5:59

    what actually works. One question I get a lot is

34. 6:05

    will it get easier to make AI products, right? Like, 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, [laughs] right?

35. 6:15

    So the first answer is yes. Like, yes, it will get easier. Uh, and we know this because we've seen it. A year ago, you had to give, you know, threaten to kill your, you know, j- uh, GPT-4 in order to get it to output JSON, right?

36. 6:27

    Like, it was like you had to threaten to kill its firstborn or something, and now it's just, like, a parameter in the API. Like, you're just like, "In fact, here's the exact scheme I want you to output," and it just works.

37. 6:36

    So those sort of things will get easier. But I think the second part of this answer is actually no. Like, like, in a lot of ways, it's not gonna get easier, and I think that comes from the fact that communication is hard.

38. 6:47

    Like, communication is a hard thing. Um, what do I mean by this? I actually, um ... I'm a big Paul Graham fan. I'm sure a lot of u- a lot of us are.

39. 6:56

    But I actually really, really disagree with this, and the reason why is ... So, so he says, "It seems to me AGI would mean the end of prompt engineering.

40. 7:03

    Moderately intelligent humans can figure out what you want without elaborate prompts." I don't think that's true. Like, I, I think that if you can think of all the times, you know, you've, your partner has told you something and you've gotten it wrong, right?

41. 7:15

    Like, you m- completely misinterpreted what they wanted, right? What their goal was. If you think about onboarding a new hire, right, and, like, w- like, you told them to do something and they come back.

42. 7:23

    What, what the hell is this, right? Um, I think it's really, really hard to communicate what you want to someone, especially someone that doesn't have a lot of context.

43. 7:34

    So yes, I think this is wrong. The other reason why I'm not sure it's gonna 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, right?

44. 7:47

    There's more edge cases you didn't think about, and this is only becoming more true, you know, as our products have to start integrating with other tools through, like, MCP, for example.

45. 7:57

    There's gonna be new data formats, new ways of doing things. So I, I think that as our products become more capable, as the A- as these models get more intelligent, we're, it's a little bit, uh, we're kinda stuck in the same, same situation.

46. 8:10

    So this is, 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, like, you know, "Here's the PRD.

47. 8:19

    Here's the document of everything I want my product to do." Like, you actually have to iterate on it. You have to kind of ship it, see what it does, and then iterate on it.

48. 8:30

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

49. 8:44

    So I'm not gonna share, I'm not gonna, like, rehash what evals are. I'm not gonna kind of go into all the details. But I will talk about, I think, some, like, common misconceptions I've seen around evals.

50. 8:54

    So one is that this idea that evals are gonna tell you how good your product is. They're not. Um, they're really not. Uh, if you're not familiar with Goodhart's Law, it's, like, kind of the reason for this.

51. 9:04

    Um, the evals that you collect are only the things you already know of. It's gonna be easy to saturate them. If you look at recent model launches, a lot of them are actually performing lower on evals than, you know, previous ones, but they're just way better in real world use.

52. 9:18

    So it's not gonna do this. The other lie is this idea that, like, oh, okay, well, if you have a sort of like ... Imagine you have something like how funny is my joke, you know, that my app is generating.

53. 9:29

    This is the example I always hear used. You'll just, like, ask an LM to judge how funny your joke is. Um, I ... This doesn't work. Like, uh, [laughs] largely does not work.

54. 9:39

    Uh, uh, they're tempting because, you know, these LM judges take text as an input, and they output a score, or they output a decision, whatever it is. Um, like, largely, the best companies are not doing this.

55. 9:52

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

56. 10:05

    Um, they're not really using LM as judges. Um, there's some edge cases here, but just, like, largely, this is not the thing you should reach for.

57. 10:12

    The last one I see which also really confuses me, which I, I don't think is real, is, like, evals on production data. Um, there's this idea that you should just move your offline evals online.

58. 10:21

    U- use the same judges, the same scoring. Um, largely doesn't work either.

59. 10:27

    I think that, A, it can be very expensive, especially if you're, you know, you have some sort of judge that requires the model to be a lot smarter. Um, so j- either it's really expensive, or you're only doing a small percentage of production traffic.

60. 10:38

    Um, it's really hard to set up accurately. You're not really getting the patterns that are emerging. Um, it's often limited to what you already know. E- even OpenAI talks about this, so they had, like, this kind of really weird behavioral issue with ChatGPT recently, and they talk about this in their postmortem.

61. 10:55

    They're like, "You know, our evals aren't gonna catch e- everything, right? The evals are catching things we already knew, and real world use is what helps us spot problems."

62. 11:04

    And so to build reliable AI apps, you really need signals.

63. 11:09

    If you think about issues in an app like Sentry,

64. 11:13

    you have what the issue is, but then you have how many times it happened and how many users it affected.

65. 11:19

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

66. 11:30

    And signals I define as, like, an ... At Raindrop we call them, like, 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 what, which are what the users are trying to do.

67. 11:48

    And there's this process of essentially defining these signals, exploring these signals, and refining them.

68. 11:54

    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.

69. 12:05

    Uh, 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.

70. 12:19

    That's something that they track. That's a signal that they're tracking.

71. 12:23

    They do preference data, right? You may have seen this sort of AB, which response do you prefer?

72. 12:28

    There's a whole host of possible, both positive and negative signals, everything from errors to regenerating to, like, syntax errors if you're a coding assistant, to copy, sharing, suggesting.

73. 12:40

    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 on, like, h- and improve the quality of our searches.

74. 12:52

    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, like, the Groq example, when you cluster them, it gets very interesting.

75. 13:08

    So we can look at and say, "Okay, there's this cluster of user frustration, and it's all around people trying to search for tweets."

76. 13:15

    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.

77. 13:24

    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, uh, the signal with the intent.

78. 13:39

    Just parting thoughts here. You really need a constant IV of your app's data.

79. 13:44

    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.

80. 13:50

    And then you really need to just refine and define new issues, which means you look, find these patterns, look at your data, talk to your users, find new definitions of issues you weren't expecting, and then start tracking them.

81. 14:01

    So I'm gonna cut this part. If you wanna 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, uh, move over to Sid.

82. 14:10

    Cool. Thanks, Ben. Hey, everybody. I'm Sid. I'm the co-founder of Oleve, and we're building a portfolio of consumer products that have-- with the aim of building products that are fulfilling and productive for people's lives.

83. 14:22

    We're a tiny team based out of New York that successfully scaled viral products around six million dollars in ARR profitably and generated about half a billion views on socials.

84. 14:32

    Today, I'm gonna talk about the framework that drives this success, which is powered by Raindrop.

85. 14:37

    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 u- user experiences.

86. 14:47

    The problem is AI is chaotic and non-deterministic, 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 non-deterministic.

87. 15:01

    The idea is that we wanna 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.

88. 15:14

    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.

89. 15:30

    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.

90. 15:44

    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 th-the chaotic, uh, output plane.

91. 15:56

    There are effectively six steps to Trellis. A lot of this has been shared by Ben in terms of the, the grounding principles of it. The first is you wanna 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

92. 16:11

    user data. The second step is once you've unders-- Once you have all this user data, you wanna correctly classify these into intents based on usage patterns. The goal is you wanna 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.

93. 16:28

    The third step is converting these intents into dedicated semi-deme- 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.

94. 16:45

    After you have your workflows, you wanna prioritize them by some scoring mechanism. This has to be something that's tied to your company's KPIs. Um, and finally, you wanna analyze these workflows w- from within.

95. 16:54

    You wanna understand the failure patterns within them. You wanna understand the sub-intents, and you wanna keep recursing from there, which is what step six involves.

96. 17:02

    A quick note on prioritization. There's 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 pr- satisfaction across your product.

97. 17:15

    A more recommended approach is volume times negative sentiment score. In this, we try to score the ex- 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.

98. 17:28

    An even more informed score is negative sentiment times volume times estimated achievable delta times some strategic relevance. The idea of estimated achievable delta is-- 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.

99. 17:44

    If you're gonna need to train a foundation model to improve something, its achievable delta is probably near zero, depending on the kind of company you are.

100. 17:51

     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 means-- Which, which allows your teams to move much more quickly, because when you, when you, uh, improve a specific workflow,

101. 18:09

     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.

102. 18:17

     And, uh, while we have a few more seconds, you can continue to further refine this process, going deeper d- and deeper into all your workflows. And at the end of that, you create magic, which is engineered, repeatable, testable, and attributable, but not accidental.

103. 18:29

     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.

104. 18:35

     Thank you for having me. [outro music]